* [U-Boot] DNS323 (Orion5x) must double ORION5X_SZ_BOOTROM to access full flash
@ 2010-08-23 16:06 Rogan Dawes
[not found] ` <4C7356E0.500@free.fr>
0 siblings, 1 reply; 7+ messages in thread
From: Rogan Dawes @ 2010-08-23 16:06 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 7+ messages in thread[parent not found: <4C7356E0.500@free.fr>]
* [U-Boot] DNS323 (Orion5x) must double ORION5X_SZ_BOOTROM to access full flash [not found] ` <4C7356E0.500@free.fr> @ 2010-08-24 6:07 ` Albert ARIBAUD 2010-08-24 7:47 ` Rogan Dawes 0 siblings, 1 reply; 7+ messages in thread From: Albert ARIBAUD @ 2010-08-24 6:07 UTC (permalink / raw) To: u-boot 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* [U-Boot] DNS323 (Orion5x) must double ORION5X_SZ_BOOTROM to access full flash 2010-08-24 6:07 ` Albert ARIBAUD @ 2010-08-24 7:47 ` Rogan Dawes 2010-08-24 11:34 ` Albert ARIBAUD 0 siblings, 1 reply; 7+ messages in thread From: Rogan Dawes @ 2010-08-24 7:47 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* [U-Boot] DNS323 (Orion5x) must double ORION5X_SZ_BOOTROM to access full flash 2010-08-24 7:47 ` Rogan Dawes @ 2010-08-24 11:34 ` Albert ARIBAUD 2010-08-24 12:17 ` Rogan Dawes 0 siblings, 1 reply; 7+ messages in thread From: Albert ARIBAUD @ 2010-08-24 11:34 UTC (permalink / raw) To: u-boot 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* [U-Boot] DNS323 (Orion5x) must double ORION5X_SZ_BOOTROM to access full flash 2010-08-24 11:34 ` Albert ARIBAUD @ 2010-08-24 12:17 ` Rogan Dawes 2010-08-24 12:52 ` Albert ARIBAUD 0 siblings, 1 reply; 7+ messages in thread From: Rogan Dawes @ 2010-08-24 12:17 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* [U-Boot] DNS323 (Orion5x) must double ORION5X_SZ_BOOTROM to access full flash 2010-08-24 12:17 ` Rogan Dawes @ 2010-08-24 12:52 ` Albert ARIBAUD 2010-08-25 4:38 ` Prafulla Wadaskar 0 siblings, 1 reply; 7+ messages in thread From: Albert ARIBAUD @ 2010-08-24 12:52 UTC (permalink / raw) To: u-boot 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* [U-Boot] DNS323 (Orion5x) must double ORION5X_SZ_BOOTROM to access full flash 2010-08-24 12:52 ` Albert ARIBAUD @ 2010-08-25 4:38 ` Prafulla Wadaskar 0 siblings, 0 replies; 7+ messages in thread From: Prafulla Wadaskar @ 2010-08-25 4:38 UTC (permalink / raw) To: u-boot > -----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. > ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2010-08-25 4:38 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-08-23 16:06 [U-Boot] DNS323 (Orion5x) must double ORION5X_SZ_BOOTROM to access full flash Rogan Dawes
[not found] ` <4C7356E0.500@free.fr>
2010-08-24 6:07 ` Albert ARIBAUD
2010-08-24 7:47 ` Rogan Dawes
2010-08-24 11:34 ` Albert ARIBAUD
2010-08-24 12:17 ` Rogan Dawes
2010-08-24 12:52 ` Albert ARIBAUD
2010-08-25 4:38 ` Prafulla Wadaskar
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.