[U-Boot] Help with Glomation GESBC-9G20

[U-Boot] Help with Glomation GESBC-9G20

[Larry Baker]

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 at 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

[U-Boot] Help with Glomation GESBC-9G20

[Bo Shen]

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

[U-Boot] Help with Glomation GESBC-9G20

[Larry Baker]

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 at 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

[U-Boot] Help with Glomation GESBC-9G20

[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

[U-Boot] Help with Glomation GESBC-9G20

[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

[U-Boot] Help with Glomation GESBC-9G20

[Andreas Bießmann]

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

[U-Boot] Help with Glomation GESBC-9G20

[Larry Baker]

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 at 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
> 

[U-Boot] Help with Glomation GESBC-9G20

[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

[U-Boot] Help with Glomation GESBC-9G20

[Andreas Bießmann]

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

[1] https://github.com/linux4sam/at91bootstrap

[U-Boot] Help with Glomation GESBC-9G20

[Larry Baker]

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 at usgs.gov

[U-Boot] Help with Glomation GESBC-9G20

[Bo Shen]

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

[U-Boot] Help with Glomation GESBC-9G20

[Larry Baker]

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 at usgs.gov

[U-Boot] Help with Glomation GESBC-9G20

[Andreas Bießmann]

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

>> [1] https://github.com/linux4sam/at91bootstrap