Re: [U-Boot] DNS323 (Orion5x) must double ORION5X_SZ_BOOTROM to access full flash
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,
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.........@.... f1020010: 07ff5931 98000000 40000000 00000000 1Y.........@.... 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
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,
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
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,
-----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.
participants (3)
-
Albert ARIBAUD -
Prafulla Wadaskar -
Rogan Dawes