User:Datenwolf

From Openmoko

Revision as of 16:03, 6 September 2008 by Datenwolf (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

I currently have two strongly interconnected projects running with my GTA02v6:

  • Booting from RAM using the debug board, completely bypassing the bootloader. rootfs geting mounted by NFS.
  • Building a distribution for the GTA based on Gentoo, using the Paludis package manager and either einit or minit for the init system (with my preference on the latter). The installation root directory (Gentoo people might know this as the ROOT variable set for emerge) shall be used as the root for the NFS rootfs in the above mentioned RAM boot.

I originally intended to use uclibc, however compiling that fails on my system. For some reason I get a "bus error", when compiling it. Normally such errors indicate some hardware defect, but that's not the case here. However I know about such errors to happen, if source code is incompatible to GCC 4.x.x, which is my compiler here. It might also have to do with my development system being a amd64 machine.

Booting from RAM using the debug board, bypassing the bootloader

Instead of bypassing the bootloader one could also write emulating the bootloader, which is precisely what the goal of the process is. One might ask, why to do so. The simple answer: This works even then, if you totally borked the flash, or if there has not been installed a flash image yet.

The steps to be carried out on the GTA are:

  1. reset halt it using open-ocd
  2. loading the steppingstone at address 0x00000000
  3. setting a HW breakpoint at the address, where the steppingstone will jump to, when it's done, doing whatever it does: Initializing the SDRAM timings, and eventually boring parts of the RAM contents. That's the reason for the breakpoint. If the steppingstone left RAM contents in order, we could just upload anything we need and just run the whole thing.
  4. resume operation, steppingstone will be executed and the CPU halted, when hitting the breakpoint
  5. load the kernel image at the current PC (in the original HOWTO on loading the bootloader into RAM we'd have loaded the bootloader here, but technically it makes no difference if the Linux kernel is standing there. The kernel will reposition itself in the memory anyway, as it must decompress itself.
  6. (optional) figure out the NAND partition layout, so that it can be passed as a mtdblocks parameter to the kernel. This could also be done in form of parameters on the PC side, which are gathered by enerting the u-boot command line and reading the NAND layout from there --- the layout may change, when things are flashed through u-boot.
  7. The most important step, which I don't have figured out yet in the details: The kernel exepts some information to be delivered from a bootloader. But we don't have a bootloader. So emulate that behaviour, copying kernel parameters, command line etc. at some free memory address (preferrebly there, where u-boot would place it) and write those memory addressed into the predefined places in the kernel image we've loaded into memory previously.
  8. Now the CPU can be resumed. The kernel boots but the above procedure didn't include initialising the serial console, so I don't know yet, if the the console can be seen right away. If not, a small helper code snippet could be prepended to the kernel image in memory, that does the initialisation.

Gentoo based distribution

Nothing here yet.

Retrieved from "http://openmoko.org/index.php?title=User:Datenwolf&oldid=52348"
Personal tools

I currently have two strongly interconnected projects running with my GTA02v6:

  • Booting from RAM using the debug board, completely bypassing the bootloader. rootfs geting mounted by NFS.
  • Building a distribution for the GTA based on Gentoo, using the Paludis package manager and either einit or minit for the init system (with my preference on the latter). The installation root directory (Gentoo people might know this as the ROOT variable set for emerge) shall be used as the root for the NFS rootfs in the above mentioned RAM boot.

I originally intended to use uclibc, however compiling that fails on my system. For some reason I get a "bus error", when compiling it. Normally such errors indicate some hardware defect, but that's not the case here. However I know about such errors to happen, if source code is incompatible to GCC 4.x.x, which is my compiler here. It might also have to do with my development system being a amd64 machine.

Booting from RAM using the debug board, bypassing the bootloader

Instead of bypassing the bootloader one could also write emulating the bootloader, which is precisely what the goal of the process is. One might ask, why to do so. The simple answer: This works even then, if you totally borked the flash, or if there has not been installed a flash image yet.

The steps to be carried out on the GTA are:

  1. reset halt it using open-ocd
  2. loading the steppingstone at address 0x00000000
  3. setting a HW breakpoint at the address, where the steppingstone will jump to, when it's done, doing whatever it does: Initializing the SDRAM timings, and eventually boring parts of the RAM contents. That's the reason for the breakpoint. If the steppingstone left RAM contents in order, we could just upload anything we need and just run the whole thing.
  4. resume operation, steppingstone will be executed and the CPU halted, when hitting the breakpoint
  5. load the kernel image at the current PC (in the original HOWTO on loading the bootloader into RAM we'd have loaded the bootloader here, but technically it makes no difference if the Linux kernel is standing there. The kernel will reposition itself in the memory anyway, as it must decompress itself.
  6. (optional) figure out the NAND partition layout, so that it can be passed as a mtdblocks parameter to the kernel. This could also be done in form of parameters on the PC side, which are gathered by enerting the u-boot command line and reading the NAND layout from there --- the layout may change, when things are flashed through u-boot.
  7. The most important step, which I don't have figured out yet in the details: The kernel exepts some information to be delivered from a bootloader. But we don't have a bootloader. So emulate that behaviour, copying kernel parameters, command line etc. at some free memory address (preferrebly there, where u-boot would place it) and write those memory addressed into the predefined places in the kernel image we've loaded into memory previously.
  8. Now the CPU can be resumed. The kernel boots but the above procedure didn't include initialising the serial console, so I don't know yet, if the the console can be seen right away. If not, a small helper code snippet could be prepended to the kernel image in memory, that does the initialisation.

Gentoo based distribution

Nothing here yet.