Raspberry Pi Bare Bones tutorial producing no output?

[mycroft]

I've followed the wiki's Raspberry Pi Bare Bones tutorial to setup a kernel running in QEMU with the following configuration:
[*] aarch64
[*] raspi3

I've followed the tutorial without getting any errors. When I finally boot QEMU, however, I get no UART output (yes, i did use the

Code: Select all

-serial stdio

flag).

I have no clue how to debug this. If I were further along on an OS, I'd use UART to debug what's going on. If I got an error message, I'd research what's causing it. But with no IO, and no error message to say what's wrong, how do I go about debugging this?

[iansjack]

There is obviously a host of things that you could have done wrong (for example, did you get the various constants right for a pi3 as opposed to eatlier versions?).

Could you post a link to a repository of your source code along with details of the commands you are using to build and run your kernel. Also, what version of qemu are you using.

[mycroft]

Could you post a link to a repository of your source code along with details of the commands you are using to build and run your kernel

https://github.com/aaronjanse/rpi-os

for example, did you get the various constants right for a pi3 as opposed to eatlier versions?

Yeah, pi2/pi3 is something I'm worried about. I don't know of any issues with the constants I used, but maybe I'm wrong.

I do know that the wiki tutorial mentioned some UART differences for pi3, so I tried with pi2 also, with no success.

what version of qemu are you using.

Code: Select all

$ qemu-system-aarch64 --version
QEMU emulator version 3.1.0
Copyright (c) 2003-2018 Fabrice Bellard and the QEMU Project developers

[iansjack]

Sorry to be so long on coming back to you.

I've set up a system to test your code, and the result is that it works fine if you use myos.elf as the kernel file. Obviously there is something not quite right about the instructions in the Wiki.

As an aside, you could try the command line:

qemu-system-aarch64 -M raspi3 -monitor telnet:localhost:4321,server,nowait -kernel myos.elf -serial stdio

Then, in another terminal, run "telnet localhost 4321". This will connect to the qemu monitor, allowing you to inspect registers, memory, etc., whilst still connecting the serial port to stdio.

Edit: To be fair, in the tutorial it says

With QEMU you do not need to objcopy the kernel into a plain binary; QEMU also supports ELF kernels

but this is really not very clear. It really should explain that if you are using the -kernel option you must not use a plain binary.

[bzt]

Hi,

I have no clue how to debug this

Start qemu with "-S -s", and connect "aarch64-linux-gnu-gdb" running in another terminal to your guest machine:

Code: Select all

(gdb) set architecture aarch64
(gdb) target remote localhost:1234

if you are using the -kernel option you must not use a plain binary.

This is not true.
Here's a minimalistic, working Hello World example for UART0: https://github.com/bztsrc/raspi3-tutori ... r/05_uart0. Works with

Code: Select all

qemu-system-aarch64 -M raspi3 -kernel kernel8.img -serial stdio

where kernel8.img is a plain binary (works on real hardware too just as-is).

It worth mentioning that before RPi3 the UART0 (PL011) was wired to the system clock, UART1 (miniAUX) was not. This means you had to set the frequency for UART1 to get a consistent baud rate with a mailbox call. On the other hand, since RPi3 it is the UART1 that's wired to a fixed clock, meaning you must set the clock frequency for UART0 otherwise you can't set the baud rate properly.

Code: Select all

    /* set up clock for consistent divisor values */
    mbox[0] = 9*4;
    mbox[1] = MBOX_REQUEST;
    mbox[2] = MBOX_TAG_SETCLKRATE; // set clock rate
    mbox[3] = 12;
    mbox[4] = 8;
    mbox[5] = 2;           // UART clock
    mbox[6] = 4000000;     // 4Mhz
    mbox[7] = 0;           // clear turbo
    mbox[8] = MBOX_TAG_LAST;
    mbox_call(MBOX_CH_PROP);

Therefore there's a good chance that the code on the wikipage won't work on real hardware as it uses an unspecified baud rate (it's setting a divisor value for an unknown, arbitrary clock frequency).

Cheers,
bzt

[iansjack]

if you are using the -kernel option you must not use a plain binary.

This is not true.

I'm sure that you are correct. However, the fact is that the OP's system runs fine if you use the .elf kernel, but not if you use the stripped binary (that's with version 3.0.1 of qemu). It would be extremely helpful if you could point out to the OP why that could be the case.

In the meantime, the pragmatic approach for the OP to progress with his work is to miss out the unnecessary step of stripping the .elf kernel to produce a raw binary.

[bzt]

I'm sure that you are correct. However, the fact is that the OP's system runs fine if you use the .elf kernel, but not if you use the stripped binary (that's with version 3.0.1 of qemu). It would be extremely helpful if you could point out to the OP why that could be the case.

Right. The qemu code uses a fixed load address (FIRMWARE_ADDR_3) which should not be modified by the elf segments (see the explicit line "binfo.entry = firmware_addr;" after the "load_image_targphys" call). But if it works as an elf (strange), I'd guess it is very likely that OP is not linking the kernel to the correct address?

I'll test it too in the weekend with qemu 3.0.1 and with the latest version, just to be sure. There's a slim chance something changed in qemu internals (namely inside load_image_targphys or arm_load_kernel) which may cause trouble since I implemented the raspi3 support in qemu 2.12.

In the meantime, the pragmatic approach for the OP to progress with his work is to miss out the unnecessary step of stripping the .elf kernel to produce a raw binary.

I understand what you wrote, and there's reason in the pragmatic approach I admit. But I disagree, since the real hardware boots a raw binary I don't think that's an unnecessary step. Emulator oddities or not, if the OP ever wants to run their code on a real hw, they will need a raw binary anyway. Therefore I think the correct approach would be to take a known-to-be-working raw binary example and start from there (imho).


EDIT: oh, there it is: https://github.com/aaronjanse/rpi-os/bl ... nker.ld#L5

Code: Select all

    . = 0x8000;
    /* For AArch64, use . = 0x80000; */

Clearly a bad linking address as I suspected. Should be

Code: Select all

    /* . = 0x8000; */
    . = 0x80000;

Lesson to be learned: don't copy'n'paste blindly everything, read the comments at least

Cheers,
bzt