On Thursday 25 June 2009, Jean-Christophe PLAGNIOL-VILLARD wrote: > On 14:58 Fri 12 Jun , David Brownell wrote: > > Add support for csb337, an older at91rm9200 board. These boards > > originally shipped with MicroMonitor, not U-Boot. This config > > supports boot from Ethernet, and talks over I2C and console. > > > > Open issues: > > - Console refuses to start at 115200 baud, and misbehaves if it's > > later changed to that speed. So, use 38400 (like MicroMonitor). > > A co-worker report me the same problem for the csb637 under uMON > after trying U-Boot it's work fine > I think there is a problem in the clock configuration > I'll take a look later
Hmm, could be. This replicates the original clock settings and DRAM timings. DRAM is underclocked -- could be another 20 MHz faster or so (use divide-by-3 not divide-by-4). But changing that would mean re-computing *all* memory timings. And I don't think I have copies of that old Strataflash stuff any more... > > - USB didn't work; the software wouldn't detect usb-storage devices. > > So it's not yet enabled. > > what is the power on the USB? I don't understand the question. 5V of course. Not switchable. > > - There seems to be some issue copying lots of data from NOR flash. > > It works OK in chunks of up to 512 KB or so, but copying a kernel > > (1.4 MB) failed ... copying *way* over 15 MBytes, and trashing > > the DRAM image of U-Boot that was running. (Compiler issue?) > > Clock issue ot RAM timing issue Doesn't quite make sense. Something clobbered a termination condition, which would be in a register, or at worst in cache. How would RAM timing cause breakage? The data copied was correct, in smaller chunks, and the termination condition wasn't stored in RAM. Or a clock issue, considering all the relevant cycles are inside the arm920t core? I like the "compiler issue" theory better. :( > > board/csb337/u-boot.lds | 56 +++++++++++ > > no need please remove In mainline u-boot it seems to be needed. Can you maybe push your first set of patches to Wolfgang, which consolidate all that stuff? > > +#if defined(CONFIG_DRIVER_ETHER) && defined(CONFIG_CMD_NET) > it will be better ot manage this in the config header You mean by defining an otherwise needless symbol, along the lines of CONFIG_SYS_AT91RM9200_LXT_PHY? Probably simpler just always include those few lines, and not support building without Ethernet. > > + > > +/* The AT91 lxt972 glue modified the original lxt971 code by > > + * changing names and generalizing a bit. So we use "lxt972" > > + * names here even though the CSB337 has an lxt971 chip. > > + */ > > +extern unsigned char lxt972_InitPhy(AT91S_EMAC *mac); > > +extern unsigned lxt972_IsPhyConnected(AT91S_EMAC *mac); > > +extern unsigned char lxt972_GetLinkSpeed(AT91S_EMAC *mac); > > +extern unsigned char lxt972_AutoNegotiate(AT91S_EMAC *mac, int *status); > :( > please a header I'll stick it in hardware.h ... you can remove similar decls from other rm9200 boards then. > > + > > +#if 0 > please > if CONFIG_CMD_USB > > +/* REVISIT: USB failed to enumerate devices of any kind ... sw issues */ An #if 0 won't work without completely re-whacking things. Right now the commands kick in *MUCH LATER* depending on whether the driver is available. And here, the driver (CONFIG_USB_OHCI_NEW driver) and its support is disabled since it's not working... > > + > > +/* allow loading from USB media */ > > +#define CONFIG_USB_OHCI_NEW > > +#define CONFIG_SYS_USB_OHCI_MAX_ROOT_PORTS 2 > > +#define CONFIG_SYS_USB_OHCI_REGS_BASE AT91_USB_HOST_BASE > > +#define CONFIG_SYS_USB_OHCI_SLOT_NAME "at91-ohci" > > +#define CONFIG_USB_STORAGE > > +#endif > > + > > +/* I2C, RTC */ > > +#define CONFIG_HARD_I2C > > +#define CONFIG_SYS_I2C_SPEED 100000 > > +#define CONFIG_SYS_I2C_SLAVE 0x08 /* SMBus host address */ > > + > > +#define CONFIG_RTC_DS1307 > > + > > +/* basic commands; and ones that need driver support */ > > +#include <config_cmd_default.h> ... and commands get configured starting here. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot