Trying to add overlay support to sunxi "dev" build

[hanni76]

Hello guys

can you help me please understand your overlay compilation support  which is working in "next" build?

I transferred  required  patches and  made a build with 4.15. Now I have my dtbos and scr in place, added "overlays=" in armbianEnv.txt but my overlays are not loaded in run-time.

I noticed that you have the following condition around dtbos: 

 

ifeq ($(CONFIG_OF_CONFIGFS),y)

...

endif

 

and there is also a special patch to add configs module to build. 

My question: is configs module required for loading overlays ? I can't apply this patch into 4.15 as configfs.c is not compatible with new codebase. 

 

Here is my patches 

https://github.com/orpaltech/antenna-analyzer-armbian/blob/master/build/userpatches/kernel/sunxi-dev/Add-overlay-compilation-support.patch

https://github.com/orpaltech/antenna-analyzer-armbian/blob/master/build/userpatches/kernel/sunxi-dev/board_bananapim1plus/Add-sun7i-a20-overlays.patch

Thanks

 

[hanni76]

The issue still exists with sunxi-dev (kernel 4.15) and sun7i-a20. I've already verified all things that in my opinion might be a cause of the problem but I haven't found a solution yet. 

I've also found that the ability to load overlays in run-time does NOT depend on CONFIG_OF_CONFIGFS. I've tested this by switching off this functionality in sunxi-next build: my OrangePi PC  is still able to load overlays without configfs. 

I think I am going to do a printk-debug soon in overlay-related code.

[Igor]

17 minutes ago, hanni76 said:

The issue still exists with sunxi-dev (kernel 4.15) and sun7i-a20.

We have no plans to adjust those patches for anything > 4.14.y in next couple of months. As you can see there is currently a big mess with patches for NEXT and that has to be sorted before we can move further. I don't see a point to mess with this right now.

 

IMHO if you need some functionality from higher kernels, rather backport to 4.14.y since this will be the next LTS build. Also first stable build for H3/H6&A64 ... when we are that far.

[martinayotte]

4 hours ago, hanni76 said:

I've also found that the ability to load overlays in run-time does NOT depend on CONFIG_OF_CONFIGFS. I've tested this by switching off this functionality in sunxi-next build: my OrangePi PC  is still able to load overlays without configfs.

Without CONFIG_OF_CONFIGFS, you won't have the sysfs location /sys/kernel/config/device-tree/overlays, so you won't be able to load overlays AFTER the kernel has booted, but this doesn't prevent U-Boot been able to load some overlays BEFORE the kernel been booted.

 

[hanni76]

7 hours ago, Igor said:

We have no plans to adjust those patches for anything > 4.14.y in next couple of months. As you can see there is currently a big mess with patches for NEXT and that has to be sorted before we can move further. I don't see a point to mess with this right now.

 

IMHO if you need some functionality from higher kernels, rather backport to 4.14.y since this will be the next LTS build. Also first stable build for H3/H6&A64 ... when we are that far.

Thanks for reply

but I don't feel I can do a painless backport of drm display engine, it seems complex to me. 

 

2 hours ago, martinayotte said:

Without CONFIG_OF_CONFIGFS, you won't have the sysfs location /sys/kernel/config/device-tree/overlays, so you won't be able to load overlays AFTER the kernel has booted, but this doesn't prevent U-Boot been able to load some overlays BEFORE the kernel been booted.

 

Thanks, martinayotte

does this mean if I rewrite configs.c file for 14.5 (there shouldn't be too much work, as far as I can see) then overlays should start loading ? 

I wonder why it works WITHOUT configs in sunxi-next. This is my big question. I confirm again that it works. I mean I normally set  "overlays=bla bla" in armbianEnv.txt file and they load and work. with no configfs.c compiled!

 

wait... I have an idea.. maybe configfs is deployed from previous builds ? I don't think I did a specific cleanup there in addition to the mandatory cleanup which is done before every build.

 

ok, I see now. configs is compiled into kernel, it is not a module. that's why it is still in the kernel and overlays work

 

7 hours ago, Igor said:

We have no plans to adjust those patches for anything > 4.14.y in next couple of months. As you can see there is currently a big mess with patches for NEXT and that has to be sorted before we can move further. I don't see a point to mess with this right now.

 

IMHO if you need some functionality from higher kernels, rather backport to 4.14.y since this will be the next LTS build. Also first stable build for H3/H6&A64 ... when we are that far.

Yes, it makes sense. I'll see if I can do that.

But I am afraid that might be much more complicated task for me than analyzing your patches that I have directly on my hard drive. I can apply them 1 by 1 as soon as I need them.

[hanni76]

On 12/22/2017 at 4:32 PM, martinayotte said:

Without CONFIG_OF_CONFIGFS, you won't have the sysfs location /sys/kernel/config/device-tree/overlays, so you won't be able to load overlays AFTER the kernel has booted, but this doesn't prevent U-Boot been able to load some overlays BEFORE the kernel been booted.

 

 

Hi again,

I have recompiled sunxi-next with "add-configfs-overlay-for-v4.10.x.patch" disabled. My overlays are still working fine!

Any ideas? @Igor  @zador.blood.stained maybe someone else can remember how overlays are actually loaded in runtime and what patch do I need ??

 

I have maid more experiments (full cleanup & rebuild & check /sys/kernel/config/ directory) with the same results :  "sunxi-next" overlays are loaded WITHOUT configfs.

 

I am still digging into it yourself but any help will be very much appreciated!

 

@martinayotte I just found in your answer that it maybe u-boot which is loading overlays and configfs.c is not required to load overlay listed in armbianEnv.txt, correct ?

[martinayotte]

Right ! There are two ways to load overlays, one by u-boot, and the other one by sysfs.

 

[hanni76]

@martinayotteOk, now I see it.

I tested my overlays with configfs and they were accepted with no error. And so I'm assuming they are correct. I previously tried loading overlays compiled without -@ option and they failed to load by configfs.

 

Let me ask you one more question: do you have any assumptions why valid overlays are not loaded by u-boot in "sunxi-dev" build ?

The "sunxi-dev" is using the same u-boot 2017.11 as "sunxi-next" with full list of patches. Why shouldn't it load my VALID overlays ?? Can this somewhat depend on patches applied to the kernel itself ?

[martinayotte]

  -@, --symbols              
	Enable symbols/fixup support

Did you tried your -@ version with u-boot or was it the one without symbols ?

I presume that is the reason.

 

[hanni76]

@martinayotte I tried dtc -@.

 

Here is my u-boot log

 

U-Boot SPL 2017.11-armbian (Dec 24 2017 - 21:10:46)
DRAM: 1024 MiB
CPU: 912000000Hz, AXI/AHB/APB: 3/2/2
Trying to boot from MMC1

U-Boot 2017.11-armbian (Dec 24 2017 - 21:10:46 +0300) Allwinner Technology

CPU:   Allwinner A20 (SUN7I)
Model: Banana Pi BPI-M1-Plus
I2C:   ready
DRAM:  1 GiB
MMC:   SUNXI SD/MMC: 0
*** Warning - bad CRC, using default environment

Setting up a 720x576i composite-pal console (overscan 32x20)
In:    serial
Out:   vga
Err:   vga
SCSI:  SATA link 0 timeout.
AHCI 0001.0100 32 slots 1 ports 3 Gbps 0x1 impl SATA mode
flags: ncq stag pm led clo only pmp pio slum part ccc apst 
Net:   eth0: ethernet@01c50000
230454 bytes read in 155 ms (1.4 MiB/s)
starting USB...
USB0:   USB EHCI 1.00
USB1:   USB OHCI 1.0
USB2:   USB EHCI 1.00
USB3:   USB OHCI 1.0
scanning bus 0 for devices... 1 USB Device(s) found
scanning bus 2 for devices... 1 USB Device(s) found
       scanning usb for storage devices... 0 Storage Device(s) found
Autoboot in 1 seconds, press <Space> to stop
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found U-Boot script /boot/boot.scr
3708 bytes read in 213 ms (16.6 KiB/s)
## Executing script at 43100000
U-boot loaded from SD
Boot script loaded from mmc
271 bytes read in 173 ms (1000 Bytes/s)
5264196 bytes read in 574 ms (8.7 MiB/s)
7193216 bytes read in 698 ms (9.8 MiB/s)
Found mainline kernel configuration
39675 bytes read in 458 ms (84 KiB/s)
573 bytes read in 1331 ms (0 Bytes/s)
Applying kernel provided DT overlay sun7i-a20-spi0.dtbo
1057 bytes read in 1358 ms (0 Bytes/s)
Applying kernel provided DT overlay sun7i-a20-spidev.dtbo
267 bytes read in 1202 ms (0 Bytes/s)
Applying kernel provided DT overlay sun7i-a20-brcmf.dtbo
269 bytes read in 1282 ms (0 Bytes/s)
Applying kernel provided DT overlay sun7i-a20-ir-off.dtbo
5450 bytes read in 1224 ms (3.9 KiB/s)
Applying kernel provided DT fixup script (sun7i-a20-fixup.scr)
## Executing script at 44000000
## Loading init Ramdisk from Legacy Image at 43300000 ...
   Image Name:   uInitrd
   Image Type:   ARM Linux RAMDisk Image (gzip compressed)
   Data Size:    5264132 Bytes = 5 MiB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 43000000
   Booting using the fdt blob at 0x43000000
   Loading Ramdisk to 49afa000, end 49fff304 ... OK
   reserving fdt memory region: addr=43000000 size=70000
   Loading Device Tree to 49a87000, end 49af9fff ... OK

Starting kernel ...
 

[hanni76]

Problem is fixed!  Kernel 4.15 in sun7i-a20.dtsi for all nodes is using the following syntax soc@1c00000  but in my overlays it was soc@01c00000

 

[martinayotte]

Good catch !