Hi Sascha, thank you for your help, your last suggestion was the last missing bit in my qspi setup. I had the following wrong parameter in my flash header file: loadaddr 0x80000000 following your hint I changed it to: loadaddr 0x80001000 and now I don't need my evil hack with the branch opcode anymore, I just replace the first 512 bytes with the QuadSPI Configuration Parameters and the resulting modified image just works. If you are interested I can have a look at the imx-image tool to see how this last special step could also be properly implemented, as Ahmad suggested. giorgio On 2020-04-14 09:59, Sascha Hauer wrote: > 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 > _______________________________________________ barebox mailing list barebox@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/barebox
