2010-09-21 17:30, Grant Edwards skrev:> On 2010-09-20, Ulf Samuelsson<nospam.ulf@atmel.com> wrote: >> 2010-09-20 20:10, Grant Edwards skrev: > >>> While the ROM bootloader supports the 25xx series "dataflash" parts we >>> got sold, there is no support in the AT91 bootstrap, U-Boot, or Linux >>> -- at least not that I could ever find. I asked about it on the AT91 >>> forum a few months back and got the usual response (IOW, none at all). >> >> It is hidden in a disused lavatory in the cellar marked: >> "Beware of the Leopard". > > Ah! I just listened to Stephen Fry's auidiobook of THHGTTG last > weekend while driving home from Chicago. > > >> There are three different AT91bootstraps around. >> >> 1) The obvious AT91bootstrap you can download from www.atmel.com > > That's the one I looked at. > >> 2) My derivative of AT91bootstrap which adds Kconfig etc. and is used >> by open source projects like Buildroot and OpenEmbedded. > > Though am using buildroot for my rootfs, I found it more convenient to > build other things (kernel, bootstrap, U-Boot) separately, so I never > really looked into that one. > >> 3) There is normally an AT91bootstrap in the "Softpack's". This is >> different from (1) and (2). It supports the 25xx series SPI flash >> but relies on libraries not normally available in arm-linux >> compilers so you may have to compile it using arm-newlib, IAR or >> Keil. > > That's interesting. I'll keep that in mind. >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.>>>> Reason is the SAM-BA S/W which only knows how to erase the complete >>>> NAND flash. >>> >>> Oh, I fixed that ages ago. >>> >>> I added a few lines of code to the nand-flash, data-flash, and >>> serial-flash applets so that they can all erase a region of flash. >> >> Nice, how about sharing! > > Sure. The changes to the applets can certainly be shared. I'll have > to check with management regarding my sam-ba client replacement. I > just double-checked, and the erase-region command has been added to > the nandflash and dataflash applets, but it never got added to the > serialflash (AT25xx) applet. > >>>> If you plan to program the NAND flash using another method, then of >>>> course, use the NAND flash for everything except bootstrap. >>> >>> We'll initially use "SAM-BA" replacement program to program >>> prototypes. Then for production, the plan is to have the distributor >>> ship them with U-Boot preprogrammed so that we can use the TFTP >>> server in U-Boot to do the rest. >> >> Or, if you have an SD-Connector, you can boot from an SD-Card/ >> external SPI flash which programs the internal flash. > > That's also an option, but since we'll have to connect an Ethernet > cable anyway as part of the normal production test process, we want to > use Ethernet as the programming interface as well. >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
Amtel SAM9 "boot from NAND" is a myth?
Started by ●September 15, 2010
Reply by ●September 23, 20102010-09-23
Reply by ●September 23, 20102010-09-23
On 2010-09-23, Ulf Samuelsson <nospam.ulf@atmel.com> wrote:> 2010-09-21 17:30, Grant Edwards skrev:>>>> Then for production, the plan is to have the distributor ship them >>>> with U-Boot preprogrammed so that we can use the TFTP server in >>>> U-Boot to do the rest. >>> >>> Or, if you have an SD-Connector, you can boot from an SD-Card/ >>> external SPI flash which programs the internal flash. >> >> That's also an option, but since we'll have to connect an Ethernet >> cable anyway as part of the normal production test process, we want >> to use Ethernet as the programming interface as well. > > You can't use Ethernet, until you have programmed the board the first > time. There is no Ethernet support in the BootROM.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.> It will be much easier to insert an SD-Card & reset the board.Not really. Even if our product had an externally accessible SD-Card socket, it's simpler to use Ethernet for everything.> 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.Our products almost never have access to the Internet. -- Grant Edwards grant.b.edwards Yow! PIZZA!! at gmail.com
Reply by ●September 23, 20102010-09-23
2010-09-23 16:25, Grant Edwards skrev:> On 2010-09-23, Ulf Samuelsson<nospam.ulf@atmel.com> wrote: >> 2010-09-21 17:30, Grant Edwards skrev: > >>>>> Then for production, the plan is to have the distributor ship them >>>>> with U-Boot preprogrammed so that we can use the TFTP server in >>>>> U-Boot to do the rest. >>>> >>>> Or, if you have an SD-Connector, you can boot from an SD-Card/ >>>> external SPI flash which programs the internal flash. >>> >>> That's also an option, but since we'll have to connect an Ethernet >>> cable anyway as part of the normal production test process, we want >>> to use Ethernet as the programming interface as well. >> >> You can't use Ethernet, until you have programmed the board the first >> time. There is no Ethernet support in the BootROM. > > 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. >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.>> It will be much easier to insert an SD-Card& reset the board. > > Not really. Even if our product had an externally accessible SD-Card > socket, it's simpler to use Ethernet for everything.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 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. > > Our products almost never have access to the Internet. >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 by ●September 23, 20102010-09-23
On 2010-09-23, Ulf Samuelsson <nospam.ulf@atmel.com> wrote:> 2010-09-23 16:25, Grant Edwards skrev: >> On 2010-09-23, Ulf Samuelsson<nospam.ulf@atmel.com> wrote: >>> 2010-09-21 17:30, Grant Edwards skrev: >> >>>>>> Then for production, the plan is to have the distributor ship them >>>>>> with U-Boot preprogrammed so that we can use the TFTP server in >>>>>> U-Boot to do the rest. >>>>> >>>>> Or, if you have an SD-Connector, you can boot from an SD-Card/ >>>>> external SPI flash which programs the internal flash. >>>> >>>> That's also an option, but since we'll have to connect an Ethernet >>>> cable anyway as part of the normal production test process, we want >>>> to use Ethernet as the programming interface as well. >>> >>> You can't use Ethernet, until you have programmed the board the first >>> time. There is no Ethernet support in the BootROM. >> >> 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. > > U-Boot needs to be setup to connect to a host, but maybe DHCP can > resolve that.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.> One issue with this method is if your image is large than the onboard > SDRAM/DDR-II.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.> It is more difficult to download and program a partial file.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
