Re: [PATCH 01/14] trace: Use notrace for short
Hi Simon,
Am 24.01.2023 um 23:44 schrieb Simon Glass:
Hi Stefan,
On Tue, 24 Jan 2023 at 05:14, Stefan Herbrechtsmeier
wrote:
Hi Simon,
Am 24.01.2023 um 11:55 schrieb Simon Glass:
Hi Stefan,
On Tue, 24 Jan 2023 at 01:12, Stefan Herbrechtsmeier
wrote:
Hi Simon,
Am 22.12.2022 um 00:08 schrieb Simon Glass:
The attribute syntax is quite verbose. Use the macro provided for this
purpose.
Signed-off-by: Simon Glass
---
arch/arm/cpu/armv7/s5p-common/timer.c | 2 +-
arch/arm/mach-exynos/include/mach/cpu.h | 6 +++---
arch/x86/include/asm/global_data.h | 2 +-
arch/x86/include/asm/msr.h | 2 +-
arch/x86/include/asm/u-boot-x86.h | 2 +-
common/spl/spl_fit.c| 1 +
doc/develop/trace.rst | 2 +-
lib/efi_loader/efi_freestanding.c | 4 ++--
lib/trace.c | 26 +++--
9 files changed, 22 insertions(+), 25 deletions(-)
[snip]
diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
index 08da7fed88e..0e026bb3d8e 100644
--- a/common/spl/spl_fit.c
+++ b/common/spl/spl_fit.c
@@ -599,6 +599,7 @@ static int spl_fit_upload_fpga(struct spl_fit_info *ctx,
int node,
debug("Ignoring compatible = %s property\n",
compatible);
}
+ return 0;
ret = fpga_load(devnum, (void *)fpga_image->load_addr,
fpga_image->size, BIT_FULL, flags);
This return makes the spl_fit_upload_fpga function useless. I assume
this change was by accident.
Yes that was a mistake. I'll send a patch.
Thanks.
Do you think it would be possible to create a sandbox driver for the
FPGA uclass? Then we could add some tests for this code.
A sandbox driver exists but the uclass is only an empty dummy.
The fpga subsystem use its own structs to describe the hardware and the
fpga_load function for example is a wrapper for xilinx_load, altera_load
and lattice_load.
Yes, I think fpga_load should become a uclass operation. See how this
is done for other uclasses.
The problem is that the fpga subsystem doesn't use uclass at the moment.
The fpga is init and added by the cpu code (see
arch/arm/mach-zynq/cpu.c). The subsystem functions use the devnum
(index) to select the added structure.
Is it possible to add a ulcass device from cpu code as a first step to
convert the functions into uclass functions.
Regards
Stefan
Re: [PATCH v8 03/10] arm_ffa: introduce Arm FF-A low-level driver
On Tue, Jan 24, 2023 at 03:56:19PM +, Abdellatif El Khlifi wrote: > > I'd like to suggest the creation of a root node called arm_smccc as shown > below. > Not sure if U-Boot already supports the existing binding of PSCI and OPTEE. > This node is the parent of all nodes using SMC calls like FF-A, PSCI, optee, > ... > Well if you want to start with the clean slate for all new platforms, then it is a good way. But you don't need any of the child nodes as they can all be queried and discovered. > The first child to be integrated in the arm_smccc root node is FF-A. > Hopefully, in the future the other features such as PSCI could be integrated > under arm_smccc as well. > You don't need FF-A or any other node if the presence of SMCCC node indicates the support of SMCCC v1.1+(need to go back and check to confirm this). You can query the presence of all the feature. There is no need to have a node for each of the feature supported. That was the whole discussion of this thread IIUC. -- Regards, Sudeep
Re: [PATCH v8 03/10] arm_ffa: introduce Arm FF-A low-level driver
On Tue, Jan 24, 2023 at 03:44:53PM -0700, Simon Glass wrote: > Hi Sudeep, > > On Tue, 24 Jan 2023 at 04:30, Sudeep Holla wrote: > > > > Hi Simon, > > [...] > > Not really. I think I have not conveyed the setup details properly. > > Let me try to explain with 2 hopefully simple examples: > > > > 1. Consider a system with a power controller running its own firmware and > >OS(or any other application software including U-Boot) interacting with > >it to get the required power resource access/modification. > > > >One such thing is CPU operating points(OPP). Typically on old systems, > >these are listing in the DT and OSPM drives them completely. Now on the > >newer systems like the one I am presenting, ideally we need to get the > >list of OPP from the f/w at runtime and use the information to drive it. > > > >Suppose we have these information statically built into DT, then if the > >firmware is upgraded and there is change in the OPP set or if the f/w > >detects some configuration(bios/similar) that requires change in the > >OPP set presented to the OSPM(or any other users), then the static info > >built in the DT is stale or wrong. And hence the use of DT in such a > >configuation or system is not correct unless DT is populated on the fly > >interacting with the firmware before DT is consumed by the users. > > > >This was one example which I was referring when I said I don't want to > >use the DT info over live firmware information. > > So you need to rebuild the firmware component to update the > information? That's not nice. > Well, I understand the firmware component itself can fetch these data from the DT, but not all firmware are built with DT support to start with(for simple reasons like they need to run with very limited ram in orders of few kB). Even if they did, they might have independent DT blob with the data required for the firmware to function. The holy grail of system DT is yet to see the reality IMO. And this rebuild is very much needed during development and updating DT for the data makes no sense to me when the Linux kernel can query the same through standard interfaces defined by the firmware. There can be no argument to no use the interface to fetch the data runtime as it will be most accurate than any other data. DT may have more data or data that firmware decided not to support runtime for various reasons(I think I mentioned couple earlier). So, strict no to static data from the DT and even if some boot code updates it, I trust getting it from the firmware if and when possible. The interface has been added considering all these. It is agnostic of firmware designs and implementation. Assuming DT support in the firmware just makes these unnecessarily hard. > These parameters need to be factored out of the code. The best way to > do that is to put them in the DT. The DT should configure all of > firmware. It should not be necessary to rebuild all the code to update > a few parameters in the build. > Completely agreed in terms of design, but in reality not all implementations want to follow that for reasons of their own. > Also these parameters should not be 'buried' in the code. I'd really > like you to consider the difference between code and data, with the > (configurable) data being in DT. > Again agreed, but this is something we are enforcing in the Linux kernel and U-Boot. It is not universal and IMO it may never be. The firmware interfaces are defined to cope up with these and they are bound to stay. DT can never replace it. Further like ACPI, these firmware interface don't just provide static data, it also supports run-time. So there is some advantage and are here to stay. Preferring DT data for sake of uniformity and simplicity are not going to sway the wind away from these interface to the DT. I am definitely not for it for all the reasons I have already mentioned. > > > > 2. Now the FF-A case, if the list of partitions on the system is listed in > >the DT and there is change in that list due to various reasons(firmware > >upgrade, reconfiguration, resource disabled for a specific reason,...etc) > >then the list will be stale when presented to the user(OSPM/Linux/U-Boot) > >if it is not updated on the fly before the DT data is consumed. > > U-Boot can set this up in the DT if that is what you want, but I think > you are confusing two things: > > - what is available to use (i.e. drivers or code that is compiled in) > - what we actually want to use and how each piece if configured (this > should be handled at runtime) > No I understand all these and advantages you have been mentioning. But there is also other side of the story and that's what I have been trying to group as firmware interface. > Imagine your code is a Linux kernel. We don't hard-code these sorts of > settings in Linux. > Yes definitely and I agree as mentioned quite a few times above. But that doesn't change a bit as already
Re: [PATCH 3/8] arm: dts: k3-am62: Bump dtsi from ti-next
On Tue, 2023-01-24 at 15:47 -0500, Tom Rini wrote: > On Sat, Jan 21, 2023 at 04:54:29PM +0100, Sjoerd Simons wrote: > > > Update the am62 and am625 device-trees from current ti-k3-next ... > These need to come from linux-next or similar, not a TI tree. What's > the > status on upstreaming those changes? With ti-k3-next i was referring to: https://git.kernel.org/pub/scm/linux/kernel/git/ti/linux.git/log/?h=ti-k3-next Which is a maintainer branch that flows into the ti tree that gets pulled into linux next.. Just checked this morning and the relevant commit is now available in linux-next as well (it wasn't just yet when i sent this out). Would you like me to resend this series with the body of this patch updated to reflect that ? -- Sjoerd Simons Collabora Ltd.
[PATCH v2] net: zynq_gem: Wait for SGMII PCS link in zynq_gem_init()
In our system using ZynqMP with an external SGMII PHY it's necessary
to wait for the PCS link and auto negotiation to finish before the xfer
starts. Otherwise the first packet(s) might get dropped, resulting in a
delay at the start of the ethernet transfers.
This is only done when the PHY link is already up, which is done in
phy_startup(). As waiting for the PHY link bits via pcsstatus does not
make much sense, when the link is not available in general (e.g. no
cable connected).
This patch adds the necessary code including a minimal delay of 1 ms
which fixes problems of dropped first packages.
Signed-off-by: Stefan Roese
Cc: Michal Simek
Cc: Katakam Harini
Cc: Ramon Fried
Cc: Sean Anderson
---
v2:
- Move wait for PCS link into the code path only executed for SGMII w/o
fixed-link
- Reduce additional delay from 10 to 1ms
- Change dev_err to dev_warn
drivers/net/zynq_gem.c | 36 +---
1 file changed, 33 insertions(+), 3 deletions(-)
diff --git a/drivers/net/zynq_gem.c b/drivers/net/zynq_gem.c
index 507b19b75975..26565d78dafd 100644
--- a/drivers/net/zynq_gem.c
+++ b/drivers/net/zynq_gem.c
@@ -125,6 +125,10 @@
*/
#define PHY_DETECT_MASK 0x1808
+/* PCS (SGMII) Link Status */
+#define ZYNQ_GEM_PCSSTATUS_LINKBIT(2)
+#define ZYNQ_GEM_PCSSTATUS_ANEG_COMPL BIT(5)
+
/* TX BD status masks */
#define ZYNQ_GEM_TXBUF_FRMLEN_MASK 0x07ff
#define ZYNQ_GEM_TXBUF_EXHAUSTED 0x0800
@@ -164,7 +168,8 @@ struct zynq_gem_regs {
u32 stat[STAT_SIZE]; /* 0x100 - Octects transmitted Low reg */
u32 reserved9[20];
u32 pcscntrl;
- u32 rserved12[36];
+ u32 pcsstatus;
+ u32 rserved12[35];
u32 dcfg6; /* 0x294 Design config reg6 */
u32 reserved7[106];
u32 transmit_q1_ptr; /* 0x440 - Transmit priority queue 1 */
@@ -491,12 +496,37 @@ static int zynq_gem_init(struct udevice *dev)
* Must be written after PCS_SEL is set in nwconfig,
* otherwise writes will not take effect.
*/
- if (priv->phydev->phy_id != PHY_FIXED_ID)
+ if (priv->phydev->phy_id != PHY_FIXED_ID) {
writel(readl(>pcscntrl) |
ZYNQ_GEM_PCS_CTL_ANEG_ENBL,
>pcscntrl);
- else
+ /*
+* When the PHY link is already up, the PCS link needs
+* to get re-checked
+*/
+ if (priv->phydev->link) {
+ u32 pcsstatus;
+
+ pcsstatus = ZYNQ_GEM_PCSSTATUS_LINK |
+ ZYNQ_GEM_PCSSTATUS_ANEG_COMPL;
+ ret = wait_for_bit_le32(>pcsstatus,
+ pcsstatus,
+ true, 5000, true);
+ if (ret) {
+ dev_warn(dev,
+"no PCS (SGMII) link\n");
+ } else {
+ /*
+* Some additional minimal delay seems
+* to be needed so that the first
+* packet will be sent correctly
+*/
+ mdelay(1);
+ }
+ }
+ } else {
writel(readl(>pcscntrl) &
~ZYNQ_GEM_PCS_CTL_ANEG_ENBL,
>pcscntrl);
+ }
}
#endif
--
2.39.1
Re: [PATCH v1 00/12] powerpc: mpc85xx: fixes and updates for socrates board
Hello Tom,
On 24.01.23 19:12, Tom Rini wrote:
> On Tue, Jan 24, 2023 at 06:06:48PM +0100, Heiko Schocher wrote:
>
>> Patchseries is based on 53c47c59e6: ("Merge tag 'dm-pull-18jan23' of
>> https://source.denx.de/u-boot/custodians/u-boot-dm;)
>>
>> It brings back socrates board working with current mainline, and
>> adds also some small updates:
>>
>> - newer U-Boot needs more space in Flash, so set new textbase.
>> adapt default environment
>> - remove Flash on CS1 as not used anymore
>> - support MTDPARTS
>> - add boot retry feature
>> - add support for i2c eeprom
>> - add autbootdelay string
>> - enable protected environement
>> - enable signed fit images boot
>> see thread:
>> https://lists.denx.de/pipermail/u-boot/2023-January/504249.html
>>
>> commit bcc85b96b5ff: ("cmd: source: Support specifying config name")
>>
>> fixes this problem for me!
>>
>> patch 0002-powerpc-mpc85xx-socrates-rework-socrates-build-proce.patch
>> is a combination of patches from Pali
>>
>> http://patchwork.ozlabs.org/project/uboot/patch/20221228200437.30971-1-p...@kernel.org/
>>
>> http://patchwork.ozlabs.org/project/uboot/patch/20221228200437.30971-2-p...@kernel.org/
>>
>> which is a base for patch
>> 0003-powerpc-mpc85xx-drop-socrates-specific-image-creatio.patch
>> which drops socrates board specific image creation and uses standard
>> mpc85xx way by enabling MPC85XX_HAVE_RESET_VECTOR, drop CONFIG_OF_BOARD
>> and use common u-boot.dtsi, so no specials anymore for this board.
>>
>> azure build:
>> https://dev.azure.com/hs0298/hs/_build/results?buildId=99=results
>
> I'm glad you were able to get the board updated and working again. Can
Me too!
> you please add moving this over to plain text based environments (such
> as the keymile family are using now, for example) as part of this?
I can try ... if there are comments for a v2 I integrate it into
v2, if v1 is fine, I send a follow up patch (if this is okay for you?).
Thanks!
bye,
Heiko
--
DENX Software Engineering GmbH, Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de
Re: [PATCH 1/6] drivers: core: ofnode: Add panel timing decode.
Hi Simon,
On 24/01/23 00:12, Simon Glass wrote:
> Hi Nikhil,
>
> On Mon, 23 Jan 2023 at 01:07, Nikhil M Jain wrote:
>>
>> ofnode_decode_display_timing supports reading timing parameters from
>> subnode of display-timings node, for displays supporting multiple
>> resolution, in case if a display supports single resolution, it fails
>> reading directly from display-timings node, to support it
>> ofnode_decode_panel_timing is added.
>>
>> Signed-off-by: Nikhil M Jain
>> ---
>> drivers/core/ofnode.c | 53 +++
>> include/dm/ofnode.h | 12 ++
>> 2 files changed, 65 insertions(+)
>>
>> diff --git a/drivers/core/ofnode.c b/drivers/core/ofnode.c
>> index 4d56b1a767..d06b947516 100644
>> --- a/drivers/core/ofnode.c
>> +++ b/drivers/core/ofnode.c
>> @@ -991,6 +991,59 @@ int ofnode_decode_display_timing(ofnode parent, int
>> index,
>> return ret;
>> }
>>
>> +int ofnode_decode_panel_timing(ofnode parent,
>> + struct display_timing *dt)
>> +{
>> + ofnode timings;
>> + u32 val = 0;
>> + int ret = 0;
>> +
>> + timings = ofnode_find_subnode(parent, "panel-timings");
>> +
>> + if (!ofnode_valid(timings))
>> + return -EINVAL;
>> + memset(dt, 0, sizeof(*dt));
>> + ret |= decode_timing_property(timings, "hback-porch",
>> >hback_porch);
>> + ret |= decode_timing_property(timings, "hfront-porch",
>> >hfront_porch);
>> + ret |= decode_timing_property(timings, "hactive", >hactive);
>> + ret |= decode_timing_property(timings, "hsync-len", >hsync_len);
>> + ret |= decode_timing_property(timings, "vback-porch",
>> >vback_porch);
>> + ret |= decode_timing_property(timings, "vfront-porch",
>> >vfront_porch);
>> + ret |= decode_timing_property(timings, "vactive", >vactive);
>> + ret |= decode_timing_property(timings, "vsync-len", >vsync_len);
>> + ret |= decode_timing_property(timings, "clock-frequency",
>> >pixelclock);
>> + dt->flags = 0;
>> + val = ofnode_read_u32_default(timings, "vsync-active", -1);
>> + if (val != -1) {
>
> if (!ofnode_read_u32(timings, "vsync-active", )) {
>
> Please fix below also
>
>> + dt->flags |= val ? DISPLAY_FLAGS_VSYNC_HIGH :
>> + DISPLAY_FLAGS_VSYNC_LOW;
>> + }
>> + val = ofnode_read_u32_default(timings, "hsync-active", -1);
>> + if (val != -1) {
>> + dt->flags |= val ? DISPLAY_FLAGS_HSYNC_HIGH :
>> + DISPLAY_FLAGS_HSYNC_LOW;
>> + }
>> + val = ofnode_read_u32_default(timings, "de-active", -1);
>> + if (val != -1) {
>> + dt->flags |= val ? DISPLAY_FLAGS_DE_HIGH :
>> + DISPLAY_FLAGS_DE_LOW;
>> + }
>> + val = ofnode_read_u32_default(timings, "pixelclk-active", -1);
>> + if (val != -1) {
>> + dt->flags |= val ? DISPLAY_FLAGS_PIXDATA_POSEDGE :
>> + DISPLAY_FLAGS_PIXDATA_NEGEDGE;
>> + }
>> +
>> + if (ofnode_read_bool(timings, "interlaced"))
>> + dt->flags |= DISPLAY_FLAGS_INTERLACED;
>> + if (ofnode_read_bool(timings, "doublescan"))
>> + dt->flags |= DISPLAY_FLAGS_DOUBLESCAN;
>> + if (ofnode_read_bool(timings, "doubleclk"))
>> + dt->flags |= DISPLAY_FLAGS_DOUBLECLK;
>> +
>> + return ret;
>> +}
>> +
>> const void *ofnode_get_property(ofnode node, const char *propname, int
>> *lenp)
>> {
>> if (ofnode_is_np(node))
>> diff --git a/include/dm/ofnode.h b/include/dm/ofnode.h
>> index fa9865602d..3f6b0843c5 100644
>> --- a/include/dm/ofnode.h
>> +++ b/include/dm/ofnode.h
>> @@ -974,6 +974,18 @@ struct display_timing;
>> int ofnode_decode_display_timing(ofnode node, int index,
>> struct display_timing *config);
>>
>> +/**
>> + * ofnode_decode_panel_timing() - decode display timings
>> + *
>> + * Decode panel timings from the supplied 'panel-timings' node.
>> + *
>> + * @node: 'display-timing' node containing the timing subnodes
>> + * @config:Place to put timings
>> + * Return: 0 if OK, -FDT_ERR_NOTFOUND if not found
>> + */
>> +int ofnode_decode_panel_timing(ofnode node,
>> + struct display_timing *config);
>> +
>> /**
>> * ofnode_get_property() - get a pointer to the value of a node property
>> *
>> --
>> 2.17.1
>>
>
> Please add a test to test/dm/ofnode.c
>
Wanted to confirm whether I need to add a test for ofnode_get_property
or for the ofnode_decode_panel_timings.
> Regards,
> Simon
Thanks
[PATCH] bootstd: Replicate the dtb-filename quirks of distroboot
For EFI, the distro boot scripts search in three different directories
for the .dtb file. The SOC-based filename fallback is supported only for
32-bit ARM.
Adjust the code to mirror this behaviour.
Signed-off-by: Simon Glass
Suggested-by: Mark Kettenis
---
boot/bootmeth_efi.c | 63 ++---
1 file changed, 54 insertions(+), 9 deletions(-)
diff --git a/boot/bootmeth_efi.c b/boot/bootmeth_efi.c
index 67c972e3fe4..f9544846e68 100644
--- a/boot/bootmeth_efi.c
+++ b/boot/bootmeth_efi.c
@@ -147,25 +147,57 @@ static int distro_efi_check(struct udevice *dev, struct
bootflow_iter *iter)
return 0;
}
-static void distro_efi_get_fdt_name(char *fname, int size)
+/**
+ * distro_efi_get_fdt_name() - Get the filename for reading the .dtb file
+ *
+ * @fname: Place to put filename
+ * @size: Max size of filename
+ * @seq: Sequence number, to cycle through options (0=first)
+ * Returns: 0 on success, -ENOENT if the "fdtfile" env var does not exist,
+ * -EINVAL if there are no more options
+ */
+static int distro_efi_get_fdt_name(char *fname, int size, int seq)
{
const char *fdt_fname;
+ const char *prefix;
+
+ /* select the prefix */
+ switch (seq) {
+ case 0:
+ /* this is the default */
+ prefix = "/dtb";
+ break;
+ case 1:
+ prefix = "";
+ break;
+ case 2:
+ prefix = "/dtb/current";
+ break;
+ default:
+ return log_msg_ret("pref", -EINVAL);
+ }
fdt_fname = env_get("fdtfile");
if (fdt_fname) {
- snprintf(fname, size, "dtb/%s", fdt_fname);
+ snprintf(fname, size, "%s/%s", prefix, fdt_fname);
log_debug("Using device tree: %s\n", fname);
- } else {
+
+ /* Use this fallback only for 32-bit ARM */
+ } else if (IS_ENABLED(CONFIG_ARM) && !IS_ENABLED(CONFIG_ARM64)) {
const char *soc = env_get("soc");
const char *board = env_get("board");
const char *boardver = env_get("boardver");
/* cf the code in label_boot() which seems very complex */
- snprintf(fname, size, "dtb/%s%s%s%s.dtb",
+ snprintf(fname, size, "%s/%s%s%s%s.dtb", prefix,
soc ? soc : "", soc ? "-" : "", board ? board : "",
boardver ? boardver : "");
log_debug("Using default device tree: %s\n", fname);
+ } else {
+ return log_msg_ret("env", -ENOENT);
}
+
+ return 0;
}
static int distro_efi_read_bootflow_file(struct udevice *dev,
@@ -174,7 +206,7 @@ static int distro_efi_read_bootflow_file(struct udevice
*dev,
struct blk_desc *desc = NULL;
ulong fdt_addr, size;
char fname[256];
- int ret;
+ int ret, seq;
/* We require a partition table */
if (!bflow->part)
@@ -196,13 +228,22 @@ static int distro_efi_read_bootflow_file(struct udevice
*dev,
if (ret)
return log_msg_ret("read", -EINVAL);
- distro_efi_get_fdt_name(fname, sizeof(fname));
+ fdt_addr = env_get_hex("fdt_addr_r", 0);
+
+ /* try the various available names */
+ ret = -ENOENT;
+ for (seq = 0; ret; seq++) {
+ ret = distro_efi_get_fdt_name(fname, sizeof(fname), seq);
+ if (ret)
+ return log_msg_ret("nam", ret);
+ ret = bootmeth_common_read_file(dev, bflow, fname, fdt_addr,
+ );
+ }
+
bflow->fdt_fname = strdup(fname);
if (!bflow->fdt_fname)
return log_msg_ret("fil", -ENOMEM);
- fdt_addr = env_get_hex("fdt_addr_r", 0);
- ret = bootmeth_common_read_file(dev, bflow, fname, fdt_addr, );
if (!ret) {
bflow->fdt_size = size;
bflow->fdt_addr = fdt_addr;
@@ -277,7 +318,11 @@ static int distro_efi_read_bootflow_net(struct bootflow
*bflow)
fdt_addr = hextoul(fdt_addr_str, NULL);
sprintf(file_addr, "%lx", fdt_addr);
- distro_efi_get_fdt_name(fname, sizeof(fname));
+ /* We only allow the first prefix with PXE */
+ ret = distro_efi_get_fdt_name(fname, sizeof(fname), 0);
+ if (ret)
+ return log_msg_ret("nam", ret);
+
bflow->fdt_fname = strdup(fname);
if (!bflow->fdt_fname)
return log_msg_ret("fil", -ENOMEM);
--
2.39.1.405.gd4c25cc71f-goog
RE: [PATCH 41/41] imx9: support i.MX93 9x9 QSB board
> -Original Message- > From: Fabio Estevam > Sent: 2023年1月24日 3:34 > To: Peng Fan (OSS) > Cc: sba...@denx.de; dl-uboot-imx ; u- > b...@lists.denx.de; Peng Fan > Subject: Re: [PATCH 41/41] imx9: support i.MX93 9x9 QSB board > > Hi > > On Mon, Jan 23, 2023 at 5:30 AM Peng Fan (OSS) > wrote: > > > > From: Peng Fan > > > > Support i.MX93 9x9 Quick Start Board, UART/SD/MMC/I2C supported. > > > > Boot Log as below: > > U-Boot SPL 2023.01-rc3-00069-g7c3dea52355-dirty (Dec 14 2022 - > > 11:46:43 +0800) > > SOC: 0xa0009300 > > LC: 0x40010 > > M33 prepare ok > > The last three lines above are too noisy. Please move them to debug level. [Peng Fan] Ok > > > Normal Boot > > Trying to boot from BOOTROM > > Boot Stage: Primary boot > > image offset 0x8000, pagesize 0x200, ivt offset 0x0 Load image from > > 0x42000 by ROM_API > > NOTICE: BL31: v2.6(release):v2.6-277-g5234dfb98 > > NOTICE: BL31: Built : 10:11:35, Dec 9 2022 > > > > U-Boot 2023.01-rc3-00069-g7c3dea52355-dirty (Dec 14 2022 - 11:46:43 > > +0800) > > > > CPU: i.MX93(52) rev1.0 1700 MHz (running at 1692 MHz) > > CPU: Consumer temperature grade (0C to 95C) at 33C > > Reset cause: POR (0x1) > > Model: NXP i.MX93 9x9 Quick Start Board > > DRAM: 2 GiB > > Core: 51 devices, 18 uclasses, devicetree: separate > > MMC: FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 2 > > Loading Environment from MMC... OK > > In:serial@4438 > > Out: serial@4438 > > Err: serial@4438 > > > > BuildInfo: > > - ELE firmware version 0.0.8-80d3db4b > > What does ELE firmware mean? > > Please add a doc/board/nxp/imx93_qsb.rst with instructions on how to > build U-Boot + all required firmware for this board. [Peng Fan] Sure. > > > +/* Link Definitions */ > > + > > +#define CFG_SYS_INIT_RAM_ADDR 0x8000 > > +#define CFG_SYS_INIT_RAM_SIZE 0x20 > > + > > +#define CFG_SYS_SDRAM_BASE 0x8000 > > +#define PHYS_SDRAM 0x8000 > > +#define PHYS_SDRAM_SIZE0x8000 /* 2GB DDR */ > > + > > +/* Using ULP WDOG for reset */ > > +#define WDOG_BASE_ADDR WDG3_BASE_ADDR > > This should be retrieved from the device tree. [Peng Fan] Ok. If no other major comments, I will post out V2 in a few days. Thanks, Peng.
Pull request: u-boot-sunxi/master for 2023.04
Hi Tom, please pull the first part of the sunxi pull request for this cycle. This contains some fixes, and the first bunch of some clean up patches to get rid of legacy GPIO and PMIC code. Highlight is the DM AXP PMIC driver, which is required to convert some drivers over to use DM regulators, and also is required to get rid of some less optimal PMIC setup code in Trusted Firmware. This isn't enabled by any defconfig yet, but can be enabled manually and works. For the full glory some patches are still missing, and this requires more testing, which would be simpler if the core code is upstream. I couldn't get the gitlab CI to pass, it seemed to time out in the last step, when building all ARM(32) boards. I built all sunxi boards with buildman locally, without issues, so this should be fine. Tested on an H3, A64, R40, A20 and H6 board. If everything goes well, I will send a second part later this week, some patches still need some review and testing. Thanks, Andre The following changes since commit dd31cd58b02729807934cb699b164b1f8736620f: Merge tag 'efi-2023-04-rc1-2' of https://source.denx.de/u-boot/custodians/u-boot-efi (2023-01-20 14:23:20 -0500) are available in the Git repository at: https://source.denx.de/u-boot/custodians/u-boot-sunxi.git master for you to fetch changes up to cd108f2795777d3cca1d0f00c50bb92f766f6591: video: sunxi: dw-hdmi: Read address from DT node (2023-01-23 01:18:31 +) Andre Przywara (9): sunxi: f1c100s: re-enable SYSRESET sunxi: f1c100s: Drop no-MMC hack sunxi: armv8: fel: load only 32-bit values sunxi: h616: lower SPL stack address to avoid BROM data sunxi: fel: drop redundant "control register" save/restore sunxi: mmc: ignore card detect in SPL sunxi: mmc: group non-DM specific functions sunxi: remove CONFIG_MMC?_CD_PIN sunxi: eMMC: support TOC0 on boot partitions Jernej Skrabec (2): video: sunxi: dw-hdmi: Probe driver by compatible video: sunxi: dw-hdmi: Read address from DT node Samuel Holland (4): power: pmic: axp: Provide a variant ID in the driver data power: regulator: Add a driver for AXP PMIC regulators power: pmic: axp: Bind regulators from the DT clk: sunxi: Add DE2 display-related clocks/resets arch/arm/cpu/armv7/sunxi/fel_utils.S | 4 - arch/arm/cpu/armv8/fel_utils.S | 8 +- arch/arm/dts/sunxi-u-boot.dtsi | 2 - arch/arm/mach-sunxi/Kconfig | 27 --- arch/arm/mach-sunxi/board.c | 12 +- configs/A10-OLinuXino-Lime_defconfig | 1 - configs/A10s-OLinuXino-M_defconfig | 2 - configs/A13-OLinuXinoM_defconfig | 1 - configs/A13-OLinuXino_defconfig | 1 - configs/A20-OLinuXino-Lime2-eMMC_defconfig | 1 - configs/A20-OLinuXino-Lime2_defconfig| 1 - configs/A20-OLinuXino-Lime_defconfig | 1 - configs/A20-OLinuXino_MICRO-eMMC_defconfig | 1 - configs/A20-OLinuXino_MICRO_defconfig| 2 - configs/A20-Olimex-SOM-EVB_defconfig | 2 - configs/A20-Olimex-SOM204-EVB-eMMC_defconfig | 1 - configs/A20-Olimex-SOM204-EVB_defconfig | 1 - configs/A33-OLinuXino_defconfig | 1 - configs/Ainol_AW1_defconfig | 1 - configs/Ampe_A76_defconfig | 1 - configs/Bananapi_M2_Ultra_defconfig | 1 - configs/Bananapi_m2m_defconfig | 1 - configs/Cubieboard2_defconfig| 1 - configs/Cubieboard4_defconfig| 1 - configs/Cubieboard_defconfig | 1 - configs/Cubietruck_defconfig | 1 - configs/Empire_electronix_d709_defconfig | 1 - configs/Empire_electronix_m712_defconfig | 1 - configs/Itead_Ibox_A20_defconfig | 1 - configs/Lamobo_R1_defconfig | 1 - configs/Mele_M3_defconfig| 1 - configs/Mele_M5_defconfig| 1 - configs/Merrii_A80_Optimus_defconfig | 1 - configs/Orangepi_mini_defconfig | 2 - configs/Sinlinx_SinA31s_defconfig| 1 - configs/Sinlinx_SinA33_defconfig | 1 - configs/Sunchip_CX-A99_defconfig | 1 - configs/UTOO_P66_defconfig | 1 - configs/Wobo_i5_defconfig| 1 - configs/Yones_Toptech_BD1078_defconfig | 2 - configs/Yones_Toptech_BS1078_V2_defconfig| 1 - configs/bananapi_m2_berry_defconfig | 1 - configs/bananapi_m2_zero_defconfig | 1 - configs/bananapi_m64_defconfig | 1 - configs/beelink_gs1_defconfig| 1 - configs/colorfly_e708_q1_defconfig | 1 - configs/difrnce_dit4350_defconfig| 1 - configs/dserve_dsrv9703c_defconfig | 1 -
Re: [PATCH 3/5] usb: dwc3-generic: Add dependency on SIMPLE_BUS
On 1/24/23 03:53, Kunihiko Hayashi wrote:
Hi Marek,
Hello Hayashi-san,
On 2023/01/24 0:49, Marek Vasut wrote:
On 1/23/23 06:01, Kunihiko Hayashi wrote:
Hi Marek,
Hello Hayashi-san,
[...]
On the other hand, the PXS2 controller for example is not a bus:
arch/arm/dts/uniphier-pxs2.dtsi:
596 _usb0: usb@65a0 {
597 compatible = "socionext,uniphier-dwc3", "snps,dwc3";
598 status = "disabled";
599 reg = <0x65a0 0xcd00>;
...
610 };
I understand. However, this node isn't used in u-boot.
(see below for details)
Is this needed for socionext dwc3 variant to handle the simple-mfd in
e.g. arch/arm/dts/uniphier-pxs3.dtsi :
614 usb-glue@65b0 {
615 compatible = "socionext,uniphier-pxs3-dwc3-glue",
616 "simple-mfd";
?
In case of U-Boot, the glue driver is probed by:
/* FIXME: U-Boot own node */
usb@65b0 {
compatible = "socionext,uniphier-pxs3-dwc3";
And dwc3-uniphier is also declared as UCLASS_SIMPLE_BUS.
Even if using "simple-mfd", this is included in
drivers/core/simple-bus.c
which is declared as UCLASS_SIMPLE_BUS.
If I understand this correctly, node compatible with
"socionext,uniphier-pxs3-dwc3-glue" is not used at all , right ?
Yes.
Original uniphier devicetree has the following usb nodes.
usb@65a0 {
compatible = "snps,dwc3";
};
usb-glue@65b0 {
compatible = "socionext,uniphier-pxs3-dwc3-glue",
"simple-mfd";
};
However, U-Boot dwc3-generic needs to put dwc3 node under the glue node.
Have a look at arch/arm/dts/imx8mq.dtsi which does not use any glue
node, the snps,dwc3 compatible node is directly placed on the soc@0 bus:
1417
1418 usb_dwc3_0: usb@3810 {
1419 compatible = "fsl,imx8mq-dwc3", "snps,dwc3";
1420 reg = <0x3810 0x1>;
1421 clocks = < IMX8MQ_CLK_USB1_CTRL_ROOT>,
Due to this restriction, there is another usb node dedicated to u-boot.
/* FIXME: U-Boot own node */
usb@65b0 { /* glue */
compatible = "socionext,uniphier-pxs3-dwc3";
dwc3@65a0 {
compatible = "snps,dwc3";
};
};
So instead of "socionext,uniphier-pxs3-dwc3-glue", the glue driver
uses "socionext,uniphier-pxs3-dwc3" in U-Boot.
Can we use the same method as imx8mq.dtsi uses, to avoid this special
node workaround ?
Umm, it's curious. It seems imx8mq doesn't have any glue registers and
defines
dwc3 core registers directly.
On the other hand, "fsl,imx8mq-dwc3" is included in dwc3-generic.c, though,
dwc3_glue_bind() calls the driver that the child node shows.
ofnode_for_each_subnode(node, dev_ofnode(parent)) {
...
device_bind_driver_to_node(parent, driver, name,
node, );
...
}
Maybe the child node expects the driver that "snps,dwc3" indicates.
If we use the same method as imx8mq.dtsi, I think there is no way to probe
the driver for "snps,dwc3" in dwc3-generic.c.
BTW, xchi-dwc3.c can handle "snps,dwc3", but it seems this doesn't use
usb/dwc3/ functions (so I'm confusing it).
Let's try the following, please have a look at this change:
https://source.denx.de/u-boot/custodians/u-boot-usb/-/commit/028ad9536e501986f4e19d27f462f81a9ea70bad
The change is difficult to read, use 'git show -w' to ignore space
changes, that might help.
The idea is that the dwc3-generic.c (or dwc3-uniphier.c , placement does
not really matter) binds to "socionext,uniphier-pxs3-dwc3-glue"
compatible first.
Then, the dwc3_glue_ops is extended with a new callback
glue_get_ctrl_dev, which returns the pointer to controller DT node (the
node compatible with "socionext,uniphier-dwc3"). This is used in
dwc3_glue_bind(), which either uses the current implementation with a
loop over all subnodes and tries to find the controller subnode, OR,
calls the glue_get_ctrl_dev callback, obtains controller device node
pointer that way, and runs the inner loop of dwc3_glue_bind() (now
dwc3_glue_bind_common()) only on that pointer.
In either case, the dwc3-generic driver is bound to the controller. You
might need to re-use this trick in dwc3_glue_probe() too.
This should allow you to get rid of the custom DT node too.
Does this work ?
Re: CONFIG_IS_ENABLED vs IS_ENABLED
Hi Troy,
On Tue, 24 Jan 2023 at 16:31, Troy Kisky wrote:
>
>
>
>
> From: Troy Kisky
> Sent: Tuesday, January 24, 2023 2:52 PM
> To: u-boot@lists.denx.de ; sba...@denx.de
> ; tr...@konsulko.com ; feste...@gmail.com
>
> Cc: s...@chromium.org ; ma...@denx.de
> Subject: CONFIG_IS_ENABLED vs IS_ENABLED
>
> Hi Guys
>
> In a recent debugging session, I stumbled across this line
> drivers/mmc/mmc.c: if (CONFIG_IS_ENABLED(MMC_QUIRKS) && mmc->quirks &
> quirk)
>
> which prevents retries in SPL code, and was causing booting from an SD card
> to fail.
> So I wrote a little script to print uses of
> CONFIG_IS_ENABLED(x) which might need to be
> IS_ENABLED(CONFIG_x) like the above one.
>
> Here it is if you want to try it out.
>
> git grep CONFIG_IS_ENABLED|sed -n -e
> "s/\(CONFIG_IS_ENABLED([0-9a-zA-Z_]*)\)/\n\1\n/gp"| \
> sed -n -r "s/CONFIG_IS_ENABLED\(([0-9a-zA-Z_]+)\)/\1/p" |sort -u|xargs -I {} \
> sh -c "git grep -E 'config [ST]PL_{}' | grep -q -E -w '[ST]PL_{}' || git grep
> 'CONFIG_IS_ENABLED({})'"
>
> It prints CONFIG_IS_ENABLED(x) uses where there is no SPL_x or TPL_x.
>
> BR
> Troy
>
> ___
> And here is the opposite check
>
> git grep -w IS_ENABLED|sed -n -e
> "s/\(IS_ENABLED(CONFIG_[0-9a-zA-Z_]*)\)/\n\1\n/gp"| \
> sed -n -r "s/IS_ENABLED\(CONFIG_([0-9a-zA-Z_]+)\)/\1/p" |sort -u|xargs -I {} \
> sh -c "git grep -E 'config [ST]PL_{}' | grep -q -E -w '[ST]PL_{}' && git grep
> 'IS_ENABLED(CONFIG_{})'"
>
>
> It prints uses of IS_ENABLED(CONFIG_x) where CONFIG_SPL_x exists.
Thank you for that. We definitely have quite a few of these.
By a great coincidence I updated moveconfig.py to do something a
little like that:.
https://patchwork.ozlabs.org/project/uboot/patch/20230123220031.3540724-2-...@chromium.org/
Regards,
Simon
>
>
> THIS MESSAGE, ANY ATTACHMENT(S), AND THE INFORMATION CONTAINED HEREIN MAY BE
> PROPRIETARY TO LAIRD CONNECTIVITY, LLC., BOUNDARY DEVICES, LLC. AND/OR
> ANOTHER PARTY, AND MAY FURTHER BE INTENDED TO BE KEPT CONFIDENTIAL. IF YOU
> ARE NOT THE INTENDED RECIPIENT, PLEASE DELETE THE EMAIL AND ANY ATTACHMENTS,
> AND IMMEDIATELY NOTIFY THE SENDER BY RETURN EMAIL. THIS MESSAGE AND ITS
> CONTENTS ARE THE PROPERTY OF LAIRD CONNECTIVITY, LLC. AND BOUNDARY DEVICES,
> LLC. AND MAY NOT BE REPRODUCED OR USED WITHOUT THE EXPRESS WRITTEN CONSENT OF
> LAIRD CONNECTIVITY, LLC. AND BOUNDARY DEVICES, LLC.
Are you able to drop that from mailing list posts, please?
Re: [PATCH v5 3/4] eficonfig: add vertical scroll support
Hi Heinrich, On Wed, 25 Jan 2023 at 00:32, Heinrich Schuchardt wrote: > > On 1/24/23 07:56, Masahisa Kojima wrote: > > The current eficonfig menu does not support vertical scroll, > > so it can not display the menu entries greater than > > the console row size. > > > > This commit add the vertial scroll support. > > The console size is retrieved by > > SIMPLE_TEXT_OUTPUT_PROTOCOL.QueryMode() service, then > > calculates the row size for menu entry by subtracting > > menu header and description row size from the console row size. > > "start" and "end" are added in the efimenu structure. > > "start" keeps the menu entry index at the top, "end" keeps > > the bottom menu entry index. item_data_print() menu function > > only draws the menu entry between "start" and "end". > > > > This commit also fixes the issue that "Save" and "Quit" > > entries can be moved by BKEY_PLUS in change boot order menu. > > > > Signed-off-by: Masahisa Kojima > > Hello Masahisa, > > my example with 100 boot options works fine now. I will get that series > merged. Thank you for merging this series. > > When I edit the boot order and want to save the changes I have to scroll > down up to INT_MAX lines to reach the line with "Save". Can't we just > use CTRL+S for saving in a future patch? > > "ESC/CTRL+C to quit" is misleading: > On the sandbox called without "--terminal raw" CTRL+C leaves U-Boot. How > about removing "/CTRL+C" from that text? OK, I will send patches for both comments. Thanks, Masahisa Kojima > > Best regards > > Heinrich
Re: CONFIG_IS_ENABLED vs IS_ENABLED
From: Troy Kisky
Sent: Tuesday, January 24, 2023 2:52 PM
To: u-boot@lists.denx.de ; sba...@denx.de
; tr...@konsulko.com ; feste...@gmail.com
Cc: s...@chromium.org ; ma...@denx.de
Subject: CONFIG_IS_ENABLED vs IS_ENABLED
Hi Guys
In a recent debugging session, I stumbled across this line
drivers/mmc/mmc.c: if (CONFIG_IS_ENABLED(MMC_QUIRKS) && mmc->quirks &
quirk)
which prevents retries in SPL code, and was causing booting from an SD card to
fail.
So I wrote a little script to print uses of
CONFIG_IS_ENABLED(x) which might need to be
IS_ENABLED(CONFIG_x) like the above one.
Here it is if you want to try it out.
git grep CONFIG_IS_ENABLED|sed -n -e
"s/\(CONFIG_IS_ENABLED([0-9a-zA-Z_]*)\)/\n\1\n/gp"| \
sed -n -r "s/CONFIG_IS_ENABLED\(([0-9a-zA-Z_]+)\)/\1/p" |sort -u|xargs -I {} \
sh -c "git grep -E 'config [ST]PL_{}' | grep -q -E -w '[ST]PL_{}' || git grep
'CONFIG_IS_ENABLED({})'"
It prints CONFIG_IS_ENABLED(x) uses where there is no SPL_x or TPL_x.
BR
Troy
___
And here is the opposite check
git grep -w IS_ENABLED|sed -n -e
"s/\(IS_ENABLED(CONFIG_[0-9a-zA-Z_]*)\)/\n\1\n/gp"| \
sed -n -r "s/IS_ENABLED\(CONFIG_([0-9a-zA-Z_]+)\)/\1/p" |sort -u|xargs -I {} \
sh -c "git grep -E 'config [ST]PL_{}' | grep -q -E -w '[ST]PL_{}' && git grep
'IS_ENABLED(CONFIG_{})'"
It prints uses of IS_ENABLED(CONFIG_x) where CONFIG_SPL_x exists.
BR
Troy
THIS MESSAGE, ANY ATTACHMENT(S), AND THE INFORMATION CONTAINED HEREIN MAY BE
PROPRIETARY TO LAIRD CONNECTIVITY, LLC., BOUNDARY DEVICES, LLC. AND/OR ANOTHER
PARTY, AND MAY FURTHER BE INTENDED TO BE KEPT CONFIDENTIAL. IF YOU ARE NOT THE
INTENDED RECIPIENT, PLEASE DELETE THE EMAIL AND ANY ATTACHMENTS, AND
IMMEDIATELY NOTIFY THE SENDER BY RETURN EMAIL. THIS MESSAGE AND ITS CONTENTS
ARE THE PROPERTY OF LAIRD CONNECTIVITY, LLC. AND BOUNDARY DEVICES, LLC. AND MAY
NOT BE REPRODUCED OR USED WITHOUT THE EXPRESS WRITTEN CONSENT OF LAIRD
CONNECTIVITY, LLC. AND BOUNDARY DEVICES, LLC.
CONFIG_IS_ENABLED vs IS_ENABLED
Hi Guys
In a recent debugging session, I stumbled across this line
drivers/mmc/mmc.c: if (CONFIG_IS_ENABLED(MMC_QUIRKS) && mmc->quirks &
quirk)
which prevents retries in SPL code, and was causing booting from an SD card to
fail.
So I wrote a little script to print uses of
CONFIG_IS_ENABLED(x) which might need to be
IS_ENABLED(CONFIG_x) like the above one.
Here it is if you want to try it out.
git grep CONFIG_IS_ENABLED|sed -n -e
"s/\(CONFIG_IS_ENABLED([0-9a-zA-Z_]*)\)/\n\1\n/gp"| \
sed -n -r "s/CONFIG_IS_ENABLED\(([0-9a-zA-Z_]+)\)/\1/p" |sort -u|xargs -I {} \
sh -c "git grep -E 'config [ST]PL_{}' | grep -q -E -w '[ST]PL_{}' || git grep
'CONFIG_IS_ENABLED({})'"
It prints CONFIG_IS_ENABLED(x) uses where there is no SPL_x or TPL_x.
BR
Troy
THIS MESSAGE, ANY ATTACHMENT(S), AND THE INFORMATION CONTAINED HEREIN MAY BE
PROPRIETARY TO LAIRD CONNECTIVITY, LLC., BOUNDARY DEVICES, LLC. AND/OR ANOTHER
PARTY, AND MAY FURTHER BE INTENDED TO BE KEPT CONFIDENTIAL. IF YOU ARE NOT THE
INTENDED RECIPIENT, PLEASE DELETE THE EMAIL AND ANY ATTACHMENTS, AND
IMMEDIATELY NOTIFY THE SENDER BY RETURN EMAIL. THIS MESSAGE AND ITS CONTENTS
ARE THE PROPERTY OF LAIRD CONNECTIVITY, LLC. AND BOUNDARY DEVICES, LLC. AND MAY
NOT BE REPRODUCED OR USED WITHOUT THE EXPRESS WRITTEN CONSENT OF LAIRD
CONNECTIVITY, LLC. AND BOUNDARY DEVICES, LLC.
Re: [PATCH v2 2/4] sunxi: binman: Move BL31 and SCP firmware addresses to Kconfig
Hi Samuel, On Mon, 23 Jan 2023 at 22:22, Samuel Holland wrote: > > Hi Simon, > > On 1/23/23 12:42, Simon Glass wrote: > > HI Samuel, > > > > On Sun, 22 Jan 2023 at 14:16, Samuel Holland wrote: > >> > >> This is easier to read than the #ifdef staircase, provides better > >> visibility into the memory map (alongside the other Kconfig > >> definitions), and allows these addresses to be reused from code. > >> > >> Signed-off-by: Samuel Holland > >> --- > >> > >> Changes in v2: > >> - New patch for v2, split from the .dtsi changes > >> > >> arch/arm/dts/sunxi-u-boot.dtsi | 24 +++- > >> arch/arm/mach-sunxi/Kconfig| 17 + > >> 2 files changed, 24 insertions(+), 17 deletions(-) > > > > Reviewed-by: Simon Glass > > > > Is this info not in the device tree? > > It is not. These values do not correspond to any hardware property. For > example, on A64/H5/H6, BL31 and SCP share a single "SRAM A2" region. The > division of the SRAM between them was chosen arbitrarily (though now it > is ABI). How would you represent this in the devicetree? I would probably add a new node for the SRAM, with partition information within that, as is done for MTD. Regards, Simon
Re: [PATCH v8 03/10] arm_ffa: introduce Arm FF-A low-level driver
Hi Abdellatif, On Tue, 24 Jan 2023 at 08:56, Abdellatif El Khlifi wrote: > > On Mon, Jan 23, 2023 at 09:32:28AM -0700, Simon Glass wrote: > > Hi Rob, > > > > On Mon, 23 Jan 2023 at 08:13, Rob Herring wrote: > > > > > > On Fri, Jan 20, 2023 at 4:04 PM Simon Glass wrote: > > > > > > > > Hi Rob, > > > > > > > > On Thu, 19 Jan 2023 at 11:11, Rob Herring wrote: > > > > > > > > > > On Thu, Jan 19, 2023 at 10:41 AM Simon Glass > > > > > wrote: > > > > > > > > > > > > Hi Abdellatif, > > > > > > > > > > > > On Thu, 19 Jan 2023 at 09:32, Abdellatif El Khlifi > > > > > > wrote: > > > > > > > > > > > > > > On Wed, Jan 18, 2023 at 08:59:32AM -0500, Tom Rini wrote: > > > > > > > > On Wed, Jan 18, 2023 at 01:46:54PM +, Sudeep Holla wrote: > > > > > > > > > On Wed, Jan 18, 2023 at 12:49 PM Tom Rini > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I guess the problem comes down to, can we have one > > > > > > > > > > discovery method that > > > > > > > > > > everyone shares, or do we have to let everyone invent a new > > > > > > > > > > discovery > > > > > > > > > > method every time? > > > > > > > > > > > > > > > > > > > > > > > > > > > No one needs to invent any discovery method every time if the > > > > > > > > > firmware > > > > > > > > > specification > > > > > > > > > provides one and as Rob mentioned many times in the thread, > > > > > > > > > all new firmware > > > > > > > > > specification must provide one and we are trying to make sure > > > > > > > > > that is > > > > > > > > > the case with all new > > > > > > > > > specs from Arm. > > > > > > > > > > > > > > > > > > > > > > > > > > > > FF-A, Op-tee, U-Boot, coreboot, barebox (and > > > > > > > > > > everyone else I'm unintentionally forgetting) could just > > > > > > > > > > discover these > > > > > > > > > > things via device tree. > > > > > > > > > > > > > > > > > > > > > > > > > > > I leave that to the individual projects to decide and agree > > > > > > > > > but > > > > > > > > > fundamentally if > > > > > > > > > the specification provides a way to discover, not sure why we > > > > > > > > > are even > > > > > > > > > discussing > > > > > > > > > an alternative method here. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Or, we could all write our own code to perform > > > > > > > > > > the discovery. > > > > > > > > > > > > > > > > > > > > > > > > > > > For what reason ? I can understand if there is no discovery > > > > > > > > > mechanism but > > > > > > > > > that's not the > > > > > > > > > case in $subject. > > > > > > > > > > > > > > > > > > > > > > > > > > > > And when RISC-V comes along with similar functionality, > > > > > > > > > > we could probe their device tree and see they've > > > > > > > > > > implemented the same > > > > > > > > > > concept, but a little differently, but still have the > > > > > > > > > > discovery portion > > > > > > > > > > be in the device tree. To which it sounds like your answer > > > > > > > > > > is "not in > > > > > > > > > > the device tree". > > > > > > > > > > > > > > > > > > > > > > > > > > > > I see U-boot seem to have made a decision to create DT node > > > > > > > > > for each and > > > > > > > > > everything > > > > > > > > > that needs to be added to DM which seems bit unfortunate but > > > > > > > > > I don't > > > > > > > > > understand the > > > > > > > > > history/motive/background for it but I respect the decision > > > > > > > > > if it is > > > > > > > > > already made. > > > > > > > > > > > > > > > > > > These firmware interfaces are standard on all Arm platforms > > > > > > > > > and can be > > > > > > > > > discovered > > > > > > > > > based on PSCI/SMCCC. Not using the same and use DT node needs > > > > > > > > > unnecessary > > > > > > > > > addition of DT nodes for all the f/w i/f on all the platforms > > > > > > > > > that need the > > > > > > > > > support when > > > > > > > > > one can be just discovered. > > > > > > > > > > > > > > > > > > Sorry for the sudden appearance on this thread, I was > > > > > > > > > avoiding getting into > > > > > > > > > this but thought > > > > > > > > > I will at least express my opinion and also the way the > > > > > > > > > firmware > > > > > > > > > specifications from Arm is > > > > > > > > > expected to be evolved from now on. With that I will leave it > > > > > > > > > to you and > > > > > > > > > other U-boot > > > > > > > > > maintainers and the community in general to decide the right > > > > > > > > > course in this > > > > > > > > > case. > > > > > > > > > > > > > > > > To be clear, if the position is that "this is what everyone > > > > > > > > else will > > > > > > > > use, really" then yes, we'll follow this in U-Boot. > > > > > > > > > > > > > > Hi Simon, Tom, > > > > > > > > > > > > > > The FF-A transport is a SW bus and is not associated to any HW > > > > > > > peripheral or > > > > > > > undiscoverable base address. > > > > > > > > > > > > > > There is only 1
Re: [PATCH v8 03/10] arm_ffa: introduce Arm FF-A low-level driver
Hi Sudeep, On Tue, 24 Jan 2023 at 04:30, Sudeep Holla wrote: > > Hi Simon, > > On Mon, Jan 23, 2023 at 09:32:19AM -0700, Simon Glass wrote: > > Hi Sudeep, > > > > I'd like to see DT defined across firmware and OS, not just be a Linux > > thing. > > Fair enough. > > > It is a better approach than having little fiefdoms everywhere > > with their own config mechanisms. > > > > Agreed. > > > It seems that you have lots of build-time config in the ARM > > components. > > Not really. I think I have not conveyed the setup details properly. > Let me try to explain with 2 hopefully simple examples: > > 1. Consider a system with a power controller running its own firmware and >OS(or any other application software including U-Boot) interacting with >it to get the required power resource access/modification. > >One such thing is CPU operating points(OPP). Typically on old systems, >these are listing in the DT and OSPM drives them completely. Now on the >newer systems like the one I am presenting, ideally we need to get the >list of OPP from the f/w at runtime and use the information to drive it. > >Suppose we have these information statically built into DT, then if the >firmware is upgraded and there is change in the OPP set or if the f/w >detects some configuration(bios/similar) that requires change in the >OPP set presented to the OSPM(or any other users), then the static info >built in the DT is stale or wrong. And hence the use of DT in such a >configuation or system is not correct unless DT is populated on the fly >interacting with the firmware before DT is consumed by the users. > >This was one example which I was referring when I said I don't want to >use the DT info over live firmware information. So you need to rebuild the firmware component to update the information? That's not nice. These parameters need to be factored out of the code. The best way to do that is to put them in the DT. The DT should configure all of firmware. It should not be necessary to rebuild all the code to update a few parameters in the build. Also these parameters should not be 'buried' in the code. I'd really like you to consider the difference between code and data, with the (configurable) data being in DT. > > 2. Now the FF-A case, if the list of partitions on the system is listed in >the DT and there is change in that list due to various reasons(firmware >upgrade, reconfiguration, resource disabled for a specific reason,...etc) >then the list will be stale when presented to the user(OSPM/Linux/U-Boot) >if it is not updated on the fly before the DT data is consumed. U-Boot can set this up in the DT if that is what you want, but I think you are confusing two things: - what is available to use (i.e. drivers or code that is compiled in) - what we actually want to use and how each piece if configured (this should be handled at runtime) Imagine your code is a Linux kernel. We don't hard-code these sorts of settings in Linux. > > Since in both the cases the firmware provides interface to the users to get > the information at runtime, I am against using the DT as source of > information. Well we should figure out a time or place to talk about this, as I believe this is heading down the wrong path. As firmware gets more complex, we need a unified configuration mechanism and proper visibility into each component and what it is doing. They need to act as a unified whole, not as a collection of blobs that might conflict. Regards, Simon
Re: [PATCH 01/14] trace: Use notrace for short
Hi Stefan,
On Tue, 24 Jan 2023 at 05:14, Stefan Herbrechtsmeier
wrote:
>
> Hi Simon,
>
> Am 24.01.2023 um 11:55 schrieb Simon Glass:
> > Hi Stefan,
> >
> > On Tue, 24 Jan 2023 at 01:12, Stefan Herbrechtsmeier
> > wrote:
> >> Hi Simon,
> >>
> >> Am 22.12.2022 um 00:08 schrieb Simon Glass:
> >>> The attribute syntax is quite verbose. Use the macro provided for this
> >>> purpose.
> >>>
> >>> Signed-off-by: Simon Glass
> >>> ---
> >>>
> >>>arch/arm/cpu/armv7/s5p-common/timer.c | 2 +-
> >>>arch/arm/mach-exynos/include/mach/cpu.h | 6 +++---
> >>>arch/x86/include/asm/global_data.h | 2 +-
> >>>arch/x86/include/asm/msr.h | 2 +-
> >>>arch/x86/include/asm/u-boot-x86.h | 2 +-
> >>>common/spl/spl_fit.c| 1 +
> >>>doc/develop/trace.rst | 2 +-
> >>>lib/efi_loader/efi_freestanding.c | 4 ++--
> >>>lib/trace.c | 26 +++--
> >>>9 files changed, 22 insertions(+), 25 deletions(-)
> >>>
> >> [snip]
> >>
> >>> diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
> >>> index 08da7fed88e..0e026bb3d8e 100644
> >>> --- a/common/spl/spl_fit.c
> >>> +++ b/common/spl/spl_fit.c
> >>> @@ -599,6 +599,7 @@ static int spl_fit_upload_fpga(struct spl_fit_info
> >>> *ctx, int node,
> >>>debug("Ignoring compatible = %s property\n",
> >>> compatible);
> >>>}
> >>> + return 0;
> >>>
> >>>ret = fpga_load(devnum, (void *)fpga_image->load_addr,
> >>>fpga_image->size, BIT_FULL, flags);
> >>
> >> This return makes the spl_fit_upload_fpga function useless. I assume
> >> this change was by accident.
> > Yes that was a mistake. I'll send a patch.
>
> Thanks.
>
> > Do you think it would be possible to create a sandbox driver for the
> > FPGA uclass? Then we could add some tests for this code.
>
> A sandbox driver exists but the uclass is only an empty dummy.
>
> The fpga subsystem use its own structs to describe the hardware and the
> fpga_load function for example is a wrapper for xilinx_load, altera_load
> and lattice_load.
Yes, I think fpga_load should become a uclass operation. See how this
is done for other uclasses.
Regards,
Simon
Re: Trouble pushing to u-boot-tegra
On Tue, Jan 24, 2023 at 09:11:47PM +, Tom Warren wrote: > Tom, > > I haven't had to push an update to master on u-boot-tegra in several months, > but I've got a new PR that needs to go in. I've tried my normal 'git push > ssh://gu-te...@git.denx.de/u-boot-tegra master', but it's not working. > > I get: > > gu-te...@git.denx.de: Permission denied (publickey). > fatal: Could not read from remote repository. > > Please make sure you have the correct access rights > and the repository exists. > > Has something changed in the last (several) months? I've also just upgraded > from 16.04 Ubuntu to 18.04, but everything else is working OK, so I'm not > sure it's all my fault, but it may well be. :) Yes, you should be using https://source.denx.de/u-boot/custodians/u-boot-tegra which you should have access to, but please contact me off-list if you're having problems logging in. -- Tom signature.asc Description: PGP signature
Trouble pushing to u-boot-tegra
Tom, I haven't had to push an update to master on u-boot-tegra in several months, but I've got a new PR that needs to go in. I've tried my normal 'git push ssh://gu-te...@git.denx.de/u-boot-tegra master', but it's not working. I get: gu-te...@git.denx.de: Permission denied (publickey). fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. Has something changed in the last (several) months? I've also just upgraded from 16.04 Ubuntu to 18.04, but everything else is working OK, so I'm not sure it's all my fault, but it may well be. :) Thanks, Tom
Re: [PATCH v3 01/70] dm: core: Correct ordering of uclasses IDs
On Tue, Jan 17, 2023 at 10:47:11AM -0700, Simon Glass wrote: > A few of these are out of order. Fix them. > > Signed-off-by: Simon Glass For the series, applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 7/8] arm: dts: k3-am625-sk: Enable usb ports in u-boot
On Sat, Jan 21, 2023 at 04:54:33PM +0100, Sjoerd Simons wrote: > Enable both usb0 as a peripheral for use with DFU and usb1 as a host > port for usage with e.g. usb storage. > > Signed-off-by: Sjoerd Simons Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature
Re: [PATCH 4/8] arm: dts: k3-am625-sk: Enable emmc in SPL
On Sat, Jan 21, 2023 at 04:54:30PM +0100, Sjoerd Simons wrote: > sdhci0 on the k3-am625-sk is the emmc, enable this in SPL as well to > allow booting from that media. > > Signed-off-by: Sjoerd Simons Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 3/8] arm: dts: k3-am62: Bump dtsi from ti-next
On Sat, Jan 21, 2023 at 04:54:29PM +0100, Sjoerd Simons wrote: > Update the am62 and am625 device-trees from current ti-k3-next (commit > 880932e657f). This needed the following tweaks to the u-boot specific$ > dtsi as well: > - Switch tick-timer to the main_timer as it's now defined in the main dtsi > - Add mdio pins to the cpsw3g pinctrl. It moved to a subnode in the > linux dtsi that u-boot doesn't use/support > > Signed-off-by: Sjoerd Simons These need to come from linux-next or similar, not a TI tree. What's the status on upstreaming those changes? -- Tom signature.asc Description: PGP signature
Re: [PATCH 2/8] arm: mach-k3: am62: Add timer0 id to the dev list
On Sat, Jan 21, 2023 at 04:54:28PM +0100, Sjoerd Simons wrote: > Timer0 is used by u-boot as the tick timer; Add it to the soc devices > list so it can be enabled via the k3 power controller. > > Signed-off-by: Sjoerd Simons Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/8] omap: timer: add ti,am654-timer compatibility
On Sat, Jan 21, 2023 at 04:54:27PM +0100, Sjoerd Simons wrote: > THe TI AM654 timer is compatible with the omap-timer implementation, so > add it to the id list > > Signed-off-by: Sjoerd Simons Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature
[PATCH] board: edgeble: Fix neural-compute-module-2 board name
The board should be RV1126-NEU2 instead RV1126-ECM0.
Fix the wrong name.
Fixes: b8f1ca954013 ("board: rockchip: Add Edgeble Neu2 IO Board")
Signed-off-by: Jagan Teki
---
board/edgeble/neural-compute-module-2/MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/board/edgeble/neural-compute-module-2/MAINTAINERS
b/board/edgeble/neural-compute-module-2/MAINTAINERS
index 38edb3a360..bd2405220f 100644
--- a/board/edgeble/neural-compute-module-2/MAINTAINERS
+++ b/board/edgeble/neural-compute-module-2/MAINTAINERS
@@ -1,4 +1,4 @@
-RV1126-ECM0
+RV1126-NEU2
M: Jagan Teki
S: Maintained
F: board/edgeble/neural-compute-module-2
--
2.25.1
Re: [PATCH 1/7] board: rockchip: Add rk3588 evb board support
On Wed, 25 Jan 2023 at 00:47, wrote: > > From: Joseph Chen > > Add support for rk3588 evaluation board. > > Signed-off-by: Joseph Chen > --- Does it boot with BL31 (bin/rk35/rk3588_bl31_v1.27.elf) from rkbin master branch? I have tried with some information provided to Kever the BL31 seems not working from my side. Can you confirm which BL31 is working? Thanks, Jagan.
[PATCH 7/7] phy: phy-rockchip-snps-pcie3: Add pcie3_phymode setting
From: Jon Lin rk3588 pcie3 phy has a pcie3_phymode to decide how to use the four lanes, add support in dts so that we can customize in dts. The phy has two port and each port has two lane: pcie30_phy_mode[2:0] 2: aggregation 1: bifurcation for port 1 0: bifurcation for port 0 Signed-off-by: Kever Yang Signed-off-by: Jon Lin --- include/dt-bindings/phy/phy-snps-pcie3.h | 21 + 1 file changed, 21 insertions(+) create mode 100644 include/dt-bindings/phy/phy-snps-pcie3.h diff --git a/include/dt-bindings/phy/phy-snps-pcie3.h b/include/dt-bindings/phy/phy-snps-pcie3.h new file mode 100644 index 00..5006947f22 --- /dev/null +++ b/include/dt-bindings/phy/phy-snps-pcie3.h @@ -0,0 +1,21 @@ +/* SPDX-License-Identifier: (GPL-2.0+ OR MIT) */ +/* + * Copyright (c) 2021 Rockchip Electronics Co., Ltd. + */ + +#ifndef _DT_BINDINGS_PHY_SNPS_PCIE3 +#define _DT_BINDINGS_PHY_SNPS_PCIE3 + +/* + * pcie30_phy_mode[2:0] + * bit2: aggregation + * bit1: bifurcation for port 1 + * bit0: bifurcation for port 0 + */ +#define PHY_MODE_PCIE_AGGREGATION 4/* PCIe3x4 */ +#define PHY_MODE_PCIE_NANBNB 0 /* P1:PCIe3x2 + P0:PCIe3x2 */ +#define PHY_MODE_PCIE_NANBBI 1 /* P1:PCIe3x2 + P0:PCIe3x1*2 */ +#define PHY_MODE_PCIE_NABINB 2 /* P1:PCIe3x1*2 + P0:PCIe3x2 */ +#define PHY_MODE_PCIE_NABIBI 3 /* P1:PCIe3x1*2 + P0:PCIe3x1*2 */ + +#endif /* _DT_BINDINGS_PHY_SNPS_PCIE3 */ -- 2.39.1
Re: [u-boot PATCH v2 3/3] arm: dts: k3-am64: Fix CPSW3G ethernet
On Tue, Jan 24, 2023 at 11:43:27AM +0200, Roger Quadros wrote: > As MDIO driver does not support Driver Model, the > pinctrl settings in the MDIO node will not > be applied resulting in PHY not being detected. > > To workaround this we add the MDIO pinctrl in > the CPSW3G node in the -u-boot.dtsi file. > > Add the missing MDIO and RGMII pinctrl nodes in > k3-am642-r5-evm.dts > > Signed-off-by: Roger Quadros Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature
[PATCH 5/7] rockchip: clk: pll: add pll_rk3588 type for RK3588 Soc
From: Elaine Zhang
Signed-off-by: Elaine Zhang
---
arch/arm/include/asm/arch-rockchip/clock.h | 15 ++
drivers/clk/rockchip/clk_pll.c | 231 -
2 files changed, 243 insertions(+), 3 deletions(-)
diff --git a/arch/arm/include/asm/arch-rockchip/clock.h
b/arch/arm/include/asm/arch-rockchip/clock.h
index 52eaf6f5e4..6b09fa0057 100644
--- a/arch/arm/include/asm/arch-rockchip/clock.h
+++ b/arch/arm/include/asm/arch-rockchip/clock.h
@@ -68,6 +68,15 @@ enum rk_clk_id {
.frac = _frac, \
}
+#define RK3588_PLL_RATE(_rate, _p, _m, _s, _k) \
+{ \
+ .rate = _rate##U, \
+ .p = _p,\
+ .m = _m,\
+ .s = _s,\
+ .k = _k,\
+}
+
struct rockchip_pll_rate_table {
unsigned long rate;
unsigned int nr;
@@ -81,6 +90,11 @@ struct rockchip_pll_rate_table {
unsigned int postdiv2;
unsigned int dsmpd;
unsigned int frac;
+ /* for RK3588 */
+ unsigned int m;
+ unsigned int p;
+ unsigned int s;
+ unsigned int k;
};
enum rockchip_pll_type {
@@ -89,6 +103,7 @@ enum rockchip_pll_type {
pll_rk3328,
pll_rk3366,
pll_rk3399,
+ pll_rk3588,
};
struct rockchip_pll_clock {
diff --git a/drivers/clk/rockchip/clk_pll.c b/drivers/clk/rockchip/clk_pll.c
index 09b97cf57a..ac37dd494c 100644
--- a/drivers/clk/rockchip/clk_pll.c
+++ b/drivers/clk/rockchip/clk_pll.c
@@ -41,6 +41,10 @@ enum {
VCO_MIN_HZ = 800 * 100,
OUTPUT_MAX_HZ = 3200U * 100,
OUTPUT_MIN_HZ = 24 * 100,
+ RK3588_VCO_MIN_HZ = 2250U * 100,
+ RK3588_VCO_MAX_HZ = 4500U * 100,
+ RK3588_FOUT_MIN_HZ = 37U * 100,
+ RK3588_FOUT_MAX_HZ = 4500U * 100,
};
#define MIN_FOUTVCO_FREQ (800 * MHZ)
@@ -164,6 +168,66 @@ rockchip_pll_clk_set_by_auto(ulong fin_hz,
return rate_table;
}
+static struct rockchip_pll_rate_table *
+rk3588_pll_clk_set_by_auto(unsigned long fin_hz,
+ unsigned long fout_hz)
+{
+ struct rockchip_pll_rate_table *rate_table = _auto_table;
+ u32 p, m, s;
+ ulong fvco, fref, fout, ffrac;
+
+ if (fin_hz == 0 || fout_hz == 0 || fout_hz == fin_hz)
+ return NULL;
+
+ if (fout_hz > RK3588_FOUT_MAX_HZ || fout_hz < RK3588_FOUT_MIN_HZ)
+ return NULL;
+
+ if (fin_hz / MHZ * MHZ == fin_hz && fout_hz / MHZ * MHZ == fout_hz) {
+ for (s = 0; s <= 6; s++) {
+ fvco = fout_hz << s;
+ if (fvco < RK3588_VCO_MIN_HZ ||
+ fvco > RK3588_VCO_MAX_HZ)
+ continue;
+ for (p = 2; p <= 4; p++) {
+ for (m = 64; m <= 1023; m++) {
+ if (fvco == m * fin_hz / p) {
+ rate_table->p = p;
+ rate_table->m = m;
+ rate_table->s = s;
+ rate_table->k = 0;
+ return rate_table;
+ }
+ }
+ }
+ }
+ pr_err("CANNOT FIND Fout by auto,fout = %lu\n", fout_hz);
+ } else {
+ fout = (fout_hz / MHZ) * MHZ;
+ ffrac = (fout_hz % MHZ);
+ for (s = 0; s <= 6; s++) {
+ fvco = fout << s;
+ if (fvco < RK3588_VCO_MIN_HZ ||
+ fvco > RK3588_VCO_MAX_HZ)
+ continue;
+ for (p = 1; p <= 4; p++) {
+ for (m = 64; m <= 1023; m++) {
+ if (fvco == m * fin_hz / p) {
+ rate_table->p = p;
+ rate_table->m = m;
+ rate_table->s = s;
+ fref = fin_hz / p;
+ fout = (ffrac << s) * 65535;
+ rate_table->k = fout / fref;
+ return rate_table;
+ }
+ }
+ }
+ }
+ pr_err("CANNOT FIND Fout by auto,fout = %lu\n", fout_hz);
+ }
+ return NULL;
+}
+
static
Re: [PATCH] usb: host: ehci-generic: Handle DM_RESET=n case
On 1/24/23 09:07, Patrice CHOTARD wrote:
Hi Marek
Hi,
On 1/23/23 23:32, Marek Vasut wrote:
In case CONFIG_DM_RESET=n, reset_get_bulk() returns -ENOTSUPP.
Do not fail in that case either. This is a valid use case, e.g.
in case the reset driver is a no-op and would only waste space
in the build.
Fixes: 81755b8c20f ("usb: host: ehci-generic: Make resets and clocks optional")
Signed-off-by: Marek Vasut
---
Cc: Andre Przywara
Cc: Patrice Chotard
---
drivers/usb/host/ehci-generic.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/host/ehci-generic.c b/drivers/usb/host/ehci-generic.c
index a765a307a32..83fe701ff67 100644
--- a/drivers/usb/host/ehci-generic.c
+++ b/drivers/usb/host/ehci-generic.c
@@ -81,7 +81,7 @@ static int ehci_usb_probe(struct udevice *dev)
}
err = reset_get_bulk(dev, >resets);
- if (err && err != -ENOENT) {
+ if (err && err != -ENOENT && err != -ENOTSUPP) {
dev_err(dev, "Failed to get resets (err=%d)\n", err);
goto clk_err;
}
A similar patch can be applied for testing return value of clk_get_bulk() ?
In case CONFIG_CLK is not set, clk_get_bulk() can return -ENOSYS.
I would much prefer a proper STIH clock driver however.
And looking at R-Car CPG, I think I will also write a reset controller
driver instead of this patch.
[PATCH 4/7] dt-bindings: clock: rk3588: Add binding header for rk3588
From: Elaine Zhang files origin from kernel tree. Signed-off-by: Zhang Yubing Signed-off-by: Elaine Zhang --- include/dt-bindings/clock/rk3588-cru.h | 1494 ++ include/dt-bindings/power/rk3588-power.h | 69 + 2 files changed, 1563 insertions(+) create mode 100644 include/dt-bindings/clock/rk3588-cru.h create mode 100644 include/dt-bindings/power/rk3588-power.h diff --git a/include/dt-bindings/clock/rk3588-cru.h b/include/dt-bindings/clock/rk3588-cru.h new file mode 100644 index 00..87f35d8da5 --- /dev/null +++ b/include/dt-bindings/clock/rk3588-cru.h @@ -0,0 +1,1494 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +/* + * Copyright (c) 2021 Rockchip Electronics Co. Ltd. + * Author: Elaine Zhang + */ + +#ifndef _DT_BINDINGS_CLK_ROCKCHIP_RK3588_H +#define _DT_BINDINGS_CLK_ROCKCHIP_RK3588_H + +/* cru-clocks indices */ + +/* cru plls */ +#define PLL_B0PLL 1 +#define PLL_B1PLL 2 +#define PLL_LPLL 3 +#define PLL_V0PLL 4 +#define PLL_AUPLL 5 +#define PLL_CPLL 6 +#define PLL_GPLL 7 +#define PLL_NPLL 8 +#define PLL_PPLL 9 +#define ARMCLK_L 10 +#define ARMCLK_B01 11 +#define ARMCLK_B23 12 + +/* cru clocks */ +#define PCLK_BIGCORE0_ROOT 20 +#define PCLK_BIGCORE0_PVTM 21 +#define PCLK_BIGCORE1_ROOT 22 +#define PCLK_BIGCORE1_PVTM 23 +#define PCLK_DSU_S_ROOT24 +#define PCLK_DSU_ROOT 25 +#define PCLK_DSU_NS_ROOT 26 +#define PCLK_LITCORE_PVTM 27 +#define PCLK_DBG 28 +#define PCLK_DSU 29 +#define PCLK_S_DAPLITE 30 +#define PCLK_M_DAPLITE 31 +#define MBIST_MCLK_PDM132 +#define MBIST_CLK_ACDCDIG 33 +#define HCLK_I2S2_2CH 34 +#define HCLK_I2S3_2CH 35 +#define CLK_I2S2_2CH_SRC 36 +#define CLK_I2S2_2CH_FRAC 37 +#define CLK_I2S2_2CH 38 +#define MCLK_I2S2_2CH 39 +#define I2S2_2CH_MCLKOUT 40 +#define CLK_DAC_ACDCDIG41 +#define CLK_I2S3_2CH_SRC 42 +#define CLK_I2S3_2CH_FRAC 43 +#define CLK_I2S3_2CH 44 +#define MCLK_I2S3_2CH 45 +#define I2S3_2CH_MCLKOUT 46 +#define PCLK_ACDCDIG 47 +#define HCLK_I2S0_8CH 48 +#define CLK_I2S0_8CH_TX_SRC49 +#define CLK_I2S0_8CH_TX_FRAC 50 +#define MCLK_I2S0_8CH_TX 51 +#define CLK_I2S0_8CH_TX52 +#define CLK_I2S0_8CH_RX_SRC53 +#define CLK_I2S0_8CH_RX_FRAC 54 +#define MCLK_I2S0_8CH_RX 55 +#define CLK_I2S0_8CH_RX56 +#define I2S0_8CH_MCLKOUT 57 +#define HCLK_PDM1 58 +#define MCLK_PDM1 59 +#define HCLK_AUDIO_ROOT60 +#define PCLK_AUDIO_ROOT61 +#define HCLK_SPDIF062 +#define CLK_SPDIF0_SRC 63 +#define CLK_SPDIF0_FRAC64 +#define MCLK_SPDIF065 +#define CLK_SPDIF0 66 +#define CLK_SPDIF1 67 +#define HCLK_SPDIF168 +#define CLK_SPDIF1_SRC 69 +#define CLK_SPDIF1_FRAC70 +#define MCLK_SPDIF171 +#define ACLK_AV1_ROOT 72 +#define ACLK_AV1 73 +#define PCLK_AV1_ROOT 74 +#define PCLK_AV1 75 +#define PCLK_MAILBOX0 76 +#define PCLK_MAILBOX1 77 +#define PCLK_MAILBOX2 78 +#define PCLK_PMU2 79 +#define PCLK_PMUCM0_INTMUX 80 +#define PCLK_DDRCM0_INTMUX 81 +#define PCLK_TOP 82 +#define PCLK_PWM1 83 +#define CLK_PWM1 84 +#define CLK_PWM1_CAPTURE 85 +#define PCLK_PWM2 86 +#define CLK_PWM2 87 +#define CLK_PWM2_CAPTURE 88 +#define PCLK_PWM3 89 +#define CLK_PWM3 90 +#define CLK_PWM3_CAPTURE 91 +#define PCLK_BUSTIMER0 92 +#define PCLK_BUSTIMER1 93 +#define CLK_BUS_TIMER_ROOT 94 +#define CLK_BUSTIMER0 95 +#define CLK_BUSTIMER1 96 +#define CLK_BUSTIMER2 97 +#define CLK_BUSTIMER3 98 +#define CLK_BUSTIMER4 99 +#define CLK_BUSTIMER5 100 +#define CLK_BUSTIMER6
[PATCH 3/7] clk: rockchip: rk3588: Add clock driver
From: Elaine Zhang
Add basic clock for rk3588 which including top, peri, mmc,
i2c, pwm, gmac and more clocks init.
Signed-off-by: Elaine Zhang
---
.../include/asm/arch-rockchip/cru_rk3588.h| 408
drivers/clk/rockchip/Makefile |1 +
drivers/clk/rockchip/clk_rk3588.c | 1803 +
3 files changed, 2212 insertions(+)
create mode 100644 arch/arm/include/asm/arch-rockchip/cru_rk3588.h
create mode 100644 drivers/clk/rockchip/clk_rk3588.c
diff --git a/arch/arm/include/asm/arch-rockchip/cru_rk3588.h
b/arch/arm/include/asm/arch-rockchip/cru_rk3588.h
new file mode 100644
index 00..252e33e35e
--- /dev/null
+++ b/arch/arm/include/asm/arch-rockchip/cru_rk3588.h
@@ -0,0 +1,408 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (c) 2020 Rockchip Electronics Co. Ltd.
+ * Author: Elaine Zhang
+ */
+
+#ifndef _ASM_ARCH_CRU_RK3588_H
+#define _ASM_ARCH_CRU_RK3588_H
+
+#define MHz100
+#define KHz1000
+#define OSC_HZ (24 * MHz)
+
+#define LPLL_HZ(816 * MHz)
+#define GPLL_HZ(1188 * MHz)
+#define CPLL_HZ(1500 * MHz)
+#define NPLL_HZ (850 * MHz)
+#define PPLL_HZ(100 * MHz)
+
+/* RK3588 pll id */
+enum rk3588_pll_id {
+ B0PLL,
+ B1PLL,
+ LPLL,
+ CPLL,
+ GPLL,
+ NPLL,
+ V0PLL,
+ AUPLL,
+ PPLL,
+ PLL_COUNT,
+};
+
+struct rk3588_clk_info {
+ unsigned long id;
+ char *name;
+ bool is_cru;
+};
+
+struct rk3588_clk_priv {
+ struct rk3588_cru *cru;
+ struct rk3588_grf *grf;
+ ulong ppll_hz;
+ ulong gpll_hz;
+ ulong cpll_hz;
+ ulong npll_hz;
+ ulong v0pll_hz;
+ ulong aupll_hz;
+ ulong armclk_hz;
+ ulong armclk_enter_hz;
+ ulong armclk_init_hz;
+ bool sync_kernel;
+ bool set_armclk_rate;
+};
+
+struct rk3588_pll {
+ unsigned int con0;
+ unsigned int con1;
+ unsigned int con2;
+ unsigned int con3;
+ unsigned int con4;
+ unsigned int reserved0[3];
+};
+
+struct rk3588_cru {
+ struct rk3588_pll pll[18];
+ unsigned int reserved0[16];/* Address Offset: 0x0240 */
+ unsigned int mode_con00;/* Address Offset: 0x0280 */
+ unsigned int reserved1[31];/* Address Offset: 0x0284 */
+ unsigned int clksel_con[178]; /* Address Offset: 0x0300 */
+ unsigned int reserved2[142];/* Address Offset: 0x05c8 */
+ unsigned int clkgate_con[78];/* Address Offset: 0x0800 */
+ unsigned int reserved3[50];/* Address Offset: 0x0938 */
+ unsigned int softrst_con[78];/* Address Offset: 0x0400 */
+ unsigned int reserved4[50];/* Address Offset: 0x0b38 */
+ unsigned int glb_cnt_th;/* Address Offset: 0x0c00 */
+ unsigned int glb_rst_st;/* Address Offset: 0x0c04 */
+ unsigned int glb_srst_fst;/* Address Offset: 0x0c08 */
+ unsigned int glb_srsr_snd; /* Address Offset: 0x0c0c */
+ unsigned int glb_rst_con;/* Address Offset: 0x0c10 */
+ unsigned int reserved5[4];/* Address Offset: 0x0c14 */
+ unsigned int sdio_con[2];/* Address Offset: 0x0c24 */
+ unsigned int reserved7;/* Address Offset: 0x0c2c */
+ unsigned int sdmmc_con[2];/* Address Offset: 0x0c30 */
+ unsigned int reserved8[48562];/* Address Offset: 0x0c38 */
+ unsigned int pmuclksel_con[21]; /* Address Offset: 0x0100 */
+ unsigned int reserved9[299];/* Address Offset: 0x0c38 */
+ unsigned int pmuclkgate_con[9]; /* Address Offset: 0x0100 */
+};
+
+check_member(rk3588_cru, mode_con00, 0x280);
+check_member(rk3588_cru, pmuclksel_con[1], 0x30304);
+
+struct pll_rate_table {
+ unsigned long rate;
+ unsigned int m;
+ unsigned int p;
+ unsigned int s;
+ unsigned int k;
+};
+
+#define RK3588_PLL_CON(x) ((x) * 0x4)
+#define RK3588_MODE_CON0x280
+
+#define RK3588_PHP_CRU_BASE0x8000
+#define RK3588_PMU_CRU_BASE0x3
+#define RK3588_BIGCORE0_CRU_BASE 0x5
+#define RK3588_BIGCORE1_CRU_BASE 0x52000
+#define RK3588_DSU_CRU_BASE0x58000
+
+#define RK3588_PLL_CON(x) ((x) * 0x4)
+#define RK3588_MODE_CON0 0x280
+#define RK3588_CLKSEL_CON(x) ((x) * 0x4 + 0x300)
+#define RK3588_CLKGATE_CON(x) ((x) * 0x4 + 0x800)
+#define RK3588_SOFTRST_CON(x) ((x) * 0x4 + 0xa00)
+#define RK3588_GLB_CNT_TH 0xc00
+#define RK3588_GLB_SRST_FST0xc08
+#define RK3588_GLB_SRST_SND0xc0c
+#define RK3588_GLB_RST_CON 0xc10
+#define RK3588_GLB_RST_ST 0xc04
+#define RK3588_SDIO_CON0 0xC24
+#define RK3588_SDIO_CON1 0xC28
+#define RK3588_SDMMC_CON0 0xC30
+#define RK3588_SDMMC_CON1 0xC34
+
+#define RK3588_PHP_CLKGATE_CON(x) ((x) * 0x4 + RK3588_PHP_CRU_BASE +
0x800)
+#define
[PATCH 2/7] rockchip: Add rk3588 core architecture
From: Joseph Chen
RK3588 is a high-performance and low power octa-core application
processor designed for personal mobile internet device and AIoT
equipments.
Signed-off-by: Joseph Chen
---
arch/arm/include/asm/arch-rk3588/boot0.h | 11 +
arch/arm/include/asm/arch-rk3588/gpio.h | 11 +
arch/arm/include/asm/arch-rockchip/clock.h| 7 +
.../include/asm/arch-rockchip/grf_rk3588.h| 182 ++
.../include/asm/arch-rockchip/ioc_rk3588.h| 102 ++
arch/arm/mach-rockchip/Kconfig| 22 ++
arch/arm/mach-rockchip/Makefile | 1 +
arch/arm/mach-rockchip/rk3588/Kconfig | 32 ++
arch/arm/mach-rockchip/rk3588/Makefile| 9 +
arch/arm/mach-rockchip/rk3588/clk_rk3588.c| 41 +++
arch/arm/mach-rockchip/rk3588/rk3588.c| 330 ++
arch/arm/mach-rockchip/rk3588/syscon_rk3588.c | 31 ++
include/configs/rk3588_common.h | 37 ++
13 files changed, 816 insertions(+)
create mode 100644 arch/arm/include/asm/arch-rk3588/boot0.h
create mode 100644 arch/arm/include/asm/arch-rk3588/gpio.h
create mode 100644 arch/arm/include/asm/arch-rockchip/grf_rk3588.h
create mode 100644 arch/arm/include/asm/arch-rockchip/ioc_rk3588.h
create mode 100644 arch/arm/mach-rockchip/rk3588/Kconfig
create mode 100644 arch/arm/mach-rockchip/rk3588/Makefile
create mode 100644 arch/arm/mach-rockchip/rk3588/clk_rk3588.c
create mode 100644 arch/arm/mach-rockchip/rk3588/rk3588.c
create mode 100644 arch/arm/mach-rockchip/rk3588/syscon_rk3588.c
create mode 100644 include/configs/rk3588_common.h
diff --git a/arch/arm/include/asm/arch-rk3588/boot0.h
b/arch/arm/include/asm/arch-rk3588/boot0.h
new file mode 100644
index 00..dea2b20252
--- /dev/null
+++ b/arch/arm/include/asm/arch-rk3588/boot0.h
@@ -0,0 +1,11 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * (C) Copyright 2021 Rockchip Electronics Co., Ltd
+ */
+
+#ifndef __ASM_ARCH_BOOT0_H__
+#define __ASM_ARCH_BOOT0_H__
+
+#include
+
+#endif
diff --git a/arch/arm/include/asm/arch-rk3588/gpio.h
b/arch/arm/include/asm/arch-rk3588/gpio.h
new file mode 100644
index 00..b48c0a5cf8
--- /dev/null
+++ b/arch/arm/include/asm/arch-rk3588/gpio.h
@@ -0,0 +1,11 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * (C) Copyright 2021 Rockchip Electronics Co., Ltd
+ */
+
+#ifndef __ASM_ARCH_GPIO_H__
+#define __ASM_ARCH_GPIO_H__
+
+#include
+
+#endif
diff --git a/arch/arm/include/asm/arch-rockchip/clock.h
b/arch/arm/include/asm/arch-rockchip/clock.h
index 566bdcc4fa..52eaf6f5e4 100644
--- a/arch/arm/include/asm/arch-rockchip/clock.h
+++ b/arch/arm/include/asm/arch-rockchip/clock.h
@@ -22,6 +22,13 @@ enum {
ROCKCHIP_SYSCON_PMUSGRF,
ROCKCHIP_SYSCON_CIC,
ROCKCHIP_SYSCON_MSCH,
+ ROCKCHIP_SYSCON_PCIE30_PHY_GRF,
+ ROCKCHIP_SYSCON_PHP_GRF,
+ ROCKCHIP_SYSCON_PIPE_PHY0_GRF,
+ ROCKCHIP_SYSCON_PIPE_PHY1_GRF,
+ ROCKCHIP_SYSCON_PIPE_PHY2_GRF,
+ ROCKCHIP_SYSCON_VOP_GRF,
+ ROCKCHIP_SYSCON_VO_GRF,
};
/* Standard Rockchip clock numbers */
diff --git a/arch/arm/include/asm/arch-rockchip/grf_rk3588.h
b/arch/arm/include/asm/arch-rockchip/grf_rk3588.h
new file mode 100644
index 00..51152974b1
--- /dev/null
+++ b/arch/arm/include/asm/arch-rockchip/grf_rk3588.h
@@ -0,0 +1,182 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * (C) Copyright 2021 Rockchip Electronics Co., Ltd
+ */
+
+#ifndef _ASM_ARCH_GRF_RK3588_H
+#define _ASM_ARCH_GRF_RK3588_H
+
+struct rk3588_sys_grf {
+ u32 wdt_con0; /* Address Offset: 0x */
+ u32 reserved0004[3];/* Address Offset: 0x0004 */
+ u32 uart_con0; /* Address Offset: 0x0010 */
+ u32 uart_con1; /* Address Offset: 0x0014 */
+ u32 reserved0018[42]; /* Address Offset: 0x0018 */
+ u32 gic_con0; /* Address Offset: 0x00C0 */
+ u32 reserved00c4[79]; /* Address Offset: 0x00C4 */
+ u32 memcfg_con0;/* Address Offset: 0x0200 */
+ u32 memcfg_con1;/* Address Offset: 0x0204 */
+ u32 memcfg_con2;/* Address Offset: 0x0208 */
+ u32 memcfg_con3;/* Address Offset: 0x020C */
+ u32 memcfg_con4;/* Address Offset: 0x0210 */
+ u32 memcfg_con5;/* Address Offset: 0x0214 */
+ u32 memcfg_con6;/* Address Offset: 0x0218 */
+ u32 memcfg_con7;/* Address Offset: 0x021C */
+ u32 memcfg_con8;/* Address Offset: 0x0220 */
+ u32 memcfg_con9;/* Address Offset: 0x0224 */
+ u32 memcfg_con10; /* Address Offset: 0x0228 */
+ u32 memcfg_con11; /* Address Offset: 0x022C */
+ u32 memcfg_con12; /* Address Offset: 0x0230 */
+ u32
[PATCH 1/7] board: rockchip: Add rk3588 evb board support
From: Joseph Chen Add support for rk3588 evaluation board. Signed-off-by: Joseph Chen --- board/rockchip/evb_rk3588/Kconfig | 15 ++ board/rockchip/evb_rk3588/MAINTAINERS | 6 +++ board/rockchip/evb_rk3588/Makefile | 7 +++ board/rockchip/evb_rk3588/evb_rk3588.c | 4 ++ configs/evb-rk3588_defconfig | 69 ++ include/configs/evb_rk3588.h | 15 ++ 6 files changed, 116 insertions(+) create mode 100644 board/rockchip/evb_rk3588/Kconfig create mode 100644 board/rockchip/evb_rk3588/MAINTAINERS create mode 100644 board/rockchip/evb_rk3588/Makefile create mode 100644 board/rockchip/evb_rk3588/evb_rk3588.c create mode 100644 configs/evb-rk3588_defconfig create mode 100644 include/configs/evb_rk3588.h diff --git a/board/rockchip/evb_rk3588/Kconfig b/board/rockchip/evb_rk3588/Kconfig new file mode 100644 index 00..d38efe61d8 --- /dev/null +++ b/board/rockchip/evb_rk3588/Kconfig @@ -0,0 +1,15 @@ +if TARGET_EVB_RK3588 + +config SYS_BOARD + default "evb_rk3588" + +config SYS_VENDOR + default "rockchip" + +config SYS_CONFIG_NAME + default "evb_rk3588" + +config BOARD_SPECIFIC_OPTIONS # dummy + def_bool y + +endif diff --git a/board/rockchip/evb_rk3588/MAINTAINERS b/board/rockchip/evb_rk3588/MAINTAINERS new file mode 100644 index 00..1a9695458d --- /dev/null +++ b/board/rockchip/evb_rk3588/MAINTAINERS @@ -0,0 +1,6 @@ +EVB-RK3568 +M: Joseph Chen +S: Maintained +F: board/rockchip/evb_rk3588 +F: include/configs/evb_rk3588.h +F: configs/evb-rk3588_defconfig diff --git a/board/rockchip/evb_rk3588/Makefile b/board/rockchip/evb_rk3588/Makefile new file mode 100644 index 00..3946c3565e --- /dev/null +++ b/board/rockchip/evb_rk3588/Makefile @@ -0,0 +1,7 @@ +# +# SPDX-License-Identifier: GPL-2.0+ +# +# Copyright (c) 2021 Rockchip Electronics Co., Ltd +# + +obj-y += evb_rk3588.o diff --git a/board/rockchip/evb_rk3588/evb_rk3588.c b/board/rockchip/evb_rk3588/evb_rk3588.c new file mode 100644 index 00..c2fdf95d9a --- /dev/null +++ b/board/rockchip/evb_rk3588/evb_rk3588.c @@ -0,0 +1,4 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * (C) Copyright 2021 Rockchip Electronics Co., Ltd + */ diff --git a/configs/evb-rk3588_defconfig b/configs/evb-rk3588_defconfig new file mode 100644 index 00..83cddcf2b0 --- /dev/null +++ b/configs/evb-rk3588_defconfig @@ -0,0 +1,69 @@ +CONFIG_ARM=y +CONFIG_SKIP_LOWLEVEL_INIT=y +CONFIG_COUNTER_FREQUENCY=2400 +CONFIG_ARCH_ROCKCHIP=y +CONFIG_TEXT_BASE=0x0020 +CONFIG_SPL_LIBCOMMON_SUPPORT=y +CONFIG_SPL_LIBGENERIC_SUPPORT=y +CONFIG_NR_DRAM_BANKS=2 +CONFIG_DEFAULT_DEVICE_TREE="rk3588-evb" +CONFIG_ROCKCHIP_RK3588=y +CONFIG_SPL_ROCKCHIP_BACK_TO_BROM=y +CONFIG_SPL_ROCKCHIP_COMMON_BOARD=y +CONFIG_SPL_MMC=y +CONFIG_SPL_SERIAL=y +CONFIG_SPL_STACK_R_ADDR=0x60 +CONFIG_TARGET_EVB_RK3588=y +CONFIG_DEBUG_UART_BASE=0xFEB5 +CONFIG_DEBUG_UART_CLOCK=2400 +CONFIG_SYS_LOAD_ADDR=0x400800 +CONFIG_DEBUG_UART=y +CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y +CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x40 +CONFIG_FIT=y +CONFIG_FIT_VERBOSE=y +CONFIG_SPL_LOAD_FIT=y +CONFIG_DEFAULT_FDT_FILE="rockchip/rk3588-evb.dtb" +# CONFIG_DISPLAY_CPUINFO is not set +CONFIG_DISPLAY_BOARDINFO_LATE=y +CONFIG_SPL_MAX_SIZE=0x2 +CONFIG_SPL_PAD_TO=0x7f8000 +CONFIG_SPL_HAS_BSS_LINKER_SECTION=y +CONFIG_SPL_BSS_START_ADDR=0x400 +CONFIG_SPL_BSS_MAX_SIZE=0x4000 +# CONFIG_SPL_RAW_IMAGE_SUPPORT is not set +# CONFIG_SPL_SHARES_INIT_SP_ADDR is not set +CONFIG_SPL_STACK=0x40 +CONFIG_SPL_STACK_R=y +CONFIG_SPL_ATF=y +CONFIG_CMD_GPT=y +CONFIG_CMD_MMC=y +# CONFIG_CMD_SETEXPR is not set +# CONFIG_SPL_DOS_PARTITION is not set +CONFIG_SPL_OF_CONTROL=y +CONFIG_OF_LIVE=y +CONFIG_NET_RANDOM_ETHADDR=y +CONFIG_SPL_REGMAP=y +CONFIG_SPL_SYSCON=y +CONFIG_SPL_CLK=y +CONFIG_ROCKCHIP_GPIO=y +CONFIG_SYS_I2C_ROCKCHIP=y +CONFIG_MISC=y +CONFIG_SUPPORT_EMMC_RPMB=y +CONFIG_MMC_DW=y +CONFIG_MMC_DW_ROCKCHIP=y +CONFIG_MMC_SDHCI=y +CONFIG_MMC_SDHCI_SDMA=y +CONFIG_MMC_SDHCI_ROCKCHIP=y +CONFIG_ETH_DESIGNWARE=y +CONFIG_GMAC_ROCKCHIP=y +CONFIG_REGULATOR_PWM=y +CONFIG_PWM_ROCKCHIP=y +CONFIG_SPL_RAM=y +CONFIG_DM_RESET=y +CONFIG_BAUDRATE=150 +CONFIG_DEBUG_UART_SHIFT=2 +CONFIG_SYS_NS16550_MEM32=y +CONFIG_SYSRESET=y +# CONFIG_BINMAN_FDT is not set +CONFIG_ERRNO_STR=y diff --git a/include/configs/evb_rk3588.h b/include/configs/evb_rk3588.h new file mode 100644 index 00..13411c9609 --- /dev/null +++ b/include/configs/evb_rk3588.h @@ -0,0 +1,15 @@ +/* SPDX-License-Identifier: GPL-2.0+ */ +/* + * (C) Copyright 2016 Rockchip Electronics Co., Ltd + */ + +#ifndef __CONFIGS_RK3588_EVB_H +#define __CONFIGS_RK3588_EVB_H + +#include + +#define ROCKCHIP_DEVICE_SETTINGS \ + "stdout=serial,vidconsole\0" \ + "stderr=serial,vidconsole\0" + +#endif -- 2.39.1
Re: [PATCH] odroid: add CROS_EC to odroid_defconfig
Hi Joost, [ ... ] > > That would be OK too, but if you do that, please use IS_ENABLED() > > rather than #ifdef > > I've tested the alternative, and that works for me as well. I am > slightly in favour of the alternative, because it seems illogical to > require building a driver that is never going to be used. On the other > hand this patch only affects the Odroid U2, and the alternative every > board using an Exnyos chip. > > I'm still wondering why other boards, e.g. the Odroid XU3, are seemingly > (I don't have any) unaffected by this. Odroid-xu4 has the same issue, and the proposed solutions fixes the issue there as well. I also think the alternative `#if IS_ENABLED(CONFIG_CROS_EC)`-solution would be better. Thanks for reporting the issue! Best regards, Henrik Grimler
Re: [PATCH 51/88] omap: Drop unused CONFIG_OMAP_USB_PHY
On Mon, Jan 23, 2023 at 02:59:54PM -0700, Simon Glass wrote: > This option does not exist, so the Makefile rule does nothing. Drop it. > > Signed-off-by: Simon Glass Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature
Re: [PATCH v3 12/70] dm: part: Update test to use mmc2
Hi Tom,
On Tue, 24 Jan 2023 at 12:02, Tom Rini wrote:
>
> On Tue, Jan 24, 2023 at 11:55:32AM -0700, Simon Glass wrote:
> > Hi Tom,
> >
> > On Tue, 24 Jan 2023 at 11:28, Tom Rini wrote:
> > >
> > > On Tue, Jan 24, 2023 at 11:15:15AM -0700, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Tue, 24 Jan 2023 at 08:49, Tom Rini wrote:
> > > > >
> > > > > On Tue, Jan 24, 2023 at 03:56:00AM -0700, Simon Glass wrote:
> > > > > > Hi Tom,
> > > > > >
> > > > > > On Mon, 23 Jan 2023 at 18:39, Tom Rini wrote:
> > > > > > >
> > > > > > > On Tue, Jan 17, 2023 at 10:47:22AM -0700, Simon Glass wrote:
> > > > > > >
> > > > > > > > At present this test sets up a partition table on mmc1. But
> > > > > > > > this is used
> > > > > > > > by the bootstd tests, so it is not possible to run those after
> > > > > > > > this test
> > > > > > > > has run, without restarting the Python test harness.
> > > > > > > >
> > > > > > > > This is inconvenient when running tests repeatedly with 'ut
> > > > > > > > dm'. Move the
> > > > > > > > test to use mmc2, which is not used by anything.
> > > > > > > >
> > > > > > > > Signed-off-by: Simon Glass
> > > > > > >
> > > > > > > When I run tests like this:
> > > > > > > TEST="not sleep and not event_dump and not bootmgr and not
> > > > > > > extension"
> > > > > > > ./tools/buildman/buildman -o /tmp/sandbox -P --board sandbox
> > > > > > > ./test/py/test.py --bd $ARGS --build-dir /tmp/sandbox -k "$TEST"
> > > > > > > -ra
> > > > > > > I get:
> > > > > > > == FAILURES
> > > > > > > ===
> > > > > > > _ test_ut[ut_dm_dm_test_part]
> > > > > > > _
> > > > > > > test/py/tests/test_ut.py:341: in test_ut
> > > > > > > assert output.endswith('Failures: 0')
> > > > > > > E assert False
> > > > > > > E+ where False = > > > > > > 0x2776470>('Failures: 0')
> > > > > > > E+where > > > > > > 0x2776470> = 'Test: dm_test_part: part.c\r\r\n** No device
> > > > > > > specified **\r\r\nCouldn\'t find partition mmc \r\r\n** No
> > > > > > > device ...: 0 == do_test(uts, 2, "1:2", 0): Expected 0x0 (0), got
> > > > > > > 0x1 (1)\r\r\nTest dm_test_part failed 4 times\r\r\nFailures:
> > > > > > > 4'.endswith
> > > > > > > Captured stdout call
> > > > > > > -
> > > > > > > => ut dm dm_test_part
> > > > > > > Test: dm_test_part: part.c
> > > > > > > ** No device specified **
> > > > > > > Couldn't find partition mmc
> > > > > > > ** No device specified **
> > > > > > > Couldn't find partition mmc
> > > > > > > ** No partition table - mmc 0 **
> > > > > > > Couldn't find partition mmc 0
> > > > > > > Could not find "test1" partition
> > > > > > > ** Bad device specification mmc #test1 **
> > > > > > > ** Bad device specification mmc #test1 **
> > > > > > > Couldn't find partition mmc #test1
> > > > > > > ** Bad partition specification mmc 1:0 **
> > > > > > > Couldn't find partition mmc 1:0
> > > > > > > ** Invalid partition 2 **
> > > > > > > Couldn't find partition mmc 1:2
> > > > > > > test/dm/part.c:20, do_test(): expected ==
> > > > > > > part_get_info_by_dev_and_name_or_num("mmc", part_str,
> > > > > > > _dev_desc, _info, whole): Expected 0x2 (2), got
> > > > > > > 0xfffe (-2)
> > > > > > > test/dm/part.c:82, dm_test_part(): 0 == do_test(uts, 2, "1:2",
> > > > > > > 0): Expected 0x0 (0), got 0x1 (1)
> > > > > > > Test: dm_test_part: part.c (flat tree)
> > > > > > > ** No device specified **
> > > > > > > Couldn't find partition mmc
> > > > > > > ** No device specified **
> > > > > > > Couldn't find partition mmc
> > > > > > > ** No partition table - mmc 0 **
> > > > > > > Couldn't find partition mmc 0
> > > > > > > Could not find "test1" partition
> > > > > > > ** Bad device specification mmc #test1 **
> > > > > > > ** Bad device specification mmc #test1 **
> > > > > > > Couldn't find partition mmc #test1
> > > > > > > ** Bad partition specification mmc 1:0 **
> > > > > > > Couldn't find partition mmc 1:0
> > > > > > > ** Invalid partition 2 **
> > > > > > > Couldn't find partition mmc 1:2
> > > > > > > test/dm/part.c:20, do_test(): expected ==
> > > > > > > part_get_info_by_dev_and_name_or_num("mmc", part_str,
> > > > > > > _dev_desc, _info, whole): Expected 0x2 (2), got
> > > > > > > 0xfffe (-2)
> > > > > > > test/dm/part.c:82, dm_test_part(): 0 == do_test(uts, 2, "1:2",
> > > > > > > 0): Expected 0x0 (0), got 0x1 (1)
> > > > > > > Test dm_test_part failed 4 times
> > > > > > > Failures: 4
> > > > > > > =>
> > > > > >
> > > > > > Oh dear. I believe this is an ordering problem. These two patches
> > > > > > need
> > > > > > to be applied together because the first one changes mmc1.img and
> > > > > > the
> > > > > > second one relies on that change:
> > > > > >
> > > > > > part: Add a function to find the first bootable partition
> > > >
Re: [PATCH v3 12/70] dm: part: Update test to use mmc2
On Tue, Jan 24, 2023 at 11:55:32AM -0700, Simon Glass wrote:
> Hi Tom,
>
> On Tue, 24 Jan 2023 at 11:28, Tom Rini wrote:
> >
> > On Tue, Jan 24, 2023 at 11:15:15AM -0700, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Tue, 24 Jan 2023 at 08:49, Tom Rini wrote:
> > > >
> > > > On Tue, Jan 24, 2023 at 03:56:00AM -0700, Simon Glass wrote:
> > > > > Hi Tom,
> > > > >
> > > > > On Mon, 23 Jan 2023 at 18:39, Tom Rini wrote:
> > > > > >
> > > > > > On Tue, Jan 17, 2023 at 10:47:22AM -0700, Simon Glass wrote:
> > > > > >
> > > > > > > At present this test sets up a partition table on mmc1. But this
> > > > > > > is used
> > > > > > > by the bootstd tests, so it is not possible to run those after
> > > > > > > this test
> > > > > > > has run, without restarting the Python test harness.
> > > > > > >
> > > > > > > This is inconvenient when running tests repeatedly with 'ut dm'.
> > > > > > > Move the
> > > > > > > test to use mmc2, which is not used by anything.
> > > > > > >
> > > > > > > Signed-off-by: Simon Glass
> > > > > >
> > > > > > When I run tests like this:
> > > > > > TEST="not sleep and not event_dump and not bootmgr and not
> > > > > > extension"
> > > > > > ./tools/buildman/buildman -o /tmp/sandbox -P --board sandbox
> > > > > > ./test/py/test.py --bd $ARGS --build-dir /tmp/sandbox -k "$TEST" -ra
> > > > > > I get:
> > > > > > == FAILURES
> > > > > > ===
> > > > > > _ test_ut[ut_dm_dm_test_part]
> > > > > > _
> > > > > > test/py/tests/test_ut.py:341: in test_ut
> > > > > > assert output.endswith('Failures: 0')
> > > > > > E assert False
> > > > > > E+ where False = > > > > > 0x2776470>('Failures: 0')
> > > > > > E+where > > > > > 0x2776470> = 'Test: dm_test_part: part.c\r\r\n** No device
> > > > > > specified **\r\r\nCouldn\'t find partition mmc \r\r\n** No
> > > > > > device ...: 0 == do_test(uts, 2, "1:2", 0): Expected 0x0 (0), got
> > > > > > 0x1 (1)\r\r\nTest dm_test_part failed 4 times\r\r\nFailures:
> > > > > > 4'.endswith
> > > > > > Captured stdout call
> > > > > > -
> > > > > > => ut dm dm_test_part
> > > > > > Test: dm_test_part: part.c
> > > > > > ** No device specified **
> > > > > > Couldn't find partition mmc
> > > > > > ** No device specified **
> > > > > > Couldn't find partition mmc
> > > > > > ** No partition table - mmc 0 **
> > > > > > Couldn't find partition mmc 0
> > > > > > Could not find "test1" partition
> > > > > > ** Bad device specification mmc #test1 **
> > > > > > ** Bad device specification mmc #test1 **
> > > > > > Couldn't find partition mmc #test1
> > > > > > ** Bad partition specification mmc 1:0 **
> > > > > > Couldn't find partition mmc 1:0
> > > > > > ** Invalid partition 2 **
> > > > > > Couldn't find partition mmc 1:2
> > > > > > test/dm/part.c:20, do_test(): expected ==
> > > > > > part_get_info_by_dev_and_name_or_num("mmc", part_str,
> > > > > > _dev_desc, _info, whole): Expected 0x2 (2), got 0xfffe
> > > > > > (-2)
> > > > > > test/dm/part.c:82, dm_test_part(): 0 == do_test(uts, 2, "1:2", 0):
> > > > > > Expected 0x0 (0), got 0x1 (1)
> > > > > > Test: dm_test_part: part.c (flat tree)
> > > > > > ** No device specified **
> > > > > > Couldn't find partition mmc
> > > > > > ** No device specified **
> > > > > > Couldn't find partition mmc
> > > > > > ** No partition table - mmc 0 **
> > > > > > Couldn't find partition mmc 0
> > > > > > Could not find "test1" partition
> > > > > > ** Bad device specification mmc #test1 **
> > > > > > ** Bad device specification mmc #test1 **
> > > > > > Couldn't find partition mmc #test1
> > > > > > ** Bad partition specification mmc 1:0 **
> > > > > > Couldn't find partition mmc 1:0
> > > > > > ** Invalid partition 2 **
> > > > > > Couldn't find partition mmc 1:2
> > > > > > test/dm/part.c:20, do_test(): expected ==
> > > > > > part_get_info_by_dev_and_name_or_num("mmc", part_str,
> > > > > > _dev_desc, _info, whole): Expected 0x2 (2), got 0xfffe
> > > > > > (-2)
> > > > > > test/dm/part.c:82, dm_test_part(): 0 == do_test(uts, 2, "1:2", 0):
> > > > > > Expected 0x0 (0), got 0x1 (1)
> > > > > > Test dm_test_part failed 4 times
> > > > > > Failures: 4
> > > > > > =>
> > > > >
> > > > > Oh dear. I believe this is an ordering problem. These two patches need
> > > > > to be applied together because the first one changes mmc1.img and the
> > > > > second one relies on that change:
> > > > >
> > > > > part: Add a function to find the first bootable partition
> > > > > dm: part: Update test to use mmc2
> > > > >
> > > > > I have them quite far apart in the series.
> > > > >
> > > > > I can merge them into one commit, perhaps?
> > > > >
> > > > > >
> > > > > > And further tests down the series also fail / introduce failures,
> > > > > > but
> > > > > > this is the
Re: [PATCH v3 12/70] dm: part: Update test to use mmc2
Hi Tom,
On Tue, 24 Jan 2023 at 11:28, Tom Rini wrote:
>
> On Tue, Jan 24, 2023 at 11:15:15AM -0700, Simon Glass wrote:
> > Hi Tom,
> >
> > On Tue, 24 Jan 2023 at 08:49, Tom Rini wrote:
> > >
> > > On Tue, Jan 24, 2023 at 03:56:00AM -0700, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Mon, 23 Jan 2023 at 18:39, Tom Rini wrote:
> > > > >
> > > > > On Tue, Jan 17, 2023 at 10:47:22AM -0700, Simon Glass wrote:
> > > > >
> > > > > > At present this test sets up a partition table on mmc1. But this is
> > > > > > used
> > > > > > by the bootstd tests, so it is not possible to run those after this
> > > > > > test
> > > > > > has run, without restarting the Python test harness.
> > > > > >
> > > > > > This is inconvenient when running tests repeatedly with 'ut dm'.
> > > > > > Move the
> > > > > > test to use mmc2, which is not used by anything.
> > > > > >
> > > > > > Signed-off-by: Simon Glass
> > > > >
> > > > > When I run tests like this:
> > > > > TEST="not sleep and not event_dump and not bootmgr and not extension"
> > > > > ./tools/buildman/buildman -o /tmp/sandbox -P --board sandbox
> > > > > ./test/py/test.py --bd $ARGS --build-dir /tmp/sandbox -k "$TEST" -ra
> > > > > I get:
> > > > > == FAILURES
> > > > > ===
> > > > > _ test_ut[ut_dm_dm_test_part]
> > > > > _
> > > > > test/py/tests/test_ut.py:341: in test_ut
> > > > > assert output.endswith('Failures: 0')
> > > > > E assert False
> > > > > E+ where False = > > > > 0x2776470>('Failures: 0')
> > > > > E+where
> > > > > = 'Test: dm_test_part: part.c\r\r\n** No device specified
> > > > > **\r\r\nCouldn\'t find partition mmc \r\r\n** No device ...: 0
> > > > > == do_test(uts, 2, "1:2", 0): Expected 0x0 (0), got 0x1 (1)\r\r\nTest
> > > > > dm_test_part failed 4 times\r\r\nFailures: 4'.endswith
> > > > > Captured stdout call
> > > > > -
> > > > > => ut dm dm_test_part
> > > > > Test: dm_test_part: part.c
> > > > > ** No device specified **
> > > > > Couldn't find partition mmc
> > > > > ** No device specified **
> > > > > Couldn't find partition mmc
> > > > > ** No partition table - mmc 0 **
> > > > > Couldn't find partition mmc 0
> > > > > Could not find "test1" partition
> > > > > ** Bad device specification mmc #test1 **
> > > > > ** Bad device specification mmc #test1 **
> > > > > Couldn't find partition mmc #test1
> > > > > ** Bad partition specification mmc 1:0 **
> > > > > Couldn't find partition mmc 1:0
> > > > > ** Invalid partition 2 **
> > > > > Couldn't find partition mmc 1:2
> > > > > test/dm/part.c:20, do_test(): expected ==
> > > > > part_get_info_by_dev_and_name_or_num("mmc", part_str, _dev_desc,
> > > > > _info, whole): Expected 0x2 (2), got 0xfffe (-2)
> > > > > test/dm/part.c:82, dm_test_part(): 0 == do_test(uts, 2, "1:2", 0):
> > > > > Expected 0x0 (0), got 0x1 (1)
> > > > > Test: dm_test_part: part.c (flat tree)
> > > > > ** No device specified **
> > > > > Couldn't find partition mmc
> > > > > ** No device specified **
> > > > > Couldn't find partition mmc
> > > > > ** No partition table - mmc 0 **
> > > > > Couldn't find partition mmc 0
> > > > > Could not find "test1" partition
> > > > > ** Bad device specification mmc #test1 **
> > > > > ** Bad device specification mmc #test1 **
> > > > > Couldn't find partition mmc #test1
> > > > > ** Bad partition specification mmc 1:0 **
> > > > > Couldn't find partition mmc 1:0
> > > > > ** Invalid partition 2 **
> > > > > Couldn't find partition mmc 1:2
> > > > > test/dm/part.c:20, do_test(): expected ==
> > > > > part_get_info_by_dev_and_name_or_num("mmc", part_str, _dev_desc,
> > > > > _info, whole): Expected 0x2 (2), got 0xfffe (-2)
> > > > > test/dm/part.c:82, dm_test_part(): 0 == do_test(uts, 2, "1:2", 0):
> > > > > Expected 0x0 (0), got 0x1 (1)
> > > > > Test dm_test_part failed 4 times
> > > > > Failures: 4
> > > > > =>
> > > >
> > > > Oh dear. I believe this is an ordering problem. These two patches need
> > > > to be applied together because the first one changes mmc1.img and the
> > > > second one relies on that change:
> > > >
> > > > part: Add a function to find the first bootable partition
> > > > dm: part: Update test to use mmc2
> > > >
> > > > I have them quite far apart in the series.
> > > >
> > > > I can merge them into one commit, perhaps?
> > > >
> > > > >
> > > > > And further tests down the series also fail / introduce failures, but
> > > > > this is the first one, and why I thought v2 had more problems.
> > > >
> > > > For some reason I'm not seeing this, but it could be another ordering
> > > > thing. I don't see failures on CI but it only tests the whole.
> > > >
> > > > Let me know what you'd like me to do. I don't currently have a way to
> > > > run tests on every commit, so my testing there is a
Re: [PATCH v3 12/70] dm: part: Update test to use mmc2
On Tue, Jan 24, 2023 at 11:15:15AM -0700, Simon Glass wrote:
> Hi Tom,
>
> On Tue, 24 Jan 2023 at 08:49, Tom Rini wrote:
> >
> > On Tue, Jan 24, 2023 at 03:56:00AM -0700, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Mon, 23 Jan 2023 at 18:39, Tom Rini wrote:
> > > >
> > > > On Tue, Jan 17, 2023 at 10:47:22AM -0700, Simon Glass wrote:
> > > >
> > > > > At present this test sets up a partition table on mmc1. But this is
> > > > > used
> > > > > by the bootstd tests, so it is not possible to run those after this
> > > > > test
> > > > > has run, without restarting the Python test harness.
> > > > >
> > > > > This is inconvenient when running tests repeatedly with 'ut dm'. Move
> > > > > the
> > > > > test to use mmc2, which is not used by anything.
> > > > >
> > > > > Signed-off-by: Simon Glass
> > > >
> > > > When I run tests like this:
> > > > TEST="not sleep and not event_dump and not bootmgr and not extension"
> > > > ./tools/buildman/buildman -o /tmp/sandbox -P --board sandbox
> > > > ./test/py/test.py --bd $ARGS --build-dir /tmp/sandbox -k "$TEST" -ra
> > > > I get:
> > > > == FAILURES
> > > > ===
> > > > _ test_ut[ut_dm_dm_test_part]
> > > > _
> > > > test/py/tests/test_ut.py:341: in test_ut
> > > > assert output.endswith('Failures: 0')
> > > > E assert False
> > > > E+ where False = > > > 0x2776470>('Failures: 0')
> > > > E+where =
> > > > 'Test: dm_test_part: part.c\r\r\n** No device specified
> > > > **\r\r\nCouldn\'t find partition mmc \r\r\n** No device ...: 0 ==
> > > > do_test(uts, 2, "1:2", 0): Expected 0x0 (0), got 0x1 (1)\r\r\nTest
> > > > dm_test_part failed 4 times\r\r\nFailures: 4'.endswith
> > > > Captured stdout call
> > > > -
> > > > => ut dm dm_test_part
> > > > Test: dm_test_part: part.c
> > > > ** No device specified **
> > > > Couldn't find partition mmc
> > > > ** No device specified **
> > > > Couldn't find partition mmc
> > > > ** No partition table - mmc 0 **
> > > > Couldn't find partition mmc 0
> > > > Could not find "test1" partition
> > > > ** Bad device specification mmc #test1 **
> > > > ** Bad device specification mmc #test1 **
> > > > Couldn't find partition mmc #test1
> > > > ** Bad partition specification mmc 1:0 **
> > > > Couldn't find partition mmc 1:0
> > > > ** Invalid partition 2 **
> > > > Couldn't find partition mmc 1:2
> > > > test/dm/part.c:20, do_test(): expected ==
> > > > part_get_info_by_dev_and_name_or_num("mmc", part_str, _dev_desc,
> > > > _info, whole): Expected 0x2 (2), got 0xfffe (-2)
> > > > test/dm/part.c:82, dm_test_part(): 0 == do_test(uts, 2, "1:2", 0):
> > > > Expected 0x0 (0), got 0x1 (1)
> > > > Test: dm_test_part: part.c (flat tree)
> > > > ** No device specified **
> > > > Couldn't find partition mmc
> > > > ** No device specified **
> > > > Couldn't find partition mmc
> > > > ** No partition table - mmc 0 **
> > > > Couldn't find partition mmc 0
> > > > Could not find "test1" partition
> > > > ** Bad device specification mmc #test1 **
> > > > ** Bad device specification mmc #test1 **
> > > > Couldn't find partition mmc #test1
> > > > ** Bad partition specification mmc 1:0 **
> > > > Couldn't find partition mmc 1:0
> > > > ** Invalid partition 2 **
> > > > Couldn't find partition mmc 1:2
> > > > test/dm/part.c:20, do_test(): expected ==
> > > > part_get_info_by_dev_and_name_or_num("mmc", part_str, _dev_desc,
> > > > _info, whole): Expected 0x2 (2), got 0xfffe (-2)
> > > > test/dm/part.c:82, dm_test_part(): 0 == do_test(uts, 2, "1:2", 0):
> > > > Expected 0x0 (0), got 0x1 (1)
> > > > Test dm_test_part failed 4 times
> > > > Failures: 4
> > > > =>
> > >
> > > Oh dear. I believe this is an ordering problem. These two patches need
> > > to be applied together because the first one changes mmc1.img and the
> > > second one relies on that change:
> > >
> > > part: Add a function to find the first bootable partition
> > > dm: part: Update test to use mmc2
> > >
> > > I have them quite far apart in the series.
> > >
> > > I can merge them into one commit, perhaps?
> > >
> > > >
> > > > And further tests down the series also fail / introduce failures, but
> > > > this is the first one, and why I thought v2 had more problems.
> > >
> > > For some reason I'm not seeing this, but it could be another ordering
> > > thing. I don't see failures on CI but it only tests the whole.
> > >
> > > Let me know what you'd like me to do. I don't currently have a way to
> > > run tests on every commit, so my testing there is a bit random. I
> > > normally just build-test the series and then check with CI.
> >
> > Well, your ordering comment is interesting. I bisect'd down to this
> > patch being a problem because with the full series applied I see:
> > ==
Re: [PATCH v3 12/70] dm: part: Update test to use mmc2
Hi Tom,
On Tue, 24 Jan 2023 at 08:49, Tom Rini wrote:
>
> On Tue, Jan 24, 2023 at 03:56:00AM -0700, Simon Glass wrote:
> > Hi Tom,
> >
> > On Mon, 23 Jan 2023 at 18:39, Tom Rini wrote:
> > >
> > > On Tue, Jan 17, 2023 at 10:47:22AM -0700, Simon Glass wrote:
> > >
> > > > At present this test sets up a partition table on mmc1. But this is used
> > > > by the bootstd tests, so it is not possible to run those after this test
> > > > has run, without restarting the Python test harness.
> > > >
> > > > This is inconvenient when running tests repeatedly with 'ut dm'. Move
> > > > the
> > > > test to use mmc2, which is not used by anything.
> > > >
> > > > Signed-off-by: Simon Glass
> > >
> > > When I run tests like this:
> > > TEST="not sleep and not event_dump and not bootmgr and not extension"
> > > ./tools/buildman/buildman -o /tmp/sandbox -P --board sandbox
> > > ./test/py/test.py --bd $ARGS --build-dir /tmp/sandbox -k "$TEST" -ra
> > > I get:
> > > == FAILURES
> > > ===
> > > _ test_ut[ut_dm_dm_test_part]
> > > _
> > > test/py/tests/test_ut.py:341: in test_ut
> > > assert output.endswith('Failures: 0')
> > > E assert False
> > > E+ where False = > > 0x2776470>('Failures: 0')
> > > E+where =
> > > 'Test: dm_test_part: part.c\r\r\n** No device specified **\r\r\nCouldn\'t
> > > find partition mmc \r\r\n** No device ...: 0 == do_test(uts, 2,
> > > "1:2", 0): Expected 0x0 (0), got 0x1 (1)\r\r\nTest dm_test_part failed 4
> > > times\r\r\nFailures: 4'.endswith
> > > Captured stdout call
> > > -
> > > => ut dm dm_test_part
> > > Test: dm_test_part: part.c
> > > ** No device specified **
> > > Couldn't find partition mmc
> > > ** No device specified **
> > > Couldn't find partition mmc
> > > ** No partition table - mmc 0 **
> > > Couldn't find partition mmc 0
> > > Could not find "test1" partition
> > > ** Bad device specification mmc #test1 **
> > > ** Bad device specification mmc #test1 **
> > > Couldn't find partition mmc #test1
> > > ** Bad partition specification mmc 1:0 **
> > > Couldn't find partition mmc 1:0
> > > ** Invalid partition 2 **
> > > Couldn't find partition mmc 1:2
> > > test/dm/part.c:20, do_test(): expected ==
> > > part_get_info_by_dev_and_name_or_num("mmc", part_str, _dev_desc,
> > > _info, whole): Expected 0x2 (2), got 0xfffe (-2)
> > > test/dm/part.c:82, dm_test_part(): 0 == do_test(uts, 2, "1:2", 0):
> > > Expected 0x0 (0), got 0x1 (1)
> > > Test: dm_test_part: part.c (flat tree)
> > > ** No device specified **
> > > Couldn't find partition mmc
> > > ** No device specified **
> > > Couldn't find partition mmc
> > > ** No partition table - mmc 0 **
> > > Couldn't find partition mmc 0
> > > Could not find "test1" partition
> > > ** Bad device specification mmc #test1 **
> > > ** Bad device specification mmc #test1 **
> > > Couldn't find partition mmc #test1
> > > ** Bad partition specification mmc 1:0 **
> > > Couldn't find partition mmc 1:0
> > > ** Invalid partition 2 **
> > > Couldn't find partition mmc 1:2
> > > test/dm/part.c:20, do_test(): expected ==
> > > part_get_info_by_dev_and_name_or_num("mmc", part_str, _dev_desc,
> > > _info, whole): Expected 0x2 (2), got 0xfffe (-2)
> > > test/dm/part.c:82, dm_test_part(): 0 == do_test(uts, 2, "1:2", 0):
> > > Expected 0x0 (0), got 0x1 (1)
> > > Test dm_test_part failed 4 times
> > > Failures: 4
> > > =>
> >
> > Oh dear. I believe this is an ordering problem. These two patches need
> > to be applied together because the first one changes mmc1.img and the
> > second one relies on that change:
> >
> > part: Add a function to find the first bootable partition
> > dm: part: Update test to use mmc2
> >
> > I have them quite far apart in the series.
> >
> > I can merge them into one commit, perhaps?
> >
> > >
> > > And further tests down the series also fail / introduce failures, but
> > > this is the first one, and why I thought v2 had more problems.
> >
> > For some reason I'm not seeing this, but it could be another ordering
> > thing. I don't see failures on CI but it only tests the whole.
> >
> > Let me know what you'd like me to do. I don't currently have a way to
> > run tests on every commit, so my testing there is a bit random. I
> > normally just build-test the series and then check with CI.
>
> Well, your ordering comment is interesting. I bisect'd down to this
> patch being a problem because with the full series applied I see:
> == FAILURES
> ===
> ___ test_ut_dm_init_bootstd
> ___
> test/py/tests/test_ut.py:320: in test_ut_dm_init_bootstd
> setup_bootflow_image(u_boot_console)
> test/py/tests/test_ut.py:226: in
Re: [PATCH v1 00/12] powerpc: mpc85xx: fixes and updates for socrates board
On Tue, Jan 24, 2023 at 06:06:48PM +0100, Heiko Schocher wrote:
> Patchseries is based on 53c47c59e6: ("Merge tag 'dm-pull-18jan23' of
> https://source.denx.de/u-boot/custodians/u-boot-dm;)
>
> It brings back socrates board working with current mainline, and
> adds also some small updates:
>
> - newer U-Boot needs more space in Flash, so set new textbase.
> adapt default environment
> - remove Flash on CS1 as not used anymore
> - support MTDPARTS
> - add boot retry feature
> - add support for i2c eeprom
> - add autbootdelay string
> - enable protected environement
> - enable signed fit images boot
> see thread:
> https://lists.denx.de/pipermail/u-boot/2023-January/504249.html
>
> commit bcc85b96b5ff: ("cmd: source: Support specifying config name")
>
> fixes this problem for me!
>
> patch 0002-powerpc-mpc85xx-socrates-rework-socrates-build-proce.patch
> is a combination of patches from Pali
>
> http://patchwork.ozlabs.org/project/uboot/patch/20221228200437.30971-1-p...@kernel.org/
>
> http://patchwork.ozlabs.org/project/uboot/patch/20221228200437.30971-2-p...@kernel.org/
>
> which is a base for patch
> 0003-powerpc-mpc85xx-drop-socrates-specific-image-creatio.patch
> which drops socrates board specific image creation and uses standard
> mpc85xx way by enabling MPC85XX_HAVE_RESET_VECTOR, drop CONFIG_OF_BOARD
> and use common u-boot.dtsi, so no specials anymore for this board.
>
> azure build:
> https://dev.azure.com/hs0298/hs/_build/results?buildId=99=results
I'm glad you were able to get the board updated and working again. Can
you please add moving this over to plain text based environments (such
as the keymile family are using now, for example) as part of this?
--
Tom
signature.asc
Description: PGP signature
[PATCH v1 12/12] powerpc/mpc85xx: socrates: enable signed fitImages
allow only to boot signed fitimages (and signed u-boot scripts). Signed-off-by: Heiko Schocher --- configs/socrates_defconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/configs/socrates_defconfig b/configs/socrates_defconfig index d4c08f1941..e03c971b5e 100644 --- a/configs/socrates_defconfig +++ b/configs/socrates_defconfig @@ -16,7 +16,9 @@ CONFIG_L2_CACHE=y CONFIG_ENABLE_36BIT_PHYS=y CONFIG_SYS_MONITOR_LEN=786432 CONFIG_FIT=y +CONFIG_FIT_SIGNATURE=y CONFIG_FIT_VERBOSE=y +CONFIG_LEGACY_IMAGE_FORMAT=y CONFIG_OF_BOARD_SETUP=y CONFIG_SYS_MONITOR_BASE=0xFFF4 CONFIG_BOOTDELAY=1 -- 2.37.3
[PATCH v1 11/12] powerpc/mpc85xx: socrates: enable protected Environment
enable protected Environment on socrates board.
Signed-off-by: Heiko Schocher
---
board/socrates/socrates.c | 17 +
configs/socrates_defconfig | 4
include/configs/socrates.h | 2 ++
3 files changed, 23 insertions(+)
diff --git a/board/socrates/socrates.c b/board/socrates/socrates.c
index 1d63c81a9c..02e6afb099 100644
--- a/board/socrates/socrates.c
+++ b/board/socrates/socrates.c
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -221,3 +222,19 @@ int get_serial_clock(void)
{
return 0;
}
+
+enum env_location env_get_location(enum env_operation op, int prio)
+{
+ if (op == ENVOP_SAVE || op == ENVOP_ERASE)
+ return ENVL_FLASH;
+
+ switch (prio) {
+ case 0:
+ return ENVL_NOWHERE;
+ case 1:
+ return ENVL_FLASH;
+ default:
+ return ENVL_UNKNOWN;
+ }
+ return ENVL_UNKNOWN;
+}
diff --git a/configs/socrates_defconfig b/configs/socrates_defconfig
index 8640dc990a..d4c08f1941 100644
--- a/configs/socrates_defconfig
+++ b/configs/socrates_defconfig
@@ -68,9 +68,13 @@
CONFIG_MTDIDS_DEFAULT="nor0=fe00.nor_flash,nand0=socrates_nand"
CONFIG_MTDPARTS_DEFAULT="mtdparts=fe00.nor_flash:13312k(system1),13312k(system2),5120k(data),128k(env),128k(env-red),768k(u-boot);socrates_nand:256M(ubi-data1),-(ubi-data2)"
# CONFIG_CMD_IRQ is not set
CONFIG_OF_CONTROL=y
+CONFIG_ENV_IS_NOWHERE=y
CONFIG_ENV_IS_IN_FLASH=y
CONFIG_SYS_REDUNDAND_ENVIRONMENT=y
CONFIG_ENV_ADDR_REDUND=0xFFF0
+CONFIG_ENV_APPEND=y
+CONFIG_ENV_WRITEABLE_LIST=y
+CONFIG_ENV_ACCESS_IGNORE_FORCE=y
CONFIG_USE_ETHPRIME=y
CONFIG_ETHPRIME="eTSEC0"
CONFIG_SPD_EEPROM=y
diff --git a/include/configs/socrates.h b/include/configs/socrates.h
index e2afba96cd..305914de85 100644
--- a/include/configs/socrates.h
+++ b/include/configs/socrates.h
@@ -171,6 +171,8 @@
SOCRATES_ENV_MTD \
""
+#define CFG_ENV_FLAGS_LIST_STATIC
"ethaddr:mw,eth1addr:mw,system1_addr:xw,serial#:sw,ethact:sw,ethprime:sw"
+
/* pass open firmware flat tree */
#endif /* __CONFIG_H */
--
2.37.3
[PATCH v1 10/12] powerpc/mpc85xx: socrates: add autoboot delay string
add autoboot delay string for socrates board. use sha256 for abort autoboot, use "ao" to abort. Signed-off-by: Heiko Schocher --- configs/socrates_defconfig | 5 + 1 file changed, 5 insertions(+) diff --git a/configs/socrates_defconfig b/configs/socrates_defconfig index 816e59872e..8640dc990a 100644 --- a/configs/socrates_defconfig +++ b/configs/socrates_defconfig @@ -20,6 +20,11 @@ CONFIG_FIT_VERBOSE=y CONFIG_OF_BOARD_SETUP=y CONFIG_SYS_MONITOR_BASE=0xFFF4 CONFIG_BOOTDELAY=1 +CONFIG_AUTOBOOT_KEYED=y +CONFIG_AUTOBOOT_PROMPT="Enter password to abort autoboot in %d seconds!\n" +CONFIG_AUTOBOOT_ENCRYPTION=y +CONFIG_AUTOBOOT_STOP_STR_ENABLE=y +CONFIG_AUTOBOOT_STOP_STR_SHA256="2dd411308b37266d33c9246821adc5aa4002f0091f5e2aece1953789930ad924" CONFIG_BOOT_RETRY=y CONFIG_BOOT_RETRY_TIME=120 CONFIG_RESET_TO_RETRY=y -- 2.37.3
[PATCH v1 09/12] powerpc/mpc85xx: socrates: add support for i2c eeprom at 0x51
add support for i2c eeprom on address 0x51.
Signed-off-by: Heiko Schocher
---
arch/powerpc/dts/socrates-u-boot.dtsi | 10 ++
configs/socrates_defconfig| 4
2 files changed, 14 insertions(+)
diff --git a/arch/powerpc/dts/socrates-u-boot.dtsi
b/arch/powerpc/dts/socrates-u-boot.dtsi
index 67c12f672c..88df031732 100644
--- a/arch/powerpc/dts/socrates-u-boot.dtsi
+++ b/arch/powerpc/dts/socrates-u-boot.dtsi
@@ -6,6 +6,10 @@
#include
/ {
+ aliases {
+ eeprom0 = _eeprom0;
+ };
+
chosen {
stdout-path =
};
@@ -13,6 +17,12 @@
soc8544@e000 {
i2c@3000 {
u-boot,dm-pre-reloc;
+
+ i2c_eeprom0: eeprom@51{
+ compatible = "atmel,24c64";
+ reg = <0x51>;
+ pagesize = <32>;
+ };
};
};
};
diff --git a/configs/socrates_defconfig b/configs/socrates_defconfig
index c4a3fd30d8..816e59872e 100644
--- a/configs/socrates_defconfig
+++ b/configs/socrates_defconfig
@@ -39,6 +39,8 @@ CONFIG_CMD_REGINFO=y
# CONFIG_BOOTM_VXWORKS is not set
CONFIG_SYS_BOOTM_LEN=0x80
CONFIG_CMD_IMLS=y
+CONFIG_CMD_EEPROM=y
+CONFIG_SYS_EEPROM_PAGE_WRITE_BITS=4
CONFIG_CMD_DM=y
CONFIG_CMD_I2C=y
CONFIG_LOADS_ECHO=y
@@ -79,6 +81,8 @@ CONFIG_SYS_BR3_PRELIM=0xC0001881
CONFIG_SYS_OR3_PRELIM=0xFFF0
CONFIG_DM_I2C=y
CONFIG_SYS_I2C_FSL=y
+CONFIG_MISC=y
+CONFIG_I2C_EEPROM=y
# CONFIG_MMC is not set
CONFIG_MTD=y
CONFIG_DM_MTD=y
--
2.37.3
[PATCH v1 08/12] powerpc/mpc85xx: socrates: Add boot retry feature
add boot retry feature and reboot after 120 seconds. Signed-off-by: Heiko Schocher --- configs/socrates_defconfig | 3 +++ 1 file changed, 3 insertions(+) diff --git a/configs/socrates_defconfig b/configs/socrates_defconfig index 770f37a0be..c4a3fd30d8 100644 --- a/configs/socrates_defconfig +++ b/configs/socrates_defconfig @@ -20,6 +20,9 @@ CONFIG_FIT_VERBOSE=y CONFIG_OF_BOARD_SETUP=y CONFIG_SYS_MONITOR_BASE=0xFFF4 CONFIG_BOOTDELAY=1 +CONFIG_BOOT_RETRY=y +CONFIG_BOOT_RETRY_TIME=120 +CONFIG_RESET_TO_RETRY=y CONFIG_USE_BOOTCOMMAND=y CONFIG_BOOTCOMMAND="run boot_nor" CONFIG_USE_PREBOOT=y -- 2.37.3
[PATCH v1 07/12] powerpc/mpc85xx: socrates: drop second flash bank
drop second flash bank, as not used anymore.
Signed-off-by: Heiko Schocher
---
configs/socrates_defconfig | 4
include/configs/socrates.h | 5 ++---
2 files changed, 2 insertions(+), 7 deletions(-)
diff --git a/configs/socrates_defconfig b/configs/socrates_defconfig
index 17c12aed7d..770f37a0be 100644
--- a/configs/socrates_defconfig
+++ b/configs/socrates_defconfig
@@ -68,9 +68,6 @@ CONFIG_CHIP_SELECTS_PER_CTRL=2
CONFIG_SYS_BR0_PRELIM_BOOL=y
CONFIG_SYS_BR0_PRELIM=0xFE001001
CONFIG_SYS_OR0_PRELIM=0xFE30
-CONFIG_SYS_BR1_PRELIM_BOOL=y
-CONFIG_SYS_BR1_PRELIM=0xFC001001
-CONFIG_SYS_OR1_PRELIM=0xFE30
CONFIG_SYS_BR2_PRELIM_BOOL=y
CONFIG_SYS_BR2_PRELIM=0xC80018A1
CONFIG_SYS_OR2_PRELIM=0xFC00
@@ -89,7 +86,6 @@ CONFIG_FLASH_CFI_MTD=y
CONFIG_SYS_FLASH_CFI=y
CONFIG_SYS_FLASH_QUIET_TEST=y
CONFIG_SYS_MAX_FLASH_SECT=256
-CONFIG_SYS_MAX_FLASH_BANKS=2
CONFIG_MTD_RAW_NAND=y
CONFIG_PHY_LXT=y
CONFIG_PHY_MARVELL=y
diff --git a/include/configs/socrates.h b/include/configs/socrates.h
index ed1003158b..e2afba96cd 100644
--- a/include/configs/socrates.h
+++ b/include/configs/socrates.h
@@ -66,10 +66,9 @@
* Flash on the LocalBus
*/
#define CFG_SYS_FLASH0 0xFE00
-#define CFG_SYS_FLASH1 0xFC00
-#define CFG_SYS_FLASH_BANKS_LIST { CFG_SYS_FLASH1, CFG_SYS_FLASH0 }
+#define CFG_SYS_FLASH_BANKS_LIST { CFG_SYS_FLASH0 }
-#define CFG_SYS_LBC_FLASH_BASE CFG_SYS_FLASH1 /* Localbus flash start */
+#define CFG_SYS_LBC_FLASH_BASE CFG_SYS_FLASH0 /* Localbus flash start */
#define CFG_SYS_FLASH_BASE CFG_SYS_LBC_FLASH_BASE /* start of
FLASH*/
#define CFG_SYS_LBC_LCRR 0x00030004/* LB clock ratio reg
*/
--
2.37.3
[PATCH v1 06/12] powerpc/mpc85xx: socrates: add initrd_high default environment variable
we need to set initrd_high to get fitimage booting. Without, U-Boot drops when booting fitimage: ERROR: Failed to allocate 0x59a0b6 bytes below 0x80. ramdisk - allocation error bootm - boot application image from memory Signed-off-by: Heiko Schocher --- include/configs/socrates.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/configs/socrates.h b/include/configs/socrates.h index 67ff370e05..ed1003158b 100644 --- a/include/configs/socrates.h +++ b/include/configs/socrates.h @@ -118,6 +118,7 @@ #defineCFG_EXTRA_ENV_SETTINGS \ "netdev=eth0\0" \ "consdev=ttyS0\0" \ + "initrd_high=0x0300\0" \ "uboot_file=/home/tftp/syscon3/u-boot.bin\0"\ "bootfile=/home/tftp/syscon3/uImage\0" \ "fdt_file=/home/tftp/syscon3/socrates.dtb\0"\ -- 2.37.3
[PATCH v1 05/12] powerpc/mpc85xx: socrates: add MTD partitioning support
setup MTD partitioning through mtdparts variable
and set it to:
mtdparts=fe000.nor:13312k(system1),13312k(system2),5120k(data),128k(env),128k(env-red),768k(u-boot)
and pass this to linux per kernel commandline.
Signed-off-by: Heiko Schocher
---
configs/socrates_defconfig | 5 +
include/configs/socrates.h | 17 +++--
2 files changed, 16 insertions(+), 6 deletions(-)
diff --git a/configs/socrates_defconfig b/configs/socrates_defconfig
index 03e84c3e7e..17c12aed7d 100644
--- a/configs/socrates_defconfig
+++ b/configs/socrates_defconfig
@@ -53,6 +53,9 @@ CONFIG_CMD_PING=y
CONFIG_CMD_SNTP=y
# CONFIG_CMD_HASH is not set
CONFIG_CMD_EXT2=y
+CONFIG_CMD_MTDPARTS=y
+CONFIG_MTDIDS_DEFAULT="nor0=fe00.nor_flash,nand0=socrates_nand"
+CONFIG_MTDPARTS_DEFAULT="mtdparts=fe00.nor_flash:13312k(system1),13312k(system2),5120k(data),128k(env),128k(env-red),768k(u-boot);socrates_nand:256M(ubi-data1),-(ubi-data2)"
# CONFIG_CMD_IRQ is not set
CONFIG_OF_CONTROL=y
CONFIG_ENV_IS_IN_FLASH=y
@@ -78,9 +81,11 @@ CONFIG_DM_I2C=y
CONFIG_SYS_I2C_FSL=y
# CONFIG_MMC is not set
CONFIG_MTD=y
+CONFIG_DM_MTD=y
CONFIG_MTD_NOR_FLASH=y
CONFIG_FLASH_CFI_DRIVER=y
CONFIG_FLASH_SHOW_PROGRESS=0
+CONFIG_FLASH_CFI_MTD=y
CONFIG_SYS_FLASH_CFI=y
CONFIG_SYS_FLASH_QUIET_TEST=y
CONFIG_SYS_MAX_FLASH_SECT=256
diff --git a/include/configs/socrates.h b/include/configs/socrates.h
index 2b35be83ec..67ff370e05 100644
--- a/include/configs/socrates.h
+++ b/include/configs/socrates.h
@@ -110,6 +110,10 @@
*/
#define CFG_SYS_BOOTMAPSZ (8 << 20) /* Initial Memory map for Linux
*/
+#define SOCRATES_ENV_MTD \
+ "mtdids=" CONFIG_MTDIDS_DEFAULT "\0" \
+ "mtdparts=" CONFIG_MTDPARTS_DEFAULT "\0" \
+ "addmtd=setenv bootargs ${bootargs} ${mtdparts}\0"
#defineCFG_EXTRA_ENV_SETTINGS \
"netdev=eth0\0" \
@@ -118,7 +122,7 @@
"bootfile=/home/tftp/syscon3/uImage\0" \
"fdt_file=/home/tftp/syscon3/socrates.dtb\0"\
"initrd_file=/home/tftp/syscon3/uinitrd.gz\0" \
- "uboot_addr=FFF6\0" \
+ "uboot_addr=FFF4\0" \
"kernel_addr=FE00\0"\
"fdt_addr=FE1E\0" \
"ramdisk_addr=FE20\0" \
@@ -134,16 +138,16 @@
"addip=setenv bootargs $bootargs " \
"ip=$ipaddr:$serverip:$gatewayip:$netmask" \
":$hostname:$netdev:off panic=1\0" \
- "boot_nor=run ramargs addcons;" \
+ "boot_nor=run ramargs addcons addmtd;" \
"bootm ${kernel_addr} ${ramdisk_addr} ${fdt_addr}\0"\
"net_nfs=tftp ${kernel_addr_r} ${bootfile}; " \
"tftp ${fdt_addr_r} ${fdt_file}; " \
- "run nfsargs addip addcons;"\
+ "run nfsargs addip addcons addmtd;" \
"bootm ${kernel_addr_r} - ${fdt_addr_r}\0" \
"update_uboot=tftp 10 ${uboot_file};" \
- "protect off fff6 ;"\
- "era fff6 ;"\
- "cp.b 10 fff6 ${filesize};" \
+ "protect off ${uboot_addr} ;" \
+ "era ${uboot_addr} ;" \
+ "cp.b 10 ${uboot_addr} ${filesize};" \
"setenv filesize;saveenv\0" \
"update_kernel=tftp 10 ${bootfile};"\
"era fe00 fe1d;"\
@@ -164,6 +168,7 @@
"boot_usb=run load_usb usbargs addcons;"\
"bootm ${kernel_addr_r} - ${fdt_addr};" \
"bootm ${kernel_addr} ${ramdisk_addr} ${fdt_addr}\0"\
+ SOCRATES_ENV_MTD \
""
/* pass open firmware flat tree */
--
2.37.3
[PATCH v1 04/12] powerpc: dts: updates socrates board
include common e500v2_power_isa.dtsi and rearrange
some nodes.
Signed-off-by: Heiko Schocher
---
arch/powerpc/dts/socrates.dts | 59 +++
1 file changed, 32 insertions(+), 27 deletions(-)
diff --git a/arch/powerpc/dts/socrates.dts b/arch/powerpc/dts/socrates.dts
index 452cf58b5e..ea75eb6af3 100644
--- a/arch/powerpc/dts/socrates.dts
+++ b/arch/powerpc/dts/socrates.dts
@@ -9,6 +9,8 @@
/dts-v1/;
+/include/ "e500v2_power_isa.dtsi"
+
/ {
model = "abb,socrates";
compatible = "abb,socrates";
@@ -142,26 +144,29 @@
phy-handle = <>;
tbi-handle = <>;
phy-connection-type = "rgmii-id";
+ };
- mdio@520 {
- #address-cells = <1>;
- #size-cells = <0>;
- compatible = "fsl,gianfar-mdio";
- reg = <0x520 0x20>;
-
- phy0: ethernet-phy@0 {
- interrupt-parent = <>;
- interrupts = <0 1>;
- reg = <0>;
- };
- phy1: ethernet-phy@1 {
- interrupt-parent = <>;
- interrupts = <0 1>;
- reg = <1>;
- };
- tbi0: tbi-phy@11 {
- reg = <0x11>;
- };
+ mdio@24520 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl,gianfar-mdio";
+ reg = <0x24520 0x20>;
+
+ phy0: ethernet-phy@0 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ interrupt-parent = <>;
+ interrupts = <0 1>;
+ reg = <0>;
+ };
+
+ phy1: ethernet-phy@1 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ interrupt-parent = <>;
+ interrupts = <0 1>;
+ reg = <1>;
+ };
+ tbi0: tbi-phy@11 {
+ reg = <0x11>;
};
};
@@ -180,16 +185,16 @@
phy-handle = <>;
tbi-handle = <>;
phy-connection-type = "rgmii-id";
+ };
- mdio@520 {
- #address-cells = <1>;
- #size-cells = <0>;
- compatible = "fsl,gianfar-tbi";
- reg = <0x520 0x20>;
+ mdio@26520 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl,gianfar-tbi";
+ reg = <0x26520 0x20>;
- tbi1: tbi-phy@11 {
- reg = <0x11>;
- };
+ tbi1: tbi-phy@11 {
+ reg = <0x11>;
};
};
--
2.37.3
[PATCH v1 03/12] powerpc/mpc85xx: drop socrates specific image creation
convert socrates board to use MPC85XX_HAVE_RESET_VECTOR and
disable CONFIG_OF_BOARD and use common u-boot.dtsi for
creating u-boot-dtb.bin.
Signed-off-by: Heiko Schocher
---
arch/powerpc/dts/socrates-u-boot.dtsi | 17 -
board/socrates/socrates.c | 17 -
configs/socrates_defconfig| 6 +++---
3 files changed, 7 insertions(+), 33 deletions(-)
diff --git a/arch/powerpc/dts/socrates-u-boot.dtsi
b/arch/powerpc/dts/socrates-u-boot.dtsi
index f6af611b51..67c12f672c 100644
--- a/arch/powerpc/dts/socrates-u-boot.dtsi
+++ b/arch/powerpc/dts/socrates-u-boot.dtsi
@@ -3,20 +3,9 @@
* Copyright (C) 2019
* Heiko Schocher, DENX Software Engineering, h...@denx.de
*/
-/ {
- binman {
- filename = "u-boot-dtb.bin";
- pad-byte = <0xff>;
- // Place dtb one sector before u-boot-nodtb.bin
- blob {
- filename = "u-boot.dtb";
- };
- u-boot-nodtb {
- filename = "u-boot-nodtb.bin";
- offset = <0x2>;
- };
- };
+#include
+/ {
chosen {
stdout-path =
};
@@ -38,3 +27,5 @@
u-boot,dm-pre-reloc;
clock-frequency = <0>;
};
+
+#include "u-boot.dtsi"
diff --git a/board/socrates/socrates.c b/board/socrates/socrates.c
index 9c4dd186fc..1d63c81a9c 100644
--- a/board/socrates/socrates.c
+++ b/board/socrates/socrates.c
@@ -217,23 +217,6 @@ int ft_board_setup(void *blob, struct bd_info *bd)
}
#endif /* CONFIG_OF_BOARD_SETUP */
-#if defined(CONFIG_OF_SEPARATE)
-void *board_fdt_blob_setup(int *err)
-{
- void *fw_dtb;
-
- *err = 0;
- fw_dtb = (void *)(CONFIG_TEXT_BASE - CONFIG_ENV_SECT_SIZE);
- if (fdt_magic(fw_dtb) != FDT_MAGIC) {
- printf("DTB is not passed via %x\n", (u32)fw_dtb);
- *err = -ENXIO;
- return NULL;
- }
-
- return fw_dtb;
-}
-#endif
-
int get_serial_clock(void)
{
return 0;
diff --git a/configs/socrates_defconfig b/configs/socrates_defconfig
index ade1c79c03..03e84c3e7e 100644
--- a/configs/socrates_defconfig
+++ b/configs/socrates_defconfig
@@ -1,6 +1,6 @@
CONFIG_PPC=y
CONFIG_SYS_IMMR=0xE000
-CONFIG_TEXT_BASE=0xfff6
+CONFIG_TEXT_BASE=0xFFF4
CONFIG_ENV_SIZE=0x4000
CONFIG_ENV_SECT_SIZE=0x2
CONFIG_DEFAULT_DEVICE_TREE="socrates"
@@ -11,13 +11,14 @@ CONFIG_MPC85xx=y
CONFIG_SYS_INIT_RAM_LOCK=y
# CONFIG_CMD_ERRATA is not set
CONFIG_TARGET_SOCRATES=y
+CONFIG_MPC85XX_HAVE_RESET_VECTOR=y
CONFIG_L2_CACHE=y
CONFIG_ENABLE_36BIT_PHYS=y
CONFIG_SYS_MONITOR_LEN=786432
CONFIG_FIT=y
CONFIG_FIT_VERBOSE=y
CONFIG_OF_BOARD_SETUP=y
-CONFIG_SYS_MONITOR_BASE=0xFFF6
+CONFIG_SYS_MONITOR_BASE=0xFFF4
CONFIG_BOOTDELAY=1
CONFIG_USE_BOOTCOMMAND=y
CONFIG_BOOTCOMMAND="run boot_nor"
@@ -54,7 +55,6 @@ CONFIG_CMD_SNTP=y
CONFIG_CMD_EXT2=y
# CONFIG_CMD_IRQ is not set
CONFIG_OF_CONTROL=y
-CONFIG_OF_BOARD=y
CONFIG_ENV_IS_IN_FLASH=y
CONFIG_SYS_REDUNDAND_ENVIRONMENT=y
CONFIG_ENV_ADDR_REDUND=0xFFF0
--
2.37.3
[PATCH v1 02/12] powerpc/mpc85xx: socrates: rework build process
U-Boot build process for socrates board produces final U-Boot binary in
file u-boot-socrates.bin (by binman) And as a bonus it produces two
unusable broken binaries u-boot-dtb.bin and u-boot.bin (by Makefile).
Clean this up, so final U-Boot binary is in u-boot-dtb.bin
Signed-off-by: Pali Rohár
Signed-off-by: Heiko Schocher
---
Makefile | 11 +++
arch/powerpc/dts/socrates-u-boot.dtsi | 4 ++--
arch/powerpc/dts/u-boot.dtsi | 2 +-
3 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/Makefile b/Makefile
index eb354c045c..3472b59920 100644
--- a/Makefile
+++ b/Makefile
@@ -1190,19 +1190,22 @@ endif
u-boot.bin: u-boot-fit-dtb.bin FORCE
$(call if_changed,copy)
+ifneq ($(CONFIG_MPC85XX_HAVE_RESET_VECTOR)$(CONFIG_OF_SEPARATE),yy)
u-boot-dtb.bin: u-boot-nodtb.bin dts/dt.dtb FORCE
$(call if_changed,cat)
+endif
else ifeq ($(CONFIG_OF_SEPARATE).$(CONFIG_OF_OMIT_DTB),y.)
+
+ifneq ($(CONFIG_MPC85XX_HAVE_RESET_VECTOR)$(CONFIG_OF_SEPARATE),yy)
u-boot-dtb.bin: u-boot-nodtb.bin dts/dt.dtb FORCE
$(call if_changed,cat)
+endif
-ifneq ($(CONFIG_MPC85XX_HAVE_RESET_VECTOR)$(CONFIG_OF_SEPARATE),yy)
u-boot.bin: u-boot-dtb.bin FORCE
$(call if_changed,copy)
-endif
-else ifneq ($(CONFIG_MPC85XX_HAVE_RESET_VECTOR)$(CONFIG_OF_SEPARATE),yy)
+else
u-boot.bin: u-boot-nodtb.bin FORCE
$(call if_changed,copy)
endif
@@ -1580,7 +1583,7 @@ u-boot-with-nand-spl.sfp: u-boot-spl-padx4.sfp u-boot.img
FORCE
endif
ifeq ($(CONFIG_MPC85XX_HAVE_RESET_VECTOR)$(CONFIG_OF_SEPARATE),yy)
-u-boot.bin: u-boot-nodtb.bin u-boot.dtb u-boot-br.bin FORCE
+u-boot-dtb.bin: u-boot-nodtb.bin u-boot.dtb u-boot-br.bin FORCE
$(call if_changed,binman)
OBJCOPYFLAGS_u-boot-br.bin := -O binary -j .bootpg -j .resetvec
diff --git a/arch/powerpc/dts/socrates-u-boot.dtsi
b/arch/powerpc/dts/socrates-u-boot.dtsi
index 14a7c245dc..f6af611b51 100644
--- a/arch/powerpc/dts/socrates-u-boot.dtsi
+++ b/arch/powerpc/dts/socrates-u-boot.dtsi
@@ -5,11 +5,11 @@
*/
/ {
binman {
- filename = "u-boot-socrates.bin";
+ filename = "u-boot-dtb.bin";
pad-byte = <0xff>;
// Place dtb one sector before u-boot-nodtb.bin
blob {
- filename = "dts/dt.dtb";
+ filename = "u-boot.dtb";
};
u-boot-nodtb {
filename = "u-boot-nodtb.bin";
diff --git a/arch/powerpc/dts/u-boot.dtsi b/arch/powerpc/dts/u-boot.dtsi
index 6b7375cff2..c39ab6f0ca 100644
--- a/arch/powerpc/dts/u-boot.dtsi
+++ b/arch/powerpc/dts/u-boot.dtsi
@@ -9,7 +9,7 @@
/ {
binman {
- filename = "u-boot.bin";
+ filename = "u-boot-dtb.bin";
skip-at-start = ;
sort-by-offset;
pad-byte = <0xff>;
--
2.37.3
[PATCH v1 01/12] powerpc/mpc85xx: fixes and updates for socrates board
current mainline does not work on socrates board. To
get it back up working, there are some updates needed
in socrates_defconfig.
Signed-off-by: Heiko Schocher
Fixes: 94633c36f9eb ("net: Make DM_ETH be selected by NETDEVICE")
Fixes: 2f8a6db5d83b ("Finish conversion of CONFIG_SYS_CLK_FREQ to Kconfig")
---
configs/socrates_defconfig | 23 +++
1 file changed, 11 insertions(+), 12 deletions(-)
diff --git a/configs/socrates_defconfig b/configs/socrates_defconfig
index 46be662037..ade1c79c03 100644
--- a/configs/socrates_defconfig
+++ b/configs/socrates_defconfig
@@ -1,10 +1,11 @@
CONFIG_PPC=y
CONFIG_SYS_IMMR=0xE000
-CONFIG_TEXT_BASE=0xfff8
+CONFIG_TEXT_BASE=0xfff6
CONFIG_ENV_SIZE=0x4000
CONFIG_ENV_SECT_SIZE=0x2
CONFIG_DEFAULT_DEVICE_TREE="socrates"
-CONFIG_ENV_ADDR=0xFFF4
+CONFIG_SYS_CLK_FREQ=
+CONFIG_ENV_ADDR=0xFFF2
# CONFIG_SYS_PCI_64BIT is not set
CONFIG_MPC85xx=y
CONFIG_SYS_INIT_RAM_LOCK=y
@@ -12,11 +13,11 @@ CONFIG_SYS_INIT_RAM_LOCK=y
CONFIG_TARGET_SOCRATES=y
CONFIG_L2_CACHE=y
CONFIG_ENABLE_36BIT_PHYS=y
-CONFIG_SYS_MONITOR_LEN=393216
+CONFIG_SYS_MONITOR_LEN=786432
CONFIG_FIT=y
CONFIG_FIT_VERBOSE=y
CONFIG_OF_BOARD_SETUP=y
-CONFIG_SYS_MONITOR_BASE=0xFFF8
+CONFIG_SYS_MONITOR_BASE=0xFFF6
CONFIG_BOOTDELAY=1
CONFIG_USE_BOOTCOMMAND=y
CONFIG_BOOTCOMMAND="run boot_nor"
@@ -53,11 +54,12 @@ CONFIG_CMD_SNTP=y
CONFIG_CMD_EXT2=y
# CONFIG_CMD_IRQ is not set
CONFIG_OF_CONTROL=y
+CONFIG_OF_BOARD=y
CONFIG_ENV_IS_IN_FLASH=y
CONFIG_SYS_REDUNDAND_ENVIRONMENT=y
-CONFIG_ENV_ADDR_REDUND=0xFFF2
+CONFIG_ENV_ADDR_REDUND=0xFFF0
CONFIG_USE_ETHPRIME=y
-CONFIG_ETHPRIME="TSEC0"
+CONFIG_ETHPRIME="eTSEC0"
CONFIG_SPD_EEPROM=y
CONFIG_CHIP_SELECTS_PER_CTRL=2
CONFIG_SYS_BR0_PRELIM_BOOL=y
@@ -84,15 +86,12 @@ CONFIG_SYS_FLASH_QUIET_TEST=y
CONFIG_SYS_MAX_FLASH_SECT=256
CONFIG_SYS_MAX_FLASH_BANKS=2
CONFIG_MTD_RAW_NAND=y
-CONFIG_PHY_ATHEROS=y
-CONFIG_PHY_BROADCOM=y
-CONFIG_PHY_DAVICOM=y
CONFIG_PHY_LXT=y
CONFIG_PHY_MARVELL=y
CONFIG_PHY_NATSEMI=y
-CONFIG_PHY_REALTEK=y
-CONFIG_PHY_SMSC=y
-CONFIG_PHY_VITESSE=y
+CONFIG_DM_MDIO=y
+CONFIG_PHY_GIGE=y
+CONFIG_RGMII=y
CONFIG_MII=y
CONFIG_TSEC_ENET=y
CONFIG_PCI_MPC85XX=y
--
2.37.3
[PATCH v1 00/12] powerpc: mpc85xx: fixes and updates for socrates board
Patchseries is based on 53c47c59e6: ("Merge tag 'dm-pull-18jan23' of
https://source.denx.de/u-boot/custodians/u-boot-dm;)
It brings back socrates board working with current mainline, and
adds also some small updates:
- newer U-Boot needs more space in Flash, so set new textbase.
adapt default environment
- remove Flash on CS1 as not used anymore
- support MTDPARTS
- add boot retry feature
- add support for i2c eeprom
- add autbootdelay string
- enable protected environement
- enable signed fit images boot
see thread:
https://lists.denx.de/pipermail/u-boot/2023-January/504249.html
commit bcc85b96b5ff: ("cmd: source: Support specifying config name")
fixes this problem for me!
patch 0002-powerpc-mpc85xx-socrates-rework-socrates-build-proce.patch
is a combination of patches from Pali
http://patchwork.ozlabs.org/project/uboot/patch/20221228200437.30971-1-p...@kernel.org/
http://patchwork.ozlabs.org/project/uboot/patch/20221228200437.30971-2-p...@kernel.org/
which is a base for patch
0003-powerpc-mpc85xx-drop-socrates-specific-image-creatio.patch
which drops socrates board specific image creation and uses standard
mpc85xx way by enabling MPC85XX_HAVE_RESET_VECTOR, drop CONFIG_OF_BOARD
and use common u-boot.dtsi, so no specials anymore for this board.
azure build:
https://dev.azure.com/hs0298/hs/_build/results?buildId=99=results
Heiko Schocher (12):
powerpc/mpc85xx: fixes and updates for socrates board
powerpc/mpc85xx: socrates: rework build process
powerpc/mpc85xx: drop socrates specific image creation
powerpc: dts: updates socrates board
powerpc/mpc85xx: socrates: add MTD partitioning support
powerpc/mpc85xx: socrates: add initrd_high default environment
variable
powerpc/mpc85xx: socrates: drop second flash bank
powerpc/mpc85xx: socrates: Add boot retry feature
powerpc/mpc85xx: socrates: add support for i2c eeprom at 0x51
powerpc/mpc85xx: socrates: add autoboot delay string
powerpc/mpc85xx: socrates: enable protected Environment
powerpc/mpc85xx: socrates: enable signed fitImages
Makefile | 11 +++--
arch/powerpc/dts/socrates-u-boot.dtsi | 23 ++-
arch/powerpc/dts/socrates.dts | 59 +++
arch/powerpc/dts/u-boot.dtsi | 2 +-
board/socrates/socrates.c | 32 +++
configs/socrates_defconfig| 50 +++
include/configs/socrates.h| 25
7 files changed, 118 insertions(+), 84 deletions(-)
--
2.37.3
Re: [PATCH v4] mtd: parsers: ofpart: add workaround for #size-cells 0
On Tue, Jan 24, 2023 at 11:44:44AM +0100, Francesco Dolcini wrote:
> From: Francesco Dolcini
>
> Add a mechanism to handle the case in which partitions are present as
> direct child of the nand controller node and #size-cells is set to <0>.
>
> This could happen if the nand-controller node in the DTS is supposed to
> have #size-cells set to 0, but for some historical reason/bug it was set
> to 1 in the past, and the firmware (e.g. U-Boot) is adding the partition
> as direct children of the nand-controller defaulting to #size-cells
> being to 1.
>
> This prevents a real boot failure on colibri-imx7 that happened during v6.1
> development cycles.
>
> Link:
> https://lore.kernel.org/all/y4dgbtgnwpm6s...@francesco-nb.int.toradex.com/
> Link:
> https://lore.kernel.org/all/20221202071900.1143950-1-france...@dolcini.it/
> Signed-off-by: Francesco Dolcini
> Reviewed-by: Greg Kroah-Hartman
> ---
> I do not expect this patch to be backported to stable, however I would expect
> that we do not backport nand-controller dts cleanups neither.
>
> v4:
> fixed wrong English spelling in the comment
>
> v3:
> minor formatting change, removed not needed new-line and space.
>
> v2:
> fixup size-cells only when partitions are direct children of the
> nand-controller
> completely revised commit message, comments and warning print
> use pr_warn instead of pr_warn_once
> added Reviewed-by Greg
> removed cc:stable@ and fixes tag, since the problematic commit was reverted
> ---
> drivers/mtd/parsers/ofpart_core.c | 19 +++
> 1 file changed, 19 insertions(+)
>
> diff --git a/drivers/mtd/parsers/ofpart_core.c
> b/drivers/mtd/parsers/ofpart_core.c
> index 192190c42fc8..e7b8e9d0a910 100644
> --- a/drivers/mtd/parsers/ofpart_core.c
> +++ b/drivers/mtd/parsers/ofpart_core.c
> @@ -122,6 +122,25 @@ static int parse_fixed_partitions(struct mtd_info
> *master,
>
> a_cells = of_n_addr_cells(pp);
> s_cells = of_n_size_cells(pp);
> + if (!dedicated && s_cells == 0) {
> + /*
> + * This is a ugly workaround to not create
> + * regression on devices that are still creating
> + * partitions as direct children of the nand controller.
> + * This can happen in case the nand controller node has
> + * #size-cells equal to 0 and the firmware (e.g.
> + * U-Boot) just add the partitions there assuming
> + * 32-bit addressing.
> + *
> + * If you get this warning your firmware and/or DTS
> + * should be really fixed.
> + *
> + * This is working only for devices smaller than 4GiB.
> + */
> + pr_warn("%s: ofpart partition %pOF (%pOF) #size-cells
> is wrongly set to <0>, assuming <1> for parsing partitions.\n",
> + master->name, pp, mtd_node);
This is a driver, always use dev_*() calls, not pr_*() calls so that we
know what is being referred to exactly.
I take back my "reviewed-by" line above, please fix this up to not need
pr_warn, but to use dev_warn() instead.
thanks,
greg k-h
[PATCH v2] watchdog: Add a watchdog driver for Raspberry Pi boards
This driver supports the bcm2835 watchdog found on
Raspberry Pi boards.
It is derived from the Linux driver and was tested
on two Raspberry Pi board versions (B+ and 3B+).
Signed-off-by: Etienne Dublé
---
Changes for v2:
- fixed whitespaces in email
- moved a static variable to the priv struct
drivers/watchdog/Kconfig | 9 +++
drivers/watchdog/Makefile | 1 +
drivers/watchdog/bcm2835_wdt.c | 140 +
3 files changed, 150 insertions(+)
create mode 100644 drivers/watchdog/bcm2835_wdt.c
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index f1b1cf63ca..06c0d630c8 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -30,6 +30,7 @@ config WATCHDOG_TIMEOUT_MSECS
default 128000 if ARCH_MX7 || ARCH_VF610
default 3 if ARCH_SOCFPGA
default 16000 if ARCH_SUNXI
+ default 15000 if ARCH_BCM283X
default 6
help
Watchdog timeout in msec
@@ -326,6 +327,14 @@ config WDT_SUNXI
help
Enable support for the watchdog timer in Allwinner sunxi SoCs.
+config WDT_BCM2835
+ bool "Broadcom 2835 watchdog timer support"
+ depends on WDT && ARCH_BCM283X
+ default y
+ help
+ Enable support for the watchdog timer in Broadcom 283X SoCs such
+ as Raspberry Pi boards.
+
config XILINX_TB_WATCHDOG
bool "Xilinx Axi watchdog timer support"
depends on WDT
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 446d961d7d..f99915960c 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -21,6 +21,7 @@ obj-$(CONFIG_WDT_APPLE) += apple_wdt.o
obj-$(CONFIG_WDT_ARMADA_37XX) += armada-37xx-wdt.o
obj-$(CONFIG_WDT_ASPEED) += ast_wdt.o
obj-$(CONFIG_WDT_AST2600) += ast2600_wdt.o
+obj-$(CONFIG_WDT_BCM2835) += bcm2835_wdt.o
obj-$(CONFIG_WDT_BCM6345) += bcm6345_wdt.o
obj-$(CONFIG_WDT_BOOKE) += booke_wdt.o
obj-$(CONFIG_WDT_CORTINA) += cortina_wdt.o
diff --git a/drivers/watchdog/bcm2835_wdt.c b/drivers/watchdog/bcm2835_wdt.c
new file mode 100644
index 00..00f7806cd5
--- /dev/null
+++ b/drivers/watchdog/bcm2835_wdt.c
@@ -0,0 +1,140 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2013 Lubomir Rintel
+ * Copyright (C) 2023 Etienne Dublé (CNRS)
+ *
+ * This code is mostly derived from the linux driver.
+ */
+
+#include
+#include
+#include
+#include
+
+#define PM_RSTC0x1c
+#define PM_WDOG0x24
+
+#define PM_PASSWORD0x5a00
+
+/* The hardware supports a maximum timeout value of 0xf ticks
+ * (just below 16 seconds).
+ * U-boot users specify the timeout as a number of milliseconds
+ * by using variable CONFIG_WATCHDOG_TIMEOUT_MSECS.
+ * The maximum value should be 15999 ms in our case.
+ * However, u-boot internally converts this config value to seconds,
+ * thus specifying 15999 actually means 15000 ms (0xf ticks).
+ */
+#define PM_WDOG_MAX_TICKS 0x000f
+#define PM_RSTC_WRCFG_CLR 0xffcf
+#define PM_RSTC_WRCFG_FULL_RESET 0x0020
+#define PM_RSTC_RESET 0x0102
+
+#define MS_TO_WDOG_TICKS(x) (((x) << 16) / 1000)
+
+struct bcm2835_wdt_priv {
+ void __iomem *base;
+ u64 timeout_ticks;
+};
+
+static int bcm2835_wdt_start_ticks(struct udevice *dev,
+ u64 timeout_ticks, ulong flags)
+{
+ struct bcm2835_wdt_priv *priv = dev_get_priv(dev);
+ void __iomem *base = priv->base;
+ u32 cur;
+
+ writel(PM_PASSWORD | timeout_ticks, base + PM_WDOG);
+ cur = readl(base + PM_RSTC);
+ writel(PM_PASSWORD | (cur & PM_RSTC_WRCFG_CLR) |
+ PM_RSTC_WRCFG_FULL_RESET, base + PM_RSTC);
+
+ return 0;
+}
+
+static int bcm2835_wdt_start(struct udevice *dev, u64 timeout_ms, ulong flags)
+{
+ struct bcm2835_wdt_priv *priv = dev_get_priv(dev);
+
+ priv->timeout_ticks = MS_TO_WDOG_TICKS(timeout_ms);
+
+ if (priv->timeout_ticks > PM_WDOG_MAX_TICKS) {
+ printf("WARNING: bcm2835_wdt cannot handle large timeout
values.\n");
+ printf(" Setting the max value of 15000 ms instead.\n");
+ printf(" Set CONFIG_WATCHDOG_TIMEOUT_MSECS=15000 at
most "
+ "to avoid this warning.\n");
+ priv->timeout_ticks = PM_WDOG_MAX_TICKS;
+ }
+
+ return bcm2835_wdt_start_ticks(dev, priv->timeout_ticks, flags);
+}
+
+static int bcm2835_wdt_reset(struct udevice *dev)
+{
+ struct bcm2835_wdt_priv *priv = dev_get_priv(dev);
+
+ /* restart the timer with the value of priv->timeout_ticks
+* saved from the last bcm2835_wdt_start() call.
+*/
+ return bcm2835_wdt_start_ticks(dev, priv->timeout_ticks, 0);
+}
+
+static int bcm2835_wdt_stop(struct udevice *dev)
+{
+ struct
Re: [PATCH] watchdog: Add a watchdog driver for Raspberry Pi boards
Hi Stefan,
Thanks for the feedback.
I will send a v2 to fix those issues.
Regards,
Etienne
Le 24/01/2023 à 14:38, Stefan Roese a écrit :
Hi Etienne,
On 1/24/23 14:20, Etienne Dublé wrote:
This driver supports the bcm2835 watchdog found on
Raspberry Pi boards.
It is derived from the Linux driver and was tested
on two Raspberry Pi board versions (B+ and 3B+).
Signed-off-by: Etienne Dublé
---
drivers/watchdog/Kconfig | 9 +++
drivers/watchdog/Makefile | 1 +
drivers/watchdog/bcm2835_wdt.c | 135 +
3 files changed, 145 insertions(+)
create mode 100644 drivers/watchdog/bcm2835_wdt.c
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index f1b1cf63ca..06c0d630c8 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -30,6 +30,7 @@ config WATCHDOG_TIMEOUT_MSECS
default 128000 if ARCH_MX7 || ARCH_VF610
default 3 if ARCH_SOCFPGA
default 16000 if ARCH_SUNXI
+ default 15000 if ARCH_BCM283X
default 6
help
Watchdog timeout in msec
@@ -326,6 +327,14 @@ config WDT_SUNXI
help
Enable support for the watchdog timer in Allwinner sunxi SoCs.
+config WDT_BCM2835
+ bool "Broadcom 2835 watchdog timer support"
Your patch seems to have whitespace problems. Please make sure to send
it e.g. via git send-email.
More comments below...
+ depends on WDT && ARCH_BCM283X
+ default y
+ help
+ Enable support for the watchdog timer in Broadcom 283X SoCs such
+ as Raspberry Pi boards.
+
config XILINX_TB_WATCHDOG
bool "Xilinx Axi watchdog timer support"
depends on WDT
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 446d961d7d..f99915960c 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -21,6 +21,7 @@ obj-$(CONFIG_WDT_APPLE) += apple_wdt.o
obj-$(CONFIG_WDT_ARMADA_37XX) += armada-37xx-wdt.o
obj-$(CONFIG_WDT_ASPEED) += ast_wdt.o
obj-$(CONFIG_WDT_AST2600) += ast2600_wdt.o
+obj-$(CONFIG_WDT_BCM2835) += bcm2835_wdt.o
obj-$(CONFIG_WDT_BCM6345) += bcm6345_wdt.o
obj-$(CONFIG_WDT_BOOKE) += booke_wdt.o
obj-$(CONFIG_WDT_CORTINA) += cortina_wdt.o
diff --git a/drivers/watchdog/bcm2835_wdt.c
b/drivers/watchdog/bcm2835_wdt.c
new file mode 100644
index 00..48535c003f
--- /dev/null
+++ b/drivers/watchdog/bcm2835_wdt.c
@@ -0,0 +1,135 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2013 Lubomir Rintel
+ * Copyright (C) 2023 Etienne Dublé (CNRS)
+ *
+ * This code is mostly derived from the linux driver.
+ */
+
+#include
+#include
+#include
+#include
+
+#define PM_RSTC 0x1c
+#define PM_WDOG 0x24
+
+#define PM_PASSWORD 0x5a00
+
+/* The hardware supports a maximum timeout value of 0xf ticks
+ * (just below 16 seconds).
+ * U-boot users specify the timeout as a number of milliseconds
+ * by using variable CONFIG_WATCHDOG_TIMEOUT_MSECS.
+ * The maximum value should be 15999 ms in our case.
+ * However, u-boot internally converts this config value to seconds,
+ * thus specifying 15999 actually means 15000 ms (0xf ticks).
+ */
+#define PM_WDOG_MAX_TICKS 0x000f
+#define PM_RSTC_WRCFG_CLR 0xffcf
+#define PM_RSTC_WRCFG_FULL_RESET 0x0020
+#define PM_RSTC_RESET 0x0102
+
+#define MS_TO_WDOG_TICKS(x) (((x) << 16) / 1000)
+
+struct bcm2835_wdt_priv {
+ void __iomem *base;
+};
+
+static u64 timeout_ticks = PM_WDOG_MAX_TICKS;
Is this static variable really needed? Why not add this variable (if
needed) into the priv struct above instead?
+
+static int bcm2835_wdt_start_ticks(struct udevice *dev,
+ u64 timeout_ticks, ulong flags)
+{
+ struct bcm2835_wdt_priv *priv = dev_get_priv(dev);
+ void __iomem *base = priv->base;
+ u32 cur;
+
+ writel(PM_PASSWORD | timeout_ticks, base + PM_WDOG);
+ cur = readl(base + PM_RSTC);
+ writel(PM_PASSWORD | (cur & PM_RSTC_WRCFG_CLR) |
+ PM_RSTC_WRCFG_FULL_RESET, base + PM_RSTC);
+
+ return 0;
+}
+
+static int bcm2835_wdt_start(struct udevice *dev, u64 timeout_ms,
ulong flags)
+{
+ timeout_ticks = MS_TO_WDOG_TICKS(timeout_ms);
Again, there should be no need for this static variable. Please move it
to the priv struct instead.
Thanks,
Stefan
+
+ if (timeout_ticks > PM_WDOG_MAX_TICKS) {
+ printf("WARNING: bcm2835_wdt cannot handle large timeout
values.\n");
+ printf(" Setting the max value of 15000 ms instead.\n");
+ printf(" Set CONFIG_WATCHDOG_TIMEOUT_MSECS=15000 at most "
+ "to avoid this warning.\n");
+ timeout_ticks = PM_WDOG_MAX_TICKS;
+ }
+
+ return bcm2835_wdt_start_ticks(dev, timeout_ticks, flags);
+}
+
+static int bcm2835_wdt_reset(struct udevice *dev)
+{
+ /* restart the timer with the static variable 'timeout_ticks'
+ * saved from the last bcm2835_wdt_start() call.
+ */
+ return
Re: [PATCH v8 03/10] arm_ffa: introduce Arm FF-A low-level driver
On Mon, Jan 23, 2023 at 09:32:28AM -0700, Simon Glass wrote: > Hi Rob, > > On Mon, 23 Jan 2023 at 08:13, Rob Herring wrote: > > > > On Fri, Jan 20, 2023 at 4:04 PM Simon Glass wrote: > > > > > > Hi Rob, > > > > > > On Thu, 19 Jan 2023 at 11:11, Rob Herring wrote: > > > > > > > > On Thu, Jan 19, 2023 at 10:41 AM Simon Glass wrote: > > > > > > > > > > Hi Abdellatif, > > > > > > > > > > On Thu, 19 Jan 2023 at 09:32, Abdellatif El Khlifi > > > > > wrote: > > > > > > > > > > > > On Wed, Jan 18, 2023 at 08:59:32AM -0500, Tom Rini wrote: > > > > > > > On Wed, Jan 18, 2023 at 01:46:54PM +, Sudeep Holla wrote: > > > > > > > > On Wed, Jan 18, 2023 at 12:49 PM Tom Rini > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > I guess the problem comes down to, can we have one discovery > > > > > > > > > method that > > > > > > > > > everyone shares, or do we have to let everyone invent a new > > > > > > > > > discovery > > > > > > > > > method every time? > > > > > > > > > > > > > > > > > > > > > > > > No one needs to invent any discovery method every time if the > > > > > > > > firmware > > > > > > > > specification > > > > > > > > provides one and as Rob mentioned many times in the thread, all > > > > > > > > new firmware > > > > > > > > specification must provide one and we are trying to make sure > > > > > > > > that is > > > > > > > > the case with all new > > > > > > > > specs from Arm. > > > > > > > > > > > > > > > > > > > > > > > > > FF-A, Op-tee, U-Boot, coreboot, barebox (and > > > > > > > > > everyone else I'm unintentionally forgetting) could just > > > > > > > > > discover these > > > > > > > > > things via device tree. > > > > > > > > > > > > > > > > > > > > > > > > I leave that to the individual projects to decide and agree but > > > > > > > > fundamentally if > > > > > > > > the specification provides a way to discover, not sure why we > > > > > > > > are even > > > > > > > > discussing > > > > > > > > an alternative method here. > > > > > > > > > > > > > > > > > > > > > > > > > Or, we could all write our own code to perform > > > > > > > > > the discovery. > > > > > > > > > > > > > > > > > > > > > > > > For what reason ? I can understand if there is no discovery > > > > > > > > mechanism but > > > > > > > > that's not the > > > > > > > > case in $subject. > > > > > > > > > > > > > > > > > > > > > > > > > And when RISC-V comes along with similar functionality, > > > > > > > > > we could probe their device tree and see they've implemented > > > > > > > > > the same > > > > > > > > > concept, but a little differently, but still have the > > > > > > > > > discovery portion > > > > > > > > > be in the device tree. To which it sounds like your answer is > > > > > > > > > "not in > > > > > > > > > the device tree". > > > > > > > > > > > > > > > > > > > > > > > > > I see U-boot seem to have made a decision to create DT node for > > > > > > > > each and > > > > > > > > everything > > > > > > > > that needs to be added to DM which seems bit unfortunate but I > > > > > > > > don't > > > > > > > > understand the > > > > > > > > history/motive/background for it but I respect the decision if > > > > > > > > it is > > > > > > > > already made. > > > > > > > > > > > > > > > > These firmware interfaces are standard on all Arm platforms and > > > > > > > > can be > > > > > > > > discovered > > > > > > > > based on PSCI/SMCCC. Not using the same and use DT node needs > > > > > > > > unnecessary > > > > > > > > addition of DT nodes for all the f/w i/f on all the platforms > > > > > > > > that need the > > > > > > > > support when > > > > > > > > one can be just discovered. > > > > > > > > > > > > > > > > Sorry for the sudden appearance on this thread, I was avoiding > > > > > > > > getting into > > > > > > > > this but thought > > > > > > > > I will at least express my opinion and also the way the firmware > > > > > > > > specifications from Arm is > > > > > > > > expected to be evolved from now on. With that I will leave it > > > > > > > > to you and > > > > > > > > other U-boot > > > > > > > > maintainers and the community in general to decide the right > > > > > > > > course in this > > > > > > > > case. > > > > > > > > > > > > > > To be clear, if the position is that "this is what everyone else > > > > > > > will > > > > > > > use, really" then yes, we'll follow this in U-Boot. > > > > > > > > > > > > Hi Simon, Tom, > > > > > > > > > > > > The FF-A transport is a SW bus and is not associated to any HW > > > > > > peripheral or > > > > > > undiscoverable base address. > > > > > > > > > > > > There is only 1 way of discovering the FF-A bus and it's through > > > > > > the FF-A SW > > > > > > interfaces. The FF-A spec [1] describes this in details. > > > > > > > > > > Can you add a DT node for the 'FF-A SW interfaces' and attach some > > > > > sort of top-level driver to that? Perhaps simple-bus, or your own > > > > > thing? You don't need to add compatible strings
Re: [PATCH v2] watchdog: Add a watchdog driver for Raspberry Pi boards
Hi Etienne,
On 1/24/23 15:55, ETIENNE DUBLE wrote:
This driver supports the bcm2835 watchdog found on
Raspberry Pi boards.
It is derived from the Linux driver and was tested
on two Raspberry Pi board versions (B+ and 3B+).
Signed-off-by: Etienne Dublé
---
Changes for v2:
- fixed whitespaces in email
- moved a static variable to the priv struct
drivers/watchdog/Kconfig | 9 +++
drivers/watchdog/Makefile | 1 +
drivers/watchdog/bcm2835_wdt.c | 140 +
3 files changed, 150 insertions(+)
create mode 100644 drivers/watchdog/bcm2835_wdt.c
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index f1b1cf63ca..06c0d630c8 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -30,6 +30,7 @@ config WATCHDOG_TIMEOUT_MSECS
default 128000 if ARCH_MX7 || ARCH_VF610
default 3 if ARCH_SOCFPGA
default 16000 if ARCH_SUNXI
+ default 15000 if ARCH_BCM283X
default 6
help
Watchdog timeout in msec
@@ -326,6 +327,14 @@ config WDT_SUNXI
help
Enable support for the watchdog timer in Allwinner sunxi SoCs.
+config WDT_BCM2835
+ bool "Broadcom 2835 watchdog timer support"
+ depends on WDT && ARCH_BCM283X
+ default y
+ help
+ Enable support for the watchdog timer in Broadcom 283X SoCs such
+ as Raspberry Pi boards.
+
config XILINX_TB_WATCHDOG
bool "Xilinx Axi watchdog timer support"
depends on WDT
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 446d961d7d..f99915960c 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -21,6 +21,7 @@ obj-$(CONFIG_WDT_APPLE) += apple_wdt.o
obj-$(CONFIG_WDT_ARMADA_37XX) += armada-37xx-wdt.o
obj-$(CONFIG_WDT_ASPEED) += ast_wdt.o
obj-$(CONFIG_WDT_AST2600) += ast2600_wdt.o
+obj-$(CONFIG_WDT_BCM2835) += bcm2835_wdt.o
obj-$(CONFIG_WDT_BCM6345) += bcm6345_wdt.o
obj-$(CONFIG_WDT_BOOKE) += booke_wdt.o
obj-$(CONFIG_WDT_CORTINA) += cortina_wdt.o
diff --git a/drivers/watchdog/bcm2835_wdt.c b/drivers/watchdog/bcm2835_wdt.c
new file mode 100644
index 00..00f7806cd5
--- /dev/null
+++ b/drivers/watchdog/bcm2835_wdt.c
@@ -0,0 +1,140 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2013 Lubomir Rintel
+ * Copyright (C) 2023 Etienne Dublé (CNRS)
+ *
+ * This code is mostly derived from the linux driver.
+ */
+
+#include
+#include
+#include
+#include
+
+#define PM_RSTC0x1c
+#define PM_WDOG0x24
+
+#define PM_PASSWORD0x5a00
+
+/* The hardware supports a maximum timeout value of 0xf ticks
+ * (just below 16 seconds).
+ * U-boot users specify the timeout as a number of milliseconds
+ * by using variable CONFIG_WATCHDOG_TIMEOUT_MSECS.
+ * The maximum value should be 15999 ms in our case.
+ * However, u-boot internally converts this config value to seconds,
+ * thus specifying 15999 actually means 15000 ms (0xf ticks).
means 15999 ms?
+ */
+#define PM_WDOG_MAX_TICKS 0x000f
+#define PM_RSTC_WRCFG_CLR 0xffcf
+#define PM_RSTC_WRCFG_FULL_RESET 0x0020
+#define PM_RSTC_RESET 0x0102
+
+#define MS_TO_WDOG_TICKS(x) (((x) << 16) / 1000)
+
+struct bcm2835_wdt_priv {
+ void __iomem *base;
+ u64 timeout_ticks;
+};
+
+static int bcm2835_wdt_start_ticks(struct udevice *dev,
+ u64 timeout_ticks, ulong flags)
+{
+ struct bcm2835_wdt_priv *priv = dev_get_priv(dev);
+ void __iomem *base = priv->base;
+ u32 cur;
+
+ writel(PM_PASSWORD | timeout_ticks, base + PM_WDOG);
+ cur = readl(base + PM_RSTC);
+ writel(PM_PASSWORD | (cur & PM_RSTC_WRCFG_CLR) |
+ PM_RSTC_WRCFG_FULL_RESET, base + PM_RSTC);
This does not seem to be aligned with the "(" from the line above.
BTW: Please use scripts/checkpatch.pl to see, if the patch has no more
issues.
+
+ return 0;
+}
+
+static int bcm2835_wdt_start(struct udevice *dev, u64 timeout_ms, ulong flags)
+{
+ struct bcm2835_wdt_priv *priv = dev_get_priv(dev);
+
+ priv->timeout_ticks = MS_TO_WDOG_TICKS(timeout_ms);
+
+ if (priv->timeout_ticks > PM_WDOG_MAX_TICKS) {
+ printf("WARNING: bcm2835_wdt cannot handle large timeout
values.\n");
+ printf("Setting the max value of 15000 ms instead.\n");
+ printf("Set CONFIG_WATCHDOG_TIMEOUT_MSECS=15000 at most "
+ "to avoid this warning.\n");
This seems way too long for a warning from this driver. Please shorten
it to one line. The comment above already covers this limitation AFAICT.
Thanks,
Stefan
+ priv->timeout_ticks = PM_WDOG_MAX_TICKS;
+ }
+
+ return bcm2835_wdt_start_ticks(dev, priv->timeout_ticks, flags);
+}
+
Re: [PATCH v2 1/1] include: configs: am62x_evm: Add .env file for Am62x
On Tue, Jan 24, 2023 at 10:46:02AM +0530, Nikhil M Jain wrote: > Use .env file for setting board related environment variables, > in place of am62x_evm.h file. Except for BOOTENV settings, as > config_distro_boot.env file doesn't exist. > > Signed-off-by: Nikhil M Jain Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature
Re: [PATCH v3 12/70] dm: part: Update test to use mmc2
On Tue, Jan 24, 2023 at 03:56:00AM -0700, Simon Glass wrote:
> Hi Tom,
>
> On Mon, 23 Jan 2023 at 18:39, Tom Rini wrote:
> >
> > On Tue, Jan 17, 2023 at 10:47:22AM -0700, Simon Glass wrote:
> >
> > > At present this test sets up a partition table on mmc1. But this is used
> > > by the bootstd tests, so it is not possible to run those after this test
> > > has run, without restarting the Python test harness.
> > >
> > > This is inconvenient when running tests repeatedly with 'ut dm'. Move the
> > > test to use mmc2, which is not used by anything.
> > >
> > > Signed-off-by: Simon Glass
> >
> > When I run tests like this:
> > TEST="not sleep and not event_dump and not bootmgr and not extension"
> > ./tools/buildman/buildman -o /tmp/sandbox -P --board sandbox
> > ./test/py/test.py --bd $ARGS --build-dir /tmp/sandbox -k "$TEST" -ra
> > I get:
> > == FAILURES
> > ===
> > _ test_ut[ut_dm_dm_test_part]
> > _
> > test/py/tests/test_ut.py:341: in test_ut
> > assert output.endswith('Failures: 0')
> > E assert False
> > E+ where False = > 0x2776470>('Failures: 0')
> > E+where =
> > 'Test: dm_test_part: part.c\r\r\n** No device specified **\r\r\nCouldn\'t
> > find partition mmc \r\r\n** No device ...: 0 == do_test(uts, 2,
> > "1:2", 0): Expected 0x0 (0), got 0x1 (1)\r\r\nTest dm_test_part failed 4
> > times\r\r\nFailures: 4'.endswith
> > Captured stdout call
> > -
> > => ut dm dm_test_part
> > Test: dm_test_part: part.c
> > ** No device specified **
> > Couldn't find partition mmc
> > ** No device specified **
> > Couldn't find partition mmc
> > ** No partition table - mmc 0 **
> > Couldn't find partition mmc 0
> > Could not find "test1" partition
> > ** Bad device specification mmc #test1 **
> > ** Bad device specification mmc #test1 **
> > Couldn't find partition mmc #test1
> > ** Bad partition specification mmc 1:0 **
> > Couldn't find partition mmc 1:0
> > ** Invalid partition 2 **
> > Couldn't find partition mmc 1:2
> > test/dm/part.c:20, do_test(): expected ==
> > part_get_info_by_dev_and_name_or_num("mmc", part_str, _dev_desc,
> > _info, whole): Expected 0x2 (2), got 0xfffe (-2)
> > test/dm/part.c:82, dm_test_part(): 0 == do_test(uts, 2, "1:2", 0): Expected
> > 0x0 (0), got 0x1 (1)
> > Test: dm_test_part: part.c (flat tree)
> > ** No device specified **
> > Couldn't find partition mmc
> > ** No device specified **
> > Couldn't find partition mmc
> > ** No partition table - mmc 0 **
> > Couldn't find partition mmc 0
> > Could not find "test1" partition
> > ** Bad device specification mmc #test1 **
> > ** Bad device specification mmc #test1 **
> > Couldn't find partition mmc #test1
> > ** Bad partition specification mmc 1:0 **
> > Couldn't find partition mmc 1:0
> > ** Invalid partition 2 **
> > Couldn't find partition mmc 1:2
> > test/dm/part.c:20, do_test(): expected ==
> > part_get_info_by_dev_and_name_or_num("mmc", part_str, _dev_desc,
> > _info, whole): Expected 0x2 (2), got 0xfffe (-2)
> > test/dm/part.c:82, dm_test_part(): 0 == do_test(uts, 2, "1:2", 0): Expected
> > 0x0 (0), got 0x1 (1)
> > Test dm_test_part failed 4 times
> > Failures: 4
> > =>
>
> Oh dear. I believe this is an ordering problem. These two patches need
> to be applied together because the first one changes mmc1.img and the
> second one relies on that change:
>
> part: Add a function to find the first bootable partition
> dm: part: Update test to use mmc2
>
> I have them quite far apart in the series.
>
> I can merge them into one commit, perhaps?
>
> >
> > And further tests down the series also fail / introduce failures, but
> > this is the first one, and why I thought v2 had more problems.
>
> For some reason I'm not seeing this, but it could be another ordering
> thing. I don't see failures on CI but it only tests the whole.
>
> Let me know what you'd like me to do. I don't currently have a way to
> run tests on every commit, so my testing there is a bit random. I
> normally just build-test the series and then check with CI.
Well, your ordering comment is interesting. I bisect'd down to this
patch being a problem because with the full series applied I see:
== FAILURES
===
___ test_ut_dm_init_bootstd
___
test/py/tests/test_ut.py:320: in test_ut_dm_init_bootstd
setup_bootflow_image(u_boot_console)
test/py/tests/test_ut.py:226: in setup_bootflow_image
fname, mnt = setup_image(cons, mmc_dev, 0xc, second_part=True)
test/py/tests/test_ut.py:45: in setup_image
u_boot_utils.run_and_log(cons, 'sudo sfdisk %s' % fname,
test/py/u_boot_utils.py:180: in run_and_log
output = runner.run(cmd, ignore_errors=ignore_errors,
Re: [PATCH v5 3/4] eficonfig: add vertical scroll support
On 1/24/23 07:56, Masahisa Kojima wrote: The current eficonfig menu does not support vertical scroll, so it can not display the menu entries greater than the console row size. This commit add the vertial scroll support. The console size is retrieved by SIMPLE_TEXT_OUTPUT_PROTOCOL.QueryMode() service, then calculates the row size for menu entry by subtracting menu header and description row size from the console row size. "start" and "end" are added in the efimenu structure. "start" keeps the menu entry index at the top, "end" keeps the bottom menu entry index. item_data_print() menu function only draws the menu entry between "start" and "end". This commit also fixes the issue that "Save" and "Quit" entries can be moved by BKEY_PLUS in change boot order menu. Signed-off-by: Masahisa Kojima Hello Masahisa, my example with 100 boot options works fine now. I will get that series merged. When I edit the boot order and want to save the changes I have to scroll down up to INT_MAX lines to reach the line with "Save". Can't we just use CTRL+S for saving in a future patch? "ESC/CTRL+C to quit" is misleading: On the sandbox called without "--terminal raw" CTRL+C leaves U-Boot. How about removing "/CTRL+C" from that text? Best regards Heinrich
[PATCH v2 3/3] xilinx: board: Update logic in xilinx_read_eeprom_legacy
When eeprom has random content printing random chars can stuck U-Boot.
That's why update legacy eeprom format decoding algorithm to copy only
maximum amount of chars allocated for fields.
And also print them directly from desc structure.
Previous algorithm was printing strings first directly from eeprom content
and then copy them to desc structure.
Signed-off-by: Michal Simek
---
Changes in v2:
- Add +1 for strlcpy because only size -1 is used compare to strncpy.
board/xilinx/common/board.c | 24 ++--
1 file changed, 14 insertions(+), 10 deletions(-)
diff --git a/board/xilinx/common/board.c b/board/xilinx/common/board.c
index 8bcb54da88e7..c3b2114ff03a 100644
--- a/board/xilinx/common/board.c
+++ b/board/xilinx/common/board.c
@@ -140,21 +140,25 @@ static int xilinx_read_eeprom_legacy(struct udevice *dev,
char *name,
xilinx_eeprom_legacy_cleanup((char *)eeprom_content, size);
- printf("Xilinx I2C Legacy format at %s:\n", name);
- printf(" Board name:\t%s\n", eeprom_content->board_name);
- printf(" Board rev:\t%s\n", eeprom_content->board_revision);
- printf(" Board SN:\t%s\n", eeprom_content->board_sn);
+ /* Terminating \0 chars are the part of desc fields already */
+ strlcpy(desc->name, eeprom_content->board_name,
+ sizeof(eeprom_content->board_name) + 1);
+ strlcpy(desc->revision, eeprom_content->board_revision,
+ sizeof(eeprom_content->board_revision) + 1);
+ strlcpy(desc->serial, eeprom_content->board_sn,
+ sizeof(eeprom_content->board_sn) + 1);
eth_valid = is_valid_ethaddr((const u8 *)eeprom_content->eth_mac);
if (eth_valid)
- printf(" Ethernet mac:\t%pM\n", eeprom_content->eth_mac);
+ memcpy(desc->mac_addr[0], eeprom_content->eth_mac, ETH_ALEN);
+
+ printf("Xilinx I2C Legacy format at %s:\n", name);
+ printf(" Board name:\t%s\n", desc->name);
+ printf(" Board rev:\t%s\n", desc->revision);
+ printf(" Board SN:\t%s\n", desc->serial);
- /* Terminating \0 chars ensure end of string */
- strcpy(desc->name, eeprom_content->board_name);
- strcpy(desc->revision, eeprom_content->board_revision);
- strcpy(desc->serial, eeprom_content->board_sn);
if (eth_valid)
- memcpy(desc->mac_addr[0], eeprom_content->eth_mac, ETH_ALEN);
+ printf(" Ethernet mac:\t%pM\n", desc->mac_addr);
desc->header = EEPROM_HEADER_MAGIC;
--
2.36.1
[PATCH v2 2/3] xilinx: board: Fix xilinx_eeprom_legacy_cleanup()
When ethernet mac address contains 0x20 or 0xff MAC address is changed and
bytes are converted to zeros. That's why fix decoding algorithm to ignore
fields where MAC address is stored and all non printable chars (including
space) are zeroed.
Signed-off-by: Michal Simek
---
(no changes since v1)
board/xilinx/common/board.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/board/xilinx/common/board.c b/board/xilinx/common/board.c
index 6fc41e978669..8bcb54da88e7 100644
--- a/board/xilinx/common/board.c
+++ b/board/xilinx/common/board.c
@@ -101,9 +101,13 @@ static void xilinx_eeprom_legacy_cleanup(char *eeprom, int
size)
for (i = 0; i < size; i++) {
byte = eeprom[i];
- /* Remove all ffs and spaces */
- if (byte == 0xff || byte == ' ')
+ /* Remove all non printable chars but ignore MAC address */
+ if ((i < offsetof(struct xilinx_legacy_format, eth_mac) ||
+i >= offsetof(struct xilinx_legacy_format, unused1)) &&
+(byte < '!' || byte > '~')) {
eeprom[i] = 0;
+ continue;
+ }
/* Convert strings to lower case */
if (byte >= 'A' && byte <= 'Z')
--
2.36.1
[PATCH v2 1/3] xilinx: board: Use ETH_ALEN macro for mac address size
Use predefined macro for eth_mac legacy format.
Signed-off-by: Michal Simek
---
(no changes since v1)
board/xilinx/common/board.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/board/xilinx/common/board.c b/board/xilinx/common/board.c
index 823d703ea93c..6fc41e978669 100644
--- a/board/xilinx/common/board.c
+++ b/board/xilinx/common/board.c
@@ -85,7 +85,7 @@ static struct xilinx_board_description *board_info;
struct xilinx_legacy_format {
char board_sn[18]; /* 0x0 */
char unused0[14]; /* 0x12 */
- char eth_mac[6]; /* 0x20 */
+ char eth_mac[ETH_ALEN]; /* 0x20 */
char unused1[170]; /* 0x26 */
char board_name[11]; /* 0xd0 */
char unused2[5]; /* 0xdc */
--
2.36.1
[PATCH v2 0/3] xilinx: board: Improve legacy format handling
Hi, fix and improve legacy format handling to cover cases where eeprom content is corrupted and random. Very likely detection algorithm can be improved - for example check that mac address is valid, check all strings, etc. but the aim of this series is to remove all non printable chars without mac address and never copy more bytes than expected. Thanks, Michal Changes in v2: - Add +1 for strlcpy because only size -1 is used compare to strncpy. Michal Simek (3): xilinx: board: Use ETH_ALEN macro for mac address size xilinx: board: Fix xilinx_eeprom_legacy_cleanup() xilinx: board: Update logic in xilinx_read_eeprom_legacy board/xilinx/common/board.c | 34 +- 1 file changed, 21 insertions(+), 13 deletions(-) -- 2.36.1
[BUG] Re: [PATCH v3 02/25] cli: Move readline character-processing to a state machine
On 1/6/23 15:52, Simon Glass wrote:
The current cread_line() function is very long. It handles the escape
processing inline. The menu command does similar processing but at the
character level, so there is some duplication.
Split the character processing into a new function cli_ch_process() which
processes individual characters and returns the resulting input character,
taking account of escape sequences. It requires the caller to set up and
maintain its state.
Update cread_line() to use this new function.
The only intended functional change is that an invalid escape sequence
does not add invalid/control characters into the input buffer, but instead
discards these.
Signed-off-by: Simon Glass
---
Hello Simon
in the Change Boot Order menu of the eficonfig command I hit the
PAGE-UP or PAGE-DOWN button and get this output:
[ ] label0038
[ ] label0039impossible condition #876
impossible condition #876
Press UP/DOWN to move, +/- to change orde
Press SPACE to activate or deactivate the entry
Select [Save] to complete, ESC/CTRL+C to quit
Hitting an unsupported key should not result in output.
This is the line providing the output.
common/cli_getch.c:201:
puts("impossible condition #876\n");
How line be reached by an "impossible condition". That text does not
make any sense.
This is the patch to blame
b08e9d4b6632 ("cli: Move readline character-processing to a state machine")
Please, remove that debug message.
The conitrace command shows these escape sequences:
PAGE-DOWN 1b 5b 36 7e
PAGE-UP 1b 5b 35 7e
Best regards
Heinrich
[PATCH 1/3] xilinx: board: Use ETH_ALEN macro for mac address size
Use predefined macro for eth_mac legacy format.
Signed-off-by: Michal Simek
---
board/xilinx/common/board.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/board/xilinx/common/board.c b/board/xilinx/common/board.c
index 823d703ea93c..6fc41e978669 100644
--- a/board/xilinx/common/board.c
+++ b/board/xilinx/common/board.c
@@ -85,7 +85,7 @@ static struct xilinx_board_description *board_info;
struct xilinx_legacy_format {
char board_sn[18]; /* 0x0 */
char unused0[14]; /* 0x12 */
- char eth_mac[6]; /* 0x20 */
+ char eth_mac[ETH_ALEN]; /* 0x20 */
char unused1[170]; /* 0x26 */
char board_name[11]; /* 0xd0 */
char unused2[5]; /* 0xdc */
--
2.36.1
[PATCH 3/3] xilinx: board: Update logic in xilinx_read_eeprom_legacy
When eeprom has random content printing random chars can stuck U-Boot.
That's why update legacy eeprom format decoding algorithm to copy only
maximum amount of chars allocated for fields.
And also print them directly from desc structure.
Previous algorithm was printing strings first directly from eeprom content
and then copy them to desc structure.
Signed-off-by: Michal Simek
---
board/xilinx/common/board.c | 24 ++--
1 file changed, 14 insertions(+), 10 deletions(-)
diff --git a/board/xilinx/common/board.c b/board/xilinx/common/board.c
index 8bcb54da88e7..763232e2ff60 100644
--- a/board/xilinx/common/board.c
+++ b/board/xilinx/common/board.c
@@ -140,21 +140,25 @@ static int xilinx_read_eeprom_legacy(struct udevice *dev,
char *name,
xilinx_eeprom_legacy_cleanup((char *)eeprom_content, size);
- printf("Xilinx I2C Legacy format at %s:\n", name);
- printf(" Board name:\t%s\n", eeprom_content->board_name);
- printf(" Board rev:\t%s\n", eeprom_content->board_revision);
- printf(" Board SN:\t%s\n", eeprom_content->board_sn);
+ /* Terminating \0 chars are the part of desc fields already */
+ strlcpy(desc->name, eeprom_content->board_name,
+ sizeof(eeprom_content->board_name));
+ strlcpy(desc->revision, eeprom_content->board_revision,
+ sizeof(eeprom_content->board_revision));
+ strlcpy(desc->serial, eeprom_content->board_sn,
+ sizeof(eeprom_content->board_sn));
eth_valid = is_valid_ethaddr((const u8 *)eeprom_content->eth_mac);
if (eth_valid)
- printf(" Ethernet mac:\t%pM\n", eeprom_content->eth_mac);
+ memcpy(desc->mac_addr[0], eeprom_content->eth_mac, ETH_ALEN);
+
+ printf("Xilinx I2C Legacy format at %s:\n", name);
+ printf(" Board name:\t%s\n", desc->name);
+ printf(" Board rev:\t%s\n", desc->revision);
+ printf(" Board SN:\t%s\n", desc->serial);
- /* Terminating \0 chars ensure end of string */
- strcpy(desc->name, eeprom_content->board_name);
- strcpy(desc->revision, eeprom_content->board_revision);
- strcpy(desc->serial, eeprom_content->board_sn);
if (eth_valid)
- memcpy(desc->mac_addr[0], eeprom_content->eth_mac, ETH_ALEN);
+ printf(" Ethernet mac:\t%pM\n", desc->mac_addr);
desc->header = EEPROM_HEADER_MAGIC;
--
2.36.1
[PATCH 0/3] xilinx: board: Improve legacy format handling
Hi, fix and improve legacy format handling to cover cases where eeprom content is corrupted and random. Very likely detection algorithm can be improved - for example check that mac address is valid, check all strings, etc. but the aim of this series is to remove all non printable chars without mac address and never copy more bytes than expected. Thanks, Michal Michal Simek (3): xilinx: board: Use ETH_ALEN macro for mac address size xilinx: board: Fix xilinx_eeprom_legacy_cleanup() xilinx: board: Update logic in xilinx_read_eeprom_legacy board/xilinx/common/board.c | 34 +- 1 file changed, 21 insertions(+), 13 deletions(-) -- 2.36.1
[PATCH 2/3] xilinx: board: Fix xilinx_eeprom_legacy_cleanup()
When ethernet mac address contains 0x20 or 0xff MAC address is changed and
bytes are converted to zeros. That's why fix decoding algorithm to ignore
fields where MAC address is stored and all non printable chars (including
space) are zeroed.
Signed-off-by: Michal Simek
---
board/xilinx/common/board.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/board/xilinx/common/board.c b/board/xilinx/common/board.c
index 6fc41e978669..8bcb54da88e7 100644
--- a/board/xilinx/common/board.c
+++ b/board/xilinx/common/board.c
@@ -101,9 +101,13 @@ static void xilinx_eeprom_legacy_cleanup(char *eeprom, int
size)
for (i = 0; i < size; i++) {
byte = eeprom[i];
- /* Remove all ffs and spaces */
- if (byte == 0xff || byte == ' ')
+ /* Remove all non printable chars but ignore MAC address */
+ if ((i < offsetof(struct xilinx_legacy_format, eth_mac) ||
+i >= offsetof(struct xilinx_legacy_format, unused1)) &&
+(byte < '!' || byte > '~')) {
eeprom[i] = 0;
+ continue;
+ }
/* Convert strings to lower case */
if (byte >= 'A' && byte <= 'Z')
--
2.36.1
Re: [PATCH v2 00/17] Basic StarFive JH7110 RISC-V SoC support
On Jan 18 2023, Yanhong Wang wrote: > This series of patches base on the latest branch/master, and add support > for the StarFive JH7110 RISC-V SoC and VisionFive V2 board. In order for > this to be achieved, the respective DT nodes have been added, and the > required defconfigs have been added to the boards' defconfig. What is more, > the basic required DM drivers have been added, such as reset, clock, pinctrl, > uart, ram etc. > > Note that the register base address of reset controller is same with the > clock controller. Therefore, there is no device tree node alone for reset > driver. It binds device node in the clock driver. > > The u-boot-spl and u-boot has been tested on the VisionFive V2 boards which > equip with JH7110 SoC and works normally. I tried to put that on an SD card for testing and boot from it, but the SPL cannot read it, thus fails to load U-Boot proper. U-Boot SPL 2023.01-00735-gc8fc99adce (Jan 24 2023 - 15:11:27 +0100) DDR version: dc2e84f0. Trying to boot from MMC2 spl: partition error SPL: failed to boot from all boot devices -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."
Re: [PATCH] net: zynq_gem: Add a 10ms delay in zynq_gem_init()
Hi Michal, On 1/24/23 14:12, Michal Simek wrote: Hi Stefan, On 1/11/23 12:38, Stefan Roese wrote: Hi Harini, On 1/11/23 12:20, Katakam, Harini wrote: + Hi Stefan, -Original Message- From: U-Boot On Behalf Of Stefan Roese Sent: Wednesday, January 11, 2023 1:01 PM To: u-boot@lists.denx.de Cc: Michal Simek ; Ramon Fried ; Sean Anderson Subject: [PATCH] net: zynq_gem: Add a 10ms delay in zynq_gem_init() In our system using ZynqMP with an external SGMII PHY it's necessary to wait a short while after the configuration in zynq_gem_init() before the xfer starts. Otherwise the first packet(s) might get dropped, resulting in a delay at the start of the ethernet transfers. This patch adds a minimal delay of 10ms which fixes problems of dropped first packages. Signed-off-by: Stefan Roese Cc: Michal Simek Cc: Ramon Fried Cc: Sean Anderson --- drivers/net/zynq_gem.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/net/zynq_gem.c b/drivers/net/zynq_gem.c index 507b19b75975..26e468766871 100644 --- a/drivers/net/zynq_gem.c +++ b/drivers/net/zynq_gem.c @@ -522,6 +522,13 @@ static int zynq_gem_init(struct udevice *dev) return ret; } } + + /* + * Some additional minimal delay seems to be needed so that + * the first packet will be sent correctly + */ + mdelay(10); + Thanks for the patch. The PCS status check in your v1 seems valid. However, this delay of 10 msecs should not be necessary. If the PCS status (when autoneg is enabled with the external PHY on your board) shows link up, that's enough. Unfortunately this is not the case. Regardless of using the PCS check from the v1 patch from yesterday, such a minimal delay is necessary on our setup. Could you please consider the following to investigate why initial packets are lost? -> If the external PHY on your board has a hardware reset please consider updating the reset-assert-us and reset-deassert-us properties to ensure PHY is ready before access. Not sure if this will help. See my comment at the end please for this. -> Can you please check if there's any link stability issues in the initial msecs? Monitoring the serdes/GTR SGMII lane that's setup on ZynqMP will be useful. I tested 2 situations: a) Starting network traffic very early in U-Boot, before the aneg link establishment has finished (preboot=ping 192.168.1.5): [8.448005 0.007878] Net: [8.453711 0.005706] ZYNQ GEM: ff0d, mdio bus ff0d, phyaddr 0, interface sgmii [8.454449 0.000739] eth0: ethernet@ff0d [8.454752 0.000303] ethernet@ff0d Waiting for PHY auto negotiation to complete. done [10.915882 2.461130] Using ethernet@ff0d device [10.916228 0.000346] host 192.168.1.5 is alive [10.917247 0.001019] Hit any key to stop autoboot: 0 b) Late in U-Boot, after waiting for some seconds (or even minutes, it makes no difference) on the prompt (preboot=sleep 10;ping 192.168.1.5): [4.655932 0.007849] Net: [4.661612 0.005680] ZYNQ GEM: ff0d, mdio bus ff0d, phyaddr 0, interface sgmii [4.662367 0.000755] eth0: ethernet@ff0d [14.671655 10.009288] Using ethernet@ff0d device [14.672018 0.000364] host 192.168.1.5 is alive [14.673032 0.001014] Hit any key to stop autoboot: 0 The delay is needed in both cases. In a) you see, that the PHY aneg takes a bit of time to finish. The link is established at this time. My feeling is that configuration of "pcscntrl" (or some other register) after phy_startup() in zynq_gem_init() introduces this necessity of this additional delay. I think this will require further investigation what it is really happening. If this is related to SGMII only or also RGMII. Obviously adding some delay without proper explanation is not the right way to go. Agreed. I'm also not 100% satisfied with this "solution". Pretty much if something is not stable there should be a way to pooling any bit. You mean polling (instead of pooling)? Again, the link is already established when "pcscntrl" is configured. I can try to double-check again, if I can poll for something in this "pcscntrl". There is ongoing effort on moving clock from direct register access to using firmware interface. And maybe this issue will be resolve by that that simply clock is not stable at the time when driver tries to enable RX/TX. And current clock driver is not waiting for clock to be stable but firmware base driver does it. As mentioned above, my feeling is that configuration of "pcscntrl" (or some other register) after phy_startup() in zynq_gem_init() introduces this necessity of this additional delay. If this is the case, then changes in the clock access won't make any difference here IIUTC. Still I will do some more tests with this "pcscntrl" hopefully later today and will report back. Stay tuned... Thanks, Stefan
Re: [PATCH] watchdog: Add a watchdog driver for Raspberry Pi boards
Hi Etienne,
On 1/24/23 14:20, Etienne Dublé wrote:
This driver supports the bcm2835 watchdog found on
Raspberry Pi boards.
It is derived from the Linux driver and was tested
on two Raspberry Pi board versions (B+ and 3B+).
Signed-off-by: Etienne Dublé
---
drivers/watchdog/Kconfig | 9 +++
drivers/watchdog/Makefile | 1 +
drivers/watchdog/bcm2835_wdt.c | 135 +
3 files changed, 145 insertions(+)
create mode 100644 drivers/watchdog/bcm2835_wdt.c
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index f1b1cf63ca..06c0d630c8 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -30,6 +30,7 @@ config WATCHDOG_TIMEOUT_MSECS
default 128000 if ARCH_MX7 || ARCH_VF610
default 3 if ARCH_SOCFPGA
default 16000 if ARCH_SUNXI
+ default 15000 if ARCH_BCM283X
default 6
help
Watchdog timeout in msec
@@ -326,6 +327,14 @@ config WDT_SUNXI
help
Enable support for the watchdog timer in Allwinner sunxi SoCs.
+config WDT_BCM2835
+ bool "Broadcom 2835 watchdog timer support"
Your patch seems to have whitespace problems. Please make sure to send
it e.g. via git send-email.
More comments below...
+ depends on WDT && ARCH_BCM283X
+ default y
+ help
+ Enable support for the watchdog timer in Broadcom 283X SoCs such
+ as Raspberry Pi boards.
+
config XILINX_TB_WATCHDOG
bool "Xilinx Axi watchdog timer support"
depends on WDT
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 446d961d7d..f99915960c 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -21,6 +21,7 @@ obj-$(CONFIG_WDT_APPLE) += apple_wdt.o
obj-$(CONFIG_WDT_ARMADA_37XX) += armada-37xx-wdt.o
obj-$(CONFIG_WDT_ASPEED) += ast_wdt.o
obj-$(CONFIG_WDT_AST2600) += ast2600_wdt.o
+obj-$(CONFIG_WDT_BCM2835) += bcm2835_wdt.o
obj-$(CONFIG_WDT_BCM6345) += bcm6345_wdt.o
obj-$(CONFIG_WDT_BOOKE) += booke_wdt.o
obj-$(CONFIG_WDT_CORTINA) += cortina_wdt.o
diff --git a/drivers/watchdog/bcm2835_wdt.c
b/drivers/watchdog/bcm2835_wdt.c
new file mode 100644
index 00..48535c003f
--- /dev/null
+++ b/drivers/watchdog/bcm2835_wdt.c
@@ -0,0 +1,135 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2013 Lubomir Rintel
+ * Copyright (C) 2023 Etienne Dublé (CNRS)
+ *
+ * This code is mostly derived from the linux driver.
+ */
+
+#include
+#include
+#include
+#include
+
+#define PM_RSTC 0x1c
+#define PM_WDOG 0x24
+
+#define PM_PASSWORD 0x5a00
+
+/* The hardware supports a maximum timeout value of 0xf ticks
+ * (just below 16 seconds).
+ * U-boot users specify the timeout as a number of milliseconds
+ * by using variable CONFIG_WATCHDOG_TIMEOUT_MSECS.
+ * The maximum value should be 15999 ms in our case.
+ * However, u-boot internally converts this config value to seconds,
+ * thus specifying 15999 actually means 15000 ms (0xf ticks).
+ */
+#define PM_WDOG_MAX_TICKS 0x000f
+#define PM_RSTC_WRCFG_CLR 0xffcf
+#define PM_RSTC_WRCFG_FULL_RESET 0x0020
+#define PM_RSTC_RESET 0x0102
+
+#define MS_TO_WDOG_TICKS(x) (((x) << 16) / 1000)
+
+struct bcm2835_wdt_priv {
+ void __iomem *base;
+};
+
+static u64 timeout_ticks = PM_WDOG_MAX_TICKS;
Is this static variable really needed? Why not add this variable (if
needed) into the priv struct above instead?
+
+static int bcm2835_wdt_start_ticks(struct udevice *dev,
+ u64 timeout_ticks, ulong flags)
+{
+ struct bcm2835_wdt_priv *priv = dev_get_priv(dev);
+ void __iomem *base = priv->base;
+ u32 cur;
+
+ writel(PM_PASSWORD | timeout_ticks, base + PM_WDOG);
+ cur = readl(base + PM_RSTC);
+ writel(PM_PASSWORD | (cur & PM_RSTC_WRCFG_CLR) |
+ PM_RSTC_WRCFG_FULL_RESET, base + PM_RSTC);
+
+ return 0;
+}
+
+static int bcm2835_wdt_start(struct udevice *dev, u64 timeout_ms, ulong
flags)
+{
+ timeout_ticks = MS_TO_WDOG_TICKS(timeout_ms);
Again, there should be no need for this static variable. Please move it
to the priv struct instead.
Thanks,
Stefan
+
+ if (timeout_ticks > PM_WDOG_MAX_TICKS) {
+ printf("WARNING: bcm2835_wdt cannot handle large timeout
values.\n");
+ printf(" Setting the max value of 15000 ms instead.\n");
+ printf(" Set CONFIG_WATCHDOG_TIMEOUT_MSECS=15000 at most "
+ "to avoid this warning.\n");
+ timeout_ticks = PM_WDOG_MAX_TICKS;
+ }
+
+ return bcm2835_wdt_start_ticks(dev, timeout_ticks, flags);
+}
+
+static int bcm2835_wdt_reset(struct udevice *dev)
+{
+ /* restart the timer with the static variable 'timeout_ticks'
+ * saved from the last bcm2835_wdt_start() call.
+ */
+ return bcm2835_wdt_start_ticks(dev, timeout_ticks, 0);
+}
+
+static int bcm2835_wdt_stop(struct udevice *dev)
+{
+ struct bcm2835_wdt_priv *priv =
[PATCH] watchdog: Add a watchdog driver for Raspberry Pi boards
This driver supports the bcm2835 watchdog found on
Raspberry Pi boards.
It is derived from the Linux driver and was tested
on two Raspberry Pi board versions (B+ and 3B+).
Signed-off-by: Etienne Dublé
---
drivers/watchdog/Kconfig | 9 +++
drivers/watchdog/Makefile | 1 +
drivers/watchdog/bcm2835_wdt.c | 135 +
3 files changed, 145 insertions(+)
create mode 100644 drivers/watchdog/bcm2835_wdt.c
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index f1b1cf63ca..06c0d630c8 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -30,6 +30,7 @@ config WATCHDOG_TIMEOUT_MSECS
default 128000 if ARCH_MX7 || ARCH_VF610
default 3 if ARCH_SOCFPGA
default 16000 if ARCH_SUNXI
+ default 15000 if ARCH_BCM283X
default 6
help
Watchdog timeout in msec
@@ -326,6 +327,14 @@ config WDT_SUNXI
help
Enable support for the watchdog timer in Allwinner sunxi SoCs.
+config WDT_BCM2835
+ bool "Broadcom 2835 watchdog timer support"
+ depends on WDT && ARCH_BCM283X
+ default y
+ help
+ Enable support for the watchdog timer in Broadcom 283X SoCs such
+ as Raspberry Pi boards.
+
config XILINX_TB_WATCHDOG
bool "Xilinx Axi watchdog timer support"
depends on WDT
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 446d961d7d..f99915960c 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -21,6 +21,7 @@ obj-$(CONFIG_WDT_APPLE) += apple_wdt.o
obj-$(CONFIG_WDT_ARMADA_37XX) += armada-37xx-wdt.o
obj-$(CONFIG_WDT_ASPEED) += ast_wdt.o
obj-$(CONFIG_WDT_AST2600) += ast2600_wdt.o
+obj-$(CONFIG_WDT_BCM2835) += bcm2835_wdt.o
obj-$(CONFIG_WDT_BCM6345) += bcm6345_wdt.o
obj-$(CONFIG_WDT_BOOKE) += booke_wdt.o
obj-$(CONFIG_WDT_CORTINA) += cortina_wdt.o
diff --git a/drivers/watchdog/bcm2835_wdt.c b/drivers/watchdog/bcm2835_wdt.c
new file mode 100644
index 00..48535c003f
--- /dev/null
+++ b/drivers/watchdog/bcm2835_wdt.c
@@ -0,0 +1,135 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2013 Lubomir Rintel
+ * Copyright (C) 2023 Etienne Dublé (CNRS)
+ *
+ * This code is mostly derived from the linux driver.
+ */
+
+#include
+#include
+#include
+#include
+
+#define PM_RSTC0x1c
+#define PM_WDOG0x24
+
+#define PM_PASSWORD0x5a00
+
+/* The hardware supports a maximum timeout value of 0xf ticks
+ * (just below 16 seconds).
+ * U-boot users specify the timeout as a number of milliseconds
+ * by using variable CONFIG_WATCHDOG_TIMEOUT_MSECS.
+ * The maximum value should be 15999 ms in our case.
+ * However, u-boot internally converts this config value to seconds,
+ * thus specifying 15999 actually means 15000 ms (0xf ticks).
+ */
+#define PM_WDOG_MAX_TICKS 0x000f
+#define PM_RSTC_WRCFG_CLR 0xffcf
+#define PM_RSTC_WRCFG_FULL_RESET 0x0020
+#define PM_RSTC_RESET 0x0102
+
+#define MS_TO_WDOG_TICKS(x) (((x) << 16) / 1000)
+
+struct bcm2835_wdt_priv {
+ void __iomem *base;
+};
+
+static u64 timeout_ticks = PM_WDOG_MAX_TICKS;
+
+static int bcm2835_wdt_start_ticks(struct udevice *dev,
+ u64 timeout_ticks, ulong flags)
+{
+ struct bcm2835_wdt_priv *priv = dev_get_priv(dev);
+ void __iomem *base = priv->base;
+ u32 cur;
+
+ writel(PM_PASSWORD | timeout_ticks, base + PM_WDOG);
+ cur = readl(base + PM_RSTC);
+ writel(PM_PASSWORD | (cur & PM_RSTC_WRCFG_CLR) |
+ PM_RSTC_WRCFG_FULL_RESET, base + PM_RSTC);
+
+ return 0;
+}
+
+static int bcm2835_wdt_start(struct udevice *dev, u64 timeout_ms, ulong
flags)
+{
+ timeout_ticks = MS_TO_WDOG_TICKS(timeout_ms);
+
+ if (timeout_ticks > PM_WDOG_MAX_TICKS) {
+ printf("WARNING: bcm2835_wdt cannot handle large timeout
values.\n");
+ printf("Setting the max value of 15000 ms instead.\n");
+ printf("Set CONFIG_WATCHDOG_TIMEOUT_MSECS=15000 at most "
+ "to avoid this warning.\n");
+ timeout_ticks = PM_WDOG_MAX_TICKS;
+ }
+
+ return bcm2835_wdt_start_ticks(dev, timeout_ticks, flags);
+}
+
+static int bcm2835_wdt_reset(struct udevice *dev)
+{
+ /* restart the timer with the static variable 'timeout_ticks'
+* saved from the last bcm2835_wdt_start() call.
+*/
+ return bcm2835_wdt_start_ticks(dev, timeout_ticks, 0);
+}
+
+static int bcm2835_wdt_stop(struct udevice *dev)
+{
+ struct bcm2835_wdt_priv *priv = dev_get_priv(dev);
+ void __iomem *base = priv->base;
+
+ writel(PM_PASSWORD | PM_RSTC_RESET, base + PM_RSTC);
+
+ return 0;
+}
+
+static int bcm2835_wdt_expire_now(struct udevice
Re: [PATCH 40/88] ppc: Rename MPC83xx
Hello Simon, On 23.01.23 22:59, Simon Glass wrote: > CONFIG options must not use lower-case letter. Convert this to upper case. > > Signed-off-by: Simon Glass > --- > > api/api_platform-powerpc.c | 2 +- > arch/Kconfig | 2 +- > arch/powerpc/Kconfig | 8 > arch/powerpc/cpu/Makefile | 2 +- > arch/powerpc/cpu/mpc83xx/Kconfig | 4 ++-- > arch/powerpc/cpu/mpc83xx/cpu.c | 2 +- > arch/powerpc/cpu/mpc83xx/start.S | 2 +- > arch/powerpc/cpu/mpc8xxx/fsl_lbc.c | 2 +- > arch/powerpc/include/asm/fsl_dma.h | 4 ++-- > arch/powerpc/include/asm/fsl_lbc.h | 2 +- > arch/powerpc/include/asm/global_data.h | 6 +++--- > arch/powerpc/include/asm/immap_83xx.h | 14 +++--- > arch/powerpc/include/asm/ppc.h | 6 +++--- > arch/powerpc/include/asm/processor.h | 4 ++-- > arch/powerpc/lib/bdinfo.c | 2 +- > board/freescale/mpc837xerdb/README | 2 +- > board/keymile/Kconfig | 4 ++-- > board/keymile/km83xx/Kconfig | 2 +- > configs/MPC837XERDB_defconfig | 2 +- > configs/gazerbeam_defconfig| 2 +- > configs/kmcoge5ne_defconfig| 2 +- > configs/kmeter1_defconfig | 2 +- > configs/kmopti2_defconfig | 2 +- > configs/kmsupx5_defconfig | 2 +- > configs/kmtepr2_defconfig | 2 +- > configs/tuge1_defconfig| 2 +- > configs/tuxx1_defconfig| 2 +- > drivers/clk/Kconfig| 4 ++-- > drivers/clk/mpc83xx_clk.c | 4 ++-- > drivers/clk/mpc83xx_clk.h | 20 ++-- > drivers/cpu/Kconfig| 6 +++--- > drivers/cpu/mpc83xx_cpu.c | 14 +++--- > drivers/cpu/mpc83xx_cpu.h | 8 > drivers/ddr/fsl/Kconfig| 4 ++-- > drivers/ddr/fsl/main.c | 2 +- > drivers/dma/fsl_dma.c | 16 > drivers/gpio/mpc83xx_gpio.c| 2 +- > drivers/misc/Kconfig | 4 ++-- > drivers/misc/mpc83xx_serdes.c | 4 ++-- > drivers/mtd/nand/raw/fsl_elbc_spl.c| 2 +- > drivers/ram/Kconfig| 2 +- > drivers/ram/mpc83xx_sdram.c| 2 +- > drivers/spi/mpc8xxx_spi.c | 2 +- > drivers/sysreset/Kconfig | 4 ++-- > drivers/timer/Kconfig | 4 ++-- > drivers/timer/mpc83xx_timer.c | 2 +- > env/Kconfig| 2 +- > include/asm-generic/u-boot.h | 2 +- > include/configs/MPC837XERDB.h | 2 +- > include/linux/immap_qe.h | 2 +- > include/serial.h | 2 +- > post/Makefile | 2 +- > 52 files changed, 103 insertions(+), 103 deletions(-) Thanks! Reviewed-by: Heiko Schocher bye, Heiko -- DENX Software Engineering GmbH, Managing Director: Erika Unter HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de
Re: [PATCH] odroid: add CROS_EC to odroid_defconfig
On Mon, Jan 23, 2023 at 11:42, Simon Glass wrote:
Hi,
On Mon, 23 Jan 2023 at 02:39, Joost van Zwieten
wrote:
On Mon, Jan 23, 2023 at 08:33, Peter Robinson
wrote:
> On Fri, Jan 20, 2023 at 11:17 PM Joost van Zwieten
> wrote:
>>
>> As of commit e44d7e73fe ("dm: core: Switch uclass_*_device_err
to
>> use
>> uclass_*_device_check") U-Boot built with `odroid_defconfig`
fails
>> to
>> initialize on an Odroid U2: `board_late_init()`
>> (board/samsung/common/board.c)
>> returns with an error due to the absence of the CROS_EC uclass,
and
>> the
>> board
>> resets. This patch adds `CROS_EC` to the defconfig, leading to a
>> succcessful
>> initialization of U-Boot.
>
> This doesn't seem to be the right fix to the problem, why would an
> odroid device have a need for a driver for the ChromeOS Embedded
> Controller?
For reference, here's the thread that led to this patch: [1].
My board returns `ENODEV` when calling
`uclass_first_device_err(UCLASS_CROS_EC, )` with `CROS_EC`
enabled,
so I don't seem to have this device.
This is really adding the driver rather than the device. The device
still does not exist. It is because the exynos boards share common
code like board_init().
Reviewed-by: Simon Glass
At the end of [1] I have suggested an alternative fix: enclosing a
couple of statements that assume there's a CROS_EC driver inside an
`#ifdef CONFIG_CROS_EC`. Do you think that is a viable approach?
I'm not
at all familiar with the U-Boot codebase, so forgive me if this
doesn't
make any sense.
That would be OK too, but if you do that, please use IS_ENABLED()
rather than #ifdef
I've tested the alternative, and that works for me as well. I am
slightly in favour of the alternative, because it seems illogical to
require building a driver that is never going to be used. On the other
hand this patch only affects the Odroid U2, and the alternative every
board using an Exnyos chip.
I'm still wondering why other boards, e.g. the Odroid XU3, are seemingly
(I don't have any) unaffected by this.
Best regards,
Joost
[1]: https://lists.denx.de/pipermail/u-boot/2023-January/505627.html
>
>> Signed-off-by: Joost van Zwieten
>> ---
>> configs/odroid_defconfig | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/configs/odroid_defconfig b/configs/odroid_defconfig
>> index 6e1c29b355..b1ccabd0d2 100644
>> --- a/configs/odroid_defconfig
>> +++ b/configs/odroid_defconfig
>> @@ -55,6 +55,7 @@ CONFIG_DFU_MMC=y
>> CONFIG_SET_DFU_ALT_INFO=y
>> CONFIG_SYS_DFU_DATA_BUF_SIZE=0x200
>> CONFIG_SYS_I2C_S3C24X0=y
>> +CONFIG_CROS_EC=y
>> CONFIG_MMC_DW=y
>> CONFIG_MMC_SDHCI=y
>> CONFIG_MMC_SDHCI_SDMA=y
>> --
>> 2.30.2
>>
>>
>>
>>
>>
Regards,
SImon
Re: [PATCH v3 2/6] tpm: Support boot measurements
Hi Eddie,
On Mon, Jan 23, 2023 at 02:15:18PM -0600, Eddie James wrote:
>
> On 1/16/23 06:00, Ilias Apalodimas wrote:
> > Hi Eddie
> >
> >
> > > +static inline u16 tpm2_algorithm_to_len(enum tpm2_algorithms a)
> > > +{
> > > + switch (a) {
> > > + case TPM2_ALG_SHA1:
> > > + return TPM2_SHA1_DIGEST_SIZE;
> > > + case TPM2_ALG_SHA256:
> > > + return TPM2_SHA256_DIGEST_SIZE;
> > > + case TPM2_ALG_SHA384:
> > > + return TPM2_SHA384_DIGEST_SIZE;
> > > + case TPM2_ALG_SHA512:
> > > + return TPM2_SHA512_DIGEST_SIZE;
> > > + default:
> > > + return 0;
> > > + }
> > > +}
> > Any reason we can't move the static 'const struct digest_info
> > hash_algo_list' from the efi_tcg.c here? We can then move the
> > functions defined in there alg_to_mask and alg_to_len.
> >
> > And since alg_to_mask is really just a bitshift maybe replace that?
>
>
> Hi,
>
> It seems more efficient to keep the switch statement rather than iterate
> through the structure array looking for the matching hash algorithm? I could
> remove the 'static const struct digest_info hash_algo_list' in efi_tcg2.c
> and instead use the tpm2_algorithm_to_len and tpm2_algorithm_to_mask in
> efi_tcg2.c. What do you think?
Sure that's fine. I just prefer a single implementation of getting sizes and
masks
>
>
> > > +
> > > +#define tpm2_algorithm_to_mask(a)(1 << (a))
> > > +
> > > /* NV index attributes */
> > > +
[...]
> > > + return 0;
> > > +}
> > > +
> > > +static int tcg2_log_init(struct udevice *dev, struct tcg2_event_log
> > > *elog)
> > > +{
> > I think we need to re-use efi_init_event_log here. The reason is that on
> > Arm devices TF-A is capable of constructing an eventlog and passing it
> > along in memory. That code takes that into account and tries to reuse the
> > existing EventLog passed from previous boot stages.
> >
> > The main difference between the EFI function and this one
> > is the allocated memory of the EventLog itself. But even in this case, it
> > would be better to tweak the EFI code and do
> > create log -> Allocate EFI memory -> copy log and then use that for EFI
>
>
> OK... I'll try and get that to work. I see some potential issues like the
> fact that EFI finds the platform event log differently.
>
It's been a while since I wrote this but from memory you should
1. move the code from efi_init_event_log() and replace the memory
allocation calls from efi -> calloc
2. get rid of that create_final_event() since it's part of the EFI TCG
protocol.
3. Pass the eventlog to the EFI code eventually, allocate EFI memory and
copy it and create the final events table.
The main problem I can see is handling of the EFI Final Events
table but I think it's doable.
>
> >
> > > + struct tcg_efi_spec_id_event *ev;
> > > + struct tcg_pcr_event *log;
> > > + u32 event_size;
> > > + u32 count = 0;
> > > + u32 log_size;
> > > + u32 active;
> > > + u32 mask;
> > > + size_t i;
> > > + u16 len;
> > > + int rc;
> > > +
> > > + rc = tcg2_get_active_pcr_banks(dev, );
> > > + if (rc)
> > > + return rc;
> > > +
> > > + event_size = offsetof(struct tcg_efi_spec_id_event, digest_sizes);
> > > + for (i = 0; i < ARRAY_SIZE(tcg2algos); ++i) {
> > > + mask = tpm2_algorithm_to_mask(tcg2algos[i]);
> > > +
> > > + if (!(active & mask))
> > > + continue;
> > > +
> > > + switch (tcg2algos[i]) {
> > > + case TPM2_ALG_SHA1:
> > > + case TPM2_ALG_SHA256:
> > > + case TPM2_ALG_SHA384:
> > > + case TPM2_ALG_SHA512:
> > > + count++;
> > > + break;
> > > + default:
> > > + continue;
> > > + }
> > > + }
> > > +
> > > + event_size += 1 +
> > > + (sizeof(struct tcg_efi_spec_id_event_algorithm_size) * count);
> > > + log_size = offsetof(struct tcg_pcr_event, event) + event_size;
> > > +
> > > + if (log_size > elog->log_size) {
> > > + printf("%s: log too large: %u > %u\n", __func__, log_size,
> > > +elog->log_size);
> > > + return -ENOBUFS;
> > > + }
> > > +
>
> > > +
> > > +int tcg2_measure_event(struct udevice *dev, struct tcg2_event_log *elog,
> > > +u32 pcr_index, u32 event_type, u32 size,
> > > +const u8 *event)
> > > +{
> > > + struct tpml_digest_values digest_list;
> > > + int rc;
> > > +
> > > + rc = tcg2_create_digest(dev, event, size, _list);
> > > + if (rc)
> > > + return rc;
> > > +
> > > + rc = tcg2_pcr_extend(dev, pcr_index, _list);
> > > + if (rc)
> > > + return rc;
> > > +
> > > + return tcg2_log_append_check(elog, pcr_index, event_type, _list,
> > > + size, event);
> > > +}
> > There's a static efi_status_t tcg2_measure_event(...) left in efi_tcg.c
> > which breaks compilation. WE should just use the one you added in tpm-v2.c
>
>
> Hmm. The EFI version does a slightly different way of event logging, so I'm
> not sure it's that simple. There is EFI
Re: [PATCH] net: zynq_gem: Add a 10ms delay in zynq_gem_init()
Hi Stefan, On 1/11/23 12:38, Stefan Roese wrote: Hi Harini, On 1/11/23 12:20, Katakam, Harini wrote: + Hi Stefan, -Original Message- From: U-Boot On Behalf Of Stefan Roese Sent: Wednesday, January 11, 2023 1:01 PM To: u-boot@lists.denx.de Cc: Michal Simek ; Ramon Fried ; Sean Anderson Subject: [PATCH] net: zynq_gem: Add a 10ms delay in zynq_gem_init() In our system using ZynqMP with an external SGMII PHY it's necessary to wait a short while after the configuration in zynq_gem_init() before the xfer starts. Otherwise the first packet(s) might get dropped, resulting in a delay at the start of the ethernet transfers. This patch adds a minimal delay of 10ms which fixes problems of dropped first packages. Signed-off-by: Stefan Roese Cc: Michal Simek Cc: Ramon Fried Cc: Sean Anderson --- drivers/net/zynq_gem.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/net/zynq_gem.c b/drivers/net/zynq_gem.c index 507b19b75975..26e468766871 100644 --- a/drivers/net/zynq_gem.c +++ b/drivers/net/zynq_gem.c @@ -522,6 +522,13 @@ static int zynq_gem_init(struct udevice *dev) return ret; } } + + /* + * Some additional minimal delay seems to be needed so that + * the first packet will be sent correctly + */ + mdelay(10); + Thanks for the patch. The PCS status check in your v1 seems valid. However, this delay of 10 msecs should not be necessary. If the PCS status (when autoneg is enabled with the external PHY on your board) shows link up, that's enough. Unfortunately this is not the case. Regardless of using the PCS check from the v1 patch from yesterday, such a minimal delay is necessary on our setup. Could you please consider the following to investigate why initial packets are lost? -> If the external PHY on your board has a hardware reset please consider updating the reset-assert-us and reset-deassert-us properties to ensure PHY is ready before access. Not sure if this will help. See my comment at the end please for this. -> Can you please check if there's any link stability issues in the initial msecs? Monitoring the serdes/GTR SGMII lane that's setup on ZynqMP will be useful. I tested 2 situations: a) Starting network traffic very early in U-Boot, before the aneg link establishment has finished (preboot=ping 192.168.1.5): [8.448005 0.007878] Net: [8.453711 0.005706] ZYNQ GEM: ff0d, mdio bus ff0d, phyaddr 0, interface sgmii [8.454449 0.000739] eth0: ethernet@ff0d [8.454752 0.000303] ethernet@ff0d Waiting for PHY auto negotiation to complete. done [10.915882 2.461130] Using ethernet@ff0d device [10.916228 0.000346] host 192.168.1.5 is alive [10.917247 0.001019] Hit any key to stop autoboot: 0 b) Late in U-Boot, after waiting for some seconds (or even minutes, it makes no difference) on the prompt (preboot=sleep 10;ping 192.168.1.5): [4.655932 0.007849] Net: [4.661612 0.005680] ZYNQ GEM: ff0d, mdio bus ff0d, phyaddr 0, interface sgmii [4.662367 0.000755] eth0: ethernet@ff0d [14.671655 10.009288] Using ethernet@ff0d device [14.672018 0.000364] host 192.168.1.5 is alive [14.673032 0.001014] Hit any key to stop autoboot: 0 The delay is needed in both cases. In a) you see, that the PHY aneg takes a bit of time to finish. The link is established at this time. My feeling is that configuration of "pcscntrl" (or some other register) after phy_startup() in zynq_gem_init() introduces this necessity of this additional delay. I think this will require further investigation what it is really happening. If this is related to SGMII only or also RGMII. Obviously adding some delay without proper explanation is not the right way to go. Pretty much if something is not stable there should be a way to pooling any bit. There is ongoing effort on moving clock from direct register access to using firmware interface. And maybe this issue will be resolve by that that simply clock is not stable at the time when driver tries to enable RX/TX. And current clock driver is not waiting for clock to be stable but firmware base driver does it. Thanks, Michal
Re: [PATCH] usb: host: ehci-generic: Handle DM_RESET=n case
Hi Xavier
On 1/24/23 09:32, Xavier Drudis Ferran wrote:
> El Tue, Jan 24, 2023 at 09:07:58AM +0100, Patrice CHOTARD deia:
>> Hi Marek
>>
>> On 1/23/23 23:32, Marek Vasut wrote:
>>> In case CONFIG_DM_RESET=n, reset_get_bulk() returns -ENOTSUPP.
>>> Do not fail in that case either. This is a valid use case, e.g.
>>> in case the reset driver is a no-op and would only waste space
>>> in the build.
>>>
>>> Fixes: 81755b8c20f ("usb: host: ehci-generic: Make resets and clocks
>>> optional")
>>> Signed-off-by: Marek Vasut
>>> ---
>>> Cc: Andre Przywara
>>> Cc: Patrice Chotard
>>> ---
>>> drivers/usb/host/ehci-generic.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/usb/host/ehci-generic.c
>>> b/drivers/usb/host/ehci-generic.c
>>> index a765a307a32..83fe701ff67 100644
>>> --- a/drivers/usb/host/ehci-generic.c
>>> +++ b/drivers/usb/host/ehci-generic.c
>>> @@ -81,7 +81,7 @@ static int ehci_usb_probe(struct udevice *dev)
>>> }
>>>
>>> err = reset_get_bulk(dev, >resets);
>>> - if (err && err != -ENOENT) {
>>> + if (err && err != -ENOENT && err != -ENOTSUPP) {
>>> dev_err(dev, "Failed to get resets (err=%d)\n", err);
>>> goto clk_err;
>>> }
>>
>> A similar patch can be applied for testing return value of clk_get_bulk() ?
>> In case CONFIG_CLK is not set, clk_get_bulk() can return -ENOSYS.
>>
>
> I thought without CONFIG_CLK the USB port wouldn't work in general ?
> Is there a case where it works ? (a board with the clocks enabled
Yes it's the case for stih410-b2260 board. All clocks are enabled by default by
bootrom.
I have just noticed that CONFIG_CLK is enabled for this board, but it shouldn't
as there is no
clock driver implemented for it.
I made a quick test on stih410-b2260 (i haven't test this board for a while)
with CONFIG_CLK
disable as it should be, and the following patch is needed :
err = 0;
ret = clk_get_bulk(dev, >clocks);
- if (ret && ret != -ENOENT) {
+ if (ret && ret != -ENOENT && ret != -ENOSYS) {
dev_err(dev, "Failed to get clocks (ret=%d)\n", ret);
return ret;
> before U-Boot or something?) I once sent a patch[1] allowing some of
> the clocks to fail to be got, but it still returned error if they all
> failed.
>
> [1]
> https://patchwork.ozlabs.org/project/uboot/patch/Y44+ayJfUlI08ptM@localhost/
>
This patch is superseeded and v3 [1] doesn't update ehci_generic.c anymore ?
[1] https://patchwork.ozlabs.org/project/uboot/patch/Y5IWpjYLB4aXMy9o@localhost/
Patrice
Re: [0/4] Add eMMC 5.1 support for Versal NET
Hi Jaehoon, On 1/10/23 12:31, Ashok Reddy Soma wrote: This patch series, - Add support for eMMC5.1 on Versal NET platform by adding new compatible string and PHY support. - Add support for input and output tap delays for eMMC - Add support for enabling HS400 in host capabilities by checking quirk. - Add quirk to support HS400 for Versal NET Ashok Reddy Soma (4): mmc: zynq_sdhci: Add support for eMMC5.1 for Versal NET platform mmc: sdhci: Check and call config_dll callback functions mmc: sdhci: Enable HS400 support if available in caps mmc: zynq_sdhci: Add support and quirk for HS400 drivers/mmc/sdhci.c | 20 +++ drivers/mmc/zynq_sdhci.c | 292 ++- include/sdhci.h | 5 + 3 files changed, 314 insertions(+), 3 deletions(-) Can you please review this series? Thanks, Michal
Re: [PATCH] arm64: zynqmp: Add support for Kria K24 SOM
On 1/18/23 13:11, Michal Simek wrote:
SOM itself from PS point of view is using the same configuration as K26
that's why reuse that files and only change compatible strings.
The reason for creating own set of files is just in case when versions
start to diverge because of HW change, supply chain issue, etc.
Signed-off-by: Michal Simek
---
arch/arm/dts/Makefile |2 +
arch/arm/dts/zynqmp-sm-k24-revA.dts | 22 +
arch/arm/dts/zynqmp-smk-k24-revA.dts | 21 +
.../zynqmp/zynqmp-sm-k24-revA/psu_init_gpl.c | 1061 +
board/xilinx/zynqmp/zynqmp-smk-k24-revA |1 +
5 files changed, 1107 insertions(+)
create mode 100644 arch/arm/dts/zynqmp-sm-k24-revA.dts
create mode 100644 arch/arm/dts/zynqmp-smk-k24-revA.dts
create mode 100644 board/xilinx/zynqmp/zynqmp-sm-k24-revA/psu_init_gpl.c
create mode 12 board/xilinx/zynqmp/zynqmp-smk-k24-revA
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 79bec315a2a5..82aa4508873c 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -349,6 +349,8 @@ dtb-$(CONFIG_ARCH_ZYNQMP) += \
zynqmp-mini-emmc1.dtb \
zynqmp-mini-nand.dtb\
zynqmp-mini-qspi.dtb\
+ zynqmp-sm-k24-revA.dtb \
+ zynqmp-smk-k24-revA.dtb \
zynqmp-sm-k26-revA.dtb \
zynqmp-smk-k26-revA.dtb \
zynqmp-sck-kr-g-revA.dtbo \
diff --git a/arch/arm/dts/zynqmp-sm-k24-revA.dts
b/arch/arm/dts/zynqmp-sm-k24-revA.dts
new file mode 100644
index ..24514409cb9e
--- /dev/null
+++ b/arch/arm/dts/zynqmp-sm-k24-revA.dts
@@ -0,0 +1,22 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * dts file for Xilinx ZynqMP SM-K24 RevA
+ *
+ * (C) Copyright 2020 - 2021, Xilinx, Inc.
+ * (C) Copyright 2022, Advanced Micro Devices, Inc.
+ *
+ * Michal Simek
+ */
+
+#include "zynqmp-sm-k26-revA.dts"
+
+/ {
+ model = "ZynqMP SM-K24 RevA";
+ compatible = "xlnx,zynqmp-sm-k24-revA", "xlnx,zynqmp-sm-k24",
+"xlnx,zynqmp";
+
+ memory@0 {
+ device_type = "memory"; /* 2GB */
+ reg = <0 0 0 0x8000>;
+ };
+};
diff --git a/arch/arm/dts/zynqmp-smk-k24-revA.dts
b/arch/arm/dts/zynqmp-smk-k24-revA.dts
new file mode 100644
index ..7308983b15a0
--- /dev/null
+++ b/arch/arm/dts/zynqmp-smk-k24-revA.dts
@@ -0,0 +1,21 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * dts file for Xilinx ZynqMP SMK-K24 RevA
+ *
+ * (C) Copyright 2020 - 2021, Xilinx, Inc.
+ * (C) Copyright 2022, Advanced Micro Devices, Inc.
+ *
+ * Michal Simek
+ */
+
+#include "zynqmp-sm-k24-revA.dts"
+
+/ {
+ model = "ZynqMP SMK-K24 RevA";
+ compatible = "xlnx,zynqmp-smk-k24-revA", "xlnx,zynqmp-smk-k24",
+"xlnx,zynqmp";
+};
+
+ {
+ status = "disabled";
+};
diff --git a/board/xilinx/zynqmp/zynqmp-sm-k24-revA/psu_init_gpl.c
b/board/xilinx/zynqmp/zynqmp-sm-k24-revA/psu_init_gpl.c
new file mode 100644
index ..45102302dc2c
--- /dev/null
+++ b/board/xilinx/zynqmp/zynqmp-sm-k24-revA/psu_init_gpl.c
@@ -0,0 +1,1061 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (c) Copyright 2015 Xilinx, Inc. All rights reserved.
+ */
+
+#include
+#include
+
+static void dpll_prog(int div2, int ddr_pll_fbdiv, int d_lock_dly,
+ int d_lock_cnt, int d_lfhf, int d_cp, int d_res)
+{
+ unsigned int pll_ctrl_regval;
+ unsigned int pll_status_regval;
+
+ pll_ctrl_regval = Xil_In32(((0xFD1AU) + 0x002C));
+ pll_ctrl_regval = pll_ctrl_regval & (~0x0001U);
+ pll_ctrl_regval = pll_ctrl_regval | (div2 << 16);
+ Xil_Out32(((0xFD1AU) + 0x002C), pll_ctrl_regval);
+
+ pll_ctrl_regval = Xil_In32(((0xFD1AU) + 0x0030));
+ pll_ctrl_regval = pll_ctrl_regval & (~0xFE00U);
+ pll_ctrl_regval = pll_ctrl_regval | (d_lock_dly << 25);
+ Xil_Out32(((0xFD1AU) + 0x0030), pll_ctrl_regval);
+
+ pll_ctrl_regval = Xil_In32(((0xFD1AU) + 0x0030));
+ pll_ctrl_regval = pll_ctrl_regval & (~0x007FE000U);
+ pll_ctrl_regval = pll_ctrl_regval | (d_lock_cnt << 13);
+ Xil_Out32(((0xFD1AU) + 0x0030), pll_ctrl_regval);
+
+ pll_ctrl_regval = Xil_In32(((0xFD1AU) + 0x0030));
+ pll_ctrl_regval = pll_ctrl_regval & (~0x0C00U);
+ pll_ctrl_regval = pll_ctrl_regval | (d_lfhf << 10);
+ Xil_Out32(((0xFD1AU) + 0x0030), pll_ctrl_regval);
+
+ pll_ctrl_regval = Xil_In32(((0xFD1AU) + 0x0030));
+ pll_ctrl_regval = pll_ctrl_regval & (~0x01E0U);
+ pll_ctrl_regval = pll_ctrl_regval | (d_cp << 5);
+ Xil_Out32(((0xFD1AU) + 0x0030), pll_ctrl_regval);
+
+ pll_ctrl_regval = Xil_In32(((0xFD1AU) + 0x0030));
+ pll_ctrl_regval = pll_ctrl_regval & (~0x000FU);
+
Re: [PATCH] arm64: zynqmp: Fill model name for SOM CCs
On 1/18/23 13:04, Michal Simek wrote:
When U-Boot do DTB reselection origin model for SOM is used and from log it
is not visible if DTB was switched or not. That's why add model directly to
CC (carrier card) to show new model if reselection was successful.
Signed-off-by: Michal Simek
---
arch/arm/dts/zynqmp-sck-kr-g-revA.dts | 1 +
arch/arm/dts/zynqmp-sck-kr-g-revB.dts | 1 +
arch/arm/dts/zynqmp-sck-kv-g-revA.dts | 1 +
arch/arm/dts/zynqmp-sck-kv-g-revB.dts | 1 +
4 files changed, 4 insertions(+)
diff --git a/arch/arm/dts/zynqmp-sck-kr-g-revA.dts
b/arch/arm/dts/zynqmp-sck-kr-g-revA.dts
index 735c1e3d1a88..83c65029c75f 100644
--- a/arch/arm/dts/zynqmp-sck-kr-g-revA.dts
+++ b/arch/arm/dts/zynqmp-sck-kr-g-revA.dts
@@ -18,6 +18,7 @@
&{/} {
compatible = "xlnx,zynqmp-sk-kr260-revA",
"xlnx,zynqmp-sk-kr260", "xlnx,zynqmp";
+ model = "ZynqMP KR260 revA";
ina260-u14 {
compatible = "iio-hwmon";
diff --git a/arch/arm/dts/zynqmp-sck-kr-g-revB.dts
b/arch/arm/dts/zynqmp-sck-kr-g-revB.dts
index 63590619d43e..f41a2f830caf 100644
--- a/arch/arm/dts/zynqmp-sck-kr-g-revB.dts
+++ b/arch/arm/dts/zynqmp-sck-kr-g-revB.dts
@@ -18,6 +18,7 @@
&{/} {
compatible = "xlnx,zynqmp-sk-kr260-revB",
"xlnx,zynqmp-sk-kr260", "xlnx,zynqmp";
+ model = "ZynqMP KR260 revB";
ina260-u14 {
compatible = "iio-hwmon";
diff --git a/arch/arm/dts/zynqmp-sck-kv-g-revA.dts
b/arch/arm/dts/zynqmp-sck-kv-g-revA.dts
index b714bd3eb1b1..0be5b29c0512 100644
--- a/arch/arm/dts/zynqmp-sck-kv-g-revA.dts
+++ b/arch/arm/dts/zynqmp-sck-kv-g-revA.dts
@@ -25,6 +25,7 @@
"xlnx,zynqmp-sk-kv260-revY",
"xlnx,zynqmp-sk-kv260-revZ",
"xlnx,zynqmp-sk-kv260", "xlnx,zynqmp";
+ model = "ZynqMP KV260 revA";
};
{ /* I2C_SCK C23/C24 - MIO from SOM */
diff --git a/arch/arm/dts/zynqmp-sck-kv-g-revB.dts
b/arch/arm/dts/zynqmp-sck-kv-g-revB.dts
index a1d8f9f0e51f..fca57a6d91eb 100644
--- a/arch/arm/dts/zynqmp-sck-kv-g-revB.dts
+++ b/arch/arm/dts/zynqmp-sck-kv-g-revB.dts
@@ -19,6 +19,7 @@
compatible = "xlnx,zynqmp-sk-kv260-rev1",
"xlnx,zynqmp-sk-kv260-revB",
"xlnx,zynqmp-sk-kv260", "xlnx,zynqmp";
+ model = "ZynqMP KV260 revB";
};
{ /* I2C_SCK C23/C24 - MIO from SOM */
Applied.
M
Re: [PATCH] arm64: versal: Remove xilinx_versal_mini_qspi.h configs
On 1/18/23 12:26, Michal Simek wrote:
The commit eaf6ea6a1dc1 ("Migrate CUSTOM_SYS_INIT_SP_ADDR to Kconfig using
system-constants.h") moved custom init stack pointer address to Kconfig
which ends up in situation that xilinx_versal_mini_qspi.h is not
needed anymore. That's why remove the file and move defconfigs directly to
xilinx_versal_mini.h configuration.
Signed-off-by: Michal Simek
---
configs/xilinx_versal_mini_defconfig | 2 +-
configs/xilinx_versal_mini_ospi_defconfig | 2 +-
configs/xilinx_versal_mini_qspi_defconfig | 2 +-
include/configs/xilinx_versal_mini_qspi.h | 15 ---
4 files changed, 3 insertions(+), 18 deletions(-)
delete mode 100644 include/configs/xilinx_versal_mini_qspi.h
diff --git a/configs/xilinx_versal_mini_defconfig
b/configs/xilinx_versal_mini_defconfig
index 3c5ab01aa9ee..463aee410ef2 100644
--- a/configs/xilinx_versal_mini_defconfig
+++ b/configs/xilinx_versal_mini_defconfig
@@ -1,5 +1,5 @@
CONFIG_ARM=y
-CONFIG_SYS_CONFIG_NAME="xilinx_versal_mini_qspi"
+CONFIG_SYS_CONFIG_NAME="xilinx_versal_mini"
CONFIG_SYS_ICACHE_OFF=y
CONFIG_COUNTER_FREQUENCY=1
CONFIG_ARCH_VERSAL=y
diff --git a/configs/xilinx_versal_mini_ospi_defconfig
b/configs/xilinx_versal_mini_ospi_defconfig
index abcd20ba8570..f9fdf61747dd 100644
--- a/configs/xilinx_versal_mini_ospi_defconfig
+++ b/configs/xilinx_versal_mini_ospi_defconfig
@@ -1,5 +1,5 @@
CONFIG_ARM=y
-CONFIG_SYS_CONFIG_NAME="xilinx_versal_mini_qspi"
+CONFIG_SYS_CONFIG_NAME="xilinx_versal_mini"
CONFIG_COUNTER_FREQUENCY=1
CONFIG_ARCH_VERSAL=y
CONFIG_TEXT_BASE=0xFFFC
diff --git a/configs/xilinx_versal_mini_qspi_defconfig
b/configs/xilinx_versal_mini_qspi_defconfig
index 11aff80f14f2..9fc3eb69e7e2 100644
--- a/configs/xilinx_versal_mini_qspi_defconfig
+++ b/configs/xilinx_versal_mini_qspi_defconfig
@@ -1,5 +1,5 @@
CONFIG_ARM=y
-CONFIG_SYS_CONFIG_NAME="xilinx_versal_mini_qspi"
+CONFIG_SYS_CONFIG_NAME="xilinx_versal_mini"
CONFIG_COUNTER_FREQUENCY=1
CONFIG_ARCH_VERSAL=y
CONFIG_TEXT_BASE=0xFFFC
diff --git a/include/configs/xilinx_versal_mini_qspi.h
b/include/configs/xilinx_versal_mini_qspi.h
deleted file mode 100644
index e2f2df293540..
--- a/include/configs/xilinx_versal_mini_qspi.h
+++ /dev/null
@@ -1,15 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 */
-/*
- * Configuration for Xilinx Versal QSPI Flash utility
- *
- * (C) Copyright 2018-2019 Xilinx, Inc.
- * Michal Simek
- * Siva Durga Prasad Paladugu
- */
-
-#ifndef __CONFIG_VERSAL_MINI_QSPI_H
-#define __CONFIG_VERSAL_MINI_QSPI_H
-
-#include
-
-#endif /* __CONFIG_VERSAL_MINI_QSPI_H */
Applied.
M
Re: [PATCH] arm64: zynqmp: Remove xilinx_zynqmp_mini_emmc/qspi.h configs
On 1/18/23 12:12, Michal Simek wrote:
The commit eaf6ea6a1dc1 ("Migrate CUSTOM_SYS_INIT_SP_ADDR to Kconfig using
system-constants.h") moved custom init stack pointer address to Kconfig
which ends up in situation that xilinx_zynqmp_mini_emmc/qspi.h are not
needed anymore. That's why remove files and move defconfigs directly to
xilinx_zynqmp_mini.h configuration.
Signed-off-by: Michal Simek
---
configs/xilinx_zynqmp_mini_defconfig | 2 +-
configs/xilinx_zynqmp_mini_emmc0_defconfig | 2 +-
configs/xilinx_zynqmp_mini_emmc1_defconfig | 2 +-
configs/xilinx_zynqmp_mini_qspi_defconfig | 2 +-
include/configs/xilinx_zynqmp_mini_emmc.h | 15 ---
include/configs/xilinx_zynqmp_mini_qspi.h | 15 ---
6 files changed, 4 insertions(+), 34 deletions(-)
delete mode 100644 include/configs/xilinx_zynqmp_mini_emmc.h
delete mode 100644 include/configs/xilinx_zynqmp_mini_qspi.h
diff --git a/configs/xilinx_zynqmp_mini_defconfig
b/configs/xilinx_zynqmp_mini_defconfig
index d8b3aab94f1f..9680d9b1c2f0 100644
--- a/configs/xilinx_zynqmp_mini_defconfig
+++ b/configs/xilinx_zynqmp_mini_defconfig
@@ -1,5 +1,5 @@
CONFIG_ARM=y
-CONFIG_SYS_CONFIG_NAME="xilinx_zynqmp_mini_qspi"
+CONFIG_SYS_CONFIG_NAME="xilinx_zynqmp_mini"
CONFIG_SYS_ICACHE_OFF=y
CONFIG_ARCH_ZYNQMP=y
CONFIG_TEXT_BASE=0xFFFC
diff --git a/configs/xilinx_zynqmp_mini_emmc0_defconfig
b/configs/xilinx_zynqmp_mini_emmc0_defconfig
index a1ee98dfc252..93aaa9304b32 100644
--- a/configs/xilinx_zynqmp_mini_emmc0_defconfig
+++ b/configs/xilinx_zynqmp_mini_emmc0_defconfig
@@ -1,5 +1,5 @@
CONFIG_ARM=y
-CONFIG_SYS_CONFIG_NAME="xilinx_zynqmp_mini_emmc"
+CONFIG_SYS_CONFIG_NAME="xilinx_zynqmp_mini"
CONFIG_SYS_ICACHE_OFF=y
CONFIG_ARCH_ZYNQMP=y
CONFIG_TEXT_BASE=0x1
diff --git a/configs/xilinx_zynqmp_mini_emmc1_defconfig
b/configs/xilinx_zynqmp_mini_emmc1_defconfig
index 88c95d4ce2a0..81ea67acedbe 100644
--- a/configs/xilinx_zynqmp_mini_emmc1_defconfig
+++ b/configs/xilinx_zynqmp_mini_emmc1_defconfig
@@ -1,5 +1,5 @@
CONFIG_ARM=y
-CONFIG_SYS_CONFIG_NAME="xilinx_zynqmp_mini_emmc"
+CONFIG_SYS_CONFIG_NAME="xilinx_zynqmp_mini"
CONFIG_SYS_ICACHE_OFF=y
CONFIG_ARCH_ZYNQMP=y
CONFIG_TEXT_BASE=0x1
diff --git a/configs/xilinx_zynqmp_mini_qspi_defconfig
b/configs/xilinx_zynqmp_mini_qspi_defconfig
index 7ef62dbcdab6..046cbcf30b60 100644
--- a/configs/xilinx_zynqmp_mini_qspi_defconfig
+++ b/configs/xilinx_zynqmp_mini_qspi_defconfig
@@ -1,5 +1,5 @@
CONFIG_ARM=y
-CONFIG_SYS_CONFIG_NAME="xilinx_zynqmp_mini_qspi"
+CONFIG_SYS_CONFIG_NAME="xilinx_zynqmp_mini"
CONFIG_SYS_ICACHE_OFF=y
CONFIG_ARCH_ZYNQMP=y
CONFIG_TEXT_BASE=0xFFFC
diff --git a/include/configs/xilinx_zynqmp_mini_emmc.h
b/include/configs/xilinx_zynqmp_mini_emmc.h
deleted file mode 100644
index f423ddd08ec5..
--- a/include/configs/xilinx_zynqmp_mini_emmc.h
+++ /dev/null
@@ -1,15 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0+ */
-/*
- * Configuration for Xilinx ZynqMP eMMC Flash utility
- *
- * (C) Copyright 2018 Xilinx, Inc.
- * Michal Simek
- * Siva Durga Prasad Paladugu
- */
-
-#ifndef __CONFIG_ZYNQMP_MINI_EMMC_H
-#define __CONFIG_ZYNQMP_MINI_EMMC_H
-
-#include
-
-#endif /* __CONFIG_ZYNQMP_MINI_EMMC_H */
diff --git a/include/configs/xilinx_zynqmp_mini_qspi.h
b/include/configs/xilinx_zynqmp_mini_qspi.h
deleted file mode 100644
index 5bea1c9908c7..
--- a/include/configs/xilinx_zynqmp_mini_qspi.h
+++ /dev/null
@@ -1,15 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0+ */
-/*
- * Configuration for Xilinx ZynqMP QSPI Flash utility
- *
- * (C) Copyright 2018 Xilinx, Inc.
- * Michal Simek
- * Siva Durga Prasad Paladugu
- */
-
-#ifndef __CONFIG_ZYNQMP_MINI_QSPI_H
-#define __CONFIG_ZYNQMP_MINI_QSPI_H
-
-#include
-
-#endif /* __CONFIG_ZYNQMP_MINI_QSPI_H */
Applied.
M
Re: [PATCH] soc: zynqmp: Fix IDcode for xck24
On 1/18/23 09:25, Michal Simek wrote:
ID code was added by commit ddf8deabc39d ("arm64: zynqmp: Add support for
SVD devices") based on documentation but after receiving part new ID code
came up. That's why fix IDcode to match xck24 module.
Signed-off-by: Michal Simek
---
drivers/soc/soc_xilinx_zynqmp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/soc/soc_xilinx_zynqmp.c b/drivers/soc/soc_xilinx_zynqmp.c
index a51bcdb478fb..afa277f6049f 100644
--- a/drivers/soc/soc_xilinx_zynqmp.c
+++ b/drivers/soc/soc_xilinx_zynqmp.c
@@ -186,7 +186,7 @@ static const struct zynqmp_device zynqmp_devices[] = {
.variants = ZYNQMP_VARIANT_DR,
},
{
- .id = 0x04714093,
+ .id = 0x04712093,
.device = 24,
.variants = 0,
},
Applied.
M
Re: [PATCH 01/14] trace: Use notrace for short
Hi Simon,
Am 24.01.2023 um 11:55 schrieb Simon Glass:
Hi Stefan,
On Tue, 24 Jan 2023 at 01:12, Stefan Herbrechtsmeier
wrote:
Hi Simon,
Am 22.12.2022 um 00:08 schrieb Simon Glass:
The attribute syntax is quite verbose. Use the macro provided for this
purpose.
Signed-off-by: Simon Glass
---
arch/arm/cpu/armv7/s5p-common/timer.c | 2 +-
arch/arm/mach-exynos/include/mach/cpu.h | 6 +++---
arch/x86/include/asm/global_data.h | 2 +-
arch/x86/include/asm/msr.h | 2 +-
arch/x86/include/asm/u-boot-x86.h | 2 +-
common/spl/spl_fit.c| 1 +
doc/develop/trace.rst | 2 +-
lib/efi_loader/efi_freestanding.c | 4 ++--
lib/trace.c | 26 +++--
9 files changed, 22 insertions(+), 25 deletions(-)
[snip]
diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
index 08da7fed88e..0e026bb3d8e 100644
--- a/common/spl/spl_fit.c
+++ b/common/spl/spl_fit.c
@@ -599,6 +599,7 @@ static int spl_fit_upload_fpga(struct spl_fit_info *ctx,
int node,
debug("Ignoring compatible = %s property\n",
compatible);
}
+ return 0;
ret = fpga_load(devnum, (void *)fpga_image->load_addr,
fpga_image->size, BIT_FULL, flags);
This return makes the spl_fit_upload_fpga function useless. I assume
this change was by accident.
Yes that was a mistake. I'll send a patch.
Thanks.
Do you think it would be possible to create a sandbox driver for the
FPGA uclass? Then we could add some tests for this code.
A sandbox driver exists but the uclass is only an empty dummy.
The fpga subsystem use its own structs to describe the hardware and the
fpga_load function for example is a wrapper for xilinx_load, altera_load
and lattice_load.
Regards
Stefan
Re: [PATCH 47/88] mtd: Drop unused fsmc_nand driver
Hi
On Mon, Jan 23, 2023 at 11:03 PM Simon Glass wrote:
>
> This is not used since this commit:
>
>570c3dcfc15 arm: Remove spear600 boards and the rest of SPEAr support
>
> Drop the driver and Kconfig option.
>
> Signed-off-by: Simon Glass
> ---
>
> drivers/mtd/nand/raw/Makefile| 1 -
> drivers/mtd/nand/raw/fsmc_nand.c | 470 ---
> include/linux/mtd/fsmc_nand.h| 84 --
> 3 files changed, 555 deletions(-)
> delete mode 100644 drivers/mtd/nand/raw/fsmc_nand.c
> delete mode 100644 include/linux/mtd/fsmc_nand.h
>
> diff --git a/drivers/mtd/nand/raw/Makefile b/drivers/mtd/nand/raw/Makefile
> index e8764cf358b..f004eb39f3b 100644
> --- a/drivers/mtd/nand/raw/Makefile
> +++ b/drivers/mtd/nand/raw/Makefile
> @@ -56,7 +56,6 @@ obj-$(CONFIG_NAND_DENALI) += denali.o
> obj-$(CONFIG_NAND_DENALI_DT) += denali_dt.o
> obj-$(CONFIG_NAND_FSL_ELBC) += fsl_elbc_nand.o
> obj-$(CONFIG_NAND_FSL_IFC) += fsl_ifc_nand.o
> -obj-$(CONFIG_NAND_FSMC) += fsmc_nand.o
> obj-$(CONFIG_NAND_KB9202) += kb9202_nand.o
> obj-$(CONFIG_NAND_KIRKWOOD) += kirkwood_nand.o
> obj-$(CONFIG_NAND_KMETER1) += kmeter1_nand.o
> diff --git a/drivers/mtd/nand/raw/fsmc_nand.c
> b/drivers/mtd/nand/raw/fsmc_nand.c
> deleted file mode 100644
> index d795864949c..000
> --- a/drivers/mtd/nand/raw/fsmc_nand.c
> +++ /dev/null
> @@ -1,470 +0,0 @@
> -// SPDX-License-Identifier: GPL-2.0+
> -/*
> - * (C) Copyright 2010
> - * Vipin Kumar, STMicroelectronics, vipin.ku...@st.com.
> - *
> - * (C) Copyright 2012
> - * Amit Virdi, STMicroelectronics, amit.vi...@st.com.
> - */
> -
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -
> -static u32 fsmc_version;
> -static struct fsmc_regs *const fsmc_regs_p = (struct fsmc_regs *)
> - CONFIG_SYS_FSMC_BASE;
> -
> -/*
> - * ECC4 and ECC1 have 13 bytes and 3 bytes of ecc respectively for 512 bytes
> of
> - * data. ECC4 can correct up to 8 bits in 512 bytes of data while ECC1 can
> - * correct 1 bit in 512 bytes
> - */
> -
> -static struct nand_ecclayout fsmc_ecc4_lp_layout = {
> - .eccbytes = 104,
> - .eccpos = { 2, 3, 4, 5, 6, 7, 8,
> - 9, 10, 11, 12, 13, 14,
> - 18, 19, 20, 21, 22, 23, 24,
> - 25, 26, 27, 28, 29, 30,
> - 34, 35, 36, 37, 38, 39, 40,
> - 41, 42, 43, 44, 45, 46,
> - 50, 51, 52, 53, 54, 55, 56,
> - 57, 58, 59, 60, 61, 62,
> - 66, 67, 68, 69, 70, 71, 72,
> - 73, 74, 75, 76, 77, 78,
> - 82, 83, 84, 85, 86, 87, 88,
> - 89, 90, 91, 92, 93, 94,
> - 98, 99, 100, 101, 102, 103, 104,
> - 105, 106, 107, 108, 109, 110,
> - 114, 115, 116, 117, 118, 119, 120,
> - 121, 122, 123, 124, 125, 126
> - },
> - .oobfree = {
> - {.offset = 15, .length = 3},
> - {.offset = 31, .length = 3},
> - {.offset = 47, .length = 3},
> - {.offset = 63, .length = 3},
> - {.offset = 79, .length = 3},
> - {.offset = 95, .length = 3},
> - {.offset = 111, .length = 3},
> - {.offset = 127, .length = 1}
> - }
> -};
> -
> -/*
> - * ECC4 layout for NAND of pagesize 4096 bytes & OOBsize 224 bytes. 13*8
> bytes
> - * of OOB size is reserved for ECC, Byte no. 0 & 1 reserved for bad block &
> 118
> - * bytes are free for use.
> - */
> -static struct nand_ecclayout fsmc_ecc4_224_layout = {
> - .eccbytes = 104,
> - .eccpos = { 2, 3, 4, 5, 6, 7, 8,
> - 9, 10, 11, 12, 13, 14,
> - 18, 19, 20, 21, 22, 23, 24,
> - 25, 26, 27, 28, 29, 30,
> - 34, 35, 36, 37, 38, 39, 40,
> - 41, 42, 43, 44, 45, 46,
> - 50, 51, 52, 53, 54, 55, 56,
> - 57, 58, 59, 60, 61, 62,
> - 66, 67, 68, 69, 70, 71, 72,
> - 73, 74, 75, 76, 77, 78,
> - 82, 83, 84, 85, 86, 87, 88,
> - 89, 90, 91, 92, 93, 94,
> - 98, 99, 100, 101, 102, 103, 104,
> - 105, 106, 107, 108, 109, 110,
> - 114, 115, 116, 117, 118, 119, 120,
> - 121, 122, 123, 124, 125, 126
> - },
> - .oobfree = {
> - {.offset = 15, .length = 3},
> - {.offset = 31, .length = 3},
> - {.offset = 47, .length = 3},
> - {.offset = 63, .length = 3},
> - {.offset = 79, .length = 3},
> - {.offset = 95, .length = 3},
> - {.offset = 111, .length = 3},
> - {.offset = 127, .length = 97}
> - }
> -};
> -
> -/*
> - * ECC placement definitions in oobfree type format
> - * There are 13
Re: [PATCH 46/88] mtd: Drop unused fsl_upm driver
Hi
On Mon, Jan 23, 2023 at 11:03 PM Simon Glass wrote:
>
> This is not used since this commit:
>
>8d1e3cb1400 powerpc: mpc83xx: remove MPC8360ERDK, EMPC8360EMDS support
>
No problem to drop here.
> Drop the driver and Kconfig option.
>
> Signed-off-by: Simon Glass
> ---
>
> drivers/mtd/nand/raw/Makefile | 1 -
> drivers/mtd/nand/raw/fsl_upm.c | 187 -
> include/linux/mtd/fsl_upm.h| 44
> 3 files changed, 232 deletions(-)
> delete mode 100644 drivers/mtd/nand/raw/fsl_upm.c
> delete mode 100644 include/linux/mtd/fsl_upm.h
>
> diff --git a/drivers/mtd/nand/raw/Makefile b/drivers/mtd/nand/raw/Makefile
> index 4c59903aa8c..e8764cf358b 100644
> --- a/drivers/mtd/nand/raw/Makefile
> +++ b/drivers/mtd/nand/raw/Makefile
> @@ -56,7 +56,6 @@ obj-$(CONFIG_NAND_DENALI) += denali.o
> obj-$(CONFIG_NAND_DENALI_DT) += denali_dt.o
> obj-$(CONFIG_NAND_FSL_ELBC) += fsl_elbc_nand.o
> obj-$(CONFIG_NAND_FSL_IFC) += fsl_ifc_nand.o
> -obj-$(CONFIG_NAND_FSL_UPM) += fsl_upm.o
> obj-$(CONFIG_NAND_FSMC) += fsmc_nand.o
> obj-$(CONFIG_NAND_KB9202) += kb9202_nand.o
> obj-$(CONFIG_NAND_KIRKWOOD) += kirkwood_nand.o
> diff --git a/drivers/mtd/nand/raw/fsl_upm.c b/drivers/mtd/nand/raw/fsl_upm.c
> deleted file mode 100644
> index 91cc1339537..000
> --- a/drivers/mtd/nand/raw/fsl_upm.c
> +++ /dev/null
> @@ -1,187 +0,0 @@
> -// SPDX-License-Identifier: GPL-2.0+
> -/*
> - * FSL UPM NAND driver
> - *
> - * Copyright (C) 2007 MontaVista Software, Inc.
> - *Anton Vorontsov
> - */
> -
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -
> -static void fsl_upm_start_pattern(struct fsl_upm *upm, u32 pat_offset)
> -{
> - clrsetbits_be32(upm->mxmr, MxMR_MAD_MSK, MxMR_OP_RUNP | pat_offset);
> - (void)in_be32(upm->mxmr);
> -}
> -
> -static void fsl_upm_end_pattern(struct fsl_upm *upm)
> -{
> - clrbits_be32(upm->mxmr, MxMR_OP_RUNP);
> -
> - while (in_be32(upm->mxmr) & MxMR_OP_RUNP)
> - eieio();
> -}
> -
> -static void fsl_upm_run_pattern(struct fsl_upm *upm, int width,
> - void __iomem *io_addr, u32 mar)
> -{
> - out_be32(upm->mar, mar);
> - (void)in_be32(upm->mar);
> - switch (width) {
> - case 8:
> - out_8(io_addr, 0x0);
> - break;
> - case 16:
> - out_be16(io_addr, 0x0);
> - break;
> - case 32:
> - out_be32(io_addr, 0x0);
> - break;
> - }
> -}
> -
> -static void fun_wait(struct fsl_upm_nand *fun)
> -{
> - if (fun->dev_ready) {
> - while (!fun->dev_ready(fun->chip_nr))
> - debug("unexpected busy state\n");
> - } else {
> - /*
> -* If the R/B pin is not connected,
> -* a short delay is necessary.
> -*/
> - udelay(1);
> - }
> -}
> -
> -#if CONFIG_SYS_NAND_MAX_CHIPS > 1
> -static void fun_select_chip(struct mtd_info *mtd, int chip_nr)
> -{
> - struct nand_chip *chip = mtd_to_nand(mtd);
> - struct fsl_upm_nand *fun = nand_get_controller_data(chip);
> -
> - if (chip_nr >= 0) {
> - fun->chip_nr = chip_nr;
> - chip->IO_ADDR_R = chip->IO_ADDR_W =
> - fun->upm.io_addr + fun->chip_offset * chip_nr;
> - } else if (chip_nr == -1) {
> - chip->cmd_ctrl(mtd, NAND_CMD_NONE, 0 | NAND_CTRL_CHANGE);
> - }
> -}
> -#endif
> -
> -static void fun_cmd_ctrl(struct mtd_info *mtd, int cmd, unsigned int ctrl)
> -{
> - struct nand_chip *chip = mtd_to_nand(mtd);
> - struct fsl_upm_nand *fun = nand_get_controller_data(chip);
> - void __iomem *io_addr;
> - u32 mar;
> -
> - if (!(ctrl & fun->last_ctrl)) {
> - fsl_upm_end_pattern(>upm);
> -
> - if (cmd == NAND_CMD_NONE)
> - return;
> -
> - fun->last_ctrl = ctrl & (NAND_ALE | NAND_CLE);
> - }
> -
> - if (ctrl & NAND_CTRL_CHANGE) {
> - if (ctrl & NAND_ALE)
> - fsl_upm_start_pattern(>upm,
> fun->upm_addr_offset);
> - else if (ctrl & NAND_CLE)
> - fsl_upm_start_pattern(>upm, fun->upm_cmd_offset);
> - }
> -
> - mar = cmd << (32 - fun->width);
> - io_addr = fun->upm.io_addr;
> -#if CONFIG_SYS_NAND_MAX_CHIPS > 1
> - if (fun->chip_nr > 0) {
> - io_addr += fun->chip_offset * fun->chip_nr;
> - if (fun->upm_mar_chip_offset)
> - mar |= fun->upm_mar_chip_offset * fun->chip_nr;
> - }
> -#endif
> - fsl_upm_run_pattern(>upm, fun->width, io_addr, mar);
> -
> - /*
> -* Some boards/chips needs this. At least the MPC8360E-RDK
> -* needs it. Probably weird chip, because I don't see any
> -
Re: [PATCH 04/88] nand: Drop CONFIG_NAND_SPEAR
Hi On Mon, Jan 23, 2023 at 11:02 PM Simon Glass wrote: > > This is not used anymore. Drop it. > > Signed-off-by: Simon Glass > --- > > drivers/mtd/nand/raw/Makefile | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/mtd/nand/raw/Makefile b/drivers/mtd/nand/raw/Makefile > index 7320d581e2f..4c59903aa8c 100644 > --- a/drivers/mtd/nand/raw/Makefile > +++ b/drivers/mtd/nand/raw/Makefile > @@ -70,7 +70,6 @@ obj-$(CONFIG_NAND_MXS_DT) += mxs_nand_dt.o > obj-$(CONFIG_NAND_OCTEONTX) += octeontx_nand.o > obj-$(CONFIG_NAND_OCTEONTX_HW_ECC) += octeontx_bch.o > obj-$(CONFIG_NAND_PXA3XX) += pxa3xx_nand.o > -obj-$(CONFIG_NAND_SPEAR) += spr_nand.o > obj-$(CONFIG_TEGRA_NAND) += tegra_nand.o > obj-$(CONFIG_NAND_OMAP_GPMC) += omap_gpmc.o > obj-$(CONFIG_NAND_OMAP_ELM) += omap_elm.o > -- > 2.39.1.456.gfc5497dd1b-goog > Reviewed-by: Michael Trimarchi -- Michael Nazzareno Trimarchi Co-Founder & Chief Executive Officer M. +39 347 913 2170 mich...@amarulasolutions.com __ Amarula Solutions BV Joop Geesinkweg 125, 1114 AB, Amsterdam, NL T. +31 (0)85 111 9172 i...@amarulasolutions.com www.amarulasolutions.com
Re: [PATCH] spl: Drop unwanted return in spl_fit_upload_fpga()
On Tue, Jan 24, 2023 at 12:56 PM Simon Glass wrote:
>
> This was added by mistake and renders the function useless. Fix it.
>
> Signed-off-by: Simon Glass
> Fixes: 33c60a38bb9 ("trace: Use notrace for short")
> Reported-by: Stefan Herbrechtsmeier
>
Reviewed-by: Oleksandr Suvorov
> ---
>
> common/spl/spl_fit.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
> index 9ae3e5e35d4..c51482b3b65 100644
> --- a/common/spl/spl_fit.c
> +++ b/common/spl/spl_fit.c
> @@ -591,7 +591,6 @@ static int spl_fit_upload_fpga(struct spl_fit_info *ctx,
> int node,
> debug("Ignoring compatible = %s property\n",
> compatible);
> }
> - return 0;
>
> ret = fpga_load(devnum, (void *)fpga_image->load_addr,
> fpga_image->size, BIT_FULL, flags);
> --
> 2.39.0.246.g2a6d74b583-goog
>
--
Best regards
Oleksandr
Oleksandr Suvorov
cryo...@gmail.com
Re: [PATCH v8 03/10] arm_ffa: introduce Arm FF-A low-level driver
Hi Simon, On Mon, Jan 23, 2023 at 09:32:19AM -0700, Simon Glass wrote: > Hi Sudeep, > > I'd like to see DT defined across firmware and OS, not just be a Linux > thing. Fair enough. > It is a better approach than having little fiefdoms everywhere > with their own config mechanisms. > Agreed. > It seems that you have lots of build-time config in the ARM > components. Not really. I think I have not conveyed the setup details properly. Let me try to explain with 2 hopefully simple examples: 1. Consider a system with a power controller running its own firmware and OS(or any other application software including U-Boot) interacting with it to get the required power resource access/modification. One such thing is CPU operating points(OPP). Typically on old systems, these are listing in the DT and OSPM drives them completely. Now on the newer systems like the one I am presenting, ideally we need to get the list of OPP from the f/w at runtime and use the information to drive it. Suppose we have these information statically built into DT, then if the firmware is upgraded and there is change in the OPP set or if the f/w detects some configuration(bios/similar) that requires change in the OPP set presented to the OSPM(or any other users), then the static info built in the DT is stale or wrong. And hence the use of DT in such a configuation or system is not correct unless DT is populated on the fly interacting with the firmware before DT is consumed by the users. This was one example which I was referring when I said I don't want to use the DT info over live firmware information. 2. Now the FF-A case, if the list of partitions on the system is listed in the DT and there is change in that list due to various reasons(firmware upgrade, reconfiguration, resource disabled for a specific reason,...etc) then the list will be stale when presented to the user(OSPM/Linux/U-Boot) if it is not updated on the fly before the DT data is consumed. Since in both the cases the firmware provides interface to the users to get the information at runtime, I am against using the DT as source of information. -- Regards, Sudeep
Re: [PATCH v3 12/70] dm: part: Update test to use mmc2
Hi Tom,
On Mon, 23 Jan 2023 at 18:39, Tom Rini wrote:
>
> On Tue, Jan 17, 2023 at 10:47:22AM -0700, Simon Glass wrote:
>
> > At present this test sets up a partition table on mmc1. But this is used
> > by the bootstd tests, so it is not possible to run those after this test
> > has run, without restarting the Python test harness.
> >
> > This is inconvenient when running tests repeatedly with 'ut dm'. Move the
> > test to use mmc2, which is not used by anything.
> >
> > Signed-off-by: Simon Glass
>
> When I run tests like this:
> TEST="not sleep and not event_dump and not bootmgr and not extension"
> ./tools/buildman/buildman -o /tmp/sandbox -P --board sandbox
> ./test/py/test.py --bd $ARGS --build-dir /tmp/sandbox -k "$TEST" -ra
> I get:
> == FAILURES
> ===
> _ test_ut[ut_dm_dm_test_part]
> _
> test/py/tests/test_ut.py:341: in test_ut
> assert output.endswith('Failures: 0')
> E assert False
> E+ where False = 0x2776470>('Failures: 0')
> E+where =
> 'Test: dm_test_part: part.c\r\r\n** No device specified **\r\r\nCouldn\'t
> find partition mmc \r\r\n** No device ...: 0 == do_test(uts, 2, "1:2",
> 0): Expected 0x0 (0), got 0x1 (1)\r\r\nTest dm_test_part failed 4
> times\r\r\nFailures: 4'.endswith
> Captured stdout call
> -
> => ut dm dm_test_part
> Test: dm_test_part: part.c
> ** No device specified **
> Couldn't find partition mmc
> ** No device specified **
> Couldn't find partition mmc
> ** No partition table - mmc 0 **
> Couldn't find partition mmc 0
> Could not find "test1" partition
> ** Bad device specification mmc #test1 **
> ** Bad device specification mmc #test1 **
> Couldn't find partition mmc #test1
> ** Bad partition specification mmc 1:0 **
> Couldn't find partition mmc 1:0
> ** Invalid partition 2 **
> Couldn't find partition mmc 1:2
> test/dm/part.c:20, do_test(): expected ==
> part_get_info_by_dev_and_name_or_num("mmc", part_str, _dev_desc,
> _info, whole): Expected 0x2 (2), got 0xfffe (-2)
> test/dm/part.c:82, dm_test_part(): 0 == do_test(uts, 2, "1:2", 0): Expected
> 0x0 (0), got 0x1 (1)
> Test: dm_test_part: part.c (flat tree)
> ** No device specified **
> Couldn't find partition mmc
> ** No device specified **
> Couldn't find partition mmc
> ** No partition table - mmc 0 **
> Couldn't find partition mmc 0
> Could not find "test1" partition
> ** Bad device specification mmc #test1 **
> ** Bad device specification mmc #test1 **
> Couldn't find partition mmc #test1
> ** Bad partition specification mmc 1:0 **
> Couldn't find partition mmc 1:0
> ** Invalid partition 2 **
> Couldn't find partition mmc 1:2
> test/dm/part.c:20, do_test(): expected ==
> part_get_info_by_dev_and_name_or_num("mmc", part_str, _dev_desc,
> _info, whole): Expected 0x2 (2), got 0xfffe (-2)
> test/dm/part.c:82, dm_test_part(): 0 == do_test(uts, 2, "1:2", 0): Expected
> 0x0 (0), got 0x1 (1)
> Test dm_test_part failed 4 times
> Failures: 4
> =>
Oh dear. I believe this is an ordering problem. These two patches need
to be applied together because the first one changes mmc1.img and the
second one relies on that change:
part: Add a function to find the first bootable partition
dm: part: Update test to use mmc2
I have them quite far apart in the series.
I can merge them into one commit, perhaps?
>
> And further tests down the series also fail / introduce failures, but
> this is the first one, and why I thought v2 had more problems.
For some reason I'm not seeing this, but it could be another ordering
thing. I don't see failures on CI but it only tests the whole.
Let me know what you'd like me to do. I don't currently have a way to
run tests on every commit, so my testing there is a bit random. I
normally just build-test the series and then check with CI.
Regards,
Simon
[PATCH] spl: Drop unwanted return in spl_fit_upload_fpga()
This was added by mistake and renders the function useless. Fix it.
Signed-off-by: Simon Glass
Fixes: 33c60a38bb9 ("trace: Use notrace for short")
Reported-by: Stefan Herbrechtsmeier
---
common/spl/spl_fit.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
index 9ae3e5e35d4..c51482b3b65 100644
--- a/common/spl/spl_fit.c
+++ b/common/spl/spl_fit.c
@@ -591,7 +591,6 @@ static int spl_fit_upload_fpga(struct spl_fit_info *ctx,
int node,
debug("Ignoring compatible = %s property\n",
compatible);
}
- return 0;
ret = fpga_load(devnum, (void *)fpga_image->load_addr,
fpga_image->size, BIT_FULL, flags);
--
2.39.0.246.g2a6d74b583-goog
Re: [PATCH 01/14] trace: Use notrace for short
Hi Stefan,
On Tue, 24 Jan 2023 at 01:12, Stefan Herbrechtsmeier
wrote:
>
> Hi Simon,
>
> Am 22.12.2022 um 00:08 schrieb Simon Glass:
> > The attribute syntax is quite verbose. Use the macro provided for this
> > purpose.
> >
> > Signed-off-by: Simon Glass
> > ---
> >
> > arch/arm/cpu/armv7/s5p-common/timer.c | 2 +-
> > arch/arm/mach-exynos/include/mach/cpu.h | 6 +++---
> > arch/x86/include/asm/global_data.h | 2 +-
> > arch/x86/include/asm/msr.h | 2 +-
> > arch/x86/include/asm/u-boot-x86.h | 2 +-
> > common/spl/spl_fit.c| 1 +
> > doc/develop/trace.rst | 2 +-
> > lib/efi_loader/efi_freestanding.c | 4 ++--
> > lib/trace.c | 26 +++--
> > 9 files changed, 22 insertions(+), 25 deletions(-)
> >
>
> [snip]
>
> > diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
> > index 08da7fed88e..0e026bb3d8e 100644
> > --- a/common/spl/spl_fit.c
> > +++ b/common/spl/spl_fit.c
> > @@ -599,6 +599,7 @@ static int spl_fit_upload_fpga(struct spl_fit_info
> > *ctx, int node,
> > debug("Ignoring compatible = %s property\n",
> > compatible);
> > }
> > + return 0;
> >
> > ret = fpga_load(devnum, (void *)fpga_image->load_addr,
> > fpga_image->size, BIT_FULL, flags);
>
>
> This return makes the spl_fit_upload_fpga function useless. I assume
> this change was by accident.
Yes that was a mistake. I'll send a patch.
Do you think it would be possible to create a sandbox driver for the
FPGA uclass? Then we could add some tests for this code.
Regards,
Simon
[PATCH v4] mtd: parsers: ofpart: add workaround for #size-cells 0
From: Francesco Dolcini
Add a mechanism to handle the case in which partitions are present as
direct child of the nand controller node and #size-cells is set to <0>.
This could happen if the nand-controller node in the DTS is supposed to
have #size-cells set to 0, but for some historical reason/bug it was set
to 1 in the past, and the firmware (e.g. U-Boot) is adding the partition
as direct children of the nand-controller defaulting to #size-cells
being to 1.
This prevents a real boot failure on colibri-imx7 that happened during v6.1
development cycles.
Link: https://lore.kernel.org/all/y4dgbtgnwpm6s...@francesco-nb.int.toradex.com/
Link: https://lore.kernel.org/all/20221202071900.1143950-1-france...@dolcini.it/
Signed-off-by: Francesco Dolcini
Reviewed-by: Greg Kroah-Hartman
---
I do not expect this patch to be backported to stable, however I would expect
that we do not backport nand-controller dts cleanups neither.
v4:
fixed wrong English spelling in the comment
v3:
minor formatting change, removed not needed new-line and space.
v2:
fixup size-cells only when partitions are direct children of the
nand-controller
completely revised commit message, comments and warning print
use pr_warn instead of pr_warn_once
added Reviewed-by Greg
removed cc:stable@ and fixes tag, since the problematic commit was reverted
---
drivers/mtd/parsers/ofpart_core.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/mtd/parsers/ofpart_core.c
b/drivers/mtd/parsers/ofpart_core.c
index 192190c42fc8..e7b8e9d0a910 100644
--- a/drivers/mtd/parsers/ofpart_core.c
+++ b/drivers/mtd/parsers/ofpart_core.c
@@ -122,6 +122,25 @@ static int parse_fixed_partitions(struct mtd_info *master,
a_cells = of_n_addr_cells(pp);
s_cells = of_n_size_cells(pp);
+ if (!dedicated && s_cells == 0) {
+ /*
+* This is a ugly workaround to not create
+* regression on devices that are still creating
+* partitions as direct children of the nand controller.
+* This can happen in case the nand controller node has
+* #size-cells equal to 0 and the firmware (e.g.
+* U-Boot) just add the partitions there assuming
+* 32-bit addressing.
+*
+* If you get this warning your firmware and/or DTS
+* should be really fixed.
+*
+* This is working only for devices smaller than 4GiB.
+*/
+ pr_warn("%s: ofpart partition %pOF (%pOF) #size-cells
is wrongly set to <0>, assuming <1> for parsing partitions.\n",
+ master->name, pp, mtd_node);
+ s_cells = 1;
+ }
if (len / 4 != a_cells + s_cells) {
pr_debug("%s: ofpart partition %pOF (%pOF) error
parsing reg property.\n",
master->name, pp,
--
2.25.1
