> -----Original Message----- > From: Albert ARIBAUD [mailto:albert.arib...@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. > _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
