Closed richardcochran closed 8 years ago
Hi Richard, Thanks for reporting this. We ported on a number of boards, very likely we "abandoned" the qemu build for a while. We'll have a look to fix, and possibly add this to our continuous integration so it won't happen in the future.
OK, quickly tested, and it seems to boot, but I can't get to a prompt. The fact is that qemu LM3 target is very limited in flash size, so it will refuse to boot if the flash image is too big.
I ran menuconfig from the userland dir, and left in only fresh+init.
I am using qemu 2.5.0. Since I am testing via ssh, I replaced the -serial stdio with -nographic, like this:
qemu-system-arm -semihosting -M lm3s6965evb --kernel image.bin -nographic
I get this:
Frosted shell - aka "Fresh"
--------------------------------------------
Licensed under GPL
qemu: fatal: Trying to execute code outside RAM or ROM at 0xdecea5ec
R00=20007fa0 R01=00000001 R02=00000010 R03=20007fa0 R04=00000000 R05=00009e04 R06=00000000 R07=20007f90 R08=00000000 R09=00000000 R10=00000000 R11=00000000 R12=00000000 R13=20007f90 R14=00002ac7 R15=decea5ec PSR=000001f3 ---- T svc32 FPSCR: 00000000 [1] 522 abort (core dumped) qemu-system-arm -semihosting -M lm3s6965evb --kernel image.bin -nographic ` What is the error you are getting? Is it similar to this?
On Thu, Jun 09, 2016 at 03:09:17AM -0700, Daniele Lacamera wrote:
I ran menuconfig from the userland dir, and left in only fresh+init.
I tried to do that, but the kernel doesn't build afterwards. Here is what I did:
cd frosted-userland/
make menuconfig
cd ..
make
The build crashes with:
arm-frosted-eabi-gcc -DFLASH_ORIGIN=0x0 -DFLASH_ORIGIN=0x0 -DAPPS_ORIGIN=$(( * 1024)) -DCONFIG_KRAM_SIZE= -DCONFIG_SYS_CLOCK= -mthumb -mlittle-endian -mthumb-interwork -DCORE_M3 -fno-builtin -ffreestanding -DSYS_CLOCK= -DCORTEX_M3 -DFROSTED -Ikernel/libopencm3/include -Ikernel -Iinclude -I. -mthumb -mlittle-endian -mthumb-interwork -DCORE_M3 -DBOARD_ -D -DCONFIG_KMEM_SIZE= -DCONFIG_TASK_STACK_SIZE= -DCONFIG_KLOG_SIZE= -Ikernel -Iinclude -I. -Ikernel/libopencm3/include/libopencm3 -Ikernel/libopencm3/include -fno-builtin -ffreestanding -nostdlib -ggdb -ggdb3 -c -o kernel/frosted.o kernel/frosted.c
/bin/bash: * 1024: syntax error: operand expected (error token is "* 1024")
Notice this:
-DAPPS_ORIGIN=$(( * 1024))
.................^^
What am I missing?
What is the error you are getting? Is it similar to this?
Nope, it did not get that far. Qemu stops right away with:
qemu-system-arm -semihosting -M lm3s6965evb --kernel image.bin -serial stdio
qemu-system-arm: Could not load kernel 'image.bin'
Thanks, Richard
Have you also run 'make menuconfig' from the root dir? Can you share your kconfig/.config
file?
I think that the "Could not load kernel" message is because the image does not fit into the emulated flash device. What's the size of image.bin in your case?
Ok, after running menuconfig again from the top level (very intuitive - not!), the build succeeds. The resulting sizes are:
169K Jun 9 15:00 image.bin 105K Jun 9 15:00 apps.img 64K Jun 9 15:00 kernel.img 411K Jun 9 15:00 kernel.elf
Before the "slimming down" of frosted-userland, the sizes were:
331K Jun 9 15:13 image.bin 267K Jun 9 15:13 apps.img 64K Jun 9 15:13 kernel.img 411K Jun 9 15:13 kernel.elf
With the slimmed configuration, qemu does start, but there is no output at all using the qemu command line in the Makefile.
HTH, Richard
Confirmed, we are taking care of this
Some improvements have been made, even if it looks like that starting the idling process is giving issues. Also stdin on the virtual uart does not seem to work properly. Still investigating.
Still working on this... we are now investigating whether it might be related to the other bug (#49). @richardcochran please be patient, we all want the qemu port back to life ASAP...
No hurry, I can wait. At one time, I was working with uCs, and was really frustrated at the lack of posix-like environments. I expect the cortex-m devices will totally eliminate the 8 and 16 devices (or at least I hope they will), and so you have picked the right horse, IMHO.
Anyhow, once the qemu works again, then I can take a closer look. For your project, I think it will help to keep the qemu working in order to attract more people. A working qemu demo demonstrates quality, while a broken one gives a different first impression.
Thanks, Richard
Several problems fixed:
Shell can now be started, but it looks like there are some issues left in signal handling when running on qemu
Seems to be working again after 615a7be4aba7b0bef5af2f6da53b2b30528d9da7 . However, I am currently using a modified version of qemu to have a synthetic LM3S target with 1MB flash and 256K RAM, in order to test more features and applications at once. My dirty qemu hack is here : https://github.com/insane-adding-machines/qemu/commit/7fe46bb1bb218046121ec7d596c532ecc9c134c5
Coincidentally I started playing around with frosted and qemu a bit today and I'm also having no luck with getting it working. I downloaded qemu 2.6.0 source, compiled and installed it. I'm at latest hash 0a72a6a0afdb087cbc82dc644b4ade2b1df52225. When I run make qemu, all I get is a black qemu screen. Unfortunately no frosted shell. MCU is LM3S-VIRTUAL. Kernel flash and ram is set to 64KB (default). Userland includes only init and fresh. @danielinux I applied your "dirty qemu hack" but also no results with that. @richardcochran could you maybe check now if you see some improvement?
@S4mw1s3 make qemu
will wait for you to start gdb before booting. You should use make qemu2
instead.
Here is my current working config (using modified qemu) https://gist.github.com/danielinux/c19b8b69ca80cd2dd7215fd0a5235539
On Sat, Jul 16, 2016 at 03:20:29PM -0700, Sam Van Den Berge wrote:
@richardcochran could you maybe check now if you see some improvement?
Nope, it is not fixed. Black screens only.
I wanted to debug the image, but frosted's ARM toolchain doesn't include gdb. How lame is that?
Thanks, Richard
On Sat, Jul 16, 2016 at 05:39:46PM -0700, Daniele Lacamera wrote:
@S4mw1s3
make qemu
will wait for you to start gdb before booting. You should usemake qemu2
instead.Here is my current working config (using modified qemu) https://gist.github.com/danielinux/c19b8b69ca80cd2dd7215fd0a5235539
Didn't help me at all.
I bet you have got some kind lucky (for you, unlucky for everyone else) developer environment. I suggest taking a reality check. Start with a fresh machine or VM, clone your github stuff, and try to build the qemu demo, following the directions from your wiki. You may be surprised to find out how well it works.
Thanks, Richard
I wanted to debug the image, but frosted's ARM toolchain doesn't include gdb. How lame is that?
We don't have a specific host debugger. You can use arm-none-eabi-gdb (in my distro is a separate package from the arm-none-eabi toolchain, namely gdb-arm-none-eabi)
I bet you have got some kind lucky (for you, unlucky for everyone else) developer environment. I suggest taking a reality check.
I am going to try on a second machine. Thanks.
@richardcochran Sorry to disappoint, I just got another laptop, did this
https://gist.github.com/danielinux/7609e4615c11e6ba44c83cd1540bda5e
And I get a woking console on stdio.
Can you double check what's different with your procedure?
Thanks
@richardcochran @S4mw1s3 @lorddex Can you please help me figuring out wheter there is something wrong in the procedure? I don't want to close this as "works for me" until I get a confirmation from any of you.
I get a shell now. I only executed the 2 wget commands to get kernel and user space configs to get it working. I guess there must be one (or more) option(s) that prevents qemu to show the shell. I'll try to find out which one. Thanks for helping us out so far @danielinux !
I think I found why it failed at my case. In kernel config -> device drivers, Generic UART driver was enabled but USART0 wasn't checked. @danielinux is it an option to enable USART0 by default when generic uart driver is enabled? Or maybe to enable USART0 when LM3S-VIRTUAL is selected?
Either way, current steps I did to get a shell was: 1) clone frosted repo 2) submodule init & update in frosted and frosted-userland 3) make menuconfig in kernel, set MCU to LM3S-VIRTUAL and in device driver -> Generic UART driver I enabled USART 0 4) make 5) make qemu2
On Sun, Jul 17, 2016 at 02:23:18AM -0700, Daniele Lacamera wrote:
We don't have a specific host debugger. You can use arm-none-eabi-gdb (in my distro is a separate package from the arm-none-eabi toolchain, namely gdb-arm-none-eabi)
I have had some bad experiences mixing and matching gdb with cross toolchains. Anyhow, it is super easy in crosstool-ng to include gdb, just one check box, iirc. Why not include it?
Thanks, Richard
Anyhow, it is super easy in crosstool-ng to include gdb, just one check box, iirc. Why not include it?
Thanks for the suggestion, I opened a different issue #60 for this.
This is now solved.
On Sun, Jul 17, 2016 at 03:10:30AM -0700, Daniele Lacamera wrote:
https://gist.github.com/danielinux/7609e4615c11e6ba44c83cd1540bda5e
Yes, this works for me, too. Thanks!
(These instructions should be on the qemu wiki page, don't you think?)
Can you double check what's different with your procedure?
Here is what fails: Selecting ARCH/MACH_LM3S6965 instead of _LM3SVIRT does not work. However, I would expect it to work, since git grep for LM3S in the repos finds only stuff related to the memory sizes.
I'll take a closer look when I get the chance...
Thanks, Richard
Did you change the default memory settings when testing with the LM3S target? As the board only has 64KB of RAM, you can't use it all for the kernel, or the processes won't start.
In order to test with MACH_LM3S6965, you should reduce KRAMMEM_SIZE to 32.
@richardcochran wiki updated as you suggested.
On Sun, Jul 17, 2016 at 11:07:31AM -0700, Daniele Lacamera wrote:
As the board only has 64KB of RAM, you can't use it all for the kernel, or the processes won't start.
Aha. (Hm, the build system knows the sizes. Ideally it would detect my misconfiguration.)
In order to test with MACH_LM3S6965, you should reduce KRAMMEM_SIZE to 32.
Yes, that works. Must it always be half of the RAM? I tried 16, and that did not work.
Thanks, Richard
Following the readme, 'make qemu2' gives
The readme says qemu 2.2 is required. I tried:
None of them works for me.
FWIW, it appears that the '-kernel' option expects an ELF file, but the image.bin is a binary flash image, isn't it?
Thanks, Richard