DNS323 (Orion5x) must double ORION5X_SZ_BOOTROM to access full flash
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
A message that is not in the archive (sent off-list or not yet received): [email protected]
Le 24/08/2010 07:21, Chris Moore a ?crit :
Quoted 16 lines
Hi Rogan,
Le 23/08/2010 18:06, Rogan Dawes a ?crit :
Quoted 8 lines
Doubling the value for
ORION5X_SZ_BOOTROMallowed 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).
Quoted 5 lines
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,
Signature · 1 line
Albert.
Quoted 36 lines · Albert ARIBAUD
Le 24/08/2010 07:21, Chris Moore a ?crit :
Quoted 16 lines
Hi Rogan,
Le 23/08/2010 18:06, Rogan Dawes a ?crit :
Quoted 8 lines
Doubling the value for
ORION5X_SZ_BOOTROMallowed 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).
Quoted 5 lines
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,
ChrisHi Chris, BTW. :)
Rogan,
Seeing as
ORION5X_SZ_BOOTROMis 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.
Quoted 8 lines
Can you still try the original u-boot? Does it allow reading the full 8 MB? If so, can you do a 'md.l
0xF102000040' in it, and then in your own u-boot withORION5X_SZ_BOOTROMset 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:
Quoted 1 line
md.l
f102000040
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):
Quoted 1 line
md.l
f102000040
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):
Quoted 1 line
md.l
f102000040
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 ................
Quoted 1 line
$ diff vendor mainline_8MB < Vendor u-boot:
Quoted 1 line
Mainline (8MB window):
---
< f1020000: 07ff5941 90000000 40000000 00000000 AY.........@....
Quoted 1 line
f1020000:03ff594190000000 90000000 00000000 AY..............
---
< f1020010: 07ff5931 98000000 40000000 00000000 1Y.........@....
Quoted 1 line
f1020010: 00005141f000000090000000 00000000 AQ..............
---
< f1020020: 000f5141 f0000000 00000000 00000000 AQ..............
Quoted 1 line
f1020020:03ff593198000000 00000000 00000000 1Y..............
---
< f1020030: 000f5131 f0100000 00000000 00000000 1Q..............
Quoted 1 line
f1020030: 00005131f010000000000000 00000000 1Q..............
---
< f1020040: 007f0f11 ff800000 00000000 00000000 ................
Quoted 1 line
f1020040:000f1e11fa00000000000000 00000000 ................
---
< f1020050: 001f1e11 fa000000 00000000 00000000 ................
Quoted 1 line
f1020050:00ff1d11f800000000000000 00000000 ................
---
< f1020060: 01ff1d11 f8000000 00000000 00000000 ................
Quoted 1 line
f1020060:00071b11fa80000000000000 00000000 ................
---
< f1020070: 000f1b11 fa800000 00000000 00000000 ................
Quoted 1 line
f1020070:003f0f11ff80000000000000 00000000 ..?.............
$ diff vendor mainline_16MB < Vendor u-boot:
Quoted 1 line
Mainline (16MB window):
---
< f1020000: 07ff5941 90000000 40000000 00000000 AY.........@....
Quoted 1 line
f1020000:03ff594190000000 90000000 00000000 AY..............
---
< f1020010: 07ff5931 98000000 40000000 00000000 1Y.........@....
Quoted 1 line
f1020010: 00005141f000000090000000 00000000 AQ..............
---
< f1020020: 000f5141 f0000000 00000000 00000000 AQ..............
Quoted 1 line
f1020020:03ff593198000000 00000000 00000000 1Y..............
---
< f1020030: 000f5131 f0100000 00000000 00000000 1Q..............
Quoted 1 line
f1020030: 00005131f010000000000000 00000000 1Q..............
---
< f1020040: 007f0f11 ff800000 00000000 00000000 ................
Quoted 1 line
f1020040:000f1e11fa00000000000000 00000000 ................
---
< f1020050: 001f1e11 fa000000 00000000 00000000 ................
Quoted 1 line
f1020050:00ff1d11f800000000000000 00000000 ................
---
< f1020060: 01ff1d11 f8000000 00000000 00000000 ................
Quoted 1 line
f1020060:00071b11fa80000000000000 00000000 ................
---
< f1020070: 000f1b11 fa800000 00000000 00000000 ................
Quoted 1 line
f1020070:007f0f11ff80000000000000 00000000 ................
$ diff mainline_8MB mainline_16MB < Mainline (8MB window):
Quoted 1 line
Mainline (16MB window):
---
< f1020070: 003f0f11 ff800000 00000000 00000000 ..?.............
Quoted 1 line
f1020070:007f0f11ff80000000000000 00000000 ................
Here is the dump of the other region you requested, too. It is the same on all versions of u-boot:
Quoted 1 line
md.l
f101046c40
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
Le 24/08/2010 09:47, Rogan Dawes a ?crit :
Quoted 7 lines
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:007f0f11ff80000000000000 00000000 ................
Quoted 7 lines
Mainline (8MB window):
f1020070:003f0f11ff80000000000000 00000000 ..?.............Mainline (16MB window):
f1020070:007f0f11ff80000000000000 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,
Signature · 1 line
Albert.
Quoted 29 lines · Albert ARIBAUD
Le 24/08/2010 09:47, Rogan Dawes a ?crit :
Quoted 7 lines
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:007f0f11ff80000000000000 00000000 ................Quoted 7 lines
Mainline (8MB window):
f1020070:003f0f11ff80000000000000 00000000 ..?.............Mainline (16MB window):
f1020070:007f0f11ff80000000000000 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 be00ff0f11.007f0f11is 8MB, and003f0f11is 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. :(
Quoted 5 lines
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
Le 24/08/2010 14:17, Rogan Dawes a ?crit :
Quoted 36 lines · Albert ARIBAUD
Quoted 29 lines
Le 24/08/2010 09:47, Rogan Dawes a ?crit :
Quoted 7 lines
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:007f0f11ff80000000000000 00000000 ................Quoted 7 lines
Mainline (8MB window):
f1020070:003f0f11ff80000000000000 00000000 ..?.............Mainline (16MB window):
f1020070:007f0f11ff80000000000000 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 be00ff0f11.007f0f11is 8MB, and003f0f11is 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. :(
Quoted 5 lines
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,
Quoted 7 lines
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,
Signature · 1 line
Albert.
Quoted 76 lines
-----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 doubleORION5X_SZ_BOOTROMto access full flashLe 24/08/2010 14:17, Rogan Dawes a ?crit :
Quoted 4 lines · Albert ARIBAUD
Quoted 3 lines
Le 24/08/2010 09:47, Rogan Dawes a ?crit :
Quoted 1 line
Yes, I still have the vendor u-boot flashed, so I can
still see its
Quoted 1 line
Quoted 1 line
Quoted 1 line
configuration. And, yes, it does allow reading the full
8MB of flash.
Quoted 9 lines
Quoted 9 lines
Quoted 8 lines
Vendor u-boot:
f1020040:007f0f11ff80000000000000 00000000 ................Mainline (8MB window):
f1020070:003f0f11ff80000000000000 00000000 ..?.............Quoted 8 lines
Quoted 8 lines
Quoted 3 lines
Mainline (16MB window):
f1020070:007f0f11ff80000000000000 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 MBwindow would be
Quoted 1 line
Quoted 1 line
00ff0f11.007f0f11is 8MB, and003f0f11is 4 MB. Thus,what you think is
Quoted 1 line
Quoted 1 line
a 16MB widow is actually a 8MB one, and the 8MB one is
actually 4MB,
Quoted 3 lines
Quoted 3 lines
which explains the issues you have.
I've just checked the code for computing the window size
in mainline
Quoted 9 lines
Quoted 8 lines
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,
Quoted 7 lines
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.
Quoted 2 lines
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 . .
Quoted 5 lines
Amicalement,
Signature · 1 line
Albert.