Finishing vanilla kernel support for H3?

[tkaiser]

Hi all,

 

since we're currently collecting tasks to be done by community to get a nice board (OPi Plus 2E) in return I thought I sum up where we currently are regarding working H3 OS images with mainline kernel:

 

Our main showstoppers for releasing H3 images with mainline kernel are still: missing/non-working THS stuff (see explanation here), native Ethernet driver not finished and a few minor bits.

 

My last attempt to check situation has been a few days ago. Since megi rebased his THS stuff (also containing the various USB and Ethernet patches) I chose his 4.6 branch to give it a try (see commit 224550b). Unfortunately I ran into kernel panics when testing on my OPi PC Plus and so I gave up again.

 

But since we got another report (see below, issue #360) trying out the stuff on both OPi One and PC and reporting different/interesting results in the meantime I believe this THS stuff should be solveable quite easily and it's just one missing bit here or there. So this would be a great opportunity for someone claiming a task to finish:

 

Get kernel 4.6 (or even better 4.7-rc) up and running including the following:

• Ethernet (required)
• USB, leds, serial and so on (required and works already since this is just .dts stuff)
• THS (required -- please also see issue #360))
• WiFi (nice to have but then please both 8189ETV/8189FTV -- both patches for our legacy kernel are backported from mainline versions so it should be rather simple)
• HDMI (nice to have)
• SPI, I2C (nice to have, IIRC @martinayotte has everything up and running with 4.x already?)

Anyone?

 

Edit: THS update: http://irclog.whitequark.org/linux-sunxi/2016-06-13#16729515;

[martinayotte]

 

SPI, I2C (nice to have, IIRC @martinayotte has everything up and running with 4.x already?)

 

Hi @tkaiser,

 

Unfortunately, this task isn't finished ...

First, all my patches have been submitted to linux-sunxi mainline almost 3 months ago and nothing is merged yet.

Several reasons lead to that : patches format, email issues, email headers corrupted, this last one is been solved/workarounded recently : Maxime Ripard told me that my tests using "git send-email" worked but earlier tests with "msmtp" didn't. I should now resend my patches soon as "v5"...

Then, still the goal of the patches : kernel gurus which to avoid to beef up DTS, want to keep them as little as possible, claiming it take time to parse it (ridiculous statement here since we are not using 8bits MCU), and peripherals such I2C/SPI should not be enabled on all boards by default, stealing GPIOs (well, there so much GPIOs, is that really important to save them ?). @Wens suggested me strongly to go with overlays like C.H.I.P guys did.

So, this is a new task for me : getting familiar with Dynamic Overlays loaded from UserSpace !

I will have to study that , recompile new kernel of the OF flag, tests, overlay prototypes, etc.

I hope to met expectation, especially that "time is the missing ingredient" !

 

Ciao !

[tkaiser]

Then, still the goal of the patches : kernel gurus which to avoid to beef up DTS, want to keep them as little as possible, claiming it take time to parse it (ridiculous statement here since we are not using 8bits MCU), and peripherals such I2C/SPI should not be enabled on all boards by default, stealing GPIOs

 

While I understand some of their points I also think it might be desirable if we at Armbian start to maintain an own set of device tree files just like we now do with fex files: https://github.com/igorpecovnik/lib/tree/master/config/fex

 

Currently if anyone switches from legacy to vanilla kernel all the stuff SBCs are about isn't working any more (since SPI, UART, I2C is missing due to no device tree nodes in default .dtb). Patching this stuff in is time consuming since after every upstream change our patches have to be adjusted. So why not maintaining a set of working .dts ourselves?

[zador.blood.stained]

While I understand some of their points I also think it might be desirable if we at Armbian start to maintain an own set of device tree files just like we now do with fex files: https://github.com/igorpecovnik/lib/tree/master/config/fex

 

Currently if anyone switches from legacy to vanilla kernel all the stuff SBCs are about isn't working any more (since SPI, UART, I2C is missing due to no device tree nodes in default .dtb). Patching this stuff in is time consuming since after every upstream change our patches have to be adjusted. So why not maintaining a set of working .dts ourselves?

 

Two problems:

• We can't decide for the user if he needs more GPIOs (default) or more interfaces, so we need to provide full environment for easy updating DTB files
• Compared to .fex files, DT configuration  is updated with the kernel, so if user wants custom configuration, he has to either hold on to specific kernel version or he has to edit DT after each major kernel update.

[tkaiser]

 

Two problems:

• We can't decide for the user if he needs more GPIOs (default) or more interfaces, so we need to provide full environment for easy updating DTB files
• Compared to .fex files, DT configuration  is updated with the kernel, so if user wants custom configuration, he has to either hold on to specific kernel version or he has to edit DT after each major kernel update.

 

Ok, mostly understood. So it's really not that easy and means 'typical SBC useage' on boards with RPi style GPIO header makes less fun with mainline kernel (since the stuff on the GPIO header won't work as supposed to)

[martinayotte]

I think there should be some trade-offs somehow. That maybe why Wens suggested me to look at the "dynamic overlays" path, where basic pins will be present in mainline DT, but not activated a special peripherals until some overlays would be loaded.

[zador.blood.stained]

DT overlays is a great feature, but it's not present in mainline (and probably won't be available this year).

 

AFAIK there are 2 possible implementations:

• One used on RPi boards - DT overlays are applied by proprietary bootloader before loading the kernel. I must say that basic DT modifications can be done in mainline u-boot (like adding status = "okay" to a node), but this won't help in more complicated scenarios.
• If I remember correctly, BeagleBone kernel is using "dynamic" DT modification to the kernel - this way it's possible to modify DeviceTree at any time to add new device nodes. This requires adding DT modification event handlers to EVERY driver that reads data from DT... so this won't be an easy thing to implement.

[martinayotte]

DT overlays is a great feature, but it's not present in mainline (and probably won't be available this year).

But why Wens was telling me that C.H.I.P is already using it with Mainline ?

Also Beaglebone is using overlays since awhile, my current kernel on it is beaglebone 4.4.9+.

Samething about RaspeberryPi which is using overlays since awhile, my current kernel on it is raspberrypi 4.4.11+.

 

From my early studies in both RaspberryPi and BeagleBone, Nope, the DT overlays isn't loaded by the bootloader, only the plain DTB is loaded at that time.

Then, when kernel is started completely, there is a service that simply copy overlays defines in a conf file to be copied into something like /sys/bus/platform/devices/bone_capemgr in case of BeagleBone (I don't remember my recent foundings). Same kind apply to RaspberryPi although I don't remember details. The EndUser can also load new overlays/"capes" from command line at the time he wish just before running a software that actually use those "capes"/i2c/spi peripherals.

My next goal is to compile some OrangePi kernel is this flag CONFIG_OF_OVERLAY and see if I can start to upload "dynamic overlays" from UserSpace. If this succeed, then, lot of maintenance tasks, but it will be the way to go, like other boards such RaspberryPi, BeagleBone or C.H.I.P (like Wens emphasised as an example)

[zador.blood.stained]

But why Wens was telling me that C.H.I.P is already using it with Mainline ?

Also Beaglebone is using overlays since awhile, my current kernel on it is beaglebone 4.4.9+.

Both C.H.I.P. and beaglebone have their own kernel trees (Raspberry Pi too)

 

Samething about RaspeberryPi which is using overlays since awhile, my current kernel on it is raspberrypi 4.4.11+.

I have a Raspberry Pi too, and I'm sure that its overlays (those that are activated by "dtoverlay" and modified by "dtparam" in config.txt) are managed by bootloader. Please check Part 3 of this: https://www.raspberrypi.org/documentation/configuration/device-tree.md

 

So this is not "Dynamic DT" exactly, this is boot time modificactions only.

[martinayotte]

Yes, I've already looked at that document.

So, it is maybe question of wording between real "DT overlays" (as you've said, where each drivers will get notified of DT changes) against "DT params changes".

At least, if we could get a few steps in that direction, it would be already a nice to have.

[martinayotte]

Unfortunately, I don't see much comments about my recent works ...

 

http://forum.armbian.com/index.php/topic/1633-dynamic-device-tree-overlays/

http://forum.armbian.com/index.php/topic/1537-397-maintainfix-dts-entries-for-some-devices-such-i2cspiw1/

 

Did someone has chances to give it try or I'm the only one using it to load overlays ?

 

As asked in the PRs (which didn't have much comments either, even if officially merged), where should Armbian image should provide DT overlays samples ?

Should it be a bit like BeagleBone locating them somewhere like /lib/firmware/overlays ?

(I've now having some overlays ready such i2c-enable.dtbo, spi-enable.dtbo and w1-gpio-overlay.dtbo. Others such mcp-enable.dtbo, gpio-keys.dtbo and matrix-keypad.dts could be added soon if well tested.)

[zador.blood.stained]

Unfortunately, I don't see much comments about my recent works ...

For example I'm waiting for mainlined USB (kernel 4.8), final version of Ethernet driver (AFAIK v3 is not final yet) and THS to look more closely at mainline kernel on H3 devices

 

Did someone has chances to give it try or I'm the only one using it to load overlays ?

 

As asked in the PRs (which didn't have much comments either, even if officially merged), where should Armbian image should provide DT overlays samples ?

Should it be a bit like BeagleBone locating them somewhere like /lib/firmware/overlays ?

(I've now having some overlays ready such i2c-enable.dtbo, spi-enable.dtbo and w1-gpio-overlay.dtbo. Others such mcp-enable.dtbo, gpio-keys.dtbo and matrix-keypad.dts could be added soon if well tested.)

I'll search for not soldered chips with SPI or I2C interfaces to test some overlays later (maybe after finalizing packaging/desktop modification process)

 

IMO overlays should be stored somewhere in bin subdirectory of build tools and then packaged in board support package, /lib/firmware/overlays is a good directory to put them.

[martinayotte]

Thanks Zador for your feedback !

I'm not fluent with the whole build process, so I will have to figure out how to get those overlays sample copied from /bin to /lib/firmware/overlays of the final image.

 

BTW, today, I've decided to revamp my OlinuXinoA20-Micro with full image. I saw that patching mechanism used /patch/kernel/sunxi-* instead of /patch/kernel/sun8i-* for H3 didn't bring by patches, so I will have to port my Dynamic DT Overlays patches for that target too. It should be trivial, I hope so, I will see tomorrow ...

[martinayotte]

I've done a PR for applying those Dynamic DT Overlays patches into "sunxi-next".

Next thing to do is to apply it also into "sunxi-dev".

 

EDIT : "sunxi-dev" done ! it was a bit more work since part of the patches were not required anymore in 4.8.x

[gompa]

i know this is a old post but iam trying to get mainline running on the orange pi one, and it crashes with the default orangepione uboot config, (i think its mem corruption) when using the config from the nanopineo it works fine: 

+CONFIG_DRAM_CLK=408
+CONFIG_DRAM_ZQ=3881979
+CONFIG_DRAM_ODT_EN=y

the orangepi one crashes with : 

 

-CONFIG_DRAM_CLK=672
+CONFIG_DRAM_CLK=624
 CONFIG_DRAM_ZQ=3881979
 CONFIG_DRAM_ODT_EN=y

is this the same config as uboot in the legacy kernel ? : 

 

 

 

edit:

 

oh this doesnt seem to be the problem when using the nanopineo config en changing dram speed to 624 it works fine

but the default orange pi one config crashes with a kernel panic (ill boot a image later to post the error)

 

 

ps thanks for this wonderful project 

[tkaiser]

is this the same config as uboot in the legacy kernel ? 

 

No idea, the DRAM values upstream u-boot uses for various H3 devices seem to be random. In case you're not using our build system please have in mind that we use this patch here: https://github.com/igorpecovnik/lib/blob/master/patch/u-boot/u-boot-dev/u-boot-set-safe-axi_apb-clock-dividers.patch(necessary to get the THS / dvfs stuff working)

[cbbc_curry]

I followed your steps to patch kernel 4.9 here: http://moinejf.free.fr/opi2/(because i want hdmi can work on my OPI with mainline kernel). After pached, when I compile kernel 4.9, it was failed. It said can`t find "sunxi-hdmi.h"!  Could you help me?

[René Kliment]

Hey. Are patches from OndÅ™ej Jirman's repo applied in the beta images? I've looked in the Armbian repo and I don't see them there. I've spoken to Josef Gajdusek and he said that he hasn't made any progress from the v2 on the mailing list and that OndÅ™ej took that up - some patches based on the v2 have been sent to the mailing-list in June this year.