OSDev.org

Ok, since the work tonight is not working out, I've finally decided to write some short "announce" here. It's not really an announce, since there are no samples of the project doing much yet, but the code can already run on the hardware in question (mips machine) and it slowly is getting more functionality, so I put this topic, so that I will have a place to report progress or something, have answers and questions (probably), take advices, even overly lengthy. anything related.

It's a sub-project of my OS project and it's about creating a UEFI compliant implementation for a couple of arm and mips boards.
it's not based on Tianocore. I am creating it for educational purposes, to learn and test myself on ability to program HW. And, maybe it would be useful for others for the same reasons or even for the direct usage as a FW.

The target boards chosen are:
Mips Creator CI20 - mips32r2
Beagle Bone Black - armv7 (aarch32)
Cubieboard 2 - armv7 (aarch32)
Pine64+ - armv8 (aarch64)
Some settop box with RK3368 - armv8 (aarch64)

Only mips32 and aarch32 are somewhat touched by the project so far, aarch64 is not yet.
The project informally is called U3 as a shortening of uefi.upptech.ua - where "upptech" is a non-registered "organization" consisting of me as a developer. The OS is called ANT (and finally, its POSIX environment subsystem is called PussyX as my signature shows).

The implementation has its main goal as to be a UEFI-conformant firmware for a few SBC. Those don't have it yet. So, there is a practical goal too, to bring UEFI support into the (mostly arm) SBC landscape.
It does follow the PI spec as well, but it's not a strict requirement, it's an internal implementation thing anyway, UEFI is the standard implemented. So for example it is split up into PI defined phases:

- SEC ("teh security", taking control of ROM code, a very basic initialization in fact)
- PEI (pre Efi init - SDRAM init mostly)
- DXE (driver execution environment, everything goes here, it's a UEFI "kernel", exactly it supplies UEFI Services for example)
- BDS (boot device selection, UEFI Boot Manager, dealing with boot policies, boot options, interaction with user)

we kind of follow this. But the Pei phase is omitted on the mips target. And will be omitted on armv7 targets too. There are reasons for this - it avoids unnecessary duplication between Dxe and Pei. We put Pei's responsibilty of inintializing SDRAM on the Sec blob, and everything else is done by Dxe. You will not be wondered to hear, that some EDK targets also omit the Pei phase. It doesn't look sane to do this split (between Pei and Dxe) on SoC based designs. Pei foundation has a very similar tasks and organization to the Dxe counterpart, still it differs and results in duplication. I mean PPI vs Protocols, PPI database vs Handle Table, PEIMs dispatching vs DXE drivers dispatching. Basically Pei has been invented as a little Dxe, for platforms where it's needed. Or for additional solidity, some other reasons. SoC based machines clearly will be happy with this phase fusion.

Mostly we are at the Sec stage. Some portions of UEFI services are written as well, but not tested yet. Handle table database (with protocols of course) organization is designed.
The Sec blob, SEC.SYS is written entirely in assembly - I said I want to learn HW programming. It's a format-less binary which is put where the ROM code expects it to be, for the SD card boot scenario (that we are using now), it's right after an MBR sector. Fortunately, the first partition lies so far away from this area, we can easily fit our entire FW into this spare area, not messing up with partitions. But this scenario is a beginning one. We need more permanent storage where it's present (not always it's the case on the SBC landscape, examples - Pine64+, our aarch64 target, Raspberry Pi, they don't have eMMC or NAND storages, only SD card slots) to store our FW. So with the progress, we migrate to NAND for the CI20 target.
Our SEC gets loaded by the ROM code into TCSM - tightly coupled shared memory, a SRAM area with only 14 KB of available space (this limitation was an initial reason we offcast the PEI phase).
So far SEC.SYS only can print into UART, starts PLLs and configures clocks for the CPU, L2 cache, AHB0 and AHB2 buses and for PCLK - peripheral clock, also it initializes the OS Timer. It plays with the LED, and has some support routines for printing.
Now we need to finally initialize SDRAM. Then configure SD controller and read our Dxe.exe PE file into SDRAM and load it as an executable. Then create HOB-list (jack off, sorry, - hand off blocks - needed for memory representation for Dxe) and jump to DxeEntryPoint(). Later, when we figure out what the security it really needs, we add it here, so far, practically, it's a fancy 1st stage bootloader for the rest of FW, if you want, but with an SDRAM initialization bonus inside.

minor fix. now the OS timer counts up. and everything is ready for starting the SDRAM init process. which is hard but not very learning and informative, not very giving you an experience. because you just reproduce what you've seen in u-boot, and they reproduced what they saw in Ingenic's BSP. Because the process is not documented well. So you are forced to act as a code monkey. :^/
Anyways, we tried to get an idea what things are for as much as we could.
we chose BASE 0x00, and MASK 0x80. Those are related to the most significant byte of SDRAM bus address (physical address) by the formula:
BUS_ADDR[31-24] & MASK == BASE
Given we have 1GB of SDRAM, with such a configuration we will have 2 subspaces of aliases - the lower 0x00000000-0x3fffffff and the higher 0x40000000-7fffffff pointing to the same SDRAM locations. Using the higher part, we hope to overcome the reserved (for I/O particularly) range 0x10000000-0x1fffffff. Hopefully, it's yet to be figured out, because again, the manual is sooo unclear (it's a censored version of its characteristic).
For example in a drawing it shows an arrow from address 0 pointing to the 0x20000000... What this means? That these (256MB in size) ranges are aliases too? But they couldn't be those, with the above configuration, which in turn is OK according to the DDRC part of the manual. Will I end up with space folding (overlapping) with this? Who knows, it will be needed to check this manually. Then again if 0x00 and 0x20 (in MSB) are aliases somehow, then will the pair 0x40-0x60 be aliases too? But wait, this way, we are losing 1/4 of address space for SDRAM! That's why there is no much enthusiasm to insert that (almost written) code and test it. *sigh*

I'll jump in with some Aarch64 code if you'd like. I'm planning to write some firmware myself

Cool. Are you working on UEFI implementation for aarch64?
Honestly, for now, I am fully get stuck into mips, can't say anything on aarch64 which I am interested in of course, but for future, I even have two boards with this architecture.
If you mean some cooperation, it's all possible and even desirable, probably, but for now I am not ready to participate in aarch64.

it's more of an initialization code (setting up acpi, pci, interrupts and so forward) but I imagine it'll be of great use for the aarch64 side of your uefi. You don't have to do any work, I'll just donate the code when im done with it

everybody loves (code) donations.
it was planned for this kind of development - providing a "framework" (UEFI Core (DXE+BDS), some build utilities, SDK, Tianocore shell ported) for UEFI implementations not covered by edk - low-end arm, mips. people then would add particular board support in it - supply board specific SEC bootstrap, Dxe drivers, basically adding new board support. but it's "ideally". so far it's just a mess. xD
of course, it would be nice to have others' effort incorporated, because it's unfeasible for 1 person - to do everything, anyway.)

i will follow your work, and i will possibly add a Dawn-compatible emulator to your code.

^_^ that's flattering. on my side, I hope there will be something to follow for interested.)