On my board I want to add support for GPIO. The relevant drivers rely on the pinctrl configuration stored in a Device Tree Blob.
So I exposed the memory regions and IRQs to the l4linux task, enabled CONFIG_ARM_APPEND_DTB=y, CONFIG_ARM_DTB_COMPAT=y, CONFIG_USE_OF=y, compiled the dts (from a native linux build) and added it to moe but without any success. Unfortunately I did not find any references nor any examples how someone can provide a Device Tree Blob to l4linux.
Has anybody ever managed to get l4linux running with DTB support?
Best regards Martin Schröder.
On Tue Aug 05, 2014 at 17:56:54 +0200, Martin Schröder wrote:
On my board I want to add support for GPIO. The relevant drivers rely on the pinctrl configuration stored in a Device Tree Blob.
So I exposed the memory regions and IRQs to the l4linux task, enabled CONFIG_ARM_APPEND_DTB=y, CONFIG_ARM_DTB_COMPAT=y, CONFIG_USE_OF=y, compiled the dts (from a native linux build) and added it to moe but without any success. Unfortunately I did not find any references nor any examples how someone can provide a Device Tree Blob to l4linux.
Has anybody ever managed to get l4linux running with DTB support?
Appending the DTB won't work with L4Linux. However, you can just use l4x_dtb=rom/your.dtb on the cmdline.
Adam
Hi Adam,
Am 05.08.2014 um 22:44 schrieb Adam Lackorzynski:
Appending the DTB won't work with L4Linux. However, you can just use l4x_dtb=rom/your.dtb on the cmdline.
it does not work for me. With a provided dtb it stops here:
l4linux | l4x_register_pointer_section: addr = 02000000 size = 3956736 l4linux | text: Virt: 0x2000000 to 0x23c5c0f [3863 KiB] l4linux | text: Phys: 0x40441000 to 0x40806c0f, [3863 KiB] l4linux | DTB: virt=0x2400100 phys=41600100
If l4x_dtb is left out booting continues with:
l4linux | l4lx_thread_create: Created thread 41a timer0) (u:b3000a00, v:00000000, sp:0235dfa) Booting Linux on physical CPU 0X0 ...
So l4x_load_dtb(main.c) is fine, but then something else in setup_arch goes wrong. The dtb s stolen from some other linux build, so maybe the dtb is wrong.
Martin
Hi Martin,
On Mon Aug 11, 2014 at 19:13:51 +0200, Martin Schröder wrote:
Am 05.08.2014 um 22:44 schrieb Adam Lackorzynski:
Appending the DTB won't work with L4Linux. However, you can just use l4x_dtb=rom/your.dtb on the cmdline.
it does not work for me. With a provided dtb it stops here:
l4linux | l4x_register_pointer_section: addr = 02000000 size = 3956736 l4linux | text: Virt: 0x2000000 to 0x23c5c0f [3863 KiB] l4linux | text: Phys: 0x40441000 to 0x40806c0f, [3863 KiB] l4linux | DTB: virt=0x2400100 phys=41600100
If l4x_dtb is left out booting continues with:
l4linux | l4lx_thread_create: Created thread 41a timer0) (u:b3000a00, v:00000000, sp:0235dfa) Booting Linux on physical CPU 0X0 ...
So l4x_load_dtb(main.c) is fine, but then something else in setup_arch goes wrong. The dtb s stolen from some other linux build, so maybe the dtb is wrong.
Hmm, you need to tune the DT a bit I think. Did you take out the GIC, timer and UART? (In case they might be compiled in.) Do you have earlyprintk enabled? Maybe you also could try arch/l4/boot/dts/simple.dtb.
Adam
Hi Adam,
Am 11.08.2014 um 23:41 schrieb Adam Lackorzynski:
So l4x_load_dtb(main.c) is fine, but then something else in setup_arch goes wrong. The dtb s stolen from some other linux build, so maybe the dtb is wrong.
Hmm, you need to tune the DT a bit I think. Did you take out the GIC, timer and UART? (In case they might be compiled in.) Do you have earlyprintk enabled? Maybe you also could try arch/l4/boot/dts/simple.dtb.
thanks for the tip with simple.dtb: l4linux went up again, so I switched to imx28.dts from /l4linux/arch/arm. Even icoll, timrot and duart compiled don't harm. So let's forget about the other dtb which was build for some 3.7.x kernel.
Up to now I am using a platform_device for ethernet with "preconfigured" clocks from U-Boot. Now I switched the ethernet device to device tree. Probing works fine, the phy is detected, but the link no longer goes up.
Best regards, Martin
On Tue Aug 12, 2014 at 19:54:37 +0200, Martin Schröder wrote:
Hi Adam,
Am 11.08.2014 um 23:41 schrieb Adam Lackorzynski:
So l4x_load_dtb(main.c) is fine, but then something else in setup_arch goes wrong. The dtb s stolen from some other linux build, so maybe the dtb is wrong.
Hmm, you need to tune the DT a bit I think. Did you take out the GIC, timer and UART? (In case they might be compiled in.) Do you have earlyprintk enabled? Maybe you also could try arch/l4/boot/dts/simple.dtb.
thanks for the tip with simple.dtb: l4linux went up again, so I switched to imx28.dts from /l4linux/arch/arm. Even icoll, timrot and duart compiled don't harm. So let's forget about the other dtb which was build for some 3.7.x kernel.
Ah yes, DTBs should match the kernel (in this time of the century).
Up to now I am using a platform_device for ethernet with "preconfigured" clocks from U-Boot. Now I switched the ethernet device to device tree. Probing works fine, the phy is detected, but the link no longer goes up.
So it worked before using DTBs? Some config/setting issue?
Adam
Am 13.08.2014 um 22:40 schrieb Adam Lackorzynski:
So it worked before using DTBs? Some config/setting issue?
Yes, both network of my imx28 worked withou DTB. I is some config issue:
After searching a while, I am sure that the Device Tree is not used in my configuration at all. As I wrote in an older thread "IO configuration language" I am using on the vbus the strings "imx28-fec.mydev0" => wrap(hw-root.NIC0) to get the platform device added in mach_setup.c. This is done by a custom handler in the callbacks which captures the "imx28-fec.mydev0" and "imx28-fec.mydev1" devices and creates the platform device. After renaming the device to "imx28-fec" (and thus disabling the private callback), I see that the device is still added in a generic way (IRQ, MEM, PORT) in copy_platform_device, but without the required additional data (Phy Interface Mode). So Ethernet is still probed but due to the wring mode not working.
Now I removed the strings from the io configuration. Mach_setup.c is no longer adding platform devices and ... Ethernet is no longer probed. I also verified that the DTB was loaded, but for some reasons the DTB is unfortunately not used or does not match.
I am using the imx28-evk.dts where I replaced the "model" and "compatible" line by what I found in simple.dts.
Martin
On Mon Aug 18, 2014 at 19:38:54 +0200, Martin Schröder wrote:
Am 13.08.2014 um 22:40 schrieb Adam Lackorzynski:
So it worked before using DTBs? Some config/setting issue?
Yes, both network of my imx28 worked withou DTB. I is some config issue:
After searching a while, I am sure that the Device Tree is not used in my configuration at all. As I wrote in an older thread "IO configuration language" I am using on the vbus the strings "imx28-fec.mydev0" => wrap(hw-root.NIC0) to get the platform device added in mach_setup.c. This is done by a custom handler in the callbacks which captures the "imx28-fec.mydev0" and "imx28-fec.mydev1" devices and creates the platform device. After renaming the device to "imx28-fec" (and thus disabling the private callback), I see that the device is still added in a generic way (IRQ, MEM, PORT) in copy_platform_device, but without the required additional data (Phy Interface Mode). So Ethernet is still probed but due to the wring mode not working.
Now I removed the strings from the io configuration. Mach_setup.c is no longer adding platform devices and ... Ethernet is no longer probed. I also verified that the DTB was loaded, but for some reasons the DTB is unfortunately not used or does not match.
I am using the imx28-evk.dts where I replaced the "model" and "compatible" line by what I found in simple.dts.
Ok, that's one thing to do. Does Linux say that it uses a DT? Like: [ 0.000000] Machine model: L4Linux (DT)
Adam
Hello Adam and Martin,
I hope you do not mind I join this conversation. I am facing the exactly same problem Martin has. except I am using imx6q.
So I got the same result that dtb seems be read in but does not take effect as Martin reported.
And I got this from log
/Machine model: L4Linux (DT)/
and now digging into the code how dtb are read and used. Please help!
-Yunchuan
On 08/19/2014 01:13 AM, Adam Lackorzynski wrote:
On Mon Aug 18, 2014 at 19:38:54 +0200, Martin Schröder wrote:
Am 13.08.2014 um 22:40 schrieb Adam Lackorzynski:
So it worked before using DTBs? Some config/setting issue?
Yes, both network of my imx28 worked withou DTB. I is some config issue:
After searching a while, I am sure that the Device Tree is not used in my configuration at all. As I wrote in an older thread "IO configuration language" I am using on the vbus the strings "imx28-fec.mydev0" => wrap(hw-root.NIC0) to get the platform device added in mach_setup.c. This is done by a custom handler in the callbacks which captures the "imx28-fec.mydev0" and "imx28-fec.mydev1" devices and creates the platform device. After renaming the device to "imx28-fec" (and thus disabling the private callback), I see that the device is still added in a generic way (IRQ, MEM, PORT) in copy_platform_device, but without the required additional data (Phy Interface Mode). So Ethernet is still probed but due to the wring mode not working.
Now I removed the strings from the io configuration. Mach_setup.c is no longer adding platform devices and ... Ethernet is no longer probed. I also verified that the DTB was loaded, but for some reasons the DTB is unfortunately not used or does not match.
I am using the imx28-evk.dts where I replaced the "model" and "compatible" line by what I found in simple.dts.
Ok, that's one thing to do. Does Linux say that it uses a DT? Like: [ 0.000000] Machine model: L4Linux (DT)
Adam
Hi Adam,
Am 19.08.2014 um 00:13 schrieb Adam Lackorzynski:
I am using the imx28-evk.dts where I replaced the "model" and "compatible" line by what I found in simple.dts.
Ok, that's one thing to do. Does Linux say that it uses a DT? Like: [ 0.000000] Machine model: L4Linux (DT)
Yes it does:
Booting Linux on physical CPU 0x0 Linux version 3.14.0-l4 (mschroeder@dev04) (gcc version 4.6.2 (OSELAS.Toolchain-2011.11.3) ) #32 Mon Aug 18 DTB: virt=02400100 phys=41600100 CPU: Fiasco [41069265] revision 5 (ARMv5TEJ, cr=00000000 CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing instruction cache Machine model: L4Linux (DT) Ignoring RAM at 40000000-47ffffff (!CONFIG_HIGHMEM). Memory pilcy: Data cache writeback
Martin.
Hi Adam,
I tracked the problem down to l4linux/arch/l4/kernel/arch-arm/setup.c: In static customize_machine(void) either machine_desc->init_machine() is called and the static/generic platform devices are added (and the DT disregarded). If init_machine is not set the DT is parsed instead by of_platform_populate. So I changed in l4.c the .init_machine property to NULL and got all the devices generated from the DT.
Now at least I got the pinctrl-mxs.c working (utilizes only memory). But gpoi-mxs.c does not get it's irq and fails probing. What is the correct interrupt-parent definition if the interrupt controller is outside of l4linux?
Best regards, Martin
Am 19.08.2014 um 14:25 schrieb Martin Schröder:
Hi Adam,
I tracked the problem down to l4linux/arch/l4/kernel/arch-arm/setup.c: In static customize_machine(void) either machine_desc->init_machine() is called and the static/generic platform devices are added (and the DT disregarded). If init_machine is not set the DT is parsed instead by of_platform_populate. So I changed in l4.c the .init_machine property to NULL and got all the devices generated from the DT.
While trying to get fec_main.c probed, I recognized that skipping .init_machine is not a good idea, since dma_alloc_coherent fails while allocating the memory for the network buffer descriptors in fec_main.c. This is due to the missing call of l4io_request_iomem in the "dmamem" device L4X_DEVICE_CB. So it seems that both init_machine() and of_platform_populate() is needed. If I remove the "else" line from the if statement in customize_machine the dma_alloc_coherent succeeds again.
Now at least I got the pinctrl-mxs.c working (utilizes only memory). But gpoi-mxs.c does not get it's irq and fails probing. What is the correct interrupt-parent definition if the interrupt controller is outside of l4linux?
Maybe the interrupt-parent adjustment could also be done "in memory" after loading the dtb?
Best regards, Martin.
On Tue Aug 19, 2014 at 17:43:29 +0200, Martin Schröder wrote:
Am 19.08.2014 um 14:25 schrieb Martin Schröder:
Hi Adam,
I tracked the problem down to l4linux/arch/l4/kernel/arch-arm/setup.c: In static customize_machine(void) either machine_desc->init_machine() is called and the static/generic platform devices are added (and the DT disregarded). If init_machine is not set the DT is parsed instead by of_platform_populate. So I changed in l4.c the .init_machine property to NULL and got all the devices generated from the DT.
While trying to get fec_main.c probed, I recognized that skipping .init_machine is not a good idea, since dma_alloc_coherent fails while allocating the memory for the network buffer descriptors in fec_main.c. This is due to the missing call of l4io_request_iomem in the "dmamem" device L4X_DEVICE_CB. So it seems that both init_machine() and of_platform_populate() is needed. If I remove the "else" line from the if statement in customize_machine the dma_alloc_coherent succeeds again.
Ok, I should probably rip this all out and do DT only.
Now at least I got the pinctrl-mxs.c working (utilizes only memory). But gpoi-mxs.c does not get it's irq and fails probing. What is the correct interrupt-parent definition if the interrupt controller is outside of l4linux?
Maybe the interrupt-parent adjustment could also be done "in memory" after loading the dtb?
I have some still hacky code on my disk which I think handles this. I have to check and clean this up to commit it.
Adam
On Mon Aug 25, 2014 at 14:22:57 +0200, Martin Schröder wrote:
Am 21.08.2014 um 23:03 schrieb Adam Lackorzynski:
I have some still hacky code on my disk which I think handles this. I have to check and clean this up to commit it.
sounds promising! Even a dirty patch would help me a lot.
Ack, will be offline.
Adam
l4-hackers@os.inf.tu-dresden.de