Artem Bityutskiy [Fri, 27 Mar 2009 09:21:14 +0000 (10:21 +0100)]
UBIFS: add R/O compatibility
Now UBIFS is supported by u-boot. If we ever decide to change the
media format, then people will have to upgrade their u-boots to
mount new format images. However, very often it is possible to
preserve R/O forward-compatibility, even though the write
forward-compatibility is not preserved.
This patch introduces a new super-block field which stores the
R/O compatibility version.
Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com> Acked-by: Adrian Hunter <Adrian.Hunter@nokia.com> Signed-off-by: Stefan Roese <sr@denx.de>
Ladislav Michl [Mon, 23 Mar 2009 11:06:07 +0000 (12:06 +0100)]
Separate mtdparts command from jffs2
On Thu, Mar 19, 2009 at 01:30:36PM +0100, Stefan Roese wrote:
> Currently the mtdparts commands are included in the jffs2 command support.
> This doesn't make sense anymore since other commands (e.g. UBI) use this
> infrastructure as well now. This patch separates the mtdparts commands from
> the jffs2 commands making it possible to only select mtdparts when no JFFS2
> support is needed.
... and to make it useful for NAND chips as well, we should also remove now
unrelated CONFIG_JFFS2_NAND. Note that struct part_info etc is in
jffs2/load_kernel.h which is a bit misleading filename for that purpose,
but that can be fixed later (tm).
Signed-off-by: Ladislav Michl <ladis@linux-mips.org>
Mike Frysinger [Mon, 23 Mar 2009 02:18:01 +0000 (22:18 -0400)]
smc91111_eeprom: move board-specific init into SMC91111_EEPROM_INIT()
Rather than sticking Blackfin-specific stuff into the eeprom example, use
an indirect macro so that any board can override it with their own magic
sauce in their board config file.
Also fix some spurious semi-colons in defines while I'm at it ...
Signed-off-by: Mike Frysinger <vapier@gentoo.org> CC: Ben Warren <biggerbadderben@gmail.com>
Ulf Samuelsson [Fri, 27 Mar 2009 22:26:43 +0000 (23:26 +0100)]
Add support for the AT91RM9200EK Board.
The AT91RM9200-EK Evaluation Board supports the AT91RM9200
ARM9-based 32-bit RISC microcontroller and enables real-time code development
and evaluation.
Here is the chip page on Atmel website:
http://www.atmel.com/dyn/products/tools_card.asp?tool_id=3507
with
- NOR (cfi driver)
- DataFlash
- USB OHCI
- Net
- I2C (hard)
Kumar Gala [Sat, 4 Apr 2009 15:21:02 +0000 (10:21 -0500)]
fsl_law: Fix bug in calculation of LAW sizing
In set_ddr_laws() when we determined how much of the size requested
to be mapped was covered by the the first LAW we needed to recalculate
the size based on what was actually mapped.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Wolfgang Denk [Sat, 4 Apr 2009 14:10:40 +0000 (16:10 +0200)]
Fix building of env_embedded.o
Since commit a706bfc7 common/env_embedded.o and tools/envcrc were
only built when CONFIG_ENV_IS_EMBEDDED was set, but this breaks
building for many boards.
We always have to build these files when CONFIG_ENV_IS_IN_FLASH is
set.
Some systems have zlib.h installed in /usr/include/. This isn't the
desired file for u-boot code - we want the one in include/zlib.h.
This rename will avoid the conflict.
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> Signed-off-by: Mike Frysinger <vapier@gentoo.org>
include/ns16550.h: Unify structure declaration for registers
Instead of special casing the different access patterns, use common
code with light macros sprinkled in to accomodate for the different
layouts of the register structure.
Note that this also changes the types of the registers for the
"positively packed (>1)" cases. As the registers truly are unsigned
chars, this is surely the Right Thing, but it is a semantic change.
Note that for this case depending on the endianness on the bus, we may
see a change of behaviour.
Peter Tyser [Fri, 13 Mar 2009 23:54:51 +0000 (18:54 -0500)]
Add support for building native win32 tools
Add support for compiling the host tools in the tools directory using
the MinGW toolchain. This produces executables which can be used on
standard Windows computers without requiring cygwin.
One must specify the MinGW compiler and strip utilities as if they
were the host toolchain in order to build win32 executables, eg:
make HOSTCC=i586-mingw32msvc-gcc HOSTSTRIP=i586-mingw32msvc-strip tools
Peter Tyser [Fri, 13 Mar 2009 23:54:43 +0000 (18:54 -0500)]
tools: Remove unecessary symlinking of zlib.h
crc32.c uses the zlib.h header in include/u-boot/zlib.h. The symlink
was previously necessary to give U-Boot's version of zlib.h precedence
over the host computer's version of zlib.h.
Peter Tyser [Fri, 13 Mar 2009 23:54:34 +0000 (18:54 -0500)]
tools/Makefile: Split variable declarations into multiple lines
Split variable declarations into multiple lines and use the standard
VAR-y convention. Also move object and binary variable declarations to
after config.mk has been included to allow for these lists to utilize
the CONFIG_XXX variables.
These changes lay the groundwork for conditional compilation of files
in the tools directory.
Peter Tyser [Fri, 13 Mar 2009 23:54:31 +0000 (18:54 -0500)]
gen_eth_addr: Use POSIX rand() and srand()
Replace random()/srandom() use with rand()/srand() to support
compilation with the mingw toolchain. The rand()/srand() functions are
generally more common and are functionally equivalent to the original
random()/srandom() calls.
Peter Tyser [Fri, 13 Mar 2009 23:54:25 +0000 (18:54 -0500)]
Makefile: Make autoconf.mk a dependency of the depend target
The original code did not generate autoconf.mk until after some targets
dependencies had already been calculated, for example the directories in
the SUBDIRS variable
unsik Kim [Wed, 25 Feb 2009 02:31:24 +0000 (11:31 +0900)]
mflash: Initial mflash support
Mflash is fusion memory device mainly targeted consumer eletronic and
mobile phone.
Internally, it have nand flash and other hardware logics and supports
some different operation (ATA, IO, XIP) modes.
IO mode is custom mode for the host that doesn't have IDE interface.
(Many mobile targeted SoC doesn't have IDE bus)
This driver support mflash IO mode.
Followings are brief descriptions about IO mode.
1. IO mode based on ATA protocol and uses some custom command. (read
confirm, write confirm)
2. IO mode uses SRAM bus interface.
Rename common ns16550 constants with UART_ prefix to prevent conflicts
Fix problems introduced in commit 7b5611cdd12ca0cc33f994f0d4a4454788fc3124 [inka4x0: Add hardware
diagnosis functions for inka4x0] which redefined MSR_RI which is
already used on PowerPC systems.
Also eliminate redundant definitions in ps2mult.h. More cleanup will
be needed for other redundant occurrences though.
Scott Wood [Wed, 1 Apr 2009 20:33:24 +0000 (15:33 -0500)]
Noisily disable the legacy NAND subsystem.
Legacy NAND is marked for feature removal after April 2009 (i.e. this
upcoming release). There are still several boards that reference it
(though many do so only for disk-on-chip support which has been silently
disabled for a while now). These boards will now fail to build
with #error, though the code is still there if the user removes #error.
The plan is to remove the code outright in the next release, along with
any board code that refers to it (such as board/esd/common/auto_update.c).
Also, remove the legacy NAND API description from README.nand.
Signed-off-by: Scott Wood <scottwood@freescale.com>
apgmoorthy [Fri, 27 Mar 2009 09:15:23 +0000 (14:45 +0530)]
Fix OneNAND ipl to read CONFIG_SYS_MONITOR_LEN
Currently OneNAND initial program loader (ipl) reads only block 0 ie 128KB.
However, u-boot image for apollon board is 195KB making the board
unbootable with OneNAND.
Fix ipl to read CONFIG_SYS_MONITOR_LEN.
CONFIG_SYS_MONITOR_LEN macro holds the U-Boot image size.
Wolfgang Denk [Wed, 1 Apr 2009 21:34:12 +0000 (23:34 +0200)]
Add "source" command; prepare removal of "autoscr" command
According to the doc/feature-removal-schedule.txt, the "autoscr"
command will be replaced by the "source" command in approximately 6
months from now.
This patch prepares this change and starts a 6 month transition
period as follows:
- The new "source" command has been added, which implements exactly
the same functionlaity as the old "autoscr" command before
- The old "autoscr" command name is kept as an alias for compatibility
- Command sequences, script files atc. have been adapted to use the
new "source" command
- Related environment variables ("autoscript", "autoscript_uname")
have *not* been adapted yet; these will be renamed resp. removed in
a separate patch when the support for the "autoscr" command get's
finally dropped.
Mike Frysinger [Thu, 2 Apr 2009 16:51:28 +0000 (12:51 -0400)]
sf: stmicro: dont send 4 bytes when reading status register
I can't find anywhere in the datasheet that says the status register needs
3 dummy bytes sent to it before being able to read back the first real
result. Tests on a Blackfin board show that after writing the opcode, the
status register starts coming back immediately. So only write out the
read status register opcode before polling the result.
Signed-off-by: Mike Frysinger <vapier@gentoo.org> CC: Jason McMullan <mcmullan@netapp.com> CC: TsiChung Liew <Tsi-Chung.Liew@freescale.com>
Mike Frysinger [Thu, 2 Apr 2009 12:11:31 +0000 (08:11 -0400)]
sf: set common timeouts in seconds, not milliseconds
Since timeouts are only hit when there is a problem in the system, we
don't want to prematurely timeout on a functioning setup. Thus having
low timeouts (in milliseconds) doesn't gain us anything in the production
case, but rather increases likely hood of causing problems where none
otherwise exist.
Signed-off-by: Mike Frysinger <vapier@gentoo.org> CC: Haavard Skinnemoen <haavard.skinnemoen@atmel.com>
Mike Frysinger [Sat, 28 Mar 2009 10:41:09 +0000 (06:41 -0400)]
sf: always read 5 bytes for the idcode
Some SPI flash drivers like to have extended id information available
(like the spansion flash), so rather than making it re-issue the ID cmd
to get at the last 2 bytes, have the common code read 5 bytes rather than
just 3. This also matches the Linux behavior where it always reads 5 id
bytes from all flashes.
Signed-off-by: Mike Frysinger <vapier@gentoo.org> Acked-by: Haavard Skinnemoen <haavard.skinnemoen@atmel.com> CC: Mingkai Hu <Mingkai.hu@freescale.com>
Mike Frysinger [Fri, 13 Feb 2009 22:10:58 +0000 (17:10 -0500)]
Blackfin: fix crash when booting from external memory
When testing a u-boot binary that hasn't been booted from the bootrom, we
have to make sure the bootstruct structure has sane storage space. If we
don't, the initcode will crash when it tries to dereference an invalid
pointer.
Emil Medve [Mon, 23 Feb 2009 16:43:36 +0000 (10:43 -0600)]
Fix a possible overflow case detected by gcc 4.3.2
.../dtc/libfdt/fdt_sw.c: In function 'fdt_end_node':
.../dtc/libfdt/fdt_sw.c:81: error: assuming signed overflow does not occur when assuming that (X + c) < X is always false
Signed-off-by: Emil Medve <Emilian.Medve@Freescale.com>
David Gibson [Fri, 6 Feb 2009 03:03:24 +0000 (14:03 +1100)]
libfdt: Rework/cleanup fdt_next_tag()
Currently, callers of fdt_next_tag() must usually follow the call with
some sort of call to fdt_offset_ptr() to verify that the blob isn't
truncated in the middle of the tag data they're going to process.
This is a bit silly, since fdt_next_tag() generally has to call
fdt_offset_ptr() on at least some of the data following the tag for
its own operation.
This patch alters fdt_next_tag() to always use fdt_offset_ptr() to
verify the data between its starting offset and the offset it returns
in nextoffset. This simplifies fdt_get_property() which no longer has
to verify itself that the property data is all present.
At the same time, I neaten and clarify the error handling for
fdt_next_tag(). Previously, fdt_next_tag() could return -1 instead of
a tag value in some circumstances - which almost none of the callers
checked for. Also, fdt_next_tag() could return FDT_END either because
it encountered an FDT_END tag, or because it reached the end of the
structure block - no way was provided to tell between these cases.
With this patch, fdt_next_tag() always returns FDT_END with a negative
value in nextoffset for an error. This means the several places which
loop looking for FDT_END will still work correctly - they only need to
check for errors at the end. The errors which fdt_next_tag() can
report are:
- -FDT_ERR_TRUNCATED if it reached the end of the structure
block instead of finding a tag.
- -FDT_BADSTRUCTURE if a bad tag was encountered, or if the
tag data couldn't be verified with fdt_offset_ptr().
This patch also updates the callers of fdt_next_tag(), where
appropriate, to make use of the new error reporting.
Finally, the prototype for the long gone _fdt_next_tag() is removed
from libfdt_internal.h.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
David Gibson [Fri, 6 Feb 2009 03:01:56 +0000 (14:01 +1100)]
libfdt: Rework fdt_next_node()
Currently fdt_next_node() will find the next node in the blob
regardless of whether it is above, below or at the same level in the
tree as the starting node - the depth parameter is updated to indicate
which is the case. When a depth parameter is supplied, this patch
makes it instead terminate immediately when it finds the END_NODE tag
for a node at depth 0. In this case it returns the offset immediately
past the END_NODE tag.
This has a couple of advantages. First, this slightly simplifies
fdt_subnode_offset(), which no longer needs to explicitly check that
fdt_next_node()'s iteration hasn't left the starting node. Second,
this allows fdt_next_node() to be used to implement
_fdt_node_end_offset() considerably simplifying the latter function.
The other users of fdt_next_node() either don't need to iterate out of
the starting node, or don't pass a depth parameter at all. Any
callers that really need to iterate out of the starting node, but keep
tracking depth can do so by biasing the initial depth value.
This is a semantic change, but I think it's very unlikely to break any
existing library users.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Scott Wood [Tue, 31 Mar 2009 22:49:36 +0000 (17:49 -0500)]
mpc83xx: Set guarded bit on BAT that covers the end of the address space
The mpc8313erdb board currently sets DBAT6 to cover all of the final 256MiB of
address space; however, not all of this space is covered by a device. In
particular, flash sits at 0xfe000000-0xfe7fffff, and nothing is mapped
at the far end of the address space.
In zlib, there is a loop that references p[-1] if p is non-NULL. Under
some circumstances, this leads to the CPU speculatively loading from
0xfffffff8 if p is NULL. This leads to a machine check.
Signed-off-by: Scott Wood <scottwood@freescale.com>
continuation to the remaining mpc83xx boards that suffer from the same problem.
Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
Kim Phillips [Mon, 30 Mar 2009 19:28:05 +0000 (14:28 -0500)]
rtc: remove broken rtc_read and rtc_write declarations
commit 04e11cf3 "rtc: add support for 4543 RTC (manufactured by e.g.
EPSON)" introduces the following build error on boards configuring e.g,
the ds1374 rtc:
Configuring for MPC837XEMDS board...
ds1374.c:103: error: static declaration of 'rtc_read' follows non-static declaration
/home/r1aaha/git/u-boot/include/rtc.h:64: error: previous declaration of 'rtc_read' was here
ds1374.c:104: error: conflicting types for 'rtc_write'
/home/r1aaha/git/u-boot/include/rtc.h:65: error: previous declaration of 'rtc_write' was here
this reverts the erroneous chunk.
Signed-off-by: Kim Phillips <kim.phillips@freescale.com> Acked-by: Detlev Zundel <dzu@denx.de> CC: Detlev Zundel <dzu@denx.de> CC: Andreas Pfefferle <ap@denx.de>
projects / u-boot / log