====== Resolving Booting Problems on arm ======

From [[http://ts78xx.digriz.org.uk/booting-woes]]

===== Resolving Booting Problems on your TS-7800 =====

Sometimes you can find yourself pulling out your hair when trying to get your board to boot. Here is a list of the ones I have stumbled into, how you can identify them and how you fix them.

==== unrecognized/unsupported machine ID ====

Technologic Systems unfortunately fell into the same trap that all ARM board manufacturers insist on doing, they [[http://tech.groups.yahoo.com/group/ts-7000/message/11866?var=0&l=1|completely messed up on registering]] an [[http://www.arm.linux.org.uk/developer/machines/|ARM Linux offical machine ID]]. This means then when Linux boots, it thinks it is booting on a hardware platform it knows nothing about, and so aborts.

To fix this, once you have compiled your kernel, you use the tool [[http://devio.sourceforge.net/|devio]] (you will need to compile from source if you are not a Debian-esque user) and have a script that is similar to:

<code>
alex@berk:~$ cat /usr/src/ts7800/prep-kernel
#!/bin/sh
(
  devio 'wl 0xe3a01c06,4' 'wl 0xe3811074,4'
  cat /usr/src/ts7800/ts78xx.git/arch/arm/boot/zImage
) > /usr/src/ts7800/zImage.fixup
exit 0
</code>

After running the above script, you will find a new file (/usr/src/ts7800/zImage.fixup) that you should use instead to run on your TS-7800. For those curious what it does, it loads into the ARM register r1 the expected machine ID for the TS-7800 (0x0674 aka 1652), plastering over the incorrect value the TS-BOOTROM places into there just prior to running the Linux kernel.

Alternatively, this can be changed for good in the MBR. A quick look in the MBRs provided by Technologic Systems shows a value of 0x020E at offset 0x00D0, and this is the value displayed by a kernel with full debugging when it refuses to boot. By using a hex editor and changing that value to 0x0674 the kernel binaries no longer hacking for forced loading of the machine ID but it is still functional with such a kernel. So far this solution has not been checked with any of the kernels provided by Technologic Systems and for those the original MBRs might still be the best choice.

==== Linux Uncompressing Works, then Nothing ====

This could be a number of things:

  - did you remember to compile your kernel with ''%%CONFIG_SERIAL_8250=y%%'' and ''%%CONFIG_SERIAL_8250_CONSOLE=y%%''
  - even if you do not use an initrd and are using an initramfs, for some wierd reason if you have enabled ''%%CONFIG_BLK_DEV_INITRD=y%%'' you must also have ''%%CONFIG_BLK_DEV_RAM=y%%'' selected
  - did you remember to set ''%%CONFIG_CMDLINE="console=ttyS0,115200n8"%%''