Quote:
Originally Posted by twobob
Hi mate, just read your mails and such.
And Knc1's link to Uboot. First time I ever looked at it. Scary.
So perhaps we should list out the knowns and work towards the unknowns.
Knowns: you have the file you want.
You know the "place" you want it to go.
There is a tool that can one to the other.
You have the parts required to do it.
Unknowns:
how to initiate "safe" file transfer including:
how to ensure file transfer does not stall
(this appears to have happened twice now according to my recollection when people have tried to undemo, check on that, will this affect our Uboot connection too? for example)
Where to put the files
(The file copying params look like expect addresses rather than helpful names, putting it in the wrong place would be "bad", like Ghost-busters "bad")
If I missed something add it below.
|
I agree that it would be nice to have the full start-up sequence from power-on to prompt documented somewhere.
Reasons:
- It is a very structured process, because machinery can not "guess".
- For RISC machines it is different than the CISC machine most common in the user's daily use computer (laptop, desktop, whatever).
- For a SoC based machine, the "usual" RISC (or CISC) machine sequence is extended by the need to "start" parts of the SoC before the outside world can influence the coding.
- I suspect the readership here is not familiar with the process.
- The 'net has plenty of documentation on what happens in the sequence between loading the Linux kernel until the user space command prompt. Not so much what happens beforehand.
In the case of the Freescale parts, the application note AN3996.pdf has a collection of the material scattered around the (3,000+ page) technical reference manual. That information (and pretty, colored, flowchart) covers power-on until the machine reaches the point where external code can affect the operation.
The nickel quick tour (to bring this post back to the "what next" question):
- The internal start up code initializes the cpu core (clock chains, etc)
- The internal start up code initializes the SPI, I2C, serial UART, USB UART. All of these devices "on-chip" (on-SoC) with a minor exception of the USB UART in the special case that the chip is hardwired to use an "off-chip" device instead of the "on-chip" device.
- In the case of the Freescale devices, the code inserts a single TLB entry that provides a one-to-one identity mapping between the physical addresses and the virtual addresses for the lowest 32bits of the 36bit address space.
- It then goes off to find an external storage media among the external media the Freescale part is built to work with.
- Note: No mention (yet) of starting any external RAM device(s). In the case of Freescale, it doesn't do that (other RISC products sometimes do).
- With an identity address mapping, at a i.MX<part> specific address offset from 0, there will be a data block with characteristics of how this (now identified part number) part has its user defined content laid out.
- At this point, you run into a en_Freescale language problem, they call it a "header partition table" - it is - it is not what most readers think of as "the header and partition table" sorry about that. The reader is supposed to understand en_Freescale at this point in the documentation.
- In the case of the part used in the K3 (I haven't looked up the tech. doc of the part used in the DX) there are three areas from which it can load the next glop of code in the the sequence. Two of which require diddling the eMMC control registers to be visible on the address bus.
- If that fails, execution continues to the i.ROM command processor code (Downloader code in en_MobileRead).
- If that succeeds, execution continues with the "boot monitor" code loaded from the first block of the selected (1 of 3 for the K3) "boot areas". The boot monitor may itself be a multiple stage boot loader (for those boot monitors larger than the fixed boot area, first block, size). In the case of the Kindle parts, this will be U-Boot. In other Freescale devices, it might be something else, for instance RedBoot is sometimes used.
- NOW you have available the command set provided by the loaded boot monitor code. My link above was to a listing from a non-Kindle product, but those where most of the basic commands.
From the above, you can see that the machine is now running one of two command processing programs (there are two exits from the above if you missed it).
Either:
i.ROM "Downloader code" (either serial UART or USB UART, it runs on the device on which it first finds activity); or
U-Boot command processor.
In the case of the U-Boot command processor, this is a fairly "high-level" application - it will have programmed into it how to start the DRAM (and other neat things).
In the case of the i.ROM command processor, this is a fairly "low-level" application (see: AN3996.pdf for details) - the user ("host") end is expected to send the i.ROM ("client") end the required hardware description (DCD) and sequence of "commands" to be run (address, data, data size tuples) **prior** to loading the next application code.
And yes, there is a watchdog that needs to be service once it is started - and it gets started **prior** to the user having a chance to inject code into the execution path.
The watchdog timer has two "time out" settings -
The shortest one only generates an interrupt (request for service) as a warning that your time is almost over; and
The longer one generates both an interrupt and an "illegal instruction" causing the SoC to trap into a hard-coded shutdown sequence.
The watchdog may be service at any time in its count down sequence by writing two special data values to it, and/or
It may be serviced by the short (getting short of time) interrupt.
The watchdog timing intervals (either or both) may be changed at any time during the count down sequence.
The parameters as set in the i.ROM code is to look for external activity for a relatively long time (2 to 3 minutes) and if none found, do a shutdown of the SoC.
Once external activity is detected (which selects either the serial UART or the USB UART as the external source of commands) the watchdog is reprogrammed to disconnect and re-initialize the (selected) UART every 90 seconds of in-activity.
** The what next answer: **
We need to use either the various source codes and/or the i.ROM "peek and poke" (as in Basic) commands to determine the contents of that flash media descriptor block.
From that, we will then know where (and what) sort of storage layout (mmcblk* logical sections) descriptor block to read.
Which answers the question - Where do I write that external file to in the address space.
(Known so far on MobileRead as a "magic offset" from address zero.)
Disclaimer the above is from memory and may well include technical errors - but it is just intended to be a general over-view, not a detailed, technical description.