Author Topic: The Boot process  (Read 3635 times)

Destroyer

  • Administrator
  • Jr. Member
  • *****
  • Posts: 60
  • Karma: +2/-0
    • Hardcore forensics
The Boot process
« on: January 14, 2011, 03:58:09 AM »
The Freescale iMX515 Cortex™-A8 is an interesting beast  as regards the boot process, particularly because it allows multiple boot sources to be configured  by either 'fuses' within the CPU or external GPIO lines external to the CPU, the internal fuses take precedence, this allows enhanced security features to be kept within the silicon where they are harder to 'hack'.

As previously stated, the 'hardware' fuses dictates how the CPU will boot, currently most of the tablet computers on the market are configured to boot from an integral SDcard, particularly because it means that by using a different SDcard image you can quickly upgrade/downgrade the boot process and the device functionality, interestingly then next generation of devices from China are utilizing  Nand-Flash boot systems, these are significantly cheaper, but come with their own set of problems related to reliability and upgrade functionality.


SDCard Boot process

The CPU hands over to the  boot-loader which is resident on the SDcard ,  it must be noted that at this stage the Tablet device is completely dumb and blind knowing very little or absolutely nothing  about it's attached peripherals and herein lies a key problem.

If the SDcard is corrupted or removed/miss-located  from the internal SDcard slot,  the pad device will appear to be  completely DEAD,no sound,no LCD, no function what so ever, but it needs to be pointed out that your pad/tablet is  completely ok, just the CPU does not know what it has to do to bring up the operating system so for safety , it just sits there.
« Last Edit: January 28, 2011, 05:36:55 AM by Admin »

shanghailoz

  • Special Member
  • Newbie
  • ******
  • Posts: 20
  • Karma: +0/-0
Re: The Boot process
« Reply #1 on: January 14, 2011, 06:11:37 PM »
Not quite true.
According to the data sheet it says

Ports AB21, AB22 control boot mode *

*on 19x19mm BGA version. For 13x13mm BGA is W22 / AA24

AB21 = BMOD0
AB22 = BMOD1

This is how it boots depending on that:


BMODBoot typeBoot Defaults
0 0 Internal BootExecutre ROM code boot mode from boot switches
0 1 FSL Test ModeSpecial mode for device testing (Freescale chip test?)
1 0Internal BootBoot Config from FUSE only
1 1Serial Boot Loader*USB *UART


If I check the AN4173 PDF at Freescale it also adds this:

The i.MX51 has no external boot modes but provides the following internal boot modes:

Internal boot mode—allows selection of all boot sources such as NOR, NAND, MMC/SD, OneNAND, Parallel Advanced Technology Attachment (P-ATA), Serial ROM/Flash, and so on. After Power On Reset (POR) or reset, the ROM code of the processor samples the boot pins or eFuses and loads the first set of code from the selected boot media. This code must have a Flash header at a particular offset and it varies depending on the boot source. The Flash header stores information about the application in a specific structure. It can also store DCD, which is a block of data processed by the i.MX51 to configure the hardware at boot time. This enables the configuration of some on-chip modules and external peripherals before moving to the entry point of the application.

Internal boot mode (ROM select)—is equivalent to the Internal boot, BOOT_MODE[1:0]   =   00, with the only difference being General Purpose Input/Output (GPIO) boot override pins are ignored, regardless of the BT_GPIO_SEL setting. The boot program uses only the boot eFuse settings. This allows the user to burn fuses on the closed production device with no external muxes on the BOOT_MODE, pull-ups/pull-downs, and no uncertainty of serial downloader is invoked by the unknown boot pin values during the initial boot of the device.



Of course, looking at the current boot logs, it is set to boot from MMC in the uboot.
Interested to see if the eFuses are set or not.  I suspect not.

Given that they do set to boot from MMC, it does make life easier though ;)

On an off note, I'm guessing you "hacked" the boot by modifying the env variables on MMC with a hex editor?

MMC Driver says:
#define CONFIG_ENV_OFFSET environment variables will be stored at (768 * 1024) //Offset within the MMC card where the environment variables will be stored at.


Lawrence / 小杜

Destroyer

  • Administrator
  • Jr. Member
  • *****
  • Posts: 60
  • Karma: +2/-0
    • Hardcore forensics
Re: The Boot process
« Reply #2 on: January 14, 2011, 10:35:46 PM »
Hi,
Yes you are correct about the external PIO pins setting the 'mode' ,but that is configurable by the internal security fuses of the CPU, otherwise it allows a breach of the chip security in that by changing the PIO pins you could bypass any secure loading.

But this boot can be a two stage process, and may include code 'hidden' in the CPU or a direct boot to an external peripheral.
The current system appears to be using an integral CPU boot that then reads in a 'small' section off the SDcard,  which in-turn pulls in the rest of the U-Boot loader, so 'hacking' the U-Boot loader only gives functionality after that point.

As regards  hex-edit, the only modification needed was to get over a bug in the U-Boot loader , specifically if bootdelay=0 and your on a really fast CPU, then there is no time to get any  keypreses into the Console connection before U-Boot continues the boot process, as a result it was necessary to increase the boot delay to 4,  other than that ,these boards are configured correctly to use the console, either by accident or as an aid to debugging in the production environment.

We were actually *very lucky*, I was working on a utility to automatically patch the boot-loader without the need to  'hex-edit' the  SDcard image ,but because I'm busy it was delayed.
However I now find out WHY they set it to zero because, the board is prone to 'glitching' echoed characters for the con out ... back into the con in. which means that when this U-Boot is printing up a message for  'press any key', the characters are actually 'glitching' back in as keyboard responses......
The net result is that if you do not turn the board off for 15 minutes, there is a possibility it gets stuck in the boot loader as it replies to it's own 'press any key'.

The obvious solution is to add some tie-up/tie down resistors to the lines, to ensure a little more   of a logic push is required.

Hc.