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.
Technologic Systems unfortunately fell into the same trap that all ARM board manufacturers insist on doing, they completely messed up on registering an 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 devio (you will need to compile from source if you are not a Debian-esque user) and have a script that is similar to:
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
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.
This could be a number of things:
CONFIG_SERIAL_8250=y and CONFIG_SERIAL_8250_CONSOLE=yCONFIG_BLK_DEV_INITRD=y you must also have CONFIG_BLK_DEV_RAM=y selectedCONFIG_CMDLINE="console=ttyS0,115200n8"