Support for OrangePI zero 3

[Paiusco]

I'm considering to buy an Orange PI Zero 3 to play around with Yocto. However, from what I understood it's not yet supported by the layer, am I wrong?

Do you guys plan to add basic support for it soon?

[nandra]

Sorry no support yet. Please see here: https://linux-sunxi.org/Xunlong_Orange_Pi_Zero3#BSP as there is still some parts missing. When it will be supported we can add support but someone must test as we're not owners of that board :). Thanks.

[Paiusco]

Thanks @nandra, do you know more or less (ballpark) how long it takes for the support to be added from upstream? (1 month, 6 months, a year) I mean, if it doesn't take long... after upstream is done I can help to test :)

[nandra]

@Paiusco hard to say. I could be half a year maybe bit more ;).

[nandra]

If you want to experiement zero pi 2 is supported so maybe would be an option for you ;)

[electricworry]

When it will be supported we can add support but someone must test as we're not owners of that board.

I've got one and I'm happy to help as much as I can.

[electricworry]

I've started looking at this and I think I've got everything I need to start work on it. The build scripts provided will make it a lot easier (sourcing the correct dts files and patches, etc.)

Before I start spending time on it, can I query why meta-sunxi uses the mainline kernel and patches it instead of using the orangepi kernel fork at https://github.com/orangepi-xunlong/linux-orangepi which is used by OrangePiOS? Same question for U-Boot at https://github.com/orangepi-xunlong/u-boot-orangepi. Is that so that the layer isn't tied down to a vendor provided fork that might not be maintained, future compatibility, etc.?

[nandra]

meta-sunxi support allwinner board not only orangepi's thus we use mainline kernel/u-boot. We can add other kernel/u-boot provider for opi3 if necessary.

[electricworry]

Thanks for the explanation. That strategy makes sense, using the mainline kernel if possible. I'll proceed on that basis and see if I can get a working image.

[forky2]

Is this really completed or is it closed due to lack of pull request to improve it?

[nandra]

Not completed. Waiting for some pull request from @electricworry maybe ;)

[electricworry]

I've done a bit of work on it but I'm nowhere near done yet. Unfortunately I've had not had a lot of personal free time to work on this but my intention is to keep at it particularly as we head into winter. Made some headway with u-boot patches but not in a state to share yet.

[electricworry]

FYI, work on u-boot is in my meta-sunxi fork, and also a u-boot fork. I've started a conversation on the u-boot mailing list to help get this added to the next change window.

I'll update when the kernel work is done.

[nandra]

@electricworry thanks for an update! :+1:

[electricworry]

Making good progress. I've got kernel booting and I've got graphics working. Please could this issue be re-opened so that it's visible? I'll be asking some questions about best practices for patching and upstreaming changes and it would be good if more people see them.

[nandra]

@electricworry reopened. Feel free to ask ;). Good job BTW :+1:

[electricworry]

You can congratulate me when I've contributed some fixes. :) Thanks for reopening. Here's my progress:

• [x] Working u-boot for OrangePi Zero 3 (mainly support LPDDR4 memory among others)
• [x] Linux kernel patches against 6.1.31 (chosen as that's the closest to the vendor fork)
• [x] Fix blocking issue with thermal reporting incorrect high temperature and causing shutdown
• [ ] Fix u-boot boot.cmd partition selection
• [ ] Fix systemd / usrmerge issue
• [x] Fix /etc/fstab /boot issue
• [ ] Fix mesa graphics issue
• [ ] See if booting can be made faster
• [ ] Test
• [ ] Submit PR for review

I fully anticipate that there will be changes suggested to the patches; that's fine.

A couple of questions I have:

• I've had to add IMAGE_INSTALL:append = " kernel-modules" to my local.conf in order for kernel modules to be included. Ideally I'd like just the kernel modules that are required to be part of the machine config. Is that possible, and if so what's the incantation to do that in yocto?
• When it comes to rebase the patches against the newer kernel are there any best practices to make the work easier? My current thinking is that I need to devtool modify linux-mainline and manually apply patches and intervene whenever there's a merge conflict and then I make new patches from those resulting commits. Is there a better way?

[nandra]

Well kernel modules can be tricky I would suggest to add specific modules to machine config but not all of them, or maybe update config to include things in kernel not as modules.

Yes devtool is your friend when you want to rebase patches.

[electricworry]

Well kernel modules can be tricky I would suggest to add specific modules to machine config but not all of them, or maybe update config to include things in kernel not as modules.

Please could you elaborate? I'm not a yocto expert. For example, there's the kernel module sprdwl_ng which I need to include for networking. If I include the line MACHINE_EXTRA_RDEPENDS = "kernel-module-sprdwl_ng" to orange-pi-zero3.conf nothing happens. (i.e. the module isn't included in /lib/modules.)

If I further add MACHINE_EXTRA_RDEPENDS = "kernel-module-sprdwl_ng" to the same, then I get the following error:

Error: 
 Problem: package packagegroup-base-extended-1.0-r0.orange_pi_zero3 from oe-repo requires packagegroup-base, but none of the providers can be installed
  - package packagegroup-base-1.0-r0.orange_pi_zero3 from oe-repo requires packagegroup-machine-base, but none of the providers can be installed
  - conflicting requests
  - nothing provides kernel-module-sprdwl_ng needed by packagegroup-machine-base-1.0-r0.orange_pi_zero3 from oe-repo
(try to add '--skip-broken' to skip uninstallable packages)

I don't know the correct way to have it added by default.

[nandra]

I forgot that we already have in sunxi.inc MACHINE_EXTRA_RRECOMMENDS which will be added to image with packagegroup-machine-base.

[electricworry]

Ah, yes it does. But that doesn't get included by sun50i-h616, that uses sunxi64.inc instead. Anyway, I think you've pointed me in the right direction. If I modify my machine change to be the following then it does get added to the image:

MACHINE_EXTRA_RRECOMMENDS:append = " kernel-module-sprdwl-ng"

Now that I understand what the variables do I can see that the line I added before was completely broken; the package name was wrong and I wasn't doing an append. I'll add all of the packages that I think are required there. Will keep the image size down compared to adding kernel-modules (i.e. all of them) to MACHINE_EXTRA_RRECOMMENDS.

[electricworry]

I've managed to get a set of patches that allow the Orange Pi Zero 3 to work, and as soon as I've got all my ducks in a row I'll be happy to submit a PR. Depending on your responses below that could be hours instead of days. :smile:

One of the problems I'd like to discuss is that I've targetted 6.1.31; that made the most sense to me as that was the closest kernel version to the vendor's codebase. Are you willing to accept this into the layer, or would you have a hard requirement that it targets 6.5.% which all boards have been moved to? It will be a fair amount of work to update the patches and I don't think I've got time right now.

One side note on the targetted kernel version... Going back to the Zero 2 (not the Zero 3 that I'm working on). That's now targetting kernel 6.5.%. But doesn't that therefore mean that all of the patches for the Zero 2 (in recipes-kernel/linux/linux-mainline_6.1.9.bb) are now being discarded? Is that intentional? Because it seems to me that the vast majority of that stuff (in particular the wireless drivers) is not in the main kernel branch yet. It seems to me that the machine config for Zero 2 also needs to be pinned back to kernel 6.1.% until those patches are adapted for 6.5.% (which is the same problem I'm facing with the Zero 3).

[nandra]

@electricworry perfect work!

Yes I remember we have zero2 also on 6.1 kernel which is totally fine. I agree to have working board even without latest kernel. Later it can be updated to latest when most of stuff will be added to mainline. Looking forward to PR ;)

[electricworry]

Thanks. Incoming soon.

I think my point about the zero2 may have been missed; because recipes-kernel/linux/linux-mainline_6.5.11.bb has been added to the layer and there's nothing pinning the zero2 to version 6.1.% in the configuration, it builds against 6.5.11 (i.e. the latest) and doesn't incorporate any of the required patches. I've not got a zero2 handy to test, but I think the result will be a deficient build.

I think that the machine conf for the zero2 needs PREFERRED_VERSION_linux-mainline ?= "6.1.%" added so that it uses that version (plus the patches indicated for the board in recipes-kernel/linux/linux-mainline_6.1.9.bb). (Which is exactly what I'll be doing for the zero3.)

[nandra]

Yes I think you're right about zero2 but I think most of the stuff should be present in 6.5. I don't have a board so cannot try it, but will ask submitter to verify. And you're right for zero 3 you can force linux-mainline to 6.1 as you wrote. Thanks.

[electricworry]

This is my last question, I promise. Because I'm targetting 6.1.% I need to set the KERNEL_DEVICETREE to "allwinner/sun50i-h616-orangepi-zero3.dtb". (i.e. I need the vendor prefix). So that means that I would need to add back the custom task which was previously in sunxi64.inc, namely:

# arm64 dbts are under <vendor>/dts but is deployed under DEPLOYDIR 
do_fix_device_tree_location() {

    for kdt in ${KERNEL_DEVICETREE}
    do
        local dbt_dir=$(dirname ${kdt})
        if [ "." != "${dbt_dir}" ] ; then
            local dbt=$(basename ${kdt})
            local dst=${DEPLOY_DIR_IMAGE}/${dbt_dir}/${dbt}
            if [ ! -f ${dst} ] ; then
                mkdir -p ${DEPLOY_DIR_IMAGE}/$dbt_dir
                ln -s ${DEPLOY_DIR_IMAGE}/${dbt} ${dst}
            fi
        fi
    done
}

addtask do_fix_device_tree_location after do_write_wks_template before do_image_wic

I don't really understand what happened between kernel 6.1 and 6.5 to cause the change in behaviour, but if I need to add that back, how can I add it so it's just done for certain machines? Adding it back to sunxi64.inc for all 64-bit boards will surely break the builds of machines on the newer kernel?

[nandra]

I think this was used also for zero2 so also for kernel 6.1. Kernel 6.5 influence mainly arm32 dtbs where we need to add allwinner prefix but it's another story. Above method just symlink compiled dtb from allwinner/*.dtb to deploy dir if I'm not mistaken.

[electricworry]

That's right, that's all it does. I think what I'm trying to ask is how can I write task that will know to only run for a certain machine? I know how to override a task (e.g. I can have a task that only runs for a machine with an append: do_compile:append:orange-pi-zero3()) but I'm not sure how I would create a new task that only runs just for one machine. Does that make sense?

[nandra]

What would be the purpose of custom task? I don't get it :)

[electricworry]

Sorry I'm not explaining myself well. :) That snippet above... I need to add it back for the same reason it was required for other allwinner boards that were targetting 6.1.%. It's been removed now because the boards are targetting 6.5.% which doesn't need it. If I add it back, won't it cause problems for those boards? I trying to add it back in a selective way so that it's only used for the build for this particular board. (And it can be removed again if I manage to get the board working under 6.5.% in the future.)

[nandra]

It's not removed, it was moved to sunxi.inc cos now it's common for both platforms (32 and 64 bit). So feel free just add custom kernel and everything should work IIRC.

[electricworry]

I don't think that's true. sunxi.inc and sunxi64.inc seem to be mutually exclusive. sunxi.inc is included by 32-bit boards and sunxi64.inc is included by 64-bit boards. When conf/machine/include/sun50i-h616.inc (for example) includes sunxi64.inc it doesn't also get sunxi.inc.

[nandra]

Oh right, then I think I made a mistake here in this commit: c867cb74e2847599d973e1bccab28af90b8e0bac and needs to be fixed!

[electricworry]

That's ok. :smile: yocto layers are complicated and it can be hard for an outsider like me to know what's been done by intent and what might be a mistake. I can say that without sunxi64.inc having an explicit inclusion of sunxi.inc everything does work (except for the lack of that task do_fix_device_tree_location causing me a problem. If you could please consider whether sunx64.inc does need to include sunxi.inc or whether that task needs to be added back to sunxi64.inc and the two kept mutually exclusive, then I can retest and I'll have a PR to contribute.

Thanks very much for all of your time and help.

[electricworry]

@nandra I'll just add the snippet back into my fork until a decision is made. :smile: No rush; I don't want to mess up the good organisation of someone else's project and I'll wait before doing a PR.

@Paiusco Meanwhile do you want to check the fork I've made to see if it works for you? I've created a repository at https://github.com/electricworry/orangepizero3 which should work as a hello world test. What board have you got? I've got a 4GB one. If you could test and feedback it would be appreciated.

Testing steps:

git clone https://github.com/electricworry/orangepizero3.git
cd orangepizero3
git submodule update --init
. poky/oe-init-build-env
bitbake core-image-x11

Once complete you should have an image you can write with bmaptool for testing as follows:

sudo bmaptool copy ./tmp/deploy/images/orange-pi-zero3/core-image-x11-orange-pi-zero3.rootfs.wic.gz <your-sdcard>

Hopefully you should get x11 terminal and a prompt. I've got lots of work to do going forward (e.g. I don't think systemd works yet if added) so this isn't the end of it, but it's a good milestone if it works for others.

[nandra]

@electricworry added back stuff to sunxi64.inc

[Paiusco]

@electricworry Thanks for working on it, but I ended up postponing my purchase :) I'll get one next year probably

[electricworry]

@electricworry added back stuff to sunxi64.inc

Thank you. I've just got a bit more testing to do since I'm the only one doing it. Once I'm satisfied I'll submit a PR.

[electricworry]

Just wanted to update I'm making progress with graphics. Slowly. Feel free to chase me for updates if you'd like, but until I get that sorted I'm holding off on a PR. Please do keep this issue open if you don't mind it as I'll keep posting occasional updates.

[nandra]

@electricworry thanks for an update. NO worries I'll keep this issue open until you post some PR. Thanks for community support!

[electricworry]

I've finished the main work on the OrangePi Zero 3, but I should do some tidying on it before submitting a PR. Here's some updated instructions for anyone with the board that wants to test...

Testing steps:

git clone https://github.com/electricworry/orangepizero3.git
cd orangepizero3
git submodule update --init
. poky/oe-init-build-env
bitbake core-image-base

Once complete you should have an image you can write with bmaptool for testing as follows:

sudo bmaptool copy ./tmp/deploy/images/orange-pi-zero3/core-image-base-orange-pi-zero3.rootfs.wic.gz <your-sdcard>

Once booted, there will be a console on both serial and HDMI. If one is to run kmscube from either of these, then a spinning cube should be seen on HDMI using the panfrost Mali-G31 driver.

I should summarise what's been done:

• orange-pi-zero3 machine created
• u-boot patches from u-boot mailing list (working very well)
• kernel patches specifically for 6.1.31 taken from vendor kernel branch
• Panfrost graphics working
• Audio working
• Bluetooth, ethernet and wifi working

While pleased to have a working layer, I should also summarise the ugly things about my changes:

• The vendor kernel patches are not fit for upstream kernel and so until I or someone better improves them and submits them the board will be stuck on kernel 6.1.31
• I had to add aliases for mmc0 and mmc1 to DTB in order for SD card to always appear as mmc0
• I needed to create a startup service to get bluetooth working; this invokes a closed source binary hciattach_opi which appears to be a vendor fork of hciattach from bluez. It's not ideal and I've asked the vendor to provide the source. For now it's the only way unless I feel like reversing it at some point.

[kgilmer]

I was able to successfully boot into Poky using the steps in the above post by @electricworry. I have tested with a Orange Pi Zero 2W (4GB model), which is a different product than the Zero 3 but is very similar. After logging in as root I was able to see the rotating cube on a monitor attached over HDMI to the device when running kmscube. I was also able to use a USB network adapter, could ping an internet host. Happy to perform any specific testing steps it if helps.

[electricworry]

@kgilmer Sorry for my delayed response; I've been busy with other work. I'm very glad that you were able to get it working. I didn't realise that the Zero 2W was so similar.

I'm going to hold off making an official pull request until the dust has settled on the yocto scarthgap release which should be soon.

[nandra]

@electricworry I'm planning to push scarthgap branch soon ;)

[nandra]

See #405