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

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

[Rogan Dawes]

Hi Albert,

I've been trying to figure out why I could not erase sectors in my flash
greater than SA70. It turned out that this was on a megabyte boundary,
and in fact, was exactly half way through my flash.

The flash is a 64Mbit part, i.e. 8MB, and I could only access the first
4MB of it, even though the ORION5X_SZ_BOOTROM parameter was set to (8 *
1024 * 1024). By "access" I mean that even md.b commands simply returned
"00", and flash erase commands returned immediately without actually
doing anything.

Doubling the value for ORION5X_SZ_BOOTROM allowed me to access the
additional sectors, but that makes me wonder what the reason for it is.

I know that the flash chip is wired up strangely, but would that also
affect the window mappings? If that is the case, I just need to document
WHY the parameter is doubled, but if not, it would be good to understand
the real reason for the change.

Rogan

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

[Albert ARIBAUD]

Le 24/08/2010 07:21, Chris Moore a ?crit :
> Hi Rogan,
>
> Le 23/08/2010 18:06, Rogan Dawes a ?crit :
>> Doubling the value for ORION5X_SZ_BOOTROM allowed me to access the
>> additional sectors, but that makes me wonder what the reason for it is.
>>
>> I know that the flash chip is wired up strangely, but would that also
>> affect the window mappings? If that is the case, I just need to document
>> WHY the parameter is doubled, but if not, it would be good to understand
>> the real reason for the change.
>>
>
> I am (very rashly) stabbing in the dark here because I don't know much
> about U-Boot and I haven't followed your previous posts (hence this
> off-list reply).
>
> However if your device size is half the bus size (like an 8-bit device
> on a 16-bit bus) it would seem logical to have to double the window size.
>
> Cheers,
> Chris

Hi Chris, BTW. :)

Rogan,

Seeing as ORION5X_SZ_BOOTROM is only used as a byte address limit for 
window mapping, and device vs bus size govern the maximum amout in a 
single bus access but do not govern its addressing, I don't think device 
width is involved here.

I'd rather ask whether this could be a window alignment issue, i.e is 
the flash base address 8 MB aligned? Seems like it, because IIRC its 
base is FF800000, which is 8MB-aligned.

Can you still try the original u-boot? Does it allow reading the full 8 
MB? If so, can you do a 'md.l 0xF1020000 40' in it, and then in your own 
u-boot with ORION5X_SZ_BOOTROM set to 8MB then 16MB? These are the 
window mapping registers, and it will allow us to know what the CPU 
really thinks boot ROM looks like. Also dump F101046C, that's the boot 
device bus configuration, again in both U-boots.

Amicalement,
-- 
Albert.

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

[Rogan Dawes]

On 2010/08/24 8:07 AM, Albert ARIBAUD wrote:
> Le 24/08/2010 07:21, Chris Moore a ?crit :
>> Hi Rogan,
>>
>> Le 23/08/2010 18:06, Rogan Dawes a ?crit :
>>> Doubling the value for ORION5X_SZ_BOOTROM allowed me to access the
>>> additional sectors, but that makes me wonder what the reason for it is.
>>>
>>> I know that the flash chip is wired up strangely, but would that also
>>> affect the window mappings? If that is the case, I just need to document
>>> WHY the parameter is doubled, but if not, it would be good to understand
>>> the real reason for the change.
>>>
>>
>> I am (very rashly) stabbing in the dark here because I don't know much
>> about U-Boot and I haven't followed your previous posts (hence this
>> off-list reply).
>>
>> However if your device size is half the bus size (like an 8-bit device
>> on a 16-bit bus) it would seem logical to have to double the window size.
>>
>> Cheers,
>> Chris
> 
> Hi Chris, BTW. :)
> 
> Rogan,
> 
> Seeing as ORION5X_SZ_BOOTROM is only used as a byte address limit for
> window mapping, and device vs bus size govern the maximum amout in a
> single bus access but do not govern its addressing, I don't think device
> width is involved here.
> 
> I'd rather ask whether this could be a window alignment issue, i.e is
> the flash base address 8 MB aligned? Seems like it, because IIRC its
> base is FF800000, which is 8MB-aligned.
> 
> Can you still try the original u-boot? Does it allow reading the full 8
> MB? If so, can you do a 'md.l 0xF1020000 40' in it, and then in your own
> u-boot with ORION5X_SZ_BOOTROM set to 8MB then 16MB? These are the
> window mapping registers, and it will allow us to know what the CPU
> really thinks boot ROM looks like. Also dump F101046C, that's the boot
> device bus configuration, again in both U-boots.
> 
> Amicalement,

Hi Albert,

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:

> md.l f1020000 40
f1020000: 07ff5941 90000000 40000000 00000000    AY......... at ....
f1020010: 07ff5931 98000000 40000000 00000000    1Y......... at ....
f1020020: 000f5141 f0000000 00000000 00000000    AQ..............
f1020030: 000f5131 f0100000 00000000 00000000    1Q..............
f1020040: 007f0f11 ff800000 00000000 00000000    ................
f1020050: 001f1e11 fa000000 00000000 00000000    ................
f1020060: 01ff1d11 f8000000 00000000 00000000    ................
f1020070: 000f1b11 fa800000 00000000 00000000    ................
f1020080: f1000000 00000000 00000000 00000000    ................
f1020090: 00000000 00000000 00000000 00000000    ................
f10200a0: 00000000 00000000 00000000 00000000    ................
f10200b0: 00000000 00000000 00000000 00000000    ................
f10200c0: 00000000 00000000 00000000 00000000    ................
f10200d0: 00000000 00000000 00000000 00000000    ................
f10200e0: 00000000 00000000 00000000 00000000    ................
f10200f0: 00000000 00000000 00000000 00000000    ................

Mainline (8MB window):

> md.l f1020000 40
f1020000: 03ff5941 90000000 90000000 00000000    AY..............
f1020010: 00005141 f0000000 90000000 00000000    AQ..............
f1020020: 03ff5931 98000000 00000000 00000000    1Y..............
f1020030: 00005131 f0100000 00000000 00000000    1Q..............
f1020040: 000f1e11 fa000000 00000000 00000000    ................
f1020050: 00ff1d11 f8000000 00000000 00000000    ................
f1020060: 00071b11 fa800000 00000000 00000000    ................
f1020070: 003f0f11 ff800000 00000000 00000000    ..?.............
f1020080: f1000000 00000000 00000000 00000000    ................
f1020090: 00000000 00000000 00000000 00000000    ................
f10200a0: 00000000 00000000 00000000 00000000    ................
f10200b0: 00000000 00000000 00000000 00000000    ................
f10200c0: 00000000 00000000 00000000 00000000    ................
f10200d0: 00000000 00000000 00000000 00000000    ................
f10200e0: 00000000 00000000 00000000 00000000    ................
f10200f0: 00000000 00000000 00000000 00000000    ................

Mainline (16MB window):

> md.l f1020000 40
f1020000: 03ff5941 90000000 90000000 00000000    AY..............
f1020010: 00005141 f0000000 90000000 00000000    AQ..............
f1020020: 03ff5931 98000000 00000000 00000000    1Y..............
f1020030: 00005131 f0100000 00000000 00000000    1Q..............
f1020040: 000f1e11 fa000000 00000000 00000000    ................
f1020050: 00ff1d11 f8000000 00000000 00000000    ................
f1020060: 00071b11 fa800000 00000000 00000000    ................
f1020070: 007f0f11 ff800000 00000000 00000000    ................
f1020080: f1000000 00000000 00000000 00000000    ................
f1020090: 00000000 00000000 00000000 00000000    ................
f10200a0: 00000000 00000000 00000000 00000000    ................
f10200b0: 00000000 00000000 00000000 00000000    ................
f10200c0: 00000000 00000000 00000000 00000000    ................
f10200d0: 00000000 00000000 00000000 00000000    ................
f10200e0: 00000000 00000000 00000000 00000000    ................
f10200f0: 00000000 00000000 00000000 00000000    ................
>

$ diff vendor mainline_8MB
< Vendor u-boot:
> Mainline (8MB window):
---
< f1020000: 07ff5941 90000000 40000000 00000000    AY.........@....
> f1020000: 03ff5941 90000000 90000000 00000000    AY..............
---
< f1020010: 07ff5931 98000000 40000000 00000000    1Y.........@....
> f1020010: 00005141 f0000000 90000000 00000000    AQ..............
---
< f1020020: 000f5141 f0000000 00000000 00000000    AQ..............
> f1020020: 03ff5931 98000000 00000000 00000000    1Y..............
---
< f1020030: 000f5131 f0100000 00000000 00000000    1Q..............
> f1020030: 00005131 f0100000 00000000 00000000    1Q..............
---
< f1020040: 007f0f11 ff800000 00000000 00000000    ................
> f1020040: 000f1e11 fa000000 00000000 00000000    ................
---
< f1020050: 001f1e11 fa000000 00000000 00000000    ................
> f1020050: 00ff1d11 f8000000 00000000 00000000    ................
---
< f1020060: 01ff1d11 f8000000 00000000 00000000    ................
> f1020060: 00071b11 fa800000 00000000 00000000    ................
---
< f1020070: 000f1b11 fa800000 00000000 00000000    ................
> f1020070: 003f0f11 ff800000 00000000 00000000    ..?.............

$ diff vendor mainline_16MB
< Vendor u-boot:
> Mainline (16MB window):
---
< f1020000: 07ff5941 90000000 40000000 00000000    AY.........@....
> f1020000: 03ff5941 90000000 90000000 00000000    AY..............
---
< f1020010: 07ff5931 98000000 40000000 00000000    1Y.........@....
> f1020010: 00005141 f0000000 90000000 00000000    AQ..............
---
< f1020020: 000f5141 f0000000 00000000 00000000    AQ..............
> f1020020: 03ff5931 98000000 00000000 00000000    1Y..............
---
< f1020030: 000f5131 f0100000 00000000 00000000    1Q..............
> f1020030: 00005131 f0100000 00000000 00000000    1Q..............
---
< f1020040: 007f0f11 ff800000 00000000 00000000    ................
> f1020040: 000f1e11 fa000000 00000000 00000000    ................
---
< f1020050: 001f1e11 fa000000 00000000 00000000    ................
> f1020050: 00ff1d11 f8000000 00000000 00000000    ................
---
< f1020060: 01ff1d11 f8000000 00000000 00000000    ................
> f1020060: 00071b11 fa800000 00000000 00000000    ................
---
< f1020070: 000f1b11 fa800000 00000000 00000000    ................
> f1020070: 007f0f11 ff800000 00000000 00000000    ................

$ diff mainline_8MB mainline_16MB
< Mainline (8MB window):
> Mainline (16MB window):
---
< f1020070: 003f0f11 ff800000 00000000 00000000    ..?.............
> f1020070: 007f0f11 ff800000 00000000 00000000    ................

Here is the dump of the other region you requested, too. It is the same
on all versions of u-boot:

> md.l f101046c 40
f101046c: 8fcfffff 00000000 00000000 00000000    ................
f101047c: 00000000 00000000 00000000 00000000    ................
f101048c: 00000000 00000000 00000000 00000000    ................
f101049c: 00000000 00000000 00000000 00000000    ................
f10104ac: 00000000 00000000 00000000 00000000    ................
f10104bc: 00000000 0004ffff 00000000 00000000    ................
f10104cc: 00000000 00000000 00000000 00000000    ................
f10104dc: 0000001f 0000781f 00000000 f007d8c0    .....x..........
f10104ec: 00000000 00000042 00000000 00000000    ....B...........
f10104fc: 00000000 00000000 00000000 00000000    ................
f101050c: 00000000 00000000 00000000 00000000    ................
f101051c: 00000000 00000000 00000000 00000000    ................
f101052c: 00000000 00000000 00000000 00000000    ................
f101053c: 00000000 00000000 00000000 00000000    ................
f101054c: 00000000 00000000 00000000 00000000    ................
f101055c: 00000000 00000000 00000000 00000000    ................

Hope this makes sense!

Rogan

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

[Albert ARIBAUD]

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,
-- 
Albert.

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

[Rogan Dawes]

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

[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.

[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.
>