Hi Felix, On Thursday 24 May 2018 02:32 PM, Felix Brack wrote: > Hello, > > I am working on a patch to synchronize the DTS files of the am33xx SoC > with those from Linux 4.16.11 (current stable). > > After some tiny modifications to the boards am335x-pdu001, am335x-evm, > am335x-rut, am437x-gp-evm and am43x-epos-evm buildman passes without any > warnings on the 46 am33xx based boards. This is required but not > sufficient at all. > > As I'm the maintainer of the am335x-pdu001 board I will use it to > illustrate a sample problem. > The am335x-pdu001 board uses the ns16550 driver which reads the property > <reg-shift> from the DT. This property is required and must be set to a > value of 2, otherwise it would default to 0. > The am33xx.dtsi file currently used by U-Boot sets this property > correctly for all 6 uarts. The am33xx.dtsi file from Linux 4.16.11 > however does not define this property anymore. > For the am335x-pdu001 board the fix is trivial: just add the property > <reg-shift> to the board and U-Boot specific am335xx-pdu001-u-boot.dtsi > file. > But this has a major drawback: only the am335x-pdu001 board gets fixed. > What about other boards requiring the <reg-shift> property?
I agree this is a problem. Also not all kernel drivers need this property as there are separate driver files for some of the compatibles. And few drivers has this property hard-coded. > The first idea that would probably come into mind is to put the property > <reg-shift> into the SoC specific am33xx-u-boot.dtsi file. But this file > is ignored if a board specific file already exists. Hence this can not > be done. One solution I can think of is add a Kconfig entry CONFIG_SYS_NS16550_REG_SHIFT. A default value of 0 can be assigned for this and can be updated in as necessary. So when doing dev_read_u32_default for reg-shift, CONFIG_SYS_NS16550_REG_SHIFT can be passed as default instead of 0. This way no DTS files needs to be updated. Thanks and regards, Lokesh > > For the patch I'm working on there is the general question about how to > proceed. Should I just fix the board I'm maintaining and then post the > patch? This would most certainly break some of the remaining 45 boards > which I think is a no-go. > > A more specific question dealing with the "missing SoC property" > <reg-shift> above is about <>-u-boot.dtsi files: would it be possible, > useful and hazard-free to change the build process to use, for example, > SoC specific _and_ board specific files? Of course some sort of > hierarchy would be necessary to make sure that properties defined in the > board specific dtsi file would overwrite the same properties defined in > the SoC specific file ect. > > I believe that keeping DT files (especially include files) in sync > between U-Boot and Linux is of big importance. Maybe there is already a > standard solution to problems similar to the one depicted above. Anyway, > I would appreciate any feedback. > > regards, Felix > _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot