[U-Boot] Help with Glomation GESBC-9G20
I am trying to upgrade U-Boot on a Glomation GESBC-9G20 (a derivative of the Atmel AT91SAM9G20-EK) to a version that supports UBIFS. The latest U-Boot does not work. (See also my report on the Glomation user forum, http://glomation.net/smf/index.php/topic,1389.0.html.)
The GESBC-9G20 comes with a patched U-Boot 1.3.4. I built U-Boot 1.3.4 with Glomation patches using both the Glomation ARM cross development tool chain and the Code Sourcery 2013.05 ARM EABI cross development tool chain. Both work fine. I built the latest U-Boot release (2013.04) and the U-Boot git tree (2013.07 preview) version using the Code Sourcery tool chain (the Glomation tool chain is too old). Neither work. They both hang at:
ˇRomBOOT Start AT91Bootstrap...
In topic http://glomation.net/smf/index.php/topic,1382.0.html, it says the latest U-Boot supports the AT91SAM9G20. That seems to be true for an Atmel AT91SAM9G20-EK. But, U-Boot built for an AT91SAM9G20-EK does not seem to work on my GESBC-9G20.
Glomation's response about the differences:
The GESBC-9G20 is a slimmed down version of the Atmel AT91SAM9G20-ek (the earlier version with 1 SD card slot). The audio, serial EEPROM, etc were omitted. The binary code (bootstrap, U-Boot, kernel) from Atmel can run directly on the GESBC-9G20.
As far as I can tell from the SAM-BA download log file, U-Boot fits in its flash partition:
<snip> -I- === Erase all the NAND flash blocs and test the erasing === -I- GENERIC::EraseAll -I- === Load the bootstrap: nandflash_at91sam9-ek in the first sector === GENERIC::SendFile nandflash_at91sam9g20ek.bin at address 0x0 -I- File size : 0x1078 byte(s) -I- Complete 0% -I- Writing: 0x1078 bytes at 0x0 (buffer addr : 0x20003E38) -I- 0x1078 bytes written by applet -I- === Load the u-boot in the next sectors === -I- Send File u-boot-2013.07-git.bin at address 0x00020000 GENERIC::SendFile u-boot-2013.07-git.bin at address 0x20000 -I- File size : 0x3E054 byte(s) -I- Complete 0% -I- Writing: 0x20000 bytes at 0x20000 (buffer addr : 0x20003E38) -I- 0x20000 bytes written by applet -I- Complete 51% -I- Writing: 0x1E054 bytes at 0x40000 (buffer addr : 0x20003E38) -I- 0x1E054 bytes written by applet -I- === Load the u-boot environment variables === -I- Send File ubootEnvtFileNandFlash.bin at address 0x00060000 GENERIC::SendFile ubootEnvtFileNandFlash.bin at address 0x60000 -I- File size : 0x20000 byte(s) -I- Complete 0% -I- Writing: 0x20000 bytes at 0x60000 (buffer addr : 0x20003E38) -I- 0x20000 bytes written by applet -I- === Load the Kernel image === -I- Send File uImage-3.2.6 at address 0x00100000 GENERIC::SendFile uImage-3.2.6 at address 0x100000 <snip> -I- === Load the linux file system === -I- Send File 9260rootfs.img at address 0x00400000 GENERIC::SendFile 9260rootfs.img at address 0x400000 <snip>
I could use some guidance to track down the problem.
Larry Baker US Geological Survey 650-329-5608 baker@usgs.gov
Below are the steps I followed (plus, I ran SAM-BA under Windows 8 to write the bootstrap, u-boot, kernel, and rootfs to flash memory):
• Download and build U-Boot 1.3.4 with Glomation patches using the Glomation ARM cross development tool chain.
$ mkdir -p /opt/gesbc-9g20/u-boot $ cd /opt/gesbc-9g20/u-boot $ wget http://ftp.denx.de/pub/u-boot/u-boot-1.3.4.tar.bz2
Download u-boot-1.3.4-exp.5.diff from the Glomation user forum topic, reply #1, at http://glomation.net/smf/index.php/topic,1389.0.html
$ tar -xjf u-boot-1.3.4.tar.bz2 $ cd u-boot-1.3.4 $ patch -p1 < ../u-boot-1.3.4-exp.5.diff $ make ARCH=arm CROSS_COMPILE=arm-unknown-linux-gnu- at91sam9g20ek_nandflash_config $ make ARCH=arm CROSS_COMPILE=arm-unknown-linux-gnu- $ cp u-boot.bin /opt/gesbc-9g20/u-boot-1.3.4.bin
• Repeat the build using the Code Sourcery ARM cross development tool chain.
$ cd /opt/gesbc-9g20/u-boot/u-boot-1.3.4 $ make ARCH=arm CROSS_COMPILE=arm-none-eabi- distclean $ make ARCH=arm CROSS_COMPILE=arm-none-eabi- at91sam9g20ek_nandflash_config $ make ARCH=arm CROSS_COMPILE=arm-none-eabi- $ cp u-boot.bin /opt/gesbc-9g20/u-boot-1.3.4.bin
• Download and build the latest U-Boot stable release using the Code Sourcery ARM cross development tool chain.
$ cd /opt/u-boot $ wget http://ftp.denx.de/pub/u-boot/u-boot-latest.tar.bz2 $ tar -xjf u-boot-latest.tar.bz2 $ cd u-boot-2013.04 $ make ARCH=arm CROSS_COMPILE=arm-none-eabi- distclean $ make ARCH=arm CROSS_COMPILE=arm-none-eabi- at91sam9g20ek_nandflash_config $ make ARCH=arm CROSS_COMPILE=arm-none-eabi- $ cp u-boot.bin /opt/gesbc-9g20/u-boot-2013.04.bin
• Download and build the latest U-Boot development tree using the Code Sourcery ARM cross development tool chain.
$ cd /opt/u-boot $ git clone git://git.denx.de/u-boot.git $ cd u-boot $ make ARCH=arm CROSS_COMPILE=arm-none-eabi- distclean $ make ARCH=arm CROSS_COMPILE=arm-none-eabi- at91sam9g20ek_nandflash_config $ make ARCH=arm CROSS_COMPILE=arm-none-eabi- $ cp u-boot.bin /opt/gesbc-9g20/u-boot-2013.07-git.bin
Hi Larry Baker,
On 6/23/2013 14:34, Larry Baker wrote:
I am trying to upgrade U-Boot on a Glomation GESBC-9G20 (a derivative of the Atmel AT91SAM9G20-EK) to a version that supports UBIFS. The latest U-Boot does not work. (See also my report on the Glomation user forum, http://glomation.net/smf/index.php/topic,1389.0.html.)
I checked this post, you issue have been solved. Am I right?
Best Regards, Bo Shen
I have found why the latest U-Boot does not work on my Glomation GESBC-9G20 board. Two causes: a bad code text segment address (prevents U-Boot from executing) and bad flash partition offsets (prevents U-Boot from reading its environment variables). The latter I assume is common, as the flash partition layout can vary. The former has to do with where the primary boot loader expects to find U-Boot's entry point. The primary boot loader comes from Atmel, I believe, and I assume does not change. Yet, the 2011.06 release of U-Boot changed that address. (FYI: the two immediately preceding releases, 2010.12 and 2011.03, fail to compile with configuration errors. There were definitely changes taking place during that time with the Atmel AT91SAM U-Boot code.) That may be a bug. I don't know who the authority on that question would be. If it is decided the U-Boot code text segment address is incorrect, it wold be nice to fix that in the upcoming release. (If there is time.)
Larry Baker US Geological Survey 650-329-5608 baker@usgs.gov
On Jun 24, 2013, at 12:29 AM, Bo Shen wrote:
Hi Larry Baker,
On 6/23/2013 14:34, Larry Baker wrote:
I am trying to upgrade U-Boot on a Glomation GESBC-9G20 (a derivative of the Atmel AT91SAM9G20-EK) to a version that supports UBIFS. The latest U-Boot does not work. (See also my report on the Glomation user forum, http://glomation.net/smf/index.php/topic,1389.0.html.)
I checked this post, you issue have been solved. Am I right?
Best Regards, Bo Shen
Hi Larry Baker,
On 6/24/2013 16:02, Larry Baker wrote:
I have found why the latest U-Boot does not work on my Glomation GESBC-9G20 board. Two causes: a bad code text segment address (prevents U-Boot from executing) and bad flash partition offsets (prevents U-Boot from reading its environment variables). The latter I assume is common, as the flash partition layout can vary. The former has to do with where the primary boot loader expects to find U-Boot's entry point. The primary boot loader comes from Atmel, I believe, and I assume does not change. Yet, the 2011.06 release of U-Boot changed that address. (FYI: the two immediately preceding releases, 2010.12 and 2011.03, fail to compile with configuration errors. There were definitely changes taking place during that time with the Atmel AT91SAM U-Boot code.) That may be a bug. I don't know who the authority on that question would be. If it is decided the U-Boot code text segment address is incorrect, it wold be nice to fix that in the upcoming release. (If there is time
.)
For the text base, why we use 0x21f00000 instead of 0x23f00000 is that, the memory only 64MiB on at91sam9g20ek board, if use 0x23f00000 as the text base, there is only 1MiB reserved for u-boot use. So, we move down to let more space for u-boot.
For the NAND partition, as to the u-boot grow bigger and bigger, so we reserve more space for it.
BTW, when you upgrade the u-boot, please also upgrade the bootstrap. we always keep the update bootstrap work with mainline u-boot properly.
Best Regards, Bo Shen
On 06/24/2013 10:22 AM, Bo Shen wrote:
Hi Larry Baker,
On 6/24/2013 16:02, Larry Baker wrote:
I have found why the latest U-Boot does not work on my Glomation GESBC-9G20 board. Two causes: a bad code text segment address (prevents U-Boot from executing) and bad flash partition offsets (prevents U-Boot from reading its environment variables). The latter I assume is common, as the flash partition layout can vary. The former has to do with where the primary boot loader expects to find U-Boot's entry point. The primary boot loader comes from Atmel, I believe, and I assume does not change. Yet, the 2011.06 release of U-Boot changed that address. (FYI: the two immediately preceding releases, 2010.12 and 2011.03, fail to compile with configuration errors. There were definitely changes taking place during that time with the Atmel AT91SAM U-Boot code.) That may be a bug. I don't know who the authority on that question would be. If it is decided the U-Boot code text segment address is incorrect, it wold be nice to fix that in the upcoming release. (If there is time
.)
For the text base, why we use 0x21f00000 instead of 0x23f00000 is that, the memory only 64MiB on at91sam9g20ek board, if use 0x23f00000 as the text base, there is only 1MiB reserved for u-boot use. So, we move down to let more space for u-boot.
For the NAND partition, as to the u-boot grow bigger and bigger, so we reserve more space for it.
BTW, when you upgrade the u-boot, please also upgrade the bootstrap. we always keep the update bootstrap work with mainline u-boot properly.
... we really should force SPL for at91
Bo and Andreas,
Thank you all for your guidance. I had no idea the primary bootstrap might also have to be upgraded.
Andreas had a concern about the partition size for U-Boot. The latest releases are near the limit for the current flash partition layout. However, I believe there is 128 Kb available for U-Boot to expand -- the env partitions would have to slide up. But, the primary boot loader has to know that as well. Is there a way to know the U-Boot partition size the at91loader expects? I don't know the version Glomation ships. The U-Boot they ship is a patched 1.3.4-exp5 -- I assume one of the first, if not the first, to support AT91 SAM SoCs. They are both pretty old, I think.
I've been working on this project at night and weekends because I don't have the time (and it is not my boss's priority) during the day. I really want to get a UBIFS root file system on this board. But, I haven't figured out how to do that yet, nor have I found a rootfs small enough to fit yet. Then, there are the actual apps I want to run (real-time earthquake data acquisition). Too much (interesting and challenging) work!
Thank you,
Larry Baker US Geological Survey 650-329-5608 baker@usgs.gov
On Jun 24, 2013, at 1:22 AM, Bo Shen wrote:
Hi Larry Baker,
On 6/24/2013 16:02, Larry Baker wrote:
I have found why the latest U-Boot does not work on my Glomation GESBC-9G20 board. Two causes: a bad code text segment address (prevents U-Boot from executing) and bad flash partition offsets (prevents U-Boot from reading its environment variables). The latter I assume is common, as the flash partition layout can vary. The former has to do with where the primary boot loader expects to find U-Boot's entry point. The primary boot loader comes from Atmel, I believe, and I assume does not change. Yet, the 2011.06 release of U-Boot changed that address. (FYI: the two immediately preceding releases, 2010.12 and 2011.03, fail to compile with configuration errors. There were definitely changes taking place during that time with the Atmel AT91SAM U-Boot code.) That may be a bug. I don't know who the authority on that question would be. If it is decided the U-Boot code text segment address is incorrect, it wold be nice to fix that in the upcoming release. (If there is time.)
For the text base, why we use 0x21f00000 instead of 0x23f00000 is that, the memory only 64MiB on at91sam9g20ek board, if use 0x23f00000 as the text base, there is only 1MiB reserved for u-boot use. So, we move down to let more space for u-boot.
For the NAND partition, as to the u-boot grow bigger and bigger, so we reserve more space for it.
BTW, when you upgrade the u-boot, please also upgrade the bootstrap. we always keep the update bootstrap work with mainline u-boot properly.
Best Regards, Bo Shen
Hi Larry Baker, Please stop top posting.
On 6/24/2013 16:45, Larry Baker wrote:
Is there a way to know the U-Boot partition size the at91loader expects?
Till now, there is no such function. However, if you use new bootstrap, it will show useful information as following:
---8>--- AT91Bootstrap 3.5.3 (Thu Apr 25 10:08:24 CST 2013)
NAND: ONFI not supported NAND: Manufacturer ID: 0xec Chip ID: 0xda NAND: Disable On-Die ECC NAND: Press the recovery button (BP4) to recovery NAND: Using Software ECC NAND: Image: Copy 0x80000 bytes from 0x40000 to 0x21f00000 NAND: Done to load image ---<8---
I really want to get a UBIFS root file system on this board. But, I haven't figured out how to do that yet, nor have I found a rootfs small enough to fit yet.
For UBI file system support 1. if you want to mount, read or something else with u-boot, please reference to <include/configs/at91sam9x5ek.h>. Some quote information ---8>--- #define CONFIG_MTD_DEVICE #define CONFIG_CMD_MTDPARTS #define CONFIG_MTD_PARTITIONS #define CONFIG_RBTREE #define CONFIG_LZO #define CONFIG_CMD_UBI #define CONFIG_CMD_UBIFS
#define CONFIG_SYS_MALLOC_LEN (4 * 1024 * 1024) // for mount ubifs ---<8---
2. if you just want use ubifs as rootfs. just one thing for u-boot, it is bootcmd, please also reference <include/configs/at91sam9x5ek.h>.
Best Regards, Bo Shen
Hi Larry,
On 06/24/2013 10:45 AM, Larry Baker wrote:
Bo and Andreas,
Thank you all for your guidance. I had no idea the primary bootstrap might also have to be upgraded.
Andreas had a concern about the partition size for U-Boot. The latest releases are near the limit for the current flash partition layout. However, I believe there is 128 Kb available for U-Boot to expand -- the env partitions would have to slide up. But, the primary boot loader has to know that as well. Is there a way to know the U-Boot partition size the at91loader expects?
that doesn't count here. The proloader just need to know about the start address and size in NAND to load into SDRAM. These three parameters (NAND offset address, size of payload and 'JUMP_ADDRESS') are configurable in at91bootstrap (or whichever preloader is used). If the glomation board is really a stripped down clone of at91sam9g20ek it should work out with the current version of at91bootstarp [1]. If you have the glomation binary of at91bootstarp you could try to flash a newer, self-built version with SAM-BA. I don't think you can destruct the hardware by that newer at91bootstarp ... but don't beat me if it does, please ask glomation before.
To address the NAND partition sizes concerns ... Have you (or your boss) ever heard about the technique behind NAND? You need to know that every NAND can have a bunch of defective blocks when shipped. What will you do if just one bad block is placed in the section reserved for u-boot? Therefore we decided to add some spare space to all the RAW NAND storage partitions (bootstrap loader, u-boot, env1, env2, dtb, kernel). Ok, bootstrap isn't that hard cause most NAND manufacturers guarantee that the first block is good for less than 1000 erasures, but the other partitions count. We had several NAND devices with bad blocks when shipped, mostly they where placed somewhere in the big block for rootfs, but some had bad blocks in kernel or u-boot.
Hopefully your outdated bootstrap and u-boot has bad block management to detect this at least.
I don't know the version Glomation ships. The U-Boot they ship is a patched 1.3.4-exp5 -- I assume one of the first, if not the first, to support AT91 SAM SoCs. They are both pretty old, I think.
I've been working on this project at night and weekends because I don't have the time (and it is not my boss's priority) during the day.
Well, you should really spend some time on the low level part. We build medical devices with u-boot, linux, a.s.o. and need to ensure that these parts work well (FDA and other regulatory domains require this ...). It costs some time and money but one could manage to reduce such risks. If you know what could happen you will enforce to spend some time on that parts too.
I really want to get a UBIFS root file system on this board. But, I haven't figured out how to do that yet, nor have I found a rootfs small enough to fit yet. Then, there are the actual apps I want to run (real-time earthquake data acquisition).
Well, so your product will mostly write data. I really recommend to use UBIFS on NAND for that use-case! If boottime doesn't count I recommend to also place the kernel into the rootfs which would be ubifs then. Also u-boot environment could be placed into ubi since some time (I saw patches, dunno if they are integrated for this release).
Off Topic: How big is your rootfs? We build our current product with around 50MiB rootfs (full blown glibc, Qt, about 20 languages, a lot of other resources like pictures and sounds).
Too much (interesting and challenging) work!
... as always ;)
Best regards,
Andreas Bießmann
On 24 Jun 2013, at 1:22 AM, Bo Shen wrote:
Hi Larry Baker,
On 6/24/2013 16:02, Larry Baker wrote:
I have found why the latest U-Boot does not work on my Glomation GESBC-9G20 board. Two causes: a bad code text segment address (prevents U-Boot from executing) and bad flash partition offsets (prevents U-Boot from reading its environment variables). The latter I assume is common, as the flash partition layout can vary. The former has to do with where the primary boot loader expects to find U-Boot's entry point. The primary boot loader comes from Atmel, I believe, and I assume does not change. Yet, the 2011.06 release of U-Boot changed that address. (FYI: the two immediately preceding releases, 2010.12 and 2011.03, fail to compile with configuration errors. There were definitely changes taking place during that time with the Atmel AT91SAM U-Boot code.) That may be a bug. I don't know who the authority on that question would be. If it is decided the U-Boot code text segment address is incorrect, it wold be nice to fix that in the upcoming release. (If there is time.)
For the text base, why we use 0x21f00000 instead of 0x23f00000 is that, the memory only 64MiB on at91sam9g20ek board, if use 0x23f00000 as the text base, there is only 1MiB reserved for u-boot use. So, we move down to let more space for u-boot.
For the NAND partition, as to the u-boot grow bigger and bigger, so we reserve more space for it.
BTW, when you upgrade the u-boot, please also upgrade the bootstrap. we always keep the update bootstrap work with mainline u-boot properly.
Will AT91loader be updated when U-Boot 2013.07 is released? If not, I will put the current AT91loader on my board with U-Boot 2013.04 now.
Best Regards, Bo Shen
Thank you,
Larry Baker US Geological Survey 650-329-5608 baker@usgs.gov
Hi Larry Baker,
On 06/26/2013 02:02 AM, Larry Baker wrote:
On 24 Jun 2013, at 1:22 AM, Bo Shen wrote:
Hi Larry Baker,
On 6/24/2013 16:02, Larry Baker wrote:
I have found why the latest U-Boot does not work on my Glomation GESBC-9G20 board. Two causes: a bad code text segment address (prevents U-Boot from executing) and bad flash partition offsets (prevents U-Boot from reading its environment variables). The latter I assume is common, as the flash partition layout can vary. The former has to do with where the primary boot loader expects to find U-Boot's entry point. The primary boot loader comes from Atmel, I believe, and I assume does not change. Yet, the 2011.06 release of U-Boot changed that address. (FYI: the two immediately preceding releases, 2010.12 and 2011.03, fail to compile with configuration errors. There were definitely changes taking place during that time with the Atmel AT91SAM U-Boot code.) That may be a bug. I don't know who the authority on that question would be. If it is decided the U-Boot code text segment address is incorrect, it wold be nice to fix that in the upcoming release. (If there is time.)
For the text base, why we use 0x21f00000 instead of 0x23f00000 is that, the memory only 64MiB on at91sam9g20ek board, if use 0x23f00000 as the text base, there is only 1MiB reserved for u-boot use. So, we move down to let more space for u-boot.
For the NAND partition, as to the u-boot grow bigger and bigger, so we reserve more space for it.
BTW, when you upgrade the u-boot, please also upgrade the bootstrap. we always keep the update bootstrap work with mainline u-boot properly.
Will AT91loader be updated when U-Boot 2013.07 is released? If not, I will put the current AT91loader on my board with U-Boot 2013.04 now.
As Andreas described in previous e-mail, you can find the newest bootstrap at [1].
[1] https://github.com/linux4sam/at91bootstrap
Best Regards, Bo Shen
On Jun 25, 2013, at 6:08 PM, Bo Shen wrote:
Hi Larry Baker,
On 06/26/2013 02:02 AM, Larry Baker wrote:
On 24 Jun 2013, at 1:22 AM, Bo Shen wrote:
Hi Larry Baker,
On 6/24/2013 16:02, Larry Baker wrote:
I have found why the latest U-Boot does not work on my Glomation GESBC-9G20 board. Two causes: a bad code text segment address (prevents U-Boot from executing) and bad flash partition offsets (prevents U-Boot from reading its environment variables). The latter I assume is common, as the flash partition layout can vary. The former has to do with where the primary boot loader expects to find U-Boot's entry point. The primary boot loader comes from Atmel, I believe, and I assume does not change. Yet, the 2011.06 release of U-Boot changed that address. (FYI: the two immediately preceding releases, 2010.12 and 2011.03, fail to compile with configuration errors. There were definitely changes taking place during that time with the Atmel AT91SAM U-Boot code.) That may be a bug. I don't know who the authority on that question would be. If it is decided the U-Boot code text segment address is incorrect, it wold be nice to fix that in the upcoming release. (If there is time.)
For the text base, why we use 0x21f00000 instead of 0x23f00000 is that, the memory only 64MiB on at91sam9g20ek board, if use 0x23f00000 as the text base, there is only 1MiB reserved for u-boot use. So, we move down to let more space for u-boot.
For the NAND partition, as to the u-boot grow bigger and bigger, so we reserve more space for it.
BTW, when you upgrade the u-boot, please also upgrade the bootstrap. we always keep the update bootstrap work with mainline u-boot properly.
Will AT91loader be updated when U-Boot 2013.07 is released? If not, I will put the current AT91loader on my board with U-Boot 2013.04 now.
As Andreas described in previous e-mail, you can find the newest bootstrap at [1].
Yes, thank you. But, my question is, will AT91loader be updated when U-Boot 2013.07 is released? If yes, I will wait. If no, I will use what you is available now. You have said that one should update the loader when U-Boot is updated. This is what I wish to do.
[1] https://github.com/linux4sam/at91bootstrap
Best Regards, Bo Shen
Thank you,
Larry Baker US Geological Survey 650-329-5608 baker@usgs.gov
Hi Larry,
On 26.06.13 03:55, Larry Baker wrote:
On Jun 25, 2013, at 6:08 PM, Bo Shen wrote:
Hi Larry Baker,
On 06/26/2013 02:02 AM, Larry Baker wrote:
On 24 Jun 2013, at 1:22 AM, Bo Shen wrote:
Hi Larry Baker,
On 6/24/2013 16:02, Larry Baker wrote:
<snip>
BTW, when you upgrade the u-boot, please also upgrade the bootstrap. we always keep the update bootstrap work with mainline u-boot properly.
Will AT91loader be updated when U-Boot 2013.07 is released? If not, I will put the current AT91loader on my board with U-Boot 2013.04 now.
As Andreas described in previous e-mail, you can find the newest bootstrap at [1].
Yes, thank you. But, my question is, will AT91loader be updated when U-Boot 2013.07 is released? If yes, I will wait. If no, I will use what you is available now. You have said that one should update the loader when U-Boot is updated. This is what I wish to do.
there is no release schedule aligned to the u-boot release schedule. If some change in u-boot requires changes in at91loader or vice versa the changes on the other side will be made. The current at91loader release (3.5.4 I think) has the required JUMP_ADDRESS change to run current u-boot (2013.04 and the upcoming one).
Best regards
Andreas Bießmann
Hi Bo,
On 06/24/2013 09:29 AM, Bo Shen wrote:
Hi Larry Baker,
On 6/23/2013 14:34, Larry Baker wrote:
I am trying to upgrade U-Boot on a Glomation GESBC-9G20 (a derivative of the Atmel AT91SAM9G20-EK) to a version that supports UBIFS. The latest U-Boot does not work. (See also my report on the Glomation user forum, http://glomation.net/smf/index.php/topic,1389.0.html.)
I checked this post, you issue have been solved. Am I right?
Yea, seems so. I'm a bit unhappy about the solution (change 0x21f00000 to 0x23f00000 for link address) but I already explained that to Larry off-list. Maybe he decides to switch to a newer at91bootstrap also which would solve this too.
Best regards
Andreas Bießmann
participants (3)
-
Andreas Bießmann -
Bo Shen -
Larry Baker