* barebox image for an spi flash (like m25p0) on an imx7 soc @ 2020-03-05 8:26 Giorgio Dal Molin 2020-03-05 9:05 ` Ahmad Fatoum 0 siblings, 1 reply; 14+ messages in thread From: Giorgio Dal Molin @ 2020-03-05 8:26 UTC (permalink / raw) To: barebox Hi, does barebox support generating a bootloader image that's able to boot from an spi nor flash (m25p0) on an imx7 soc ? I'm currently able to read/write/erase the flash and I can also 'barebox_update' the image on the flash but the imx7 does not want to boot from it. After comparing a working u-boot image with what 'barebox_update' flashes I think the problem is the barebox image does not have the proper binary layout. Is this use case already implemented or is it still a TODO ? thank you, giorgio _______________________________________________ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: barebox image for an spi flash (like m25p0) on an imx7 soc 2020-03-05 8:26 barebox image for an spi flash (like m25p0) on an imx7 soc Giorgio Dal Molin @ 2020-03-05 9:05 ` Ahmad Fatoum 2020-03-05 9:50 ` Giorgio Dal Molin 0 siblings, 1 reply; 14+ messages in thread From: Ahmad Fatoum @ 2020-03-05 9:05 UTC (permalink / raw) To: Giorgio Dal Molin, barebox On 3/5/20 9:26 AM, Giorgio Dal Molin wrote: > Hi, > > does barebox support generating a bootloader image that's able to boot > from an spi nor flash (m25p0) on an imx7 soc ? > > I'm currently able to read/write/erase the flash and I can also 'barebox_update' > the image on the flash but the imx7 does not want to boot from it. > > After comparing a working u-boot image with what 'barebox_update' flashes I think > the problem is the barebox image does not have the proper binary layout. > > Is this use case already implemented or is it still a TODO ? At what offset is the barebox partition you apply the barebox update to? If the barebox partition offset is not at the very start, try setting offset to zero. Not sure about the i.MX7 specifically, but for other i.MX*, the image already contains padding at the start, so it can directly be written to the medium, unlike U-Boot, which needs to be written at an offset. Cheers Ahmad > > thank you, > giorgio > > _______________________________________________ > barebox mailing list > barebox@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/barebox > -- Pengutronix e.K. | | Steuerwalder Str. 21 | https://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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: barebox image for an spi flash (like m25p0) on an imx7 soc 2020-03-05 9:05 ` Ahmad Fatoum @ 2020-03-05 9:50 ` Giorgio Dal Molin 2020-03-05 13:24 ` Sascha Hauer 2020-03-06 10:11 ` Giorgio Dal Molin 0 siblings, 2 replies; 14+ messages in thread From: Giorgio Dal Molin @ 2020-03-05 9:50 UTC (permalink / raw) To: Ahmad Fatoum, barebox Hi, thank you for the quick reply. here is how I register the bbu for the spi flash: imx7_bbu_internal_spi_i2c_register_handler("SPI", "/dev/m25p0", BBU_HANDLER_FLAG_DEFAULT); and here is a hex dump of the spi flash after bb-updating (I hacked the 'cat' command a bit): imx7d: / cat -h -b 0x450 /dev/m25p0 0000: 0xfe 0x03 0x00 0xea 0xfe 0xff 0xff 0xea 0xfe 0xff 0xff 0xea 0xfe 0xff 0xff 0xea 0010: 0xfe 0xff 0xff 0xea 0xfe 0xff 0xff 0xea 0xfe 0xff 0xff 0xea 0xfe 0xff 0xff 0xea 0020: 0x62 0x61 0x72 0x65 0x62 0x6f 0x78 0x00 0x00 0x00 0x00 0x00 0x00 0xf0 0x06 0x00 0030: 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0040: 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0050: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 ... < zeros > ... 03f0: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0400: 0xd1 0x00 0x20 0x40 0x00 0x10 0x00 0x80 0x00 0x00 0x00 0x00 0x2c 0x04 0x00 0x80 0410: 0x20 0x04 0x00 0x80 0x00 0x04 0x00 0x80 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0420: 0x00 0x00 0x00 0x80 0x00 0xf0 0x06 0x00 0x00 0x00 0x00 0x00 0xd2 0x01 0xbc 0x40 0430: 0xcc 0x01 0x6c 0x04 0x30 0x34 0x00 0x04 0x0f 0x40 0x00 0x05 0x30 0x39 0x10 0x00 0440: 0x00 0x00 0x00 0x02 0x30 0x7a 0x00 0x00 0x01 0x04 0x00 0x01 0x30 0x7a 0x01 0xa0 It seems 'reasonable': there's a 0x400 bytes flash header and then the actual image starts, but it does not boot. The following dump is a booting u-boot image, flashed from barebox with the commands: imx7d: tftp ub.bin imx7d: erase /dev/m25p0 imx7d: cp ub.bin /dev/m25p0 imx7d: / cat -h -b 0x450 /dev/m25p0 0000: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0010: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x02 0020: 0x03 0x00 0x00 0x00 0x03 0x00 0x00 0x00 0x00 0x00 0x00 0x02 0x00 0x00 0x00 0x00 0030: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0040: 0x02 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0050: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0060: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x3b 0x04 0x18 0x08 0x08 0x0d 0x04 0x1d 0070: 0x00 0x24 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0080: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 ... < zeros > ... 0150: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0160: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x01 0x00 0x00 0x01 0x00 0x00 0x00 0x00 0170: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0180: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0190: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 01a0: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 01b0: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 01c0: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 01d0: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 01e0: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 01f0: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x01 0xee 0xff 0xc0 0200: 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff ... < ffs > ... 03f0: 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0400: 0xd1 0x00 0x20 0x40 0x00 0x10 0x91 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0410: 0x20 0x04 0x91 0x00 0x00 0x04 0x91 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0420: 0x00 0x00 0x91 0x00 0x00 0xa0 0x00 0x00 0x00 0x00 0x00 0x00 0xd2 0x00 0x04 0x40 0430: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0440: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 The first 4 bites at offset 0x400 are the same but then the u-boot working image is different. ub: 0400: 0xd1 0x00 0x20 0x40 0x00 0x10 0x91 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 bb: 0400: 0xd1 0x00 0x20 0x40 0x00 0x10 0x00 0x80 0x00 0x00 0x00 0x00 0x2c 0x04 0x00 0x80 Digging a bit in the IMX7DRM.pdf I found the table at 6.6.6.3 'QuadSPI configuration parameters': the table seems SPI-specific so it should be generated only in the special case of an SPI barebox image. giorgio > On March 5, 2020 at 10:05 AM Ahmad Fatoum <a.fatoum@pengutronix.de> wrote: > > > On 3/5/20 9:26 AM, Giorgio Dal Molin wrote: > > Hi, > > > > does barebox support generating a bootloader image that's able to boot > > from an spi nor flash (m25p0) on an imx7 soc ? > > > > I'm currently able to read/write/erase the flash and I can also 'barebox_update' > > the image on the flash but the imx7 does not want to boot from it. > > > > After comparing a working u-boot image with what 'barebox_update' flashes I think > > the problem is the barebox image does not have the proper binary layout. > > > > Is this use case already implemented or is it still a TODO ? > > At what offset is the barebox partition you apply the barebox update to? > If the barebox partition offset is not at the very start, try setting offset > to zero. > > Not sure about the i.MX7 specifically, but for other i.MX*, the image already > contains padding at the start, so it can directly be written to the medium, unlike > U-Boot, which needs to be written at an offset. > > Cheers > Ahmad > > > > > thank you, > > giorgio > > > > _______________________________________________ > > barebox mailing list > > barebox@lists.infradead.org > > http://lists.infradead.org/mailman/listinfo/barebox > > > > > -- > Pengutronix e.K. | | > Steuerwalder Str. 21 | https://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 _______________________________________________ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: barebox image for an spi flash (like m25p0) on an imx7 soc 2020-03-05 9:50 ` Giorgio Dal Molin @ 2020-03-05 13:24 ` Sascha Hauer 2020-03-05 13:54 ` Giorgio Dal Molin 2020-03-06 10:11 ` Giorgio Dal Molin 1 sibling, 1 reply; 14+ messages in thread From: Sascha Hauer @ 2020-03-05 13:24 UTC (permalink / raw) To: Giorgio Dal Molin; +Cc: barebox, Ahmad Fatoum On Thu, Mar 05, 2020 at 10:50:15AM +0100, Giorgio Dal Molin wrote: > Hi, > > thank you for the quick reply. > > here is how I register the bbu for the spi flash: > > imx7_bbu_internal_spi_i2c_register_handler("SPI", "/dev/m25p0", BBU_HANDLER_FLAG_DEFAULT); > > and here is a hex dump of the spi flash after bb-updating (I hacked the 'cat' command a bit): > > imx7d: / cat -h -b 0x450 /dev/m25p0 There's the 'md' command for this purpose ;) > 0000: 0xfe 0x03 0x00 0xea 0xfe 0xff 0xff 0xea 0xfe 0xff 0xff 0xea 0xfe 0xff 0xff 0xea > 0010: 0xfe 0xff 0xff 0xea 0xfe 0xff 0xff 0xea 0xfe 0xff 0xff 0xea 0xfe 0xff 0xff 0xea > 0020: 0x62 0x61 0x72 0x65 0x62 0x6f 0x78 0x00 0x00 0x00 0x00 0x00 0x00 0xf0 0x06 0x00 > 0030: 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 > 0040: 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 > 0050: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 > ... < zeros > ... > 03f0: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 > 0400: 0xd1 0x00 0x20 0x40 0x00 0x10 0x00 0x80 0x00 0x00 0x00 0x00 0x2c 0x04 0x00 0x80 > 0410: 0x20 0x04 0x00 0x80 0x00 0x04 0x00 0x80 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 > 0420: 0x00 0x00 0x00 0x80 0x00 0xf0 0x06 0x00 0x00 0x00 0x00 0x00 0xd2 0x01 0xbc 0x40 > 0430: 0xcc 0x01 0x6c 0x04 0x30 0x34 0x00 0x04 0x0f 0x40 0x00 0x05 0x30 0x39 0x10 0x00 > 0440: 0x00 0x00 0x00 0x02 0x30 0x7a 0x00 0x00 0x01 0x04 0x00 0x01 0x30 0x7a 0x01 0xa0 > > It seems 'reasonable': there's a 0x400 bytes flash header and then the actual image > starts, but it does not boot. ... > 03f0: 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff > 0400: 0xd1 0x00 0x20 0x40 0x00 0x10 0x91 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 > 0410: 0x20 0x04 0x91 0x00 0x00 0x04 0x91 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 > 0420: 0x00 0x00 0x91 0x00 0x00 0xa0 0x00 0x00 0x00 0x00 0x00 0x00 0xd2 0x00 0x04 0x40 > 0430: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 > 0440: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 > > > The first 4 bites at offset 0x400 are the same but then the u-boot working image is > different. Where do you have the SDRAM setup? The U-Boot snippet loads into internal SRAM which looks like the SDRAM setup is done in code. The barebox image above loads into SDRAM which of course requires that you have setup the SDRAM in the DCD table. 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: barebox image for an spi flash (like m25p0) on an imx7 soc 2020-03-05 13:24 ` Sascha Hauer @ 2020-03-05 13:54 ` Giorgio Dal Molin 2020-03-05 14:20 ` Rouven Czerwinski 0 siblings, 1 reply; 14+ messages in thread From: Giorgio Dal Molin @ 2020-03-05 13:54 UTC (permalink / raw) To: Sascha Hauer; +Cc: barebox, Ahmad Fatoum Hi Sascha, > On March 5, 2020 at 2:24 PM Sascha Hauer <s.hauer@pengutronix.de> wrote: > > > On Thu, Mar 05, 2020 at 10:50:15AM +0100, Giorgio Dal Molin wrote: > > Hi, > > > > thank you for the quick reply. > > > > here is how I register the bbu for the spi flash: > > > > imx7_bbu_internal_spi_i2c_register_handler("SPI", "/dev/m25p0", BBU_HANDLER_FLAG_DEFAULT); > > > > and here is a hex dump of the spi flash after bb-updating (I hacked the 'cat' command a bit): > > > > imx7d: / cat -h -b 0x450 /dev/m25p0 > > There's the 'md' command for this purpose ;) > > > 0000: 0xfe 0x03 0x00 0xea 0xfe 0xff 0xff 0xea 0xfe 0xff 0xff 0xea 0xfe 0xff 0xff 0xea > > 0010: 0xfe 0xff 0xff 0xea 0xfe 0xff 0xff 0xea 0xfe 0xff 0xff 0xea 0xfe 0xff 0xff 0xea > > 0020: 0x62 0x61 0x72 0x65 0x62 0x6f 0x78 0x00 0x00 0x00 0x00 0x00 0x00 0xf0 0x06 0x00 > > 0030: 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 > > 0040: 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 > > 0050: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 > > ... < zeros > ... > > 03f0: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 > > 0400: 0xd1 0x00 0x20 0x40 0x00 0x10 0x00 0x80 0x00 0x00 0x00 0x00 0x2c 0x04 0x00 0x80 > > 0410: 0x20 0x04 0x00 0x80 0x00 0x04 0x00 0x80 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 > > 0420: 0x00 0x00 0x00 0x80 0x00 0xf0 0x06 0x00 0x00 0x00 0x00 0x00 0xd2 0x01 0xbc 0x40 > > 0430: 0xcc 0x01 0x6c 0x04 0x30 0x34 0x00 0x04 0x0f 0x40 0x00 0x05 0x30 0x39 0x10 0x00 > > 0440: 0x00 0x00 0x00 0x02 0x30 0x7a 0x00 0x00 0x01 0x04 0x00 0x01 0x30 0x7a 0x01 0xa0 > > > > It seems 'reasonable': there's a 0x400 bytes flash header and then the actual image > > starts, but it does not boot. > > ... > > > 03f0: 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff > > 0400: 0xd1 0x00 0x20 0x40 0x00 0x10 0x91 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 > > 0410: 0x20 0x04 0x91 0x00 0x00 0x04 0x91 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 > > 0420: 0x00 0x00 0x91 0x00 0x00 0xa0 0x00 0x00 0x00 0x00 0x00 0x00 0xd2 0x00 0x04 0x40 > > 0430: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 > > 0440: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 > > > > > > The first 4 bites at offset 0x400 are the same but then the u-boot working image is > > different. > > Where do you have the SDRAM setup? The U-Boot snippet loads into > internal SRAM which looks like the SDRAM setup is done in code. The > barebox image above loads into SDRAM which of course requires that you > have setup the SDRAM in the DCD table. > Yes, this is right, u-boot does not have a DCD, they init the soc (ddr cntr) in the bootloader self. The DCD I use in barebox works when I upload the image with the imx-usb-loader: root [ /tmp ]# /tmp/bbuild/arm32/scripts/imx/imx-usb-loader /tmp/bbuild/arm32/barebox-flash-image found i.MX7S USB device [15a2:0076] main dcd length 1bc DCD write: sub dcd length: 0x016c, flags: 0x04 DCD check condition 3 on address 0x307900c4 DCD write: sub dcd length: 0x0034, flags: 0x04 DCD check condition 3 on address 0x307a0004 loading binary file(/tmp/bbuild/arm32/barebox-flash-image) to 0x80000000, skip=0x0, fsize=456157 type=170... binary file successfully loaded jumping to 0x80000400 The same barebox image on the spi flash does not work; unfortunately I have no debug messages in that case, I just see that the u-boot image boots so the HW is OK. giorgio > 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 _______________________________________________ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: barebox image for an spi flash (like m25p0) on an imx7 soc 2020-03-05 13:54 ` Giorgio Dal Molin @ 2020-03-05 14:20 ` Rouven Czerwinski 2020-03-05 17:11 ` Giorgio 0 siblings, 1 reply; 14+ messages in thread From: Rouven Czerwinski @ 2020-03-05 14:20 UTC (permalink / raw) To: Giorgio Dal Molin, Sascha Hauer; +Cc: barebox, Ahmad Fatoum On Thu, 2020-03-05 at 14:54 +0100, Giorgio Dal Molin wrote: > Hi Sascha, > > > > On March 5, 2020 at 2:24 PM Sascha Hauer <s.hauer@pengutronix.de> wrote: > > > > > > On Thu, Mar 05, 2020 at 10:50:15AM +0100, Giorgio Dal Molin wrote: > > > Hi, > > > > > > thank you for the quick reply. > > > > > > here is how I register the bbu for the spi flash: > > > > > > imx7_bbu_internal_spi_i2c_register_handler("SPI", "/dev/m25p0", BBU_HANDLER_FLAG_DEFAULT); > > > > > > and here is a hex dump of the spi flash after bb-updating (I hacked the 'cat' command a bit): > > > > > > imx7d: / cat -h -b 0x450 /dev/m25p0 > > > > There's the 'md' command for this purpose ;) > > > > > 0000: 0xfe 0x03 0x00 0xea 0xfe 0xff 0xff 0xea 0xfe 0xff 0xff 0xea 0xfe 0xff 0xff 0xea > > > 0010: 0xfe 0xff 0xff 0xea 0xfe 0xff 0xff 0xea 0xfe 0xff 0xff 0xea 0xfe 0xff 0xff 0xea > > > 0020: 0x62 0x61 0x72 0x65 0x62 0x6f 0x78 0x00 0x00 0x00 0x00 0x00 0x00 0xf0 0x06 0x00 > > > 0030: 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 > > > 0040: 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 > > > 0050: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 > > > ... < zeros > ... > > > 03f0: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 > > > 0400: 0xd1 0x00 0x20 0x40 0x00 0x10 0x00 0x80 0x00 0x00 0x00 0x00 0x2c 0x04 0x00 0x80 > > > 0410: 0x20 0x04 0x00 0x80 0x00 0x04 0x00 0x80 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 > > > 0420: 0x00 0x00 0x00 0x80 0x00 0xf0 0x06 0x00 0x00 0x00 0x00 0x00 0xd2 0x01 0xbc 0x40 > > > 0430: 0xcc 0x01 0x6c 0x04 0x30 0x34 0x00 0x04 0x0f 0x40 0x00 0x05 0x30 0x39 0x10 0x00 > > > 0440: 0x00 0x00 0x00 0x02 0x30 0x7a 0x00 0x00 0x01 0x04 0x00 0x01 0x30 0x7a 0x01 0xa0 > > > > > > It seems 'reasonable': there's a 0x400 bytes flash header and then the actual image > > > starts, but it does not boot. > > > > ... > > > > > 03f0: 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff > > > 0400: 0xd1 0x00 0x20 0x40 0x00 0x10 0x91 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 > > > 0410: 0x20 0x04 0x91 0x00 0x00 0x04 0x91 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 > > > 0420: 0x00 0x00 0x91 0x00 0x00 0xa0 0x00 0x00 0x00 0x00 0x00 0x00 0xd2 0x00 0x04 0x40 > > > 0430: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 > > > 0440: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 > > > > > > > > > The first 4 bites at offset 0x400 are the same but then the u-boot working image is > > > different. > > > > Where do you have the SDRAM setup? The U-Boot snippet loads into > > internal SRAM which looks like the SDRAM setup is done in code. The > > barebox image above loads into SDRAM which of course requires that you > > have setup the SDRAM in the DCD table. > > > > Yes, this is right, u-boot does not have a DCD, they init the soc (ddr cntr) > in the bootloader self. > > The DCD I use in barebox works when I upload the image with the imx-usb-loader: > > root [ /tmp ]# /tmp/bbuild/arm32/scripts/imx/imx-usb-loader /tmp/bbuild/arm32/barebox-flash-image > found i.MX7S USB device [15a2:0076] > main dcd length 1bc > DCD write: sub dcd length: 0x016c, flags: 0x04 > DCD check condition 3 on address 0x307900c4 > DCD write: sub dcd length: 0x0034, flags: 0x04 > DCD check condition 3 on address 0x307a0004 > loading binary file(/tmp/bbuild/arm32/barebox-flash-image) to 0x80000000, skip=0x0, fsize=456157 type=170... > binary file successfully loaded > jumping to 0x80000400 > > > The same barebox image on the spi flash does not work; unfortunately I have no debug > messages in that case, I just see that the u-boot image boots so the HW is OK. At least on i.MX6 there is a list of valid dcd address ranges. imx-usb- loader is different, since the values are written by the tool and not by the ROM code. The ROM code will refuse to boot if values are outside of the valid ranges, maybe this is the case in your DCD table? - Rouven _______________________________________________ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: barebox image for an spi flash (like m25p0) on an imx7 soc 2020-03-05 14:20 ` Rouven Czerwinski @ 2020-03-05 17:11 ` Giorgio 2020-03-06 8:41 ` Giorgio Dal Molin 0 siblings, 1 reply; 14+ messages in thread From: Giorgio @ 2020-03-05 17:11 UTC (permalink / raw) To: Rouven Czerwinski; +Cc: barebox, Ahmad Fatoum Hi Rouven, thank you for your suggestion about the addresses in the DTD. The DTD I'm using is actually rather simple, tomorrow I'll try to remove everything not absolutely necessary and see if it helps. giorgio On 3/5/20 3:20 PM, Rouven Czerwinski wrote: > On Thu, 2020-03-05 at 14:54 +0100, Giorgio Dal Molin wrote: >> Hi Sascha, >> >> >>> On March 5, 2020 at 2:24 PM Sascha Hauer <s.hauer@pengutronix.de> wrote: >>> >>> >>> On Thu, Mar 05, 2020 at 10:50:15AM +0100, Giorgio Dal Molin wrote: >>>> Hi, >>>> >>>> thank you for the quick reply. >>>> >>>> here is how I register the bbu for the spi flash: >>>> >>>> imx7_bbu_internal_spi_i2c_register_handler("SPI", "/dev/m25p0", BBU_HANDLER_FLAG_DEFAULT); >>>> >>>> and here is a hex dump of the spi flash after bb-updating (I hacked the 'cat' command a bit): >>>> >>>> imx7d: / cat -h -b 0x450 /dev/m25p0 >>> >>> There's the 'md' command for this purpose ;) >>> >>>> 0000: 0xfe 0x03 0x00 0xea 0xfe 0xff 0xff 0xea 0xfe 0xff 0xff 0xea 0xfe 0xff 0xff 0xea >>>> 0010: 0xfe 0xff 0xff 0xea 0xfe 0xff 0xff 0xea 0xfe 0xff 0xff 0xea 0xfe 0xff 0xff 0xea >>>> 0020: 0x62 0x61 0x72 0x65 0x62 0x6f 0x78 0x00 0x00 0x00 0x00 0x00 0x00 0xf0 0x06 0x00 >>>> 0030: 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 >>>> 0040: 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 >>>> 0050: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 >>>> ... < zeros > ... >>>> 03f0: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 >>>> 0400: 0xd1 0x00 0x20 0x40 0x00 0x10 0x00 0x80 0x00 0x00 0x00 0x00 0x2c 0x04 0x00 0x80 >>>> 0410: 0x20 0x04 0x00 0x80 0x00 0x04 0x00 0x80 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 >>>> 0420: 0x00 0x00 0x00 0x80 0x00 0xf0 0x06 0x00 0x00 0x00 0x00 0x00 0xd2 0x01 0xbc 0x40 >>>> 0430: 0xcc 0x01 0x6c 0x04 0x30 0x34 0x00 0x04 0x0f 0x40 0x00 0x05 0x30 0x39 0x10 0x00 >>>> 0440: 0x00 0x00 0x00 0x02 0x30 0x7a 0x00 0x00 0x01 0x04 0x00 0x01 0x30 0x7a 0x01 0xa0 >>>> >>>> It seems 'reasonable': there's a 0x400 bytes flash header and then the actual image >>>> starts, but it does not boot. >>> >>> ... >>> >>>> 03f0: 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff >>>> 0400: 0xd1 0x00 0x20 0x40 0x00 0x10 0x91 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 >>>> 0410: 0x20 0x04 0x91 0x00 0x00 0x04 0x91 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 >>>> 0420: 0x00 0x00 0x91 0x00 0x00 0xa0 0x00 0x00 0x00 0x00 0x00 0x00 0xd2 0x00 0x04 0x40 >>>> 0430: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 >>>> 0440: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 >>>> >>>> >>>> The first 4 bites at offset 0x400 are the same but then the u-boot working image is >>>> different. >>> >>> Where do you have the SDRAM setup? The U-Boot snippet loads into >>> internal SRAM which looks like the SDRAM setup is done in code. The >>> barebox image above loads into SDRAM which of course requires that you >>> have setup the SDRAM in the DCD table. >>> >> >> Yes, this is right, u-boot does not have a DCD, they init the soc (ddr cntr) >> in the bootloader self. >> >> The DCD I use in barebox works when I upload the image with the imx-usb-loader: >> >> root [ /tmp ]# /tmp/bbuild/arm32/scripts/imx/imx-usb-loader /tmp/bbuild/arm32/barebox-flash-image >> found i.MX7S USB device [15a2:0076] >> main dcd length 1bc >> DCD write: sub dcd length: 0x016c, flags: 0x04 >> DCD check condition 3 on address 0x307900c4 >> DCD write: sub dcd length: 0x0034, flags: 0x04 >> DCD check condition 3 on address 0x307a0004 >> loading binary file(/tmp/bbuild/arm32/barebox-flash-image) to 0x80000000, skip=0x0, fsize=456157 type=170... >> binary file successfully loaded >> jumping to 0x80000400 >> >> >> The same barebox image on the spi flash does not work; unfortunately I have no debug >> messages in that case, I just see that the u-boot image boots so the HW is OK. > > At least on i.MX6 there is a list of valid dcd address ranges. imx-usb- > loader is different, since the values are written by the tool and not > by the ROM code. The ROM code will refuse to boot if values are outside > of the valid ranges, maybe this is the case in your DCD table? > > - Rouven > _______________________________________________ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: barebox image for an spi flash (like m25p0) on an imx7 soc 2020-03-05 17:11 ` Giorgio @ 2020-03-06 8:41 ` Giorgio Dal Molin 2020-03-06 13:01 ` Sascha Hauer 0 siblings, 1 reply; 14+ messages in thread From: Giorgio Dal Molin @ 2020-03-06 8:41 UTC (permalink / raw) To: Rouven Czerwinski; +Cc: barebox Hi all, I've just double checked the reg=val entries I have in my DTD for the imx7d but could not find anything wrong with it, it is very similar to the 'arch/arm/mach-imx/include/mach/flash-header/imx7d-ddr-sabresd.imxcfg'. What I don't understand is the absolute address of the DTD present at offset 0x40c: in my barebox image it is 0x8000042c: when the rom code in the imx7 reads the image from the qspi flash it must transfer it to the OCRAM (0x00910000) because it is the only memory that works at this early stage of the boot process; but then, when it searches for the DCD it finds its absolute address, at offset 040c, to be 0x8000042c; but this address is on the DDR space that is still not configured and so cannot be accessed. Here is a hex dump of the barebox image I'm using: ... 0400: 0xd1 0x00 0x20 0x40 0x00 0x10 0x00 0x80 0x00 0x00 0x00 0x00 0x2c 0x04 0x00 0x80 0410: 0x20 0x04 0x00 0x80 0x00 0x04 0x00 0x80 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0420: 0x00 0x00 0x00 0x80 0x00 0x00 0x07 0x00 0x00 0x00 0x00 0x00 0xd2 0x01 0xbc 0x40 0430: 0xcc 0x01 0x6c 0x04 0x30 0x34 0x00 0x04 0x4f 0x40 0x00 0x05 0x30 0x39 0x10 0x00 0440: 0x00 0x00 0x00 0x02 0x30 0x7a 0x00 0x00 0x01 0x04 0x00 0x01 0x30 0x7a 0x01 0xa0 ... giorgio > On March 5, 2020 at 6:11 PM Giorgio <giorgio.nicole@arcor.de> wrote: > > > Hi Rouven, > > thank you for your suggestion about the addresses in the DTD. > The DTD I'm using is actually rather simple, tomorrow I'll try > to remove everything not absolutely necessary and see if it helps. > > giorgio > > On 3/5/20 3:20 PM, Rouven Czerwinski wrote: > > On Thu, 2020-03-05 at 14:54 +0100, Giorgio Dal Molin wrote: > >> Hi Sascha, > >> > >> > >>> On March 5, 2020 at 2:24 PM Sascha Hauer <s.hauer@pengutronix.de> wrote: > >>> > >>> > >>> On Thu, Mar 05, 2020 at 10:50:15AM +0100, Giorgio Dal Molin wrote: > >>>> Hi, > >>>> > >>>> thank you for the quick reply. > >>>> > >>>> here is how I register the bbu for the spi flash: > >>>> > >>>> imx7_bbu_internal_spi_i2c_register_handler("SPI", "/dev/m25p0", BBU_HANDLER_FLAG_DEFAULT); > >>>> > >>>> and here is a hex dump of the spi flash after bb-updating (I hacked the 'cat' command a bit): > >>>> > >>>> imx7d: / cat -h -b 0x450 /dev/m25p0 > >>> > >>> There's the 'md' command for this purpose ;) > >>> > >>>> 0000: 0xfe 0x03 0x00 0xea 0xfe 0xff 0xff 0xea 0xfe 0xff 0xff 0xea 0xfe 0xff 0xff 0xea > >>>> 0010: 0xfe 0xff 0xff 0xea 0xfe 0xff 0xff 0xea 0xfe 0xff 0xff 0xea 0xfe 0xff 0xff 0xea > >>>> 0020: 0x62 0x61 0x72 0x65 0x62 0x6f 0x78 0x00 0x00 0x00 0x00 0x00 0x00 0xf0 0x06 0x00 > >>>> 0030: 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 > >>>> 0040: 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 > >>>> 0050: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 > >>>> ... < zeros > ... > >>>> 03f0: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 > >>>> 0400: 0xd1 0x00 0x20 0x40 0x00 0x10 0x00 0x80 0x00 0x00 0x00 0x00 0x2c 0x04 0x00 0x80 > >>>> 0410: 0x20 0x04 0x00 0x80 0x00 0x04 0x00 0x80 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 > >>>> 0420: 0x00 0x00 0x00 0x80 0x00 0xf0 0x06 0x00 0x00 0x00 0x00 0x00 0xd2 0x01 0xbc 0x40 > >>>> 0430: 0xcc 0x01 0x6c 0x04 0x30 0x34 0x00 0x04 0x0f 0x40 0x00 0x05 0x30 0x39 0x10 0x00 > >>>> 0440: 0x00 0x00 0x00 0x02 0x30 0x7a 0x00 0x00 0x01 0x04 0x00 0x01 0x30 0x7a 0x01 0xa0 > >>>> > >>>> It seems 'reasonable': there's a 0x400 bytes flash header and then the actual image > >>>> starts, but it does not boot. > >>> > >>> ... > >>> > >>>> 03f0: 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff > >>>> 0400: 0xd1 0x00 0x20 0x40 0x00 0x10 0x91 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 > >>>> 0410: 0x20 0x04 0x91 0x00 0x00 0x04 0x91 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 > >>>> 0420: 0x00 0x00 0x91 0x00 0x00 0xa0 0x00 0x00 0x00 0x00 0x00 0x00 0xd2 0x00 0x04 0x40 > >>>> 0430: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 > >>>> 0440: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 > >>>> > >>>> > >>>> The first 4 bites at offset 0x400 are the same but then the u-boot working image is > >>>> different. > >>> > >>> Where do you have the SDRAM setup? The U-Boot snippet loads into > >>> internal SRAM which looks like the SDRAM setup is done in code. The > >>> barebox image above loads into SDRAM which of course requires that you > >>> have setup the SDRAM in the DCD table. > >>> > >> > >> Yes, this is right, u-boot does not have a DCD, they init the soc (ddr cntr) > >> in the bootloader self. > >> > >> The DCD I use in barebox works when I upload the image with the imx-usb-loader: > >> > >> root [ /tmp ]# /tmp/bbuild/arm32/scripts/imx/imx-usb-loader /tmp/bbuild/arm32/barebox-flash-image > >> found i.MX7S USB device [15a2:0076] > >> main dcd length 1bc > >> DCD write: sub dcd length: 0x016c, flags: 0x04 > >> DCD check condition 3 on address 0x307900c4 > >> DCD write: sub dcd length: 0x0034, flags: 0x04 > >> DCD check condition 3 on address 0x307a0004 > >> loading binary file(/tmp/bbuild/arm32/barebox-flash-image) to 0x80000000, skip=0x0, fsize=456157 type=170... > >> binary file successfully loaded > >> jumping to 0x80000400 > >> > >> > >> The same barebox image on the spi flash does not work; unfortunately I have no debug > >> messages in that case, I just see that the u-boot image boots so the HW is OK. > > > > At least on i.MX6 there is a list of valid dcd address ranges. imx-usb- > > loader is different, since the values are written by the tool and not > > by the ROM code. The ROM code will refuse to boot if values are outside > > of the valid ranges, maybe this is the case in your DCD table? > > > > - Rouven > > > > _______________________________________________ > barebox mailing list > barebox@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/barebox _______________________________________________ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: barebox image for an spi flash (like m25p0) on an imx7 soc 2020-03-06 8:41 ` Giorgio Dal Molin @ 2020-03-06 13:01 ` Sascha Hauer 2020-03-06 13:46 ` Giorgio Dal Molin 2020-03-06 17:22 ` Giorgio Dal Molin 0 siblings, 2 replies; 14+ messages in thread From: Sascha Hauer @ 2020-03-06 13:01 UTC (permalink / raw) To: Giorgio Dal Molin; +Cc: barebox, Rouven Czerwinski On Fri, Mar 06, 2020 at 09:41:42AM +0100, Giorgio Dal Molin wrote: > Hi all, > > I've just double checked the reg=val entries I have in my DTD for the imx7d > but could not find anything wrong with it, it is very similar to the > 'arch/arm/mach-imx/include/mach/flash-header/imx7d-ddr-sabresd.imxcfg'. > > What I don't understand is the absolute address of the DTD present at offset 0x40c: > in my barebox image it is 0x8000042c: when the rom code in the imx7 reads the image > from the qspi flash it must transfer it to the OCRAM (0x00910000) because it is > the only memory that works at this early stage of the boot process; but then, when it > searches for the DCD it finds its absolute address, at offset 040c, to be 0x8000042c; > but this address is on the DDR space that is still not configured and so cannot be accessed. > > Here is a hex dump of the barebox image I'm using: > > ... > 0400: 0xd1 0x00 0x20 0x40 0x00 0x10 0x00 0x80 0x00 0x00 0x00 0x00 0x2c 0x04 0x00 0x80 > 0410: 0x20 0x04 0x00 0x80 0x00 0x04 0x00 0x80 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 > 0420: 0x00 0x00 0x00 0x80 0x00 0x00 0x07 0x00 0x00 0x00 0x00 0x00 0xd2 0x01 0xbc 0x40 > 0430: 0xcc 0x01 0x6c 0x04 0x30 0x34 0x00 0x04 0x4f 0x40 0x00 0x05 0x30 0x39 0x10 0x00 > 0440: 0x00 0x00 0x00 0x02 0x30 0x7a 0x00 0x00 0x01 0x04 0x00 0x01 0x30 0x7a 0x01 0xa0 This is quite unreadable. Could you post the output of 'md -s /dev/m25p0 1k+1k' ? 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: barebox image for an spi flash (like m25p0) on an imx7 soc 2020-03-06 13:01 ` Sascha Hauer @ 2020-03-06 13:46 ` Giorgio Dal Molin 2020-03-06 17:22 ` Giorgio Dal Molin 1 sibling, 0 replies; 14+ messages in thread From: Giorgio Dal Molin @ 2020-03-06 13:46 UTC (permalink / raw) To: Sascha Hauer; +Cc: barebox, Rouven Czerwinski Hi Sascha, excuse my difficult to read English. Here is the requested dump: imx7d: / md -s /dev/m25p0 1k+1k 00000400: 402000d1 80001000 00000000 8000042c .. @........,... 00000410: 80000420 80000400 00000000 00000000 ............... 00000420: 80000000 00070000 00000000 40bc01d2 ...............@ 00000430: 046c01cc 04003430 0500404f 00103930 ..l.04..O@..09.. 00000440: 02000000 00007a30 01000401 a0017a30 ....0z......0z.. 00000450: 03004080 a4017a30 20001000 a8017a30 .@..0z..... 0z.. 00000460: 04001080 64007a30 46004000 90047a30 ....0z.d.@.F0z.. 00000470: 01000000 d0007a30 03010200 d4007a30 ....0z......0z.. 00000480: 00006900 dc007a30 04003009 e0007a30 .i..0z...0..0z.. 00000490: 00000804 e4007a30 00001000 f4007a30 ....0z......0z.. 000004a0: 3f030000 00017a30 09080809 04017a30 ...?0z......0z.. 000004b0: 0d020d00 08017a30 07030504 0c017a30 ....0z......0z.. 000004c0: 06200000 10017a30 05020204 14017a30 .. .0z......0z.. 000004d0: 02020303 20017a30 03080000 80017a30 ....0z. ....0z.. 000004e0: 20008000 84017a30 00010002 90017a30 ... 0z......0z.. 000004f0: 04820902 94017a30 03030300 00027a30 ....0z......0z.. 00000500: 1f000000 04027a30 08080800 10027a30 ....0z......0z.. 00000510: 0f0f0000 14027a30 07070707 18027a30 ....0z......0z.. 00000520: 07070707 40027a30 04060006 44027a30 ....0z.@....0z.D 00000530: 01000000 00103930 00000000 00007930 ....09......0y.. 00000540: 400f4217 04007930 00012110 10007930 .B.@0y...!..0y.. 00000550: 07080600 b0007930 7e001010 9c007930 ....0y.....~0y.. 00000560: 6e0d0000 20007930 08080808 30007930 ...n0y. ....0y.0 00000570: 08080808 50007930 10000001 50007930 ....0y.P....0y.P 00000580: 10000000 c0007930 0473400e c0007930 ....0y...@s.0y.. 00000590: 0473440e c0007930 0673440e 1c0c00cf .Ds.0y...Ds..... 000005a0: c4007930 01000000 043400cc c0007930 0y........4.0y.. 000005b0: 0473440e c0007930 0473400e 30413830 .Ds.0y...@s.08A0 000005c0: 00000000 20003430 78010000 30413830 ....04. ...x08A0 000005d0: 02000000 18007930 0f000000 1c0c00cf ....0y.......... 000005e0: 04007a30 01000000 00000000 00000000 0z.............. 000005f0: 00000000 00000000 00000000 00000000 ................ 00000600: 00000000 00000000 00000000 00000000 ................ 00000610: 00000000 00000000 00000000 00000000 ................ 00000620: 00000000 00000000 00000000 00000000 ................ 00000630: 00000000 00000000 00000000 00000000 ................ 00000640: 00000000 00000000 00000000 00000000 ................ 00000650: 00000000 00000000 00000000 00000000 ................ 00000660: 00000000 00000000 00000000 00000000 ................ 00000670: 00000000 00000000 00000000 00000000 ................ 00000680: 00000000 00000000 00000000 00000000 ................ 00000690: 00000000 00000000 00000000 00000000 ................ 000006a0: 00000000 00000000 00000000 00000000 ................ 000006b0: 00000000 00000000 00000000 00000000 ................ 000006c0: 00000000 00000000 00000000 00000000 ................ 000006d0: 00000000 00000000 00000000 00000000 ................ 000006e0: 00000000 00000000 00000000 00000000 ................ 000006f0: 00000000 00000000 00000000 00000000 ................ 00000700: 00000000 00000000 00000000 00000000 ................ 00000710: 00000000 00000000 00000000 00000000 ................ 00000720: 00000000 00000000 00000000 00000000 ................ 00000730: 00000000 00000000 00000000 00000000 ................ 00000740: 00000000 00000000 00000000 00000000 ................ 00000750: 00000000 00000000 00000000 00000000 ................ 00000760: 00000000 00000000 00000000 00000000 ................ 00000770: 00000000 00000000 00000000 00000000 ................ 00000780: 00000000 00000000 00000000 00000000 ................ 00000790: 00000000 00000000 00000000 00000000 ................ 000007a0: 00000000 00000000 00000000 00000000 ................ 000007b0: 00000000 00000000 00000000 00000000 ................ 000007c0: 00000000 00000000 00000000 00000000 ................ 000007d0: 00000000 00000000 00000000 00000000 ................ 000007e0: 00000000 00000000 00000000 00000000 ................ 000007f0: 00000000 00000000 00000000 00000000 ................ I try to rephrase the question: the barebox image, at offset 0x400, has the IVT (Image Vector Table), and that table contains the absolute address of the DCD table (0x8000042c in the previous dump); 0x8000042c is an address in the DDR3 address space, so to read the data at that addresses (the DCD table) the boot rom must have already configured the memory controller of the imx7d soc; but this configuration is in the DCD that is in the still unconfigured DDR3. giorgio > On March 6, 2020 at 2:01 PM Sascha Hauer <s.hauer@pengutronix.de> wrote: > > > On Fri, Mar 06, 2020 at 09:41:42AM +0100, Giorgio Dal Molin wrote: > > Hi all, > > > > I've just double checked the reg=val entries I have in my DTD for the imx7d > > but could not find anything wrong with it, it is very similar to the > > 'arch/arm/mach-imx/include/mach/flash-header/imx7d-ddr-sabresd.imxcfg'. > > > > What I don't understand is the absolute address of the DTD present at offset 0x40c: > > in my barebox image it is 0x8000042c: when the rom code in the imx7 reads the image > > from the qspi flash it must transfer it to the OCRAM (0x00910000) because it is > > the only memory that works at this early stage of the boot process; but then, when it > > searches for the DCD it finds its absolute address, at offset 040c, to be 0x8000042c; > > but this address is on the DDR space that is still not configured and so cannot be accessed. > > > > Here is a hex dump of the barebox image I'm using: > > > > ... > > 0400: 0xd1 0x00 0x20 0x40 0x00 0x10 0x00 0x80 0x00 0x00 0x00 0x00 0x2c 0x04 0x00 0x80 > > 0410: 0x20 0x04 0x00 0x80 0x00 0x04 0x00 0x80 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 > > 0420: 0x00 0x00 0x00 0x80 0x00 0x00 0x07 0x00 0x00 0x00 0x00 0x00 0xd2 0x01 0xbc 0x40 > > 0430: 0xcc 0x01 0x6c 0x04 0x30 0x34 0x00 0x04 0x4f 0x40 0x00 0x05 0x30 0x39 0x10 0x00 > > 0440: 0x00 0x00 0x00 0x02 0x30 0x7a 0x00 0x00 0x01 0x04 0x00 0x01 0x30 0x7a 0x01 0xa0 > > This is quite unreadable. Could you post the output of 'md -s /dev/m25p0 1k+1k' ? > > 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 _______________________________________________ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: barebox image for an spi flash (like m25p0) on an imx7 soc 2020-03-06 13:01 ` Sascha Hauer 2020-03-06 13:46 ` Giorgio Dal Molin @ 2020-03-06 17:22 ` Giorgio Dal Molin 1 sibling, 0 replies; 14+ messages in thread From: Giorgio Dal Molin @ 2020-03-06 17:22 UTC (permalink / raw) To: Sascha Hauer; +Cc: barebox, a.fatoum, Rouven Czerwinski Hi all, I could finally put a barebox image together that's able to boot from the qspi on an imx7d soc ! It is still very much hacked up but it works. The imx7 boots in internal boot mode (BOOT_MODE=0x2) and the eFuses selecting the boot device are as follows (BOOT_CFG): imx7d: / md 0x30350470+1 30350470: 10004000 . The '4' means QSPI as the boot device. Now the bootloader image on the QSPI flash needs to have the 'QSPI Parameters Table' at offset 0x00 (512 bytes long): I cut the table from my working u-boot image; the table depends only on the used flash, not on the bootloader SW. The rest of the image is a 'normal' barebox image, at offset 0x400 starts the IVT as usual. The image composed this way still doesn't boot, because of how the barebox 'boot process' is structured in the early boot stages (this description is fuzzy because I'm not aware of all the details here). What's missing is a jump asm instruction at offset 0x00: 0xea0003fe it overwrites the first 4 bytes of the 'QSPI Parameters Table' but is seems not so dangerous. Here is a dump of the final result: samx7: / md -s /dev/m25p0 0+2k 00000000: ea0003fe 00000000 00000000 00000000 ................ 00000010: 00000000 00000000 00000000 02000000 ................ 00000020: 00000003 00000003 02000000 00000000 ................ 00000030: 00000000 00000000 00000000 00000000 ................ 00000040: 00000002 00000000 00000000 00000000 ................ 00000050: 00000000 00000000 00000000 00000000 ................ 00000060: 00000000 00000000 0818043b 1d040d08 ........;....... 00000070: 00002400 00000000 00000000 00000000 .$.............. 00000080: 00000000 00000000 00000000 00000000 ................ 00000090: 00000000 00000000 00000000 00000000 ................ 000000a0: 00000000 00000000 00000000 00000000 ................ 000000b0: 00000000 00000000 00000000 00000000 ................ 000000c0: 00000000 00000000 00000000 00000000 ................ 000000d0: 00000000 00000000 00000000 00000000 ................ 000000e0: 00000000 00000000 00000000 00000000 ................ 000000f0: 00000000 00000000 00000000 00000000 ................ 00000100: 00000000 00000000 00000000 00000000 ................ 00000110: 00000000 00000000 00000000 00000000 ................ 00000120: 00000000 00000000 00000000 00000000 ................ 00000130: 00000000 00000000 00000000 00000000 ................ 00000140: 00000000 00000000 00000000 00000000 ................ 00000150: 00000000 00000000 00000000 00000000 ................ 00000160: 00000000 00000000 01000001 00000000 ................ 00000170: 00000000 00000000 00000000 00000000 ................ 00000180: 00000000 00000000 00000000 00000000 ................ 00000190: 00000000 00000000 00000000 00000000 ................ 000001a0: 00000000 00000000 00000000 00000000 ................ 000001b0: 00000000 00000000 00000000 00000000 ................ 000001c0: 00000000 00000000 00000000 00000000 ................ 000001d0: 00000000 00000000 00000000 00000000 ................ 000001e0: 00000000 00000000 00000000 00000000 ................ 000001f0: 00000000 00000000 00000000 c0ffee01 ................ 00000200: ffffffff ffffffff ffffffff ffffffff ................ 00000210: ffffffff ffffffff ffffffff ffffffff ................ 00000220: ffffffff ffffffff ffffffff ffffffff ................ 00000230: ffffffff ffffffff ffffffff ffffffff ................ 00000240: ffffffff ffffffff ffffffff ffffffff ................ 00000250: ffffffff ffffffff ffffffff ffffffff ................ 00000260: ffffffff ffffffff ffffffff ffffffff ................ 00000270: ffffffff ffffffff ffffffff ffffffff ................ 00000280: ffffffff ffffffff ffffffff ffffffff ................ 00000290: ffffffff ffffffff ffffffff ffffffff ................ 000002a0: ffffffff ffffffff ffffffff ffffffff ................ 000002b0: ffffffff ffffffff ffffffff ffffffff ................ 000002c0: ffffffff ffffffff ffffffff ffffffff ................ 000002d0: ffffffff ffffffff ffffffff ffffffff ................ 000002e0: ffffffff ffffffff ffffffff ffffffff ................ 000002f0: ffffffff ffffffff ffffffff ffffffff ................ 00000300: ffffffff ffffffff ffffffff ffffffff ................ 00000310: ffffffff ffffffff ffffffff ffffffff ................ 00000320: ffffffff ffffffff ffffffff ffffffff ................ 00000330: ffffffff ffffffff ffffffff ffffffff ................ 00000340: ffffffff ffffffff ffffffff ffffffff ................ 00000350: ffffffff ffffffff ffffffff ffffffff ................ 00000360: ffffffff ffffffff ffffffff ffffffff ................ 00000370: ffffffff ffffffff ffffffff ffffffff ................ 00000380: ffffffff ffffffff ffffffff ffffffff ................ 00000390: ffffffff ffffffff ffffffff ffffffff ................ 000003a0: ffffffff ffffffff ffffffff ffffffff ................ 000003b0: ffffffff ffffffff ffffffff ffffffff ................ 000003c0: ffffffff ffffffff ffffffff ffffffff ................ 000003d0: ffffffff ffffffff ffffffff ffffffff ................ 000003e0: ffffffff ffffffff ffffffff ffffffff ................ 000003f0: ffffffff ffffffff ffffffff ffffffff ................ 00000400: 402000d1 80001000 00000000 8000042c .. @........,... 00000410: 80000420 80000400 00000000 00000000 ............... 00000420: 80000000 00070000 00000000 40bc01d2 ...............@ 00000430: 046c01cc 04003430 0500404f 00103930 ..l.04..O@..09.. 00000440: 02000000 00007a30 01000401 a0017a30 ....0z......0z.. 00000450: 03004080 a4017a30 20001000 a8017a30 .@..0z..... 0z.. 00000460: 04001080 64007a30 46004000 90047a30 ....0z.d.@.F0z.. 00000470: 01000000 d0007a30 03010200 d4007a30 ....0z......0z.. 00000480: 00006900 dc007a30 04003009 e0007a30 .i..0z...0..0z.. 00000490: 00000804 e4007a30 00001000 f4007a30 ....0z......0z.. 000004a0: 3f030000 00017a30 09080809 04017a30 ...?0z......0z.. 000004b0: 0d020d00 08017a30 07030504 0c017a30 ....0z......0z.. 000004c0: 06200000 10017a30 05020204 14017a30 .. .0z......0z.. 000004d0: 02020303 20017a30 03080000 80017a30 ....0z. ....0z.. 000004e0: 20008000 84017a30 00010002 90017a30 ... 0z......0z.. 000004f0: 04820902 94017a30 03030300 00027a30 ....0z......0z.. 00000500: 1f000000 04027a30 08080800 10027a30 ....0z......0z.. 00000510: 0f0f0000 14027a30 07070707 18027a30 ....0z......0z.. 00000520: 07070707 40027a30 04060006 44027a30 ....0z.@....0z.D 00000530: 01000000 00103930 00000000 00007930 ....09......0y.. 00000540: 400f4217 04007930 00012110 10007930 .B.@0y...!..0y.. 00000550: 07080600 b0007930 7e001010 9c007930 ....0y.....~0y.. 00000560: 6e0d0000 20007930 08080808 30007930 ...n0y. ....0y.0 00000570: 08080808 50007930 10000001 50007930 ....0y.P....0y.P 00000580: 10000000 c0007930 0473400e c0007930 ....0y...@s.0y.. 00000590: 0473440e c0007930 0673440e 1c0c00cf .Ds.0y...Ds..... 000005a0: c4007930 01000000 043400cc c0007930 0y........4.0y.. 000005b0: 0473440e c0007930 0473400e 30413830 .Ds.0y...@s.08A0 000005c0: 00000000 20003430 78010000 30413830 ....04. ...x08A0 000005d0: 02000000 18007930 0f000000 1c0c00cf ....0y.......... 000005e0: 04007a30 01000000 00000000 00000000 0z.............. 000005f0: 00000000 00000000 00000000 00000000 ................ 00000600: 00000000 00000000 00000000 00000000 ................ 00000610: 00000000 00000000 00000000 00000000 ................ 00000620: 00000000 00000000 00000000 00000000 ................ ... thank you again for your help, giorgio > On March 6, 2020 at 2:01 PM Sascha Hauer <s.hauer@pengutronix.de> wrote: > > > On Fri, Mar 06, 2020 at 09:41:42AM +0100, Giorgio Dal Molin wrote: > > Hi all, > > > > I've just double checked the reg=val entries I have in my DTD for the imx7d > > but could not find anything wrong with it, it is very similar to the > > 'arch/arm/mach-imx/include/mach/flash-header/imx7d-ddr-sabresd.imxcfg'. > > > > What I don't understand is the absolute address of the DTD present at offset 0x40c: > > in my barebox image it is 0x8000042c: when the rom code in the imx7 reads the image > > from the qspi flash it must transfer it to the OCRAM (0x00910000) because it is > > the only memory that works at this early stage of the boot process; but then, when it > > searches for the DCD it finds its absolute address, at offset 040c, to be 0x8000042c; > > but this address is on the DDR space that is still not configured and so cannot be accessed. > > > > Here is a hex dump of the barebox image I'm using: > > > > ... > > 0400: 0xd1 0x00 0x20 0x40 0x00 0x10 0x00 0x80 0x00 0x00 0x00 0x00 0x2c 0x04 0x00 0x80 > > 0410: 0x20 0x04 0x00 0x80 0x00 0x04 0x00 0x80 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 > > 0420: 0x00 0x00 0x00 0x80 0x00 0x00 0x07 0x00 0x00 0x00 0x00 0x00 0xd2 0x01 0xbc 0x40 > > 0430: 0xcc 0x01 0x6c 0x04 0x30 0x34 0x00 0x04 0x4f 0x40 0x00 0x05 0x30 0x39 0x10 0x00 > > 0440: 0x00 0x00 0x00 0x02 0x30 0x7a 0x00 0x00 0x01 0x04 0x00 0x01 0x30 0x7a 0x01 0xa0 > > This is quite unreadable. Could you post the output of 'md -s /dev/m25p0 1k+1k' ? > > 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 _______________________________________________ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: barebox image for an spi flash (like m25p0) on an imx7 soc 2020-03-05 9:50 ` Giorgio Dal Molin 2020-03-05 13:24 ` Sascha Hauer @ 2020-03-06 10:11 ` Giorgio Dal Molin 2020-03-06 12:59 ` Sascha Hauer 1 sibling, 1 reply; 14+ messages in thread From: Giorgio Dal Molin @ 2020-03-06 10:11 UTC (permalink / raw) To: Ahmad Fatoum, barebox Hi, I think I've found an error in the imx7 ref. manual: the table at 6.6.6.3 'QuadSPI configuration parameters' should be placed at offset 0x00 (the very beginning of the spi flash) and not at offset 0x400 as it is written on the ref. manual !!! This means, if I look at the hex dump of the working u-boot image: 0000: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0010: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x02 0020: 0x03 0x00 0x00 0x00 0x03 0x00 0x00 0x00 0x00 0x00 0x00 0x02 0x00 0x00 0x00 0x00 0030: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0040: 0x02 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0050: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0060: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x3b 0x04 0x18 0x08 0x08 0x0d 0x04 0x1d 0070: 0x00 0x24 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0080: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 ... < zeros > ... 0150: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0160: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x01 0x00 0x00 0x01 0x00 0x00 0x00 0x00 0170: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0180: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0190: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 01a0: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 01b0: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 01c0: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 01d0: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 01e0: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 01f0: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x01 0xee 0xff 0xc0 0200: 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff ... what I see is that qspi parameters table (512 bytes long as described in the manual). I think barebox does not support such an image layout. giorgio > barebox image. > On March 5, 2020 at 10:50 AM Giorgio Dal Molin <giorgio.nicole@arcor.de> wrote: > > > Hi, > > thank you for the quick reply. > > here is how I register the bbu for the spi flash: > > imx7_bbu_internal_spi_i2c_register_handler("SPI", "/dev/m25p0", BBU_HANDLER_FLAG_DEFAULT); > > and here is a hex dump of the spi flash after bb-updating (I hacked the 'cat' command a bit): > > imx7d: / cat -h -b 0x450 /dev/m25p0 > 0000: 0xfe 0x03 0x00 0xea 0xfe 0xff 0xff 0xea 0xfe 0xff 0xff 0xea 0xfe 0xff 0xff 0xea > 0010: 0xfe 0xff 0xff 0xea 0xfe 0xff 0xff 0xea 0xfe 0xff 0xff 0xea 0xfe 0xff 0xff 0xea > 0020: 0x62 0x61 0x72 0x65 0x62 0x6f 0x78 0x00 0x00 0x00 0x00 0x00 0x00 0xf0 0x06 0x00 > 0030: 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 > 0040: 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 > 0050: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 > ... < zeros > ... > 03f0: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 > 0400: 0xd1 0x00 0x20 0x40 0x00 0x10 0x00 0x80 0x00 0x00 0x00 0x00 0x2c 0x04 0x00 0x80 > 0410: 0x20 0x04 0x00 0x80 0x00 0x04 0x00 0x80 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 > 0420: 0x00 0x00 0x00 0x80 0x00 0xf0 0x06 0x00 0x00 0x00 0x00 0x00 0xd2 0x01 0xbc 0x40 > 0430: 0xcc 0x01 0x6c 0x04 0x30 0x34 0x00 0x04 0x0f 0x40 0x00 0x05 0x30 0x39 0x10 0x00 > 0440: 0x00 0x00 0x00 0x02 0x30 0x7a 0x00 0x00 0x01 0x04 0x00 0x01 0x30 0x7a 0x01 0xa0 > > It seems 'reasonable': there's a 0x400 bytes flash header and then the actual image > starts, but it does not boot. > > The following dump is a booting u-boot image, flashed from barebox with the commands: > > imx7d: tftp ub.bin > imx7d: erase /dev/m25p0 > imx7d: cp ub.bin /dev/m25p0 > imx7d: / cat -h -b 0x450 /dev/m25p0 > 0000: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 > 0010: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x02 > 0020: 0x03 0x00 0x00 0x00 0x03 0x00 0x00 0x00 0x00 0x00 0x00 0x02 0x00 0x00 0x00 0x00 > 0030: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 > 0040: 0x02 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 > 0050: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 > 0060: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x3b 0x04 0x18 0x08 0x08 0x0d 0x04 0x1d > 0070: 0x00 0x24 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 > 0080: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 > ... < zeros > ... > 0150: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 > 0160: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x01 0x00 0x00 0x01 0x00 0x00 0x00 0x00 > 0170: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 > 0180: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 > 0190: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 > 01a0: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 > 01b0: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 > 01c0: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 > 01d0: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 > 01e0: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 > 01f0: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x01 0xee 0xff 0xc0 > 0200: 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff > ... < ffs > ... > 03f0: 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff > 0400: 0xd1 0x00 0x20 0x40 0x00 0x10 0x91 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 > 0410: 0x20 0x04 0x91 0x00 0x00 0x04 0x91 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 > 0420: 0x00 0x00 0x91 0x00 0x00 0xa0 0x00 0x00 0x00 0x00 0x00 0x00 0xd2 0x00 0x04 0x40 > 0430: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 > 0440: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 > > > The first 4 bites at offset 0x400 are the same but then the u-boot working image is > different. > > ub: 0400: 0xd1 0x00 0x20 0x40 0x00 0x10 0x91 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 > bb: 0400: 0xd1 0x00 0x20 0x40 0x00 0x10 0x00 0x80 0x00 0x00 0x00 0x00 0x2c 0x04 0x00 0x80 > > Digging a bit in the IMX7DRM.pdf I found the table at 6.6.6.3 'QuadSPI configuration parameters': > the table seems SPI-specific so it should be generated only in the special case of an SPI > barebox image. > > giorgio > > > On March 5, 2020 at 10:05 AM Ahmad Fatoum <a.fatoum@pengutronix.de> wrote: > > > > > > On 3/5/20 9:26 AM, Giorgio Dal Molin wrote: > > > Hi, > > > > > > does barebox support generating a bootloader image that's able to boot > > > from an spi nor flash (m25p0) on an imx7 soc ? > > > > > > I'm currently able to read/write/erase the flash and I can also 'barebox_update' > > > the image on the flash but the imx7 does not want to boot from it. > > > > > > After comparing a working u-boot image with what 'barebox_update' flashes I think > > > the problem is the barebox image does not have the proper binary layout. > > > > > > Is this use case already implemented or is it still a TODO ? > > > > At what offset is the barebox partition you apply the barebox update to? > > If the barebox partition offset is not at the very start, try setting offset > > to zero. > > > > Not sure about the i.MX7 specifically, but for other i.MX*, the image already > > contains padding at the start, so it can directly be written to the medium, unlike > > U-Boot, which needs to be written at an offset. > > > > Cheers > > Ahmad > > > > > > > > thank you, > > > giorgio > > > > > > _______________________________________________ > > > barebox mailing list > > > barebox@lists.infradead.org > > > http://lists.infradead.org/mailman/listinfo/barebox > > > > > > > > > -- > > Pengutronix e.K. | | > > Steuerwalder Str. 21 | https://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 > > _______________________________________________ > barebox mailing list > barebox@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/barebox _______________________________________________ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: barebox image for an spi flash (like m25p0) on an imx7 soc 2020-03-06 10:11 ` Giorgio Dal Molin @ 2020-03-06 12:59 ` Sascha Hauer 2020-03-06 14:08 ` Giorgio Dal Molin 0 siblings, 1 reply; 14+ messages in thread From: Sascha Hauer @ 2020-03-06 12:59 UTC (permalink / raw) To: Giorgio Dal Molin; +Cc: barebox, Ahmad Fatoum On Fri, Mar 06, 2020 at 11:11:16AM +0100, Giorgio Dal Molin wrote: > Hi, > > I think I've found an error in the imx7 ref. manual: the table at 6.6.6.3 'QuadSPI > configuration parameters' should be placed at offset 0x00 (the very beginning of the > spi flash) and not at offset 0x400 as it is written on the ref. manual !!! This seems to be specific to QuadSPI. Are you sure you boot from the QuadSPI controller? There is a driver for that in barebox, but the i.MX7 dts files do not register it. Given that you have written the image with barebox I doubt you are doing QuadSPI. 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: barebox image for an spi flash (like m25p0) on an imx7 soc 2020-03-06 12:59 ` Sascha Hauer @ 2020-03-06 14:08 ` Giorgio Dal Molin 0 siblings, 0 replies; 14+ messages in thread From: Giorgio Dal Molin @ 2020-03-06 14:08 UTC (permalink / raw) To: Sascha Hauer; +Cc: barebox, Ahmad Fatoum Hi, > On March 6, 2020 at 1:59 PM Sascha Hauer <s.hauer@pengutronix.de> wrote: > > > On Fri, Mar 06, 2020 at 11:11:16AM +0100, Giorgio Dal Molin wrote: > > Hi, > > > > I think I've found an error in the imx7 ref. manual: the table at 6.6.6.3 'QuadSPI > > configuration parameters' should be placed at offset 0x00 (the very beginning of the > > spi flash) and not at offset 0x400 as it is written on the ref. manual !!! > > This seems to be specific to QuadSPI. Are you sure you boot from the > QuadSPI controller? There is a driver for that in barebox, but the i.MX7 > dts files do not register it. Given that you have written the image with > barebox I doubt you are doing QuadSPI. > > Sascha Yes, the current barebox master does not have a qspi block in the dts file for the imx7, I had to add it: barebox/dts/src/arm/imx7s.dtsi: ... usdhc3: usdhc@30b60000 { compatible = "fsl,imx7d-usdhc", "fsl,imx6sl-usdhc"; reg = <0x30b60000 0x10000>; interrupts = <GIC_SPI 24 IRQ_TYPE_LEVEL_HIGH>; clocks = <&clks IMX7D_IPG_ROOT_CLK>, <&clks IMX7D_NAND_USDHC_BUS_ROOT_CLK>, <&clks IMX7D_USDHC3_ROOT_CLK>; clock-names = "ipg", "ahb", "per"; bus-width = <4>; status = "disabled"; }; qspi1: spi@30bb0000 { #address-cells = <1>; #size-cells = <0>; compatible = "fsl,imx7d-qspi"; reg = <0x30bb0000 0x10000>, <0x60000000 0x10000000>; reg-names = "QuadSPI", "QuadSPI-memory"; interrupts = <GIC_SPI 107 IRQ_TYPE_LEVEL_HIGH>; clocks = <&clks IMX7D_QSPI_ROOT_CLK>, <&clks IMX7D_QSPI_ROOT_CLK>; clock-names = "qspi_en", "qspi"; status = "disabled"; }; sdma: sdma@30bd0000 { compatible = "fsl,imx7d-sdma", "fsl,imx35-sdma"; reg = <0x30bd0000 0x10000>; interrupts = <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>; clocks = <&clks IMX7D_IPG_ROOT_CLK>, <&clks IMX7D_SDMA_CORE_CLK>; clock-names = "ipg", "ahb"; #dma-cells = <3>; fsl,sdma-ram-script-name = "imx/sdma/sdma-imx7d.bin"; }; ... and in the dts for my board: ... &fec2 { pinctrl-names = "default"; pinctrl-0 = <&pinctrl_enet2>; assigned-clocks = <&clks IMX7D_ENET2_TIME_ROOT_SRC>, <&clks IMX7D_ENET2_TIME_ROOT_CLK>; assigned-clock-parents = <&clks IMX7D_PLL_ENET_MAIN_125M_CLK>; assigned-clock-rates = <0>, <100000000>; phy-mode = "rgmii-id"; phy-handle = <ðphy1>; fsl,magic-packet; status = "okay"; }; &qspi1 { pinctrl-names = "default"; pinctrl-0 = <&pinctrl_qspi1>; status = "okay"; flash0: w25q16dw@0 { #address-cells = <1>; #size-cells = <1>; compatible = "winbond,w25q16dw", "jedec,spi-nor"; spi-max-frequency = <20000000>; // take off one dummy cycle spi-nor,ddr-quad-read-dummy = <5>; reg = <0>; partition@0 { label = "flash_header"; reg = <0x000000 0x400>; }; partition@1 { label = "barebox"; reg = <0x000400 0x100000>; }; }; }; With this setup I can build a barebox image and upload it to the imx7d with the imx-usb-loader: barebox boots and I can access the spi flash through /dev/m25p0. Now, if I erase /dev/m25p0 and copy the binary u-boot image to it then the imx7d boots the u-boot, if I just erase /dev/m25p0 then it doesn't boot anymore. giorgio > -- > 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 _______________________________________________ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2020-03-06 17:22 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-03-05 8:26 barebox image for an spi flash (like m25p0) on an imx7 soc Giorgio Dal Molin 2020-03-05 9:05 ` Ahmad Fatoum 2020-03-05 9:50 ` Giorgio Dal Molin 2020-03-05 13:24 ` Sascha Hauer 2020-03-05 13:54 ` Giorgio Dal Molin 2020-03-05 14:20 ` Rouven Czerwinski 2020-03-05 17:11 ` Giorgio 2020-03-06 8:41 ` Giorgio Dal Molin 2020-03-06 13:01 ` Sascha Hauer 2020-03-06 13:46 ` Giorgio Dal Molin 2020-03-06 17:22 ` Giorgio Dal Molin 2020-03-06 10:11 ` Giorgio Dal Molin 2020-03-06 12:59 ` Sascha Hauer 2020-03-06 14:08 ` Giorgio Dal Molin
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox