Dear community, dear Sascha, an accident happened on my side. I totally overlooked that after my initial mail with the initial quoted error message the message changed. Probably either the change of compiling the dtb file (make dtbs DTC_FLAGS=-@) got me a __symbols__ node or another thing was sorted out by me on accident meanwhile since still I am trying to get used to device tree handling. In detail, this messages are not valid any more: >>>> Loading ARM Linux zImage '/boot/uImage' >>>> Loading devicetree from '/boot/am335x-boneblack.dtb' >>>> ERROR: of_resolver: __symbols__ missing from base devicetree >>>> WARNING: Failed to fixup node in of_overlay_fixup+0x1/0x4: Invalid argument >>>> ERROR: of_resolver: __symbols__ missing from base devicetree >>>> WARNING: Failed to fixup node in of_overlay_fixup+0x1/0x4: Invalid argument but I get a different set of errors. Probably since including Friday and I overlooked this. How embarassing, sorry! Now I get: ERROR: of_resolver: cannot find node ocp in base devicetree WARNING: Failed to fixup node in of_overlay_fixup+0x1/0x4: Invalid argument ERROR: of_resolver: cannot find node ocp in base devicetree WARNING: Failed to fixup node in of_overlay_fixup+0x1/0x4: Invalid argument which is very reasonable: > Have a look at the generated dtb file with 'dtc -I dtb -O dts <file>'. > It should contain a __symbols__ node. The decompiled result of “my” dtb has a __symbols__ note at the bottom of the file, yes! I suppose each “fragment@n {target = XYZ …”) in a overlay has to have a matching counterpart XYZ in the __symbols__ node in the base file, right? Because in my overlay there is an "target = <&ocp>!" without a matching counterpart in the base dtb. Two other entries (uart1, am33xx_pinmux) have a matching entry. > BTW do you have a good reason to use overlays? Overlays only have a No indeed I don’t necessarily - I realized meanwhile by myself. Additionally I relaized the overlays I have here in question only do some GPIO multiplexing I can do by hand/script in the /sys gpio section anyway. Only interesting for serial line availability at boot. May be later it’s interesting for us for different variante, I hope I am used to this stuff then. > value when you have different hardware variants in which different > overlays are loaded. If that's not the case I'd just go with a static > devicetree and be done with it. For now I agree and I try to understand how to enable the UART1 and UART4 in a static dtb way and I currently search the vanille device tree on how to do this and how this currently this is done at least with the working UART0 :-) Sadly not barebox related :-) Kind Regards Konsti
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ barebox mailing list barebox@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/barebox