[U-Boot] Is somebody workin on getting the AT91SAM9G45EKES working on the latest build?
I need the AT91SAM9G45 port - if I need to bring it up to date to keep it among the living I will volunteer, but if one of the usual AT91 maintainers is already working on it I suspect they can do it more easily than I. I can start work on the 9G45 update in early July if necessary. Thanks, Bill Landolina Technology Atlanta Corporation 500 Sugar Mill Road - Suite 202A Atlanta, Georgia 30350 (404) 303-0446 (Voice) (678) 596-3625 (Cell) w...@techatl.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Is somebody workin on getting the AT91SAM9G45EKES working on the latest build?
> Bill, > > On 06/30/2011 02:10 PM, William C. Landolina wrote: > > Alex - If there is anything I can do to help please let me know. I've been > roughly patching the various builds for a while and really would like to see > this get back in the mainline. > > I will send my patch set in a few moments; just a few more things and it > should be a good start. I have a few questions... > > 1 What boot strapper are you using? The default at91bootstrapper that you > can download from the linux4sam web site? I start with Atmel's vanilla first stage boot from NAND. I have a much hacked SDCard boot that works as well and that is where I want to head. My target systems do not have NAND or Dataflash. (I can put NAND on my boards for development but I do not want to ship with NAND.) > 2 Are you booting from NAND? I currently boot from NAND - the features I want to get from the current version is booting from, and environment on, SDCard. I hacked that into the December release but it was a hack - the environment was at fixed sector offsets on the SDCard which required building the partition table by hand. Long term I want to get the environment in a file on the SDCard. > 3 How far have you gotten with your patching? Does everything work? For > me, I > have all of my hardware up and running (including the second bank of RAM > which seemed like it was not supported before). I hacked the December release to work, but I know I did some things in the wrong places and in a style that is not Wolfgang-compatible. I stopped working on improving the December release because it was clear that a lot of good things were happening to the MMC framework and the underlying AT91 framework was in flux so it seemed like a good idea to wait until that stabilized before I revisit putting a modern U-Boot on my boards "the right way". I only have one bank of RAM on my custom target so I didn't test the second bank. On my targets the other EBI interface runs a bunch of slow peripherals. > 4 I presume your booting into Linux after U-Boot? Yes, I'm booting Linux 2.6.30 or so. > Best regards, > Alex > > -- > Alex Waterman > Computer Engineer > Phone: 215-896-4920 > Email: awater...@dawning.com Enjoy, Bill. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Is somebody workin on getting the AT91SAM9G45EKES working on the latest build?
> Bill, > > On 06/30/2011 04:54 PM, William C. Landolina wrote: > > I start with Atmel's vanilla first stage boot from NAND. I have a > > much hacked SDCard boot that works as well and that is where I want to > > head. My target systems do not have NAND or Dataflash. (I can put > > NAND on my boards for development but I do not want to ship with > > NAND.) > I see. I have not tried any of the MMC u-boot stuff for my board (a > sam9m10g45ek). > > > I hacked the December release to work, but I know I did some things in the > wrong places and in a style that is not Wolfgang-compatible. I stopped > working on improving the December release because it was clear that a lot of > good things were happening to the MMC framework and the underlying > AT91 framework was in flux so it seemed like a good idea to wait until that > stabilized before I revisit putting a modern U-Boot on my boards "the right > way". > Ahh, Wolfgang compatible :). I still haven't really figured out exactly what > is > actually correct with the AT91 framework code yet. I just started playing with > this a few weeks ago. There was a patch a little which back which was the > reference implementation for the AT91 framework, but I could not find it > when I searched my mail box. > > > I only have one bank of RAM on my custom target so I didn't test the > second bank. On my targets the other EBI interface runs a bunch of slow > peripherals. > Ah, so dual RAM is no matter for you. > > Which config header are you using? Naturally, I am using the sam9m10g45ek > header, but since you have a slightly different board, which doesn't appear > to have a header, how did you proceed? I start with the 9G45EKES headers and throw things out. My board is an EKES minus a lot of things - It is just a 9G45 with single bank RAM, SDCard and serial ports. No display, dataflash, codec, or NAND. I have USB ports on the board but don't need or want it in U-Boot. I do have some interesting peripherals hanging off the second EBI but they don't come into play at U-Boot time. Using a stock EKES U-Boot on my board will work - nothing bad happens on my board if U-Boot turns on the display controller for example. I do have an official Atmel AT91SAM9G45-EKES for testing as well. [And 9260 and 9G20 versions in the closet as well]. When testing U-Boot I get the Atmel board working then I start whittling down the configuration to fit my board. > Best regards, > Alex Thanks, Bill. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] RTC value corruption on QIL-A9G20 startup
> -Original Message- > From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On > Behalf Of Albin Tonnerre > Sent: Tuesday, August 25, 2009 12:49 PM > To: u-boot@lists.denx.de > Subject: Re: [U-Boot] RTC value corruption on QIL-A9G20 startup > > On Tue, Aug 25, 2009 at 08:51:56AM -0400, Stephen Caudle wrote : > > Hello Eric, > > > > On Tue, Aug 25, 2009 at 5:38 AM, Eric BĂ©nard wrote: > > > isn't the RTC connected to the SPI chip select that the internal > > > firmware toggle on boot to probe for a SPI Flash ? > > > > That is certainly possible. This problem went away for me when I > > > upgraded to the "next" branch. Could the SPI dataflash code have been > > removed between > > v2009.06 and "next"? I'll look into this some more. Thanks for the hint! > > Using the "next" branch doesn't help here. Anyway, the code Eric is referring > to is the firmware code the CPU > executes from its internal ROM very early > in the boot process, so you likely won't find anything remotely related to > > this in U-Boot. > > Regards, > -- > Albin Tonnerre, Free Electrons > Kernel, drivers and embedded Linux development, consulting, training and > support. > http://free-electrons.com Has there been any resolution on this? From what I can see (with scope and logic analyzer) the RTC seems to be corrupted by the DataFlash boot code built into the chip. [The Calao board doesn't have the DataFlash memory and used the chip select for its RTC instead...] Has anyone found a smoking gun inside U-Boot or will we have to wait for Calao to make boards with the RTC on a different chip select? Thanks, Bill Landolina Technology Atlanta Corporation 500 Sugar Mill Road, Suite 202A Atlanta, GA 30350 (404) 303-0446 (Voice) (404) 303-0448 (FAX) (678) 596-3625 (Cell) w...@techatl.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Loading u-boot from SD/MMC (was Re: [PATCH v3] AT91: MCI: add SD/MMC driver using mmc framework)
Running U-Boot from the SDCard on an Atmel 9G20 is certainly doable. I have recently booted U-Boot and Linux from an SDCard on an Atmel AT91SAM9G45-EKES with no other non-volatile memories and the process is the same with some minor limitations. The process I used: 1. SAM Boot loader loads "boot.bin" from the first FAT partition 2. Boot.bin loads U-Boot from "uboot.bin" into high DRAM 3. Boot.bin loads a uImage file lower into DRAM 4. Boot.bin jumps into U-Boot 4. U-Boot's boot command boots the image my boot.bin leaves lying around in DRAM. I started with Atmel's SDCard bootstrap example and modified it to load both U-Boot and a Linux image into RAM then jump to U-Boot. The U-Boot and the Linux uImage were "stock" builds with no special features. Once the SD/MMC U-Boot patches make it into the mainline I expect to let U-Boot read the Linux image from the SDCard. The 9G20 has two limitations that I know of: 1. 9G20's boot ROM doesn't support SDHC cards (> 2GB) 2. 9G20's SRAM that boot.bin loads into is 16K which may be too tight for a full FAT handler. The 9G45 has 64K of SRAM so the boot.bin program I used has a full FAT file system handler. Start by looking at the 9G20 "AT91 Software package" at http://www.atmel.com/dyn/products/tools_card.asp?tool_id=4343 and dive into the SD/MMC examples. The SD/MMC patches for AT91 will make this a lot simpler. Enjoy, Bill. > -Original Message- > From: u-boot-boun...@lists.denx.de [mailto:u-boot- > boun...@lists.denx.de] On Behalf Of Reinhard Meyer > Sent: Tuesday, September 07, 2010 6:40 PM > To: Will Tucker; u-boot@lists.denx.de > Subject: [U-Boot] Loading u-boot from SD/MMC (was Re: [PATCH v3] AT91: > MCI: add SD/MMC driver using mmc framework) > > Dear Will Tucker, > > Hi, > > > > I'm trying to get the ATSAM9G20-EK booting from SD/MMC on MCI A, with > the Nand > and Dataflash disabled, with no luck. > > > > I have gotten the latest u-boot-atmel compiled and placed boot.bin on a > FAT 16 > formatted. When I turn power on I only get RomBoot on the debug > uart. > > > > 1) Do I need to use the latest AT91Bootstrap, I have v1.16 but do not see > any > way to enable the mci > > If I need an update where can I get the > latest version? > > > > Any help would be appreciated, > > > > Will Tucker > > > > First, please observe the following: > 1. Start a new thread for comments/questions unrelated to the existing > thread. > 2. Always post the u-boot mailing list as well. > 3. Please make your lines wrap at less than 80 characters. > > To give a brief answer to your issue: > > Please study sections 8 and 13 of the 9G20 datasheet. As a result you will see > that the ROM will try to load "boot.bin" to internal SRAM. This will limit the > image size to 16K. Apparently that cannot be u-boot itself. This 16k code > would need to initialize SDRAM and load another, larger file (e.g. u-boot.bin) > from SD/MMC into SDRAM. I don't know whether AT91Bootstrap sources > already handle such a situation. Latest Versions you will find on the Atmel > Website. > > Please note that this is not an u-boot issue. > > The patch "SD/MMC support" for u-boot enables to access SD/MMC from u- > boot ONCE it is running. > > Best Regards, > Reinhard > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] 2010.09-rc1 SD/MMC tested on Atmel AT91SAM9G45EKES - works
Reinhard - FYI, your 2010.09-rc1 SD/MMC patches work on an Atmel 9G45 evaluation kit. I customized the board and configuration files following the directions in README.atmel_mci and everything works as expected. I included the console output from a test boot below in case there is some information in the debugging messages that is of interest. Thanks, Bill Landolina. - U-Boot 2010.09-rc1 (Sep 11 2010 - 22:43:16) DRAM: 128 MiB ## Unknown FLASH on Bank 1 - Size = 0x = 0 MB Flash: 0 Bytes NAND: 256 MiB In:serial Out: serial Err: serial MMC: WCL MCI Init at91sam9m10g45_devices.c:192 mci: 0 Net: macb0 Hit any key to stop autoboot: 0 UB-X1> mmcinfo mci: setting clock 260416 Hz, block size 512 mci: setting clock 260416 Hz, block size 512 mci: setting clock 260416 Hz, block size 512 gen_atmel_mci: CMDR 1048 ( 8) ARGR 01aa (SR: 0c100025) Command Failed mci: setting clock 260416 Hz, block size 512 mci: setting clock Hz, block size 512 Device: mci Manufacturer ID: 1b OEM: 534d Name: SMI Tran Speed: 2500 Rd Block Len: 512 SD version 1.10 High Capacity: No Capacity: 1017643008 Bus Width: 4-bit UB-X1> fatls mmc 0 5805 test.c 2160828 uimage.bin 2 file(s), 0 dir(s) UB-X1> fatload mmc 0 2200 uimage.bin reading uimage.bin 2160828 bytes read UB-X1> bootm ## Booting kernel from Legacy Image at 2200 ... Image Name: Linux-2.6.30-ts-armv5l Image Type: ARM Linux Kernel Image (uncompressed) Data Size:2160764 Bytes = 2.1 MiB Load Address: 70008000 Entry Point: 70008000 Verifying Checksum ... OK Loading Kernel Image ... OK OK Starting kernel ... Uncompressing Linux. done, booting the kernel. Linux version 2.6.30-ts-armv5l (r...@localhost.localdomain) (gcc version 4.4.4 (GCC) ) #1 PREEMPT Sat Aug 28 14:24:26 EDT 2010 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] 2010.09-rc1 SD/MMC tested on Atmel AT91SAM9G45EKES - works
> Dear William C. Landolina, >> UB-X1> mmcinfo >> mci: setting clock 260416 Hz, block size 512 >> mci: setting clock 260416 Hz, block size 512 >> mci: setting clock 260416 Hz, block size 512 >> gen_atmel_mci: CMDR 1048 ( 8) ARGR 01aa (SR: 0c100025) Command Failed > Seems the card does not understand the CMD8 (Voltage supplied) Mmcinfo lists this card as conforming to the SDCard 1.10 specification, but the voltage configuration command wasn't defined until version 2.0. The SDCard I'm testing with is definitely an old generic card. The text I found describing CMD8: "After the card enters idle state with a CMD0, send a CMD8 with argument of 0x01AA and correct CRC prior to initialization process. When the CMD8 is rejected with an illigal command error (0x05), the card is SDC V1 or MMC. When the CMD8 is accepted, R7 response (R1(0x01) and trailing 32 bit data) will be returned. The lower 12 bits in the return value 0x1AA means that the card is SDC V2 and it can work at voltage range of 2.7 to 3.6 volts. If not the case, the card must be rejected. And then initiate initialization with ACMD41 with HCS (bit 30). After the initialization completed, read OCR and check CCS (bit 30) in the OCR. When it is set, subsequent data read/write operations that described below are commanded in block address insted of byte address. The block size is always fixed to 512 bytes." The web page with the CMD8 description came out of Google's cache [http://webcache.googleusercontent.com/search?q=cache:5IE3l8XsBq0J:elm-chan.org/docs/mmc/mmc_e.html+mmc+supplied+voltage&cd=1&hl=en&ct=clnk&gl=us&client=firefox-a]. There is also a document from Samsung that list CMD8 as a difference between MMC and SDCard 2.0: http://www.samsung.com/global/business/semiconductor/products/flash/downloads/applicationnote/4gb_mmc_application_note_200606.pdf > mci: setting clock 260416 Hz, block size 512 > mci: setting clock Hz, block size 512 > The function that sets clock and blocksize is repeatedly called by the common > MMC > framework, one might want to make that output debug only. Fot the time being, > however, > its good to see that the calculated clock is less than what the card can > handle. > What clocks does you system use? Xtal/PLL/PBI? The Atmel 9G45 evaluation board uses a 12MHz crystal and internal PLLs. CPU clock is 400MHz. I'm using the stock 9G45EKES configuration and haven't looked at what other frequencies the other system clocks are running. The "setting clock" message is a straight up printf() in drivers/mmc/gen_atmel_mci.c rather than a debug() message. This seems to be the only printf that isn't conditioned on DEBUG so it is probably an oversight that should be corrected. I am working on a 9G45 product that will be released early next year and I expect to post board support patches for that with MMC support, but before that I don't plan to post my hacks to Atmel's evaluation board BSP - I'll freely share my code as-is with anyone who wants to make patches for the Atmel distribution, but my main goal is to learn what I need to know to make a clean BSP for my product. Thanks, Bill. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] fs/fat.c - file sizes incorrectly printed for files greater than 2G
Fatls prints negative numbers for file sizes larger than 2GiB because the format statements where dentptr->size are referenced all use %ld rather than %lu formats. There appear to be four places in fs/fat.c where this occurs. - Bill. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] AT91SAM9260/9XE: add support for MultiMedia Card Interface (MCI)
What is the status of this patch for getting MCI working on SAM9 CPUs? I am working on a new AT91SAM9G45 board and would like to incorporate it if it is ready for prime time. It is not clear to me who should be signing off on this patch and if they have done so. If there is work to be done on this and I could help, please let me know. I intend to submit the patches to get my 9G45 board mainlined and this might be a good way for me to start learning the intricacies of making and submitting a proper patch. Any suggestions will be appreciated. Thanks, Bill Landolina Technology Atlanta Corporation w...@techatl.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot