Tom Rini trini@konsulko.com schrieb am Mo., 13. Aug. 2018, 15:41:
On Mon, Aug 13, 2018 at 03:36:35PM +0200, Simon Goldschmidt wrote:
Tom Rini trini@konsulko.com schrieb am Mo., 13. Aug. 2018, 15:33:
On Mon, Aug 13, 2018 at 03:29:30PM +0200, Marek Vasut wrote:
On 08/13/2018 03:28 PM, Tom Rini wrote:
On Mon, Aug 13, 2018 at 03:25:19PM +0200, Simon Goldschmidt wrote:
On Mon, Aug 13, 2018 at 3:17 PM Tom Rini trini@konsulko.com
wrote:
> > On Mon, Aug 13, 2018 at 09:33:45AM +0200, Simon Goldschmidt
wrote:
> >> Device trees need to have the serial console device available >> before relocation and require a stdout-path in chosen at least >> for SPL to have a console. >> >> Signed-off-by: Simon Goldschmidt <
simon.k.r.goldschmidt@gmail.com>
>> --- >> >> Changes in v3: >> - moved uart0's "u-boot,dm-pre-reloc;" from socfpga.dtsi to
board
>> specific dts files since this can change per board > > Why are these not in socfpga-u-boot.dtsi ? We have the
mechanism to
> grab CONFIG_SYS_CPU/CONFIG_SYS_SOC/CONFIG_SYS_VENDOR-u-boot.dtsi > automatically so that we don't have to modify the files we sync
in
from
> upstream.
Ehrm, I don't know, really. The DTS files for socfpga already have many U-Boot specifics and are quite different to Linux. It might
make
sense to sync them, but do we really have to do this for 2018.09?
Keep in mind that this series exists to fix that 2018.07 broke on
these boards.
Well, I think given that you're adding these changes right now,
they
should be added to the correct file so that they aren't lost on
re-sync
later. It would be adding: &uart0 { u-boot,dm-pre-reloc; };
once to arch/arm/dts/socfpga-u-boot.dtsi rather than for every
board.
Pulling the U-Boot specific crap would be most welcome, but it could
be
a separate patch.
So you want to add stuff now and pull it out later? That seems counter intuitive, but sure, you're the custodian here. When do you plan to do the clean-up, for v2018.11?
Can we do this in one step with syncing up to the latest Linux device
trees?
I honestly don't understand the hesitation to not introduce more change than is required now. But, I will defer. I do want to know when people plan to fix this however, as that feels like a reasonable compromise to me.
It's holiday season here so I can't say I'll be available all the time until the 2018.09 release. That's why I don't want to do changes I can't thoroughly test right now.
I might try the sync in September. It should not be too much work, but I can only test one of the boards (the SoCrates).
Simom