Re: imx7d dual core boot

[Sascha Hauer <s.hauer@pengutronix.de>]

On Tue, Apr 14, 2020 at 12:30:40AM +0200, Giorgio wrote:
> Hi Ahmad,
> 
> On 4/7/20 3:43 PM, Ahmad Fatoum wrote:
> > Hello,
> > 
> > On 4/7/20 2:28 PM, Giorgio wrote:
> >>> Great. Even better than hardcoding the CLIENT_DOMAIN.
> >>>
> >> OK.
> >>
> >> To read the current value of DACR, in secure mode, we need a
> >> get_domain(). I would add it to mmu.h, beside the set_domain().
> > 
> > sounds good.
> > 
> >>>> What do you mean with the 'other i.MX7 patches' ?
> >>>
> >>> Didn't you add support for some i.MX7 spi flash image format?
> >>>
> >>
> >> That was an evil hack actually, just to verify why the normal barebox image
> >> didn't worked. To really support booting barebox from the qspi flash
> >> I think we need more *structural* changes to the way barebox starts.
> >> For this I need *at least* some suggestions from someone that really knows
> >> in detail how barebox works and how an image is built, like you or Sascha...
> > 
> > scripts/imx/imx-image.c is what's building the i.MX images. It receives
> > the imxcfg specific to a board as argument. If you have extra configuration
> > for the QSPI, you'll probably need to extend that, either with a new option
> > or maybe by adding new directives to the existing imxcfg format.
> > 
> 
> thank you for the suggestions, I already knew about the imx-image tool even
> if not in detail; to add support for the QSPI boot we must for sure extend
> the code there somehow.
> 
> > What other changes do you think will be necessary?
> >
> I have currently have a qspi-patched barebox image on my QSPI flash that the imx7d
> is able to boot, but only due to an evil hack I only made to see if it was
> the last problem I had.
> According to the imx7d ref. manual (Rev. 1, 01/2018), at page 1233, the boot ROM
> reads out the content of the QSPI flash and expects, at offset 0x00 (watch out here,
> the ref. manual says actually offset 0x400 but it's an error), the QuadSPI Configuration
> Parameters, a 512 bytes long binary table with HW parameters describing the flash.
> Without this table the soc won't boot.
> The problem is here that barebox already uses this offset range with other informations,
> in particular the first 32bits (at offset 0x00) contain the asm opcode of a branch:

This branch shouldn't be necessary to boot from ROM. Normally we set the
entry point of the image to the image start + 0x1000 which is the
address of the first instruction of the binary.

The branch instruction at offset 0x0 in the image is only meant for
starting the image second stage: You can jump directly to the start of
the image without caring where the real start is.

I don't know why the instruction at 0x0 is necessary in your case. I
also don't know how booting with QSPI works. Other boot devices are
actively read from by the CPU, the QSPI controller probably has a
feature to map QSPI NOR contents into the physical address space of the
CPU. Maybe the ROM uses this feature and maybe this causes differences
to the boot flow from other devices.

What have you specified as loadaddr and dcdofs in you flash header
configuration file?

Sascha

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox