[U-Boot] [patch] csb337 board support (ARM at91rm9200)

[David Brownell <david-b@pacbell.net>]

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.