Hi linnix
I got your point but what do you mean by " If you load it with the Linux kernel, it can then load the rest from SD."
Do you mean that after loading kernel rest of thing like porting the QT library to the embedded board and running the QT application in the embedded board.
What do you mean by rest from SD , actually there is nothing loaded in the SD before.
Thank you
--------------------------------------- Posted through
e
Yes, we are really talking about two SDs. One SD for the kernel, loaded by the PC or external loader (I am using an external AVR JTAG loader). The second SD contains the file system and libraries, loaded by the board itself.
In my case:
I have
The CPU module is a soft IP cortex M1 with 32Mx32 sdram and SD2.
Hi Linnix I want to know that how the libraries can be loaded to the second SD card with the help of first one.
I mean means would not be it a double work.
Please tell this process in detail , that what is your plan.
Thank you
--------------------------------------- Posted through
My bootloader
My M1A3
M1A3 is connected to a 32Mx32 DDR SDRAM.
A 2G uSD card is also connected to M1A3.
From the PC, a Virtual Com command is sent to UDIP for bus request of SDRAM via M1A3. So, the SDRAM appears as a 128MB USB drive on the PC. The 2G uSD card also appears as a separate USB drive.
During development, the PC format an ext2 file system on the SD and write a copy of the Linux kernel on the master boot record. All the system and apps libraries are written as well.
At run-time, UDIP DMA the Linux kernel into the SDRAM boot memory. Once the kernel (running on M1A3) is activated, it can load the rest directly from the uSD.
Furthermore, UDIP can also halt/step through the Cortex M1 core and examine SDRAM directly, upon request from the PC.
All flash micros will boot from the internal flash. The bootloader is only for the parts which has a bootROM.
There is already a USB Mass Storage application which can be loaded by the bootloader.
This is also ported to the SAM3S. Release Notes:
Don't know about Digikey, but samples shipped now are the production kind.
-- Best Regards Ulf Samuelsson These are my own personal opinions, which may (or may not) be shared by my employer Atmel Nordic AB
Many recent AT91SAM9 has a bootROM which will look for an SD-Card formatted with FAT. If this is found, and a file "boot.ini" is present, it will be loaded into SRAM and executed.
The "boot.ini" application can program internal flash memories in the system using the contents of another arbitrary file on the FAT file system.
The file could be an application which implemented a USB flash card reader.
-- Best Regards Ulf Samuelsson These are my own personal opinions, which may (or may not) be shared by my employer Atmel Nordic AB
You can partition an SD-Card to contain the FAT file system with the kernel in one partion, and an EXT3 file system on the other partition. No need for two SD-Cards.
-- Best Regards Ulf Samuelsson These are my own personal opinions, which may (or may not) be shared by my employer Atmel Nordic AB
One
hen
u can
uThat's not the same. The NXP bootloader itself supports USB Mass Storage. So, you can rewrite (reprogram) the flash via USB.
The phrase "Well, you still need to JTAG the USB storage code into the CPU first." indicates that there is no support in the *bootROM* for USB Mass Storage. The Atmel first level bootloader is limited to the size of the internal SRAM, and this can be as small as 4 kB. That is why loading a USB Mass Storage application instead of integrating it into the bootloader is the preferred way. The user will not see any difference.
The Atmel bootROM does support programming a system with unprogrammed flash. You can connect using USB and SAM-BA, or you can insert an SD-Card with the neccessary firmware and let the CPU boot from the SD-Card containing code, which will program an image from the flash card into internal flash.
You can also connect SPI to an external SPI Flash/Dataflash, using a flatcable, program an internal SPI flash/Dataflash or whatever code storage you use, and then remove the flatcable, reset and boot from the newly programmed image.
The LPC32x0 does not support USB at all. You have to use the UART or JTAG for initial programming. It supports a single SPI chip select as the first boot option. It then tries parallel flash and then NAND flash.
The boot options of the SAM9 is way superior to this.
-- Best Regards Ulf Samuelsson These are my own personal opinions, which may (or may not) be shared by my employer Atmel Nordic AB
e:
b. One
mThen
you can
You
t.
Yes, my miss-statement. Boot loader comes pre-loaded.
USB mass storage device takes around 8KB.
Yes, it does. The user does not need to deal with FLIP/Avrdude or similiar. I know this is not Atmel fault (except for using JRE on window). But FLIP is flipping me off on my XP, since I have to deinstall and reinstall every time I reboot.
I think we are taking about USB capable chip such as LPC1768.
can
For ARM products, FLIP i snot used. You use SAM-BA which uses the CDC device class over USB. This allows you to program the internal memory or any external flash. AFAIK, USB Mass Storage is pretty useless for programming internal flash, since the PC might allocate any sector and does not neccessarily put things in a contiguous area. The code cannot be executed in place, so you have to load it into SRAM, or copy it into another area of flash before use.
When you mention "kernel", are you talking about a linux kernel, or what? A Linux kernel will not fit into the internal flash of most micros. It is 2 MB compressed, and ~4 MB uncompressed, so it needs to be stored in external memory anyway.
If you choose to store the kernel on an SD-Card, then you can progrm the kernel the first time, using a flash card reader, and then you can reprogram the flash using a USB Mass Storage when running linux. I am working on a prototype which will allow you to use a button which selects between booting USB mass storage or boot linux.
-- Best Regards Ulf Samuelsson These are my own personal opinions, which may or may not be shared by my employer Atmel Nordic AB
Hi, I have read the posts of this topic in this forum and want to ask something.
I'm currently working on an embedded project where we are going to use Qt. The project is based on a custom board with an ARM9 processor (Freescale i.MX27) with Linux 2.6.22 on it. This is the first time I'm doing this so I thought I'ld check that I got the procedure right. This is how I think that it should be done:
Am I correct on that? If so, I've got a few more questions but I'll wait with those until this one is answered
Thanks in advance!
Game
--------------------------------------- Posted through
Hi
can anybody tell me about my this post.
I'm currently working on an embedded project where we are going to use Qt. The project is based on a custom board with an ARM9 processor (Freescale i.MX27) with Linux 2.6.22 on it. This is the first time I'm doing this so I thought I'ld check that I got the procedure right. This is how I think that it should be done:
Am I correct on that? If so, I've got a few more questions but I'll wait with those until this one is answered.
Thank you
--------------------------------------- Posted through
Yes you are right first cross compile the linux kernel on your host PC and than port this kernel image to the developement board you have.
than compile the qt libraries for your embedded board and also port it to the board but have the same path as compiled in the host because if the path would not be same than you will get error and will not be able to run your application.
the
Use the path variable with which you compiled your application on the host PC
ofcourse you can't compile the qt application on the embedded board , so you have to have to compile it on the PC with linux.
as told earlier.
yeah trANSFER THE application to the board with the care of path variables.
yeah just switch on your board and than you will see your application running , if everything goes well.
piyush pandey
--------------------------------------- Posted through
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.