Re: [U-Boot] FLASH write bug on NGW100
reconstructing thread and cc'ing u-boot list; please don't
top-post :-)
when using the latest u-boot version from
git://www.denx.de/git/u-boot-avr32.git, it is not possible for me to
write (I have tried saveenv and protect) to NOR FLASH anymore.
U-Boot gives the following error: start or end address not on sector
boundary
Is this a known problem?
Gerhard
Post the exact commands you are using. Probably you are using wrong
addresses
The exact command:
U-Boot saveenv
Saving Environment to Flash...
Error: start and/or end address not on sector boundary
Seriously, it's that easy. The addresses are the default ones found in
include/configs/atngw100.h since the dawn of time :-)
--Ben.
On Wed, 2009-05-20 at 13:08 +0200, Eirik Aanonsen wrote:
I dont have tha board. What result do you get if you run: Flinfo ( post it
back here )
On Wed, 2009-05-20 at 15:54 +0200, Gerhard Berghofer wrote:
Hi Eirik,
flinfo with u-boot version = 2009.03 gives the following output:
##
Bank # 1: CFI conformant FLASH (16 x 16) Size: 8 MB in 135 Sectors
AMD Standard command set, Manufacturer ID: 0x1F, Device ID: 0x1D6
Erase timeout: 8192 ms, write timeout: 1 ms
Buffer write timeout: 1 ms, buffer size: 4 bytes
Sector Start Addresses:
A000A0002000A0004000A0006000 A0008000
A000A000A000C000A000E000A001 A002
A003A004A005A006 A007
...
flinfo with u-boot version 2008.10 gives the following output:
##
Bank # 1: CFI conformant FLASH (16 x 16) Size: 8 MB in 135 Sectors
AMD Standard command set, Manufacturer ID: 0x1F, Device ID: 0x1D6
Erase timeout: 8192 ms, write timeout: 1 ms
Buffer write timeout: 1 ms, buffer size: 4 bytes
Sector Start Addresses:
RO 2000 RO 4000 RO 6000 RO 8000
RO
A000 RO C000 RO E000 RO 0001 RO 0002
00030004000500060007
...
the FLASH seems to be attached to a wrong address range ...
Well on the AVR32 both addresses are correct - the first accessed the
flash through the uncached, untranslatable segment, now it's both cached
and translated but that should only be a win. I guess though that the
environment address (which in the config is set to 007F) is still
somehow somewhere being translated to A07F then breaking all the
flash range checking.
But I'm kinda guessing here, I hope someone on the u-boot list can tell
us it's known and fixed and we should be have scoured their archives
harder ;-)
--Ben.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/6] ATSTK1000 LCD panel support
On Wed, 2008-09-03 at 11:03 +0200, Haavard Skinnemoen wrote: Ben Nizette [EMAIL PROTECTED] wrote: Doesn't the MTD system have facility to override partitioning information from the boot arguments? If so then any big u-boots can just ship with such a clause in their default bootargs, job done. Have to look in to that... Yes. But it won't fix boards which already have a valid environment and just want to upgrade u-boot. We could perhaps fix up the bootargs and add partitioning information when preparing to boot the kernel... Hmm, I don't think anything we do will fix the case of people just trying to upgrade u-boot but keeping an old environment. Fixing the partitioning information as the kernel sees it won't alter the actual partition layout in flash, we're going to need the user's help there, and if they're repartitioning their flash there's a good chance they just nuked their old environment anyway. Right, I give in, prolly best to just keep the LCD support disabled by default, stick a page on the 'freaks wiki explaining all the steps to turn it on and try and point as many people towards that as possible. --Ben. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/6] ATSTK1000 LCD panel support
On Tue, 2008-09-02 at 14:09 +0200, Haavard Skinnemoen wrote: Right. I was thinking maybe we could extend the boot protocol to pass partitioning information from u-boot to the kernel -- that should make it possible to run the same kernel on boards with different flash layout as long as the in-flash u-boot is consistent with the flash layout. If we do end up with libfdt on avr32 then we solve our problems here too, we can encapsulate this partitioning in the fdt image. But, as I understand it, that involves not only the actual libfdt support but making all avr32 driver nice and OF compatible. At least, if we want the fdt support to be _useful_ then that needs to happen (CMIIW). One problem this doesn't solve is that if you load an older kernel which doesn't understand the extended boot protocol, it will keep using the old flash layout. Doesn't the MTD system have facility to override partitioning information from the boot arguments? If so then any big u-boots can just ship with such a clause in their default bootargs, job done. Have to look in to that... --Ben. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
