Re: Fit Signature booting without public key
Hi Tom, On 11:30-20230516, Tom Rini wrote: > On Tue, May 16, 2023 at 12:11:24PM +0530, Manorit Chawdhry wrote: > > > Hi All, > > > > I recently came upon a discussion that had happened a while back [0]. > > I want to continue the discussion as I believe the issue still persists > > and the checks around fit signature booting are still the same, that > > allows booting the fit without changing the uboot dtb. > > > > Allowing the signed fit image without this seems to be a bypass that is > > available and should not be allowed without any gate to it for people > > who'd like to enforce these signing checks. Let me know if there is a > > config already available for it and if not, are there any plans to > > enable such a config in future. Would like to hear your opinions on > > this as I believe this should be fixed as soon as possible. > > > > [0]: > > https://u-boot.denx.narkive.com/dEClg9dW/signed-fit-image-boots-without-public-key > > Yes, can you please reproduce the issue in question on the current tree, > with a supported platform and provide the defconfig and steps you used > for this issue? Thanks. > > -- I've created a branch with some custom patches to make the fitimage booting currently, please try with the branch and the fitimage that are also committed [0]. The devices that I've tested this with is j721e-hs-evm, the defconfig to use for the builds are j721e_evm_r5_defconfig and j721e_evm_a72_defconfig. Although not synced up with the latest changes but for reference the SDK documentation can help if required [1]. Attached the logs for reference with the signed fitimage and an unsigned uboot without any modifications[2]. [0]: https://github.com/manorit2001/u-boot/tree/fit-image-poc [1]: https://software-dl.ti.com/jacinto7/esd/processor-sdk-linux-jacinto7/08_06_00_11/exports/docs/linux/Foundational_Components/U-Boot/UG-General-Info.html [2]: https://gist.github.com/manorit2001/3c49cfc19bf937783efb75fd4cddc58f Regards, Manorit > Tom
Re: [PATCH v2 3/6] net: introduce TCP/IP6 support
On 2023/5/11 00:59, Dmitrii Merkurev wrote:
Add TCP/IP6 related headers and reuse refactored TCP/IP
implementation
Signed-off-by: Dmitrii Merkurev
Cc: Ying-Chun Liu (PaulLiu)
Cc: Simon Glass
Сс: Joe Hershberger
Сс: Ramon Fried
---
include/net/tcp6.h | 106 +
include/net6.h | 14 ++
net/Makefile | 1 +
net/net.c | 6 +++
net/net6.c | 72 +-
net/tcp6.c | 99 ++
6 files changed, 288 insertions(+), 10 deletions(-)
create mode 100644 include/net/tcp6.h
create mode 100644 net/tcp6.c
diff --git a/include/net/tcp6.h b/include/net/tcp6.h
new file mode 100644
index 00..3db125ecc5
--- /dev/null
+++ b/include/net/tcp6.h
@@ -0,0 +1,106 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright (C) 2022 The Android Open Source Project
+ */
+
+#ifndef __TCP6_H__
+#define __TCP6_H__
+
+#if defined(CONFIG_PROT_TCP)
+
+#include
+#include
+
+/**
+ * typedef rxhand_tcp6_f() - An incoming TCP IPv6 packet handler.
+ * @pkt: pointer to the application packet
+ * @dport: destination TCP port
+ * @sip: source IP6 address
+ * @sport: source TCP port
+ * @tcp_seq_num: TCP sequential number
+ * @tcp_ack_num: TCP acknowledgment number
+ * @action: TCP packet type (SYN, ACK, FIN, etc)
+ */
+typedef void rxhand_tcp6_f(uchar *pkt, u16 dport,
+ struct in6_addr sip, u16 sport,
+ u32 tcp_seq_num, u32 tcp_ack_num,
+ u8 action, unsigned int len);
+
+/**
+ * struct ip6_tcp_hdr_o - IP6 + TCP header + TCP options
+ * @ip_hdr: IP6 + TCP header
+ * @tcp_hdr: TCP header
+ * @tcp_o: TCP options
+ * @end: end of IP6/TCP header
+ */
+struct ip6_tcp_hdr_o {
+ struct ip6_hdrip_hdr;
+ struct tcp_hdrtcp_hdr;
+ struct tcp_hdr_o tcp_o;
+ u8 end;
+} __packed;
+
+#define IP6_TCP_O_SIZE (sizeof(struct ip6_tcp_hdr_o))
+
+/**
+ * struct ip6_tcp_hdr_s - IP6 + TCP header + TCP options
+ * @ip_hdr: IP6 + TCP header
+ * @tcp_hdr: TCP header
+ * @t_opt: TCP Timestamp Option
+ * @sack_v: TCP SACK Option
+ * @end: end of options
+ */
+struct ip6_tcp_hdr_s {
+ struct ip6_hdrip_hdr;
+ struct tcp_hdrtcp_hdr;
+ struct tcp_t_opt t_opt;
+ struct tcp_sack_v sack_v;
+ u8 end;
+} __packed;
+
+#define IP6_TCP_SACK_SIZE (sizeof(struct ip6_tcp_hdr_s))
+
+/**
+ * union tcp6_build_pkt - union for building TCP/IP6 packet.
+ * @ip: IP6 and TCP header plus TCP options
+ * @sack: IP6 and TCP header plus SACK options
+ * @raw: buffer
+ */
+union tcp6_build_pkt {
+ struct ip6_tcp_hdr_o ip;
+ struct ip6_tcp_hdr_s sack;
+ uchar raw[1600];
+} __packed;
+
+/**
+ * net_set_tcp6_handler6() - set application TCP6 packet handler
+ * @param f pointer to callback function
+ */
+void net_set_tcp_handler6(rxhand_tcp6_f *f);
+
+/**
+ * net_set_tcp_header6() - set
+ * @pkt: pointer to IP6/TCP headers
+ * @dport: destination TCP port
+ * @sport: source TCP port
+ * @payload_len: payload length
+ * @action: TCP packet type (SYN, ACK, FIN, etc)
+ * @tcp_seq_num: TCP sequential number
+ * @tcp_ack_num: TCP acknowledgment number
+ *
+ * returns TCP header size
+ */
+int net_set_tcp_header6(uchar *pkt, u16 dport, u16 sport, int payload_len,
+ u8 action, u32 tcp_seq_num, u32 tcp_ack_num);
+
+void net_set_tcp_handler6(rxhand_tcp6_f *f);
+
+/**
+ * rxhand_tcp6() - handle incoming IP6 TCP packet
+ * @param b pointer to IP6/TCP packet builder struct
+ * @param len full packet length
+ */
+void rxhand_tcp6(union tcp6_build_pkt *b, unsigned int len);
+
+#endif // CONFIG_PROT_TCP
+#endif // __TCP6_H__
diff --git a/include/net6.h b/include/net6.h
index beafc05338..fa926f07ac 100644
--- a/include/net6.h
+++ b/include/net6.h
@@ -344,6 +344,20 @@ int ip6_add_hdr(uchar *xip, struct in6_addr *src, struct
in6_addr *dest,
int net_send_udp_packet6(uchar *ether, struct in6_addr *dest, int dport,
int sport, int len);
+/**
+ * net_send_tcp_packet6() - Make up TCP packet and send it
+ *
+ * @payload_len: TCP payload length
+ * @dport: destination port
+ * @sport: source port
+ * @action: TCP flag (SYN, ACL, PUSH, etc)
+ * @tcp_seq_num: TCP sequence number
+ * @tcp_ack_num: TCP ackno
+ * Return: 0 if send successfully, -1 otherwise
+ */
+int net_send_tcp_packet6(int payload_len, int dport, int sport, u8 action,
+u32 tcp_seq_num, u32 tcp_ack_num);
+
/**
* net_ip6_handler() - Handle IPv6 packet
*
diff --git a/net/Makefile b/net/Makefile
index 3e2d061338..002b0f68a2 100644
--- a/net/Makefile
+++ b/net/Makefile
@@ -32,6 +32,7 @@ obj-$(CONFIG_TCP_FUNCTION_FASTBOOT) += fastboot_tcp.o
obj-$(CONFIG_CMD_WOL) += wol.o
obj-$(CONFIG_PROT_UDP) += udp.o
obj-$(CONFIG_PROT_TCP) += tcp.o
+obj-$(CONFIG_IPV6) += tcp6.o
obj-$(CONFIG_CMD_WGET) += wget.o
# Disable
Re: [PATCH 3/3] arm: dts: imx8mp: Sync with Linux 6.3
Hi Tim,
On Fri, May 19, 2023 at 8:00 PM Tim Harvey wrote:
> Fabio,
>
> There's more to be done here also. With this patch, and with the
> spba-bus added to u-boot.dtsi, if you try to enable usb (usb start)
> you get:
> starting USB...
> Bus usb@3820:
> Enable clock-controller@3038 failed
> probe failed, error -2
> No working controllers found
Does this help?
--- a/drivers/clk/imx/clk-imx8mp.c
+++ b/drivers/clk/imx/clk-imx8mp.c
@@ -337,8 +337,8 @@ static int imx8mp_clk_probe(struct udevice *dev)
clk_dm(IMX8MP_CLK_UART2_ROOT, imx_clk_gate4("uart2_root_clk",
"uart2", base + 0x44a0, 0));
clk_dm(IMX8MP_CLK_UART3_ROOT, imx_clk_gate4("uart3_root_clk",
"uart3", base + 0x44b0, 0));
clk_dm(IMX8MP_CLK_UART4_ROOT, imx_clk_gate4("uart4_root_clk",
"uart4", base + 0x44c0, 0));
- clk_dm(IMX8MP_CLK_USB_ROOT, imx_clk_gate4("usb_root_clk",
"usb_core_ref", base + 0x44d0, 0));
- clk_dm(IMX8MP_CLK_USB_PHY_ROOT,
imx_clk_gate4("usb_phy_root_clk", "usb_phy_ref", base + 0x44f0, 0));
+ clk_dm(IMX8MP_CLK_USB_ROOT, imx_clk_gate4("usb_root_clk",
"hsio_axi", base + 0x44d0, 0));
+ clk_dm(IMX8MP_CLK_USB_SUSP, imx_clk_gate4("usb_suspend_clk",
"osc_32k", base + 0x44d0, 0));
clk_dm(IMX8MP_CLK_USDHC1_ROOT,
imx_clk_gate4("usdhc1_root_clk", "usdhc1", base + 0x4510, 0));
clk_dm(IMX8MP_CLK_USDHC2_ROOT,
imx_clk_gate4("usdhc2_root_clk", "usdhc2", base + 0x4520, 0));
clk_dm(IMX8MP_CLK_WDOG1_ROOT, imx_clk_gate4("wdog1_root_clk",
"wdog", base + 0x4530, 0));
Re: [PATCH v2] imx: imx8mp: Add support for Polyhex Debix Model A SBC
On 5/24/2023 3:21 AM, Gilles Talis wrote: Add support for the Polyhex Debix Model A SBC board. It is an industrial grade single board computer based on NXP's i.MX 8M Plus. Currently supported interfaces are: - Serial console - Micro SD - eQOS and FEC Ethernet imx8mp-debix-model-a.dts is taken from Linux 6.3. Signed-off-by: Gilles Talis Reviewed-by: Peng Fan
Re: [PATCH v2 2/6] net: prepare existing TCP stack to be reused by IP6
On 2023/5/11 00:59, Dmitrii Merkurev wrote:
Changes:
1. Separate reusable part from net_set_tcp_header to
net_set_tcp_header_common
2. Make TCP signatures reusable by receiving particular
IP agnostic TCP headers
3. Extract net_send_ip_packet6 from net_send_udp_packet6
to reuse the code
4. Expose TCP state machine related functions
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 | 109 +--
net/net.c | 18 ++-
net/net6.c| 78 ---
net/tcp.c | 337 --
4 files changed, 372 insertions(+), 170 deletions(-)
diff --git a/include/net/tcp.h b/include/net/tcp.h
index 93ed728dfe..344b4be2a4 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -8,10 +8,20 @@
#ifndef __TCP_H__
#define __TCP_H__
+#include
+
#define TCP_ACTIVITY 127 /* Number of packets received */
/* before console progress mark */
+/*
+ * TCP lengths are stored as a rounded up number of 32 bit words.
+ * Add 3 to length round up, rounded, then divided into the
+ * length in 32 bit words.
+ */
+#define LEN_B_TO_DW(x) ((x) >> 2)
+#define ROUND_TCPHDR_LEN(x) (LEN_B_TO_DW((x) + 3))
#define GET_TCP_HDR_LEN_IN_BYTES(x) ((x) >> 2)
+#define SHIFT_TO_TCPHDRLEN_FIELD(x) ((x) << 4)
/**
* struct tcp_hdr - TCP header
@@ -24,7 +34,7 @@
* @tcp_win: TCP windows size
* @tcp_xsum: Checksum
* @tcp_ugr: Pointer to urgent data
-*/
+ */
struct tcp_hdr {
u16 tcp_src;
u16 tcp_dst;
@@ -163,18 +173,14 @@ struct tcp_t_opt {
*/
/**
- * struct ip_tcp_hdr_o - IP + TCP header + TCP options
- * @ip_hdr: IP + TCP header
- * @tcp_hdr: TCP header
+ * struct tcp_hdr_o - TCP options
* @mss: TCP MSS Option
* @scale: TCP Windows Scale Option
* @sack_p: TCP Sack-Permitted Option
* @t_opt: TCP Timestamp Option
* @end: end of options
*/
-struct ip_tcp_hdr_o {
- struct ip_hdr ip_hdr;
- struct tcp_hdrtcp_hdr;
+struct tcp_hdr_o {
struct tcp_mssmss;
struct tcp_scale scale;
struct tcp_sack_p sack_p;
@@ -182,6 +188,22 @@ struct ip_tcp_hdr_o {
u8 end;
} __packed;
+#define TCP_O_SIZE (sizeof(struct tcp_hdr_o))
+
+/**
+ * struct ip_tcp_hdr_o - IP + TCP header + TCP options
+ * @ip_hdr: IP + TCP header
+ * @tcp_hdr: TCP header
+ * @tcp_o: TCP options
+ * @end: end of IP/TCP header
+ */
+struct ip_tcp_hdr_o {
+ struct ip_hdr ip_hdr;
+ struct tcp_hdrtcp_hdr;
+ struct tcp_hdr_o tcp_o;
+ u8 end;
+} __packed;
+
#define IP_TCP_O_SIZE (sizeof(struct ip_tcp_hdr_o))
/**
@@ -209,7 +231,7 @@ struct ip_tcp_hdr_s {
/**
* struct pseudo_hdr - Pseudo Header
- * @padding: pseudo hdr size = ip_tcp hdr size
+ * @padding: pseudo hdr size = ip hdr size
* @p_src: Source IP address
* @p_dst: Destination IP address
* @rsvd: reserved
@@ -236,7 +258,6 @@ struct pseudo_hdr {
*
* Build Pseudo header in packed buffer
* first, calculate TCP checksum, then build IP header in packed buffer.
- *
*/
union tcp_build_pkt {
struct pseudo_hdr ph;
@@ -269,9 +290,77 @@ enum tcp_state {
enum tcp_state tcp_get_tcp_state(void);
void tcp_set_tcp_state(enum tcp_state new_state);
-int tcp_set_tcp_header(uchar *pkt, int dport, int sport, int payload_len,
+
+/**
+ * net_set_tcp_header_common() - IP version agnostic TCP header building
implementation
+ *
+ * @tcp_hdr: pointer to TCP header struct
+ * @tcp_o: pointer to TCP options header struct
+ * @sack_t_opt: pointer to TCP sack options header struct
+ * @sack_v: pointer to TCP sack header struct
+ * @dport: destination TCP port
+ * @sport: source TCP port
+ * @payload_len: TCP payload len
+ * @action: TCP action (SYN, ACK, FIN, etc)
+ * @tcp_seq_num: TCP sequential number
+ * @tcp_ack_num: TCP acknowledgment number
+ *
+ * returns TCP header
+ */
+int net_set_tcp_header_common(struct tcp_hdr *tcp_hdr, struct tcp_hdr_o *tcp_o,
+ struct tcp_t_opt *sack_t_opt, struct tcp_sack_v
*sack_v,
+ u16 dport, u16 sport, int payload_len, u8 action,
+ u32 tcp_seq_num, u32 tcp_ack_num);
+
+/**
+ * net_set_tcp_header() - IPv4 TCP header bulding implementation
+ *
+ * @pkt: pointer to the IP header
+ * @dport: destination TCP port
+ * @sport: source TCP port
+ * @payload_len: TCP payload len
+ * @action: TCP action (SYN, ACK, FIN, etc)
+ * @tcp_seq_num: TCP sequential number
+ * @tcp_ack_num: TCP acknowledgment number
+ *
+ * returns TCP header
+ */
+int net_set_tcp_header(uchar *pkt, u16 dport, u16 sport, int payload_len,
u8 action, u32 tcp_seq_num, u32 tcp_ack_num);
+/**
+ * tcp_parse_options() - parsing TCP options
+ *
+ *
Re: [PATCH v2 1/6] net: split IP_TCP header into separate IP/IP6 and TCP headers
Reviewed-by: Ying-Chun Liu (PaulLiu)
On 2023/5/11 00:59, 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 | 54
net/tcp.c | 70 +++
test/cmd/wget.c | 48 ++--
3 files changed, 85 insertions(+), 87 deletions(-)
diff --git a/include/net/tcp.h b/include/net/tcp.h
index c29d4ce24a..93ed728dfe 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_FIN 0x01/* 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,15 +186,17 @@ 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 tcp_t_opt t_opt;
- struct tcp_sack_v sack_v;
+ struct ip_hdr ip_hdr;
+ struct tcp_hdrtcp_hdr;
+ struct tcp_t_opt t_opt;
+ struct tcp_sack_v sack_v;
u8 end;
} __packed;
@@ -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 net_set_ack_options(union tcp_build_pkt *b)
b->sack.sack_v.hill[3].r = TCP_O_NOP;
}
- b->sack.hdr.tcp_hlen = SHIFT_TO_TCPHDRLEN_FIELD(ROUND_TCPHDR_LEN(TCP_HDR_SIZE +
+ b->sack.tcp_hdr.tcp_hlen =
SHIFT_TO_TCPHDRLEN_FIELD(ROUND_TCPHDR_LEN(TCP_HDR_SIZE +
TCP_TSOPT_SIZE +
tcp_lost.len));
Re: [lwip-devel] [RFC PATCH 0/5] LWIP stack integration
Hi Maxim, Tom, On 24.05.2023 16:05, Maxim Uvarov wrote: On Tue, 23 May 2023 at 03:23, Tom Rini wrote: On Mon, May 22, 2023 at 12:40:49PM -0400, Maxim Uvarov wrote: On Mon, 22 May 2023 at 10:20, Tom Rini wrote: On Mon, May 22, 2023 at 04:33:57PM +0300, Ilias Apalodimas wrote: Hi Maxim On Mon, 22 May 2023 at 12:01, Maxim Uvarov wrote: My measurements for binary after LTO looks like: U-boot WGET | LWIP WGET + ping | LWIP WGET| diff bytes| diff % 870728| 915000| 912560 | 41832| 4.8 I think you'll need to analyze that a bit more. First of all I don't think the '+ping' tab is useful. What is is trying to achieve? To show the difference of extra bytes if we add a ping app on top. - How was LWIP compiled? It has a really huge configuration. I tried to turn off everything off everything what can impact on size but still make http app work: #define LWIP_HAVE_LOOPIF0 #define LWIP_NETCONN0 #define LWIP_SOCKET 0 #define SO_REUSE0 #define LWIP_STATS 0 #define PPP_SUPPORT 0 Disabling loopback: #define LWIP_NETIF_LOOPBACK 0 can lower to 912288 bytes. And it's the same compilation option (optimization for size) as the main u-boot. I will do more experiments, but I think the goal is not to turn off everything. - Was ipv6 supported? No. I.e. when I sent results it was enabled on the compilation stage but not used. I just checked that size remains the same if IPv6 is not even compiled. - Can we strip it down even further? There is always room for optimization. I think I tried to turn off everything that is configurable with defines. I can play with disable IP reassembly and things like that or figure out which functions have more size and if it's possible to exclude them. In general please give as much information as you can with what we gain in functionality from LWIP with those extra bytes of code. The main idea is to reuse a maintainable IP stack outside of U-boot. LWIP can give a nice separation between IP stack code and network application code. I.e. application should not take care about any TCP details (SYN, ACK, retransmission, reassembly etc) and should open connection and use functions similar to recv() and send() to transfer data. Data means application data, no network packets. And LWIP allows us to do that. Because LWIP has an API similar to sockets, it has to be very easy to port a linux application to LWIP. Then you can test it with a tap device. Then copy sources to U-boot, add a small integration layer (cmd command to call), compile and use. So my suggestion was: - do not maintain new network stack code in the current U-boot. Use lwip sources as an external project. All bugs related to network stack go to lwip project first, then sync with U-boot. - maintain network apps code* or -- inside U-boot. Write our own code for application and maintain it inside U-boot. -- inside LWIP. Add examples to LWIP which are suitable for both U-boot and LWIP. * Let's define a U-boot network application as a cmd command. It might be ping, wget (http or https download), telnet, arp dns etc.. Let's consider the real use case, like HTTPS download client. We need to enable TLS connection, validate certificates, then do http download. Looking at the current code of wget command it's quite difficult to implement this due to the application having some protol level things. On the other side we can find embedTLS examples to do https download on sockets. If LWIP socket API is ported then the only thing you need to do is change socket() -> lwip_socket(), recv()->lwip_recv(), send()->lwip_send() and etc, even function names are similar. If LWIP socket API is not supported, then use callback API for recv() and send(), which are also easy. So yes we add extra bytes, but that will allow us to write more complex apps, use standard debug tools, use applications with very minimal integration changes, use help from the LWIP community to fix protocol bugs, etc.. Bunch of things already implemented there: - ipv6 - dhcp - snmp - igmp - dns - tcp and udp and raw. - loopback - netconn - socket - stats - ppp (I just followed configurable defines). And please make sure to disable the previous support, my guess fro that much growth is that you didn't. # CONFIG_PROT_TCP is not set # CONFIG_PROT_UDP is not set # CONFIG_UDP_CHECKSUM is not set # CONFIG_UDP_FUNCTION_FASTBOOT is not set # CONFIG_CMD_WGET is not set I think you need to step back and figure out a better way to measure the size change and growth. I am not interested in a path that long term means two networking stacks in U-Boot. I am not interested in massively growing the overall binary size for every platform. Given how much larger just TCP support is, that's strongly implying a huge growth for the older use cases too. But I
Re: [RFC PATCH 0/5] LWIP stack integration
On Tue, 23 May 2023 at 03:23, Tom Rini wrote: > On Mon, May 22, 2023 at 12:40:49PM -0400, Maxim Uvarov wrote: > > On Mon, 22 May 2023 at 10:20, Tom Rini wrote: > > > > > On Mon, May 22, 2023 at 04:33:57PM +0300, Ilias Apalodimas wrote: > > > > Hi Maxim > > > > > > > > On Mon, 22 May 2023 at 12:01, Maxim Uvarov > > > wrote: > > > > > > > > > > My measurements for binary after LTO looks like: > > > > > > > > > > U-boot WGET | LWIP WGET + ping | LWIP WGET| diff bytes| diff % > > > > > 870728| 915000| 912560 | > > > 41832| 4.8 > > > > > > > > > > > > I think you'll need to analyze that a bit more. First of all I don't > > > > think the '+ping' tab is useful. What is is trying to achieve? > > > > > > > To show the difference of extra bytes if we add a ping app on top. > > > > > > > > - How was LWIP compiled? > > > > > > > It has a really huge configuration. I tried to turn off everything off > > everything what can impact on size but still make http app work: > > #define LWIP_HAVE_LOOPIF0 > > #define LWIP_NETCONN0 > > #define LWIP_SOCKET 0 > > #define SO_REUSE0 > > #define LWIP_STATS 0 > > #define PPP_SUPPORT 0 > > > > Disabling loopback: > > #define LWIP_NETIF_LOOPBACK 0 > > can lower to 912288 bytes. > > > > And it's the same compilation option (optimization for size) as the main > > u-boot. I will do more experiments, but I think the goal is not to turn > off > > everything. > > > > > > > > - Was ipv6 supported? > > > > > > > No. I.e. when I sent results it was enabled on the compilation stage but > > not used. I just checked that size remains the same if IPv6 is not even > > compiled. > > > > > > > > - Can we strip it down even further? > > > > > > > > > > > There is always room for optimization. I think I tried to turn off > > everything that is configurable with defines. I can play with disable IP > > reassembly and things like that or figure out which functions have more > > size and if it's possible to exclude them. > > > > > > > > In general please give as much information as you can with what we > > > > gain in functionality from LWIP with those extra bytes of code. > > > > > > > > The main idea is to reuse a maintainable IP stack outside of U-boot. > LWIP > > can give a nice separation between IP stack code and network application > > code. I.e. application should not take care about any TCP details (SYN, > > ACK, retransmission, reassembly etc) and should open connection and use > > functions similar to recv() and send() to transfer data. Data means > > application data, no network packets. And LWIP allows > > us to do that. > > Because LWIP has an API similar to sockets, it has to be very easy to > port > > a linux application to LWIP. Then you can test it with a tap device. Then > > copy sources to U-boot, add a small integration layer (cmd command to > > call), compile and use. > > > > So my suggestion was: > > - do not maintain new network stack code in the current U-boot. Use lwip > > sources as an external project. All bugs related to network stack go to > > lwip project first, then sync with U-boot. > > - maintain network apps code* or > > -- inside U-boot. Write our own code for application and maintain it > > inside U-boot. > > -- inside LWIP. Add examples to LWIP which are suitable for both > U-boot > > and LWIP. > > > > * Let's define a U-boot network application as a cmd command. It might be > > ping, wget (http or https download), telnet, arp dns etc.. > > > > Let's consider the real use case, like HTTPS download client. We need to > > enable TLS connection, validate certificates, then do http download. > > Looking at the current code of wget command it's quite difficult to > > implement this due to the application having some protol level things. On > > the other side we can find embedTLS examples to do https download on > > sockets. If LWIP socket API is ported then the only thing you need to do > is > > change socket() -> lwip_socket(), recv()->lwip_recv(), > send()->lwip_send() > > and etc, even function names are similar. If LWIP socket API is not > > supported, then use callback API for recv() and send(), which are also > > easy. > > > > So yes we add extra bytes, but that will allow us to write more complex > > apps, use standard debug tools, use applications with very minimal > > integration changes, use help from the LWIP community to fix protocol > bugs, > > etc.. > > Bunch of things already implemented there: > > - ipv6 > > - dhcp > > - snmp > > - igmp > > - dns > > - tcp and udp and raw. > > - loopback > > - netconn > > - socket > > - stats > > - ppp > > (I just followed configurable defines). > > > > > > And please make sure to disable the previous support, my guess fro that > > > much growth is that you didn't. > > > > > > > # CONFIG_PROT_TCP is not set > > # CONFIG_PROT_UDP is not set > >
Re: [PATCH v4 1/7] dt-bindings: clock: Add StarFive JH7110 PLL clock generator
On 2023/5/23 19:28, Conor Dooley wrote:
> On Tue, May 23, 2023 at 01:10:06PM +0200, Torsten Duwe wrote:
>> On Tue, 23 May 2023 09:28:39 +0100
>> Conor Dooley wrote:
>>
>> > On Tue, May 23, 2023 at 10:56:43AM +0800, Xingyu Wu wrote:
>> > > On 2023/5/19 22:16, Conor Dooley wrote:
>> > > > On Fri, May 19, 2023 at 03:57:33PM +0200, Torsten Duwe wrote:
>> > > >> On Fri, May 12, 2023 at 10:20:30AM +0800, Xingyu Wu wrote:
>> > > >> [...]
>>
>> > > >> > +/* PLL clocks */
>> > > >> > +#define JH7110_CLK_PLL0_OUT0
>> > > >> > +#define JH7110_CLK_PLL1_OUT1
>> > > >> > +#define JH7110_CLK_PLL2_OUT2
>> > > >>
>> > > >> In U-Boot commit 58c9c60b Yanhong Wang added:
>> > > >>
>> > > >> +
>> > > >> +#define JH7110_SYSCLK_PLL0_OUT 190
>> > > >> +#define JH7110_SYSCLK_PLL1_OUT 191
>> > > >> +#define JH7110_SYSCLK_PLL2_OUT 192
>> > > >> +
>> > > >> +#define JH7110_SYSCLK_END193
>> [...]
>> > > > Ohh, that's not good.. If you pass the U-Boot dtb to Linux it
>> > > > won't understand the numbering. The headers are part of the
>> > > > dt-binding :/
>>
>> In fact, the clock index >= 190 makes linux hang on boot, waiting with
>> EPROBE_DEFER for every device's clock, because the sysclk driver errors
>> out with EINVAL (jh7110_sysclk_get()).
>
> Yup, that's about what I expected to happen.
>
>> > > Because PLL driver is separated from SYSCRG drivers in Linux, the
>> > > numbering starts from 0. But in Uboot, the PLL driver is included
>> > > in the SYSCRG driver, and the number follows the SYSCRG.
>> >
>> > Unfortunately, how you choose to construct your drivers has nothing to
>> > do with this.
>> > These defines/numbers appear in the dts and are part of the DT ABI.
>> > The same dts is supposed to work for Linux & U-Boot.
>>
>> The JH7110 has 6 blocks of 64k iomem in that functional area:
>> {SYS,STG,AON} x {CRG,SYSCON}. None of these has 190 clocks.
>> The good news: the current DTS, as proposed here and in U-Boot master,
>> provides nodes for all 6 entities. The bad news is that the clock
>> assignments to those nodes and their numbering is messed up.
>>
>> AFAICT PLL{0,1,2} _are_ generated in SYS_SYSCON and thus U-Boot gets it
>> wrong, in addition to the erroneous DTS.
>
> The numbers are kinda hocus-pocus anyway, they are just made up since the
> clock numbering usually isn't something with a nice TRM to go and
> reference (unlike interrupts which usually are documented in that way).
> It is very helpful to make them aligned some register/bit positions or,
> but that is not required.
> IOW U-Boot is not wrong per se to use 190 instead of 0, but it is wrong
> to have different numbers in both places.
>
> It sounds like you're saying that (and I have not looked) the U-Boot dts
> actually has structural difference w.r.t. what provides which clock?
> If so, that'll need to be fixed independently of the numbering problem.
>
> Otherwise Xingyu & Yanhong should coordinate on which is the "correct"
> way of doing things & do it in both places.
>
Oh, unfortunately, the 7110 can not support to mix the uboot dtb and linux dtb
up.
If boot the Linux and should use the linux dtb instead of the uboot dtb.
Because all clock ids and reset ids in Linux and Uboot are different include
PLL, and some modules can work in Linux but not in uboot.
I suggest to boot Linux with its own linux dtb.
Best regards,
Xingyu Wu
Re: [RFC PATCH v1 2/3] spi: sunxi: Add support for R329/D1/R528/T113 SPI controller
Hi Sam, Thanks for testing! > By any chance do you happen to know when in sunxi history the SPI > controller grew QuadSPI/DualSPI support? Unfortunately I don't know the history of Allwinner's SoCs that well :) > I might be interested in taking a stab at supporting them. Oh, that will be great
Re: [PATCH v4 1/7] dt-bindings: clock: Add StarFive JH7110 PLL clock generator
On Wed, May 24, 2023 at 05:00:02PM +0800, Xingyu Wu wrote:
> On 2023/5/23 19:28, Conor Dooley wrote:
> > On Tue, May 23, 2023 at 01:10:06PM +0200, Torsten Duwe wrote:
> >> On Tue, 23 May 2023 09:28:39 +0100
> >> Conor Dooley wrote:
> >>
> >> > On Tue, May 23, 2023 at 10:56:43AM +0800, Xingyu Wu wrote:
> >> > > On 2023/5/19 22:16, Conor Dooley wrote:
> >> > > > On Fri, May 19, 2023 at 03:57:33PM +0200, Torsten Duwe wrote:
> >> > > >> On Fri, May 12, 2023 at 10:20:30AM +0800, Xingyu Wu wrote:
> >> > > >> [...]
> >>
> >> > > >> > +/* PLL clocks */
> >> > > >> > +#define JH7110_CLK_PLL0_OUT 0
> >> > > >> > +#define JH7110_CLK_PLL1_OUT 1
> >> > > >> > +#define JH7110_CLK_PLL2_OUT 2
> >> > > >>
> >> > > >> In U-Boot commit 58c9c60b Yanhong Wang added:
> >> > > >>
> >> > > >> +
> >> > > >> +#define JH7110_SYSCLK_PLL0_OUT 190
> >> > > >> +#define JH7110_SYSCLK_PLL1_OUT 191
> >> > > >> +#define JH7110_SYSCLK_PLL2_OUT 192
> >> > > >> +
> >> > > >> +#define JH7110_SYSCLK_END193
> >> [...]
> >> > > > Ohh, that's not good.. If you pass the U-Boot dtb to Linux it
> >> > > > won't understand the numbering. The headers are part of the
> >> > > > dt-binding :/
> >>
> >> In fact, the clock index >= 190 makes linux hang on boot, waiting with
> >> EPROBE_DEFER for every device's clock, because the sysclk driver errors
> >> out with EINVAL (jh7110_sysclk_get()).
> >
> > Yup, that's about what I expected to happen.
> >
> >> > > Because PLL driver is separated from SYSCRG drivers in Linux, the
> >> > > numbering starts from 0. But in Uboot, the PLL driver is included
> >> > > in the SYSCRG driver, and the number follows the SYSCRG.
> >> >
> >> > Unfortunately, how you choose to construct your drivers has nothing to
> >> > do with this.
> >> > These defines/numbers appear in the dts and are part of the DT ABI.
> >> > The same dts is supposed to work for Linux & U-Boot.
> >>
> >> The JH7110 has 6 blocks of 64k iomem in that functional area:
> >> {SYS,STG,AON} x {CRG,SYSCON}. None of these has 190 clocks.
> >> The good news: the current DTS, as proposed here and in U-Boot master,
> >> provides nodes for all 6 entities. The bad news is that the clock
> >> assignments to those nodes and their numbering is messed up.
> >>
> >> AFAICT PLL{0,1,2} _are_ generated in SYS_SYSCON and thus U-Boot gets it
> >> wrong, in addition to the erroneous DTS.
> >
> > The numbers are kinda hocus-pocus anyway, they are just made up since the
> > clock numbering usually isn't something with a nice TRM to go and
> > reference (unlike interrupts which usually are documented in that way).
> > It is very helpful to make them aligned some register/bit positions or,
> > but that is not required.
> > IOW U-Boot is not wrong per se to use 190 instead of 0, but it is wrong
> > to have different numbers in both places.
> >
> > It sounds like you're saying that (and I have not looked) the U-Boot dts
> > actually has structural difference w.r.t. what provides which clock?
> > If so, that'll need to be fixed independently of the numbering problem.
> >
> > Otherwise Xingyu & Yanhong should coordinate on which is the "correct"
> > way of doing things & do it in both places.
> >
>
> Oh, unfortunately, the 7110 can not support to mix the uboot dtb and linux
> dtb up.
What does "cannot support" mean? It's normal and desirable for the same
dtb to be usable for both. The Linux kernel's dt-bindings are used for
multiple projects, not just Linux - it'd be silly for U-Boot, FreeBSD
etc etc to go off and each have their open set of (incompatible) bindings.
> If boot the Linux and should use the linux dtb instead of the uboot dtb.
> Because all clock ids and reset ids in Linux and Uboot are different include
> PLL, and some modules can work in Linux but not in uboot.
What do you mean by "modules"? It is fine for either Linux or U-Boot to
not have drivers for particular peripherals - for example, there might
be no driver for your camera related bits in U-Boot, or for controlling
DRAM in Linux.
The description of the hardware should not change though, as the
hardware has not.
> I suggest to boot Linux with its own linux dtb.
I suggest to make sure that you can use the same dtb for both.
Thanks,
Conor.
signature.asc
Description: PGP signature
Re: [PATCH] spi: synquacer: remove SPI_TX_BYTE handling
On Wed, 24 May 2023 at 10:33, Masahisa Kojima
wrote:
>
> Current code expects that SPI_TX_BYTE is single bit mode
> but it is wrong. It indicates byte program mode,
> not single bit mode.
>
> If SPI_TX_DUAL, SPI_TX_QUAD and SPI_TX_OCTAL bits are not set,
> the default transfer bus width is single bit.
>
> Signed-off-by: Masahisa Kojima
> ---
> drivers/spi/spi-synquacer.c | 8 +++-
> 1 file changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/spi/spi-synquacer.c b/drivers/spi/spi-synquacer.c
> index 0f5d0a30c3..553f9687e3 100644
> --- a/drivers/spi/spi-synquacer.c
> +++ b/drivers/spi/spi-synquacer.c
> @@ -186,7 +186,7 @@ static void synquacer_spi_config(struct udevice *dev,
> void *rx, const void *tx)
> struct udevice *bus = dev->parent;
> struct synquacer_spi_priv *priv = dev_get_priv(bus);
> struct dm_spi_slave_plat *slave_plat = dev_get_parent_plat(dev);
> - u32 val, div, bus_width = 1;
> + u32 val, div, bus_width;
> int rwflag;
>
> rwflag = (rx ? 1 : 0) | (tx ? 2 : 0);
> @@ -203,16 +203,14 @@ static void synquacer_spi_config(struct udevice *dev,
> void *rx, const void *tx)
> priv->mode = slave_plat->mode;
> priv->speed = slave_plat->max_hz;
>
> - if (priv->mode & SPI_TX_BYTE)
> - bus_width = 1;
> - else if (priv->mode & SPI_TX_DUAL)
> + if (priv->mode & SPI_TX_DUAL)
> bus_width = 2;
> else if (priv->mode & SPI_TX_QUAD)
> bus_width = 4;
> else if (priv->mode & SPI_TX_OCTAL)
> bus_width = 8;
> else
> - log_warning("SPI mode not configured, setting to byte
> mode\n");
> + bus_width = 1; /* default is single bit mode */
>
> div = DIV_ROUND_UP(12500, priv->speed);
>
> --
> 2.34.1
>
Reviewed-by: Ilias Apalodimas
[PATCH] spi: synquacer: remove SPI_TX_BYTE handling
Current code expects that SPI_TX_BYTE is single bit mode
but it is wrong. It indicates byte program mode,
not single bit mode.
If SPI_TX_DUAL, SPI_TX_QUAD and SPI_TX_OCTAL bits are not set,
the default transfer bus width is single bit.
Signed-off-by: Masahisa Kojima
---
drivers/spi/spi-synquacer.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/spi/spi-synquacer.c b/drivers/spi/spi-synquacer.c
index 0f5d0a30c3..553f9687e3 100644
--- a/drivers/spi/spi-synquacer.c
+++ b/drivers/spi/spi-synquacer.c
@@ -186,7 +186,7 @@ static void synquacer_spi_config(struct udevice *dev, void
*rx, const void *tx)
struct udevice *bus = dev->parent;
struct synquacer_spi_priv *priv = dev_get_priv(bus);
struct dm_spi_slave_plat *slave_plat = dev_get_parent_plat(dev);
- u32 val, div, bus_width = 1;
+ u32 val, div, bus_width;
int rwflag;
rwflag = (rx ? 1 : 0) | (tx ? 2 : 0);
@@ -203,16 +203,14 @@ static void synquacer_spi_config(struct udevice *dev,
void *rx, const void *tx)
priv->mode = slave_plat->mode;
priv->speed = slave_plat->max_hz;
- if (priv->mode & SPI_TX_BYTE)
- bus_width = 1;
- else if (priv->mode & SPI_TX_DUAL)
+ if (priv->mode & SPI_TX_DUAL)
bus_width = 2;
else if (priv->mode & SPI_TX_QUAD)
bus_width = 4;
else if (priv->mode & SPI_TX_OCTAL)
bus_width = 8;
else
- log_warning("SPI mode not configured, setting to byte mode\n");
+ bus_width = 1; /* default is single bit mode */
div = DIV_ROUND_UP(12500, priv->speed);
--
2.34.1
Re: [PATCH] PCI: zynqmp: Add ZynqMP NWL PCIe root port driver
Hi Pali, On 5/23/23 19:17, Pali Rohár wrote: Hello! I have looked at this change and below are my comments. Many thanks. On Tuesday 23 May 2023 14:57:38 Stefan Roese wrote: This patch adds the PCIe controller driver for the Xilinx / AMD ZynqMP NWL PCIe Bridge as root port. The driver source is partly copied from the Linux PCI driver and modified to enable usage in U-Boot (e.g. simplified and interrupt support removed). Signed-off-by: Stefan Roese Cc: Simon Glass Cc: Pali Rohár Cc: Bin Meng Cc: Michal Simek --- MAINTAINERS | 1 + drivers/pci/Kconfig | 7 + drivers/pci/Makefile | 1 + drivers/pci/pcie-xilinx-nwl.c | 374 ++ 4 files changed, 383 insertions(+) create mode 100644 drivers/pci/pcie-xilinx-nwl.c diff --git a/MAINTAINERS b/MAINTAINERS index c8f72e9ec6a2..2bc19d9daa75 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -343,6 +343,7 @@ F: drivers/rtc/armada38x.c F:drivers/spi/kirkwood_spi.c F:drivers/spi/mvebu_a3700_spi.c F:drivers/pci/pcie_dw_mvebu.c +F: drivers/pci/pcie-xilinx-nwl.c F:drivers/watchdog/armada-37xx-wdt.c F:drivers/watchdog/orion_wdt.c F:include/configs/mv-common.h diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig index ef328d26525b..60d98d14640d 100644 --- a/drivers/pci/Kconfig +++ b/drivers/pci/Kconfig @@ -374,4 +374,11 @@ config PCIE_UNIPHIER Say Y here if you want to enable PCIe controller support on UniPhier SoCs. +config PCIE_XILINX_NWL + bool "Xilinx NWL PCIe controller" + depends on ARCH_ZYNQMP + help +Say 'Y' here if you want support for Xilinx / AMD NWL PCIe +controller as Root Port. + endif diff --git a/drivers/pci/Makefile b/drivers/pci/Makefile index 49506e7ba59b..11f60c6991d9 100644 --- a/drivers/pci/Makefile +++ b/drivers/pci/Makefile @@ -49,3 +49,4 @@ obj-$(CONFIG_PCI_OCTEONTX) += pci_octeontx.o obj-$(CONFIG_PCIE_OCTEON) += pcie_octeon.o obj-$(CONFIG_PCIE_DW_SIFIVE) += pcie_dw_sifive.o obj-$(CONFIG_PCIE_UNIPHIER) += pcie_uniphier.o +obj-$(CONFIG_PCIE_XILINX_NWL) += pcie-xilinx-nwl.o diff --git a/drivers/pci/pcie-xilinx-nwl.c b/drivers/pci/pcie-xilinx-nwl.c new file mode 100644 index ..3d64a0e3b961 --- /dev/null +++ b/drivers/pci/pcie-xilinx-nwl.c @@ -0,0 +1,374 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * PCIe host bridge driver for Xilinx / AMD ZynqMP NWL PCIe Bridge + * + * Based on the Linux driver which is: + * (C) Copyright 2014 - 2015, Xilinx, Inc. + * + * Author: Stefan Roese + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include + +/* Bridge core config registers */ +#define BRCFG_PCIE_RX0 0x +#define BRCFG_PCIE_RX1 0x0004 +#define BRCFG_INTERRUPT0x0010 +#define BRCFG_PCIE_RX_MSG_FILTER 0x0020 + +/* Egress - Bridge translation registers */ +#define E_BREG_CAPABILITIES0x0200 +#define E_BREG_CONTROL 0x0208 +#define E_BREG_BASE_LO 0x0210 +#define E_BREG_BASE_HI 0x0214 +#define E_ECAM_CAPABILITIES0x0220 +#define E_ECAM_CONTROL 0x0228 +#define E_ECAM_BASE_LO 0x0230 +#define E_ECAM_BASE_HI 0x0234 + +#define I_ISUB_CONTROL 0x03E8 +#define SET_ISUB_CONTROL BIT(0) +/* Rxed msg fifo - Interrupt status registers */ +#define MSGF_MISC_STATUS 0x0400 +#define MSGF_MISC_MASK 0x0404 +#define MSGF_LEG_STATUS0x0420 +#define MSGF_LEG_MASK 0x0424 +#define MSGF_MSI_STATUS_LO 0x0440 +#define MSGF_MSI_STATUS_HI 0x0444 +#define MSGF_MSI_MASK_LO 0x0448 +#define MSGF_MSI_MASK_HI 0x044C + +/* Msg filter mask bits */ +#define CFG_ENABLE_PM_MSG_FWD BIT(1) +#define CFG_ENABLE_INT_MSG_FWD BIT(2) +#define CFG_ENABLE_ERR_MSG_FWD BIT(3) +#define CFG_ENABLE_MSG_FILTER_MASK (CFG_ENABLE_PM_MSG_FWD |\ +CFG_ENABLE_INT_MSG_FWD | \ +CFG_ENABLE_ERR_MSG_FWD) + +/* Misc interrupt status mask bits */ +#define MSGF_MISC_SR_RXMSG_AVAIL BIT(0) +#define MSGF_MISC_SR_RXMSG_OVERBIT(1) +#define MSGF_MISC_SR_SLAVE_ERR BIT(4) +#define MSGF_MISC_SR_MASTER_ERRBIT(5) +#define MSGF_MISC_SR_I_ADDR_ERRBIT(6) +#define MSGF_MISC_SR_E_ADDR_ERRBIT(7) +#define MSGF_MISC_SR_FATAL_AER BIT(16) +#define MSGF_MISC_SR_NON_FATAL_AER BIT(17) +#define MSGF_MISC_SR_CORR_AER BIT(18) +#define MSGF_MISC_SR_UR_DETECT BIT(20) +#define MSGF_MISC_SR_NON_FATAL_DEV BIT(22) +#define MSGF_MISC_SR_FATAL_DEV BIT(23) +#define
