[PATCH 07/11] env: Enable SPI flash env for rockchip

[Jagan Teki]

On Fri, Dec 27, 2019 at 4:00 PM Soeren Moch <smoch at web.de> wrote:
>
> Hi!
>
> On 27.12.19 07:50, Jagan Teki wrote:
> > Hi Kever,
> >
> > On Mon, Dec 23, 2019 at 8:04 AM Kever Yang <kever.yang at rock-chips.com> wrote:
> >>
> >> Jagan,
> >>
> >>
> >> On 2019/12/21 下午3:54, Jagan Teki wrote:
> >>> Most of the SPI flash devices in rockchip are 16MiB size.
> >>>
> >>> So, keeping U-Boot proper offset start from 128MiB with 1MiB
> >>> size and then start env of 8KiB would be a compatible location
> >>> between all variants of flash sizes.
> >>>
> >>> This patch add env start from 0x14000 with a size of 8KiB.
> >>
> >> What's the space map in SPI flash suppose to be? Including
> >> tpl/spl/u-boot.itb
> >>
> >> I would prefer to use 128KiB-8KiB as the env start address, we'd better
> >> to avoid the
> >>
> >> risk of overlap between the env space and the firmware space.
> >
> > Here is the 16MiB flash layout, I have used. I can see the loader1
> > (tpl/spl) can be possible to load at 0x0 or 0x32K so I have given the
> > space for it. and 8K env after loader2(u-boot). let me know your
> > thoughts?
>
> Why we cannot use the same layout as what is defined for SD/eMMC:
> http://opensource.rock-chips.com/wiki_Partitions
>
>
>
> >
> >           0x0 - 0x8000,       32K  =>  reserved/loader1
> >     0x8000 - 0x40000,    224K =>  loader1
> >   0x40000 - 0x140000,    1M  =>  loader2
> > 0x140000 - 0x142000,    8K  =>   env
> > 0x142000 - 0x842000,    7M  =>  kernel
> > 0x842000 - 0x853800,  100K =>  dtb
> > 0x853800 -                             =>  root
>
> These small loader1/loader2 partitions may byte us later when newer
> u-boot versions only will fit for SD and not for SPI anymore.

Yes, the initial idea is to reuse the existing SD layout but the SPI
flash is limited in size, and it is further limited in rk3399 boards
(rockpro64, roc-rk3399-pc..). which is 16MiB. So reusing half of the
flash size will occupy for till loader2 in SD scheme.

>
> The reserved space for kernel is already too small for normal kernel
> builds today, not to mention a root filesystem.
>
> Are there any use cases where somebody needs to place boot and root
> partitions on SPI flash?

So, explained above due to size limitation the respective blocks like
kernel, root (we can say initrd) are indeed less-sized partitions.
Moreover SPI flash is not a suitable storage for rootfs in rockchip,
since the boot order start from SPI flash usually board would boot
from flash and then look for SD, eMMC, PCIe NVM for loading big chunk
rootfs.

More or less the idea of above flash layout is to fit properly
with-in-the size boundaries and indeed for small initramfs systems.

Jagan.