-----Original Message----- From: Albert ARIBAUD [mailto:albert.aribaud@free.fr] Sent: Tuesday, August 24, 2010 6:22 PM To: Rogan Dawes Cc: Chris Moore; u-boot@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.