Re: [U-Boot] Booting from network
On Sun, 7 Apr 2019, 9:03 AM U.Mutlu, wrote:
> I'm booting over the network (GbE) from a tftp server.
> It works, but is IMHO very slow.
> Is there a faster method for booting over the net?
>
TFTP is about as good as your going to get in u-boot right now.
Because TFTP sends a block at a time waiting for an ack between blocks it's
not going to be as fast as something that runs over TCP and benefits from
buffering.
One tunable you might get some use out of is $tftpblocksize, this will
increase the number of bytes per block. Try setting this to around 1400
keeping the overall Ethernet frame under 1518.
boot.cmd:
> dhcp 0x4900
> tftpboot 0x4600 192.168.1.201:uImage
> tftpboot 0x4900 192.168.1.201:u-boot.dtb
> setenv bootargs console=ttyS0,115200 root=/dev/sda1 rootwait panic=10
> rootfstype=ext4 rw ${extra}
> bootm 0x4600 - 0x4900
>
> Btw, in the above script, can I safely replace the addresses
> with ${kloadaddr} and ${fdtaddr} ?
> I wonder where these variables get set or obtained from.
> (I saw these variables somewhere on the net, but there was no
> initialisation,
> so I assumed it must be something internal/intrinsic, right?)
>
To my knowledge the only intrinsics are $loadaddr, $fileaddr and $filesize.
The latter two are set after a successful load. However plenty of boards
have $fdtaddr etc in their default environment so you might have acces to
those depending on your board.
And: though my board can output via HDMI, I've no monitor attached,
> and a serial cable (TTY to USB) I don't have at the moment.
> Is there another method to get the u-boot output (or log) to be sent to a
> remote host/log?
>
I've never used in personally but CONFIG_NET_CONSOLE exists, I believe its
only good for output.
I'd still recommend getting a serial cable if your going to be playing with
u-boot becasue at some point you'll do something that stops your board from
booting.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PULL] u-boot-usb/master
On Wed, Apr 03, 2019 at 01:48:46PM +0200, Marek Vasut wrote: > The following changes since commit bcd40c347d2c983625065ec70e9e9e1f98b42baf: > > Merge branch 'master' of git://git.denx.de/u-boot-sunxi (2019-04-01 > 12:31:22 -0400) > > are available in the Git repository at: > > git://git.denx.de/u-boot-usb.git master > > for you to fetch changes up to 2a766db11a7e3129db0c893a43661ed7ee944c55: > > doc: Fix outdated ohci board hook documentation (2019-04-02 12:52:54 > +0200) > Applied (a while ago, but I don't see my own email) to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-imx u -boot-imx-201900405
On Fri, Apr 05, 2019 at 12:27:29PM +0200, Stefano Babic wrote: > Hi Tom, > > some fixes for release. Travis: > > https://travis-ci.org/sbabic/u-boot-imx/builds/514637506 > > The following changes since commit 00102ae52055e294ac37ae1380f37620f4a8bb26: > > pico-imx7d: README: Recommend the usage of a USB hub (2019-03-31 > 20:19:19 +0200) > > are available in the Git repository at: > > git://www.denx.de/git/u-boot-imx.git tags/u-boot-imx-20190405 > > for you to fetch changes up to da60b4301c77fdc0ce16a4f6fb6dc04b69b6282c: > > DTS: Fix ETH PHY reset on HSC|DDC boards (imx53) (2019-04-02 13:44:18 > +0200) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] crypto: fsl: jr: Make job-rings assignment non-Secure dependent
Hi Bryan,
Seems that my last email didn't get in U-Boot mailing list, I'm sending again.
Em sáb, 6 de abr de 2019 às 12:21, Bryan O'Donoghue
escreveu:
>
>
>
> On 05/04/2019 17:16, Breno Matheus Lima wrote:
> > + if ((IS_ENABLED(CONFIG_OPTEE) ||
> > + !IS_ENABLED(CONFIG_ARMV7_BOOT_SEC_DEFAULT)) &&
> > + !IS_ENABLED(CONFIG_CMD_DEKBLOB)) {
>
> So.
>
> How does this patch work if you want to do HABv4 encrypted
> authentication of an OP-TEE image prior to booting it ?
Thanks for your comments and for pointing this out, I agree that this
can be an issue for OP-TEE users that may want to decrypt additional
boot images at U-Boot level.
The main issue is that all users are currently impacted in first
authentication/decryption executed at BootROM level:
BootROM -> HABv4 -> U-Boot
We may need to come up with a solution suitable for all use cases
>
> i.e.
>
> You'll switch the job-ring ownership over to non-trusted world, call HAB
> and the BootROM will fail to authenticate.
>
> How about we improve the hab driver in u-boot ?
>
> 1. I notice somebody has already added a save_gd()/restore_gd() pair
> 2. How about a save_jr()/restore_jr() pair and
> 3. a bootrom_jr_setup() ?
>
> In pseudocode then
>
> do_hab_auth()
> {
> save_jr(); // save current job-ring context
> bootrom_jr_setup(); // set job-ring to bootrom mode
> hab_rvt_authenticate();
> restore_jr(); // restore previous job-ring context
> }
>
> That gets us out of the nasty business of
>
> 1. Constraining the use case of CONFIG_OPTEE=y &&
> authenticate(encrypted-dek-blob);
>
> 2. Pushing changes into upstream OP-TEE for job-ring assignment
>
> IMV - we should save and restore the job ring context so that all of
> this stuff will "just work"
>
> That should work for
>
> BootROM -> u-boot -> HABv4 auth(encryptedblob) -> Linux
>
> and
>
> BootROM -> u-boot -> run optee -> HABv4 auth(encrypted blob) -> Linux
>
> Basically you've described and additional dependency the BootROM has, so
> lets just "switch context" prior to calling into the BootROM and restore
> to a default non-secure job-ring assignment after.
Yes, this can work for OP-TEE users decrypting additional boot images
at U-Boot level, however all users won't be able to
authenticate/decrypt the initial boot image at BootROM level. Out of
reset CAAM job rings are assigned to TrustZone secure world and
BootROM code is expecting blobs generated by the same environment.
What about moving the job rings assignment to OP-TEE level? Something
similar as we currently have in imx-optee-os project?
https://source.codeaurora.org/external/imx/imx-optee-os/tree/core/drivers/caam/hal/imx_6_7/hal_jr.c?h=imx_4.14.78_1.0.0_ga#n31
U-Boot is running in TrustZone secure world in most of targets, in my
opinion it makes sense to have at least 1 job ring assigned to
TrustZone secure world.
Best regards,
Breno Lima
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] crypto: fsl: jr: Make job-rings assignment non-Secure dependent
Hi Bryan,
Em sáb, 6 de abr de 2019 às 12:21, Bryan O'Donoghue
escreveu:
>
>
>
> On 05/04/2019 17:16, Breno Matheus Lima wrote:
> > + if ((IS_ENABLED(CONFIG_OPTEE) ||
> > + !IS_ENABLED(CONFIG_ARMV7_BOOT_SEC_DEFAULT)) &&
> > + !IS_ENABLED(CONFIG_CMD_DEKBLOB)) {
>
> So.
>
> How does this patch work if you want to do HABv4 encrypted
> authentication of an OP-TEE image prior to booting it ?
Thanks for your comments and for pointing this out, I agree that this
can be an issue for OP-TEE users that may want to decrypt additional
boot images at U-Boot level.
The main issue is that all users are currently impacted in first
authentication/decryption executed at BootROM level:
BootROM -> HABv4 -> U-Boot
We may need to come up with a solution suitable for all use cases.
>
> i.e.
>
> You'll switch the job-ring ownership over to non-trusted world, call HAB
> and the BootROM will fail to authenticate.
>
> How about we improve the hab driver in u-boot ?
>
> 1. I notice somebody has already added a save_gd()/restore_gd() pair
> 2. How about a save_jr()/restore_jr() pair and
> 3. a bootrom_jr_setup() ?
>
> In pseudocode then
>
> do_hab_auth()
> {
> save_jr(); // save current job-ring context
> bootrom_jr_setup(); // set job-ring to bootrom mode
> hab_rvt_authenticate();
> restore_jr(); // restore previous job-ring context
> }
>
> That gets us out of the nasty business of
>
> 1. Constraining the use case of CONFIG_OPTEE=y &&
> authenticate(encrypted-dek-blob);
>
> 2. Pushing changes into upstream OP-TEE for job-ring assignment
>
> IMV - we should save and restore the job ring context so that all of
> this stuff will "just work"
>
> That should work for
>
> BootROM -> u-boot -> HABv4 auth(encryptedblob) -> Linux
>
> and
>
> BootROM -> u-boot -> run optee -> HABv4 auth(encrypted blob) -> Linux
>
> Basically you've described and additional dependency the BootROM has, so
> lets just "switch context" prior to calling into the BootROM and restore
> to a default non-secure job-ring assignment after.
Yes, this can work for OP-TEE users decrypting additional boot images
at U-Boot level, however all users won't be able to
authenticate/decrypt the initial boot image at BootROM level. Out of
reset CAAM job rings are assigned to TrustZone secure world and
BootROM code is expecting blobs generated by the same environment.
What about moving the job rings assignment to OP-TEE level? Something
similar as we currently have in imx-optee-os project?
https://source.codeaurora.org/external/imx/imx-optee-os/tree/core/drivers/caam/hal/imx_6_7/hal_jr.c?h=imx_4.14.78_1.0.0_ga#n31
U-Boot is running in TrustZone secure world in most of targets, in my
opinion it makes sense to have at least 1 job ring assigned to
TrustZone secure world.
Best regards,
Breno Lima
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] Booting from network
I'm booting over the network (GbE) from a tftp server.
It works, but is IMHO very slow.
Is there a faster method for booting over the net?
boot.cmd:
dhcp 0x4900
tftpboot 0x4600 192.168.1.201:uImage
tftpboot 0x4900 192.168.1.201:u-boot.dtb
setenv bootargs console=ttyS0,115200 root=/dev/sda1 rootwait panic=10
rootfstype=ext4 rw ${extra}
bootm 0x4600 - 0x4900
Btw, in the above script, can I safely replace the addresses
with ${kloadaddr} and ${fdtaddr} ?
I wonder where these variables get set or obtained from.
(I saw these variables somewhere on the net, but there was no initialisation,
so I assumed it must be something internal/intrinsic, right?)
And: though my board can output via HDMI, I've no monitor attached,
and a serial cable (TTY to USB) I don't have at the moment.
Is there another method to get the u-boot output (or log) to be sent to a
remote host/log?
Thx
--
U.Mutlu
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/1] efi_loader: correct CTRL-A - CTRL-Z console input
In the extended text input protocol CTRL-A - CTRL-Z have to be signaled as
Unicode characters a-z or A-Z depending on the shift state and not as 0x01
to 0x1a.
This patch is required for using the EFI shell `edit` command.
Signed-off-by: Heinrich Schuchardt
---
lib/efi_loader/efi_console.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/lib/efi_loader/efi_console.c b/lib/efi_loader/efi_console.c
index 8e0965bfc89..051fc1d339f 100644
--- a/lib/efi_loader/efi_console.c
+++ b/lib/efi_loader/efi_console.c
@@ -797,9 +797,26 @@ static efi_status_t EFIAPI efi_cin_read_key_stroke_ex(
ret = EFI_NOT_READY;
goto out;
}
+ /*
+* CTRL+A - CTRL+Z have to be signaled as a - z.
+* SHIFT+CTRL+A - SHIFT+CTRL+Z have to be signaled as A - Z.
+*/
+ switch (next_key.key.unicode_char) {
+ case 0x01 ... 0x07:
+ case 0x0b ... 0x0c:
+ case 0x0e ... 0x1a:
+ if (!(next_key.key_state.key_toggle_state &
+ EFI_CAPS_LOCK_ACTIVE) ^
+ !(next_key.key_state.key_shift_state &
+ (EFI_LEFT_SHIFT_PRESSED | EFI_RIGHT_SHIFT_PRESSED)))
+ next_key.key.unicode_char += 0x40;
+ else
+ next_key.key.unicode_char += 0x60;
+ }
*key_data = next_key;
key_available = false;
efi_con_in.wait_for_key->is_signaled = false;
+
out:
return EFI_EXIT(ret);
}
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] mmc: add eraseenv command
"mmc eraseenv" allows to erase the section on mmc where env is stored
Signed-off-by: Frank Wunderlich
---
cmd/mmc.c | 33 +
1 file changed, 33 insertions(+)
diff --git a/cmd/mmc.c b/cmd/mmc.c
index 8bc3648193..b8e2c353b4 100644
--- a/cmd/mmc.c
+++ b/cmd/mmc.c
@@ -441,6 +441,37 @@ static int do_mmc_erase(cmd_tbl_t *cmdtp, int flag,
return (n == cnt) ? CMD_RET_SUCCESS : CMD_RET_FAILURE;
}
+
+static int do_mmc_erase_env(cmd_tbl_t *cmdtp, int flag,
+ int argc, char * const argv[])
+{
+ struct mmc *mmc;
+ u32 blk, cnt, n;
+
+ if (argc != 1)
+ return CMD_RET_USAGE;
+
+ mmc = init_mmc_device(curr_device, false);
+
+ if (!mmc)
+ return CMD_RET_FAILURE;
+
+ blk = CONFIG_ENV_OFFSET / mmc->read_bl_len;
+ cnt = CONFIG_ENV_SIZE / mmc->read_bl_len;
+
+ printf("\nMMC erase env: dev # %d, block # %d (0x%8x), count %d
(0x%8x)",
+ curr_device, blk, blk * mmc->read_bl_len,
+ cnt, cnt * mmc->read_bl_len);
+
+ if (mmc_getwp(mmc) == 1) {
+ printf("Error: card is write protected!\n");
+ return CMD_RET_FAILURE;
+ }
+ n = blk_derase(mmc_get_blk_desc(mmc), blk, cnt);
+ printf("%d blocks erased: %s\n", n, (n == cnt) ? "OK" : "ERROR");
+
+ return (n == cnt) ? CMD_RET_SUCCESS : CMD_RET_FAILURE;
+}
#endif
static int do_mmc_rescan(cmd_tbl_t *cmdtp, int flag,
@@ -878,6 +909,7 @@ static cmd_tbl_t cmd_mmc[] = {
#if CONFIG_IS_ENABLED(MMC_WRITE)
U_BOOT_CMD_MKENT(write, 4, 0, do_mmc_write, "", ""),
U_BOOT_CMD_MKENT(erase, 3, 0, do_mmc_erase, "", ""),
+ U_BOOT_CMD_MKENT(eraseenv, 1, 0, do_mmc_erase_env, "", ""),
#endif
#if CONFIG_IS_ENABLED(CMD_MMC_SWRITE)
U_BOOT_CMD_MKENT(swrite, 3, 0, do_mmc_sparse_write, "", ""),
@@ -940,6 +972,7 @@ U_BOOT_CMD(
"mmc swrite addr blk#\n"
#endif
"mmc erase blk# cnt\n"
+ "mmc eraseenv - erase environment\n"
"mmc rescan\n"
"mmc part - lists available partition on current mmc device\n"
"mmc dev [dev] [part] - show or set current mmc device [partition]\n"
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] Enabling external watchdog support u-boot NXP imx6
Hello, I'm using external watchdog MAX6751 for imx6q board and i need to trigger it in u-boot, otherwise system would reset. The reset time is about 1 sec. I've added initialization of GPIO PAD to the board support code and function hw_watchdog_reset(). When i enable CONFIG_HW_WATCHDOG and compile u-boot, it does not load at all. When i disable CONFIG_HW_WATCHSOG, everything boots fine. Did anybody have any issues of auto-triggering watchdogs in u-boot? Thanks a lot Konstantyn ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v1 0/5] colibri imx8qxp 2gb wb it v1.0b module support
This series fixes the i.MX 8QXP SCFW API header file, adds support for more lpuart instances, cleans-up and extends the Toradex SKU handling and last but not least introduces support for the Toradex Colibri iMX8QXP 2GB WB IT V1.0B module. This series is available together with my previous series addressing Apalis and Colibri iMX6 as well as Colibri Vybrid aka VF50/VF61 and Colibri iMX6ULL on our git server [1]. [1] http://git.toradex.com/cgit/u-boot-toradex.git/log/?h=for-next Marcel Ziswiler (5): misc: imx8: remove duplicates from scfw api arm: dts: imx8dx: add lpuart1, lpuart2, lpuart3 board: toradex: tdx-cfg-block: clean-up sku handling board: toradex: tdx-cfg-block: add new skus board: toradex: add colibri imx8qxp 2gb wb it v1.0b module support arch/arm/dts/Makefile | 4 +- arch/arm/dts/fsl-imx8dx.dtsi | 54 +++ arch/arm/dts/fsl-imx8qxp-colibri-u-boot.dtsi | 112 ++ arch/arm/dts/fsl-imx8qxp-colibri.dts | 328 ++ arch/arm/include/asm/arch-imx8/sci/sci.h | 4 - arch/arm/mach-imx/imx8/Kconfig| 6 + board/toradex/colibri-imx8qxp/Kconfig | 30 ++ board/toradex/colibri-imx8qxp/MAINTAINERS | 9 + board/toradex/colibri-imx8qxp/Makefile| 7 + board/toradex/colibri-imx8qxp/README | 67 .../toradex/colibri-imx8qxp/colibri-imx8qxp.c | 211 +++ board/toradex/colibri-imx8qxp/imximage.cfg| 24 ++ board/toradex/common/tdx-cfg-block.c | 19 +- board/toradex/common/tdx-cfg-block.h | 29 +- configs/colibri-imx8qxp_defconfig | 53 +++ include/configs/colibri-imx8qxp.h | 240 + 16 files changed, 1178 insertions(+), 19 deletions(-) create mode 100644 arch/arm/dts/fsl-imx8qxp-colibri-u-boot.dtsi create mode 100644 arch/arm/dts/fsl-imx8qxp-colibri.dts create mode 100644 board/toradex/colibri-imx8qxp/Kconfig create mode 100644 board/toradex/colibri-imx8qxp/MAINTAINERS create mode 100644 board/toradex/colibri-imx8qxp/Makefile create mode 100644 board/toradex/colibri-imx8qxp/README create mode 100644 board/toradex/colibri-imx8qxp/colibri-imx8qxp.c create mode 100644 board/toradex/colibri-imx8qxp/imximage.cfg create mode 100644 configs/colibri-imx8qxp_defconfig create mode 100644 include/configs/colibri-imx8qxp.h -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/1] efi_loader: enable file SetInfo()
EFI shell command edit uses the SetInfo() methods to unset the read only
attribute of the file to be edited. So let efi_file_setinfo() return
success in this case.
Return an error if the function is called for to rename or resize a file
as we do not support this yet.
Signed-off-by: Heinrich Schuchardt
---
lib/efi_loader/efi_file.c | 67 +--
1 file changed, 65 insertions(+), 2 deletions(-)
diff --git a/lib/efi_loader/efi_file.c b/lib/efi_loader/efi_file.c
index 80adebbac34..4c3f04f1cd4 100644
--- a/lib/efi_loader/efi_file.c
+++ b/lib/efi_loader/efi_file.c
@@ -637,9 +637,72 @@ static efi_status_t EFIAPI efi_file_setinfo(struct
efi_file_handle *file,
efi_uintn_t buffer_size,
void *buffer)
{
- EFI_ENTRY("%p, %p, %zu, %p", file, info_type, buffer_size, buffer);
+ struct file_handle *fh = to_fh(file);
+ efi_status_t ret = EFI_UNSUPPORTED;
+
+ EFI_ENTRY("%p, %pUl, %zu, %p", file, info_type, buffer_size, buffer);
- return EFI_EXIT(EFI_UNSUPPORTED);
+ if (!guidcmp(info_type, &efi_file_info_guid)) {
+ struct efi_file_info *info = (struct efi_file_info *)buffer;
+ char *filename = basename(fh);
+ char *new_file_name, *pos;
+ loff_t file_size;
+
+ if (buffer_size < sizeof(struct efi_file_info)) {
+ ret = EFI_BAD_BUFFER_SIZE;
+ goto out;
+ }
+ /* We cannot change the directory attribute */
+ if (!fh->isdir != !(info->attribute & EFI_FILE_DIRECTORY)) {
+ ret = EFI_ACCESS_DENIED;
+ goto out;
+ }
+ /* Check for renaming */
+ new_file_name = malloc(utf16_utf8_strlen(info->file_name));
+ if (!new_file_name) {
+ ret = EFI_OUT_OF_RESOURCES;
+ goto out;
+ }
+ pos = new_file_name;
+ utf16_utf8_strcpy(&pos, info->file_name);
+ if (strcmp(new_file_name, filename)) {
+ /* TODO: we do not support renaming */
+ EFI_PRINT("Renaming not supported\n");
+ free(new_file_name);
+ ret = EFI_ACCESS_DENIED;
+ goto out;
+ }
+ free(new_file_name);
+ /* Check for truncation */
+ if (set_blk_dev(fh)) {
+ ret = EFI_DEVICE_ERROR;
+ goto out;
+ }
+ if (fs_size(fh->path, &file_size)) {
+ ret = EFI_DEVICE_ERROR;
+ goto out;
+ }
+ if (file_size != info->file_size) {
+ /* TODO: we do not support truncation */
+ EFI_PRINT("Truncation not supported\n");
+ ret = EFI_ACCESS_DENIED;
+ goto out;
+ }
+ /*
+* We do not care for the other attributes
+* TODO: Support read only
+*/
+ ret = EFI_SUCCESS;
+ } else if (!guidcmp(info_type, &efi_file_system_info_guid)) {
+ if (buffer_size < sizeof(struct efi_file_system_info)) {
+ ret = EFI_BAD_BUFFER_SIZE;
+ goto out;
+ }
+ } else {
+ ret = EFI_UNSUPPORTED;
+ }
+out:
+ return EFI_EXIT(ret);
}
static efi_status_t EFIAPI efi_file_flush(struct efi_file_handle *file)
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] crypto: fsl: jr: Make job-rings assignment non-Secure dependent
On 06/04/2019 16:21, Bryan O'Donoghue wrote: 1. I notice somebody has already added a save_gd()/restore_gd() pair I'm referring to save_gd()/restore_gd() here : https://source.codeaurora.org/external/imx/uboot-imx/tree/arch/arm/mach-imx/hab.c?h=imx_v2018.03_4.14.78_1.0.0_ga but... it's still the right idea for this problem. Save context Switch to bootrom mode Restore context Job done ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] crypto: fsl: jr: Make job-rings assignment non-Secure dependent
On 05/04/2019 17:16, Breno Matheus Lima wrote:
+ if ((IS_ENABLED(CONFIG_OPTEE) ||
+!IS_ENABLED(CONFIG_ARMV7_BOOT_SEC_DEFAULT)) &&
+!IS_ENABLED(CONFIG_CMD_DEKBLOB)) {
So.
How does this patch work if you want to do HABv4 encrypted
authentication of an OP-TEE image prior to booting it ?
i.e.
You'll switch the job-ring ownership over to non-trusted world, call HAB
and the BootROM will fail to authenticate.
How about we improve the hab driver in u-boot ?
1. I notice somebody has already added a save_gd()/restore_gd() pair
2. How about a save_jr()/restore_jr() pair and
3. a bootrom_jr_setup() ?
In pseudocode then
do_hab_auth()
{
save_jr(); // save current job-ring context
bootrom_jr_setup(); // set job-ring to bootrom mode
hab_rvt_authenticate();
restore_jr(); // restore previous job-ring context
}
That gets us out of the nasty business of
1. Constraining the use case of CONFIG_OPTEE=y &&
authenticate(encrypted-dek-blob);
2. Pushing changes into upstream OP-TEE for job-ring assignment
IMV - we should save and restore the job ring context so that all of
this stuff will "just work"
That should work for
BootROM -> u-boot -> HABv4 auth(encryptedblob) -> Linux
and
BootROM -> u-boot -> run optee -> HABv4 auth(encrypted blob) -> Linux
Basically you've described and additional dependency the BootROM has, so
lets just "switch context" prior to calling into the BootROM and restore
to a default non-secure job-ring assignment after.
---
bod
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/1] efi_loader: correct file creation
The EFI shell expects that after opening a file with EFI_FILE_MODE_CREATE
GetInfo() succeeds. Up to now we do not actually create the file when
method Open() of the EFI_FILE_PROTOCOL is called.
If method Open() of the EFI_FILE_PROTOCOL is called with
EFI_FILE_MODE_CREATE and the file does not yet exist, call fs_write() with
a buffer size of zero to actually create the file.
Signed-off-by: Heinrich Schuchardt
---
lib/efi_loader/efi_file.c | 35 +++
1 file changed, 27 insertions(+), 8 deletions(-)
diff --git a/lib/efi_loader/efi_file.c b/lib/efi_loader/efi_file.c
index 39e37749fe2..80adebbac34 100644
--- a/lib/efi_loader/efi_file.c
+++ b/lib/efi_loader/efi_file.c
@@ -134,6 +134,25 @@ static int sanitize_path(char *path)
return 0;
}
+/**
+ * efi_create_file() - create file or directory
+ *
+ * @fh:file handle
+ * @attributes:attributes for newly created file
+ * Returns:0 for success
+ */
+static int efi_create_file(struct file_handle *fh, u64 attributes)
+{
+ loff_t actwrite;
+ void *buffer = &actwrite;
+
+ if (attributes & EFI_FILE_DIRECTORY)
+ return fs_mkdir(fh->path);
+ else
+ return fs_write(fh->path, map_to_sysmem(buffer), 0, 0,
+ &actwrite);
+}
+
/**
* file_open() - open a file handle
*
@@ -176,6 +195,7 @@ static struct efi_file_handle *file_open(struct file_system
*fs,
if (parent) {
char *p = fh->path;
+ int exists;
if (plen > 0) {
strcpy(p, parent->path);
@@ -192,18 +212,17 @@ static struct efi_file_handle *file_open(struct
file_system *fs,
if (set_blk_dev(fh))
goto error;
- if ((mode & EFI_FILE_MODE_CREATE) &&
- (attributes & EFI_FILE_DIRECTORY)) {
- if (fs_mkdir(fh->path))
- goto error;
- } else if (!((mode & EFI_FILE_MODE_CREATE) ||
-fs_exists(fh->path)))
- goto error;
-
+ exists = fs_exists(fh->path);
/* fs_exists() calls fs_close(), so open file system again */
if (set_blk_dev(fh))
goto error;
+ if (!exists) {
+ if (!(mode & EFI_FILE_MODE_CREATE) ||
+ efi_create_file(fh, attributes))
+ goto error;
+ }
+
/* figure out if file is a directory: */
fh->isdir = is_dir(fh);
} else {
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/1] efi_loader: debug output file handle in efi_file_open()
For debugging it is helpful to know the address of the file handle created
by the Open() method of the EFI file protocol. So let's write it with
EFI_PRINT().
Signed-off-by: Heinrich Schuchardt
---
lib/efi_loader/efi_file.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/lib/efi_loader/efi_file.c b/lib/efi_loader/efi_file.c
index 0483403be0d..39e37749fe2 100644
--- a/lib/efi_loader/efi_file.c
+++ b/lib/efi_loader/efi_file.c
@@ -257,10 +257,12 @@ static efi_status_t EFIAPI efi_file_open(struct
efi_file_handle *file,
/* Open file */
*new_handle = file_open(fh->fs, fh, file_name, open_mode, attributes);
- if (*new_handle)
+ if (*new_handle) {
+ EFI_PRINT("file handle %p\n", *new_handle);
ret = EFI_SUCCESS;
- else
+ } else {
ret = EFI_NOT_FOUND;
+ }
out:
return EFI_EXIT(ret);
}
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 28/40] x86: Add a sysreset driver for the Intel PCH
Hi Simon, On Sat, Apr 6, 2019 at 10:02 AM Simon Glass wrote: > > Hi Bin, > > On Wed, 3 Apr 2019 at 02:42, Bin Meng wrote: > > > > Hi Simon, > > > > On Wed, Apr 3, 2019 at 10:22 AM Simon Glass wrote: > > > > > > Hi Bin, > > > > > > On Fri, 22 Feb 2019 at 00:20, Bin Meng wrote: > > > > > > > > Hi Simon, > > > > > > > > On Wed, Jan 30, 2019 at 12:00 PM Simon Glass wrote: > > > > > > > > > > Intel SoCs support a fairly stardard reset mechanism which can support > > > > > powering off the device. Add support for this and enable it by > > > > > default on > > > > > broadwell, which already has the necessary pm.h header file. > > > > > > > > > > This driver augments the standard x86 sysreset driver. > > > > > > > > > > > > > I think we need update the existing sysreset_x86 driver to support > > > > SYSRESET_POWER_OFF, instead of creating a new driver to do such. > > > > > > > > We can add a new PCH ioctl code to get the pmbase, and do the ACPI > > > > power off in the sysreset_x86 driver. > > > > > > So are you saying that the registers are the same for all x86 chips? > > > From what I can tell, the offsets vary. > > > > Yes, the offsets might be different, so instead of getting only the > > pmbase, we need do something like getting ACPI PM register block > > information from the PCH driver. That's how acpi_create_fadt() passes > > ACPI register block information to the OS. > > That doesn't make a lot of sense to me. If the register layout is > different, why not just use different drivers? > Yes, the register layout might be different but the programming model is the same and well defined in the ACPI spec. > I suppose we could put the common code (with parameters) in a separate > file and call it from the driver. The parameters would presumably be: > > PMBASE > GPE0_EN(0) > PM1_STS > PM1_CNT That's why I suggest to ask PCH driver to provide these offsets in a struct via an ioctl call to the sysreset driver. Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v1 2/5] arm: dts: imx8dx: add lpuart1, lpuart2, lpuart3
From: Marcel Ziswiler
Add support for lpuart1, lpuart2 and lpuart3.
Signed-off-by: Marcel Ziswiler
---
arch/arm/dts/fsl-imx8dx.dtsi | 54
1 file changed, 54 insertions(+)
diff --git a/arch/arm/dts/fsl-imx8dx.dtsi b/arch/arm/dts/fsl-imx8dx.dtsi
index 3b1a2a20e3..715abb413d 100644
--- a/arch/arm/dts/fsl-imx8dx.dtsi
+++ b/arch/arm/dts/fsl-imx8dx.dtsi
@@ -236,6 +236,21 @@
power-domains = <&pd_dma>;
wakeup-irq = <225>;
};
+ pd_dma_lpuart1: PD_DMA_UART1 {
+ reg = ;
+ #power-domain-cells = <0>;
+ power-domains = <&pd_dma>;
+ };
+ pd_dma_lpuart2: PD_DMA_UART2 {
+ reg = ;
+ #power-domain-cells = <0>;
+ power-domains = <&pd_dma>;
+ };
+ pd_dma_lpuart3: PD_DMA_UART3 {
+ reg = ;
+ #power-domain-cells = <0>;
+ power-domains = <&pd_dma>;
+ };
};
};
@@ -402,6 +417,45 @@
status = "disabled";
};
+ lpuart1: serial@5a07 {
+ compatible = "fsl,imx8qm-lpuart";
+ reg = <0x0 0x5a07 0x0 0x1000>;
+ interrupts = ;
+ clocks = <&clk IMX8QXP_UART1_CLK>,
+<&clk IMX8QXP_UART1_IPG_CLK>;
+ clock-names = "per", "ipg";
+ assigned-clocks = <&clk IMX8QXP_UART1_CLK>;
+ assigned-clock-rates = <8000>;
+ power-domains = <&pd_dma_lpuart1>;
+ status = "disabled";
+ };
+
+ lpuart2: serial@5a08 {
+ compatible = "fsl,imx8qm-lpuart";
+ reg = <0x0 0x5a08 0x0 0x1000>;
+ interrupts = ;
+ clocks = <&clk IMX8QXP_UART2_CLK>,
+<&clk IMX8QXP_UART2_IPG_CLK>;
+ clock-names = "per", "ipg";
+ assigned-clocks = <&clk IMX8QXP_UART2_CLK>;
+ assigned-clock-rates = <8000>;
+ power-domains = <&pd_dma_lpuart2>;
+ status = "disabled";
+ };
+
+ lpuart3: serial@5a09 {
+ compatible = "fsl,imx8qm-lpuart";
+ reg = <0x0 0x5a09 0x0 0x1000>;
+ interrupts = ;
+ clocks = <&clk IMX8QXP_UART3_CLK>,
+<&clk IMX8QXP_UART3_IPG_CLK>;
+ clock-names = "per", "ipg";
+ assigned-clocks = <&clk IMX8QXP_UART3_CLK>;
+ assigned-clock-rates = <8000>;
+ power-domains = <&pd_dma_lpuart3>;
+ status = "disabled";
+ };
+
usdhc1: usdhc@5b01 {
compatible = "fsl,imx8qm-usdhc", "fsl,imx6sl-usdhc";
interrupt-parent = <&gic>;
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v1 5/5] board: toradex: add colibri imx8qxp 2gb wb it v1.0b module support
From: Marcel Ziswiler
This commit adds initial support for the Toradex Colibri iMX8QXP 2GB WB
IT V1.0B module. Unlike the V1.0A early access samples exclusively
booting from SD card, they are now strapped to boot from eFuses which
are factory fused to properly boot from their on-module eMMC. U-Boot
supports either booting from the on-module eMMC or may be used for
recovery purpose using the universal update utility (uuu) aka mfgtools
3.0.
Functionality wise the following is known to be working:
- eMMC and MMC/SD card
- Ethernet
- GPIOs
- I2C
Unfortunately, there is no USB functionality for the i.MX 8QXP as of
yet.
Signed-off-by: Marcel Ziswiler
---
arch/arm/dts/Makefile | 4 +-
arch/arm/dts/fsl-imx8qxp-colibri-u-boot.dtsi | 112 ++
arch/arm/dts/fsl-imx8qxp-colibri.dts | 328 ++
arch/arm/mach-imx/imx8/Kconfig| 6 +
board/toradex/colibri-imx8qxp/Kconfig | 30 ++
board/toradex/colibri-imx8qxp/MAINTAINERS | 9 +
board/toradex/colibri-imx8qxp/Makefile| 7 +
board/toradex/colibri-imx8qxp/README | 67
.../toradex/colibri-imx8qxp/colibri-imx8qxp.c | 211 +++
board/toradex/colibri-imx8qxp/imximage.cfg| 24 ++
configs/colibri-imx8qxp_defconfig | 53 +++
include/configs/colibri-imx8qxp.h | 240 +
12 files changed, 1090 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/dts/fsl-imx8qxp-colibri-u-boot.dtsi
create mode 100644 arch/arm/dts/fsl-imx8qxp-colibri.dts
create mode 100644 board/toradex/colibri-imx8qxp/Kconfig
create mode 100644 board/toradex/colibri-imx8qxp/MAINTAINERS
create mode 100644 board/toradex/colibri-imx8qxp/Makefile
create mode 100644 board/toradex/colibri-imx8qxp/README
create mode 100644 board/toradex/colibri-imx8qxp/colibri-imx8qxp.c
create mode 100644 board/toradex/colibri-imx8qxp/imximage.cfg
create mode 100644 configs/colibri-imx8qxp_defconfig
create mode 100644 include/configs/colibri-imx8qxp.h
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index d63b6874b5..fa0f28a84a 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -562,7 +562,9 @@ dtb-$(CONFIG_MX7) += imx7d-sdb.dtb \
dtb-$(CONFIG_ARCH_MX7ULP) += imx7ulp-evk.dtb
-dtb-$(CONFIG_ARCH_IMX8) += fsl-imx8qxp-mek.dtb
+dtb-$(CONFIG_ARCH_IMX8) += \
+ fsl-imx8qxp-colibri.dtb \
+ fsl-imx8qxp-mek.dtb
dtb-$(CONFIG_ARCH_IMX8M) += fsl-imx8mq-evk.dtb
diff --git a/arch/arm/dts/fsl-imx8qxp-colibri-u-boot.dtsi
b/arch/arm/dts/fsl-imx8qxp-colibri-u-boot.dtsi
new file mode 100644
index 00..f8686befdf
--- /dev/null
+++ b/arch/arm/dts/fsl-imx8qxp-colibri-u-boot.dtsi
@@ -0,0 +1,112 @@
+// SPDX-License-Identifier: GPL-2.0+ OR X11
+/*
+ * Copyright 2019 Toradex AG
+ */
+
+&mu {
+ u-boot,dm-spl;
+};
+
+&clk {
+ u-boot,dm-spl;
+};
+
+&iomuxc {
+ u-boot,dm-spl;
+};
+
+&pd_lsio {
+ u-boot,dm-spl;
+};
+
+&pd_lsio_gpio0 {
+ u-boot,dm-spl;
+};
+
+&pd_lsio_gpio1 {
+ u-boot,dm-spl;
+};
+
+&pd_lsio_gpio2 {
+ u-boot,dm-spl;
+};
+
+&pd_lsio_gpio3 {
+ u-boot,dm-spl;
+};
+
+&pd_lsio_gpio4 {
+ u-boot,dm-spl;
+};
+
+&pd_lsio_gpio5 {
+ u-boot,dm-spl;
+};
+
+&pd_lsio_gpio6 {
+ u-boot,dm-spl;
+};
+
+&pd_lsio_gpio7 {
+ u-boot,dm-spl;
+};
+
+&pd_conn {
+ u-boot,dm-spl;
+};
+
+&pd_conn_sdch0 {
+ u-boot,dm-spl;
+};
+
+&pd_conn_sdch1 {
+ u-boot,dm-spl;
+};
+
+&pd_conn_sdch2 {
+ u-boot,dm-spl;
+};
+
+&gpio0 {
+ u-boot,dm-spl;
+};
+
+&gpio1 {
+ u-boot,dm-spl;
+};
+
+&gpio2 {
+ u-boot,dm-spl;
+};
+
+&gpio3 {
+ u-boot,dm-spl;
+};
+
+&gpio4 {
+ u-boot,dm-spl;
+};
+
+&gpio5 {
+ u-boot,dm-spl;
+};
+
+&gpio6 {
+ u-boot,dm-spl;
+};
+
+&gpio7 {
+ u-boot,dm-spl;
+};
+
+&lpuart3 {
+ u-boot,dm-spl;
+};
+
+&usdhc1 {
+ u-boot,dm-spl;
+};
+
+&usdhc2 {
+ u-boot,dm-spl;
+};
diff --git a/arch/arm/dts/fsl-imx8qxp-colibri.dts
b/arch/arm/dts/fsl-imx8qxp-colibri.dts
new file mode 100644
index 00..0c20edf2cf
--- /dev/null
+++ b/arch/arm/dts/fsl-imx8qxp-colibri.dts
@@ -0,0 +1,328 @@
+// SPDX-License-Identifier: GPL-2.0+ OR X11
+/*
+ * Copyright 2019 Toradex AG
+ */
+
+/dts-v1/;
+
+#include "fsl-imx8qxp.dtsi"
+#include "fsl-imx8qxp-colibri-u-boot.dtsi"
+
+/ {
+ model = "Toradex Colibri iMX8QXP";
+ compatible = "toradex,colibri-imx8qxp", "fsl,imx8qxp";
+
+ chosen {
+ bootargs = "console=ttyLP3,115200
earlycon=lpuart32,0x5a09,115200";
+ stdout-path = &lpuart3;
+ };
+
+ reg_usbh_vbus: regulator-usbh-vbus {
+ compatible = "regulator-fixed";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usbh1_reg>;
+ regulator-name = "usbh_vbus";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ gpio = <&gpio4 3 GPIO_ACTIVE_LOW>;
+
[U-Boot] [PATCH v1 4/5] board: toradex: tdx-cfg-block: add new skus
From: Marcel Ziswiler
Add all the latest new SKUs:
- Apalis iMX8 QuadXPlus 2GB Wi-Fi / BT IT
- Apalis iMX8 QuadMax 4GB IT
- Apalis iMX8 QuadPlus 2GB Wi-Fi / BT
- Apalis iMX8 QuadPlus 2GB",
- Colibri iMX8 QuadXPlus 2GB IT
- Colibri iMX8 DualX 1GB Wi-Fi / Bluetooth
- Colibri iMX8 DualX 1GB
Signed-off-by: Marcel Ziswiler
---
board/toradex/common/tdx-cfg-block.c | 7 +++
board/toradex/common/tdx-cfg-block.h | 7 +++
2 files changed, 14 insertions(+)
diff --git a/board/toradex/common/tdx-cfg-block.c
b/board/toradex/common/tdx-cfg-block.c
index 7e529afc7f..f69c4433b2 100644
--- a/board/toradex/common/tdx-cfg-block.c
+++ b/board/toradex/common/tdx-cfg-block.c
@@ -103,6 +103,13 @@ const char * const toradex_modules[] = {
[43] = "Colibri T20 512MB IT SETEK",
[44] = "Colibri iMX6ULL 512MB IT",
[45] = "Colibri iMX6ULL 512MB Wi-Fi / Bluetooth",
+ [46] = "Apalis iMX8 QuadXPlus 2GB Wi-Fi / BT IT",
+ [47] = "Apalis iMX8 QuadMax 4GB IT",
+ [48] = "Apalis iMX8 QuadPlus 2GB Wi-Fi / BT",
+ [49] = "Apalis iMX8 QuadPlus 2GB",
+ [50] = "Colibri iMX8 QuadXPlus 2GB IT",
+ [51] = "Colibri iMX8 DualX 1GB Wi-Fi / Bluetooth",
+ [52] = "Colibri iMX8 DualX 1GB",
};
#ifdef CONFIG_TDX_CFG_BLOCK_IS_IN_MMC
diff --git a/board/toradex/common/tdx-cfg-block.h
b/board/toradex/common/tdx-cfg-block.h
index b20b522e1d..bfdc8b7f70 100644
--- a/board/toradex/common/tdx-cfg-block.h
+++ b/board/toradex/common/tdx-cfg-block.h
@@ -66,6 +66,13 @@ enum {
COLIBRI_T20_512MB_IT_SETEK,
COLIBRI_IMX6ULL_IT,
COLIBRI_IMX6ULL_WIFI_BT, /* 45 */
+ APALIS_IMX8QXP_WIFI_BT_IT,
+ APALIS_IMX8QM_IT,
+ APALIS_IMX8QP_WIFI_BT,
+ APALIS_IMX8QP,
+ COLIBRI_IMX8QXP_IT, /* 50 */
+ COLIBRI_IMX8DX_WIFI_BT,
+ COLIBRI_IMX8DX,
};
extern const char * const toradex_modules[];
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v1 1/5] misc: imx8: remove duplicates from scfw api
From: Marcel Ziswiler Remove duplicate function declarations from the SCFW API header file. Signed-off-by: Marcel Ziswiler --- arch/arm/include/asm/arch-imx8/sci/sci.h | 4 1 file changed, 4 deletions(-) diff --git a/arch/arm/include/asm/arch-imx8/sci/sci.h b/arch/arm/include/asm/arch-imx8/sci/sci.h index d1621669e2..97377697f0 100644 --- a/arch/arm/include/asm/arch-imx8/sci/sci.h +++ b/arch/arm/include/asm/arch-imx8/sci/sci.h @@ -62,10 +62,6 @@ int sc_pm_set_clock_rate(sc_ipc_t ipc, sc_rsrc_t resource, sc_pm_clk_t clk, sc_pm_clock_rate_t *rate); int sc_pm_get_clock_rate(sc_ipc_t ipc, sc_rsrc_t resource, sc_pm_clk_t clk, sc_pm_clock_rate_t *rate); -int sc_pm_set_clock_rate(sc_ipc_t ipc, sc_rsrc_t resource, sc_pm_clk_t clk, -sc_pm_clock_rate_t *rate); -int sc_pm_get_clock_rate(sc_ipc_t ipc, sc_rsrc_t resource, sc_pm_clk_t clk, -sc_pm_clock_rate_t *rate); int sc_pm_clock_enable(sc_ipc_t ipc, sc_rsrc_t resource, sc_pm_clk_t clk, sc_bool_t enable, sc_bool_t autog); -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v1 3/5] board: toradex: tdx-cfg-block: clean-up sku handling
From: Marcel Ziswiler
Clean-up handling of several SKUs.
Signed-off-by: Marcel Ziswiler
---
board/toradex/common/tdx-cfg-block.c | 12
board/toradex/common/tdx-cfg-block.h | 22 --
2 files changed, 20 insertions(+), 14 deletions(-)
diff --git a/board/toradex/common/tdx-cfg-block.c
b/board/toradex/common/tdx-cfg-block.c
index 71ff40cfad..7e529afc7f 100644
--- a/board/toradex/common/tdx-cfg-block.c
+++ b/board/toradex/common/tdx-cfg-block.c
@@ -6,7 +6,9 @@
#include
#include "tdx-cfg-block.h"
-#if defined(CONFIG_TARGET_APALIS_IMX6) || defined(CONFIG_TARGET_COLIBRI_IMX6)
+#if defined(CONFIG_TARGET_APALIS_IMX6) || \
+ defined(CONFIG_TARGET_COLIBRI_IMX6) || \
+ defined(CONFIG_TARGET_COLIBRI_IMX8QXP)
#include
#else
#define is_cpu_type(cpu) (0)
@@ -92,10 +94,10 @@ const char * const toradex_modules[] = {
[34] = "Apalis TK1 2GB",
[35] = "Apalis iMX6 Dual 1GB IT",
[36] = "Colibri iMX6ULL 256MB",
- [37] = "Apalis iMX8 QuadMax 4GB Wi-Fi / Bluetooth",
- [38] = "Colibri iMX8X",
+ [37] = "Apalis iMX8 QuadMax 4GB Wi-Fi / BT IT",
+ [38] = "Colibri iMX8 QuadXPlus 2GB Wi-Fi / BT IT",
[39] = "Colibri iMX7 Dual 1GB (eMMC)",
- [40] = "Colibri iMX6ULL 512MB Wi-Fi / Bluetooth IT",
+ [40] = "Colibri iMX6ULL 512MB Wi-Fi / BT IT",
[41] = "Colibri iMX7 Dual 512MB EPDC",
[42] = "Apalis TK1 4GB",
[43] = "Colibri T20 512MB IT SETEK",
@@ -340,6 +342,8 @@ static int get_cfgblock_interactive(void)
tdx_hw_tag.prodid = COLIBRI_IMX7D;
else if (!strcmp("imx7s", soc))
tdx_hw_tag.prodid = COLIBRI_IMX7S;
+ else if (is_cpu_type(MXC_CPU_IMX8QXP))
+ tdx_hw_tag.prodid = COLIBRI_IMX8QXP_WIFI_BT_IT;
else if (!strcmp("tegra20", soc)) {
if (it == 'y' || it == 'Y')
if (gd->ram_size == 0x1000)
diff --git a/board/toradex/common/tdx-cfg-block.h
b/board/toradex/common/tdx-cfg-block.h
index 961bb4394f..b20b522e1d 100644
--- a/board/toradex/common/tdx-cfg-block.h
+++ b/board/toradex/common/tdx-cfg-block.h
@@ -25,42 +25,44 @@ enum {
COLIBRI_PXA270_V1_520MHZ,
COLIBRI_PXA320,
COLIBRI_PXA300,
- COLIBRI_PXA310,
+ COLIBRI_PXA310, /* 5 */
COLIBRI_PXA320_IT,
COLIBRI_PXA300_XT,
COLIBRI_PXA270_312MHZ,
COLIBRI_PXA270_520MHZ,
- COLIBRI_VF50, /* not currently on sale */
- COLIBRI_VF61,
+ COLIBRI_VF50, /* 10 */
+ COLIBRI_VF61, /* not currently on sale */
COLIBRI_VF61_IT,
COLIBRI_VF50_IT,
COLIBRI_IMX6S,
- COLIBRI_IMX6DL,
+ COLIBRI_IMX6DL, /* 15 */
COLIBRI_IMX6S_IT,
COLIBRI_IMX6DL_IT,
+ /* 18 */
+ /* 19 */
COLIBRI_T20_256MB = 20,
COLIBRI_T20_512MB,
COLIBRI_T20_512MB_IT,
COLIBRI_T30,
COLIBRI_T20_256MB_IT,
- APALIS_T30_2GB,
+ APALIS_T30_2GB, /* 25 */
APALIS_T30_1GB,
APALIS_IMX6Q,
APALIS_IMX6Q_IT,
APALIS_IMX6D,
- COLIBRI_T30_IT,
+ COLIBRI_T30_IT, /* 30 */
APALIS_T30_IT,
COLIBRI_IMX7S,
COLIBRI_IMX7D,
APALIS_TK1_2GB,
- APALIS_IMX6D_IT,
+ APALIS_IMX6D_IT, /* 35 */
COLIBRI_IMX6ULL,
- APALIS_IMX8QM, /* 37 */
- COLIBRI_IMX8X,
+ APALIS_IMX8QM_WIFI_BT_IT,
+ COLIBRI_IMX8QXP_WIFI_BT_IT,
COLIBRI_IMX7D_EMMC,
COLIBRI_IMX6ULL_WIFI_BT_IT, /* 40 */
COLIBRI_IMX7D_EPDC,
- APALIS_TK1_4GB,
+ APALIS_TK1_4GB, /* not currently on sale */
COLIBRI_T20_512MB_IT_SETEK,
COLIBRI_IMX6ULL_IT,
COLIBRI_IMX6ULL_WIFI_BT, /* 45 */
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
