Re: [PATCH v4 00/11] An effort to bring DT bindings compliance within U-Boot
On Thu, 25 Jan 2024 at 07:36, Marek Vasut wrote: > > On 1/24/24 09:16, Sumit Garg wrote: > > Hi, > > How do you propose to handle fixes to DTs which are applied to > linux-stable releases ? For example, if Linux 6.6(.0) ships a DT which > has some defect that is fixed in 6.6.1, how will that fix get into > U-Boot DTs ? > >>> > >>> This fix would also be in the latest Linux tags, so I think it would > >>> find its way here - as I understand it patches aren't accepted into > >>> Linux stable unless they land in torvalds tree. > >> > >> See the devicetree-rebasing.git: > >> > >> https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git/refs/ > >> > >> That only contains refs for release versions (v6.6-dts, v6.7-dts etc), > >> not any follow-up updates from linux-stable (like current 6.6.13 etc). > >> > > > > Here we should only consider fixes which are critical to U-Boot. I > > think -u-boot.dtsi files would be suitable to carry those fixes until > > next uprev. However, if there is a fix affecting many platforms than > > we can consider pulling that standalone too. > > That would mean extra duplicate work -- the critical fixes have already > been selected into linux-stable, that work is already done, I don't > think it makes sense to re-do it again. > > Furthermore, I do not like the new necessity to start porting those > fixes from linux-stable and converting them to adjustments to > *-u-boot.dtsi files, this is tedious and error prone, so it would have > to be automated. > > But I still think it is much better to simply take the fixes directly > from linux-stable as-is instead. That's fair, it would essentially be a DT ABI breakage for U-Boot for which a fix has to be taken in U-Boot from Linux stable release. So I am fine with that. But at this point we have to move away from apprehensions about DT ABI breakages and provide real examples of the DT ABI breakages in the past. Are you aware of any DT ABI breaking change backported to Linux stable releases? This is the sort of information we would like to make DT bindings maintainers aware about. > > >> Would this require syncing in -rc versions of Linux DTs to get the > >> latest fixes in ? > > > > Syncing -rc versions makes U-Boot more prone to DT ABI breakages. So > > its a chicken and egg problem as per your comments below. However, we > > can revisit our syncing strategy based on how the current one pans > > out. > > > >> > Assume that there is some large breaking change in Linux 6.(n+1), > something which would be problematic for specific U-Boot platform > (e.g. i.MX) or would require a lot of work to sort out, will there be > a way to temporarily pin DTs for specific platform to older DT version > until that is resolved (e.g. pin to 6.n) ? > >>> > >>> (Upstream) devicetree has to be forwards and backwards compatible, were > >>> such a breaking change to get merged without prior discussion with DT > >>> users (i.e. U-Boot) then I think the correct course of action would be > >>> to revert it. > >> > >> Not really, this could be a perfectly valid change, and would work for > >> Linux just fine, it might simply be pulling in something which is not > >> supported by U-Boot just yet and therefore syncing the DTs into U-Boot > >> would break U-Boot on that platform . Using older version of DTs for a > >> platform could work as a stopgap measure until the functionality is > >> implemented. Is this possible ? > > > > For this particular reason we want to pull once during beginning on > > U-Boot next window and allow sufficient time for platform maintainers > > to adapt to it. However, OF_UPSTREAM=n can be an alternative for a > > stopgap solution. > > That pull would break other peoples platforms. It would be no different > than adding broken patch into the code base. The platforms which get converted to OF_UPSTREAM=y are the ones which would be compliant with upstream DT bindings. So any DT ABI change among major Linux .0 releases would be the reason for that breakage. And we are happy to accept a revert for that change and feed that information back to Linux DT bindings maintainers. Also as above, are you aware of any past DT ABI breakages for U-Boot since people have already been doing DT syncing from Linux manually. This series allows to reduce that pain and try to bring DT bindings compliance in U-Boot. > What I think would be an > option is that there is a pull (as in patch) and people should be able > to test it before it is applied. We can't modify that pull but rather accept changes on top of it. IMO, it will get widely tested in U-Boot next branch. > If one platform is severely affected > while other platforms are fine, the one platform should be able to use > the current working version of DTs, while the other platforms should not > be blocked by it. Is that what OF_UPSTREAM=n does ? > > As far as I understand OF_UPSTREAM=n, it would require re-importing DTs > into the
[PATCH] board: rockchip: Add Hardkernel ODROID-M1S
Hardkernel ODROID-M1S is a single board computer with a RK3566 SoC,
a slightly modified version of the RK3566 SoC.
Features tested on a ODROID-M1S 8GB v1.0 2023-08-10:
- SD-card boot
- eMMC boot
- PCIe/NVMe
Signed-off-by: Dongjin Kim
---
arch/arm/dts/rk3566-odroid-m1s-u-boot.dtsi | 28 +
arch/arm/dts/rk3566-odroid-m1s.dts | 665 +
arch/arm/mach-rockchip/rk3568/Kconfig | 6 +
board/hardkernel/odroid_m1s/Kconfig| 15 +
board/hardkernel/odroid_m1s/MAINTAINERS| 9 +
board/hardkernel/odroid_m1s/Makefile | 7 +
board/hardkernel/odroid_m1s/board.c| 80 +++
configs/odroid-m1s-rk3566_defconfig| 109
doc/board/rockchip/rockchip.rst| 1 +
include/configs/odroid_m1s.h | 12 +
10 files changed, 932 insertions(+)
create mode 100644 arch/arm/dts/rk3566-odroid-m1s-u-boot.dtsi
create mode 100644 arch/arm/dts/rk3566-odroid-m1s.dts
create mode 100644 board/hardkernel/odroid_m1s/Kconfig
create mode 100644 board/hardkernel/odroid_m1s/MAINTAINERS
create mode 100644 board/hardkernel/odroid_m1s/Makefile
create mode 100644 board/hardkernel/odroid_m1s/board.c
create mode 100644 configs/odroid-m1s-rk3566_defconfig
create mode 100644 include/configs/odroid_m1s.h
diff --git a/arch/arm/dts/rk3566-odroid-m1s-u-boot.dtsi
b/arch/arm/dts/rk3566-odroid-m1s-u-boot.dtsi
new file mode 100644
index 000..33a1d142b8c
--- /dev/null
+++ b/arch/arm/dts/rk3566-odroid-m1s-u-boot.dtsi
@@ -0,0 +1,28 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+#include "rk356x-u-boot.dtsi"
+
+#include
+#include
+
+/ {
+ chosen {
+ stdout-path =
+ u-boot,spl-boot-order = ,
+ };
+};
+
+ {
+ cap-mmc-highspeed;
+ mmc-ddr-1_8v;
+ mmc-hs200-1_8v;
+ mmc-hs400-1_8v;
+ mmc-hs400-enhanced-strobe;
+ pinctrl-0 = <_bus8 _clk _cmd _datastrobe>;
+};
+
+ {
+ bootph-all;
+ clock-frequency = <2400>;
+ status = "okay";
+};
diff --git a/arch/arm/dts/rk3566-odroid-m1s.dts
b/arch/arm/dts/rk3566-odroid-m1s.dts
new file mode 100644
index 000..73e29d80c71
--- /dev/null
+++ b/arch/arm/dts/rk3566-odroid-m1s.dts
@@ -0,0 +1,665 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2024 Hardkernel Co., Ltd.
+ *
+ */
+
+/dts-v1/;
+#include
+#include
+#include
+#include
+#include "rk3566.dtsi"
+
+/ {
+ model = "Hardkernel ODROID-M1S";
+ compatible = "hardkernel,rk3568-odroid-m1s", "rockchip,rk3568";
+
+ aliases {
+ ethernet0 =
+ i2c0 =
+ i2c3 =
+ mmc0 =
+ mmc1 =
+ serial0 =
+ serial1 =
+ };
+
+ chosen {
+ stdout-path = "serial2:150n8";
+ };
+
+ gmac1_clkin: external-gmac1-clock {
+ compatible = "fixed-clock";
+ clock-frequency = <12500>;
+ clock-output-names = "gmac1_clkin";
+ #clock-cells = <0>;
+ };
+
+ hdmi-con {
+ compatible = "hdmi-connector";
+ type = "a";
+
+ port {
+ hdmi_con_in: endpoint {
+ remote-endpoint = <_out_con>;
+ };
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ led_power: led-0 {
+ gpios = < RK_PC6 GPIO_ACTIVE_HIGH>;
+ function = LED_FUNCTION_POWER;
+ color = ;
+ default-state = "keep";
+ linux,default-trigger = "default-on";
+ pinctrl-names = "default";
+ pinctrl-0 = <_power_pin>;
+ };
+ led_work: led-1 {
+ gpios = < RK_PB7 GPIO_ACTIVE_HIGH>;
+ function = LED_FUNCTION_HEARTBEAT;
+ color = ;
+ linux,default-trigger = "heartbeat";
+ pinctrl-names = "default";
+ pinctrl-0 = <_work_pin>;
+ };
+ };
+
+ pcie20_3v3: pcie20-3v3-regulator {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ gpios = < RK_PC2 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_pcie20_en_pin>;
+ regulator-name = "pcie20_3v3";
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ rk809-sound {
+ compatible = "simple-audio-card";
+ simple-audio-card,name = "Analog RK817";
+ simple-audio-card,format = "i2s";
+ simple-audio-card,mclk-fs = <256>;
+ simple-audio-card,widgets =
+ "Headphone", "Headphones",
+ "Speaker", "Speaker";
+
Re: [PATCH v1 0/1] Fix booting kernels with ATAGS and extlinux
25 січня 2024 р. 08:29:54 GMT+02:00, Dan Carpenter написав(-ла): >On Wed, Jan 24, 2024 at 10:27:30PM +0200, Svyatoslav Ryhel wrote: >> Currently, if boot with extlinux.conf and do not set the fdt >> U-Boot will provide its own device tree. This behavior is >> beneficial if the U-Boot device tree is in sync with Linux, >> but it totally halts the booting of pre-dtb kernels (3.4 for >> example) since it uses ATAGs. To fix this, pass `-` in the >> fdt extlinux field as a signal that no tree should be used. > >Passing - doesn't seem like the most intuitive thing... Is there a >different argument we could use? > I agree that `-` is not the most intuitive argument, but this is a way to implement a fix with the least code posssible. To make this less obscure I have adjusted documentation. Currently if no fdt is specified u-boot will pass its own device tree and if leave fdt field blank u-boot will fail with the wrong name for the device tree. So there is NO way to boot ATAGs based kernel if u-boot has an appended tree and fdt support built in. >regards, >dan carpenter >
Re: [PATCH v1 0/1] Fix booting kernels with ATAGS and extlinux
On Wed, Jan 24, 2024 at 10:27:30PM +0200, Svyatoslav Ryhel wrote: > Currently, if boot with extlinux.conf and do not set the fdt > U-Boot will provide its own device tree. This behavior is > beneficial if the U-Boot device tree is in sync with Linux, > but it totally halts the booting of pre-dtb kernels (3.4 for > example) since it uses ATAGs. To fix this, pass `-` in the > fdt extlinux field as a signal that no tree should be used. Passing - doesn't seem like the most intuitive thing... Is there a different argument we could use? regards, dan carpenter
Re: [PATCH] firmware: ti_sci: fix the secure_hdr in do_xfer
On Jan 24, 2024 at 12:08:13 -0600, Nishanth Menon wrote:
> On 23:07-20240124, Dhruva Gole wrote:
> > On Jan 24, 2024 at 10:39:10 -0600, Nishanth Menon wrote:
> > > On 18:38-20240124, Dhruva Gole wrote:
> > > > On Jan 24, 2024 at 16:42:12 +0530, Kamlesh Gurudasani wrote:
> > > > > Dhruva Gole writes:
> > > > >
> > > > > > The secure_hdr needs to be 0 init-ed however this was never being
> > > > > > put
> > > > > > into the secure_buf, leading to possibility of the first 4 bytes of
> > > > > > secure_buf being possibly garbage.
> > > > > >
> > > > > > Fix this by initialising the secure_hdr itself to the secure_buf
> > > > > > location, thus when we make it 0, it automatically ensures the
> > > > > > first 4
> > > > > > bytes are 0.
> > > > > >
> > > > > > Fixes: 32cd25128bd849 ("firmware: Add basic support for TI System
> > > > > > Control Interface (TI SCI)")
> > > > > > Signed-off-by: Dhruva Gole
> > > > > > ---
> > > > > >
> > > > > > Boot tested for sanity on AM62x SK
> > > > > > https://gist.github.com/DhruvaG2000/724ceba3a0db03f4b0bff47de1160074
> > > > > >
> > > > > > Cc: Nishanth Menon
> > > > > > Cc: Tom Rini
> > > > > >
> > > > > > drivers/firmware/ti_sci.c | 6 +++---
> > > > > > 1 file changed, 3 insertions(+), 3 deletions(-)
> > > > > >
> > > > > > diff --git a/drivers/firmware/ti_sci.c b/drivers/firmware/ti_sci.c
> > > > > > index f5f659c11274..83ee8401a731 100644
> > > > > > --- a/drivers/firmware/ti_sci.c
> > > > > > +++ b/drivers/firmware/ti_sci.c
> > > > > > @@ -236,13 +236,13 @@ static int ti_sci_do_xfer(struct ti_sci_info
> > > > > > *info,
> > > > > > {
> > > > > > struct k3_sec_proxy_msg *msg = >tx_message;
> > > > > > u8 secure_buf[info->desc->max_msg_size];
> > > > > > - struct ti_sci_secure_msg_hdr secure_hdr;
> > > > > > + struct ti_sci_secure_msg_hdr *secure_hdr = (struct
> > > > > > ti_sci_secure_msg_hdr *)secure_buf;
> > > > > > int ret;
> > > > > >
> > > > > > if (info->is_secure) {
> > > > > > /* ToDo: get checksum of the entire message */
> > > > > > - secure_hdr.checksum = 0;
> > > > > > - secure_hdr.reserved = 0;
> > > > > > + secure_hdr->checksum = 0;
> > > > > > + secure_hdr->reserved = 0;
> > > > > >
> > > > > > memcpy(_buf[sizeof(secure_hdr)],xfer->tx_message.buf,
> > > > > secure_hdr is pointer now, the value may be same but (struct
> > > > > ti_sci_secure_msg_hdr) would make more sense
> > > >
> > > > Good catch Kamlesh! I have sent a new revision addressing this.
> > > >
> > >
> > > Makes no sense why we have secure API support in U-Boot. what is using
> > > this?
> >
> > In my understanding of generic K3 boot flow, things like proc_boot and
> > even applying or removing of firewalls will need a secure channel to
> > talk to TIFS right? From my understanding secure host can only talk to
> > TIFS and make such requests hence secure API.
>
> U-boot runs in NS world, you cant even talk to the Trustzone Sec proxy
> without triggering a firewall violation.
I am not going to debate on whether U-Boot is or isn't a secure entity.
The original code base was making secure_hdr.checksum = 0;
But this wasn't really being used anywhere. I am just making sure what the
original code base intended to do is being actually done.
>
>
> https://software-dl.ti.com/tisci/esd/latest/2_tisci_msgs/general/TISCI_header.html?highlight=header#secure-messaging-header
> "The Secure Messaging Header is only required when sending messages over
> secure transport. Messages sent over non-secure transport must not
> contain the secure messaging header."
Yes, understood. I do not have the context behind the commit
32cd25128bd849 ("firmware: Add basic support for TI System Control
Interface (TI SCI)") but perhaps you do. So please help me understand
why there's this code:
memcpy(_buf[sizeof(secure_hdr)], xfer->tx_message.buf,
xfer->tx_message.len);
which is basically trying to create a 4 byte offset (trying to abide by the
secure
msg format?)
If UBoot as you say is non secure let's just send regular TISCI messages. Are
you
suggesting that we trim all of if (info->is_secure) and related "secure"
code from uboot? Then that's a separate cleanup we need to have.
>
> btw, that checksum field should be renamed integ_check, but anyways..
>
> So, I do not see a reason to even have that if condition in the first
> place and what real bug was getting fixed in this patch.
"Real" bug or "potential" bug, the code did not seem to be doing what it should
have
been doing, that's all. For anyone reading the checksum = 0 that is
there in today's code it's super confusing.
Either get rid of it completely, or else make it do what it was trying
to do. Let me know how we should proceed.
--
Best regards,
Dhruva Gole
Re: [RFC PATCH v3 02/15] misc: fs-loader: Use fw_storage_interface instead of storage_interface
Hi Nishant,
On 1/24/2024 11:40 PM, Nishanth Menon wrote:
> On 12:19-20240124, MD Danish Anwar wrote:
>> The fs-loader driver reads env storage_interface and uses it to load
>> firmware file into memory using the medium set by env. Update the driver
>> to use env fw_storage_interface as this variable is only used to load
>> firmwares. The env storage_interface will act as fallback so that the
>> existing implementations do not break.
>>
>> Also update the FS Loader documentation accordingly.
>>
>> Signed-off-by: MD Danish Anwar
>> ---
>> doc/develop/driver-model/fs_firmware_loader.rst | 5 -
>> drivers/misc/fs_loader.c| 5 -
>> 2 files changed, 8 insertions(+), 2 deletions(-)
>>
>> diff --git a/doc/develop/driver-model/fs_firmware_loader.rst
>> b/doc/develop/driver-model/fs_firmware_loader.rst
>> index 149b8b436e..410cc1442d 100644
>> --- a/doc/develop/driver-model/fs_firmware_loader.rst
>> +++ b/doc/develop/driver-model/fs_firmware_loader.rst
>> @@ -98,8 +98,11 @@ through the U-Boot environment variable during run time.
>>
>> For examples:
>>
>> +fw_storage_interface:
>> + Firmware storage interface, it can be "mmc", "usb", "sata" or "ubi".
>> storage_interface:
>> - Storage interface, it can be "mmc", "usb", "sata" or "ubi".
>> + Storage interface, it can be "mmc", "usb", "sata" or "ubi". This acts
>> + as a fallback if fw_storage_interface is not set.
>> fw_dev_part:
>>Block device number and its partition, it can be "0:1".
>> fw_ubi_mtdpart:
>> diff --git a/drivers/misc/fs_loader.c b/drivers/misc/fs_loader.c
>> index 1ffc199ba1..3798dab5b6 100644
>> --- a/drivers/misc/fs_loader.c
>> +++ b/drivers/misc/fs_loader.c
>> @@ -153,7 +153,10 @@ static int fw_get_filesystem_firmware(struct udevice
>> *dev)
>> char *storage_interface, *dev_part, *ubi_mtdpart, *ubi_volume;
>> int ret;
>>
>> -storage_interface = env_get("storage_interface");
>> +storage_interface = env_get("fw_storage_interface");
>> +if (!storage_interface)
>> +storage_interface = env_get("storage_interface");
>> +
>> dev_part = env_get("fw_dev_part");
>> ubi_mtdpart = env_get("fw_ubi_mtdpart");
>> ubi_volume = env_get("fw_ubi_volume");
>> --
>> 2.34.1
>>
>
> You should move these specific patches out of the series and debate on
> their merits seperately. mixing things like these in a single series
> that needs to go to multiple u-boot custodians just creates problems for
> everyone.
>
I have kept these patches in the series because ICSSG driver depends on
these patches. I didn't want to post multiple series and map
dependencies so I posted all patches in one series. Patch 1 to 3 are
dependency for ICSSG driver. Patch 4 to 9 are ICSSG driver patches.
Patch 10 to 15 are AM65x-EVM specific patches (DTS and configs).
The first 3 patches will also go to different u-boot custodians as first
one is dma related, second one is related to fs-loader driver and the
third one modifies the remoteproc driver. So instead of posting all
these separately, I wanted to post it along with the ICSSG driver series
so that folks can understand why these three patches are needed.
--
Thanks and Regards,
Md Danish Anwar
Re: [PATCH v4 00/11] An effort to bring DT bindings compliance within U-Boot
On 1/24/24 09:16, Sumit Garg wrote: Hi, How do you propose to handle fixes to DTs which are applied to linux-stable releases ? For example, if Linux 6.6(.0) ships a DT which has some defect that is fixed in 6.6.1, how will that fix get into U-Boot DTs ? This fix would also be in the latest Linux tags, so I think it would find its way here - as I understand it patches aren't accepted into Linux stable unless they land in torvalds tree. See the devicetree-rebasing.git: https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git/refs/ That only contains refs for release versions (v6.6-dts, v6.7-dts etc), not any follow-up updates from linux-stable (like current 6.6.13 etc). Here we should only consider fixes which are critical to U-Boot. I think -u-boot.dtsi files would be suitable to carry those fixes until next uprev. However, if there is a fix affecting many platforms than we can consider pulling that standalone too. That would mean extra duplicate work -- the critical fixes have already been selected into linux-stable, that work is already done, I don't think it makes sense to re-do it again. Furthermore, I do not like the new necessity to start porting those fixes from linux-stable and converting them to adjustments to *-u-boot.dtsi files, this is tedious and error prone, so it would have to be automated. But I still think it is much better to simply take the fixes directly from linux-stable as-is instead. Would this require syncing in -rc versions of Linux DTs to get the latest fixes in ? Syncing -rc versions makes U-Boot more prone to DT ABI breakages. So its a chicken and egg problem as per your comments below. However, we can revisit our syncing strategy based on how the current one pans out. Assume that there is some large breaking change in Linux 6.(n+1), something which would be problematic for specific U-Boot platform (e.g. i.MX) or would require a lot of work to sort out, will there be a way to temporarily pin DTs for specific platform to older DT version until that is resolved (e.g. pin to 6.n) ? (Upstream) devicetree has to be forwards and backwards compatible, were such a breaking change to get merged without prior discussion with DT users (i.e. U-Boot) then I think the correct course of action would be to revert it. Not really, this could be a perfectly valid change, and would work for Linux just fine, it might simply be pulling in something which is not supported by U-Boot just yet and therefore syncing the DTs into U-Boot would break U-Boot on that platform . Using older version of DTs for a platform could work as a stopgap measure until the functionality is implemented. Is this possible ? For this particular reason we want to pull once during beginning on U-Boot next window and allow sufficient time for platform maintainers to adapt to it. However, OF_UPSTREAM=n can be an alternative for a stopgap solution. That pull would break other peoples platforms. It would be no different than adding broken patch into the code base. What I think would be an option is that there is a pull (as in patch) and people should be able to test it before it is applied. If one platform is severely affected while other platforms are fine, the one platform should be able to use the current working version of DTs, while the other platforms should not be blocked by it. Is that what OF_UPSTREAM=n does ? As far as I understand OF_UPSTREAM=n, it would require re-importing DTs into the codebase ? On a tangential note: as I understand it, DTs built from dt-rebasing are still subject to U-Boot customisations via the "-u-boot.dtsi" include files, this allows for dealing with incompatibilities due to missing features in U-Boot. Would it be possible to auto-update those -u-boot.dtsi files during sync, to minimize the resulting DT blob delta before/after update, and thus also minimize the likelihood of causing breakage ? In the long run the DT community would like to avoid any DT ABI breakages at all. Rob is already working on a DT ABI check tool and seeking inputs for what could be an ABI break [1] from U-Boot perspective too. Feel free to provide your inputs. Along with that we wouldn't need -u-boot.dtsi files once we make U-Boot fully compliant with DT bindings. Until that point U-Boot platform maintainers have to keep their -u-boot.dtsi files updated corresponding to latest DT rebasing releases. I think upstreaming the bootph* properties would still take a while, but is not relevant to the aforementioned question. Assume there is a sync, would the current in-tree -u-boot.dtsi files get updated to work correctly with the newly synced DTs ?
[PATCH] smbios: use struct_table_length to get SMBIOS 2.1 total table length
The current code convert the SMBIOS 2.1 entry point structure to
SMBIOS 3.0 entry point structure. The max_struct_size member in
SMBIOS 2.1 entry point structure indicates
"Size of the largest SMBIOS structure, in bytes".
We need to use struct_table_length instead.
Fixes: 1c5aab803c0b ("smbios: copy QEMU tables")
Signed-off-by: Masahisa Kojima
---
drivers/misc/qfw_smbios.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/misc/qfw_smbios.c b/drivers/misc/qfw_smbios.c
index 9019345783..a898cb4eea 100644
--- a/drivers/misc/qfw_smbios.c
+++ b/drivers/misc/qfw_smbios.c
@@ -90,7 +90,7 @@ static int qfw_parse_smbios_anchor(struct udevice *dev,
entry->length = sizeof(struct smbios3_entry);
entry->major_ver = entry2->major_ver;
entry->minor_ver = entry2->minor_ver;
- entry->max_struct_size = entry2->max_struct_size;
+ entry->max_struct_size = entry2->struct_table_length;
} else {
ret = -ENOENT;
goto out;
--
2.34.1
Re: [PATCH v2 2/4] cmd: provide command to display SMBIOS information
On Thu, Jan 25, 2024 at 12:24:33AM +0100, Heinrich Schuchardt wrote: > On 1/24/24 22:16, Tom Rini wrote: > > On Wed, Jan 17, 2024 at 04:33:45PM +0100, Heinrich Schuchardt wrote: > > > > > U-Boot can either generated an SMBIOS table or copy it from a prior boot > > > stage, e.g. QEMU. > > > > > > Provide a command to display the SMBIOS information. > > > > > > Currently only type 1 and 2 are translated to human readable text. > > > Other types may be added later. Currently only a hexdump and the list of > > > strings is provided for these. > > > > > > Signed-off-by: Heinrich Schuchardt > > > Reviewed-by: Simon Glass > > > Reviewed-by: Ilias Apalodimas > > [snip] > > > @@ -227,6 +227,13 @@ config CMD_SBI > > > help > > > Display information about the SBI implementation. > > > +config CMD_SMBIOS > > > + bool "smbios" > > > + depends on SMBIOS > > > + default y > > > + help > > > + Display the SMBIOS information. > > > + > > > > So this would be enabled (today) on 888 boards and is a bit more than a > > kilobyte. I think we can just let this be enabled as needed in > > defconfigs? > > > > As needed would be the boards where we want to run the related Python test. > Sandbox and QEMU should be good enough? And the test needs the pytest mark for cmd_smbios, yes. -- Tom signature.asc Description: PGP signature
Re: [PATCH] efi_loader: migrate SMBIOS 3.0 entry point structure for measurement
Hi Heinrich,
On Wed, 24 Jan 2024 at 22:54, Heinrich Schuchardt wrote:
>
> On 24.01.24 12:51, Masahisa Kojima wrote:
> > Hi Heinrich,
> >
> > On Wed, 24 Jan 2024 at 18:29, Heinrich Schuchardt
> > wrote:
> >>
> >> On 1/24/24 10:15, Masahisa Kojima wrote:
> >>> Current U-Boot only supports the SMBIOS 3.0 entry point structure.
> >>> TCG2 measurement code should migrate to SMBIOS 3.0 entry
> >>> point structure.
> >>>
> >>> efi_selftest tcg2 test also needs to be updated, and expected
> >>> PCR[1] result is changed since guid for SMBIOS EFI system table
> >>> uses different guid SMBIOS3_TABLE_GUID instead of SMBIOS_TABLE_GUID.
> >>>
> >>> Signed-off-by: Masahisa Kojima
> >>
> >> Hello Maasahisa,
> >>
> >> Thank you for looking into this.
> >>
> >> SMBIOS tables may be provided by QEMU. Depending on the architecture and
> >> the QEMU release we will see SMBIOS2.1 and SMBIOS3 tables. We should
> >> support measuring for both.
> >
> > With this commit, I assume that only SMBIOS 3.0 is supported in an EFI
> > enabled system.
> > # Sorry but I don't fully follow the recent SMBIOS discussion in U-Boot
> > ML.
> >
> > commit aa8499680c14afa80ed731b4cfcd6934b4f93712
> > "efi: smbios: Drop support for SMBIOS2 tables"
> >
> > If QEMU provides the SMBIOS 2.1 tables, do we need to revert the above
> > patch?
>
> qemu-x86_defconfig receives a SMBIOS 2.1 table from QEMU 8.2.
>
> But in qfw_parse_smbios_anchor() we translate this to SMBIOS 3.0. So it
> seems my worries concerning QEMU were unjustified.
Thank you for confirming it.
>
> I still wonder why in smbios_prepare_measurement() we don't check that
> the SMBIOS header has the expected signature ('_SM3_').
I will add anchor string checking.
Thanks,
Masahisa Kojima
>
> Best regards
>
> Heinrich
> >>
> >>> ---
> >>>include/efi_loader.h | 1 +
> >>>include/smbios.h | 4 +-
> >>>lib/efi_loader/efi_tcg2.c| 14 ++--
> >>>lib/efi_selftest/efi_selftest_tcg2.c | 97 +---
> >>>lib/smbios-parser.c | 9 ++-
> >>>5 files changed, 61 insertions(+), 64 deletions(-)
> >>>
> >>> diff --git a/include/efi_loader.h b/include/efi_loader.h
> >>> index d5fca2fa5e..5c5af4f7fd 100644
> >>> --- a/include/efi_loader.h
> >>> +++ b/include/efi_loader.h
> >>> @@ -340,6 +340,7 @@ extern const efi_guid_t
> >>> efi_guid_firmware_management_protocol;
> >>>extern const efi_guid_t efi_esrt_guid;
> >>>/* GUID of the SMBIOS table */
> >>>extern const efi_guid_t smbios_guid;
> >>> +extern const efi_guid_t smbios3_guid;
> >>>/*GUID of console */
> >>>extern const efi_guid_t efi_guid_text_input_protocol;
> >>>extern const efi_guid_t efi_guid_text_output_protocol;
> >>> diff --git a/include/smbios.h b/include/smbios.h
> >>> index b507b9d9d7..e45303d0d3 100644
> >>> --- a/include/smbios.h
> >>> +++ b/include/smbios.h
> >>> @@ -326,10 +326,10 @@ int smbios_update_version_full(void *smbios_tab,
> >>> const char *version);
> >>> * This function clear the device dependent parameters such as
> >>> * serial number for the measurement.
> >>> *
> >>> - * @entry: pointer to a struct smbios_entry
> >>> + * @entry: pointer to a struct smbios3_entry
> >>> * @header: pointer to a struct smbios_header
> >>> */
> >>> -void smbios_prepare_measurement(const struct smbios_entry *entry,
> >>> +void smbios_prepare_measurement(const struct smbios3_entry *entry,
> >>>struct smbios_header *header);
> >>>
> >>>#endif /* _SMBIOS_H_ */
> >>> diff --git a/lib/efi_loader/efi_tcg2.c b/lib/efi_loader/efi_tcg2.c
> >>> index 8db35d0b3c..8b4f2fd2da 100644
> >>> --- a/lib/efi_loader/efi_tcg2.c
> >>> +++ b/lib/efi_loader/efi_tcg2.c
> >>> @@ -1075,7 +1075,7 @@ error:
> >>> */
> >>>static efi_status_t
> >>>tcg2_measure_smbios(struct udevice *dev,
> >>> - const struct smbios_entry *entry)
> >>> + const struct smbios3_entry *entry)
> >>>{
> >>>efi_status_t ret;
> >>>struct smbios_header *smbios_copy;
> >>> @@ -1093,7 +1093,7 @@ tcg2_measure_smbios(struct udevice *dev,
> >>> */
> >>>event_size = sizeof(struct smbios_handoff_table_pointers2) +
> >>> FIELD_SIZEOF(struct efi_configuration_table, guid) +
> >>> - entry->struct_table_length;
> >>> + entry->max_struct_size;
> >>>event = calloc(1, event_size);
> >>>if (!event) {
> >>>ret = EFI_OUT_OF_RESOURCES;
> >>> @@ -1104,11 +1104,11 @@ tcg2_measure_smbios(struct udevice *dev,
> >>>memcpy(event->table_description, SMBIOS_HANDOFF_TABLE_DESC,
> >>> sizeof(SMBIOS_HANDOFF_TABLE_DESC));
> >>>put_unaligned_le64(1, >number_of_tables);
> >>> - guidcpy(>table_entry[0].guid, _guid);
> >>> + guidcpy(>table_entry[0].guid, _guid);
> >>>smbios_copy = (struct smbios_header
> >>>
Re: [PATCH v2 2/4] cmd: provide command to display SMBIOS information
On 1/24/24 22:16, Tom Rini wrote: On Wed, Jan 17, 2024 at 04:33:45PM +0100, Heinrich Schuchardt wrote: U-Boot can either generated an SMBIOS table or copy it from a prior boot stage, e.g. QEMU. Provide a command to display the SMBIOS information. Currently only type 1 and 2 are translated to human readable text. Other types may be added later. Currently only a hexdump and the list of strings is provided for these. Signed-off-by: Heinrich Schuchardt Reviewed-by: Simon Glass Reviewed-by: Ilias Apalodimas [snip] @@ -227,6 +227,13 @@ config CMD_SBI help Display information about the SBI implementation. +config CMD_SMBIOS + bool "smbios" + depends on SMBIOS + default y + help + Display the SMBIOS information. + So this would be enabled (today) on 888 boards and is a bit more than a kilobyte. I think we can just let this be enabled as needed in defconfigs? As needed would be the boards where we want to run the related Python test. Sandbox and QEMU should be good enough? Best regards Heinrich
Re: [PATCH 1/1] riscv: separate .data and .text sections of EFI binaries
On Thu, Jan 25, 2024 at 12:08:57AM +0100, Heinrich Schuchardt wrote:
> EFI binaries should not contain sections that are both writable and
> executable. Separate the RX .text section from the RW .data section
>
> Adjust the section alignment to 4096 bytes.
>
> Fix conflicting SPDX license information in linker scripts introduced by
> commit 7215787c4ea4 ("SPDX: Convert single license tags to Linux Kernel
> style").
>
> Fixes: 7215787c4ea4 ("SPDX: Convert single license tags to Linux Kernel
> style")
> Signed-off-by: Heinrich Schuchardt
> ---
> arch/riscv/lib/crt0_riscv_efi.S| 39 ++
> arch/riscv/lib/elf_riscv32_efi.lds | 26
> arch/riscv/lib/elf_riscv64_efi.lds | 26
> 3 files changed, 61 insertions(+), 30 deletions(-)
Lets not do two distinct changes like this in a single commit, thanks.
--
Tom
signature.asc
Description: PGP signature
[PATCH 1/1] riscv: separate .data and .text sections of EFI binaries
EFI binaries should not contain sections that are both writable and
executable. Separate the RX .text section from the RW .data section
Adjust the section alignment to 4096 bytes.
Fix conflicting SPDX license information in linker scripts introduced by
commit 7215787c4ea4 ("SPDX: Convert single license tags to Linux Kernel
style").
Fixes: 7215787c4ea4 ("SPDX: Convert single license tags to Linux Kernel style")
Signed-off-by: Heinrich Schuchardt
---
arch/riscv/lib/crt0_riscv_efi.S| 39 ++
arch/riscv/lib/elf_riscv32_efi.lds | 26
arch/riscv/lib/elf_riscv64_efi.lds | 26
3 files changed, 61 insertions(+), 30 deletions(-)
diff --git a/arch/riscv/lib/crt0_riscv_efi.S b/arch/riscv/lib/crt0_riscv_efi.S
index 793eefdd883..46b08552371 100644
--- a/arch/riscv/lib/crt0_riscv_efi.S
+++ b/arch/riscv/lib/crt0_riscv_efi.S
@@ -53,7 +53,7 @@ pe_header:
.long IMAGE_NT_SIGNATURE /* 'PE' */
coff_header:
.short PE_MACHINE /* RISC-V 64/32-bit */
- .short 2 /* nr_sections */
+ .short 3 /* nr_sections */
.long 0 /* TimeDateStamp */
.long 0 /* PointerToSymbolTable */
.long 0 /* NumberOfSymbols */
@@ -144,18 +144,37 @@ section_table:
.byte 0
.byte 0
.byte 0 /* end of 0 padding of section name */
- .long _edata - _start /* VirtualSize */
+ .long _etext - _start /* VirtualSize */
.long _start - ImageBase /* VirtualAddress */
- .long _edata - _start /* SizeOfRawData */
+ .long _etext - _start /* SizeOfRawData */
.long _start - ImageBase /* PointerToRawData */
+ .long 0 /* PointerToRelocations (0 for
executables) */
+ .long 0 /* PointerToLineNumbers (0 for
executables) */
+ .short 0 /* NumberOfRelocations (0 for
executables) */
+ .short 0 /* NumberOfLineNumbers (0 for
executables) */
+ /* Characteristics (section flags) */
+ .long (IMAGE_SCN_MEM_READ | \
+IMAGE_SCN_MEM_EXECUTE | \
+IMAGE_SCN_CNT_CODE)
+
+ .ascii ".data"
+ .byte 0
+ .byte 0
+ .byte 0 /* end of 0 padding of section name */
+ .long _edata - _data /* VirtualSize */
+ .long _data - ImageBase /* VirtualAddress */
+ .long _edata - _data /* SizeOfRawData */
+ .long _data - ImageBase /* PointerToRawData */
+ .long 0 /* PointerToRelocations */
+ .long 0 /* PointerToLineNumbers */
+ .short 0 /* NumberOfRelocations */
+ .short 0 /* NumberOfLineNumbers */
+ /* Characteristics (section flags) */
+ .long (IMAGE_SCN_MEM_WRITE | \
+IMAGE_SCN_MEM_READ | \
+IMAGE_SCN_CNT_INITIALIZED_DATA)
- .long 0 /* PointerToRelocations (0 for executables) */
- .long 0 /* PointerToLineNumbers (0 for executables) */
- .short 0 /* NumberOfRelocations (0 for executables) */
- .short 0 /* NumberOfLineNumbers (0 for executables) */
- .long 0xe0500020 /* Characteristics (section flags) */
-
- .align 9
+ .align 12
_start:
addisp, sp, -(SIZE_LONG * 3)
SAVE_LONG(a0, 0)
diff --git a/arch/riscv/lib/elf_riscv32_efi.lds
b/arch/riscv/lib/elf_riscv32_efi.lds
index c3e0d20d577..7b9bd7b7f15 100644
--- a/arch/riscv/lib/elf_riscv32_efi.lds
+++ b/arch/riscv/lib/elf_riscv32_efi.lds
@@ -1,14 +1,18 @@
-/* SPDX-License-Identifier: GPL-2.0+ */
+/* SPDX-License-Identifier: BSD-2-Clause */
/*
* U-Boot riscv32 EFI linker script
*
- * SPDX-License-Identifier:BSD-2-Clause
- *
* Modified from arch/arm/lib/elf_aarch64_efi.lds
*/
OUTPUT_FORMAT("elf32-littleriscv", "elf32-littleriscv", "elf32-littleriscv")
OUTPUT_ARCH(riscv)
+
+PHDRS
+{
+ data PT_LOAD FLAGS(3); /* SHF_WRITE | SHF_ALLOC */
+}
+
ENTRY(_start)
SECTIONS
{
@@ -20,11 +24,17 @@ SECTIONS
*(.gnu.linkonce.t.*)
*(.srodata)
*(.rodata*)
+ . = ALIGN(16);
+ *(.dynamic);
. = ALIGN(512);
}
+ .rela.dyn : { *(.rela.dyn) }
+ .rela.plt : { *(.rela.plt) }
+ .rela.got : { *(.rela.got) }
+ .rela.data : { *(.rela.data) *(.rela.data*) }
_etext = .;
_text_size = . - _text;
- .dynamic : { *(.dynamic) }
+ . = ALIGN(4096);
.data : {
_data =
Re: [PATCH V4 3/7] rockchip: boot_mode: Allow rockchip_dnl_key_pressed() in SPL
On Fri, Jan 19, 2024 at 05:01:38PM +0800, Kever Yang wrote: > Hi Chris, > > On 2024/1/18 23:06, Chris Morgan wrote: > > On Thu, Jan 18, 2024 at 03:20:52PM +0800, Kever Yang wrote: > > > Hi Chris, > > > > > > On 2024/1/2 23:46, Chris Morgan wrote: > > > > From: Chris Morgan > > > > > > > > Update the rockchip_dnl_key_pressed() so that it can run in > > > > SPL. Also change the ADC channel to a define that can be > > > > overridden by a board specific option. > > > I should ask this earlier. > > > > > > Why you have to enable the download key in SPL? > > > > > > This works for a long time in U-Boot proper, both mainline and downstream > > > vendor U-Boot, > > > > > > no one is detect this download key in SPL. > > > > > > In theory the SPL can implement all the feature which is available in > > > U-Boot > > > proper, > > > > > > but it would be better to make the SPL focus on the job it should be done > > > and keep as small as possible. > > > > > I wanted this code to run as soon as possible in the event of a bad > > write. I have some devices which lack a way to bypass the eMMC in the > > boot path; the fear is that if an SPL stage is written with a good > > header but a bad payload (or if the A-TF does something wrong) the > > device will become unbootable. If we can't do it this way for > > all Rockchip boards that's fine, but I REALLY want to at least do > > it this way for the Powkiddy X55 board and the Anbernic RGxx3 board. > > That's why rockchip platform has two download mode, loader mode(in U-Boot) > > and maskRom mode, any error happen before U-Boot should get into maksRom > mode. > > Most of user/developer only use loader mode because the modules before > U-Boot should > > be more stable and have very little chance to update, for the module owners > before U-Boot, > > they are the users of maskRom mode. > > If you enable this feature in SPL, the error still have chance to happen > during dram init to SPL key detect. > > Does these two board has no way to get into eMMC event with hardware rework? > any hardware > > signal of eMMC CMD/CLK/DATA is OK. A few do not. The error is less likely to occur between RAM init and SPL key detect, but yes it's even possible at this stage. >From my testing using the latest BL31 file from the rockchip-linux/rkbin github repository I was unable to reboot into maskrom mode after A-TF loaded, the device would just straight reboot. Do you know if A-TF does something that makes reboot into maskrom mode no longer work? > > And another way to bypass eMMC is to use SDcard which has higher priority > then eMMC in BootRom. > I see in the TRM under section 1.2 that the eMMC is higher in the boot path than SDMMC, and that matches my experience as well. So this wouldn't be a solution sadly. > For SPL itself debug, I would suggest to RESET into bootrom download mode if > any error happen > > and a reset will need. > > I pick up patches other than 2,3,4 in this patchset for now. > > > While I have you, I have a related question I hope you can help with. > > Is there any way to utilize the boot partitions of an eMMC device? I > > don't know if the BROM of an RK3568 or RK3588 is capable, but I'd love > > to have the SPL and U-Boot stages written to the eMMC boot partitions > > instead of the user partition if I can. > > No, Rockchip SoCs does not use the boot partitions of eMMC, only use the > user data partition. That's unfortunate, but I appreciate the feedback. Thank you, Chris > > > Thanks, > > - Kever > > > > > Thank you. > > > > > Thanks, > > > > > > - Kever > > > > > > > Signed-off-by: Chris Morgan > > > > --- > > > >arch/arm/mach-rockchip/Makefile| 4 ++-- > > > >arch/arm/mach-rockchip/boot_mode.c | 11 ++- > > > >2 files changed, 12 insertions(+), 3 deletions(-) > > > > > > > > diff --git a/arch/arm/mach-rockchip/Makefile > > > > b/arch/arm/mach-rockchip/Makefile > > > > index 1dc92066bb..ff089ae949 100644 > > > > --- a/arch/arm/mach-rockchip/Makefile > > > > +++ b/arch/arm/mach-rockchip/Makefile > > > > @@ -15,13 +15,13 @@ obj-tpl-$(CONFIG_ROCKCHIP_PX30) += px30-board-tpl.o > > > >obj-spl-$(CONFIG_ROCKCHIP_RK3036) += rk3036-board-spl.o > > > > -ifeq ($(CONFIG_SPL_BUILD)$(CONFIG_TPL_BUILD),) > > > > - > > > ># Always include boot_mode.o, as we bypass it (i.e. turn it off) > > > ># inside of boot_mode.c when CONFIG_ROCKCHIP_BOOT_MODE_REG is 0. > > > > This way, > > > ># we can have the preprocessor correctly recognise both 0x0 and 0 > > > ># meaning "turn it off". > > > >obj-y += boot_mode.o > > > > + > > > > +ifeq ($(CONFIG_SPL_BUILD)$(CONFIG_TPL_BUILD),) > > > >obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += board.o > > > >obj-$(CONFIG_MISC_INIT_R) += misc.o > > > >endif > > > > diff --git a/arch/arm/mach-rockchip/boot_mode.c > > > > b/arch/arm/mach-rockchip/boot_mode.c > > > > index eb8f65ae4e..d2308768be 100644 > > > > --- a/arch/arm/mach-rockchip/boot_mode.c > > > > +++
Re: [PATCH v2 2/4] cmd: provide command to display SMBIOS information
On Wed, Jan 17, 2024 at 04:33:45PM +0100, Heinrich Schuchardt wrote: > U-Boot can either generated an SMBIOS table or copy it from a prior boot > stage, e.g. QEMU. > > Provide a command to display the SMBIOS information. > > Currently only type 1 and 2 are translated to human readable text. > Other types may be added later. Currently only a hexdump and the list of > strings is provided for these. > > Signed-off-by: Heinrich Schuchardt > Reviewed-by: Simon Glass > Reviewed-by: Ilias Apalodimas [snip] > @@ -227,6 +227,13 @@ config CMD_SBI > help > Display information about the SBI implementation. > > +config CMD_SMBIOS > + bool "smbios" > + depends on SMBIOS > + default y > + help > + Display the SMBIOS information. > + So this would be enabled (today) on 888 boards and is a bit more than a kilobyte. I think we can just let this be enabled as needed in defconfigs? -- Tom signature.asc Description: PGP signature
[PATCH v1 1/1] boot: pxe_utils: skip fdt setup in case legacy kernel is booted
Currently, if boot with extlinux.conf and do not set the fdt
U-Boot will provide its own device tree. This behavior is
beneficial if the U-Boot device tree is in sync with Linux,
but it totally halts the booting of pre-dtb kernels (3.4 for
example) since it uses ATAGs. To fix this, pass `-` in the
fdt extlinux field as a signal that no tree should be used.
Suggested-by: Jonas Schwöbel
Tested-by: Jethro Bull
Signed-off-by: Svyatoslav Ryhel
---
boot/pxe_utils.c | 8 +---
doc/develop/distro.rst | 3 +++
2 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/boot/pxe_utils.c b/boot/pxe_utils.c
index 83bc167785..6a2c881965 100644
--- a/boot/pxe_utils.c
+++ b/boot/pxe_utils.c
@@ -634,7 +634,8 @@ static int label_boot(struct pxe_context *ctx, struct
pxe_label *label)
char *fdtfilefree = NULL;
if (label->fdt) {
- fdtfile = label->fdt;
+ if (strcmp("-", label->fdt))
+ fdtfile = label->fdt;
} else if (label->fdtdir) {
char *f1, *f2, *f3, *f4, *slash;
@@ -731,13 +732,14 @@ static int label_boot(struct pxe_context *ctx, struct
pxe_label *label)
zboot_argc = 5;
}
- if (!bootm_argv[3])
+ if (!bootm_argv[3] && strcmp("-", label->fdt))
bootm_argv[3] = env_get("fdt_addr");
kernel_addr_r = genimg_get_kernel_addr(kernel_addr);
buf = map_sysmem(kernel_addr_r, 0);
- if (!bootm_argv[3] && genimg_get_format(buf) != IMAGE_FORMAT_FIT)
+ if (!bootm_argv[3] && genimg_get_format(buf) != IMAGE_FORMAT_FIT &&
+ strcmp("-", label->fdt))
bootm_argv[3] = env_get("fdtcontroladdr");
if (bootm_argv[3]) {
diff --git a/doc/develop/distro.rst b/doc/develop/distro.rst
index 8016acad09..c81da8a0fd 100644
--- a/doc/develop/distro.rst
+++ b/doc/develop/distro.rst
@@ -81,6 +81,9 @@ as specified at `Boot Loader Specification`_:
* Does not document the fdtdir option, which automatically selects the DTB to
pass to the kernel.
+* If no fdt/fdtdir is provided, the U-Boot will pass its own device tree, and
+ if fdt is passed with ``-``, then device tree will not be used (legacy
booting).
+
See also doc/README.pxe under 'pxe file format'.
One example extlinux.conf generated by the Fedora installer is::
--
2.40.1
[PATCH v1 0/1] Fix booting kernels with ATAGS and extlinux
Currently, if boot with extlinux.conf and do not set the fdt U-Boot will provide its own device tree. This behavior is beneficial if the U-Boot device tree is in sync with Linux, but it totally halts the booting of pre-dtb kernels (3.4 for example) since it uses ATAGs. To fix this, pass `-` in the fdt extlinux field as a signal that no tree should be used. Tested with 3.4 legacy kernel and mainline 6.7 kernel on P895 (lg_x3 board). Svyatoslav Ryhel (1): boot: pxe_utils: skip fdt setup in case legacy kernel is booted boot/pxe_utils.c | 8 +--- doc/develop/distro.rst | 3 +++ 2 files changed, 8 insertions(+), 3 deletions(-) -- 2.40.1
[PATCH 1/1] efi_selftest: add missing line feed in efi_selftest_miniapp_exit
If an error occurs we may see an output like:
EFI application calling Exit
Could not open loaded image protocolLoaded image protocol missing
Add the missing line feed.
Signed-off-by: Heinrich Schuchardt
---
lib/efi_selftest/efi_selftest_miniapp_exit.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/efi_selftest/efi_selftest_miniapp_exit.c
b/lib/efi_selftest/efi_selftest_miniapp_exit.c
index 8b2e60cc711..0909a5ca748 100644
--- a/lib/efi_selftest/efi_selftest_miniapp_exit.c
+++ b/lib/efi_selftest/efi_selftest_miniapp_exit.c
@@ -39,7 +39,7 @@ static efi_status_t EFIAPI check_loaded_image_protocol
NULL, EFI_OPEN_PROTOCOL_GET_PROTOCOL);
if (ret != EFI_SUCCESS) {
cout->output_string(cout,
- u"Could not open loaded image protocol");
+ u"Could not open loaded image protocol\n");
return ret;
}
if ((void *)check_loaded_image_protocol <
--
2.43.0
Re: [RFC PATCH v3 02/15] misc: fs-loader: Use fw_storage_interface instead of storage_interface
On 12:19-20240124, MD Danish Anwar wrote:
> The fs-loader driver reads env storage_interface and uses it to load
> firmware file into memory using the medium set by env. Update the driver
> to use env fw_storage_interface as this variable is only used to load
> firmwares. The env storage_interface will act as fallback so that the
> existing implementations do not break.
>
> Also update the FS Loader documentation accordingly.
>
> Signed-off-by: MD Danish Anwar
> ---
> doc/develop/driver-model/fs_firmware_loader.rst | 5 -
> drivers/misc/fs_loader.c| 5 -
> 2 files changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/doc/develop/driver-model/fs_firmware_loader.rst
> b/doc/develop/driver-model/fs_firmware_loader.rst
> index 149b8b436e..410cc1442d 100644
> --- a/doc/develop/driver-model/fs_firmware_loader.rst
> +++ b/doc/develop/driver-model/fs_firmware_loader.rst
> @@ -98,8 +98,11 @@ through the U-Boot environment variable during run time.
>
> For examples:
>
> +fw_storage_interface:
> + Firmware storage interface, it can be "mmc", "usb", "sata" or "ubi".
> storage_interface:
> - Storage interface, it can be "mmc", "usb", "sata" or "ubi".
> + Storage interface, it can be "mmc", "usb", "sata" or "ubi". This acts
> + as a fallback if fw_storage_interface is not set.
> fw_dev_part:
>Block device number and its partition, it can be "0:1".
> fw_ubi_mtdpart:
> diff --git a/drivers/misc/fs_loader.c b/drivers/misc/fs_loader.c
> index 1ffc199ba1..3798dab5b6 100644
> --- a/drivers/misc/fs_loader.c
> +++ b/drivers/misc/fs_loader.c
> @@ -153,7 +153,10 @@ static int fw_get_filesystem_firmware(struct udevice
> *dev)
> char *storage_interface, *dev_part, *ubi_mtdpart, *ubi_volume;
> int ret;
>
> - storage_interface = env_get("storage_interface");
> + storage_interface = env_get("fw_storage_interface");
> + if (!storage_interface)
> + storage_interface = env_get("storage_interface");
> +
> dev_part = env_get("fw_dev_part");
> ubi_mtdpart = env_get("fw_ubi_mtdpart");
> ubi_volume = env_get("fw_ubi_volume");
> --
> 2.34.1
>
You should move these specific patches out of the series and debate on
their merits seperately. mixing things like these in a single series
that needs to go to multiple u-boot custodians just creates problems for
everyone.
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
Re: [PATCH v1 1/1] net: ti: am65-cpsw-nuss: Remove incorrect RGMII_ID bit functionality
Hi Roger,
Thanks for your review.
Hi Ken,
On 16/01/2024 22:01, Ken Sloat wrote:
The CPSW implementations on the AM6x platforms do not support the
selectable RGMII TX clk delay functionality via the RGMII_ID_MODE bit as
the earlier platforms did. According to various TI datasheets, reference
manuals, hardware design guides and TI forum posts from TI, this bit is
"not timed, tested, or characterized. RGMII_ID is enabled by default and
the register bit reserved."
The driver implementation today however, will incorrectly set this bit
whenever the interface mode is in RGMII_ID or RGMII_TXID.
To fix this, remove any statement setting this bit, and moreover, mask
bits 31:4 as these are all reserved.
See:
https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1211306/am625-enet1_ctrl_rgmii_id-_mode
https://www.ti.com/lit/pdf/spruiv7 (Rev. B Figure 14-1717>
https://www.ti.com/lit/gpn/am625 (Rev. B Figure 7-31 Note A)
https://www.ti.com/lit/an/sprad05b/sprad05b.pdf (Rev. B Section 7.4)
Thanks for the patch. Some comments below.
Signed-off-by: Ken Sloat
---
drivers/net/ti/am65-cpsw-nuss.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ti/am65-cpsw-nuss.c b/drivers/net/ti/am65-cpsw-nuss.c
index 18a33c4c0e..51c432408f 100644
--- a/drivers/net/ti/am65-cpsw-nuss.c
+++ b/drivers/net/ti/am65-cpsw-nuss.c
@@ -256,7 +256,6 @@ static int am65_cpsw_gmii_sel_k3(struct am65_cpsw_priv
*priv,
{
struct udevice *dev = priv->dev;
u32 offset, reg, phandle;
- bool rgmii_id = false;
fdt_addr_t gmii_sel;
u32 mode = 0;
ofnode node;
@@ -296,7 +295,6 @@ static int am65_cpsw_gmii_sel_k3(struct am65_cpsw_priv
*priv,
case PHY_INTERFACE_MODE_RGMII_ID:
case PHY_INTERFACE_MODE_RGMII_TXID:
mode = AM65_GMII_SEL_MODE_RGMII;
- rgmii_id = true;
break;
case PHY_INTERFACE_MODE_SGMII:
@@ -313,15 +311,13 @@ static int am65_cpsw_gmii_sel_k3(struct am65_cpsw_priv
*priv,
break;
};
- if (rgmii_id)
- mode |= AM65_GMII_SEL_RGMII_IDMODE;
-
- reg = mode;
+ /* bits 31:4 are reserved */
Updated documentation is still wrong. Reserved bits should be Read only and
should
always read 0. In updated TRM it doesn't show reserved bits as read-only and
states
read value is 1.
Bit 4 is clearly read/write so it cannot be treated as reserved. But setting it
to 1 is not supported.
If bootROM or some other software set it to 1 then it will remain 1 and we
cannot
rely on it to be always 0. That's why it shouldn't be treated as reserved.
On AM65 bits 31:5 and 3:2 are reserved (read only 0).
Bit 4 is still r/w but setting 1 is not supported.
+ reg = (GENMASK(31, 4) & reg) | mode;
As reserved bits will always read 0 this mask is not required.
What we do need to do is always clear bit 4.
So
#define AM6X_GMII_SEL_MODE_SEL_MASK GENMASK(2:0)
/* RGMII_ID_MODE = 1 is not supported */
reg &= ~AM65_GMII_SEL_RGMII_IDMODE;
reg &= ~AM6X_GMII_SEL_MODE_SEL_MASK;
reg |= mode;
I like this first approach, as it is clear what is happening and could
account for future use of other currently reserved bits in this register.
Or simply this would have worked as we don't really set bit 4 in mode.
reg = mode;
dev_dbg(dev, "gmii_sel PHY mode: %u, new gmii_sel: %08x\n",
phy_mode, reg);
writel(reg, gmii_sel);
- reg = readl(gmii_sel);
+ reg = GENMASK(3, 0) & readl(gmii_sel);
should be GENMASK(2, 0);
You are right thanks
but now we can use AM6X_GMII_SEL_MODE_SEL_MASK here instead.
if (reg != mode) {
dev_err(dev,
"gmii_sel PHY mode NOT SET!: requested: %08x, gmii_sel:
%08x\n",
--
cheers,
-roger
I will work on a v2, thanks again.
Sincerely,
Ken Sloat
Re: [PATCH 1/2] env: ti: mmc: add save_uenv command
On 12:56-20240124, Manorit Chawdhry wrote:
> This is to make easier development with uEnv.txt to update from the
> board on the fly from u-boot to MMC boot media.
>
> Signed-off-by: Manorit Chawdhry
> ---
> include/env/ti/mmc.env | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/include/env/ti/mmc.env b/include/env/ti/mmc.env
> index 0256a2d2aaca..886e4cab36fe 100644
> --- a/include/env/ti/mmc.env
> +++ b/include/env/ti/mmc.env
> @@ -34,6 +34,9 @@ envboot=if mmc dev ${mmcdev}; then
> fi;
> fi;
>fi;
> +save_uenv=
> + env export -t $loadaddr $save_to_env save_to_env;
> + fatwrite mmc ${mmcdev} ${loadaddr} ${bootenvfile} ${filesize};
Please NO! saveenv has ability.. why not use that? it is better to
improve the commands themselves.
> mmcloados=
> if test ${boot_fdt} = yes || test ${boot_fdt} = try; then
> if run get_fdt_mmc; then
>
> --
> 2.43.0
>
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
Re: [PATCH V3] firmware: ti_sci: fix the secure_hdr in do_xfer
On 18:37-20240124, Dhruva Gole wrote:
> The secure_hdr needs to be 0 init-ed however this was never being put
> into the secure_buf, leading to possibility of the first 4 bytes of
> secure_buf being possibly garbage.
>
> Fix this by initialising the secure_hdr itself to the secure_buf
> location, thus when we make it 0, it automatically ensures the first 4
> bytes are 0.
>
> Fixes: 32cd25128bd849 ("firmware: Add basic support for TI System Control
> Interface (TI SCI)")
> Signed-off-by: Dhruva Gole
> ---
>
> Boot tested for sanity on AM62x SK
> https://gist.github.com/DhruvaG2000/724ceba3a0db03f4b0bff47de1160074
>
> Changelog:
> v2 --> v3
> Address Kamlesh's comment on v2: use sizeof(struct ti_sci_secure_msg_hdr)
Lets finish discussing in:
https://lore.kernel.org/all/20240124163910.sp7gt56lihoujm7k@etching/
Responding to keep patchworks happy.
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
Re: [PATCH] firmware: ti_sci: fix the secure_hdr in do_xfer
On 23:07-20240124, Dhruva Gole wrote:
> On Jan 24, 2024 at 10:39:10 -0600, Nishanth Menon wrote:
> > On 18:38-20240124, Dhruva Gole wrote:
> > > On Jan 24, 2024 at 16:42:12 +0530, Kamlesh Gurudasani wrote:
> > > > Dhruva Gole writes:
> > > >
> > > > > The secure_hdr needs to be 0 init-ed however this was never being put
> > > > > into the secure_buf, leading to possibility of the first 4 bytes of
> > > > > secure_buf being possibly garbage.
> > > > >
> > > > > Fix this by initialising the secure_hdr itself to the secure_buf
> > > > > location, thus when we make it 0, it automatically ensures the first 4
> > > > > bytes are 0.
> > > > >
> > > > > Fixes: 32cd25128bd849 ("firmware: Add basic support for TI System
> > > > > Control Interface (TI SCI)")
> > > > > Signed-off-by: Dhruva Gole
> > > > > ---
> > > > >
> > > > > Boot tested for sanity on AM62x SK
> > > > > https://gist.github.com/DhruvaG2000/724ceba3a0db03f4b0bff47de1160074
> > > > >
> > > > > Cc: Nishanth Menon
> > > > > Cc: Tom Rini
> > > > >
> > > > > drivers/firmware/ti_sci.c | 6 +++---
> > > > > 1 file changed, 3 insertions(+), 3 deletions(-)
> > > > >
> > > > > diff --git a/drivers/firmware/ti_sci.c b/drivers/firmware/ti_sci.c
> > > > > index f5f659c11274..83ee8401a731 100644
> > > > > --- a/drivers/firmware/ti_sci.c
> > > > > +++ b/drivers/firmware/ti_sci.c
> > > > > @@ -236,13 +236,13 @@ static int ti_sci_do_xfer(struct ti_sci_info
> > > > > *info,
> > > > > {
> > > > > struct k3_sec_proxy_msg *msg = >tx_message;
> > > > > u8 secure_buf[info->desc->max_msg_size];
> > > > > - struct ti_sci_secure_msg_hdr secure_hdr;
> > > > > + struct ti_sci_secure_msg_hdr *secure_hdr = (struct
> > > > > ti_sci_secure_msg_hdr *)secure_buf;
> > > > > int ret;
> > > > >
> > > > > if (info->is_secure) {
> > > > > /* ToDo: get checksum of the entire message */
> > > > > - secure_hdr.checksum = 0;
> > > > > - secure_hdr.reserved = 0;
> > > > > + secure_hdr->checksum = 0;
> > > > > + secure_hdr->reserved = 0;
> > > > >
> > > > > memcpy(_buf[sizeof(secure_hdr)],xfer->tx_message.buf,
> > > > secure_hdr is pointer now, the value may be same but (struct
> > > > ti_sci_secure_msg_hdr) would make more sense
> > >
> > > Good catch Kamlesh! I have sent a new revision addressing this.
> > >
> >
> > Makes no sense why we have secure API support in U-Boot. what is using
> > this?
>
> In my understanding of generic K3 boot flow, things like proc_boot and
> even applying or removing of firewalls will need a secure channel to
> talk to TIFS right? From my understanding secure host can only talk to
> TIFS and make such requests hence secure API.
U-boot runs in NS world, you cant even talk to the Trustzone Sec proxy
without triggering a firewall violation.
https://software-dl.ti.com/tisci/esd/latest/2_tisci_msgs/general/TISCI_header.html?highlight=header#secure-messaging-header
"The Secure Messaging Header is only required when sending messages over
secure transport. Messages sent over non-secure transport must not
contain the secure messaging header."
btw, that checksum field should be renamed integ_check, but anyways..
So, I do not see a reason to even have that if condition in the first
place and what real bug was getting fixed in this patch.
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
Re: [PATCH] firmware: ti_sci: fix the secure_hdr in do_xfer
On Jan 24, 2024 at 10:39:10 -0600, Nishanth Menon wrote:
> On 18:38-20240124, Dhruva Gole wrote:
> > On Jan 24, 2024 at 16:42:12 +0530, Kamlesh Gurudasani wrote:
> > > Dhruva Gole writes:
> > >
> > > > The secure_hdr needs to be 0 init-ed however this was never being put
> > > > into the secure_buf, leading to possibility of the first 4 bytes of
> > > > secure_buf being possibly garbage.
> > > >
> > > > Fix this by initialising the secure_hdr itself to the secure_buf
> > > > location, thus when we make it 0, it automatically ensures the first 4
> > > > bytes are 0.
> > > >
> > > > Fixes: 32cd25128bd849 ("firmware: Add basic support for TI System
> > > > Control Interface (TI SCI)")
> > > > Signed-off-by: Dhruva Gole
> > > > ---
> > > >
> > > > Boot tested for sanity on AM62x SK
> > > > https://gist.github.com/DhruvaG2000/724ceba3a0db03f4b0bff47de1160074
> > > >
> > > > Cc: Nishanth Menon
> > > > Cc: Tom Rini
> > > >
> > > > drivers/firmware/ti_sci.c | 6 +++---
> > > > 1 file changed, 3 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/drivers/firmware/ti_sci.c b/drivers/firmware/ti_sci.c
> > > > index f5f659c11274..83ee8401a731 100644
> > > > --- a/drivers/firmware/ti_sci.c
> > > > +++ b/drivers/firmware/ti_sci.c
> > > > @@ -236,13 +236,13 @@ static int ti_sci_do_xfer(struct ti_sci_info
> > > > *info,
> > > > {
> > > > struct k3_sec_proxy_msg *msg = >tx_message;
> > > > u8 secure_buf[info->desc->max_msg_size];
> > > > - struct ti_sci_secure_msg_hdr secure_hdr;
> > > > + struct ti_sci_secure_msg_hdr *secure_hdr = (struct
> > > > ti_sci_secure_msg_hdr *)secure_buf;
> > > > int ret;
> > > >
> > > > if (info->is_secure) {
> > > > /* ToDo: get checksum of the entire message */
> > > > - secure_hdr.checksum = 0;
> > > > - secure_hdr.reserved = 0;
> > > > + secure_hdr->checksum = 0;
> > > > + secure_hdr->reserved = 0;
> > > >
> > > > memcpy(_buf[sizeof(secure_hdr)],xfer->tx_message.buf,
> > > secure_hdr is pointer now, the value may be same but (struct
> > > ti_sci_secure_msg_hdr) would make more sense
> >
> > Good catch Kamlesh! I have sent a new revision addressing this.
> >
>
> Makes no sense why we have secure API support in U-Boot. what is using
> this?
In my understanding of generic K3 boot flow, things like proc_boot and
even applying or removing of firewalls will need a secure channel to
talk to TIFS right? From my understanding secure host can only talk to
TIFS and make such requests hence secure API.
--
Best regards,
Dhruva Gole
REGRESSION: [PATCH 5/9] toradex: Use checkboard() instead of show_board_info()
Hi Simon Sorry, I missed this one, also due to a longer Xmas/New Year and later skiing vacation. On Sun, 2023-11-12 at 19:58 -0700, Simon Glass wrote: > Boards can use a sysinfo driver if a particular model name is needed. Okay, but so far we did print more than just a model name: On Apalis/Colibri: Model: Toradex 0028 Apalis iMX6Q 2GB IT V1.1D Serial#: 10867499 On Verdin: Model: Toradex 0058 Verdin iMX8M Plus Quad 4GB WB IT V1.1A Serial#: 14772913 Carrier: Toradex Dahlia V1.1A, Serial# 10870316 Optionally there would even be display adapters with potentially more model (serial) information. Now with your change we get the following: On Apalis/Colibri: Model: Toradex Apalis iMX6Q/D Module on Apalis Evaluation Board Model: Toradex Apalis iMX6 Quad 2GB IT Model: Toradex 0028 Apalis iMX6Q 2GB IT V1.1D Serial#: 11211073 The first line gets printed from the information in the device tree, the second Line from the fall-back in our board file (which so far was only used for the case when we failed reading the ConfigBlock) and the third and fourth lines are the previous information. Ugly, but so far so good. On Verdin: Model: Toradex Verdin iMX8M Plus WB on Verdin Development Board Here only the device tree information gets printed and the ConfigBlock is not even read at all which subsequently fails detecting the variant (e.g. Wi-Fi vs. non-Wi-Fi) and later Ethernet fails due to an invalid MAC address. This does not look good... Anyway, I don't propose to just revert your work but instead looked into converting our previous show_board_info (now tdx_checkboard) to a proper sysinfo driver. The basics actually worked quite smoothly but we would need more than just SYSINFO_ID_BOARD_MODEL, just like you do with CONFIG_SYSINFO_EXTRA. Of course, I could just do a CONFIG_SYSINFO_TORADEX, with e.g. SYSINFO_ID_BOARD_SERIAL and optionally SYSINFO_ID_BOARD_CARRIER or something but maybe a more generic way of extending sysinfo would make more sense. What do you think? > Update this board to use checkboard() directly, rather than having a > weak function laid on top of a weak function. Unfortunately, as mentioned above, this does not quite lead to any desired behaviour. > Make all the checkboard() functions call the new tdx_checkboard() so > that the same information is displayed. Not quite. > Signed-off-by: Simon Glass > --- > > board/toradex/apalis-imx8/apalis-imx8.c | 2 +- > board/toradex/apalis-tk1/apalis-tk1.c | 2 +- > board/toradex/apalis_imx6/apalis_imx6.c | 3 ++- > board/toradex/apalis_t30/apalis_t30.c | 2 +- > board/toradex/colibri-imx6ull/colibri-imx6ull.c | 2 +- > board/toradex/colibri-imx8x/colibri-imx8x.c | 2 +- > board/toradex/colibri_imx6/colibri_imx6.c | 3 ++- > board/toradex/colibri_imx7/colibri_imx7.c | 2 +- > board/toradex/colibri_t20/colibri_t20.c | 2 +- > board/toradex/colibri_t30/colibri_t30.c | 2 +- > board/toradex/colibri_vf/colibri_vf.c | 2 +- > board/toradex/common/tdx-common.c | 2 +- > board/toradex/common/tdx-common.h | 1 + > 13 files changed, 15 insertions(+), 12 deletions(-) [snip] Cheers Marcel
Re: [PATCH] firmware: ti_sci: fix the secure_hdr in do_xfer
On 18:38-20240124, Dhruva Gole wrote:
> On Jan 24, 2024 at 16:42:12 +0530, Kamlesh Gurudasani wrote:
> > Dhruva Gole writes:
> >
> > > The secure_hdr needs to be 0 init-ed however this was never being put
> > > into the secure_buf, leading to possibility of the first 4 bytes of
> > > secure_buf being possibly garbage.
> > >
> > > Fix this by initialising the secure_hdr itself to the secure_buf
> > > location, thus when we make it 0, it automatically ensures the first 4
> > > bytes are 0.
> > >
> > > Fixes: 32cd25128bd849 ("firmware: Add basic support for TI System Control
> > > Interface (TI SCI)")
> > > Signed-off-by: Dhruva Gole
> > > ---
> > >
> > > Boot tested for sanity on AM62x SK
> > > https://gist.github.com/DhruvaG2000/724ceba3a0db03f4b0bff47de1160074
> > >
> > > Cc: Nishanth Menon
> > > Cc: Tom Rini
> > >
> > > drivers/firmware/ti_sci.c | 6 +++---
> > > 1 file changed, 3 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/firmware/ti_sci.c b/drivers/firmware/ti_sci.c
> > > index f5f659c11274..83ee8401a731 100644
> > > --- a/drivers/firmware/ti_sci.c
> > > +++ b/drivers/firmware/ti_sci.c
> > > @@ -236,13 +236,13 @@ static int ti_sci_do_xfer(struct ti_sci_info *info,
> > > {
> > > struct k3_sec_proxy_msg *msg = >tx_message;
> > > u8 secure_buf[info->desc->max_msg_size];
> > > - struct ti_sci_secure_msg_hdr secure_hdr;
> > > + struct ti_sci_secure_msg_hdr *secure_hdr = (struct
> > > ti_sci_secure_msg_hdr *)secure_buf;
> > > int ret;
> > >
> > > if (info->is_secure) {
> > > /* ToDo: get checksum of the entire message */
> > > - secure_hdr.checksum = 0;
> > > - secure_hdr.reserved = 0;
> > > + secure_hdr->checksum = 0;
> > > + secure_hdr->reserved = 0;
> > > memcpy(_buf[sizeof(secure_hdr)],xfer->tx_message.buf,
> > secure_hdr is pointer now, the value may be same but (struct
> > ti_sci_secure_msg_hdr) would make more sense
>
> Good catch Kamlesh! I have sent a new revision addressing this.
>
Makes no sense why we have secure API support in U-Boot. what is using
this?
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
Re: [PATCH v6 0/7] board: siemens: clean up subfolders
On Wed, Jan 24, 2024 at 03:43:48PM +0100, Enrico Leto wrote: > The common folder was initialially created for the common parts of > the products based on draco-am355x board family. We have the > product lines 'pxm2', 'rut' and the base line unfortunately named > 'draco'! Adding the new capricorn-imx8 board family, the files > were enhanced without cleanup. > > Simplify first EEPROM probe and access that implements both i2c > with & without driver model. Use abstraction functions for this. > > Move all am355x specifics to a new file 'board_am335x'. > > Clean-up includes, config checks, maintainer. > > Signed-off-by: Enrico Leto Thanks, this is indeed building for me as well and I'll apply it soon. In terms of future work, many of the siemens platforms need to migrate to using DM_I2C, and should also move from using OF_EMBED to using OF_SEPARATE if possible. -- Tom signature.asc Description: PGP signature
[PATCH v6 5/7] siemens: board: clean up products folders vs common
The common folder was initialially created for the common parts of the
products based on draco-am355x board family. These are the product lines
'pxm2', 'rut' and the base line named 'draco'!
Adding the new capricorn-imx8 board family, common was enhanced without
cleanup.
- rename 'common/board.c' to 'common/board_am335x.c'
- add 'common/board_am335x.h' for export to the product lines
Reviewed-by: Alexander Sverdlin
Signed-off-by: Enrico Leto
---
.../common/{board.c => board_am335x.c}| 7 ++--
board/siemens/common/board_am335x.h | 39 +++
board/siemens/draco/Makefile | 1 +
board/siemens/draco/board.c | 8 ++--
board/siemens/draco/board.h | 31 +++
board/siemens/pxm2/MAINTAINERS| 2 +-
board/siemens/pxm2/Makefile | 1 +
board/siemens/pxm2/board.c| 10 ++---
board/siemens/pxm2/board.h| 21 --
board/siemens/rut/MAINTAINERS | 2 +-
board/siemens/rut/Makefile| 1 +
board/siemens/rut/board.c | 10 ++---
board/siemens/rut/board.h | 21 --
13 files changed, 64 insertions(+), 90 deletions(-)
rename board/siemens/common/{board.c => board_am335x.c} (98%)
create mode 100644 board/siemens/common/board_am335x.h
delete mode 100644 board/siemens/pxm2/board.h
delete mode 100644 board/siemens/rut/board.h
diff --git a/board/siemens/common/board.c b/board/siemens/common/board_am335x.c
similarity index 98%
rename from board/siemens/common/board.c
rename to board/siemens/common/board_am335x.c
index e5a42d734bb..c55ca983bdd 100644
--- a/board/siemens/common/board.c
+++ b/board/siemens/common/board_am335x.c
@@ -33,6 +33,7 @@
#include
#include
#include
+#include "board_am335x.h"
#include "eeprom.h"
#include "factoryset.h"
@@ -56,7 +57,7 @@ void set_mux_conf_regs(void)
gd->have_console = 1;
siemens_ee_setup();
- if (read_eeprom() < 0)
+ if (draco_read_eeprom() < 0)
puts("Could not get board ID.\n");
enable_board_pin_mux();
@@ -64,8 +65,8 @@ void set_mux_conf_regs(void)
void sdram_init(void)
{
- spl_siemens_board_init();
- board_init_ddr();
+ spl_draco_board_init();
+ draco_init_ddr();
return;
}
diff --git a/board/siemens/common/board_am335x.h
b/board/siemens/common/board_am335x.h
new file mode 100644
index 000..3a20352d457
--- /dev/null
+++ b/board/siemens/common/board_am335x.h
@@ -0,0 +1,39 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Board definitions for draco products
+ *
+ * (C) Copyright 2013 Siemens Schweiz AG
+ * (C) Heiko Schocher, DENX Software Engineering, h...@denx.de.
+ *
+ * Based on:
+ * TI AM335x boards information header
+ * u-boot:/board/ti/am335x/board.h
+ *
+ * Copyright (C) 2011, Texas Instruments, Incorporated - http://www.ti.com/
+ */
+
+#ifndef _BOARD_AM335X_H_
+#define _BOARD_AM335X_H_
+
+#include "eeprom.h"
+
+/* Common functions with product specific implementation */
+void spl_draco_board_init(void);
+void draco_init_ddr(void);
+int draco_read_eeprom(void);
+
+#ifdef CONFIG_SPL_BUILD
+/* Mux for init: uart?, i2c0 to read the main EEPROM */
+void enable_uart0_pin_mux(void);
+void enable_uart1_pin_mux(void);
+void enable_uart2_pin_mux(void);
+void enable_uart3_pin_mux(void);
+void enable_uart4_pin_mux(void);
+void enable_uart5_pin_mux(void);
+void enable_i2c0_pin_mux(void);
+
+/* Main mux function to enable other pinmux required on the board */
+void enable_board_pin_mux(void);
+#endif /* CONFIG_SPL_BUILD */
+
+#endif /* _BOARD_AM335X_H_ */
diff --git a/board/siemens/draco/Makefile b/board/siemens/draco/Makefile
index 1d0cb82bcb6..aae536472c5 100644
--- a/board/siemens/draco/Makefile
+++ b/board/siemens/draco/Makefile
@@ -14,6 +14,7 @@ obj-y := mux.o
endif
obj-y += board.o
+obj-y += ../common/board_am335x.o
obj-y += ../common/eeprom.o
ifndef CONFIG_SPL_BUILD
obj-y += ../common/factoryset.o
diff --git a/board/siemens/draco/board.c b/board/siemens/draco/board.c
index d108d3e49db..2412a04a9a1 100644
--- a/board/siemens/draco/board.c
+++ b/board/siemens/draco/board.c
@@ -159,7 +159,7 @@ static int draco_read_nand_geometry(void)
/*
* Read header information from EEPROM into global structure.
*/
-static int read_eeprom(void)
+int draco_read_eeprom(void)
{
/* Read Siemens eeprom data (DDR3) */
if (siemens_ee_read_data(SIEMENS_EE_ADDR_DDR3, (uchar *),
@@ -195,7 +195,7 @@ static int read_eeprom(void)
return draco_read_nand_geometry();
}
-static void board_init_ddr(void)
+void draco_init_ddr(void)
{
struct emif_regs draco_ddr3_emif_reg_data = {
.zq_config = 0x50074BE4,
@@ -242,7 +242,7 @@ struct ctrl_ioregs draco_ddr3_ioregs = {
_ddr3_cmd_ctrl_data, _ddr3_emif_reg_data, 0);
}
-static void spl_siemens_board_init(void)
+void
[PATCH v6 4/7] siemens: board: etamin: remove deprecated nand config
NAND was used in the early development phase of etamin. The board runs now
on MMC. This setting is no more used -> remove to simplify the board file.
Further clean-up of etamin should remove all NAND settings. Complete clean-
up of etamin board will take place in a separate patch serie.
Signed-off-by: Enrico Leto
---
board/siemens/common/board.c | 4
board/siemens/draco/Kconfig | 2 --
board/siemens/draco/board.c | 26 --
3 files changed, 32 deletions(-)
diff --git a/board/siemens/common/board.c b/board/siemens/common/board.c
index e412858c4a9..e5a42d734bb 100644
--- a/board/siemens/common/board.c
+++ b/board/siemens/common/board.c
@@ -93,10 +93,6 @@ int board_init(void)
gpmc_init();
-#if CONFIG_IS_ENABLED(NAND_CS_INIT)
- board_nand_cs_init();
-#endif
-
return 0;
}
#endif /* #ifndef CONFIG_SPL_BUILD */
diff --git a/board/siemens/draco/Kconfig b/board/siemens/draco/Kconfig
index 0cdf5bc9812..9d45c4239be 100644
--- a/board/siemens/draco/Kconfig
+++ b/board/siemens/draco/Kconfig
@@ -44,6 +44,4 @@ config SYS_SOC
config SYS_CONFIG_NAME
default "draco-etamin"
-config NAND_CS_INIT
- def_bool y
endif
diff --git a/board/siemens/draco/board.c b/board/siemens/draco/board.c
index 30ad9d7ab3a..d108d3e49db 100644
--- a/board/siemens/draco/board.c
+++ b/board/siemens/draco/board.c
@@ -358,30 +358,4 @@ U_BOOT_CMD(
#endif /* #if defined(CONFIG_DRIVER_TI_CPSW) */
#endif /* #if (defined(CONFIG_DRIVER_TI_CPSW) && !defined(CONFIG_SPL_BUILD)) */
-#if CONFIG_IS_ENABLED(NAND_CS_INIT)
-#define ETAMIN_NAND_GPMC_CONFIG1 0x0800
-#define ETAMIN_NAND_GPMC_CONFIG2 0x001e1e00
-#define ETAMIN_NAND_GPMC_CONFIG3 0x001e1e00
-#define ETAMIN_NAND_GPMC_CONFIG4 0x16051807
-#define ETAMIN_NAND_GPMC_CONFIG5 0x00151e1e
-#define ETAMIN_NAND_GPMC_CONFIG6 0x16000f80
-
-/* GPMC definitions for second nand cs1 */
-static const u32 gpmc_nand_config[] = {
- ETAMIN_NAND_GPMC_CONFIG1,
- ETAMIN_NAND_GPMC_CONFIG2,
- ETAMIN_NAND_GPMC_CONFIG3,
- ETAMIN_NAND_GPMC_CONFIG4,
- ETAMIN_NAND_GPMC_CONFIG5,
- ETAMIN_NAND_GPMC_CONFIG6,
- /*CONFIG7- computed as params */
-};
-
-static void board_nand_cs_init(void)
-{
- enable_gpmc_cs_config(gpmc_nand_config, _cfg->cs[1],
- 0x1800, GPMC_SIZE_16M);
-}
-#endif
-
#include "../common/board.c"
--
2.30.2
[PATCH v6 7/7] siemens: factoryset: use correct config for soc specific implementation
Adding the capricorn board family some parts diverge from draco family.
The switches used were not pertinent and need to be enhanced for each new
board of the capricorn family. Replace them through the SOC name 'AM33XX'
and 'IMX8'.
Signed-off-by: Enrico Leto
---
board/siemens/common/factoryset.c | 6 +++---
board/siemens/common/factoryset.h | 2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/board/siemens/common/factoryset.c
b/board/siemens/common/factoryset.c
index b20af95d13d..a250ccfe252 100644
--- a/board/siemens/common/factoryset.c
+++ b/board/siemens/common/factoryset.c
@@ -11,7 +11,7 @@
#include
#include
#include
-#if !CONFIG_IS_ENABLED(TARGET_GIEDI) && !CONFIG_IS_ENABLED(TARGET_DENEB)
+#if CONFIG_IS_ENABLED(AM33XX)
#include
#endif
#include "eeprom.h"
@@ -197,7 +197,7 @@ int factoryset_read_eeprom(int i2c_addr)
cp1 += 3;
}
-#if CONFIG_IS_ENABLED(TARGET_GIEDI) || CONFIG_IS_ENABLED(TARGET_DENEB)
+#if CONFIG_IS_ENABLED(IMX8)
/* get mac address for WLAN */
if (get_factory_record_val(cp, size, (uchar *)"WLAN1", (uchar *)"mac",
buf, MAX_STRING_LENGTH) > 0) {
@@ -304,7 +304,7 @@ static int factoryset_mac_env_set(void)
eth_env_set_enetaddr("ethaddr", mac_addr);
-#if CONFIG_IS_ENABLED(TARGET_GIEDI) || CONFIG_IS_ENABLED(TARGET_DENEB)
+#if CONFIG_IS_ENABLED(IMX8)
eth_env_set_enetaddr("eth1addr", mac_addr);
/* wlan mac */
diff --git a/board/siemens/common/factoryset.h
b/board/siemens/common/factoryset.h
index 8fa6c3b3d3b..ee8bcd0f20d 100644
--- a/board/siemens/common/factoryset.h
+++ b/board/siemens/common/factoryset.h
@@ -11,7 +11,7 @@
struct factorysetcontainer {
uchar mac[6];
-#if CONFIG_IS_ENABLED(TARGET_GIEDI) || CONFIG_IS_ENABLED(TARGET_DENEB)
+#if CONFIG_IS_ENABLED(IMX8)
uchar mac_wlan[6];
#endif
int usb_vendor_id;
--
2.30.2
[PATCH v6 2/7] siemens: eeprom: simplify setup & read
Since we have boards using the driver model or not for i2c, use abstraction
function to probe the i2c, check the EEPROM and read from EEPROM.
Signed-off-by: Enrico Leto
---
board/siemens/capricorn/Makefile | 1 +
board/siemens/common/board.c | 8 ++--
board/siemens/common/eeprom.c | 52 +
board/siemens/common/eeprom.h | 3 ++
board/siemens/common/factoryset.c | 63 +--
board/siemens/draco/Makefile | 1 +
board/siemens/draco/board.c | 23 ---
board/siemens/draco/mux.c | 2 +-
board/siemens/pxm2/Makefile | 1 +
board/siemens/pxm2/board.c| 2 +-
board/siemens/pxm2/mux.c | 2 +-
board/siemens/rut/Makefile| 1 +
board/siemens/rut/board.c | 2 +-
13 files changed, 84 insertions(+), 77 deletions(-)
create mode 100644 board/siemens/common/eeprom.c
diff --git a/board/siemens/capricorn/Makefile b/board/siemens/capricorn/Makefile
index d5846cc8e3c..4dafac10829 100644
--- a/board/siemens/capricorn/Makefile
+++ b/board/siemens/capricorn/Makefile
@@ -4,6 +4,7 @@
#
obj-y += board.o
+obj-y += ../common/eeprom.o
ifdef CONFIG_SPL_BUILD
obj-y += spl.o
diff --git a/board/siemens/common/board.c b/board/siemens/common/board.c
index 420c4965816..e412858c4a9 100644
--- a/board/siemens/common/board.c
+++ b/board/siemens/common/board.c
@@ -29,7 +29,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -39,6 +38,7 @@
DECLARE_GLOBAL_DATA_PTR;
+
#ifdef CONFIG_SPL_BUILD
void set_uart_mux_conf(void)
{
@@ -49,12 +49,13 @@ void set_mux_conf_regs(void)
{
/* Initalize the board header */
enable_i2c0_pin_mux();
- i2c_set_bus_num(0);
/* enable early the console */
gd->baudrate = CONFIG_BAUDRATE;
serial_init();
gd->have_console = 1;
+
+ siemens_ee_setup();
if (read_eeprom() < 0)
puts("Could not get board ID.\n");
@@ -79,8 +80,7 @@ int board_init(void)
#if defined(CONFIG_HW_WATCHDOG)
hw_watchdog_init();
#endif /* defined(CONFIG_HW_WATCHDOG) */
- i2c_set_bus_num(0);
- if (read_eeprom() < 0)
+ if (siemens_ee_setup() < 0)
puts("Could not get board ID.\n");
#ifdef CONFIG_MACH_TYPE
gd->bd->bi_arch_number = CONFIG_MACH_TYPE;
diff --git a/board/siemens/common/eeprom.c b/board/siemens/common/eeprom.c
new file mode 100644
index 000..fc93df91d52
--- /dev/null
+++ b/board/siemens/common/eeprom.c
@@ -0,0 +1,52 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ *
+ * Read EEPROM data
+ * (C) Copyright 2024 Siemens AG
+ */
+
+#include
+#include
+#include "eeprom.h"
+
+#if CONFIG_IS_ENABLED(DM_I2C)
+static struct udevice *i2c_dev;
+#endif
+
+/* Probe I2C and set-up EEPROM */
+int siemens_ee_setup(void)
+{
+#if CONFIG_IS_ENABLED(DM_I2C)
+ struct udevice *bus;
+ int ret;
+
+ ret = uclass_get_device_by_seq(UCLASS_I2C, SIEMENS_EE_I2C_BUS, );
+ if (ret)
+ goto err;
+
+ ret = dm_i2c_probe(bus, SIEMENS_EE_I2C_ADDR, 0, _dev);
+ if (ret)
+ goto err;
+ if (i2c_set_chip_offset_len(i2c_dev, 2))
+ goto err;
+#else
+ i2c_set_bus_num(SIEMENS_EE_I2C_BUS);
+ if (i2c_probe(SIEMENS_EE_I2C_ADDR))
+ goto err;
+#endif
+ return 0;
+
+err:
+ printf("Could not probe the EEPROM; something fundamentally wrong on
the I2C bus.\n");
+ return 1;
+}
+
+/* Read data from EEPROM */
+int siemens_ee_read_data(uint address, uchar *buffer, int len)
+{
+#if CONFIG_IS_ENABLED(DM_I2C)
+ return dm_i2c_read(i2c_dev, address, buffer, len);
+#else
+ return i2c_read(SIEMENS_EE_I2C_ADDR, address, 2, buffer, len);
+#endif
+}
diff --git a/board/siemens/common/eeprom.h b/board/siemens/common/eeprom.h
index a21d42789a5..a5ef5abbafd 100644
--- a/board/siemens/common/eeprom.h
+++ b/board/siemens/common/eeprom.h
@@ -18,4 +18,7 @@
#define SIEMENS_EE_ADDR_CHIP 0x120
#define SIEMENS_EE_ADDR_FACTORYSET 0x400
+int siemens_ee_setup(void);
+int siemens_ee_read_data(uint address, uchar *buffer, int len);
+
#endif /* _COMMON_EEPROM_H_ */
diff --git a/board/siemens/common/factoryset.c
b/board/siemens/common/factoryset.c
index b5befab9f52..4a1277340a7 100644
--- a/board/siemens/common/factoryset.c
+++ b/board/siemens/common/factoryset.c
@@ -148,39 +148,14 @@ int factoryset_read_eeprom(int i2c_addr)
int i, pages = 0, size = 0;
unsigned char eeprom_buf[0x3c00], hdr[4], buf[MAX_STRING_LENGTH];
unsigned char *cp, *cp1;
-#if CONFIG_IS_ENABLED(DM_I2C)
- struct udevice *bus, *dev;
- int ret;
-#endif
#if defined(CONFIG_DFU_OVER_USB)
factory_dat.usb_vendor_id = CONFIG_USB_GADGET_VENDOR_NUM;
factory_dat.usb_product_id = CONFIG_USB_GADGET_PRODUCT_NUM;
#endif
-#if CONFIG_IS_ENABLED(DM_I2C)
- ret = uclass_get_device_by_seq(UCLASS_I2C, SIEMENS_EE_I2C_BUS, );
- if (ret)
-
[PATCH v6 6/7] siemens: board: clean up includes
Many includes were not removed when code parts were moved or removed.
Signed-off-by: Enrico Leto
---
board/siemens/capricorn/board.c | 1 -
board/siemens/common/board_am335x.c | 19 +--
board/siemens/common/factoryset.c | 12 ++--
board/siemens/draco/board.c | 25 ++---
board/siemens/draco/mux.c | 4 +---
board/siemens/pxm2/board.c | 26 ++
board/siemens/pxm2/mux.c| 4 +---
board/siemens/rut/board.c | 25 +
board/siemens/rut/mux.c | 4 +---
9 files changed, 23 insertions(+), 97 deletions(-)
diff --git a/board/siemens/capricorn/board.c b/board/siemens/capricorn/board.c
index 5f7e2b1e899..0d66a75bbfa 100644
--- a/board/siemens/capricorn/board.c
+++ b/board/siemens/capricorn/board.c
@@ -22,7 +22,6 @@
#include
#include
#include
-#include
#include
#ifndef CONFIG_SPL
#include
diff --git a/board/siemens/common/board_am335x.c
b/board/siemens/common/board_am335x.c
index c55ca983bdd..445af9ddbf6 100644
--- a/board/siemens/common/board_am335x.c
+++ b/board/siemens/common/board_am335x.c
@@ -9,29 +9,12 @@
* Copyright (C) 2011, Texas Instruments, Incorporated - https://www.ti.com/
*/
-#include
#include
-#include
-#include
-#include
-#include
#include
-#include
-#include
-#include
-#include
-#include
+#include
#include
-#include
-#include
#include
-#include
-#include
-#include
#include
-#include
-#include
-#include
#include
#include "board_am335x.h"
#include "eeprom.h"
diff --git a/board/siemens/common/factoryset.c
b/board/siemens/common/factoryset.c
index 4a1277340a7..b20af95d13d 100644
--- a/board/siemens/common/factoryset.c
+++ b/board/siemens/common/factoryset.c
@@ -7,21 +7,13 @@
#if !defined(CONFIG_SPL_BUILD)
-#include
#include
-#include
-#include
-#include
-#include
+#include
+#include
#include
#if !CONFIG_IS_ENABLED(TARGET_GIEDI) && !CONFIG_IS_ENABLED(TARGET_DENEB)
#include
#endif
-#include
-#include
-#include
-#include
-#include
#include "eeprom.h"
#include "factoryset.h"
diff --git a/board/siemens/draco/board.c b/board/siemens/draco/board.c
index 2412a04a9a1..fc3eb06ccf2 100644
--- a/board/siemens/draco/board.c
+++ b/board/siemens/draco/board.c
@@ -12,34 +12,21 @@
* Copyright (C) 2011, Texas Instruments, Incorporated - https://www.ti.com/
*/
-#include
#include
+#include
#include
-#include
#include
-#include
-#include
-#include
-#include
-#include
-#include
+#include
+#include
#include
-#include
-#include
-#include
+#include
#include
-#include
-#include
+#include
#include
-#include
-#include
-#include
-#include
-#include
+#include
#include "board.h"
#include "../common/eeprom.h"
#include "../common/factoryset.h"
-#include
#ifdef CONFIG_SPL_BUILD
static struct draco_baseboard_id __section(".data") settings;
diff --git a/board/siemens/draco/mux.c b/board/siemens/draco/mux.c
index 56d8f45c349..4149e628475 100644
--- a/board/siemens/draco/mux.c
+++ b/board/siemens/draco/mux.c
@@ -10,12 +10,10 @@
* Copyright (C) 2011 Texas Instruments Incorporated - https://www.ti.com/
*/
-#include
+#include
#include
#include
#include
-#include
-#include
#include "eeprom.h"
static struct module_pin_mux uart0_pin_mux[] = {
diff --git a/board/siemens/pxm2/board.c b/board/siemens/pxm2/board.c
index bff6d20251e..888c7c09baf 100644
--- a/board/siemens/pxm2/board.c
+++ b/board/siemens/pxm2/board.c
@@ -12,35 +12,21 @@
* Copyright (C) 2011, Texas Instruments, Incorporated - https://www.ti.com/
*/
-#include
+#include
#include
-#include
+#include
#include
-#include
-#include
+#include
#include
-#include
-#include
-#include
-#include
-#include
#include
-#include
-#include
+#include
#include
-#include
-#include
#include
-#include
-#include
-#include
-#include
+#include
+#include "pmic.h"
#include "../common/board_am335x.h"
#include "../common/eeprom.h"
#include "../common/factoryset.h"
-#include "pmic.h"
-#include
-#include
#ifdef CONFIG_SPL_BUILD
void draco_init_ddr(void)
diff --git a/board/siemens/pxm2/mux.c b/board/siemens/pxm2/mux.c
index 07cf5675927..bdf460b5920 100644
--- a/board/siemens/pxm2/mux.c
+++ b/board/siemens/pxm2/mux.c
@@ -11,12 +11,10 @@
* Copyright (C) 2011 Texas Instruments Incorporated - https://www.ti.com/
*/
-#include
+#include
#include
#include
#include
-#include
-#include
#include "eeprom.h"
static struct module_pin_mux uart0_pin_mux[] = {
diff --git a/board/siemens/rut/board.c b/board/siemens/rut/board.c
index 1e0e131addf..8d316918e7a 100644
--- a/board/siemens/rut/board.c
+++ b/board/siemens/rut/board.c
@@ -10,31 +10,16 @@
* Copyright (C) 2011, Texas Instruments, Incorporated - https://www.ti.com/
*/
-#include
+#include
#include
-#include
#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
[PATCH v6 3/7] siemens draco: i2c: use driver model for u-boot
Add support for driver model where EEPROM data are read in draco board. Reviewed-by: Alexander Sverdlin Signed-off-by: Enrico Leto --- configs/draco-etamin_defconfig | 4 +++- configs/draco-rastaban_defconfig | 4 +++- configs/draco-thuban_defconfig | 4 +++- 3 files changed, 9 insertions(+), 3 deletions(-) diff --git a/configs/draco-etamin_defconfig b/configs/draco-etamin_defconfig index a89494f9083..ec9331e625a 100644 --- a/configs/draco-etamin_defconfig +++ b/configs/draco-etamin_defconfig @@ -86,8 +86,10 @@ CONFIG_CLK=y CONFIG_CLK_TI_CTRL=y CONFIG_DFU_NAND=y CONFIG_SYS_DFU_DATA_BUF_SIZE=0x10 -CONFIG_SYS_I2C_LEGACY=y +CONFIG_DM_I2C=y +# CONFIG_SPL_DM_I2C is not set CONFIG_SPL_SYS_I2C_LEGACY=y +CONFIG_I2C_SET_DEFAULT_BUS_NUM=y # CONFIG_SPL_DM_MMC is not set CONFIG_MMC_OMAP_HS=y CONFIG_MTD=y diff --git a/configs/draco-rastaban_defconfig b/configs/draco-rastaban_defconfig index f4a9b860bf0..03fbe494901 100644 --- a/configs/draco-rastaban_defconfig +++ b/configs/draco-rastaban_defconfig @@ -84,8 +84,10 @@ CONFIG_CLK=y CONFIG_CLK_TI_CTRL=y CONFIG_DFU_NAND=y CONFIG_SYS_DFU_DATA_BUF_SIZE=0x10 -CONFIG_SYS_I2C_LEGACY=y +CONFIG_DM_I2C=y +# CONFIG_SPL_DM_I2C is not set CONFIG_SPL_SYS_I2C_LEGACY=y +CONFIG_I2C_SET_DEFAULT_BUS_NUM=y # CONFIG_MMC is not set CONFIG_MTD=y CONFIG_MTD_RAW_NAND=y diff --git a/configs/draco-thuban_defconfig b/configs/draco-thuban_defconfig index cf2c46b3d20..fcc9b0380f4 100644 --- a/configs/draco-thuban_defconfig +++ b/configs/draco-thuban_defconfig @@ -84,8 +84,10 @@ CONFIG_CLK=y CONFIG_CLK_TI_CTRL=y CONFIG_DFU_NAND=y CONFIG_SYS_DFU_DATA_BUF_SIZE=0x10 -CONFIG_SYS_I2C_LEGACY=y +CONFIG_DM_I2C=y +# CONFIG_SPL_DM_I2C is not set CONFIG_SPL_SYS_I2C_LEGACY=y +CONFIG_I2C_SET_DEFAULT_BUS_NUM=y # CONFIG_MMC is not set CONFIG_MTD=y CONFIG_MTD_RAW_NAND=y -- 2.30.2
[PATCH v6 1/7] siemens: eeprom: clean up definitions
Move the I2C and EEPROM address definitions in common board header.
Reviewed-by: Alexander Sverdlin
Signed-off-by: Enrico Leto
---
board/siemens/capricorn/board.c | 5 ++---
board/siemens/common/board.c | 6 +++---
board/siemens/common/eeprom.h | 21 +
board/siemens/common/factoryset.c | 12 ++--
board/siemens/draco/board.c | 13 +
board/siemens/pxm2/board.c| 1 +
board/siemens/rut/board.c | 1 +
include/configs/draco-etamin.h| 3 ---
include/configs/draco-rastaban.h | 3 ---
include/configs/draco-thuban.h| 3 ---
10 files changed, 39 insertions(+), 29 deletions(-)
create mode 100644 board/siemens/common/eeprom.h
diff --git a/board/siemens/capricorn/board.c b/board/siemens/capricorn/board.c
index 924c88e8fab..5f7e2b1e899 100644
--- a/board/siemens/capricorn/board.c
+++ b/board/siemens/capricorn/board.c
@@ -28,6 +28,7 @@
#include
#endif
#include
+#include "../common/eeprom.h"
#include "../common/factoryset.h"
#define GPIO_PAD_CTRL \
@@ -337,13 +338,11 @@ void board_late_mmc_env_init(void)
}
#ifndef CONFIG_SPL_BUILD
-int factoryset_read_eeprom(int i2c_addr);
-
static int load_parameters_from_factoryset(void)
{
int ret;
- ret = factoryset_read_eeprom(EEPROM_I2C_ADDR);
+ ret = factoryset_read_eeprom(SIEMENS_EE_I2C_ADDR);
if (ret)
return ret;
diff --git a/board/siemens/common/board.c b/board/siemens/common/board.c
index d077751cbe1..420c4965816 100644
--- a/board/siemens/common/board.c
+++ b/board/siemens/common/board.c
@@ -34,7 +34,8 @@
#include
#include
#include
-#include "../common/factoryset.h"
+#include "eeprom.h"
+#include "factoryset.h"
DECLARE_GLOBAL_DATA_PTR;
@@ -70,7 +71,6 @@ void sdram_init(void)
#endif /* #ifdef CONFIG_SPL_BUILD */
#ifndef CONFIG_SPL_BUILD
-#define FACTORYSET_EEPROM_ADDR 0x50
/*
* Basic board specific setup. Pinmux has been handled already.
*/
@@ -88,7 +88,7 @@ int board_init(void)
gd->bd->bi_boot_params = CFG_SYS_SDRAM_BASE + 0x100;
#ifdef CONFIG_FACTORYSET
- factoryset_read_eeprom(FACTORYSET_EEPROM_ADDR);
+ factoryset_read_eeprom(SIEMENS_EE_I2C_ADDR);
#endif
gpmc_init();
diff --git a/board/siemens/common/eeprom.h b/board/siemens/common/eeprom.h
new file mode 100644
index 000..a21d42789a5
--- /dev/null
+++ b/board/siemens/common/eeprom.h
@@ -0,0 +1,21 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright Siemens AG 2023
+ *
+ * Common board definitions for siemens boards
+ */
+
+#ifndef _COMMON_EEPROM_H_
+#define _COMMON_EEPROM_H_
+
+/* EEPROM @ I2C */
+#define SIEMENS_EE_I2C_BUS 0
+#define SIEMENS_EE_I2C_ADDR0x50
+
+/* EEPROM mapping */
+#define SIEMENS_EE_ADDR_NAND_GEO 0x80
+#define SIEMENS_EE_ADDR_DDR3 0x90
+#define SIEMENS_EE_ADDR_CHIP 0x120
+#define SIEMENS_EE_ADDR_FACTORYSET 0x400
+
+#endif /* _COMMON_EEPROM_H_ */
diff --git a/board/siemens/common/factoryset.c
b/board/siemens/common/factoryset.c
index 4e36a6f3199..b5befab9f52 100644
--- a/board/siemens/common/factoryset.c
+++ b/board/siemens/common/factoryset.c
@@ -22,11 +22,11 @@
#include
#include
#include
+#include "eeprom.h"
#include "factoryset.h"
-#define EEPR_PG_SZ 0x80
-#define EEPROM_FATORYSET_OFFSET0x400
-#define OFF_PGEEPROM_FATORYSET_OFFSET/EEPR_PG_SZ
+#define EEPR_PG_SZ 0x80
+#define OFF_PG (SIEMENS_EE_ADDR_FACTORYSET / EEPR_PG_SZ)
/* Global variable that contains necessary information from FactorySet */
struct factorysetcontainer factory_dat;
@@ -159,7 +159,7 @@ int factoryset_read_eeprom(int i2c_addr)
#endif
#if CONFIG_IS_ENABLED(DM_I2C)
- ret = uclass_get_device_by_seq(UCLASS_I2C, EEPROM_I2C_BUS, );
+ ret = uclass_get_device_by_seq(UCLASS_I2C, SIEMENS_EE_I2C_BUS, );
if (ret)
goto err;
@@ -171,14 +171,14 @@ int factoryset_read_eeprom(int i2c_addr)
if (ret)
goto err;
- ret = dm_i2c_read(dev, EEPROM_FATORYSET_OFFSET, hdr, sizeof(hdr));
+ ret = dm_i2c_read(dev, SIEMENS_EE_ADDR_FACTORYSET, hdr, sizeof(hdr));
if (ret)
goto err;
#else
if (i2c_probe(i2c_addr))
goto err;
- if (i2c_read(i2c_addr, EEPROM_FATORYSET_OFFSET, 2, hdr, sizeof(hdr)))
+ if (i2c_read(i2c_addr, SIEMENS_EE_ADDR_FACTORYSET, 2, hdr, sizeof(hdr)))
goto err;
#endif
diff --git a/board/siemens/draco/board.c b/board/siemens/draco/board.c
index 8b13d23aca7..367a300b897 100644
--- a/board/siemens/draco/board.c
+++ b/board/siemens/draco/board.c
@@ -37,6 +37,7 @@
#include
#include
#include "board.h"
+#include "../common/eeprom.h"
#include "../common/factoryset.h"
#include
@@ -132,16 +133,12 @@ struct am335x_nand_geometry {
u8 nand_bus;
};
-#define EEPROM_ADDR0x50
-#define EEPROM_ADDR_DDR3 0x90
-#define EEPROM_ADDR_CHIP 0x120
-
[PATCH v6 0/7] board: siemens: clean up subfolders
The common folder was initialially created for the common parts of
the products based on draco-am355x board family. We have the
product lines 'pxm2', 'rut' and the base line unfortunately named
'draco'! Adding the new capricorn-imx8 board family, the files
were enhanced without cleanup.
Simplify first EEPROM probe and access that implements both i2c
with & without driver model. Use abstraction functions for this.
Move all am355x specifics to a new file 'board_am335x'.
Clean-up includes, config checks, maintainer.
Signed-off-by: Enrico Leto
Enrico Leto (7):
siemens: eeprom: clean up definitions
siemens: eeprom: simplify setup & read
siemens draco: i2c: use driver model for u-boot
siemens: board: etamin: remove deprecated nand config
siemens: board: clean up products folders vs common
siemens: board: clean up includes
siemens: factoryset: use correct config for soc specific
implementation
board/siemens/capricorn/Makefile | 1 +
board/siemens/capricorn/board.c | 6 +-
.../common/{board.c => board_am335x.c}| 44 +++---
board/siemens/common/board_am335x.h | 39 +
board/siemens/common/eeprom.c | 52 +++
board/siemens/common/eeprom.h | 24 +
board/siemens/common/factoryset.c | 87 ---
board/siemens/common/factoryset.h | 2 +-
board/siemens/draco/Kconfig | 2 -
board/siemens/draco/Makefile | 2 +
board/siemens/draco/board.c | 87 ---
board/siemens/draco/board.h | 31 ++-
board/siemens/draco/mux.c | 6 +-
board/siemens/pxm2/MAINTAINERS| 2 +-
board/siemens/pxm2/Makefile | 2 +
board/siemens/pxm2/board.c| 39 +++--
board/siemens/pxm2/board.h| 21 -
board/siemens/pxm2/mux.c | 6 +-
board/siemens/rut/MAINTAINERS | 2 +-
board/siemens/rut/Makefile| 2 +
board/siemens/rut/board.c | 38 +++-
board/siemens/rut/board.h | 21 -
board/siemens/rut/mux.c | 4 +-
configs/draco-etamin_defconfig| 4 +-
configs/draco-rastaban_defconfig | 4 +-
configs/draco-thuban_defconfig| 4 +-
include/configs/draco-etamin.h| 3 -
include/configs/draco-rastaban.h | 3 -
include/configs/draco-thuban.h| 3 -
29 files changed, 216 insertions(+), 325 deletions(-)
rename board/siemens/common/{board.c => board_am335x.c} (87%)
create mode 100644 board/siemens/common/board_am335x.h
create mode 100644 board/siemens/common/eeprom.c
create mode 100644 board/siemens/common/eeprom.h
delete mode 100644 board/siemens/pxm2/board.h
delete mode 100644 board/siemens/rut/board.h
--
2.30.2
[PATCH v2] Add Phytec i.MX93 support
Add support for the Phytec i.MX93 Segin evaluation kit. The SoM consists
of an NXP i.MX93 dual A55 CPU. The SoM is mounted on a Phytec Segin SBC.
Signed-off-by: Mathieu Othacehe
---
Hello,
This new revision takes Yannic and Primoz comments into account. I went
for a configuration file that is named imx93-phyboard-segin_defconfig,
which is inline with the imx8mm-phygate-tauri-l_defconfig, as discussed
with Yannic.
This way, the device tree and the configuration files are matching. I
restored the original phycore_imx93 directory in board/phytec/. The
documentation is updated accordingly.
I aligned the device trees with the v5 revision of the matching kernel
patch.
I removed the initialization of fec and eqos Ethernet ports that is not
tested yet.
Thanks,
Mathieu
v1: https://lists.denx.de/pipermail/u-boot/2024-January/543599.html
arch/arm/dts/Makefile |3 +-
arch/arm/dts/imx93-phyboard-segin-u-boot.dtsi | 287 +++
arch/arm/dts/imx93-phyboard-segin.dts | 117 ++
arch/arm/dts/imx93-phycore-som.dtsi | 126 ++
arch/arm/mach-imx/imx9/Kconfig|6 +
board/phytec/phycore_imx93/Kconfig| 13 +
board/phytec/phycore_imx93/MAINTAINERS| 10 +
board/phytec/phycore_imx93/Makefile | 14 +
board/phytec/phycore_imx93/lpddr4_timing.c| 1546 +
board/phytec/phycore_imx93/phycore_imx93.c| 61 +
board/phytec/phycore_imx93/phycore_imx93.env | 96 +
board/phytec/phycore_imx93/spl.c | 182 ++
configs/imx93-phyboard-segin_defconfig| 147 ++
doc/board/phytec/imx93-phyboard-segin.rst | 61 +
doc/board/phytec/index.rst|1 +
include/configs/phycore_imx93.h | 47 +
16 files changed, 2716 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/dts/imx93-phyboard-segin-u-boot.dtsi
create mode 100644 arch/arm/dts/imx93-phyboard-segin.dts
create mode 100644 arch/arm/dts/imx93-phycore-som.dtsi
create mode 100644 board/phytec/phycore_imx93/Kconfig
create mode 100644 board/phytec/phycore_imx93/MAINTAINERS
create mode 100644 board/phytec/phycore_imx93/Makefile
create mode 100644 board/phytec/phycore_imx93/lpddr4_timing.c
create mode 100644 board/phytec/phycore_imx93/phycore_imx93.c
create mode 100644 board/phytec/phycore_imx93/phycore_imx93.env
create mode 100644 board/phytec/phycore_imx93/spl.c
create mode 100644 configs/imx93-phyboard-segin_defconfig
create mode 100644 doc/board/phytec/imx93-phyboard-segin.rst
create mode 100644 include/configs/phycore_imx93.h
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index d456a524b36..e7687a1b57d 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1127,7 +1127,8 @@ dtb-$(CONFIG_ARCH_IMX8M) += \
dtb-$(CONFIG_ARCH_IMX9) += \
imx93-11x11-evk.dtb \
- imx93-var-som-symphony.dtb
+ imx93-var-som-symphony.dtb \
+ imx93-phyboard-segin.dtb
dtb-$(CONFIG_ARCH_IMXRT) += imxrt1050-evk.dtb \
imxrt1020-evk.dtb \
diff --git a/arch/arm/dts/imx93-phyboard-segin-u-boot.dtsi
b/arch/arm/dts/imx93-phyboard-segin-u-boot.dtsi
new file mode 100644
index 000..3d4c851b0d0
--- /dev/null
+++ b/arch/arm/dts/imx93-phyboard-segin-u-boot.dtsi
@@ -0,0 +1,287 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2023 PHYTEC Messtechnik GmbH
+ * Christoph Stoidner
+ *
+ * Product homepage:
+ * phyBOARD-Segin carrier board is reused for the i.MX93 design.
+ *
https://www.phytec.eu/en/produkte/single-board-computer/phyboard-segin-imx6ul/
+ */
+
+#include "imx93-u-boot.dtsi"
+
+/ {
+ wdt-reboot {
+ compatible = "wdt-reboot";
+ wdt = <>;
+ bootph-pre-ram;
+ bootph-some-ram;
+ };
+
+ aliases {
+ ethernet0 =
+ ethernet1 =
+ };
+
+ firmware {
+ optee {
+ compatible = "linaro,optee-tz";
+ method = "smc";
+ };
+ };
+};
+
+&{/soc@0} {
+ bootph-all;
+ bootph-pre-ram;
+};
+
+ {
+ bootph-pre-ram;
+ bootph-all;
+};
+
+ {
+ bootph-pre-ram;
+ bootph-some-ram;
+};
+
+ {
+ bootph-pre-ram;
+ bootph-some-ram;
+};
+
+ {
+ bootph-pre-ram;
+ bootph-some-ram;
+};
+
+_usdhc2_vmmc {
+ u-boot,off-on-delay-us = <2>;
+ bootph-pre-ram;
+ bootph-some-ram;
+};
+
+_reg_usdhc2_vmmc {
+ bootph-pre-ram;
+};
+
+_uart1 {
+ bootph-pre-ram;
+ bootph-some-ram;
+};
+
+_usdhc1 {
+ bootph-pre-ram;
+ bootph-some-ram;
+};
+
+_usdhc2_cd {
+ bootph-pre-ram;
+ bootph-some-ram;
+};
+
+_usdhc2_default {
+ bootph-pre-ram;
+ bootph-some-ram;
+};
+
+_usdhc2_100mhz {
+ bootph-pre-ram;
+ bootph-some-ram;
+};
+
+_usdhc2_200mhz {
+ bootph-pre-ram;
+ bootph-some-ram;
+};
+
+ {
+ bootph-pre-ram;
+ bootph-some-ram;
+};
+
+ {
Re: [PATCH] efi_loader: migrate SMBIOS 3.0 entry point structure for measurement
On 24.01.24 12:51, Masahisa Kojima wrote:
Hi Heinrich,
On Wed, 24 Jan 2024 at 18:29, Heinrich Schuchardt wrote:
On 1/24/24 10:15, Masahisa Kojima wrote:
Current U-Boot only supports the SMBIOS 3.0 entry point structure.
TCG2 measurement code should migrate to SMBIOS 3.0 entry
point structure.
efi_selftest tcg2 test also needs to be updated, and expected
PCR[1] result is changed since guid for SMBIOS EFI system table
uses different guid SMBIOS3_TABLE_GUID instead of SMBIOS_TABLE_GUID.
Signed-off-by: Masahisa Kojima
Hello Maasahisa,
Thank you for looking into this.
SMBIOS tables may be provided by QEMU. Depending on the architecture and
the QEMU release we will see SMBIOS2.1 and SMBIOS3 tables. We should
support measuring for both.
With this commit, I assume that only SMBIOS 3.0 is supported in an EFI
enabled system.
# Sorry but I don't fully follow the recent SMBIOS discussion in U-Boot ML.
commit aa8499680c14afa80ed731b4cfcd6934b4f93712
"efi: smbios: Drop support for SMBIOS2 tables"
If QEMU provides the SMBIOS 2.1 tables, do we need to revert the above patch?
qemu-x86_defconfig receives a SMBIOS 2.1 table from QEMU 8.2.
But in qfw_parse_smbios_anchor() we translate this to SMBIOS 3.0. So it
seems my worries concerning QEMU were unjustified.
I still wonder why in smbios_prepare_measurement() we don't check that
the SMBIOS header has the expected signature ('_SM3_').
Best regards
Heinrich
---
include/efi_loader.h | 1 +
include/smbios.h | 4 +-
lib/efi_loader/efi_tcg2.c| 14 ++--
lib/efi_selftest/efi_selftest_tcg2.c | 97 +---
lib/smbios-parser.c | 9 ++-
5 files changed, 61 insertions(+), 64 deletions(-)
diff --git a/include/efi_loader.h b/include/efi_loader.h
index d5fca2fa5e..5c5af4f7fd 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -340,6 +340,7 @@ extern const efi_guid_t
efi_guid_firmware_management_protocol;
extern const efi_guid_t efi_esrt_guid;
/* GUID of the SMBIOS table */
extern const efi_guid_t smbios_guid;
+extern const efi_guid_t smbios3_guid;
/*GUID of console */
extern const efi_guid_t efi_guid_text_input_protocol;
extern const efi_guid_t efi_guid_text_output_protocol;
diff --git a/include/smbios.h b/include/smbios.h
index b507b9d9d7..e45303d0d3 100644
--- a/include/smbios.h
+++ b/include/smbios.h
@@ -326,10 +326,10 @@ int smbios_update_version_full(void *smbios_tab, const
char *version);
* This function clear the device dependent parameters such as
* serial number for the measurement.
*
- * @entry: pointer to a struct smbios_entry
+ * @entry: pointer to a struct smbios3_entry
* @header: pointer to a struct smbios_header
*/
-void smbios_prepare_measurement(const struct smbios_entry *entry,
+void smbios_prepare_measurement(const struct smbios3_entry *entry,
struct smbios_header *header);
#endif /* _SMBIOS_H_ */
diff --git a/lib/efi_loader/efi_tcg2.c b/lib/efi_loader/efi_tcg2.c
index 8db35d0b3c..8b4f2fd2da 100644
--- a/lib/efi_loader/efi_tcg2.c
+++ b/lib/efi_loader/efi_tcg2.c
@@ -1075,7 +1075,7 @@ error:
*/
static efi_status_t
tcg2_measure_smbios(struct udevice *dev,
- const struct smbios_entry *entry)
+ const struct smbios3_entry *entry)
{
efi_status_t ret;
struct smbios_header *smbios_copy;
@@ -1093,7 +1093,7 @@ tcg2_measure_smbios(struct udevice *dev,
*/
event_size = sizeof(struct smbios_handoff_table_pointers2) +
FIELD_SIZEOF(struct efi_configuration_table, guid) +
- entry->struct_table_length;
+ entry->max_struct_size;
event = calloc(1, event_size);
if (!event) {
ret = EFI_OUT_OF_RESOURCES;
@@ -1104,11 +1104,11 @@ tcg2_measure_smbios(struct udevice *dev,
memcpy(event->table_description, SMBIOS_HANDOFF_TABLE_DESC,
sizeof(SMBIOS_HANDOFF_TABLE_DESC));
put_unaligned_le64(1, >number_of_tables);
- guidcpy(>table_entry[0].guid, _guid);
+ guidcpy(>table_entry[0].guid, _guid);
smbios_copy = (struct smbios_header
*)((uintptr_t)>table_entry[0].table);
memcpy(>table_entry[0].table,
(void *)((uintptr_t)entry->struct_table_address),
-entry->struct_table_length);
+entry->max_struct_size);
smbios_prepare_measurement(entry, smbios_copy);
@@ -1133,7 +1133,7 @@ static void *find_smbios_table(void)
u32 i;
for (i = 0; i < systab.nr_tables; i++) {
- if (!guidcmp(_guid, [i].guid))
+ if (!guidcmp(_guid, [i].guid))
return systab.tables[i].table;
}
@@ -1360,7 +1360,7 @@ efi_status_t efi_tcg2_measure_efi_app_invocation(struct
efi_loaded_image_obj *ha
u32 pcr_index;
struct udevice *dev;
u32 event = 0;
- struct smbios_entry *entry;
+ struct
Re: [PATCH] Add Phytec i.MX93 support
On Wed, 2024-01-24 at 14:30 +0100, Mathieu Othacehe wrote: > > Hello Yannic, > > > As a heads-up: you need to rebase as am62 (doc) got applied by Tom. > > Noted. > > > Is the trusted-firmware-a upstream version working? If so, please use that > > instead. > > It is but only on the master branch, so it might be better to stick to > the nxp-imx repository until a lts release is created. Ok, sounds reasonable. > > > > +#include > > > > I don't see a specific reason to have this include separate?! Group it with > > the others, please. > > Many other include files place it here, right after the > BOOT_TARGET_DEVICES macro, so I guess there must be a reason, even > though I am unsure why :). See doc/develop/distro.rst for information. The reason to have this separate is to have this wrapped in ifdefs. Since you have this unconditionally, you may move this include as far as I can tell. > > Thanks, > > Mathieu
Re: [PATCH] Add Phytec i.MX93 support
Hello Yannic, > As a heads-up: you need to rebase as am62 (doc) got applied by Tom. Noted. > Is the trusted-firmware-a upstream version working? If so, please use that > instead. It is but only on the master branch, so it might be better to stick to the nxp-imx repository until a lts release is created. >> +#include > > I don't see a specific reason to have this include separate?! Group it with > the others, please. Many other include files place it here, right after the BOOT_TARGET_DEVICES macro, so I guess there must be a reason, even though I am unsure why :). Thanks, Mathieu
Re: [PATCH 02/16] xilinx_mbv: Remove empty config header
On Wed, Jan 24, 2024 at 08:19:00AM +0100, Michal Simek wrote: > > > On 1/23/24 18:58, Tom Rini wrote: > > On Tue, Jan 23, 2024 at 08:53:21AM +0100, Michal Simek wrote: > > > > > > > > > On 1/22/24 23:39, Tom Rini wrote: > > > > Now that we support having CONFIG_SYS_CONFIG_NAME be unset to indicate a > > > > lack of board.h file, unset this on the xilinx_mbv platforms and remove > > > > the otherwise empty file. > > > > > > > > Signed-off-by: Tom Rini > > > > --- > > > > Cc: Michal Simek > > > > --- > > > >board/xilinx/mbv/Kconfig | 3 --- > > > >board/xilinx/mbv/MAINTAINERS | 1 - > > > >include/configs/xilinx_mbv.h | 6 -- > > > >3 files changed, 10 deletions(-) > > > >delete mode 100644 include/configs/xilinx_mbv.h > > > > > > > > diff --git a/board/xilinx/mbv/Kconfig b/board/xilinx/mbv/Kconfig > > > > index 4bc9f72c541b..d2dec397ed6f 100644 > > > > --- a/board/xilinx/mbv/Kconfig > > > > +++ b/board/xilinx/mbv/Kconfig > > > > @@ -9,9 +9,6 @@ config SYS_VENDOR > > > >config SYS_CPU > > > > default "generic" > > > > -config SYS_CONFIG_NAME > > > > - default "xilinx_mbv" > > > > - > > > >config TEXT_BASE > > > > default 0x8000 if !RISCV_SMODE > > > > default 0x8040 if RISCV_SMODE && ARCH_RV32I > > > > diff --git a/board/xilinx/mbv/MAINTAINERS b/board/xilinx/mbv/MAINTAINERS > > > > index 445654fe740e..db9f03388df9 100644 > > > > --- a/board/xilinx/mbv/MAINTAINERS > > > > +++ b/board/xilinx/mbv/MAINTAINERS > > > > @@ -4,4 +4,3 @@ S: Maintained > > > >F: arch/riscv/dts/xilinx-mbv* > > > >F: board/xilinx/mbv/ > > > >F: configs/xilinx_mbv* > > > > -F: include/configs/xilinx_mbv.h > > > > diff --git a/include/configs/xilinx_mbv.h b/include/configs/xilinx_mbv.h > > > > deleted file mode 100644 > > > > index dba398aeec49.. > > > > --- a/include/configs/xilinx_mbv.h > > > > +++ /dev/null > > > > @@ -1,6 +0,0 @@ > > > > -/* SPDX-License-Identifier: GPL-2.0 */ > > > > -/* > > > > - * (C) Copyright 2023, Advanced Micro Devices, Inc. > > > > - * > > > > - * Michal Simek > > > > - */ > > > > > > Acked-by: Michal Simek > > > > > > But maybe in future we need to revert this patch to add more options > > > there. > > > Or do you plan to remove all of these configs? > > > I can imagine distro boot wiring but that can be done via vars file only > > > but > > > it is not practical. > > > > Do you mean that plain text environment feels impractical for standard > > boot (which should be used instead of the pure scripts of distro_boot) ? > > I didn't play with standard boot yet to find out how to prioritize certain > devices at run time. But normally we are trying to keep all amd platforms in > sync to make sure that from user perspective doesn't really matter if you > are on microblaze, arm32, arm64 or risc-v based platform. > > There are still a lot of configs like GUIDs, dfu and others that I don't > think we will end up without these config files anytime soon. But it doesn't > mean we shouldn't aim for it. OK. Yeah, after a quick look at include/configs/xilinx* today, a lot of that could just be in standard boot and plain text environment and just like there's include/env/ti/ today to share common logic, we should get include/env/amd/ to share some common logic too. Or you and your team can suggest a better sharing alternative too. -- Tom signature.asc Description: PGP signature
Re: [PATCH] firmware: ti_sci: fix the secure_hdr in do_xfer
On Jan 24, 2024 at 16:42:12 +0530, Kamlesh Gurudasani wrote:
> Dhruva Gole writes:
>
> > The secure_hdr needs to be 0 init-ed however this was never being put
> > into the secure_buf, leading to possibility of the first 4 bytes of
> > secure_buf being possibly garbage.
> >
> > Fix this by initialising the secure_hdr itself to the secure_buf
> > location, thus when we make it 0, it automatically ensures the first 4
> > bytes are 0.
> >
> > Fixes: 32cd25128bd849 ("firmware: Add basic support for TI System Control
> > Interface (TI SCI)")
> > Signed-off-by: Dhruva Gole
> > ---
> >
> > Boot tested for sanity on AM62x SK
> > https://gist.github.com/DhruvaG2000/724ceba3a0db03f4b0bff47de1160074
> >
> > Cc: Nishanth Menon
> > Cc: Tom Rini
> >
> > drivers/firmware/ti_sci.c | 6 +++---
> > 1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/firmware/ti_sci.c b/drivers/firmware/ti_sci.c
> > index f5f659c11274..83ee8401a731 100644
> > --- a/drivers/firmware/ti_sci.c
> > +++ b/drivers/firmware/ti_sci.c
> > @@ -236,13 +236,13 @@ static int ti_sci_do_xfer(struct ti_sci_info *info,
> > {
> > struct k3_sec_proxy_msg *msg = >tx_message;
> > u8 secure_buf[info->desc->max_msg_size];
> > - struct ti_sci_secure_msg_hdr secure_hdr;
> > + struct ti_sci_secure_msg_hdr *secure_hdr = (struct
> > ti_sci_secure_msg_hdr *)secure_buf;
> > int ret;
> >
> > if (info->is_secure) {
> > /* ToDo: get checksum of the entire message */
> > - secure_hdr.checksum = 0;
> > - secure_hdr.reserved = 0;
> > + secure_hdr->checksum = 0;
> > + secure_hdr->reserved = 0;
> > memcpy(_buf[sizeof(secure_hdr)],xfer->tx_message.buf,
> secure_hdr is pointer now, the value may be same but (struct
> ti_sci_secure_msg_hdr) would make more sense
Good catch Kamlesh! I have sent a new revision addressing this.
--
Best regards,
Dhruva Gole
[PATCH V3] firmware: ti_sci: fix the secure_hdr in do_xfer
The secure_hdr needs to be 0 init-ed however this was never being put
into the secure_buf, leading to possibility of the first 4 bytes of
secure_buf being possibly garbage.
Fix this by initialising the secure_hdr itself to the secure_buf
location, thus when we make it 0, it automatically ensures the first 4
bytes are 0.
Fixes: 32cd25128bd849 ("firmware: Add basic support for TI System Control
Interface (TI SCI)")
Signed-off-by: Dhruva Gole
---
Boot tested for sanity on AM62x SK
https://gist.github.com/DhruvaG2000/724ceba3a0db03f4b0bff47de1160074
Changelog:
v2 --> v3
Address Kamlesh's comment on v2: use sizeof(struct ti_sci_secure_msg_hdr)
v1 --> v2:
Rebased on top of latest master branch
Cc: Nishanth Menon
Cc: Tom Rini
Cc: Neha Francis
Cc: Manorit Chawdhry
Cc: Vignesh Raghavendra
Cc: Kamlesh Gurudasani
---
drivers/firmware/ti_sci.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/firmware/ti_sci.c b/drivers/firmware/ti_sci.c
index 6e9f93e9a302..49d2696a6d09 100644
--- a/drivers/firmware/ti_sci.c
+++ b/drivers/firmware/ti_sci.c
@@ -236,21 +236,21 @@ static int ti_sci_do_xfer(struct ti_sci_info *info,
{
struct k3_sec_proxy_msg *msg = >tx_message;
u8 secure_buf[info->desc->max_msg_size];
- struct ti_sci_secure_msg_hdr secure_hdr;
+ struct ti_sci_secure_msg_hdr *secure_hdr = (struct
ti_sci_secure_msg_hdr *)secure_buf;
int ret;
if (info->is_secure) {
/* ToDo: get checksum of the entire message */
- secure_hdr.checksum = 0;
- secure_hdr.reserved = 0;
- memcpy(_buf[sizeof(secure_hdr)], xfer->tx_message.buf,
+ secure_hdr->checksum = 0;
+ secure_hdr->reserved = 0;
+ memcpy(_buf[sizeof(struct ti_sci_secure_msg_hdr)],
xfer->tx_message.buf,
xfer->tx_message.len);
xfer->tx_message.buf = (u32 *)secure_buf;
- xfer->tx_message.len += sizeof(secure_hdr);
+ xfer->tx_message.len += sizeof(struct ti_sci_secure_msg_hdr);
if (xfer->rx_len)
- xfer->rx_len += sizeof(secure_hdr);
+ xfer->rx_len += sizeof(struct ti_sci_secure_msg_hdr);
}
/* Send the message */
base-commit: 15e7927b5a2d33666af19879577bf0c30ab088fe
--
2.34.1
[PATCH] ARM: meson: stop printing board model after sysinfo update
After the sysinfo update, Model is printed twice, remove
the now duplicate Model print from mach-meson/board-info.
Signed-off-by: Neil Armstrong
---
arch/arm/mach-meson/board-info.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/arch/arm/mach-meson/board-info.c b/arch/arm/mach-meson/board-info.c
index 95a29da072..d51d9b8f06 100644
--- a/arch/arm/mach-meson/board-info.c
+++ b/arch/arm/mach-meson/board-info.c
@@ -126,13 +126,6 @@ static const char *socinfo_to_soc_id(u32 socinfo)
return "Unknown";
}
-static void print_board_model(void)
-{
- const char *model;
- model = fdt_getprop(gd->fdt_blob, 0, "model", NULL);
- printf("Model: %s\n", model ? model : "Unknown");
-}
-
static unsigned int get_socinfo(void)
{
struct regmap *regmap;
@@ -172,9 +165,6 @@ int checkboard(void)
{
unsigned int socinfo;
- /* print board information */
- print_board_model();
-
socinfo = get_socinfo();
if (!socinfo)
return 0;
---
base-commit: 15e7927b5a2d33666af19879577bf0c30ab088fe
change-id: 20240124-u-boot-model-print-fix-cd2e95d67e21
Best regards,
--
Neil Armstrong
Re: [RFC PATCH v3 14/15] board: ti: am65x: Add check for k3-am654-icssg2 in board_fit_config_match()
On 24/01/24 1:57 pm, Dan Carpenter wrote:
> On Wed, Jan 24, 2024 at 12:19:29PM +0530, MD Danish Anwar wrote:
>> When CONFIG_TI_ICSSG_PRUETH is enabled, add config name check for the
>> icssg2 overlay in board_fit_config_match() API.
>>
>> Signed-off-by: MD Danish Anwar
>> ---
>> board/ti/am65x/evm.c | 11 +++
>> 1 file changed, 7 insertions(+), 4 deletions(-)
>>
>> diff --git a/board/ti/am65x/evm.c b/board/ti/am65x/evm.c
>> index df209021c1..0b661f0084 100644
>> --- a/board/ti/am65x/evm.c
>> +++ b/board/ti/am65x/evm.c
>> @@ -90,10 +90,13 @@ int dram_init_banksize(void)
>> #ifdef CONFIG_SPL_LOAD_FIT
>> int board_fit_config_name_match(const char *name)
>> {
>> -#ifdef CONFIG_TARGET_AM654_A53_EVM
>> -if (!strcmp(name, "k3-am654-base-board"))
>> -return 0;
>> -#endif
>> +if (IS_ENABLED(CONFIG_TI_ICSSG_PRUETH)) {
>> +if (!strcmp(name, "k3-am654-icssg2"))
>> +return 0;
>> +} else {
>> +if (!strcmp(name, "k3-am654-base-board"))
>> +return 0;
>> +}
>>
>> return -1;
>> }
>
> It probably should support both configs being enabled.
>
> if (IS_ENABLED(CONFIG_TI_ICSSG_PRUETH) &&
> strcmp(name, "k3-am654-icssg2") == 0)
> return 0;
>
> if (IS_ENABLED(TARGET_AM654_A53_EVM) &&
> strcmp(name, "k3-am654-base-board"))
> return 0;
>
> return -1;
>
Sure Dan. This seems reasonable. I will add check for both configs in
next revision. Thanks for the review.
> regards,
> dan carpenter
--
Thanks and Regards,
Danish
Re: [RFC PATCH v3 14/15] board: ti: am65x: Add check for k3-am654-icssg2 in board_fit_config_match()
On Wed, Jan 24, 2024 at 11:27:12AM +0300, Dan Carpenter wrote:
> On Wed, Jan 24, 2024 at 12:19:29PM +0530, MD Danish Anwar wrote:
> > When CONFIG_TI_ICSSG_PRUETH is enabled, add config name check for the
> > icssg2 overlay in board_fit_config_match() API.
> >
> > Signed-off-by: MD Danish Anwar
> > ---
> > board/ti/am65x/evm.c | 11 +++
> > 1 file changed, 7 insertions(+), 4 deletions(-)
> >
> > diff --git a/board/ti/am65x/evm.c b/board/ti/am65x/evm.c
> > index df209021c1..0b661f0084 100644
> > --- a/board/ti/am65x/evm.c
> > +++ b/board/ti/am65x/evm.c
> > @@ -90,10 +90,13 @@ int dram_init_banksize(void)
> > #ifdef CONFIG_SPL_LOAD_FIT
> > int board_fit_config_name_match(const char *name)
> > {
> > -#ifdef CONFIG_TARGET_AM654_A53_EVM
> > - if (!strcmp(name, "k3-am654-base-board"))
> > - return 0;
> > -#endif
> > + if (IS_ENABLED(CONFIG_TI_ICSSG_PRUETH)) {
> > + if (!strcmp(name, "k3-am654-icssg2"))
> > + return 0;
> > + } else {
> > + if (!strcmp(name, "k3-am654-base-board"))
> > + return 0;
> > + }
> >
> > return -1;
> > }
>
> It probably should support both configs being enabled.
>
> if (IS_ENABLED(CONFIG_TI_ICSSG_PRUETH) &&
> strcmp(name, "k3-am654-icssg2") == 0)
> return 0;
>
> if (IS_ENABLED(TARGET_AM654_A53_EVM) &&
> strcmp(name, "k3-am654-base-board"))
I reversed this strcmp()...
strcmp(name, "k3-am654-base-board") == 0)
regards,
dan carpenter
Re: [RFC PATCH v3 14/15] board: ti: am65x: Add check for k3-am654-icssg2 in board_fit_config_match()
On Wed, Jan 24, 2024 at 12:19:29PM +0530, MD Danish Anwar wrote:
> When CONFIG_TI_ICSSG_PRUETH is enabled, add config name check for the
> icssg2 overlay in board_fit_config_match() API.
>
> Signed-off-by: MD Danish Anwar
> ---
> board/ti/am65x/evm.c | 11 +++
> 1 file changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/board/ti/am65x/evm.c b/board/ti/am65x/evm.c
> index df209021c1..0b661f0084 100644
> --- a/board/ti/am65x/evm.c
> +++ b/board/ti/am65x/evm.c
> @@ -90,10 +90,13 @@ int dram_init_banksize(void)
> #ifdef CONFIG_SPL_LOAD_FIT
> int board_fit_config_name_match(const char *name)
> {
> -#ifdef CONFIG_TARGET_AM654_A53_EVM
> - if (!strcmp(name, "k3-am654-base-board"))
> - return 0;
> -#endif
> + if (IS_ENABLED(CONFIG_TI_ICSSG_PRUETH)) {
> + if (!strcmp(name, "k3-am654-icssg2"))
> + return 0;
> + } else {
> + if (!strcmp(name, "k3-am654-base-board"))
> + return 0;
> + }
>
> return -1;
> }
It probably should support both configs being enabled.
if (IS_ENABLED(CONFIG_TI_ICSSG_PRUETH) &&
strcmp(name, "k3-am654-icssg2") == 0)
return 0;
if (IS_ENABLED(TARGET_AM654_A53_EVM) &&
strcmp(name, "k3-am654-base-board"))
return 0;
return -1;
regards,
dan carpenter
[RFC PATCH v3 11/15] arm: dts: k3-am65x-binman: Add ICSSG2 overlay and configuration
Add ICSSG2 overlay and configuration to tispl and u-boot images.
Signed-off-by: MD Danish Anwar
---
arch/arm/dts/k3-am65x-binman.dtsi | 65 +--
1 file changed, 61 insertions(+), 4 deletions(-)
diff --git a/arch/arm/dts/k3-am65x-binman.dtsi
b/arch/arm/dts/k3-am65x-binman.dtsi
index 8cc24da1f3..d0cd4889cd 100644
--- a/arch/arm/dts/k3-am65x-binman.dtsi
+++ b/arch/arm/dts/k3-am65x-binman.dtsi
@@ -98,6 +98,8 @@
#define SPL_AM654_EVM_DTB "spl/dts/k3-am654-base-board.dtb"
#define AM654_EVM_DTB "u-boot.dtb"
+#define AM654_EVM_ICSSG2_DTBO "arch/arm/dts/k3-am654-icssg2.dtbo"
+
{
ti-spl {
insert-template = <_spl_template>;
@@ -124,6 +126,20 @@
filename = SPL_AM654_EVM_DTB;
};
};
+
+ fdt-1 {
+ description = "k3-am654-icssg2 overlay";
+ type = "flat_dt";
+ arch = "arm";
+ compression = "none";
+ ti-secure {
+ content =
<_am65x_evm_icssg2_dtb>;
+ keyfile = "custMpk.pem";
+ };
+ spl_am65x_evm_icssg2_dtb: blob-ext {
+ filename =
AM654_EVM_ICSSG2_DTBO;
+ };
+ };
};
configurations {
@@ -133,7 +149,7 @@
description = "k3-am654-base-board";
firmware = "atf";
loadables = "tee", "dm", "spl";
- fdt = "fdt-0";
+ fdt = "fdt-0", "fdt-1";
};
};
};
@@ -168,6 +184,24 @@
};
};
+ fdt-1 {
+ description = "k3-am654-icssg2 overlay";
+ type = "flat_dt";
+ arch = "arm";
+ compression = "none";
+ ti-secure {
+ content =
<_evm_icssg2_dtb>;
+ keyfile = "custMpk.pem";
+
+ };
+ am65x_evm_icssg2_dtb: blob-ext {
+ filename =
AM654_EVM_ICSSG2_DTBO;
+ };
+ hash {
+ algo = "crc32";
+ };
+ };
+
};
configurations {
@@ -177,7 +211,7 @@
description = "k3-am654-base-board";
firmware = "uboot";
loadables = "uboot";
- fdt = "fdt-0";
+ fdt = "fdt-0", "fdt-1";
};
};
};
@@ -205,6 +239,16 @@
filename = SPL_AM654_EVM_DTB;
};
};
+
+ fdt-1 {
+ description = "k3-am654-icssg2 overlay";
+ type = "flat_dt";
+ arch = "arm";
+ compression = "none";
+ blob {
+ filename =
AM654_EVM_ICSSG2_DTBO;
+ };
+ };
};
configurations {
@@ -214,7 +258,7 @@
description = "k3-am654-base-board";
firmware = "atf";
loadables = "tee", "dm", "spl";
- fdt = "fdt-0";
+ fdt = "fdt-0", "fdt-1";
};
};
};
@@ -243,6 +287,19 @@
algo = "crc32";
};
[RFC PATCH v3 15/15] board: ti: am65x: Set fw_storage_interface and fw_dev_part ENVs
When ICSSG driver is enabled (CONFIG_TI_ICSSG_PRUETH=y) set
fw_storage_interface and fw_dev_part env variables.
These variables need be set appropriately in order to load differnet
ICSSG firmwares needed for ICSSG driver. By default the storage
interface is mmc and the partition is 1:2. User can modify this based on
their needs.
Signed-off-by: MD Danish Anwar
---
board/ti/am65x/am65x.env | 4
1 file changed, 4 insertions(+)
diff --git a/board/ti/am65x/am65x.env b/board/ti/am65x/am65x.env
index 286b9c300c..5d6b98b87c 100644
--- a/board/ti/am65x/am65x.env
+++ b/board/ti/am65x/am65x.env
@@ -30,3 +30,7 @@ get_fdt_ubi=ubifsload ${fdtaddr} ${bootdir}/${name_fdt}
args_ubi=setenv bootargs console=${console} ${optargs}
rootfstype=ubifs root=ubi0:rootfs rw ubi.mtd=ospi.rootfs
+#if CONFIG_TI_ICSSG_PRUETH
+fw_storage_interface=mmc
+fw_dev_part=1:2
+#endif
--
2.34.1
[RFC PATCH v3 14/15] board: ti: am65x: Add check for k3-am654-icssg2 in board_fit_config_match()
When CONFIG_TI_ICSSG_PRUETH is enabled, add config name check for the
icssg2 overlay in board_fit_config_match() API.
Signed-off-by: MD Danish Anwar
---
board/ti/am65x/evm.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/board/ti/am65x/evm.c b/board/ti/am65x/evm.c
index df209021c1..0b661f0084 100644
--- a/board/ti/am65x/evm.c
+++ b/board/ti/am65x/evm.c
@@ -90,10 +90,13 @@ int dram_init_banksize(void)
#ifdef CONFIG_SPL_LOAD_FIT
int board_fit_config_name_match(const char *name)
{
-#ifdef CONFIG_TARGET_AM654_A53_EVM
- if (!strcmp(name, "k3-am654-base-board"))
- return 0;
-#endif
+ if (IS_ENABLED(CONFIG_TI_ICSSG_PRUETH)) {
+ if (!strcmp(name, "k3-am654-icssg2"))
+ return 0;
+ } else {
+ if (!strcmp(name, "k3-am654-base-board"))
+ return 0;
+ }
return -1;
}
--
2.34.1
[RFC PATCH v3 13/15] configs: am65x_evm_a53: add SPL_LOAD_FIT_APPLY_OVERLAY
We want SPL to apply DTB overlays (e.g. ICSSG2 overlay) so enable SPL_LOAD_FIT_APPLY_OVERLAY. Signed-off-by: MD Danish Anwar --- configs/am65x_evm_a53_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/am65x_evm_a53_defconfig b/configs/am65x_evm_a53_defconfig index aeea24d773..329973de68 100644 --- a/configs/am65x_evm_a53_defconfig +++ b/configs/am65x_evm_a53_defconfig @@ -69,6 +69,7 @@ CONFIG_CMD_I2C=y CONFIG_CMD_MMC=y CONFIG_CMD_PCI=y CONFIG_CMD_REMOTEPROC=y +CONFIG_SPL_LOAD_FIT_APPLY_OVERLAY=y CONFIG_CMD_USB=y CONFIG_CMD_TIME=y CONFIG_MTDIDS_DEFAULT="nor0=4704.spi.0" -- 2.34.1
[RFC PATCH v3 12/15] configs: am65x_evm_a53: Enable ICSSG Driver
Enable ICSSG driver in am65x_evm_a53_defconfig Signed-off-by: MD Danish Anwar --- configs/am65x_evm_a53_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/am65x_evm_a53_defconfig b/configs/am65x_evm_a53_defconfig index 529bda283d..aeea24d773 100644 --- a/configs/am65x_evm_a53_defconfig +++ b/configs/am65x_evm_a53_defconfig @@ -129,6 +129,7 @@ CONFIG_PHY_FIXED=y CONFIG_E1000=y CONFIG_CMD_E1000=y CONFIG_TI_AM65_CPSW_NUSS=y +CONFIG_TI_ICSSG_PRUETH=y CONFIG_PCI_KEYSTONE=y CONFIG_PHY=y CONFIG_SPL_PHY=y -- 2.34.1
[RFC PATCH v3 10/15] arm: dts: k3-am654-base-board: Add ICSSG2 Ethernet support
ICSSG2 provides dual Gigabit Ethernet support.
Add ICSSG2 ethernet node to an overlay k3-am654-icssg2.dtso
Signed-off-by: MD Danish Anwar
---
arch/arm/dts/Makefile | 3 +-
arch/arm/dts/k3-am654-icssg2.dtso | 145 ++
2 files changed, 147 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/dts/k3-am654-icssg2.dtso
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index e9e58c5478..2bc53fba89 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1396,7 +1396,8 @@ dtb-$(CONFIG_SOC_K3_AM654) += \
k3-am6548-iot2050-advanced-pg2.dtb \
k3-am6548-iot2050-advanced-m2.dtb \
k3-am6548-iot2050-advanced-m2-bkey-usb3-overlay.dtbo \
- k3-am6548-iot2050-advanced-m2-bkey-ekey-pcie-overlay.dtbo
+ k3-am6548-iot2050-advanced-m2-bkey-ekey-pcie-overlay.dtbo \
+ k3-am654-icssg2.dtbo
dtb-$(CONFIG_SOC_K3_J721E) += k3-j721e-common-proc-board.dtb \
k3-j721e-r5-common-proc-board.dtb \
k3-j7200-common-proc-board.dtb \
diff --git a/arch/arm/dts/k3-am654-icssg2.dtso
b/arch/arm/dts/k3-am654-icssg2.dtso
new file mode 100644
index 00..faefa2febc
--- /dev/null
+++ b/arch/arm/dts/k3-am654-icssg2.dtso
@@ -0,0 +1,145 @@
+// SPDX-License-Identifier: GPL-2.0
+/**
+ * DT overlay for enabling ICSSG2 on AM654 EVM
+ *
+ * Copyright (C) 2018-2023 Texas Instruments Incorporated - https://www.ti.com/
+ */
+
+/dts-v1/;
+/plugin/;
+
+#include
+#include "k3-pinctrl.h"
+
+&{/} {
+ aliases {
+ ethernet1 = "/icssg2-eth/ethernet-ports/port@0";
+ ethernet2 = "/icssg2-eth/ethernet-ports/port@1";
+ };
+
+ /* Ethernet node on PRU-ICSSG2 */
+ icssg2_eth: icssg2-eth {
+ compatible = "ti,am654-icssg-prueth";
+ pinctrl-names = "default";
+ pinctrl-0 = <_rgmii_pins_default>;
+ sram = <_ram>;
+ ti,prus = <_0>, <_0>, <_pru2_0>,
+ <_1>, <_1>, <_pru2_1>;
+ firmware-name = "ti-pruss/am65x-sr2-pru0-prueth-fw.elf",
+ "ti-pruss/am65x-sr2-rtu0-prueth-fw.elf",
+ "ti-pruss/am65x-sr2-txpru0-prueth-fw.elf",
+ "ti-pruss/am65x-sr2-pru1-prueth-fw.elf",
+ "ti-pruss/am65x-sr2-rtu1-prueth-fw.elf",
+ "ti-pruss/am65x-sr2-txpru1-prueth-fw.elf";
+
+ ti,pruss-gp-mux-sel = <2>, /* MII mode */
+ <2>,
+ <2>,
+ <2>, /* MII mode */
+ <2>,
+ <2>;
+
+ ti,mii-g-rt = <_mii_g_rt>;
+ ti,mii-rt = <_mii_rt>;
+ ti,iep = <_iep0>, <_iep1>;
+
+ interrupt-parent = <_intc>;
+ interrupts = <24 0 2>, <25 1 3>;
+ interrupt-names = "tx_ts0", "tx_ts1";
+
+ dmas = <_udmap 0xc300>, /* egress slice 0 */
+ <_udmap 0xc301>, /* egress slice 0 */
+ <_udmap 0xc302>, /* egress slice 0 */
+ <_udmap 0xc303>, /* egress slice 0 */
+ <_udmap 0xc304>, /* egress slice 1 */
+ <_udmap 0xc305>, /* egress slice 1 */
+ <_udmap 0xc306>, /* egress slice 1 */
+ <_udmap 0xc307>, /* egress slice 1 */
+ <_udmap 0x4300>, /* ingress slice 0 */
+ <_udmap 0x4301>; /* ingress slice 1 */
+
+ dma-names = "tx0-0", "tx0-1", "tx0-2", "tx0-3",
+ "tx1-0", "tx1-1", "tx1-2", "tx1-3",
+ "rx0", "rx1";
+ ethernet-ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ icssg2_emac0: port@0 {
+ reg = <0>;
+ phy-handle = <_phy0>;
+ phy-mode = "rgmii-id";
+ ti,syscon-rgmii-delay = <_conf 0x4120>;
+ /* Filled in by bootloader */
+ local-mac-address = [00 00 00 00 00 00];
+ };
+ icssg2_emac1: port@1 {
+ reg = <1>;
+ phy-handle = <_phy1>;
+ phy-mode = "rgmii-id";
+ ti,syscon-rgmii-delay = <_conf 0x4124>;
+ /* Filled in by bootloader */
+ local-mac-address = [00 00 00 00 00 00];
+ };
+ };
+ };
+};
+
+_pmx0 {
+
+ icssg2_mdio_pins_default: icssg2-mdio-default-pins {
+ pinctrl-single,pins = <
+
[RFC PATCH v3 09/15] net: ti: icssg: Enforce pinctrl state on the MDIO child node
The binding represents the MDIO controller as a child device tree
node of the MAC device tree node.
The U-Boot driver mostly ignores that child device tree node and just
hardcodes the resources it uses to support both the MAC and MDIO in a
single driver.
However, some resources like pinctrl muxing states are thus ignored.
This has been a problem with some device trees that will put some
pinctrl states on the MDIO device tree node.
Let's rework the driver a bit to create a dummy MDIO driver that we will
then get during our initialization to force the core to select the right
muxing.
Signed-off-by: MD Danish Anwar
---
drivers/net/ti/Kconfig| 1 +
drivers/net/ti/icssg_prueth.c | 59 +++
2 files changed, 60 insertions(+)
diff --git a/drivers/net/ti/Kconfig b/drivers/net/ti/Kconfig
index 9fead2c7ce..6935b70e12 100644
--- a/drivers/net/ti/Kconfig
+++ b/drivers/net/ti/Kconfig
@@ -53,6 +53,7 @@ config TI_AM65_CPSW_NUSS
config TI_ICSSG_PRUETH
bool "TI Gigabit PRU Ethernet driver"
depends on ARCH_K3
+ imply DM_MDIO
select PHYLIB
help
Support Gigabit Ethernet ports over the ICSSG PRU Subsystem
diff --git a/drivers/net/ti/icssg_prueth.c b/drivers/net/ti/icssg_prueth.c
index 50af9a2bc6..225928e477 100644
--- a/drivers/net/ti/icssg_prueth.c
+++ b/drivers/net/ti/icssg_prueth.c
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -103,9 +104,56 @@ static int icssg_phy_init(struct udevice *dev)
return ret;
}
+static ofnode prueth_find_mdio(ofnode parent)
+{
+ ofnode node;
+
+ ofnode_for_each_subnode(node, parent)
+ if (ofnode_device_is_compatible(node, "ti,davinci_mdio"))
+ return node;
+
+ return ofnode_null();
+}
+
+static int prueth_mdio_setup(struct udevice *dev)
+{
+ struct prueth *priv = dev_get_priv(dev);
+ struct udevice *mdio_dev;
+ ofnode mdio;
+ int ret;
+
+ mdio = prueth_find_mdio(dev_ofnode(priv->pruss));
+ if (!ofnode_valid(mdio))
+ return 0;
+
+ /*
+* The MDIO controller is represented in the DT binding by a
+* subnode of the MAC controller.
+*
+* We don't have a DM driver for the MDIO device yet, and thus any
+* pinctrl setting on its node will be ignored.
+*
+* However, we do need to make sure the pins states tied to the
+* MDIO node are configured properly. Fortunately, the core DM
+* does that for use when we get a device, so we can work around
+* that whole issue by just requesting a dummy MDIO driver to
+* probe, and our pins will get muxed.
+*/
+ ret = uclass_get_device_by_ofnode(UCLASS_MDIO, mdio, _dev);
+ if (ret)
+ return ret;
+
+ return 0;
+}
+
static int icssg_mdio_init(struct udevice *dev)
{
struct prueth *prueth = dev_get_priv(dev);
+ int ret;
+
+ ret = prueth_mdio_setup(dev);
+ if (ret)
+ return ret;
prueth->bus = cpsw_mdio_init(dev->name, prueth->mdio_base,
prueth->mdio_freq,
@@ -701,3 +749,14 @@ U_BOOT_DRIVER(prueth) = {
.plat_auto = sizeof(struct eth_pdata),
.flags = DM_FLAG_ALLOC_PRIV_DMA,
};
+
+static const struct udevice_id prueth_mdio_ids[] = {
+ { .compatible = "ti,davinci_mdio" },
+ { }
+};
+
+U_BOOT_DRIVER(prueth_mdio) = {
+ .name = "prueth_mdio",
+ .id = UCLASS_MDIO,
+ .of_match = prueth_mdio_ids,
+};
--
2.34.1
[RFC PATCH v3 08/15] net: ti: icssg: Add support sending FDB command to update rx_flow_id
ICSSG firmware supports FDB commands. Add support to send FDB commands
from driver. Once rx_flow_id is obtained from dma, let firmware know that
we are using this rx_flow_id by sending a FDB command.
Signed-off-by: MD Danish Anwar
---
drivers/net/ti/icssg_config.c | 66 +++
drivers/net/ti/icssg_config.h | 18 ++
drivers/net/ti/icssg_prueth.c | 6
drivers/net/ti/icssg_prueth.h | 6
4 files changed, 96 insertions(+)
diff --git a/drivers/net/ti/icssg_config.c b/drivers/net/ti/icssg_config.c
index 0dc2c0fa3a..630698add4 100644
--- a/drivers/net/ti/icssg_config.c
+++ b/drivers/net/ti/icssg_config.c
@@ -9,6 +9,7 @@
#include "icssg_switch_map.h"
#include "icss_mii_rt.h"
#include
+#include
/* TX IPG Values to be set for 100M and 1G link speeds. These values are
* in ocp_clk cycles. So need change if ocp_clk is changed for a specific
@@ -395,3 +396,68 @@ int emac_set_port_state(struct prueth *prueth,
return ret;
}
+
+int icssg_send_fdb_msg(struct prueth *prueth, struct mgmt_cmd *cmd,
+ struct mgmt_cmd_rsp *rsp)
+{
+ int slice = prueth->slice;
+ int ret, addr;
+
+ addr = icssg_queue_pop(prueth, slice == 0 ?
+ ICSSG_CMD_POP_SLICE0 : ICSSG_CMD_POP_SLICE1);
+ if (addr < 0)
+ return addr;
+
+ /* First 4 bytes have FW owned buffer linking info which should
+* not be touched
+*/
+ memcpy_toio((void __iomem *)prueth->shram.pa + addr + 4, cmd,
sizeof(*cmd));
+ icssg_queue_push(prueth, slice == 0 ?
+ICSSG_CMD_PUSH_SLICE0 : ICSSG_CMD_PUSH_SLICE1, addr);
+ ret = read_poll_timeout(icssg_queue_pop, addr, addr >= 0,
+ 2000, 2000, prueth, slice == 0 ?
+ ICSSG_RSP_POP_SLICE0 : ICSSG_RSP_POP_SLICE1);
+
+ if (ret) {
+ dev_err(prueth->dev, "Timedout sending HWQ message\n");
+ return ret;
+ }
+
+ memcpy_fromio(rsp, (void __iomem *)prueth->shram.pa + addr,
sizeof(*rsp));
+ /* Return buffer back for to pool */
+ icssg_queue_push(prueth, slice == 0 ?
+ICSSG_RSP_PUSH_SLICE0 : ICSSG_RSP_PUSH_SLICE1, addr);
+
+ return 0;
+}
+
+int emac_fdb_flow_id_updated(struct prueth *prueth)
+{
+ struct mgmt_cmd_rsp fdb_cmd_rsp = { 0 };
+ int slice = prueth->slice;
+ struct mgmt_cmd fdb_cmd = { 0 };
+ int ret = 0;
+
+ fdb_cmd.header = ICSSG_FW_MGMT_CMD_HEADER;
+ fdb_cmd.type = ICSSG_FW_MGMT_FDB_CMD_TYPE_RX_FLOW;
+ fdb_cmd.seqnum = ++(prueth->icssg_hwcmdseq);
+ fdb_cmd.param = 0;
+
+ fdb_cmd.param |= (slice << 4);
+ fdb_cmd.cmd_args[0] = 0;
+
+ ret = icssg_send_fdb_msg(prueth, _cmd, _cmd_rsp);
+ if (ret)
+ return ret;
+
+ if (fdb_cmd.seqnum != fdb_cmd_rsp.seqnum) {
+ dev_err(prueth->dev, "seqnum doesn't match, cmd.seqnum %d !=
rsp.seqnum %d\n",
+ fdb_cmd.seqnum, fdb_cmd_rsp.seqnum);
+ return -EINVAL;
+ }
+
+ if (fdb_cmd_rsp.status == 1)
+ return 0;
+
+ return -EINVAL;
+}
diff --git a/drivers/net/ti/icssg_config.h b/drivers/net/ti/icssg_config.h
index fc6eae0426..156127bd3d 100644
--- a/drivers/net/ti/icssg_config.h
+++ b/drivers/net/ti/icssg_config.h
@@ -80,6 +80,7 @@ struct icssg_rxq_ctx {
#define ICSSG_FW_MGMT_FDB_CMD_TYPE 0x03
#define ICSSG_FW_MGMT_CMD_TYPE 0x04
#define ICSSG_FW_MGMT_PKT 0x8000
+#define ICSSG_FW_MGMT_FDB_CMD_TYPE_RX_FLOW 0x05
struct icssg_r30_cmd {
u32 cmd[4];
@@ -156,6 +157,23 @@ struct icssg_setclock_desc {
u32 CMP0_new;
} __packed;
+struct mgmt_cmd {
+ u8 param;
+ u8 seqnum;
+ u8 type;
+ u8 header;
+ u32 cmd_args[3];
+} __packed;
+
+struct mgmt_cmd_rsp {
+ u32 reserved;
+ u8 status;
+ u8 seqnum;
+ u8 type;
+ u8 header;
+ u32 cmd_args[3];
+} __packed;
+
#define ICSSG_CMD_POP_SLICE0 56
#define ICSSG_CMD_POP_SLICE1 60
diff --git a/drivers/net/ti/icssg_prueth.c b/drivers/net/ti/icssg_prueth.c
index cd6ff1a7fe..50af9a2bc6 100644
--- a/drivers/net/ti/icssg_prueth.c
+++ b/drivers/net/ti/icssg_prueth.c
@@ -351,6 +351,12 @@ static int prueth_start(struct udevice *dev)
dev_info(dev, "K3 ICSSG: rflow_id_base: %u, chn_name = %s\n",
dma_rx_cfg_data->flow_id_base, chn_name);
+ ret = emac_fdb_flow_id_updated(priv);
+ if (ret) {
+ dev_err(dev, "Failed to update Rx Flow ID %d", ret);
+ goto phy_fail;
+ }
+
ret = phy_startup(priv->phydev);
if (ret) {
dev_err(dev, "phy_startup failed\n");
diff --git a/drivers/net/ti/icssg_prueth.h b/drivers/net/ti/icssg_prueth.h
index fb76668f90..24dda1fee8 100644
--- a/drivers/net/ti/icssg_prueth.h
+++ b/drivers/net/ti/icssg_prueth.h
[RFC PATCH v3 07/15] net: ti: icssg: Add ICSSG ethernet driver
This is the PURSS Ethernet driver for TI AM654 Sr2.0 and laterSoCs with
the ICSSG PRU Sub-system running EMAC firmware. This driver caters to
either of the slices of the icssg subsystem.
One and exactly one of the slices is supported as the u-boot ethernet
supports probing one interface at a time.
Signed-off-by: MD Danish Anwar
---
drivers/net/ti/Kconfig| 8 +
drivers/net/ti/Makefile | 1 +
drivers/net/ti/icssg_prueth.c | 697 ++
drivers/net/ti/icssg_prueth.h | 3 +
4 files changed, 709 insertions(+)
create mode 100644 drivers/net/ti/icssg_prueth.c
diff --git a/drivers/net/ti/Kconfig b/drivers/net/ti/Kconfig
index c75f418628..9fead2c7ce 100644
--- a/drivers/net/ti/Kconfig
+++ b/drivers/net/ti/Kconfig
@@ -49,3 +49,11 @@ config TI_AM65_CPSW_NUSS
help
This driver supports TI K3 MCU CPSW Nuss Ethernet controller
in Texas Instruments K3 AM65x SoCs.
+
+config TI_ICSSG_PRUETH
+ bool "TI Gigabit PRU Ethernet driver"
+ depends on ARCH_K3
+ select PHYLIB
+ help
+ Support Gigabit Ethernet ports over the ICSSG PRU Subsystem
+ This subsystem is available starting with the AM65 platform.
diff --git a/drivers/net/ti/Makefile b/drivers/net/ti/Makefile
index 0ce0cf2828..5af760572f 100644
--- a/drivers/net/ti/Makefile
+++ b/drivers/net/ti/Makefile
@@ -6,3 +6,4 @@ obj-$(CONFIG_DRIVER_TI_CPSW) += cpsw.o cpsw-common.o cpsw_mdio.o
obj-$(CONFIG_DRIVER_TI_EMAC) += davinci_emac.o
obj-$(CONFIG_DRIVER_TI_KEYSTONE_NET) += keystone_net.o cpsw_mdio.o
obj-$(CONFIG_TI_AM65_CPSW_NUSS) += am65-cpsw-nuss.o cpsw_mdio.o
+obj-$(CONFIG_TI_ICSSG_PRUETH) += icssg_prueth.o cpsw_mdio.o icssg_classifier.o
icssg_config.o icssg_queues.o
diff --git a/drivers/net/ti/icssg_prueth.c b/drivers/net/ti/icssg_prueth.c
new file mode 100644
index 00..cd6ff1a7fe
--- /dev/null
+++ b/drivers/net/ti/icssg_prueth.c
@@ -0,0 +1,697 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Texas Instruments K3 AM65 PRU Ethernet Driver
+ *
+ * Copyright (C) 2019-2021, Texas Instruments, Incorporated
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "cpsw_mdio.h"
+#include "icssg_prueth.h"
+#include "icss_mii_rt.h"
+
+#define ICSS_SLICE0 0
+#define ICSS_SLICE1 1
+
+#ifdef PKTSIZE_ALIGN
+#define UDMA_RX_BUF_SIZE PKTSIZE_ALIGN
+#else
+#define UDMA_RX_BUF_SIZE ALIGN(1522, ARCH_DMA_MINALIGN)
+#endif
+
+#ifdef PKTBUFSRX
+#define UDMA_RX_DESC_NUM PKTBUFSRX
+#else
+#define UDMA_RX_DESC_NUM 4
+#endif
+
+/* Config region lies in shared RAM */
+#define ICSS_CONFIG_OFFSET_SLICE0 0
+#define ICSS_CONFIG_OFFSET_SLICE1 0x8000
+
+/* Firmware flags */
+#define ICSS_SET_RUN_FLAG_VLAN_ENABLE BIT(0) /* switch only */
+#define ICSS_SET_RUN_FLAG_FLOOD_UNICASTBIT(1) /* switch only
*/
+#define ICSS_SET_RUN_FLAG_PROMISC BIT(2) /* MAC only */
+#define ICSS_SET_RUN_FLAG_MULTICAST_PROMISCBIT(3) /* MAC only */
+
+/* CTRLMMR_ICSSG_RGMII_CTRL register bits */
+#define ICSSG_CTRL_RGMII_ID_MODE BIT(24)
+
+/* Management packet type */
+#define PRUETH_PKT_TYPE_CMD0x10
+
+/* Number of PRU Cores per Slice */
+#define ICSSG_NUM_PRU_CORES3
+
+static int icssg_phy_init(struct udevice *dev)
+{
+ struct prueth *priv = dev_get_priv(dev);
+ struct phy_device *phydev;
+ u32 supported = PHY_GBIT_FEATURES;
+ int ret;
+
+ phydev = phy_connect(priv->bus,
+priv->phy_addr,
+priv->dev,
+priv->phy_interface);
+
+ if (!phydev) {
+ dev_err(dev, "phy_connect() failed\n");
+ return -ENODEV;
+ }
+
+ /* disable unsupported features */
+ supported &= ~(PHY_10BT_FEATURES |
+ SUPPORTED_100baseT_Half |
+ SUPPORTED_1000baseT_Half |
+ SUPPORTED_Pause |
+ SUPPORTED_Asym_Pause);
+
+ phydev->supported &= supported;
+ phydev->advertising = phydev->supported;
+
+ if (IS_ENABLED(CONFIG_DM_ETH))
+ if (ofnode_valid(priv->phy_node))
+ phydev->node = priv->phy_node;
+
+ priv->phydev = phydev;
+ ret = phy_config(phydev);
+ if (ret < 0)
+ pr_err("phy_config() failed: %d", ret);
+
+ return ret;
+}
+
+static int icssg_mdio_init(struct udevice *dev)
+{
+ struct prueth *prueth = dev_get_priv(dev);
+
+ prueth->bus = cpsw_mdio_init(dev->name, prueth->mdio_base,
+prueth->mdio_freq,
+clk_get_rate(>mdiofck),
+prueth->mdio_manual_mode);
+ if (!prueth->bus)
+ return
[RFC PATCH v3 05/15] net: ti: icssg: Add Firmware config and classification APIs.
Add icssg_config.h / .c and icssg_classifier.c files. These are firmware configuration and classification related files. Add MII helper APIs and MACROs. These APIs and MACROs will be later used by ICSSG Ethernet driver. Also introduce icssg_prueth.h which has definition of prueth related structures. Signed-off-by: MD Danish Anwar --- drivers/net/ti/icss_mii_rt.h | 192 +++ drivers/net/ti/icssg_classifier.c | 376 drivers/net/ti/icssg_config.c | 397 ++ drivers/net/ti/icssg_config.h | 177 + drivers/net/ti/icssg_prueth.h | 78 ++ 5 files changed, 1220 insertions(+) create mode 100644 drivers/net/ti/icss_mii_rt.h create mode 100644 drivers/net/ti/icssg_classifier.c create mode 100644 drivers/net/ti/icssg_config.c create mode 100644 drivers/net/ti/icssg_config.h create mode 100644 drivers/net/ti/icssg_prueth.h diff --git a/drivers/net/ti/icss_mii_rt.h b/drivers/net/ti/icss_mii_rt.h new file mode 100644 index 00..6b2449e736 --- /dev/null +++ b/drivers/net/ti/icss_mii_rt.h @@ -0,0 +1,192 @@ +/* SPDX-License-Identifier: GPL-2.0 */ + +/* PRU-ICSS MII_RT register definitions + * + * Copyright (C) 2015-2020 Texas Instruments Incorporated - http://www.ti.com + */ + +#ifndef __NET_PRUSS_MII_RT_H__ +#define __NET_PRUSS_MII_RT_H__ + +#include + +/* PRUSS_MII_RT Registers */ +#define PRUSS_MII_RT_RXCFG00x0 +#define PRUSS_MII_RT_RXCFG10x4 +#define PRUSS_MII_RT_TXCFG00x10 +#define PRUSS_MII_RT_TXCFG10x14 +#define PRUSS_MII_RT_TX_CRC0 0x20 +#define PRUSS_MII_RT_TX_CRC1 0x24 +#define PRUSS_MII_RT_TX_IPG0 0x30 +#define PRUSS_MII_RT_TX_IPG1 0x34 +#define PRUSS_MII_RT_PRS0 0x38 +#define PRUSS_MII_RT_PRS1 0x3c +#define PRUSS_MII_RT_RX_FRMS0 0x40 +#define PRUSS_MII_RT_RX_FRMS1 0x44 +#define PRUSS_MII_RT_RX_PCNT0 0x48 +#define PRUSS_MII_RT_RX_PCNT1 0x4c +#define PRUSS_MII_RT_RX_ERR0 0x50 +#define PRUSS_MII_RT_RX_ERR1 0x54 + +/* PRUSS_MII_RT_RXCFG0/1 bits */ +#define PRUSS_MII_RT_RXCFG_RX_ENABLE BIT(0) +#define PRUSS_MII_RT_RXCFG_RX_DATA_RDY_MODE_DISBIT(1) +#define PRUSS_MII_RT_RXCFG_RX_CUT_PREAMBLE BIT(2) +#define PRUSS_MII_RT_RXCFG_RX_MUX_SEL BIT(3) +#define PRUSS_MII_RT_RXCFG_RX_L2_ENBIT(4) +#define PRUSS_MII_RT_RXCFG_RX_BYTE_SWAPBIT(5) +#define PRUSS_MII_RT_RXCFG_RX_AUTO_FWD_PRE BIT(6) +#define PRUSS_MII_RT_RXCFG_RX_L2_EOF_SCLR_DIS BIT(9) + +/* PRUSS_MII_RT_TXCFG0/1 bits */ +#define PRUSS_MII_RT_TXCFG_TX_ENABLE BIT(0) +#define PRUSS_MII_RT_TXCFG_TX_AUTO_PREAMBLEBIT(1) +#define PRUSS_MII_RT_TXCFG_TX_EN_MODE BIT(2) +#define PRUSS_MII_RT_TXCFG_TX_BYTE_SWAPBIT(3) +#define PRUSS_MII_RT_TXCFG_TX_MUX_SEL BIT(8) +#define PRUSS_MII_RT_TXCFG_PRE_TX_AUTO_SEQUENCEBIT(9) +#define PRUSS_MII_RT_TXCFG_PRE_TX_AUTO_ESC_ERR BIT(10) +#define PRUSS_MII_RT_TXCFG_TX_32_MODE_EN BIT(11) +#define PRUSS_MII_RT_TXCFG_TX_IPG_WIRE_CLK_EN BIT(12) /* SR2.0 onwards */ + +#define PRUSS_MII_RT_TXCFG_TX_START_DELAY_SHIFT16 +#define PRUSS_MII_RT_TXCFG_TX_START_DELAY_MASK GENMASK(25, 16) + +#define PRUSS_MII_RT_TXCFG_TX_CLK_DELAY_SHIFT 28 +#define PRUSS_MII_RT_TXCFG_TX_CLK_DELAY_MASK GENMASK(30, 28) + +/* PRUSS_MII_RT_TX_IPG0/1 bits */ +#define PRUSS_MII_RT_TX_IPG_IPG_SHIFT 0 +#define PRUSS_MII_RT_TX_IPG_IPG_MASK GENMASK(9, 0) + +/* PRUSS_MII_RT_PRS0/1 bits */ +#define PRUSS_MII_RT_PRS_COL BIT(0) +#define PRUSS_MII_RT_PRS_CRS BIT(1) + +/* PRUSS_MII_RT_RX_FRMS0/1 bits */ +#define PRUSS_MII_RT_RX_FRMS_MIN_FRM_SHIFT 0 +#define PRUSS_MII_RT_RX_FRMS_MIN_FRM_MASK GENMASK(15, 0) + +#define PRUSS_MII_RT_RX_FRMS_MAX_FRM_SHIFT 16 +#define PRUSS_MII_RT_RX_FRMS_MAX_FRM_MASK GENMASK(31, 16) + +/* Min/Max in MII_RT_RX_FRMS */ +/* For EMAC and Switch */ +#define PRUSS_MII_RT_RX_FRMS_MAX (VLAN_ETH_FRAME_LEN + ETH_FCS_LEN) +#define PRUSS_MII_RT_RX_FRMS_MIN_FRM (64) + +/* for HSR and PRP */ +#define PRUSS_MII_RT_RX_FRMS_MAX_FRM_LRE (PRUSS_MII_RT_RX_FRMS_MAX + \ +ICSS_LRE_TAG_RCT_SIZE) +/* PRUSS_MII_RT_RX_PCNT0/1 bits */ +#define PRUSS_MII_RT_RX_PCNT_MIN_PCNT_SHIFT0 +#define PRUSS_MII_RT_RX_PCNT_MIN_PCNT_MASK GENMASK(3, 0) + +#define PRUSS_MII_RT_RX_PCNT_MAX_PCNT_SHIFT4 +#define PRUSS_MII_RT_RX_PCNT_MAX_PCNT_MASK GENMASK(7, 4) + +/* PRUSS_MII_RT_RX_ERR0/1 bits */ +#define PRUSS_MII_RT_RX_ERR_MIN_PCNT_ERR BIT(0) +#define PRUSS_MII_RT_RX_ERR_MAX_PCNT_ERR BIT(1) +#define PRUSS_MII_RT_RX_ERR_MIN_FRM_ERRBIT(2) +#define PRUSS_MII_RT_RX_ERR_MAX_FRM_ERRBIT(3) + +#define ICSSG_CFG_OFFSET 0 +#define RGMII_CFG_OFFSET 4 + +/* Constant to choose between MII0 and MII1 */ +#define ICSS_MII0 0 +#define ICSS_MII1
[RFC PATCH v3 06/15] net: ti: icssg: Add icssg queues APIs and macros
Add icssg_queue.c file. This file introduces macros and APIs related to
ICSSG queues. These will be used by ICSSG Ethernet driver.
Signed-off-by: MD Danish Anwar
---
drivers/net/ti/icssg_prueth.h | 5
drivers/net/ti/icssg_queues.c | 51 +++
2 files changed, 56 insertions(+)
create mode 100644 drivers/net/ti/icssg_queues.c
diff --git a/drivers/net/ti/icssg_prueth.h b/drivers/net/ti/icssg_prueth.h
index 26b77dd8f3..f34ab5d6d4 100644
--- a/drivers/net/ti/icssg_prueth.h
+++ b/drivers/net/ti/icssg_prueth.h
@@ -75,4 +75,9 @@ void icssg_config_ipg(struct prueth *prueth, int speed, int
mii);
int icssg_config(struct prueth *prueth);
int emac_set_port_state(struct prueth *prueth, enum icssg_port_state_cmd cmd);
+/* Buffer queue helpers */
+int icssg_queue_pop(struct prueth *prueth, u8 queue);
+void icssg_queue_push(struct prueth *prueth, int queue, u16 addr);
+u32 icssg_queue_level(struct prueth *prueth, int queue);
+
#endif /* __NET_TI_ICSSG_PRUETH_H */
diff --git a/drivers/net/ti/icssg_queues.c b/drivers/net/ti/icssg_queues.c
new file mode 100644
index 00..6a95ef5d58
--- /dev/null
+++ b/drivers/net/ti/icssg_queues.c
@@ -0,0 +1,51 @@
+// SPDX-License-Identifier: GPL-2.0
+/* ICSSG Buffer queue helpers
+ *
+ * Copyright (C) 2021 Texas Instruments Incorporated - https://www.ti.com
+ */
+
+#include
+#include
+#include "icssg_prueth.h"
+
+#define ICSSG_QUEUES_MAX 64
+#define ICSSG_QUEUE_OFFSET 0xd00
+#define ICSSG_QUEUE_PEEK_OFFSET0xe00
+#define ICSSG_QUEUE_CNT_OFFSET 0xe40
+#defineICSSG_QUEUE_RESET_OFFSET0xf40
+
+int icssg_queue_pop(struct prueth *prueth, u8 queue)
+{
+ u32 val, cnt;
+
+ if (queue >= ICSSG_QUEUES_MAX)
+ return -EINVAL;
+
+ regmap_read(prueth->miig_rt, ICSSG_QUEUE_CNT_OFFSET + 4 * queue, );
+ if (!cnt)
+ return -EINVAL;
+
+ regmap_read(prueth->miig_rt, ICSSG_QUEUE_OFFSET + 4 * queue, );
+
+ return val;
+}
+
+void icssg_queue_push(struct prueth *prueth, int queue, u16 addr)
+{
+ if (queue >= ICSSG_QUEUES_MAX)
+ return;
+
+ regmap_write(prueth->miig_rt, ICSSG_QUEUE_OFFSET + 4 * queue, addr);
+}
+
+u32 icssg_queue_level(struct prueth *prueth, int queue)
+{
+ u32 reg;
+
+ if (queue >= ICSSG_QUEUES_MAX)
+ return 0;
+
+ regmap_read(prueth->miig_rt, ICSSG_QUEUE_CNT_OFFSET + 4 * queue, );
+
+ return reg;
+}
--
2.34.1
[RFC PATCH v3 04/15] net: ti: icssg: Add Firmware Interface for ICSSG Ethernet driver.
Add firmware interface related headers and macros for ICSSG Ethernet driver. These macros will be later used by the ICSSG ethernet driver. Signed-off-by: MD Danish Anwar --- drivers/net/ti/icssg_switch_map.h | 209 ++ 1 file changed, 209 insertions(+) create mode 100644 drivers/net/ti/icssg_switch_map.h diff --git a/drivers/net/ti/icssg_switch_map.h b/drivers/net/ti/icssg_switch_map.h new file mode 100644 index 00..ba87a44023 --- /dev/null +++ b/drivers/net/ti/icssg_switch_map.h @@ -0,0 +1,209 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +/* Texas Instruments ICSSG Ethernet driver + * + * Copyright (C) 2020 Texas Instruments Incorporated - https://www.ti.com/ + * + */ + +#ifndef __NET_TI_ICSSG_SWITCH_MAP_H +#define __NET_TI_ICSSG_SWITCH_MAP_H + +/*Time after which FDB entries are checked for aged out values. Value in nanoseconds*/ +#define FDB_AGEING_TIMEOUT_OFFSET 0x0014 + +/*default VLAN tag for Host Port*/ +#define HOST_PORT_DF_VLAN_OFFSET 0x001C + +/*Same as HOST_PORT_DF_VLAN_OFFSET*/ +#define EMAC_ICSSG_SWITCH_PORT0_DEFAULT_VLAN_OFFSET HOST_PORT_DF_VLAN_OFFSET + +/*default VLAN tag for P1 Port*/ +#define P1_PORT_DF_VLAN_OFFSET 0x0020 + +/*Same as P1_PORT_DF_VLAN_OFFSET*/ +#define EMAC_ICSSG_SWITCH_PORT1_DEFAULT_VLAN_OFFSET P1_PORT_DF_VLAN_OFFSET + +/*default VLAN tag for P2 Port*/ +#define P2_PORT_DF_VLAN_OFFSET 0x0024 + +/*Same as P2_PORT_DF_VLAN_OFFSET*/ +#define EMAC_ICSSG_SWITCH_PORT2_DEFAULT_VLAN_OFFSET P2_PORT_DF_VLAN_OFFSET + +/*VLAN-FID Table offset. 4096 VIDs. 2B per VID = 8KB = 0x2000*/ +#define VLAN_STATIC_REG_TABLE_OFFSET 0x0100 + +/*VLAN-FID Table offset for EMAC*/ +#define EMAC_ICSSG_SWITCH_DEFAULT_VLAN_TABLE_OFFSET VLAN_STATIC_REG_TABLE_OFFSET + +/*packet descriptor Q reserved memory*/ +#define PORT_DESC0_HI 0x2104 + +/*packet descriptor Q reserved memory*/ +#define PORT_DESC0_LO 0x2F6C + +/*packet descriptor Q reserved memory*/ +#define PORT_DESC1_HI 0x3DD4 + +/*packet descriptor Q reserved memory*/ +#define PORT_DESC1_LO 0x4C3C + +/*packet descriptor Q reserved memory*/ +#define HOST_DESC0_HI 0x5AA4 + +/*packet descriptor Q reserved memory*/ +#define HOST_DESC0_LO 0x5F0C + +/*packet descriptor Q reserved memory*/ +#define HOST_DESC1_HI 0x6374 + +/*packet descriptor Q reserved memory*/ +#define HOST_DESC1_LO 0x67DC + +/*special packet descriptor Q reserved memory*/ +#define HOST_SPPD0 0x7AAC + +/*special packet descriptor Q reserved memory*/ +#define HOST_SPPD1 0x7EAC + +/*_Small_Description_*/ +#define TIMESYNC_FW_WC_CYCLECOUNT_OFFSET 0x83EC + +/*IEP count hi roll over count*/ +#define TIMESYNC_FW_WC_HI_ROLLOVER_COUNT_OFFSET0x83F4 + +/*_Small_Description_*/ +#define TIMESYNC_FW_WC_COUNT_HI_SW_OFFSET_OFFSET 0x83F8 + +/*Set clock descriptor*/ +#define TIMESYNC_FW_WC_SETCLOCK_DESC_OFFSET0x83FC + +/*_Small_Description_*/ +#define TIMESYNC_FW_WC_SYNCOUT_REDUCTION_FACTOR_OFFSET 0x843C + +/*_Small_Description_*/ +#define TIMESYNC_FW_WC_SYNCOUT_REDUCTION_COUNT_OFFSET 0x8440 + +/*_Small_Description_*/ +#define TIMESYNC_FW_WC_SYNCOUT_START_TIME_CYCLECOUNT_OFFSET 0x8444 + +/*Control variable to generate SYNC1*/ +#define TIMESYNC_FW_WC_ISOM_PIN_SIGNAL_EN_OFFSET 0x844C + +/*SystemTime Sync0 periodicity*/ +#define TIMESYNC_FW_ST_SYNCOUT_PERIOD_OFFSET 0x8450 + +/*pktTxDelay for P1 = link speed dependent p1 mac delay + p1 phy delay*/ +#define TIMESYNC_FW_WC_PKTTXDELAY_P1_OFFSET0x8454 + +/*pktTxDelay for P2 = link speed dependent p2 mac delay + p2 phy delay*/ +#define TIMESYNC_FW_WC_PKTTXDELAY_P2_OFFSET0x8458 + +/*Set clock operation done signal for next task*/ +#define TIMESYNC_FW_SIG_PNFW_OFFSET0x845C + +/*Set clock operation done signal for next task*/ +#define TIMESYNC_FW_SIG_TIMESYNCFW_OFFSET 0x8460 + +/*New list is copied at this time*/ +#define TAS_CONFIG_CHANGE_TIME 0x000C + +/*config change error counter*/ +#define TAS_CONFIG_CHANGE_ERROR_COUNTER0x0014 + +/*TAS List update pending flag*/ +#define TAS_CONFIG_PENDING 0x0018 + +/*TAS list update trigger flag*/ +#define TAS_CONFIG_CHANGE 0x0019 + +/*List length for new TAS schedule*/ +#define TAS_ADMIN_LIST_LENGTH 0x001A + +/*Currently active TAS list index*/ +#define
[RFC PATCH v3 03/15] remoteproc: uclass: Add methods to load firmware to rproc and boot rproc
Add APIs to set a firmware_name to a rproc and boot the rproc with the
same firmware.
Clients can call rproc_set_firmware() API to set firmware_name for a rproc
whereas rproc_boot() will load the firmware set by rproc_set_firmware() to
a buffer by calling request_firmware_into_buf(). rproc_boot() will then
load the firmware file to the remote processor and start the remote
processor.
Also include "fs-loader.h" and make remoteproc driver select FS_LOADER in
Kconfig so that we can call request_firmware_into_buf() from remoteproc
driver.
Signed-off-by: MD Danish Anwar
---
drivers/remoteproc/Kconfig| 1 +
drivers/remoteproc/rproc-uclass.c | 85 +++
include/remoteproc.h | 35 +
3 files changed, 121 insertions(+)
diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index 781de530af..0fdf1b38ea 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -10,6 +10,7 @@ menu "Remote Processor drivers"
# All users should depend on DM
config REMOTEPROC
bool
+ select FS_LOADER
depends on DM
# Please keep the configuration alphabetically sorted.
diff --git a/drivers/remoteproc/rproc-uclass.c
b/drivers/remoteproc/rproc-uclass.c
index 28b362c887..76db4157f7 100644
--- a/drivers/remoteproc/rproc-uclass.c
+++ b/drivers/remoteproc/rproc-uclass.c
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -961,3 +962,87 @@ unsigned long rproc_parse_resource_table(struct udevice
*dev, struct rproc *cfg)
return 1;
}
+
+int rproc_set_firmware(struct udevice *rproc_dev, const char *fw_name)
+{
+ struct dm_rproc_uclass_pdata *uc_pdata;
+ int len;
+ char *p;
+
+ if (!rproc_dev || !fw_name)
+ return -EINVAL;
+
+ uc_pdata = dev_get_uclass_plat(rproc_dev);
+
+ len = strcspn(fw_name, "\n");
+ if (!len) {
+ debug("can't provide empty string for firmware name\n");
+ return -EINVAL;
+ }
+
+ p = strndup(fw_name, len);
+ if (!p)
+ return -ENOMEM;
+
+ uc_pdata->fw_name = p;
+
+ return 0;
+}
+
+int rproc_boot(struct udevice *rproc_dev, size_t fw_size)
+{
+ struct dm_rproc_uclass_pdata *uc_pdata;
+ struct udevice *fs_loader;
+ void *addr = malloc(fw_size);
+ int core_id, ret = 0;
+ char *firmware;
+ ulong rproc_addr;
+
+ if (!rproc_dev)
+ return -EINVAL;
+
+ if (!addr)
+ return -ENOMEM;
+
+ uc_pdata = dev_get_uclass_plat(rproc_dev);
+ core_id = dev_seq(rproc_dev);
+ firmware = uc_pdata->fw_name;
+
+ if (!firmware) {
+ debug("No firmware set for rproc core %d\n", core_id);
+ return -EINVAL;
+ }
+
+ /* Initialize all rproc cores */
+ rproc_init();
+
+ /* Loading firmware to a given address */
+ ret = get_fs_loader(_loader);
+ if (ret) {
+ debug("could not get fs loader: %d\n", ret);
+ return ret;
+ }
+
+ ret = request_firmware_into_buf(fs_loader, firmware, addr, fw_size, 0);
+ if (ret < 0) {
+ debug("could not request %s: %d\n", firmware, ret);
+ return ret;
+ }
+
+ rproc_addr = (ulong)addr;
+
+ ret = rproc_load(core_id, rproc_addr, ret);
+ if (ret) {
+ debug("failed to load %s to rproc core %d from addr 0x%08lX err
%d\n",
+ uc_pdata->fw_name, core_id, rproc_addr, ret);
+ return ret;
+ }
+
+ ret = rproc_start(core_id);
+ if (ret) {
+ debug("failed to start rproc core %d\n", core_id);
+ return ret;
+ }
+
+ return ret;
+}
diff --git a/include/remoteproc.h b/include/remoteproc.h
index a11dc8a9b6..65b0ff7477 100644
--- a/include/remoteproc.h
+++ b/include/remoteproc.h
@@ -402,6 +402,7 @@ enum rproc_mem_type {
* @name: Platform-specific way of naming the Remote proc
* @mem_type: one of 'enum rproc_mem_type'
* @driver_plat_data: driver specific platform data that may be needed.
+ * @fw_name: firmware name
*
* This can be accessed with dev_get_uclass_plat() for any UCLASS_REMOTEPROC
* device.
@@ -411,6 +412,7 @@ struct dm_rproc_uclass_pdata {
const char *name;
enum rproc_mem_type mem_type;
void *driver_plat_data;
+ char *fw_name;
};
/**
@@ -704,6 +706,35 @@ unsigned long rproc_parse_resource_table(struct udevice
*dev,
struct resource_table *rproc_find_resource_table(struct udevice *dev,
unsigned int addr,
int *tablesz);
+/**
+ * rproc_set_firmware() - assign a new firmware
+ * @rproc_dev: device for wich new firmware is being assigned
+ * @fw_name: new firmware name to be assigned
+ *
+ * This function allows remoteproc drivers or clients to
[RFC PATCH v3 01/15] dma: ti: k3-udma: Use ring_idx to pair k3 nav rings
Use ring_idx to pair rings. ring_idx will be same as tx flow_id for all
non-negative flow_ids. For negative flow_ids, ring_idx will be tchan->id
added with bchan_cnt.
Signed-off-by: MD Danish Anwar
---
drivers/dma/ti/k3-udma.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/dma/ti/k3-udma.c b/drivers/dma/ti/k3-udma.c
index 8a62d63dfe..eea9ec9659 100644
--- a/drivers/dma/ti/k3-udma.c
+++ b/drivers/dma/ti/k3-udma.c
@@ -876,13 +876,20 @@ static int udma_alloc_tx_resources(struct udma_chan *uc)
{
struct k3_nav_ring_cfg ring_cfg;
struct udma_dev *ud = uc->ud;
- int ret;
+ struct udma_tchan *tchan;
+ int ring_idx, ret;
ret = udma_get_tchan(uc);
if (ret)
return ret;
- ret = k3_nav_ringacc_request_rings_pair(ud->ringacc, uc->tchan->id, -1,
+ tchan = uc->tchan;
+ if (tchan->tflow_id >= 0)
+ ring_idx = tchan->tflow_id;
+ else
+ ring_idx = ud->bchan_cnt + tchan->id;
+
+ ret = k3_nav_ringacc_request_rings_pair(ud->ringacc, ring_idx, -1,
>tchan->t_ring,
>tchan->tc_ring);
if (ret) {
--
2.34.1
[RFC PATCH v3 00/15] Introduce ICSSG Ethernet driver
Introduce ICSSG PRUETH support in uboot. The ICSSG driver is used in TI AM654 SR2.0. The ICSSG PRU Sub-system runs on EMAC firmware. This series Introduces support for ICSSG driver in uboot. This series also adds the driver's dependencies. The ICSSG2 node is added in device tree overlay so that it remains in sync with linux kernel. The series introduces device tree and config changes and AM65x to enable ICSSG driver. The series also enables SPL_LOAD_FIT_APPLY_OVERLAY for AM65x in order to load overlay over spl. This series has been tested on AM65x SR2.0, and the ICSSG interface is able to ping / dhcp and boot kernel using tftp in uboot. To use ICSSG2 ethernet, the ICSSG firmware needs to be loaded to PRU RPROC cores and RPROC cores need to be booted with the firmware. This step is done inside driver similar to kernel. The remoteproc driver uses request_fw_into_buf() API from fs-loader driver to load and start rproc with the required firmwares. The users need to set env variables fw_storage_interface, fw_dev_part, fw_ubi_mtdpart, fw_ubi_volume to indicate which storage medium and partition they want to use to load firmware files from. By default the env fw_storage_interface=mmc and fw_dev_part=1:2 but users can modify these envs as per their requirements. Log while running dhcp at u-boot: k3-navss-ringacc ringacc@3c00: Ring Accelerator probed rings:818, gp-rings[304,100] sci-dev-id:187 k3-navss-ringacc ringacc@3c00: dma-ring-reset-quirk: disabled prueth icssg2-eth: K3 ICSSG: rflow_id_base: 8, chn_name = rx0 link up on port 0, speed 1000, full duplex BOOTP broadcast 1 BOOTP broadcast 2 BOOTP broadcast 3 DHCP client bound to address 192.168.4.97 (1037 ms) This is v3 of the series [1]. Changes from v2 [2] to v3: *) No functional changes. *) Rebased the series on latest u-boot/next. *) Dropped the RFC tag. Changes from v1 to v2: *) Modified the driver to load the firmware inside the driver only instead of loading the firmware using commands at u-boot prompt. Added patch 3/16 for this. *) Rebased the series on the latest u-boot/next. *) Modified conf-0 configuration in k3-am65x-binman.dtsi as suggested by Roger. *) Dropped patch [3] as the patch is no longer needed. *) Added patch 2/15 to modify fs-loader driver to use fw_storage_interface env instead of storage_interface and keep the env storage_interface as fallback as suggested by Roger. *) Added patch 15/15 to set default values to env fw_storage_interface and fw_dev_part. [1] https://lore.kernel.org/all/20231219103418.3445886-1-danishan...@ti.com/ [2] https://lore.kernel.org/all/20240111070611.342701-1-danishan...@ti.com/ [3] https://lore.kernel.org/all/20231219103418.3445886-16-danishan...@ti.com/ NOTE: All the device tree changes introduced in this patch are already part of upstream linux kernel. Thanks and Regards, MD Danish Anwar MD Danish Anwar (15): dma: ti: k3-udma: Use ring_idx to pair k3 nav rings misc: fs-loader: Use fw_storage_interface instead of storage_interface remoteproc: uclass: Add methods to load firmware to rproc and boot rproc net: ti: icssg: Add Firmware Interface for ICSSG Ethernet driver. net: ti: icssg: Add Firmware config and classification APIs. net: ti: icssg: Add icssg queues APIs and macros net: ti: icssg: Add ICSSG ethernet driver net: ti: icssg: Add support sending FDB command to update rx_flow_id net: ti: icssg: Enforce pinctrl state on the MDIO child node arm: dts: k3-am654-base-board: Add ICSSG2 Ethernet support arm: dts: k3-am65x-binman: Add ICSSG2 overlay and configuration configs: am65x_evm_a53: Enable ICSSG Driver configs: am65x_evm_a53: add SPL_LOAD_FIT_APPLY_OVERLAY board: ti: am65x: Add check for k3-am654-icssg2 in board_fit_config_match() board: ti: am65x: Set fw_storage_interface and fw_dev_part ENVs arch/arm/dts/Makefile | 3 +- arch/arm/dts/k3-am654-icssg2.dtso | 145 arch/arm/dts/k3-am65x-binman.dtsi | 65 +- board/ti/am65x/am65x.env | 4 + board/ti/am65x/evm.c | 11 +- configs/am65x_evm_a53_defconfig | 2 + .../driver-model/fs_firmware_loader.rst | 5 +- drivers/dma/ti/k3-udma.c | 11 +- drivers/misc/fs_loader.c | 5 +- drivers/net/ti/Kconfig| 9 + drivers/net/ti/Makefile | 1 + drivers/net/ti/icss_mii_rt.h | 192 + drivers/net/ti/icssg_classifier.c | 376 + drivers/net/ti/icssg_config.c | 463 +++ drivers/net/ti/icssg_config.h | 195 + drivers/net/ti/icssg_prueth.c | 762 ++ drivers/net/ti/icssg_prueth.h | 92 +++ drivers/net/ti/icssg_queues.c | 51 ++ drivers/net/ti/icssg_switch_map.h | 209 + drivers/remoteproc/Kconfig|
[RFC PATCH v3 02/15] misc: fs-loader: Use fw_storage_interface instead of storage_interface
The fs-loader driver reads env storage_interface and uses it to load
firmware file into memory using the medium set by env. Update the driver
to use env fw_storage_interface as this variable is only used to load
firmwares. The env storage_interface will act as fallback so that the
existing implementations do not break.
Also update the FS Loader documentation accordingly.
Signed-off-by: MD Danish Anwar
---
doc/develop/driver-model/fs_firmware_loader.rst | 5 -
drivers/misc/fs_loader.c| 5 -
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/doc/develop/driver-model/fs_firmware_loader.rst
b/doc/develop/driver-model/fs_firmware_loader.rst
index 149b8b436e..410cc1442d 100644
--- a/doc/develop/driver-model/fs_firmware_loader.rst
+++ b/doc/develop/driver-model/fs_firmware_loader.rst
@@ -98,8 +98,11 @@ through the U-Boot environment variable during run time.
For examples:
+fw_storage_interface:
+ Firmware storage interface, it can be "mmc", "usb", "sata" or "ubi".
storage_interface:
- Storage interface, it can be "mmc", "usb", "sata" or "ubi".
+ Storage interface, it can be "mmc", "usb", "sata" or "ubi". This acts
+ as a fallback if fw_storage_interface is not set.
fw_dev_part:
Block device number and its partition, it can be "0:1".
fw_ubi_mtdpart:
diff --git a/drivers/misc/fs_loader.c b/drivers/misc/fs_loader.c
index 1ffc199ba1..3798dab5b6 100644
--- a/drivers/misc/fs_loader.c
+++ b/drivers/misc/fs_loader.c
@@ -153,7 +153,10 @@ static int fw_get_filesystem_firmware(struct udevice *dev)
char *storage_interface, *dev_part, *ubi_mtdpart, *ubi_volume;
int ret;
- storage_interface = env_get("storage_interface");
+ storage_interface = env_get("fw_storage_interface");
+ if (!storage_interface)
+ storage_interface = env_get("storage_interface");
+
dev_part = env_get("fw_dev_part");
ubi_mtdpart = env_get("fw_ubi_mtdpart");
ubi_volume = env_get("fw_ubi_volume");
--
2.34.1
Re: [PATCH] video: tidss: Use DT property names for parsing nodes
Hi Devarsh,
On 24/01/24 14:37, Devarsh Thakkar wrote:
> Use device-tree node property names for parsing nodes instead of
> indexing as indexing could be different between different SoCs based on
> number of DSS entities available on that particular SoC.
>
> Also correct the video layer naming in driver to match to actual one
> being used in upstream DSS device-tree node [1].
>
> This also fixes AM62x splash screen usage using the latest upstream DSS
> device-tree nodes where hard-coded indexing which driver was using
> before this patch was not matching the correct properties in the DT
> node.
>
> [1]: Upstream AM62x DSS node:
> https://github.com/torvalds/linux/blob/v6.8-rc1/arch/arm64/boot/dts/ti/k3-am62-main.dtsi#L774
>
> Fixes: 5f9f816bb8 ("drivers: video: tidss: TIDSS video driver support
> for AM62x")
> Signed-off-by: Devarsh Thakkar
Reviewed-by: Nikhil M Jain
Re: [PATCH v2] common: splash_source: Don't compile ubifs splash cmd for SPL build
Hi Devarsh,
On 24/01/24 14:35, Devarsh Thakkar wrote:
> Don't compile ubifs splash mount command for SPL build as this command
> is not supported (and also not enabled) during SPL stage.
>
> This fixes below compilation error, when CONFIG_CMD_UBIFS is enabled in
> defconfig along with splash screen enabled at SPL stage:
>
> "aarch64-none-linux-gnu-ld.bfd: common/cli.o: in function `run_command':
> u-boot-next/u-boot/common/cli.c:51: undefined reference to
> `parse_string_outer'
> u-boot-next/u-boot/common/cli.c:51:(.text.run_command+0x10): relocation
> truncated to fit: R_AARCH64_JUMP26 against undefined symbol
> `parse_string_outer' make[2]: ***
> [u-boot-next/u-boot/scripts/Makefile.spl:527: spl/u-boot-spl] Error 1
> make[1]: *** [u-boot-next/u-boot/Makefile:2053: spl/u-boot-spl] Error 2
> make[1]: Leaving directory 'u-boot-next/u-boot/out/a53' make: ***
> [Makefile:177: sub-make] Error 2"
>
> Fixes: eb9217dc03 ("common: Enable splash functions at SPL")
> Signed-off-by: Devarsh Thakkar
Reviewed-by: Nikhil M Jain
Re: [PATCH] efi_loader: migrate SMBIOS 3.0 entry point structure for measurement
Hi Heinrich,
On Wed, 24 Jan 2024 at 18:29, Heinrich Schuchardt wrote:
>
> On 1/24/24 10:15, Masahisa Kojima wrote:
> > Current U-Boot only supports the SMBIOS 3.0 entry point structure.
> > TCG2 measurement code should migrate to SMBIOS 3.0 entry
> > point structure.
> >
> > efi_selftest tcg2 test also needs to be updated, and expected
> > PCR[1] result is changed since guid for SMBIOS EFI system table
> > uses different guid SMBIOS3_TABLE_GUID instead of SMBIOS_TABLE_GUID.
> >
> > Signed-off-by: Masahisa Kojima
>
> Hello Maasahisa,
>
> Thank you for looking into this.
>
> SMBIOS tables may be provided by QEMU. Depending on the architecture and
> the QEMU release we will see SMBIOS2.1 and SMBIOS3 tables. We should
> support measuring for both.
With this commit, I assume that only SMBIOS 3.0 is supported in an EFI
enabled system.
# Sorry but I don't fully follow the recent SMBIOS discussion in U-Boot ML.
commit aa8499680c14afa80ed731b4cfcd6934b4f93712
"efi: smbios: Drop support for SMBIOS2 tables"
If QEMU provides the SMBIOS 2.1 tables, do we need to revert the above patch?
Thanks,
Masahisa Kojima
>
> Best regards
>
> Heinrich
>
> > ---
> > include/efi_loader.h | 1 +
> > include/smbios.h | 4 +-
> > lib/efi_loader/efi_tcg2.c| 14 ++--
> > lib/efi_selftest/efi_selftest_tcg2.c | 97 +---
> > lib/smbios-parser.c | 9 ++-
> > 5 files changed, 61 insertions(+), 64 deletions(-)
> >
> > diff --git a/include/efi_loader.h b/include/efi_loader.h
> > index d5fca2fa5e..5c5af4f7fd 100644
> > --- a/include/efi_loader.h
> > +++ b/include/efi_loader.h
> > @@ -340,6 +340,7 @@ extern const efi_guid_t
> > efi_guid_firmware_management_protocol;
> > extern const efi_guid_t efi_esrt_guid;
> > /* GUID of the SMBIOS table */
> > extern const efi_guid_t smbios_guid;
> > +extern const efi_guid_t smbios3_guid;
> > /*GUID of console */
> > extern const efi_guid_t efi_guid_text_input_protocol;
> > extern const efi_guid_t efi_guid_text_output_protocol;
> > diff --git a/include/smbios.h b/include/smbios.h
> > index b507b9d9d7..e45303d0d3 100644
> > --- a/include/smbios.h
> > +++ b/include/smbios.h
> > @@ -326,10 +326,10 @@ int smbios_update_version_full(void *smbios_tab,
> > const char *version);
> >* This function clear the device dependent parameters such as
> >* serial number for the measurement.
> >*
> > - * @entry: pointer to a struct smbios_entry
> > + * @entry: pointer to a struct smbios3_entry
> >* @header: pointer to a struct smbios_header
> >*/
> > -void smbios_prepare_measurement(const struct smbios_entry *entry,
> > +void smbios_prepare_measurement(const struct smbios3_entry *entry,
> > struct smbios_header *header);
> >
> > #endif /* _SMBIOS_H_ */
> > diff --git a/lib/efi_loader/efi_tcg2.c b/lib/efi_loader/efi_tcg2.c
> > index 8db35d0b3c..8b4f2fd2da 100644
> > --- a/lib/efi_loader/efi_tcg2.c
> > +++ b/lib/efi_loader/efi_tcg2.c
> > @@ -1075,7 +1075,7 @@ error:
> >*/
> > static efi_status_t
> > tcg2_measure_smbios(struct udevice *dev,
> > - const struct smbios_entry *entry)
> > + const struct smbios3_entry *entry)
> > {
> > efi_status_t ret;
> > struct smbios_header *smbios_copy;
> > @@ -1093,7 +1093,7 @@ tcg2_measure_smbios(struct udevice *dev,
> >*/
> > event_size = sizeof(struct smbios_handoff_table_pointers2) +
> >FIELD_SIZEOF(struct efi_configuration_table, guid) +
> > - entry->struct_table_length;
> > + entry->max_struct_size;
> > event = calloc(1, event_size);
> > if (!event) {
> > ret = EFI_OUT_OF_RESOURCES;
> > @@ -1104,11 +1104,11 @@ tcg2_measure_smbios(struct udevice *dev,
> > memcpy(event->table_description, SMBIOS_HANDOFF_TABLE_DESC,
> > sizeof(SMBIOS_HANDOFF_TABLE_DESC));
> > put_unaligned_le64(1, >number_of_tables);
> > - guidcpy(>table_entry[0].guid, _guid);
> > + guidcpy(>table_entry[0].guid, _guid);
> > smbios_copy = (struct smbios_header
> > *)((uintptr_t)>table_entry[0].table);
> > memcpy(>table_entry[0].table,
> > (void *)((uintptr_t)entry->struct_table_address),
> > -entry->struct_table_length);
> > +entry->max_struct_size);
> >
> > smbios_prepare_measurement(entry, smbios_copy);
> >
> > @@ -1133,7 +1133,7 @@ static void *find_smbios_table(void)
> > u32 i;
> >
> > for (i = 0; i < systab.nr_tables; i++) {
> > - if (!guidcmp(_guid, [i].guid))
> > + if (!guidcmp(_guid, [i].guid))
> > return systab.tables[i].table;
> > }
> >
> > @@ -1360,7 +1360,7 @@ efi_status_t
> > efi_tcg2_measure_efi_app_invocation(struct efi_loaded_image_obj *ha
> > u32 pcr_index;
> > struct udevice *dev;
> > u32 event = 0;
> > - struct
Re: [PATCH 01/18] configs: fwu: Remove FWU configs for metadata V2 migration
On Mon, Jan 22, 2024 at 05:24:22PM +0530, Sughosh Ganu wrote: > The FWU metadata is to be migrated to version 2. Disable the FWU > feature on platforms that enable it for the migration. > > Signed-off-by: Sughosh Ganu > --- > configs/corstone1000_defconfig | 2 -- > configs/sandbox64_defconfig | 1 - > configs/synquacer_developerbox_defconfig | 4 > 3 files changed, 7 deletions(-) > > diff --git a/configs/corstone1000_defconfig b/configs/corstone1000_defconfig > index e45415b90c..24b7984959 100644 > --- a/configs/corstone1000_defconfig > +++ b/configs/corstone1000_defconfig > @@ -25,7 +25,6 @@ CONFIG_BOARD_LATE_INIT=y > CONFIG_SYS_PROMPT="corstone1000# " > CONFIG_SYS_MAXARGS=64 > # CONFIG_CMD_CONSOLE is not set > -CONFIG_CMD_FWU_METADATA=y > CONFIG_CMD_BOOTZ=y > # CONFIG_CMD_XIMG is not set > CONFIG_CMD_GPT=y > @@ -67,4 +66,3 @@ CONFIG_FFA_SHARED_MM_BUF_OFFSET=0 > CONFIG_FFA_SHARED_MM_BUF_ADDR=0x0200 > CONFIG_EFI_CAPSULE_ON_DISK=y > CONFIG_EFI_IGNORE_OSINDICATIONS=y > -CONFIG_FWU_MULTI_BANK_UPDATE=y > diff --git a/configs/sandbox64_defconfig b/configs/sandbox64_defconfig > index 996bb7aa4f..7b5888af38 100644 > --- a/configs/sandbox64_defconfig > +++ b/configs/sandbox64_defconfig > @@ -274,7 +274,6 @@ CONFIG_EFI_CAPSULE_ON_DISK=y > CONFIG_EFI_CAPSULE_FIRMWARE_RAW=y > CONFIG_EFI_SECURE_BOOT=y > CONFIG_TEST_FDTDEC=y > -CONFIG_FWU_MULTI_BANK_UPDATE=y > CONFIG_UNIT_TEST=y > CONFIG_UT_TIME=y > CONFIG_UT_DM=y > diff --git a/configs/synquacer_developerbox_defconfig > b/configs/synquacer_developerbox_defconfig > index 2a0407de40..616d410074 100644 > --- a/configs/synquacer_developerbox_defconfig > +++ b/configs/synquacer_developerbox_defconfig > @@ -11,14 +11,12 @@ CONFIG_DM_GPIO=y > CONFIG_DEFAULT_DEVICE_TREE="synquacer-sc2a11-developerbox" > CONFIG_SYS_LOAD_ADDR=0x8000 > CONFIG_TARGET_DEVELOPERBOX=y > -CONFIG_FWU_NUM_IMAGES_PER_BANK=1 > CONFIG_AHCI=y > CONFIG_FIT=y > CONFIG_SYS_BOOTM_LEN=0x80 > CONFIG_BOOTSTAGE_STASH_SIZE=4096 > CONFIG_HUSH_PARSER=y > CONFIG_SYS_MAXARGS=128 > -CONFIG_CMD_FWU_METADATA=y > CONFIG_CMD_IMLS=y > CONFIG_CMD_ERASEENV=y > CONFIG_CMD_NVEDIT_EFI=y > @@ -53,7 +51,6 @@ CONFIG_DFU_TFTP=y > CONFIG_DFU_MTD=y > CONFIG_DFU_RAM=y > CONFIG_DFU_SF=y > -CONFIG_FWU_MDATA_MTD=y > CONFIG_DM_I2C=y > CONFIG_SYS_I2C_SYNQUACER=y > CONFIG_MMC_SDHCI=y > @@ -96,4 +93,3 @@ CONFIG_EFI_RUNTIME_UPDATE_CAPSULE=y > CONFIG_EFI_CAPSULE_ON_DISK=y > CONFIG_EFI_IGNORE_OSINDICATIONS=y > CONFIG_EFI_CAPSULE_FIRMWARE_RAW=y > -CONFIG_FWU_MULTI_BANK_UPDATE=y > -- > 2.34.1 > Reviewed-by: Ilias Apalodimas
Re: [PATCH 02/18] fwu: metadata: Migrate to version 2 of the structure
Hi Sughosh,
On Mon, Jan 22, 2024 at 05:24:23PM +0530, Sughosh Ganu wrote:
> The latest version of the FWU specification [1] has changes to the
> metadata structure. This is version 2 of the structure.
>
> Primary changes include
> - bank_state field in the top level structure
> - Total metadata size in the top level structure
> - Image description structures now optional
> - Number of banks and images per bank values part of the structure
>
> Migrate to the version 2 of the metadata structure.
>
> [1] - https://developer.arm.com/documentation/den0118/latest/
>
> Signed-off-by: Sughosh Ganu
> ---
> include/fwu_mdata.h | 56 +
> 1 file changed, 42 insertions(+), 14 deletions(-)
>
> diff --git a/include/fwu_mdata.h b/include/fwu_mdata.h
> index 56189e2f40..050ee969e3 100644
> --- a/include/fwu_mdata.h
> +++ b/include/fwu_mdata.h
> @@ -11,7 +11,7 @@
>
> /**
> * struct fwu_image_bank_info - firmware image information
> - * @image_uuid: Guid value of the image in this bank
> + * @image_guid: Guid value of the image in this bank
> * @accepted: Acceptance status of the image
> * @reserved: Reserved
> *
> @@ -20,15 +20,15 @@
> * acceptance status
> */
> struct fwu_image_bank_info {
> - efi_guid_t image_uuid;
> + efi_guid_t image_guid;
> uint32_t accepted;
> uint32_t reserved;
> } __packed;
>
> /**
> * struct fwu_image_entry - information for a particular type of image
> - * @image_type_uuid: Guid value for identifying the image type
> - * @location_uuid: Guid of the storage volume where the image is located
> + * @image_type_guid: Guid value for identifying the image type
> + * @location_guid: Guid of the storage volume where the image is located
> * @img_bank_info: Array containing properties of images
> *
> * This structure contains information on various types of updatable
> @@ -36,9 +36,30 @@ struct fwu_image_bank_info {
> * information per bank.
> */
> struct fwu_image_entry {
> - efi_guid_t image_type_uuid;
> - efi_guid_t location_uuid;
> - struct fwu_image_bank_info img_bank_info[CONFIG_FWU_NUM_BANKS];
> + efi_guid_t image_type_guid;
> + efi_guid_t location_guid;
> + struct fwu_image_bank_info img_bank_info[];
> +} __packed;
> +
> +/**
> + * struct fwu_fw_desc_store - FWU updatable image information
> + * @num_banks: Number of firmware banks
> + * num_images: Number of images per bank
> + * @img_entry_size: The size of the img_entry array
> + * @bank_info_entry_size: The size of the img_bank_info array
> + * @img_entry: Array of image entries each giving information on a image
> + *
> + * This image descriptor structure contains information on the number of
> + * updatable banks and images per bank. It also gives the total sizes of
> + * the fwu_image_entry and fwu_image_bank_info arrays.
> + */
> +struct fwu_fw_store_desc {
> + uint8_t num_banks;
> + uint8_t reserved;
> + uint16_t num_images;
> + uint16_t img_entry_size;
> + uint16_t bank_info_entry_size;
> + struct fwu_image_entry img_entry[];
This is a bit problematic. When a struct is defined using flexible array
members, you are not supposed to include it on other structs or arrays [0].
We need a way of working around this
> } __packed;
>
> /**
> @@ -48,21 +69,28 @@ struct fwu_image_entry {
> * @active_index: Index of the bank currently used for booting images
> * @previous_active_inde: Index of the bank used before the current bank
> *being used for booting
> - * @img_entry: Array of information on various firmware images that can
> - * be updated
> + * @metadata_size: Size of the entire metadata structure, including the
> + * image descriptors
> + * @desc_offset: The offset from the start of this structure where the
> + * image descriptor structure starts. 0 if absent
> + * @bank_state: State of each bank, valid, invalid or accepted
> + * @fw_desc: The structure describing the FWU updatable images
> *
> - * This structure is used to store all the needed information for performing
> + * This is the top level structure used to store all information for
> performing
> * multi bank updates on the platform. This contains info on the bank being
> - * used to boot along with the information needed for identification of
> - * individual images
> + * used to boot along with the information on state of individual banks.
> */
> struct fwu_mdata {
> uint32_t crc32;
> uint32_t version;
> uint32_t active_index;
> uint32_t previous_active_index;
> -
> - struct fwu_image_entry img_entry[CONFIG_FWU_NUM_IMAGES_PER_BANK];
> + uint32_t metadata_size;
> + uint16_t desc_offset;
> + uint16_t reserved1;
> + uint8_t bank_state[4];
> + uint32_t reserved2;
> + struct fwu_fw_store_desc fw_desc[];
ditto
> } __packed;
>
> #endif /* _FWU_MDATA_H_ */
> --
> 2.34.1
>
[0] git show b10bfd0019f601
Re: [PATCH] doc: dm: Fix typo
On 1/24/24 08:48, Alexander Dahl wrote:
That's most probably a typo, because driver model design documents seem
to be from 2012 and there is no 2010.01 release.
Fixes: 282ed24fb3ca ("dm: MIGRATION: Add migration plan for CONFIG_DM")
Signed-off-by: Alexander Dahl
Reviewed-by: Heinrich Schuchardt
---
Notes:
This was still in an old local branch of my working copy, but it applies
cleanly to master so I guess it is still valid?! ;-)
doc/develop/driver-model/migration.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/develop/driver-model/migration.rst
b/doc/develop/driver-model/migration.rst
index 03fea943b29..b40a6af9d11 100644
--- a/doc/develop/driver-model/migration.rst
+++ b/doc/develop/driver-model/migration.rst
@@ -13,7 +13,7 @@ CONFIG_DM
* Status: In progress
* Deadline: 2020.01
-Starting with the 2010.01 release CONFIG_DM will be enabled for all boards.
+Starting with the 2020.01 release CONFIG_DM will be enabled for all boards.
This does not concern CONFIG_DM_SPL and CONFIG_DM_TPL. The conversion date for
these configuration items still needs to be defined.
base-commit: 15e7927b5a2d33666af19879577bf0c30ab088fe
Re: [PATCH 15/18] rockchip: migrate hardware.h inclusion into appropriate files
Hi Kever, On 1/24/24 11:46, Kever Yang wrote: Hi Quentin, On 2024/1/23 22:49, Quentin Schulz wrote: From: Quentin Schulz Nothing of the hardware.h is used in include/configs, therefore, let's move that include to the files that actually require this include. hardware.h is one of common header for soc level, it's reasonable in the soc_common.h. hardware.h is only defining macros which are "wrappers" around writel(). writel() is NOT available in hardware.h, we need to include . Which means someone who wants to use the wrappers defined in hardware.h also needs to include the header, which doesn't make much sense. Why this is done is because if I include in hardware.h but do not remove hardware.h from the SoC configs header files, some boards stop compiling in arch/arm/cpu/armv8/u-boot.lds with a non-existing ALIGN signature (expects two arguments instead of 1). I assume this is because there's an ALIGN macro somewhere in asm/io.h that redefines the ALIGN assembly directive (c.f. https://developer.arm.com/documentation/dui0473/m/directives-reference/align) and that u-boot.lds somehow includes the SoC config header file (because IIRC this is also included in the autogenerated include/config.h which is included by "everything" ?) Basically, if I don't do that, then I need to manually add to any file that also include , which isn't really nice (but doable, we've done this until now). If you still prefer to keep hardware.h include in the SoC config header file, then lemme know and I'll drop the hardware.h and io.h patches from that patch series. Cheers, Quentin
Re: [PATCH] firmware: ti_sci: fix the secure_hdr in do_xfer
Dhruva Gole writes:
> The secure_hdr needs to be 0 init-ed however this was never being put
> into the secure_buf, leading to possibility of the first 4 bytes of
> secure_buf being possibly garbage.
>
> Fix this by initialising the secure_hdr itself to the secure_buf
> location, thus when we make it 0, it automatically ensures the first 4
> bytes are 0.
>
> Fixes: 32cd25128bd849 ("firmware: Add basic support for TI System Control
> Interface (TI SCI)")
> Signed-off-by: Dhruva Gole
> ---
>
> Boot tested for sanity on AM62x SK
> https://gist.github.com/DhruvaG2000/724ceba3a0db03f4b0bff47de1160074
>
> Cc: Nishanth Menon
> Cc: Tom Rini
>
> drivers/firmware/ti_sci.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/firmware/ti_sci.c b/drivers/firmware/ti_sci.c
> index f5f659c11274..83ee8401a731 100644
> --- a/drivers/firmware/ti_sci.c
> +++ b/drivers/firmware/ti_sci.c
> @@ -236,13 +236,13 @@ static int ti_sci_do_xfer(struct ti_sci_info *info,
> {
> struct k3_sec_proxy_msg *msg = >tx_message;
> u8 secure_buf[info->desc->max_msg_size];
> - struct ti_sci_secure_msg_hdr secure_hdr;
> + struct ti_sci_secure_msg_hdr *secure_hdr = (struct
> ti_sci_secure_msg_hdr *)secure_buf;
> int ret;
>
> if (info->is_secure) {
> /* ToDo: get checksum of the entire message */
> - secure_hdr.checksum = 0;
> - secure_hdr.reserved = 0;
> + secure_hdr->checksum = 0;
> + secure_hdr->reserved = 0;
> memcpy(_buf[sizeof(secure_hdr)],xfer->tx_message.buf,
secure_hdr is pointer now, the value may be same but (struct
ti_sci_secure_msg_hdr) would make more sense
Regards,
Kamlesh
> xfer->tx_message.len);
>
>
> base-commit: a1448e3cf9a0602d284566d6cacf60b96c3c1316
> --
> 2.34.1
Re: [PATCH 17/18] rockchip: rk3588: bind MMC controllers in U-Boot proper pre-reloc
Hi Kever,
On 1/24/24 11:35, Kever Yang wrote:
Hi Quentin,
On 2024/1/23 22:49, Quentin Schulz wrote:
From: Quentin Schulz
Since commit 9e644284ab81 ("dm: core: Report bootph-pre-ram/sram node as
pre-reloc after relocation"), bootph-pre-ram doesn't make U-Boot proper
bind the device before relocation.
While this is usually not much of an issue, it is when there's a lookup
for devices by code running before the relocation. Such is the case of
env_init() which calls env_driver_lookup() which calls
env_get_location() which is a weak symbol and may call
arch_env_get_location() also a weak symbol. Those are two functions that
may traverse UCLASS to find some devices (e.g.
board/theobroma-systems/common/common.c:arch_env_get_location()).
This sounds like we need to update arch_env_get_location() instead of
enable mmc driver
before relocate, because you we don't really need the mmc driver works
here, there is no
access requirement to mmc at this point, right?
All Rockchip SoCs except RK3588(S) and RK356x have it done this way, a
little bit of consistency wouldn't hurt :)
I need to be able to find out if the device that was used to load U-Boot
proper is an MMC device so that I can tell arch_env_get_location() to
return ENVL_MMC; in that case.
For that, I've used uclass_find_device_by_ofnode() which parses the list
of devices registered in the UCLASS_MMC (for that scenario). I assume
the only requirement is that the device needs to be bound, not probed
(haven't checked). If there's another way to do this **properly**, I'm
all ears. I would likely need to do the same for the SPI controllers but
since none of our RK3588-based products have SPI-NOR, I don't need those
(but it works on RK3399 just fine).
I still think there's value in having consistency between all Rockchip
SoCs (and if applicable to other SoC vendors, then those as well). We
could still do both though, have this and then fix the need for
requiring sdmmc/sdhci devices to be bound/probed for env_init()
(arch_env_get_location()) to work.
What is bothering you in enabling those drivers in U-Boot proper before
relocation?
Cheers,
Quentin
[PATCH] arm64: xilinx: Enable EFI_HTTP_BOOT by default
Enable EFI_HTTP_BOOT to be able to booting OS via http.
In case of that dhcp server is not providing dns server IP set it up via
setenv dnsip .
Signed-off-by: Michal Simek
---
I am ignoring defconfig sync because it needs to done because of
cda3f81b06f5 ("cmd/flash: Make this default y for CFI and NOR only")
anyway that's why I will just enable feature and Tom will run resync at
some point to remove automatically selected options.
---
configs/xilinx_versal_net_virt_defconfig | 1 +
configs/xilinx_versal_virt_defconfig | 1 +
configs/xilinx_zynqmp_kria_defconfig | 1 +
configs/xilinx_zynqmp_virt_defconfig | 1 +
4 files changed, 4 insertions(+)
diff --git a/configs/xilinx_versal_net_virt_defconfig
b/configs/xilinx_versal_net_virt_defconfig
index 371d14eb89b7..0f1d990936f3 100644
--- a/configs/xilinx_versal_net_virt_defconfig
+++ b/configs/xilinx_versal_net_virt_defconfig
@@ -146,3 +146,4 @@ CONFIG_VIRTIO_MMIO=y
CONFIG_VIRTIO_NET=y
CONFIG_VIRTIO_BLK=y
CONFIG_TPM=y
+CONFIG_EFI_HTTP_BOOT=y
diff --git a/configs/xilinx_versal_virt_defconfig
b/configs/xilinx_versal_virt_defconfig
index 5f76a305ab32..3c55dd8dcde9 100644
--- a/configs/xilinx_versal_virt_defconfig
+++ b/configs/xilinx_versal_virt_defconfig
@@ -153,3 +153,4 @@ CONFIG_VIRTIO_MMIO=y
CONFIG_VIRTIO_NET=y
CONFIG_VIRTIO_BLK=y
CONFIG_TPM=y
+CONFIG_EFI_HTTP_BOOT=y
diff --git a/configs/xilinx_zynqmp_kria_defconfig
b/configs/xilinx_zynqmp_kria_defconfig
index 0dc6c5b6877f..28b28f68411f 100644
--- a/configs/xilinx_zynqmp_kria_defconfig
+++ b/configs/xilinx_zynqmp_kria_defconfig
@@ -224,3 +224,4 @@ CONFIG_EFI_SET_TIME=y
CONFIG_EFI_RUNTIME_UPDATE_CAPSULE=y
CONFIG_EFI_CAPSULE_ON_DISK=y
CONFIG_EFI_CAPSULE_FIRMWARE_RAW=y
+CONFIG_EFI_HTTP_BOOT=y
diff --git a/configs/xilinx_zynqmp_virt_defconfig
b/configs/xilinx_zynqmp_virt_defconfig
index 2742e38b599e..1fcae45e95db 100644
--- a/configs/xilinx_zynqmp_virt_defconfig
+++ b/configs/xilinx_zynqmp_virt_defconfig
@@ -242,3 +242,4 @@ CONFIG_EFI_SET_TIME=y
CONFIG_EFI_RUNTIME_UPDATE_CAPSULE=y
CONFIG_EFI_CAPSULE_ON_DISK=y
CONFIG_EFI_CAPSULE_FIRMWARE_RAW=y
+CONFIG_EFI_HTTP_BOOT=y
--
2.36.1
Re: [PATCH 13/18] rockchip: rk3588: fix non-working SD controller if booting from other media
Hi Kever, On 1/24/24 11:19, Kever Yang wrote: Hi Quentin, On 2024/1/23 22:49, Quentin Schulz wrote: From: Quentin Schulz Rockchip SoCs have some jtag/sdmmc autoswitching that simply doesn't work really well.[00] The Linux kernel disables it for all SoCs[01], so U-Boot needs to do the same in order to fix issues related to SD card on RK3588. This autoswitching is enabled (by default) via the force_jtag bitfield in SYS_GRF_SOC_CON6 in the TRM part1. For some reason, when booting from SD card, the BootROM does mux the SDMMC controller in the proper configuration for the RK3588-Jaguar. But when we don't boot from SD card, U-Boot needs to set it up correctly to allow accessing SD cards in that configuration. Could you share what's the really issue you met in your board? I revert the patch and then I have the following when booting from eMMC: """ DDR V1.11 f1474cf52f cym 23/05/09-11:02:36 LPDDR4X, 2112MHz channel[0] BW=16 Col=10 Bk=8 CS0 Row=16 CS=1 Die BW=16 Size=1024MB channel[1] BW=16 Col=10 Bk=8 CS0 Row=16 CS=1 Die BW=16 Size=1024MB channel[2] BW=16 Col=10 Bk=8 CS0 Row=16 CS=1 Die BW=16 Size=1024MB channel[3] BW=16 Col=10 Bk=8 CS0 Row=16 CS=1 Die BW=16 Size=1024MB Manufacturer ID:0x1 CH0 RX Vref:27.1%, TX Vref:21.8%,0.0% CH1 RX Vref:30.1%, TX Vref:20.8%,0.0% CH2 RX Vref:27.9%, TX Vref:21.8%,0.0% CH3 RX Vref:31.4%, TX Vref:19.8%,0.0% change to F1: 528MHz change to F2: 1068MHz change to F3: 1560MHz change to F0: 2112MHz out U-Boot SPL 2024.01-00344-gf1fab3b9557 (Jan 24 2024 - 11:33:43 +0100) Trying to boot from MMC1 ## Checking hash(es) for config config-1 ... OK ## Checking hash(es) for Image atf-1 ... sha256+ OK ## Checking hash(es) for Image u-boot ... sha256+ OK ## Checking hash(es) for Image fdt-1 ... sha256+ OK ## Checking hash(es) for Image atf-2 ... sha256+ OK ## Checking hash(es) for Image atf-3 ... sha256+ OK INFO:Preloader serial: 2 NOTICE: BL31: v2.3():v2.3-589-g3389cfdda:derrick.huang NOTICE: BL31: Built : 10:14:29, May 9 2023 INFO:spec: 0x1 INFO:ext 32k is not valid INFO:ddr: stride-en 4CH INFO:GICv3 without legacy support detected. INFO:ARM GICv3 driver initialized in EL3 INFO:valid_cpu_msk=0xff bcore0_rst = 0x0, bcore1_rst = 0x0 INFO:system boots from cpu-hwid-0 INFO:idle_st=0x21fff, pd_st=0x11fff9, repair_st=0xfff70001 INFO:dfs DDR fsp_params[0].freq_mhz= 2112MHz INFO:dfs DDR fsp_params[1].freq_mhz= 528MHz INFO:dfs DDR fsp_params[2].freq_mhz= 1068MHz INFO:dfs DDR fsp_params[3].freq_mhz= 1560MHz INFO:BL31: Initialising Exception Handling Framework INFO:BL31: Initializing runtime services WARNING: No OPTEE provided by BL2 boot loader, Booting device without OPTEE initialization. SMC`s destined for OPTEE will return SMC_UNK ERROR: Error initializing runtime service opteed_fast INFO:BL31: Preparing for EL3 exit to normal world INFO:Entry point address = 0xa0 INFO:SPSR = 0x3c9 U-Boot 2024.01-00344-gf1fab3b9557 (Jan 24 2024 - 11:33:43 +0100) Model: Theobroma Systems RK3588-SBC Jaguar DRAM: 4 GiB (effective 3.7 GiB) Core: 327 devices, 26 uclasses, devicetree: separate MMC: mmc@fe2c: 1, mmc@fe2e: 0 Loading Environment from MMC... *** Warning - bad CRC, using default environment In:serial@feb5 Out: serial@feb5 Err: serial@feb5 Model: Theobroma Systems RK3588-SBC Jaguar Net: eth0: ethernet@fe1b Hit any key to stop autoboot: 0 => mmc dev 1 unable to select a mode => """ The SD card will need to enable SD-DET for SD card function int he hardware design, We do not have an SD-DET on that board, this is not possible (the connector doesn't support it). SDMMC_DET/GPIO0_A4_u signal is pulled low in HW if left floating (the state by default since we expose it on an external connector) but we plan to let customer use it as a GPIO. which is rockchip reference design and followed by most of the customer and boards. This feature works in all the rk3588 boards we known, and no need to disable this auto switching. This is clearly not what people have experienced, c.f. the Linux kernel patch: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/soc/rockchip/grf.c?id=6f6878ec6faf16a5f36761c93da6ea9cf09adb33 Note that jtag_switching has been disabled for all Rockchip SoCs in the kernel, for a long long time already, c.f. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/soc/rockchip/grf.c?id=4c58063d4258f6beb4fd5647db6b58f49e337c8f Cheers, Quentin
Re: [PATCH 15/18] rockchip: migrate hardware.h inclusion into appropriate files
Hi Quentin, On 2024/1/23 22:49, Quentin Schulz wrote: From: Quentin Schulz Nothing of the hardware.h is used in include/configs, therefore, let's move that include to the files that actually require this include. hardware.h is one of common header for soc level, it's reasonable in the soc_common.h. Thanks, - Kever Cc: Quentin Schulz Signed-off-by: Quentin Schulz --- arch/arm/mach-rockchip/rk3066/rk3066.c | 1 + drivers/ram/rockchip/dmc-rk3368.c | 1 + drivers/ram/rockchip/sdram_rk3188.c| 1 + drivers/ram/rockchip/sdram_rk3288.c| 1 + include/configs/rk3036_common.h| 1 - include/configs/rk3066_common.h| 1 - include/configs/rk3188_common.h| 1 - include/configs/rk322x_common.h| 1 - include/configs/rk3288_common.h| 1 - include/configs/rk3368_common.h| 1 - include/configs/rv1108_common.h| 1 - 11 files changed, 4 insertions(+), 7 deletions(-) diff --git a/arch/arm/mach-rockchip/rk3066/rk3066.c b/arch/arm/mach-rockchip/rk3066/rk3066.c index 78c7d894f90..6661b788295 100644 --- a/arch/arm/mach-rockchip/rk3066/rk3066.c +++ b/arch/arm/mach-rockchip/rk3066/rk3066.c @@ -7,6 +7,7 @@ #include #include #include +#include #define GRF_BASE 0x20008000 diff --git a/drivers/ram/rockchip/dmc-rk3368.c b/drivers/ram/rockchip/dmc-rk3368.c index f36be941a38..74d8aed571c 100644 --- a/drivers/ram/rockchip/dmc-rk3368.c +++ b/drivers/ram/rockchip/dmc-rk3368.c @@ -20,6 +20,7 @@ #include #include #include +#include #include #include #include diff --git a/drivers/ram/rockchip/sdram_rk3188.c b/drivers/ram/rockchip/sdram_rk3188.c index ad9f936df55..16a68885f1f 100644 --- a/drivers/ram/rockchip/sdram_rk3188.c +++ b/drivers/ram/rockchip/sdram_rk3188.c @@ -25,6 +25,7 @@ #include #include #include +#include #include #include diff --git a/drivers/ram/rockchip/sdram_rk3288.c b/drivers/ram/rockchip/sdram_rk3288.c index c99118fd612..ec6bdcb2015 100644 --- a/drivers/ram/rockchip/sdram_rk3288.c +++ b/drivers/ram/rockchip/sdram_rk3288.c @@ -25,6 +25,7 @@ #include #include #include +#include #include #include #include diff --git a/include/configs/rk3036_common.h b/include/configs/rk3036_common.h index c2abd14e114..0bf9e8b9a2e 100644 --- a/include/configs/rk3036_common.h +++ b/include/configs/rk3036_common.h @@ -5,7 +5,6 @@ #ifndef __CONFIG_RK3036_COMMON_H #define __CONFIG_RK3036_COMMON_H -#include #include "rockchip-common.h" #define CFG_SYS_HZ_CLOCK 2400 diff --git a/include/configs/rk3066_common.h b/include/configs/rk3066_common.h index d70c8f77d48..6a3b6900463 100644 --- a/include/configs/rk3066_common.h +++ b/include/configs/rk3066_common.h @@ -6,7 +6,6 @@ #ifndef __CONFIG_RK3066_COMMON_H #define __CONFIG_RK3066_COMMON_H -#include #include "rockchip-common.h" #define CFG_IRAM_BASE 0x1008 diff --git a/include/configs/rk3188_common.h b/include/configs/rk3188_common.h index a8cee1e44d4..98f2c25f3cf 100644 --- a/include/configs/rk3188_common.h +++ b/include/configs/rk3188_common.h @@ -6,7 +6,6 @@ #ifndef __CONFIG_RK3188_COMMON_H #define __CONFIG_RK3188_COMMON_H -#include #include "rockchip-common.h" #define CFG_IRAM_BASE 0x1008 diff --git a/include/configs/rk322x_common.h b/include/configs/rk322x_common.h index 15f77df3e17..bab4ca015f7 100644 --- a/include/configs/rk322x_common.h +++ b/include/configs/rk322x_common.h @@ -5,7 +5,6 @@ #ifndef __CONFIG_RK322X_COMMON_H #define __CONFIG_RK322X_COMMON_H -#include #include "rockchip-common.h" #define CFG_SYS_HZ_CLOCK 2400 diff --git a/include/configs/rk3288_common.h b/include/configs/rk3288_common.h index 3063076a97a..0c449e31099 100644 --- a/include/configs/rk3288_common.h +++ b/include/configs/rk3288_common.h @@ -6,7 +6,6 @@ #ifndef __CONFIG_RK3288_COMMON_H #define __CONFIG_RK3288_COMMON_H -#include #include "rockchip-common.h" #define CFG_SYS_HZ_CLOCK 2400 diff --git a/include/configs/rk3368_common.h b/include/configs/rk3368_common.h index ccb5369b901..d488f8d477a 100644 --- a/include/configs/rk3368_common.h +++ b/include/configs/rk3368_common.h @@ -8,7 +8,6 @@ #include "rockchip-common.h" -#include #include #define CFG_SYS_SDRAM_BASE 0 diff --git a/include/configs/rv1108_common.h b/include/configs/rv1108_common.h index 3bf70a0e0ae..ff28236a21d 100644 --- a/include/configs/rv1108_common.h +++ b/include/configs/rv1108_common.h @@ -5,7 +5,6 @@ #ifndef __CONFIG_RV1108_COMMON_H #define __CONFIG_RV1108_COMMON_H -#include #include "rockchip-common.h" #define CFG_IRAM_BASE 0x1008
Re: [PATCH] firmware: ti_sci: fix the secure_hdr in do_xfer
On Jan 24, 2024 at 15:45:58 +0530, Dhruva Gole wrote:
> The secure_hdr needs to be 0 init-ed however this was never being put
> into the secure_buf, leading to possibility of the first 4 bytes of
> secure_buf being possibly garbage.
>
> Fix this by initialising the secure_hdr itself to the secure_buf
> location, thus when we make it 0, it automatically ensures the first 4
> bytes are 0.
>
> Fixes: 32cd25128bd849 ("firmware: Add basic support for TI System Control
> Interface (TI SCI)")
> Signed-off-by: Dhruva Gole
> ---
>
> Boot tested for sanity on AM62x SK
> https://gist.github.com/DhruvaG2000/724ceba3a0db03f4b0bff47de1160074
>
> Cc: Nishanth Menon
> Cc: Tom Rini
>
> drivers/firmware/ti_sci.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
Kindly ignore this patch, seems like it's from an older u-boot. I have
rebased an sent new patch with updated boot logs.
Please forgive the spam.
--
Best regards,
Dhruva Gole
[PATCH V2] firmware: ti_sci: fix the secure_hdr in do_xfer
The secure_hdr needs to be 0 init-ed however this was never being put
into the secure_buf, leading to possibility of the first 4 bytes of
secure_buf being possibly garbage.
Fix this by initialising the secure_hdr itself to the secure_buf
location, thus when we make it 0, it automatically ensures the first 4
bytes are 0.
Fixes: 32cd25128bd849 ("firmware: Add basic support for TI System Control
Interface (TI SCI)")
Signed-off-by: Dhruva Gole
---
Boot tested for sanity on AM62x SK
https://gist.github.com/DhruvaG2000/724ceba3a0db03f4b0bff47de1160074
Changelog:
Rebased on top of latest master branch
Cc: Nishanth Menon
Cc: Tom Rini
Cc: Neha Francis
Cc: Manorit Chawdhry ,
Cc: Vignesh Raghavendra ,
Cc: Kamlesh Gurudasani
drivers/firmware/ti_sci.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/firmware/ti_sci.c b/drivers/firmware/ti_sci.c
index 6e9f93e9a302..f7675e383d47 100644
--- a/drivers/firmware/ti_sci.c
+++ b/drivers/firmware/ti_sci.c
@@ -236,13 +236,13 @@ static int ti_sci_do_xfer(struct ti_sci_info *info,
{
struct k3_sec_proxy_msg *msg = >tx_message;
u8 secure_buf[info->desc->max_msg_size];
- struct ti_sci_secure_msg_hdr secure_hdr;
+ struct ti_sci_secure_msg_hdr *secure_hdr = (struct
ti_sci_secure_msg_hdr *)secure_buf;
int ret;
if (info->is_secure) {
/* ToDo: get checksum of the entire message */
- secure_hdr.checksum = 0;
- secure_hdr.reserved = 0;
+ secure_hdr->checksum = 0;
+ secure_hdr->reserved = 0;
memcpy(_buf[sizeof(secure_hdr)], xfer->tx_message.buf,
xfer->tx_message.len);
base-commit: 15e7927b5a2d33666af19879577bf0c30ab088fe
--
2.34.1
Re: [PATCH 17/18] rockchip: rk3588: bind MMC controllers in U-Boot proper pre-reloc
Hi Quentin,
On 2024/1/23 22:49, Quentin Schulz wrote:
From: Quentin Schulz
Since commit 9e644284ab81 ("dm: core: Report bootph-pre-ram/sram node as
pre-reloc after relocation"), bootph-pre-ram doesn't make U-Boot proper
bind the device before relocation.
While this is usually not much of an issue, it is when there's a lookup
for devices by code running before the relocation. Such is the case of
env_init() which calls env_driver_lookup() which calls
env_get_location() which is a weak symbol and may call
arch_env_get_location() also a weak symbol. Those are two functions that
may traverse UCLASS to find some devices (e.g.
board/theobroma-systems/common/common.c:arch_env_get_location()).
This sounds like we need to update arch_env_get_location() instead of
enable mmc driver
before relocate, because you we don't really need the mmc driver works
here, there is no
access requirement to mmc at this point, right?
Thanks,
- Kever
This allows something in the env_init() call stack to be able to use
uclasses for SD and eMMC controller on RK3588S/RK3588. This aligns the
behavior with what seems to be all SoCs except RK356x family.
Cc: Quentin Schulz
Signed-off-by: Quentin Schulz
---
arch/arm/dts/rk3588s-u-boot.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/dts/rk3588s-u-boot.dtsi b/arch/arm/dts/rk3588s-u-boot.dtsi
index 960ac4abda3..bdfe13836b2 100644
--- a/arch/arm/dts/rk3588s-u-boot.dtsi
+++ b/arch/arm/dts/rk3588s-u-boot.dtsi
@@ -187,12 +187,12 @@
};
{
- bootph-pre-ram;
+ bootph-all;
u-boot,spl-fifo-mode;
};
{
- bootph-pre-ram;
+ bootph-all;
u-boot,spl-fifo-mode;
};
Re: [PATCH 13/18] rockchip: rk3588: fix non-working SD controller if booting from other media
Hi Quentin,
On 2024/1/23 22:49, Quentin Schulz wrote:
From: Quentin Schulz
Rockchip SoCs have some jtag/sdmmc autoswitching that simply doesn't
work really well.[00] The Linux kernel disables it for all SoCs[01], so
U-Boot needs to do the same in order to fix issues related to SD card on
RK3588. This autoswitching is enabled (by default) via the force_jtag
bitfield in SYS_GRF_SOC_CON6 in the TRM part1.
For some reason, when booting from SD card, the BootROM does mux the
SDMMC controller in the proper configuration for the RK3588-Jaguar. But
when we don't boot from SD card, U-Boot needs to set it up correctly to
allow accessing SD cards in that configuration.
Could you share what's the really issue you met in your board?
The SD card will need to enable SD-DET for SD card function int he
hardware design,
which is rockchip reference design and followed by most of the customer
and boards.
This feature works in all the rk3588 boards we known, and no need to
disable this auto switching.
Thanks,
- Kever
Therefore, let's disable the JTAG mode for the SDMMC pins so that the SD
controller can be used either as a fallback mechanism to find U-Boot
proper when the boot medium used to load TPL/SPL cannot find U-Boot
proper, or to be used in U-Boot CLI.
Note that soc_con[0] is reserved. But considering that it's way more
user-friendly to access soc_con1 from the TRM with soc_con[1] than
soc_con[0], and that soc_con0 would actually be located at 4 bytes
before soc_con1, let's just make soc_con0 part of the soc_con array.
[00]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c9b75d51c940c25587a2ad72ec7ec60490abfb6c
[01]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/soc/rockchip/grf.c
Cc: Quentin Schulz
Signed-off-by: Quentin Schulz
---
arch/arm/include/asm/arch-rockchip/grf_rk3588.h | 24
arch/arm/mach-rockchip/rk3588/rk3588.c | 7 +++
2 files changed, 31 insertions(+)
diff --git a/arch/arm/include/asm/arch-rockchip/grf_rk3588.h
b/arch/arm/include/asm/arch-rockchip/grf_rk3588.h
index e0694068bb1..f0ecff97f0b 100644
--- a/arch/arm/include/asm/arch-rockchip/grf_rk3588.h
+++ b/arch/arm/include/asm/arch-rockchip/grf_rk3588.h
@@ -32,4 +32,28 @@ struct rk3588_pmu1grf {
check_member(rk3588_pmu1grf, sd_detect_cnt, 0x03b0);
+#define SYS_GRF_BASE 0xfd58c000
+
+struct rk3588_sysgrf {
+ unsigned int wdt_con0;
+ unsigned int reserved0[(0x0010 - 0x) / 4 - 1];
+ unsigned int uart_con[2];
+ unsigned int reserved1[(0x00c0 - 0x0014) / 4 - 1];
+ unsigned int gic_con0;
+ unsigned int reserved2[(0x0200 - 0x00c0) / 4 - 1];
+ unsigned int memcfg_con[32];
+ unsigned int reserved3[(0x0300 - 0x027c) / 4 - 1];
+ /* soc_con0 is reserved */
+ unsigned int soc_con[14];
+ unsigned int reserved4[(0x0380 - 0x0334) / 4 - 1];
+ unsigned int soc_status[4];
+ unsigned int reserved5[(0x0500 - 0x038c) / 4 - 1];
+ unsigned int otp_key08;
+ unsigned int otp_key0d;
+ unsigned int otp_key0e;
+ unsigned int reserved6[(0x0600 - 0x0508) / 4 - 1];
+ unsigned int chip_id;
+};
+
+check_member(rk3588_sysgrf, chip_id, 0x0600);
#endif /*__SOC_ROCKCHIP_RK3588_GRF_H__ */
diff --git a/arch/arm/mach-rockchip/rk3588/rk3588.c
b/arch/arm/mach-rockchip/rk3588/rk3588.c
index 38e95a6e2b2..c5eeda9d751 100644
--- a/arch/arm/mach-rockchip/rk3588/rk3588.c
+++ b/arch/arm/mach-rockchip/rk3588/rk3588.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#define FIREWALL_DDR_BASE 0xfe03
#define FW_DDR_MST5_REG 0x54
@@ -35,6 +36,8 @@
#define BUS_IOC_GPIO2D_IOMUX_SEL_H0x5c
#define BUS_IOC_GPIO3A_IOMUX_SEL_L0x60
+#define SYS_GRF_FORCE_JTAG BIT(14)
+
/**
* Boot-device identifiers used by the BROM on RK3588 when device is booted
* from SPI flash. IOMUX used for SPI flash affect the value used by the BROM
@@ -134,6 +137,7 @@ void rockchip_stimer_init(void)
int arch_cpu_init(void)
{
#ifdef CONFIG_SPL_BUILD
+ static struct rk3588_sysgrf * const sys_grf = (void *)SYS_GRF_BASE;
int secure_reg;
/* Set the SDMMC eMMC crypto_ns FSPI access secure area */
@@ -168,6 +172,9 @@ int arch_cpu_init(void)
secure_reg = readl(FIREWALL_SYSMEM_BASE + FW_SYSM_MST27_REG);
secure_reg &= 0x;
writel(secure_reg, FIREWALL_SYSMEM_BASE + FW_SYSM_MST27_REG);
+
+ /* Disable JTAG exposed on SDMMC */
+ rk_clrreg(_grf->soc_con[6], SYS_GRF_FORCE_JTAG);
#endif
return 0;
[PATCH] firmware: ti_sci: fix the secure_hdr in do_xfer
The secure_hdr needs to be 0 init-ed however this was never being put
into the secure_buf, leading to possibility of the first 4 bytes of
secure_buf being possibly garbage.
Fix this by initialising the secure_hdr itself to the secure_buf
location, thus when we make it 0, it automatically ensures the first 4
bytes are 0.
Fixes: 32cd25128bd849 ("firmware: Add basic support for TI System Control
Interface (TI SCI)")
Signed-off-by: Dhruva Gole
---
Boot tested for sanity on AM62x SK
https://gist.github.com/DhruvaG2000/724ceba3a0db03f4b0bff47de1160074
Cc: Nishanth Menon
Cc: Tom Rini
drivers/firmware/ti_sci.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/firmware/ti_sci.c b/drivers/firmware/ti_sci.c
index f5f659c11274..83ee8401a731 100644
--- a/drivers/firmware/ti_sci.c
+++ b/drivers/firmware/ti_sci.c
@@ -236,13 +236,13 @@ static int ti_sci_do_xfer(struct ti_sci_info *info,
{
struct k3_sec_proxy_msg *msg = >tx_message;
u8 secure_buf[info->desc->max_msg_size];
- struct ti_sci_secure_msg_hdr secure_hdr;
+ struct ti_sci_secure_msg_hdr *secure_hdr = (struct
ti_sci_secure_msg_hdr *)secure_buf;
int ret;
if (info->is_secure) {
/* ToDo: get checksum of the entire message */
- secure_hdr.checksum = 0;
- secure_hdr.reserved = 0;
+ secure_hdr->checksum = 0;
+ secure_hdr->reserved = 0;
memcpy(_buf[sizeof(secure_hdr)], xfer->tx_message.buf,
xfer->tx_message.len);
base-commit: a1448e3cf9a0602d284566d6cacf60b96c3c1316
--
2.34.1
Re: [PATCH 00/18] FWU: Migrate FWU metadata to version 2
Hi Sughosh, On Mon, Jan 22, 2024 at 05:24:21PM +0530, Sughosh Ganu wrote: > > The following patches migrate the FWU metadata access code to version > 2 of the structure. This is based on the structure definition as > defined in the latest rev of the FWU Multi Bank Update specification > [1]. > > Since the version 1 of the structure has currently been adopted on a > couple of platforms, it was decided to have a clean migration of the > metadata to version 2 only, instead of supporting both the versions of > the structure. Also, based on consultations with the main author of > the specification, it is expected that any further changes in the > structure would be minor tweaks, and not be significant. Hence a > migration to version 2. I think this makes sense. We've already verified Socionext doesn't mind dropping v1 support. If some from ST doesn't have objections, only supporting v2 will simplify the code a lot. Thanks /Ilias > > Similar migration is also being done in TF-A, including migrating the > ST platform port to support version 2 of the metadata structure [2]. > > The patches have been tested on STM32MP1 DK2 board and the Synquacer > board from Socionext. This covers testing both the GPT and the MTD > partitioned storage devices for the metadata access. > > [1] - https://developer.arm.com/documentation/den0118/latest/ > [2] - > https://review.trustedfirmware.org/q/topic:%22topics/fwu_metadata_v2_migration%22 > > Sughosh Ganu (18): > configs: fwu: Remove FWU configs for metadata V2 migration > fwu: metadata: Migrate to version 2 of the structure > drivers: fwu: Add the size parameter to the metadata access API's > fwu: Add some API's for metadata version 2 access > lib: fwu: Make changes to support version 2 of FWU metadata > drivers: fwu: mtd: Allocate buffer for image info dynamically > drivers: fwu: Allocate memory for metadata copies > fwu: Add a function to put a bank in Trial State > capsule: Accept a bank on a successful update > fwu: mtd: Modify the DFU API's to align with metadata version 2 > efi_firmware: fwu: Do not read FWU metadata on sandbox > efi_firmware: fwu: Get the number of FWU banks at runtime > cmd: fwu: Align the command with metadata version 2 > test: fwu: Align the FWU metadata access test with version 2 > fwu: Remove the config symbols for number of banks and images > tools: mkfwumdata: Migrate to metadata version 2 > configs: fwu: Re-enable FWU configs > doc: fwu: Make changes for supporting FWU Metadata version 2 > > arch/sandbox/Kconfig | 6 - > board/armltd/corstone1000/corstone1000.c | 2 +- > cmd/fwu_mdata.c | 43 +++- > configs/synquacer_developerbox_defconfig | 1 - > doc/board/socionext/developerbox.rst | 9 +- > doc/develop/uefi/fwu_updates.rst | 12 +- > doc/usage/cmd/fwu_mdata.rst | 12 +- > drivers/fwu-mdata/fwu-mdata-uclass.c | 10 +- > drivers/fwu-mdata/gpt_blk.c | 27 +- > drivers/fwu-mdata/raw_mtd.c | 85 --- > include/fwu.h| 94 ++- > include/fwu_mdata.h | 56 +++-- > lib/efi_loader/efi_capsule.c | 12 +- > lib/efi_loader/efi_firmware.c| 20 +- > lib/fwu_updates/Kconfig | 11 - > lib/fwu_updates/fwu.c| 308 ++- > lib/fwu_updates/fwu_mtd.c| 76 -- > test/dm/fwu_mdata.c | 56 +++-- > test/dm/fwu_mdata_disk_image.h | 124 - > tools/mkfwumdata.c | 43 +++- > 20 files changed, 705 insertions(+), 302 deletions(-) > > -- > 2.34.1 > >
Re: [PATCH] efi_loader: migrate SMBIOS 3.0 entry point structure for measurement
On 1/24/24 10:15, Masahisa Kojima wrote:
Current U-Boot only supports the SMBIOS 3.0 entry point structure.
TCG2 measurement code should migrate to SMBIOS 3.0 entry
point structure.
efi_selftest tcg2 test also needs to be updated, and expected
PCR[1] result is changed since guid for SMBIOS EFI system table
uses different guid SMBIOS3_TABLE_GUID instead of SMBIOS_TABLE_GUID.
Signed-off-by: Masahisa Kojima
Hello Maasahisa,
Thank you for looking into this.
SMBIOS tables may be provided by QEMU. Depending on the architecture and
the QEMU release we will see SMBIOS2.1 and SMBIOS3 tables. We should
support measuring for both.
Best regards
Heinrich
---
include/efi_loader.h | 1 +
include/smbios.h | 4 +-
lib/efi_loader/efi_tcg2.c| 14 ++--
lib/efi_selftest/efi_selftest_tcg2.c | 97 +---
lib/smbios-parser.c | 9 ++-
5 files changed, 61 insertions(+), 64 deletions(-)
diff --git a/include/efi_loader.h b/include/efi_loader.h
index d5fca2fa5e..5c5af4f7fd 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -340,6 +340,7 @@ extern const efi_guid_t
efi_guid_firmware_management_protocol;
extern const efi_guid_t efi_esrt_guid;
/* GUID of the SMBIOS table */
extern const efi_guid_t smbios_guid;
+extern const efi_guid_t smbios3_guid;
/*GUID of console */
extern const efi_guid_t efi_guid_text_input_protocol;
extern const efi_guid_t efi_guid_text_output_protocol;
diff --git a/include/smbios.h b/include/smbios.h
index b507b9d9d7..e45303d0d3 100644
--- a/include/smbios.h
+++ b/include/smbios.h
@@ -326,10 +326,10 @@ int smbios_update_version_full(void *smbios_tab, const
char *version);
* This function clear the device dependent parameters such as
* serial number for the measurement.
*
- * @entry: pointer to a struct smbios_entry
+ * @entry: pointer to a struct smbios3_entry
* @header: pointer to a struct smbios_header
*/
-void smbios_prepare_measurement(const struct smbios_entry *entry,
+void smbios_prepare_measurement(const struct smbios3_entry *entry,
struct smbios_header *header);
#endif /* _SMBIOS_H_ */
diff --git a/lib/efi_loader/efi_tcg2.c b/lib/efi_loader/efi_tcg2.c
index 8db35d0b3c..8b4f2fd2da 100644
--- a/lib/efi_loader/efi_tcg2.c
+++ b/lib/efi_loader/efi_tcg2.c
@@ -1075,7 +1075,7 @@ error:
*/
static efi_status_t
tcg2_measure_smbios(struct udevice *dev,
- const struct smbios_entry *entry)
+ const struct smbios3_entry *entry)
{
efi_status_t ret;
struct smbios_header *smbios_copy;
@@ -1093,7 +1093,7 @@ tcg2_measure_smbios(struct udevice *dev,
*/
event_size = sizeof(struct smbios_handoff_table_pointers2) +
FIELD_SIZEOF(struct efi_configuration_table, guid) +
-entry->struct_table_length;
+entry->max_struct_size;
event = calloc(1, event_size);
if (!event) {
ret = EFI_OUT_OF_RESOURCES;
@@ -1104,11 +1104,11 @@ tcg2_measure_smbios(struct udevice *dev,
memcpy(event->table_description, SMBIOS_HANDOFF_TABLE_DESC,
sizeof(SMBIOS_HANDOFF_TABLE_DESC));
put_unaligned_le64(1, >number_of_tables);
- guidcpy(>table_entry[0].guid, _guid);
+ guidcpy(>table_entry[0].guid, _guid);
smbios_copy = (struct smbios_header
*)((uintptr_t)>table_entry[0].table);
memcpy(>table_entry[0].table,
(void *)((uintptr_t)entry->struct_table_address),
- entry->struct_table_length);
+ entry->max_struct_size);
smbios_prepare_measurement(entry, smbios_copy);
@@ -1133,7 +1133,7 @@ static void *find_smbios_table(void)
u32 i;
for (i = 0; i < systab.nr_tables; i++) {
- if (!guidcmp(_guid, [i].guid))
+ if (!guidcmp(_guid, [i].guid))
return systab.tables[i].table;
}
@@ -1360,7 +1360,7 @@ efi_status_t efi_tcg2_measure_efi_app_invocation(struct
efi_loaded_image_obj *ha
u32 pcr_index;
struct udevice *dev;
u32 event = 0;
- struct smbios_entry *entry;
+ struct smbios3_entry *entry;
if (!is_tcg2_protocol_installed())
return EFI_SUCCESS;
@@ -1382,7 +1382,7 @@ efi_status_t efi_tcg2_measure_efi_app_invocation(struct
efi_loaded_image_obj *ha
if (ret != EFI_SUCCESS)
goto out;
- entry = (struct smbios_entry *)find_smbios_table();
+ entry = (struct smbios3_entry *)find_smbios_table();
if (entry) {
ret = tcg2_measure_smbios(dev, entry);
if (ret != EFI_SUCCESS)
diff --git a/lib/efi_selftest/efi_selftest_tcg2.c
b/lib/efi_selftest/efi_selftest_tcg2.c
index 67a886efaa..fb8b997653 100644
--- a/lib/efi_selftest/efi_selftest_tcg2.c
+++ b/lib/efi_selftest/efi_selftest_tcg2.c
@@ -126,41 +126,40 @@ static u8
[PATCH] efi_loader: migrate SMBIOS 3.0 entry point structure for measurement
Current U-Boot only supports the SMBIOS 3.0 entry point structure.
TCG2 measurement code should migrate to SMBIOS 3.0 entry
point structure.
efi_selftest tcg2 test also needs to be updated, and expected
PCR[1] result is changed since guid for SMBIOS EFI system table
uses different guid SMBIOS3_TABLE_GUID instead of SMBIOS_TABLE_GUID.
Signed-off-by: Masahisa Kojima
---
include/efi_loader.h | 1 +
include/smbios.h | 4 +-
lib/efi_loader/efi_tcg2.c| 14 ++--
lib/efi_selftest/efi_selftest_tcg2.c | 97 +---
lib/smbios-parser.c | 9 ++-
5 files changed, 61 insertions(+), 64 deletions(-)
diff --git a/include/efi_loader.h b/include/efi_loader.h
index d5fca2fa5e..5c5af4f7fd 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -340,6 +340,7 @@ extern const efi_guid_t
efi_guid_firmware_management_protocol;
extern const efi_guid_t efi_esrt_guid;
/* GUID of the SMBIOS table */
extern const efi_guid_t smbios_guid;
+extern const efi_guid_t smbios3_guid;
/*GUID of console */
extern const efi_guid_t efi_guid_text_input_protocol;
extern const efi_guid_t efi_guid_text_output_protocol;
diff --git a/include/smbios.h b/include/smbios.h
index b507b9d9d7..e45303d0d3 100644
--- a/include/smbios.h
+++ b/include/smbios.h
@@ -326,10 +326,10 @@ int smbios_update_version_full(void *smbios_tab, const
char *version);
* This function clear the device dependent parameters such as
* serial number for the measurement.
*
- * @entry: pointer to a struct smbios_entry
+ * @entry: pointer to a struct smbios3_entry
* @header: pointer to a struct smbios_header
*/
-void smbios_prepare_measurement(const struct smbios_entry *entry,
+void smbios_prepare_measurement(const struct smbios3_entry *entry,
struct smbios_header *header);
#endif /* _SMBIOS_H_ */
diff --git a/lib/efi_loader/efi_tcg2.c b/lib/efi_loader/efi_tcg2.c
index 8db35d0b3c..8b4f2fd2da 100644
--- a/lib/efi_loader/efi_tcg2.c
+++ b/lib/efi_loader/efi_tcg2.c
@@ -1075,7 +1075,7 @@ error:
*/
static efi_status_t
tcg2_measure_smbios(struct udevice *dev,
- const struct smbios_entry *entry)
+ const struct smbios3_entry *entry)
{
efi_status_t ret;
struct smbios_header *smbios_copy;
@@ -1093,7 +1093,7 @@ tcg2_measure_smbios(struct udevice *dev,
*/
event_size = sizeof(struct smbios_handoff_table_pointers2) +
FIELD_SIZEOF(struct efi_configuration_table, guid) +
-entry->struct_table_length;
+entry->max_struct_size;
event = calloc(1, event_size);
if (!event) {
ret = EFI_OUT_OF_RESOURCES;
@@ -1104,11 +1104,11 @@ tcg2_measure_smbios(struct udevice *dev,
memcpy(event->table_description, SMBIOS_HANDOFF_TABLE_DESC,
sizeof(SMBIOS_HANDOFF_TABLE_DESC));
put_unaligned_le64(1, >number_of_tables);
- guidcpy(>table_entry[0].guid, _guid);
+ guidcpy(>table_entry[0].guid, _guid);
smbios_copy = (struct smbios_header
*)((uintptr_t)>table_entry[0].table);
memcpy(>table_entry[0].table,
(void *)((uintptr_t)entry->struct_table_address),
- entry->struct_table_length);
+ entry->max_struct_size);
smbios_prepare_measurement(entry, smbios_copy);
@@ -1133,7 +1133,7 @@ static void *find_smbios_table(void)
u32 i;
for (i = 0; i < systab.nr_tables; i++) {
- if (!guidcmp(_guid, [i].guid))
+ if (!guidcmp(_guid, [i].guid))
return systab.tables[i].table;
}
@@ -1360,7 +1360,7 @@ efi_status_t efi_tcg2_measure_efi_app_invocation(struct
efi_loaded_image_obj *ha
u32 pcr_index;
struct udevice *dev;
u32 event = 0;
- struct smbios_entry *entry;
+ struct smbios3_entry *entry;
if (!is_tcg2_protocol_installed())
return EFI_SUCCESS;
@@ -1382,7 +1382,7 @@ efi_status_t efi_tcg2_measure_efi_app_invocation(struct
efi_loaded_image_obj *ha
if (ret != EFI_SUCCESS)
goto out;
- entry = (struct smbios_entry *)find_smbios_table();
+ entry = (struct smbios3_entry *)find_smbios_table();
if (entry) {
ret = tcg2_measure_smbios(dev, entry);
if (ret != EFI_SUCCESS)
diff --git a/lib/efi_selftest/efi_selftest_tcg2.c
b/lib/efi_selftest/efi_selftest_tcg2.c
index 67a886efaa..fb8b997653 100644
--- a/lib/efi_selftest/efi_selftest_tcg2.c
+++ b/lib/efi_selftest/efi_selftest_tcg2.c
@@ -126,41 +126,40 @@ static u8 boot_order[] = {0x02, 0x10, 0x00, 0x10, 0x01,
0x10};
static void *orig_smbios_table;
static u64 dmi_addr = U32_MAX;
-#define SMBIOS_ENTRY_HEADER_SIZE 0x20
+#define SMBIOS3_ENTRY_HEADER_SIZE 0x18
/* smbios table for the measurement test */
-static u8 smbios_table_test[] = {
-0x5f, 0x53, 0x4d, 0x5f, 0x2c, 0x1f,
[PATCH] video: tidss: Use DT property names for parsing nodes
Use device-tree node property names for parsing nodes instead of
indexing as indexing could be different between different SoCs based on
number of DSS entities available on that particular SoC.
Also correct the video layer naming in driver to match to actual one
being used in upstream DSS device-tree node [1].
This also fixes AM62x splash screen usage using the latest upstream DSS
device-tree nodes where hard-coded indexing which driver was using
before this patch was not matching the correct properties in the DT
node.
[1]: Upstream AM62x DSS node:
https://github.com/torvalds/linux/blob/v6.8-rc1/arch/arm64/boot/dts/ti/k3-am62-main.dtsi#L774
Fixes: 5f9f816bb8 ("drivers: video: tidss: TIDSS video driver support
for AM62x")
Signed-off-by: Devarsh Thakkar
---
drivers/video/tidss/tidss_drv.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/video/tidss/tidss_drv.c b/drivers/video/tidss/tidss_drv.c
index e285f255d7..1380c6b693 100644
--- a/drivers/video/tidss/tidss_drv.c
+++ b/drivers/video/tidss/tidss_drv.c
@@ -107,7 +107,7 @@ const struct dss_features dss_am625_feats = {
.num_planes = 2,
/* note: vid is plane_id 0 and vidl1 is plane_id 1 */
- .vid_name = { "vidl1", "vid1" },
+ .vid_name = { "vidl1", "vid" },
.vid_lite = { true, false },
.vid_order = { 1, 0 },
};
@@ -814,13 +814,13 @@ static int tidss_drv_probe(struct udevice *dev)
priv->bus_format = _bus_formats[8];
/* Common address */
- priv->base_common = dev_remap_addr_index(dev, 0);
+ priv->base_common = dev_remap_addr_name(dev, priv->feat->common);
if (!priv->base_common)
return -EINVAL;
/* plane address setup and enable */
for (i = 0; i < priv->feat->num_planes; i++) {
- priv->base_vid[i] = dev_remap_addr_index(dev, i + 2);
+ priv->base_vid[i] = dev_remap_addr_name(dev,
priv->feat->vid_name[i]);
if (!priv->base_vid[i])
return -EINVAL;
}
@@ -841,8 +841,8 @@ static int tidss_drv_probe(struct udevice *dev)
/* video port address clocks and enable */
for (i = 0; i < priv->feat->num_vps; i++) {
- priv->base_ovr[i] = dev_remap_addr_index(dev, i + 4);
- priv->base_vp[i] = dev_remap_addr_index(dev, i + 6);
+ priv->base_ovr[i] = dev_remap_addr_name(dev,
priv->feat->ovr_name[i]);
+ priv->base_vp[i] = dev_remap_addr_name(dev,
priv->feat->vp_name[i]);
}
ret = clk_get_by_name(dev, "vp1", >vp_clk[0]);
--
2.34.1
[PATCH v2] common: splash_source: Don't compile ubifs splash cmd for SPL build
Don't compile ubifs splash mount command for SPL build as this command
is not supported (and also not enabled) during SPL stage.
This fixes below compilation error, when CONFIG_CMD_UBIFS is enabled in
defconfig along with splash screen enabled at SPL stage:
"aarch64-none-linux-gnu-ld.bfd: common/cli.o: in function `run_command':
u-boot-next/u-boot/common/cli.c:51: undefined reference to
`parse_string_outer'
u-boot-next/u-boot/common/cli.c:51:(.text.run_command+0x10): relocation
truncated to fit: R_AARCH64_JUMP26 against undefined symbol
`parse_string_outer' make[2]: ***
[u-boot-next/u-boot/scripts/Makefile.spl:527: spl/u-boot-spl] Error 1
make[1]: *** [u-boot-next/u-boot/Makefile:2053: spl/u-boot-spl] Error 2
make[1]: Leaving directory 'u-boot-next/u-boot/out/a53' make: ***
[Makefile:177: sub-make] Error 2"
Fixes: eb9217dc03 ("common: Enable splash functions at SPL")
Signed-off-by: Devarsh Thakkar
---
V2: Drop repeat sentence in commit msg
common/splash_source.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/common/splash_source.c b/common/splash_source.c
index 7223a1aae7..2ce0768833 100644
--- a/common/splash_source.c
+++ b/common/splash_source.c
@@ -216,7 +216,7 @@ static int splash_init_virtio(void)
}
}
-#ifdef CONFIG_CMD_UBIFS
+#if defined(CONFIG_CMD_UBIFS) && !defined(CONFIG_SPL_BUILD)
static int splash_mount_ubifs(struct splash_location *location)
{
int res;
--
2.34.1
Re: [PATCH v4 00/11] An effort to bring DT bindings compliance within U-Boot
Hi Rob, Andre, On Tue, 23 Jan 2024 at 22:12, Rob Herring wrote: > > On Mon, Jan 22, 2024 at 6:59 PM Andre Przywara wrote: > > > > On Mon, 22 Jan 2024 11:49:59 -0500 > > Tom Rini wrote: > > > > Hi Tom, > > > > > On Mon, Jan 22, 2024 at 11:45:15AM +, Andre Przywara wrote: > > > > On Wed, 10 Jan 2024 16:05:36 +0530 > > > > Sumit Garg wrote: > > > > > > > > Hi, > > > > > > > > I certainly welcome this more automatic synchronisation of the DTs, > > > > however have one comment about the upcoming sync process: > > > > > > > > > ... > > > > > However, Linux kernel DT maintainers proposed [2] for U-Boot to rather > > > > > use devicetree-rebasing repo [3] which is a forked copy from Linux > > > > > kernel for DT source files as well as bindings. It is tagged at every > > > > > Linux kernel major release or intermideate release candidates. So > > > > > here I > > > > > have tried to reuse that to bring DT bingings compliance as well as a > > > > > standard way to maintain a regular sync of DT source files with Linux > > > > > kernel. > > > > > > > > > > In order to maintain devicetree files sync, U-Boot will maintains a > > > > > Git > > > > > subtree for devicetee-rebasing repo as `dts/upstream` sub-directory. > > > > > U-Boot will regularly sync `dts/upstream/` subtree whenever the next > > > > > window > > > > > opens with the next available kernel major release. > > > > > > > > I hope this doesn't need to stay that restricted? Can we either sync > > > > more > > > > often, or at least on the kernel's -rc1, and not only on a "full" > > > > release? > > > > > > > > The reason I ask is that we have a chicken-egg problem here: without a > > > > DT > > > > merged into the kernel tree, no U-Boot board support can be merged. And > > > > without U-Boot support, we cannot boot a kernel, at least not in the > > > > canonical way. > > > > > > > > Since the U-Boot and kernel merge windows are not in phase, for sunxi I > > > > try > > > > to sync the kernel DTs either as early as possible (-rc1, sometimes even > > > > before, when the maintainers have merged them into their tree), or > > > > sometimes "out of season", if a board defconfig patch is coming up. > > > > > > > > Otherwise new board support, which typically has a very low regression > > > > risk > > > > for the rest of the code base, would need to be delayed until the next > > > > release. In the worst case the U-Boot merge windows opens one week > > > > before > > > > a kernel release, then new boards need to wait three months? > > > > > > Would it be to bad to bring in board X with OF_UPSTREAM=n for one U-Boot > > > release, and then with the next one switch to OF_UPSTREAM=y (and delete > > > the dts from arch/) for the next release, when we would have gotten back > > > in sync? > > > > Ah, I didn't look into the actual patches, but if this provision is > > there, that sounds surely acceptable. It might still be good to sync > > earlier than the .0 kernel release: if it appears in Linus' tree, it > > had already seen a good share of review and testing. And with the > > U-Boot releases being always further away than the next kernel release, > > we could pull fixes still in time. So we could pick the latest -rc (or > > .0 release, whichever is more recent) when the U-Boot merge window > > opens? > > That should be mostly fine IMO, but there are the occasional "oops, > let's change/fix the binding before it's released". > > Couldn't you pull in the latest rc in the merge window, but only if > the .0 release will happen before the next u-boot release. And then > update from rc to .0 before the u-boot release. > > Also, from a quick look at the dts changes during rc releases, they > tend to come in the later rc releases. Probably that's just the > latency of going to sub-arch maintainer->SoC->Linus. > I agree with your intent to keep U-Boot updated with the latest Linux DT .0 releases. However, we would like to provide sufficient time (a full U-Boot release cycle) for U-Boot developers/maintainers to adapt, detect and fix problems for their platforms wrt. to a new Linux DT .0 release. We can always revisit the syncing strategy to be more aggressive if everything pans out as per plan. -Sumit > Rob
[PATCH] common: splash_source: Don't compile ubifs splash cmd for SPL build
Don't compile ubifs splash mount command for SPL build as this command
is not supported (and also not enabled) during SPL stage.
This fixes below compilation error, when CONFIG_CMD_UBIFS is enabled in
defconfig along with splash screen enabled at SPL stage.
Fixes below error when CONFIG_CMD_UBIFS is enabled in defconfig along
with splash screen at SPL stage:
"aarch64-none-linux-gnu-ld.bfd: common/cli.o: in function `run_command':
u-boot-next/u-boot/common/cli.c:51: undefined reference to
`parse_string_outer'
u-boot-next/u-boot/common/cli.c:51:(.text.run_command+0x10): relocation
truncated to fit: R_AARCH64_JUMP26 against undefined symbol
`parse_string_outer' make[2]: ***
[u-boot-next/u-boot/scripts/Makefile.spl:527: spl/u-boot-spl] Error 1
make[1]: *** [u-boot-next/u-boot/Makefile:2053: spl/u-boot-spl] Error 2
make[1]: Leaving directory 'u-boot-next/u-boot/out/a53' make: ***
[Makefile:177: sub-make] Error 2"
Fixes: eb9217dc03 ("common: Enable splash functions at SPL")
Signed-off-by: Devarsh Thakkar
---
common/splash_source.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/common/splash_source.c b/common/splash_source.c
index 7223a1aae7..2ce0768833 100644
--- a/common/splash_source.c
+++ b/common/splash_source.c
@@ -216,7 +216,7 @@ static int splash_init_virtio(void)
}
}
-#ifdef CONFIG_CMD_UBIFS
+#if defined(CONFIG_CMD_UBIFS) && !defined(CONFIG_SPL_BUILD)
static int splash_mount_ubifs(struct splash_location *location)
{
int res;
--
2.34.1
Re: [PATCH V4 2/2] configs: andes: add watchdog support fot andes ae350
Hi Randolph, On 1/24/24 07:21, Randolph wrote: It adds the ATCWDT200 support for Andes AE350 platform. It also enables wdt command support. Signed-off-by: CL Wang Signed-off-by: Randolph Reviewed-by: Leo Yu-Chi Liang This fails in world CI build in "test.py for sandbox": https://dev.azure.com/sr0718/0cded7c3-6e6a-4b57-8d0f-65c99496c42f/_apis/build/builds/338/logs/181 Not sure how this is related. Could you please take a look? Thanks, Stefan --- configs/ae350_rv32_defconfig | 4 configs/ae350_rv32_spl_defconfig | 4 configs/ae350_rv32_spl_xip_defconfig | 4 configs/ae350_rv32_xip_defconfig | 4 configs/ae350_rv64_defconfig | 4 configs/ae350_rv64_spl_defconfig | 4 configs/ae350_rv64_spl_xip_defconfig | 4 configs/ae350_rv64_xip_defconfig | 4 8 files changed, 32 insertions(+) diff --git a/configs/ae350_rv32_defconfig b/configs/ae350_rv32_defconfig index 3bfa3e9f8e..35ad62c845 100644 --- a/configs/ae350_rv32_defconfig +++ b/configs/ae350_rv32_defconfig @@ -23,6 +23,7 @@ CONFIG_SYS_PROMPT="RISC-V # " CONFIG_CMD_IMLS=y CONFIG_CMD_MMC=y CONFIG_CMD_SF_TEST=y +CONFIG_CMD_WDT=y # CONFIG_CMD_SETEXPR is not set CONFIG_BOOTP_PREFER_SERVERIP=y CONFIG_CMD_CACHE=y @@ -49,3 +50,6 @@ CONFIG_BAUDRATE=38400 CONFIG_SYS_NS16550=y CONFIG_SPI=y CONFIG_ATCSPI200_SPI=y +# CONFIG_WATCHDOG_AUTOSTART is not set +CONFIG_WDT=y +CONFIG_WDT_ATCWDT200=y diff --git a/configs/ae350_rv32_spl_defconfig b/configs/ae350_rv32_spl_defconfig index aeb50206d2..41cd457bc3 100644 --- a/configs/ae350_rv32_spl_defconfig +++ b/configs/ae350_rv32_spl_defconfig @@ -33,6 +33,7 @@ CONFIG_SYS_PROMPT="RISC-V # " CONFIG_CMD_IMLS=y CONFIG_CMD_MMC=y CONFIG_CMD_SF_TEST=y +CONFIG_CMD_WDT=y # CONFIG_CMD_SETEXPR is not set CONFIG_BOOTP_PREFER_SERVERIP=y CONFIG_CMD_CACHE=y @@ -58,3 +59,6 @@ CONFIG_SYS_NS16550=y CONFIG_SPI=y CONFIG_ATCSPI200_SPI=y # CONFIG_BINMAN_FDT is not set +# CONFIG_WATCHDOG_AUTOSTART is not set +CONFIG_WDT=y +CONFIG_WDT_ATCWDT200=y diff --git a/configs/ae350_rv32_spl_xip_defconfig b/configs/ae350_rv32_spl_xip_defconfig index f15ec301ce..954e2f2de7 100644 --- a/configs/ae350_rv32_spl_xip_defconfig +++ b/configs/ae350_rv32_spl_xip_defconfig @@ -34,6 +34,7 @@ CONFIG_SYS_PROMPT="RISC-V # " CONFIG_CMD_IMLS=y CONFIG_CMD_MMC=y CONFIG_CMD_SF_TEST=y +CONFIG_CMD_WDT=y # CONFIG_CMD_SETEXPR is not set CONFIG_BOOTP_PREFER_SERVERIP=y CONFIG_CMD_CACHE=y @@ -59,3 +60,6 @@ CONFIG_SYS_NS16550=y CONFIG_SPI=y CONFIG_ATCSPI200_SPI=y # CONFIG_BINMAN_FDT is not set +# CONFIG_WATCHDOG_AUTOSTART is not set +CONFIG_WDT=y +CONFIG_WDT_ATCWDT200=y diff --git a/configs/ae350_rv32_xip_defconfig b/configs/ae350_rv32_xip_defconfig index c40eb043c5..95863595d2 100644 --- a/configs/ae350_rv32_xip_defconfig +++ b/configs/ae350_rv32_xip_defconfig @@ -24,6 +24,7 @@ CONFIG_SYS_PROMPT="RISC-V # " CONFIG_CMD_IMLS=y CONFIG_CMD_MMC=y CONFIG_CMD_SF_TEST=y +CONFIG_CMD_WDT=y # CONFIG_CMD_SETEXPR is not set CONFIG_BOOTP_PREFER_SERVERIP=y CONFIG_CMD_CACHE=y @@ -50,3 +51,6 @@ CONFIG_BAUDRATE=38400 CONFIG_SYS_NS16550=y CONFIG_SPI=y CONFIG_ATCSPI200_SPI=y +# CONFIG_WATCHDOG_AUTOSTART is not set +CONFIG_WDT=y +CONFIG_WDT_ATCWDT200=y diff --git a/configs/ae350_rv64_defconfig b/configs/ae350_rv64_defconfig index 7ae938aeb2..988214285a 100644 --- a/configs/ae350_rv64_defconfig +++ b/configs/ae350_rv64_defconfig @@ -23,6 +23,7 @@ CONFIG_SYS_PROMPT="RISC-V # " CONFIG_CMD_IMLS=y CONFIG_CMD_MMC=y CONFIG_CMD_SF_TEST=y +CONFIG_CMD_WDT=y # CONFIG_CMD_SETEXPR is not set CONFIG_BOOTP_PREFER_SERVERIP=y CONFIG_CMD_CACHE=y @@ -49,3 +50,6 @@ CONFIG_BAUDRATE=38400 CONFIG_SYS_NS16550=y CONFIG_SPI=y CONFIG_ATCSPI200_SPI=y +# CONFIG_WATCHDOG_AUTOSTART is not set +CONFIG_WDT=y +CONFIG_WDT_ATCWDT200=y diff --git a/configs/ae350_rv64_spl_defconfig b/configs/ae350_rv64_spl_defconfig index 68ac4325ab..e929320433 100644 --- a/configs/ae350_rv64_spl_defconfig +++ b/configs/ae350_rv64_spl_defconfig @@ -33,6 +33,7 @@ CONFIG_SYS_PROMPT="RISC-V # " CONFIG_CMD_IMLS=y CONFIG_CMD_MMC=y CONFIG_CMD_SF_TEST=y +CONFIG_CMD_WDT=y # CONFIG_CMD_SETEXPR is not set CONFIG_BOOTP_PREFER_SERVERIP=y CONFIG_CMD_CACHE=y @@ -58,3 +59,6 @@ CONFIG_SYS_NS16550=y CONFIG_SPI=y CONFIG_ATCSPI200_SPI=y # CONFIG_BINMAN_FDT is not set +# CONFIG_WATCHDOG_AUTOSTART is not set +CONFIG_WDT=y +CONFIG_WDT_ATCWDT200=y diff --git a/configs/ae350_rv64_spl_xip_defconfig b/configs/ae350_rv64_spl_xip_defconfig index 839ca335d4..3f92643b07 100644 --- a/configs/ae350_rv64_spl_xip_defconfig +++ b/configs/ae350_rv64_spl_xip_defconfig @@ -34,6 +34,7 @@ CONFIG_SYS_PROMPT="RISC-V # " CONFIG_CMD_IMLS=y CONFIG_CMD_MMC=y CONFIG_CMD_SF_TEST=y +CONFIG_CMD_WDT=y # CONFIG_CMD_SETEXPR is not set CONFIG_BOOTP_PREFER_SERVERIP=y CONFIG_CMD_CACHE=y @@ -59,3 +60,6 @@ CONFIG_SYS_NS16550=y CONFIG_SPI=y CONFIG_ATCSPI200_SPI=y # CONFIG_BINMAN_FDT is not set +#
Re: [PATCH v4 00/11] An effort to bring DT bindings compliance within U-Boot
Hi Marek, On Mon, 22 Jan 2024 at 05:47, Marek Vasut wrote: > > On 1/21/24 23:41, Caleb Connolly wrote: > > Hi, > > [...] > > >> How do you propose to handle fixes to DTs which are applied to > >> linux-stable releases ? For example, if Linux 6.6(.0) ships a DT which > >> has some defect that is fixed in 6.6.1, how will that fix get into > >> U-Boot DTs ? > > > > This fix would also be in the latest Linux tags, so I think it would > > find its way here - as I understand it patches aren't accepted into > > Linux stable unless they land in torvalds tree. > > See the devicetree-rebasing.git: > > https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git/refs/ > > That only contains refs for release versions (v6.6-dts, v6.7-dts etc), > not any follow-up updates from linux-stable (like current 6.6.13 etc). > Here we should only consider fixes which are critical to U-Boot. I think -u-boot.dtsi files would be suitable to carry those fixes until next uprev. However, if there is a fix affecting many platforms than we can consider pulling that standalone too. > Would this require syncing in -rc versions of Linux DTs to get the > latest fixes in ? Syncing -rc versions makes U-Boot more prone to DT ABI breakages. So its a chicken and egg problem as per your comments below. However, we can revisit our syncing strategy based on how the current one pans out. > > >> Assume that there is some large breaking change in Linux 6.(n+1), > >> something which would be problematic for specific U-Boot platform > >> (e.g. i.MX) or would require a lot of work to sort out, will there be > >> a way to temporarily pin DTs for specific platform to older DT version > >> until that is resolved (e.g. pin to 6.n) ? > > > > (Upstream) devicetree has to be forwards and backwards compatible, were > > such a breaking change to get merged without prior discussion with DT > > users (i.e. U-Boot) then I think the correct course of action would be > > to revert it. > > Not really, this could be a perfectly valid change, and would work for > Linux just fine, it might simply be pulling in something which is not > supported by U-Boot just yet and therefore syncing the DTs into U-Boot > would break U-Boot on that platform . Using older version of DTs for a > platform could work as a stopgap measure until the functionality is > implemented. Is this possible ? For this particular reason we want to pull once during beginning on U-Boot next window and allow sufficient time for platform maintainers to adapt to it. However, OF_UPSTREAM=n can be an alternative for a stopgap solution. > > > On a tangential note: as I understand it, DTs built from dt-rebasing are > > still subject to U-Boot customisations via the "-u-boot.dtsi" include > > files, this allows for dealing with incompatibilities due to missing > > features in U-Boot. > > Would it be possible to auto-update those -u-boot.dtsi files during > sync, to minimize the resulting DT blob delta before/after update, and > thus also minimize the likelihood of causing breakage ? In the long run the DT community would like to avoid any DT ABI breakages at all. Rob is already working on a DT ABI check tool and seeking inputs for what could be an ABI break [1] from U-Boot perspective too. Feel free to provide your inputs. Along with that we wouldn't need -u-boot.dtsi files once we make U-Boot fully compliant with DT bindings. Until that point U-Boot platform maintainers have to keep their -u-boot.dtsi files updated corresponding to latest DT rebasing releases. [1] https://lore.kernel.org/all/cal_jsqlo4nxrj93ddsfp3uyls08v02amnbccnsdj0mbbomc...@mail.gmail.com/ -Sumit
