Re: New to this list
On Wednesday 08 November 2006 18:41 IST, Wookey wrote:
> On 2006-11-08 00:21 +0530, kitts wrote:
> Are you doing this as a job or for your own interest? If the former
> then I suggest you pay someone to get you started with qeustions like
> this. (My company offers this service, for example, although we are arm
> rather than coldfire specialists: http://www.aleph1.co.uk/node/326 )
I am doing this as a job. However, i picked this assignment as i was
interested in doing it. I work on embedded systems on the job front and am
personally a lover of Linux on my desktop. I have never before worked on
embedded system with hardware suitable to run linux. This is my
opportunity. We are already in talks for getting commercial support but i
am asking here more on personal interest. :-)
> > The first thing i need to know about is the design of the bootloader
> > (colilo?). How does the kernel get loaded? does the bootloader
> > decompress the kernel? I do recollect reading that the kernel
> > decompresses itself?
> I'd have to takre a look at colilo to see how it actually works, but
> you can either make an uncompressed kernel and load it to the right
> place (then neither the bootloader or the kernel does decompression)
> or make a compressed kernel, which the bootloader loads then it
> uncompresses itself. You could have the bootloader doign the
> decompression if you wanted for some reason. everything is possible.
Is vmlinux uncompressed?
> > What is the address to which the kernel is to be loaded? It is not a
> > multiboot compliant ELF image. Or is it?
> It is not an elf image, no. The load address is highly hardwre
> specific. It depends where you ram is, and whether decompression is
> occuring (which makes things more complicated). This mail explains the
> kernel symbols that lay things out:
Where does one set these values in the kernel source tree? Speaking of it,
where is all the board (not processor) specific code located in the source
tree? And how does the kernel choose this code over the rest of the
drivers? Say for example the processors internal UART?
> > The second and rather important part that i have little information
> > about is MTD. How will these flash chips appear in the /dev folder? I
> > mean; how are the chip recognized? how do they get mapped to /dev/mtd1
> > /dev/mtd2 etc?
> Mtd provides both block and char devices:
> /dev/mtdblock/0 (sometimes /dev/mtdblock0)
> These access the blocks the device presents for data, and the device
> control aspects respectively.
> MTD itself detects the chips during boot up, and you can configure
> whether it concatenates all chips into one mtd device, or presents
> them as separate devices, or concatenates them and then partitions
> them into separate devices. It is completely flexible (and thus also
> somewhat complicated to understand in full).
Again, related to the previous... How does MTD do the identification? I can
understand device discovery on larger systems which fall into a
architecture like the IBM PC. But how does it work for the embedded custom
boards? Say for example, i have two boards and they differ in the GPIOs
used to interface the flash chips. I believe there needs to be information
passed to the kernel (MTD) at either boot time or compile time that helps
it work with these devices. No?
> > I would greatly appreciate anyone who would either answer these or show
> > me documentation where i can get the relevant information.
> I've given you a few pointers above. HTH
Thanks a ton. It has been very helpful!