qemu -M raspi[23] timer

[bzt]

Dear All,

Some time ago I've implemented the raspi3 machine type in qemu, which made it to the mainline since. Because it turned out that qemu raspi does not have any periodic timer implementation, now I've created another patch in the hope that it will be useful. Until this one gets merged too, you can apply my patch on the latest qemu repo:

https://github.com/bztsrc/qemu-local-timer

Notes: this is not the "BCM System Timer" (at 0x3F003000), and not the "Timer (ARM side)" (at 0x3F00B400) that BCM2835 Peripherals document mentions. This is the Local timer (at 0x40000034) described in BCM2836 QA7 section 4.11, available since the multicore Raspberry Pi 2 (not to confuse with the one-shot only Core timers (at 0x40000040) defined in the same spec section 4.6, which are already emulated by qemu). The emulation is limited, because there's no way of reading the current counter value, so polling is not possible. As a result, there's not much point in enabling this device without the interrupt enable flag set. But with interrupts, it can generate a periodic IRQ at 38.4MHz with a 2^28 divisor, which you can route to one of the cores' IRQ or FIQ line, and works just like in real hardware.

Tests and suggestions are always welcome.

Cheers,
bzt

[bzt]

Hi,

A very interesting, and frankly quite disturbing thing was brought to my attention.

Gregory Estrade, who originally write the raspi1 emulation in 2012 has already implemented almost all the devices in qemu. Next year, when Jan Petrous cleaned up the code for the qemu mainline, those drivers were still there. But later, in 2015 when Microshit took over the qemu's raspi branch, they have deliberately REMOVED many of the devices from qemu, including all the timer peripherals.
https://github.com/0xabu/qemu/blob/rasp ... ipherals.c

Code: Select all

/*
 * Raspberry Pi emulation (c) 2012 Gregory Estrade
 * Upstreaming code cleanup [including bcm2835_*] (c) 2013 Jan Petrous
 *
 * Rasperry Pi 2 emulation and refactoring Copyright (c) 2015, Microsoft
 * Written by Andrew Baumann
 *
 * This code is licensed under the GNU GPLv2 and later.
 */

#include "qemu/osdep.h"
   ...
    /* AUX / UART1 */
    object_initialize(&s->aux, sizeof(s->aux), TYPE_BCM2835_AUX);
    object_property_add_child(obj, "aux", OBJECT(&s->aux), NULL);
    qdev_set_parent_bus(DEVICE(&s->aux), sysbus_get_default());

    /* System timer */
    object_initialize(&s->st, sizeof(s->st), TYPE_BCM2835_ST);
    object_property_add_child(obj, "systimer", OBJECT(&s->st), NULL);
    qdev_set_parent_bus(DEVICE(&s->st), sysbus_get_default());

    /* ARM timer */
    object_initialize(&s->timer, sizeof(s->timer), TYPE_BCM2835_TIMER);
    object_property_add_child(obj, "armtimer", OBJECT(&s->timer), NULL);
    qdev_set_parent_bus(DEVICE(&s->timer), sysbus_get_default());
   ...

I've checked, there's nothing wrong with those drivers, they work like a charm, the code is clean, effective and also fits qemu's coding standards.

What do you think, why on Earth did they do that? What could be the reason behind M$ removing raspi timers from qemu? I'd like to fix those drivers to be accepted in the qemu mainline, but I can't see what was the reason for the refusal in the first place. Thoughts, suggestions?

Cheers,
bzt

[iansjack]

Why don't you ask them? Though try not to be so childish when addressing them.

[bzt]

Why don't you ask them? Though try not to be so childish when addressing them.

Hahahahaha, you made my day, man! Look who's speaking! You do realize that, right? FYI, I'm way ahead of you, and I don't just simply know the answer, what's even more, I'm already on the solution! How childish of me, isn't it? Hahahaha!

But seriously, I found it very sad that no OSDev members care about a good raspi qemu. At least noone cares enough to help. Thank God there are others!

Have a nice day,
bzt

[Schol-R-LEA]

But seriously, I found it very sad that no OSDev members care about a good raspi qemu. At least noone cares enough to help.

Or more likely, no one else knows enough about the subject to help - most of the others here don't work on RPi, and those who do are mostly only starting to learn it. The only other one I can think of here who might have enough experience with RPi is Zaval, and I get the impression that Zaval would sooner swallow a burning coal than do any more work with RPi. (OK, that's probably an exaggeration, but still.)

Also, I don't know if anyone else here has experience with writing QEMU extensions/modules. I honestly doubt it.

[zaval]

funny, but what is much more than my scepticism about rpi (as a "king" of SBCs) is my rejection and even hatred towards such a hysterical, psychotic sh!tstorm as bzt has shown here (again). after this kind of rant, there is barely a wish to even read what he types here.

and of course, I am not suitable for writing anything for qemu - neither am familiar with it nor interested in it. all my humble attempts of programming SBCs, I do on bear metal.

[bzt]

Hi Schol-R-LEA,

Thank you very much for your normal tone post (actually that's the only one in this topic, as the others are just trolling). Good to see that someone can still write a calm and on topic post.

Or more likely, no one else knows enough about the subject to help
...
Also, I don't know if anyone else here has experience with writing QEMU extensions/modules. I honestly doubt it.

Exactly my thoughts.
Btw, the answer is there's nothing wrong with those drivers (no wonder I couldn't see any problem with them), as it turned out they just happen to use an outdated qemu API incompatible with current mainline qemu.

Cheers,
bzt

[kzinti]

Hahahahaha, you made my day, man! Look who's speaking! You do realize that, right? FYI, I'm way ahead of you, and I don't just simply know the answer, what's even more, I'm already on the solution! How childish of me, isn't it? Hahahaha!

But seriously, I found it very sad that no OSDev members care about a good raspi qemu. At least noone cares enough to help. Thank God there are others!

Have a nice day,
bzt

Well yes, you can be very childish sometimes.

[Solar]

Btw, the answer is there's nothing wrong with those drivers (no wonder I couldn't see any problem with them), as it turned out they just happen to use an outdated qemu API incompatible with current mainline qemu.

Well, accessing a no-longer-supported API is "something wrong" with those drivers. It can be fixed, too -- by making drivers accessing the new API, either based on the old ones (if feasible) or from scratch.

[iansjack]

A "no-longer supported API" is one thing. An API that is "incompatible with current mainline qemu" is somewhat worse.

So - nothing wrong with the drivers - except they don't work. How evil it must be to remove them.

[Schol-R-LEA]

after this kind of rant, there is barely a wish to even read what he types here.

The forum does have an option for that, if you really mean this. If you set someone to 'foe' in their profile, you won't see their posts unless you choose to explicitly - there will be a placeholder for the post, and you can open the post if you choose, but by default the posts themselves will be hidden.

Now, then, at the risk of going off-topic...

all my humble attempts of programming SBCs, I do on bare metal.

Wait, you don't use any emulation or virtualization? That's got to make testing turn-around pretty painful - IIUC, you would need to burn each update to an SD card (or transfer it to the eMMC memory, depending) each time you update the kernel code. Do you really see that as acceptable?

I get that you have an issue with the idea of virtualization as a part of regular OS operation - I am curious as to why, but that's a separate matter - but I would expect that using an emulator would be an obvious way of simplifying the testing of new OS code. Is there some specific reason you don't do this?

[bzt]

offtopic
So many post, but all just trolling. The usual personal insults, but nothing helpful, nothing technical nor topic-related (save one). What's the matter with you?
/offtopic

FYI: "there's nothing wrong with the drivers" means they are implementing the Raspberry Pi devices as they should. Using an old qemu API is not a driver implementation issue (not RPi emulation related), that's a qemu interface issue (you know, API related).

Egyébként meg eső után köpönyeg minden okoskodásotok.

Cheers,
bzt

[Kazinsal]

The raspi is an atrocious platform that is intentionally built to be hostile to independent developers. Effort is better expended on just about any other gimmick SBC, given that the other options in that category tend to not be saddled with a melange of bad design choices and proprietary parts.

[zaval]

The forum does have an option for that, if you really mean this. If you set someone to 'foe' in their profile, you won't see their posts unless you choose to explicitly - there will be a placeholder for the post, and you can open the post if you choose, but by default the posts themselves will be hidden.

I know about that, but I don't use it. just not reading annoying/whiny stuff and that's all.

Now, then, at the risk of going off-topic...

all my humble attempts of programming SBCs, I do on bare metal.

Wait, you don't use any emulation or virtualization? That's got to make testing turn-around pretty painful - IIUC, you would need to burn each update to an SD card (or transfer it to the eMMC memory, depending) each time you update the kernel code. Do you really see that as acceptable?

I totally agree with you that "using an emulator would be an obvious way of simplifying the testing of new OS code" and I absolutely understand why people do so on x86. It's well reasonable there. But on arm SBCs, it's not as beneficial. ARM platforms aren't even closely as unified as x86, so messing around with emulators for arm, you will end up working for something like "spherical arm board in vacuum", that won't let you get closer to the real targets even a bit, or working for ... rpi which is, I believe, good emulated. both options suck. Also, the hardware differences mitigate that burden you've mentioned for ARM/MIPS boards. For example rebooting an x86 rig 10-30 times a day is a little bit painful and can cause heartburn; but it's not so for a few watts consuming SBC, which is just fine with frequent rebooting. It's fast and painless. And yes, you understood correctly, I put new files everytime on an SD card or eMMC module. It's not that tiresome at these early stages. I don't even remove media, ftp helps here. So far my "installation" lives in a dedicated folder on the very same /boot volume (or just a folder in some cases), most linux "distros" come with. So I don't need to swap cards everytime in most cases. Just a boot into linux, flash and reboot cycle and break into uboot sequence when it's time to test new portions of the lameness of your own production.
Not to mention, that for the FW part, it's inevitable way of doing things. You really need to program this real SoC and not something imaginary. And take into account slight whims of every particular SoC (like for example Amlogic SoC lying about CPU frequences, it's just an example, I don't own Amlogic devices, Amlogic doesn't provide manuals. Just remembered it, since finally Odroid-N2 has been released with their new (not so) impressive S922X SoC). Or Allwinner a64 HDMI controller, the same thing as on NXP iMX6 SoC (that are documented) but with obfuscated register offsets... Or for example different versions of the same board having proper UHS-I support and not having it (because earlier versions didn't provide a dedicated voltage regulator for the SD host controller for making 1.8V switching possible, despite the SoC is all the same and UHS-I was there all the time, what the emulator could give you such an intimate view of so many SBCs and their variances?) So you need to agree, when it's about e.g. SDRAM initialization or stuff like mentioned, none emulation could help here. OS is more free of this platform specific stuff, but not fully free on ARM platforms. Yeah, there is platform independent code in the OS, a lot of it on a good architected OS, but still to run it, you need platform dependent parts as well (of course, for the beginning, you could limit yourself by only having SDRAM and UART). Either for some "virtual" arm thing, what's there on emulators or for real one. I told, that when all your OS is just a few files (loader, an OS delegate into FW, kernel executable, hal, system hive of registry (or device tree on early stages) and a couple of "drivers" (too raw), it's not so hard to flash it everytime. Especially, given all the platform independent code lives in the kernel executable, and we kinda agreed, that emulators are useless for platform dependent one. Basically, if you want your OS to run on real ARM SBCs, write on them. This is exactly what I want, I have zero interest in programming virtual rpi.

I get that you have an issue with the idea of virtualization as a part of regular OS operation - I am curious as to why, but that's a separate matter - but I would expect that using an emulator would be an obvious way of simplifying the testing of new OS code. Is there some specific reason you don't do this?

Yes, I hate it. It's a wasteful pseudotechnology, parasitic thing eating up zillions of watts of energy for nothing. The worst of them. I hate exactly that it is being used outside of its real scope, where it's useful and helpful - testing, developing, analyzing (malware for example).
I think, that Secure World devised by ARM is way more interesting, not to mention - useful, than HV. I am very eager to try it on my own, unfortunately, am not ready yet. For an osdev, this feature opens a lot of challenges and fun. Unfortunately, not every vendor is ready to give it to you. I guess, Monitor Mode/EL3 availability on some platforms yet is a temporary goody, thanks to overlooking this by clumsy a little vendors like Allwinner, Rockchip etc. Eventually they will "grow up", get toothier and lock that down, not doing anything useful there by themselves and not letting anybody else. Just like TI does.

[bzt]

Dear All,

just not reading annoying/whiny stuff and that's all.

Meanwhile the trolls were "whinning" my patch has been merged with qemu. Moving forward with the emulation of other peripherals.

Cheers,
bzt