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
as the ARMv5 was only a test to see if things can work, I started
getting a ARMv7-a (i.e. Cortex-A15) VM running.
But so far the resulting image wouldn't boot at all. QEMU crashes
even before trying to start the kernel: "PFLASH: Possible BUG - Write
The qemu command used is this:
qemu-system-arm -m 1024M -M vexpress-a15 -serial stdio -cpu cortex-
a15 -nographic -no-reboot -kernel linux -initrd rootfs.cpio.gz
-append "mem=1024M panic=1 HOST=armv7lhf $KERNEL_EXTRA" $QEMU_EXTRA
As kernel config I used arch/arm/configs/vexpress_defconfig.
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:
Setup 2 buffered serial ports:
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
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.
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
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
- objdump -d is, unfortunately, your friend.
o Once you've got _that_, skip the rest of userspace and build a
- 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"
"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
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.