Hi Jonas,
On Mon, 17 Feb 2025 at 15:10, Jonas Karlman <jo...@kwiboo.se> wrote:
>
> Hi Simon,
>
> On 2025-02-09 22:14, Simon Glass wrote:
> > The rockchip image is written to the media at block 64, which is a 32K
> > offset, so set the skip-at-start property to 0x8000
> >
> > Update CONFIG_SPL_PAD_TO to point to the offset in the image, since
> > Binman is dealing with the 'missing' 32K now.
>
> This confuses me, to me the image is the output binary image. And the
> offset in the image is what SPL_PAD_TO already is referring to.
It is confusing, but there actually isn't any change in where things
are placed in the image. All that is changing is that binman is
handling it for us.
This depends on the binf series ("Honour the skip-at-start property
more faithfully") of which I'm sending a new version.
>
> The help for SPL_PAD_TO mention "Image offset to which the SPL should be
> padded before appending the SPL payload.".
>
> I can be fine with changing it to payload location in storage, however
> do such mass change in a separate series and with a clear explanation
> why SPL_PAD_TO should mean the offset on storage and not offset in the
> output binary image written to storage.
>
> With one patch that just add the skip-at-start prop and adjust to use
> <(CONFIG_SPL_PAD_TO + 0x8000)> for the offset prop. And put the mass
> change to defconfig in a separate patch.
But that would break bisectability, wouldn't it?
>
> Another option could possible be to use SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR
> in a calculation and drop use of the SPL_PAD_TO symbol.
There are too many options and we should really just be using Binman.
But this is a step in the right direction.
>
> Else this blocks others from adding new boards, and/or will break them
> if a defconfig was missed. With a separate series adding a new board can
> just reference the smaller series.
OK, once the binf series is in, then this could go in separately?
>
> Regards,
> Jonas
>
> >
> > Signed-off-by: Simon Glass <s...@chromium.org>
> > ---
> >
> > Changes in v2:
> > - Move this patch to the end of the series
> > - Drop 0x8000 offset for SPI
> >
[..]
Regards,
SImon
