Re: [yocto] [meta-rockchip][PATCH 2/4] rockchip.wks: add all Rockchip partitions

[Trevor Woerner <twoerner@gmail.com>]

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.