On Fri, 2016-05-27 at 16:41 +0000, Baumann, Christoph (C.) wrote: Bringing this back on-list, sorry I have been multitasking a lot and trying to catch up with various emails this morning. To summarize, I asked Christoph off list (because it was excessively late at night and I didn't want him to feel forgotten) to check the kernel startup output from running ./aboriginal-start --interactive from the aboriginal-controller wrapper scripts to further debug the problem, and he has also been trying to add support for ARMv7-a hard float to aboriginal. A separate thread on the aboriginal mailing list has been started regarding ARMv7-a support for which Rob's reply is also enlightening: http://lists.landley.net/pipermail/aboriginal-landley.net/2016-May/0025 75.html So we are looking at 2 separate issues here, one is that the aboriginal automation of ybd is not working on your setup. To test this we should not get ahead of ourselves and stick with armv5l which we know works. For this first issue, it would be best to start the aboriginal-start wrapper script with the interactive flag, because without that we do not connect anything to the kernel's boot terminal and we do not get any useful output. I should point out that the aboriginal-start differs from the dev- environment.sh script mostly because of the qemu features that it uses. Particularly, it adds the following qemu options: Setup a virtfs for the 9p mount: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -virtfs local,path=${SHARE_DIR},security_model=mapped- file,mount_tag=share Setup 2 buffered serial ports: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -device virtio-serial -chardev pipe,path=${COMM_OUT},id=comm0 -device virtserialport,chardev=comm0,name=serial0 -chardev pipe,path=${COMM_IN},id=comm1 -device virtserialport,chardev=comm1,name=serial1 Without having looked at the bootup messages from aboriginal-start in interactive mode, we cant really know for sure but I think it's a good bet that this will not work on your slightly older version (2.0.0) of qemu. For ARMv7-A support, it's great to see that someone is looking at this, supporting ARMv7-A and AArch64 is also important to us :) I did also make a similar attempt as you did for ARMv7-A and obtained similar results. I have a local IRC log of a conversation with Rob in which he tries to explain some details about what efforts go into supporting a new arch. First, I think we're missing the compiler tuning options you provided for your ARMv7-A attempt, and further, I think that we can draw inspiration from other projects, including Baserock definitions for the armv7lhf target in build-essential. The trick here is to build a cross compiler that targets a very specific ARM feature-set. For ARMv7-A, we are most probably interested in generating binary code which:   o Expects thumb2 features are present   o Uses vfpv3 (vector floating point v3)   o Has neon SIMD available The last one is probably unimportant for testing purposes but really should be chosen for production. This needs to be expressed in the GCC_FLAGS in your new ARMv7-A target file, as Rob explains in his reply on the Aboriginal mailing list, the kernel build system will interrogate the compiler to some extent and decide how to build itself, in addition to it's own config. Getting it off the ground is a delicate dance of bringing all three aspects in line:   o Compiler target tuning options   o Kernel configuration   o Qemu launch command At the end of this mail, I tried to summarize comments from an IRC conversation which should give you at least a vague idea of what your time might look like should you endeavor to debug it and add support for ARMv7-A, it's a bit messy sorry for that, it's just a summary of a random IRC conversation but should still help to provide some insight. Best Regards     -Tristan Summary of IRC chat explaining about adding new targets: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ o Build your compiler (needs a tuple and gcc/binutils configure   options) and libc (uClibc needed a config, musl generally needs a   target added). o Get a hello world program that qemu-blah can run.  - Finding an existing hello world and single-stepping through    qemu's -s mode hooked to gdb "target remote" is sometimes    required. :P  - objdump -d is, unfortunately, your friend. o Once you've got _that_, skip the rest of userspace and build a   kernel.     - Try to get console output.     - Pick a target board qemu can emulate that has a linux defconfig.     - Lists available boards - qemu-system-blah -M "?"   So do your "make ARCH=arm64 defconfig", then "mv .config walrus" and   "ARCH=arm64 ~/aboriginal/more/miniconfig.sh walrus" that'll grind for   like an hour.   And at the end you have a mini.config file. Then run it through that   filter, which yanks the baseconfig symbols out ("filter   baseconfigfile miniconfigfile" with output to stdout)   Then read through your symbols and look each one up in   "make ARCH=arm64 menuconfig"'s help.   Forward slash is your friend there (search for config symbol) o Build that (yanking all =m symbols first becuase if it's a module,   it's not needed to boot the system.) o Once you've got console output, try to get an initramfs going.   for armv7l you can just use an armv5l cpio file, it's backwards   compatible. But the kernel won't build without the right toolchain because it uses inline assembly that cares. :P Eventually you want to add just the symbols to enable board support, including board-specific devices. Use the other sources/targets as examples.