OSDev.org

> Were they high making this? So ethernet, wifi, blutooth, sd cards are "intended to be controlled by the GPU"? entirely?

Ignoring the uncalled-for insult...

You do get access to the SDIO interface. Add to that that the Ethernet controller is attached to the USB controller, which you do get access to, and that the wifi/bluetooth chip is attached to the second SDIO interface that you also have control of, and your argument falls completely flat.

Please also note that on x86/x64 systems you always retain a SMM that can contort anything you do and deny you access to literally everything. It can even emulate whole devices for you. This is not worse than x86 - and I will argue it's actually better.

Candy wrote: You do get access to the SDIO interface.

SDIO is NOT SD memory card interface. It's first. Second, - I don't see even SDIO in the list of accessible interfaces. It's a mode of operation of an SD controller, which doesn't seem to be accessible directly, normally.

Add to that that the Ethernet controller is attached to the USB controller, which you do get access to, and that the wifi/bluetooth chip is attached to the second SDIO interface that you also have control of, and your argument falls completely flat.

Not it doesn't. On a normal ARM machine, you have every peripheral accessible, and it's done a normal way. For example, you see (in the TRM) - we have 3 SD/MMC controllers, their bases are <bases>, here, their version compliance and capabilities are <blablabla>, see, it's their block scheme, SD controller is SDA HC compliant, so go read that, it's how it works, or, if it's not SDA compliant (it not necessarily should), - here is its HC interface, here is register description, every bit is described. Finally, good manuals give you programming guides, notes and algorithms' block schemes - you have all the set of information to do a real hardware programming, you really program that peripheral - isn't this the joy of OS development? When I first programmed SD controller, it was on the Mips Creator CI20, it's controller had all that descriptions. I didn't look anywhere else except jz4780 TRM (the SoC) and SD specification. And it succeeded almost instantly! The only thing, I screwed up the bus width, chose 4 bits, whereas only one line was configured. Just one bug and then it worked! It was amazing. And why it was so successful? because there was satisfactory description of how to do that. And that was SD controller programming. Not VC mailbox programming. That's the difference.
There is no such thing on RPi. Instead you only program ARM MCU, on a closed VC machine, and that ARM MCU is a toy, allowed to do a very small set of platform control.

Please also note that on x86/x64 systems you always retain a SMM that can contort anything you do and deny you access to literally everything. It can even emulate whole devices for you. This is not worse than x86 - and I will argue it's actually better.

Not fair comparison. In reality, that legacy SMM doesn't hide from you almost 90% of peripherals like VC does. Doesn't hide system address space of the CPU, turning it into an MCU. It runs at the same CPU at all. SMM is an auxiliary thing, what does it really control? Fan speed, CPU throttling? Anyway, it's a system management component of the FW, we might say, it's a BIOS's variant of the UEFI runtime services, roughly speaking, every FW exposes runtime services to the OS, it's not even close to what VC does, SMM doesn't stick its nose into peripherals it has nothing to do with. By the way, on real ARM machines, you can do DVFS - dynamic voltage frequency scaling by yourself, whereas RPi only lets you play with I2C, UART and GPIO! For sure - "so much better".
This is the worst approach ever devised. I just thought, what if everybody else in the ARM landscape will start to mimick this idiocy? It's very uncomfortable. I hope they won't do that, because otherwise, I have no will to even look at that crippled down thing.

SMM is supposed to be for controlling the nodes in a cluster. For example, it's the reason a supercomputer sysop doesn't need to walk to a node when it needs rebooting. However, it's so powerful, it can be used to make an OS believe there's a floppy disk drive attached over a normal PC interface when it's attached over USB. I'd be happy to see that functionality, but if it can do that, the scope of things it could do is quite frightening.

Also, if I haven't misunderstood, Intel have recently revealed there's a security vulnerability in SMM because they stupidly used Minix -- a research operating system which is neither stable nor intended to be secure -- in SMM hardware. You have to go back to Core 2 processors to get away from that. I think AMD did the same stupid thing, but can't remember properly. I'm a teeny bit happy almost all my potential OS-dev machines are Core 2 or non-386. (Can't exactly say non-Intel when one of them is Intel Freescale PXA-270. I doubt it has SMM, ARM SoCs aren't serious cluster material.)

It was Intel ME that has Minix right, not SMM? Or has Intel fused them?

zaval wrote:SDIO is NOT SD memory card interface. It's first. Second, - I don't see even SDIO in the list of accessible interfaces. It's a mode of operation of an SD controller, which doesn't seem to be accessible directly, normally.

First, SDIO is there in the list. Second, as normally, on RPi too you shouldn't access it directly, but through a controller.

zaval wrote:On a normal ARM machine, you have every peripheral accessible, and it's done a normal way. For example, you see (in the TRM) - we have 3 SD/MMC controllers, their bases are <bases>, here, their version compliance and capabilities are <blablabla>, see, it's their block scheme, SD controller is SDA HC compliant, so go read that

Please zaval, read the documentation. https://github.com/raspberrypi/document ... s/1888662/, page 65. It starts with:

It is compliant with the following standards:
* SD Host Controller Standard Specification Version 3.0 Draft 1.0
* SDIO card specification version 3.0
* SD Memory Card Specification Draft version 3.0
* SD Memory Card Security Specification version 1.01
* MMC Specification version 3.31,4.2 and 4.4

For detailed information about the EMMC internals please refer to the Arasan document SD3.0_Host_AHB_eMMC4.4_Userguide_ver5.9_jan11_10.pdf but make sure to read the following chapter which lists the changes made to Arasan IP.

On page 66, in section "Registers":

The EMMC register base address is 0x7E300000.

And the page continues with the detailed block scheme in a table, called EMMC Address Map.

Anything else? Everything you asked for is in the documentation. Can you conclude finally that Raspberry Pi is a normal ARM machine, please? There's no point in saying it is not.

Cheers,
bzt

thomtl wrote:It was Intel ME that has Minix right, not SMM? Or has Intel fused them?

Probably, I get confused.

Anything else? Everything you asked for is in the documentation. Can you conclude finally that Raspberry Pi is a normal ARM machine, please? There's no point in saying it is not.

Absolutely not! Looking at the "documentation", only strengthened me in my opinion on what Broadcom SoCs for RPi are.

Yes, I missed the emmc part in the documentation, since I first looked at the list of peripherals in the introduction, that broadcom decided to expose to ARM and there was no SD/MMC. So, since it wasn't in the list, I didn't search any farther. My bad. But does it really change much? Okay, you can program the SD controller, given that Arasan document is sufficient. But that doesn't change the fact of missing other important peripherals. You can do UART - nice, printing first output. You can implement storage stack - cool! What's next? Right, you would want to run your fancy font renderer as part of the console subsystem. Tell me, will you be able to reach to the display hardware? Not GPU acceleration stuff, just to the HDMI transmitter? Next, USB, I see even fans acknowledge USB isn't nearly described. Even though is exposed to ARM. You know, the very fact we talk about "being exposed to ARM or not" is already a sufficient reason to not count RPi an ARM machine. Face it, this is a VC computer with an ARM MCU with the restricted access to the SoC modules and if that is not enough - yet very poorly documented. Clock control, reset control, power management? Is it possible on RPi? temperature sensors maybe? so, combined with ability to setup system PLLs, you'd able to throttle your RPi down, should it overheat. See, even if these cool things are available through the asking VC to do that, it's not teaching you how it works everywhere.
Again, just go at the NXP or TI site and download a TRM on any of their SoC. And you'll see what the real documentation looks like. For the reference: TRM on i.MX 6DualPlus/6QuadPlus has 5891 pages, and cosists of 72 chapters and 2 appendices. Finally, if you want to have a real ARM SBC, just pick any of the sea of ARM SBCs, but that with a raspberry logo on it. and you'll not miss. Many people, willing to "play" with an ARM SBC, stick up with RPi because of good support and community. It's not much relevant to hobby OS developers, but the awkward architecture of it is very much against them - you won't learn how to program an ARM computer with a VC board.

zaval wrote:

Yes, I missed the emmc part in the documentation, since I first looked at the list of peripherals in the introduction, that broadcom decided to expose to ARM and there was no SD/MMC. So, since it wasn't in the list, I didn't search any farther.

A nice summary of your research methodology.

Most of your complaints about the Pi have now been shown to be examples of not RTFM.

iansjack wrote:

zaval wrote: Yes, I missed the emmc part in the documentation, since I first looked at the list of peripherals in the introduction, that broadcom decided to expose to ARM and there was no SD/MMC. So, since it wasn't in the list, I didn't search any farther.

A nice summary of your research methodology.

Most of your complaints about the Pi have now been shown to be examples of not RTFM.

See, I am not arguing for the sake of arguing and not of that type, who never acknowledges own mistakes. The above is an example. I keep insisting, because of the only thing - even with the missed by me SD part, RPi mostly is not documented, and thus - is a very poor choice for the osdev because of the latter and because of the awkward architecture. It's obvious. maybe not for bzt, but he also thinks, that other SBCs are "ripoffs" of RPi. so. What I don't understand is why you and bzt are so persistent with your attempts to prove things, that don't exist. There is no normal documenation for the osdev for any RPi and there is no any for RPi 4. You cannot seriously think, that 204 pages are equally informative and sufficient, when for others, of the same class, - thousands of pages are needed.
If you want to believe, it's possible to write your own OS for RPi, without brain damaging crawling through linux code, fine. I would be glad to know how you accomplished that, there is now a very appropriate thread for this, so if you or bzt would be that kind to share your experience, that would be fantastic.
Honestly, most ARM SoC aren't brilliantly documented. (I mean Allwinner, Rockchip, Amlogic). I told that already. Broadcom is one of the worst and I don't understand why you try to prove that it's not when it's obvious.