Re: inconsistent wget behavior
Hi Fabio, I'm on vacation now (Chinese new year). I hope I'll find some time to revive my imx8 board. I've tried sandbox and qemu. Both of them are not reproducible. I'm wondering if it could be some packet loss that causes the issue. Because sandbox and qemu there won't be any missing packets because of loopback devices. Yours, Paul On Thu, 8 Feb 2024 at 02:00, Fabio Estevam wrote: > Hi Paul, > > On Wed, Jan 10, 2024 at 9:20 AM Fabio Estevam wrote: > > > One colleague from you at Linaro was able to reproduce the bug: > > > > > https://lore.kernel.org/u-boot/cadq0-x_cj1ecn67u3sefcz-jm4obsymzka+jazrca3ekq84...@mail.gmail.com/ > > > > It is not specific to i.MX. > > Have you had a chance to look into this wget problem? >
Re: inconsistent wget behavior
Hi Fabio, I tried to investigate this by U-boot sandbox. But it seems to me that I cannot reproduce this issue. I put a file on localhost apache server and tried to download it from localhost. I might need a more persistent way to reproduce this bug. Yours, Paul On Sat, 6 Jan 2024 at 00:17, Fabio Estevam wrote: > Hi Paul, > > On Thu, Nov 16, 2023 at 6:41 AM Paul Liu wrote: > > > > Hi Fabio, > > > > Yes. I'll look into this problem. > > Did you have a chance to investigate this problem? > > Thanks >
Re: inconsistent wget behavior
Hi Fabio, Yes. I'll look into this problem. Yours, Paul On Thu, 16 Nov 2023 at 08:34, Fabio Estevam wrote: > Hi Paul, > > On Wed, Nov 8, 2023 at 10:24 PM Fabio Estevam wrote: > > > I was not able to see a failure when using "tftp" to transfer the same > > 420MB file. > > > > The number of bytes transferred and md5sum always match, so this is a > wget bug. > > There was another user who confirmed the same issue: > > > https://lore.kernel.org/u-boot/cadq0-x_cj1ecn67u3sefcz-jm4obsymzka+jazrca3ekq84...@mail.gmail.com/ > > Could you please take a look at this bug? > > wget is not reliable at the moment. > > Thanks >
Re: [PATCH 1/1] lib/vsprintf.c: fix integer overflow in vsprintf
Hi Tom, Yes, I think Rasmus is correct. I didn't have any real cases that can trigger the bug. So let's don't include this patch. I'll see if I can revert this in AOSP's branch. Yours, Paul Y On Tue, 15 Aug 2023 at 22:42, Tom Rini wrote: > On Thu, Mar 09, 2023 at 10:12:21AM +0800, Ying-Chun Liu (PaulLiu) wrote: > > > From: Tom Cherry > > > > vsnprintf_internal() adds 'size' to 'buf' and vsprintf() sets 'size' > > to 'INT_MAX' which can overflow. This causes sprintf() to fail when > > initializing the environment on 8GB. > > > > Instead of using 'INT_MAX', we use SIZE_MAX - buf, which is the > > largest possible string that could fit without overflowing 'size'. > > > > Signed-off-by: Tom Cherry > > [ Paul: pick from the Android tree. Rebase to the upstream ] > > Signed-off-by: Ying-Chun Liu (PaulLiu) > > Cc: Tom Rini > > Link: > https://android.googlesource.com/platform/external/u-boot/+/43aae5d4415e0f9d744fb798acd52429d09957ce > > So, this link here leads back to > https://issuetracker.google.com/issues/200479053 which isn't public. > > Rasmus followed up and asked pointed questions, that weren't followed up > on. > > -- > Tom >
Re: [PATCH 5/6] net: add fastboot TCP documentation and IP6-only mode
Reviewed-by: Ying-Chun Liu (PaulLiu)
On Tue, 9 May 2023 at 01:16, Dmitrii Merkurev wrote:
> Command to start IP6 only TCP fastboot:
> fastboot tcp -ipv6
>
> Signed-off-by: Dmitrii Merkurev
> Cc: Ying-Chun Liu (PaulLiu)
> Cc: Simon Glass
> Сс: Joe Hershberger
> Сс: Ramon Fried
> ---
> cmd/fastboot.c | 29 +
> doc/android/fastboot.rst | 8 +++-
> 2 files changed, 32 insertions(+), 5 deletions(-)
>
> diff --git a/cmd/fastboot.c b/cmd/fastboot.c
> index 3d5ff951eb..36f744ae01 100644
> --- a/cmd/fastboot.c
> +++ b/cmd/fastboot.c
> @@ -12,6 +12,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -121,10 +122,23 @@ static int do_fastboot(struct cmd_tbl *cmdtp, int
> flag, int argc,
> {
> uintptr_t buf_addr = (uintptr_t)NULL;
> size_t buf_size = 0;
> + bool is_ipv6_only = false;
> + bool is_usb = false;
> + bool is_udp = false;
> + bool is_tcp = false;
>
> if (argc < 2)
> return CMD_RET_USAGE;
>
> + if (IS_ENABLED(CONFIG_IPV6)) {
> + use_ip6 = false;
> + /* IPv6 parameter has to be always *last* */
> + if (!strcmp(argv[argc - 1], USE_IP6_CMD_PARAM)) {
> + is_ipv6_only = true;
> + --argc;
> + }
> + }
> +
> while (argc > 1 && **(argv + 1) == '-') {
> char *arg = *++argv;
>
> @@ -159,11 +173,18 @@ NXTARG:
>
> fastboot_init((void *)buf_addr, buf_size);
>
> - if (!strcmp(argv[1], "udp"))
> + is_usb = strcmp(argv[1], "usb") == 0;
> + is_udp = strcmp(argv[1], "udp") == 0;
> + is_tcp = strcmp(argv[1], "tcp") == 0;
> +
> + if (is_ipv6_only && is_tcp)
> + use_ip6 = true;
> +
> + if (is_udp)
> return do_fastboot_udp(argc, argv, buf_addr, buf_size);
> - if (!strcmp(argv[1], "tcp"))
> + if (is_tcp)
> return do_fastboot_tcp(argc, argv, buf_addr, buf_size);
> - if (!strcmp(argv[1], "usb")) {
> + if (is_usb) {
> argv++;
> argc--;
> }
> @@ -174,7 +195,7 @@ NXTARG:
> U_BOOT_CMD(
> fastboot, CONFIG_SYS_MAXARGS, 1, do_fastboot,
> "run as a fastboot usb or udp device",
> - "[-l addr] [-s size] usb | udp\n"
> + "[-l addr] [-s size] usb | udp [-ipv6] | tcp
> [-ipv6]\n"
> "\taddr - address of buffer used during data transfers ("
> __stringify(CONFIG_FASTBOOT_BUF_ADDR) ")\n"
> "\tsize - size of buffer used during data transfers ("
> diff --git a/doc/android/fastboot.rst b/doc/android/fastboot.rst
> index 1ad8a897c8..aa6e9e5a9e 100644
> --- a/doc/android/fastboot.rst
> +++ b/doc/android/fastboot.rst
> @@ -181,13 +181,19 @@ Enter into fastboot by executing the fastboot
> command in U-Boot for either USB::
>
> => fastboot usb 0
>
> -or UDP::
> +UDP::
>
> => fastboot udp
> link up on port 0, speed 100, full duplex
> Using ethernet@4a10 device
> Listening for fastboot command on 192.168.0.102
>
> +or TCP::
> +
> + => fastboot tcp
> + Using ethernet@4a10 device
> + Listening for fastboot command on 192.168.0.102
> +
> On the client side you can fetch the bootloader version for instance::
>
> $ fastboot getvar version-bootloader
> --
> 2.40.1.521.gf1e218fcd8-goog
>
>
Re: [PATCH v2 4/6] net: add fastboot TCP6 support
Reviewed-by: Ying-Chun Liu (PaulLiu)
On Thu, 11 May 2023 at 01:00, Dmitrii Merkurev wrote:
> fastboot tcp command remains the same, but started
> listening IP6 in case it's enabled.
>
> Signed-off-by: Dmitrii Merkurev
> Cc: Ying-Chun Liu (PaulLiu)
> Cc: Simon Glass
> Сс: Joe Hershberger
> Сс: Ramon Fried
> ---
> include/net/fastboot_tcp.h | 2 +-
> net/fastboot_tcp.c | 72 --
> 2 files changed, 62 insertions(+), 12 deletions(-)
>
> diff --git a/include/net/fastboot_tcp.h b/include/net/fastboot_tcp.h
> index 6cf29d52e9..98986fa10a 100644
> --- a/include/net/fastboot_tcp.h
> +++ b/include/net/fastboot_tcp.h
> @@ -7,7 +7,7 @@
> #define __NET_FASTBOOT_TCP_H__
>
> /**
> - * Wait for incoming tcp fastboot comands.
> + * Wait for incoming TCP fastboot comands.
> */
> void fastboot_tcp_start_server(void);
>
> diff --git a/net/fastboot_tcp.c b/net/fastboot_tcp.c
> index 2eb52ea256..d93b52ede5 100644
> --- a/net/fastboot_tcp.c
> +++ b/net/fastboot_tcp.c
> @@ -6,8 +6,10 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> +#include
>
> static char command[FASTBOOT_COMMAND_LEN] = {0};
> static char response[FASTBOOT_RESPONSE_LEN] = {0};
> @@ -20,18 +22,30 @@ static u16 curr_dport;
> static u32 curr_tcp_seq_num;
> static u32 curr_tcp_ack_num;
> static unsigned int curr_request_len;
> +static bool is_ipv6;
> +static size_t ip_header_size;
> static enum fastboot_tcp_state {
> FASTBOOT_CLOSED,
> FASTBOOT_CONNECTED,
> FASTBOOT_DISCONNECTING
> } state = FASTBOOT_CLOSED;
>
> +static int command_handled_id;
> +static bool command_handled_success;
> +
> static void fastboot_tcp_answer(u8 action, unsigned int len)
> {
> const u32 response_seq_num = curr_tcp_ack_num;
> const u32 response_ack_num = curr_tcp_seq_num +
> (curr_request_len > 0 ? curr_request_len : 1);
>
> +#if defined(CONFIG_IPV6)
> + if (is_ipv6) {
> + net_send_tcp_packet6(len, htons(curr_sport),
> htons(curr_dport),
> +action, response_seq_num,
> response_ack_num);
> + return;
> + }
> +#endif
> net_send_tcp_packet(len, htons(curr_sport), htons(curr_dport),
> action, response_seq_num, response_ack_num);
> }
> @@ -47,7 +61,7 @@ static void fastboot_tcp_send_packet(u8 action, const
> uchar *data, unsigned int
> uchar *pkt = net_get_async_tx_pkt_buf();
>
> memset(pkt, '\0', PKTSIZE);
> - pkt += net_eth_hdr_size() + IP_TCP_HDR_SIZE + TCP_TSOPT_SIZE + 2;
> + pkt += net_eth_hdr_size() + ip_header_size + TCP_HDR_SIZE +
> TCP_TSOPT_SIZE + 2;
> memcpy(pkt, data, len);
> fastboot_tcp_answer(action, len);
> memset(pkt, '\0', PKTSIZE);
> @@ -59,7 +73,7 @@ static void fastboot_tcp_send_message(const char
> *message, unsigned int len)
> uchar *pkt = net_get_async_tx_pkt_buf();
>
> memset(pkt, '\0', PKTSIZE);
> - pkt += net_eth_hdr_size() + IP_TCP_HDR_SIZE + TCP_TSOPT_SIZE + 2;
> + pkt += net_eth_hdr_size() + ip_header_size + TCP_HDR_SIZE +
> TCP_TSOPT_SIZE + 2;
> // Put first 8 bytes as a big endian message length
> memcpy(pkt, _be, 8);
> pkt += 8;
> @@ -68,10 +82,9 @@ static void fastboot_tcp_send_message(const char
> *message, unsigned int len)
> memset(pkt, '\0', PKTSIZE);
> }
>
> -static void fastboot_tcp_handler_ipv4(uchar *pkt, u16 dport,
> - struct in_addr sip, u16 sport,
> - u32 tcp_seq_num, u32 tcp_ack_num,
> - u8 action, unsigned int len)
> +static void fastboot_tcp_handler(uchar *pkt, u16 dport, u16 sport,
> +u32 tcp_seq_num, u32 tcp_ack_num,
> +u8 action, unsigned int len)
> {
> int fastboot_command_id;
> u64 command_size;
> @@ -88,7 +101,6 @@ static void fastboot_tcp_handler_ipv4(uchar *pkt, u16
> dport,
> case FASTBOOT_CLOSED:
> if (tcp_push) {
> if (len != handshake_length ||
> - strlen(pkt) != handshake_length ||
> memcmp(pkt, handshake, handshake_length) != 0)
> {
> fastboot_tcp_reset();
> break;
> @@ -111,18 +123,25 @@ static void fastboot_tcp_handler_ipv4(uchar *pkt,
> u16 dport,
> pkt += 8;
>
> // Only single packet messages are supported ATM
> - if (strlen(pkt) != command_size) {
> + if (len != command_size) {
> fastboot_tcp_reset();
> break;
> }
> strlcpy(command, pkt, len + 1);
> fastboot_command_id =
>
Re: [PATCH 1/6] net: split IP_TCP header into separate IP/IP6 and TCP headers
Hi Dmitrii,
It seems to me that this series of patches breaks the unittest of TCP stack
in sandbox.
I'll see if I have some time to fix the unittest too.
The unittest can be built by the following commands.
1. "make sandbox64_defconfig"
2. turn on the options that need to be tested. For example, CMD_WGET
3. "make"
4. "sudo ./u-boot -D"
5. "ut lib net_test_wget" in the U-boot prompt.
Yours,
Paul
On Tue, 9 May 2023 at 01:15, Dmitrii Merkurev wrote:
> This allows us to reuse TCP logic between IP and IP6 stack.
>
> Signed-off-by: Dmitrii Merkurev
> Cc: Ying-Chun Liu (PaulLiu)
> Cc: Simon Glass
> Сс: Joe Hershberger
> Сс: Ramon Fried
> ---
> include/net/tcp.h | 50 ++---
> net/tcp.c | 70 +++
> test/cmd/wget.c | 16 +--
> 3 files changed, 64 insertions(+), 72 deletions(-)
>
> diff --git a/include/net/tcp.h b/include/net/tcp.h
> index c29d4ce24a..5ab1127d8b 100644
> --- a/include/net/tcp.h
> +++ b/include/net/tcp.h
> @@ -5,20 +5,16 @@
> * Copyright 2017 Duncan Hare, All rights reserved.
> */
>
> +#ifndef __TCP_H__
> +#define __TCP_H__
> +
> #define TCP_ACTIVITY 127 /* Number of packets received */
> /* before console progress mark */
> +
> +#define GET_TCP_HDR_LEN_IN_BYTES(x) ((x) >> 2)
> +
> /**
> - * struct ip_tcp_hdr - IP and TCP header
> - * @ip_hl_v: header length and version
> - * @ip_tos: type of service
> - * @ip_len: total length
> - * @ip_id: identification
> - * @ip_off: fragment offset field
> - * @ip_ttl: time to live
> - * @ip_p: protocol
> - * @ip_sum: checksum
> - * @ip_src: Source IP address
> - * @ip_dst: Destination IP address
> + * struct tcp_hdr - TCP header
> * @tcp_src: TCP source port
> * @tcp_dst: TCP destination port
> * @tcp_seq: TCP sequence number
> @@ -28,18 +24,8 @@
> * @tcp_win: TCP windows size
> * @tcp_xsum: Checksum
> * @tcp_ugr: Pointer to urgent data
> - */
> -struct ip_tcp_hdr {
> - u8 ip_hl_v;
> - u8 ip_tos;
> - u16 ip_len;
> - u16 ip_id;
> - u16 ip_off;
> - u8 ip_ttl;
> - u8 ip_p;
> - u16 ip_sum;
> - struct in_addr ip_src;
> - struct in_addr ip_dst;
> +*/
> +struct tcp_hdr {
> u16 tcp_src;
> u16 tcp_dst;
> u32 tcp_seq;
> @@ -51,8 +37,8 @@ struct ip_tcp_hdr {
> u16 tcp_ugr;
> } __packed;
>
> -#define IP_TCP_HDR_SIZE(sizeof(struct ip_tcp_hdr))
> -#define TCP_HDR_SIZE (IP_TCP_HDR_SIZE - IP_HDR_SIZE)
> +#define TCP_HDR_SIZE (sizeof(struct tcp_hdr))
> +#define IP_TCP_HDR_SIZE (IP_HDR_SIZE + TCP_HDR_SIZE)
>
> #define TCP_DATA 0x00/* Data Packet - internal use only */
> #define TCP_FIN0x01/* Finish flag
> */
> @@ -178,7 +164,8 @@ struct tcp_t_opt {
>
> /**
> * struct ip_tcp_hdr_o - IP + TCP header + TCP options
> - * @hdr: IP + TCP header
> + * @ip_hdr: IP + TCP header
> + * @tcp_hdr: TCP header
> * @mss: TCP MSS Option
> * @scale: TCP Windows Scale Option
> * @sack_p: TCP Sack-Permitted Option
> @@ -186,7 +173,8 @@ struct tcp_t_opt {
> * @end: end of options
> */
> struct ip_tcp_hdr_o {
> - struct ip_tcp_hdr hdr;
> + struct ip_hdr ip_hdr;
> + struct tcp_hdrtcp_hdr;
> struct tcp_mssmss;
> struct tcp_scale scale;
> struct tcp_sack_p sack_p;
> @@ -198,13 +186,15 @@ struct ip_tcp_hdr_o {
>
> /**
> * struct ip_tcp_hdr_s - IP + TCP header + TCP options
> - * @hdr: IP + TCP header
> + * @ip_hdr: IP + TCP header
> + * @tcp_hdr: TCP header
> * @t_opt: TCP Timestamp Option
> * @sack_v: TCP SACK Option
> * @end: end of options
> */
> struct ip_tcp_hdr_s {
> - struct ip_tcp_hdr hdr;
> + struct ip_hdr ip_hdr;
> + struct tcp_hdrtcp_hdr;
> struct tcp_t_opt t_opt;
> struct tcp_sack_v sack_v;
> u8 end;
> @@ -303,3 +293,5 @@ void rxhand_tcp_f(union tcp_build_pkt *b, unsigned int
> len);
>
> u16 tcp_set_pseudo_header(uchar *pkt, struct in_addr src, struct in_addr
> dest,
> int tcp_len, int pkt_len);
> +
> +#endif // __TCP_H__
> diff --git a/net/tcp.c b/net/tcp.c
> index a713e1dd60..10ce799814 100644
> --- a/net/tcp.c
> +++ b/net/tcp.c
> @@ -155,7 +155,7 @@ u16 tcp_set_pseudo_header(uchar *pkt, struct in_addr
> src, struct in_addr dest,
> */
> int net_set_ack_options(union tcp_build_pkt *b)
> {
> - b->sack.hdr.tcp_hlen =
> SHIFT_TO_TCPHDRLEN_FIELD(LEN_B_TO_DW(TCP_HDR_SIZE));
> + b->sack.tcp_hdr.tcp_hlen =
> SHIFT_TO_TCPHDRLEN_FIELD(LEN_B_TO_DW(TCP_HDR_SIZE));
>
> b->sack.t_opt.kind = TCP_O_TS;
> b->sack.t_opt.len = TCP_OPT_LEN_A;
> @@ -187,12 +187,12 @@ int
Re: [PATCH 1/3] net: support being a TCP server to unblock TCP fastboot
On Wed, 29 Mar 2023 at 04:31, Dmitrii Merkurev wrote: > Make following changes to unblock TCP fastboot support: > > 1. Implement being a TCP server support > 2. Introduce dedicated TCP traffic handler (get rid of UDP signature) > 3. Ensure seq_num and ack_num are respected in net_send_tcp_packet > function (make sure existing wget_cmd code is reflected with the fix) > > Signed-off-by: Dmitrii Merkurev > Cc: Ying-Chun Liu (PaulLiu) > Cc: Simon Glass > Сс: Joe Hershberger > Сс: Ramon Fried > --- Reviewed-by: Ying-Chun Liu (PaulLiu) I've built it and ran the unit test of the TCP stack. The code looks good to me.
Re: [PATCH 4/6] compulab: imx8mm-cl-iot-gate: Fix some function declarations in eeprom_spl.c
Hi Tom,
Maybe we should fix the header by changing it to u8?
Because the eeprom only returns one byte for the DDRSUBIND value.
Yours,
Paul
On Fri, 10 Mar 2023 at 00:22, Tom Rini wrote:
> We have a few places here we the function declarations do not match
> their prototypes in another header, correct them.
>
> Signed-off-by: Tom Rini
> ---
> Cc: "Ying-Chun Liu (PaulLiu)"
> ---
> board/compulab/imx8mm-cl-iot-gate/eeprom_spl.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/board/compulab/imx8mm-cl-iot-gate/eeprom_spl.c
> b/board/compulab/imx8mm-cl-iot-gate/eeprom_spl.c
> index 90cc33a6e460..b8573aaac283 100644
> --- a/board/compulab/imx8mm-cl-iot-gate/eeprom_spl.c
> +++ b/board/compulab/imx8mm-cl-iot-gate/eeprom_spl.c
> @@ -101,7 +101,7 @@ u32 cl_eeprom_set_ddrinfo(u32 ddrinfo)
> return board_ddrinfo;
> };
>
> -u8 cl_eeprom_get_subind(void)
> +u32 cl_eeprom_get_subind(void)
> {
> if (cl_eeprom_read(BOARD_DDRSUBIND_OFFSET, (uchar
> *)_ddrsubind, BOARD_DDRSUBIND_SIZE))
> return 0xff;
> @@ -109,7 +109,7 @@ u8 cl_eeprom_get_subind(void)
> return board_ddrsubind;
> };
>
> -u8 cl_eeprom_set_subind(u8 ddrsubind)
> +u32 cl_eeprom_set_subind(u32 ddrsubind)
> {
> if (cl_eeprom_write(BOARD_DDRSUBIND_OFFSET, (uchar *),
> BOARD_DDRSUBIND_SIZE))
> return 0xff;
> --
> 2.34.1
>
>
Re: [PATCH 1/2] arm: cpu: Add optional CMOs by VA
Hi Marc, I think you are the author. I'm just making some minor fixes and then upstreaming to the mailing list. What is the correct way to make the Signed-off-by list? Yours, Paul On Wed, 8 Feb 2023 at 00:35, Marc Zyngier wrote: > On 2023-02-07 16:20, Ying-Chun Liu (PaulLiu) wrote: > > Exposing set/way cache maintenance to a virtual machine is unsafe, not > > least because the instructions are not permission-checked but also > > because they are not broadcast between CPUs. Consequently, KVM traps > > and > > emulates such maintenance in the host kernel using by-VA operations and > > looping over the stage-2 page-tables. However, when running under > > protected KVM, these instructions are not able to be emulated and will > > instead result in an exception being delivered to the guest. > > > > Introduce CONFIG_CMO_BY_VA_ONLY so that virtual platforms can select > > this option and perform by-VA cache maintenance instead of using the > > set/way instructions. > > > > Signed-off-by: Ying-Chun Liu (PaulLiu) > > Signed-off-by: Marc Zyngier > > Signed-off-by: Will Deacon > > Cc: Tom Rini > > The sign-off chain looks pretty odd. Either you are the author > of this patch, and I have nothing to do on the sign-off list, > or I'm the author and the authorship is wrong. Similar things > would apply for Will. > > So which one is it? > > M. > -- > Jazz is not dead. It just smells funny... >
Re: [PATCH v14 0/2] add TCP and HTTP for downloading images
Hi Michal, Thanks for reviewing. I'll make a fix based on your review soon. However I don't know the change from v1 to v12. The previous version are made by Duncan, and the patches are one year ago so I lost track of the changes from v1 to v12. For booting iso images (installer) from distros I think I'll need to try it. But it is definitely not related to HTTPS. What I know is the distro release ISO images. And we need to extract all efi (EFI shell, grub..) and initrd/kernel from ISO image's eltorito section. I need to figure that out how to do it by commands if we load the iso images to the memory. Yours, Paul On Wed, 18 May 2022 at 17:54, Michal Simek wrote: > Hi, > > On 4/21/22 18:54, Ying-Chun Liu wrote: > > From: "Ying-Chun Liu (PaulLiu)" > > > > This patch is a refresh from previous patches made by > > Duncan Hare . I've contacted him and > > continue to work on this patch. > > > > This patch introduce a TCP stack with SACK. And a simple wget command > > to download images from http server. > > > > v13: Fix some issues which is reviewed by Christian > > v14: Add options to enable/disable SACK. > > What did you change from v1 to v12? > > I think you should clean up the code and in this cover letter I would > expect > more description what you have tried. I have seen demo with downloading > efi > application. > Is there any way to run any OS installer? Or for that you need to have > https? > > Thanks, > Michal > > > >
Re: [PATCH] imx8m: fix reading of DDR4 MR registers
Hi Fabio, I tested. It works. Tested-by: Ying-Chun Liu (PaulLiu) On Tue, 26 Apr 2022 at 20:59, Fabio Estevam wrote: > Hi Paul, > > On Mon, Apr 25, 2022 at 11:23 AM Rasmus Villemoes > wrote: > > > > I was trying to employ lpddr4_mr_read() to something similar to what > > the imx8mm-cl-iot-gate board is doing for auto-detecting the RAM > > type. However, the version in drivers/ddr/imx/imx8m/ddrphy_utils.c > > differs from the private one used by that board in how it extracts the > > byte value, and I was only getting zeroes. Adding a bit of debug > > printf'ing gives me > > > > tmp = 0x0000 > > tmp = 0x00070700 > > tmp = 0x > > tmp = 0x00101000 > > > > and indeed I was expecting a (combined) value of 0xff070010 (0xff > > being Manufacturer ID for Micron). I can't find any documentation that > > says how the values are supposed to be read, but clearly the iot-gate > > definition is the right one, both for its use case as well as my > > imx8mp-based board. > > > > So lift the private definition of lpddr4_mr_read() from the > > imx8mm-cl-iot-gate board code to ddrphy_utils.c, and add a declaration > > in the ddr.h header where e.g. get_trained_CDD() is already declared. > > > > This has only been compile-tested for the imx8mm-cl-iot-gate > > board (since I don't have the hardware), but since I've merely moved > > its definition of lpddr4_mr_read(), I'd be surprised if it changed > > anything for that board. > > > > Signed-off-by: Rasmus Villemoes > > Could you please test this patch? > > I only have remote access to this board. >
Re: [PATCH 2/5] imx8mm-cl-iot-gate: Retrieve the DDR type from EEPROM
Hi Tim,
It seems to me the correct logic is.
If EEPROM provides information, we use that information directly.
Pick a dram setting and test the ram if it works.
If it is not working, then that means EEPROM has wrong data or someone
clean it wrongly.
So we loop the table, try to find the correct setting, and update the
EEPROM.
Yours,
Paul
On Tue, 22 Mar 2022 at 01:31, Tim Harvey wrote:
> On Sat, Mar 19, 2022 at 5:23 AM Fabio Estevam wrote:
> >
> > From: Fabio Estevam
> >
> > Currently, the DDR type is retrieved by iteracting inside an array
> > of possible DDR types.
> >
> > This may take saveral attempts, which slows the overall U-Boot process
> > and does not provide a good user experience:
> >
> > U-Boot SPL 2021.07 (Feb 28 2022 - 06:39:32 +)
> > DDRINFO: Cfg attempt: [ 1/6 ]
> > DDRINFO(M): mr5-8 [ 0xff10 ]
> > DDRINFO(T): mr5-8 [ 0x510 ]
> > resetting ...
> >
> > U-Boot SPL 2021.07 (Feb 28 2022 - 06:39:32 +)
> > DDRINFO: Cfg attempt: [ 2/6 ]
> > DDRINFO(M): mr5-8 [ 0xff10 ]
> > DDRINFO(T): mr5-8 [ 0x1061010 ]
> > resetting ...
> >
> > U-Boot SPL 2021.07 (Feb 28 2022 - 06:39:32 +)
> > DDRINFO: Cfg attempt: [ 3/6 ]
> > DDRINFO(M): mr5-8 [ 0xff10 ]
> > DDRINFO(T): mr5-8 [ 0xff10 ]
> > Normal Boot
> > WDT: Not starting
> > Trying to boot from MMC2
> > NOTICE: BL31: v2.5(release):v2.5
> > NOTICE: BL31: Built : 07:12:44, Jan 24 2022
> >
> > Improve the boot time by retrieving the correct DDR information from
> > the EEPROM:
> >
> > U-Boot SPL 2022.04-rc4-00045-g6d02bc40d58c (Mar 19 2022 - 08:22:29 -0300)
> > DDRINFO(D): Kingston 4096G
> > DDRINFO(M): mr5-8 [ 0xff10 ]
> > DDRINFO(E): mr5-8 [ 0xff10 ]
> > Normal Boot
> > WDT: Started watchdog@3028 with servicing (60s timeout)
> > Trying to boot from MMC2
> > NOTICE: BL31: v2.5(release):v2.5
> > NOTICE: BL31: Built : 22:28:11, Mar 15 2022
> >
> > Based on the original code from Compulab's U-Boot.
> >
> > Tested on a imx8mm-cl-iot-gate board populated with 4GB of RAM.
> >
> > Signed-off-by: Fabio Estevam
> > ---
> > board/compulab/imx8mm-cl-iot-gate/ddr/ddr.c | 24 ++---
> > board/compulab/imx8mm-cl-iot-gate/ddr/ddr.h | 5 +
> > 2 files changed, 26 insertions(+), 3 deletions(-)
> >
> > diff --git a/board/compulab/imx8mm-cl-iot-gate/ddr/ddr.c
> b/board/compulab/imx8mm-cl-iot-gate/ddr/ddr.c
> > index 42dd0dbf18fa..5b93491923e9 100644
> > --- a/board/compulab/imx8mm-cl-iot-gate/ddr/ddr.c
> > +++ b/board/compulab/imx8mm-cl-iot-gate/ddr/ddr.c
> > @@ -22,6 +22,8 @@
> > #include
> > #include "ddr.h"
> >
> > +#include
> > +
> > static unsigned int lpddr4_mr_read(unsigned int mr_rank, unsigned int
> mr_addr)
> > {
> > unsigned int tmp;
> > @@ -137,10 +139,11 @@ void spl_dram_init_compulab(void)
> > (struct lpddr4_tcm_desc *)SPL_TCM_DATA;
> >
> > if (lpddr4_tcm_desc->sign != DEFAULT) {
> > - /* if not in tcm scan mode */
> > + /* get ddr type from the eeprom if not in tcm scan mode
> */
> > + ddr_info = cl_eeprom_get_ddrinfo();
> > for (i = 0; i < ARRAY_SIZE(lpddr4_array); i++) {
> > if (lpddr4_array[i].id == ddr_info &&
> > - lpddr4_array[i].subind == 0xff) {
> > + lpddr4_array[i].subind ==
> cl_eeprom_get_subind()) {
> > ddr_found = 1;
> > break;
> > }
> > @@ -198,10 +201,25 @@ void spl_dram_init_compulab(void)
> >
> > SPL_TCM_FINI;
> >
> > + if (ddr_found == 0) {
> > + /* Update eeprom */
> > + cl_eeprom_set_ddrinfo(ddr_info_mrr);
> > + mdelay(10);
> > + ddr_info = cl_eeprom_get_ddrinfo();
> > + mdelay(10);
> > + cl_eeprom_set_subind(lpddr4_array[i].subind);
> > + /* make sure that the ddr_info has reached the eeprom */
> > + printf("DDRINFO(E): mr5-8 [ 0x%x ], read back\n",
> ddr_info);
> > + if (ddr_info_mrr != ddr_info || cl_eeprom_get_subind()
> != lpddr4_array[i].subind) {
> > + printf("DDRINFO(EEPROM): make sure that the
> eeprom is accessible\n");
> > + printf("DDRINFO(EEPROM): i2c dev 1; i2c md 0x51
> 0x40 0x50\n");
> > + }
> > + }
> > +
> > /* Pass the dram size to th U-Boot through the tcm memory */
> > { /* To figure out what to store into the TCM buffer */
> > /* For debug purpouse only. To override the real memsize */
> > - unsigned int ddr_tcm_size = 0;
> > + unsigned int ddr_tcm_size = cl_eeprom_get_osize();
> >
> > if (ddr_tcm_size == 0 || ddr_tcm_size == -1)
> > ddr_tcm_size = lpddr4_array[i].size;
> > diff --git a/board/compulab/imx8mm-cl-iot-gate/ddr/ddr.h
> b/board/compulab/imx8mm-cl-iot-gate/ddr/ddr.h
> > index
Re: [RFC 1/2] drivers: mmc: write protect active boot area after mmc init.
Hi Jaehoon,
There are 2 boot partitions on eMMC. So the active one is write-protected.
Users can write the new firmware to another boot partition (inactive) which
is not write-protected.
And then switch it on.
In U-boot, execute "mmc wp" write-protect all of the boot partitions.
Maybe we can add an additional command that just write-protect only one
boot partition.
Yours,
Paul
On Thu, 27 Jan 2022 at 07:24, Jaehoon Chung wrote:
> Hi,
>
> On 1/25/22 22:55, Ying-Chun Liu wrote:
> > From: "Ying-Chun Liu (PaulLiu)"
> >
> > This commit implements write protection for active boot partition for
> > eMMC. The active boot partition is write protected, and it is still
> > able to write to the inactive boot partition.
>
> It seems that you want to enable Write-protect about boot partition
> without additional command, right?
> After initialized eMMC, how to update image into boot partition?
>
> Best Regards,
> Jaehoon Chung
>
> >
> > Signed-off-by: Ying-Chun Liu (PaulLiu)
> > Cc: Peng Fan
> > Cc: Jaehoon Chung
> > ---
> > drivers/mmc/Kconfig | 10
> > drivers/mmc/mmc.c | 58 +
> > 2 files changed, 68 insertions(+)
> >
> > diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
> > index e0927ce1c9..c4bae743e6 100644
> > --- a/drivers/mmc/Kconfig
> > +++ b/drivers/mmc/Kconfig
> > @@ -100,6 +100,16 @@ config MMC_HW_PARTITIONING
> > This adds a command and an API to do hardware partitioning on
> eMMC
> > devices.
> >
> > +config MMC_WRITE_PROTECT_ACTIVE_BOOT
> > + bool "Write protection for active boot partition (eMMC)"
> > + depends on MMC_HW_PARTITIONING
> > + default n
> > + help
> > + Write protection for active boot partition when mmc initialized.
> > + This option protects the active boot partition so that it cannot
> > + be written. But it is still able to write to the inactive boot
> > + partition.
> > +
> > config SUPPORT_EMMC_RPMB
> > bool "Support eMMC replay protected memory block (RPMB)"
> > imply CMD_MMC_RPMB
> > diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
> > index 4d9871d69f..8620918749 100644
> > --- a/drivers/mmc/mmc.c
> > +++ b/drivers/mmc/mmc.c
> > @@ -860,6 +860,60 @@ int mmc_boot_wp(struct mmc *mmc)
> > return mmc_switch(mmc, EXT_CSD_CMD_SET_NORMAL, EXT_CSD_BOOT_WP, 1);
> > }
> >
> > +/**
> > + * mmc_boot_wp_single_partition() - set write protection to a boot
> partition.
> > + *
> > + * This function sets a single boot partition to protect and leave the
> > + * other partition writable.
> > + *
> > + * @param mmc the mmc device.
> > + * @param partition 0 - first boot partition, 1 - second boot partition.
> > + */
> > +int mmc_boot_wp_single_partition(struct mmc *mmc, int partition)
> > +{
> > + u8 value;
> > + int ret;
> > +
> > + value = 1;
> > +
> > + if (partition == 0) {
> > + value |= 0x80;
> > + ret = mmc_switch(mmc,
> > + EXT_CSD_CMD_SET_NORMAL,
> > + EXT_CSD_BOOT_WP,
> > + value);
> > + } else if (partition == 1) {
> > + value |= 0x80;
> > + value |= 0x02;
> > + ret = mmc_switch(mmc,
> > + EXT_CSD_CMD_SET_NORMAL,
> > + EXT_CSD_BOOT_WP,
> > + value);
> > + } else {
> > + ret = mmc_boot_wp(mmc);
> > + }
> > +
> > + return ret;
> > +}
> > +
> > +/**
> > + * mmc_boot_wp_active_partition() - set write protection to active boot
> > + * partition.
> > + *
> > + * @param mmc the mmc device.
> > + */
> > +static int mmc_boot_wp_active_partition(struct mmc *mmc)
> > +{
> > + u8 part;
> > +
> > + if (mmc->part_config == MMCPART_NOAVAILABLE)
> > + return -EOPNOTSUPP;
> > +
> > + part = EXT_CSD_EXTRACT_BOOT_PART(mmc->part_config);
> > +
> > + return mmc_boot_wp_single_partition(mmc, part - 1);
> > +}
> > +
> > #if !CONFIG_IS_ENABLED(MMC_TINY)
> > static int mmc_set_card_speed(struct mmc *mmc, enum bus_mode mode,
> > bool hsdowngrade)
> > @@ -2925,6 +2979,10 @@ static int mmc_complete_init(struct mmc *mmc)
> > mmc->has_init = 0;
> > else
> > mmc->has_init = 1;
> > +
> > + if (!err && CONFIG_IS_ENABLED(MMC_WRITE_PROTECT_ACTIVE_BOOT))
> > + mmc_boot_wp_active_partition(mmc);
> > +
> > return err;
> > }
> >
>
>
Re: [PATCH v3] imx8mm-cl-iot-gate: Split the defconfigs
On Tue, 24 Aug 2021 at 08:11, Fabio Estevam wrote:
> Currently imx8mm-cl-iot-gate_defconfig fails to produce a working boot
> binary due to the lack of fip.bin:
>
> " BINMAN all
> Image 'main-section' is missing external blobs and is non-functional:
> blob-ext
>
> Some images are invalid"
>
> To make the build process more consistent with the other i.MX8M targets,
> split the defconfig in two:
>
> - imx8mm-cl-iot-gate_defconfig: standard defconfig that only
> requires ATF / DDR firmware.
>
> - imx8mm-cl-iot-gate-optee_defconfig: "more advanced" defconfig that
> requires ATF / Optee / mbedtls / DDR firmware.
>
> Signed-off-by: Fabio Estevam
> ---
> Changes since v2:
> - Rename the ATF binary to bl2.bin in the optee case (Paul)
>
> arch/arm/dts/Makefile | 2 +
> .../dts/imx8mm-cl-iot-gate-optee-u-boot.dtsi | 255 ++
> arch/arm/dts/imx8mm-cl-iot-gate-optee.dts | 6 +
> arch/arm/dts/imx8mm-cl-iot-gate-u-boot.dtsi | 14 +-
> arch/arm/mach-imx/imx8m/Kconfig | 7 +
> board/compulab/imx8mm-cl-iot-gate/Kconfig | 2 +-
> board/compulab/imx8mm-cl-iot-gate/MAINTAINERS | 1 +
> configs/imx8mm-cl-iot-gate-optee_defconfig| 147 ++
> 8 files changed, 420 insertions(+), 14 deletions(-)
> create mode 100644 arch/arm/dts/imx8mm-cl-iot-gate-optee-u-boot.dtsi
> create mode 100644 arch/arm/dts/imx8mm-cl-iot-gate-optee.dts
> create mode 100644 configs/imx8mm-cl-iot-gate-optee_defconfig
>
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index c42715ead4..88f52cd390 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -1127,6 +1127,8 @@ dtb-$(CONFIG_TARGET_PRESIDIO_ASIC) +=
> ca-presidio-engboard.dtb
>
> dtb-$(CONFIG_TARGET_IMX8MM_CL_IOT_GATE) += imx8mm-cl-iot-gate.dtb
>
> +dtb-$(CONFIG_TARGET_IMX8MM_CL_IOT_GATE_OPTEE) +=
> imx8mm-cl-iot-gate-optee.dtb
> +
> dtb-$(CONFIG_TARGET_EA_LPC3250DEVKITV2) += lpc3250-ea3250.dtb
>
> targets += $(dtb-y)
> diff --git a/arch/arm/dts/imx8mm-cl-iot-gate-optee-u-boot.dtsi
> b/arch/arm/dts/imx8mm-cl-iot-gate-optee-u-boot.dtsi
> new file mode 100644
> index 00..3226a244a9
> --- /dev/null
> +++ b/arch/arm/dts/imx8mm-cl-iot-gate-optee-u-boot.dtsi
> @@ -0,0 +1,255 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright 2019 NXP
> + */
> +
> +/ {
> + binman: binman {
> + multiple-images;
> + };
> +
> + wdt-reboot {
> + compatible = "wdt-reboot";
> + wdt = <>;
> + u-boot,dm-spl;
> + };
> +
> + firmware {
> + optee {
> + compatible = "linaro,optee-tz";
> + method = "smc";
> + };
> + };
> +};
> +
> +&{/soc@0} {
> + u-boot,dm-pre-reloc;
> + u-boot,dm-spl;
> +};
> +
> + {
> + u-boot,dm-spl;
> + u-boot,dm-pre-reloc;
> + /delete-property/ assigned-clocks;
> + /delete-property/ assigned-clock-parents;
> + /delete-property/ assigned-clock-rates;
> +};
> +
> +_24m {
> + u-boot,dm-spl;
> + u-boot,dm-pre-reloc;
> +};
> +
> + {
> + u-boot,dm-spl;
> + u-boot,dm-pre-reloc;
> +};
> +
> + {
> + u-boot,dm-spl;
> +};
> +
> + {
> + u-boot,dm-spl;
> +};
> +
> + {
> + u-boot,dm-spl;
> +};
> +
> +_uart3 {
> + u-boot,dm-spl;
> +};
> +
> +_usdhc2_gpio {
> + u-boot,dm-spl;
> +};
> +
> +_usdhc2 {
> + u-boot,dm-spl;
> +};
> +
> +_usdhc3 {
> + u-boot,dm-spl;
> +};
> +
> + {
> + u-boot,dm-spl;
> +};
> +
> + {
> + u-boot,dm-spl;
> +};
> +
> + {
> + u-boot,dm-spl;
> +};
> +
> + {
> + u-boot,dm-spl;
> +};
> +
> + {
> + u-boot,dm-spl;
> +};
> +
> + {
> + u-boot,dm-spl;
> +};
> +
> + {
> + u-boot,dm-spl;
> +};
> +
> + {
> + u-boot,dm-spl;
> +};
> +
> + {
> + u-boot,dm-spl;
> +};
> +
> + {
> + u-boot,dm-spl;
> +};
> +
> + {
> + u-boot,dm-spl;
> +};
> +
> +&{/soc@0/bus@3080/i2c@30a3/pmic@4b} {
> + u-boot,dm-spl;
> +};
> +
> +&{/soc@0/bus@3080/i2c@30a3/pmic@4b/regulators} {
> + u-boot,dm-spl;
> +};
> +
> +_i2c2 {
> + u-boot,dm-spl;
> +};
> +
> +_pmic {
> + u-boot,dm-spl;
> +};
> +
> + {
> + phy-reset-gpios = < 22 GPIO_ACTIVE_LOW>;
> +};
> +
> + {
> + u-boot,dm-spl;
> +};
> +
> + {
> + u-boot-spl-ddr {
> + filename = "u-boot-spl-ddr.bin";
> + pad-byte = <0xff>;
> + align-size = <4>;
> + align = <4>;
> +
> + u-boot-spl {
> + align-end = <4>;
> + };
> +
> + blob_1: blob-ext@1 {
> + filename = "lpddr4_pmu_train_1d_imem.bin";
> + size = <0x8000>;
> + };
> +
> + blob_2: blob-ext@2 {
> + filename = "lpddr4_pmu_train_1d_dmem.bin";
> + size = <0x4000>;
> + };
> +
> +
Re: [PATCH v2] imx8mm-cl-iot-gate: Split the defconfigs
Hi Fabio,
Yes. This patch works for me after fixing the top address.
I have another little comment on the name of bl31.bin as following.
--- /dev/null
+++ b/arch/arm/dts/imx8mm-cl-iot-gate-optee-u-boot.dtsi
@@ -0,0 +1,255 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2019 NXP
+ */
+
+/ {
+ binman: binman {
+ multiple-images;
+ };
+
+ wdt-reboot {
+ compatible = "wdt-reboot";
+ wdt = <>;
+ u-boot,dm-spl;
+ };
+
+ firmware {
+ optee {
+ compatible = "linaro,optee-tz";
+ method = "smc";
+ };
+ };
+};
+
+&{/soc@0} {
+ u-boot,dm-pre-reloc;
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+ u-boot,dm-pre-reloc;
+ /delete-property/ assigned-clocks;
+ /delete-property/ assigned-clock-parents;
+ /delete-property/ assigned-clock-rates;
+};
+
+_24m {
+ u-boot,dm-spl;
+ u-boot,dm-pre-reloc;
+};
+
+ {
+ u-boot,dm-spl;
+ u-boot,dm-pre-reloc;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+_uart3 {
+ u-boot,dm-spl;
+};
+
+_usdhc2_gpio {
+ u-boot,dm-spl;
+};
+
+_usdhc2 {
+ u-boot,dm-spl;
+};
+
+_usdhc3 {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+&{/soc@0/bus@3080/i2c@30a3/pmic@4b} {
+ u-boot,dm-spl;
+};
+
+&{/soc@0/bus@3080/i2c@30a3/pmic@4b/regulators} {
+ u-boot,dm-spl;
+};
+
+_i2c2 {
+ u-boot,dm-spl;
+};
+
+_pmic {
+ u-boot,dm-spl;
+};
+
+ {
+ phy-reset-gpios = < 22 GPIO_ACTIVE_LOW>;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot-spl-ddr {
+ filename = "u-boot-spl-ddr.bin";
+ pad-byte = <0xff>;
+ align-size = <4>;
+ align = <4>;
+
+ u-boot-spl {
+ align-end = <4>;
+ };
+
+ blob_1: blob-ext@1 {
+ filename = "lpddr4_pmu_train_1d_imem.bin";
+ size = <0x8000>;
+ };
+
+ blob_2: blob-ext@2 {
+ filename = "lpddr4_pmu_train_1d_dmem.bin";
+ size = <0x4000>;
+ };
+
+ blob_3: blob-ext@3 {
+ filename = "lpddr4_pmu_train_2d_imem.bin";
+ size = <0x8000>;
+ };
+
+ blob_4: blob-ext@4 {
+ filename = "lpddr4_pmu_train_2d_dmem.bin";
+ size = <0x4000>;
+ };
+ };
+
+ flash {
+ mkimage {
+ args = "-n spl/u-boot-spl.cfgout -T imx8mimage -e
0x7e1000";
+
+ blob {
+ filename = "u-boot-spl-ddr.bin";
+ };
+ };
+ };
+
+ itb {
+ filename = "u-boot.itb";
+
+ fit {
+ description = "Configuration to load ATF before
U-Boot";
+ #address-cells = <1>;
+ fit,external-offset = ;
+
+ images {
+ uboot {
+ description = "U-Boot (64-bit)";
+ type = "standalone";
+ arch = "arm64";
+ compression = "none";
+ load = ;
+
+ uboot_blob: blob-ext {
+ filename =
"u-boot-nodtb.bin";
+ };
+ };
+
+ atf {
+ description = "ARM Trusted
Firmware";
+ type = "firmware";
+ arch = "arm64";
+ compression = "none";
+ load = <0x92>;
+ entry = <0x92>;
+
+ atf_blob: blob-ext {
+ filename = "bl31.bin";
I think we can call it bl2.bin now because now the dts is separated. So in
this defconfig we don't need to take care the name compatibility of the
non-optee defconfig.
+ };
+ };
And I'll write a document after your commits gets in to describe the
Re: [PATCH 1/2] imx8mm-cl-iot-gate: Do not build fip.bin by default
Hi Frieder,
I think I might have found a reason. The problem might be that the
board_get_usable_ram_top() doesn't subtract the memory used by optee. Optee
on imx8m uses the end of the memory. It is passed by arguments.
VERBOSE: Argument #1 = 0x7e00
VERBOSE: Argument #2 = 0x200
So if I extract 0x8000 by 0x200 then the board boots. That also
explains why Fabio can boot his board because he doesn't use OPTEE.
What I'm doing is I implemented a board_phys_sdram_size(). However because
all of my boards are 2G memory. And I did set PHYS_SDRAM_SIZE to 2G when
upstreaming Compulab's support previously. That means with or without
board_phys_sdram_size() the board just doesn't boot on the master branch
because the gd->ram_size is the same, 2GB.
But you are correct, we do need to have board_phys_sdram_size() implemented
because on Compulab's page we know that they have multiple choices. The
memory could be 1G/2G/4G. So this function is needed to tell how much
memory we have. But the hang problem is just not related to this function.
The problem I think is we need to deal with rom_pointer that contains the
OPTEE address in board_get_usable_ram_top().
Yours,
Paul
On Fri, 20 Aug 2021 at 04:51, Paul Liu wrote:
> Hi Frieder,
>
> I'll confirm it. But I guess you are correct. I'll send a patch soon when
> I implement this right.
>
> Yours,
> Paul
>
>
> On Thu, 19 Aug 2021 at 15:14, Frieder Schrempf <
> frieder.schre...@kontron.de> wrote:
>
>> On 19.08.21 02:27, Fabio Estevam wrote:
>> > [Adding Marek]
>> >
>> > On Wed, Aug 18, 2021 at 6:39 PM Fabio Estevam
>> wrote:
>> >>
>> >> Hi Paul,
>> >>
>> >> On Wed, Aug 18, 2021 at 6:32 PM Paul Liu wrote:
>> >>>
>> >>> Hi Fabio,
>> >>>
>> >>> I got several boards. With all different PN. But all of them are 2GB
>> memory. And the recent master doesn't boot on one of my board. I haven't
>> tried all of the combinations.
>> >>
>> >> With the U-Boot from Compulab, it reports 4GB. With mainline U-Boot it
>> >> reports 2GB, so yes, there is an issue indeed.
>> >>
>> >> However, I don't see a hang.
>> >>
>> >>> After bisect, I found commit e27bddff breaks the boot. It just hang
>> there.
>> >>
>> >> Adding Frieder as the author of the patch.
>> >
>> > Marek objected to this change, which is now:
>> > e27bdd ff4b97 ("imx8m: Restrict usable memory to space below 4G
>> boundary")
>>
>> Yes, Marek objected and it was still pulled in for some reason.
>>
>> >
>> > As this causes a regression on Paul's i.MX8MM IoT Gateway board,
>> > should this be reverted?
>>
>> Maybe, yes. I'll leave that decision to the maintainers.
>>
>> For the failure: The change in e27bddff4b97 assumes that gd->ram_size was
>> set during initialization/detection of the DDR. Could it be that the
>> Compulab board doesn't do this and gd->ram_size is 0 or differs from the
>> actual DDR size? That would probably cause some kind of issue.
>>
>> Paul, maybe you could check if gd->ram_size is set properly. Other boards
>> do this by implementing board_phys_sdram_size() [1], which also makes sure
>> that the memory map is updated with the detected size in dram_init() [2].
>>
>> [1]
>> https://elixir.bootlin.com/u-boot/latest/source/board/gateworks/venice/imx8mm_venice.c#L21
>> [2]
>> https://elixir.bootlin.com/u-boot/latest/source/arch/arm/mach-imx/imx8m/soc.c#L218
>>
>
Re: [PATCH 1/2] imx8mm-cl-iot-gate: Do not build fip.bin by default
Hi Frieder,
I'll confirm it. But I guess you are correct. I'll send a patch soon when I
implement this right.
Yours,
Paul
On Thu, 19 Aug 2021 at 15:14, Frieder Schrempf
wrote:
> On 19.08.21 02:27, Fabio Estevam wrote:
> > [Adding Marek]
> >
> > On Wed, Aug 18, 2021 at 6:39 PM Fabio Estevam
> wrote:
> >>
> >> Hi Paul,
> >>
> >> On Wed, Aug 18, 2021 at 6:32 PM Paul Liu wrote:
> >>>
> >>> Hi Fabio,
> >>>
> >>> I got several boards. With all different PN. But all of them are 2GB
> memory. And the recent master doesn't boot on one of my board. I haven't
> tried all of the combinations.
> >>
> >> With the U-Boot from Compulab, it reports 4GB. With mainline U-Boot it
> >> reports 2GB, so yes, there is an issue indeed.
> >>
> >> However, I don't see a hang.
> >>
> >>> After bisect, I found commit e27bddff breaks the boot. It just hang
> there.
> >>
> >> Adding Frieder as the author of the patch.
> >
> > Marek objected to this change, which is now:
> > e27bdd ff4b97 ("imx8m: Restrict usable memory to space below 4G
> boundary")
>
> Yes, Marek objected and it was still pulled in for some reason.
>
> >
> > As this causes a regression on Paul's i.MX8MM IoT Gateway board,
> > should this be reverted?
>
> Maybe, yes. I'll leave that decision to the maintainers.
>
> For the failure: The change in e27bddff4b97 assumes that gd->ram_size was
> set during initialization/detection of the DDR. Could it be that the
> Compulab board doesn't do this and gd->ram_size is 0 or differs from the
> actual DDR size? That would probably cause some kind of issue.
>
> Paul, maybe you could check if gd->ram_size is set properly. Other boards
> do this by implementing board_phys_sdram_size() [1], which also makes sure
> that the memory map is updated with the detected size in dram_init() [2].
>
> [1]
> https://elixir.bootlin.com/u-boot/latest/source/board/gateworks/venice/imx8mm_venice.c#L21
> [2]
> https://elixir.bootlin.com/u-boot/latest/source/arch/arm/mach-imx/imx8m/soc.c#L218
>
Re: [PATCH 1/2] imx8mm-cl-iot-gate: Do not build fip.bin by default
Hi Fabio, I got several boards. With all different PN. But all of them are 2GB memory. And the recent master doesn't boot on one of my board. I haven't tried all of the combinations. After bisect, I found commit e27bddff breaks the boot. It just hang there. But if I change PHYS_SDRAM_SIZE to 1GB then it can boot. However this is not the solution because it limits the memory usage. So I might need to take some time look into what happened and spend more time to test on other PN. Before start testing your patches. And because you can boot the master branch fine so I'm not sure what happened on my side. Yours, Paul On Wed, 18 Aug 2021 at 20:24, Fabio Estevam wrote: > Hi Paul, > > On Tue, Aug 17, 2021 at 9:09 PM Paul Liu wrote: > > > > Hi Fabio, > > > > Can I know your Compulab's hardware PN? > > Something like "IOTG-IMX8-D2-NA16-WB-FATPM". > > I only have remote access to the board, so I can't tell you the part > number at the moment. > > Anything in particular that you are concerned about? > > Thanks, > > Fabio Estevam >
Re: [PATCH 1/2] imx8mm-cl-iot-gate: Do not build fip.bin by default
Hi Fabio, Can I know your Compulab's hardware PN? Something like "IOTG-IMX8-D2-NA16-WB-FATPM". Yours, Paul On Wed, 18 Aug 2021 at 02:32, Fabio Estevam wrote: > Hi Paul, > > On Mon, Aug 16, 2021 at 9:50 PM Paul Liu wrote: > > > > Hi Fabio, > > > > It looks good to me. Thanks a lot. > > I have sent a v2 with such a proposal. > > I would appreciate it if you could review and test booting the two > defconfigs. > > Thanks, > > Fabio Estevam >
Re: [PATCH 1/2] imx8mm-cl-iot-gate: Do not build fip.bin by default
Hi Fabio, It looks good to me. Thanks a lot. BTW. mbedtls version might not always work. In my local directory the mbedtls commit is bd21b18a1faa08705ac6d9980794c181e645f53a. Which is a commit in the development branch. Based on Tom's correction I'll write more detailed steps. Yours, Paul On Tue, 17 Aug 2021 at 06:41, Fabio Estevam wrote: > Hi Paul, > > On Mon, Aug 16, 2021 at 6:09 PM Fabio Estevam wrote: > > > What about having two defconfigs for this board? > > > > imx8mm-cl-iot-gate_defconfig for the regular users. This one can be > > simply be built by > > following the README I wrote and it matches the way used on other > > i.MX8MM boards. > > > > imx8mm-cl-iot-gate_optee_defconfig for the users that want to use > > fip/optee, etc? > > > > Would you agree with such an approach? > > Here is my proposal: > https://pastebin.com/raw/PGKZvCGR > > If you are happy with this, I can submit it formally. > > Thanks >
Re: [PATCH 1/2] imx8mm-cl-iot-gate: Do not build fip.bin by default
Hi Fabio,
No. I think they actually use fip.bin but just not upstreamed yet. Please
see the "Firmware version" in the list. For Compulab we are using mainline
U-boot. But for imx8mm-evk it is NXP released firmware.
And yes we do use mainline ATF and mainline OPTEE. I'll explain how to
build all of them.
# OPTEE
1. export ARCH=arm
2. export CROSS_COMPILE=arm-linux-gnueabihf-
3. export CROSS_COMPILE64=aarch64-linux-gnu-
4. make PLATFORM=imx PLATFORM_FLAVOR=mx8mm_cl_iot_gate O=build.mx8mmevk \
CFG_TEE_CORE_LOG_LEVEL=2 \
CFG_TEE_TA_LOG_LEVEL=2 \
CFG_TEE_CORE_DEBUG=y \
CFG_EXTERNAL_DTB_OVERLAY=y \
CFG_DT=y \
CFG_DT_ADDR=0x5200 \
CFG_DEBUG_INFO=y
And we got tee-header_v2.bin tee-pager_v2.bin and tee-pageable_v2.bin.
These files will be used in the TF-A stage.
Then we start building U-boot (BL31).
# U-boot (BL31)
1. export ARCH=arm64
2. export CROSS_COMPILE=aarch64-linux-gnu-
3. export ATF_LOAD_ADDR=0x92
4. make O=/tmp/uboot-imx8 imx8mm-cl-iot-gate_defconfig
5. make O=/tmp/uboot-imx8
We got u-boot.bin at this stage. u-boot.bin is needed for the next stage.
# TF-A
make ARCH=aarch64 CROSS_COMPILE=aarch64-linux-gnu- PLAT=imx8mm \
SPD=opteed BL32_BASE=0x7e00 IMX_BOOT_UART_BASE=0x3088 \
NEED_BL32=yes NEED_BL33=yes NEED_BL2=yes \
LOG_LEVEL=50 \
USE_TBBR_DEFS=1 GENERATE_COT=1 TRUSTED_BOARD_BOOT=1 \
MBEDTLS_DIR=../mbedtls \
BL32=../optee_os/build.mx8mmevk/core/tee-header_v2.bin \
BL32_EXTRA1=../optee_os/build.mx8mmevk/core/tee-pager_v2.bin \
BL32_EXTRA2=../optee_os/build.mx8mmevk/core/tee-pageable_v2.bin \
BL33=/tmp/uboot-imx8/u-boot.bin BL2_CFLAGS=-DIMX8M_FIP_MMAP \
fip bl2 bl31
Now we have bl2.bin and fip.bin in build/imx8mm/release for the next stage.
# U-boot (generate flash.bin and u-boot.itb)
1. export NXP_FIRMWARE=firmware-imx-8.8.bin
2. wget -c http://www.freescale.com/lgfiles/NMG/MAD/YOCTO/${NXP_FIRMWARE}
3. bash -x ${NXP_FIRMWARE} --auto-accept
4. cp -v $(find firmware* | awk '/train|hdmi_imx8|dp_imx8/' ORS=" ")
/tmp/uboot-imx8
5. cp -v ../trusted-firmware-a/build/imx8mm/release/bl2.bin
/tmp/uboot-imx8/bl31.bin
6. cp -v ../trusted-firmware-a/build/imx8mm/release/fip.bin
/tmp/uboox-imx8/fip.bin
7. export ARCH=arm64
8. export CROSS_COMPILE=aarch64-linux-gnu-
9. export ATF_LOAD_ADDR=0x92
10. make O=/tmp/uboot-imx8
So now it shouldn't complain about missing images.
Yours,
Paul
On Fri, 13 Aug 2021 at 20:15, Fabio Estevam wrote:
> Hi Paul,
>
> On 13/08/2021 06:59, Paul Liu wrote:
> > Hi Fabio,
> >
> > Can we think of a way to keep this fip.bin feature? This is part of
> > the SystemReady IR certificate for this Compulab board. [1]
> >
> > [1]
> >
> https://developer.arm.com/architectures/system-architectures/arm-systemready/ir
>
> i.MX8MM EVK is also listed there and we don't use fip.bin on this
> platform (and
> not on any other i.MX8MM platform in mainline U-Boot).
>
> If you really want to use fip.bin, could you please let me know the
> exact
> build procedure for AT-F? Do you use mainline ATF?
>
> As a user of the IOT-GATE-iMX8, I would just like to be able to flash
> mainline
> U-Boot and move forward. Even better if I could use the same procedure
> that has been used on other i.MX8MM boards.
>
> Regards,
>
> Fabio Estevam
> --
> DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-60 Fax: (+49)-8142-66989-80 Email:
> feste...@denx.de
>
Re: [PATCH 2/2] imx8mm-cl-iot-gate: Add documentation
Hi Fabio,
Did you use the boot partition?
I mean, why don't we use "mmc partconf 0 0 1 0"
So that we can flash u-boot to partition 1 and leave partition 0 for distro
install.
The following sequence should work.
init setup
1. mmc dev 2
2. mmc partconf 0 0 1 0
flash u-boot
1. tftp ${loadaddr} flash.bin
2. setexpr blkcnt $filesize + 0x1ff && setexpr blkcnt $blkcnt / 0x200
3. mmc dev 2 1
4. mmc write $loadaddr 0x42 $blkcnt
5. tftp ${loadaddr} u-boot.itb
6. setexpr blkcnt $filesize + 0x1ff && setexpr blkcnt $blkcnt / 0x200
7. mmc dev 2 1
8. mmc write $loadaddr 0x300 $blkcnt
Yours,
Paul
On Fri, 13 Aug 2021 at 08:59, Fabio Estevam wrote:
> Add documentation for building and flashing mainline U-Boot
> in the IOT-GATE-iMX8 board.
>
> Signed-off-by: Fabio Estevam
> ---
> doc/board/compulab/imx8mm-cl-iot-gate.rst | 84 +++
> doc/board/index.rst | 1 +
> 2 files changed, 85 insertions(+)
> create mode 100644 doc/board/compulab/imx8mm-cl-iot-gate.rst
>
> diff --git a/doc/board/compulab/imx8mm-cl-iot-gate.rst
> b/doc/board/compulab/imx8mm-cl-iot-gate.rst
> new file mode 100644
> index ..b63b8d61f13f
> --- /dev/null
> +++ b/doc/board/compulab/imx8mm-cl-iot-gate.rst
> @@ -0,0 +1,83 @@
> +.. SPDX-License-Identifier: GPL-2.0+
> +
> +IOT-GATE-iMX8
> +=
> +
> +U-Boot for Compulab i.MX8MM IoT Gateway board.
> +
> +Quick Start
> +---
> +
> +- Build the ARM Trusted firmware binary
> +- Get the DDR firmwares
> +- Build U-Boot
> +- Flash U-Boot into the eMMC
> +
> +Get and build the ARM Trusted firmware
> +--
> +
> +Note: builddir is U-Boot build directory (source directory for in-tree
> builds).
> +
> +Get mainline ATF:
> +
> +.. code-block:: bash
> +
> + $ git clone https://github.com/ARM-software/arm-trusted-firmware.git
> + $ cd arm-trusted-firmware
> + $ git checkout v2.5
> +
> +Generate the bl31.bin ATF binary:
> +
> +.. code-block:: bash
> +
> + $ export CROSS_COMPILE=aarch64-poky-linux-
> + $ make PLAT=imx8mm IMX_BOOT_UART_BASE=0x3088 bl31
> + $ cp build/imx8mm/release/bl31.bin $(builddir)
> +
> +Get the DDR firmwares
> +-
> +
> +.. code-block:: bash
> +
> + $ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-8.9.bin
> + $ chmod +x firmware-imx-8.9.bin
> + $ ./firmware-imx-8.9
> + $ cp firmware-imx-8.9/firmware/ddr/synopsys/lpddr4*.bin $(builddir)
> +
> +Build U-Boot
> +
> +
> +.. code-block:: bash
> +
> + $ export CROSS_COMPILE=aarch64-poky-linux-
> + $ make imx8mm-cl-iot-gate_defconfig
> + $ export ATF_LOAD_ADDR=0x92
> + $ make
> +
> +This will result in two binaries: flash.bin and u-boot.itb.
> +
> +Flash U-Boot into the eMMC
> +--
> +
> +Make sure to have access to the IOTG-ACC-M2SD adapter to recover
> +the board in case something goes wrong. More details at:
> +
> https://mediawiki.compulab.com/w/index.php?title=IOT-GATE-iMX8_and_SBC-IOT-iMX8:_U-Boot:_Recovery
> +
> +The flash.bin and u-boot.itb binaries need to be flashed into the eMMC at
> +offset 33K and 384K, respectively.
> +
> +These binaries can be transferred from the host PC to the board running
> +U-Boot via TFTP:
> +
> +.. code-block:: bash
> +
> + => mmc dev 2
> + => mmc partconf 2 1 7 0 (This is only needed to be done for the first
> time)
> +
> + => tftp $loadaddr flash.bin
> + => setexpr blkcnt $filesize + 0x1ff && setexpr blkcnt $blkcnt / 0x200
> + => mmc write $loadaddr 0x42 $blkcnt
> +
> + => tftp $loadaddr u-boot.itb
> + => setexpr blkcnt $filesize + 0x1ff && setexpr blkcnt $blkcnt / 0x200
> + => mmc write $loadaddr 0x300 $blkcnt
> diff --git a/doc/board/index.rst b/doc/board/index.rst
> index 9e9097889161..5c5420f3d75a 100644
> --- a/doc/board/index.rst
> +++ b/doc/board/index.rst
> @@ -11,6 +11,7 @@ Board-specific doc
> AndesTech/index
> amlogic/index
> atmel/index
> + compulab/index
> congatec/index
> coreboot/index
> emulation/index
> --
> 2.25.1
>
>
Re: [PATCH 1/2] imx8mm-cl-iot-gate: Do not build fip.bin by default
Hi Fabio,
Can we think of a way to keep this fip.bin feature? This is part of the
SystemReady IR certificate for this Compulab board. [1]
[1]
https://developer.arm.com/architectures/system-architectures/arm-systemready/ir
Yours,
Paul
On Fri, 13 Aug 2021 at 08:59, Fabio Estevam wrote:
> When trying to build the imx8mm-cl-iot-gate_defconfig target there is a
> build error due to the missing 'fip.bin'.
>
> To make the build process more consistent with other i.MX8M boards,
> do not build fip.bin by default.
>
> Signed-off-by: Fabio Estevam
> ---
> arch/arm/dts/imx8mm-cl-iot-gate-u-boot.dtsi | 14 +-
> 1 file changed, 1 insertion(+), 13 deletions(-)
>
> diff --git a/arch/arm/dts/imx8mm-cl-iot-gate-u-boot.dtsi
> b/arch/arm/dts/imx8mm-cl-iot-gate-u-boot.dtsi
> index 3226a244a97e..00927c157449 100644
> --- a/arch/arm/dts/imx8mm-cl-iot-gate-u-boot.dtsi
> +++ b/arch/arm/dts/imx8mm-cl-iot-gate-u-boot.dtsi
> @@ -217,18 +217,6 @@
> };
> };
>
> - fip {
> - description = "Trusted Firmware
> FIP";
> - type = "firmware";
> - arch = "arm64";
> - compression = "none";
> - load = <0x4031>;
> -
> - fip_blob: blob-ext{
> - filename = "fip.bin";
> - };
> - };
> -
> fdt {
> description = "NAME";
> type = "flat_dt";
> @@ -246,7 +234,7 @@
> conf {
> description = "NAME";
> firmware = "uboot";
> - loadables = "atf", "fip";
> + loadables = "atf";
> fdt = "fdt";
> };
> };
> --
> 2.25.1
>
>
Re: Building U-Boot for Compulab's imx8mm-cl-iot-gate board
Hi Fabio,
It might work. But why? I mean the imx8mm-evk has already switched to
binman on the mainline.
So we should do the same. If you can't get into U-boot prompt using binman
I can give you more detailed information.
Yours,
Paul
On Wed, 11 Aug 2021 at 07:13, Fabio Estevam wrote:
> Hi Paul,
>
> Thanks for your response.
>
> On Thu, Jul 1, 2021 at 6:38 PM Paul Liu wrote:
> >
> > Hi Fabio,
> >
> > We have dfu_alt_info set. So that we can capsule update from UEFI.
> > First, "setenv -e -nv -bs -rt -v OsIndications =0x04"
> > And then we can "efidebug capsule update -v ${loadaddr}".
> >
> > To make the capsule binary, we need to create a capsule1.itb with the
> following content:
> > /dts-v1/;
> >
> > / {
> >description = "Automatic U-Boot environment update";
> >#address-cells = <2>;
> >
> >images {
> >flash-bin {
> >description = "U-Boot binary on SPI Flash";
> >data = /incbin/("flash.bin");
> >compression = "none";
> >type = "firmware";
> >arch = "arm64";
> >load = <0>;
> >hash-1 {
> >algo = "sha1";
> >};
> >};
> >u-boot-itb {
> >description = "U-Boot binary";
> >data = /incbin/("u-boot.itb");
> >compression = "none";
> >type = "firmware";
> > arch = "arm64";
> >load = <0>;
> >hash-1 {
> >algo = "sha1";
> >};
> >};
> >};
> > };
> >
> > And then "./tools/mkimage -f capsule1.its capsule1.itb"
> > "./tools/mkeficapsule --fit capsule1.itb --index 1 capsule1.bin"
> >
> > And we can tftp the capsule1.bin to ${loadaddr} and then use the capsule
> update.
>
> In my case, I have the original U-Boot 2020.04 version from Compulab
> on the IoT Gateway board.
>
> Would it be possible to run a patch like this
> https://pastebin.com/raw/Rq1Yv6ka
>
> And then just load flash.bin via TFTP and flash it to offset 33K of the
> eMMC?
>
> Would that work?
>
> Thanks,
>
> Fabio Estevam
>
Re: Building U-Boot for Compulab's imx8mm-cl-iot-gate board
Hi Fabio,
We have dfu_alt_info set. So that we can capsule update from UEFI.
First, "setenv -e -nv -bs -rt -v OsIndications =0x04"
And then we can "efidebug capsule update -v ${loadaddr}".
To make the capsule binary, we need to create a capsule1.itb with the
following content:
/dts-v1/;
/ {
description = "Automatic U-Boot environment update";
#address-cells = <2>;
images {
flash-bin {
description = "U-Boot binary on SPI Flash";
data = /incbin/("flash.bin");
compression = "none";
type = "firmware";
arch = "arm64";
load = <0>;
hash-1 {
algo = "sha1";
};
};
u-boot-itb {
description = "U-Boot binary";
data = /incbin/("u-boot.itb");
compression = "none";
type = "firmware";
arch = "arm64";
load = <0>;
hash-1 {
algo = "sha1";
};
};
};
};
And then "./tools/mkimage -f capsule1.its capsule1.itb"
"./tools/mkeficapsule --fit capsule1.itb --index 1 capsule1.bin"
And we can tftp the capsule1.bin to ${loadaddr} and then use the capsule
update.
Yours,
Paul
On Fri, 2 Jul 2021 at 00:39, Fabio Estevam wrote:
> Hi Paul,
>
> On Thu, Jul 1, 2021 at 12:45 PM Paul Liu wrote:
>
> > Hi Fabio,
> >
> > Yes. It is able to not provide the fip,bin.
> > If you use bl31.bin as bl31.bin then fip.bin can be empty.
> > If you use bl2.bin as bl31.bin then you have to have the fip.
> >
> > This depends on how TF-A are being built.
> > If you build TF-A without NEED_BL2=yes. Then you don't need the fip.bin.
> > If you build TF-A with NEED_BL2=yes. Then FIP is needed. And you have to
> use bl2.bin generated by TF-A and rename it to bl31.bin. I think maybe I
> can fix the README. If you can do that then that's perfect because my
> English is always not very good. So that means I sometimes need more review
> on my English sentences.
>
> Thanks for the clarification.
>
> I can work on creating a README file for this board after I manage to boot
> it.
>
> What is the process of flashing the flash.bin and u-boot.itb binaries
> to the eMMC?
>
> Do you use the uuu tool? If so, what is the uuu_script script that you
> use?
>
> Thanks,
>
> Fabio Estevam
>
Re: Building U-Boot for Compulab's imx8mm-cl-iot-gate board
Hi Fabio,
Yes. It is able to not provide the fip,bin.
If you use bl31.bin as bl31.bin then fip.bin can be empty.
If you use bl2.bin as bl31.bin then you have to have the fip.
This depends on how TF-A are being built.
If you build TF-A without NEED_BL2=yes. Then you don't need the fip.bin.
If you build TF-A with NEED_BL2=yes. Then FIP is needed. And you have to
use bl2.bin generated by TF-A and rename it to bl31.bin. I think maybe I
can fix the README. If you can do that then that's perfect because my
English is always not very good. So that means I sometimes need more review
on my English sentences.
Yours,
Paul
On Thu, 1 Jul 2021 at 05:43, Fabio Estevam wrote:
> Hi Paul,
>
> I am trying to build U-Boot 2021.07-rc5 for the
> imx8mm-cl-iot-gate_defconfig target and I am following the imx8mm-evk
> readme: doc/board/freescale/imx8mm_evk.rst for the build instructions
> and this is the output:
>
> make[1]: Nothing to be done for 'SPL'.
> BINMAN all
> Image 'main-section' is missing external blobs and is non-functional:
> blob-ext
>
> Some images are invalid
>
> This happens because I did not provide the fip.bin binary.
>
> Is it OK if I remove the fip.bin entry like this? Would the board still
> boot?
>
> --- a/arch/arm/dts/imx8mm-cl-iot-gate-u-boot.dtsi
> +++ b/arch/arm/dts/imx8mm-cl-iot-gate-u-boot.dtsi
> @@ -217,18 +217,6 @@
> };
> };
>
> - fip {
> - description = "Trusted Firmware
> FIP";
> - type = "firmware";
> - arch = "arm64";
> - compression = "none";
> - load = <0x4031>;
> -
> - fip_blob: blob-ext{
> - filename = "fip.bin";
> - };
> - };
> -
> fdt {
> description = "NAME";
> type = "flat_dt";
>
> Could you please let me know the process for generating fip.bin?
>
> It would be nice to have a doc/board/compulab/imx8mm-iot-gate.rst
> README file with these details. I can help with that but need your
> help to clarify the generation of fip.bin.
>
> Also, is it OK if I use the ATF firmware and LPDDR binaries version as
> specified in doc/board/freescale/imx8mm_evk.rst ?
>
> Thanks,
>
> Fabio Estevam
>
Re: [PATCH 1/2] power: regulator: add driver for ANATOP regulator
Hi Jaehoon,
Thanks for the review.
On Mon, 8 Mar 2021 at 07:03, Jaehoon Chung wrote:
> Dear Ying-Chun
>
> On 3/8/21 3:18 AM, Ying-Chun Liu wrote:
> > From: "Ying-Chun Liu (PaulLiu)"
> >
> > Anatop is an integrated regulator inside i.MX6 SoC.
> > There are 3 digital regulators which controls PU, CORE (ARM), and SOC.
> > And 3 analog regulators which controls 1P1, 2P5, 3P0 (USB).
> > This patch adds the Anatop regulator driver.
> >
> > Signed-off-by: Ying-Chun Liu (PaulLiu)
> > ---
> > drivers/power/regulator/Kconfig| 10 +
> > drivers/power/regulator/Makefile | 1 +
> > drivers/power/regulator/anatop_regulator.c | 289 +
> > 3 files changed, 300 insertions(+)
> > create mode 100644 drivers/power/regulator/anatop_regulator.c
> >
> > diff --git a/drivers/power/regulator/Kconfig
> b/drivers/power/regulator/Kconfig
> > index fbbea18c7d..1cd1f3f5ed 100644
> > --- a/drivers/power/regulator/Kconfig
> > +++ b/drivers/power/regulator/Kconfig
> > @@ -312,6 +312,16 @@ config DM_REGULATOR_STPMIC1
> > by the PMIC device. This driver is controlled by a device tree node
> > which includes voltage limits.
> >
> > +config DM_REGULATOR_ANATOP
> > + bool "Enable driver for ANATOP regulators"
> > + depends on DM_REGULATOR
> > + select REGMAP
> > + select SYSCON
> > + help
> > + Enable support for the Freescale i.MX on-chip ANATOP LDOs
> > + regulators. It is recommended that this option be enabled on
> > + i.MX6 platform.
> > +
> > config SPL_DM_REGULATOR_STPMIC1
> > bool "Enable driver for STPMIC1 regulators in SPL"
> > depends on SPL_DM_REGULATOR && PMIC_STPMIC1
> > diff --git a/drivers/power/regulator/Makefile
> b/drivers/power/regulator/Makefile
> > index 9d58112dcb..e7198da911 100644
> > --- a/drivers/power/regulator/Makefile
> > +++ b/drivers/power/regulator/Makefile
> > @@ -30,3 +30,4 @@ obj-$(CONFIG_DM_REGULATOR_TPS65910) +=
> tps65910_regulator.o
> > obj-$(CONFIG_DM_REGULATOR_TPS62360) += tps62360_regulator.o
> > obj-$(CONFIG_$(SPL_)DM_REGULATOR_STPMIC1) += stpmic1.o
> > obj-$(CONFIG_DM_REGULATOR_TPS65941) += tps65941_regulator.o
> > +obj-$(CONFIG_$(SPL_)DM_REGULATOR_ANATOP) += anatop_regulator.o
> > diff --git a/drivers/power/regulator/anatop_regulator.c
> b/drivers/power/regulator/anatop_regulator.c
> > new file mode 100644
> > index 00..2bb5cdbac5
> > --- /dev/null
> > +++ b/drivers/power/regulator/anatop_regulator.c
> > @@ -0,0 +1,289 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +//
> > +// Copyright (C) 2011 Freescale Semiconductor, Inc. All Rights Reserved.
> > +// Copyright (C) 2021 Linaro
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
>
> Well, i think that it can be removed more than now.
>
>
Will fix it in v2.
> > +
> > +#define LDO_RAMP_UP_UNIT_IN_CYCLES 64 /* 64 cycles per step */
> > +#define LDO_RAMP_UP_FREQ_IN_MHZ 24 /* cycle based on 24M OSC */
> > +
> > +#define LDO_POWER_GATE 0x00
> > +#define LDO_FET_FULL_ON 0x1f
> > +
> > +struct anatop_regulator {
> > + const char *name;
> > + u32 control_reg;
> > + u32 vol_bit_shift;
> > + u32 vol_bit_width;
> > + u32 min_bit_val;
> > + u32 min_voltage;
> > + u32 max_voltage;
> > + u32 delay_reg;
> > + u32 delay_bit_shift;
> > + u32 delay_bit_width;
> > +};
> > +
> > +static u32 anatop_get_bits(struct udevice *dev, u32 addr, int bit_shift,
> > +int bit_width)
> > +{
> > + struct udevice *syscon;
> > + struct regmap *regmap;
> > + int err;
> > + u32 val, mask;
> > +
> > + syscon = dev_get_parent(dev);
> > + if (!syscon) {
> > + dev_err(dev, "%s: unable to find syscon device\n",
> __func__);
> > + return err;
> > + }
> > +
> > + regmap = syscon_get_regmap(syscon);
> > + if (IS_ERR(regmap)) {
> > + dev_err(dev, "%s: unable to find regmap (%ld)\n", __func__,
> > + PTR_ERR(regmap));
> > + return PTR_ERR(regmap);
> > + }
> > +
> > + if (bit_width == 32)
>
> Use macro instead of 32, plz.
>
>
Will fix it in v2.
> > + mask = ~0;
> > + else
> > + mask = (1 << bit_width) - 1;
> > +
> > + err = regmap_read(regmap, addr, );
> > + if (err)
> > + return err;
> > +
> > + val = (val >> bit_shift) & mask;
> > +
> > + return val;
> > +}
> > +
> > +void anatop_set_bits(struct udevice *dev, u32 addr, int bit_shift,
> > + int bit_width, u32 data)
>
> static?
> doesn't it need to return int type?
> If there is a somehting failed, it seems that it needs to pass the error
> number.
> (get_bits is returend to error..but set_bits doesn't return. It's strange.)
>
>
Will fix it in v2.
