Re: [PATCH] arm: rpi: Device tree modifications for U-Boot

[Stephen Warren]

On 08/12/2015 07:21 AM, Simon Glass wrote:
> Hi Lucas,
> 
> On 11 August 2015 at 11:05, Lucas Stach <dev@xxxxxxxxxx> wrote:
>> Hi Simon,
>>
>> why did you send this to the Tegra ML?
>>
>> Am Dienstag, den 11.08.2015, 08:25 -0600 schrieb Simon Glass:
>>> This updates the device tree from the kernel version to something suitable
>>> for U-Boot:
>>>
>>> - Add stdout-path alias for console
>>> - Mark the /soc node to be available pre-relocation so that the early
>>> serial console works (we need the 'ranges' property to be available)
>>>
>>> Signed-off-by: Simon Glass <sjg@xxxxxxxxxxxx>
>>> ---
>>>
>>>  arch/arm/boot/dts/bcm2835.dtsi | 4 +++-
>>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/arch/arm/boot/dts/bcm2835.dtsi b/arch/arm/boot/dts/bcm2835.dtsi
>>> index 301c73f..bd6bff6 100644
>>> --- a/arch/arm/boot/dts/bcm2835.dtsi
>>> +++ b/arch/arm/boot/dts/bcm2835.dtsi
>>> @@ -8,6 +8,7 @@
>>>
>>>       chosen {
>>>               bootargs = "earlyprintk console=ttyAMA0";
>>> +             stdout-path = &uart;
>>>       };
>>>
>>>       soc {
>>> @@ -16,6 +17,7 @@
>>>               #size-cells = <1>;
>>>               ranges = <0x7e000000 0x20000000 0x02000000>;
>>>               dma-ranges = <0x40000000 0x00000000 0x20000000>;
>>> +             u-boot,dm-pre-reloc;
>>
>> Why do you need this and why should upstream carry your favourite
>> bootloaders configuration? This is in no way hardware description.
> 
> I'm not sure how much you know about U-Boot, so let me know if you
> need more info.
> 
> U-Boot normally starts up by setting up its serial UART and displaying
> a banner message. At this stage typically only a few devices are
> initialised (e.g. maybe just the UART). It then relocates itself to
> the top of memory and starts up all the devices. It throws away any
> previous devices that it set up before relocation and starts again.
> 
> U-Boot uses a thing called driver model (dm) which handles driver
> binding and probing. Driver model has the device tree and would
> normally scan through it and create devices for everything it finds.
> 
> Before relocation we don't need every device. Also the CPU is often
> running slowly, perhaps without the cache enabled. SDRAM may not be
> available yet so space is short. We want to avoid starting up things
> that will not be used.
> 
> So this property indicates that the device is needed before relocation
> and should be set up by driver model. We need it to avoid a very slow
> and memory-hungry startup.
> 
> As to why upstream should accept it, my understanding of upstream is
> that people can send patches to it and in fact are encouraged to do
> so, to avoid misunderstandings and duplication. The device tree files
> are stored in Linux so any binding or source file changes should end
> up there. Otherwise the files tend to diverge and we end up with
> multiple bindings and multiple versions of the same source file.

On many platforms, we have U-Boot SPL running first, then the main
U-Boot. The main U-Boot binary contains both the code to do the
relocation and the binary that runs after relocation. It seems like it'd
be simpler to split these up into 3 binaries that each do a single job:

1) SPL, roughly as-is today (varying jobs depending on platform)

2) Relocator, which does nothing but work out where to copy U-Boot,
memcpy()s it there, relocates the image (if not PIE), and jumps to it.

3) The main U-Boot.

Item (2) above should be simple enough that it can use a very simple
debug mechanism rather like DEBUG_LL in the Linux kernel. Similar to
what Rob mentioned in his email.

Item (3) could use DM and DT/ACPI/... to get device information in a
complete non-hard-coded manner.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/