/srv/irclogs.ubuntu.com/2010/03/17/#ubuntu-arm.txt

=== plars` is now known as plars
=== jussi01 is now known as o1
=== o1 is now known as jussi01
apwogra_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
loolapw: Yes; and it didn't help13:09
loolapw: And I don't know what the issue is13:10
loolapw: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/52489313:10
ubot4Launchpad bug 524893 in qemu-kvm (Ubuntu Lucid) (and 3 other projects) "versatile: Can't boot initramfses (affects: 1)" [Low,In progress]13:10
apwlool ... ok thank13:10
loolapw: 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.gz13:10
loolapw: Happy if you have any idea what's going on13:10
apwlooking at it whether it needs to built in for another branch, seems not, so good13:12
loolok13:15
looldmart: Could it be that ldr is causing SIGILL under qemu but it's really a SIGBUS?13:15
looldmart: 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:16
dmartlool: hi, are we talking qemu-kvm or valgrind here?13:27
dmartpc is rounded down to a multiple of 4 when used as a base in ldr in Thumb13:30
looldmart: It's under qemu-system-arm that I test, but it's a valgrind SIGILL AFAICT13:56
looldmart: Not sure what would cause the SIGILL then13:56
dmartHi, I posted another patch.13:56
looldmart: I have a debug session open here if it helps13:56
dmartIt looks like the code at _start is executed as ARM, not Thumb, so it's a real SIGILL13:57
cwillu_at_worklool, could you pop your head into #ubuntu+1, and glare at thiebaude, and then leave again?13:57
dmartThe _start symbol needs to be properly tagged to solve this (as for ARM/Thumb interworking generally)13:57
loolcwillu_at_work: thiebaude?13:59
cwillu_at_workyes13:59
cwillu_at_workhe's using your name in vain13:59
cwillu_at_workah, he's gone now anyway14:00
looldmart: 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; ok14:00
looldmart: This ARM/Thumb stuff is tricky14:00
dmartlool: 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
loolI didn't quite grasp how the various memory locations are ARM or Thumb yet14:00
dmartNormally you don't need to worry about the instruction set for the program entry point 'cause that's in crt*.o14:00
loolcwillu_at_work:14:01
loolcwillu_at_work: As in lol?14:01
cwillu_at_workdon't mind me, I'm goofy at this hour14:01
cwillu_at_work(yes)14:01
dmartlool: "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:02
looldmart: Wee!14:07
looldmart: Doesn't SIGILL anymore14:07
loolI get helpful output14:08
loolNow need to start qemu-system-arm as qemu-arm wont cut it14:08
looldmart: Ok; after another similar fix than yours, I'm hitting "unhandled instruction"14:21
dmartunhandled instruction: yeah, that would probably be the real "valrgind doesn't support Thumb-2" problems15:18
dmartUnless you can eliminate *all* Thumb code (including crt*.o and friends and all libraries including libgcc), this will happen15:19
=== bjf is now known as bjf-afk
=== bjf-afk is now known as bjf
=== bjf is now known as bjf-afk
Sleep_Walkerhi22:25

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!