1. Home
  2. Embedded Programming
  3. Amtel SAM9 "boot from NAND" is a myth?
  4. Page 4

Amtel SAM9 "boot from NAND" is a myth?

There is a new bootstrap in the works which will merge everything. The business unit like my idea of using Kconfig, so I think they used my version as the base, and they have extended it with all the new features that Atmel wants supported like SPI flash and SD-Card boot.

You can't use Ethernet, until you have programmed the board the first time. There is no Ethernet support in the BootROM.

It will be much easier to insert an SD-Card & reset the board. The code loaded from the SD-Card can be used to download stuff over ethernet.

You can put images on a webserver that can be downloaded to an SD-Card by end customers.

--
Best Regards
Ulf Samuelsson
These are my own personal opinions, which may (or may not)
be shared by my employer Atmel Nordic AB
Reply to
Ulf Samuelsson
Loading thread data ...

Right. As I said, we will have the NAND flash distributor pre-program the parts with the bootstrap and U-Boot. It allows our production procedure to do everything via Ethernet.

Not really. Even if our product had an externally accessible SD-Card socket, it's simpler to use Ethernet for everything.

Our products almost never have access to the Internet.

--
Grant Edwards               grant.b.edwards        Yow! PIZZA!!
                                  at               
                              gmail.com
Reply to
Grant Edwards

U-Boot needs to be setup to connect to a host, but maybe DHCP can resolve that.

One issue with this method is if your image is large than the onboard SDRAM/DDR-II.

It is more difficult to download and program a partial file. Probably you have to split the file into several files in the host, This may be problematic with advanced file systems like JFFS2.

The SD-Card approach allows you to program large amounts of flash. You have the same problem with limited RAM space, but you can at least run an application which reads the SD-Card and writes to the flash.

If you don't have an SD-Card socket, then that is a problem of course.

Some people use the primary SPI boot option for an ISP connection to external H/W, and the secondary SPI boot option is used for onboard dataflash.

The intention was that you can publish a support pack on internet. A customer then manually downloads the support pack files and stores them on an SD-Card. By inserting the SD-Card into the system it is upgraded. Depending on Bootorder, you may have to kill the erase the first sector of any flash containing a bootable image.

--
Best Regards
Ulf Samuelsson
These are my own personal opinions, which may (or may not)
be shared by my employer Atmel Nordic AB
Reply to
Ulf Samuelsson

As you imply a TFTP _client_ in U-Boot is less than optimal for this usage.

My U-Boot has a TFTP server. U-Boot doesn't have to be configured to connect to anything. It just has to be configured to listen for TFTP commands for a second or two before it attempts to boot a Linux image. I usually also configure it to listen indefinitely for TFTP commands in the case where the Linux image is missing or corrupt.

Despite Hr. Denx's strenuous assertions that a TFTP server is useless and wrong and unwanted in U-Boot, I find it to be very useful indeed.

The TFTP server doesn't write the image to RAM. It writes it to flash (if that's what it's been told to do by the TFTP client).

Of course the received data has to be buffered in at least write-page-sized chunks, but that's usually 4K or less for all the NAND flashes I've seen.

I actually found it more convenient to buffer erase-block-size chunks (128KB in my case), but that's still no problem on most ARM9 platforms running U-Boot.

Indded it would be. That's why I don't. :)

--
Grant Edwards               grant.b.edwards        Yow! Hello, GORRY-O!!
                                  at               I'm a GENIUS from HARVARD!!
                              gmail.com
Reply to
Grant Edwards

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.