Re: [PATCH v3 2/2] imx8mn/8mp: Allow booting via USB
Hi Fabio
On Tue, Apr 26, 2022 at 3:57 AM Fabio Estevam wrote:
>
> Hi Tim,
>
> On Mon, Apr 25, 2022 at 8:15 PM Tim Harvey wrote:
>
> > Tested-By: Tim Harvey
>
> Thanks.
>
> > agreed it would be a separate issue... just curious if you knew where
> > that was coming from. It certainly isn't a common behavior to boot via
> > USB then expect 'saveenv' to save to a specific eMMC device.
> >
> > >
> > > I see that you replied to Peng's patch:
> > > "imx: dynamic setting mmcdev and mmcroot" and this is likely the cause
> > > for your env numbering problem.
> >
> > That has nothing to do with the mmc device used for U-Boot env. Commit
> > f342c9e381c0 ("imx: dynamic setting mmcdev and mmcroot") adds setting
> > 'mmcroot=' if mmcautodetect=yes which seems to me like a completely
> > inappropriate hack that assumes U-Boot's mmc device numbering matches
>
> Agreed.
>
> > the kernels device numbering (which has changed over time and is not a
> > stable ABI). I believe you have been involved in discussions about
> > that in the past as well regarding how to best tell the kernel what
> > the root device is. Every discussion I have seen (and there have been
> > many over the years) end up with the recommendation of using UUID.
>
> Yes, using UUID is good solution for that.
>
> mmc alias also works in kernels > 5.10 too.
What changes if we drop? Does the board boot anyway?
Michael
--
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
[PATCH 2/2] doc: boards: amlogic: update jethub d1 specifications
Signed-off-by: Vyacheslav Bocharov --- doc/board/amlogic/jethub-j100.rst | 24 ++-- 1 file changed, 14 insertions(+), 10 deletions(-) diff --git a/doc/board/amlogic/jethub-j100.rst b/doc/board/amlogic/jethub-j100.rst index d54519aaef..8081569bba 100644 --- a/doc/board/amlogic/jethub-j100.rst +++ b/doc/board/amlogic/jethub-j100.rst @@ -3,27 +3,31 @@ U-Boot for JetHub J100 === -JetHome Jethub D1 (http://jethome.ru/jethub-d1) is a home automation -controller manufactured by JetHome with the following specifications: +JetHome Jethub D1 (http://jethome.ru/jethub-d1) is a series of home +automation controller manufactured by JetHome with the following +specifications: - Amlogic A113X (ARM Cortex-A53) quad-core up to 1.5GHz - no video out - - 512Mb/1GB DDR3 - - 8/16GB eMMC flash + - 512MB/1GB DDR3 or 2GB DDR4 SDRAM + - 8/16/32GB eMMC flash - 1 x USB 2.0 - 1 x 10/100Mbps ethernet - - WiFi / Bluetooth AMPAK AP6255 (Broadcom BCM43455) IEEE - 802.11a/b/g/n/ac, Bluetooth 4.2. - - TI CC2538 + CC2592 Zigbee Wireless Module with up to 20dBm output - power and Zigbee 3.0 support. + - WiFi / Bluetooth one from: + - AMPAK AP6255 (Broadcom BCM43455) IEEE 802.11a/b/g/n/ac, Bluetooth 4.2 + - RTL8822CS IEEE 802.11a/b/g/n/ac, Bluetooth 5.0 + - Amlogic W155S1 WiFi5 IEEE 802.11a/b/g/n/ac, Bluetooth 5.2 - 2 x gpio LEDS - GPIO user Button + - DC source with a voltage of 9 to 56 V / Passive POE + - DIN Rail Mounting case +Basic version also has: + - TI CC2538 + CC2592 Zigbee Wireless Module with up to 20dBm output + power and Zigbee 3.0 support. - 1 x 1-Wire - 2 x RS-485 - 4 x dry contact digital GPIO inputs - 3 x relay GPIO outputs - - DC source with a voltage of 9 to 56 V / Passive POE - - DIN Rail Mounting case U-Boot compilation -- -- 2.30.2
[PATCH 1/2] doc: boards: amlogic: update documentation for ADC support for AXG
Signed-off-by: Vyacheslav Bocharov --- doc/board/amlogic/index.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/board/amlogic/index.rst b/doc/board/amlogic/index.rst index 9ef1440433..9c7fadf2c0 100644 --- a/doc/board/amlogic/index.rst +++ b/doc/board/amlogic/index.rst @@ -55,7 +55,7 @@ This matrix concerns the actual source code version. +---+---+-+--+-++-+--+ | NAND | No| No | No | No | No | No | No | +---+---+-+--+-++-+--+ -| ADC | **Yes** | **Yes** | **Yes** | No | No | No | No | +| ADC | **Yes** | **Yes** | **Yes** | **Yes** | No | No | No | +---+---+-+--+-++-+--+ | CVBS Output | **Yes** | **Yes** | **Yes** | *N/A* | **Yes**| **Yes** | **Yes** | +---+---+-+--+-++-+--+ -- 2.30.2
Re: [PATCH v5 00/34] Initial implementation of standard boot
> > The bootflow feature provide a built-in way for U-Boot to automatically > > boot an Operating System without custom scripting and other customisation. > > This is called 'standard boot' since it provides a standard way for > > U-Boot to boot a distro, without scripting. > > > > It introduces the following concepts: > > > >- bootdev - a device which can hold a distro > >- bootmeth - a method to scan a bootdev to find bootflows (owned by > > U-Boot) > >- bootflow - a description of how to boot (owned by the distro) > > > > This series provides an implementation of these, enabled to scan for > > bootflows from MMC, USB and Ethernet. It supports the existing distro > > boot as well as the EFI loader flow (bootefi/bootmgr). It works > > similiarly to the existing script-based approach, but is native to > > U-Boot. > > I've put most of this cover letter in the merge commit, and applied this > to u-boot/master. This is an incremental starting point at providing a > alternative way of constructing and controlling the load and execute OS > stage of booting. There is some growth on most platforms for this, but > it is a reasonable alternative and will be iterated on. I'm guessing this would allow us to optionally disable hush and associated pieces for a lot of the boards which may equal it out?
Re: [PATCH v1] drivers: spi: spi-sunxi: Add Kconfig option for sun4i_spi_parse_pins
On 4/25/22 1:21 AM, qianfangui...@163.com wrote: > From: qianfan Zhao > > spi-sunxi driver will init pins based on "pinctrl-0", but the > implementation is very limited. > > Adding an Kconfig option if you really need this feature, or disable it > and config pinmux at board's board_init. This code has already been removed in U-Boot master by: https://lore.kernel.org/u-boot/20220318035420.15058-24-sam...@sholland.org/ Pin setup is now handled by the separate pinctrl driver. Regards, Samuel
Re: [PATCH v3 2/2] imx8mn/8mp: Allow booting via USB
Hi Tim,
On Mon, Apr 25, 2022 at 8:15 PM Tim Harvey wrote:
> Tested-By: Tim Harvey
Thanks.
> agreed it would be a separate issue... just curious if you knew where
> that was coming from. It certainly isn't a common behavior to boot via
> USB then expect 'saveenv' to save to a specific eMMC device.
>
> >
> > I see that you replied to Peng's patch:
> > "imx: dynamic setting mmcdev and mmcroot" and this is likely the cause
> > for your env numbering problem.
>
> That has nothing to do with the mmc device used for U-Boot env. Commit
> f342c9e381c0 ("imx: dynamic setting mmcdev and mmcroot") adds setting
> 'mmcroot=' if mmcautodetect=yes which seems to me like a completely
> inappropriate hack that assumes U-Boot's mmc device numbering matches
Agreed.
> the kernels device numbering (which has changed over time and is not a
> stable ABI). I believe you have been involved in discussions about
> that in the past as well regarding how to best tell the kernel what
> the root device is. Every discussion I have seen (and there have been
> many over the years) end up with the recommendation of using UUID.
Yes, using UUID is good solution for that.
mmc alias also works in kernels > 5.10 too.
[PATCH v1] splash: splash_storage_read_raw: Add mmc support
From: qianfan Zhao
Add splash_mmc_read_raw for loading splash from mmc's raw partition.
Signed-off-by: qianfan Zhao
---
common/splash_source.c | 90 ++
1 file changed, 90 insertions(+)
diff --git a/common/splash_source.c b/common/splash_source.c
index d05670f5ee..28ec405bcf 100644
--- a/common/splash_source.c
+++ b/common/splash_source.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include
DECLARE_GLOBAL_DATA_PTR;
@@ -64,6 +65,93 @@ static int splash_nand_read_raw(u32 bmp_load_addr, int
offset, size_t read_size)
}
#endif
+#ifdef CONFIG_MMC
+static size_t blk_dread_size(struct blk_desc *desc, lbaint_t start,
+u32 load_addr, size_t read_size)
+{
+ ALLOC_CACHE_ALIGN_BUFFER(__u8, tmpbuf, desc->blksz);
+ size_t n, sz_read = 0;
+
+ while (sz_read < read_size) {
+ if (blk_dread(desc, start, 1, tmpbuf) < 0)
+ break;
+
+ n = min(read_size - sz_read, (size_t)desc->blksz);
+ memcpy((void *)load_addr, tmpbuf, n);
+ load_addr += n;
+ sz_read += n;
+ start++;
+ }
+
+ return sz_read;
+}
+
+static struct blk_desc *mmc_blk_get_dev(const char *name)
+{
+ struct blk_desc *dev_desc = NULL;
+
+ if (strncmp(name, "mmc", 3) == 0 && strlen(name) > 3) {
+ int mmc_dev;
+ char *endp;
+
+ mmc_dev = (int)simple_strtol(name + 3, , 10);
+ if (*endp == '\0')
+ dev_desc = blk_get_dev("mmc", mmc_dev);
+ }
+
+ return dev_desc;
+}
+
+static int splash_mmc_read_raw(u32 bmp_load_addr, struct splash_location *loc,
+ size_t read_size)
+{
+ struct blk_desc *dev_desc = mmc_blk_get_dev(loc->name);
+ lbaint_t offset;
+ size_t sz;
+
+ if (!dev_desc) {
+ printf("mmc device %s not found\n", loc->name);
+ return -ENODEV;
+ }
+
+ if (loc->devpart) {
+ struct disk_partition partition;
+ int ret;
+
+ ret = part_get_info_by_name(dev_desc, loc->devpart, );
+ if (ret < 0) {
+ printf("%s: partition %s not found\n",
+ loc->name, loc->devpart);
+ return ret;
+ } else if (partition.size * partition.blksz < read_size) {
+ printf("%s: partition %s size less that requested\n",
+ loc->name, loc->devpart);
+ return -E2BIG;
+ }
+
+ offset = partition.start;
+ } else {
+ offset = loc->offset;
+ }
+
+ sz = blk_dread_size(dev_desc, offset, bmp_load_addr, read_size);
+ if (sz != read_size) {
+ printf("%s: got %zu but expected %zu\n",
+ loc->name, sz, read_size);
+ return -EIO;
+ }
+
+ return 0;
+}
+#else
+static int splash_mmc_read_raw(u32 bmp_load_addr, struct splash_location *loc,
+ size_t read_size)
+{
+ debug("%s: mmc support not available\n", __func__);
+ return -ENOSYS;
+}
+#endif
+
static int splash_storage_read_raw(struct splash_location *location,
u32 bmp_load_addr, size_t read_size)
{
@@ -78,6 +166,8 @@ static int splash_storage_read_raw(struct splash_location
*location,
return splash_nand_read_raw(bmp_load_addr, offset, read_size);
case SPLASH_STORAGE_SF:
return splash_sf_read_raw(bmp_load_addr, offset, read_size);
+ case SPLASH_STORAGE_MMC:
+ return splash_mmc_read_raw(bmp_load_addr, location, read_size);
default:
printf("Unknown splash location\n");
}
--
2.25.1
Re: [PATCH v5 00/12] efi_loader: more tightly integrate UEFI disks to driver model
On Mon, Apr 25, 2022 at 10:43:44PM +0200, Heinrich Schuchardt wrote: > On 4/19/22 03:05, AKASHI Takahiro wrote: > > With this patch set[1] applied, UEFI subsystem maintains a list of its > > disk objects dynamically at runtime based on block device's probing. > > (See "issues" and "prerequisite" below.) > > > > [1] https://github.com/t-akashi/u-boot/tree/efi/dm_disk > > > > For instance, > > => dm tree > > Class Index Probed DriverName > > --- > > root 0 [ + ] root_driver root_driver > > ... > > pci 0 [ + ] pci_generic_ecam |-- pcie@1000 > > ... > > ahci 0 [ ] ahci_pci | |-- ahci_pci > > scsi 0 [ ] ahci_scsi | | `-- ahci_scsi > > usb 0 [ ] xhci_pci | `-- xhci_pci > > ... > > => efi devices > > Missing RNG device for EFI_RNG_PROTOCOL > > No EFI system partition > > Unable to find TPMv2 device > > Device Device Path > > > > 00013eee88d0 /VenHw(..) > > 00013ffeb798 /VenHw(..)/Uart(0,0,D,D) > > 00013eeeb810 /VenHw(..)/MAC(525252525252,1) > > => scsi rescan > > > With the series binding block devices after initializing the UEFI > sub-system works fine. Also unbinding is reflected in the EFI devices. > > But this series breaks UEFI compliance. I don't think so. > All block devices must be probed > before booting. This (not enumerating all the devices) is also true even before my patch. > Without this GRUB will not be able to read the boot > partition with vmlinuz and initrd. I'm not sure what you expect here, but is it enough to define "preboot" variables with any number of enumerating commands, like "scsi rescan", "usb start" and so on? # Again, this method can also be applied even without my patch. -Takahiro Akashi > Will you provide the missing patch? > > Best regards > > Heinrich
[scan-ad...@coverity.com: New Defects reported by Coverity Scan for Das U-Boot]
- Forwarded message from scan-ad...@coverity.com -
Date: Mon, 25 Apr 2022 23:38:10 + (UTC)
From: scan-ad...@coverity.com
To: tom.r...@gmail.com
Subject: New Defects reported by Coverity Scan for Das U-Boot
Hi,
Please find the latest report on new defect(s) introduced to Das U-Boot found
with Coverity Scan.
21 new defect(s) introduced to Das U-Boot found with Coverity Scan.
4 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent
build analyzed by Coverity Scan.
New defect(s) Reported-by: Coverity Scan
Showing 20 of 21 defect(s)
** CID 352464: Memory - illegal accesses (NO_EFFECT)
/scripts/dtc/pylibfdt/libfdt_wrap.c: 4291 in _wrap_fdt_property_data_set()
*** CID 352464: Memory - illegal accesses (NO_EFFECT)
/scripts/dtc/pylibfdt/libfdt_wrap.c: 4291 in _wrap_fdt_property_data_set()
4285 res2 = SWIG_AsCharArray(swig_obj[1], temp2, 0);
4286 if (!SWIG_IsOK(res2)) {
4287 SWIG_exception_fail(SWIG_ArgError(res2), "in method '"
"fdt_property_data_set" "', argument " "2"" of type '" "char [0]""'");
4288 }
4289 arg2 = (char *)(temp2);
4290 if (arg2) memcpy(arg1->data,arg2,0*sizeof(char));
>>> CID 352464: Memory - illegal accesses (NO_EFFECT)
>>> Calling "memset" with size 0: "memset(arg1->data, 0, 0UL)" does nothing.
4291 else memset(arg1->data,0,0*sizeof(char));
4292 resultobj = SWIG_Py_Void();
4293 return resultobj;
4294 fail:
4295 return NULL;
4296 }
** CID 352463: Control flow issues (DEADCODE)
/scripts/dtc/pylibfdt/libfdt_wrap.c: 4030 in _wrap_fdt_node_header_name_set()
*** CID 352463: Control flow issues (DEADCODE)
/scripts/dtc/pylibfdt/libfdt_wrap.c: 4030 in _wrap_fdt_node_header_name_set()
4024 res2 = SWIG_AsCharArray(swig_obj[1], temp2, 0);
4025 if (!SWIG_IsOK(res2)) {
4026 SWIG_exception_fail(SWIG_ArgError(res2), "in method '"
"fdt_node_header_name_set" "', argument " "2"" of type '" "char [0]""'");
4027 }
4028 arg2 = (char *)(temp2);
4029 if (arg2) memcpy(arg1->name,arg2,0*sizeof(char));
>>> CID 352463: Control flow issues (DEADCODE)
>>> Execution cannot reach this statement: "memset(arg1->name, 0, 0UL);".
4030 else memset(arg1->name,0,0*sizeof(char));
4031 resultobj = SWIG_Py_Void();
4032 return resultobj;
4033 fail:
4034 return NULL;
4035 }
** CID 352462: Insecure data handling (TAINTED_SCALAR)
*** CID 352462: Insecure data handling (TAINTED_SCALAR)
/drivers/gpio/gpio-uclass.c: 1203 in gpio_request_by_line_name()
1197return ret;
1198
1199desc->dev = dev;
1200desc->offset = ret;
1201desc->flags = 0;
1202
>>> CID 352462: Insecure data handling (TAINTED_SCALAR)
>>> Passing tainted expression "desc->offset" to "dm_gpio_request", which
>>> uses it as an offset.
1203ret = dm_gpio_request(desc, line_name);
1204if (ret) {
1205debug("%s: dm_gpio_requestf failed\n", __func__);
1206return ret;
1207}
1208
** CID 352461: Control flow issues (UNREACHABLE)
/drivers/block/blk-uclass.c: 568 in blk_find_first()
*** CID 352461: Control flow issues (UNREACHABLE)
/drivers/block/blk-uclass.c: 568 in blk_find_first()
562 int blk_find_first(enum blk_flag_t flags, struct udevice **devp)
563 {
564 int ret;
565
566 for (ret = uclass_find_first_device(UCLASS_BLK, devp);
567 *devp && !blk_flags_check(*devp, flags);
>>> CID 352461: Control flow issues (UNREACHABLE)
>>> Since the loop increment "ret = uclass_find_next_devi..." is
>>> unreachable, the loop body will never execute more than once.
568 ret = uclass_find_next_device(devp))
569 return 0;
570
571 return -ENODEV;
572 }
573
** CID 352460: Memory - illegal accesses (RETURN_LOCAL)
/drivers/clk/clk_scmi.c: 56 in scmi_clk_get_attibute()
*** CID 352460: Memory - illegal accesses (RETURN_LOCAL)
/drivers/clk/clk_scmi.c: 56 in scmi_clk_get_attibute()
50 int ret;
51
52 ret = devm_scmi_process_msg(dev, );
53 if (ret)
54 return ret;
55
>>> CID 352460: Memory - illegal accesses (RETURN_LOCAL)
>>> Returning, through "*name", the address of stack variable "out".
56 *name = out.clock_name;
57
58
[ANN] U-Boot v2022.07-rc1 released
Hey all, It's release day and so here's v2022.07-rc1. There's a lot in here, and there's a few more things yet to come, hopefully this week, in terms of pull requests. In terms of a changelog, git log --merges v2022.04..v2022.07-rc1 contains what I've pulled but as always, better PR messages and tags will provide better results here. So we're now looking at regular releases every other Monday, and with final release on July 4th, 2022. Thanks all! -- Tom signature.asc Description: PGP signature
Re: [PATCH v3 2/2] imx8mn/8mp: Allow booting via USB
On Mon, Apr 25, 2022 at 3:47 PM Fabio Estevam wrote:
>
> Hi Tim,
>
> On 25/04/2022 16:41, Tim Harvey wrote:
>
> > Fabio,
> >
> > Thanks - this at least allows me to boot on imx8mp-venice-gw74xx
> > without needing to enable CONFIG_ENV_IS_NOWHERE.
>
> Care to reply with your Tested-by?
Sure,
Tested-By: Tim Harvey
>
> >
> > I do however notice when I do so env is attempted to load from MMC dev
> > 0 (CONFIG_ENV_IS_IN_MMC=y) - what controls the device number in this
> > case as for this board, the emmc is dev 2.
>
> That's a separate issue.
agreed it would be a separate issue... just curious if you knew where
that was coming from. It certainly isn't a common behavior to boot via
USB then expect 'saveenv' to save to a specific eMMC device.
>
> I see that you replied to Peng's patch:
> "imx: dynamic setting mmcdev and mmcroot" and this is likely the cause
> for your env numbering problem.
That has nothing to do with the mmc device used for U-Boot env. Commit
f342c9e381c0 ("imx: dynamic setting mmcdev and mmcroot") adds setting
'mmcroot=' if mmcautodetect=yes which seems to me like a completely
inappropriate hack that assumes U-Boot's mmc device numbering matches
the kernels device numbering (which has changed over time and is not a
stable ABI). I believe you have been involved in discussions about
that in the past as well regarding how to best tell the kernel what
the root device is. Every discussion I have seen (and there have been
many over the years) end up with the recommendation of using UUID.
Best regards,
Tim
Re: [PATCH v5 00/34] Initial implementation of standard boot
On Sun, Apr 24, 2022 at 11:30:53PM -0600, Simon Glass wrote: > The bootflow feature provide a built-in way for U-Boot to automatically > boot an Operating System without custom scripting and other customisation. > This is called 'standard boot' since it provides a standard way for > U-Boot to boot a distro, without scripting. > > It introduces the following concepts: > >- bootdev - a device which can hold a distro >- bootmeth - a method to scan a bootdev to find bootflows (owned by > U-Boot) >- bootflow - a description of how to boot (owned by the distro) > > This series provides an implementation of these, enabled to scan for > bootflows from MMC, USB and Ethernet. It supports the existing distro > boot as well as the EFI loader flow (bootefi/bootmgr). It works > similiarly to the existing script-based approach, but is native to > U-Boot. I've put most of this cover letter in the merge commit, and applied this to u-boot/master. This is an incremental starting point at providing a alternative way of constructing and controlling the load and execute OS stage of booting. There is some growth on most platforms for this, but it is a reasonable alternative and will be iterated on. -- Tom signature.asc Description: PGP signature
Re: [PATCH] nds32: Remove the architecture
On Wed, Apr 06, 2022 at 09:21:25AM -0400, Tom Rini wrote: > As removal of nds32 has been ack'd for the Linux kernel, remove support > here as well. > > Cc: Rick Chen > Signed-off-by: Tom Rini > Reviewed-by: Rick Chen Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] cmd: part: add explicit dependency on PARTITIONS
On Fri, Apr 22, 2022 at 10:44:30AM +0900, AKASHI Takahiro wrote: > This is a follow-up patch for my "disk: don't compile in partition > support for spl/tpl if not really necessary". > > "part" command is useful only if, at least, one of partition table types > is selected. So it should have a dependency on PARTITIONS which is now > automatically selected if one of partition table types is enabled. > > With this change, *_defconfig which explicitly selects CMD_PART but > has no partition table types enabled should also be fixed. > > Signed-off-by: AKASHI Takahiro > Reviewed-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: Pull request for efi-2022-07-rc1-3
On Sat, Apr 23, 2022 at 11:14:37PM +0200, Heinrich Schuchardt wrote: > Dear Tom, > > The following changes since commit faeb5641131ba0bfafa5ed61dd03b98b1f2a5edb: > > Merge https://gitlab.denx.de/u-boot/custodians/u-boot-pmic (2022-04-22 > 11:06:38 -0400) > > are available in the Git repository at: > > https://source.denx.de/u-boot/custodians/u-boot-efi.git > tags/efi-2022-07-rc1-3 > > for you to fetch changes up to d97e98c887ed8fa4a339350c02f093f03cd1cf4d: > > efi_loader: disk: use udevice instead of blk_desc (2022-04-23 22:05:41 > +0200) > > Gitlab CI showed no problem: > https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/11846 > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v3 2/2] imx8mn/8mp: Allow booting via USB
Hi Tim, On 25/04/2022 16:41, Tim Harvey wrote: Fabio, Thanks - this at least allows me to boot on imx8mp-venice-gw74xx without needing to enable CONFIG_ENV_IS_NOWHERE. Care to reply with your Tested-by? I do however notice when I do so env is attempted to load from MMC dev 0 (CONFIG_ENV_IS_IN_MMC=y) - what controls the device number in this case as for this board, the emmc is dev 2. That's a separate issue. I see that you replied to Peng's patch: "imx: dynamic setting mmcdev and mmcroot" and this is likely the cause for your env numbering problem.
Re: [PATCH] ARM: dts: imx: Use 100 kHz I2C2 on Data Modul i.MX8M Mini eDM SBC
On 25/04/2022 19:16, Marek Vasut wrote: The I2C2 has SMBus device SMSC USB2514Bi connected to it, the device is capable of up to 100 kHz operation. Reduce the bus frequency to 100 kHz to guarantee this I2C device can work correctly. Signed-off-by: Marek Vasut Cc: Fabio Estevam Cc: Peng Fan Cc: Stefano Babic Reviewed-by: Fabio Estevam
[PATCH] ARM: dts: imx: Use 100 kHz I2C2 on Data Modul i.MX8M Mini eDM SBC
The I2C2 has SMBus device SMSC USB2514Bi connected to it, the device is
capable of up to 100 kHz operation. Reduce the bus frequency to 100 kHz
to guarantee this I2C device can work correctly.
Signed-off-by: Marek Vasut
Cc: Fabio Estevam
Cc: Peng Fan
Cc: Stefano Babic
---
arch/arm/dts/imx8mm-data-modul-edm-sbc.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/dts/imx8mm-data-modul-edm-sbc.dts
b/arch/arm/dts/imx8mm-data-modul-edm-sbc.dts
index 154116d01c9..5b022040902 100644
--- a/arch/arm/dts/imx8mm-data-modul-edm-sbc.dts
+++ b/arch/arm/dts/imx8mm-data-modul-edm-sbc.dts
@@ -392,7 +392,7 @@
{
/* IMX8MM ERRATA e7805 -- I2C is limited to 384 kHz due to SoC bug */
- clock-frequency = <32>;
+ clock-frequency = <10>;
pinctrl-names = "default", "gpio";
pinctrl-0 = <_i2c2>;
pinctrl-1 = <_i2c2_gpio>;
--
2.35.1
Re: [PATCH] net: marvell: mvgbe: Set PHY page 0 before phy_connect
Hi Stefan,
On Mon, Apr 25, 2022 at 4:18 AM Stefan Roese wrote:
>
> Hi Tony,
>
> On 4/25/22 11:33, Tony Dinh wrote:
> > Hi Stefan,
> >
> > On Sun, Apr 24, 2022 at 11:00 PM Stefan Roese wrote:
> >>
> >> Hi Tony,
> >>
> >> On 4/23/22 04:15, Tony Dinh wrote:
> >>> Hi Stefan,
> >>>
> >>> Please see my various comments below. And my thoughts at the end.
> >>>
> >>> On Thu, Apr 21, 2022 at 11:15 PM Stefan Roese wrote:
>
> Hi Tony,
>
> On 4/21/22 23:21, Tony Dinh wrote:
>
>
>
> >> What really puzzles me is, why the page address is set to a non-zero
> >> value at all at this early boot stage? Could you perhaps add some
> >> debugging code, to check, if and where the page address gets set?
> >> I find it hard to belief, that this starts with non-zero after
> >> powering up the device / PHY.
> >>
> >> Or did I miss something?
> >
> > Other Kirkwood boards behave correctly (such as the Sheevaplug,
> > Dreamplug, and Dell Kace M300). The Page Select register (22) contains
> > 0 in these boards, and all have PHY id 1410e90. The NSA310s also has
> > PHY id 1410e90.
>
> Yes. I'm pretty sure that the page select register is set to 0 upon
> PHY startup. Even though there might be some strapping possibilities
> to configure some PHY registers, the page select is most likely always
> 0 after power-up. So if nobody writes to this reg, then is should be 0.
> >>>
> >>> Agree. All other Kirkwood boards execute the same code so I think we
> >>> would see if somebody writes to this register.
> >>>
> > But I could not find in the uclass MVGBE where the Page Select
> > register is set before phy_connect is called. So my guess is that
> > memory location just happens to be zero in other boards but not in
> > this NSA310S board. Perhaps the memory location needs to be set to
> > zero, to make sure all registers point to page 0 in the beginning.
>
> Please see above.
>
> > Possibly, it is here that the Page Select register should be zero out
> > after the priv data is copied: dev_get_priv(). mvgbe_of_to_plat() is
> > called very early on (during the uclass MVGBE creation).
> >
> > static int mvgbe_of_to_plat(struct udevice *dev)
> > {
> > struct eth_pdata *pdata = dev_get_plat(dev);
> > struct mvgbe_device *dmvgbe = dev_get_priv(dev);
>
> Possibly. Again my suggestion is to add some debug code to check at
> different boot times, which value is currently set in the page select
> register. By just reading is out and printing it's value. You might need
> to add some "special code" at the early code paths, as the MDIO driver
> is not started there.
>
> Another idea is, if it's possible to issue a HW-reset to the PHY on the
> NSA310 board. Do you know if some GPIO is connected to the PHY's reset
> pin which could be toggled by the SoC?
> >>>
> >>> I don't think there is a GPIO that does. I looked at the GPL source
> >>> code for this board from way back, and created the DTS for this based
> >>> on info in that GPL source. I don't recall that it was available.
> >>>
> Note: We could of course just add the reset to 0 as you have done in the
> MAC driver or some board specific code. But I really would like to
> understand why the page select reg is non-zero in this case.
> >>>
> >>> My conclusion is the register was polluted by something in the board
> >>> hardware. This is the comments (paraphrase) we got from this board
> >>> GPL source:
> >>> /* The ZyXEL NSA310S uses the 88E1310S Alaska (interface
> >>> identical to 88E1318) */
> >>> /* and has an MCU attached to the LED[2] via tristate interrupt
> >>> */
> >>>
> >>> I've rebuilt and rerun the tests for both the Sheevaplug and NSA310S.
> >>> Please see the debug log from mvgbe_probe. This is as early as we can
> >>> see the uclass initializing.
> >>>
> >>> NSA310S boot log
> >>> U-Boot 2022.04-00569-gca51a8dc04-dirty (Apr 22 2022 - 16:49:50 -0700)
> >>> ZyXEL NSA310S/320S 1/2-Bay Power Media Server
> >>>
> >>> SoC: Kirkwood 88F6281_A1
> >>> DRAM: 256 MiB
> >>> Core: 7 devices, 5 uclasses, devicetree: separate
> >>> NAND: 128 MiB
> >>> Loading Environment from NAND... OK
> >>> In:serial
> >>> Out: serial
> >>> Err: serial
> >>>
> >>> Net: mvgbe_of_to_plat called
> >>> mvgbe_of_to_plat phy-mode 7
> >>> mvgbe_of_to_plat phy addr 1
> >>> mvgbe_probe called
> >>> smi_reg_read: phy_addr 1 reg_ofs 22 devad -1
> >>> __mvgbe_mdio_read:(adr 1, off 22) value= 0011
> >>> eth0: ethernet-controller@72000
> >>> Hit any key to stop autoboot: 0
> >>>
> >>> = Sheevaplug boot log
> >>>
> >>> U-Boot 2022.04-00569-gca51a8dc04-dirty (Apr 22 2022 - 18:16:25 -0700)
> >>> Marvell-Sheevaplug
> >>>
> >>> SoC: Kirkwood 88F6281_A1
> >>> DRAM: 512 MiB
> >>> Core: 9 devices, 7 uclasses, devicetree: separate
> >>> NAND: 512
[PATCH 1/1] efi_loader: simplify efi_add_conventional_memory_map()
Remove redundant constraint.
Signed-off-by: Heinrich Schuchardt
---
lib/efi_loader/efi_memory.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/efi_loader/efi_memory.c b/lib/efi_loader/efi_memory.c
index 1c51a3fc45..e048a545e4 100644
--- a/lib/efi_loader/efi_memory.c
+++ b/lib/efi_loader/efi_memory.c
@@ -771,7 +771,7 @@ efi_status_t efi_add_conventional_memory_map(u64 ram_start,
u64 ram_end,
/* ram_top is before this region, reserve all */
efi_add_memory_map_pg(ram_start, pages,
EFI_BOOT_SERVICES_DATA, true);
- } else if ((ram_top >= ram_start) && (ram_top < ram_end)) {
+ } else if (ram_top < ram_end) {
/* ram_top is inside this region, reserve parts */
pages = (ram_end - ram_top) >> EFI_PAGE_SHIFT;
--
2.34.1
[PATCH 1/1] efi_loader: simplify try_load_entry()
Use function efi_create_indexed_name() to create the Boot variable
name.
Signed-off-by: Heinrich Schuchardt
---
lib/efi_loader/efi_bootmgr.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/lib/efi_loader/efi_bootmgr.c b/lib/efi_loader/efi_bootmgr.c
index 8c04ecbdc8..92fc2fcdf0 100644
--- a/lib/efi_loader/efi_bootmgr.c
+++ b/lib/efi_loader/efi_bootmgr.c
@@ -46,16 +46,12 @@ static efi_status_t try_load_entry(u16 n, efi_handle_t
*handle,
void **load_options)
{
struct efi_load_option lo;
- u16 varname[] = u"Boot";
- u16 hexmap[] = u"0123456789ABCDEF";
+ u16 varname[9];
void *load_option;
efi_uintn_t size;
efi_status_t ret;
- varname[4] = hexmap[(n & 0xf000) >> 12];
- varname[5] = hexmap[(n & 0x0f00) >> 8];
- varname[6] = hexmap[(n & 0x00f0) >> 4];
- varname[7] = hexmap[(n & 0x000f) >> 0];
+ efi_create_indexed_name(varname, sizeof(varname), u"Boot", n);
load_option = efi_get_var(varname, _global_variable_guid, );
if (!load_option)
--
2.34.1
[PATCH 1/1] efi: fix devpath_is_partition()
If the path consists only of an end node, it does not refer to a partition.
Avoid returning a random value from the stack in this case.
Signed-off-by: Heinrich Schuchardt
---
lib/efi/efi_app.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/efi/efi_app.c b/lib/efi/efi_app.c
index 1e5606c7b8..2209410f35 100644
--- a/lib/efi/efi_app.c
+++ b/lib/efi/efi_app.c
@@ -190,7 +190,7 @@ static void free_memory(struct efi_priv *priv)
static bool devpath_is_partition(const struct efi_device_path *path)
{
const struct efi_device_path *p;
- bool was_part;
+ bool was_part = false;
for (p = path; p->type != DEVICE_PATH_TYPE_END;
p = (void *)p + p->length) {
--
2.34.1
[PATCH 1/1] cmd: mmc: don't assign unused values
Don't assign a value to variable speedmode which is never used.
Signed-off-by: Heinrich Schuchardt
---
cmd/mmc.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/cmd/mmc.c b/cmd/mmc.c
index 7464f8d00c..63bf69b0bd 100644
--- a/cmd/mmc.c
+++ b/cmd/mmc.c
@@ -501,11 +501,12 @@ static int do_mmc_rescan(struct cmd_tbl *cmdtp, int flag,
int argc, char *const argv[])
{
struct mmc *mmc;
- enum bus_mode speed_mode = MMC_MODES_END;
if (argc == 1) {
mmc = init_mmc_device(curr_device, true);
} else if (argc == 2) {
+ enum bus_mode speed_mode;
+
speed_mode = (int)dectoul(argv[1], NULL);
mmc = __init_mmc_device(curr_device, true, speed_mode);
} else {
@@ -543,7 +544,6 @@ static int do_mmc_dev(struct cmd_tbl *cmdtp, int flag,
{
int dev, part = 0, ret;
struct mmc *mmc;
- enum bus_mode speed_mode = MMC_MODES_END;
if (argc == 1) {
dev = curr_device;
@@ -561,6 +561,8 @@ static int do_mmc_dev(struct cmd_tbl *cmdtp, int flag,
}
mmc = init_mmc_device(dev, true);
} else if (argc == 4) {
+ enum bus_mode speed_mode;
+
dev = (int)dectoul(argv[1], NULL);
part = (int)dectoul(argv[2], NULL);
if (part > PART_ACCESS_MASK) {
--
2.34.1
[PATCH 1/1] cmd: onenand: fix printf codes
For printing size_t use %zu or %zx.
Signed-off-by: Heinrich Schuchardt
---
cmd/onenand.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/cmd/onenand.c b/cmd/onenand.c
index 592985a7ee..d633f19d3b 100644
--- a/cmd/onenand.c
+++ b/cmd/onenand.c
@@ -53,7 +53,7 @@ static int arg_off_size_onenand(int argc, char *const argv[],
ulong *off,
if (*size == mtd->size)
puts("whole chip\n");
else
- printf("offset 0x%lx, size 0x%x\n", *off, *size);
+ printf("offset 0x%lx, size 0x%zx\n", *off, *size);
return 0;
}
@@ -401,7 +401,7 @@ static int do_onenand_read(struct cmd_tbl *cmdtp, int flag,
int argc,
ret = onenand_block_read(ofs, len, , (u8 *)addr, oob);
- printf(" %d bytes read: %s\n", retlen, ret ? "ERROR" : "OK");
+ printf(" %zu bytes read: %s\n", retlen, ret ? "ERROR" : "OK");
return ret == 0 ? 0 : 1;
}
@@ -428,7 +428,7 @@ static int do_onenand_write(struct cmd_tbl *cmdtp, int
flag, int argc,
ret = onenand_block_write(ofs, len, , (u8 *)addr, withoob);
- printf(" %d bytes written: %s\n", retlen, ret ? "ERROR" : "OK");
+ printf(" %zu bytes written: %s\n", retlen, ret ? "ERROR" : "OK");
return ret == 0 ? 0 : 1;
}
--
2.34.1
Re: [PATCH v5 00/12] efi_loader: more tightly integrate UEFI disks to driver model
On 4/19/22 03:05, AKASHI Takahiro wrote: With this patch set[1] applied, UEFI subsystem maintains a list of its disk objects dynamically at runtime based on block device's probing. (See "issues" and "prerequisite" below.) [1] https://github.com/t-akashi/u-boot/tree/efi/dm_disk For instance, => dm tree Class Index Probed DriverName --- root 0 [ + ] root_driver root_driver ... pci 0 [ + ] pci_generic_ecam |-- pcie@1000 ... ahci 0 [ ] ahci_pci | |-- ahci_pci scsi 0 [ ] ahci_scsi | | `-- ahci_scsi usb 0 [ ] xhci_pci | `-- xhci_pci ... => efi devices Missing RNG device for EFI_RNG_PROTOCOL No EFI system partition Unable to find TPMv2 device Device Device Path 00013eee88d0 /VenHw(..) 00013ffeb798 /VenHw(..)/Uart(0,0,D,D) 00013eeeb810 /VenHw(..)/MAC(525252525252,1) => scsi rescan With the series binding block devices after initializing the UEFI sub-system works fine. Also unbinding is reflected in the EFI devices. But this series breaks UEFI compliance. All block devices must be probed before booting. Without this GRUB will not be able to read the boot partition with vmlinuz and initrd. Will you provide the missing patch? Best regards Heinrich
Re: [PATCH 1/1] cmd: simplify do_adc_single()
On 4/25/22 22:26, Heinrich Schuchardt wrote:
If argc is not < 3, it must be >= 3.
If argc >= 3, argv[2] cannot be NULL.
Fixes: 9de612ae4ded ("cmd: adc: Add support for storing ADC result in env
variable")
Signed-off-by: Heinrich Schuchardt
---
cmd/adc.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/cmd/adc.c b/cmd/adc.c
index 8de9121cad..195efa8661 100644
--- a/cmd/adc.c
+++ b/cmd/adc.c
@@ -71,7 +71,6 @@ static int do_adc_info(struct cmd_tbl *cmdtp, int flag, int
argc,
static int do_adc_single(struct cmd_tbl *cmdtp, int flag, int argc,
char *const argv[])
{
- char *varname = NULL;
struct udevice *dev;
unsigned int data;
int ret, uV, val;
@@ -79,9 +78,6 @@ static int do_adc_single(struct cmd_tbl *cmdtp, int flag, int
argc,
if (argc < 3)
return CMD_RET_USAGE;
- if (argc >= 3)
- varname = argv[2];
-
ret = adc_channel_single_shot(argv[1], simple_strtol(argv[2], NULL, 0),
);
if (ret) {
@@ -99,8 +95,7 @@ static int do_adc_single(struct cmd_tbl *cmdtp, int flag, int
argc,
printf("%u\n", data);
}
- if (varname)
- env_set_ulong(varname, val);
+ env_set_ulong(argv[2], val);
We don't want to set the variable unconditionally .
[PATCH 1/1] cmd: simplify do_adc_single()
If argc is not < 3, it must be >= 3.
If argc >= 3, argv[2] cannot be NULL.
Fixes: 9de612ae4ded ("cmd: adc: Add support for storing ADC result in env
variable")
Signed-off-by: Heinrich Schuchardt
---
cmd/adc.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/cmd/adc.c b/cmd/adc.c
index 8de9121cad..195efa8661 100644
--- a/cmd/adc.c
+++ b/cmd/adc.c
@@ -71,7 +71,6 @@ static int do_adc_info(struct cmd_tbl *cmdtp, int flag, int
argc,
static int do_adc_single(struct cmd_tbl *cmdtp, int flag, int argc,
char *const argv[])
{
- char *varname = NULL;
struct udevice *dev;
unsigned int data;
int ret, uV, val;
@@ -79,9 +78,6 @@ static int do_adc_single(struct cmd_tbl *cmdtp, int flag, int
argc,
if (argc < 3)
return CMD_RET_USAGE;
- if (argc >= 3)
- varname = argv[2];
-
ret = adc_channel_single_shot(argv[1], simple_strtol(argv[2], NULL, 0),
);
if (ret) {
@@ -99,8 +95,7 @@ static int do_adc_single(struct cmd_tbl *cmdtp, int flag, int
argc,
printf("%u\n", data);
}
- if (varname)
- env_set_ulong(varname, val);
+ env_set_ulong(argv[2], val);
return CMD_RET_SUCCESS;
}
--
2.34.1
Re: [PATCH V2 20/26] imx: dynamic setting mmcdev and mmcroot
On Tue, Apr 5, 2022 at 10:56 PM Peng Fan (OSS) wrote:
>
> From: Peng Fan
>
> Dynamic setting mmcdev and mmcroot.
> Then when boot linux, we can have correct "root=/dev/mmcblk[x]p2"
>
> Signed-off-by: Peng Fan
> ---
> arch/arm/include/asm/mach-imx/sys_proto.h | 2 +
> board/freescale/common/Makefile | 3 ++
> board/freescale/common/mmc.c | 49 +++
> 3 files changed, 54 insertions(+)
> create mode 100644 board/freescale/common/mmc.c
>
> diff --git a/arch/arm/include/asm/mach-imx/sys_proto.h
> b/arch/arm/include/asm/mach-imx/sys_proto.h
> index 0c0c7814fb2..37fd427cc00 100644
> --- a/arch/arm/include/asm/mach-imx/sys_proto.h
> +++ b/arch/arm/include/asm/mach-imx/sys_proto.h
> @@ -228,6 +228,8 @@ int mxs_reset_block(struct mxs_register_32 *reg);
> int mxs_wait_mask_set(struct mxs_register_32 *reg, u32 mask, u32 timeout);
> int mxs_wait_mask_clr(struct mxs_register_32 *reg, u32 mask, u32 timeout);
>
> +void board_late_mmc_env_init(void);
> +
> unsigned long call_imx_sip(unsigned long id, unsigned long reg0,
>unsigned long reg1, unsigned long reg2,
>unsigned long reg3);
> diff --git a/board/freescale/common/Makefile b/board/freescale/common/Makefile
> index f13965daf2e..4df484935f4 100644
> --- a/board/freescale/common/Makefile
> +++ b/board/freescale/common/Makefile
> @@ -63,6 +63,9 @@ obj-$(CONFIG_ZM7300) += zm7300.o
> obj-$(CONFIG_POWER_PFUZE100) += pfuze.o
> obj-$(CONFIG_DM_PMIC_PFUZE100) += pfuze.o
> obj-$(CONFIG_POWER_MC34VR500) += mc34vr500.o
> +ifneq (,$(filter $(SOC), imx8ulp))
> +obj-y += mmc.o
> +endif
>
> obj-$(CONFIG_LS102XA_STREAM_ID)+= ls102xa_stream_id.o
>
> diff --git a/board/freescale/common/mmc.c b/board/freescale/common/mmc.c
> new file mode 100644
> index 000..8cd5079f962
> --- /dev/null
> +++ b/board/freescale/common/mmc.c
> @@ -0,0 +1,49 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright 2016 Freescale Semiconductor, Inc.
> + * Copyright 2018-2022 NXP
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +static int check_mmc_autodetect(void)
> +{
> + char *autodetect_str = env_get("mmcautodetect");
> +
> + if (autodetect_str && !strcmp(autodetect_str, "yes"))
> + return 1;
> +
> + return 0;
> +}
> +
> +/* This should be defined for each board */
> +__weak int mmc_map_to_kernel_blk(int dev_no)
> +{
> + return dev_no;
> +}
> +
> +void board_late_mmc_env_init(void)
> +{
> + char cmd[32];
> + char mmcblk[32];
> + u32 dev_no = mmc_get_env_dev();
> +
> + if (!check_mmc_autodetect())
> + return;
> +
> + env_set_ulong("mmcdev", dev_no);
> +
> + /* Set mmcblk env */
> + sprintf(mmcblk, "/dev/mmcblk%dp2 rootwait rw",
> mmc_map_to_kernel_blk(dev_no));
> + env_set("mmcroot", mmcblk);
> +
> + sprintf(cmd, "mmc dev %d", dev_no);
> + run_command(cmd, 0);
> +}
> --
> 2.35.1
>
Peng,
I see Stefano already applied this but I'm not sure I agree with it.
Why should you assume that U-Boot and Linux have the same device
mapping? The kernel device mapping is not guaranteed to be consistent.
Every time I have asked about this I've been told the standard was to
use a boot script that used 'part' to determine the UUID of the boot
device from U-Boot's perspective then use root=PARTUUID= to match that
from the kernel's perspective.
For example if using CONFIG_DISTRO_DEFAULTS=y (which I think everyone
should be using) your bootscript would look like this:
part uuid ${devtype} ${devnum}:${distro_bootpart} uuid
setenv bootargs "root=PARTUUID=${uuid} rootwait $bootargs"
Best Regards,
Tim
Re: [PATCH] rockchip: rk3399: Add Nanopi M4V2 board support
Hi Shuying Li & Libunko,
Would you be able to resend this patch to uboot mailing list ?
If you are no longer interested, I can resend it if you would like.
Thank you
Chris
On Sun, 18 Oct 2020 at 13:10, Shuying Li wrote:
>
> From: Libunko
>
> Add initial support for Nanopi M4V2 board.
>
> Specification
> - Rockchip RK3399
> - Dual-Channel 4GB LPDDR4
> - SD card slot
> - eMMC socket
> - RTL8211E 1Gbps
> - AP6356S WiFI/BT
> - HDMI In/Out, MIPI DSI/CSI
> - USB 3.0 x4
> - USB Type C power and data
> - GPIO1, GPIO2 expansion ports
> - DC5V/3A
>
> Signed-off-by: Shuying Li
> ---
> arch/arm/dts/Makefile | 1 +
> arch/arm/dts/rk3399-nanopi-m4v2-u-boot.dtsi | 7 +++
> arch/arm/dts/rk3399-nanopi-m4v2.dts | 67 +
> board/rockchip/evb_rk3399/MAINTAINERS | 6 ++
> configs/nanopi-m4v2-rk3399_defconfig| 61 +++
> doc/board/rockchip/rockchip.rst | 1 +
> 6 files changed, 143 insertions(+)
> create mode 100644 arch/arm/dts/rk3399-nanopi-m4v2-u-boot.dtsi
> create mode 100644 arch/arm/dts/rk3399-nanopi-m4v2.dts
> create mode 100644 configs/nanopi-m4v2-rk3399_defconfig
>
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index f8f529435b..7e8dfcef88 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -130,6 +130,7 @@ dtb-$(CONFIG_ROCKCHIP_RK3399) += \
> rk3399-nanopc-t4.dtb \
> rk3399-nanopi-m4.dtb \
> rk3399-nanopi-m4-2gb.dtb \
> + rk3399-nanopi-m4v2.dtb \
> rk3399-nanopi-neo4.dtb \
> rk3399-orangepi.dtb \
> rk3399-pinebook-pro.dtb \
> diff --git a/arch/arm/dts/rk3399-nanopi-m4v2-u-boot.dtsi
> b/arch/arm/dts/rk3399-nanopi-m4v2-u-boot.dtsi
> new file mode 100644
> index 00..ff8e99cb7f
> --- /dev/null
> +++ b/arch/arm/dts/rk3399-nanopi-m4v2-u-boot.dtsi
> @@ -0,0 +1,7 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2020 Shuying Li
> + */
> +
> +#include "rk3399-nanopi4-u-boot.dtsi"
> +#include "rk3399-sdram-lpddr4-100.dtsi"
> diff --git a/arch/arm/dts/rk3399-nanopi-m4v2.dts
> b/arch/arm/dts/rk3399-nanopi-m4v2.dts
> new file mode 100644
> index 00..03d956d2c4
> --- /dev/null
> +++ b/arch/arm/dts/rk3399-nanopi-m4v2.dts
> @@ -0,0 +1,67 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * FriendlyElec NanoPi M4V2 board device tree source
> + *
> + * Copyright (c) 2018 FriendlyElec Computer Tech. Co., Ltd.
> + * (http://www.friendlyarm.com)
> + *
> + * Copyright (c) 2018 Collabora Ltd.
> + * Copyright (c) 2019 Arm Ltd.
> + * Copyright (C) 2020 Shuying Li
> + */
> +
> +/dts-v1/;
> +#include "rk3399-nanopi4.dtsi"
> +
> +/ {
> + model = "FriendlyElec NanoPi M4V2";
> + compatible = "friendlyarm,nanopi-m4v2", "rockchip,rk3399";
> +
> + vdd_5v: vdd-5v {
> + compatible = "regulator-fixed";
> + regulator-name = "vdd_5v";
> + regulator-always-on;
> + regulator-boot-on;
> + };
> +
> + vcc5v0_core: vcc5v0-core {
> + compatible = "regulator-fixed";
> + regulator-name = "vcc5v0_core";
> + regulator-always-on;
> + regulator-boot-on;
> + vin-supply = <_5v>;
> + };
> +
> + vcc5v0_usb1: vcc5v0-usb1 {
> + compatible = "regulator-fixed";
> + regulator-name = "vcc5v0_usb1";
> + regulator-always-on;
> + regulator-boot-on;
> + vin-supply = <_sys>;
> + };
> +
> + vcc5v0_usb2: vcc5v0-usb2 {
> + compatible = "regulator-fixed";
> + regulator-name = "vcc5v0_usb2";
> + regulator-always-on;
> + regulator-boot-on;
> + vin-supply = <_sys>;
> + };
> +};
> +
> +_sys {
> + vin-supply = <_core>;
> +};
> +
> +_host {
> + phy-supply = <_usb1>;
> +};
> +
> +_host {
> + phy-supply = <_usb2>;
> +};
> +
> +_typec {
> + regulator-always-on;
> + vin-supply = <_5v>;
> +};
> diff --git a/board/rockchip/evb_rk3399/MAINTAINERS
> b/board/rockchip/evb_rk3399/MAINTAINERS
> index 4c889e06a6..9967d68a88 100644
> --- a/board/rockchip/evb_rk3399/MAINTAINERS
> +++ b/board/rockchip/evb_rk3399/MAINTAINERS
> @@ -49,6 +49,12 @@ S: Maintained
> F: configs/nanopi-m4-2gb-rk3399_defconfig
> F: arch/arm/dts/rk3399-nanopi-m4-2gb-u-boot.dtsi
>
> +NANOPC-M4V2
> +M: Shuying Li
> +S: Maintained
> +F: configs/nanopi-m4v2-rk3399_defconfig
> +F: arch/arm/dts/rk3399-nanopi-m4v2-u-boot.dtsi
> +
> NANOPI-NEO4
> M: Jagan Teki
> S: Maintained
> diff --git a/configs/nanopi-m4v2-rk3399_defconfig
> b/configs/nanopi-m4v2-rk3399_defconfig
> new file mode 100644
> index 00..d5c58d549f
> --- /dev/null
> +++ b/configs/nanopi-m4v2-rk3399_defconfig
> @@ -0,0 +1,61 @@
> +CONFIG_ARM=y
> +CONFIG_ARCH_ROCKCHIP=y
> +CONFIG_SYS_TEXT_BASE=0x0020
> +CONFIG_NR_DRAM_BANKS=1
>
Re: [PATCH v3 2/2] imx8mn/8mp: Allow booting via USB
On Thu, Apr 21, 2022 at 11:06 AM Fabio Estevam wrote:
>
> From: Fabio Estevam
>
> When trying to boot via USB on i.MX8MN it is necessary to specify
> the U-Boot environment location, otherwise the boot process simply
> hangs.
>
> Specify the environment location when booting from USB.
>
> Tested on a imx8mn-evk.
>
> Suggested-by: Michael Nazzareno Trimarchi
> Signed-off-by: Fabio Estevam
> ---
> Changes since v2:
> - Handle explicitly the CONFIG_ENV_IS_NOWHERE case and return
> ENVL_UNKNOWN as fallback (Marek).
>
> arch/arm/mach-imx/imx8m/soc.c | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/arch/arm/mach-imx/imx8m/soc.c b/arch/arm/mach-imx/imx8m/soc.c
> index 7059d87e336b..34a07b53e57a 100644
> --- a/arch/arm/mach-imx/imx8m/soc.c
> +++ b/arch/arm/mach-imx/imx8m/soc.c
> @@ -1536,6 +1536,16 @@ enum env_location arch_env_get_location(enum
> env_operation op, int prio)
> return ENVL_UNKNOWN;
>
> switch (dev) {
> + case USB_BOOT:
> + if (IS_ENABLED(CONFIG_ENV_IS_IN_SPI_FLASH))
> + return ENVL_SPI_FLASH;
> + if (IS_ENABLED(CONFIG_ENV_IS_IN_NAND))
> + return ENVL_NAND;
> + if (IS_ENABLED(CONFIG_ENV_IS_IN_MMC))
> + return ENVL_MMC;
> + if (IS_ENABLED(CONFIG_ENV_IS_NOWHERE))
> + return ENVL_NOWHERE;
> + return ENVL_UNKNOWN;
> case QSPI_BOOT:
> case SPI_NOR_BOOT:
> if (IS_ENABLED(CONFIG_ENV_IS_IN_SPI_FLASH))
> --
> 2.25.1
>
Fabio,
Thanks - this at least allows me to boot on imx8mp-venice-gw74xx
without needing to enable CONFIG_ENV_IS_NOWHERE.
I do however notice when I do so env is attempted to load from MMC dev
0 (CONFIG_ENV_IS_IN_MMC=y) - what controls the device number in this
case as for this board, the emmc is dev 2.
U-Boot SPL 2022.04-00073-g9d2b56e8338a (Apr 25 2022 - 12:35:37 -0700)
DRAM: LPDDR4 4 GiB
WDT: Started watchdog@3028 with servicing (60s timeout)
Trying to boot from BOOTROM
Find img info 0x48025c00, size 1396
Need continue download 1024
DTB : imx8mp-venice-gw74xx
Download 873624, Total size 875672
NOTICE: BL31: v2.4(release):f884ad7b0ba2
NOTICE: BL31: Built : 14:00:19, Mar 17 2022
U-Boot 2022.04-00073-g9d2b56e8338a (Apr 25 2022 - 12:35:37 -0700)
CPU: Freescale i.MX8MP[8] rev1.1 1600 MHz (running at 1200 MHz)
CPU: Industrial temperature grade (-40C to 105C) at 46C
Reset cause: POR
Model: Gateworks Venice GW74xx i.MX8MP board
DRAM: 4 GiB
clk_register: failed to get osc_32k device (parent of usb_root_clk)
Core: 211 devices, 24 uclasses, devicetree: separate
WDT: Started watchdog@3028 with servicing (60s timeout)
MMC: FSL_SDHC: 2
Loading Environment from MMC... MMC Device 0 not found
*** Warning - No MMC card found, using default environment
In:serial@3089
Out: serial@3089
Err: serial@3089
Net: KSZ9897S: eth2: lan1, eth3: lan2, eth4: lan3, eth5: lan4, eth6:
lan5, eth1: ethernet@30be, eth0: ethernet@30bf
Best Regards,
Tim
[PATCH] net: dm9000: Correctly handle empty FIFO
Assign packet pointer only in case the MAC reports anything in the FIFO. In case the MAC indicates empty FIFO, return 0 to pass that information to the network stack. Signed-off-by: Marek Vasut Cc: Joe Hershberger Cc: Ramon Fried --- drivers/net/dm9000x.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/dm9000x.c b/drivers/net/dm9000x.c index 78ce536d4a3..07733df533e 100644 --- a/drivers/net/dm9000x.c +++ b/drivers/net/dm9000x.c @@ -666,10 +666,10 @@ static int dm9000_recv(struct udevice *dev, int flags, uchar **packetp) int ret; ret = dm9000_recv_common(db, data); - if (ret) + if (ret > 0) *packetp = (void *)data; - return ret ? ret : -EAGAIN; + return ret >= 0 ? ret : -EAGAIN; } static int dm9000_write_hwaddr(struct udevice *dev) -- 2.35.1
Jumping to U-boot / Image entry point: 0x1780_0000
Hello everyone ! I've started working on porting uboot from a custom version on 2017.03 to 2022.04, for a board based on NXP i.MX6D/Q. My build system is Yocto kirkstone. I've managed to get SPL running, and configured the RAM following the .cfg file that was present before: ... /* DDR IO TYPE */ DATA 4 0x020e0798 0x000C // IOMUXC_SW_PAD_CTL_GRP_DDR_TYPE DATA 4 0x020e0758 0x ... Then, I've got the SPL loading U-boot proper in DRAM at address 0x1780_ (as I've seen done in other i.MX6 boards). Problem is... nothing happens after "Jumping to U-boot" and "image entry point: 0x1780". I've not been able to get any debug from U-boot proper :-/ What I've done so far for the debug: Added a lot of debug messages (had a little trouble with the MMC init). I've hexdump'ed my u-boot.img file, both head and tail, and checked the corresponding registers at addresses 0x177f_ffc0 and 0x1782_65d0. They do correspond. Enabled the DEBUG_UART config. Added a method with puts(...) as the first thing to run in the initialization list of common/board_f.c Tried to reduce my U-boot proper board .c file to a minimum. Added a debug message after the image_entry() call from jump_to_image_no_args(...) => I do not see that message. Has anyone encountered this situation ? It looks to me as if the jump point does not contain an instruction, could this possible ? Attaching the SPL log that I'm able to get. Thanks for any help ! Damien KIRK U-Boot SPL 2022.04+fslc+gf885198273 (Apr 05 2022 - 14:46:25 +) SPL: End of magia-codex-spl board_init (libcommon) >>SPL: board_init_r() using memory lx-lx for malloc() spl_init Trying to boot from MMC1 fsl_esdhc_initialize ... ... hdr read sector 8a, count=1 SPL: payload image: U-Boot 2022.04+fslc+gf885198273 � load addr: 0x177fffc0 size: 157220 i_o_s = 0, spl_i->o = 0, mmc->r_bl_l = 200 i_offset = 0 iss = 134, splis = 26624, mmcrbll = 200 read 134 sectors to 177fffc0 sector 8a, count 134 Jumping to U-Boot... first register content 0x56190527 register content 0x37a54f33 register content 0x41564c62 register content 0xe4650200 register content 0x8017 register content 0x8017 register content 0xfcc1bb90 register content 0x50211 register content 0x6f422d55 --- register content 0x17 register content 0x17820c14 register content 0x17 register content 0x17820c44 register content 0x17 register content 0x0 register content 0x0 register content 0x0 image entry point: 0x1780
[PATCH v4] board: purism: add the Purism Librem5 phone
Initial commit of Librem5 u-boot and SPL
Signed-off-by: Angus Ainslie
Co-developed-by: Sebastian Krzyszkowiak
Signed-off-by: Sebastian Krzyszkowiak
---
All of the pre-requisite patches for this board are now upstream or in review.
Changes since v3:
Dropped unused MMCROOT
Rebased on u-boot-imx
Needs this patch to supress SPL warnings
https://lists.denx.de/pipermail/u-boot/2022-April/482369.html
Changes since v2:
Cleanup Kconfig symbols used in librem5.h
Cleanup various checkpatch issues
Drop some un-used functions
Changes since v1:
Merged patches into a monolithic board patch
Using DM drivers for devices in u-boot
Added USB storage support for uSD rootfs
Dropped many SPL_BUILD guarded define's
Fixed documentation index
arch/arm/dts/Makefile|3 +-
arch/arm/dts/imx8mq-librem5-r4-u-boot.dtsi | 134 ++
arch/arm/dts/imx8mq-librem5-r4.dts | 35 +
arch/arm/dts/imx8mq-librem5.dtsi | 1255 +
arch/arm/mach-imx/imx8m/Kconfig |9 +
board/purism/librem5/Kconfig | 15 +
board/purism/librem5/MAINTAINERS |8 +
board/purism/librem5/Makefile| 13 +
board/purism/librem5/imximage-8mq-lpddr4.cfg |8 +
board/purism/librem5/librem5.c | 425 ++
board/purism/librem5/librem5.h | 181 +++
board/purism/librem5/lpddr4_timing.c | 1324 ++
board/purism/librem5/lpddr4_timing_b0.c | 1191
board/purism/librem5/spl.c | 593
configs/librem5_defconfig| 142 ++
doc/board/index.rst |1 +
doc/board/purism/index.rst |9 +
doc/board/purism/librem5.rst | 60 +
include/configs/librem5.h| 113 ++
19 files changed, 5518 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/dts/imx8mq-librem5-r4-u-boot.dtsi
create mode 100644 arch/arm/dts/imx8mq-librem5-r4.dts
create mode 100644 arch/arm/dts/imx8mq-librem5.dtsi
create mode 100644 board/purism/librem5/Kconfig
create mode 100644 board/purism/librem5/MAINTAINERS
create mode 100644 board/purism/librem5/Makefile
create mode 100644 board/purism/librem5/imximage-8mq-lpddr4.cfg
create mode 100644 board/purism/librem5/librem5.c
create mode 100644 board/purism/librem5/librem5.h
create mode 100644 board/purism/librem5/lpddr4_timing.c
create mode 100644 board/purism/librem5/lpddr4_timing_b0.c
create mode 100644 board/purism/librem5/spl.c
create mode 100644 configs/librem5_defconfig
create mode 100644 doc/board/purism/index.rst
create mode 100644 doc/board/purism/librem5.rst
create mode 100644 include/configs/librem5.h
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 90f86e3fca..719fd7db8d 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -937,7 +937,8 @@ dtb-$(CONFIG_ARCH_IMX8M) += \
imx8mp-venice-gw74xx.dtb \
imx8mp-verdin.dtb \
imx8mq-pico-pi.dtb \
- imx8mq-kontron-pitx-imx8m.dtb
+ imx8mq-kontron-pitx-imx8m.dtb \
+ imx8mq-librem5-r4.dtb
dtb-$(CONFIG_ARCH_IMXRT) += imxrt1050-evk.dtb \
imxrt1020-evk.dtb
diff --git a/arch/arm/dts/imx8mq-librem5-r4-u-boot.dtsi
b/arch/arm/dts/imx8mq-librem5-r4-u-boot.dtsi
new file mode 100644
index 00..e3f780ca75
--- /dev/null
+++ b/arch/arm/dts/imx8mq-librem5-r4-u-boot.dtsi
@@ -0,0 +1,134 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+
+/ {
+ binman: binman {
+ multiple-images;
+ };
+};
+
+ {
+ u-boot-spl-ddr {
+ filename = "u-boot-spl-ddr.bin";
+ pad-byte = <0xff>;
+ align-size = <4>;
+ align = <4>;
+
+ u-boot-spl {
+ align-end = <4>;
+ };
+
+ blob_1: blob-ext@1 {
+ filename = "lpddr4_pmu_train_1d_imem.bin";
+ size = <0x8000>;
+ };
+
+ blob_2: blob-ext@2 {
+ filename = "lpddr4_pmu_train_1d_dmem.bin";
+ size = <0x4000>;
+ };
+
+ blob_3: blob-ext@3 {
+ filename = "lpddr4_pmu_train_2d_imem.bin";
+ size = <0x8000>;
+ };
+
+ blob_4: blob-ext@4 {
+ filename = "lpddr4_pmu_train_2d_dmem.bin";
+ size = <0x4000>;
+ };
+ };
+
+ spl {
+ filename = "spl.bin";
+
+ mkimage {
+ args = "-n spl/u-boot-spl.cfgout -T imx8mimage -e
0x7e1000";
+
+ blob {
+ filename = "u-boot-spl-ddr.bin";
+ };
+ };
+ };
+
+ itb {
+ filename = "u-boot.itb";
+
+ fit {
+ description = "Configuration to load ATF
Re: [PATCH v3] mips: dts: add initial support for ls1c300 SoC
sorry for the late response but I was on vacation ;) Am Donnerstag, dem 21.04.2022 um 20:31 -0400 schrieb Sean Anderson: > On 4/18/22 4:45 PM, Du Huanpeng wrote: > > Loongson 1C is a cost-effective SOC chip for industrial control and > > the Internet of Things. The Loongson 1C includes a floating-point > > processing unit, supports multiple types of memory, and supports > > high-capacity MLC NAND Flash. Loongson 1C provides developers with > > a > > wealth of peripheral interfaces and on-chip modules, including > > Camera > > controller, USB OTG and USB HOST interfaces, AC97/I2S controller, > > LCD > > controller, SPI interface, UART interface, etc., providing > > sufficient > > computing power and multi-application connectivity. > > > > Some highlights of this SoC are: > > - Single core LS232, MIPS32 instruction set compatible, main > > frequency > > 300MHZ > > - 16KB data cache and 16KB instruction cache > > - 64 bit float unit, hardware division > > - 8/16 bit SDRAM controller, 45 ~ 133MHz > > - 8/16 bit SRAM, NAND > > - I2S/AC97, LCD, MAC, USB, OTG, SPI, I2C, PWM, CAN, SDIO, ADC > > - 12 UARTs > > > > See Technical Reference Manual for details: > > https://www.loongson.cn/ > > > > introduce base support for the ls1c300 SoC. > > - debug UART2 > > - serial console > > - clock > > - watchdog > > - sysreset > > - many uarts > > > > Signed-off-by: Du Huanpeng > > --- > > Changelog for v3: > > - change cpu clock id from CLK_CPU to CLK_CPU_THROT > > - migrate all APB dev's clock id to CLK_APB > > - remove uarts' property to use default value <0> > > - move /clocks/acc node to /soc/acc > > - call clk_request() before use a clk > > - make get_tbclk() return 1/2 clock of cpu > > - disable debug_uart by default > > - add ops for cpu_throt_factor clk > > - declare MSEC_PER_SEC for converting between sec and msec > > - return a error code when the wdt clock is out of range > > - minor format and codingstyle fixes > > - rebase to [9859465bfe838bc8264d45e1a1bed847bba74bad] > > > > Changelog for v2: > > 1. dtsi: > > add status disabled for uart0 ~ uart11 > > remove bootargs from chosen > > make serial0 alias for uart2 > > oscillator remove @0 unit-address > > change uart2 address to kuseg > > > > 2. cleanup Kconfig and update defconfig > > - make these options configurable, disabled by default: > > CMD_DM > > DM_ETH > > DM_GPIO > > DM_SPI > > DM_SPI_FLASH > > DM_RESET > > PINCONF > > PINCTRL > > PINMUX > > RESET_LSMIPS > > - make these options configurable, enabled by default: > > CLK > > DISPLAY_CPUINFO > > SYSRESET > > ROM_EXCEPTION_VECTORS > > - disabled: > > CONFIG_ENV_IS_IN_SPI_FLASH > > > > 3. fix codingstyle drivers/watchdog/lsmips-wdt.c > > - priv->base + offset > > - add comment for default clock value > > > > 4. remove address base definition header > > - remove arch/mips/mach-lsmips/ls1c300/ls1c300.h > > - clean up files uses this header > > > > 5. spl and debug uart > > - add comment for spl & debug uart pinmuxing > > - cleanup unused registers base header > > > > 6. dtsi > > - add "loongson,ls1c300-uart" to all uart node > > > > 7. board dts > > - add memory node to board dts, start at 0x8000, size 64MB > > > > 8. Kconfig > > - make ROM_EXCEPTION_VECTORS user configureable > > - enable ROM_EXCEPTION_VECTORS in defconfig > > > > 9. > > - seperate sdram_init to sdram_init.S > > - add macro helpers to do sdram, pll lowlevel init > > > > 10. dtsi > > - move clock nodes to /clocks/xxx > > > > 11. > > - define CONFIG_SKIP_LOWLEVEL_INIT to 1 > > > > 12. > > - remove option PINCTRL_LS1C300 from Kconfig > > > > 13. > > - dram_init, use get_ram_size() to detect ram size. > > > > 14. clk driver > > - create custom clock ops for PLL > > - remove debug code > > > > 15. > > - rebase to 59bffec43a657598b194b9eb30dc01eec06078c7 > > - remove CONFIG_SYS_MONITOR_BASE from include/configs/ > > > > > commit e4d741f8abc4a92426d3a826f99390c3abe02d61 > > > Author: Tom Rini > > > Date: Thu Mar 24 17:18:05 2022 -0400 > > > > > > Convert CONFIG_SYS_MONITOR_BASE to Kconfig > > > > MAINTAINERS | 13 ++ > > arch/mips/Kconfig | 11 ++ > > arch/mips/Makefile| 1 + > > arch/mips/dts/Makefile| 1 + > > arch/mips/dts/loongson32-ls1c300b.dtsi| 141 > > ++ > > arch/mips/dts/ls1c300-eval.dts| 31 +++ > > arch/mips/mach-lsmips/Kconfig | 76 > > arch/mips/mach-lsmips/Makefile| 6 + > > arch/mips/mach-lsmips/cpu.c | 19 ++ > > arch/mips/mach-lsmips/include/mach/serial.h | 16 ++ > > arch/mips/mach-lsmips/ls1c300/Makefile| 7 + > > arch/mips/mach-lsmips/ls1c300/gpio.c | 66 +++ > > arch/mips/mach-lsmips/ls1c300/init.c
Re: [PATCH 2/3] led: Mark device instance with DM_FLAG_PROBE_AFTER_BIND
On 4/25/22 16:31, Tom Rini wrote:
On Fri, Apr 22, 2022 at 03:15:54PM +0200, Marek Vasut wrote:
Calling device_probe() from uclass .post_bind() callback has all kinds
of odd side-effects, e.g. device instances not being available just yet.
Make use of the DM_FLAG_PROBE_AFTER_BIND instead, mark device instances
which need to be probe()d in order to configure the LED default state
with this flag and let the DM core do the device_probe() at the right
time instead.
Fixes: 72675b063b6 ("led: Configure LED default-state on boot")
Signed-off-by: Marek Vasut
Cc: Patrice Chotard
Cc: Patrick Delaunay
Cc: Sean Anderson
Cc: Simon Glass
Cc: Steven Lawrance
Reviewed-by: Patrice Chotard
Tested-by: Patrice Chotard
---
drivers/led/led-uclass.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
This breaks all of the sandbox tests, which perhaps need another update
for what you've changed here? I already had to tweak them once in
72675b063b6e ("led: Configure LED default-state on boot"). But my
perhaps incorrect read then was that the dts / test weren't quite right
to start with. Perhaps that's still the case however?
Pick these two test fixes:
[PATCH 1/2] test: dm: led: Fix LED enumeration
[PATCH 2/2] test: dm: pinmux: Get LED2 udevice in the pinmux test
[PATCH 1/1] cmd: fix long text for fdt command
We don't have an option -cq but two distinct options -c and -q.
Fixes: e9496ec37440 ("fdt: Add -q option to fdt addr for distro_bootcmd")
Signed-off-by: Heinrich Schuchardt
---
cmd/fdt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/cmd/fdt.c b/cmd/fdt.c
index c07342cf25..842e6cb634 100644
--- a/cmd/fdt.c
+++ b/cmd/fdt.c
@@ -1071,7 +1071,7 @@ static int fdt_print(const char *pathp, char *prop, int
depth)
//
#ifdef CONFIG_SYS_LONGHELP
static char fdt_help_text[] =
- "addr [-cq] [] - Set the [control] fdt location to
\n"
+ "addr [-c] [-q] [] - Set the [control] fdt location to
\n"
#ifdef CONFIG_OF_LIBFDT_OVERLAY
"fdt apply - Apply overlay to the DT\n"
#endif
--
2.34.1
[PATCH 2/2] test: dm: pinmux: Get LED2 udevice in the pinmux test
The UT reinitializes the pin controller state, get LED2 udevice
to trigger its probe and configure the pin controller pin state
as it is expected by the test.
Signed-off-by: Marek Vasut
Cc: Patrice Chotard
Cc: Patrick Delaunay
Cc: Sean Anderson
Cc: Simon Glass
Cc: Steven Lawrance
---
test/cmd/pinmux.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/test/cmd/pinmux.c b/test/cmd/pinmux.c
index de3bb0d2f97..df40bb77435 100644
--- a/test/cmd/pinmux.c
+++ b/test/cmd/pinmux.c
@@ -7,12 +7,17 @@
#include
#include
+#include
#include
#include
#include
static int dm_test_cmd_pinmux_status_pinname(struct unit_test_state *uts)
{
+ struct udevice *dev;
+
+ ut_assertok(uclass_get_device(UCLASS_LED, 2, ));
+
/* Test that 'pinmux status ' displays the selected pin. */
console_record_reset();
run_command("pinmux status a5", 0);
--
2.35.1
[PATCH 1/2] test: dm: led: Fix LED enumeration
The GPIO LED driver no longer considers the top level node an LED,
because it is not an LED. With this bug fixed, the LED enumeration
has changed. Update the test accordingly.
Signed-off-by: Marek Vasut
Cc: Patrice Chotard
Cc: Patrick Delaunay
Cc: Sean Anderson
Cc: Simon Glass
Cc: Steven Lawrance
---
test/dm/led.c | 17 -
1 file changed, 8 insertions(+), 9 deletions(-)
diff --git a/test/dm/led.c b/test/dm/led.c
index 5bbe04648a1..eed3f4654c5 100644
--- a/test/dm/led.c
+++ b/test/dm/led.c
@@ -21,8 +21,7 @@ static int dm_test_led_base(struct unit_test_state *uts)
ut_assertok(uclass_get_device(UCLASS_LED, 1, ));
ut_assertok(uclass_get_device(UCLASS_LED, 2, ));
ut_assertok(uclass_get_device(UCLASS_LED, 3, ));
- ut_assertok(uclass_get_device(UCLASS_LED, 4, ));
- ut_asserteq(-ENODEV, uclass_get_device(UCLASS_LED, 5, ));
+ ut_asserteq(-ENODEV, uclass_get_device(UCLASS_LED, 4, ));
return 0;
}
@@ -52,10 +51,10 @@ static int dm_test_led_gpio(struct unit_test_state *uts)
struct udevice *dev, *gpio;
/*
-* Check that we can manipulate an LED. LED 1 is connected to GPIO
+* Check that we can manipulate an LED. LED 0 is connected to GPIO
* bank gpio_a, offset 1.
*/
- ut_assertok(uclass_get_device(UCLASS_LED, 1, ));
+ ut_assertok(uclass_get_device(UCLASS_LED, 0, ));
ut_assertok(uclass_get_device(UCLASS_GPIO, 1, ));
ut_asserteq(0, sandbox_gpio_get_value(gpio, offset));
ut_assertok(led_set_state(dev, LEDST_ON));
@@ -77,10 +76,10 @@ static int dm_test_led_toggle(struct unit_test_state *uts)
struct udevice *dev, *gpio;
/*
-* Check that we can manipulate an LED. LED 1 is connected to GPIO
+* Check that we can manipulate an LED. LED 0 is connected to GPIO
* bank gpio_a, offset 1.
*/
- ut_assertok(uclass_get_device(UCLASS_LED, 1, ));
+ ut_assertok(uclass_get_device(UCLASS_LED, 0, ));
ut_assertok(uclass_get_device(UCLASS_GPIO, 1, ));
ut_asserteq(0, sandbox_gpio_get_value(gpio, offset));
ut_assertok(led_set_state(dev, LEDST_TOGGLE));
@@ -102,12 +101,12 @@ static int dm_test_led_label(struct unit_test_state *uts)
ut_assertok(led_get_by_label("sandbox:red", ));
ut_asserteq(1, device_active(dev));
- ut_assertok(uclass_get_device(UCLASS_LED, 1, ));
+ ut_assertok(uclass_get_device(UCLASS_LED, 0, ));
ut_asserteq_ptr(dev, cmp);
ut_assertok(led_get_by_label("sandbox:green", ));
ut_asserteq(1, device_active(dev));
- ut_assertok(uclass_get_device(UCLASS_LED, 2, ));
+ ut_assertok(uclass_get_device(UCLASS_LED, 1, ));
ut_asserteq_ptr(dev, cmp);
ut_asserteq(-ENODEV, led_get_by_label("sandbox:blue", ));
@@ -127,7 +126,7 @@ static int dm_test_led_blink(struct unit_test_state *uts)
* Check that we get an error when trying to blink an LED, since it is
* not supported by the GPIO LED driver.
*/
- ut_assertok(uclass_get_device(UCLASS_LED, 1, ));
+ ut_assertok(uclass_get_device(UCLASS_LED, 0, ));
ut_assertok(uclass_get_device(UCLASS_GPIO, 1, ));
ut_asserteq(0, sandbox_gpio_get_value(gpio, offset));
ut_asserteq(-ENOSYS, led_set_state(dev, LEDST_BLINK));
--
2.35.1
Re: [PATCH v3 08/13] misc: Add support for nvmem cells
On 4/25/22 1:48 AM, Simon Glass wrote:
> Hi Sean,
>
> On Mon, 18 Apr 2022 at 13:37, Sean Anderson wrote:
>>
>> This adds support for "nvmem cells" as seen in Linux. The nvmem device
>> class in Linux is used for various assorted ROMs and EEPROMs. In this
>> sense, it is similar to UCLASS_MISC, but also includes
>> UCLASS_I2C_EEPROM, UCLASS_RTC, and UCLASS_MTD. New drivers corresponding
>> to a Linux-style nvmem device should be implemented as one of the
>> previously-mentioned uclasses. The nvmem API acts as a compatibility
>> layer to adapt the (slightly different) APIs of these uclasses. It also
>> handles the lookup of nvmem cells.
>>
>> While nvmem devices can be accessed directly, they are most often used
>> by reading/writing contiguous values called "cells". Cells typically
>> hold information like calibration, versions, or configuration (such as
>> mac addresses).
>>
>> nvmem devices can specify "cells" in their device tree:
>>
>> qfprom: eeprom@70 {
>> #address-cells = <1>;
>> #size-cells = <1>;
>> reg = <0x0070 0x10>;
>>
>> /* ... */
>>
>> tsens_calibration: calib@404 {
>> reg = <0x404 0x10>;
>> };
>> };
>>
>> which can then be referenced like:
>>
>> tsens {
>> /* ... */
>> nvmem-cells = <_calibration>;
>> nvmem-cell-names = "calibration";
>> };
>>
>> The tsens driver could then read the calibration value like:
>>
>> struct nvmem_cell cal_cell;
>> u8 cal[16];
>> nvmem_cell_get_by_name(dev, "calibration", _cell);
>> nvmem_cell_read(_cell, cal, sizeof(cal));
>>
>> Because nvmem devices are not all of the same uclass, supported uclasses
>> must register a nvmem_interface struct. This allows CONFIG_NVMEM to be
>> enabled without depending on specific uclasses. At the moment,
>> nvmem_interface is very bare-bones, and assumes that no initialization
>> is necessary. However, this could be amended in the future.
>>
>> Although I2C_EEPROM and MISC are quite similar (and could likely be
>> unified), they present different read/write function signatures. To
>> abstract over this, NVMEM uses the same read/write signature as Linux.
>> In particular, short read/writes are not allowed, which is allowed by
>> MISC.
>>
>> The functionality implemented by nvmem cells is very similar to that
>> provided by i2c_eeprom_partition. "fixed-partition"s for eeproms does
>> not seem to have made its way into Linux or into any device tree other
>> than sandbox. It is possible that with the introduction of this API it
>> would be possible to remove it.
>
> I still think this would be better as a separate uclass, with child
> devices created at bind time in each of the respective uclasses, like
> mmc_bind() does. Then you will see the nvmem devices in the DM tree.
> Wouldn't we want to add a command to access the nvmem devices?
We already do. E.g. the misc/rtc/eeprom commands. The problem is that
for software to access them, they would have to use misc_read/dm_rtc_read/
i2c_eeprom_read.
> This patch feels like a shortcut to me and I'm not sure of the
> benefit of that shortcut.
Well, I suppose it's because "nvmem" devices are strict subsets of
existing devices. There is no new functionality here (except adapting
between semantics like for misc). We should always be able to use the
existing API to implement support for a new underlying uclass. There
should never be device-specific read/write methods, because we can
use the existing read/write uclass methods.
What I'm trying to get at is that we sort of already have an nvmem
uclass with nvmem devices, they're just not accessible in a uniform
way. This series is trying to address the uniformity aspect. But I
don't think we need new devices for each nvmem interface, because
all they would do would take up ram/rom.
--Sean
PS. In an ideal world we'd have something like
struct nvmem_ops {
read();
write();
};
struct dm_rtc_ops {
nvmem_ops nvmem;
/* the other ops minus read/write */
};
int nvmem_read (...) {
struct nvmem_ops *ops = cell->nvmem->ops;
/* ... */
return ops->read(...);
}
but unfortunately, we already have fragmented implementations.
[PATCH v2] board: freescale: p1_p2_rdb_pc: Add env commands norlowerboot, norupperboot, sd2boot and defboot
All *boot env commands overrides default boot source location via i2c. After board reset without power off, BootROM then starts booting U-Boot from this specified location instead of the default one. Add new env command defboot which reverts boot location to the default value, which in most cases is configurable by HW DIP switches. And add new env commands norlowerboot, norupperboot, sd2boot to boot from other locations. norlowerboot would instruct BootROM to boot from lower NOR bank, norupperboot from upper NOR bank and sd2boot from SD card with alternative configuration. Signed-off-by: Pali Rohár --- Changes in v2: * Fix commit message * Adapt code to use p1_p2_bootsrc.h --- include/configs/p1_p2_bootsrc.h | 20 include/configs/p1_p2_rdb_pc.h | 13 + 2 files changed, 33 insertions(+) diff --git a/include/configs/p1_p2_bootsrc.h b/include/configs/p1_p2_bootsrc.h index a274c57786f5..60741ef544c0 100644 --- a/include/configs/p1_p2_bootsrc.h +++ b/include/configs/p1_p2_bootsrc.h @@ -30,6 +30,18 @@ #define RST_NOR_CMD(var, ...) "" #endif +#ifdef __SW_BOOT_NOR_BANK_LO +#define RST_NOR_LO_CMD(var, ...) __VAR_CMD_RST(var, __VA_ARGS__ __BOOTSRC_CMD(__SW_BOOT_NOR_BANK_LO, __SW_BOOT_MASK)) +#else +#define RST_NOR_LO_CMD(var, ...) "" +#endif + +#ifdef __SW_BOOT_NOR_BANK_UP +#define RST_NOR_UP_CMD(var, ...) __VAR_CMD_RST(var, __VA_ARGS__ __BOOTSRC_CMD(__SW_BOOT_NOR_BANK_UP, __SW_BOOT_MASK)) +#else +#define RST_NOR_UP_CMD(var, ...) "" +#endif + #ifdef __SW_BOOT_SPI #define RST_SPI_CMD(var, ...) __VAR_CMD_RST(var, __VA_ARGS__ __BOOTSRC_CMD(__SW_BOOT_SPI, __SW_BOOT_MASK)) #else @@ -42,6 +54,12 @@ #define RST_SD_CMD(var, ...) "" #endif +#ifdef __SW_BOOT_SD2 +#define RST_SD2_CMD(var, ...) __VAR_CMD_RST(var, __VA_ARGS__ __BOOTSRC_CMD(__SW_BOOT_SD2, __SW_BOOT_MASK)) +#else +#define RST_SD2_CMD(var, ...) "" +#endif + #ifdef __SW_BOOT_NAND #define RST_NAND_CMD(var, ...) __VAR_CMD_RST(var, __VA_ARGS__ __BOOTSRC_CMD(__SW_BOOT_NAND, __SW_BOOT_MASK)) #else @@ -53,3 +71,5 @@ #else #define RST_PCIE_CMD(var, ...) "" #endif + +#define RST_DEF_CMD(var, ...) __VAR_CMD_RST(var, __VA_ARGS__ __BOOTSRC_CMD(0x00, 0xff)) diff --git a/include/configs/p1_p2_rdb_pc.h b/include/configs/p1_p2_rdb_pc.h index 47bd20eeeafb..50ce2d9aaed4 100644 --- a/include/configs/p1_p2_rdb_pc.h +++ b/include/configs/p1_p2_rdb_pc.h @@ -25,6 +25,9 @@ #define __SW_NOR_BANK_MASK 0xfd #define __SW_NOR_BANK_UP 0x00 #define __SW_NOR_BANK_LO 0x02 +#define __SW_BOOT_NOR_BANK_UP 0x5c /* (__SW_BOOT_NOR | __SW_NOR_BANK_UP) */ +#define __SW_BOOT_NOR_BANK_LO 0x5e /* (__SW_BOOT_NOR | __SW_NOR_BANK_LO) */ +#define __SW_BOOT_NOR_BANK_MASK0x01 /* (__SW_BOOT_MASK & __SW_NOR_BANK_MASK) */ #define CONFIG_SYS_L2_SIZE (256 << 10) #endif @@ -54,6 +57,9 @@ #define __SW_NOR_BANK_MASK 0xfd #define __SW_NOR_BANK_UP 0x00 #define __SW_NOR_BANK_LO 0x02 +#define __SW_BOOT_NOR_BANK_UP 0x64 /* (__SW_BOOT_NOR | __SW_NOR_BANK_UP) */ +#define __SW_BOOT_NOR_BANK_LO 0x66 /* (__SW_BOOT_NOR | __SW_NOR_BANK_LO) */ +#define __SW_BOOT_NOR_BANK_MASK0x01 /* (__SW_BOOT_MASK & __SW_NOR_BANK_MASK) */ #define CONFIG_SYS_L2_SIZE (256 << 10) /* * Dynamic MTD Partition support with mtdparts @@ -73,6 +79,9 @@ #define __SW_NOR_BANK_MASK 0xfd #define __SW_NOR_BANK_UP 0x00 #define __SW_NOR_BANK_LO 0x02 +#define __SW_BOOT_NOR_BANK_UP 0xc8 /* (__SW_BOOT_NOR | __SW_NOR_BANK_UP) */ +#define __SW_BOOT_NOR_BANK_LO 0xca /* (__SW_BOOT_NOR | __SW_NOR_BANK_LO) */ +#define __SW_BOOT_NOR_BANK_MASK0x01 /* (__SW_BOOT_MASK & __SW_NOR_BANK_MASK) */ #define CONFIG_SYS_L2_SIZE (512 << 10) /* * Dynamic MTD Partition support with mtdparts @@ -605,10 +614,14 @@ __VSCFW_ADDR \ MAP_NOR_LO_CMD(map_lowernorbank) \ MAP_NOR_UP_CMD(map_uppernorbank) \ RST_NOR_CMD(norboot) \ +RST_NOR_LO_CMD(norlowerboot) \ +RST_NOR_UP_CMD(norupperboot) \ RST_SPI_CMD(spiboot) \ RST_SD_CMD(sdboot) \ +RST_SD2_CMD(sd2boot) \ RST_NAND_CMD(nandboot) \ RST_PCIE_CMD(pciboot) \ +RST_DEF_CMD(defboot) \ "" #define CONFIG_USB_FAT_BOOT\ -- 2.20.1
[PATCH v2] board: freescale: p1_p2_rdb_pc: Move boot reset macros to p1_p2_bootsrc.h
Code for changing boot source is platform generic and can be used by any P1* and P2* compatible RDB board. Not only by boards which use config header file p1_p2_rdb_pc.h. So move this code from p1_p2_rdb_pc.h to p1_p2_bootsrc.h and cleanup macros for generating boot source env variables in CONFIG_EXTRA_ENV_SETTINGS. This allows to use code for resetting board and rebooting to other boot source also by other boards in future. Signed-off-by: Pali Rohár --- Changes in v2: * Fix commit message * Move macros to file p1_p2_bootsrc.h * Rewrite macros even more to be more generic and use them without custom macros in p1_p2_rdb_pc.h --- include/configs/p1_p2_bootsrc.h | 55 + include/configs/p1_p2_rdb_pc.h | 41 ++-- 2 files changed, 64 insertions(+), 32 deletions(-) create mode 100644 include/configs/p1_p2_bootsrc.h diff --git a/include/configs/p1_p2_bootsrc.h b/include/configs/p1_p2_bootsrc.h new file mode 100644 index ..a274c57786f5 --- /dev/null +++ b/include/configs/p1_p2_bootsrc.h @@ -0,0 +1,55 @@ +// SPDX-License-Identifier: GPL-2.0+ +// (C) 2022 Pali Rohár + +#include + +#if !defined(CONFIG_SYS_SPD_BUS_NUM) || !defined(CONFIG_SYS_I2C_PCA9557_ADDR) +#error "CONFIG_SYS_SPD_BUS_NUM and CONFIG_SYS_I2C_PCA9557_ADDR are required" +#endif + +#define __BOOTSRC_CMD(src, msk) i2c dev CONFIG_SYS_SPD_BUS_NUM; i2c mw CONFIG_SYS_I2C_PCA9557_ADDR 1 src 1; i2c mw CONFIG_SYS_I2C_PCA9557_ADDR 3 msk 1 + +#define __VAR_CMD(var, cmd) __stringify(var=cmd\0) +#define __VAR_CMD_RST(var, cmd) __VAR_CMD(var, cmd; reset) + +#ifdef __SW_NOR_BANK_LO +#define MAP_NOR_LO_CMD(var, ...) __VAR_CMD(var, __VA_ARGS__ __BOOTSRC_CMD(__SW_NOR_BANK_LO, __SW_NOR_BANK_MASK)) +#else +#define MAP_NOR_LO_CMD(var, ...) "" +#endif + +#ifdef __SW_NOR_BANK_UP +#define MAP_NOR_UP_CMD(var, ...) __VAR_CMD(var, __VA_ARGS__ __BOOTSRC_CMD(__SW_NOR_BANK_UP, __SW_NOR_BANK_MASK)) +#else +#define MAP_NOR_UP_CMD(var, ...) "" +#endif + +#ifdef __SW_BOOT_NOR +#define RST_NOR_CMD(var, ...) __VAR_CMD_RST(var, __VA_ARGS__ __BOOTSRC_CMD(__SW_BOOT_NOR, __SW_BOOT_MASK)) +#else +#define RST_NOR_CMD(var, ...) "" +#endif + +#ifdef __SW_BOOT_SPI +#define RST_SPI_CMD(var, ...) __VAR_CMD_RST(var, __VA_ARGS__ __BOOTSRC_CMD(__SW_BOOT_SPI, __SW_BOOT_MASK)) +#else +#define RST_SPI_CMD(var, ...) "" +#endif + +#ifdef __SW_BOOT_SD +#define RST_SD_CMD(var, ...) __VAR_CMD_RST(var, __VA_ARGS__ __BOOTSRC_CMD(__SW_BOOT_SD, __SW_BOOT_MASK)) +#else +#define RST_SD_CMD(var, ...) "" +#endif + +#ifdef __SW_BOOT_NAND +#define RST_NAND_CMD(var, ...) __VAR_CMD_RST(var, __VA_ARGS__ __BOOTSRC_CMD(__SW_BOOT_NAND, __SW_BOOT_MASK)) +#else +#define RST_NAND_CMD(var, ...) "" +#endif + +#ifdef __SW_BOOT_PCIE +#define RST_PCIE_CMD(var, ...) __VAR_CMD_RST(var, __VA_ARGS__ __BOOTSRC_CMD(__SW_BOOT_PCIE, __SW_BOOT_MASK)) +#else +#define RST_PCIE_CMD(var, ...) "" +#endif diff --git a/include/configs/p1_p2_rdb_pc.h b/include/configs/p1_p2_rdb_pc.h index 995bd983cef1..47bd20eeeafb 100644 --- a/include/configs/p1_p2_rdb_pc.h +++ b/include/configs/p1_p2_rdb_pc.h @@ -575,31 +575,7 @@ #define CONFIG_BOOTFILE"uImage" #define CONFIG_UBOOTPATH u-boot.bin /* U-Boot image on TFTP server */ -#ifdef __SW_BOOT_NOR -#define __NOR_RST_CMD \ -norboot=i2c dev CONFIG_SYS_SPD_BUS_NUM; i2c mw CONFIG_SYS_I2C_PCA9557_ADDR 1 __SW_BOOT_NOR 1; \ -i2c mw CONFIG_SYS_I2C_PCA9557_ADDR 3 __SW_BOOT_MASK 1; reset -#endif -#ifdef __SW_BOOT_SPI -#define __SPI_RST_CMD \ -spiboot=i2c dev CONFIG_SYS_SPD_BUS_NUM; i2c mw CONFIG_SYS_I2C_PCA9557_ADDR 1 __SW_BOOT_SPI 1; \ -i2c mw CONFIG_SYS_I2C_PCA9557_ADDR 3 __SW_BOOT_MASK 1; reset -#endif -#ifdef __SW_BOOT_SD -#define __SD_RST_CMD \ -sdboot=i2c dev CONFIG_SYS_SPD_BUS_NUM; i2c mw CONFIG_SYS_I2C_PCA9557_ADDR 1 __SW_BOOT_SD 1; \ -i2c mw CONFIG_SYS_I2C_PCA9557_ADDR 3 __SW_BOOT_MASK 1; reset -#endif -#ifdef __SW_BOOT_NAND -#define __NAND_RST_CMD \ -nandboot=i2c dev CONFIG_SYS_SPD_BUS_NUM; i2c mw CONFIG_SYS_I2C_PCA9557_ADDR 1 __SW_BOOT_NAND 1; \ -i2c mw CONFIG_SYS_I2C_PCA9557_ADDR 3 __SW_BOOT_MASK 1; reset -#endif -#ifdef __SW_BOOT_PCIE -#define __PCIE_RST_CMD \ -pciboot=i2c dev CONFIG_SYS_SPD_BUS_NUM; i2c mw CONFIG_SYS_I2C_PCA9557_ADDR 1 __SW_BOOT_PCIE 1; \ -i2c mw CONFIG_SYS_I2C_PCA9557_ADDR 3 __SW_BOOT_MASK 1; reset -#endif +#include "p1_p2_bootsrc.h" #defineCONFIG_EXTRA_ENV_SETTINGS \ "netdev=eth0\0"\ @@ -626,13 +602,14 @@ i2c mw CONFIG_SYS_I2C_PCA9557_ADDR 3 __SW_BOOT_MASK 1; reset "nandfdtaddr=8\0" \ "ramdisk_size=12\0"\ __VSCFW_ADDR \ -"map_lowernorbank=i2c dev "__stringify(CONFIG_SYS_SPD_BUS_NUM)"; i2c mw "__stringify(CONFIG_SYS_I2C_PCA9557_ADDR)" 1 "__stringify(__SW_NOR_BANK_LO)" 1; i2c mw "__stringify(CONFIG_SYS_I2C_PCA9557_ADDR)" 3 "__stringify(__SW_NOR_BANK_MASK)" 1\0" \ -"map_uppernorbank=i2c dev "__stringify(CONFIG_SYS_SPD_BUS_NUM)"; i2c mw "__stringify(CONFIG_SYS_I2C_PCA9557_ADDR)" 1 "__stringify(__SW_NOR_BANK_UP)" 1;
Re: [PATCH 2/3] led: Mark device instance with DM_FLAG_PROBE_AFTER_BIND
On Fri, Apr 22, 2022 at 03:15:54PM +0200, Marek Vasut wrote:
> Calling device_probe() from uclass .post_bind() callback has all kinds
> of odd side-effects, e.g. device instances not being available just yet.
> Make use of the DM_FLAG_PROBE_AFTER_BIND instead, mark device instances
> which need to be probe()d in order to configure the LED default state
> with this flag and let the DM core do the device_probe() at the right
> time instead.
>
> Fixes: 72675b063b6 ("led: Configure LED default-state on boot")
> Signed-off-by: Marek Vasut
> Cc: Patrice Chotard
> Cc: Patrick Delaunay
> Cc: Sean Anderson
> Cc: Simon Glass
> Cc: Steven Lawrance
> Reviewed-by: Patrice Chotard
> Tested-by: Patrice Chotard
> ---
> drivers/led/led-uclass.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
This breaks all of the sandbox tests, which perhaps need another update
for what you've changed here? I already had to tweak them once in
72675b063b6e ("led: Configure LED default-state on boot"). But my
perhaps incorrect read then was that the dts / test weren't quite right
to start with. Perhaps that's still the case however?
--
Tom
signature.asc
Description: PGP signature
[PATCH] imx8m: fix reading of DDR4 MR registers
I was trying to employ lpddr4_mr_read() to something similar to what
the imx8mm-cl-iot-gate board is doing for auto-detecting the RAM
type. However, the version in drivers/ddr/imx/imx8m/ddrphy_utils.c
differs from the private one used by that board in how it extracts the
byte value, and I was only getting zeroes. Adding a bit of debug
printf'ing gives me
tmp = 0x0000
tmp = 0x00070700
tmp = 0x
tmp = 0x00101000
and indeed I was expecting a (combined) value of 0xff070010 (0xff
being Manufacturer ID for Micron). I can't find any documentation that
says how the values are supposed to be read, but clearly the iot-gate
definition is the right one, both for its use case as well as my
imx8mp-based board.
So lift the private definition of lpddr4_mr_read() from the
imx8mm-cl-iot-gate board code to ddrphy_utils.c, and add a declaration
in the ddr.h header where e.g. get_trained_CDD() is already declared.
This has only been compile-tested for the imx8mm-cl-iot-gate
board (since I don't have the hardware), but since I've merely moved
its definition of lpddr4_mr_read(), I'd be surprised if it changed
anything for that board.
Signed-off-by: Rasmus Villemoes
---
arch/arm/include/asm/arch-imx8m/ddr.h | 1 +
board/compulab/imx8mm-cl-iot-gate/ddr/ddr.c | 27 -
drivers/ddr/imx/imx8m/ddrphy_utils.c| 9 +--
3 files changed, 8 insertions(+), 29 deletions(-)
diff --git a/arch/arm/include/asm/arch-imx8m/ddr.h
b/arch/arm/include/asm/arch-imx8m/ddr.h
index 0f1e832c03..2ce8a8f2d4 100644
--- a/arch/arm/include/asm/arch-imx8m/ddr.h
+++ b/arch/arm/include/asm/arch-imx8m/ddr.h
@@ -723,6 +723,7 @@ void ddrphy_init_read_msg_block(enum fw_type type);
void update_umctl2_rank_space_setting(unsigned int pstat_num);
void get_trained_CDD(unsigned int fsp);
+unsigned int lpddr4_mr_read(unsigned int mr_rank, unsigned int mr_addr);
static inline void reg32_write(unsigned long addr, u32 val)
{
diff --git a/board/compulab/imx8mm-cl-iot-gate/ddr/ddr.c
b/board/compulab/imx8mm-cl-iot-gate/ddr/ddr.c
index 5b93491923..b230478b61 100644
--- a/board/compulab/imx8mm-cl-iot-gate/ddr/ddr.c
+++ b/board/compulab/imx8mm-cl-iot-gate/ddr/ddr.c
@@ -24,33 +24,6 @@
#include
-static unsigned int lpddr4_mr_read(unsigned int mr_rank, unsigned int mr_addr)
-{
- unsigned int tmp;
-
- reg32_write(DRC_PERF_MON_MRR0_DAT(0), 0x1);
- do {
- tmp = reg32_read(DDRC_MRSTAT(0));
- } while (tmp & 0x1);
-
- reg32_write(DDRC_MRCTRL0(0), (mr_rank << 4) | 0x1);
- reg32_write(DDRC_MRCTRL1(0), (mr_addr << 8));
- reg32setbit(DDRC_MRCTRL0(0), 31);
- do {
- tmp = reg32_read(DRC_PERF_MON_MRR0_DAT(0));
- } while ((tmp & 0x8) == 0);
- tmp = reg32_read(DRC_PERF_MON_MRR1_DAT(0));
- reg32_write(DRC_PERF_MON_MRR0_DAT(0), 0x4);
- while (tmp) { //try to find a significant byte in the word
- if (tmp & 0xff) {
- tmp &= 0xff;
- break;
- }
- tmp >>= 8;
- }
- return tmp;
-}
-
struct lpddr4_desc {
char name[16];
unsigned int id;
diff --git a/drivers/ddr/imx/imx8m/ddrphy_utils.c
b/drivers/ddr/imx/imx8m/ddrphy_utils.c
index a54449e5f1..975d553674 100644
--- a/drivers/ddr/imx/imx8m/ddrphy_utils.c
+++ b/drivers/ddr/imx/imx8m/ddrphy_utils.c
@@ -198,9 +198,14 @@ unsigned int lpddr4_mr_read(unsigned int mr_rank, unsigned
int mr_addr)
tmp = reg32_read(DRC_PERF_MON_MRR0_DAT(0));
} while ((tmp & 0x8) == 0);
tmp = reg32_read(DRC_PERF_MON_MRR1_DAT(0));
- tmp = tmp & 0xff;
reg32_write(DRC_PERF_MON_MRR0_DAT(0), 0x4);
-
+ while (tmp) { //try to find a significant byte in the word
+ if (tmp & 0xff) {
+ tmp &= 0xff;
+ break;
+ }
+ tmp >>= 8;
+ }
return tmp;
}
--
2.31.1
[PATCH v2] board: freescale: p1_p2_rdb_pc: Fix parsing inverted bits from boot input data
On some boards upper 4 bits of i2c boot input data (register 0) are
inverted. Information which bits are inverted is stored in register 2.
So invert read input data back according to register 2 prior processing
them. This fixes printing "rom_loc: value" line during booting.
Signed-off-by: Pali Rohár
---
Changes in v2:
* Use register 2 for detecting which bits needs to be inverted
---
board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c
b/board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c
index 29502a5c05c2..cdbff03ac45c 100644
--- a/board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c
+++ b/board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c
@@ -164,7 +164,7 @@ int checkboard(void)
{
struct cpld_data *cpld_data = (void *)(CONFIG_SYS_CPLD_BASE);
ccsr_gur_t *gur = (void *)(CONFIG_SYS_MPC85xx_GUTS_ADDR);
- u8 in, out, io_config, val;
+ u8 in, out, invert, io_config, val;
int bus_num = CONFIG_SYS_SPD_BUS_NUM;
printf("Board: %s CPLD: V%d.%d PCBA: V%d.0\n", CONFIG_BOARDNAME,
@@ -187,6 +187,7 @@ int checkboard(void)
if (dm_i2c_read(dev, 0, , 1) < 0 ||
dm_i2c_read(dev, 1, , 1) < 0 ||
+ dm_i2c_read(dev, 2, , 1) < 0 ||
dm_i2c_read(dev, 3, _config, 1) < 0) {
printf("Error reading i2c boot information!\n");
return 0; /* Don't want to hang() on this error */
@@ -196,13 +197,14 @@ int checkboard(void)
if (i2c_read(CONFIG_SYS_I2C_PCA9557_ADDR, 0, 1, , 1) < 0 ||
i2c_read(CONFIG_SYS_I2C_PCA9557_ADDR, 1, 1, , 1) < 0 ||
+ i2c_read(CONFIG_SYS_I2C_PCA9557_ADDR, 2, 1, , 1) < 0 ||
i2c_read(CONFIG_SYS_I2C_PCA9557_ADDR, 3, 1, _config, 1) < 0) {
printf("Error reading i2c boot information!\n");
return 0; /* Don't want to hang() on this error */
}
#endif
- val = (in & io_config) | (out & (~io_config));
+ val = ((in ^ invert) & io_config) | (out & (~io_config));
puts("rom_loc: ");
if ((val & (~__SW_BOOT_MASK)) == __SW_BOOT_SD) {
--
2.20.1
[PATCH 2/2] cmd: mmc: allow to write protect single boot partition
From: "Ying-Chun Liu (PaulLiu)"
add arguments for mmc wp to assign which boot partition to protect.
Signed-off-by: Ying-Chun Liu (PaulLiu)
Cc: Peng Fan
Cc: Jaehoon Chung
---
cmd/mmc.c | 18 +++---
1 file changed, 15 insertions(+), 3 deletions(-)
diff --git a/cmd/mmc.c b/cmd/mmc.c
index 7464f8d00c..7f3e5da6cd 100644
--- a/cmd/mmc.c
+++ b/cmd/mmc.c
@@ -1046,6 +1046,7 @@ static int do_mmc_boot_wp(struct cmd_tbl *cmdtp, int flag,
{
int err;
struct mmc *mmc;
+ int part;
mmc = init_mmc_device(curr_device, false);
if (!mmc)
@@ -1054,7 +1055,14 @@ static int do_mmc_boot_wp(struct cmd_tbl *cmdtp, int
flag,
printf("It is not an eMMC device\n");
return CMD_RET_FAILURE;
}
- err = mmc_boot_wp(mmc);
+
+ if (argc == 2) {
+ part = dectoul(argv[1], NULL);
+ err = mmc_boot_wp_single_partition(mmc, part);
+ } else {
+ err = mmc_boot_wp(mmc);
+ }
+
if (err)
return CMD_RET_FAILURE;
printf("boot areas protected\n");
@@ -1064,7 +1072,7 @@ static int do_mmc_boot_wp(struct cmd_tbl *cmdtp, int flag,
static struct cmd_tbl cmd_mmc[] = {
U_BOOT_CMD_MKENT(info, 1, 0, do_mmcinfo, "", ""),
U_BOOT_CMD_MKENT(read, 4, 1, do_mmc_read, "", ""),
- U_BOOT_CMD_MKENT(wp, 1, 0, do_mmc_boot_wp, "", ""),
+ U_BOOT_CMD_MKENT(wp, 2, 0, do_mmc_boot_wp, "", ""),
#if CONFIG_IS_ENABLED(MMC_WRITE)
U_BOOT_CMD_MKENT(write, 4, 0, do_mmc_write, "", ""),
U_BOOT_CMD_MKENT(erase, 3, 0, do_mmc_erase, "", ""),
@@ -1138,7 +1146,11 @@ U_BOOT_CMD(
"[MMC_LEGACY, MMC_HS, SD_HS, MMC_HS_52, MMC_DDR_52, UHS_SDR12,
UHS_SDR25,\n"
"UHS_SDR50, UHS_DDR50, UHS_SDR104, MMC_HS_200, MMC_HS_400,
MMC_HS_400_ES]\n"
"mmc list - lists available devices\n"
- "mmc wp - power on write protect boot partitions\n"
+ "mmc wp [PART] - power on write protect boot partitions\n"
+ " arguments:\n"
+ " PART - [0|1]\n"
+ " : 0 - first boot partition, 1 - second boot partition\n"
+ " if not assigned, write protect all boot partitions\n"
#if CONFIG_IS_ENABLED(MMC_HW_PARTITIONING)
"mmc hwpartition- does hardware partitioning\n"
" arguments (sizes in 512-byte blocks):\n"
--
2.35.1
[PATCH 1/2] drivers: mmc: write protect single boot area
From: "Ying-Chun Liu (PaulLiu)"
Add features to write protect single boot area rather than all boot
areas.
Signed-off-by: Ying-Chun Liu (PaulLiu)
Cc: Peng Fan
Cc: Jaehoon Chung
---
drivers/mmc/mmc.c | 27 +++
include/mmc.h | 16
2 files changed, 43 insertions(+)
diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index f6ccd837aa..53f931e993 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -860,6 +860,33 @@ int mmc_boot_wp(struct mmc *mmc)
return mmc_switch(mmc, EXT_CSD_CMD_SET_NORMAL, EXT_CSD_BOOT_WP, 1);
}
+int mmc_boot_wp_single_partition(struct mmc *mmc, int partition)
+{
+ u8 value;
+ int ret;
+
+ value = EXT_CSD_BOOT_WP_B_PWR_WP_EN;
+
+ if (partition == 0) {
+ value |= EXT_CSD_BOOT_WP_B_SEC_WP_SEL;
+ ret = mmc_switch(mmc,
+EXT_CSD_CMD_SET_NORMAL,
+EXT_CSD_BOOT_WP,
+value);
+ } else if (partition == 1) {
+ value |= EXT_CSD_BOOT_WP_B_SEC_WP_SEL;
+ value |= EXT_CSD_BOOT_WP_B_PWR_WP_SEC_SEL;
+ ret = mmc_switch(mmc,
+EXT_CSD_CMD_SET_NORMAL,
+EXT_CSD_BOOT_WP,
+value);
+ } else {
+ ret = mmc_boot_wp(mmc);
+ }
+
+ return ret;
+}
+
#if !CONFIG_IS_ENABLED(MMC_TINY)
static int mmc_set_card_speed(struct mmc *mmc, enum bus_mode mode,
bool hsdowngrade)
diff --git a/include/mmc.h b/include/mmc.h
index 6bdcce881d..a1b3c49af4 100644
--- a/include/mmc.h
+++ b/include/mmc.h
@@ -308,6 +308,10 @@ static inline bool mmc_is_tuning_cmd(uint cmdidx)
#define EXT_CSD_HS_CTRL_REL(1 << 0)/* host controlled WR_REL_SET */
+#define EXT_CSD_BOOT_WP_B_SEC_WP_SEL (0x80) /* enable partition selector */
+#define EXT_CSD_BOOT_WP_B_PWR_WP_SEC_SEL (0x02)/* partition selector
to protect */
+#define EXT_CSD_BOOT_WP_B_PWR_WP_EN(0x01) /* power-on write-protect */
+
#define EXT_CSD_WR_DATA_REL_USR(1 << 0)/* user data
area WR_REL */
#define EXT_CSD_WR_DATA_REL_GP(x) (1 << ((x)+1)) /* GP part (x+1) WR_REL
*/
@@ -980,6 +984,18 @@ int mmc_send_ext_csd(struct mmc *mmc, u8 *ext_csd);
*/
int mmc_boot_wp(struct mmc *mmc);
+/**
+ * mmc_boot_wp_single_partition() - set write protection to a boot partition.
+ *
+ * This function sets a single boot partition to protect and leave the
+ * other partition writable.
+ *
+ * @param mmc the mmc device.
+ * @param partition 0 - first boot partition, 1 - second boot partition.
+ * @return 0 for success
+ */
+int mmc_boot_wp_single_partition(struct mmc *mmc, int partition);
+
static inline enum dma_data_direction mmc_get_dma_dir(struct mmc_data *data)
{
return data->flags & MMC_DATA_WRITE ? DMA_TO_DEVICE : DMA_FROM_DEVICE;
--
2.35.1
[PATCH 0/2] allow to write protect single boot partition
From: "Ying-Chun Liu (PaulLiu)" Modify mmc wp command and mmc driver to allow write protect only a single boot partition. Ying-Chun Liu (PaulLiu) (2): drivers: mmc: write protect single boot area cmd: mmc: allow to write protect single boot partition cmd/mmc.c | 18 +++--- drivers/mmc/mmc.c | 27 +++ include/mmc.h | 16 3 files changed, 58 insertions(+), 3 deletions(-) -- 2.35.1
Re: possible off-by-one error on month counting in rtc rv8803 driver
Hi, Am 2022-04-25 14:55, schrieb Oliver Graute: I stumbled across the following possible off-by-one error in counting the month in RTC driver rv8803. .. (drivers/rtc/rv8803.c) rv8803_rtc_set() ... buf[RTC_MON_REG_ADDR] = bin2bcd(tm->tm_mon) ... rv8803_rtc_get() ... tm->tm_mon = bcd2bin(buf[RTC_MON_REG_ADDR] & 0x1F); ... I assume that the error is here and increase and decrease by one is also required here like in the Linux driver code for RTC 8803. Indeed. tm_mon has a range from 0 .. 11, but the RTC expects 1..12. Nice catch. Can someone verify and comment on this. Then I would prepare a patch later on. Yes please. -michael
Re: [PATCH 1/4] ARM: imx: imx8m: Introduce and use UART_BASE_ADDR(n)
On Mon, Apr 25, 2022 at 03:13:53PM +0200, Marek Vasut wrote: > On 4/25/22 15:05, Tom Rini wrote: > > On Mon, Apr 25, 2022 at 03:02:29PM +0200, Marek Vasut wrote: > > > On 4/25/22 14:46, Fabio Estevam wrote: > > > > Hi Marek, > > > > > > > > On 24/04/2022 18:44, Marek Vasut wrote: > > > > > Introduce helper macro UART_BASE_ADDR(n), which returns Nth UART base > > > > > address. Convert all board configurations to this new macro. This is > > > > > the > > > > > first step toward switching CONFIG_MXC_UART_BASE to Kconfig. This is a > > > > > clean up, no functional change. > > > > > > > > As DM_SERIAL is mandatory now, we should get rid of > > > > CONFIG_MXC_UART_BASE. > > > > > > > > I would prefer a patch that removes CONFIG_MXC_UART_BASE instead. > > > > > > DM is mandatory in SPL too ? I doubt it. > > > > It is strongly encouraged, but not mandatory. It is not used on I guess > > imx27/31/5, but is for all of the imx8 families. So > > CONFIG_MXC_UART_BASE still needs to be moved out of board.h files (and > > perhaps out of CONFIG namespace since it's not configurable, it's part > > of the SoC) and perhaps the path for imx8* is to drop the references > > since it's all DM? > > MX8M SPL is not DM serial either. But I think I will just postpone this > cleanup until I have time to finish it. Right, sorry, I meant DM enabled in SPL to start with. -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/4] ARM: imx: imx8m: Introduce and use UART_BASE_ADDR(n)
On 25/04/2022 10:05, Tom Rini wrote: DM is mandatory in SPL too ? I doubt it. It is strongly encouraged, but not mandatory. It is not used on I guess imx27/31/5, but is for all of the imx8 families. So CONFIG_MXC_UART_BASE still needs to be moved out of board.h files (and perhaps out of CONFIG namespace since it's not configurable, it's part of the SoC) and perhaps the path for imx8* is to drop the references since it's all DM? Correct. In the defconfigs where CONFIG_DM_SERIAL=y and CONFIG_SPL_DM=y are selected the CONFIG_MXC_UART_BASE can be safely dropped. Regards, Fabio Estevam
Re: [PATCH 1/4] ARM: imx: imx8m: Introduce and use UART_BASE_ADDR(n)
On 4/25/22 15:05, Tom Rini wrote: On Mon, Apr 25, 2022 at 03:02:29PM +0200, Marek Vasut wrote: On 4/25/22 14:46, Fabio Estevam wrote: Hi Marek, On 24/04/2022 18:44, Marek Vasut wrote: Introduce helper macro UART_BASE_ADDR(n), which returns Nth UART base address. Convert all board configurations to this new macro. This is the first step toward switching CONFIG_MXC_UART_BASE to Kconfig. This is a clean up, no functional change. As DM_SERIAL is mandatory now, we should get rid of CONFIG_MXC_UART_BASE. I would prefer a patch that removes CONFIG_MXC_UART_BASE instead. DM is mandatory in SPL too ? I doubt it. It is strongly encouraged, but not mandatory. It is not used on I guess imx27/31/5, but is for all of the imx8 families. So CONFIG_MXC_UART_BASE still needs to be moved out of board.h files (and perhaps out of CONFIG namespace since it's not configurable, it's part of the SoC) and perhaps the path for imx8* is to drop the references since it's all DM? MX8M SPL is not DM serial either. But I think I will just postpone this cleanup until I have time to finish it.
Re: [PATCH 1/4] ARM: imx: imx8m: Introduce and use UART_BASE_ADDR(n)
On Mon, Apr 25, 2022 at 03:02:29PM +0200, Marek Vasut wrote: > On 4/25/22 14:46, Fabio Estevam wrote: > > Hi Marek, > > > > On 24/04/2022 18:44, Marek Vasut wrote: > > > Introduce helper macro UART_BASE_ADDR(n), which returns Nth UART base > > > address. Convert all board configurations to this new macro. This is the > > > first step toward switching CONFIG_MXC_UART_BASE to Kconfig. This is a > > > clean up, no functional change. > > > > As DM_SERIAL is mandatory now, we should get rid of CONFIG_MXC_UART_BASE. > > > > I would prefer a patch that removes CONFIG_MXC_UART_BASE instead. > > DM is mandatory in SPL too ? I doubt it. It is strongly encouraged, but not mandatory. It is not used on I guess imx27/31/5, but is for all of the imx8 families. So CONFIG_MXC_UART_BASE still needs to be moved out of board.h files (and perhaps out of CONFIG namespace since it's not configurable, it's part of the SoC) and perhaps the path for imx8* is to drop the references since it's all DM? -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/4] ARM: imx: imx8m: Introduce and use UART_BASE_ADDR(n)
On 4/25/22 14:46, Fabio Estevam wrote: Hi Marek, On 24/04/2022 18:44, Marek Vasut wrote: Introduce helper macro UART_BASE_ADDR(n), which returns Nth UART base address. Convert all board configurations to this new macro. This is the first step toward switching CONFIG_MXC_UART_BASE to Kconfig. This is a clean up, no functional change. As DM_SERIAL is mandatory now, we should get rid of CONFIG_MXC_UART_BASE. I would prefer a patch that removes CONFIG_MXC_UART_BASE instead. DM is mandatory in SPL too ? I doubt it.
possible off-by-one error on month counting in rtc rv8803 driver
Hello, I stumbled across the following possible off-by-one error in counting the month in RTC driver rv8803. I'am using struct rtc_time to define a EOL date for my U-Boots. So after this date U-Boot stops booting by reading the RTC before with rtc_get(). I'am using the same EOL code for two different imx boards with different RTCs and therefore different RTC drivers. On both boards I have set the same EOL date. So the EOL Date is 25.09.2022 23:59:59 The board with rv3029 stopps booting on 26.09.2022 0:00:00 The board with rv8803 stopps booting on 26.08.2022 0:00:00 U-Boot Code: (drivers/rtc/rv3029.c) v3029_rtc_set() ... regs[RV3029_W_MONTHS - RV3029_W_SEC] = bin2bcd(tm->tm_mon + 1); ... rv3029_rtc_get() ... tm->tm_mon = bcd2bin(regs[RV3029_W_MONTHS - RV3029_W_SEC]) - 1; ... (drivers/rtc/rv8803.c) rv8803_rtc_set() ... buf[RTC_MON_REG_ADDR] = bin2bcd(tm->tm_mon) ... rv8803_rtc_get() ... tm->tm_mon = bcd2bin(buf[RTC_MON_REG_ADDR] & 0x1F); ... I assume that the error is here and increase and decrease by one is also required here like in the Linux driver code for RTC 8803. Linux Code: rv3029_set_time() ... regs[RV3029_W_MONTHS - RV3029_W_SEC] = bin2bcd(tm->tm_mon + 1); ... rv3029_read_time() ... tm->tm_mon = bcd2bin(regs[RV3029_W_MONTHS - RV3029_W_SEC]) - 1; ... rv8803_set_time() ... date[RV8803_MONTH] = bin2bcd(tm->tm_mon + 1); ... rv8803_get_time() ... tm->tm_mon = bcd2bin(date[RV8803_MONTH] & 0x1f) - 1; ... Can someone verify and comment on this. Then I would prepare a patch later on. Best Regards, Oliver
Re: [PATCH] ARM: imx: imx8q: Use LPUART_BASE macro in config files
On Sun, Apr 24, 2022 at 11:43:10PM +0200, Marek Vasut wrote:
> Replace ad-hoc value with LPUART_BASE macro, no functional change.
>
> Signed-off-by: Marek Vasut
> Cc: Fabio Estevam
> Cc: Peng Fan
> Cc: Stefano Babic
> Cc: Tom Rini
> ---
> include/configs/cgtqmx8.h | 2 +-
> include/configs/imx8qm_mek.h | 4 ++--
> include/configs/imx8qxp_mek.h | 2 +-
> 3 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/include/configs/cgtqmx8.h b/include/configs/cgtqmx8.h
> index 6da0483ef09..db2555c23cc 100644
> --- a/include/configs/cgtqmx8.h
> +++ b/include/configs/cgtqmx8.h
> @@ -20,7 +20,7 @@
> #define CONFIG_SPL_BSS_MAX_SIZE 0x1000 /* 4 KB */
> #define CONFIG_SYS_SPL_MALLOC_START 0x0012
> #define CONFIG_SYS_SPL_MALLOC_SIZE 0x3000 /* 12 KB */
> -#define CONFIG_SERIAL_LPUART_BASE0x5a06
> +#define CONFIG_SERIAL_LPUART_BASELPUART_BASE
> #define CONFIG_MALLOC_F_ADDR 0x0012
>
> #define CONFIG_SPL_RAW_IMAGE_ARM_TRUSTED_FIRMWARE
> diff --git a/include/configs/imx8qm_mek.h b/include/configs/imx8qm_mek.h
> index 61d56e269ac..b9ad61ce501 100644
> --- a/include/configs/imx8qm_mek.h
> +++ b/include/configs/imx8qm_mek.h
> @@ -21,7 +21,7 @@
> #define CONFIG_SPL_BSS_MAX_SIZE 0x1000 /* 4 KB */
> #define CONFIG_SYS_SPL_MALLOC_START 0x0012
> #define CONFIG_SYS_SPL_MALLOC_SIZE 0x3000 /* 12 KB */
> -#define CONFIG_SERIAL_LPUART_BASE0x5a06
> +#define CONFIG_SERIAL_LPUART_BASELPUART_BASE
> #define CONFIG_MALLOC_F_ADDR 0x0012
>
> #define CONFIG_SPL_RAW_IMAGE_ARM_TRUSTED_FIRMWARE
> @@ -41,7 +41,7 @@
> "script=boot.scr\0" \
> "image=Image\0" \
> "panel=NULL\0" \
> - "console=ttyLP0,${baudrate} earlycon=lpuart32,0x5a06,${baudrate}\0"
> \
> + "console=ttyLP0,${baudrate} earlycon=lpuart32,"
> __stringify(LPUART_BASE) ",${baudrate}\0" \
> "fdt_addr=0x8300\0" \
> "fdt_high=0x\0" \
> "boot_fdt=try\0" \
> diff --git a/include/configs/imx8qxp_mek.h b/include/configs/imx8qxp_mek.h
> index 26dc4ded030..11a8ac50691 100644
> --- a/include/configs/imx8qxp_mek.h
> +++ b/include/configs/imx8qxp_mek.h
> @@ -19,7 +19,7 @@
> #define CONFIG_SPL_BSS_MAX_SIZE 0x1000 /* 4 KB */
> #define CONFIG_SYS_SPL_MALLOC_START 0x0012
> #define CONFIG_SYS_SPL_MALLOC_SIZE 0x3000 /* 12 KB */
> -#define CONFIG_SERIAL_LPUART_BASE0x5a06
> +#define CONFIG_SERIAL_LPUART_BASELPUART_BASE
> #define CONFIG_MALLOC_F_ADDR 0x0012
>
> #define CONFIG_SPL_RAW_IMAGE_ARM_TRUSTED_FIRMWARE
This kind of change makes Kconfig migration harder for moveconfig.py to
handle. I don't see CONFIG_SERIAL_LPUART_BASE used in code, so we
should just drop it. And so far as we're consistent about how to pass
earlycon info, we just put the raw address, but I don't strongly object
to __stringify(LPUART_BASE) as it is clearer, and handling the default
env part of board config.h has its own challenges more broadly.
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH 1/4] ARM: imx: imx8m: Introduce and use UART_BASE_ADDR(n)
Hi Marek, On 24/04/2022 18:44, Marek Vasut wrote: Introduce helper macro UART_BASE_ADDR(n), which returns Nth UART base address. Convert all board configurations to this new macro. This is the first step toward switching CONFIG_MXC_UART_BASE to Kconfig. This is a clean up, no functional change. As DM_SERIAL is mandatory now, we should get rid of CONFIG_MXC_UART_BASE. I would prefer a patch that removes CONFIG_MXC_UART_BASE instead. Regards, Fabio Estevam
Re: [PATCH 1/2] powerpc: mpc85xx: Add support for generating QorIQ pre-PBL eSDHC boot sector
On Monday 25 April 2022 05:25:34 Priyanka Jain (OSS) wrote: > >-Original Message- > >From: U-Boot On Behalf Of Pali Rohár > >Sent: Tuesday, April 5, 2022 7:11 PM > >To: Priyanka Jain ; Qiang Zhao ; > >Shengzhou Liu ; Alexander Graf ; > >Bin Meng ; Wolfgang Denk ; Sinan > >Akman > >Cc: u-boot@lists.denx.de > >Subject: [PATCH 1/2] powerpc: mpc85xx: Add support for generating QorIQ pre- > >PBL eSDHC boot sector > > > >QorIQ U-Boot binary for SD card booting compiled during build process > >(either u- > >boot.bin or u-boot-with-spl.bin) cannot be directly loaded by QorIQ pre-PBL > >BootROM. Compiled U-Boot binary first needs to be processed by Freescale > >boot_format tool as described in doc/README.mpc85xx-sd-spi-boot > > > >BootROM requires that image on SD card must contain special boot sector. > >Implement support for generating this special boot sector directly in U-Boot > >start > >code. Boot sector needs to be at the beginning of the image, so when > >compiling > >only proper U-Boot without SPL then it needs to be in proper U-Boot. When > >compiling SPL with proper U-Boot then it needs to be only in SPL. > > > >Support can be enabled by a new config option > >FSL_PREPBL_ESDHC_BOOT_SECTOR. > >Via other two additional options FSL_PREPBL_ESDHC_BOOT_SECTOR_START and > >FSL_PREPBL_ESDHC_BOOT_SECTOR_DATA it is possible to tune how final U-Boot > >image could be stored on the SD card. > > > >Signed-off-by: Pali Rohár > >--- > > Kindly rebase the series to master. > > Regards > Priyanka Hello! Both patches still applies cleanly on master, just they depend on another patch series (powerpc: mpc85xx: Fix and cleanup mpc85xx code) which I mentioned in cover letter and therefore needs V2 patch of "powerpc: mpc85xx: Set TEXT_BASE addresses to real base values" which I sent recently.
Re: [PATCH v3 0/6] meson: add clk and adc support for JetHub D1 (j100)
Hi, On 25/04/2022 12:01, Vyacheslav wrote: 25.04.2022 10:25, Neil Armstrong wrote: Hi, On Sun, 24 Apr 2022 11:21:53 +0300, Vyacheslav Bocharov wrote: Prepare to use ADC channel 1 in JetHub D1 (j100) to check the hardware revision of the board. - add support for AXG in saradc driver - add simple clk-ao driver for AXG (base is taken from g12a) - enable saradc in dts and board config file - fix typo in the g12a-clk-ao driver name - move clk->id check to .request function for g12a-clk-ao driver - remove unnecessary check (gate->reg == 0) in g12a-clk-ao driver - enable saradc in dts/board config for JetHub D1 (j100) [...] Thanks, Applied to https://source.denx.de/u-boot/custodians/u-boot-amlogic (u-boot-amlogic-test) Thanks. Let me know if additional testing or rework is needed. So far all is ok, CI passed: https://source.denx.de/u-boot/custodians/u-boot-amlogic/-/pipelines/11853 Can you send a following patch to update the doc and indicate ADC is supported on AXG (and G12A, G12B & SM1 by the way) ? Thanks, Neil [1/6] clk: meson: add minimal driver for axg-ao clocks https://source.denx.de/u-boot/custodians/u-boot-amlogic/-/commit/dcccf730043197464f7bafdb1abcebcb7fd828b0 [2/6] clk: meson: fix driver name for g12a-ao clocks https://source.denx.de/u-boot/custodians/u-boot-amlogic/-/commit/4da098656228535539be40f76806ad6657b94407 [3/6] clk: meson: update driver for g12a-ao clocks https://source.denx.de/u-boot/custodians/u-boot-amlogic/-/commit/66a657b7c6082fe374c99d5b2a7e0d911091dbe4 [4/6] adc: meson-saradc: add AXG variant https://source.denx.de/u-boot/custodians/u-boot-amlogic/-/commit/8a4a73f466c1d2189aa5f8612f2f90ec9a727ea0 [5/6] board: amlogic: jethub j100: enable saradc in dts https://source.denx.de/u-boot/custodians/u-boot-amlogic/-/commit/ee8094f69646825d2c30b8bb9082e976f023f710 [6/6] board: amlogic: jethub j100: enable saradc in config https://source.denx.de/u-boot/custodians/u-boot-amlogic/-/commit/a718f5524d492fb5708e884cb1db21384f826c00
Re: [PATCH 7/8] powerpc: mpc85xx: Set TEXT_BASE addresses to real base values
On Monday 25 April 2022 04:27:51 Priyanka Jain (OSS) wrote: > >-Original Message- > >From: U-Boot On Behalf Of Pali Rohár > >Sent: Tuesday, April 5, 2022 6:43 PM > >To: Priyanka Jain ; Qiang Zhao ; > >Shengzhou Liu ; Alexander Graf ; > >Bin Meng ; Wolfgang Denk ; Sinan > >Akman > >Cc: u-boot@lists.denx.de > >Subject: [PATCH 7/8] powerpc: mpc85xx: Set TEXT_BASE addresses to real base > >values > > > >Currently CONFIG_SPL_TEXT_BASE and CONFIG_SYS_TEXT_BASE addresses are > >manually increased by 0x1000 due to .bootpg section. This section has size of > >0x1000 bytes and is manually put by linker script before .text section (and > >therefore before base address) when CONFIG_SYS_MPC85XX_NO_RESETVEC is > >set. Due to this fact lot of other config options are manually increased by > >0x1000 value to make correct layout. Note that entry point is not on > >CONFIG_SPL_TEXT_BASE (image+0x1000) but it is really on address > >CONFIG_SPL_TEXT_BASE-0x1000 (means at the start of the image). > > > >Cleanup handling of .bootpg section when > >CONFIG_SYS_MPC85XX_NO_RESETVEC is set. Put .bootpg code directly into .text > >section and move text base address to the start of .bootpg code. And finally > >remove +0x1000 value from lot of config options. With this removal custom > >PHDRS is not used anymore, so remove it too. > > > >After this change entry point would be at CONFIG_SPL_TEXT_BASE and not at > >address -0x1000 anymore. > > > >Tested on P2020 board with SPL and proper U-Boot. > > > >Signed-off-by: Pali Rohár > >--- > > Kindly rebase to top of tree. There has been changed related configs. > I am picking patches till 6/8. So just send next version of 7/8 and 8/8 Done! I rebased 7/8 on top of master and sent V2 to ML. 8/8 in current version still cleanly applied on 7/8, so I did not resent it. If there is some issue, please let me know.
[PATCH v2] powerpc: mpc85xx: Set TEXT_BASE addresses to real base values
Currently CONFIG_SPL_TEXT_BASE and CONFIG_SYS_TEXT_BASE addresses are manually increased by 0x1000 due to .bootpg section. This section has size of 0x1000 bytes and is manually put by linker script before .text section (and therefore before base address) when CONFIG_SYS_MPC85XX_NO_RESETVEC is set. Due to this fact lot of other config options are manually increased by 0x1000 value to make correct layout. Note that entry point is not on CONFIG_SPL_TEXT_BASE (image+0x1000) but it is really on address CONFIG_SPL_TEXT_BASE-0x1000 (means at the start of the image). Cleanup handling of .bootpg section when CONFIG_SYS_MPC85XX_NO_RESETVEC is set. Put .bootpg code directly into .text section and move text base address to the start of .bootpg code. And finally remove +0x1000 value from lot of config options. With this removal custom PHDRS is not used anymore, so remove it too. After this change entry point would be at CONFIG_SPL_TEXT_BASE and not at address -0x1000 anymore. Tested on P2020 board with SPL and proper U-Boot. Signed-off-by: Pali Rohár --- Changes in v2: * Rebased on top of the U-Boot master branch, commit 9bb99fa95826d1a608737ca821977b4136a1a278 --- arch/powerpc/cpu/mpc85xx/start.S | 4 ++-- arch/powerpc/cpu/mpc85xx/u-boot-spl.lds | 15 +++- arch/powerpc/cpu/mpc85xx/u-boot.lds | 24 ++-- configs/P1010RDB-PA_36BIT_NAND_defconfig | 6 ++--- configs/P1010RDB-PA_36BIT_SDCARD_defconfig | 4 ++-- configs/P1010RDB-PA_36BIT_SPIFLASH_defconfig | 4 ++-- configs/P1010RDB-PA_NAND_defconfig | 6 ++--- configs/P1010RDB-PA_SDCARD_defconfig | 4 ++-- configs/P1010RDB-PA_SPIFLASH_defconfig | 4 ++-- configs/P1010RDB-PB_36BIT_NAND_defconfig | 6 ++--- configs/P1010RDB-PB_36BIT_SDCARD_defconfig | 4 ++-- configs/P1010RDB-PB_36BIT_SPIFLASH_defconfig | 4 ++-- configs/P1010RDB-PB_NAND_defconfig | 6 ++--- configs/P1010RDB-PB_SDCARD_defconfig | 4 ++-- configs/P1010RDB-PB_SPIFLASH_defconfig | 4 ++-- configs/P1020RDB-PC_36BIT_NAND_defconfig | 6 ++--- configs/P1020RDB-PC_36BIT_SDCARD_defconfig | 6 ++--- configs/P1020RDB-PC_36BIT_SPIFLASH_defconfig | 6 ++--- configs/P1020RDB-PC_NAND_defconfig | 6 ++--- configs/P1020RDB-PC_SDCARD_defconfig | 6 ++--- configs/P1020RDB-PC_SPIFLASH_defconfig | 6 ++--- configs/P1020RDB-PD_NAND_defconfig | 6 ++--- configs/P1020RDB-PD_SDCARD_defconfig | 6 ++--- configs/P1020RDB-PD_SPIFLASH_defconfig | 6 ++--- configs/P2020RDB-PC_36BIT_NAND_defconfig | 6 ++--- configs/P2020RDB-PC_36BIT_SDCARD_defconfig | 6 ++--- configs/P2020RDB-PC_36BIT_SPIFLASH_defconfig | 6 ++--- configs/P2020RDB-PC_NAND_defconfig | 6 ++--- configs/P2020RDB-PC_SDCARD_defconfig | 6 ++--- configs/P2020RDB-PC_SPIFLASH_defconfig | 6 ++--- configs/T1024RDB_NAND_defconfig | 2 +- configs/T1024RDB_SDCARD_defconfig| 2 +- configs/T1024RDB_SPIFLASH_defconfig | 2 +- configs/T1042D4RDB_NAND_defconfig| 2 +- configs/T1042D4RDB_SDCARD_defconfig | 2 +- configs/T1042D4RDB_SPIFLASH_defconfig| 2 +- configs/T2080QDS_NAND_defconfig | 2 +- configs/T2080QDS_SDCARD_defconfig| 2 +- configs/T2080QDS_SPIFLASH_defconfig | 2 +- configs/T2080RDB_NAND_defconfig | 2 +- configs/T2080RDB_SDCARD_defconfig| 2 +- configs/T2080RDB_SPIFLASH_defconfig | 2 +- configs/T2080RDB_revD_NAND_defconfig | 2 +- configs/T2080RDB_revD_SDCARD_defconfig | 2 +- configs/T2080RDB_revD_SPIFLASH_defconfig | 2 +- configs/T4240RDB_SDCARD_defconfig| 2 +- configs/qemu-ppce500_defconfig | 4 ++-- include/configs/P1010RDB.h | 4 ++-- include/configs/p1_p2_rdb_pc.h | 4 ++-- 49 files changed, 107 insertions(+), 126 deletions(-) diff --git a/arch/powerpc/cpu/mpc85xx/start.S b/arch/powerpc/cpu/mpc85xx/start.S index 9ddd37111906..e2e9ab4d9005 100644 --- a/arch/powerpc/cpu/mpc85xx/start.S +++ b/arch/powerpc/cpu/mpc85xx/start.S @@ -1128,7 +1128,7 @@ switch_as: /*--*/ lis r3,CONFIG_VAL(SYS_MONITOR_BASE)@h ori r3,r3,CONFIG_VAL(SYS_MONITOR_BASE)@l - addir3,r3,_start_cont - _start + addir3,r3,_start_cont - CONFIG_VAL(SYS_MONITOR_BASE) mtlrr3 blr #endif @@ -1604,7 +1604,7 @@ relocate_code: * initialization, now running from RAM. */ - addir0,r10,in_ram - _start + addir0,r10,in_ram - CONFIG_VAL(SYS_MONITOR_BASE) /* * As IVPR is going to point RAM address, diff --git a/arch/powerpc/cpu/mpc85xx/u-boot-spl.lds b/arch/powerpc/cpu/mpc85xx/u-boot-spl.lds index 1b4d1e05a4a3..6fd0da9f39b1 100644 --- a/arch/powerpc/cpu/mpc85xx/u-boot-spl.lds +++
Re: [PATCH 2/2] mtd: nand: mxs_nand_spl: Fix bad block skipping
Hi
+cc Stefano Babic
We have right now a while (1) if we find a badblock
On Sat, Apr 23, 2022 at 10:12 AM Michael Trimarchi
wrote:
>
> The file was fill of problems and bugs. The bad block are marked
> beginning of erase block. The first erase block was never checked
> and the specific function to skip bad block in fit image was never
> implemented. The imx8mn bootrom seems that not handle the bad
> block as expected so this needed later to switch from boot rom
> loader to uboot spl one
>
> Signed-off-by: Michael Trimarchi
> ---
> drivers/mtd/nand/raw/mxs_nand_spl.c | 90 -
> 1 file changed, 49 insertions(+), 41 deletions(-)
>
> diff --git a/drivers/mtd/nand/raw/mxs_nand_spl.c
> b/drivers/mtd/nand/raw/mxs_nand_spl.c
> index 59a67ee414..c1a833d6c8 100644
> --- a/drivers/mtd/nand/raw/mxs_nand_spl.c
> +++ b/drivers/mtd/nand/raw/mxs_nand_spl.c
> @@ -218,14 +218,14 @@ void nand_init(void)
> mxs_nand_setup_ecc(mtd);
> }
>
> -int nand_spl_load_image(uint32_t offs, unsigned int size, void *buf)
> +int nand_spl_load_image(uint32_t offs, unsigned int size, void *dst)
> {
> - struct nand_chip *chip;
> - unsigned int page;
> + unsigned int sz;
> + unsigned int block, lastblock;
> + unsigned int page, page_offset;
> unsigned int nand_page_per_block;
> - unsigned int sz = 0;
> + struct nand_chip *chip;
> u8 *page_buf = NULL;
> - u32 page_off;
>
> chip = mtd_to_nand(mtd);
> if (!chip->numchips)
> @@ -235,47 +235,42 @@ int nand_spl_load_image(uint32_t offs, unsigned int
> size, void *buf)
> if (!page_buf)
> return -ENOMEM;
>
> - page = offs >> chip->page_shift;
> - page_off = offs & (mtd->writesize - 1);
> + /* offs has to be aligned to a page address! */
> + block = offs / mtd->erasesize;
> + lastblock = (offs + size - 1) / mtd->erasesize;
> + page = (offs % mtd->erasesize) / mtd->writesize;
> + page_offset = offs % mtd->writesize;
> nand_page_per_block = mtd->erasesize / mtd->writesize;
>
> - debug("%s offset:0x%08x len:%d page:%x\n", __func__, offs, size,
> page);
> -
> - while (size) {
> - if (mxs_read_page_ecc(mtd, page_buf, page) < 0)
> - return -1;
> -
> - if (size > (mtd->writesize - page_off))
> - sz = (mtd->writesize - page_off);
> - else
> - sz = size;
> -
> - memcpy(buf, page_buf + page_off, sz);
> -
> - offs += mtd->writesize;
> - page++;
> - buf += (mtd->writesize - page_off);
> - page_off = 0;
> - size -= sz;
> -
> - /*
> -* Check if we have crossed a block boundary, and if so
> -* check for bad block.
> -*/
> - if (!(page % nand_page_per_block)) {
> - /*
> -* Yes, new block. See if this block is good. If not,
> -* loop until we find a good block.
> -*/
> - while (is_badblock(mtd, offs, 1)) {
> - page = page + nand_page_per_block;
> - /* Check i we've reached the end of flash. */
> - if (page >= mtd->size >> chip->page_shift) {
> + while (block <= lastblock && size >= 0) {
> + if (!is_badblock(mtd, mtd->erasesize * block, 1)) {
> + /* Skip bad blocks */
> + while (page < nand_page_per_block) {
> + int curr_page = nand_page_per_block * block +
> page;
> +
> + if (mxs_read_page_ecc(mtd, page_buf,
> curr_page) < 0) {
> free(page_buf);
> - return -ENOMEM;
> + return -EIO;
> }
> +
> + if (size > (mtd->writesize - page_offset))
> + sz = (mtd->writesize - page_offset);
> + else
> + sz = size;
> +
> + memcpy(dst, page_buf + page_offset, sz);
> + dst += sz;
> + size -= sz;
> + page_offset = 0;
> + page++;
> }
> +
> + page = 0;
> + } else {
> + lastblock++;
> }
> +
> + block++;
> }
>
> free(page_buf);
> @@ -294,6 +289,19 @@ void nand_deselect(void)
>
> u32 nand_spl_adjust_offset(u32 sector, u32 offs)
> {
> - /* Handle the offset adjust in
Re: [PATCH] usb: dwc3: Fix non-usb3 configurations
On 4/25/22 13:26, Jan Kiszka wrote:
From: Jan Kiszka
Missing nodes may also be signaled via -ENODATA. We need to check for
that to prevent failing in non-usb3 setups.
Furthermore, dev.phy must be NULL'ed in case usb3-phy was not found.
Fixes: 142d50fbce7c ("usb: dwc3: Add support for usb3-phy PHY configuration")
Signed-off-by: Jan Kiszka
---
drivers/usb/dwc3/dwc3-generic.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/dwc3/dwc3-generic.c b/drivers/usb/dwc3/dwc3-generic.c
index 6e1a1d066b4..c5310e465cb 100644
--- a/drivers/usb/dwc3/dwc3-generic.c
+++ b/drivers/usb/dwc3/dwc3-generic.c
@@ -468,9 +468,11 @@ static int dwc3_glue_probe(struct udevice *dev)
ret = generic_phy_init();
if (ret)
return ret;
- } else if (ret != -ENOENT) {
+ } else if (ret != -ENOENT && ret != -ENODATA) {
debug("could not get phy (err %d)\n", ret);
return ret;
+ } else {
+ phy.dev = NULL;
}
glue->regs = dev_read_addr(dev);
Reviewed-by: Michal Simek
Thanks,
Michal
[PATCH] usb: dwc3: Fix non-usb3 configurations
From: Jan Kiszka
Missing nodes may also be signaled via -ENODATA. We need to check for
that to prevent failing in non-usb3 setups.
Furthermore, dev.phy must be NULL'ed in case usb3-phy was not found.
Fixes: 142d50fbce7c ("usb: dwc3: Add support for usb3-phy PHY configuration")
Signed-off-by: Jan Kiszka
---
drivers/usb/dwc3/dwc3-generic.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/dwc3/dwc3-generic.c b/drivers/usb/dwc3/dwc3-generic.c
index 6e1a1d066b4..c5310e465cb 100644
--- a/drivers/usb/dwc3/dwc3-generic.c
+++ b/drivers/usb/dwc3/dwc3-generic.c
@@ -468,9 +468,11 @@ static int dwc3_glue_probe(struct udevice *dev)
ret = generic_phy_init();
if (ret)
return ret;
- } else if (ret != -ENOENT) {
+ } else if (ret != -ENOENT && ret != -ENODATA) {
debug("could not get phy (err %d)\n", ret);
return ret;
+ } else {
+ phy.dev = NULL;
}
glue->regs = dev_read_addr(dev);
--
2.34.1
Re: [PATCH] net: marvell: mvgbe: Set PHY page 0 before phy_connect
Hi Tony,
On 4/25/22 11:33, Tony Dinh wrote:
Hi Stefan,
On Sun, Apr 24, 2022 at 11:00 PM Stefan Roese wrote:
Hi Tony,
On 4/23/22 04:15, Tony Dinh wrote:
Hi Stefan,
Please see my various comments below. And my thoughts at the end.
On Thu, Apr 21, 2022 at 11:15 PM Stefan Roese wrote:
Hi Tony,
On 4/21/22 23:21, Tony Dinh wrote:
What really puzzles me is, why the page address is set to a non-zero
value at all at this early boot stage? Could you perhaps add some
debugging code, to check, if and where the page address gets set?
I find it hard to belief, that this starts with non-zero after
powering up the device / PHY.
Or did I miss something?
Other Kirkwood boards behave correctly (such as the Sheevaplug,
Dreamplug, and Dell Kace M300). The Page Select register (22) contains
0 in these boards, and all have PHY id 1410e90. The NSA310s also has
PHY id 1410e90.
Yes. I'm pretty sure that the page select register is set to 0 upon
PHY startup. Even though there might be some strapping possibilities
to configure some PHY registers, the page select is most likely always
0 after power-up. So if nobody writes to this reg, then is should be 0.
Agree. All other Kirkwood boards execute the same code so I think we
would see if somebody writes to this register.
But I could not find in the uclass MVGBE where the Page Select
register is set before phy_connect is called. So my guess is that
memory location just happens to be zero in other boards but not in
this NSA310S board. Perhaps the memory location needs to be set to
zero, to make sure all registers point to page 0 in the beginning.
Please see above.
Possibly, it is here that the Page Select register should be zero out
after the priv data is copied: dev_get_priv(). mvgbe_of_to_plat() is
called very early on (during the uclass MVGBE creation).
static int mvgbe_of_to_plat(struct udevice *dev)
{
struct eth_pdata *pdata = dev_get_plat(dev);
struct mvgbe_device *dmvgbe = dev_get_priv(dev);
Possibly. Again my suggestion is to add some debug code to check at
different boot times, which value is currently set in the page select
register. By just reading is out and printing it's value. You might need
to add some "special code" at the early code paths, as the MDIO driver
is not started there.
Another idea is, if it's possible to issue a HW-reset to the PHY on the
NSA310 board. Do you know if some GPIO is connected to the PHY's reset
pin which could be toggled by the SoC?
I don't think there is a GPIO that does. I looked at the GPL source
code for this board from way back, and created the DTS for this based
on info in that GPL source. I don't recall that it was available.
Note: We could of course just add the reset to 0 as you have done in the
MAC driver or some board specific code. But I really would like to
understand why the page select reg is non-zero in this case.
My conclusion is the register was polluted by something in the board
hardware. This is the comments (paraphrase) we got from this board
GPL source:
/* The ZyXEL NSA310S uses the 88E1310S Alaska (interface
identical to 88E1318) */
/* and has an MCU attached to the LED[2] via tristate interrupt */
I've rebuilt and rerun the tests for both the Sheevaplug and NSA310S.
Please see the debug log from mvgbe_probe. This is as early as we can
see the uclass initializing.
NSA310S boot log
U-Boot 2022.04-00569-gca51a8dc04-dirty (Apr 22 2022 - 16:49:50 -0700)
ZyXEL NSA310S/320S 1/2-Bay Power Media Server
SoC: Kirkwood 88F6281_A1
DRAM: 256 MiB
Core: 7 devices, 5 uclasses, devicetree: separate
NAND: 128 MiB
Loading Environment from NAND... OK
In:serial
Out: serial
Err: serial
Net: mvgbe_of_to_plat called
mvgbe_of_to_plat phy-mode 7
mvgbe_of_to_plat phy addr 1
mvgbe_probe called
smi_reg_read: phy_addr 1 reg_ofs 22 devad -1
__mvgbe_mdio_read:(adr 1, off 22) value= 0011
eth0: ethernet-controller@72000
Hit any key to stop autoboot: 0
= Sheevaplug boot log
U-Boot 2022.04-00569-gca51a8dc04-dirty (Apr 22 2022 - 18:16:25 -0700)
Marvell-Sheevaplug
SoC: Kirkwood 88F6281_A1
DRAM: 512 MiB
Core: 9 devices, 7 uclasses, devicetree: separate
NAND: 512 MiB
MMC: mvsdio@9: 0
Loading Environment from NAND... OK
In:serial
Out: serial
Err: serial
Net: mvgbe_of_to_plat called
mvgbe_of_to_plat phy-mode 1
mvgbe_of_to_plat phy addr 0
mvgbe_probe called
smi_reg_read: phy_addr 0 reg_ofs 22 devad -1
__mvgbe_mdio_read:(adr 0, off 22) value=
eth0: ethernet-controller@72000
Hit any key to stop autoboot: 0
Still very strange. Perhaps really some HW pin strapping responsible
for this difference?
It could be. The Zyxel Kirkwood NAS series NSA310s, 320, and 325 all
behave like this. The Sheevaplug and Dreamplug don't have this
behavior, while using the same network chip (I've confirmed that the
detected PHY id is the same, it is 1410e90).
My thoughts:
I think we probably need to refactor some constants in the uclass
[PATCH] crypto/fsl: fsl_rsa: Fix dcache issue in the driver
From: Ye Li
issue:
CAAM fails with key error when perform Modular Exponentiation
using PKHA Block in CAAM
Fix:
add flush and invalidate dcache for keys, signature
and output decrypted data processed by CAAM.
Fixes: 34276478f7 (DM: crypto/fsl - Add Freescale rsa DM driver)
Signed-off-by: Ye Li
Reviewed-by: Gaurav Jain
Acked-by: Peng Fan
---
drivers/crypto/fsl/fsl_rsa.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/crypto/fsl/fsl_rsa.c b/drivers/crypto/fsl/fsl_rsa.c
index 897ee855ea..7ea0c193f9 100644
--- a/drivers/crypto/fsl/fsl_rsa.c
+++ b/drivers/crypto/fsl/fsl_rsa.c
@@ -36,12 +36,21 @@ int fsl_mod_exp(struct udevice *dev, const uint8_t *sig,
uint32_t sig_len,
inline_cnstr_jobdesc_pkha_rsaexp(desc, , out, sig_len);
+ flush_dcache_range((ulong)sig, (ulong)(sig + sig_len));
+ flush_dcache_range((ulong)prop->modulus, (ulong)(prop->modulus) +
keylen);
+ flush_dcache_range((ulong)prop->public_exponent,
+ (ulong)(prop->public_exponent) + prop->exp_len);
+ flush_dcache_range((ulong)desc, (ulong)desc + (sizeof(uint32_t) *
MAX_CAAM_DESCSIZE));
+ flush_dcache_range((ulong)out, (ulong)out + sig_len);
+
ret = run_descriptor_jr(desc);
if (ret) {
debug("%s: RSA failed to verify: %d\n", __func__, ret);
return -EFAULT;
}
+ invalidate_dcache_range((ulong)out, (ulong)sig_len);
+
return 0;
}
--
2.25.1
Re: [PATCH v3 2/2] usb: dwc3: Add support for usb3-phy PHY configuration
On 25.04.22 12:09, Jan Kiszka wrote:
> On 25.04.22 12:06, Michal Simek wrote:
>>
>>
>> On 4/25/22 12:05, Jan Kiszka wrote:
>>> On 25.04.22 11:56, Michal Simek wrote:
Hi Jan,
On 4/25/22 11:47, Jan Kiszka wrote:
> On 09.03.22 10:05, Michal Simek wrote:
>> When usb3-phy label is found, PHY driver is called and serdes line is
>> initialized. This is preparation for serdes/psgtr driver to
>> configure GT
>> lines based on description in DT.
>>
>> Signed-off-by: Michal Simek
>> ---
>>
>> Changes in v3:
>> - Add cover letter
>>
>> Changes in v2:
>> - Add missing header
>>
>> drivers/usb/dwc3/dwc3-generic.c | 18 ++
>> 1 file changed, 18 insertions(+)
>>
>> diff --git a/drivers/usb/dwc3/dwc3-generic.c
>> b/drivers/usb/dwc3/dwc3-generic.c
>> index 01bd0ca190e3..2c5205df62cd 100644
>> --- a/drivers/usb/dwc3/dwc3-generic.c
>> +++ b/drivers/usb/dwc3/dwc3-generic.c
>> @@ -14,6 +14,7 @@
>> #include
>> #include
>> #include
>> +#include
>> #include
>> #include
>> #include
>> @@ -409,6 +410,17 @@ static int dwc3_glue_probe(struct udevice *dev)
>> struct udevice *child = NULL;
>> int index = 0;
>> int ret;
>> + struct phy phy;
>> +
>> + ret = generic_phy_get_by_name(dev, "usb3-phy", );
>> + if (!ret) {
>> + ret = generic_phy_init();
>> + if (ret)
>> + return ret;
>> + } else if (ret != -ENOENT) {
>> + debug("could not get phy (err %d)\n", ret);
>> + return ret;
>> + }
>> glue->regs = dev_read_addr(dev);
>> @@ -420,6 +432,12 @@ static int dwc3_glue_probe(struct udevice
>> *dev)
>> if (ret)
>> return ret;
>> + if (phy.dev) {
>> + ret = generic_phy_power_on();
>> + if (ret)
>> + return ret;
>> + }
>> +
>> ret = device_find_first_child(dev, );
>> if (ret)
>> return ret;
>
> Breaks USB on the iot2050-pg1 (am65x) - this one has NO usb3-phy:
>
> ...
> starting USB...
> Bus usb@1: probe failed, error -61
> Bus usb@1: probe failed, error -61
> No working controllers found
> USB is stopped. Please issue 'usb start' first.
> starting USB...
> Bus usb@1: probe failed, error -61
> Bus usb@1: probe failed, error -61
> No working controllers found
> USB is stopped. Please issue 'usb start' first.
> starting USB...
> Bus usb@1: probe failed, error -61
> Bus usb@1: probe failed, error -61
> No working controllers found
> USB is stopped. Please issue 'usb start' first.
>
> Is there anything that boards need to consider now?
-61 is ENODATA. I have looked at DT and there is no usb3-phy property.
That's why generic_phy_get_by_name() can't return 0. Does it return
-ENOENT?
Maybe it returns ENODATA and it should be also handled in else part.
Can you please enable debug and see?
>>>
>>> #define DEBUG in the patched file or where?
>>
>> yes above of headers in this file is enough.
>>
>> M
>
> starting USB...
> Bus usb@1: could not get phy (err -61)
> probe failed, error -61
> Bus usb@1: could not get phy (err -61)
> probe failed, error -61
> No working controllers found
>
You need the -ENODATA check as well, see e.g.
drivers/usb/dwc3/dwc3-meson-g12a.c.
Jan
--
Siemens AG, Technology
Competence Center Embedded Linux
Re: [PATCH v3 2/2] usb: dwc3: Add support for usb3-phy PHY configuration
On 25.04.22 12:06, Michal Simek wrote:
>
>
> On 4/25/22 12:05, Jan Kiszka wrote:
>> On 25.04.22 11:56, Michal Simek wrote:
>>> Hi Jan,
>>>
>>> On 4/25/22 11:47, Jan Kiszka wrote:
On 09.03.22 10:05, Michal Simek wrote:
> When usb3-phy label is found, PHY driver is called and serdes line is
> initialized. This is preparation for serdes/psgtr driver to
> configure GT
> lines based on description in DT.
>
> Signed-off-by: Michal Simek
> ---
>
> Changes in v3:
> - Add cover letter
>
> Changes in v2:
> - Add missing header
>
> drivers/usb/dwc3/dwc3-generic.c | 18 ++
> 1 file changed, 18 insertions(+)
>
> diff --git a/drivers/usb/dwc3/dwc3-generic.c
> b/drivers/usb/dwc3/dwc3-generic.c
> index 01bd0ca190e3..2c5205df62cd 100644
> --- a/drivers/usb/dwc3/dwc3-generic.c
> +++ b/drivers/usb/dwc3/dwc3-generic.c
> @@ -14,6 +14,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -409,6 +410,17 @@ static int dwc3_glue_probe(struct udevice *dev)
> struct udevice *child = NULL;
> int index = 0;
> int ret;
> + struct phy phy;
> +
> + ret = generic_phy_get_by_name(dev, "usb3-phy", );
> + if (!ret) {
> + ret = generic_phy_init();
> + if (ret)
> + return ret;
> + } else if (ret != -ENOENT) {
> + debug("could not get phy (err %d)\n", ret);
> + return ret;
> + }
> glue->regs = dev_read_addr(dev);
> @@ -420,6 +432,12 @@ static int dwc3_glue_probe(struct udevice
> *dev)
> if (ret)
> return ret;
> + if (phy.dev) {
> + ret = generic_phy_power_on();
> + if (ret)
> + return ret;
> + }
> +
> ret = device_find_first_child(dev, );
> if (ret)
> return ret;
Breaks USB on the iot2050-pg1 (am65x) - this one has NO usb3-phy:
...
starting USB...
Bus usb@1: probe failed, error -61
Bus usb@1: probe failed, error -61
No working controllers found
USB is stopped. Please issue 'usb start' first.
starting USB...
Bus usb@1: probe failed, error -61
Bus usb@1: probe failed, error -61
No working controllers found
USB is stopped. Please issue 'usb start' first.
starting USB...
Bus usb@1: probe failed, error -61
Bus usb@1: probe failed, error -61
No working controllers found
USB is stopped. Please issue 'usb start' first.
Is there anything that boards need to consider now?
>>>
>>> -61 is ENODATA. I have looked at DT and there is no usb3-phy property.
>>> That's why generic_phy_get_by_name() can't return 0. Does it return
>>> -ENOENT?
>>>
>>> Maybe it returns ENODATA and it should be also handled in else part.
>>>
>>> Can you please enable debug and see?
>>>
>>
>> #define DEBUG in the patched file or where?
>
> yes above of headers in this file is enough.
>
> M
starting USB...
Bus usb@1: could not get phy (err -61)
probe failed, error -61
Bus usb@1: could not get phy (err -61)
probe failed, error -61
No working controllers found
Jan
--
Siemens AG, Technology
Competence Center Embedded Linux
Re: [PATCH v3 2/2] usb: dwc3: Add support for usb3-phy PHY configuration
On 4/25/22 12:05, Jan Kiszka wrote:
On 25.04.22 11:56, Michal Simek wrote:
Hi Jan,
On 4/25/22 11:47, Jan Kiszka wrote:
On 09.03.22 10:05, Michal Simek wrote:
When usb3-phy label is found, PHY driver is called and serdes line is
initialized. This is preparation for serdes/psgtr driver to configure GT
lines based on description in DT.
Signed-off-by: Michal Simek
---
Changes in v3:
- Add cover letter
Changes in v2:
- Add missing header
drivers/usb/dwc3/dwc3-generic.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/usb/dwc3/dwc3-generic.c
b/drivers/usb/dwc3/dwc3-generic.c
index 01bd0ca190e3..2c5205df62cd 100644
--- a/drivers/usb/dwc3/dwc3-generic.c
+++ b/drivers/usb/dwc3/dwc3-generic.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -409,6 +410,17 @@ static int dwc3_glue_probe(struct udevice *dev)
struct udevice *child = NULL;
int index = 0;
int ret;
+ struct phy phy;
+
+ ret = generic_phy_get_by_name(dev, "usb3-phy", );
+ if (!ret) {
+ ret = generic_phy_init();
+ if (ret)
+ return ret;
+ } else if (ret != -ENOENT) {
+ debug("could not get phy (err %d)\n", ret);
+ return ret;
+ }
glue->regs = dev_read_addr(dev);
@@ -420,6 +432,12 @@ static int dwc3_glue_probe(struct udevice *dev)
if (ret)
return ret;
+ if (phy.dev) {
+ ret = generic_phy_power_on();
+ if (ret)
+ return ret;
+ }
+
ret = device_find_first_child(dev, );
if (ret)
return ret;
Breaks USB on the iot2050-pg1 (am65x) - this one has NO usb3-phy:
...
starting USB...
Bus usb@1: probe failed, error -61
Bus usb@1: probe failed, error -61
No working controllers found
USB is stopped. Please issue 'usb start' first.
starting USB...
Bus usb@1: probe failed, error -61
Bus usb@1: probe failed, error -61
No working controllers found
USB is stopped. Please issue 'usb start' first.
starting USB...
Bus usb@1: probe failed, error -61
Bus usb@1: probe failed, error -61
No working controllers found
USB is stopped. Please issue 'usb start' first.
Is there anything that boards need to consider now?
-61 is ENODATA. I have looked at DT and there is no usb3-phy property.
That's why generic_phy_get_by_name() can't return 0. Does it return
-ENOENT?
Maybe it returns ENODATA and it should be also handled in else part.
Can you please enable debug and see?
#define DEBUG in the patched file or where?
yes above of headers in this file is enough.
M
Re: [PATCH v3 2/2] usb: dwc3: Add support for usb3-phy PHY configuration
On 25.04.22 11:56, Michal Simek wrote:
> Hi Jan,
>
> On 4/25/22 11:47, Jan Kiszka wrote:
>> On 09.03.22 10:05, Michal Simek wrote:
>>> When usb3-phy label is found, PHY driver is called and serdes line is
>>> initialized. This is preparation for serdes/psgtr driver to configure GT
>>> lines based on description in DT.
>>>
>>> Signed-off-by: Michal Simek
>>> ---
>>>
>>> Changes in v3:
>>> - Add cover letter
>>>
>>> Changes in v2:
>>> - Add missing header
>>>
>>> drivers/usb/dwc3/dwc3-generic.c | 18 ++
>>> 1 file changed, 18 insertions(+)
>>>
>>> diff --git a/drivers/usb/dwc3/dwc3-generic.c
>>> b/drivers/usb/dwc3/dwc3-generic.c
>>> index 01bd0ca190e3..2c5205df62cd 100644
>>> --- a/drivers/usb/dwc3/dwc3-generic.c
>>> +++ b/drivers/usb/dwc3/dwc3-generic.c
>>> @@ -14,6 +14,7 @@
>>> #include
>>> #include
>>> #include
>>> +#include
>>> #include
>>> #include
>>> #include
>>> @@ -409,6 +410,17 @@ static int dwc3_glue_probe(struct udevice *dev)
>>> struct udevice *child = NULL;
>>> int index = 0;
>>> int ret;
>>> + struct phy phy;
>>> +
>>> + ret = generic_phy_get_by_name(dev, "usb3-phy", );
>>> + if (!ret) {
>>> + ret = generic_phy_init();
>>> + if (ret)
>>> + return ret;
>>> + } else if (ret != -ENOENT) {
>>> + debug("could not get phy (err %d)\n", ret);
>>> + return ret;
>>> + }
>>> glue->regs = dev_read_addr(dev);
>>> @@ -420,6 +432,12 @@ static int dwc3_glue_probe(struct udevice *dev)
>>> if (ret)
>>> return ret;
>>> + if (phy.dev) {
>>> + ret = generic_phy_power_on();
>>> + if (ret)
>>> + return ret;
>>> + }
>>> +
>>> ret = device_find_first_child(dev, );
>>> if (ret)
>>> return ret;
>>
>> Breaks USB on the iot2050-pg1 (am65x) - this one has NO usb3-phy:
>>
>> ...
>> starting USB...
>> Bus usb@1: probe failed, error -61
>> Bus usb@1: probe failed, error -61
>> No working controllers found
>> USB is stopped. Please issue 'usb start' first.
>> starting USB...
>> Bus usb@1: probe failed, error -61
>> Bus usb@1: probe failed, error -61
>> No working controllers found
>> USB is stopped. Please issue 'usb start' first.
>> starting USB...
>> Bus usb@1: probe failed, error -61
>> Bus usb@1: probe failed, error -61
>> No working controllers found
>> USB is stopped. Please issue 'usb start' first.
>>
>> Is there anything that boards need to consider now?
>
> -61 is ENODATA. I have looked at DT and there is no usb3-phy property.
> That's why generic_phy_get_by_name() can't return 0. Does it return
> -ENOENT?
>
> Maybe it returns ENODATA and it should be also handled in else part.
>
> Can you please enable debug and see?
>
#define DEBUG in the patched file or where?
Jan
--
Siemens AG, Technology
Competence Center Embedded Linux
Re: [PATCH v3 2/2] usb: dwc3: Add support for usb3-phy PHY configuration
Hi Jan,
On 4/25/22 11:47, Jan Kiszka wrote:
On 09.03.22 10:05, Michal Simek wrote:
When usb3-phy label is found, PHY driver is called and serdes line is
initialized. This is preparation for serdes/psgtr driver to configure GT
lines based on description in DT.
Signed-off-by: Michal Simek
---
Changes in v3:
- Add cover letter
Changes in v2:
- Add missing header
drivers/usb/dwc3/dwc3-generic.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/usb/dwc3/dwc3-generic.c b/drivers/usb/dwc3/dwc3-generic.c
index 01bd0ca190e3..2c5205df62cd 100644
--- a/drivers/usb/dwc3/dwc3-generic.c
+++ b/drivers/usb/dwc3/dwc3-generic.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -409,6 +410,17 @@ static int dwc3_glue_probe(struct udevice *dev)
struct udevice *child = NULL;
int index = 0;
int ret;
+ struct phy phy;
+
+ ret = generic_phy_get_by_name(dev, "usb3-phy", );
+ if (!ret) {
+ ret = generic_phy_init();
+ if (ret)
+ return ret;
+ } else if (ret != -ENOENT) {
+ debug("could not get phy (err %d)\n", ret);
+ return ret;
+ }
glue->regs = dev_read_addr(dev);
@@ -420,6 +432,12 @@ static int dwc3_glue_probe(struct udevice *dev)
if (ret)
return ret;
+ if (phy.dev) {
+ ret = generic_phy_power_on();
+ if (ret)
+ return ret;
+ }
+
ret = device_find_first_child(dev, );
if (ret)
return ret;
Breaks USB on the iot2050-pg1 (am65x) - this one has NO usb3-phy:
...
starting USB...
Bus usb@1: probe failed, error -61
Bus usb@1: probe failed, error -61
No working controllers found
USB is stopped. Please issue 'usb start' first.
starting USB...
Bus usb@1: probe failed, error -61
Bus usb@1: probe failed, error -61
No working controllers found
USB is stopped. Please issue 'usb start' first.
starting USB...
Bus usb@1: probe failed, error -61
Bus usb@1: probe failed, error -61
No working controllers found
USB is stopped. Please issue 'usb start' first.
Is there anything that boards need to consider now?
-61 is ENODATA. I have looked at DT and there is no usb3-phy property. That's
why generic_phy_get_by_name() can't return 0. Does it return -ENOENT?
Maybe it returns ENODATA and it should be also handled in else part.
Can you please enable debug and see?
Thanks,
Michal
Re: [PATCH v3 2/2] usb: dwc3: Add support for usb3-phy PHY configuration
On 09.03.22 10:05, Michal Simek wrote:
> When usb3-phy label is found, PHY driver is called and serdes line is
> initialized. This is preparation for serdes/psgtr driver to configure GT
> lines based on description in DT.
>
> Signed-off-by: Michal Simek
> ---
>
> Changes in v3:
> - Add cover letter
>
> Changes in v2:
> - Add missing header
>
> drivers/usb/dwc3/dwc3-generic.c | 18 ++
> 1 file changed, 18 insertions(+)
>
> diff --git a/drivers/usb/dwc3/dwc3-generic.c b/drivers/usb/dwc3/dwc3-generic.c
> index 01bd0ca190e3..2c5205df62cd 100644
> --- a/drivers/usb/dwc3/dwc3-generic.c
> +++ b/drivers/usb/dwc3/dwc3-generic.c
> @@ -14,6 +14,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -409,6 +410,17 @@ static int dwc3_glue_probe(struct udevice *dev)
> struct udevice *child = NULL;
> int index = 0;
> int ret;
> + struct phy phy;
> +
> + ret = generic_phy_get_by_name(dev, "usb3-phy", );
> + if (!ret) {
> + ret = generic_phy_init();
> + if (ret)
> + return ret;
> + } else if (ret != -ENOENT) {
> + debug("could not get phy (err %d)\n", ret);
> + return ret;
> + }
>
> glue->regs = dev_read_addr(dev);
>
> @@ -420,6 +432,12 @@ static int dwc3_glue_probe(struct udevice *dev)
> if (ret)
> return ret;
>
> + if (phy.dev) {
> + ret = generic_phy_power_on();
> + if (ret)
> + return ret;
> + }
> +
> ret = device_find_first_child(dev, );
> if (ret)
> return ret;
Breaks USB on the iot2050-pg1 (am65x) - this one has NO usb3-phy:
...
starting USB...
Bus usb@1: probe failed, error -61
Bus usb@1: probe failed, error -61
No working controllers found
USB is stopped. Please issue 'usb start' first.
starting USB...
Bus usb@1: probe failed, error -61
Bus usb@1: probe failed, error -61
No working controllers found
USB is stopped. Please issue 'usb start' first.
starting USB...
Bus usb@1: probe failed, error -61
Bus usb@1: probe failed, error -61
No working controllers found
USB is stopped. Please issue 'usb start' first.
Is there anything that boards need to consider now?
Jan
--
Siemens AG, Technology
Competence Center Embedded Linux
Re: [PATCH] net: marvell: mvgbe: Set PHY page 0 before phy_connect
Hi Stefan,
On Sun, Apr 24, 2022 at 11:00 PM Stefan Roese wrote:
>
> Hi Tony,
>
> On 4/23/22 04:15, Tony Dinh wrote:
> > Hi Stefan,
> >
> > Please see my various comments below. And my thoughts at the end.
> >
> > On Thu, Apr 21, 2022 at 11:15 PM Stefan Roese wrote:
> >>
> >> Hi Tony,
> >>
> >> On 4/21/22 23:21, Tony Dinh wrote:
> >>
> >>
> >>
> What really puzzles me is, why the page address is set to a non-zero
> value at all at this early boot stage? Could you perhaps add some
> debugging code, to check, if and where the page address gets set?
> I find it hard to belief, that this starts with non-zero after
> powering up the device / PHY.
>
> Or did I miss something?
> >>>
> >>> Other Kirkwood boards behave correctly (such as the Sheevaplug,
> >>> Dreamplug, and Dell Kace M300). The Page Select register (22) contains
> >>> 0 in these boards, and all have PHY id 1410e90. The NSA310s also has
> >>> PHY id 1410e90.
> >>
> >> Yes. I'm pretty sure that the page select register is set to 0 upon
> >> PHY startup. Even though there might be some strapping possibilities
> >> to configure some PHY registers, the page select is most likely always
> >> 0 after power-up. So if nobody writes to this reg, then is should be 0.
> >
> > Agree. All other Kirkwood boards execute the same code so I think we
> > would see if somebody writes to this register.
> >
> >>> But I could not find in the uclass MVGBE where the Page Select
> >>> register is set before phy_connect is called. So my guess is that
> >>> memory location just happens to be zero in other boards but not in
> >>> this NSA310S board. Perhaps the memory location needs to be set to
> >>> zero, to make sure all registers point to page 0 in the beginning.
> >>
> >> Please see above.
> >>
> >>> Possibly, it is here that the Page Select register should be zero out
> >>> after the priv data is copied: dev_get_priv(). mvgbe_of_to_plat() is
> >>> called very early on (during the uclass MVGBE creation).
> >>>
> >>> static int mvgbe_of_to_plat(struct udevice *dev)
> >>> {
> >>> struct eth_pdata *pdata = dev_get_plat(dev);
> >>> struct mvgbe_device *dmvgbe = dev_get_priv(dev);
> >>
> >> Possibly. Again my suggestion is to add some debug code to check at
> >> different boot times, which value is currently set in the page select
> >> register. By just reading is out and printing it's value. You might need
> >> to add some "special code" at the early code paths, as the MDIO driver
> >> is not started there.
> >>
> >> Another idea is, if it's possible to issue a HW-reset to the PHY on the
> >> NSA310 board. Do you know if some GPIO is connected to the PHY's reset
> >> pin which could be toggled by the SoC?
> >
> > I don't think there is a GPIO that does. I looked at the GPL source
> > code for this board from way back, and created the DTS for this based
> > on info in that GPL source. I don't recall that it was available.
> >
> >> Note: We could of course just add the reset to 0 as you have done in the
> >> MAC driver or some board specific code. But I really would like to
> >> understand why the page select reg is non-zero in this case.
> >
> > My conclusion is the register was polluted by something in the board
> > hardware. This is the comments (paraphrase) we got from this board
> > GPL source:
> > /* The ZyXEL NSA310S uses the 88E1310S Alaska (interface
> > identical to 88E1318) */
> > /* and has an MCU attached to the LED[2] via tristate interrupt */
> >
> > I've rebuilt and rerun the tests for both the Sheevaplug and NSA310S.
> > Please see the debug log from mvgbe_probe. This is as early as we can
> > see the uclass initializing.
> >
> > NSA310S boot log
> > U-Boot 2022.04-00569-gca51a8dc04-dirty (Apr 22 2022 - 16:49:50 -0700)
> > ZyXEL NSA310S/320S 1/2-Bay Power Media Server
> >
> > SoC: Kirkwood 88F6281_A1
> > DRAM: 256 MiB
> > Core: 7 devices, 5 uclasses, devicetree: separate
> > NAND: 128 MiB
> > Loading Environment from NAND... OK
> > In:serial
> > Out: serial
> > Err: serial
> >
> > Net: mvgbe_of_to_plat called
> > mvgbe_of_to_plat phy-mode 7
> > mvgbe_of_to_plat phy addr 1
> > mvgbe_probe called
> > smi_reg_read: phy_addr 1 reg_ofs 22 devad -1
> > __mvgbe_mdio_read:(adr 1, off 22) value= 0011
> > eth0: ethernet-controller@72000
> > Hit any key to stop autoboot: 0
> >
> > = Sheevaplug boot log
> >
> > U-Boot 2022.04-00569-gca51a8dc04-dirty (Apr 22 2022 - 18:16:25 -0700)
> > Marvell-Sheevaplug
> >
> > SoC: Kirkwood 88F6281_A1
> > DRAM: 512 MiB
> > Core: 9 devices, 7 uclasses, devicetree: separate
> > NAND: 512 MiB
> > MMC: mvsdio@9: 0
> > Loading Environment from NAND... OK
> > In:serial
> > Out: serial
> > Err: serial
> >
> > Net: mvgbe_of_to_plat called
> > mvgbe_of_to_plat phy-mode 1
> > mvgbe_of_to_plat phy addr 0
> > mvgbe_probe called
> > smi_reg_read: phy_addr 0 reg_ofs 22 devad -1
> > __mvgbe_mdio_read:(adr 0, off 22) value=
> > eth0:
[PATCH] env: Couple networking-related variable flags to CONFIG_NET
From: Jan Kiszka
Boards may set networking variables programmatically, thus may have
CONFIG_NET on but CONFIG_CMD_NET off. The IOT2050 is an example.
Signed-off-by: Jan Kiszka
---
env/flags.c | 10 +-
include/env_flags.h | 4 ++--
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/env/flags.c b/env/flags.c
index e3e833c4333..e2866361dfe 100644
--- a/env/flags.c
+++ b/env/flags.c
@@ -22,7 +22,7 @@
#include
#endif
-#ifdef CONFIG_CMD_NET
+#ifdef CONFIG_NET
#define ENV_FLAGS_NET_VARTYPE_REPS "im"
#else
#define ENV_FLAGS_NET_VARTYPE_REPS ""
@@ -57,7 +57,7 @@ static const char * const env_flags_vartype_names[] = {
"decimal",
"hexadecimal",
"boolean",
-#ifdef CONFIG_CMD_NET
+#ifdef CONFIG_NET
"IP address",
"MAC address",
#endif
@@ -211,7 +211,7 @@ static void skip_num(int hex, const char *value,
const char **end,
*end = value;
}
-#ifdef CONFIG_CMD_NET
+#ifdef CONFIG_NET
int eth_validate_ethaddr_str(const char *addr)
{
const char *end;
@@ -244,7 +244,7 @@ static int _env_flags_validate_type(const char *value,
enum env_flags_vartype type)
{
const char *end;
-#ifdef CONFIG_CMD_NET
+#ifdef CONFIG_NET
const char *cur;
int i;
#endif
@@ -273,7 +273,7 @@ static int _env_flags_validate_type(const char *value,
if (value[1] != '\0')
return -1;
break;
-#ifdef CONFIG_CMD_NET
+#ifdef CONFIG_NET
case env_flags_vartype_ipaddr:
cur = value;
for (i = 0; i < 4; i++) {
diff --git a/include/env_flags.h b/include/env_flags.h
index 313cb8c49a6..b49ec8e80f1 100644
--- a/include/env_flags.h
+++ b/include/env_flags.h
@@ -12,7 +12,7 @@ enum env_flags_vartype {
env_flags_vartype_decimal,
env_flags_vartype_hex,
env_flags_vartype_bool,
-#ifdef CONFIG_CMD_NET
+#ifdef CONFIG_NET
env_flags_vartype_ipaddr,
env_flags_vartype_macaddr,
#endif
@@ -111,7 +111,7 @@ enum env_flags_varaccess
env_flags_parse_varaccess(const char *flags);
*/
enum env_flags_varaccess env_flags_parse_varaccess_from_binflags(int
binflags);
-#ifdef CONFIG_CMD_NET
+#ifdef CONFIG_NET
/*
* Check if a string has the format of an Ethernet MAC address
*/
--
2.34.1
[PATCH] efi_loader: Improve console screen clearing and reset
From: Jan Kiszka
Ensure that the default colors are set when clearing the screen so that
the background is properly filled and succeeding colored outputs will
have no differently colored trail.
Before clearing, ensure that no previous output of firmware or UEFI
programs will overwritten on serial devices or other streaming consoles.
This helps generating complete boot logs.
Signed-off-by: Jan Kiszka
---
lib/efi_loader/efi_console.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/lib/efi_loader/efi_console.c b/lib/efi_loader/efi_console.c
index ba68a150172..0270b20bafe 100644
--- a/lib/efi_loader/efi_console.c
+++ b/lib/efi_loader/efi_console.c
@@ -463,8 +463,18 @@ static efi_status_t EFIAPI efi_cout_set_attribute(
static efi_status_t EFIAPI efi_cout_clear_screen(
struct efi_simple_text_output_protocol *this)
{
+ unsigned int row;
+
EFI_ENTRY("%p", this);
+ /* Avoid overwriting previous outputs on streaming consoles */
+ for (row = 1; row < efi_cout_modes[efi_con_mode.mode].rows; row++)
+ printf("\n");
+
+ /* Set default colors if not done yet */
+ if (efi_con_mode.attribute == 0)
+ efi_cout_set_attribute(this, 0x07);
+
/*
* The Linux console wants both a clear and a home command. The video
* uclass does not support [H without coordinates, yet.
@@ -522,11 +532,11 @@ static efi_status_t EFIAPI efi_cout_reset(
{
EFI_ENTRY("%p, %d", this, extended_verification);
+ /* Trigger reset to default colors */
+ efi_con_mode.attribute = 0;
+
/* Clear screen */
EFI_CALL(efi_cout_clear_screen(this));
- /* Set default colors */
- efi_con_mode.attribute = 0x07;
- printf(ESC "[0;37;40m");
return EFI_EXIT(EFI_SUCCESS);
}
--
2.34.1
Re: Regression? [PATCH 1/2] mtd: call of_platform_populate() for MTD partitions
Hi Daniel,
dan...@makrotopia.org wrote on Mon, 25 Apr 2022 02:20:34 +0100:
> Hi Rafal,
> Hi Miguel,
>
>
> On Mon, Apr 11, 2022 at 11:00:32AM +0200, Miquel Raynal wrote:
> > On Wed, 2022-04-06 at 14:32:24 UTC, =?utf-8?b?UmFmYcWCIE1pxYJlY2tp?= wrote:
> >
> > > From: Rafał Miłecki
> > >
> > > Until this change MTD subsystem supported handling partitions only with
> > > MTD partitions parsers. That's a specific / limited API designed around
> > > partitions.
> > >
> > > Some MTD partitions may however require different handling. They may
> > > contain specific data that needs to be parsed and somehow extracted. For
> > > that purpose MTD subsystem should allow binding of standard platform
> > > drivers.
> > >
> > > An example can be U-Boot (sub)partition with environment variables.
> > > There exist a "u-boot,env" DT binding for MTD (sub)partition that
> > > requires an NVMEM driver.
> > >
> > > Ref: 5db1c2dbc04c ("dt-bindings: nvmem: add U-Boot environment variables
> > > binding")
> > > Signed-off-by: Rafał Miłecki
> >
> > Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git
> > mtd/next, thanks.
>
> I'm trying to use next-20220422 and noticed a few new oops'es.
> Turns out it could be a problem with this commit according to
>
> [daniel@box linux.git]$ git bisect good
> 68471517e883902cdff6ea399d043b17f803b1a8 is the first bad commit
> commit 68471517e883902cdff6ea399d043b17f803b1a8
> Author: Rafał Miłecki
> Date: Wed Apr 6 16:32:24 2022 +0200
>
> mtd: call of_platform_populate() for MTD partitions
> [...]
> ---
>
> So when ever there is at least one 'compatible' node for any of the
> mtd partitions I get the oops messages below. It doesn't really matter
> what the compatible string is, "nvmem-cells" as well as "denx,fit"
> (used for OpenWrt mtdsplit not even present in linux-next, so just a
> dead hint in DTS) make the kernel to oops.
>
> Despite the messages being shown, both accessing MTD partitions and
> also eth0 MAC address populated via NVMEM seem to work without
> problems (at least looks like it on first sight).
>
> Find the full device tree here:
>
> https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/mediatek/dts/mt7622-ubnt-unifi-6-lr-ubootmod.dts
Even though these compatibles are not mainline, it feels like the
problem exists here as well. I'm dropping this change for now, let's
fix this first.
>
> ---
> [...]
> [0.549448] mtk-spi-nor 11014000.spi: IRQ not available.
> [0.556396] spi-nor spi0.0: w25q512jvq (65536 Kbytes)
> [0.933381] Freeing initrd memory: 2124K
> [0.941567] 7 fixed-partitions partitions found on MTD device spi0.0
> [0.947966] OF: Bad cell count for /spi@11014000/flash@0/partitions
> [0.954286] OF: Bad cell count for /spi@11014000/flash@0/partitions
> [0.960583] [ cut here ]
> [0.965192] kobject: '(null)' (97a89bbf): is not initialized, yet
> kobject_get() is being called.
> [0.974688] WARNING: CPU: 0 PID: 1 at kobject_get+0x68/0x94
> [0.980263] Modules linked in:
> [0.983313] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G S
> 5.18.0-rc1+ #0
> [0.991049] Hardware name: Ubiquiti UniFi 6 LR (U-Boot mod) (DT)
> [0.997046] pstate: 6005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> [1.004000] pc : kobject_get+0x68/0x94
> [1.007743] lr : kobject_get+0x68/0x94
> [1.011484] sp : ffc008bdb4a0
> [1.014789] x29: ffc008bdb4a0 x28: x27:
> ff8005c57810
> [1.021920] x26: ff8005c74a20 x25: x24:
> 0001
> [1.029050] x23: x22: x21:
>
> [1.036182] x20: ff8005c74a20 x19: ff8005c74a20 x18:
> ffc008ab9630
> [1.043312] x17: 6f6b20746579202c x16: 64657a696c616974 x15:
> 0074
> [1.050443] x14: 015c x13: 0074 x12:
> ffea
> [1.057574] x11: efff x10: efff x9 :
> ffc008b11630
> [1.064705] x8 : 00017fe8 x7 : c000efff x6 :
> 00057fa8
> [1.071835] x5 : 0fff x4 : x3 :
> ffc008bdb1c0
> [1.078966] x2 : x1 : ffc008ab9580 x0 :
> 005c
> [1.086097] Call trace:
> [1.088534] kobject_get+0x68/0x94
> [1.091930] device_add+0xa4/0x840
> [1.095328] of_device_add+0x4c/0x5c
> [1.098898] of_platform_device_create_pdata+0xb8/0xf0
> [1.104029] of_platform_bus_create+0x104/0x350
> [1.108552] of_platform_populate+0x54/0xe0
> [1.112728] parse_mtd_partitions+0x430/0x490
> [1.117080] mtd_device_parse_register+0x90/0x2b0
> [1.121777] spi_nor_probe+0x1f8/0x2b0
> [1.125521] spi_mem_probe+0x68/0xa0
> [1.129092] spi_probe+0x80/0xdc
> [1.132314] really_probe.part.0+0x98/0x280
> [1.136490] __driver_probe_device+0x94/0x140
> [1.140839]
Re: [PATCH v3 0/6] meson: add clk and adc support for JetHub D1 (j100)
Hi, On Sun, 24 Apr 2022 11:21:53 +0300, Vyacheslav Bocharov wrote: > Prepare to use ADC channel 1 in JetHub D1 (j100) to check the hardware > revision of the board. > > - add support for AXG in saradc driver > - add simple clk-ao driver for AXG (base is taken from g12a) > - enable saradc in dts and board config file > - fix typo in the g12a-clk-ao driver name > - move clk->id check to .request function for g12a-clk-ao driver > - remove unnecessary check (gate->reg == 0) in g12a-clk-ao driver > - enable saradc in dts/board config for JetHub D1 (j100) > > [...] Thanks, Applied to https://source.denx.de/u-boot/custodians/u-boot-amlogic (u-boot-amlogic-test) [1/6] clk: meson: add minimal driver for axg-ao clocks https://source.denx.de/u-boot/custodians/u-boot-amlogic/-/commit/dcccf730043197464f7bafdb1abcebcb7fd828b0 [2/6] clk: meson: fix driver name for g12a-ao clocks https://source.denx.de/u-boot/custodians/u-boot-amlogic/-/commit/4da098656228535539be40f76806ad6657b94407 [3/6] clk: meson: update driver for g12a-ao clocks https://source.denx.de/u-boot/custodians/u-boot-amlogic/-/commit/66a657b7c6082fe374c99d5b2a7e0d911091dbe4 [4/6] adc: meson-saradc: add AXG variant https://source.denx.de/u-boot/custodians/u-boot-amlogic/-/commit/8a4a73f466c1d2189aa5f8612f2f90ec9a727ea0 [5/6] board: amlogic: jethub j100: enable saradc in dts https://source.denx.de/u-boot/custodians/u-boot-amlogic/-/commit/ee8094f69646825d2c30b8bb9082e976f023f710 [6/6] board: amlogic: jethub j100: enable saradc in config https://source.denx.de/u-boot/custodians/u-boot-amlogic/-/commit/a718f5524d492fb5708e884cb1db21384f826c00 -- Neil
Re: [PATCH v3 6/6] board: amlogic: jethub j100: enable saradc in config
On 24/04/2022 10:21, Vyacheslav Bocharov wrote: Enable ADC in board config file Signed-off-by: Vyacheslav Bocharov Reviewed-by: Neil Armstrong --- configs/jethub_j100_defconfig | 5 + 1 file changed, 5 insertions(+) diff --git a/configs/jethub_j100_defconfig b/configs/jethub_j100_defconfig index 1c6db9f6a0..a30940bf1c 100644 --- a/configs/jethub_j100_defconfig +++ b/configs/jethub_j100_defconfig @@ -17,6 +17,7 @@ CONFIG_REMAKE_ELF=y CONFIG_OF_BOARD_SETUP=y # CONFIG_DISPLAY_CPUINFO is not set CONFIG_MISC_INIT_R=y +CONFIG_CMD_ADC=y # CONFIG_CMD_BDI is not set # CONFIG_CMD_IMI is not set CONFIG_CMD_EEPROM=y @@ -34,6 +35,10 @@ CONFIG_OF_CONTROL=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_DM_I2C=y CONFIG_SYS_I2C_MESON=y +CONFIG_ADC=y +CONFIG_SARADC_MESON=y +CONFIG_CLK=y +CONFIG_CLK_MESON_AXG=y CONFIG_MMC_MESON_GX=y CONFIG_MTD_UBI=y CONFIG_PHY_REALTEK=y Reviewed-by: Neil Armstrong
Re: [PATCH v3 5/6] board: amlogic: jethub j100: enable saradc in dts
On 24/04/2022 10:21, Vyacheslav Bocharov wrote:
Prepare to use ADC channel 1 to check the hardware revision of the board:
- add u-boot dts include with saradc node
Signed-off-by: Vyacheslav Bocharov
---
arch/arm/dts/meson-axg-jethome-jethub-j100-u-boot.dtsi | 10 ++
1 file changed, 10 insertions(+)
create mode 100644 arch/arm/dts/meson-axg-jethome-jethub-j100-u-boot.dtsi
diff --git a/arch/arm/dts/meson-axg-jethome-jethub-j100-u-boot.dtsi
b/arch/arm/dts/meson-axg-jethome-jethub-j100-u-boot.dtsi
new file mode 100644
index 00..3ecb233f8e
--- /dev/null
+++ b/arch/arm/dts/meson-axg-jethome-jethub-j100-u-boot.dtsi
@@ -0,0 +1,10 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2022 Vyacheslav Bocharov
+ * Author: Vyacheslav Bocharov
+ */
+
+ {
+ status = "okay";
+ vref-supply = <_ao18>;
+};
Reviewed-by: Neil Armstrong
Re: [PATCH v3 3/6] clk: meson: update driver for g12a-ao clocks
On 24/04/2022 10:21, Vyacheslav Bocharov wrote:
Update g12a-ao clk driver:
- move clk->id check to .request function
- remove unnecessary check (gate->reg == 0)
Signed-off-by: Vyacheslav Bocharov
---
drivers/clk/meson/g12a-ao.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/clk/meson/g12a-ao.c b/drivers/clk/meson/g12a-ao.c
index 17b11eb52a..1a855a6896 100644
--- a/drivers/clk/meson/g12a-ao.c
+++ b/drivers/clk/meson/g12a-ao.c
@@ -28,14 +28,8 @@ static int meson_set_gate(struct clk *clk, bool on)
struct meson_clk *priv = dev_get_priv(clk->dev);
struct meson_gate *gate;
- if (clk->id >= ARRAY_SIZE(gates))
- return -ENOENT;
-
gate = [clk->id];
- if (gate->reg == 0)
- return 0;
-
regmap_update_bits(priv->map, gate->reg,
BIT(gate->bit), on ? BIT(gate->bit) : 0);
@@ -63,9 +57,18 @@ static int meson_clk_probe(struct udevice *dev)
return 0;
}
+static int meson_clk_request(struct clk *clk)
+{
+ if (clk->id >= ARRAY_SIZE(gates))
+ return -ENOENT;
+
+ return 0;
+}
+
static struct clk_ops meson_clk_ops = {
.disable= meson_clk_disable,
.enable = meson_clk_enable,
+ .request= meson_clk_request,
};
static const struct udevice_id meson_clk_ids[] = {
Acked-by: Neil Armstrong
[PATCH v1] drivers: spi: spi-sunxi: Add Kconfig option for sun4i_spi_parse_pins
From: qianfan Zhao
spi-sunxi driver will init pins based on "pinctrl-0", but the
implementation is very limited.
Adding an Kconfig option if you really need this feature, or disable it
and config pinmux at board's board_init.
Signed-off-by: qianfan Zhao
---
drivers/spi/Kconfig | 10 ++
drivers/spi/spi-sunxi.c | 4
2 files changed, 14 insertions(+)
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index d07e9a28af..9c2fe96ac1 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -382,6 +382,16 @@ config SPI_SUNXI
Same controller driver can reuse in all Allwinner SoC variants.
+config SUNXI_SPI_PARSE_PINS
+ bool "Enable sun4i_spi_parse_pins feature"
+ depends on SPI_SUNXI
+ default y
+ help
+ Enable sun4i_spi_parse_pins support when spi driver probing.
+
+ The default pinmux configuration for SUN50I is SUN50I_GPC_SPI0(4),
+ and SUNXI_GPC_SPI0(3) for others.
+
config STM32_QSPI
bool "STM32F7 QSPI driver"
depends on STM32F4 || STM32F7 || ARCH_STM32MP
diff --git a/drivers/spi/spi-sunxi.c b/drivers/spi/spi-sunxi.c
index bc2f544e86..f48562a59b 100644
--- a/drivers/spi/spi-sunxi.c
+++ b/drivers/spi/spi-sunxi.c
@@ -180,6 +180,7 @@ static void sun4i_spi_set_cs(struct udevice *bus, u8 cs,
bool enable)
writel(reg, SPI_REG(priv, SPI_TCR));
}
+#if CONFIG_IS_ENABLED(SUNXI_SPI_PARSE_PINS)
static int sun4i_spi_parse_pins(struct udevice *dev)
{
const void *fdt = gd->fdt_blob;
@@ -259,6 +260,7 @@ static int sun4i_spi_parse_pins(struct udevice *dev)
}
return 0;
}
+#endif /* CONFIG_IS_ENABLED(SUNXI_SPI_PARSE_PINS) */
static inline int sun4i_spi_set_clock(struct udevice *dev, bool enable)
{
@@ -506,7 +508,9 @@ static int sun4i_spi_probe(struct udevice *bus)
return ret;
}
+#if CONFIG_IS_ENABLED(SUNXI_SPI_PARSE_PINS)
sun4i_spi_parse_pins(bus);
+#endif
priv->variant = plat->variant;
priv->base = plat->base;
--
2.25.1
Re: [PATCH] net: marvell: mvgbe: Set PHY page 0 before phy_connect
Hi Tony,
On 4/23/22 04:15, Tony Dinh wrote:
Hi Stefan,
Please see my various comments below. And my thoughts at the end.
On Thu, Apr 21, 2022 at 11:15 PM Stefan Roese wrote:
Hi Tony,
On 4/21/22 23:21, Tony Dinh wrote:
What really puzzles me is, why the page address is set to a non-zero
value at all at this early boot stage? Could you perhaps add some
debugging code, to check, if and where the page address gets set?
I find it hard to belief, that this starts with non-zero after
powering up the device / PHY.
Or did I miss something?
Other Kirkwood boards behave correctly (such as the Sheevaplug,
Dreamplug, and Dell Kace M300). The Page Select register (22) contains
0 in these boards, and all have PHY id 1410e90. The NSA310s also has
PHY id 1410e90.
Yes. I'm pretty sure that the page select register is set to 0 upon
PHY startup. Even though there might be some strapping possibilities
to configure some PHY registers, the page select is most likely always
0 after power-up. So if nobody writes to this reg, then is should be 0.
Agree. All other Kirkwood boards execute the same code so I think we
would see if somebody writes to this register.
But I could not find in the uclass MVGBE where the Page Select
register is set before phy_connect is called. So my guess is that
memory location just happens to be zero in other boards but not in
this NSA310S board. Perhaps the memory location needs to be set to
zero, to make sure all registers point to page 0 in the beginning.
Please see above.
Possibly, it is here that the Page Select register should be zero out
after the priv data is copied: dev_get_priv(). mvgbe_of_to_plat() is
called very early on (during the uclass MVGBE creation).
static int mvgbe_of_to_plat(struct udevice *dev)
{
struct eth_pdata *pdata = dev_get_plat(dev);
struct mvgbe_device *dmvgbe = dev_get_priv(dev);
Possibly. Again my suggestion is to add some debug code to check at
different boot times, which value is currently set in the page select
register. By just reading is out and printing it's value. You might need
to add some "special code" at the early code paths, as the MDIO driver
is not started there.
Another idea is, if it's possible to issue a HW-reset to the PHY on the
NSA310 board. Do you know if some GPIO is connected to the PHY's reset
pin which could be toggled by the SoC?
I don't think there is a GPIO that does. I looked at the GPL source
code for this board from way back, and created the DTS for this based
on info in that GPL source. I don't recall that it was available.
Note: We could of course just add the reset to 0 as you have done in the
MAC driver or some board specific code. But I really would like to
understand why the page select reg is non-zero in this case.
My conclusion is the register was polluted by something in the board
hardware. This is the comments (paraphrase) we got from this board
GPL source:
/* The ZyXEL NSA310S uses the 88E1310S Alaska (interface
identical to 88E1318) */
/* and has an MCU attached to the LED[2] via tristate interrupt */
I've rebuilt and rerun the tests for both the Sheevaplug and NSA310S.
Please see the debug log from mvgbe_probe. This is as early as we can
see the uclass initializing.
NSA310S boot log
U-Boot 2022.04-00569-gca51a8dc04-dirty (Apr 22 2022 - 16:49:50 -0700)
ZyXEL NSA310S/320S 1/2-Bay Power Media Server
SoC: Kirkwood 88F6281_A1
DRAM: 256 MiB
Core: 7 devices, 5 uclasses, devicetree: separate
NAND: 128 MiB
Loading Environment from NAND... OK
In:serial
Out: serial
Err: serial
Net: mvgbe_of_to_plat called
mvgbe_of_to_plat phy-mode 7
mvgbe_of_to_plat phy addr 1
mvgbe_probe called
smi_reg_read: phy_addr 1 reg_ofs 22 devad -1
__mvgbe_mdio_read:(adr 1, off 22) value= 0011
eth0: ethernet-controller@72000
Hit any key to stop autoboot: 0
= Sheevaplug boot log
U-Boot 2022.04-00569-gca51a8dc04-dirty (Apr 22 2022 - 18:16:25 -0700)
Marvell-Sheevaplug
SoC: Kirkwood 88F6281_A1
DRAM: 512 MiB
Core: 9 devices, 7 uclasses, devicetree: separate
NAND: 512 MiB
MMC: mvsdio@9: 0
Loading Environment from NAND... OK
In:serial
Out: serial
Err: serial
Net: mvgbe_of_to_plat called
mvgbe_of_to_plat phy-mode 1
mvgbe_of_to_plat phy addr 0
mvgbe_probe called
smi_reg_read: phy_addr 0 reg_ofs 22 devad -1
__mvgbe_mdio_read:(adr 0, off 22) value=
eth0: ethernet-controller@72000
Hit any key to stop autoboot: 0
Still very strange. Perhaps really some HW pin strapping responsible
for this difference?
My thoughts:
I think we probably need to refactor some constants in the uclass
drivers/net/mvgbe.c and/or create a helper in the Marvell PHY driver
drivers/net/phy/marvell.c.
The mvgbe uclass is a generic Ethernet class for all Kirkwood and
Orion-5x boards (CONFIG_ARCH_KIRKWOOD and CONFIG_ARCH_ORION5X).
However, as of right now, it lacks knowledge about specific things
such as the PHY Page Select register for a specific network chip.
Yes. And the
