On 02/08/11 14:06, Somebody in the thread at some point said:
Hi -
omap3430/3530 seem to be the only supported ARMv7 CPUs in an omap3530 branch, and it seems the only supported board is beagle. It didn't build for me since my cross toolchain has FORTIFY_SOURCE and defaults to Thumb and because I'm using a French locale, I've sent a patch series to Matt Hsu since he seems to be the one committing to this branch. Overall, many things seem hardcoded like the cmdline args
Hey nice job!
which include the rootfstype. In past discussions around detecting the
Yes, to eliminate any state held by the bootloader it defines the boot scenarios that are possible sources of the kernel image per board. However those listed are tried in order and the ones with the wrong filesystem or absent file fail immediately so the next can be tried. There's also support for generic input and indicators allowing the user to change boot path to a backup kernel + initrd for example by holding a button.
What you can do about boot configuration is allow one of these "append" files in the per-board structure. These can only append to the kernel commandline that is defined for the board, but since the last version of most tokens is actually used it allows override of loglevel and so on from the filesystem.
board with John Rigby and Steve Sakoman, it wasn't entirely clear how one would actually detect the board one is running on, so I'm not sure how Qi would deal with this.
What has worked for other boards is fingerprinting by JEDEC ID, but depending on the board other peripheral ID registers, serial EEPROM, or tied IO can help. If you need board "identity" data, eg, MAC addresses that don't live on your SD Card, you will need an identity serial EEPROM anyway.
In terms of licensing, many files lack a header, and there is no top-level COPYING, but it seems to be mostly GPL v2.
It's GPL2.
The result (image/qi-omap3530-beagle-fixes_14ef8c447f592dcd.bin) wasn't recognized by QEMU whem I copied it as MLO on an otherwise working image; I guess I'm missing some required step, but I didn't find any new tool or target while reviewing the diff from the master branch to the omap3530 one.
MLO needs one of two flavours of TI magic header, I don't know what Matt did about it since there are (two) TI tools floating about for that, but for uImage I wrote a shell script to replace mkimage and integrated it into Qi and that'd be the best approach.
-Andy