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] 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
[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] 2010.09-rc1 SD/MMC tested on Atmel AT91SAM9G45EKES - works
Dear William C. Landolina, snip 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+voltagecd=1hl=enct=clnkgl=usclient=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
[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] [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
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énarde...@eukrea.com 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
