* [U-Boot] Help with Glomation GESBC-9G20
2013-06-24 8:22 ` Bo Shen
@ 2013-06-24 8:29 ` Andreas Bießmann
2013-06-24 8:45 ` Larry Baker
2013-06-25 18:02 ` Larry Baker
2 siblings, 0 replies; 13+ messages in thread
From: Andreas Bießmann @ 2013-06-24 8:29 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* [U-Boot] Help with Glomation GESBC-9G20
2013-06-24 8:22 ` Bo Shen
2013-06-24 8:29 ` Andreas Bießmann
@ 2013-06-24 8:45 ` Larry Baker
2013-06-24 9:20 ` Bo Shen
2013-06-24 9:23 ` Andreas Bießmann
2013-06-25 18:02 ` Larry Baker
2 siblings, 2 replies; 13+ messages in thread
From: Larry Baker @ 2013-06-24 8:45 UTC (permalink / raw)
To: u-boot
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
>
^ permalink raw reply [flat|nested] 13+ messages in thread
* [U-Boot] Help with Glomation GESBC-9G20
2013-06-24 8:45 ` Larry Baker
@ 2013-06-24 9:20 ` Bo Shen
2013-06-24 9:23 ` Andreas Bießmann
1 sibling, 0 replies; 13+ messages in thread
From: Bo Shen @ 2013-06-24 9:20 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* [U-Boot] Help with Glomation GESBC-9G20
2013-06-24 8:45 ` Larry Baker
2013-06-24 9:20 ` Bo Shen
@ 2013-06-24 9:23 ` Andreas Bießmann
1 sibling, 0 replies; 13+ messages in thread
From: Andreas Bießmann @ 2013-06-24 9:23 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* [U-Boot] Help with Glomation GESBC-9G20
2013-06-24 8:22 ` Bo Shen
2013-06-24 8:29 ` Andreas Bießmann
2013-06-24 8:45 ` Larry Baker
@ 2013-06-25 18:02 ` Larry Baker
2013-06-26 1:08 ` Bo Shen
2 siblings, 1 reply; 13+ messages in thread
From: Larry Baker @ 2013-06-25 18:02 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* [U-Boot] Help with Glomation GESBC-9G20
2013-06-25 18:02 ` Larry Baker
@ 2013-06-26 1:08 ` Bo Shen
2013-06-26 1:55 ` Larry Baker
0 siblings, 1 reply; 13+ messages in thread
From: Bo Shen @ 2013-06-26 1:08 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* [U-Boot] Help with Glomation GESBC-9G20
2013-06-26 1:08 ` Bo Shen
@ 2013-06-26 1:55 ` Larry Baker
2013-06-26 6:35 ` Andreas Bießmann
0 siblings, 1 reply; 13+ messages in thread
From: Larry Baker @ 2013-06-26 1:55 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* [U-Boot] Help with Glomation GESBC-9G20
2013-06-26 1:55 ` Larry Baker
@ 2013-06-26 6:35 ` Andreas Bießmann
0 siblings, 0 replies; 13+ messages in thread
From: Andreas Bießmann @ 2013-06-26 6:35 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 13+ messages in thread