Hi Bryan,
Le 14/05/2019 à 00:13, Bryan O'Donoghue a écrit :
On 09/05/2019 16:32, Bryan O'Donoghue wrote:
On 08/05/2019 20:33, Pierre-Jean Texier wrote:
Hi Bryan,
Le 08/05/2019 à 20:14, Bryan O'Donoghue a écrit :
Reusing the loadaddr to load the boot script breaks some of the
logic we
want to have around the bootscript/FIT load addresses. Making a
dedicated
bootscript address allows us to differentiate the bootscript load
address
from the Linux Kernel or OPTEE load address, thus ensuring that no
matter
what the load sequence the bootscript and Kernel/OPTEE binary load
addresses do not conflict.
Signed-off-by: Bryan O'Donoghue <bryan.odonog...@linaro.org>
---
include/configs/warp7.h | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/include/configs/warp7.h b/include/configs/warp7.h
index 95955fd626..0c63050833 100644
--- a/include/configs/warp7.h
+++ b/include/configs/warp7.h
@@ -50,6 +50,7 @@
"script=boot.scr\0" \
"bootscr_fitimage_name=bootscr\0" \
"script_signed=boot.scr.imx-signed\0" \
+ "bootscriptaddr=0x83200000\0" \
"image=zImage\0" \
"console=ttymxc0\0" \
"ethact=usb_ether\0" \
@@ -70,16 +71,16 @@
"warp7_auth_or_fail=hab_auth_img_or_fail ${hab_ivt_addr}
${filesize} 0;\0" \
"do_bootscript_hab=" \
"if test ${hab_enabled} -eq 1; then " \
- "setexpr hab_ivt_addr ${loadaddr} - ${ivt_offset}; " \
+ "setexpr hab_ivt_addr ${bootscriptaddr} -
${ivt_offset}; " \
"setenv script ${script_signed}; " \
"load mmc ${mmcdev}:${mmcpart} ${hab_ivt_addr}
${script}; " \
"run warp7_auth_or_fail; " \
"run bootscript; "\
"fi;\0" \
"loadbootscript=" \
- "load mmc ${mmcdev}:${mmcpart} ${loadaddr} ${script};\0" \
+ "load mmc ${mmcdev}:${mmcpart} ${bootscriptaddr}
${script};\0" \
"bootscript=echo Running bootscript from mmc ...; " \
- "source\0" \
+ BOOT_SCR_STRING \
"loadimage=load mmc ${mmcdev}:${mmcpart} ${loadaddr}
${image}\0" \
"loadfdt=load mmc ${mmcdev}:${mmcpart} ${fdt_addr}
${fdt_file}\0" \
"mmcboot=echo Booting from mmc ...; " \
Instead of implementing a new variable (bootscriptaddr), I think
(IMHO) it's time to migrate
to distroboot for the WaRP7 (like pico imx7 for instance >
In fact, in this specific case, this allows to use the common
scriptaddr[1] variable.
FYI, this is a task I am currently working on [2] (work in
progress). Maybe we could integrate this migration into this series ?
Sure.
Let me give it a test later tonight/tomorrow
Hi Pierre,
I've applied your patch on-top of of a 3 day old master
* 60277e4bcc - (HEAD) warp7: add distroboot support (27 hours ago)
* 4ca7700d2c - imx: Use a convenient default value for
SYS_MALLOC_F_LEN (27 hours ago)
* 48372a5af6 - Remove whitelist entry for CONFIG_CRC32 (3 days ago)
* 4ad2c8953d - Remove #define CONFIG_CRC32 (3 days ago)
* 661bbc50d3 - mtd: ubi: Remove select for non existent option (3 days
ago)
* 2b841dba5c - cmd: ubifs: Remove select for non-existent option (3
days ago)
* b8de00c671 - Remove whitelist entry for CONFIG_GPIO (3 days ago)
* 26680b9f3a - sysreset: select DM_GPIO instead of GPIO (3 days ago)
* 927a37df9f - Merge branch '2019-05-09-master-imports' (3 days ago)
should this apply in isolation ?
Not necessarily, on my side everything working well on-top of master,
for example:
Hit any key to stop autoboot: 0
=> run bootcmd_mmc0
switch to partitions #0, OK
mmc0(part 0) is current device
Scanning mmc 0:1...
Found U-Boot script /boot.scr
247 bytes read in 1 ms (241.2 KiB/s)
## Executing script at 80800000
8923088 bytes read in 131 ms (65 MiB/s)
26889 bytes read in 5 ms (5.1 MiB/s)
Kernel image @ 0x80800000 [ 0x000000 - 0x8827d0 ]
## Flattened Device Tree blob at 83000000
Booting using the fdt blob at 0x83000000
Using Device Tree in place at 83000000, end 83009908
Starting kernel ...
[ 0.000000] Booting Linux on physical CPU 0x0
I get a dead-loop on USB CDC ethernet...
=> reset
resetting ...
U-Boot 2019.07-rc1-00457-g60277e4bcc (May 13 2019 - 23:11:24 +0100)
CPU: Freescale i.MX7S rev1.2 800 MHz (running at 792 MHz)
CPU: Extended Commercial temperature grade (-20C to 105C) at 47C
Reset cause: POR
Model: Warp i.MX7 Board
Board: WARP7 in secure mode OPTEE DRAM 0x9d000000-0xa0000000
DRAM: 464 MiB
PMIC: PFUZE3000 DEV_ID=0x30 REV_ID=0x11
MMC: FSL_SDHC: 1, FSL_SDHC: 0
Loading Environment from MMC... *** Warning - bad CRC, using default
environment
In: serial@30860000
Out: serial@30860000
Err: serial@30860000
SEC0: RNG instantiated
Net: usb_ether
Warning: usb_ether (eth0) using random MAC address - b6:5e:3c:03:d8:8e
Hit any key to stop autoboot: 0
switch to partitions #0, OK
mmc0(part 0) is current device
Scanning mmc 0:1...
Found U-Boot script /boot.scr
11090492 bytes read in 146 ms (72.4 MiB/s)
## Executing script at 80800000
No FIT subimage unit name
SCRIPT FAILED: continuing...
It seems your problem is here. In fact, if this action fail,
U-Boot try to run network booting (PXE, defined in warp7.h).
For your tests, the command 'bootcmd_mmc0' is sufficient.
FYI, my setup is not exactly the the same as
you have (with the CONFIG_FIT_SIGNATURE option enabled for sure).
I'm going to do some tests with this configuration.
Pierre-Jean
28970 bytes read in 7 ms (3.9 MiB/s)
starting USB...
Bus usb@30b10000: scanning bus usb@30b10000 for devices... 1 USB
Device(s) found
using ci_udc, OUT ep2out-bulk IN ep1in-bulk STATUS ep3in-int
MAC de:ad:be:af:00:01
HOST MAC de:ad:be:af:00:00
high speed config #1: 2 mA, Ethernet Gadget, using CDC Ethernet
The remote end did not respond in time.missing environment variable:
pxeuuid
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/00000000
using ci_udc, OUT ep2out-bulk IN ep1in-bulk STATUS ep3in-int
MAC de:ad:be:af:00:01
HOST MAC de:ad:be:af:00:00
high speed config #1: 2 mA, Ethernet Gadget, using CDC Ethernet
The remote end did not respond in time.missing environment variable:
bootfile
Retrieving file: pxelinux.cfg/0000000
using ci_udc, OUT ep2out-bulk IN ep1in-bulk STATUS ep3in-int
MAC de:ad:be:af:00:01
HOST MAC de:ad:be:af:00:00
high speed config #1: 2 mA, Ethernet Gadget, using CDC Ethernet
The remote end did not respond in time.missing environment variable:
bootfile
---
bod
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
