Mike Frysinger [Tue, 20 Apr 2010 09:49:30 +0000 (05:49 -0400)]
compiler.h: add uint typedef
Recent crc changes started using the "uint" type in headers that are used
on the build system. This subsequently broke mingw targets as they do not
provide such a type. So add this basic typedef to compiler.h so that we
do not have to worry about this breaking again in the future.
Add zboot command which takes the address of a bzImage as its first
argument and (optionally) the size of the bzImage as the second argument
(the second argument is needed for older kernels which do not include
the bzImage size in the header)
x86: Provide weak PC/AT compatibility setup function
It is possibly to setup x86 boards to use non-PC/AT configurations. For
example, the sc520 is an x86 CPU with PC/AT and non-PC/AT peripherals.
This function allows the board to set itself up for maximum PC/AT
compatibility just before booting the Linux kernel (the Linux kernel
'just works' if everything is PC/AT compliant)
The x86 architecture exclusively uses Port-Mapped I/O (inb/outb) to access
the 16550 UARTs. This patch mimics how Linux selects between Memory-Mapped
and Port-Mapped I/O. This allows x86 boards to use CONFIG_SERIAL_MUTLI and
drop the custom serial port driver
Currently, the GDT is either located in FLASH or in the non-relocated
U-Boot image in RAM. Both of these locations are unsafe as those
locations can be erased during a U-Boot update. Move the GDT into the
highest available memory location and relocate U-Boot to just below it
Add a parameter to the 32-bit entry to indicate if entry is from Real
Mode or not. If entry is from Real Mode, execute the destructive 'sizer'
routine to determine memory size as we are booting cold and running in
Flash. If not entering from Real Mode, we are executing a U-Boot image
from RAM and therefore the memory size is already known (and running
'sizer' will destroy the running image)
There are now two 32-bit entry points. The first is the 'in RAM' entry
point which exists at the start of the U-Boot binary image. As such,
you can load u-boot.bin in RAM and jump directly to the load address
without needing to calculate any offsets. The second entry point is
used by the real-to-protected mode switch
This patch also changes TEXT_BASE to 0x6000000 (in RAM). You can load
the resulting image at 0x6000000 and simple go 0x6000000 from the u-boot
prompt
Hopefully a later patch will completely elliminate any dependency on
TEXT_BASE like a relocatable linux kernel (perfect world)
This patch allows the low-level assembler boot-strap to obtain the RAM
size without calling the destructive 'sizer' routine. This allows
boot-strapping from a U-Boot image loaded in RAM
There is an error in how the assembler version of the sc520 memory size
reporting code works. As a result, it will only ever report at most the
size of one bank of RAM
cmd_onenand.c: moved to standard subcommand handling
On the fly also fixed the following things:
- write help talked about a parameter oob, but that one was not used, so
removed it from the help message.
- the test command also allowed a force subcommand but didn't use it.
eliminated the code.
- do_onenand made static
- do_onenand contained
int blocksize;
...
mtd = &onenand_mtd;
this = mtd->priv;
blocksize = (1 << this->erase_shift);
As blocksize was not used the last two statements were unneeded so
removed them.
The first statement (mtd = ....) assigns to a global. Not sure if it
is needed, and since I could not test this, left the line for now
Signed-off-by: Frans Meulenbroeks <fransmeulenbroeks@gmail.com>
ppc: unused memory region too close to current stack pointer
This avoids a possible overwrite of the (end of) ramdisk by u-boot.
The unused memory region for ppc boot currently starts 1k below the
do_bootm->bootm_start->arch_lmb_reserve stack ptr. This isn't enough since
do_bootm->do_bootm_linux->boot_relocate_fdt calls printf which may
very well use more than 1k stack space.
Signed-off-by: Norbert van Bolhuis <nvbolhuis@aimvalley.nl>
Timur Tabi [Tue, 13 Apr 2010 18:16:03 +0000 (13:16 -0500)]
allow print_size to print large numbers on 32-bit systems
Modify print_size() so that it can accept numbers larger than 4GB on 32-bit
systems.
Add support for display terabyte, petabyte, and exabyte sizes. Change the
output to use International Electrotechnical Commission binary prefix standard.
Timur Tabi [Tue, 13 Apr 2010 18:16:02 +0000 (13:16 -0500)]
fix print_size printing fractional gigabyte numbers on 32-bit platforms
In print_size(), the math that calculates the fractional remainder of a number
used the same integer size as a physical address. However, the "10 *" factor
of the algorithm means that a large number (e.g. 1.5GB) can overflow the
integer if we're running on a 32-bit system. Therefore, we need to
disassociate this function from the size of a physical address.
MVSMR board support doesn't link since recent rework
of U-Boot directory structure. Fix it now.
Signed-off-by: Anatolij Gustschin <agust@denx.de> Cc: Andre Schwarz <andre.schwarz@matrix-vision.de> Acked-by: Andre Schwarz <andre.schwarz@matrix-vision.de>
Fixed merge conflict Signed-off-by: Wolfgang Denk <wd@denx.de>
net:kirkwood_egiga.c: MAC addresses programming using write_hwaddr
Added a new function kwgbe_write_hwaddr for programming egiga
controller's hardware address.
This function will be called for each egiga port being used
Signed-off-by: Prafulla Wadaskar <prafulla@marvell.com> Signed-off-by: Ben Warren <biggerbadderben@gmail.com>
Ben Warren [Mon, 26 Apr 2010 18:11:46 +0000 (11:11 -0700)]
Program net device MAC addresses after initializing
Add a new function to the eth_device struct for programming a network
controller's hardware address.
After all network devices have been initialized and the proper MAC address
for each has been determined, make a device driver call to program the
address into the device. Only device instances with valid unicast addresses
will be programmed.
Signed-off-by: Ben Warren <biggerbadderben@gmail.com> Acked-by: Detlev Zundel <dzu@denx.de> Tested-by: Prafulla Wadaskar <prafulla@marvell.com> Tested-by: Heiko Schocher <hs@denx.de> Tested-by: Thomas Chou <thomas@wytron.com.tw>
SMSC911x chips have alignment function to allow frame payload data
(which comes after 14-bytes ethernet header) to be aligned at some
boundary when reading it from fifo (usually - 4 bytes boundary).
This is done by inserting fake zeros bytes BEFORE actual frame data when
reading from SMSC's fifo.
This function controlled by RX_CFG register. There are bits that
represents amount of fake bytes to be inserted.
Linux uses alignment of 4 bytes. Ethernet frame header is 14 bytes long,
so we need to add 2 fake bytes to get payload data aligned at 4-bytes
boundary.
Linux driver does this by adding IP_ALIGNMENT constant (defined at
skb.h) when calculating fifo data length. All network subsystem of Linux
uses this constant too when calculating different offsets.
But u-boot does not use any packet data alignment, so we don't need to
add anything when calculating fifo data length.
Moreover, driver zeros the RX_CFG register just one line up, so chip
does not insert any fake data at the beginig. So calculated data length
is always bigger by 1 word.
It seems that at almost every packet read we get an underflow condition
at fifo and possible corruption of data. Especially at continuous
transfers, such as tftp.
Just after removing this magic addition, I've got tftp transfer speed as
it aught to be at 100Mbps. It was really slow before.
It seems that fifo underflow occurs only when using byte packing on
32-bit blackfin bus (may be because of very small delay between reads).
Signed-off-by: Valentin Yakovenkov <yakovenkov@niistt.ru> Signed-off-by: Ben Warren <biggerbadderben@gmail.com>
Cosmetic changes: Few comments updated
Functionality: Rx packet frame size is programming should
be done when port is in disabled state. this is corrected
Signed-off-by: Prafulla Wadaskar <prafulla@marvell.com> Signed-off-by: Ben Warren <biggerbadderben@gmail.com>
Eric Jarrige [Thu, 15 Apr 2010 22:03:19 +0000 (00:03 +0200)]
fec_mxc.c: Fix MX27 FEC MAC validity check
Fix MX27 FEC logic to check validity of the MAC address in fuse.
Only null (empty fuse) or invalid MAC address was retrieved from mx27 fuses before this change.
Signed-off-by: Eric Jarrige <jorasse@armadeus.org> Signed-off-by: Ben Warren <biggerbadderben@gmail.com>
Andy Fleming [Mon, 19 Apr 2010 19:54:49 +0000 (14:54 -0500)]
tsec: Wait for both RX and TX to stop
When gracefully stopping the controller, the driver was continuing if
*either* RX or TX had stopped. We need to wait for both, or the
controller could get into an invalid state.
Signed-off-by: Andy Fleming <afleming@freescale.com> Signed-off-by: Ben Warren <biggerbadderben@gmail.com>
Mike Frysinger [Wed, 14 Apr 2010 20:29:06 +0000 (16:29 -0400)]
net: dm9000x: use standard I/O accessors
The current dm9000x driver accesses its memory mapped registers directly
instead of using the standard I/O accessors. This can cause problems on
Blackfin systems as the accesses can get out of order. So convert the
direct volatile dereferences to use the normal in/out macros.
Signed-off-by: Mike Frysinger <vapier@gentoo.org> Signed-off-by: Ben Warren <biggerbadderben@gmail.com>
Robin Getz [Mon, 8 Mar 2010 19:07:00 +0000 (14:07 -0500)]
./net/net.c - make Microsoft dns servers happy with random_port() numbers
For some reason, (which I can't find any documentation on), if U-Boot
gives a port number higher than 17500 to a Microsoft DNS server, the
server will reply to port 17500, and U-Boot will ignore things (since
that isn't the port it asked the DNS server to reply to).
This fixes that by ensuring the random port number is less than 17500.
Signed-off-by: Robin Getz <rgetz@blackfin.uclinux.org> Signed-off-by: Ben Warren <biggerbadderben@gmail.com>
This patch fixes following build warnings for kirkwood_egiga.c
kirkwood_egiga.c: In function "kwgbe_init":
kirkwood_egiga.c:448: warning: dereferencing type-punned pointer will break strict-aliasing rules
kirkwood_egiga.c: In function "kwgbe_recv":
kirkwood_egiga.c:609: warning: dereferencing type-punned pointer will break strict-aliasing rules
Signed-off-by: Prafulla Wadaskar <prafulla@marvell.com> Signed-off-by: Ben Warren <biggerbadderben@gmail.com>
Stefano Babic [Wed, 31 Mar 2010 08:27:47 +0000 (10:27 +0200)]
MX31: Support 128MB RAM on QONG module
The QONG module can be downsized and delivered
with 128MB instead of 256MB. The patch adds
run time support for the two different memory
configurations.
Stefano Babic [Mon, 29 Mar 2010 14:43:39 +0000 (16:43 +0200)]
MX31: Add support for NAND to QONG board
The NAND device is connected to the FPGA of the QONG board
and not to the NFC controller. For this reason, the FPGA must
be set and initialized before accessing to the NAND itself.
configs/sheevaplug: added a few additional commands
This patch includes a few additional commands in the sheevaplug
version of u-boot:
- support for LONGHELP so you can get help messages
- auto completion and command editing
- ubi and mii support
- ext2 filesystem (convenient if you have an ext2 from which you want to boot)
- jffs2 and ubifs filesystems (if you want to use these in NAND)
This also makes it more similar to openrd client.
Side effect of this patch is that the code now needs 3 sectors i.s.o. 2
so an existing env is overwritten
Signed-off-by: Frans Meulenbroeks <fransmeulenbroeks@gmail.com>
Heiko Schocher [Fri, 5 Mar 2010 06:36:33 +0000 (07:36 +0100)]
arm, i.mx27: add support for magnesium board from projectiondesign
This patch adds support for the magnesium board from
projectiondesign. This board uses i.MX27 SoC and has
8MB NOR flash, 128MB NAND flash, FEC ethernet controller
integrated into i.MX27. As this port is based on
the imx27lite port, common config options are collected
in include/configs/imx27lite-common.h
Stefan Roese [Tue, 27 Apr 2010 09:37:28 +0000 (11:37 +0200)]
ppc4xx: Add support for ICON board (PPC440SPe)
This patch adds support for the Mosaix Technologies, Inc. ICON board,
based on the AppliedMicro (AMCC) PPC440SPe. It's equipped with an SODIMM
(512MB standard) and 64MByte of NOR FLASH.
Support for the onboard SM502 will be added later.
Wolfgang Denk [Wed, 28 Apr 2010 08:53:47 +0000 (10:53 +0200)]
mtdparts: fix write through NULL pointer
The "mtdparts add" command wrote through a NULL pointer - on many
systems this went unnoticed (PowerPC has writable RAM there, some ARM
systems have ROM where a write has no effect), but on arm1136
(i.MX31) it crashed the system.
projects / u-boot.git / log