[U-Boot] socfpga cyclone5 dts
Hi Marek,
I was playing with updating the dts files for cyclone5 (and arria5) from current kernel sources, but I found that the kernel as 4 boards that U-Boot doesn't have and U-Boot has 6 boards that the kernel doesn't have.
How should I proceed here? Should I copy new boards from the kernel? Should I keep U-Boot-only boards and try to adjust them to changes (if any)?
Simon
On 10/18/2018 09:28 PM, Simon Goldschmidt wrote:
Hi Marek,
Hi,
I was playing with updating the dts files for cyclone5 (and arria5) from current kernel sources, but I found that the kernel as 4 boards that U-Boot doesn't have and U-Boot has 6 boards that the kernel doesn't have.
Thanks for doing this, really appreciated (even though it probably doesn't look that way most of the time).
And yikes, which boards are where , can you list the problematic ones?
How should I proceed here? Should I copy new boards from the kernel? Should I keep U-Boot-only boards and try to adjust them to changes (if any)?
I'd say sync as much as possible with kernel and the rest, update. I don't think there are any real board specific things which would prevent the update in those DTs missing in the kernel.
Marek Vasut marek.vasut@gmail.com schrieb am Do., 18. Okt. 2018, 22:15:
On 10/18/2018 09:28 PM, Simon Goldschmidt wrote:
Hi Marek,
Hi,
I was playing with updating the dts files for cyclone5 (and arria5) from current kernel sources, but I found that the kernel as 4 boards that U-Boot doesn't have and U-Boot has 6 boards that the kernel doesn't have.
Thanks for doing this, really appreciated (even though it probably doesn't look that way most of the time).
And yikes, which boards are where , can you list the problematic ones?
How should I proceed here? Should I copy new boards from the kernel? Should I keep U-Boot-only boards and try to adjust them to changes (if any)?
I'd say sync as much as possible with kernel and the rest, update. I don't think there are any real board specific things which would prevent the update in those DTs missing in the kernel.
Ok, I'll just try and prepare a patch that ports the existing boards and mentions the boards not ported from current kernel sources. I don't want to remove boards from U-Boot, so we'll just have to test those not in Linux.
Simon
On 10/18/2018 10:20 PM, Simon Goldschmidt wrote:
Marek Vasut <marek.vasut@gmail.com mailto:marek.vasut@gmail.com> schrieb am Do., 18. Okt. 2018, 22:15:
On 10/18/2018 09:28 PM, Simon Goldschmidt wrote: > Hi Marek, Hi, > I was playing with updating the dts files for cyclone5 (and arria5) from > current kernel sources, but I found that the kernel as 4 boards that > U-Boot doesn't have and U-Boot has 6 boards that the kernel doesn't have. Thanks for doing this, really appreciated (even though it probably doesn't look that way most of the time). And yikes, which boards are where , can you list the problematic ones? > How should I proceed here? Should I copy new boards from the kernel? > Should I keep U-Boot-only boards and try to adjust them to changes (if > any)? I'd say sync as much as possible with kernel and the rest, update. I don't think there are any real board specific things which would prevent the update in those DTs missing in the kernel.Ok, I'll just try and prepare a patch that ports the existing boards and mentions the boards not ported from current kernel sources. I don't want to remove boards from U-Boot, so we'll just have to test those not in Linux.
Sounds good!
On 18.10.2018 23:04, Marek Vasut wrote:
On 10/18/2018 10:20 PM, Simon Goldschmidt wrote:
Marek Vasut <marek.vasut@gmail.com mailto:marek.vasut@gmail.com> schrieb am Do., 18. Okt. 2018, 22:15:
On 10/18/2018 09:28 PM, Simon Goldschmidt wrote: > Hi Marek, Hi, > I was playing with updating the dts files for cyclone5 (and arria5) from > current kernel sources, but I found that the kernel as 4 boards that > U-Boot doesn't have and U-Boot has 6 boards that the kernel doesn't have. Thanks for doing this, really appreciated (even though it probably doesn't look that way most of the time). And yikes, which boards are where , can you list the problematic ones? > How should I proceed here? Should I copy new boards from the kernel? > Should I keep U-Boot-only boards and try to adjust them to changes (if > any)? I'd say sync as much as possible with kernel and the rest, update. I don't think there are any real board specific things which would prevent the update in those DTs missing in the kernel.Ok, I'll just try and prepare a patch that ports the existing boards and mentions the boards not ported from current kernel sources. I don't want to remove boards from U-Boot, so we'll just have to test those not in Linux.
Sounds good!
What about the license header? Should we keep the original header for sync'ed device trees or change it to SPDX?
Simon
On 10/22/2018 09:55 PM, Simon Goldschmidt wrote:
On 18.10.2018 23:04, Marek Vasut wrote:
On 10/18/2018 10:20 PM, Simon Goldschmidt wrote:
Marek Vasut <marek.vasut@gmail.com mailto:marek.vasut@gmail.com> schrieb am Do., 18. Okt. 2018, 22:15:
On 10/18/2018 09:28 PM, Simon Goldschmidt wrote: > Hi Marek,
Hi,
> I was playing with updating the dts files for cyclone5 (and arria5) from > current kernel sources, but I found that the kernel as 4 boards that > U-Boot doesn't have and U-Boot has 6 boards that the kernel doesn't have.
Thanks for doing this, really appreciated (even though it probably doesn't look that way most of the time).
And yikes, which boards are where , can you list the problematic ones?
> How should I proceed here? Should I copy new boards from the kernel? > Should I keep U-Boot-only boards and try to adjust them to changes (if > any)?
I'd say sync as much as possible with kernel and the rest, update. I don't think there are any real board specific things which would prevent the update in those DTs missing in the kernel.
Ok, I'll just try and prepare a patch that ports the existing boards and mentions the boards not ported from current kernel sources. I don't want to remove boards from U-Boot, so we'll just have to test those not in Linux.
Sounds good!
What about the license header? Should we keep the original header for sync'ed device trees or change it to SPDX?
SPDX please. Even better, fix it in the kernel too :)
On 18.10.2018 23:04, Marek Vasut wrote:
On 10/18/2018 10:20 PM, Simon Goldschmidt wrote:
Marek Vasut <marek.vasut@gmail.com mailto:marek.vasut@gmail.com> schrieb am Do., 18. Okt. 2018, 22:15:
On 10/18/2018 09:28 PM, Simon Goldschmidt wrote: > Hi Marek, Hi, > I was playing with updating the dts files for cyclone5 (and arria5) from > current kernel sources, but I found that the kernel as 4 boards that > U-Boot doesn't have and U-Boot has 6 boards that the kernel doesn't have. Thanks for doing this, really appreciated (even though it probably doesn't look that way most of the time). And yikes, which boards are where , can you list the problematic ones? > How should I proceed here? Should I copy new boards from the kernel? > Should I keep U-Boot-only boards and try to adjust them to changes (if > any)? I'd say sync as much as possible with kernel and the rest, update. I don't think there are any real board specific things which would prevent the update in those DTs missing in the kernel.Ok, I'll just try and prepare a patch that ports the existing boards and mentions the boards not ported from current kernel sources. I don't want to remove boards from U-Boot, so we'll just have to test those not in Linux.
Sounds good!
After a short test run, I decided to first ask for the boards before preparing a patch:
Boards in U-Boot but not in Linux (not updated): - socfpga_cyclone5_dbm_soc1.dts - socfpga_cyclone5_de0_nano_soc.dts (is this 'socfpga_cyclone5_de0_sockit.dts'?) - socfpga_cyclone5_de1_soc.dts - socfpga_cyclone5_de10_nano.dts - socfpga_cyclone5_is1.dts - socfpga_cyclone5_sr1500.dts
Boards in Linux but not in U-Boot: - socfpga_cyclone5_de0_sockit.dts (is this 'socfpga_cyclone5_de0_nano_soc.dts'?) - socfpga_cyclone5_sodia.dts
Also, Dinh has enabled the watchdog nearly 4 years ago in socfpga_cyclone5.dtsi but U-Boot doesn't. Should we keep it enabled or disable it in the U-Boot specific dts files?
Thanks, Simon
On Mon, 2018-10-22 at 22:48 +0200, Simon Goldschmidt wrote:
On 18.10.2018 23:04, Marek Vasut wrote:
On 10/18/2018 10:20 PM, Simon Goldschmidt wrote:
Marek Vasut <marek.vasut@gmail.com mailto:marek.vasut@gmail.com> schrieb am Do., 18. Okt. 2018, 22:15:
On 10/18/2018 09:28 PM, Simon Goldschmidt wrote: > Hi Marek, Hi, > I was playing with updating the dts files for cyclone5 (and arria5) from > current kernel sources, but I found that the kernel as 4 boards that > U-Boot doesn't have and U-Boot has 6 boards that the kernel doesn't have. Thanks for doing this, really appreciated (even though it probably doesn't look that way most of the time). And yikes, which boards are where , can you list the problematic ones? > How should I proceed here? Should I copy new boards from the kernel? > Should I keep U-Boot-only boards and try to adjust them to changes (if > any)? I'd say sync as much as possible with kernel and the rest, update. I don't think there are any real board specific things which would prevent the update in those DTs missing in the kernel.Ok, I'll just try and prepare a patch that ports the existing boards and mentions the boards not ported from current kernel sources. I don't want to remove boards from U-Boot, so we'll just have to test those not in Linux.
Sounds good!
After a short test run, I decided to first ask for the boards before preparing a patch:
Boards in U-Boot but not in Linux (not updated):
- socfpga_cyclone5_dbm_soc1.dts
- socfpga_cyclone5_de0_nano_soc.dts (is this
'socfpga_cyclone5_de0_sockit.dts'?)
Yes, these are the same board.
- socfpga_cyclone5_de1_soc.dts- socfpga_cyclone5_de10_nano.dts-
socfpga_cyclone5_is1.dts- socfpga_cyclone5_sr1500.dts Boards in Linux but not in U-Boot:- socfpga_cyclone5_de0_sockit.dts (is this 'socfpga_cyclone5_de0_nano_soc.dts'?)- socfpga_cyclone5_sodia.dts Also, Dinh has enabled the watchdog nearly 4 years ago in socfpga_cyclone5.dtsi but U-Boot doesn't. Should we keep it enabled or disable it in the U-Boot specific dts files? Thanks,Simon_______________________________________________U-Boot mailing listU-Boot@lists.denx.dehttps://lists.denx.de/listinfo/u-boot
On 10/22/2018 10:48 PM, Simon Goldschmidt wrote:
On 18.10.2018 23:04, Marek Vasut wrote:
On 10/18/2018 10:20 PM, Simon Goldschmidt wrote:
Marek Vasut <marek.vasut@gmail.com mailto:marek.vasut@gmail.com> schrieb am Do., 18. Okt. 2018, 22:15:
On 10/18/2018 09:28 PM, Simon Goldschmidt wrote: > Hi Marek,
Hi,
> I was playing with updating the dts files for cyclone5 (and arria5) from > current kernel sources, but I found that the kernel as 4 boards that > U-Boot doesn't have and U-Boot has 6 boards that the kernel doesn't have.
Thanks for doing this, really appreciated (even though it probably doesn't look that way most of the time).
And yikes, which boards are where , can you list the problematic ones?
> How should I proceed here? Should I copy new boards from the kernel? > Should I keep U-Boot-only boards and try to adjust them to changes (if > any)?
I'd say sync as much as possible with kernel and the rest, update. I don't think there are any real board specific things which would prevent the update in those DTs missing in the kernel.
Ok, I'll just try and prepare a patch that ports the existing boards and mentions the boards not ported from current kernel sources. I don't want to remove boards from U-Boot, so we'll just have to test those not in Linux.
Sounds good!
After a short test run, I decided to first ask for the boards before preparing a patch:
Boards in U-Boot but not in Linux (not updated):
- socfpga_cyclone5_dbm_soc1.dts
Hum, I should upstream that one.
- socfpga_cyclone5_de0_nano_soc.dts (is this
'socfpga_cyclone5_de0_sockit.dts'?)
There is no de0-sockit. There is de0-nano-soc and there is sockit , these are two different boards.
- socfpga_cyclone5_de1_soc.dts
- socfpga_cyclone5_de10_nano.dts
These should be upstream.
- socfpga_cyclone5_is1.dts
- socfpga_cyclone5_sr1500.dts
CCing Stefan.
Boards in Linux but not in U-Boot:
- socfpga_cyclone5_de0_sockit.dts (is this
'socfpga_cyclone5_de0_nano_soc.dts'?)
Wasn't this removed to de0-nano-soc in next ?
- socfpga_cyclone5_sodia.dts
Also, Dinh has enabled the watchdog nearly 4 years ago in socfpga_cyclone5.dtsi but U-Boot doesn't. Should we keep it enabled or disable it in the U-Boot specific dts files?
Disable it in board files to keep the current behavior.
Thanks, Simon
On Tue, Oct 23, 2018 at 10:42 AM Marek Vasut marex@denx.de wrote:
On 10/22/2018 10:48 PM, Simon Goldschmidt wrote:
On 18.10.2018 23:04, Marek Vasut wrote:
On 10/18/2018 10:20 PM, Simon Goldschmidt wrote:
Marek Vasut <marek.vasut@gmail.com mailto:marek.vasut@gmail.com> schrieb am Do., 18. Okt. 2018, 22:15:
On 10/18/2018 09:28 PM, Simon Goldschmidt wrote: > Hi Marek, Hi, > I was playing with updating the dts files for cyclone5 (and arria5) from > current kernel sources, but I found that the kernel as 4boards that > U-Boot doesn't have and U-Boot has 6 boards that the kernel doesn't have.
Thanks for doing this, really appreciated (even though it probably doesn't look that way most of the time). And yikes, which boards are where , can you list the problematicones?
> How should I proceed here? Should I copy new boards from thekernel? > Should I keep U-Boot-only boards and try to adjust them to changes (if > any)?
I'd say sync as much as possible with kernel and the rest,update. I don't think there are any real board specific things which would prevent the update in those DTs missing in the kernel.
Ok, I'll just try and prepare a patch that ports the existing boards and mentions the boards not ported from current kernel sources. I don't want to remove boards from U-Boot, so we'll just have to test those not in Linux.
Sounds good!
After a short test run, I decided to first ask for the boards before preparing a patch:
Boards in U-Boot but not in Linux (not updated):
- socfpga_cyclone5_dbm_soc1.dts
Hum, I should upstream that one.
- socfpga_cyclone5_de0_nano_soc.dts (is this
'socfpga_cyclone5_de0_sockit.dts'?)
There is no de0-sockit. There is de0-nano-soc and there is sockit , these are two different boards.
Fixed in linux-next, I compared 4.19, see below.
- socfpga_cyclone5_de1_soc.dts
- socfpga_cyclone5_de10_nano.dts
These should be upstream.
But they aren't? Or did you mean "these should be upstreamed"? By whom?
- socfpga_cyclone5_is1.dts
- socfpga_cyclone5_sr1500.dts
CCing Stefan.
Boards in Linux but not in U-Boot:
- socfpga_cyclone5_de0_sockit.dts (is this
'socfpga_cyclone5_de0_nano_soc.dts'?)
Wasn't this removed to de0-nano-soc in next ?
Yes, sorry, I was comparing v4.19, not linux-next. You're right that this is renamed in linux-next.
- socfpga_cyclone5_sodia.dts
Also, Dinh has enabled the watchdog nearly 4 years ago in socfpga_cyclone5.dtsi but U-Boot doesn't. Should we keep it enabled or disable it in the U-Boot specific dts files?
Disable it in board files to keep the current behavior.
Do we enable such things in the "-u-boot.dtsi" "overlay" as well? Because when adding it to the dts, we end up having diffs again...
Simon
On 10/23/2018 10:52 AM, Simon Goldschmidt wrote: [...]
- socfpga_cyclone5_de1_soc.dts
- socfpga_cyclone5_de10_nano.dts
These should be upstream.
But they aren't? Or did you mean "these should be upstreamed"? By whom?
CCing Dinh :-)
[...]
Also, Dinh has enabled the watchdog nearly 4 years ago in socfpga_cyclone5.dtsi but U-Boot doesn't. Should we keep it enabled or disable it in the U-Boot specific dts files?
Disable it in board files to keep the current behavior.
Do we enable such things in the "-u-boot.dtsi" "overlay" as well? Because when adding it to the dts, we end up having diffs again...
Sounds good!
On 23.10.2018 10:54, Marek Vasut wrote:
On 10/23/2018 10:52 AM, Simon Goldschmidt wrote: [...]
- socfpga_cyclone5_de1_soc.dts
- socfpga_cyclone5_de10_nano.dts
These should be upstream.
But they aren't? Or did you mean "these should be upstreamed"? By whom?
CCing Dinh :-)
[...]
Also, Dinh has enabled the watchdog nearly 4 years ago in socfpga_cyclone5.dtsi but U-Boot doesn't. Should we keep it enabled or disable it in the U-Boot specific dts files?
Disable it in board files to keep the current behavior.
Do we enable such things in the "-u-boot.dtsi" "overlay" as well? Because when adding it to the dts, we end up having diffs again...
Sounds good!
To get the Linux devicetree running on the socrates board, I had to add the "clock-frequency" property to the uart(s). What's the status here, socfpga gen5 does not support getting clock rates from the device tree, is that correct?
If so, I'll put the clock-frequency into the "-u-boot.dtsi" files, as well. They can be removed once the clock drivers work.
Also, the gpio controllers are now missing the "bank-name" property, without which they fail to register. Since this property is not even described in device tree bindings, I chose to add a fallback to the driver to use 'fdt_get_name()' to get a name. The downside is that searching a GPIO by bank name might now fail. Is this acceptable? If not, we'll have to add the "bank-name" properties to the "-u-boot.dtsi" files as well. But since most gpio drivers seem to do it that way, I figured it should be OK...
I haven't tested QSPI yet, and I only have access to a SoCrates board, but aside from some "u-boot,dm-pre-reloc" strings, my "-u-boot.dtsi" currently only sets "clock-frequency" for the uarts and disables the watchdog and everything seems to boot fine so far.
Simon
On 10/24/2018 09:44 PM, Simon Goldschmidt wrote:
On 23.10.2018 10:54, Marek Vasut wrote:
On 10/23/2018 10:52 AM, Simon Goldschmidt wrote: [...]
- socfpga_cyclone5_de1_soc.dts
- socfpga_cyclone5_de10_nano.dts
These should be upstream.
But they aren't? Or did you mean "these should be upstreamed"? By whom?
CCing Dinh :-)
[...]
Also, Dinh has enabled the watchdog nearly 4 years ago in socfpga_cyclone5.dtsi but U-Boot doesn't. Should we keep it enabled or disable it in the U-Boot specific dts files?
Disable it in board files to keep the current behavior.
Do we enable such things in the "-u-boot.dtsi" "overlay" as well? Because when adding it to the dts, we end up having diffs again...
Sounds good!
To get the Linux devicetree running on the socrates board, I had to add the "clock-frequency" property to the uart(s). What's the status here, socfpga gen5 does not support getting clock rates from the device tree, is that correct?
We don't have a clock driver on Gen5, right.
If so, I'll put the clock-frequency into the "-u-boot.dtsi" files, as well. They can be removed once the clock drivers work.
This is per-board, so it should go into each boards' -u-boot.dts
Also, the gpio controllers are now missing the "bank-name" property, without which they fail to register. Since this property is not even described in device tree bindings, I chose to add a fallback to the driver to use 'fdt_get_name()' to get a name. The downside is that searching a GPIO by bank name might now fail. Is this acceptable? If not, we'll have to add the "bank-name" properties to the "-u-boot.dtsi" files as well. But since most gpio drivers seem to do it that way, I figured it should be OK...
Either re-add the bank-name to -u-boot.dtsi or fix the GPIO handling code. I'd prefer the former, since someone might depend on those GPIO bank names in their scripts.
I haven't tested QSPI yet, and I only have access to a SoCrates board, but aside from some "u-boot,dm-pre-reloc" strings, my "-u-boot.dtsi" currently only sets "clock-frequency" for the uarts and disables the watchdog and everything seems to boot fine so far.
Cool!
On 23.10.18 10:41, Marek Vasut wrote:
On 10/22/2018 10:48 PM, Simon Goldschmidt wrote:
On 18.10.2018 23:04, Marek Vasut wrote:
On 10/18/2018 10:20 PM, Simon Goldschmidt wrote:
Marek Vasut <marek.vasut@gmail.com mailto:marek.vasut@gmail.com> schrieb am Do., 18. Okt. 2018, 22:15:
On 10/18/2018 09:28 PM, Simon Goldschmidt wrote: > Hi Marek,
Hi,
> I was playing with updating the dts files for cyclone5 (and arria5) from > current kernel sources, but I found that the kernel as 4 boards that > U-Boot doesn't have and U-Boot has 6 boards that the kernel doesn't have.
Thanks for doing this, really appreciated (even though it probably doesn't look that way most of the time).
And yikes, which boards are where , can you list the problematic ones?
> How should I proceed here? Should I copy new boards from the kernel? > Should I keep U-Boot-only boards and try to adjust them to changes (if > any)?
I'd say sync as much as possible with kernel and the rest, update. I don't think there are any real board specific things which would prevent the update in those DTs missing in the kernel.
Ok, I'll just try and prepare a patch that ports the existing boards and mentions the boards not ported from current kernel sources. I don't want to remove boards from U-Boot, so we'll just have to test those not in Linux.
Sounds good!
After a short test run, I decided to first ask for the boards before preparing a patch:
Boards in U-Boot but not in Linux (not updated):
- socfpga_cyclone5_dbm_soc1.dts
Hum, I should upstream that one.
- socfpga_cyclone5_de0_nano_soc.dts (is this
'socfpga_cyclone5_de0_sockit.dts'?)
There is no de0-sockit. There is de0-nano-soc and there is sockit , these are two different boards.
- socfpga_cyclone5_de1_soc.dts
- socfpga_cyclone5_de10_nano.dts
These should be upstream.
- socfpga_cyclone5_is1.dts
- socfpga_cyclone5_sr1500.dts
CCing Stefan.
Thanks. Simon, It would be great, if you could update those 2 dts files.
Thanks, Stefan
participants (5)
-
Dalon L Westergreen -
Marek Vasut -
Marek Vasut -
Simon Goldschmidt -
Stefan Roese