search

insane-adding-machines / frosted

Frosted: Free POSIX OS for tiny embedded devices
GNU General Public License v2.0
214 stars 39 forks source link

qemu broken #39

Closed richardcochran closed 8 years ago

richardcochran commented 8 years ago

Following the readme, 'make qemu2' gives

qemu-system-arm -semihosting -M lm3s6965evb --kernel image.bin -serial stdio
qemu-system-arm: Could not load kernel 'image.bin'

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

danielinux commented 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.

danielinux commented 8 years ago

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?

richardcochran commented 8 years ago

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

danielinux commented 8 years ago

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?

richardcochran commented 8 years ago

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

danielinux commented 8 years ago

Confirmed, we are taking care of this

danielinux commented 8 years ago

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.

danielinux commented 8 years ago

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...

richardcochran commented 8 years ago

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

danielinux commented 8 years ago

Several problems fixed:

Shell can now be started, but it looks like there are some issues left in signal handling when running on qemu

danielinux commented 8 years ago

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

S4mw1s3 commented 8 years ago

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?

danielinux commented 8 years ago

@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

richardcochran commented 8 years ago

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

richardcochran commented 8 years ago

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 use make 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

danielinux commented 8 years ago

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.

danielinux commented 8 years ago

@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

danielinux commented 8 years ago

@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.

S4mw1s3 commented 8 years ago

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 !

S4mw1s3 commented 8 years ago

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

richardcochran commented 8 years ago

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

danielinux commented 8 years ago

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.

danielinux commented 8 years ago

This is now solved.

richardcochran commented 8 years ago

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

danielinux commented 8 years ago

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.

danielinux commented 8 years ago

@richardcochran wiki updated as you suggested.

richardcochran commented 8 years ago

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