View Single Post
Old 09-26-2012, 07:03 PM   #248
knc1
Going Viral
knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.
 
knc1's Avatar
 
Posts: 17,212
Karma: 18210809
Join Date: Feb 2012
Location: Central Texas
Device: No K1, PW2, KV, KOA
Quote:
Originally Posted by ixtab View Post
Whoa

Given that I have been exploring the inner workings of embedded devices for less than 24 hours now, I guess I can be proud of the fact that I understand about 1/3 of this (the english words, that is ).

No offense intended - this is just massively overwhelming for someone who never had to deal with the device at that level and is just trying to use it. I'm fine with looking up all the TLAs, but it would really help if you could provide links (or pointers) for those "we know that..." statements. This is exactly the kind of knowledge that is important, and that you have, because you have been dealing with embedded devices for years - but it's almost impossible to find for a newcomer, especially if the documentation spans thousands of technical pages.

For two concrete examples: could you please pinpoint the chapters/sections/other material where relocations and address space switching are described?

This would be tremendously helpful and very much appreciated - thanks!
Ah, I ruined my 20-20 with this reply.

1) I do not know ARM down to the bit level and arch description.
I would have to do the same as any other mortal, look it up in that 3,000+ page technical reference manual.

2) These ARM cores include a MMU (memory management unit).
The core comes up in the innermost level of the layers of protected memory spaces (supervisor level - anything goes).
To simplify the silicon (in MIPS and ARM) the MMU can not be turned on / turned off once its is initially loaded. The i.ROM code enables the MMU by loading a single descriptor into the TLB (translation look-aside buffer).
From then on, all your addresses are virtual, not physical.

None of that is much different than the complex instruction set computer that you are probably using every day.

A "pc" style computer has a "BIOS" as a legacy of the evolution of the devices from micro-controllers.

Other computer systems do not have a "BIOS" in the sense that a "pc" style computer has.
They use what is termed a "boot monitor" - common ones being Redboot, U-boot, and manufacturer's variations on the theme.

A link to the first thing to grab (at least for its color picture) is the Freescale publication AN3996.pdf.
I was wrong, you don't have to sign for it, it is available to everyone:
http://cache.freescale.com/files/dsp...ote/AN3996.pdf

Yes, I know that doc pertains to the i.MX35 - but the internal (burnt into the silicon) code does not differ in its external behavior enough to matter on the other SoC parts.

One thing that does differ on the i.MX31 (DX, DXG) is that SoC has some "program once" internal ROM in addition to the burnt-in code ROM.
(and some of the early mask versions burnt-in code errors. Amazon doesn't use those early parts, so toss that into the trivia bin.)

I really do not know ARM arch in detail enough other than to give the sort of over-view that I have been providing.
Not that I am being difficult, I just know the internals of non-ARM devices in more detail.

Last edited by knc1; 09-26-2012 at 07:15 PM.
knc1 is offline   Reply With Quote