[U-Boot] Cannot boot mx6qsabred with 2019.07-rc2
Hi,
I get the following error when trying to boot mx6q sabresd with 2019.07-rc2:
U-Boot SPL 2019.07-rc2 (May 16 2019 - 14:28:55 -0300) Trying to boot from MMC1 spl: could not find mmc device 0. error: -19 SPL: failed to boot from all boot devices ### ERROR ### Please RESET the board ###
I haven't debugged this yet.
Does anyone have any ideas?
Thanks,
Fabio Estevam
On Thu, May 16, 2019 at 11:02 PM Fabio Estevam festevam@gmail.com wrote:
Hi,
I get the following error when trying to boot mx6q sabresd with 2019.07-rc2:
U-Boot SPL 2019.07-rc2 (May 16 2019 - 14:28:55 -0300) Trying to boot from MMC1 spl: could not find mmc device 0. error: -19
No device.
Is it DM-SPL-enabled? check with u-boot,dm-spl on associated nodes?
usdhc3 is for sabresd, seems like gpio2 missing to add u-boot,dm-spl
Hi Jagan,
On Thu, May 16, 2019 at 2:37 PM Jagan Teki jagan@amarulasolutions.com wrote:
On Thu, May 16, 2019 at 11:02 PM Fabio Estevam festevam@gmail.com wrote:
Hi,
I get the following error when trying to boot mx6q sabresd with 2019.07-rc2:
U-Boot SPL 2019.07-rc2 (May 16 2019 - 14:28:55 -0300) Trying to boot from MMC1 spl: could not find mmc device 0. error: -19
No device.
Is it DM-SPL-enabled? check with u-boot,dm-spl on associated nodes?
Yes, configs/mx6sabresd_defconfig has CONFIG_SPL_DM=y.
arch/arm/dts/imx6qp-sabresd-u-boot.dtsi passes u-boot,dm-spl to usdhc3.
usdhc3 is for sabresd, seems like gpio2 missing to add u-boot,dm-spl
I tried:
--- a/arch/arm/dts/imx6qdl-sabresd-u-boot.dtsi +++ b/arch/arm/dts/imx6qdl-sabresd-u-boot.dtsi @@ -12,3 +12,7 @@ &pinctrl_usdhc3 { u-boot,dm-spl; }; + +&gpio2 { + u-boot,dm-spl; +};
but still not booting.
On Thu, May 16, 2019 at 2:32 PM Fabio Estevam festevam@gmail.com wrote:
Hi,
I get the following error when trying to boot mx6q sabresd with 2019.07-rc2:
U-Boot SPL 2019.07-rc2 (May 16 2019 - 14:28:55 -0300) Trying to boot from MMC1 spl: could not find mmc device 0. error: -19 SPL: failed to boot from all boot devices ### ERROR ### Please RESET the board ###
I haven't debugged this yet.
Does anyone have any ideas?
SPL is able to load u-boot-dtb.img if I disable CONFIG_SPL_DM:
--- a/configs/mx6sabresd_defconfig +++ b/configs/mx6sabresd_defconfig @@ -65,7 +65,6 @@ CONFIG_SPL_MULTI_DTB_FIT=y CONFIG_SPL_OF_LIST="imx6dl-sabresd imx6q-sabresd imx6qp-sabresd" CONFIG_ENV_IS_IN_MMC=y CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y -CONFIG_SPL_DM=y CONFIG_USB_FUNCTION_FASTBOOT=y CONFIG_FASTBOOT_BUF_ADDR=0x12000000 CONFIG_FASTBOOT_BUF_SIZE=0x10000000
Do we really want to use DM within SPL?
If we do, does anyone know how to fix it?
On Thu, 16 May 2019 16:40:56 -0300 Fabio Estevam festevam@gmail.com wrote:
On Thu, May 16, 2019 at 2:32 PM Fabio Estevam festevam@gmail.com wrote:
Hi,
I get the following error when trying to boot mx6q sabresd with 2019.07-rc2:
U-Boot SPL 2019.07-rc2 (May 16 2019 - 14:28:55 -0300) Trying to boot from MMC1 spl: could not find mmc device 0. error: -19 SPL: failed to boot from all boot devices ### ERROR ### Please RESET the board ###
I haven't debugged this yet.
Does anyone have any ideas?
SPL is able to load u-boot-dtb.img if I disable CONFIG_SPL_DM:
--- a/configs/mx6sabresd_defconfig +++ b/configs/mx6sabresd_defconfig @@ -65,7 +65,6 @@ CONFIG_SPL_MULTI_DTB_FIT=y CONFIG_SPL_OF_LIST="imx6dl-sabresd imx6q-sabresd imx6qp-sabresd" CONFIG_ENV_IS_IN_MMC=y CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y -CONFIG_SPL_DM=y CONFIG_USB_FUNCTION_FASTBOOT=y CONFIG_FASTBOOT_BUF_ADDR=0x12000000 CONFIG_FASTBOOT_BUF_SIZE=0x10000000
Do we really want to use DM within SPL?
If we do, does anyone know how to fix it?
Please find following repository with DM/DTS conversion for TPC70 imx6q board (it also has SPL DM conversion working - board boots from SD card and eMMC):
https://github.com/lmajewski/u-boot-dfu/commits/DM-SPL-TPC70
My guess is that you need the pinctrl DM support in SPL, to make the card detect pin working.
&pinctrl_usdhc4 { u-boot,dm-spl; };
&pinctrl_usdhc2 { u-boot,dm-spl; };
&gpio2 { u-boot,dm-spl; };
And also the pinctrl-imx6q.c fix to:
static struct imx_pinctrl_soc_info imx6_pinctrl_soc_info __section(".data");
To sum up: TPC70 (imx6q) has support for DM/DTS in both SPL and u-boot proper.
The issue with this port is that it uses Common Clock Framework from Linux and would need SPL's OF_PLATDATA support in eMMC and uart drivers to reduce SPL size.
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de
Hi Lukasz,
On Thu, May 16, 2019 at 6:49 PM Lukasz Majewski lukma@denx.de wrote:
Please find following repository with DM/DTS conversion for TPC70 imx6q board (it also has SPL DM conversion working - board boots from SD card and eMMC):
https://github.com/lmajewski/u-boot-dfu/commits/DM-SPL-TPC70
My guess is that you need the pinctrl DM support in SPL, to make the card detect pin working.
&pinctrl_usdhc4 { u-boot,dm-spl; };
&pinctrl_usdhc2 { u-boot,dm-spl; };
&gpio2 { u-boot,dm-spl; };
And also the pinctrl-imx6q.c fix to:
static struct imx_pinctrl_soc_info imx6_pinctrl_soc_info __section(".data");
I tried your suggestions and now it dies even earlier:
U-Boot SPL 2019.07-rc1-00427-g504bf790da-dirty (May 16 2019 - 23:17:43 -0300) ### ERROR ### Please RESET the board ###
Thanks
Hi Fabio
Booting from SD3, it works for me. See below log.
" U-Boot SPL 2019.07-rc2 (May 17 2019 - 10:24:45 +0800) Trying to boot from MMC1
U-Boot 2019.07-rc2 (May 17 2019 - 10:24:45 +0800)
CPU: Freescale i.MX6Q rev1.5 996 MHz (running at 792 MHz) CPU: Automotive temperature grade (-40C to 125C)Reset cause: POR Model: Freescale i.MX6 Quad SABRE Smart Device Board "
Regards, Peng.
-----Original Message----- From: Fabio Estevam [mailto:festevam@gmail.com] Sent: 2019年5月17日 1:33 To: Stefano Babic sbabic@denx.de; dl-uboot-imx uboot-imx@nxp.com Cc: Lukasz Majewski lukma@denx.de; Jagan Teki jagan@amarulasolutions.com; Michael Trimarchi michael@amarulasolutions.com; U-Boot-Denx u-boot@lists.denx.de Subject: Cannot boot mx6qsabred with 2019.07-rc2
Hi,
I get the following error when trying to boot mx6q sabresd with 2019.07-rc2:
U-Boot SPL 2019.07-rc2 (May 16 2019 - 14:28:55 -0300) Trying to boot from MMC1 spl: could not find mmc device 0. error: -19 SPL: failed to boot from all boot devices ### ERROR ### Please RESET the board ###
I haven't debugged this yet.
Does anyone have any ideas?
Thanks,
Fabio Estevam
Hi Peng,
On Thu, May 16, 2019 at 11:17 PM Peng Fan peng.fan@nxp.com wrote:
Hi Fabio
Booting from SD3, it works for me. See below log.
" U-Boot SPL 2019.07-rc2 (May 17 2019 - 10:24:45 +0800) Trying to boot from MMC1
U-Boot 2019.07-rc2 (May 17 2019 - 10:24:45 +0800)
CPU: Freescale i.MX6Q rev1.5 996 MHz (running at 792 MHz) CPU: Automotive temperature grade (-40C to 125C)Reset cause: POR Model: Freescale i.MX6 Quad SABRE Smart Device Board
Interesting.
It fails for me and for a customer with the same error log.
What could explain such difference?
Subject: Re: Cannot boot mx6qsabred with 2019.07-rc2
Hi Peng,
On Thu, May 16, 2019 at 11:17 PM Peng Fan peng.fan@nxp.com wrote:
Hi Fabio
Booting from SD3, it works for me. See below log.
" U-Boot SPL 2019.07-rc2 (May 17 2019 - 10:24:45 +0800) Trying to boot from MMC1
U-Boot 2019.07-rc2 (May 17 2019 - 10:24:45 +0800)
CPU: Freescale i.MX6Q rev1.5 996 MHz (running at 792 MHz) CPU: Automotive temperature grade (-40C to 125C)Reset cause: POR Model: Freescale i.MX6 Quad SABRE Smart Device Board
Interesting.
It fails for me and for a customer with the same error log.
What could explain such difference?
You could enable DEBUG in SPL, and disable SPL_SDP because of size will exceeds. Then see what happends. I have no idea, then. My board is REV C4, chip 1.5
Regards, Peng.
On Thu, May 16, 2019 at 11:29 PM Peng Fan peng.fan@nxp.com wrote:
You could enable DEBUG in SPL, and disable SPL_SDP because of size will exceeds. Then see what happends.
Even without DEBUG enabled we get useful error messages:
U-Boot SPL 2019.07-rc2 (May 17 2019 - 09:30:33 -0300) Trying to boot from MMC1 spl: could not find mmc device 0. error: -19 SPL: failed to boot from all boot devices ### ERROR ### Please RESET the board ###
This means that err = uclass_get_device(UCLASS_MMC, mmc_dev, &dev); fails inside common/spl/spl_mmc.c
Why does this happen?
About the size difference:
Original defconfig generates an SPL of 76800 bytes With CONFIG_SPL_DM=y removed the SPL size goes to 68608 bytes.
I have no idea, then. My board is REV C4, chip 1.5
Mine is rev C2 with i.MX6Q rev1.2
On Fri, 17 May 2019 09:39:31 -0300 Fabio Estevam festevam@gmail.com wrote:
On Thu, May 16, 2019 at 11:29 PM Peng Fan peng.fan@nxp.com wrote:
You could enable DEBUG in SPL, and disable SPL_SDP because of size will exceeds. Then see what happends.
Even without DEBUG enabled we get useful error messages:
U-Boot SPL 2019.07-rc2 (May 17 2019 - 09:30:33 -0300) Trying to boot from MMC1 spl: could not find mmc device 0. error: -19
I had similar issue on imx53 (hsc). The problem was with not properly set GPIO pin by DM/DTS in SPL. The GPIO was responsible for eMMC card detect, so the SPL code after checking this got the impression that the card is missing -> hence the -19 error.
Interesting commit: SHA1: 7a0425dd969c44e6afb6936bf8205c8770e9dea9
SPL: failed to boot from all boot devices ### ERROR ### Please RESET the board ###
This means that err = uclass_get_device(UCLASS_MMC, mmc_dev, &dev); fails inside common/spl/spl_mmc.c
Why does this happen?
About the size difference:
Original defconfig generates an SPL of 76800 bytes With CONFIG_SPL_DM=y removed the SPL size goes to 68608 bytes.
I have no idea, then. My board is REV C4, chip 1.5
Mine is rev C2 with i.MX6Q rev1.2
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de
Hi Lukasz,
On Fri, May 17, 2019 at 9:58 AM Lukasz Majewski lukma@denx.de wrote:
I had similar issue on imx53 (hsc). The problem was with not properly set GPIO pin by DM/DTS in SPL. The GPIO was responsible for eMMC card detect, so the SPL code after checking this got the impression that the card is missing -> hence the -19 error.
Interesting commit: SHA1: 7a0425dd969c44e6afb6936bf8205c8770e9dea9
I have also tried passing the 'non-removable' property and still get the -19 error.
On Mon, May 20, 2019 at 7:37 PM Fabio Estevam festevam@gmail.com wrote:
Hi Lukasz,
On Fri, May 17, 2019 at 9:58 AM Lukasz Majewski lukma@denx.de wrote:
I had similar issue on imx53 (hsc). The problem was with not properly set GPIO pin by DM/DTS in SPL. The GPIO was responsible for eMMC card detect, so the SPL code after checking this got the impression that the card is missing -> hence the -19 error.
Interesting commit: SHA1: 7a0425dd969c44e6afb6936bf8205c8770e9dea9
I have also tried passing the 'non-removable' property and still get the -19 error.
Look very strange, I have checked sabresd which has similar configs and dts changes as icorem6. Thought that it would be another issue wrt spl changes on this board, bisect might help?
On Fri, May 17, 2019 at 6:09 PM Fabio Estevam festevam@gmail.com wrote:
On Thu, May 16, 2019 at 11:29 PM Peng Fan peng.fan@nxp.com wrote:
You could enable DEBUG in SPL, and disable SPL_SDP because of size will exceeds. Then see what happends.
Even without DEBUG enabled we get useful error messages:
U-Boot SPL 2019.07-rc2 (May 17 2019 - 09:30:33 -0300) Trying to boot from MMC1 spl: could not find mmc device 0. error: -19 SPL: failed to boot from all boot devices ### ERROR ### Please RESET the board ###
This means that err = uclass_get_device(UCLASS_MMC, mmc_dev, &dev); fails inside common/spl/spl_mmc.c
Why does this happen?
About the size difference:
Original defconfig generates an SPL of 76800 bytes With CONFIG_SPL_DM=y removed the SPL size goes to 68608 bytes.
I have no idea, then. My board is REV C4, chip 1.5
Mine is rev C2 with i.MX6Q rev1.2
Don't know whether this is SPL size issue or not? can you try SPL_OF_PLATDATA and TINY* I can see the size reduced with 64512 bytes (one build issue on fdtdec_get_int undefined)
On Thu, May 23, 2019 at 1:11 PM Jagan Teki jagan@amarulasolutions.com wrote:
Don't know whether this is SPL size issue or not? can you try SPL_OF_PLATDATA and TINY* I can see the size reduced with 64512 bytes (one build issue on fdtdec_get_int undefined)
Yes, it does not build with CONFIG_SPL_OF_PLATDATA:
lib/built-in.o: In function `fdtdec_parse_phandle_with_args': /home/fabio/u-boot/lib/fdtdec.c:788: undefined reference to `fdtdec_get_int' drivers/built-in.o: In function `fsl_esdhc_probe': /home/fabio/u-boot/drivers/mmc/fsl_esdhc.c:1480: undefined reference to `fdtdec_get_int' /home/fabio/u-boot/drivers/mmc/fsl_esdhc.c:1482: undefined reference to `fdtdec_get_int' /home/fabio/u-boot/drivers/mmc/fsl_esdhc.c:1485: undefined reference to `fdtdec_get_int' scripts/Makefile.spl:404: recipe for target 'spl/u-boot-spl' failed make[1]: *** [spl/u-boot-spl] Error 1
Thanks for the suggestions, but at this point I prefer to go with the removal of CONFIG_SPL_DM.
For 2019.07 it would be really nice if we could fix these two issues:
1. Allow to load a FIT image via Serial Download Protocol
2. Detect the SPL size overflow in build-time
On Thu, May 23, 2019 at 10:18 PM Fabio Estevam festevam@gmail.com wrote:
On Thu, May 23, 2019 at 1:11 PM Jagan Teki jagan@amarulasolutions.com wrote:
Don't know whether this is SPL size issue or not? can you try SPL_OF_PLATDATA and TINY* I can see the size reduced with 64512 bytes (one build issue on fdtdec_get_int undefined)
Yes, it does not build with CONFIG_SPL_OF_PLATDATA:
lib/built-in.o: In function `fdtdec_parse_phandle_with_args': /home/fabio/u-boot/lib/fdtdec.c:788: undefined reference to `fdtdec_get_int'
Couldn't dig much here, would be happy someone can find this?
drivers/built-in.o: In function `fsl_esdhc_probe': /home/fabio/u-boot/drivers/mmc/fsl_esdhc.c:1480: undefined reference to `fdtdec_get_int' /home/fabio/u-boot/drivers/mmc/fsl_esdhc.c:1482: undefined reference to `fdtdec_get_int' /home/fabio/u-boot/drivers/mmc/fsl_esdhc.c:1485: undefined reference
These we can fix, by supporting platdata support into driver.
to `fdtdec_get_int' scripts/Makefile.spl:404: recipe for target 'spl/u-boot-spl' failed make[1]: *** [spl/u-boot-spl] Error 1
Thanks for the suggestions, but at this point I prefer to go with the removal of CONFIG_SPL_DM.
We have 45 days to release, I think we can make these fixes quite normally what do you think? fsl_esdhc.c build I can mark a patch in few days if required.
For 2019.07 it would be really nice if we could fix these two issues:
Allow to load a FIT image via Serial Download Protocol
Detect the SPL size overflow in build-time
1) We are working on this, 2) can be done.
On Thu, May 23, 2019 at 2:07 PM Jagan Teki jagan@amarulasolutions.com wrote:
We have 45 days to release, I think we can make these fixes quite normally what do you think? fsl_esdhc.c build I can mark a patch in few days if required.
Sure, bug fixes are always welcome :-)
For 2019.07 it would be really nice if we could fix these two issues:
Allow to load a FIT image via Serial Download Protocol
Detect the SPL size overflow in build-time
- We are working on this, 2) can be done.
Cool, please keep me in the loop for the Serial Download Protocol issue.
Thanks
On 23.05.19 19:07, Jagan Teki wrote:
On Thu, May 23, 2019 at 10:18 PM Fabio Estevam festevam@gmail.com wrote:
On Thu, May 23, 2019 at 1:11 PM Jagan Teki jagan@amarulasolutions.com wrote:
Don't know whether this is SPL size issue or not? can you try SPL_OF_PLATDATA and TINY* I can see the size reduced with 64512 bytes (one build issue on fdtdec_get_int undefined)
Yes, it does not build with CONFIG_SPL_OF_PLATDATA:
lib/built-in.o: In function `fdtdec_parse_phandle_with_args': /home/fabio/u-boot/lib/fdtdec.c:788: undefined reference to `fdtdec_get_int'
Couldn't dig much here, would be happy someone can find this?
drivers/built-in.o: In function `fsl_esdhc_probe': /home/fabio/u-boot/drivers/mmc/fsl_esdhc.c:1480: undefined reference to `fdtdec_get_int' /home/fabio/u-boot/drivers/mmc/fsl_esdhc.c:1482: undefined reference to `fdtdec_get_int' /home/fabio/u-boot/drivers/mmc/fsl_esdhc.c:1485: undefined reference
These we can fix, by supporting platdata support into driver.
to `fdtdec_get_int' scripts/Makefile.spl:404: recipe for target 'spl/u-boot-spl' failed make[1]: *** [spl/u-boot-spl] Error 1
Thanks for the suggestions, but at this point I prefer to go with the removal of CONFIG_SPL_DM.
We have 45 days to release, I think we can make these fixes quite normally what do you think? fsl_esdhc.c build I can mark a patch in few days if required.
For 2019.07 it would be really nice if we could fix these two issues:
Allow to load a FIT image via Serial Download Protocol
Detect the SPL size overflow in build-time
- We are working on this, 2) can be done.
As luck would have it, I needed to load a FIT via SDP today, so I came up with a quick patch (see below). There are probably better ways to do this, but it works.
#############################
commit 408b9d26eea48e6f85dd087750629f7a4095c73d Author: Frieder Schrempf frieder.schrempf@kontron.de Date: Thu May 23 14:52:47 2019 +0200
Allow SPL to load and boot FIT via SDP
diff --git a/common/spl/spl_sdp.c b/common/spl/spl_sdp.c index 807256e908..8f990a83a3 100644 --- a/common/spl/spl_sdp.c +++ b/common/spl/spl_sdp.c @@ -25,10 +25,13 @@ static int spl_sdp_load_image(struct spl_image_info *spl_image, return -ENODEV; }
- /* This command typically does not return but jumps to an image */ - sdp_handle(controller_index); - pr_err("SDP ended\n"); + /* + * This command either loads a legacy image, jumps and never returns, + * or it loads a FIT image and returns it to be handled by the SPL code. + */ + ret = sdp_handle(controller_index, spl_image); + debug("SDP ended\n");
- return -EINVAL; + return ret; } SPL_LOAD_IMAGE_METHOD("USB SDP", 0, BOOT_DEVICE_BOARD, spl_sdp_load_image); diff --git a/drivers/usb/gadget/f_sdp.c b/drivers/usb/gadget/f_sdp.c index ae97ab2b49..5690060a2f 100644 --- a/drivers/usb/gadget/f_sdp.c +++ b/drivers/usb/gadget/f_sdp.c @@ -638,7 +638,18 @@ static u32 sdp_jump_imxheader(void *address) return 0; }
-static void sdp_handle_in_ep(void) +#ifdef CONFIG_SPL_LOAD_FIT +static ulong sdp_fit_read(struct spl_load_info *load, ulong sector, + ulong count, void *buf) +{ + debug("%s: sector %lx, count %lx, buf %lx\n", + __func__, sector, count, (ulong)buf); + memcpy(buf, (void *)(load->dev + sector), count); + return count; +} +#endif + +static void sdp_handle_in_ep(struct spl_image_info *spl_image) { u8 *data = sdp_func->in_req->buf; u32 status; @@ -689,11 +700,25 @@ static void sdp_handle_in_ep(void)
/* If imx header fails, try some U-Boot specific headers */ if (status) { + image_header_t *header = + (void *)(u64)sdp_func->jmp_address; #ifdef CONFIG_SPL_BUILD +#ifdef CONFIG_SPL_LOAD_FIT + if (image_get_magic(header) == FDT_MAGIC) { + struct spl_load_info load; + + printf("Found FIT\n"); + load.dev = (void *)(u64)sdp_func->jmp_address; + load.bl_len = 1; + load.read = sdp_fit_read; + spl_load_simple_fit(spl_image, &load, 0, + header); + return; + } +#endif /* In SPL, allow jumps to U-Boot images */ struct spl_image_info spl_image = {}; - spl_parse_image_header(&spl_image, - (struct image_header *)sdp_func->jmp_address); + spl_parse_image_header(&spl_image, header); jump_to_image_no_args(&spl_image); #else /* In U-Boot, allow jumps to scripts */ @@ -715,19 +740,23 @@ static void sdp_handle_in_ep(void) }; }
-void sdp_handle(int controller_index) +int sdp_handle(int controller_index, struct spl_image_info *spl_image) { printf("SDP: handle requests...\n"); while (1) { if (ctrlc()) { puts("\rCTRL+C - Operation aborted.\n"); - return; + return -EINVAL; + } + + if (spl_image->flags & SPL_FIT_FOUND) { + return 0; }
WATCHDOG_RESET(); usb_gadget_handle_interrupts(controller_index);
- sdp_handle_in_ep(); + sdp_handle_in_ep(spl_image); } }
diff --git a/include/sdp.h b/include/sdp.h index f6252d027f..f30e2bca19 100644 --- a/include/sdp.h +++ b/include/sdp.h @@ -9,7 +9,9 @@ #ifndef __SDP_H_ #define __SDP_H_
+#include <spl.h> + int sdp_init(int controller_index); -void sdp_handle(int controller_index); +int sdp_handle(int controller_index, struct spl_image_info *spl_image);
#endif /* __SDP_H_ */
Hi Schrempf,
On Thu, May 23, 2019 at 2:26 PM Schrempf Frieder frieder.schrempf@kontron.de wrote:
As luck would have it, I needed to load a FIT via SDP today, so I came up with a quick patch (see below). There are probably better ways to do this, but it works.
Thanks for your patch!
I would like to give it a try, but it does not apply against U-Boot mainline.
I manually applied it, but failed to build:
cmd/usb_gadget_sdp.c: In function ‘do_sdp’: cmd/usb_gadget_sdp.c:35:2: error: too few arguments to function ‘sdp_handle’ sdp_handle(controller_index);
Could you please rebase it against U-Boot mainline and post it like a formal patch?
Thanks
On 5/23/19 7:45 PM, Fabio Estevam wrote:
Hi Schrempf,
On Thu, May 23, 2019 at 2:26 PM Schrempf Frieder frieder.schrempf@kontron.de wrote:
As luck would have it, I needed to load a FIT via SDP today, so I came up with a quick patch (see below). There are probably better ways to do this, but it works.
Thanks for your patch!
I would like to give it a try, but it does not apply against U-Boot mainline.
I manually applied it, but failed to build:
cmd/usb_gadget_sdp.c: In function ‘do_sdp’: cmd/usb_gadget_sdp.c:35:2: error: too few arguments to function ‘sdp_handle’ sdp_handle(controller_index);
Could you please rebase it against U-Boot mainline and post it like a formal patch?
And add a SoB line .
Why do you need to load fitImage via SDP btw ?
Hi Marek,
On Thu, May 23, 2019 at 2:54 PM Marek Vasut marek.vasut@gmail.com wrote:
Why do you need to load fitImage via SDP btw ?
Let's suppose a i.MX6 board that boots from eMMC is bricked and we need to load a new U-Boot to repair it.
imx_usb_loader is a very convenient tool to achieve this.
This method has been working well for a long time, but after DM transition we can no longer load and run SPL + u-boot-dtb.img via SDP.
On Thu, May 23, 2019 at 11:29 PM Fabio Estevam festevam@gmail.com wrote:
Hi Marek,
On Thu, May 23, 2019 at 2:54 PM Marek Vasut marek.vasut@gmail.com wrote:
Why do you need to load fitImage via SDP btw ?
Let's suppose a i.MX6 board that boots from eMMC is bricked and we need to load a new U-Boot to repair it.
imx_usb_loader is a very convenient tool to achieve this.
This method has been working well for a long time, but after DM transition we can no longer load and run SPL + u-boot-dtb.img via SDP.
To be prescribe, the issue with FIT formatted u-boot-dtb.img not the DM alone.
On Thu, May 23, 2019 at 3:01 PM Jagan Teki jagan@amarulasolutions.com wrote:
To be prescribe, the issue with FIT formatted u-boot-dtb.img not the DM alone.
Correct, what I meant to say is that after DM conversion we started using FIT image on imx6sabresd board, which prevented SDP download to work.
On Thu, May 23, 2019 at 12:59 PM Fabio Estevam festevam@gmail.com wrote:
Hi Marek,
On Thu, May 23, 2019 at 2:54 PM Marek Vasut marek.vasut@gmail.com wrote:
Why do you need to load fitImage via SDP btw ?
Let's suppose a i.MX6 board that boots from eMMC is bricked and we need to load a new U-Boot to repair it.
imx_usb_loader is a very convenient tool to achieve this.
I have been following this thread, because I have been working through attempting to migrate the imx6q_logic board to SPL_OF_CONTROL which requires SPL_DM.
To working around the issue you're describing, I played with disabling SPL_DM_USB. With that removed, I can still use nearly all the benefits of SPL_DM without losing access to imx_usb_loader. See log:
U-Boot SPL 2019.07-rc2-05214-g3c328a45af (May 23 2019 - 13:24:26 -0500) Trying to boot from USB SDP SDP: initialize... SDP: handle requests... Downloading file of size 626728 to 0x177fffc0... done Jumping to header at 0x177fffc0 Header Tag is not an IMX image
U-Boot 2019.07-rc2-05214-g3c328a45af (May 23 2019 - 13:24:26 -0500)
CPU: Freescale i.MX6Q rev1.5 at 792 MHz Reset cause: POR Model: Logic PD i.MX6QD SOM-M3 (HDMI) DRAM: 2 GiB NAND: 0 MiB MMC: FSL_SDHC: 0, FSL_SDHC: 1 Loading Environment from FAT... OK In: serial Out: serial Err: serial Net: eth0: ethernet@2188000 Hit any key to stop autoboot: 0 i.MX6 Logic #
Having said that, I haven't posted all my updates yet, because I am working on MMC start issues between MMC1 and MMC2. If you'd like to see some patches, etc. I can share them with you.
adam
This method has been working well for a long time, but after DM transition we can no longer load and run SPL + u-boot-dtb.img via SDP. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Hi Adam,
On Thu, May 23, 2019 at 3:28 PM Adam Ford aford173@gmail.com wrote:
I have been following this thread, because I have been working through attempting to migrate the imx6q_logic board to SPL_OF_CONTROL which requires SPL_DM.
To working around the issue you're describing, I played with disabling SPL_DM_USB. With that removed, I can still use nearly all the benefits of SPL_DM without losing access to imx_usb_loader. See log:
I took a look at the configs/imx6q_logic_defconfig file and it does not use FIT support like we do in mx6sabresd.
If I remove FIT support then imx_usb_loader works fine here too.
imx6q_logic_defconfig only supports the mx6q variant, whereas sabresd needs to support mx6q/dl/qp variants , so we use FIT image that contains therese 3 dtbs.
So the problem with SDP at the moment is when trying to load a FIT image.
Thanks
On Thu, May 23, 2019 at 1:35 PM Fabio Estevam festevam@gmail.com wrote:
Hi Adam,
On Thu, May 23, 2019 at 3:28 PM Adam Ford aford173@gmail.com wrote:
I have been following this thread, because I have been working through attempting to migrate the imx6q_logic board to SPL_OF_CONTROL which requires SPL_DM.
To working around the issue you're describing, I played with disabling SPL_DM_USB. With that removed, I can still use nearly all the benefits of SPL_DM without losing access to imx_usb_loader. See log:
I took a look at the configs/imx6q_logic_defconfig file and it does not use FIT support like we do in mx6sabresd.
If I remove FIT support then imx_usb_loader works fine here too.
imx6q_logic_defconfig only supports the mx6q variant, whereas sabresd needs to support mx6q/dl/qp variants , so we use FIT image that contains therese 3 dtbs.
So the problem with SDP at the moment is when trying to load a FIT image.
Sorry. I misunderstood the problem.
Thanks
On 5/23/19 8:37 PM, Adam Ford wrote:
On Thu, May 23, 2019 at 1:35 PM Fabio Estevam festevam@gmail.com wrote:
Hi Adam,
On Thu, May 23, 2019 at 3:28 PM Adam Ford aford173@gmail.com wrote:
I have been following this thread, because I have been working through attempting to migrate the imx6q_logic board to SPL_OF_CONTROL which requires SPL_DM.
To working around the issue you're describing, I played with disabling SPL_DM_USB. With that removed, I can still use nearly all the benefits of SPL_DM without losing access to imx_usb_loader. See log:
I took a look at the configs/imx6q_logic_defconfig file and it does not use FIT support like we do in mx6sabresd.
If I remove FIT support then imx_usb_loader works fine here too.
imx6q_logic_defconfig only supports the mx6q variant, whereas sabresd needs to support mx6q/dl/qp variants , so we use FIT image that contains therese 3 dtbs.
So the problem with SDP at the moment is when trying to load a FIT image.
Sorry. I misunderstood the problem.
Would it rather make sense to just stick with non-DM/DT SPL for iMX6 for now?
On 5/23/19 7:59 PM, Fabio Estevam wrote:
Hi Marek,
On Thu, May 23, 2019 at 2:54 PM Marek Vasut marek.vasut@gmail.com wrote:
Why do you need to load fitImage via SDP btw ?
Let's suppose a i.MX6 board that boots from eMMC is bricked and we need to load a new U-Boot to repair it.
imx_usb_loader is a very convenient tool to achieve this.
This method has been working well for a long time, but after DM transition we can no longer load and run SPL + u-boot-dtb.img via SDP.
Ah, can't you just use either non-DM/DT SPL (which is OK to do) or combine SPL+DT into a single file , like some other boards do ?
On Thu, May 23, 2019 at 7:04 PM Marek Vasut marek.vasut@gmail.com wrote:
Ah, can't you just use either non-DM/DT SPL (which is OK to do) or combine SPL+DT into a single file , like some other boards do ?
There are two orthogonal issues we are discussing:
1. DM SPL size is beyond the limit for mx6sabresd. Yes, not using DM SPL solves the issue here.
2. Not possible to boot FIT image via SDP. This problem is unrelated to number 1 above.
On 5/24/19 12:08 AM, Fabio Estevam wrote:
On Thu, May 23, 2019 at 7:04 PM Marek Vasut marek.vasut@gmail.com wrote:
Ah, can't you just use either non-DM/DT SPL (which is OK to do) or combine SPL+DT into a single file , like some other boards do ?
There are two orthogonal issues we are discussing:
- DM SPL size is beyond the limit for mx6sabresd. Yes, not using DM
SPL solves the issue here.
I think it makes sense to go this way and fix the MX6 before too many people get cranky about this forcible DM/DT push , which cripples the boards left and right.
- Not possible to boot FIT image via SDP. This problem is unrelated
to number 1 above.
Right
On Thu, May 23, 2019 at 7:11 PM Marek Vasut marek.vasut@gmail.com wrote:
I think it makes sense to go this way and fix the MX6 before too many people get cranky about this forcible DM/DT push , which cripples the boards left and right.
Yes, patch has been sent: https://lists.denx.de/pipermail/u-boot/2019-May/370224.html
Hi Fabio,
On 23.05.19 19:45, Fabio Estevam wrote:
Hi Schrempf,
On Thu, May 23, 2019 at 2:26 PM Schrempf Frieder frieder.schrempf@kontron.de wrote:
As luck would have it, I needed to load a FIT via SDP today, so I came up with a quick patch (see below). There are probably better ways to do this, but it works.
Thanks for your patch!
I would like to give it a try, but it does not apply against U-Boot mainline.
I manually applied it, but failed to build:
cmd/usb_gadget_sdp.c: In function ‘do_sdp’: cmd/usb_gadget_sdp.c:35:2: error: too few arguments to function ‘sdp_handle’ sdp_handle(controller_index);
Sorry, I just picked the patch from my messy working tree and it's based on 2019.04 and some other changes.
Could you please rebase it against U-Boot mainline and post it like a formal patch?
I need to do some rebasing and cleanup, but I'm definitely planning to send this as a patch for upstream.
Thanks, Frieder
Hi Schrempf,
On Mon, May 27, 2019 at 3:40 AM Schrempf Frieder frieder.schrempf@kontron.de wrote:
I need to do some rebasing and cleanup, but I'm definitely planning to send this as a patch for upstream.
Excellent, thanks!
Hi Schrempf,
As of now imx usb loader does not process FIT images. Have you added some patch or support on imx usb loader side ?
Thanks and regards, Shyam
On Mon, May 27, 2019 at 12:10 PM Schrempf Frieder frieder.schrempf@kontron.de wrote:
Hi Fabio,
On 23.05.19 19:45, Fabio Estevam wrote:
Hi Schrempf,
On Thu, May 23, 2019 at 2:26 PM Schrempf Frieder frieder.schrempf@kontron.de wrote:
As luck would have it, I needed to load a FIT via SDP today, so I came up with a quick patch (see below). There are probably better ways to do this, but it works.
Thanks for your patch!
I would like to give it a try, but it does not apply against U-Boot mainline.
I manually applied it, but failed to build:
cmd/usb_gadget_sdp.c: In function ‘do_sdp’: cmd/usb_gadget_sdp.c:35:2: error: too few arguments to function ‘sdp_handle’ sdp_handle(controller_index);
Sorry, I just picked the patch from my messy working tree and it's based on 2019.04 and some other changes.
Could you please rebase it against U-Boot mainline and post it like a formal patch?
I need to do some rebasing and cleanup, but I'm definitely planning to send this as a patch for upstream.
Thanks, Frieder _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Hi Shyam,
On 31.05.19 11:10, Shyam Saini wrote:
Hi Schrempf,
As of now imx usb loader does not process FIT images. Have you added some patch or support on imx usb loader side ?
No, I'm using imx_usb_loader only to load the FIT image to DRAM in SPL via SDP. The SPL is then processing the FIT image and loading U-Boot proper from the image.
Regards, Frieder
Thanks and regards, Shyam
On Mon, May 27, 2019 at 12:10 PM Schrempf Frieder frieder.schrempf@kontron.de wrote:
Hi Fabio,
On 23.05.19 19:45, Fabio Estevam wrote:
Hi Schrempf,
On Thu, May 23, 2019 at 2:26 PM Schrempf Frieder frieder.schrempf@kontron.de wrote:
As luck would have it, I needed to load a FIT via SDP today, so I came up with a quick patch (see below). There are probably better ways to do this, but it works.
Thanks for your patch!
I would like to give it a try, but it does not apply against U-Boot mainline.
I manually applied it, but failed to build:
cmd/usb_gadget_sdp.c: In function ‘do_sdp’: cmd/usb_gadget_sdp.c:35:2: error: too few arguments to function ‘sdp_handle’ sdp_handle(controller_index);
Sorry, I just picked the patch from my messy working tree and it's based on 2019.04 and some other changes.
Could you please rebase it against U-Boot mainline and post it like a formal patch?
I need to do some rebasing and cleanup, but I'm definitely planning to send this as a patch for upstream.
Thanks, Frieder _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Hi Jagan
Subject: Re: Cannot boot mx6qsabred with 2019.07-rc2
On Thu, May 23, 2019 at 10:18 PM Fabio Estevam festevam@gmail.com wrote:
On Thu, May 23, 2019 at 1:11 PM Jagan Teki jagan@amarulasolutions.com
wrote:
Don't know whether this is SPL size issue or not? can you try SPL_OF_PLATDATA and TINY* I can see the size reduced with 64512 bytes (one build issue on fdtdec_get_int undefined)
Yes, it does not build with CONFIG_SPL_OF_PLATDATA:
lib/built-in.o: In function `fdtdec_parse_phandle_with_args': /home/fabio/u-boot/lib/fdtdec.c:788: undefined reference to
`fdtdec_get_int'
Couldn't dig much here, would be happy someone can find this?
drivers/built-in.o: In function `fsl_esdhc_probe': /home/fabio/u-boot/drivers/mmc/fsl_esdhc.c:1480: undefined reference to `fdtdec_get_int' /home/fabio/u-boot/drivers/mmc/fsl_esdhc.c:1482: undefined reference to `fdtdec_get_int' /home/fabio/u-boot/drivers/mmc/fsl_esdhc.c:1485: undefined reference
These we can fix, by supporting platdata support into driver.
to `fdtdec_get_int' scripts/Makefile.spl:404: recipe for target 'spl/u-boot-spl' failed make[1]: *** [spl/u-boot-spl] Error 1
Thanks for the suggestions, but at this point I prefer to go with the removal of CONFIG_SPL_DM.
We have 45 days to release, I think we can make these fixes quite normally what do you think? fsl_esdhc.c build I can mark a patch in few days if required.
Are you working on converting the driver to support OF_PLATDATA?
Regards, Peng.
For 2019.07 it would be really nice if we could fix these two issues:
Allow to load a FIT image via Serial Download Protocol
Detect the SPL size overflow in build-time
- We are working on this, 2) can be done.
On Thu, May 23, 2019 at 01:48:21PM -0300, Fabio Estevam wrote:
On Thu, May 23, 2019 at 1:11 PM Jagan Teki jagan@amarulasolutions.com wrote:
Don't know whether this is SPL size issue or not? can you try SPL_OF_PLATDATA and TINY* I can see the size reduced with 64512 bytes (one build issue on fdtdec_get_int undefined)
Yes, it does not build with CONFIG_SPL_OF_PLATDATA:
lib/built-in.o: In function `fdtdec_parse_phandle_with_args': /home/fabio/u-boot/lib/fdtdec.c:788: undefined reference to `fdtdec_get_int' drivers/built-in.o: In function `fsl_esdhc_probe': /home/fabio/u-boot/drivers/mmc/fsl_esdhc.c:1480: undefined reference to `fdtdec_get_int' /home/fabio/u-boot/drivers/mmc/fsl_esdhc.c:1482: undefined reference to `fdtdec_get_int' /home/fabio/u-boot/drivers/mmc/fsl_esdhc.c:1485: undefined reference to `fdtdec_get_int' scripts/Makefile.spl:404: recipe for target 'spl/u-boot-spl' failed make[1]: *** [spl/u-boot-spl] Error 1
Thanks for the suggestions, but at this point I prefer to go with the removal of CONFIG_SPL_DM.
For 2019.07 it would be really nice if we could fix these two issues:
Allow to load a FIT image via Serial Download Protocol
Detect the SPL size overflow in build-time
For #2, I am very hopeful we can pull in Simon Goldschmidt's patch that allows us to set the size limit in such ways as to catch overflows like this.
Am 24.05.2019 um 19:43 schrieb Tom Rini:
On Thu, May 23, 2019 at 01:48:21PM -0300, Fabio Estevam wrote:
On Thu, May 23, 2019 at 1:11 PM Jagan Teki jagan@amarulasolutions.com wrote:
Don't know whether this is SPL size issue or not? can you try SPL_OF_PLATDATA and TINY* I can see the size reduced with 64512 bytes (one build issue on fdtdec_get_int undefined)
Yes, it does not build with CONFIG_SPL_OF_PLATDATA:
lib/built-in.o: In function `fdtdec_parse_phandle_with_args': /home/fabio/u-boot/lib/fdtdec.c:788: undefined reference to `fdtdec_get_int' drivers/built-in.o: In function `fsl_esdhc_probe': /home/fabio/u-boot/drivers/mmc/fsl_esdhc.c:1480: undefined reference to `fdtdec_get_int' /home/fabio/u-boot/drivers/mmc/fsl_esdhc.c:1482: undefined reference to `fdtdec_get_int' /home/fabio/u-boot/drivers/mmc/fsl_esdhc.c:1485: undefined reference to `fdtdec_get_int' scripts/Makefile.spl:404: recipe for target 'spl/u-boot-spl' failed make[1]: *** [spl/u-boot-spl] Error 1
Thanks for the suggestions, but at this point I prefer to go with the removal of CONFIG_SPL_DM.
For 2019.07 it would be really nice if we could fix these two issues:
Allow to load a FIT image via Serial Download Protocol
Detect the SPL size overflow in build-time
For #2, I am very hopeful we can pull in Simon Goldschmidt's patch that allows us to set the size limit in such ways as to catch overflows like this.
Hehe, right, I'm feeling the pressure ;-)
Cheers, Simon
Subject: Re: Cannot boot mx6qsabred with 2019.07-rc2
On Thu, May 23, 2019 at 1:11 PM Jagan Teki jagan@amarulasolutions.com wrote:
Don't know whether this is SPL size issue or not? can you try SPL_OF_PLATDATA and TINY* I can see the size reduced with 64512 bytes (one build issue on fdtdec_get_int undefined)
Yes, it does not build with CONFIG_SPL_OF_PLATDATA:
lib/built-in.o: In function `fdtdec_parse_phandle_with_args': /home/fabio/u-boot/lib/fdtdec.c:788: undefined reference to `fdtdec_get_int' drivers/built-in.o: In function `fsl_esdhc_probe': /home/fabio/u-boot/drivers/mmc/fsl_esdhc.c:1480: undefined reference to `fdtdec_get_int' /home/fabio/u-boot/drivers/mmc/fsl_esdhc.c:1482: undefined reference to `fdtdec_get_int' /home/fabio/u-boot/drivers/mmc/fsl_esdhc.c:1485: undefined reference to `fdtdec_get_int' scripts/Makefile.spl:404: recipe for target 'spl/u-boot-spl' failed make[1]: *** [spl/u-boot-spl] Error 1
Need the following patch.
diff --git a/lib/Makefile b/lib/Makefile index 09c45b8122..66ab6295a5 100644 --- a/lib/Makefile +++ b/lib/Makefile @@ -88,7 +88,7 @@ obj-y += crc32.o obj-$(CONFIG_CRC32C) += crc32c.o obj-y += ctype.o obj-y += div64.o -obj-$(CONFIG_OF_LIBFDT) += fdtdec.o +obj-$(CONFIG_OF_LIBFDT) += fdtdec.o fdtdec_common.o obj-y += hang.o obj-y += linux_compat.o obj-y += linux_string.o
Thanks for the suggestions, but at this point I prefer to go with the removal of CONFIG_SPL_DM.
Some drivers needs converted to use OF_PLATDATA, with remove the libfdt api in fsl_esdhc driver, the size shrinked from ~70KB to ~60KB with OF_PLATDATA.
Regards, Peng.
For 2019.07 it would be really nice if we could fix these two issues:
Allow to load a FIT image via Serial Download Protocol
Detect the SPL size overflow in build-time
Hi Peng,
On Thu, May 16, 2019 at 11:29 PM Peng Fan peng.fan@nxp.com wrote:
You could enable DEBUG in SPL, and disable SPL_SDP because of size will exceeds. Then see what happends. I have no idea, then. My board is REV C4, chip 1.5
My mx6qsabresd is revC2, with a i.MX6Q rev 1.2 populated.
After further investigation we can confirm that the problem is caused by SPL size being greater than the 68kB limit (4KB header + 64KB max size)as explained in include/configs/imx6_spl.h:
--------------- #ifndef __IMX6_SPL_CONFIG_H #define __IMX6_SPL_CONFIG_H
#ifdef CONFIG_SPL /* * see Figure 8-3 in IMX6DQ/IMX6SDL Reference manuals: * - IMX6SDL OCRAM (IRAM) is from 0x00907000 to 0x0091FFFF * - IMX6DQ has 2x IRAM of IMX6SDL but we intend to support IMX6SDL as well * - BOOT ROM stack is at 0x0091FFB8 * - if icache/dcache is enabled (eFuse/strapping controlled) then the * IMX BOOT ROM will setup MMU table at 0x00918000, therefore we need to * fit between 0x00907000 and 0x00918000. * - Additionally the BOOT ROM loads what they consider the firmware image * which consists of a 4K header in front of us that contains the IVT, DCD * and some padding thus 'our' max size is really 0x00908000 - 0x00918000 * or 64KB */ #define CONFIG_SPL_MAX_SIZE 0x10000 #define CONFIG_SPL_STACK 0x0091FFB8 /* * Pad SPL to 68KB (4KB header + 64KB max size). This allows to write the * SPL/U-Boot combination generated with u-boot-with-spl.imx directly to a * boot media (given that boot media specific offset is configured properly). */ #define CONFIG_SPL_PAD_TO 0x11000 ---------------
Here are the tests I ran:
Test 1: Original U-Boot 2019.07-rc2 -----------------------------------------------
SPL: 76800 (75 kB) Result: does not boot
Test 2: Removing extra dtbs -------------------------------------
--- a/configs/mx6sabresd_defconfig +++ b/configs/mx6sabresd_defconfig @@ -59,10 +59,10 @@ CONFIG_EFI_PARTITION=y CONFIG_OF_CONTROL=y CONFIG_SPL_OF_CONTROL=y CONFIG_DEFAULT_DEVICE_TREE="imx6q-sabresd" -CONFIG_OF_LIST="imx6q-sabresd imx6qp-sabresd imx6dl-sabresd" +CONFIG_OF_LIST="imx6q-sabresd" CONFIG_MULTI_DTB_FIT=y CONFIG_SPL_MULTI_DTB_FIT=y -CONFIG_SPL_OF_LIST="imx6dl-sabresd imx6q-sabresd imx6qp-sabresd" +CONFIG_SPL_OF_LIST="imx6q-sabresd" CONFIG_ENV_IS_IN_MMC=y CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y CONFIG_SPL_DM=y
SPL:68608 (67 kB) Result: boots correctly
Test 3: Removing SPL_DM ------------------------------------
--- a/configs/mx6sabresd_defconfig +++ b/configs/mx6sabresd_defconfig @@ -65,7 +65,6 @@ CONFIG_SPL_MULTI_DTB_FIT=y CONFIG_SPL_OF_LIST="imx6dl-sabresd imx6q-sabresd imx6qp-sabresd" CONFIG_ENV_IS_IN_MMC=y CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y -CONFIG_SPL_DM=y CONFIG_USB_FUNCTION_FASTBOOT=y CONFIG_FASTBOOT_BUF_ADDR=0x12000000 CONFIG_FASTBOOT_BUF_SIZE=0x10000000
SPL: 68608 (67 kB) Result: boots correctly
I will send a v2 removing CONFIG_SPL_DM.
Also, the SPL size check should be really done after the multi fit image is concatenated so that we can have a chance to detect such size overflow in build time.
Thanks
Hi Fabio,
Subject: Re: Cannot boot mx6qsabred with 2019.07-rc2
Hi Peng,
On Thu, May 16, 2019 at 11:29 PM Peng Fan peng.fan@nxp.com wrote:
You could enable DEBUG in SPL, and disable SPL_SDP because of size will
exceeds.
Then see what happends. I have no idea, then. My board is REV C4, chip 1.5
My mx6qsabresd is revC2, with a i.MX6Q rev 1.2 populated.
After further investigation we can confirm that the problem is caused by SPL size being greater than the 68kB limit (4KB header + 64KB max size)as explained in include/configs/imx6_spl.h:
#ifndef __IMX6_SPL_CONFIG_H #define __IMX6_SPL_CONFIG_H
#ifdef CONFIG_SPL /*
- see Figure 8-3 in IMX6DQ/IMX6SDL Reference manuals:
- IMX6SDL OCRAM (IRAM) is from 0x00907000 to 0x0091FFFF
- IMX6DQ has 2x IRAM of IMX6SDL but we intend to support IMX6SDL as
well
- BOOT ROM stack is at 0x0091FFB8
- if icache/dcache is enabled (eFuse/strapping controlled) then the
- IMX BOOT ROM will setup MMU table at 0x00918000, therefore we
need to
- fit between 0x00907000 and 0x00918000.
- Additionally the BOOT ROM loads what they consider the firmware
image
- which consists of a 4K header in front of us that contains the IVT, DCD
- and some padding thus 'our' max size is really 0x00908000 -
0x00918000
- or 64KB
*/ #define CONFIG_SPL_MAX_SIZE 0x10000 #define CONFIG_SPL_STACK 0x0091FFB8 /*
- Pad SPL to 68KB (4KB header + 64KB max size). This allows to write the
- SPL/U-Boot combination generated with u-boot-with-spl.imx directly to a
- boot media (given that boot media specific offset is configured properly).
*/
#define CONFIG_SPL_PAD_TO 0x11000
Here are the tests I ran:
Test 1: Original U-Boot 2019.07-rc2
SPL: 76800 (75 kB) Result: does not boot
Test 2: Removing extra dtbs
--- a/configs/mx6sabresd_defconfig +++ b/configs/mx6sabresd_defconfig @@ -59,10 +59,10 @@ CONFIG_EFI_PARTITION=y CONFIG_OF_CONTROL=y CONFIG_SPL_OF_CONTROL=y CONFIG_DEFAULT_DEVICE_TREE="imx6q-sabresd" -CONFIG_OF_LIST="imx6q-sabresd imx6qp-sabresd imx6dl-sabresd" +CONFIG_OF_LIST="imx6q-sabresd" CONFIG_MULTI_DTB_FIT=y CONFIG_SPL_MULTI_DTB_FIT=y -CONFIG_SPL_OF_LIST="imx6dl-sabresd imx6q-sabresd imx6qp-sabresd" +CONFIG_SPL_OF_LIST="imx6q-sabresd" CONFIG_ENV_IS_IN_MMC=y CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y CONFIG_SPL_DM=y
SPL:68608 (67 kB) Result: boots correctly
Test 3: Removing SPL_DM
--- a/configs/mx6sabresd_defconfig +++ b/configs/mx6sabresd_defconfig @@ -65,7 +65,6 @@ CONFIG_SPL_MULTI_DTB_FIT=y CONFIG_SPL_OF_LIST="imx6dl-sabresd imx6q-sabresd imx6qp-sabresd" CONFIG_ENV_IS_IN_MMC=y CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y -CONFIG_SPL_DM=y CONFIG_USB_FUNCTION_FASTBOOT=y CONFIG_FASTBOOT_BUF_ADDR=0x12000000 CONFIG_FASTBOOT_BUF_SIZE=0x10000000
SPL: 68608 (67 kB) Result: boots correctly
I will send a v2 removing CONFIG_SPL_DM.
So what is the real direction moving to use SPL driver, non-dm is allowed in future?
Also, the SPL size check should be really done after the multi fit image is concatenated so that we can have a chance to detect such size overflow in build time.
Agree. I also meet that SPL size is too large on i.MX8/8M, although still have OCRAM for it.
Regards, Peng.
Thanks
On Wed, May 22, 2019 at 01:38:44AM +0000, Peng Fan wrote:
Hi Fabio,
Subject: Re: Cannot boot mx6qsabred with 2019.07-rc2
Hi Peng,
On Thu, May 16, 2019 at 11:29 PM Peng Fan peng.fan@nxp.com wrote:
You could enable DEBUG in SPL, and disable SPL_SDP because of size will
exceeds.
Then see what happends. I have no idea, then. My board is REV C4, chip 1.5
My mx6qsabresd is revC2, with a i.MX6Q rev 1.2 populated.
After further investigation we can confirm that the problem is caused by SPL size being greater than the 68kB limit (4KB header + 64KB max size)as explained in include/configs/imx6_spl.h:
#ifndef __IMX6_SPL_CONFIG_H #define __IMX6_SPL_CONFIG_H
#ifdef CONFIG_SPL /*
- see Figure 8-3 in IMX6DQ/IMX6SDL Reference manuals:
- IMX6SDL OCRAM (IRAM) is from 0x00907000 to 0x0091FFFF
- IMX6DQ has 2x IRAM of IMX6SDL but we intend to support IMX6SDL as
well
- BOOT ROM stack is at 0x0091FFB8
- if icache/dcache is enabled (eFuse/strapping controlled) then the
- IMX BOOT ROM will setup MMU table at 0x00918000, therefore we
need to
- fit between 0x00907000 and 0x00918000.
- Additionally the BOOT ROM loads what they consider the firmware
image
- which consists of a 4K header in front of us that contains the IVT, DCD
- and some padding thus 'our' max size is really 0x00908000 -
0x00918000
- or 64KB
*/ #define CONFIG_SPL_MAX_SIZE 0x10000 #define CONFIG_SPL_STACK 0x0091FFB8 /*
- Pad SPL to 68KB (4KB header + 64KB max size). This allows to write the
- SPL/U-Boot combination generated with u-boot-with-spl.imx directly to a
- boot media (given that boot media specific offset is configured properly).
*/
#define CONFIG_SPL_PAD_TO 0x11000
Here are the tests I ran:
Test 1: Original U-Boot 2019.07-rc2
SPL: 76800 (75 kB) Result: does not boot
Test 2: Removing extra dtbs
--- a/configs/mx6sabresd_defconfig +++ b/configs/mx6sabresd_defconfig @@ -59,10 +59,10 @@ CONFIG_EFI_PARTITION=y CONFIG_OF_CONTROL=y CONFIG_SPL_OF_CONTROL=y CONFIG_DEFAULT_DEVICE_TREE="imx6q-sabresd" -CONFIG_OF_LIST="imx6q-sabresd imx6qp-sabresd imx6dl-sabresd" +CONFIG_OF_LIST="imx6q-sabresd" CONFIG_MULTI_DTB_FIT=y CONFIG_SPL_MULTI_DTB_FIT=y -CONFIG_SPL_OF_LIST="imx6dl-sabresd imx6q-sabresd imx6qp-sabresd" +CONFIG_SPL_OF_LIST="imx6q-sabresd" CONFIG_ENV_IS_IN_MMC=y CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y CONFIG_SPL_DM=y
SPL:68608 (67 kB) Result: boots correctly
Test 3: Removing SPL_DM
--- a/configs/mx6sabresd_defconfig +++ b/configs/mx6sabresd_defconfig @@ -65,7 +65,6 @@ CONFIG_SPL_MULTI_DTB_FIT=y CONFIG_SPL_OF_LIST="imx6dl-sabresd imx6q-sabresd imx6qp-sabresd" CONFIG_ENV_IS_IN_MMC=y CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y -CONFIG_SPL_DM=y CONFIG_USB_FUNCTION_FASTBOOT=y CONFIG_FASTBOOT_BUF_ADDR=0x12000000 CONFIG_FASTBOOT_BUF_SIZE=0x10000000
SPL: 68608 (67 kB) Result: boots correctly
I will send a v2 removing CONFIG_SPL_DM.
So what is the real direction moving to use SPL driver, non-dm is allowed in future?
Also, the SPL size check should be really done after the multi fit image is concatenated so that we can have a chance to detect such size overflow in build time.
Agree. I also meet that SPL size is too large on i.MX8/8M, although still have OCRAM for it.
As came up in another thread, CONFIG_MMC_TINY may be more widely useable and should help with space.
Hi Tom, Peng, Fabio,
On Wed, May 22, 2019 at 01:38:44AM +0000, Peng Fan wrote:
Hi Fabio,
Subject: Re: Cannot boot mx6qsabred with 2019.07-rc2
Hi Peng,
On Thu, May 16, 2019 at 11:29 PM Peng Fan peng.fan@nxp.com wrote:
You could enable DEBUG in SPL, and disable SPL_SDP because of size will
exceeds.
Then see what happends. I have no idea, then. My board is REV C4, chip 1.5
My mx6qsabresd is revC2, with a i.MX6Q rev 1.2 populated.
After further investigation we can confirm that the problem is caused by SPL size being greater than the 68kB limit (4KB header
- 64KB max size)as explained in include/configs/imx6_spl.h:
#ifndef __IMX6_SPL_CONFIG_H #define __IMX6_SPL_CONFIG_H
#ifdef CONFIG_SPL /*
- see Figure 8-3 in IMX6DQ/IMX6SDL Reference manuals:
- IMX6SDL OCRAM (IRAM) is from 0x00907000 to 0x0091FFFF
- IMX6DQ has 2x IRAM of IMX6SDL but we intend to support
IMX6SDL as well
- BOOT ROM stack is at 0x0091FFB8
- if icache/dcache is enabled (eFuse/strapping controlled)
then the
- IMX BOOT ROM will setup MMU table at 0x00918000, therefore
we need to
- fit between 0x00907000 and 0x00918000.
- Additionally the BOOT ROM loads what they consider the
firmware image
- which consists of a 4K header in front of us that contains
the IVT, DCD
- and some padding thus 'our' max size is really 0x00908000 -
0x00918000
- or 64KB
*/ #define CONFIG_SPL_MAX_SIZE 0x10000 #define CONFIG_SPL_STACK 0x0091FFB8 /*
- Pad SPL to 68KB (4KB header + 64KB max size). This allows to
write the
- SPL/U-Boot combination generated with u-boot-with-spl.imx
directly to a
- boot media (given that boot media specific offset is
configured properly). */
#define CONFIG_SPL_PAD_TO 0x11000
Here are the tests I ran:
Test 1: Original U-Boot 2019.07-rc2
SPL: 76800 (75 kB) Result: does not boot
Test 2: Removing extra dtbs
--- a/configs/mx6sabresd_defconfig +++ b/configs/mx6sabresd_defconfig @@ -59,10 +59,10 @@ CONFIG_EFI_PARTITION=y CONFIG_OF_CONTROL=y CONFIG_SPL_OF_CONTROL=y CONFIG_DEFAULT_DEVICE_TREE="imx6q-sabresd" -CONFIG_OF_LIST="imx6q-sabresd imx6qp-sabresd imx6dl-sabresd" +CONFIG_OF_LIST="imx6q-sabresd" CONFIG_MULTI_DTB_FIT=y CONFIG_SPL_MULTI_DTB_FIT=y -CONFIG_SPL_OF_LIST="imx6dl-sabresd imx6q-sabresd imx6qp-sabresd" +CONFIG_SPL_OF_LIST="imx6q-sabresd" CONFIG_ENV_IS_IN_MMC=y CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y CONFIG_SPL_DM=y
SPL:68608 (67 kB) Result: boots correctly
Test 3: Removing SPL_DM
--- a/configs/mx6sabresd_defconfig +++ b/configs/mx6sabresd_defconfig @@ -65,7 +65,6 @@ CONFIG_SPL_MULTI_DTB_FIT=y CONFIG_SPL_OF_LIST="imx6dl-sabresd imx6q-sabresd imx6qp-sabresd" CONFIG_ENV_IS_IN_MMC=y CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y -CONFIG_SPL_DM=y CONFIG_USB_FUNCTION_FASTBOOT=y CONFIG_FASTBOOT_BUF_ADDR=0x12000000 CONFIG_FASTBOOT_BUF_SIZE=0x10000000
SPL: 68608 (67 kB) Result: boots correctly
I will send a v2 removing CONFIG_SPL_DM.
So what is the real direction moving to use SPL driver, non-dm is allowed in future?
I think that CONFIG_SPL_DM would be a natural, next step.
However, from my experience the size of SPL grows considerably when e.g. fitImage is added (~4KiB), DM/DTB support (~8-12KiB), and the OCRAM memory footprint (as we need space to have malloc).
Solution is to use all the CONFIG_*_TINY* options in SPL as well as more widely use OF_PLATDATA. This however, would require further changes in the DM aware (converted) drivers.
Also, the SPL size check should be really done after the multi fit image is concatenated so that we can have a chance to detect such size overflow in build time.
Agree. I also meet that SPL size is too large on i.MX8/8M, although still have OCRAM for it.
As came up in another thread, CONFIG_MMC_TINY may be more widely useable and should help with space.
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de
On Tue, May 21, 2019 at 11:34 PM Tom Rini trini@konsulko.com wrote:
As came up in another thread, CONFIG_MMC_TINY may be more widely useable and should help with space.
How it can be used exactly?
I tried it like this:
--- a/configs/mx6sabresd_defconfig +++ b/configs/mx6sabresd_defconfig @@ -6,7 +6,6 @@ CONFIG_SPL_LIBCOMMON_SUPPORT=y CONFIG_SPL_LIBGENERIC_SUPPORT=y CONFIG_SYS_MALLOC_F_LEN=0x4000 CONFIG_TARGET_MX6SABRESD=y -CONFIG_SPL_MMC_SUPPORT=y CONFIG_SPL_SERIAL_SUPPORT=y CONFIG_NR_DRAM_BANKS=1 CONFIG_SPL=y @@ -100,3 +99,4 @@ CONFIG_USB_HOST_ETHER=y CONFIG_USB_ETHER_ASIX=y CONFIG_DM_VIDEO=y CONFIG_VIDEO_IPUV3=y +CONFIG_SPL_MMC_TINY=y
, but the board does not boot:
U-Boot SPL 2019.07-rc2-00164-ge1a2ed7180-dirty (May 22 2019 - 11:19:41 -0300) SPL: Unsupported Boot Device! SPL: failed to boot from all boot devices ### ERROR ### Please RESET the board ###
On Wed, May 22, 2019 at 11:23:11AM -0300, Fabio Estevam wrote:
On Tue, May 21, 2019 at 11:34 PM Tom Rini trini@konsulko.com wrote:
As came up in another thread, CONFIG_MMC_TINY may be more widely useable and should help with space.
How it can be used exactly?
I tried it like this:
--- a/configs/mx6sabresd_defconfig +++ b/configs/mx6sabresd_defconfig @@ -6,7 +6,6 @@ CONFIG_SPL_LIBCOMMON_SUPPORT=y CONFIG_SPL_LIBGENERIC_SUPPORT=y CONFIG_SYS_MALLOC_F_LEN=0x4000 CONFIG_TARGET_MX6SABRESD=y -CONFIG_SPL_MMC_SUPPORT=y CONFIG_SPL_SERIAL_SUPPORT=y CONFIG_NR_DRAM_BANKS=1 CONFIG_SPL=y @@ -100,3 +99,4 @@ CONFIG_USB_HOST_ETHER=y CONFIG_USB_ETHER_ASIX=y CONFIG_DM_VIDEO=y CONFIG_VIDEO_IPUV3=y +CONFIG_SPL_MMC_TINY=y
, but the board does not boot:
U-Boot SPL 2019.07-rc2-00164-ge1a2ed7180-dirty (May 22 2019 - 11:19:41 -0300) SPL: Unsupported Boot Device! SPL: failed to boot from all boot devices ### ERROR ### Please RESET the board ###
Yes, I was hoping to get Marek or Ezequiel to speak up a bit more on how to configure / use it, in the other thread.
On 5/22/19 5:15 PM, Tom Rini wrote:
On Wed, May 22, 2019 at 11:23:11AM -0300, Fabio Estevam wrote:
On Tue, May 21, 2019 at 11:34 PM Tom Rini trini@konsulko.com wrote:
As came up in another thread, CONFIG_MMC_TINY may be more widely useable and should help with space.
How it can be used exactly?
I tried it like this:
--- a/configs/mx6sabresd_defconfig +++ b/configs/mx6sabresd_defconfig @@ -6,7 +6,6 @@ CONFIG_SPL_LIBCOMMON_SUPPORT=y CONFIG_SPL_LIBGENERIC_SUPPORT=y CONFIG_SYS_MALLOC_F_LEN=0x4000 CONFIG_TARGET_MX6SABRESD=y -CONFIG_SPL_MMC_SUPPORT=y CONFIG_SPL_SERIAL_SUPPORT=y CONFIG_NR_DRAM_BANKS=1 CONFIG_SPL=y @@ -100,3 +99,4 @@ CONFIG_USB_HOST_ETHER=y CONFIG_USB_ETHER_ASIX=y CONFIG_DM_VIDEO=y CONFIG_VIDEO_IPUV3=y +CONFIG_SPL_MMC_TINY=y
, but the board does not boot:
U-Boot SPL 2019.07-rc2-00164-ge1a2ed7180-dirty (May 22 2019 - 11:19:41 -0300) SPL: Unsupported Boot Device! SPL: failed to boot from all boot devices ### ERROR ### Please RESET the board ###
Yes, I was hoping to get Marek or Ezequiel to speak up a bit more on how to configure / use it, in the other thread.
Look at what the CI20 does ? That board boots from SD and uses the TINY stuff.
On Wed, 2019-05-22 at 11:15 -0400, Tom Rini wrote:
On Wed, May 22, 2019 at 11:23:11AM -0300, Fabio Estevam wrote:
On Tue, May 21, 2019 at 11:34 PM Tom Rini trini@konsulko.com wrote:
As came up in another thread, CONFIG_MMC_TINY may be more widely useable and should help with space.
How it can be used exactly?
I tried it like this:
--- a/configs/mx6sabresd_defconfig +++ b/configs/mx6sabresd_defconfig @@ -6,7 +6,6 @@ CONFIG_SPL_LIBCOMMON_SUPPORT=y CONFIG_SPL_LIBGENERIC_SUPPORT=y CONFIG_SYS_MALLOC_F_LEN=0x4000 CONFIG_TARGET_MX6SABRESD=y -CONFIG_SPL_MMC_SUPPORT=y CONFIG_SPL_SERIAL_SUPPORT=y CONFIG_NR_DRAM_BANKS=1 CONFIG_SPL=y @@ -100,3 +99,4 @@ CONFIG_USB_HOST_ETHER=y CONFIG_USB_ETHER_ASIX=y CONFIG_DM_VIDEO=y CONFIG_VIDEO_IPUV3=y +CONFIG_SPL_MMC_TINY=y
, but the board does not boot:
U-Boot SPL 2019.07-rc2-00164-ge1a2ed7180-dirty (May 22 2019 - 11:19:41 -0300) SPL: Unsupported Boot Device! SPL: failed to boot from all boot devices ### ERROR ### Please RESET the board ###
Yes, I was hoping to get Marek or Ezequiel to speak up a bit more on how to configure / use it, in the other thread.
I was planning to look at this, and planned to start with a Wandboard I just happen to have on my desk.
Hi Peng,
On Tue, May 21, 2019 at 10:38 PM Peng Fan peng.fan@nxp.com wrote:
I will send a v2 removing CONFIG_SPL_DM.
So what is the real direction moving to use SPL driver, non-dm is allowed in future?
We are very limited in space when CONFIG_SPL_DM is used on imx6q-sabresd.
With CONFIG_SPL_DM selected the size increase due to the three dtb's is about 8kB.
Even with CONFIG_SPL_DM disabled we ony have 1kB of free space, so I still want to optimize the size further.
Two options that I want also to remove are:
CONFIG_SPL_FS_EXT4=y CONFIG_SPL_I2C_SUPPORT=y
We are at -rc2 now, and I would really like to have mx6sabresd booting again.
Please check my v2 series and see if it looks good.
Thanks
On Thu, May 23, 2019 at 10:49:11AM -0300, Fabio Estevam wrote:
Hi Peng,
On Tue, May 21, 2019 at 10:38 PM Peng Fan peng.fan@nxp.com wrote:
I will send a v2 removing CONFIG_SPL_DM.
So what is the real direction moving to use SPL driver, non-dm is allowed in future?
We are very limited in space when CONFIG_SPL_DM is used on imx6q-sabresd.
With CONFIG_SPL_DM selected the size increase due to the three dtb's is about 8kB.
Even with CONFIG_SPL_DM disabled we ony have 1kB of free space, so I still want to optimize the size further.
So with CONFIG_SPL_DM we're overflowing by ~7kB?
Two options that I want also to remove are:
CONFIG_SPL_FS_EXT4=y CONFIG_SPL_I2C_SUPPORT=y
We are at -rc2 now, and I would really like to have mx6sabresd booting again.
Please check my v2 series and see if it looks good.
We certainly want to do something to fix the regression, agreed.
Looking at the config, can we just use a fake DTB for SPL that works on all 3 boards, rather than 3 DTBs?
On 5/23/19 3:59 PM, Tom Rini wrote:
On Thu, May 23, 2019 at 10:49:11AM -0300, Fabio Estevam wrote:
Hi Peng,
On Tue, May 21, 2019 at 10:38 PM Peng Fan peng.fan@nxp.com wrote:
I will send a v2 removing CONFIG_SPL_DM.
So what is the real direction moving to use SPL driver, non-dm is allowed in future?
We are very limited in space when CONFIG_SPL_DM is used on imx6q-sabresd.
With CONFIG_SPL_DM selected the size increase due to the three dtb's is about 8kB.
Even with CONFIG_SPL_DM disabled we ony have 1kB of free space, so I still want to optimize the size further.
So with CONFIG_SPL_DM we're overflowing by ~7kB?
Two options that I want also to remove are:
CONFIG_SPL_FS_EXT4=y CONFIG_SPL_I2C_SUPPORT=y
We are at -rc2 now, and I would really like to have mx6sabresd booting again.
Please check my v2 series and see if it looks good.
We certainly want to do something to fix the regression, agreed.
Looking at the config, can we just use a fake DTB for SPL that works on all 3 boards, rather than 3 DTBs?
Mind you, all of that seems like a workaround. Removing functionality just to fit the monster with DM/DT in is a no-go. R-Car Gen2 doesn't use DM/DT in SPL because it just won't fit and I believe that absolutely makes sense ; why should we impose DM/DT in SPL on MX6 only to make it less usable?
On Thu, May 23, 2019 at 04:04:17PM +0200, Marek Vasut wrote:
On 5/23/19 3:59 PM, Tom Rini wrote:
On Thu, May 23, 2019 at 10:49:11AM -0300, Fabio Estevam wrote:
Hi Peng,
On Tue, May 21, 2019 at 10:38 PM Peng Fan peng.fan@nxp.com wrote:
I will send a v2 removing CONFIG_SPL_DM.
So what is the real direction moving to use SPL driver, non-dm is allowed in future?
We are very limited in space when CONFIG_SPL_DM is used on imx6q-sabresd.
With CONFIG_SPL_DM selected the size increase due to the three dtb's is about 8kB.
Even with CONFIG_SPL_DM disabled we ony have 1kB of free space, so I still want to optimize the size further.
So with CONFIG_SPL_DM we're overflowing by ~7kB?
Two options that I want also to remove are:
CONFIG_SPL_FS_EXT4=y CONFIG_SPL_I2C_SUPPORT=y
We are at -rc2 now, and I would really like to have mx6sabresd booting again.
Please check my v2 series and see if it looks good.
We certainly want to do something to fix the regression, agreed.
Looking at the config, can we just use a fake DTB for SPL that works on all 3 boards, rather than 3 DTBs?
Mind you, all of that seems like a workaround. Removing functionality just to fit the monster with DM/DT in is a no-go. R-Car Gen2 doesn't use DM/DT in SPL because it just won't fit and I believe that absolutely makes sense ; why should we impose DM/DT in SPL on MX6 only to make it less usable?
Setting aside that as I said you don't have to use DM in SPL, maybe it's also worth noting you don't have to provide "describes the whole board" DTB files. If as far as SPL is concerned there's no difference between board A, B and C, just make a DTS that describes the relevant hardware.
Also, platdata can help here too.
On 5/23/19 5:17 PM, Tom Rini wrote:
On Thu, May 23, 2019 at 04:04:17PM +0200, Marek Vasut wrote:
On 5/23/19 3:59 PM, Tom Rini wrote:
On Thu, May 23, 2019 at 10:49:11AM -0300, Fabio Estevam wrote:
Hi Peng,
On Tue, May 21, 2019 at 10:38 PM Peng Fan peng.fan@nxp.com wrote:
I will send a v2 removing CONFIG_SPL_DM.
So what is the real direction moving to use SPL driver, non-dm is allowed in future?
We are very limited in space when CONFIG_SPL_DM is used on imx6q-sabresd.
With CONFIG_SPL_DM selected the size increase due to the three dtb's is about 8kB.
Even with CONFIG_SPL_DM disabled we ony have 1kB of free space, so I still want to optimize the size further.
So with CONFIG_SPL_DM we're overflowing by ~7kB?
Two options that I want also to remove are:
CONFIG_SPL_FS_EXT4=y CONFIG_SPL_I2C_SUPPORT=y
We are at -rc2 now, and I would really like to have mx6sabresd booting again.
Please check my v2 series and see if it looks good.
We certainly want to do something to fix the regression, agreed.
Looking at the config, can we just use a fake DTB for SPL that works on all 3 boards, rather than 3 DTBs?
Mind you, all of that seems like a workaround. Removing functionality just to fit the monster with DM/DT in is a no-go. R-Car Gen2 doesn't use DM/DT in SPL because it just won't fit and I believe that absolutely makes sense ; why should we impose DM/DT in SPL on MX6 only to make it less usable?
Setting aside that as I said you don't have to use DM in SPL
Right, that's an important concensus .
, maybe it's also worth noting you don't have to provide "describes the whole board" DTB files.
That's what u-boot,dm-spl and CONFIG_OF_SPL_REMOVE_PROPS is for, yes ?
If as far as SPL is concerned there's no difference between board A, B and C, just make a DTS that describes the relevant hardware.
Right
Also, platdata can help here too.
Hi Tom,
Subject: Re: [U-Boot] Cannot boot mx6qsabred with 2019.07-rc2
On Thu, May 23, 2019 at 04:04:17PM +0200, Marek Vasut wrote:
On 5/23/19 3:59 PM, Tom Rini wrote:
On Thu, May 23, 2019 at 10:49:11AM -0300, Fabio Estevam wrote:
Hi Peng,
On Tue, May 21, 2019 at 10:38 PM Peng Fan peng.fan@nxp.com
wrote:
I will send a v2 removing CONFIG_SPL_DM.
So what is the real direction moving to use SPL driver, non-dm is
allowed in future?
We are very limited in space when CONFIG_SPL_DM is used on
imx6q-sabresd.
With CONFIG_SPL_DM selected the size increase due to the three dtb's is about 8kB.
Even with CONFIG_SPL_DM disabled we ony have 1kB of free space, so I still want to optimize the size further.
So with CONFIG_SPL_DM we're overflowing by ~7kB?
Two options that I want also to remove are:
CONFIG_SPL_FS_EXT4=y CONFIG_SPL_I2C_SUPPORT=y
We are at -rc2 now, and I would really like to have mx6sabresd booting
again.
Please check my v2 series and see if it looks good.
We certainly want to do something to fix the regression, agreed.
Looking at the config, can we just use a fake DTB for SPL that works on all 3 boards, rather than 3 DTBs?
Mind you, all of that seems like a workaround. Removing functionality just to fit the monster with DM/DT in is a no-go. R-Car Gen2 doesn't use DM/DT in SPL because it just won't fit and I believe that absolutely makes sense ; why should we impose DM/DT in SPL on MX6 only to make it less usable?
Setting aside that as I said you don't have to use DM in SPL,
I recalled that TPL could be allowed for non-DM, SPL and U-Boot need to migrate to DM, so now/future we non-DM SPL is ok?
Thanks, Peng.
maybe it's also
worth noting you don't have to provide "describes the whole board" DTB files. If as far as SPL is concerned there's no difference between board A, B and C, just make a DTS that describes the relevant hardware.
Also, platdata can help here too.
-- Tom
On 19-05-23 09:59:05, Tom Rini wrote:
On Thu, May 23, 2019 at 10:49:11AM -0300, Fabio Estevam wrote:
Hi Peng,
On Tue, May 21, 2019 at 10:38 PM Peng Fan peng.fan@nxp.com wrote:
I will send a v2 removing CONFIG_SPL_DM.
So what is the real direction moving to use SPL driver, non-dm is allowed in future?
We are very limited in space when CONFIG_SPL_DM is used on imx6q-sabresd.
With CONFIG_SPL_DM selected the size increase due to the three dtb's is about 8kB.
Even with CONFIG_SPL_DM disabled we ony have 1kB of free space, so I still want to optimize the size further.
So with CONFIG_SPL_DM we're overflowing by ~7kB?
Well, the mandatory requirements here are as follow (AFAIK): 1. keep one binary for all imx6dl imx6[qp|dl|q]-sabresd 2. have DM support in SPL
So I guess we have to either prioritize the other needed configs and leave out the one we can do without. That, ofcourse, if we still want to fit in and we still want one binary for all three sabresd boards.
Two options that I want also to remove are:
CONFIG_SPL_FS_EXT4=y CONFIG_SPL_I2C_SUPPORT=y
We are at -rc2 now, and I would really like to have mx6sabresd booting again.
Please check my v2 series and see if it looks good.
We certainly want to do something to fix the regression, agreed.
Looking at the config, can we just use a fake DTB for SPL that works on all 3 boards, rather than 3 DTBs?
-- Tom
U-Boot mailing list U-Boot@lists.denx.de https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.denx...
On Thu, May 23, 2019 at 02:08:23PM +0000, Abel Vesa wrote:
On 19-05-23 09:59:05, Tom Rini wrote:
On Thu, May 23, 2019 at 10:49:11AM -0300, Fabio Estevam wrote:
Hi Peng,
On Tue, May 21, 2019 at 10:38 PM Peng Fan peng.fan@nxp.com wrote:
I will send a v2 removing CONFIG_SPL_DM.
So what is the real direction moving to use SPL driver, non-dm is allowed in future?
We are very limited in space when CONFIG_SPL_DM is used on imx6q-sabresd.
With CONFIG_SPL_DM selected the size increase due to the three dtb's is about 8kB.
Even with CONFIG_SPL_DM disabled we ony have 1kB of free space, so I still want to optimize the size further.
So with CONFIG_SPL_DM we're overflowing by ~7kB?
Well, the mandatory requirements here are as follow (AFAIK):
- keep one binary for all imx6dl imx6[qp|dl|q]-sabresd
- have DM support in SPL
So I guess we have to either prioritize the other needed configs and leave out the one we can do without. That, ofcourse, if we still want to fit in and we still want one binary for all three sabresd boards.
Well, no, you don't have to use DM in SPL. But what I'm wondering is if we need qp/dl/q specific information at the SPL stage or if that can wait until we're doing the real U-Boot.
Hi
On Thu, May 23, 2019 at 4:33 PM Tom Rini trini@konsulko.com wrote:
On Thu, May 23, 2019 at 02:08:23PM +0000, Abel Vesa wrote:
On 19-05-23 09:59:05, Tom Rini wrote:
On Thu, May 23, 2019 at 10:49:11AM -0300, Fabio Estevam wrote:
Hi Peng,
On Tue, May 21, 2019 at 10:38 PM Peng Fan peng.fan@nxp.com wrote:
I will send a v2 removing CONFIG_SPL_DM.
So what is the real direction moving to use SPL driver, non-dm is allowed in future?
We are very limited in space when CONFIG_SPL_DM is used on imx6q-sabresd.
With CONFIG_SPL_DM selected the size increase due to the three dtb's is about 8kB.
Even with CONFIG_SPL_DM disabled we ony have 1kB of free space, so I still want to optimize the size further.
So with CONFIG_SPL_DM we're overflowing by ~7kB?
Well, the mandatory requirements here are as follow (AFAIK):
- keep one binary for all imx6dl imx6[qp|dl|q]-sabresd
- have DM support in SPL
So I guess we have to either prioritize the other needed configs and leave out the one we can do without. That, ofcourse, if we still want to fit in and we still want one binary for all three sabresd boards.
Well, no, you don't have to use DM in SPL. But what I'm wondering is if we need qp/dl/q specific information at the SPL stage or if that can wait until we're doing the real U-Boot.
Is dcd table take space?
Michael
-- Tom _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
On Thu, May 23, 2019 at 04:47:59PM +0200, Michael Nazzareno Trimarchi wrote:
Hi
On Thu, May 23, 2019 at 4:33 PM Tom Rini trini@konsulko.com wrote:
On Thu, May 23, 2019 at 02:08:23PM +0000, Abel Vesa wrote:
On 19-05-23 09:59:05, Tom Rini wrote:
On Thu, May 23, 2019 at 10:49:11AM -0300, Fabio Estevam wrote:
Hi Peng,
On Tue, May 21, 2019 at 10:38 PM Peng Fan peng.fan@nxp.com wrote:
> I will send a v2 removing CONFIG_SPL_DM.
So what is the real direction moving to use SPL driver, non-dm is allowed in future?
We are very limited in space when CONFIG_SPL_DM is used on imx6q-sabresd.
With CONFIG_SPL_DM selected the size increase due to the three dtb's is about 8kB.
Even with CONFIG_SPL_DM disabled we ony have 1kB of free space, so I still want to optimize the size further.
So with CONFIG_SPL_DM we're overflowing by ~7kB?
Well, the mandatory requirements here are as follow (AFAIK):
- keep one binary for all imx6dl imx6[qp|dl|q]-sabresd
- have DM support in SPL
So I guess we have to either prioritize the other needed configs and leave out the one we can do without. That, ofcourse, if we still want to fit in and we still want one binary for all three sabresd boards.
Well, no, you don't have to use DM in SPL. But what I'm wondering is if we need qp/dl/q specific information at the SPL stage or if that can wait until we're doing the real U-Boot.
Is dcd table take space?
The DCD table is included in that hard size limit, but yes, if there's QP/DL/Q specific stuff that we could handle via the plugin mechanism or similar, that might be part of the solution.
On 5/23/19 4:50 PM, Tom Rini wrote:
On Thu, May 23, 2019 at 04:47:59PM +0200, Michael Nazzareno Trimarchi wrote:
Hi
On Thu, May 23, 2019 at 4:33 PM Tom Rini trini@konsulko.com wrote:
On Thu, May 23, 2019 at 02:08:23PM +0000, Abel Vesa wrote:
On 19-05-23 09:59:05, Tom Rini wrote:
On Thu, May 23, 2019 at 10:49:11AM -0300, Fabio Estevam wrote:
Hi Peng,
On Tue, May 21, 2019 at 10:38 PM Peng Fan peng.fan@nxp.com wrote:
>> I will send a v2 removing CONFIG_SPL_DM. > > So what is the real direction moving to use SPL driver, non-dm is allowed in future?
We are very limited in space when CONFIG_SPL_DM is used on imx6q-sabresd.
With CONFIG_SPL_DM selected the size increase due to the three dtb's is about 8kB.
Even with CONFIG_SPL_DM disabled we ony have 1kB of free space, so I still want to optimize the size further.
So with CONFIG_SPL_DM we're overflowing by ~7kB?
Well, the mandatory requirements here are as follow (AFAIK):
- keep one binary for all imx6dl imx6[qp|dl|q]-sabresd
- have DM support in SPL
So I guess we have to either prioritize the other needed configs and leave out the one we can do without. That, ofcourse, if we still want to fit in and we still want one binary for all three sabresd boards.
Well, no, you don't have to use DM in SPL. But what I'm wondering is if we need qp/dl/q specific information at the SPL stage or if that can wait until we're doing the real U-Boot.
Is dcd table take space?
The DCD table is included in that hard size limit, but yes, if there's QP/DL/Q specific stuff that we could handle via the plugin mechanism or similar, that might be part of the solution.
You do need Q/DL/S specific stuff in SPL for e.g. pinmux . And you want to minimize the DCD table and move all that logic into SPL, since the DCD is rather limited.
participants (14)
-
Abel Vesa -
Adam Ford -
Ezequiel Garcia -
Fabio Estevam -
Jagan Teki -
Lukasz Majewski -
Marek Vasut -
Marek Vasut -
Michael Nazzareno Trimarchi -
Peng Fan -
Schrempf Frieder -
Shyam Saini -
Simon Goldschmidt -
Tom Rini