December 2003 - U-Boot

[U-Boot-Users] RE: [PATCH] probe for smc91111.c before chip init.
by Woodruff, Richard 07 Dec '03

07 Dec '03

Seems I did the order wrong in the diff. Here is the corrected version. Sorry/Regards, Richard W. -----Original Message----- From: Woodruff, Richard Sent: Monday, December 01, 2003 12:07 PM To: u-boot-users(a)lists.sourceforge.net Subject: [PATCH] probe for smc91111.c before chip init. Hello, This patch adds: - a probe to verify the existence of the 91c111 chip prior to attempting to init registers. This allows the code to live in systems where the chip is not present or disabled. Prior to this a "tftp" or "dhcp" would hang if attempted when the chip was not there, now it just returns immediately. The system I use has a plug in ether debug board, so this probe is useful and allows having a single image around. - a mac address set function outside of smc_open. This proves useful when boot happens with out the chip being touched but the kernel wants etherent. The current Linux kernel drivers assume the MAC address is good so having it set here saves messing around with the kernel driver. - all signed characters are now unsigned. A previous patch was issued with out changing all references. This gets them all. Regards, Richard W.

4 3

[U-Boot-Users] [PATCH] cmd_flash.c
by Woodruff, Richard 07 Dec '03

07 Dec '03

Hello, This patch causes cmd_flash.c to report errors. There are several cases where the flash commands can return silently even if they fail. This is can lead to further problems. ...done with some of the easy patches. One of the people here just got a USB client serial console running, it can do Kermit at blazing speed and allows the use of u-boot with out a rs232 header on OMAPs. Don't have the time to break up all the needed patches. Regards, Richard W.

2 1

[U-Boot-Users] [PATCH] cache flush for arm925.
by Woodruff, Richard 07 Dec '03

07 Dec '03

Hello, The included patch adds a cache flush for the arm925 cpu. This is necessary when downloading and executing code (as icache is currently enabled). The flush is both an I and D flush, though I is all that is strictly necessary at the moment. Regards, Richard W.

2 1

[U-Boot-Users] [PATCH] probe for smc91111.c before chip init.
by Woodruff, Richard 07 Dec '03

07 Dec '03

Hello, This patch adds: - a probe to verify the existence of the 91c111 chip prior to attempting to init registers. This allows the code to live in systems where the chip is not present or disabled. Prior to this a "tftp" or "dhcp" would hang if attempted when the chip was not there, now it just returns immediately. The system I use has a plug in ether debug board, so this probe is useful and allows having a single image around. - a mac address set function outside of smc_open. This proves useful when boot happens with out the chip being touched but the kernel wants etherent. The current Linux kernel drivers assume the MAC address is good so having it set here saves messing around with the kernel driver. - all signed characters are now unsigned. A previous patch was issued with out changing all references. This gets them all. Regards, Richard W.

2 1

[U-Boot-Users] Re: Ethernet on PPC Ebony not working
by Pavel Bartusek 07 Dec '03

07 Dec '03

Hello, I guess you are using 10MB ethernet. In the 440 is between EMAC and PHY inserted so called ZMII bridge, which can operate in several modes. If is in the RMII mode then is necessary to set correct speed in the ZMII Speed Select Register. The following patch will fix this problem. Pavel Bartusek Sysgo AG --- u-boot-1.0.0/cpu/ppc4xx/405gp_enet.c.ori 2003-09-10 20:20:30.000000000 +0200 +++ u-boot-1.0.0/cpu/ppc4xx/405gp_enet.c 2003-11-21 18:08:34.000000000 +0100 @@ -67,6 +67,9 @@ * 17-Jun-02 stefan.roese(a)esd-electronics.com * - MAL error debug printf 'M' removed (rx de interrupt may * occur upon many incoming packets with only 4 rx buffers). + * 21-Nov-03 pavel.bartusek(a)sysgo.com + * - set ZMII bridge speed on 440 + * *-----------------------------------------------------------------------------*/ #include <common.h> @@ -414,6 +417,14 @@ out32 (EMAC_M1, mode_reg); +#if defined(CONFIG_440) + /* set speed in the ZMII bridge */ + if (speed == _100BASET) + out32(ZMII_SSR, in32(ZMII_SSR) | 0x10000000); + else + out32(ZMII_SSR, in32(ZMII_SSR) & ~0x10000000); +#endif + /* Enable broadcast and indvidual address */ out32 (EMAC_RXM, EMAC_RMR_BAE | EMAC_RMR_IAE /*| EMAC_RMR_ARRP| EMAC_RMR_SFCS | EMAC_RMR_SP */ );

2 1

[U-Boot-Users] [PATCH] mismatched #ifdef/#endif
by Anders Larsen 07 Dec '03

07 Dec '03

Hi, the header include/asm-arm/arch-pxa/hardware.h contains mismatched #ifdef/#endif (more precisely, one #endif too many in line 88, which is "compensated for" farther below in line 99). The attached patch fixes this. CHANGELOG: Fix a mismatched #ifdef / #endif sequence Cheers Anders

2 1

[U-Boot-Users] [PATCH] (MIPS) Support for all dbau1x00 boards
by Thomas Lange 07 Dec '03

07 Dec '03

Use different configurations for the boards from AMD ( dbau1000, dbau1100 and dbau1500 ). Only tested for dbau1000, but compiles for all three. Users with dbau1100 and dbau1500 should check that the cpu is compatible with au1000. * Patch by Thomas Lange 14 Oct 2003 Split dbau1x00 into dbau1000, dbau1100 and dbau1500 configs /Thomas

3 2

[U-Boot-Users] [PATCH] (MIPS) Au1x00 phymem workaround
by Thomas Lange 07 Dec '03

07 Dec '03

Au1x00 uses a 36 bit bus internally and cannot access physical memory directly. Use the uncached sdram address instead of the physical one. * Patch by Thomas Lange 14 Nov 2003 Workaround for mips au1x00 physical memory accesses /Thomas

2 1

[U-Boot-Users] Where to get DENX' Linux 2.4.20?
by Jarno Gassenbauer 07 Dec '03

07 Dec '03

Hi, I just got Das U-Boot 1.0.0 working on my custom 8245 board (yay! :-) and am peeking for linux now. However, the CVS HEAD of DENX contains 2.4.23 which adds function pointers to struct bd_info while U-Boot 1.0.0 doesn't. So, which CVS tag can I use to get a 2.4.20 that works with U-Boot? Best regards, Jarno PS: Thank you for the U-Boot.

2 1

[U-Boot-Users] [PATCH][CFT] bring ARM memory layout in line with the documented behaviour
by Anders Larsen 07 Dec '03

07 Dec '03

Hi, here's a fairly lengthy patch against 0.4.8 that brings the memory layout of all supported ARM CPUs in line with the documentation. This has the positive side-effect of allowing U-Boot to actually run on PXA CPUs (the stock PXA implementation didn't set the start-address of the malloc pool at all!) The memory layout now more or less conforms to the standard as defined in the README (the absolute addresses are board-specific, of course). Since the stack and malloc-heap are now located below the U-Boot code, the TEXT_BASE of the supported ARM boards can be increased accordingly (for most (but not all) boards, the patch already does this). Memory layout example based on my PXA255 (TEXT_BASE = 0xA07E0000): 0xA079FF74 Monitor Stack (growing downwards) 0xA079FF80 Board Info Data and permanent copy of Global Data 0xA07A0000 Malloc Arena 0xA07E0000 RAM copy of Monitor Code ... optional: Frame Buffer 0xA07FFFFF [End of RAM] Since I only have access to PXA-based HW, I was only able to verify that U-Boot still *builds* for all supported ARMs; I have to rely on your help to see if it also *runs* correctly. CHANGELOG: Bring ARM memory layout in line with the documentation. Wolfgang: Please don't apply this patch until we have some feedback from the ARM maintainers. Robert: When/if this patch is eventually applied, you can probably push most of your PXA -ptx stuff without having it break things. Cheers Anders

5 16