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

[Albert ARIBAUD]

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.

Amicalement,
-- 
Albert.