[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