On Tuesday 21 March 2023 20:56:02 Pali Rohár wrote: > On Tuesday 21 March 2023 18:25:56 Pali Rohár wrote: > > On Tuesday 21 March 2023 08:34:24 Martin Rowe wrote: > > > On Mon, 20 Mar 2023 at 21:33, Pali Rohár <p...@kernel.org> wrote: > > > > > > > On Monday 20 March 2023 18:45:01 Pali Rohár wrote: > > > > > On Monday 20 March 2023 12:01:03 Martin Rowe wrote: > > > > > > On Sun, 19 Mar 2023 at 18:20, Pali Rohár <p...@kernel.org> wrote: > > > > > > > > > > > > > On Sunday 19 March 2023 17:47:57 Pali Rohár wrote: > > > > > > > > On Sunday 19 March 2023 03:30:33 Martin Rowe wrote: > > > > > > > > > On Sun, 5 Mar 2023 at 11:55, Pali Rohár <p...@kernel.org> > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > On Sunday 05 March 2023 04:21:42 Martin Rowe wrote: > > > > > > > > > > > On Sat, 4 Mar 2023 at 10:51, Pali Rohár <p...@kernel.org> > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > Improve code for checking strapping pins which specifies > > > > boot > > > > > > > mode > > > > > > > > > > source. > > > > > > > > > > > > > > > > > > > > > > > > Martin, could you test if Clearfog can be still > > > > > > > > > > > > configured > > > > into > > > > > > > UART > > > > > > > > > > > > booting mode via HW switches and if it still works > > > > correctly? > > > > > > > First > > > > > > > > > > > > patch is reverting UART related commit for Clearfog > > > > > > > > > > > > which I > > > > > > > think it > > > > > > > > > > not > > > > > > > > > > > > needed anymore. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Clearfog the logic in the CONFIG_ARMADA_38X ifdef > > > > > > > > > > > before > > > > the > > > > > > > switch > > > > > > > > > > that > > > > > > > > > > > you refactored in cpu.c/get_boot_device is all that gets > > > > > > > processed. It > > > > > > > > > > > decides there is an error and returns BOOT_DEVICE_UART, > > > > probably > > > > > > > because > > > > > > > > > > of > > > > > > > > > > > the invalid boot workaround for broken UART selection that > > > > you > > > > > > > > > > identified. > > > > > > > > > > > > > > > > > > > > Ok, so I figured out correctly how this invalid mode works. > > > > > > > > > > > > > > > > > > > > > UART only works if I use the clearfog_spi_defconfig or if > > > > > > > > > > > I > > > > select > > > > > > > > > > > CONFIG_MVEBU_SPL_BOOT_DEVICE_UART=y. It does not work with > > > > the MMC > > > > > > > or > > > > > > > > > > SATA > > > > > > > > > > > defconfigs. I get the same result without this patch > > > > > > > > > > > series > > > > > > > applied, > > > > > > > > > > though. > > > > > > > > > > > > > > > > > > > > > > The failed cases have the same output (other than kwboot > > > > header > > > > > > > patching > > > > > > > > > > > output) until after sending boot image data is complete. > > > > > > > > > > > The > > > > > > > output stops > > > > > > > > > > > after: > > > > > > > > > > > ================================ > > > > > > > > > > > 98 % > > > > > > > [................................................................. > > > > > > > > > > > ] > > > > > > > > > > > Done > > > > > > > > > > > Finishing transfer > > > > > > > > > > > [Type Ctrl-\ + c to quit] > > > > > > > > > > > ================================ > > > > > > > > > > > > > > > > > > > > This is very strange because > > > > > > > > > > CONFIG_MVEBU_SPL_BOOT_DEVICE_UART > > > > just > > > > > > > > > > instruct mkimage what to put into kwbimage header. > > > > > > > > > > > > > > > > > > > > If I'm looking at the output correctly then SPL was booted, > > > > > > > > > > it > > > > > > > correctly > > > > > > > > > > trained DDR RAM, returned back to bootrom, kwboot continued > > > > sending > > > > > > > main > > > > > > > > > > u-boot and bootrom confirmed that transfer of both SPL and > > > > > > > > > > main > > > > > > > u-boot > > > > > > > > > > is complete. But then there is no output from main u-boot. > > > > > > > > > > > > > > > > > > > > > It looks like an unrelated issue with kwboot.c, which I > > > > > > > > > > > was > > > > sure > > > > > > > was > > > > > > > > > > > working after the last patches but I can no longer > > > > > > > > > > > reproduce > > > > a > > > > > > > successful > > > > > > > > > > > boot. > > > > > > > > > > > > > > > > > > > > Can you check that you are using _both_ mkimage and kwboot > > > > > > > > > > from > > > > > > > version > > > > > > > > > > with applying _all_ my patches recently sent to ML? Because > > > > both > > > > > > > mkimage > > > > > > > > > > and kwboot have fixes for SATA and SDIO images. > > > > > > > > > > > > > > > > > > > > > > > > > > > > I tested using the latest next branch which has those changes > > > > > > > > > in > > > > it. > > > > > > > Steps: > > > > > > > > > - Set UART boot mode on device > > > > > > > > > - make clean > > > > > > > > > - make clearfog_defconfig > > > > > > > > > - make > > > > > > > > > - ./tools/kwboot -b u-boot-with-spl.kwb -t /dev/ttyUSB0 > > > > > > > > > > > > > > > > > > For me it looks like that either mkimage generated incorrect > > > > image size > > > > > > > > > > for SATA or SDIO image. Or kwboot incorrectly parsed that > > > > image size > > > > > > > > > > from kwbimage header and sent smaller image. > > > > > > > > > > > > > > > > > > > > > > > > > > > > <MMC output> > > > > > > > > > ./tools/kwboot -b u-boot-with-spl.kwb -t /dev/ttyUSB0 > > > > > > > > > kwboot version 2023.04-rc4-00339-gcefd0449d6 > > > > > > > > > Detected kwbimage v1 with SDIO boot signature > > > > > > > > > Patching image boot signature to UART > > > > > > > > > Aligning image header to Xmodem block size > > > > > > > > > Sending boot message. Please reboot the target...\ > > > > > > > > > Sending boot image header (113408 bytes)... > > > > > > > > > 0 % > > > > > > > > > > > > > > > > > > > > [......................................................................] > > > > > > > > > <snip> > > > > > > > > > 94 % [.............................................. > > > > > > > > > ] > > > > > > > > > Done > > > > > > > > > > > > > > > > > > U-Boot SPL 2023.04-rc4-00339-gcefd0449d6 (Mar 19 2023 - > > > > > > > > > 12:57:31 > > > > +1000) > > > > > > > > > High speed PHY - Version: 2.0 > > > > > > > > > EEPROM TLV detection failed: Using static config for Clearfog > > > > Pro. > > > > > > > > > Detected Device ID 6828 > > > > > > > > > board SerDes lanes topology details: > > > > > > > > > | Lane # | Speed | Type | > > > > > > > > > -------------------------------- > > > > > > > > > | 0 | 3 | SATA0 | > > > > > > > > > | 1 | 0 | SGMII1 | > > > > > > > > > | 2 | 5 | PCIe1 | > > > > > > > > > | 3 | 5 | USB3 HOST1 | > > > > > > > > > | 4 | 5 | PCIe2 | > > > > > > > > > | 5 | 0 | SGMII2 | > > > > > > > > > -------------------------------- > > > > > > > > > High speed PHY - Ended Successfully > > > > > > > > > mv_ddr: 14.0.0 > > > > > > > > > DDR3 Training Sequence - Switching XBAR Window to FastPath > > > > > > > > > Window > > > > > > > > > mv_ddr: completed successfully > > > > > > > > > Trying to boot from BOOTROM > > > > > > > > > Returning to BootROM (return address 0xffff05c4)... > > > > > > > > > > > > > > > > > > Sending boot image data (474564 bytes)... > > > > > > > > > 0 % > > > > > > > > > > > > > > > > > > > > [......................................................................] > > > > > > > > > <snip> > > > > > > > > > 98 % > > > > > > > [.................................................................... > > > > > > > > > ] > > > > > > > > > Done > > > > > > > > > Finishing transfer > > > > > > > > > [Type Ctrl-\ + c to quit] > > > > > > > > > </MMC output> > > > > > > > > > > > > > > > > > > <MMC sizes> > > > > > > > > > du -b u-boot* > > > > > > > > > 4996828 u-boot > > > > > > > > > 474304 u-boot.bin > > > > > > > > > 15155 u-boot.cfg > > > > > > > > > 19496 u-boot.dtb > > > > > > > > > 474304 u-boot-dtb.bin > > > > > > > > > 474368 u-boot-dtb.img > > > > > > > > > 474368 u-boot.img > > > > > > > > > 1721 u-boot.lds > > > > > > > > > 1069982 u-boot.map > > > > > > > > > 454808 u-boot-nodtb.bin > > > > > > > > > 1307712 u-boot.srec > > > > > > > > > 198841 u-boot.sym > > > > > > > > > 588288 u-boot-with-spl.kwb > > > > > > > > > </MMC sizes> > > > > > > > > > > > > > > > > > > If I make menuconfig and set the boot mode to UART before > > > > > > > > > making > > > > I get: > > > > > > > > > > > > > > > > > > <UART output> > > > > > > > > > ./tools/kwboot -b u-boot-with-spl.kwb -t /dev/ttyUSB0 > > > > > > > > > kwboot version 2023.04-rc4-00339-gcefd0449d6 > > > > > > > > > Detected kwbimage v1 with UART boot signature > > > > > > > > > Aligning image header to Xmodem block size > > > > > > > > > Sending boot message. Please reboot the target...\ > > > > > > > > > Sending boot image header (113408 bytes)... > > > > > > > > > 0 % > > > > > > > > > > > > > > > > > > > > [......................................................................] > > > > > > > > > <snip> > > > > > > > > > 94 % [.............................................. > > > > > > > > > ] > > > > > > > > > Done > > > > > > > > > > > > > > > > > > U-Boot SPL 2023.04-rc4-00339-gcefd0449d6 (Mar 19 2023 - > > > > > > > > > 13:20:48 > > > > +1000) > > > > > > > > > High speed PHY - Version: 2.0 > > > > > > > > > EEPROM TLV detection failed: Using static config for Clearfog > > > > Pro. > > > > > > > > > Detected Device ID 6828 > > > > > > > > > board SerDes lanes topology details: > > > > > > > > > | Lane # | Speed | Type | > > > > > > > > > -------------------------------- > > > > > > > > > | 0 | 3 | SATA0 | > > > > > > > > > | 1 | 0 | SGMII1 | > > > > > > > > > | 2 | 5 | PCIe1 | > > > > > > > > > | 3 | 5 | USB3 HOST1 | > > > > > > > > > | 4 | 5 | PCIe2 | > > > > > > > > > | 5 | 0 | SGMII2 | > > > > > > > > > -------------------------------- > > > > > > > > > High speed PHY - Ended Successfully > > > > > > > > > mv_ddr: 14.0.0 > > > > > > > > > DDR3 Training Sequence - Switching XBAR Window to FastPath > > > > > > > > > Window > > > > > > > > > mv_ddr: completed successfully > > > > > > > > > Trying to boot from BOOTROM > > > > > > > > > Returning to BootROM (return address 0xffff05c4)... > > > > > > > > > > > > > > > > > > Sending boot image data (474404 bytes)... > > > > > > > > > 0 % > > > > > > > > > > > > > > > > > > > > [......................................................................] > > > > > > > > > <snip> > > > > > > > > > 98 % > > > > > > > [................................................................... > > > > > > > > > ] > > > > > > > > > Done > > > > > > > > > Finishing transfer > > > > > > > > > [Type Ctrl-\ + c to quit] > > > > > > > > > > > > > > > > > > > > > > > > > > > U-Boot 2023.04-rc4-00339-gcefd0449d6 (Mar 19 2023 - 13:20:48 > > > > +1000) > > > > > > > > > </UART output> > > > > > > > > > > > > > > > > > > <UART sizes> > > > > > > > > > du -b u-boot* > > > > > > > > > 4997204 u-boot > > > > > > > > > 474400 u-boot.bin > > > > > > > > > 15103 u-boot.cfg > > > > > > > > > 19496 u-boot.dtb > > > > > > > > > 474400 u-boot-dtb.bin > > > > > > > > > 474464 u-boot-dtb.img > > > > > > > > > 474464 u-boot.img > > > > > > > > > 1721 u-boot.lds > > > > > > > > > 1070068 u-boot.map > > > > > > > > > 454904 u-boot-nodtb.bin > > > > > > > > > 1307988 u-boot.srec > > > > > > > > > 198886 u-boot.sym > > > > > > > > > 587904 u-boot-with-spl.kwb > > > > > > > > > </UART sizes> > > > > > > > > > > > > > > > > > > The difference is very small somewhere if that is the cause. > > > > > > > > > Let > > > > me > > > > > > > know if > > > > > > > > > there's other data I can get to help with this one. > > > > > > > > > > > > > > > > Difference should be only in the kwbimage header plus some > > > > aligning. It > > > > > > > > just proves what I wrote before "mkimage generated incorrect > > > > > > > > image > > > > size > > > > > > > > for SDIO image. Or kwboot incorrectly parsed that image size > > > > > > > > from kwbimage header and sent smaller image.". > > > > > > > > > > > > > > > > I will try to find a bug in mkimage or kwboot tool. Or you can > > > > > > > > try > > > > it > > > > > > > > too. As mmc booting is working fine from mmc I have felling that > > > > bug is > > > > > > > > in kwboot code which parses mmc images. > > > > > > > > > > > > > > Ok, I think I found 3 bugs, all are UART related (not mmc). Could > > > > you try > > > > > > > these changes? > > > > > > > > > > > > > > > > > > > Dedicated UART still works, patching an MMC for UART with kwboot > > > > > > still > > > > > > hangs after finishing transfer; no change. > > > > > > > > > > Bah :-( So there is still another bug. I will look at the code > > > > > again... > > > > > > > > I do not see anything wrong there :-( > > > > > > > > Could you try to normally build mmc image and then run following > > > > commands to manually generate uart image u-boot-with-spl.uart.kwb? > > > > > > > > sed 's/^BOOT_FROM.*/BOOT_FROM uart/' > > > > ./arch/arm/mach-mvebu/kwbimage.cfg > > > > > kwbimage.uart.cfg > > > > ./tools/mkimage -n kwbimage.uart.cfg -T kwbimage -a 0x00800000 -e > > > > 0x00800000 -d u-boot.bin u-boot-with-spl.uart.kwb > > > > > > > > I would like to know if this UART image is bootable or not. > > > > > > > > > > It is bootable. Here is the output from the normal mkimage: > > > ./tools/mkimage -n ./arch/arm/mach-mvebu/kwbimage.cfg -T kwbimage -a > > > 0x00800000 -e 0x00800000 -d u-boot.bin u-boot-with-spl.kwb > > > Image Type: MVEBU Boot from sdio Image > > > Image version:1 > > > BIN Img Size: 113416 Bytes = 110.76 KiB = 0.11 MiB > > > BIN Img Offs: 48 Bytes = 0.05 KiB = 0.00 MiB > > > Data Size: 475072 Bytes = 463.94 KiB = 0.45 MiB > > > Data Offset: 113664 Bytes = 111.00 KiB = 0.11 MiB > > > Load Address: 00800000 > > > Entry Point: 00800000 > > > > > > Here is the output from your custom command: > > > ./tools/mkimage -n kwbimage.uart.cfg -T kwbimage -a 0x00800000 -e > > > 0x00800000 -d u-boot.bin u-boot-with-spl.uart.kwb > > > Image Type: MVEBU Boot from uart Image > > > Image version:1 > > > BIN Img Size: 113416 Bytes = 110.76 KiB = 0.11 MiB > > > BIN Img Offs: 48 Bytes = 0.05 KiB = 0.00 MiB > > > Data Size: 475072 Bytes = 463.94 KiB = 0.45 MiB > > > Data Offset: 113536 Bytes = 110.88 KiB = 0.11 MiB > > > Load Address: 00800000 > > > Entry Point: 00800000 > > > > Obviously I have this output as I compiled it many times. There is > > nothing suspicious. Data offset is different just be cause mmc image is > > aligned to 512 byte long sector size and uart image is aligned to 128 > > byte log xmodem block size. Hence data offset needs to be multiply of > > 128 or 512 based on the image type > > > > > The difference is 128 bytes for the data offset. When I run kwboot I get: > > > Sending boot image data (475204 bytes)... [for the normal mkimage which > > > doesn't work] > > > Sending boot image data (475076 bytes)... [for the custom mkimage which > > > does work] > > > > But this is suspicious. Data image size printed by kwboot is data size > > printed by mkimage plus 4 bytes (which is checksum). It is correct for > > custom uart image, but not for mmc image converted to uart image by > > kwboot. > > > > And now I see where can be an issue. In kwbimage v1 header is stored > > length of the header itself (it can be variable length) and also offset > > where the data part of the image starts. As I pointed in one of the > > patch chunk sent previously, bootrom reads kwbimage header by loading > > number of xmodem blocks equals to header size divided by 128 (xmodem > > block size) rounded down. So patch chunk manually increased header size > > to the next multiply of 128 bytes. And after bootrom read kwbimage > > header it immediately starts reading data part of the image - and > > completely ignores the fact that in header is stored offset to the data > > part. > > I looked at the disassembled bootrom code again and it does not ignore > offset to the data part. But if my understanding is correct there is > off-by-one error in bootrom code when processing a gap between header > and data part. And Xth data byte is copied to the RAM[load_addr+X+1] > offset. > > Could you try prepending u-boot.bin binary by one byte and rebuild > normal (mmc) kwb binary?
Hm... no, this does not help as off-by-one is in opposite direction. You need to cut the first byte from the u-boot.bin binary, build kwb image and then put this first byte into the kwb image just before data part (by replacing that one zero byte filler). > If it starts booting over UART _without_ > remove-gap patch which I sent in previous email then it confirms my > above observation and remove-gap patch is needed. > > > In case we have different alignment, it is possible that between > > header and data part is a gap, which is multiply of the 128 bytes. E.g. > > original header size was 300 bytes, alignment was 512 bytes; new > > alignment is 128 bytes, which effectively decrease size of the header > > from 512 bytes to just 384 bytes; with creating a gap of 128 bytes > > between header and data part. > > > > Could you try following change if it fixes? > > > > diff --git a/tools/kwboot.c b/tools/kwboot.c > > index a118a26d282c..272128db3946 100644 > > --- a/tools/kwboot.c > > +++ b/tools/kwboot.c > > @@ -2181,6 +2181,16 @@ kwboot_img_patch(void *img, size_t *size, int > > baudrate) > > } > > } > > > > + /* Remove the gap between header and data part by moving data part */ > > + if (!is_secure && hdrsz != le32_to_cpu(hdr->srcaddr)) { > > + kwboot_printv("Removing gap between image header and data\n"); > > + memmove(img + hdrsz, img + le32_to_cpu(hdr->srcaddr), > > le32_to_cpu(hdr->blocksize)); > > + hdr->srcaddr = cpu_to_le32(hdrsz); > > + } else if (le32_to_cpu(hdr->srcaddr) % KWBOOT_XM_BLKSZ) { > > + fprintf(stderr, "Cannot align image with secure header\n"); > > + goto err; > > + } > > + > > hdr->checksum = kwboot_hdr_csum8(hdr) - csum; > > > > *size = le32_to_cpu(hdr->srcaddr) + le32_to_cpu(hdr->blocksize); > > > > > That 128 extra carries across. I'll poke around a bit more, but it seems > > > like a good lead so I wanted to share. > > > > > > > > > > Also it would be interesting to enable CONFIG_DEBUG_UART_ANNOUNCE option > > > > and check if you see early announce message on UART. > > > > > > > > > > That's enabled for all the clearfog builds already. > > > > > > > > > > > Meanwhile could you do following tests? > > > > > > > > > > 1) The one which you done with patched kwboot and kwbimage, but send > > > > > output (sizes and aligning information from kwboot is useful there). > > > > > > > > > > 2) Use kwboot only for sending magic packet (-b without image) and > > > > > then > > > > > use "sx" program for transferring kwb image over UART (instead of > > > > > kwboot). "sx" should work only with dedicated UART image type. > > > > > > > > > > These commands would do it (replace ttyX by correct UART device) > > > > > > > > > > $ ./tools/kwboot -b /dev/ttyX > > > > > $ sh -c 'exec 0<>/dev/ttyX 1>&0; sx u-boot-with-spl.kwb' > > > > > > > > > > > > > > > > > > diff --git a/tools/kwbimage.c b/tools/kwbimage.c > > > > > > > index 309657a5637b..177084adf825 100644 > > > > > > > --- a/tools/kwbimage.c > > > > > > > +++ b/tools/kwbimage.c > > > > > > > @@ -1231,6 +1231,16 @@ static size_t image_headersz_v1(int > > > > > > > *hasext) > > > > > > > if (count > 0) > > > > > > > headersz += sizeof(struct register_set_hdr_v1) + > > > > > > > 8 * > > > > count > > > > > > > + 4; > > > > > > > > > > > > > > + /* > > > > > > > + * For all images except UART, headersz stored in header > > > > itself > > > > > > > should > > > > > > > + * contains header size without padding. For UART image > > > > BootROM > > > > > > > rounds > > > > > > > + * down headersz to multiply of 128 bytes. Therefore align > > > > UART > > > > > > > headersz > > > > > > > + * to multiply of 128 bytes to ensure that remaining UART > > > > header > > > > > > > bytes > > > > > > > + * are not ignored by BootROM. > > > > > > > + */ > > > > > > > + if (image_get_bootfrom() == IBR_HDR_UART_ID) > > > > > > > + headersz = ALIGN(headersz, 128); > > > > > > > + > > > > > > > return headersz; > > > > > > > } > > > > > > > > > > > > > > diff --git a/tools/kwboot.c b/tools/kwboot.c > > > > > > > index 1844d7291fe0..b40800c108fc 100644 > > > > > > > --- a/tools/kwboot.c > > > > > > > +++ b/tools/kwboot.c > > > > > > > @@ -2079,6 +2079,8 @@ kwboot_img_patch(void *img, size_t *size, > > > > > > > int > > > > > > > baudrate) > > > > > > > goto err; > > > > > > > } > > > > > > > kwboot_img_grow_data_right(img, size, > > > > sizeof(uint32_t)); > > > > > > > + /* Update the 32-bit data checksum */ > > > > > > > + *kwboot_img_csum32_ptr(img) = > > > > > > > kwboot_img_csum32(img); > > > > > > > } > > > > > > > > > > > > > > if (!kwboot_img_has_ddr_init(img) && > > > > > > > @@ -2168,6 +2170,17 @@ kwboot_img_patch(void *img, size_t *size, > > > > > > > int > > > > > > > baudrate) > > > > > > > > > > > > > > kwboot_printv("Aligning image header to Xmodem > > > > > > > block > > > > > > > size\n"); > > > > > > > kwboot_img_grow_hdr(img, size, grow); > > > > > > > + > > > > > > > + /* > > > > > > > + * kwbimage v1 contains header size field and for > > > > UART > > > > > > > type it > > > > > > > + * must be set to the aligned xmodem header size > > > > because > > > > > > > BootROM > > > > > > > + * rounds header size down to xmodem block size. > > > > > > > + */ > > > > > > > + if (kwbimage_version(img) == 1) { > > > > > > > + hdrsz += grow; > > > > > > > + hdr->headersz_msb = hdrsz >> 16; > > > > > > > + hdr->headersz_lsb = cpu_to_le16(hdrsz & > > > > 0xffff); > > > > > > > + } > > > > > > > } > > > > > > > > > > > > > > hdr->checksum = kwboot_hdr_csum8(hdr) - csum; > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Also could you check if SATA booting is still working > > > > correctly? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > SATA works correctly. > > > > > > > > > > > > > > > > > > > > Perfect! > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Tony, should address problems with SPI booting when it > > > > > > > > > > > > is > > > > > > > configured to > > > > > > > > > > > > different configuration. In fourth commit I added all > > > > possible > > > > > > > boot > > > > > > > > > > mode > > > > > > > > > > > > strapping pin configurations which are recognized by > > > > > > > > > > > > A385 > > > > > > > bootrom (and > > > > > > > > > > > > not the only one described in the HW spec, which is > > > > incomplete). > > > > > > > > > > > > > > > > > > > > > > > > Stefan, do you have some AXP board with SATA boot > > > > > > > > > > > > source? > > > > > > > Because I'm > > > > > > > > > > > > adding it for completeness in the last sixth patch. > > > > > > > > > > > > > > > > > > > > > > > > Pali Rohár (6): > > > > > > > > > > > > arm: mvebu: Remove A38x BOOT_FROM_UART_ALT 0x3f > > > > > > > > > > > > constant > > > > > > > > > > > > arm: mvebu: Remove A38x BOOT_FROM_SATA 0x22 constant > > > > > > > > > > > > arm: mvebu: Convert BOOT_FROM_* constants to function > > > > macros > > > > > > > > > > > > arm: mvebu: Define all options for A38x BOOT_FROM_* > > > > macros > > > > > > > > > > > > arm: mvebu: Define all BOOTROM_ERR_MODE_* macros > > > > > > > > > > > > arm: mvebu: Define all options for AXP BOOT_FROM_* > > > > > > > > > > > > macros > > > > > > > > > > > > > > > > > > > > > > > > arch/arm/mach-mvebu/cpu.c | 20 > > > > > > > > > > > > ++++++------- > > > > > > > > > > > > arch/arm/mach-mvebu/include/mach/soc.h | 41 > > > > > > > ++++++++++++++++---------- > > > > > > > > > > > > 2 files changed, 35 insertions(+), 26 deletions(-) > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > 2.20.1 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >