[EXT] [PATCH] ARM: imx: romapi: Repair FlexSPI NOR boot offset

[Ye Li]

On Thu, 2022-03-31 at 00:27 +0200, Marek Vasut wrote:
> Caution: EXT Email
> 
> On 3/29/22 11:56, Ye Li wrote:
> 
> Hi,
> 
> > 
> > > 
> > > > 
> > > > But once you want to upgrade the
> > > > flash.bin, flexspi configurations will also be erased due to
> > > > the
> > > > block
> > > > size. Then you have to reprogram the configurations with
> > > > flash.bin.
> > > > So most of our customers add the flexspi configurations to
> > > > flash.bin
> > > > head. They don't use so called one image for both SD and
> > > > flexspi.
> > > There are no upstream users of flexspi right now, see above.
> > > 
> > > > 
> > > > 
> > > > As the spl_romapi_get_uboot_base is defined to weak. It is
> > > > better
> > > > to
> > > > overwrite this function for your particular usage.
> > > I would much rather prefer to have one flash.bin which works on
> > > both
> > > SD
> > > card and FlexSPI, on all iMX8M, that is far less confusing. And
> > > since
> > > there are no upstream users of flexspi boot so far, this is how
> > > it
> > > can
> > > still be implemented, consistently.
> > I can think out 3 drawbacks using this one flash.bin for flexspi:
> > 
> > 1. The flexspi configuration header will be erased when you update
> > the
> > flash.bin to flexspi device. In a common usage, this header will
> > combine with flash.bin to a final boot image which is not same with
> > SD.
> This is not correct.
> 
> If you need to update only the flash.bin in SPI NOR without rewriting
> the FCFB header, use 'sf update' with 0x1000 start address:
> dhcp ${loadaddr} 192.168.1.1:flash.bin && \
>    sf update ${loadaddr} 0x1000 ${filesize}
> 
> If you need to update both the flash.bin and generate the FCFB, use
> the
> aforementioned script with sf update using 0x0 start address, i.e.:
> dhcp ${loadaddr} 192.168.1.1:flash.bin ; \
> \
> setexpr sfaddr ${loadaddr} - 0x1000 ; \
> \
> base ${sfaddr} ; \
> mw 0 0 0x400 ; \
> mw 0x400 0x42464346 ; \
> mw 0x404 0x56010000 ; \
> mw 0x40c 00030300 ; \
> mw 0x444 0x00020101 ; \
> mw 0x450 0x10000000 ; \
> mw 0x480 0x0818040b ; \
> mw 0x484 0x24043008 ; \
> mw 0x5c0 0x100 ; \
> mw 0x5c4 0x10000 ; \
> base 0 ; \
> \
> setexpr filesize ${filesize} + 0x1000 ; \
> \
> sf probe && sf update ${sfaddr} 0 ${filesize}
> 
> > 
> > 2. How can users update u-boot.itb only if using this one
> > flash.bin?
> Write u-boot.itb to offset 0x59000 in SPI NOR:
> => sf update ${loadaddr} 0x59000 ${filesize}
> 
> That 0x59000 is ( imx8mp-u-boot.dtsi /imx-boot/blob-ext at 2/offset =
> <0x58000>) + (the SPI NOR flash.bin offset = 0x1000) = 0x59000
> 
> > 
> > With the same offset of SD, it causes the u-boot.itb locates at a
> > offset not block aligned.
> 0x59000 is both 4 kiB and 512 Byte aligned .

4KB is not a erase block size supported by all NOR flash. You should
use 64KB which is default to all.

Same for #1 drawback, 0x1000 offset can't satify the erase block size.
so every time your update flash.bin will need to update flash
configuration header as well, why not combine them together.


> 
> > 
> > 3. Not all iMX8M can support this one flash.bin.  8MM and 8MQ have
> > different IVT. Their flexspi IVT can't work for SD/eMMC.
> What's the difference ? Looking at the MX8MM RM rev.3, FlexSPI boot
> looks very much the same.
> 
No. The IVT structures are same but the base used by the fields in IVT
is changed. So you can't use one image for flexspi and SD, it will fail
to boot.

Another thing is the from imx8mm-u-boot.dtsi. the offset is 0x57c00. it
even does not align with 4KB. 

         binman_uboot: uboot {
             filename = "u-boot.itb";
             offset = <0x57c00>;
             type = "blob-ext";
         };


Best regards,
Ye Li


> (we have no MX8MQ/MX8MM boards which boot from FlexSPI either).
> 
> ...
> 
> I still believe it is better (=less confusing for users) to have one
> unified flash.bin for all boot media.