| Message ID | 20240212202342.37778-2-twoerner@gmail.com |
|---|---|
| State | New |
| Headers | show |
| Series | [meta-rockchip,1/4] rockchip.wks: specify fstype | expand |
Hi Trevor, On 2/12/24 21:23, Trevor Woerner via lists.yoctoproject.org wrote: > Rockchip defines the expected layout/map of the default storage device. > Fill out the wks description so it matches. > > https://opensource.rock-chips.com/wiki_Partitions > > Signed-off-by: Trevor Woerner <twoerner@gmail.com> > --- > wic/rockchip.wks | 18 ++++++++++++------ > 1 file changed, 12 insertions(+), 6 deletions(-) > > diff --git a/wic/rockchip.wks b/wic/rockchip.wks > index b14ec0d1690a..8dc4d20f2f54 100644 > --- a/wic/rockchip.wks > +++ b/wic/rockchip.wks > @@ -9,16 +9,22 @@ > # wic uses 1KB blocks. The following table uses 512 byte sectors: > # > # Partition Start Sector Number of Sectors > -# loader1 64 8000 (idbloader / U-Boot SPL) > -# reserved1 8064 128 > -# reserved2 8192 8192 > +# loader1 64 7104 (idbloader / U-Boot SPL) > +# vstorage 7168 512 (serial number, MAC address, etc) > +# reserved 7680 384 (not used) > +# reserved1 8064 64 (legacy DRM key) > +# uboot_env 8128 64 (U-Boot environment) > +# reserved2 8192 8192 (legacy parameters, ATAGS, etc) > # loader2 16384 8192 (U-Boot proper) > -# atf 24576 8192 > +# atf 24576 8192 (trusted OS e.g. ATR, OP-TEE, etc) > # boot 32768 229376 > # root 262144 - (suggested) > > -part loader1 --offset 32 --fixed-size 4000K --fstype=none --source rawcopy --sourceparams="file=${SPL_BINARY}" > -part reserved1 --offset 4032 --fixed-size 64K --fstype=none > +part loader1 --offset 32 --fixed-size 3552K --fstype=none --source rawcopy --sourceparams="file=${SPL_BINARY}" > +part vstorage --offset 3584 --fixed-size 256K --fstype=none > +part reserved --offset 3840 --fixed-size 192K --fstype=none > +part reserved1 --offset 4032 --fixed-size 32K --fstype=none > +part uboot_env --offset 4064 --fixed-size 32K --fstype=none > part reserved2 --offset 4096 --fixed-size 4096K --fstype=none > part loader2 --offset 8192 --fixed-size 4096K --fstype=none --source rawcopy --sourceparams="file=u-boot.${UBOOT_SUFFIX}" > part atf --offset 12288 --fixed-size 4096K --fstype=none > This is... quite dangerous. I assume people access raw partitions via their index number, and now they would be changed, making it harder to do partial updates. It depends how one sees this file, but could be seen as immutable for existing partitions to avoid backward compatibility issues. I was wondering whether there is support for partition labels or something like that for raw partitions, but doesn't seem like it. Which is quite odd, wouldn't that kind of information be stored in the partition table for example? Also, maybe use sectors for offsets and fixed-sizes since you document them this way? S is the suffix for it. Random thought, but we could probably also get the env from U-Boot recipe (or any other recipe that generates one) (if one is generated) and install it into uboot_env partition? Cheers, Quentin
On Thu 2024-02-15 @ 06:06:42 PM, Quentin Schulz wrote: > Hi Trevor, > > On 2/12/24 21:23, Trevor Woerner via lists.yoctoproject.org wrote: > > Rockchip defines the expected layout/map of the default storage device. > > Fill out the wks description so it matches. > > > > https://opensource.rock-chips.com/wiki_Partitions > > > > Signed-off-by: Trevor Woerner <twoerner@gmail.com> > > --- > > wic/rockchip.wks | 18 ++++++++++++------ > > 1 file changed, 12 insertions(+), 6 deletions(-) > > > > diff --git a/wic/rockchip.wks b/wic/rockchip.wks > > index b14ec0d1690a..8dc4d20f2f54 100644 > > --- a/wic/rockchip.wks > > +++ b/wic/rockchip.wks > > @@ -9,16 +9,22 @@ > > # wic uses 1KB blocks. The following table uses 512 byte sectors: > > # > > # Partition Start Sector Number of Sectors > > -# loader1 64 8000 (idbloader / U-Boot SPL) > > -# reserved1 8064 128 > > -# reserved2 8192 8192 > > +# loader1 64 7104 (idbloader / U-Boot SPL) > > +# vstorage 7168 512 (serial number, MAC address, etc) > > +# reserved 7680 384 (not used) > > +# reserved1 8064 64 (legacy DRM key) > > +# uboot_env 8128 64 (U-Boot environment) > > +# reserved2 8192 8192 (legacy parameters, ATAGS, etc) > > # loader2 16384 8192 (U-Boot proper) > > -# atf 24576 8192 > > +# atf 24576 8192 (trusted OS e.g. ATR, OP-TEE, etc) > > # boot 32768 229376 > > # root 262144 - (suggested) > > -part loader1 --offset 32 --fixed-size 4000K --fstype=none --source rawcopy --sourceparams="file=${SPL_BINARY}" > > -part reserved1 --offset 4032 --fixed-size 64K --fstype=none > > +part loader1 --offset 32 --fixed-size 3552K --fstype=none --source rawcopy --sourceparams="file=${SPL_BINARY}" > > +part vstorage --offset 3584 --fixed-size 256K --fstype=none > > +part reserved --offset 3840 --fixed-size 192K --fstype=none > > +part reserved1 --offset 4032 --fixed-size 32K --fstype=none > > +part uboot_env --offset 4064 --fixed-size 32K --fstype=none > > part reserved2 --offset 4096 --fixed-size 4096K --fstype=none > > part loader2 --offset 8192 --fixed-size 4096K --fstype=none --source rawcopy --sourceparams="file=u-boot.${UBOOT_SUFFIX}" > > part atf --offset 12288 --fixed-size 4096K --fstype=none > > > > This is... quite dangerous. I assume people access raw partitions via their > index number, and now they would be changed, making it harder to do partial > updates. It depends how one sees this file, but could be seen as immutable > for existing partitions to avoid backward compatibility issues. I don't think that's a huge problem, but I could be wrong. People will see their builds fail, investigate, update, and move on? But I think I saw something in wic about not adding a partition to the table, or not giving it a number? So it might be possible to define these partitions and not change the numbers? I could look into it a bit more. > I was wondering whether there is support for partition labels or something > like that for raw partitions, but doesn't seem like it. Which is quite odd, > wouldn't that kind of information be stored in the partition table for > example? Yes, I noticed some things that should probably be there and aren't, such as the label thing you point out. Also not formatting raw partitions; or not requiring an explicit fstype on raw partitions to keep from formatting them. > Also, maybe use sectors for offsets and fixed-sizes since you document them > this way? S is the suffix for it. > > Random thought, but we could probably also get the env from U-Boot recipe > (or any other recipe that generates one) (if one is generated) and install > it into uboot_env partition? That's exactly where I'm going with this. I already have a spreadsheet listing all the rockchip devices, and their U-Boot environment configurations (location, size, etc) to see which ones come with environment configurations, and to make sure they're all the correct location and size for those that do (they are). I also already have Yocto pieces generating and placing the U-Boot environment in the U-Boot environment partition (via wic) but haven't submitted the patches yet (as well as generating a correct /etc/fw_env.config file. My next step is to add in env support in U-Boot for those missing it.
Hi Trevor, On 2/15/24 20:20, Trevor Woerner wrote: > On Thu 2024-02-15 @ 06:06:42 PM, Quentin Schulz wrote: >> Hi Trevor, >> >> On 2/12/24 21:23, Trevor Woerner via lists.yoctoproject.org wrote: >>> Rockchip defines the expected layout/map of the default storage device. >>> Fill out the wks description so it matches. >>> >>> https://opensource.rock-chips.com/wiki_Partitions >>> >>> Signed-off-by: Trevor Woerner <twoerner@gmail.com> >>> --- >>> wic/rockchip.wks | 18 ++++++++++++------ >>> 1 file changed, 12 insertions(+), 6 deletions(-) >>> >>> diff --git a/wic/rockchip.wks b/wic/rockchip.wks >>> index b14ec0d1690a..8dc4d20f2f54 100644 >>> --- a/wic/rockchip.wks >>> +++ b/wic/rockchip.wks >>> @@ -9,16 +9,22 @@ >>> # wic uses 1KB blocks. The following table uses 512 byte sectors: >>> # >>> # Partition Start Sector Number of Sectors >>> -# loader1 64 8000 (idbloader / U-Boot SPL) >>> -# reserved1 8064 128 >>> -# reserved2 8192 8192 >>> +# loader1 64 7104 (idbloader / U-Boot SPL) >>> +# vstorage 7168 512 (serial number, MAC address, etc) >>> +# reserved 7680 384 (not used) >>> +# reserved1 8064 64 (legacy DRM key) >>> +# uboot_env 8128 64 (U-Boot environment) >>> +# reserved2 8192 8192 (legacy parameters, ATAGS, etc) >>> # loader2 16384 8192 (U-Boot proper) >>> -# atf 24576 8192 >>> +# atf 24576 8192 (trusted OS e.g. ATR, OP-TEE, etc) >>> # boot 32768 229376 >>> # root 262144 - (suggested) >>> -part loader1 --offset 32 --fixed-size 4000K --fstype=none --source rawcopy --sourceparams="file=${SPL_BINARY}" >>> -part reserved1 --offset 4032 --fixed-size 64K --fstype=none >>> +part loader1 --offset 32 --fixed-size 3552K --fstype=none --source rawcopy --sourceparams="file=${SPL_BINARY}" >>> +part vstorage --offset 3584 --fixed-size 256K --fstype=none >>> +part reserved --offset 3840 --fixed-size 192K --fstype=none >>> +part reserved1 --offset 4032 --fixed-size 32K --fstype=none >>> +part uboot_env --offset 4064 --fixed-size 32K --fstype=none >>> part reserved2 --offset 4096 --fixed-size 4096K --fstype=none >>> part loader2 --offset 8192 --fixed-size 4096K --fstype=none --source rawcopy --sourceparams="file=u-boot.${UBOOT_SUFFIX}" >>> part atf --offset 12288 --fixed-size 4096K --fstype=none >>> >> >> This is... quite dangerous. I assume people access raw partitions via their >> index number, and now they would be changed, making it harder to do partial >> updates. It depends how one sees this file, but could be seen as immutable >> for existing partitions to avoid backward compatibility issues. > > I don't think that's a huge problem, but I could be wrong. People will see > their builds fail, investigate, update, and move on? > Why would the builds fail? This is a runtime issue IMO. E.g. they flash idbloader.img to mmcblkXp0 and u-boot.itb to mmcblkXp3 but now they would need to flash the latter to mmcblkXp6. And if they have a device that was flashed with the old partition table and another device with the new partition table, they need some kind of userspace logic to figure out which is which? They could also be flashing at an offset on mmcblkX itself, but then this change wouldn't impact them in any way. > But I think I saw something in wic about not adding a partition to the table, > or not giving it a number? So it might be possible to define these partitions > and not change the numbers? I could look into it a bit more. > That makes sense, but then.. what would the change in this commit actually bring to the table? I guess as documentation? [...] >> Random thought, but we could probably also get the env from U-Boot recipe >> (or any other recipe that generates one) (if one is generated) and install >> it into uboot_env partition? > > That's exactly where I'm going with this. I already have a spreadsheet > listing all the rockchip devices, and their U-Boot environment configurations > (location, size, etc) to see which ones come with environment configurations, > and to make sure they're all the correct location and size for those that do > (they are). I also already have Yocto pieces generating and placing > the U-Boot environment in the U-Boot environment partition (via wic) but > haven't submitted the patches yet (as well as generating a correct > /etc/fw_env.config file. My next step is to add in env support in U-Boot for > those missing it. Cool. Cheers, Quentin
diff --git a/wic/rockchip.wks b/wic/rockchip.wks index b14ec0d1690a..8dc4d20f2f54 100644 --- a/wic/rockchip.wks +++ b/wic/rockchip.wks @@ -9,16 +9,22 @@ # wic uses 1KB blocks. The following table uses 512 byte sectors: # # Partition Start Sector Number of Sectors -# loader1 64 8000 (idbloader / U-Boot SPL) -# reserved1 8064 128 -# reserved2 8192 8192 +# loader1 64 7104 (idbloader / U-Boot SPL) +# vstorage 7168 512 (serial number, MAC address, etc) +# reserved 7680 384 (not used) +# reserved1 8064 64 (legacy DRM key) +# uboot_env 8128 64 (U-Boot environment) +# reserved2 8192 8192 (legacy parameters, ATAGS, etc) # loader2 16384 8192 (U-Boot proper) -# atf 24576 8192 +# atf 24576 8192 (trusted OS e.g. ATR, OP-TEE, etc) # boot 32768 229376 # root 262144 - (suggested) -part loader1 --offset 32 --fixed-size 4000K --fstype=none --source rawcopy --sourceparams="file=${SPL_BINARY}" -part reserved1 --offset 4032 --fixed-size 64K --fstype=none +part loader1 --offset 32 --fixed-size 3552K --fstype=none --source rawcopy --sourceparams="file=${SPL_BINARY}" +part vstorage --offset 3584 --fixed-size 256K --fstype=none +part reserved --offset 3840 --fixed-size 192K --fstype=none +part reserved1 --offset 4032 --fixed-size 32K --fstype=none +part uboot_env --offset 4064 --fixed-size 32K --fstype=none part reserved2 --offset 4096 --fixed-size 4096K --fstype=none part loader2 --offset 8192 --fixed-size 4096K --fstype=none --source rawcopy --sourceparams="file=u-boot.${UBOOT_SUFFIX}" part atf --offset 12288 --fixed-size 4096K --fstype=none
Rockchip defines the expected layout/map of the default storage device. Fill out the wks description so it matches. https://opensource.rock-chips.com/wiki_Partitions Signed-off-by: Trevor Woerner <twoerner@gmail.com> --- wic/rockchip.wks | 18 ++++++++++++------ 1 file changed, 12 insertions(+), 6 deletions(-)