=== plars` is now known as plars
=== jussi01 is now known as o1
=== o1 is now known as jussi01
[13:09] <apw> ogra_cmpc, lool, we recently added CRAMFS to builtin i think for at least one of our arm bracches... what was the reason again?  initrd support perhaps?
[13:09] <lool> apw: Yes; and it didn't help
[13:10] <lool> apw: And I don't know what the issue is
[13:10] <lool> apw: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/524893
[13:10] <ubot4> Launchpad bug 524893 in qemu-kvm (Ubuntu Lucid) (and 3 other projects) "versatile: Can't boot initramfses (affects: 1)" [Low,In progress]
[13:10] <apw> lool ... ok thank
[13:10] <lool> apw: You can try with the images at http://ports.ubuntu.com/ubuntu-ports/dists/lucid/main/installer-armel/current/images/versatile/netboot/ and qemu-system-arm -m 256 -M versatilepb -cpu cortex-a8 -kernel vmlinuz -initrd initrd.gz
[13:10] <lool> apw: Happy if you have any idea what's going on
[13:12] <apw> looking at it whether it needs to built in for another branch, seems not, so good
[13:15] <lool> ok
[13:15] <lool> dmart: Could it be that ldr is causing SIGILL under qemu but it's really a SIGBUS?
[13:16] <lool> dmart: disassemble shows that it's a "ldr r0, [pc, #24]"; I'm not sure what can go wrong here, I guess only the fact that it's not 4-bytes aligned?
[13:27] <dmart> lool: hi, are we talking qemu-kvm or valgrind here?
[13:30] <dmart> pc is rounded down to a multiple of 4 when used as a base in ldr in Thumb
[13:56] <lool> dmart: It's under qemu-system-arm that I test, but it's a valgrind SIGILL AFAICT
[13:56] <lool> dmart: Not sure what would cause the SIGILL then
[13:56] <dmart> Hi, I posted another patch.
[13:56] <lool> dmart: I have a debug session open here if it helps
[13:57] <dmart> It looks like the code at _start is executed as ARM, not Thumb, so it's a real SIGILL
[13:57] <cwillu_at_work> lool, could you pop your head into #ubuntu+1, and glare at thiebaude, and then leave again?
[13:57] <dmart> The _start symbol needs to be properly tagged to solve this (as for ARM/Thumb interworking generally)
[13:59] <lool> cwillu_at_work: thiebaude?
[13:59] <cwillu_at_work> yes
[13:59] <cwillu_at_work> he's using your name in vain
[14:00] <cwillu_at_work> ah, he's gone now anyway
[14:00] <lool> dmart: Oh so it's executing random instructions because it jumps into an assembly which was built as Thumb (our default) but is executed as ARM because it was not annotated properly as such; ok
[14:00] <lool> dmart: This ARM/Thumb stuff is tricky
[14:00] <dmart> lool: Yes, it looks like there is also some wrong code in m_syswrap/syswrap-arm-linux.c causing another SIGILL... I have a meeting now though.
[14:00] <lool> I didn't quite grasp how the various memory locations are ARM or Thumb yet
[14:00] <dmart> Normally you don't need to worry about the instruction set for the program entry point 'cause that's in crt*.o
[14:01] <lool> cwillu_at_work:
[14:01] <lool> cwillu_at_work: As in lol?
[14:01] <cwillu_at_work> don't mind me, I'm goofy at this hour
[14:01] <cwillu_at_work> (yes)
[14:02] <dmart> lool: "I didn't quite grasp how ..." neither does the CPU ;)  so you need to tell it when you jump into code.  The toolchain tracks this by setting the bottom bit of the address of Thumb symbols, but proper tagging is needed to enable this.
[14:07] <lool> dmart: Wee!
[14:07] <lool> dmart: Doesn't SIGILL anymore
[14:08] <lool> I get helpful output
[14:08] <lool> Now need to start qemu-system-arm as qemu-arm wont cut it
[14:21] <lool> dmart: Ok; after another similar fix than yours, I'm hitting "unhandled instruction"
[15:18] <dmart> unhandled instruction: yeah, that would probably be the real "valrgind doesn't support Thumb-2" problems
[15:19] <dmart> Unless you can eliminate *all* Thumb code (including crt*.o and friends and all libraries including libgcc), this will happen
=== bjf is now known as bjf-afk
=== bjf-afk is now known as bjf
=== bjf is now known as bjf-afk
[22:25] <Sleep_Walker> hi