[U-Boot] Fixing IXP42x boards - some general questions

[Marek Vasut]

On Thursday 23 December 2010 11:10:37 Wolfgang Denk wrote:
> Dear Michael Schwingen,
> 
> In message <4D13175F.8030207 at discworld.dascon.de> you wrote:
> > Startup code. Is the following correct?
> > 
> >  - code starts from flash, with TEXT_BASE = start of flash, ie. the code
> > 
> > is linked to flash addresses.
> 
> Correct.
> 
> >  - DATA/BSS are behind the text segment in flash, so the code may not
> > 
> > write RAM variables until relocation
> 
> Correct.
> 
> In addition, BSS is not initialized yet, so you should not even try
> reading variables in BSS, as these will contain random data.  This
> affects especially static variables that are supposed to be
> initialized with zero.
> 
> >  - code in flash sets up RAM, copies + relocates u-boot to RAM, and
> > 
> > continues there
> 
> Correct.
> 
> > Timer system.
> > 
> >  - For IXP, there are two variants of the timer system - one using
> > 
> > interrupts, and one without interrupts. Both do not work currently.
> > I have patches that fix the non-interrupt version, changing
> > CONFIG_SYS_HZ from 66666666 to 1000, bringing it in line with what most
> > other ARM platforms do.
> 
> I cannot nomment on this.  Marek?

http://download.intel.com/design/network/manuals/25248006.pdf page 411 or so.

What's the second variant ? Either way -- you should use the non-interrupt 
version. Remember, you're writing a bootloader, use the KISS principle ; you 
generally use the timer only to implement *delay() functions.

Therefore, as Wolfgang said, you use 1000 ticks per second in uboot's internal 
counting, but "convert" it from/to your real timer's ticks in timer.c

What problem do you have there? Also, can you please let us see the patches?
> 
> > What is the preferred way of handling timers? Should CONFIG_SYS_HZ be
> > 1000 or rather the timer clock?
> 
> CONFIG_SYS_HZ must always be defiend as 1000.
> 
> > What about interrupts? Use them or avoid them?
> 
> If you can do without interrupts, I would do that, because it's
> simpler.
> 
> > What about the Intel reference board (IXDP425)? Previously, I used that
> > one as a reference on how things should be done, but it looks broken,
> > too. I can prepare patches for IXDP425, but I can't currently test them
> > (we should have one at work, but that might take some time).
> 
> I cannot help with that either.  Marek?

Go ahead, patches are welcome. I don't have any ixp hardware, but it looks fairy 
similar to pxa, it should be easy to review patches.
> 
> Best regards,
> 
> Wolfgang Denk

Cheers