[U-Boot] DNS323 (Orion5x) must double ORION5X_SZ_BOOTROM to access full flash

[Prafulla Wadaskar]

> -----Original Message-----
> From: Albert ARIBAUD [mailto:albert.aribaud at free.fr] 
> Sent: Tuesday, August 24, 2010 6:22 PM
> To: Rogan Dawes
> Cc: Chris Moore; u-boot at lists.denx.de; Prafulla Wadaskar
> Subject: Re: [U-Boot] DNS323 (Orion5x) must double 
> ORION5X_SZ_BOOTROM to access full flash
> 
> Le 24/08/2010 14:17, Rogan Dawes a écrit :
> > On 2010/08/24 1:34 PM, Albert ARIBAUD wrote:
> >> Le 24/08/2010 09:47, Rogan Dawes a écrit :
> >>
> >>> Yes, I still have the vendor u-boot flashed, so I can 
> still see its
> >>> configuration. And, yes, it does allow reading the full 
> 8MB of flash.
> >>
> >>> Vendor u-boot:
> >>
> >>> f1020040: 007f0f11 ff800000 00000000 00000000    ................
> >>
> >>> Mainline (8MB window):
> >>
> >>> f1020070: 003f0f11 ff800000 00000000 00000000    ..?.............
> >>
> >>> Mainline (16MB window):
> >>
> >>> f1020070: 007f0f11 ff800000 00000000 00000000    ................
> >>
> >> The good news is that your flash works normally.
> >>
> >> The bad news is that the mainline settings you are showing here are
> >> wrong with respect to the ORION5X_SZ_BOOTROM: A 16 MB 
> window would be
> >> 00ff0f11. 007f0f11 is 8MB, and 003f0f11 is 4 MB. Thus, 
> what you think is
> >> a 16MB widow is actually a 8MB one, and the 8MB one is 
> actually 4MB,
> >> which explains the issues you have.
> >>
> >> I've just checked the code for computing the window size 
> in mainline
> >> u-boot, and it is off by one, reducing the actual window mapping by
> >> half. :(
> >>
> >> They weird thing is that it affect *all* windows, RAM included; we
> >> should have seen other issues! I'll do some checks later today and
> >> provide an officiel bugfix this evening.
> >>
> >> Amicalement,
> >
> > Hi Albert,
> >
> > Thanks for looking at this.
> >
> > Do you mean that your own u-boot is also misconfigured?
> >
> > Rogan
> 
> Yes, it is, to the point that just like you, I can only flash 
> the lower 
> half of my (512KB) flash -- when I did the flash tests, it escaped me 
> because I only erased and flashed small sectors at the 
> beginning of the 
> flash. :/
> 
> As for RAM, thanks to Wolfgang's suggestion to use 
> get_ram_size() rather 
> than the (now evidently buggy) SoC's calculation routine, mainline 
> u-boot actually finds the real amount of RAM regardless of any macro 
> value, which explains why u-boot could access RAM above the 
> first half, 
> and especially the upmost megabyte as I am doing now.
> 
> Bugfix patch on its way, and adding Prafulla as this bug also hits 
> kirkwood SoC code from which the calculation code was taken.

Thanks
I will check this for Kirkwood

Regards..
Prafulla . .

> 
> Amicalement,
> -- 
> Albert.
>