[PATCH RFC u-boot-mvebu 0/6] arm: mvebu: Fix boot mode detection
Pali Rohár
pali at kernel.org
Tue Mar 21 20:56:02 CET 2023
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 <pali at 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 <pali at 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 <pali at 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 <pali at 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? 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
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > >
> > > > > >
> > >
More information about the U-Boot
mailing list