Initial code release of Orion O6

#1

As promised during our product announcement event, we are now uploading the first public code release for Orion O6.

The code is currently available under https://gitlab.com/cix-linux/.

Here is the known issues as reported by CIX for this release:

Base on Radxa O6 board v1.2, below are known issue, will be fixed in 202503 Monthly release:
⚫ totern and chromium playback simultaneously, totern playback has probability stop at rewind;
⚫ ISO install Debian, apt install smplayer, then open smplayer, can’t play the media;
⚫ ISP: user Gstreamer command line capture photo, short horizontal lines in the photo;
⚫ GPU Performance gap(15%) between different DisplayPort (DP) ports when using glmark2-es2-
wayland.
⚫ Suggest use C1 as display output for better graphics performance.

However, due to our agreement with CIX regarding binary distribution, some repositories and binary assets are omitted, until we can get confirmation with them.

Additionally, the currently released code is NOT the code that actually used by us. This is only an unmodified vendor SDK. We will start upgrading our code base to target this release next week. Stay tuned.

8 Likes
How to get the linux kernel source of Orion O6?
#2
#3

Nice, thanks
is @radxa moving to gitlab for cixin work?

#4

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
#5

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?

#6

I looked at EDK2 sources. What are your plans when it comes to upstreaming it?

#7

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
#8

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
#9

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)
#10

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
#11

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
#12

You probably built the BIOS for one of CIX’s EVB (Merek). Check the product name in the BIOS Setup.

1 Like
#13

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 :wink:

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.

#14

You don’t have to use the external programmer though. Check our BIOS installation guide. The output are in the Build directory.

1 Like
#15

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 :wink:

1 Like