On 29.02.24 07:03, Denis OSTERLAND-HEIM wrote:
> Hi,
>
> Well, the kernel in root A may have a different device tree, than the one in
> root B.
> This is the kernel version update case.
> What would break, depends on the changes to the dt.
Hmm, ok. I just sent a patch that should support both my and your use case.
Cheers,
Ahmad
>
> Regards, Denis
>
> -----Original Message-----
> From: Ahmad Fatoum <a.fatoum@xxxxxxxxxxxxxx>
> Sent: Monday, February 26, 2024 1:39 PM
> To: Denis OSTERLAND-HEIM <denis.osterland@xxxxxxxxx>; Roland Hieber
> <rhi@xxxxxxxxxxxxxx>; Denis Osterland-Heim <denis.osterland@xxxxxxxxx>
> Cc: barebox@xxxxxxxxxxxxxxxxxxx; Alexander Dahl <ada@xxxxxxxxxxx>
> Subject: [EXT] Re: [EXT] Re: [EXT] Re: [PATCH v2 2/2] raspi: fixup
> additional vc created nodes
>
> [EXTERNAL EMAIL]
>
>
> Hello Denis,
>
> On 21.02.24 08:46, Denis OSTERLAND-HEIM wrote:
>> Hi,
>>
>> It took me a while to think about it.
>> First I would like to explain my current boot process and then how I
>> think it would like with your suggestion.
>>
>>
>> Now:
>>
>> Disk layout:
>> - rpi boot fat: dt-2nd.img, barebox-dts, rpi-elf, config.txt
>> - root A
>> - root B
>>
>> Boot process:
>> - rpi boot loader
>> * load dt-2nd.img and dt
>> * read Hat Eeprom
>> * apply fixups to dt
>> - barebox with dt from r2
>> * bootchooser select A or B
>> * load kernel and dt from A or B
>> * copy stuff to kernel dt from barebox internal dt as fixups
>> - linux boot
>>
>>
>> Your approach:
>>
>> Disk layout:
>> - rpi boot fat: bb-rpi.img, some-dts, rpi-elf, config.txt
>> - root A
>> - root B
>>
>> Boot process:
>> - rpi boot loader
>> * load bb-rpi.img and dt
>> * read Hat Eeprom
>> * apply fixups to dt
>> - barebox with built-in dt
>> * bootchooser select A or B
>> * load kernel and dt from A or B
>> * copy stuff to kernel dt from /vc.dtb as fixups
>
> This I don't understand. Why not use vc.dtb as kernel DT? You can still have
> barebox apply boot arg fixups and so on, but use /vc.dtb as base?
>
>> - linux boot
>>
>> I can remember that I tried to implement the fixups as script in the
>> environment first, but switched to C somewhen.
>> I can not recall the reason, sorry.
>> I guess it was related to recursive copy.
>> The C code uses of_merge_node or something like that, which is not
>> available as command, I think.
>
> This can be made available to shell too if there's use for it, but I think
> this is tangential.
>
>> If we can keep the patches an just do something like if /vc.dtb then
>> apply fixups, I would be fine with your approach.
>> But I guess this almost exactly matches the `if(!IS_ERR(root))
>> rpi_vc_fdt_parse(root);` approach.
>> If you just revert the patches, I guess I would have to find a way to
>> do it in script.
>
> What would break if you used vc.dtb as kernel DT?
>
> Thanks,
> Ahmad
>
>>
>> Regards, Denis
>>
>> -----Original Message-----
>> From: Ahmad Fatoum <a.fatoum@xxxxxxxxxxxxxx>
>> Sent: Tuesday, February 20, 2024 4:33 PM
>> To: Denis OSTERLAND-HEIM <denis.osterland@xxxxxxxxx>; Roland Hieber
>> <rhi@xxxxxxxxxxxxxx>; Denis Osterland-Heim <denis.osterland@xxxxxxxxx>
>> Cc: barebox@xxxxxxxxxxxxxxxxxxx; Alexander Dahl <ada@xxxxxxxxxxx>
>> Subject: [EXT] Re: [EXT] Re: [PATCH v2 2/2] raspi: fixup additional vc
>> created nodes
>>
>> [EXTERNAL EMAIL]
>>
>>
>> Hello Denis,
>>
>> On 20.02.24 09:16, Denis OSTERLAND-HEIM wrote:
>>> Hi,
>>>
>>> I think so, too.
>>> I think that my mistake was in 5ea6e19737e10973ce2cf785970e32562d9ee8f1.
>>
>> Yes.
>>
>>>> @@ -379,17 +381,17 @@ static void rpi_vc_fdt(void)
>>>> if (oftree->totalsize)
>>>> pr_err("there was an error copying fdt in pbl:
>>> %d\n",
>>>> be32_to_cpu(oftree->totalsize));
>>>> - return;
>>> This return previously avoided a call of rpi_vc_fdt_parse().
>>>
>>
>> [snip]
>>
>>>> rpi_env_init();
>>>> - rpi_vc_fdt();
>>>> + root = rpi_vc_fdt();
>>>> + rpi_vc_fdt_parse(IS_ERR(root) ? priv->dev->device_node : root);
>>> Now rpi_vc_fdt_parse() is called in both cases.
>>> So, it should be:
>>> if (!IS_ERR(root))
>>> rpi_vc_fdt_parse(root);
>>>> rpi_set_kernel_name();
>>>>
>>> ...
>>>
>>> Or do I miss something?
>>
>> Now that I think of it, I think the commit should just be reverted.
>> I don't see the utility of using barebox-dt-2nd.img on the Raspberry Pi:
>>
>> - If the board is already supported, use barebox-raspberry-pi.img, which
>> has the DT built-in.
>>
>> - If the board is not supported , use barebox-raspberry-pi.img, which
>> will take the outside DT and save it where the board code expects it.
>>
>> What do you think?
>>
>> Thanks,
>> Ahmad
>>
>>>
>>> Regards, Denis
>>>
>>> -----Original Message-----
>>> From: Ahmad Fatoum <a.fatoum@xxxxxxxxxxxxxx>
>>> Sent: Monday, February 19, 2024 10:43 PM
>>> To: Roland Hieber <rhi@xxxxxxxxxxxxxx>; Denis Osterland-Heim
>>> <denis.osterland@xxxxxxxxx>
>>> Cc: barebox@xxxxxxxxxxxxxxxxxxx; Denis OSTERLAND-HEIM
>>> <denis.osterland@xxxxxxxxx>; Alexander Dahl <ada@xxxxxxxxxxx>
>>> Subject: [EXT] Re: [PATCH v2 2/2] raspi: fixup additional vc created
>>> nodes
>>>
>>> [EXTERNAL EMAIL]
>>>
>>>
>>> Hello Roland,
>>>
>>> On 19.02.24 20:14, Roland Hieber wrote:
>>>> Hi,
>>>>
>>>> On Mon, Sep 25, 2023 at 01:10:05PM +0200, Denis Osterland-Heim wrote:
>>>>> From: Denis OSTERLAND-HEIM <denis.osterland@xxxxxxxxx>
>>>>>
>>>>> The video core creates some additional nodes.
>>>>> This code takes over this values.
>>>>> The /hat node is only there if an raspi hat with EEPROM is detected.
>>>>>
>>>>> Signed-off-by: Denis OSTERLAND-HEIM <denis.osterland@xxxxxxxxx>
>>>>> Acked-by: Ahmad Fatoum <a.fatoum@xxxxxxxxxxxxxx>
>>>>> ---
>>>>> arch/arm/boards/raspberry-pi/rpi-common.c | 39
>>>>> +++++++++++++++++------
>>>>> 1 file changed, 30 insertions(+), 9 deletions(-)
>>>>>
>>>>> diff --git a/arch/arm/boards/raspberry-pi/rpi-common.c
>>>>> b/arch/arm/boards/raspberry-pi/rpi-common.c
>>>>> index ceafd55a56..713fad78c9 100644
>>>>> --- a/arch/arm/boards/raspberry-pi/rpi-common.c
>>>>> +++ b/arch/arm/boards/raspberry-pi/rpi-common.c
>>>>> @@ -264,19 +264,37 @@ static enum reset_src_type
>>>>> rpi_decode_pm_rsts(struct device_node *chosen,
>>>>>
>>>>> static int rpi_vc_fdt_fixup(struct device_node *root, void *data)
>>>>> {
>>>>> - const struct device_node *vc_chosen = data;
>>>>> - struct device_node *chosen;
>>>>> + const struct device_node *vc_node = data;
>>>>> + struct device_node *node;
>>>>> + struct property *pp;
>>>>>
>>>>> - chosen = of_create_node(root, "/chosen");
>>>>> - if (!chosen)
>>>>> + node = of_create_node(root, vc_node->full_name);
>>>>> + if (!node)
>>>>> return -ENOMEM;
>>>>>
>>>>> - of_copy_property(vc_chosen, "overlay_prefix", chosen);
>>>>> - of_copy_property(vc_chosen, "os_prefix", chosen);
>>>>> + for_each_property_of_node(vc_node, pp)
>>>>> + of_copy_property(vc_node, pp->name, node);
>>>>>
>>>>> return 0;
>>>>> }
>>>>>
>>>>> +static struct device_node *register_vc_fixup(struct device_node
>>>>> +*root,
>>>>> + const char *path) {
>>>>> + struct device_node *ret, *tmp;
>>>>> +
>>>>> + ret = of_find_node_by_path_from(root, path);
>>>>> + if (ret) {
>>>>> + tmp = of_dup(ret);
>>>>> + tmp->full_name = xstrdup(ret->full_name);
>>>>> + of_register_fixup(rpi_vc_fdt_fixup, tmp);
>>>>> + } else {
>>>>> + pr_info("no '%s' node found in vc fdtn", path);
>>>>> + }
>>>>> +
>>>>> + return ret;
>>>>> +}
>>>>> +
>>>>> static u32 rpi_boot_mode, rpi_boot_part;
>>>>> /* Extract useful information from the VideoCore FDT we got.
>>>>> * Some parameters are defined here:
>>>>> @@ -300,14 +318,17 @@ static void rpi_vc_fdt_parse(struct
>>>>> device_node
>>>>> *root)
>>>>> free(str);
>>>>> }
>>>>>
>>>>> - chosen = of_find_node_by_path_from(root, "/chosen");
>>>>> + register_vc_fixup(root, "/system");
>>>>> + register_vc_fixup(root, "/axi");
>>>>> + register_vc_fixup(root, "/reserved-memory");
>>>>> + register_vc_fixup(root, "/hat");
>>>>> + register_vc_fixup(root, "/chosen/bootloader");
>>>>> + chosen = register_vc_fixup(root, "/chosen");
>>>>
>>>> This throws a lot of new warnings and errors on our RPi 3B:
>>>>
>>>> barebox 2024.01.0 #1 2024-02-01T00:00:00+00:00
>>>> Buildsystem version: DistroKit-2019.12.0-552-g775624b9f5d6
>>>>
>>>> Board: Raspberry Pi 3 Model B
>>>> deep-probe: supported due to raspberrypi,3-model-b
>>>> netconsole: registered as netconsole-1
>>>> bcm2835-sdhost 3f202000.mmc@xxxxxxxxxxx: registered as mci0
>>>> bcm2835_mci 3f300000.mmc@xxxxxxxxxxx: registered as mci1
>>>> mci0: detected SD card version 2.0
>>>> mci0: registered disk0
>>>> state: New state registered 'state'
>>>> state: Using bucket 0@0x00000000
>>>> malloc space: 0x1d87f620 -> 0x3b0fec3f (size 472.5 MiB)
>>>> WARNING: no property 'serial-number' found in vc fdt's '' node
>>>> no '/system' node found in vc fdt
>>>> no '/axi' node found in vc fdt
>>>> no '/hat' node found in vc fdt
>>>> no '/chosen/bootloader' node found in vc fdt
>>>> WARNING: no property 'bootargs' found in vc fdt's '/chosen' node
>>>> WARNING: no property 'overlay_prefix' found in vc fdt's '/chosen'
>> node
>>>> WARNING: no property 'os_prefix' found in vc fdt's '/chosen' node
>>>> WARNING: 'pm_rsts' value not found in vc fdt
>>>> ERROR: Won't delete root device node
>>>> environment load /boot/barebox.env: No such file or directory
>>>> Maybe you have to create the partition.
>>>>
>>>> Do you have any idea what is going on here?
>>>>
>>>> I also don't see /vc.dtb, which should have been created. I have
>>>> 'vc.kernel: kernel7.img' in the 'global' output, but nothing else
>>>> starting with vc.*.
>>>
>>> I think that a non-existent /vc.dtb is expected if there's no DTs in
>>> the boot partition as is the case with DistroKit (except for rpi4) or
>>> if using barebox-dt-2nd.img.
>>>
>>> I think the info/warning messages should just be dropped.
>>>
>>> Cheers,
>>> Ahmad
>>>
>>>>
>>>> - Roland
>>>>
>>>>> if (!chosen) {
>>>>> pr_err("no '/chosen' node found in vc fdtn");
>>>>> goto out;
>>>>> }
>>>>>
>>>>> - of_register_fixup(rpi_vc_fdt_fixup, of_dup(chosen));
>>>>> -
>>>>> bootloader = of_find_node_by_name(chosen, "bootloader");
>>>>>
>>>>> str = of_read_vc_string(chosen, "bootargs");
>>>>> --
>>>>> 2.39.2
>>>>>
>>>>>
>>>>
>>>
>>
>
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
