Nice, thanks
is @radxa moving to gitlab for cixin work?
Initial code release of Orion O6
I think we will stick with GitHub. GitLab is only for SDK dump.
GitLab is pretty hostile to users from China. They will close accounts if they believe you are from China to push you to their Chinese partner, which has turned off the free tier entirely. The international version also introduced member limits before, which we were negatively impacted when we have one such group to communicate with our customer. The overall experience is pretty bad. I can not recommend their product anymore.
3 Likes
Thanks for explanation, this was silly question because yet another thing is published in yet another place,
As far as I remember gitlab is open source, so it may be just better to host it on private/company resources?
I looked at EDK2 sources. What are your plans when it comes to upstreaming it?
GitHub can already satisfy all our needs sans the subgroup, which is very popular with Google’s repo tool and why vendor SDKs are uploaded to GitLab (I hate manifests and repo). Self hosting a public service is a lot of extra annoyances that not worth dealing with. We do have an internal GitLab instance though.
1 Like
And for once, a kernel that was added as patches on top of an official release, not a massive import as is too often seen. This will ease code manipulations and comparisons!
2 Likes
Would be nice to get which versions of tools your EDK2 build expects.
$ make orion-edk2-debug
PATH=$PWD/edk2/BaseTools/Bin/Linux-x86_64:$PWD/edk2/BaseTools/BinWrappers/PosixLike:$PATH \
WORKSPACE=$PWD \
GCC_AARCH64_PREFIX=aarch64-linux-gnu- \
PACKAGES_PATH=$WORKSPACE/edk2:$WORKSPACE/edk2-platforms:$WORKSPACE/edk2-non-osi \
build -n 0 -s -b DEBUG -a AARCH64 -t GCC5 \
-p edk2-platforms/Platform/Radxa/Orion/O6/O6.dsc
Fails with:
Building ... /home/marcin/devel/tmp/orion-c6/edk2/edk2-platforms/Platform/CIX/Sky1/Library/Acpi/CIX/AcpiMadtLibCIX/AcpiMadtLibCIX.inf [AARCH64]
/home/marcin/devel/tmp/orion-c6/edk2/Build/O6/DEBUG_GCC5/AARCH64/Platform/CIX/Sky1/Merak/ACPI/AcpiPlatfomTables/AcpiPlatfomTables/OUTPUT/./Ssdt.iiii 27: Package() {\_SB.HDA, \_SB.HDAC, 0},
Error 6084 - Object does not exist ^ (\_SB.HDA)
FWIW I could build the whole project on one of my machines here under ubuntu 22. I noticed in their build script that they expected specific paths and I moved my dirs under the same paths to avoid trouble, so I installed precisely like this under /tmp/cix/ here, and started ./build_and_package.sh :
edk2
edk2-non-osi
edk2-platforms
tools/acpica
tools/gcc/gcc-arm-10.2-2020.11-x86_64-aarch64-none-elf/
It ended like this:
Package flash binary successful, it name was:
cix_flash_all.bin
====================================================
./cix_package_tool -c spi_flash_config_ota.json -O cix_flash_ota.bin
====================================================
Package flash binary for OTA successful, it name was:
cix_flash_ota.bin
====================================================
/tmp/cix
Generate /tmp/cix/output/cix_flash_all.bin successful!
willy@x260:cix$ echo $?
0
I have not yet tried to change anything there. I’ll first flash this image and verify that it works and is up to date!
2 Likes
I could flash and boot with this image. A few points worth mentioning:
The flash is 1.8V!!! Be super careful, I flashed mine using my ch341a programmer because I didn’t even know that 1.8V devices existed. It spitted errors during verification. And I had the reflex to test twice, noticing the errors were not at the same place. That’s when I noticed that the device is a 25Q64JW and that I found in the datasheet that it’s 1.8V… Oops! I flashed another one instead, a 25Q64FV (3.3V), but it did not boot, so the board definitely wants an 1.8V device. Finally I tried to boot from the flashed device, to see, and it happened to work, so I was lucky this time. I’m going to change the voltage regulator on my ch341a because the flash might not necessarily like this joke many times.
The new BIOS has an extra menu, “CIX system manager” where a lot of settings are accessible. You can even selectively turn on/off any core (though that didn’t change anything for me). There’s a “boot core” that forced to “”, not sure if we’ll manage to fix the CPU numbering mess.
The RAM section confirms what I understood when looking at the code, which is that the CPU supports DRAM up to 6400 MT/s (hence the advertised “>100 GB/s”, but that’s only the SoC which is capable of this, not the board since Orion O6 uses LPDDR5-5500, hence 88 GB/s).
In the “CIX system manager” menu, the console is polluted by I2C errors every second. I guess the bios tries to display the fan speed, a temperature or any such a thing and fails for whatever reason.
Other than that, the board booted fine on Linux, with all the memory available and PCIe devices still there. CPU frequencies and DRAM speed are unchanged.
Edit: I found this programmer that I’ve just ordered, it lets you select between 1.8/2.5/3.3/5V: https://www.aliexpress.com/item/1005004452694448.html
2 Likes
You probably built the BIOS for one of CIX’s EVB (Merek). Check the product name in the BIOS Setup.
1 Like
Good catch! It’s indeed called Merak in the Build directory. I did not notice any mention of this one to be changed in the build_and_package.sh, but now I’m seeing it under UEFI_PROJECT, it needs to be set to “O6” instead. I’ve restarted the build and will check, thanks!
Edit: apparently my flash doesn’t like much to be programmed anymore, probably the effect of having been programmed at 3.3V the first time. I’ve ordered a bunch of 10 new ones that should arrive next week. I just don’t want to risk to reprogram the original one 
Edit2: I finally managed to flash it after insisting and confirm that by setting UEFI_PROJECT to “O6” in the script, I reproduced the original flash. Not sure which parts are blobs and which ones are really built from sources though.
You don’t have to use the external programmer though. Check our BIOS installation guide. The output are in the Build directory.
1 Like
Yes I noticed that it was also supposed to be possible using the on-board flashing tools. I just did it this way because I didn’t want to risk losing the working flash, then kept doing it this way. Anyway I’ll feel better with a more configurable programmer and with extra flashes
1 Like
Any plans to bring 6.1 kernel branch to the latest state?
Kernel.org lists 6.1.129 at the moment. So Orion’s kernel is 85 revisions behind…
SoC vendors usually have lengthy verification process, so they cannot keep up with the weekly Linux release.
1 Like
Given that their kernel really is a patchset applied on top of official 6.1, it would be worth trying a rebase. It might very well work out of the box with little conflicts. It’s much easier with such clean kernels than when they’re distributed as a massive import with no shared ancestry.
3 Likes
I had a quick look myself, it’s a fair amount of work, quite a few merge conflicts. Not the worst i’ve seen but still enough of a hassle that I gave up for now, it is 85 more version updates afterall 6.1 is sitting at .129 vs .44
If there are many, sometimes it’s easier to automate an incremental rebase on each and every intermediary version. The number of conflicts will remain roughly the same, some will be automatically resolved and others will have to be handled twice. But in any case the contextual diff between before and after will only span over a single commit at once, which does help figure out how to arrange it. The really annoying part is that it can take sufficiently long a time that you don’t want to stay in front of your terminal waiting for the next conflict :-/ I did this to rebase the rockchip 5.10 kernel, that wasn’t the funniest thing to do honnestly.
1 Like
I’ve had a look at the DRAM chips on my board, they’re H58G56AK6BX069, which according to Hynix’s site are actually 6400 MT/s chips. Thus the board should really support that and can claim the >100GB/s, i.e. 16% speed increase above the current one.
Edit: to finally complete that point, I ran measurements showing that the RAM clearly runs at 4266 MT/s instead, I moved the discussion there to avoid polluting this thread.
1 Like
I’ve used git-imerge with some good results for LLVM.
1 Like