[U-Boot] [RFC] arm: dts: am33xx: Sync DTS with Linux 4.16.11
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? 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.
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
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
Hi Lokesh, many thanks for the feedback!
On 10.07.2018 08:42, Lokesh Vutla wrote:
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.
This sounds like a very good solution for the <reg-shift> property. I'm thinking about sending in a patch ...
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
regards, Felix
Hi Felix,
On Wednesday 11 July 2018 06:59 PM, Felix Brack wrote:
Hi Lokesh, many thanks for the feedback!
On 10.07.2018 08:42, Lokesh Vutla wrote:
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.
This sounds like a very good solution for the <reg-shift> property. I'm thinking about sending in a patch ...
That would be great.
Thanks and regards, Lokesh
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
participants (2)
-
Felix Brack -
Lokesh Vutla