[RFC PATCH 0/4] Introduce global.bootm.root env var for booting via PARTUUID
Robert Karszniewicz
r.karszniewicz at phytec.de
Mon Jul 13 07:18:04 EDT 2020
On 7/9/20 4:14 PM, Sascha Hauer wrote:
> On Tue, Jun 30, 2020 at 03:48:30PM +0200, Robert Karszniewicz wrote:
>> This patch introduces a new env var which specifies which device
>> is the rootfs device to be used in Linux, passed to Linux via bootargs,
>> identified by the rootfs partition's PARTUUID.
>>
>> global.bootm.root supplements global.bootm.appendroot, in that it overrides
>> appendroot's naïve default, which picks the partition that the kernel resides
>> on (global.bootm.image).
>>
>> I don't know if it is the right way, or a good way, but this is the shortest
>> and simplest way that I've found.
>>
>> What do you think of this? And is it generally something that would be
>> accepted, or is this out of scope for barebox?
>>
>> Example:
>> detect mmc2
>> global.bootm.image='/mnt/mmc2.0/zImage'
>> global.bootm.appendroot=1
>> global.bootm.root='/mnt/mmc2.1/'
>
Generally, this was just the shortest possible way to make it basically
work, before I knew if such a feature would be accepted at all.
> Why do you pass the standard mount path here? I would expect /dev/mmc2.1.
>
Agree.
> In 4/4 you mount the root device. I think this should be avoided as it
Agree.
> only works when barebox has support for the rootfs, i.e. it doesn't work
> for XFS or the like.
>
I see.
> Ok, fsdev_set_linux_rootarg() is tied to a filesystem, so maybe we need
> something similar for a cdev.
>
> Generally I think barebox should support this usecase, but I am not
> convinced the approach you took is the right API.
>
So do I understand it correctly, that doing it via a new 'root_dev'
variable is fine, just that the implementation needs to be better?
> Sascha
>
Robert
More information about the barebox
mailing list