[PATCH 1/1] common: event: check event_type_name() argument
In event_type_name() we should avoid possible buffer overruns by checking
the type argument.
Addresses-Coverity-ID: 478862 Out-of-bounds access
Signed-off-by: Heinrich Schuchardt
---
common/event.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/common/event.c b/common/event.c
index dc61b9672f3..16c2ba6cc92 100644
--- a/common/event.c
+++ b/common/event.c
@@ -56,7 +56,10 @@ _Static_assert(ARRAY_SIZE(type_name) == EVT_COUNT, "event
type_name size");
const char *event_type_name(enum event_t type)
{
#if CONFIG_IS_ENABLED(EVENT_DEBUG)
- return type_name[type];
+ if (type < ARRAY_SIZE(type_name))
+ return type_name[type];
+ else
+ return "(unknown)";
#else
return "(unknown)";
#endif
--
2.43.0
[PATCH v2] spi: cadence_qspi: Address the comparison failure for 0-8 bytes of data
The current implementation encounters issues when testing data ranging
from 0 to 8 bytes. This was confirmed through testing with both ISSI
(IS25WX256) and Micron (MT35XU02G) Flash exclusively in SDR mode.
Upon investigation, it was observed that utilizing the
"SPI_NOR_OCTAL_READ" flag and attempting to read less than 8 bytes in
STIG mode results in a read failure, leading to a compare test failure.
To resolve this issue, the CMD_4BYTE_FAST_READ opcode is now utilized
instead of CMD_4BYTE_OCTAL_READ, specifically in SDR mode.
This is based on patch series:
https://lore.kernel.org/all/cover.1701853668.git.tejas.arvind.bhum...@amd.com/
Signed-off-by: Tejas Bhumkar
---
Changes in v2:
- Resolve the duplication in the usage of the macro definition.
drivers/spi/cadence_ospi_versal.c | 3 ---
drivers/spi/cadence_qspi.h| 4
drivers/spi/cadence_qspi_apb.c| 3 +++
3 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/spi/cadence_ospi_versal.c
b/drivers/spi/cadence_ospi_versal.c
index e02a3b3de3..c2be307f1d 100644
--- a/drivers/spi/cadence_ospi_versal.c
+++ b/drivers/spi/cadence_ospi_versal.c
@@ -18,9 +18,6 @@
#include "cadence_qspi.h"
#include
-#define CMD_4BYTE_READ 0x13
-#define CMD_4BYTE_FAST_READ 0x0C
-
int cadence_qspi_apb_dma_read(struct cadence_spi_priv *priv,
const struct spi_mem_op *op)
{
diff --git a/drivers/spi/cadence_qspi.h b/drivers/spi/cadence_qspi.h
index 12825f8911..693474a287 100644
--- a/drivers/spi/cadence_qspi.h
+++ b/drivers/spi/cadence_qspi.h
@@ -33,6 +33,10 @@
#define CQSPI_DUMMY_BYTES_MAX 4
#define CQSPI_DUMMY_CLKS_MAX31
+#define CMD_4BYTE_FAST_READ0x0C
+#define CMD_4BYTE_OCTAL_READ 0x7c
+#define CMD_4BYTE_READ 0x13
+
/
* Controller's configuration and status register (offset from QSPI_BASE)
/
diff --git a/drivers/spi/cadence_qspi_apb.c b/drivers/spi/cadence_qspi_apb.c
index d033184aa4..fb90532217 100644
--- a/drivers/spi/cadence_qspi_apb.c
+++ b/drivers/spi/cadence_qspi_apb.c
@@ -469,6 +469,9 @@ int cadence_qspi_apb_command_read(struct cadence_spi_priv
*priv,
else
opcode = op->cmd.opcode;
+ if (opcode == CMD_4BYTE_OCTAL_READ && !priv->dtr)
+ opcode = CMD_4BYTE_FAST_READ;
+
reg = opcode << CQSPI_REG_CMDCTRL_OPCODE_LSB;
/* Set up dummy cycles. */
--
2.27.0
RE: [PATCH] efi_loader : Suppress error print message
[AMD Official Use Only - General]
Hi Heinrich,
> -Original Message-
> From: Heinrich Schuchardt
> Sent: Wednesday, January 24, 2024 2:09 AM
> To: Bhumkar, Tejas Arvind
> Cc: u-boot@lists.denx.de; tr...@konsulko.com; s...@chromium.org; Simek, Michal
> ; Abbarapu, Venkatesh
> ; g...@xilinx.com; Ilias Apalodimas
>
> Subject: Re: [PATCH] efi_loader : Suppress error print message
>
> Caution: This message originated from an External Source. Use proper caution
> when opening attachments, clicking links, or responding.
>
>
> On 1/23/24 19:53, Bhumkar, Tejas Arvind wrote:
> > [AMD Official Use Only - General]
> >
> > Hi Ilias & Heinrich,
> >
> >> -Original Message-
> >> From: Heinrich Schuchardt
> >> Sent: Tuesday, January 23, 2024 3:30 PM
> >> To: Ilias Apalodimas ; Bhumkar, Tejas
> >> Arvind
> >> Cc: u-boot@lists.denx.de; xypron.g...@gmx.de; tr...@konsulko.com;
> >> s...@chromium.org; Simek, Michal ; Abbarapu,
> >> Venkatesh ; g...@xilinx.com
> >> Subject: Re: [PATCH] efi_loader : Suppress error print message
> >>
> >> Caution: This message originated from an External Source. Use proper
> >> caution when opening attachments, clicking links, or responding.
> >>
> >>
> >> On 1/23/24 09:33, Ilias Apalodimas wrote:
> >>> Hi Tejas,
> >>>
> >>> On Mon, 22 Jan 2024 at 21:12, Tejas Bhumkar
> >>> wrote:
>
> Currently, on certain Xilinx platforms, an issue has been
> identified, manifesting as follows:
> >>
> >> Hello Tejas,
> >>
> >> thank you for bringing forward this issue.
> >>
> >> Which defconfig are you relating to?
> >
> > [Tejas]:
> > Checking with xilinx_zynqmp_virt_defconfig
> >
> >>
>
> Starting kernel ...
>
> efi_free_pool: illegal free 0x77830040
> efi_free_pool: illegal free 0x7782d040
> efi_free_pool: illegal free 0x7782c040
>
> The issue arises when the ramdisk image is relocated, placing it
> within the previously allocated EFI memory region( as EFI is
> established quite early in U-Boot).
> >>
> >> Which version of U-Boot are you on? Commit 06d514d77c37 ("lmb:
> >> consider EFI memory map") was meant to avoid such a situation.
> >
> > [Tejas] :
> > I'm verifying against the latest changes in the master branch. The
> > introduction of commit 06d514d77c37 ("lmb: consider EFI memory map")
> > has resolved the occurrence of the "efi_free_pool: illegal free"
> > error. but, it leads to a new error, as detailed in the following
> > patch:
> > https://lore.kernel.org/all/20230212150706.2967007-1-sjoerd@collabora.
> > com/
>
> Could you, please, try to reproduce your issues with origin/master as of
> today and
> provide the full boot log. Please, also provide the output of the bdinfo and
> the
> printenv command as well as the sizes of the kernel and the RAM disk.
[Tejas]: I've provided two logs: one obtained from the latest u-boot
origin/master, resulting in the "ERROR: reserving fdt memory region failed"
error, and the other from reverting commit 06d514d77c37 ("lmb: consider EFI
memory map"), which leads to the "efi_free_pool: illegal free" error.
Thank You,
Tejas.
>
> Best regards
>
> Heinrich
>
> >
> >>
> >>>
> >>> I don't mind suppressing the print for some time, but out of
> >>> curiosity, how is the ramdisk relocated? LMB should be aware of the
> >>> EFI regions by then, so I assume the relocation code doesn't check
> >>> those?
> >
> >
> > [Tejas] : I observe that the relocation of the RAM disk is taking place in
> > the line
> below.
> > https://github.com/u-boot/u-boot/blob/master/lib/lmb.c#L480-L491
> > Yes, the relocated code specifically examines the LMB region and does not
> consider the EFI region.
> >
> >>
> >> The indicated situation is serious. If the EFI sub-system is using
> >> the same memory area as the ramdisk, this may lead to corruption of
> >> the ramdisk. Suppressing the messages is by no means adequate to solve the
> problem.
> >
> > [Tejas] :
> > The challenge arises when relocating the ramdisk image, inserting it
> > into the previously assigned EFI memory region, established early in
> > U-Boot. Consequently, when attempting to release memory in the EFI region
> during the handover process to the kernel in the efi_free_pool function, we
> first
> verify if the memory was allocated by efi_allocate_pool().
> > The issue originates from a checksum mismatch because, during the ramdisk
> relocation, we overwrite memory allocated by EFI.
> > This leads to the appearance of the error message: efi_free_pool: illegal
> > free
> 0x77830040.
> > Crucially, there is no corruption of the ramdisk seen since we do not
> > actually
> releasing memory due to the checksum mismatch.
> > In our testing, this issue was observed only when the ramdisk size exceeded
> approximately 24 MB.
> >
> >>
> >> Best regards
> >>
> >> Heinrich
> >>
> >>
> >>>
> >>> Thanks
> >>> /Ilias
> >>>
> Consequently, when
> attempting to release memory in the EFI memory region
RE: [PATCH RFC] spi: cadence_qspi: Address the comparison failure for 0-8
[AMD Official Use Only - General]
Please ignore this patch, as I've submitted another one to address this problem.
Thank You,
Tejas
> -Original Message-
> From: U-Boot On Behalf Of Tejas Bhumkar
> Sent: Monday, January 22, 2024 4:44 PM
> To: u-boot@lists.denx.de
> Cc: ja...@amarulasolutions.com; s...@chromium.org; d-g...@ti.com; a-
> nan...@ti.com; Simek, Michal ; Abbarapu, Venkatesh
> ; g...@xilinx.com
> Subject: [PATCH RFC] spi: cadence_qspi: Address the comparison failure for 0-8
>
> Caution: This message originated from an External Source. Use proper caution
> when opening attachments, clicking links, or responding.
>
>
> In the current implementation, the test for data ranging from 0 to 8 bytes is
> encountering failures. This has been confirmed through testing with both ISSI
> (IS25WX256) and Micron (MT35XU02G) Flash in SDR mode exclusively.
>
> Upon analysis, it was observed that utilizing the "SPI_NOR_OCTAL_READ"
> flag and attempting to read less than 8 bytes in STIG mode results in a
> failure to
> read, leading to a failure in the compare test.
>
> Upon reviewing the Micron OSPI flash data sheet, it was noted that for
> protocol
> 1-1-8, 8 dummy clock cycles are required. While the current implementation
> achieves this, it still results in a compare test failure.
>
> Therefore, the code has been revised to include DMA read for operations
> involving less than 8 bytes as well.
>
> Fixes: 53f4ef0 ("spi: cadence_qspi: use STIG mode for small reads")
>
> Signed-off-by: Tejas Bhumkar
> ---
> drivers/spi/cadence_qspi.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/spi/cadence_qspi.c b/drivers/spi/cadence_qspi.c index
> dfc74c882d..a6477dbfcf 100644
> --- a/drivers/spi/cadence_qspi.c
> +++ b/drivers/spi/cadence_qspi.c
> @@ -313,7 +313,7 @@ static int cadence_spi_mem_exec_op(struct spi_slave
> *spi,
> * which is unsupported on some flash devices during register
> * reads, prefer STIG mode for such small reads.
> */
> - if (op->data.nbytes <= CQSPI_STIG_DATA_LEN_MAX)
> + if (!op->addr.nbytes)
> mode = CQSPI_STIG_READ;
> else
> mode = CQSPI_READ;
> --
> 2.27.0
[PATCH] spi: cadence_qspi: Address the comparison failure for 0-8 bytes of data
The current implementation encounters issues when testing data ranging from 0 to 8 bytes. This was confirmed through testing with both ISSI (IS25WX256) and Micron (MT35XU02G) Flash exclusively in SDR mode. Upon investigation, it was observed that utilizing the "SPI_NOR_OCTAL_READ" flag and attempting to read less than 8 bytes in STIG mode results in a read failure, leading to a compare test failure. To resolve this issue, the CMD_4BYTE_FAST_READ opcode is now utilized instead of CMD_4BYTE_OCTAL_READ, specifically in SDR mode. Signed-off-by: Tejas Bhumkar --- drivers/spi/cadence_qspi.h | 3 +++ drivers/spi/cadence_qspi_apb.c | 3 +++ 2 files changed, 6 insertions(+) diff --git a/drivers/spi/cadence_qspi.h b/drivers/spi/cadence_qspi.h index 12825f8911..3b9cee25fa 100644 --- a/drivers/spi/cadence_qspi.h +++ b/drivers/spi/cadence_qspi.h @@ -33,6 +33,9 @@ #define CQSPI_DUMMY_BYTES_MAX 4 #define CQSPI_DUMMY_CLKS_MAX31 +#define CMD_4BYTE_FAST_READ0x0C +#define CMD_4BYTE_OCTAL_READ 0x7c + / * Controller's configuration and status register (offset from QSPI_BASE) / diff --git a/drivers/spi/cadence_qspi_apb.c b/drivers/spi/cadence_qspi_apb.c index d033184aa4..fb90532217 100644 --- a/drivers/spi/cadence_qspi_apb.c +++ b/drivers/spi/cadence_qspi_apb.c @@ -469,6 +469,9 @@ int cadence_qspi_apb_command_read(struct cadence_spi_priv *priv, else opcode = op->cmd.opcode; + if (opcode == CMD_4BYTE_OCTAL_READ && !priv->dtr) + opcode = CMD_4BYTE_FAST_READ; + reg = opcode << CQSPI_REG_CMDCTRL_OPCODE_LSB; /* Set up dummy cycles. */ -- 2.27.0
[PULL] u-boot-sh/master-cleanup
The following changes since commit fea3efb757f7a9c6831c023cb456f9fa5fd0278e: Kconfig: boot: Imply BOOTSTD_DEFAULT when BOOTSTD_FULL=y (2024-01-19 18:30:08 -0500) are available in the Git repository at: https://source.denx.de/u-boot/custodians/u-boot-sh.git master-cleanup for you to fetch changes up to 8a725c610675846b380d865ad68c2295cf15782e: ARM: renesas: whitehawk: Drop extra leading space (2024-01-27 20:17:04 +0100) Marek Vasut (4): clk: renesas: Drop include common.h pinctrl: renesas: Drop include common.h ARM: renesas: Drop include common.h ARM: renesas: whitehawk: Drop extra leading space board/renesas/alt/alt.c | 1 - board/renesas/alt/alt_spl.c | 1 - board/renesas/alt/qos.c | 1 - board/renesas/blanche/blanche.c | 1 - board/renesas/blanche/qos.c | 1 - board/renesas/draak/draak.c | 1 - board/renesas/falcon/falcon.c | 2 +- board/renesas/gose/gose.c | 1 - board/renesas/gose/gose_spl.c | 1 - board/renesas/gose/qos.c| 1 - board/renesas/grpeach/grpeach.c | 3 ++- board/renesas/koelsch/koelsch.c | 1 - board/renesas/koelsch/koelsch_spl.c | 1 - board/renesas/koelsch/qos.c | 1 - board/renesas/lager/lager.c | 1 - board/renesas/lager/lager_spl.c | 1 - board/renesas/lager/qos.c | 1 - board/renesas/porter/porter.c | 1 - board/renesas/porter/porter_spl.c | 1 - board/renesas/porter/qos.c | 1 - board/renesas/r2dplus/r2dplus.c | 1 - board/renesas/rcar-common/common.c | 1 - board/renesas/rcar-common/gen3-spl.c| 1 - board/renesas/rcar-common/v3-common.c | 2 +- board/renesas/salvator-x/salvator-x.c | 1 - board/renesas/silk/qos.c| 1 - board/renesas/silk/silk.c | 1 - board/renesas/silk/silk_spl.c | 1 - board/renesas/spider/spider.c | 1 - board/renesas/stout/cpld.c | 1 - board/renesas/stout/qos.c | 1 - board/renesas/stout/stout.c | 1 - board/renesas/stout/stout_spl.c | 1 - board/renesas/ulcb/cpld.c | 1 - board/renesas/ulcb/ulcb.c | 1 - board/renesas/v3hsk/cpld.c | 1 - board/renesas/v3msk/cpld.c | 1 - board/renesas/whitehawk/whitehawk.c | 3 +-- drivers/clk/renesas/clk-rcar-gen2.c | 1 - drivers/clk/renesas/clk-rcar-gen3.c | 1 - drivers/clk/renesas/r8a774a1-cpg-mssr.c | 1 - drivers/clk/renesas/r8a774b1-cpg-mssr.c | 1 - drivers/clk/renesas/r8a774c0-cpg-mssr.c | 1 - drivers/clk/renesas/r8a774e1-cpg-mssr.c | 1 - drivers/clk/renesas/r8a7790-cpg-mssr.c | 1 - drivers/clk/renesas/r8a7791-cpg-mssr.c | 1 - drivers/clk/renesas/r8a7792-cpg-mssr.c | 1 - drivers/clk/renesas/r8a7794-cpg-mssr.c | 1 - drivers/clk/renesas/r8a7795-cpg-mssr.c | 1 - drivers/clk/renesas/r8a7796-cpg-mssr.c | 1 - drivers/clk/renesas/r8a77965-cpg-mssr.c | 1 - drivers/clk/renesas/r8a77970-cpg-mssr.c | 1 - drivers/clk/renesas/r8a77980-cpg-mssr.c | 1 - drivers/clk/renesas/r8a77990-cpg-mssr.c | 1 - drivers/clk/renesas/r8a77995-cpg-mssr.c | 1 - drivers/clk/renesas/r8a779a0-cpg-mssr.c | 1 - drivers/clk/renesas/r8a779f0-cpg-mssr.c | 1 - drivers/clk/renesas/r8a779g0-cpg-mssr.c | 1 - drivers/clk/renesas/r9a06g032-clocks.c | 1 - drivers/clk/renesas/rcar-cpg-lib.c | 1 - drivers/clk/renesas/renesas-cpg-mssr.c | 1 - drivers/pinctrl/renesas/pfc-r8a7790.c | 1 - drivers/pinctrl/renesas/pfc-r8a7791.c | 1 - drivers/pinctrl/renesas/pfc-r8a7792.c | 1 - drivers/pinctrl/renesas/pfc-r8a7794.c | 1 - drivers/pinctrl/renesas/pfc-r8a77951.c | 1 - drivers/pinctrl/renesas/pfc-r8a7796.c | 1 - drivers/pinctrl/renesas/pfc-r8a77965.c | 1 - drivers/pinctrl/renesas/pfc-r8a77970.c | 1 - drivers/pinctrl/renesas/pfc-r8a77980.c | 1 - drivers/pinctrl/renesas/pfc-r8a77990.c | 1 - drivers/pinctrl/renesas/pfc-r8a77995.c | 1 - drivers/pinctrl/renesas/pfc-r8a779a0.c | 1 - drivers/pinctrl/renesas/pfc-r8a779f0.c | 1 - drivers/pinctrl/renesas/pfc-r8a779g0.c | 1 - drivers/pinctrl/renesas/pfc.c | 1 - drivers/pinctrl/renesas/pinctrl-rza1.c | 1 - 77 files changed, 5 insertions(+), 78 deletions(-)
[PATCH v2] net: phy: Use PHY MDIO address from DT if available
In case the PHY is fully described in DT, use PHY MDIO address from DT directly instead of always using auto-detection. This also fixes the behavior of 'mdio list' in such DT setup, which now prints the PHY connected to the MAC correctly. Signed-off-by: Marek Vasut --- Cc: Joe Hershberger Cc: Paul Barker Cc: Ramon Fried --- V2: This patch is generic replacement for - net: ravb: Use PHY MDIO address from DT if available - net: sh_eth: Use PHY MDIO address from DT if available --- drivers/net/phy/ethernet_id.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/net/phy/ethernet_id.c b/drivers/net/phy/ethernet_id.c index 877a51c3d00..6cb1fd4453e 100644 --- a/drivers/net/phy/ethernet_id.c +++ b/drivers/net/phy/ethernet_id.c @@ -71,6 +71,9 @@ struct phy_device *phy_connect_phy_id(struct mii_dev *bus, struct udevice *dev, } } + if (phyaddr == -1) + phyaddr = ofnode_read_u32_default(phandle_args.node, "reg", -1); + id = vendor << 16 | device; phydev = phy_device_create(bus, phyaddr, id, false); if (phydev) -- 2.43.0
[PATCH] video: dw_hdmi: Fix compiler warnings with gcc-14
GCC-14 find more warnings like
"make pointer from integer without a cast"
fix them by adding a type cast.
Signed-off-by: Khem Raj
Cc: Anatolij Gustschin
Cc: Tom Rini
---
drivers/video/dw_hdmi.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/video/dw_hdmi.c b/drivers/video/dw_hdmi.c
index c4fbb18294..9294d9a82a 100644
--- a/drivers/video/dw_hdmi.c
+++ b/drivers/video/dw_hdmi.c
@@ -78,10 +78,10 @@ static void dw_hdmi_write(struct dw_hdmi *hdmi, u8 val, int
offset)
{
switch (hdmi->reg_io_width) {
case 1:
- writeb(val, hdmi->ioaddr + offset);
+ writeb(val, (void *)(hdmi->ioaddr + offset));
break;
case 4:
- writel(val, hdmi->ioaddr + (offset << 2));
+ writel(val, (void *)(hdmi->ioaddr + (offset << 2)));
break;
default:
debug("reg_io_width has unsupported width!\n");
@@ -93,9 +93,9 @@ static u8 dw_hdmi_read(struct dw_hdmi *hdmi, int offset)
{
switch (hdmi->reg_io_width) {
case 1:
- return readb(hdmi->ioaddr + offset);
+ return readb((void *)(hdmi->ioaddr + offset));
case 4:
- return readl(hdmi->ioaddr + (offset << 2));
+ return readl((void *)(hdmi->ioaddr + (offset << 2)));
default:
debug("reg_io_width has unsupported width!\n");
break;
--
2.43.0
Re: Fwd: New Defects reported by Coverity Scan for Das U-Boot
Am 27. Januar 2024 16:40:18 MEZ schrieb Tom Rini :
>Hey, I'll just pass this on directly rather than to the list.
>
>-- Forwarded message -
>From:
>Date: Sat, Jan 27, 2024 at 10:36 AM
>Subject: New Defects reported by Coverity Scan for Das U-Boot
>To:
>
>
>Hi,
>
>Please find the latest report on new defect(s) introduced to Das
>U-Boot found with Coverity Scan.
>
>1 new defect(s) introduced to Das U-Boot found with Coverity Scan.
>
>
>New defect(s) Reported-by: Coverity Scan
>Showing 1 of 1 defect(s)
>
>
>** CID 479279:(TAINTED_SCALAR)
>
>
>
>*** CID 479279:(TAINTED_SCALAR)
>/cmd/smbios.c: 180 in do_smbios()
>174 smbios_print_type2((struct smbios_type2 *)pos);
>175 break;
>176 case 127:
>177 smbios_print_type127((struct
>smbios_type127 *)pos);
>178 break;
>179 default:
CID 479279:(TAINTED_SCALAR)
Passing tainted expression "pos->length" to "smbios_print_generic",
which uses it as a loop boundary.
>180 smbios_print_generic(pos);
>181 break;
>182 }
>183 }
>184
>185 return CMD_RET_SUCCESS;
>/cmd/smbios.c: 154 in do_smbios()
>148 size = entry2->length;
>149 max_struct_size = entry2->max_struct_size;
>150 } else {
>151 log_err("Unknown SMBIOS anchor format\n");
>152 return CMD_RET_FAILURE;
>153 }
CID 479279:(TAINTED_SCALAR)
Passing tainted expression "size" to "table_compute_checksum", which
uses it as a loop boundary.
>154 if (table_compute_checksum(entry, size)) {
>155 log_err("Invalid anchor checksum\n");
>156 return CMD_RET_FAILURE;
>157 }
>158 printf("SMBIOS %s present.\n", version);
>159
>/cmd/smbios.c: 174 in do_smbios()
>168(unsigned long long)map_to_sysmem(pos));
>169 switch (pos->type) {
>170 case 1:
>171 smbios_print_type1((struct smbios_type1 *)pos);
>172 break;
>173 case 2:
CID 479279:(TAINTED_SCALAR)
Passing tainted expression "((struct smbios_type2
*)pos)->number_contained_objects" to "smbios_print_type2", which uses it
as a loop boundary.
>174 smbios_print_type2((struct smbios_type2 *)pos);
>175 break;
>176 case 127:
>177 smbios_print_type127((struct
>smbios_type127 *)pos);
>178 break;
>179 default:
>/cmd/smbios.c: 154 in do_smbios()
>148 size = entry2->length;
>149 max_struct_size = entry2->max_struct_size;
>150 } else {
>151 log_err("Unknown SMBIOS anchor format\n");
>152 return CMD_RET_FAILURE;
>153 }
CID 479279:(TAINTED_SCALAR)
Passing tainted expression "size" to "table_compute_checksum", which
uses it as a loop boundary.
>154 if (table_compute_checksum(entry, size)) {
>155 log_err("Invalid anchor checksum\n");
>156 return CMD_RET_FAILURE;
>157 }
>158 printf("SMBIOS %s present.\n", version);
>159
>/cmd/smbios.c: 180 in do_smbios()
>174 smbios_print_type2((struct smbios_type2 *)pos);
>175 break;
>176 case 127:
>177 smbios_print_type127((struct
>smbios_type127 *)pos);
>178 break;
>179 default:
CID 479279:(TAINTED_SCALAR)
Passing tainted expression "pos->length" to "smbios_print_generic",
which uses it as a loop boundary.
>180 smbios_print_generic(pos);
>181 break;
>182 }
>183 }
>184
>185 return CMD_RET_SUCCESS;
>/cmd/smbios.c: 174 in do_smbios()
>168(unsigned long long)map_to_sysmem(pos));
>169 switch (pos->type) {
>170 case 1:
>171 smbios_print_type1((struct smbios_type1 *)pos);
>172 break;
>173 case 2:
CID 479279:(TAINTED_SCALAR)
Passing tainted expression "((struct smbios_type2
*)pos)->number_contained_objects" to "smbios_print_type2", which uses it
as a loop boundary.
>174
[PATCH v2] mmc: Add SPL_MMC_PWRSEQ to fix link issue when building SPL
With MMC_PWRSEQ enabled the following link issue may happen when
building SPL and SPL_PWRSEQ is not enabled.
aarch64-linux-gnu-ld.bfd: drivers/mmc/meson_gx_mmc.o: in function
`meson_mmc_probe':
drivers/mmc/meson_gx_mmc.c:295: undefined reference to `pwrseq_set_power'
Fix this by adding a SPL_MMC_PWRSEQ Kconfig option used to enable mmc
pwrseq support in SPL.
Also add depends on DM_GPIO to fix following link issue:
aarch64-linux-gnu-ld.bfd: drivers/mmc/mmc-pwrseq.o: in function
`mmc_pwrseq_set_power':
drivers/mmc/mmc-pwrseq.c:26: undefined reference to `gpio_request_by_name'
aarch64-linux-gnu-ld.bfd: drivers/mmc/mmc-pwrseq.c:29: undefined reference to
`dm_gpio_set_value'
aarch64-linux-gnu-ld.bfd: drivers/mmc/mmc-pwrseq.c:31: undefined reference to
`dm_gpio_set_value'
Signed-off-by: Jonas Karlman
Reviewed-by: Kever Yang
Reviewed-by: Neil Armstrong
Acked-by: Ferass El Hafidi
---
Changes in v2:
- Fix Ths typo
- Collect r-b and a-b tags
Link to v1: https://patchwork.ozlabs.org/patch/1839392/
---
drivers/mmc/Kconfig | 12 ++--
drivers/mmc/Makefile | 2 +-
drivers/mmc/meson_gx_mmc.c| 2 +-
drivers/mmc/rockchip_dw_mmc.c | 2 +-
include/mmc.h | 4 ++--
5 files changed, 15 insertions(+), 7 deletions(-)
diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
index 17618c3bdcc1..a141007a576f 100644
--- a/drivers/mmc/Kconfig
+++ b/drivers/mmc/Kconfig
@@ -20,11 +20,19 @@ config MMC_WRITE
config MMC_PWRSEQ
bool "HW reset support for eMMC"
- depends on PWRSEQ
+ depends on PWRSEQ && DM_GPIO
help
- Ths select Hardware reset support aka pwrseq-emmc for eMMC
+ This select Hardware reset support aka pwrseq-emmc for eMMC
devices.
+config SPL_MMC_PWRSEQ
+ bool "HW reset support for eMMC in SPL"
+ depends on SPL_PWRSEQ && SPL_DM_GPIO
+ default y if MMC_PWRSEQ
+ help
+ This select Hardware reset support aka pwrseq-emmc for eMMC
+ devices in SPL.
+
config MMC_BROKEN_CD
bool "Poll for broken card detection case"
help
diff --git a/drivers/mmc/Makefile b/drivers/mmc/Makefile
index e9cf1fcc6400..2b94cc2f1c34 100644
--- a/drivers/mmc/Makefile
+++ b/drivers/mmc/Makefile
@@ -11,7 +11,7 @@ obj-$(CONFIG_$(SPL_TPL_)BOOTSTD) += mmc_bootdev.o
endif
obj-$(CONFIG_$(SPL_TPL_)MMC_WRITE) += mmc_write.o
-obj-$(CONFIG_MMC_PWRSEQ) += mmc-pwrseq.o
+obj-$(CONFIG_$(SPL_)MMC_PWRSEQ) += mmc-pwrseq.o
obj-$(CONFIG_MMC_SDHCI_ADMA_HELPERS) += sdhci-adma.o
ifndef CONFIG_$(SPL_)BLK
diff --git a/drivers/mmc/meson_gx_mmc.c b/drivers/mmc/meson_gx_mmc.c
index fcf4f03d1e24..0825c0a2a838 100644
--- a/drivers/mmc/meson_gx_mmc.c
+++ b/drivers/mmc/meson_gx_mmc.c
@@ -288,7 +288,7 @@ static int meson_mmc_probe(struct udevice *dev)
mmc_set_clock(mmc, cfg->f_min, MMC_CLK_ENABLE);
-#ifdef CONFIG_MMC_PWRSEQ
+#if CONFIG_IS_ENABLED(MMC_PWRSEQ)
/* Enable power if needed */
ret = mmc_pwrseq_get_power(dev, cfg);
if (!ret) {
diff --git a/drivers/mmc/rockchip_dw_mmc.c b/drivers/mmc/rockchip_dw_mmc.c
index 72c820ee6330..ad4529d6afa8 100644
--- a/drivers/mmc/rockchip_dw_mmc.c
+++ b/drivers/mmc/rockchip_dw_mmc.c
@@ -145,7 +145,7 @@ static int rockchip_dwmmc_probe(struct udevice *dev)
host->fifo_mode = priv->fifo_mode;
-#ifdef CONFIG_MMC_PWRSEQ
+#if CONFIG_IS_ENABLED(MMC_PWRSEQ)
/* Enable power if needed */
ret = mmc_pwrseq_get_power(dev, >cfg);
if (!ret) {
diff --git a/include/mmc.h b/include/mmc.h
index 1022db3ffa7c..9aef31ea5deb 100644
--- a/include/mmc.h
+++ b/include/mmc.h
@@ -590,7 +590,7 @@ struct mmc_config {
uint f_max;
uint b_max;
unsigned char part_type;
-#ifdef CONFIG_MMC_PWRSEQ
+#if CONFIG_IS_ENABLED(MMC_PWRSEQ)
struct udevice *pwr_dev;
#endif
};
@@ -808,7 +808,7 @@ int mmc_deinit(struct mmc *mmc);
*/
int mmc_of_parse(struct udevice *dev, struct mmc_config *cfg);
-#ifdef CONFIG_MMC_PWRSEQ
+#if CONFIG_IS_ENABLED(MMC_PWRSEQ)
/**
* mmc_pwrseq_get_power() - get a power device from device tree
*
--
2.43.0
[PATCH v2] mmc: Remove alignment hole for cmdidx in struct mmc_cmd
The alignment hole caused by cmdidx in struct mmc_cmd cause strange
issues together with the peephole2 optimization on Amlogic SoCs.
Following was observed while working on SPL support for Amlogic SoCs.
sd_get_capabilities() normally issue a CMD55 followed by a CMD51.
However, on at least Amlogic S905 (Cortex-A53) and S905X3 (Cortex-A55),
CMD55 was instead followed by CMD8 (and a few reties) in SPL.
Code from the call site:
cmd.cmdidx = SD_CMD_APP_SEND_SCR; // 51
...
data.blocksize = 8;
...
err = mmc_send_cmd_retry(mmc, , , 3);
Running the code with MMC_TRACE enabled shows:
CMD_SEND:55
ARG 0x5048
MMC_RSP_R1,5,6,7 0x0920
CMD_SEND:8
ARG 0x
RET -110
Removing the alignment hole by changing cmdidx from ushort to uint or
building with -fno-peephole2 flag seem to resolve this issue.
CMD_SEND:55
ARG 0x5048
MMC_RSP_R1,5,6,7 0x0920
CMD_SEND:51
ARG 0x
MMC_RSP_R1,5,6,7 0x0920
Same issue was observed building U-Boot with gcc 8 - 13.
Remove this alignment hole by changing cmdidx from ushort to uint.
Signed-off-by: Jonas Karlman
---
Changes in v2:
- Drop use of -fno-peephole2 flag
Link to RFC: https://patchwork.ozlabs.org/patch/1841495/
---
include/mmc.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/mmc.h b/include/mmc.h
index 1022db3ffa7c..031ea0fb3545 100644
--- a/include/mmc.h
+++ b/include/mmc.h
@@ -413,7 +413,7 @@ struct mmc_cid {
};
struct mmc_cmd {
- ushort cmdidx;
+ uint cmdidx;
uint resp_type;
uint cmdarg;
uint response[4];
--
2.43.0
Re: [PATCH v3 1/3] riscv: dts: sophgo: add basic device tree for Milk-V Duo board
Hi Kongyang:
On 23:05 Sun 21 Jan , Kongyang Liu wrote:
> Import device tree from Linux kernel to add basic support for CPU, PLIC,
> UART and Timer. The name cv1800b in the filename represent the chip used
> on Milk-V Duo board.
>
> Signed-off-by: Kongyang Liu
>
> ---
>
> Changes in v3:
> - Swap patch 1 and 2 duo to dependency of defconfig and device tree
>
> arch/riscv/dts/Makefile | 1 +
> arch/riscv/dts/cv1800b-milkv-duo.dts | 38 +
> arch/riscv/dts/cv1800b.dtsi | 123 +++
> 3 files changed, 162 insertions(+)
> create mode 100644 arch/riscv/dts/cv1800b-milkv-duo.dts
> create mode 100644 arch/riscv/dts/cv1800b.dtsi
since these dts files are took from kernel tree,
it'd be wise to keep them sync.. please take a look at
(should be easy for us to add more SoCs support later)
https://lore.kernel.org/all/ia1pr20mb4953c128fdde7a2249669213bb...@ia1pr20mb4953.namprd20.prod.outlook.com/
>
> diff --git a/arch/riscv/dts/Makefile b/arch/riscv/dts/Makefile
> index b05bb5607f..17cda483e1 100644
> --- a/arch/riscv/dts/Makefile
> +++ b/arch/riscv/dts/Makefile
> @@ -2,6 +2,7 @@
>
> dtb-$(CONFIG_TARGET_ANDES_AE350) += ae350_32.dtb ae350_64.dtb
> dtb-$(CONFIG_TARGET_MICROCHIP_ICICLE) += mpfs-icicle-kit.dtb
> +dtb-$(CONFIG_TARGET_MILKV_DUO) += cv1800b-milkv-duo.dtb
> dtb-$(CONFIG_TARGET_QEMU_VIRT) += qemu-virt32.dtb qemu-virt64.dtb
> dtb-$(CONFIG_TARGET_OPENPITON_RISCV64) += openpiton-riscv64.dtb
> dtb-$(CONFIG_TARGET_SIFIVE_UNLEASHED) += hifive-unleashed-a00.dtb
> diff --git a/arch/riscv/dts/cv1800b-milkv-duo.dts
> b/arch/riscv/dts/cv1800b-milkv-duo.dts
> new file mode 100644
> index 00..3af9e34b3b
> --- /dev/null
> +++ b/arch/riscv/dts/cv1800b-milkv-duo.dts
> @@ -0,0 +1,38 @@
> +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> +/*
> + * Copyright (C) 2023 Jisheng Zhang
> + */
> +
> +/dts-v1/;
> +
> +#include "cv1800b.dtsi"
> +
> +/ {
> + model = "Milk-V Duo";
> + compatible = "milkv,duo", "sophgo,cv1800b";
> +
> + aliases {
> + serial0 =
> + serial1 =
> + serial2 =
> + serial3 =
> + serial4 =
> + };
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };
> +
> + memory@8000 {
> + device_type = "memory";
> + reg = <0x8000 0x3f4>;
> + };
> +};
> +
> + {
> + clock-frequency = <2500>;
> +};
> +
> + {
> + status = "okay";
> +};
> diff --git a/arch/riscv/dts/cv1800b.dtsi b/arch/riscv/dts/cv1800b.dtsi
> new file mode 100644
> index 00..df40e87ee0
> --- /dev/null
> +++ b/arch/riscv/dts/cv1800b.dtsi
> @@ -0,0 +1,123 @@
> +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> +/*
> + * Copyright (C) 2023 Jisheng Zhang
> + */
> +
> +#include
> +
> +/ {
> + compatible = "sophgo,cv1800b";
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + cpus: cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + timebase-frequency = <2500>;
> +
> + cpu0: cpu@0 {
> + compatible = "thead,c906", "riscv";
> + device_type = "cpu";
> + reg = <0>;
> + d-cache-block-size = <64>;
> + d-cache-sets = <512>;
> + d-cache-size = <65536>;
> + i-cache-block-size = <64>;
> + i-cache-sets = <128>;
> + i-cache-size = <32768>;
> + mmu-type = "riscv,sv39";
> + riscv,isa = "rv64imafdc";
> + riscv,isa-base = "rv64i";
> + riscv,isa-extensions = "i", "m", "a", "f", "d", "c",
> "zicntr", "zicsr",
> +"zifencei", "zihpm";
> +
> + cpu0_intc: interrupt-controller {
> + compatible = "riscv,cpu-intc";
> + interrupt-controller;
> + #address-cells = <0>;
> + #interrupt-cells = <1>;
> + };
> + };
> + };
> +
> + osc: oscillator {
> + compatible = "fixed-clock";
> + clock-output-names = "osc_25m";
> + #clock-cells = <0>;
> + };
> +
> + soc {
> + compatible = "simple-bus";
> + interrupt-parent = <>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + dma-noncoherent;
> + ranges;
> +
> + uart0: serial@414 {
> + compatible = "snps,dw-apb-uart";
> + reg = <0x0414 0x100>;
> + interrupts = <44 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + status = "disabled";
> + };
> +
>
Re: Pull request smbios-2024-04-rc1-2
On Sat, Jan 27, 2024 at 09:55:04AM +0100, Heinrich Schuchardt wrote: > Dear Tom, > > The following changes since commit e7f9e5eb584dd0b5d1b1ff82fe607d6da9940cc6: > > Merge branch '2024-01-24-assorted-fixes-and-updates' (2024-01-25 > 11:01:38 -0500) > > are available in the Git repository at: > > https://source.denx.de/u-boot/custodians/u-boot-efi.git > tags/smbios-2024-04-rc1-2 > > for you to fetch changes up to 91cc06bcab76dd4b9d07c221b4962283f0984c8e: > > lib: support SMBIOS3 table in uuid_guid_get_str() (2024-01-26 > 14:17:55 +0100) > > Gitlab CI did not report any issues: > https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/19447 > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
[PATCH] configs: visionfive2: Disable ENV_IS_NOWHERE
The VisionFive 2 board supports saving the u-boot environment settings
are saved to on-board SPI flash. However the defconfig enables both
ENV_IS_NOWHERE and ENV_IS_IN_SPI_FLASH, preventing the "saveenv" command
to work. Fix that by disabling ENV_IS_NOWHERE.
Fixes: 7d79bed00c9e ("configs: starfive: Enable environment in SPI flash
support")
Reported-by: E Shattow
Signed-off-by: Aurelien Jarno
---
configs/starfive_visionfive2_defconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/configs/starfive_visionfive2_defconfig
b/configs/starfive_visionfive2_defconfig
index 1b7d57bac7..c68f3c2def 100644
--- a/configs/starfive_visionfive2_defconfig
+++ b/configs/starfive_visionfive2_defconfig
@@ -77,7 +77,6 @@ CONFIG_CMD_TFTPPUT=y
CONFIG_CMD_BOOTSTAGE=y
CONFIG_OF_BOARD=y
CONFIG_ENV_OVERWRITE=y
-CONFIG_ENV_IS_NOWHERE=y
CONFIG_ENV_IS_IN_SPI_FLASH=y
CONFIG_ENV_SECT_SIZE_AUTO=y
CONFIG_SYS_RELOC_GD_ENV_ADDR=y
--
2.42.0
Re: [PATCH v1] tools: mkimage: Add support for i.MXRT FlexSPI Header
On Tue, Jan 23, 2024 at 11:15 PM Jesse Taube wrote: > > Modify imx8m Flex SPI Configuration Block to work with imxrt. > Add more Flex SPI configuration options to Kconfig. > > Signed-off-by: Jesse Taube Applied, thanks.
Re: [PATCH] ARM: imx: Enable kaslrseed command on Data Modul i.MX8M Mini/Plus eDM SBC
On Mon, Jan 22, 2024 at 11:56 AM Marek Vasut wrote: > > Linux 6.6.y with KASLR enabled would print the following message on boot: > " > KASLR disabled due to lack of seed > " > Enable the 'kaslrseed' command so a random number seed can be pulled > from CAAM and inserted into the /chosen node 'kaslr-seed' property of > Linux kernel DT before boot, thus letting KASLR work properly. > > Signed-off-by: Marek Vasut Applied, thanks.
Re: [PATCH] toradex: tdx-cfg-block: Add new apalis and colibri pid
On Thu, Jan 25, 2024 at 8:02 AM Francesco Dolcini wrote: > there is some trailing space here at the end of the line. > > Fabio, can you fix this up before applying? Removed the whitespace and applied it, thanks.
Re: [PATCH 1/3] rockchip: rk35xx: Remove use of eMMC DDR52 mode
Hi Eugen, On 2024-01-27 04:48, Eugen Hristev wrote: > Hi Jonas, > > > On 1/27/24 01:26, Jonas Karlman wrote: >> Writing to eMMC using DDR52 mode does not work reliably or at all on >> RK356x and RK3588 boards. >> > > > This is related to the old issue I encountered last year with mmc write? Yes, I think it is. I did some testing on RK3566/RK3568/RK3588S/RK3588 boards with different eMMC modules with following result: Read seem to work with all enabled modes: RK3566: MMC legacy, MMC High Speed (26MHz), MMC High Speed (52MHz), MMC DDR52 (52MHz) and HS200 (200MHz) RK3568/RK3588S/RK3588: all above + HS400 (200MHz) and HS400ES (200MHz) However, write had issues with some of the modes: MMC DDR52 (52MHz): all RK35xx HS400/HS400ES: only on RK3568 after changing hs400_txclk_tapnum to 8 HS200 seem to be the most stable write speed that worked on all SoCs. So, dropping MMC DDR52 (52MHz) and enable use of HS200 (200MHz) seem to be the best option to get speedy and working read and write eMMC. Regards, Jonas > > Thanks, > Eugen > >> Fix this by removing the mmc-ddr-1_8v prop from sdhci nodes. >> >> Signed-off-by: Jonas Karlman >> --- >> arch/arm/dts/rk3566-quartz64-a-u-boot.dtsi | 1 - >> arch/arm/dts/rk3566-quartz64-b-u-boot.dtsi | 1 - >> arch/arm/dts/rk3566-radxa-cm3-io-u-boot.dtsi | 1 - >> arch/arm/dts/rk3566-soquartz-u-boot.dtsi | 1 - >> arch/arm/dts/rk3568-lubancat-2-u-boot.dtsi | 1 - >> arch/arm/dts/rk3568-nanopi-r5s-u-boot.dtsi | 1 - >> arch/arm/dts/rk3568-odroid-m1-u-boot.dtsi| 1 - >> arch/arm/dts/rk3568-radxa-e25-u-boot.dtsi| 1 - >> arch/arm/dts/rk3568-rock-3a-u-boot.dtsi | 1 - >> arch/arm/dts/rk3588-rock-5b-u-boot.dtsi | 1 - >> arch/arm/dts/rk3588-turing-rk1-u-boot.dtsi | 1 - >> arch/arm/dts/rk3588s-rock-5a-u-boot.dtsi | 1 - >> 12 files changed, 12 deletions(-) >> [snip]
Pull request smbios-2024-04-rc1-2
Dear Tom, The following changes since commit e7f9e5eb584dd0b5d1b1ff82fe607d6da9940cc6: Merge branch '2024-01-24-assorted-fixes-and-updates' (2024-01-25 11:01:38 -0500) are available in the Git repository at: https://source.denx.de/u-boot/custodians/u-boot-efi.git tags/smbios-2024-04-rc1-2 for you to fetch changes up to 91cc06bcab76dd4b9d07c221b4962283f0984c8e: lib: support SMBIOS3 table in uuid_guid_get_str() (2024-01-26 14:17:55 +0100) Gitlab CI did not report any issues: https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/19447 Pull request smbios-2024-04-rc1-2 * Add missing field to SMBIOS type 2 structure definition * Provide smbios command to display smbios table * Enable the command on sandbox and qemu_arm64_defconfig * Provide a python test for the smbios command * Fix copying SMBIOS 2.1 table from QEMU * Correct EFI TCG measurement to assume SMBIOS 3 table Heinrich Schuchardt (7): smbios: type2: contained object handles cmd: provide command to display SMBIOS information doc: man-page for smbios command test: unit test for smbios command configs: enable smbios command on sandbox configs: enable smbios command on qemu_arm64_defconfig lib: support SMBIOS3 table in uuid_guid_get_str() Masahisa Kojima (2): efi_loader: migrate SMBIOS 3.0 entry point structure for measurement smbios: use struct_table_length to get SMBIOS 2.1 total table length cmd/Kconfig | 6 ++ cmd/Makefile | 1 + cmd/smbios.c | 191 +++ configs/qemu_arm64_defconfig | 1 + configs/sandbox_defconfig| 1 + doc/usage/cmd/smbios.rst | 93 + doc/usage/index.rst | 1 + drivers/misc/qfw_smbios.c| 2 +- include/efi_loader.h | 1 + include/smbios.h | 5 +- lib/efi_loader/efi_tcg2.c| 19 ++-- lib/efi_selftest/efi_selftest_tcg2.c | 97 +- lib/smbios-parser.c | 9 +- lib/uuid.c | 4 + test/py/tests/test_smbios.py | 41 15 files changed, 407 insertions(+), 65 deletions(-) create mode 100644 cmd/smbios.c create mode 100644 doc/usage/cmd/smbios.rst create mode 100644 test/py/tests/test_smbios.py
Re: [PATCH v1] sunxi: R528: add UART1 support
пт, 26 янв. 2024 г. в 20:11, Andre Przywara : > > On Sun, 21 Jan 2024 14:49:08 +0300 > Maksim Kiselev wrote: > > > Add PG6-PG7 pins configuration for the SPL to allow use UART1 > > on boards with the Allwinner R528/T113 family. > > That looks alright. Not super happy to take yet another combination, but > well. Also see below. > > > Signed-off-by: Maksim Kiselev > > Reviewed-by: Andre Przywara > > > --- > > > > I tested this patch on LC-PI-T113 board. > > This board can be found on eBay or Aliexpress, and looks like > > that it is widespread enough to send this patch to the upstream :) > > ... it would be even better to have a DT and defconfig then, right? > Then we would have a user for this code part then. Any chance you could > send something to that effect? Well, I can try to do this. > Are there any BSP code drops, or a schematic or some other documentation? > I couldn't find something on a quick search. The google drive link https://drive.google.com/drive/folders/1lrqDsxtGl8WvU7o547lT9IkHwGyAHXFU is the only “official” documentation that I found. It contains a board scheme, some datasheets and a useless fw image :) > Cheers, > Andre > > > > arch/arm/mach-sunxi/board.c | 4 > > 1 file changed, 4 insertions(+) > > > > diff --git a/arch/arm/mach-sunxi/board.c b/arch/arm/mach-sunxi/board.c > > index 11a4941822..9dedcd45f5 100644 > > --- a/arch/arm/mach-sunxi/board.c > > +++ b/arch/arm/mach-sunxi/board.c > > @@ -159,6 +159,10 @@ static int gpio_init(void) > > sunxi_gpio_set_cfgpin(SUNXI_GPG(3), SUN5I_GPG_UART1); > > sunxi_gpio_set_cfgpin(SUNXI_GPG(4), SUN5I_GPG_UART1); > > sunxi_gpio_set_pull(SUNXI_GPG(4), SUNXI_GPIO_PULL_UP); > > +#elif CONFIG_CONS_INDEX == 2 && defined(CONFIG_MACH_SUN8I_R528) > > + sunxi_gpio_set_cfgpin(SUNXI_GPG(6), 2); > > + sunxi_gpio_set_cfgpin(SUNXI_GPG(7), 2); > > + sunxi_gpio_set_pull(SUNXI_GPG(7), SUNXI_GPIO_PULL_UP); > > #elif CONFIG_CONS_INDEX == 3 && defined(CONFIG_MACH_SUN8I_H3) > > sunxi_gpio_set_cfgpin(SUNXI_GPA(0), SUN8I_H3_GPA_UART2); > > sunxi_gpio_set_cfgpin(SUNXI_GPA(1), SUN8I_H3_GPA_UART2); > Best wishes, Maksim
