Re: [PATCH] arm64: xilinx: Move address/size-cells to proper locations
On 11/01/2024 08:09, Michal Simek wrote:
>
>
> On 1/10/24 22:27, Krzysztof Kozlowski wrote:
>> On 10/01/2024 14:35, Michal Simek wrote:
>>> Move cells to board dtsi files from generic zynqmp.dtsi. Changes are
>>> related to qspi, spi, nand, i2c and ethernet nodes.
>>>
>>> All errors are generated when dtbs are compiled with W=1.
>>>
>>
>> I don't see any errors on some other platforms, like Samsung. Isn't the
>> actual problem that you do not disable the nodes (I2C, SPI etc) in DTSI?
>
> On i2c node. Bus is present on the board but it can end in a connector or
> device
> which we don't have OS/bootloader drivers for. But we have drivers using i2c
> tools or u-boot i2c probe. It means that transition should happen.
> On i2c interesting is that W=1 is not able to report issues when you have i2c
> mux described like this
>
> i2c@0 {
> #address-cells = <1>;
> #size-cells = <0>;
> reg = <0>;
> /* HPC0_IIC */
I understand and it is quite common, but it does not explain the case.
Your bus should still be disabled in DTSI and enabled in DTS for these
cases.
And how exactly do you solve the warning for above case?
> };
>
> and it doesn't report that cells shouldn't be there.
>
> SPI is pretty much the same story with using spidev.
>
> Ethernet with mdio. I have converted all phy description to use mdio node
> because it provides ability to have separate reset for the whole mdio bus and
> then every phy can also have own reset itself that's why using this type of
> description is better from flexibility point of view.
>
> qspi/nand - we have driver for that devices all the time but it doesn't make
> sense to have some nodes follow some rules and others not.
Best regards,
Krzysztof
Re: [PATCH 1/1] cmd: mtd: avoid unintentional integer overflow
Hi Heinrich, heinrich.schucha...@canonical.com wrote on Thu, 11 Jan 2024 08:31:55 +0100: > mtd dump beyond 4 GiB will show incorrect results. > > Multiplying two u32 will yield a u32. Add a missing cast. Good point, thanks for the fix. Reviewed-by: Miquel Raynal Thanks, Miquèl
Re: [PATCH] usb: dwc3: Integrate usb5744 & usb2244 driver support
First of all I think this should be more RFC.
On 1/11/24 08:10, Venkatesh Yadav Abbarapu wrote:
Usb5744 & usb2244 are Microchip based usbhub and usb-2.0 based SD
controller devices. Integrate these devices into dwc3 driver to bind and
probe the respective drivers to get detected by usb controller.
Signed-off-by: T Karthik Reddy
Signed-off-by: Venkatesh Yadav Abbarapu
---
drivers/usb/dwc3/dwc3-generic.c | 67 -
1 file changed, 49 insertions(+), 18 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-generic.c b/drivers/usb/dwc3/dwc3-generic.c
index 6fb2de8a5a..a2eb2c8e24 100644
--- a/drivers/usb/dwc3/dwc3-generic.c
+++ b/drivers/usb/dwc3/dwc3-generic.c
@@ -430,29 +430,49 @@ static int dwc3_glue_bind_common(struct udevice *parent,
ofnode node)
debug("%s: subnode name: %s\n", __func__, name);
+ if (!ofnode_device_is_compatible(node, "snps,dwc3")) {
+ if (ofnode_device_is_compatible(node,
+ "microchip,usb5744"))
+ driver = "usb5744";
+ else if (ofnode_device_is_compatible
+ (node, "microchip,usb2244"))
+ driver = "usb2244";
+
+ ret = device_bind_driver_to_node(parent, driver, name,
+node, );
+ if (ret) {
+ printf("Failed to bind: %s, err: %d\n",
+ driver, ret);
+ return ret;
+ }
+ }
I don't think this is going to be accepted by Marek to have device specific code
in generic code.
I did some grepping and I see that there is new CONFIG_USB_ONBOARD_HUB entry.
Don't understand why it is in common folder if this is pretty much device
specific. But there is a new UCLASS_USB_HUB class.
Venkatesh: it should be investigated more how it works.
Marek: IIRC you mentioned any support for companion/peer hubs.
How do you think it should be integrated to u-boot?
Thanks,
Michal
[PATCH 1/1] cmd: mtd: avoid unintentional integer overflow
mtd dump beyond 4 GiB will show incorrect results.
Multiplying two u32 will yield a u32. Add a missing cast.
Fixes: 5db66b3aee6f ("cmd: mtd: add 'mtd' command")
Addresses-Coverity-ID: 477205 ("Unintentional integer overflow")
Signed-off-by: Heinrich Schuchardt
---
cmd/mtd.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/cmd/mtd.c b/cmd/mtd.c
index e63c011e79..9083a6840a 100644
--- a/cmd/mtd.c
+++ b/cmd/mtd.c
@@ -77,7 +77,7 @@ static void mtd_dump_device_buf(struct mtd_info *mtd, u64
start_off,
if (has_pages) {
for (page = 0; page < npages; page++) {
- u64 data_off = page * mtd->writesize;
+ u64 data_off = (u64)page * mtd->writesize;
printf("\nDump %d data bytes from 0x%08llx:\n",
mtd->writesize, start_off + data_off);
@@ -85,7 +85,7 @@ static void mtd_dump_device_buf(struct mtd_info *mtd, u64
start_off,
mtd->writesize, start_off + data_off);
if (woob) {
- u64 oob_off = page * mtd->oobsize;
+ u64 oob_off = (u64)page * mtd->oobsize;
printf("Dump %d OOB bytes from page at
0x%08llx:\n",
mtd->oobsize, start_off + data_off);
--
2.43.0
Re: [PATCH 1/1] smbios: buffer overflow when zeroing entry point
On Thu, 11 Jan 2024 at 08:34, Heinrich Schuchardt
wrote:
>
> A SMBIOS 3 entry point has a different length than an SMBIOS 2.1 entry
> point.
>
> Fixes: 70924294f375 ("smbios: Use SMBIOS 3.0 to support an address above 4GB")
> Fixes: 1c5f6fa3883d ("smbios: Drop support for SMBIOS2 tables")
> Addresses-Coverity-ID: 477212 ("Wrong sizeof argument")
> Signed-off-by: Heinrich Schuchardt
> ---
> lib/smbios.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/lib/smbios.c b/lib/smbios.c
> index 41aa936c4c..25595f55ab 100644
> --- a/lib/smbios.c
> +++ b/lib/smbios.c
> @@ -591,8 +591,8 @@ ulong write_smbios_table(ulong addr)
> table_addr = (ulong)map_sysmem(tables, 0);
>
> /* now go back and write the SMBIOS3 header */
> - se = map_sysmem(start_addr, sizeof(struct smbios_entry));
> - memset(se, '\0', sizeof(struct smbios_entry));
> + se = map_sysmem(start_addr, sizeof(struct smbios3_entry));
> + memset(se, '\0', sizeof(struct smbios3_entry));
> memcpy(se->anchor, "_SM3_", 5);
> se->length = sizeof(struct smbios3_entry);
> se->major_ver = SMBIOS_MAJOR_VER;
> --
> 2.43.0
>
Reviewed-by: Ilias Apalodimas
[PATCH] usb: dwc3: Integrate usb5744 & usb2244 driver support
Usb5744 & usb2244 are Microchip based usbhub and usb-2.0 based SD
controller devices. Integrate these devices into dwc3 driver to bind and
probe the respective drivers to get detected by usb controller.
Signed-off-by: T Karthik Reddy
Signed-off-by: Venkatesh Yadav Abbarapu
---
drivers/usb/dwc3/dwc3-generic.c | 67 -
1 file changed, 49 insertions(+), 18 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-generic.c b/drivers/usb/dwc3/dwc3-generic.c
index 6fb2de8a5a..a2eb2c8e24 100644
--- a/drivers/usb/dwc3/dwc3-generic.c
+++ b/drivers/usb/dwc3/dwc3-generic.c
@@ -430,29 +430,49 @@ static int dwc3_glue_bind_common(struct udevice *parent,
ofnode node)
debug("%s: subnode name: %s\n", __func__, name);
+ if (!ofnode_device_is_compatible(node, "snps,dwc3")) {
+ if (ofnode_device_is_compatible(node,
+ "microchip,usb5744"))
+ driver = "usb5744";
+ else if (ofnode_device_is_compatible
+ (node, "microchip,usb2244"))
+ driver = "usb2244";
+
+ ret = device_bind_driver_to_node(parent, driver, name,
+node, );
+ if (ret) {
+ printf("Failed to bind: %s, err: %d\n",
+ driver, ret);
+ return ret;
+ }
+ }
+
/* if the parent node doesn't have a mode check the leaf */
dr_mode = usb_get_dr_mode(dev_ofnode(parent));
if (!dr_mode)
dr_mode = usb_get_dr_mode(node);
- if (CONFIG_IS_ENABLED(DM_USB_GADGET) &&
- (dr_mode == USB_DR_MODE_PERIPHERAL || dr_mode == USB_DR_MODE_OTG)) {
- debug("%s: dr_mode: OTG or Peripheral\n", __func__);
- driver = "dwc3-generic-peripheral";
- } else if (CONFIG_IS_ENABLED(USB_HOST) && dr_mode == USB_DR_MODE_HOST) {
- debug("%s: dr_mode: HOST\n", __func__);
- driver = "dwc3-generic-host";
- } else {
- debug("%s: unsupported dr_mode %d\n", __func__, dr_mode);
- return -ENODEV;
- }
+ if (ofnode_device_is_compatible(node, "snps,dwc3")) {
+ if (CONFIG_IS_ENABLED(DM_USB_GADGET) &&
+ (dr_mode == USB_DR_MODE_PERIPHERAL || dr_mode ==
USB_DR_MODE_OTG)) {
+ debug("%s: dr_mode: OTG or Peripheral\n", __func__);
+ driver = "dwc3-generic-peripheral";
+ } else if (CONFIG_IS_ENABLED(USB_HOST) && dr_mode ==
USB_DR_MODE_HOST) {
+ debug("%s: dr_mode: HOST\n", __func__);
+ driver = "dwc3-generic-host";
+ } else {
+ debug("%s: unsupported dr_mode %d\n", __func__,
dr_mode);
+ return -ENODEV;
+ }
- ret = device_bind_driver_to_node(parent, driver, name,
-node, );
- if (ret) {
- debug("%s: not able to bind usb device mode\n",
- __func__);
- return ret;
+ ret = device_bind_driver_to_node(parent, driver, name,
+node, );
+
+ if (ret) {
+ debug("%s: not able to bind usb device mode\n",
+ __func__);
+ return ret;
+ }
}
return 0;
@@ -479,7 +499,6 @@ int dwc3_glue_bind(struct udevice *parent)
if (ret)
return ret;
}
-
return 0;
}
@@ -530,6 +549,7 @@ int dwc3_glue_probe(struct udevice *dev)
struct dwc3_glue_ops *ops = (struct dwc3_glue_ops
*)dev_get_driver_data(dev);
struct dwc3_glue_data *glue = dev_get_plat(dev);
struct udevice *child = NULL;
+ ofnode node;
int index = 0;
int ret;
struct phy phy;
@@ -560,6 +580,17 @@ int dwc3_glue_probe(struct udevice *dev)
return ret;
}
+ ofnode_for_each_subnode(node, dev_ofnode(dev)) {
+ if (!ofnode_device_is_compatible(node, "snps,dwc3")) {
+ ret = uclass_get_device_by_ofnode(UCLASS_MISC, node,
);
+ if (ret) {
+ printf("could not get device %s, err = %d\n",
+ node.np->name, ret);
+ return ret;
+ }
+ }
+ }
+
device_find_first_child(dev, );
if (!child)
return 0;
--
2.25.1
Re: [PATCH] arm64: xilinx: Move address/size-cells to proper locations
On 1/10/24 22:27, Krzysztof Kozlowski wrote:
On 10/01/2024 14:35, Michal Simek wrote:
Move cells to board dtsi files from generic zynqmp.dtsi. Changes are
related to qspi, spi, nand, i2c and ethernet nodes.
All errors are generated when dtbs are compiled with W=1.
I don't see any errors on some other platforms, like Samsung. Isn't the
actual problem that you do not disable the nodes (I2C, SPI etc) in DTSI?
On i2c node. Bus is present on the board but it can end in a connector or device
which we don't have OS/bootloader drivers for. But we have drivers using i2c
tools or u-boot i2c probe. It means that transition should happen.
On i2c interesting is that W=1 is not able to report issues when you have i2c
mux described like this
i2c@0 {
#address-cells = <1>;
#size-cells = <0>;
reg = <0>;
/* HPC0_IIC */
};
and it doesn't report that cells shouldn't be there.
SPI is pretty much the same story with using spidev.
Ethernet with mdio. I have converted all phy description to use mdio node
because it provides ability to have separate reset for the whole mdio bus and
then every phy can also have own reset itself that's why using this type of
description is better from flexibility point of view.
qspi/nand - we have driver for that devices all the time but it doesn't make
sense to have some nodes follow some rules and others not.
Thanks,
Michal
[PATCH 1/1] smbios: buffer overflow when zeroing entry point
A SMBIOS 3 entry point has a different length than an SMBIOS 2.1 entry
point.
Fixes: 70924294f375 ("smbios: Use SMBIOS 3.0 to support an address above 4GB")
Fixes: 1c5f6fa3883d ("smbios: Drop support for SMBIOS2 tables")
Addresses-Coverity-ID: 477212 ("Wrong sizeof argument")
Signed-off-by: Heinrich Schuchardt
---
lib/smbios.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/smbios.c b/lib/smbios.c
index 41aa936c4c..25595f55ab 100644
--- a/lib/smbios.c
+++ b/lib/smbios.c
@@ -591,8 +591,8 @@ ulong write_smbios_table(ulong addr)
table_addr = (ulong)map_sysmem(tables, 0);
/* now go back and write the SMBIOS3 header */
- se = map_sysmem(start_addr, sizeof(struct smbios_entry));
- memset(se, '\0', sizeof(struct smbios_entry));
+ se = map_sysmem(start_addr, sizeof(struct smbios3_entry));
+ memset(se, '\0', sizeof(struct smbios3_entry));
memcpy(se->anchor, "_SM3_", 5);
se->length = sizeof(struct smbios3_entry);
se->major_ver = SMBIOS_MAJOR_VER;
--
2.43.0
[PATCH] test/py: reset: Add a test for reset command
Add a test for reset commands which performs resetting of CPU, It does
COLD reset by default and WARM reset with -w option.
Signed-off-by: Love Kumar
---
test/py/tests/test_reset.py | 50 +
1 file changed, 50 insertions(+)
create mode 100644 test/py/tests/test_reset.py
diff --git a/test/py/tests/test_reset.py b/test/py/tests/test_reset.py
new file mode 100644
index ..896918cd8baf
--- /dev/null
+++ b/test/py/tests/test_reset.py
@@ -0,0 +1,50 @@
+# SPDX-License-Identifier: GPL-2.0
+# (C) Copyright 2023, Advanced Micro Devices, Inc.
+
+"""
+Note: This test doesn't rely on boardenv_* configuration value but they can
+change test behavior.
+
+# Setup env__reset_test_skip to True if reset test is not possible or desired
+# and should be skipped.
+env__reset_test_skip = True
+
+# This test will be also skipped if the bootmode is detected to JTAG.
+"""
+
+import pytest
+import re
+import test_000_version
+
+def setup_reset_env(u_boot_console):
+if u_boot_console.config.env.get('env__reset_test_skip', False):
+pytest.skip('reset test is not enabled')
+
+output = u_boot_console.run_command('print modeboot')
+m = re.search('modeboot=(.+?)boot', output)
+if not m:
+pytest.skip('bootmode cannnot be determined')
+
+bootmode = m.group(1)
+if bootmode == 'jtag':
+pytest.skip('skipping reset test due to jtag bootmode')
+
+def test_reset(u_boot_console):
+"""Test the reset command in non-JTAG bootmode.
+It does COLD reset, which resets CPU, DDR and peripherals
+"""
+setup_reset_env(u_boot_console)
+u_boot_console.run_command('reset', wait_for_reboot=True)
+
+# Checks the u-boot command prompt's functionality after reset
+test_000_version.test_version(u_boot_console)
+
+def test_reset_w(u_boot_console):
+"""Test the reset -w command in non-JTAG bootmode.
+It does WARM reset, which resets CPU but keep DDR/peripherals active.
+"""
+setup_reset_env(u_boot_console)
+u_boot_console.run_command('reset -w', wait_for_reboot=True)
+
+# Checks the u-boot command prompt's functionality after reset
+test_000_version.test_version(u_boot_console)
--
2.25.1
[PATCH v3 2/2] efi_loader: support fmp versioning for multi bank update
This commit stores the firmware version into the array
of fmp_state structure to support the fmp versioning
for multi bank update. The index of the array is identified
by the bank index.
This modification keeps the backward compatibility with
the existing versioning feature.
Signed-off-by: Masahisa Kojima
---
lib/efi_loader/efi_firmware.c | 75 ---
1 file changed, 60 insertions(+), 15 deletions(-)
diff --git a/lib/efi_loader/efi_firmware.c b/lib/efi_loader/efi_firmware.c
index e558336bc1..9fd13297a6 100644
--- a/lib/efi_loader/efi_firmware.c
+++ b/lib/efi_loader/efi_firmware.c
@@ -206,18 +206,10 @@ void efi_firmware_fill_version_info(struct
efi_firmware_image_descriptor *image_
{
u16 varname[13]; /* u"FmpState" */
efi_status_t ret;
- efi_uintn_t size;
- struct fmp_state var_state = { 0 };
-
- efi_create_indexed_name(varname, sizeof(varname), "FmpState",
- fw_array->image_index);
- size = sizeof(var_state);
- ret = efi_get_variable_int(varname, _array->image_type_id,
- NULL, , _state, NULL);
- if (ret == EFI_SUCCESS)
- image_info->version = var_state.fw_version;
- else
- image_info->version = 0;
+ efi_uintn_t size, expected_size;
+ uint num_banks = 1;
+ uint active_index = 0;
+ struct fmp_state *var_state;
efi_firmware_get_lsv_from_dtb(fw_array->image_index,
_array->image_type_id,
@@ -226,6 +218,31 @@ void efi_firmware_fill_version_info(struct
efi_firmware_image_descriptor *image_
image_info->version_name = NULL; /* not supported */
image_info->last_attempt_version = 0;
image_info->last_attempt_status = LAST_ATTEMPT_STATUS_SUCCESS;
+ image_info->version = 0;
+
+ /* get the fw_version */
+ efi_create_indexed_name(varname, sizeof(varname), "FmpState",
+ fw_array->image_index);
+ if (IS_ENABLED(CONFIG_FWU_MULTI_BANK_UPDATE)) {
+ ret = fwu_get_active_index(_index);
+ if (ret)
+ return;
+
+ num_banks = CONFIG_FWU_NUM_BANKS;
+ }
+
+ size = num_banks * sizeof(*var_state);
+ expected_size = size;
+ var_state = calloc(1, size);
+ if (!var_state)
+ return;
+
+ ret = efi_get_variable_int(varname, _array->image_type_id,
+ NULL, , var_state, NULL);
+ if (ret == EFI_SUCCESS && expected_size == size)
+ image_info->version = var_state[active_index].fw_version;
+
+ free(var_state);
}
/**
@@ -361,8 +378,11 @@ efi_status_t efi_firmware_set_fmp_state_var(struct
fmp_state *state, u8 image_in
{
u16 varname[13]; /* u"FmpState" */
efi_status_t ret;
+ uint num_banks = 1;
+ uint update_bank = 0;
+ efi_uintn_t size;
efi_guid_t *image_type_id;
- struct fmp_state var_state = { 0 };
+ struct fmp_state *var_state;
image_type_id = efi_firmware_get_image_type_id(image_index);
if (!image_type_id)
@@ -371,19 +391,44 @@ efi_status_t efi_firmware_set_fmp_state_var(struct
fmp_state *state, u8 image_in
efi_create_indexed_name(varname, sizeof(varname), "FmpState",
image_index);
+ if (IS_ENABLED(CONFIG_FWU_MULTI_BANK_UPDATE)) {
+ ret = fwu_plat_get_update_index(_bank);
+ if (ret)
+ return EFI_INVALID_PARAMETER;
+
+ num_banks = CONFIG_FWU_NUM_BANKS;
+ }
+
+ size = num_banks * sizeof(*var_state);
+ var_state = calloc(1, size);
+ if (!var_state)
+ return EFI_OUT_OF_RESOURCES;
+
+ /*
+* GetVariable may fail, EFI_NOT_FOUND is returned if FmpState
+* variable has not been set yet.
+* Ignore the error here since the correct FmpState variable
+* is set later.
+*/
+ efi_get_variable_int(varname, image_type_id, NULL, , var_state,
+NULL);
+
/*
* Only the fw_version is set here.
* lowest_supported_version in FmpState variable is ignored since
* it can be tampered if the file based EFI variable storage is used.
*/
- var_state.fw_version = state->fw_version;
+ var_state[update_bank].fw_version = state->fw_version;
+ size = num_banks * sizeof(*var_state);
ret = efi_set_variable_int(varname, image_type_id,
EFI_VARIABLE_READ_ONLY |
EFI_VARIABLE_NON_VOLATILE |
EFI_VARIABLE_BOOTSERVICE_ACCESS |
EFI_VARIABLE_RUNTIME_ACCESS,
- sizeof(var_state), _state, false);
+ size, var_state,
[PATCH v3 1/2] fwu: fix fwu_get_image_index interface
The capsule update uses the DFU framework for updating
storage. fwu_get_image_index() currently returns the
image_index calculated by (dfu_alt_num + 1), but this is
different from the image_index in UEFI terminology.
Since capsule update implementation calls dfu_write_by_alt
function, it is better that FWU returns the dfu_alt_num.
Signed-off-by: Masahisa Kojima
Reviewed-by: Ilias Apalodimas
---
include/fwu.h | 13 +
lib/efi_loader/efi_firmware.c | 11 +--
lib/fwu_updates/fwu.c | 32
3 files changed, 26 insertions(+), 30 deletions(-)
diff --git a/include/fwu.h b/include/fwu.h
index ac5c5de870..eb5638f4f3 100644
--- a/include/fwu.h
+++ b/include/fwu.h
@@ -122,21 +122,18 @@ int fwu_get_active_index(uint *active_idxp);
int fwu_set_active_index(uint active_idx);
/**
- * fwu_get_image_index() - Get the Image Index to be used for capsule update
- * @image_index: The Image Index for the image
- *
- * The FWU multi bank update feature computes the value of image_index at
- * runtime, based on the bank to which the image needs to be written to.
- * Derive the image_index value for the image.
+ * fwu_get_dfu_alt_num() - Get the dfu_alt_num to be used for capsule update
+ * @image_index: The Image Index for the image
+ * @alt_num: pointer to store dfu_alt_num
*
* Currently, the capsule update driver uses the DFU framework for
* the updates. This function gets the DFU alt number which is to
- * be used as the Image Index
+ * be used for capsule update.
*
* Return: 0 if OK, -ve on error
*
*/
-int fwu_get_image_index(u8 *image_index);
+int fwu_get_dfu_alt_num(u8 image_index, u8 *alt_num);
/**
* fwu_revert_boot_index() - Revert the active index in the FWU metadata
diff --git a/lib/efi_loader/efi_firmware.c b/lib/efi_loader/efi_firmware.c
index 1fde1885e3..e558336bc1 100644
--- a/lib/efi_loader/efi_firmware.c
+++ b/lib/efi_loader/efi_firmware.c
@@ -610,6 +610,7 @@ efi_status_t EFIAPI efi_firmware_raw_set_image(
u16 **abort_reason)
{
int ret;
+ u8 dfu_alt_num;
efi_status_t status;
struct fmp_state state = { 0 };
@@ -624,19 +625,25 @@ efi_status_t EFIAPI efi_firmware_raw_set_image(
if (status != EFI_SUCCESS)
return EFI_EXIT(status);
+ /*
+* dfu_alt_num is assigned from 0 while image_index starts from 1.
+* dfu_alt_num is calculated by (image_index - 1) when multi bank update
+* is not used.
+*/
+ dfu_alt_num = image_index - 1;
if (IS_ENABLED(CONFIG_FWU_MULTI_BANK_UPDATE)) {
/*
* Based on the value of update bank, derive the
* image index value.
*/
- ret = fwu_get_image_index(_index);
+ ret = fwu_get_dfu_alt_num(image_index, _alt_num);
if (ret) {
log_debug("Unable to get FWU image_index\n");
return EFI_EXIT(EFI_DEVICE_ERROR);
}
}
- if (dfu_write_by_alt(image_index - 1, (void *)image, image_size,
+ if (dfu_write_by_alt(dfu_alt_num, (void *)image, image_size,
NULL, NULL))
return EFI_EXIT(EFI_DEVICE_ERROR);
diff --git a/lib/fwu_updates/fwu.c b/lib/fwu_updates/fwu.c
index b580574015..86518108c2 100644
--- a/lib/fwu_updates/fwu.c
+++ b/lib/fwu_updates/fwu.c
@@ -125,16 +125,14 @@ static int in_trial_state(struct fwu_mdata *mdata)
return 0;
}
-static int fwu_get_image_type_id(u8 *image_index, efi_guid_t *image_type_id)
+static int fwu_get_image_type_id(u8 image_index, efi_guid_t *image_type_id)
{
- u8 index;
int i;
struct efi_fw_image *image;
- index = *image_index;
image = update_info.images;
for (i = 0; i < update_info.num_images; i++) {
- if (index == image[i].image_index) {
+ if (image_index == image[i].image_index) {
guidcpy(image_type_id, [i].image_type_id);
return 0;
}
@@ -332,24 +330,20 @@ int fwu_set_active_index(uint active_idx)
}
/**
- * fwu_get_image_index() - Get the Image Index to be used for capsule update
- * @image_index: The Image Index for the image
- *
- * The FWU multi bank update feature computes the value of image_index at
- * runtime, based on the bank to which the image needs to be written to.
- * Derive the image_index value for the image.
+ * fwu_get_dfu_alt_num() - Get the dfu_alt_num to be used for capsule update
+ * @image_index: The Image Index for the image
+ * @alt_num: pointer to store dfu_alt_num
*
* Currently, the capsule update driver uses the DFU framework for
* the updates. This function gets the DFU alt number which is to
- * be used as the Image Index
+ * be used for capsule update.
*
* Return: 0 if OK, -ve on error
*
*/
-int
[PATCH v3 0/2] fix FMP versioning for FWU multi bank update
The current FMP versioning does not work when CONFIG_FWU_MULTI_BANK_UPDATE is enabled. This series aims to support FMP versioning for FWU multi bank update. [Changelog] v2 -> v3 - add comment of ignoring GetVariable error when set FmpState variable v1 -> v2 - update fwu_get_image_index() function to return the dfu_alt_num - store firmware version into the array of fmp_state structure Masahisa Kojima (2): fwu: fix fwu_get_image_index interface efi_loader: support fmp versioning for multi bank update include/fwu.h | 13 ++ lib/efi_loader/efi_firmware.c | 86 --- lib/fwu_updates/fwu.c | 32 + 3 files changed, 86 insertions(+), 45 deletions(-) -- 2.34.1
Re: Please pull u-boot-samsung master
Hi. 2024년 1월 10일 (수) 02:49, Tom Rini 님이 작성: > On Tue, Jan 09, 2024 at 10:55:16AM +0900, Minkyu Kang wrote: > > > Dear Tom, > > > > The following changes since commit > 2f0282922b2c458eea7f85c500a948a587437b63: > > > > Prepare v2024.01-rc4 (2023-12-04 13:46:56 -0500) > > > > are available in the git repository at: > > > > g...@source.denx.de:u-boot/custodians/u-boot-samsung.git master > > > > for you to fetch changes up to 5631d20e2ef1008d55569790f79672ea8cc6894b: > > > > pinctrl: exynos: Convert to use livetree API for fdt access (2023-12-07 > > 18:58:48 +0900) > > > > > > Sam Protsenko (7): > > pinctrl: exynos: Improve coding style > > pinctrl: exynos: Extract pin parsing code into a separate function > > pinctrl: exynos: Rework pin_to_bank_base() to obtain data by name > > pinctrl: exynos: Support different register types in pin banks > > pinctrl: exynos: Refactor handling the pin related dt properties > > pinctrl: exynos: Reduce variables scope > > pinctrl: exynos: Convert to use livetree API for fdt access > > > > Stefan Bosch (2): > > common: board_f: change calculation of gd->mon_len to fix s5p4418 > > reloc > > arm: s5p4418: fix relocation of vectors > > Taking just the pincttrl changes here (as I know this blocks other work) > I've taken that and I assume Stefan will fix microblaze shortly and then > his work can be picked up. Ok, I'll rebase my branch. Thanks. Minkyu Kang
Re: [PATCH v2 2/2] efi_loader: support fmp versioning for multi bank update
Hi Ilias,
On Thu, 11 Jan 2024 at 10:53, Masahisa Kojima
wrote:
>
> On Wed, 10 Jan 2024 at 18:10, Ilias Apalodimas
> wrote:
> >
> > On Wed, 10 Jan 2024 at 02:53, Masahisa Kojima
> > wrote:
> > >
> > > On Tue, 9 Jan 2024 at 22:02, Ilias Apalodimas
> > > wrote:
> > > >
> > > > On Tue, 9 Jan 2024 at 03:00, Masahisa Kojima
> > > > wrote:
> > > > >
> > > > > Hi Ilias,
> > > > >
> > > > > On Thu, 28 Dec 2023 at 00:14, Ilias Apalodimas
> > > > > wrote:
> > > > > >
> > > > > > Kojima-san
> > > > > >
> > > > > > On Thu, Dec 21, 2023 at 06:52:58PM +0900, Masahisa Kojima wrote:
> > > > > > > This commit stores the firmware version into the array
> > > > > > > of fmp_state structure to support the fmp versioning
> > > > > > > for multi bank update. The index of the array is identified
> > > > > > > by the bank index.
> > > > > >
> > > > > > Why do we all of them? Can't we just always store/use the version
> > > > > > of the active
> > > > > > bank?
> > > > >
> > > > > Sorry for the late reply.
> > > > > When the capsule update is reverted, the active bank is back to the
> > > > > previous active bank.
> > > > > So I think versions for all banks should be stored.
> > > >
> > > > But even in that case, the active bank should point to the correct
> > > > version when the ESRT tables are generated. Wouldn't it be simpler to
> > > > just set the FmpState variable accordingly when that happens?
> > >
> > > The fw_version in FmpState variable comes from UEFI Capsule Header and
> > > FmpState variable is set when the UEFI capsule update is performed.
> > > If we only store the fw_version of the active bank, the fw_version of
> > > the previous active bank is overwritten. When the capsule is reverted,
> > > we can not get the fw_version of the previous active bank.
> > >
> > > Thanks,
> > > Masahisa Kojima
> >
> > Ah yes, that makes sense. In that case, the patch looks fine, apart
> > from the return value of the getvariable call which is never checked
> >
> >
> > > > > > >
> > > > > > > image_type_id = efi_firmware_get_image_type_id(image_index);
> > > > > > > if (!image_type_id)
> > > > > > > @@ -372,19 +392,38 @@ efi_status_t
> > > > > > > efi_firmware_set_fmp_state_var(struct fmp_state *state, u8
> > > > > > > image_in
> > > > > > > efi_create_indexed_name(varname, sizeof(varname),
> > > > > > > "FmpState",
> > > > > > > image_index);
> > > > > > >
> > > > > > > + if (IS_ENABLED(CONFIG_FWU_MULTI_BANK_UPDATE)) {
> > > > > > > + ret = fwu_plat_get_update_index(_bank);
> > > > > > > + if (ret)
> > > > > > > + return EFI_INVALID_PARAMETER;
> > > > > > > +
> > > > > > > + num_banks = CONFIG_FWU_NUM_BANKS;
> > > > > > > + }
> > > > > > > +
> > > > > > > + size = num_banks * sizeof(*var_state);
> > > > > > > + var_state = calloc(1, size);
> > > > > > > + if (!var_state)
> > > > > > > + return EFI_OUT_OF_RESOURCES;
> > > > > > > +
> > > > > > > + ret = efi_get_variable_int(varname, image_type_id, NULL,
> > > > > > > ,
> > > > > > > +var_state, NULL);
> > > > > > > +
> >
> > We should be checking the return value here.
>
> I will fix it.
This efi_get_variable_int() call may fail, EFI_NOT_FOUND is returned
if FmpState variable has not been set yet for example.
We can ignore the error since the correct FmpState variable is set later.
I will add a comment.
Thanks,
Masahisa Kojima
>
> Thanks,
> Masahisa Kojima
>
> >
> > > > > > > /*
> > > > > > >* Only the fw_version is set here.
> > > > > > >* lowest_supported_version in FmpState variable is ignored
> > > > > > > since
> > > > > > >* it can be tampered if the file based EFI variable
> > > > > > > storage is used.
> > > > > > >*/
> > > > > > > - var_state.fw_version = state->fw_version;
> > > > > > > + var_state[update_bank].fw_version = state->fw_version;
> > > > > > >
> > > > > > > + size = num_banks * sizeof(*var_state);
> > > > > > > ret = efi_set_variable_int(varname, image_type_id,
> > > > > > > EFI_VARIABLE_READ_ONLY |
> > > > > > > EFI_VARIABLE_NON_VOLATILE |
> > > > > > > EFI_VARIABLE_BOOTSERVICE_ACCESS |
> > > > > > > EFI_VARIABLE_RUNTIME_ACCESS,
> > > > > > > -sizeof(var_state), _state,
> > > > > > > false);
> > > > > > > +size, var_state, false);
> > > > > > > +
> > > > > > > + free(var_state);
> > > > > > >
> > > > > > > return ret;
> > > > > > > }
> > > > > > > --
> > > > > > > 2.34.1
> > > > > > >
> >
> > Thanks
> > /Ilias
RE: FIELD_RETURN on i.MX8MNANOLPD4 EVK
I think there is no particular SW support needed for FIELD_RETURN on 8MN. From what you described, you have moved the part from closed to FIELD_RETURN. So are you able to boot into SPL without signature? Best regards, Ye Li > -Original Message- > From: Peng Fan (OSS) > Sent: Thursday, January 11, 2024 11:51 AM > To: Thomas Schäfer ; 'u-boot@lists.denx.de' > ; Ye Li > Cc: Peng Fan > Subject: Re: FIELD_RETURN on i.MX8MNANOLPD4 EVK > > +Ye > > 在 1/9/2024 4:52 PM, Thomas Schaefer 写道: > > Hi all, > > > > We are trying to enable FIELD RETURN on the NXP i.MX8MNano LPD4 EVK > board. > > > > We enabled Secure Boot in u-boot in the first step. After checking proper > execution of a signed bootloader image we closed the board blowing the > SEC_CONFIG fuse. > > > > In the next step we created the board specific signature with UID of the CPU > included to remove the FIELD RETURN lock. After that we were able to blow > the FIELD_RETURN fuse with 'fuse prog 8 3 0x1' command. But now, the board > cannot boot any more, it will hang after execution of the SPL bootloader part. > > > > We can observe this behavior with both signed and unsigned bootloader > images. > > > > Is the FIELD_RETURN feature for the i.MX8MNano supported with u-boot > v2024.01? > > > > Best regards, > > Thomas > > > > > > Thomas Schäfer > > SW Design Engineer > > > > thomas.schae...@kontron.com > > www.kontron.com > > > > > > > > > > Kontron Europe GmbH > > Heinrich-Barth-Straße 1-1a | 66115 Saarbrücken | Germany
Re: FIELD_RETURN on i.MX8MNANOLPD4 EVK
+Ye 在 1/9/2024 4:52 PM, Thomas Schaefer 写道: Hi all, We are trying to enable FIELD RETURN on the NXP i.MX8MNano LPD4 EVK board. We enabled Secure Boot in u-boot in the first step. After checking proper execution of a signed bootloader image we closed the board blowing the SEC_CONFIG fuse. In the next step we created the board specific signature with UID of the CPU included to remove the FIELD RETURN lock. After that we were able to blow the FIELD_RETURN fuse with 'fuse prog 8 3 0x1' command. But now, the board cannot boot any more, it will hang after execution of the SPL bootloader part. We can observe this behavior with both signed and unsigned bootloader images. Is the FIELD_RETURN feature for the i.MX8MNano supported with u-boot v2024.01? Best regards, Thomas Thomas Schäfer SW Design Engineer thomas.schae...@kontron.com www.kontron.com Kontron Europe GmbH Heinrich-Barth-Straße 1-1a | 66115 Saarbrücken | Germany
[PATCH v2 12/13] board: samsung: Add support for E850-96 board
Add support for WinLink E850-96 board [1]. It's based on Exynos850 SoC
and follows 96boards specification, so it's compatible with 96boards
mezzanine boards [2]. This patch enables next features:
* Serial console
* USI
* PMU (muxing AP UART path)
* Pinctrl
* Clocks
* Timer (ARMv8 architected)
* Reset control
It's quite a minimal enablement. Features like MMC, USB and Ethernet
will be enabled later.
The rationale for config values is as follows:
* TEXT_BASE = 0xf880
That's where BL2 loads the U-Boot payload, so TEXT_BASE must be
exactly this value. Overall the memory map is designed in a way to
keep the bootloader in the upper 128 MiB area of RAM, which is
0xf800..0x. That includes bootloader's code, stack,
data, heap, MMU tables, etc. All the memory below that 128 MiB chunk
can be used for storing boot images (0x8000..0xf800).
* CUSTOM_SYS_INIT_SP_ADDR = 0xf8c0
Just 4 MiB above the TEXT_BASE address, to leave enough space for
U-Boot code and stack itself (grows downwards).
* SYS_LOAD_ADDR = 0x8000
The beginning of RAM. That's where Linux kernel image must be
loaded.
* SYS_MALLOC_LEN = 0x81f000
8 MiB for malloc() + ENV_SIZE (128 KiB)
* SYS_MALLOC_F_LEN = 0x4000
Increase malloc() pool size available before relocation from 8 KiB
(default) to 16 KiB. Otherwise "alloc space exhausted" message
appears in U-Boot log during board_init_f() stage. There are next
reasons for doing so:
1. Having "bootph-all" flags in some dts nodes leads to binding
those during pre-relocation stage, and binding (DM) uses
dynamic memory allocation
2. clk-exynos850 driver uses CCF clocks, which in turn use dynamic
memory allocation
Device tree file was imported from Linux kernel. All nodes and boot
phase flags added in exynos850-e850-96-u-boot.dtsi are only needed to
enable serial console:
* oscclk -> cmu_top -> cmu_peri: generate UART/USI clocks
* pinctrl_alive and uart1_pins: needed to mux UART pins
* pmu_system_controller: configures AP UART path to uart1_pins
* usi_uart: configures USI block to operate as a UART protocol
* serial_0: enables serial console (UART)
[1] https://www.96boards.org/product/e850-96b/
[2] https://www.96boards.org/products/mezzanine/
Signed-off-by: Sam Protsenko
---
Changes in v2:
- (none)
arch/arm/dts/Makefile |1 +
arch/arm/dts/exynos850-e850-96-u-boot.dtsi| 37 +
arch/arm/dts/exynos850-e850-96.dts| 273
arch/arm/mach-exynos/Kconfig | 19 +-
board/samsung/e850-96/Kconfig | 16 +
board/samsung/e850-96/MAINTAINERS |9 +
board/samsung/e850-96/Makefile|6 +
board/samsung/e850-96/e850-96.c | 22 +
configs/e850-96_defconfig | 21 +
doc/board/samsung/e850-96.rst | 87 ++
.../img/exynos850-boot-architecture.svg | 1283 +
doc/board/samsung/index.rst |1 +
include/configs/e850-96.h | 12 +
13 files changed, 1786 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/dts/exynos850-e850-96-u-boot.dtsi
create mode 100644 arch/arm/dts/exynos850-e850-96.dts
create mode 100644 board/samsung/e850-96/Kconfig
create mode 100644 board/samsung/e850-96/MAINTAINERS
create mode 100644 board/samsung/e850-96/Makefile
create mode 100644 board/samsung/e850-96/e850-96.c
create mode 100644 configs/e850-96_defconfig
create mode 100644 doc/board/samsung/e850-96.rst
create mode 100644 doc/board/samsung/img/exynos850-boot-architecture.svg
create mode 100644 include/configs/e850-96.h
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 773c2546131c..84b8203e0f6a 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -31,6 +31,7 @@ dtb-$(CONFIG_EXYNOS7420) += exynos7420-espresso7420.dtb
dtb-$(CONFIG_TARGET_A5Y17LTE) += exynos78x0-axy17lte.dtb
dtb-$(CONFIG_TARGET_A3Y17LTE) += exynos78x0-axy17lte.dtb
dtb-$(CONFIG_TARGET_A7Y17LTE) += exynos78x0-axy17lte.dtb
+dtb-$(CONFIG_TARGET_E850_96) += exynos850-e850-96.dtb
dtb-$(CONFIG_ARCH_APPLE) += \
t8103-j274.dtb \
diff --git a/arch/arm/dts/exynos850-e850-96-u-boot.dtsi
b/arch/arm/dts/exynos850-e850-96-u-boot.dtsi
new file mode 100644
index ..7ad11e9faab2
--- /dev/null
+++ b/arch/arm/dts/exynos850-e850-96-u-boot.dtsi
@@ -0,0 +1,37 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2023 Linaro Ltd.
+ */
+
+_top {
+ bootph-all;
+};
+
+_peri {
+ bootph-all;
+};
+
+ {
+ bootph-all;
+};
+
+_alive {
+ bootph-all;
+};
+
+_system_controller {
+ bootph-all;
+ samsung,uart-debug-1;
+};
+
+_0 {
+ bootph-all;
+};
+
+_pins {
+ bootph-all;
+};
+
+_uart {
+ bootph-all;
+};
diff --git a/arch/arm/dts/exynos850-e850-96.dts
b/arch/arm/dts/exynos850-e850-96.dts
new file
[PATCH v2 11/13] arm: exynos: Add Exynos850 SoC support
Samsung Exynos850 is ARMv8-based mobile-oriented SoC. It features
Cortex-A55 CPU (8 cores) and it's built using 8nm process.
Add Exynos850 support by enabling next features:
* Import Exynos850 SoC dtsi files from Linux kernel
* Add Exynos850 MMU memory map
* Introduce ARCH_EXYNOS9 platform config option
Signed-off-by: Sam Protsenko
---
Changes in v2:
- (none)
arch/arm/dts/exynos-pinctrl.h | 79 +++
arch/arm/dts/exynos850-pinctrl.dtsi | 663 +++
arch/arm/dts/exynos850.dtsi | 809
arch/arm/mach-exynos/Kconfig| 9 +
arch/arm/mach-exynos/mmu-arm64.c| 34 ++
5 files changed, 1594 insertions(+)
create mode 100644 arch/arm/dts/exynos-pinctrl.h
create mode 100644 arch/arm/dts/exynos850-pinctrl.dtsi
create mode 100644 arch/arm/dts/exynos850.dtsi
diff --git a/arch/arm/dts/exynos-pinctrl.h b/arch/arm/dts/exynos-pinctrl.h
new file mode 100644
index ..7dd94a9b3652
--- /dev/null
+++ b/arch/arm/dts/exynos-pinctrl.h
@@ -0,0 +1,79 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Samsung Exynos DTS pinctrl constants
+ *
+ * Copyright (c) 2016 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ * Copyright (c) 2022 Linaro Ltd
+ * Author: Krzysztof Kozlowski
+ */
+
+#ifndef __DTS_ARM64_SAMSUNG_EXYNOS_PINCTRL_H__
+#define __DTS_ARM64_SAMSUNG_EXYNOS_PINCTRL_H__
+
+#define EXYNOS_PIN_PULL_NONE 0
+#define EXYNOS_PIN_PULL_DOWN 1
+#define EXYNOS_PIN_PULL_UP 3
+
+/* Pin function in power down mode */
+#define EXYNOS_PIN_PDN_OUT00
+#define EXYNOS_PIN_PDN_OUT11
+#define EXYNOS_PIN_PDN_INPUT 2
+#define EXYNOS_PIN_PDN_PREV3
+
+/*
+ * Drive strengths for Exynos5410, Exynos542x, Exynos5800, Exynos7885,
Exynos850
+ * (except GPIO_HSI block), ExynosAutov9 (FSI0, PERIC1)
+ */
+#define EXYNOS5420_PIN_DRV_LV1 0
+#define EXYNOS5420_PIN_DRV_LV2 1
+#define EXYNOS5420_PIN_DRV_LV3 2
+#define EXYNOS5420_PIN_DRV_LV4 3
+
+/* Drive strengths for Exynos5433 */
+#define EXYNOS5433_PIN_DRV_FAST_SR10
+#define EXYNOS5433_PIN_DRV_FAST_SR21
+#define EXYNOS5433_PIN_DRV_FAST_SR32
+#define EXYNOS5433_PIN_DRV_FAST_SR43
+#define EXYNOS5433_PIN_DRV_FAST_SR54
+#define EXYNOS5433_PIN_DRV_FAST_SR65
+#define EXYNOS5433_PIN_DRV_SLOW_SR18
+#define EXYNOS5433_PIN_DRV_SLOW_SR29
+#define EXYNOS5433_PIN_DRV_SLOW_SR30xa
+#define EXYNOS5433_PIN_DRV_SLOW_SR40xb
+#define EXYNOS5433_PIN_DRV_SLOW_SR50xc
+#define EXYNOS5433_PIN_DRV_SLOW_SR60xf
+
+/* Drive strengths for Exynos7 (except FSYS1) */
+#define EXYNOS7_PIN_DRV_LV10
+#define EXYNOS7_PIN_DRV_LV22
+#define EXYNOS7_PIN_DRV_LV31
+#define EXYNOS7_PIN_DRV_LV43
+
+/* Drive strengths for Exynos7 FSYS1 block */
+#define EXYNOS7_FSYS1_PIN_DRV_LV1 0
+#define EXYNOS7_FSYS1_PIN_DRV_LV2 4
+#define EXYNOS7_FSYS1_PIN_DRV_LV3 2
+#define EXYNOS7_FSYS1_PIN_DRV_LV4 6
+#define EXYNOS7_FSYS1_PIN_DRV_LV5 1
+#define EXYNOS7_FSYS1_PIN_DRV_LV6 5
+
+/* Drive strengths for Exynos850 GPIO_HSI block */
+#define EXYNOS850_HSI_PIN_DRV_LV1 0 /* 1x */
+#define EXYNOS850_HSI_PIN_DRV_LV1_51 /* 1.5x */
+#define EXYNOS850_HSI_PIN_DRV_LV2 2 /* 2x */
+#define EXYNOS850_HSI_PIN_DRV_LV2_53 /* 2.5x */
+#define EXYNOS850_HSI_PIN_DRV_LV3 4 /* 3x */
+#define EXYNOS850_HSI_PIN_DRV_LV4 5 /* 4x */
+
+#define EXYNOS_PIN_FUNC_INPUT 0
+#define EXYNOS_PIN_FUNC_OUTPUT 1
+#define EXYNOS_PIN_FUNC_2 2
+#define EXYNOS_PIN_FUNC_3 3
+#define EXYNOS_PIN_FUNC_4 4
+#define EXYNOS_PIN_FUNC_5 5
+#define EXYNOS_PIN_FUNC_6 6
+#define EXYNOS_PIN_FUNC_EINT 0xf
+#define EXYNOS_PIN_FUNC_F EXYNOS_PIN_FUNC_EINT
+
+#endif /* __DTS_ARM64_SAMSUNG_EXYNOS_PINCTRL_H__ */
diff --git a/arch/arm/dts/exynos850-pinctrl.dtsi
b/arch/arm/dts/exynos850-pinctrl.dtsi
new file mode 100644
index ..424bc80bde68
--- /dev/null
+++ b/arch/arm/dts/exynos850-pinctrl.dtsi
@@ -0,0 +1,663 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Samsung's Exynos850 SoC pin-mux and pin-config device tree source
+ *
+ * Copyright (C) 2017 Samsung Electronics Co., Ltd.
+ * Copyright (C) 2021 Linaro Ltd.
+ *
+ * Samsung's Exynos850 SoC pin-mux and pin-config options are listed as device
+ * tree nodes in this file.
+ */
+
+#include
+#include "exynos-pinctrl.h"
+
+_alive {
+ gpa0: gpa0-gpio-bank {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupt-parent = <>;
+ interrupts = ,
+,
+,
+,
+,
+,
+
[PATCH v2 13/13] MAINTAINERS: Add new Samsung subsystems
Add next Samsung subsystems with Sam Protsenko as a maintainer: - Samsung CCF Clock Framework - Exynos850 SoC Support - Samsung SoC Drivers Signed-off-by: Sam Protsenko --- Changes in v2: - (none) MAINTAINERS | 25 + 1 file changed, 25 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 4fec063a242f..33e96cd4231f 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -563,6 +563,31 @@ F: arch/arm/mach-exynos/ F: arch/arm/mach-s5pc1xx/ F: arch/arm/cpu/armv7/s5p-common/ +ARM SAMSUNG CLOCK +M: Sam Protsenko +S: Maintained +F: drivers/clk/exynos/clk-pll.c +F: drivers/clk/exynos/clk-pll.h +F: drivers/clk/exynos/clk.c +F: drivers/clk/exynos/clk.h + +ARM SAMSUNG EXYNOS850 SOC +M: Sam Protsenko +S: Maintained +F: arch/arm/dts/exynos850-pinctrl.dtsi +F: arch/arm/dts/exynos850.dtsi +F: doc/device-tree-bindings/clock/samsung,exynos850-clock.yaml +F: drivers/clk/exynos/clk-exynos850.c +F: drivers/pinctrl/exynos/pinctrl-exynos850.c +F: include/dt-bindings/clock/exynos850.h + +ARM SAMSUNG SOC DRIVERS +M: Sam Protsenko +S: Maintained +F: doc/device-tree-bindings/soc/samsung/* +F: drivers/soc/samsung/* +F: include/dt-bindings/soc/samsung,*.h + ARM SANCLOUD M: Paul Barker R: Marc Murphy -- 2.39.2
[PATCH v2 10/13] serial: s5p: Add Exynos850 compatible
Enable serial support for Exynos850 SoC by adding the corresponding
compatible string. No additional changes needed, the driver works as is
on Exynos850. Related USI and PMU configuration is enabled in separate
drivers. The only other dependencies are clock and pinctrl drivers,
which are already enabled too.
Signed-off-by: Sam Protsenko
---
Changes in v2:
- (none)
drivers/serial/serial_s5p.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/serial/serial_s5p.c b/drivers/serial/serial_s5p.c
index 7d04dcff54fc..801b7645afa4 100644
--- a/drivers/serial/serial_s5p.c
+++ b/drivers/serial/serial_s5p.c
@@ -257,6 +257,7 @@ static const struct dm_serial_ops s5p_serial_ops = {
static const struct udevice_id s5p_serial_ids[] = {
{ .compatible = "samsung,exynos4210-uart", .data = PORT_S5P },
+ { .compatible = "samsung,exynos850-uart", .data = PORT_S5P },
{ .compatible = "apple,s5l-uart", .data = PORT_S5L },
{ }
};
--
2.39.2
[PATCH v2 09/13] pinctrl: exynos: Add pinctrl support for Exynos850
Add pinctrl support for Exynos850 SoC. It was mostly extracted from
corresponding Linux kernel code [1]. Power down modes and external
interrupt data were removed while converting the code for U-Boot, but
everything else was kept almost unchanged.
[1] drivers/pinctrl/samsung/pinctrl-exynos-arm64.c
Signed-off-by: Sam Protsenko
Reviewed-by: Chanho Park
---
Changes in v2:
- Fixed driver description in the comment
- Added R-b tag
drivers/pinctrl/exynos/Kconfig | 8 ++
drivers/pinctrl/exynos/Makefile| 1 +
drivers/pinctrl/exynos/pinctrl-exynos850.c | 125 +
3 files changed, 134 insertions(+)
create mode 100644 drivers/pinctrl/exynos/pinctrl-exynos850.c
diff --git a/drivers/pinctrl/exynos/Kconfig b/drivers/pinctrl/exynos/Kconfig
index a60f49869b45..1b7fb62bc4ba 100644
--- a/drivers/pinctrl/exynos/Kconfig
+++ b/drivers/pinctrl/exynos/Kconfig
@@ -16,3 +16,11 @@ config PINCTRL_EXYNOS78x0
help
Support pin multiplexing and pin configuration control on
Samsung's Exynos78x0 SoC.
+
+config PINCTRL_EXYNOS850
+ bool "Samsung Exynos850 pinctrl driver"
+ depends on ARCH_EXYNOS && PINCTRL_FULL
+ select PINCTRL_EXYNOS
+ help
+ Support pin multiplexing and pin configuration control on
+ Samsung's Exynos850 SoC.
diff --git a/drivers/pinctrl/exynos/Makefile b/drivers/pinctrl/exynos/Makefile
index 07db970ca942..3abe1226eb74 100644
--- a/drivers/pinctrl/exynos/Makefile
+++ b/drivers/pinctrl/exynos/Makefile
@@ -6,3 +6,4 @@
obj-$(CONFIG_PINCTRL_EXYNOS) += pinctrl-exynos.o
obj-$(CONFIG_PINCTRL_EXYNOS7420) += pinctrl-exynos7420.o
obj-$(CONFIG_PINCTRL_EXYNOS78x0) += pinctrl-exynos78x0.o
+obj-$(CONFIG_PINCTRL_EXYNOS850)+= pinctrl-exynos850.o
diff --git a/drivers/pinctrl/exynos/pinctrl-exynos850.c
b/drivers/pinctrl/exynos/pinctrl-exynos850.c
new file mode 100644
index ..3ec2636e0d87
--- /dev/null
+++ b/drivers/pinctrl/exynos/pinctrl-exynos850.c
@@ -0,0 +1,125 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2023 Linaro Ltd.
+ * Author: Sam Protsenko
+ *
+ * Exynos850 pinctrl driver.
+ */
+
+#include
+#include
+#include "pinctrl-exynos.h"
+
+#define EXYNOS850_PIN_BANK(pins, reg, id) \
+ { \
+ .type = _bank_type, \
+ .offset = reg, \
+ .nr_pins= pins, \
+ .name = id\
+ }
+
+/* CON, DAT, PUD, DRV */
+static const struct samsung_pin_bank_type exynos850_bank_type = {
+ .fld_width = { 4, 1, 4, 4, },
+ .reg_offset = { 0x00, 0x04, 0x08, 0x0c, },
+};
+
+static const struct pinctrl_ops exynos850_pinctrl_ops = {
+ .set_state = exynos_pinctrl_set_state
+};
+
+/* pin banks of exynos850 pin-controller 0 (ALIVE) */
+static const struct samsung_pin_bank_data exynos850_pin_banks0[] = {
+ EXYNOS850_PIN_BANK(8, 0x000, "gpa0"),
+ EXYNOS850_PIN_BANK(8, 0x020, "gpa1"),
+ EXYNOS850_PIN_BANK(8, 0x040, "gpa2"),
+ EXYNOS850_PIN_BANK(8, 0x060, "gpa3"),
+ EXYNOS850_PIN_BANK(4, 0x080, "gpa4"),
+ EXYNOS850_PIN_BANK(3, 0x0a0, "gpq0"),
+};
+
+/* pin banks of exynos850 pin-controller 1 (CMGP) */
+static const struct samsung_pin_bank_data exynos850_pin_banks1[] = {
+ EXYNOS850_PIN_BANK(1, 0x000, "gpm0"),
+ EXYNOS850_PIN_BANK(1, 0x020, "gpm1"),
+ EXYNOS850_PIN_BANK(1, 0x040, "gpm2"),
+ EXYNOS850_PIN_BANK(1, 0x060, "gpm3"),
+ EXYNOS850_PIN_BANK(1, 0x080, "gpm4"),
+ EXYNOS850_PIN_BANK(1, 0x0a0, "gpm5"),
+ EXYNOS850_PIN_BANK(1, 0x0c0, "gpm6"),
+ EXYNOS850_PIN_BANK(1, 0x0e0, "gpm7"),
+};
+
+/* pin banks of exynos850 pin-controller 2 (AUD) */
+static const struct samsung_pin_bank_data exynos850_pin_banks2[] = {
+ EXYNOS850_PIN_BANK(5, 0x000, "gpb0"),
+ EXYNOS850_PIN_BANK(5, 0x020, "gpb1"),
+};
+
+/* pin banks of exynos850 pin-controller 3 (HSI) */
+static const struct samsung_pin_bank_data exynos850_pin_banks3[] = {
+ EXYNOS850_PIN_BANK(6, 0x000, "gpf2"),
+};
+
+/* pin banks of exynos850 pin-controller 4 (CORE) */
+static const struct samsung_pin_bank_data exynos850_pin_banks4[] = {
+ EXYNOS850_PIN_BANK(4, 0x000, "gpf0"),
+ EXYNOS850_PIN_BANK(8, 0x020, "gpf1"),
+};
+
+/* pin banks of exynos850 pin-controller 5 (PERI) */
+static const struct samsung_pin_bank_data exynos850_pin_banks5[] = {
+ EXYNOS850_PIN_BANK(2, 0x000, "gpg0"),
+ EXYNOS850_PIN_BANK(6, 0x020, "gpp0"),
+ EXYNOS850_PIN_BANK(4, 0x040, "gpp1"),
+ EXYNOS850_PIN_BANK(4, 0x060, "gpp2"),
+ EXYNOS850_PIN_BANK(8, 0x080, "gpg1"),
+ EXYNOS850_PIN_BANK(8, 0x0a0, "gpg2"),
+ EXYNOS850_PIN_BANK(1, 0x0c0, "gpg3"),
+ EXYNOS850_PIN_BANK(3, 0x0e0, "gpc0"),
+ EXYNOS850_PIN_BANK(6, 0x100, "gpc1"),
+};
+
+static const struct samsung_pin_ctrl
[PATCH v2 08/13] clk: exynos: Add Exynos850 clock driver
Heavily influenced by its Linux kernel counterpart. It's implemented on
top of recently added Samsung CCF clock framework API. For now only UART
leaf clocks are implemented, along with all preceding clocks in CMU_TOP
and CMU_PERI. The UART baud clock is required in the serial driver, to
get its rate for the consequent baud rate calculation.
Signed-off-by: Sam Protsenko
Reviewed-by: Chanho Park
---
Changes in v2:
- Added R-b tag
drivers/clk/exynos/Kconfig | 7 ++
drivers/clk/exynos/Makefile| 1 +
drivers/clk/exynos/clk-exynos850.c | 189 +
3 files changed, 197 insertions(+)
create mode 100644 drivers/clk/exynos/clk-exynos850.c
diff --git a/drivers/clk/exynos/Kconfig b/drivers/clk/exynos/Kconfig
index eb0efa97d15c..85ce9d6e2418 100644
--- a/drivers/clk/exynos/Kconfig
+++ b/drivers/clk/exynos/Kconfig
@@ -15,4 +15,11 @@ config CLK_EXYNOS7420
This enables common clock driver support for platforms based
on Samsung Exynos7420 SoC.
+config CLK_EXYNOS850
+ bool "Clock driver for Samsung's Exynos850 SoC"
+ select CLK_CCF
+ help
+ This enables common clock driver support for platforms based
+ on Samsung Exynos850 SoC.
+
endmenu
diff --git a/drivers/clk/exynos/Makefile b/drivers/clk/exynos/Makefile
index 04c5b9a39e16..734100e2bff3 100644
--- a/drivers/clk/exynos/Makefile
+++ b/drivers/clk/exynos/Makefile
@@ -9,3 +9,4 @@
obj-$(CONFIG_$(SPL_TPL_)CLK_CCF) += clk.o clk-pll.o
obj-$(CONFIG_CLK_EXYNOS7420) += clk-exynos7420.o
+obj-$(CONFIG_CLK_EXYNOS850)+= clk-exynos850.o
diff --git a/drivers/clk/exynos/clk-exynos850.c
b/drivers/clk/exynos/clk-exynos850.c
new file mode 100644
index ..cf94a3e1b646
--- /dev/null
+++ b/drivers/clk/exynos/clk-exynos850.c
@@ -0,0 +1,189 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Samsung Exynos850 clock driver.
+ * Copyright (c) 2023 Linaro Ltd.
+ * Author: Sam Protsenko
+ */
+
+#include
+#include
+#include
+#include "clk.h"
+
+/* CMU_TOP -
*/
+
+/* Register Offset definitions for CMU_TOP (0x120e) */
+#define PLL_CON0_PLL_MMC 0x0100
+#define PLL_CON3_PLL_MMC 0x010c
+#define PLL_CON0_PLL_SHARED0 0x0140
+#define PLL_CON3_PLL_SHARED0 0x014c
+#define PLL_CON0_PLL_SHARED1 0x0180
+#define PLL_CON3_PLL_SHARED1 0x018c
+#define CLK_CON_MUX_MUX_CLKCMU_PERI_BUS0x1070
+#define CLK_CON_MUX_MUX_CLKCMU_PERI_IP 0x1074
+#define CLK_CON_MUX_MUX_CLKCMU_PERI_UART 0x1078
+#define CLK_CON_DIV_CLKCMU_PERI_BUS0x187c
+#define CLK_CON_DIV_CLKCMU_PERI_IP 0x1880
+#define CLK_CON_DIV_CLKCMU_PERI_UART 0x1884
+#define CLK_CON_DIV_PLL_SHARED0_DIV2 0x188c
+#define CLK_CON_DIV_PLL_SHARED0_DIV3 0x1890
+#define CLK_CON_DIV_PLL_SHARED0_DIV4 0x1894
+#define CLK_CON_DIV_PLL_SHARED1_DIV2 0x1898
+#define CLK_CON_DIV_PLL_SHARED1_DIV3 0x189c
+#define CLK_CON_DIV_PLL_SHARED1_DIV4 0x18a0
+#define CLK_CON_GAT_GATE_CLKCMU_PERI_BUS 0x2080
+#define CLK_CON_GAT_GATE_CLKCMU_PERI_IP0x2084
+#define CLK_CON_GAT_GATE_CLKCMU_PERI_UART 0x2088
+
+static const struct samsung_pll_clock top_pure_pll_clks[] = {
+ PLL(pll_0822x, CLK_FOUT_SHARED0_PLL, "fout_shared0_pll", "clock-oscclk",
+ PLL_CON3_PLL_SHARED0),
+ PLL(pll_0822x, CLK_FOUT_SHARED1_PLL, "fout_shared1_pll", "clock-oscclk",
+ PLL_CON3_PLL_SHARED1),
+ PLL(pll_0831x, CLK_FOUT_MMC_PLL, "fout_mmc_pll", "clock-oscclk",
+ PLL_CON3_PLL_MMC),
+};
+
+/* List of parent clocks for Muxes in CMU_TOP */
+PNAME(mout_shared0_pll_p) = { "clock-oscclk", "fout_shared0_pll" };
+PNAME(mout_shared1_pll_p) = { "clock-oscclk", "fout_shared1_pll" };
+PNAME(mout_mmc_pll_p) = { "clock-oscclk", "fout_mmc_pll" };
+/* List of parent clocks for Muxes in CMU_TOP: for CMU_PERI */
+PNAME(mout_peri_bus_p) = { "dout_shared0_div4", "dout_shared1_div4" };
+PNAME(mout_peri_uart_p)= { "clock-oscclk", "dout_shared0_div4",
+ "dout_shared1_div4", "clock-oscclk" };
+PNAME(mout_peri_ip_p) = { "clock-oscclk", "dout_shared0_div4",
+ "dout_shared1_div4", "clock-oscclk" };
+
+static const struct samsung_mux_clock top_pure_mux_clks[] = {
+ MUX(CLK_MOUT_SHARED0_PLL, "mout_shared0_pll", mout_shared0_pll_p,
+ PLL_CON0_PLL_SHARED0, 4, 1),
+ MUX(CLK_MOUT_SHARED1_PLL, "mout_shared1_pll", mout_shared1_pll_p,
+ PLL_CON0_PLL_SHARED1, 4, 1),
+ MUX(CLK_MOUT_MMC_PLL, "mout_mmc_pll", mout_mmc_pll_p,
+ PLL_CON0_PLL_MMC, 4, 1),
+};
+
+static const struct samsung_mux_clock top_peri_mux_clks[] = {
+ MUX(CLK_MOUT_PERI_BUS, "mout_peri_bus",
[PATCH v2 06/13] clk: exynos: Move pll code into clk-exynos7420
PLL utilities code is only used by clk-exynos7420 driver at the moment.
Move it into clk-exynos7420 to make clk-pll.c file available for CCF PLL
clocks implementation, which is coming in the next patches.
Signed-off-by: Sam Protsenko
Reviewed-by: Chanho Park
---
Changes in v2:
- Added R-b tag
drivers/clk/exynos/Makefile | 1 -
drivers/clk/exynos/clk-exynos7420.c | 25 +-
drivers/clk/exynos/clk-pll.c| 32 -
drivers/clk/exynos/clk-pll.h| 13
4 files changed, 24 insertions(+), 47 deletions(-)
delete mode 100644 drivers/clk/exynos/clk-pll.c
delete mode 100644 drivers/clk/exynos/clk-pll.h
diff --git a/drivers/clk/exynos/Makefile b/drivers/clk/exynos/Makefile
index c9f29c873e9b..7faf238571ef 100644
--- a/drivers/clk/exynos/Makefile
+++ b/drivers/clk/exynos/Makefile
@@ -3,5 +3,4 @@
# Copyright (C) 2016 Samsung Electronics
# Thomas Abraham
-obj-y += clk-pll.o
obj-$(CONFIG_CLK_EXYNOS7420) += clk-exynos7420.o
diff --git a/drivers/clk/exynos/clk-exynos7420.c
b/drivers/clk/exynos/clk-exynos7420.c
index 7d869eb02b8e..9caa932e12fb 100644
--- a/drivers/clk/exynos/clk-exynos7420.c
+++ b/drivers/clk/exynos/clk-exynos7420.c
@@ -10,8 +10,15 @@
#include
#include
#include
+#include
#include
-#include "clk-pll.h"
+
+#define PLL145X_MDIV_SHIFT 16
+#define PLL145X_MDIV_MASK 0x3ff
+#define PLL145X_PDIV_SHIFT 8
+#define PLL145X_PDIV_MASK 0x3f
+#define PLL145X_SDIV_SHIFT 0
+#define PLL145X_SDIV_MASK 0x7
#define DIVIDER(reg, shift, mask) \
(((readl(reg) >> shift) & mask) + 1)
@@ -64,6 +71,22 @@ struct exynos7420_clk_top0_priv {
unsigned long sclk_uart2;
};
+static unsigned long pll145x_get_rate(unsigned int *con1,
+ unsigned long fin_freq)
+{
+ unsigned long pll_con1 = readl(con1);
+ unsigned long mdiv, sdiv, pdiv;
+ u64 fvco = fin_freq;
+
+ mdiv = (pll_con1 >> PLL145X_MDIV_SHIFT) & PLL145X_MDIV_MASK;
+ pdiv = (pll_con1 >> PLL145X_PDIV_SHIFT) & PLL145X_PDIV_MASK;
+ sdiv = (pll_con1 >> PLL145X_SDIV_SHIFT) & PLL145X_SDIV_MASK;
+
+ fvco *= mdiv;
+ do_div(fvco, (pdiv << sdiv));
+ return (unsigned long)fvco;
+}
+
static ulong exynos7420_topc_get_rate(struct clk *clk)
{
struct exynos7420_clk_topc_priv *priv = dev_get_priv(clk->dev);
diff --git a/drivers/clk/exynos/clk-pll.c b/drivers/clk/exynos/clk-pll.c
deleted file mode 100644
index 407fc71d415b..
--- a/drivers/clk/exynos/clk-pll.c
+++ /dev/null
@@ -1,32 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+
-/*
- * Exynos PLL helper functions for clock drivers.
- * Copyright (C) 2016 Samsung Electronics
- * Thomas Abraham
- */
-
-#include
-#include
-#include
-
-#define PLL145X_MDIV_SHIFT 16
-#define PLL145X_MDIV_MASK 0x3ff
-#define PLL145X_PDIV_SHIFT 8
-#define PLL145X_PDIV_MASK 0x3f
-#define PLL145X_SDIV_SHIFT 0
-#define PLL145X_SDIV_MASK 0x7
-
-unsigned long pll145x_get_rate(unsigned int *con1, unsigned long fin_freq)
-{
- unsigned long pll_con1 = readl(con1);
- unsigned long mdiv, sdiv, pdiv;
- uint64_t fvco = fin_freq;
-
- mdiv = (pll_con1 >> PLL145X_MDIV_SHIFT) & PLL145X_MDIV_MASK;
- pdiv = (pll_con1 >> PLL145X_PDIV_SHIFT) & PLL145X_PDIV_MASK;
- sdiv = (pll_con1 >> PLL145X_SDIV_SHIFT) & PLL145X_SDIV_MASK;
-
- fvco *= mdiv;
- do_div(fvco, (pdiv << sdiv));
- return (unsigned long)fvco;
-}
diff --git a/drivers/clk/exynos/clk-pll.h b/drivers/clk/exynos/clk-pll.h
deleted file mode 100644
index 7b7af5e67612..
--- a/drivers/clk/exynos/clk-pll.h
+++ /dev/null
@@ -1,13 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0+ */
-/*
- * Exynos PLL helper functions for clock drivers.
- * Copyright (C) 2016 Samsung Electronics
- * Thomas Abraham
- */
-
-#ifndef __EXYNOS_CLK_PLL_H
-#define __EXYNOS_CLK_PLL_H
-
-unsigned long pll145x_get_rate(unsigned int *con1, unsigned long fin_freq);
-
-#endif /* __EXYNOS_CLK_PLL_H */
--
2.39.2
[PATCH v2 07/13] clk: exynos: Add Samsung clock framework
Heavily based on Linux kernel Samsung clock framework, with some changes
to accommodate the differences in U-Boot CCF implementation. It's also
quite minimal as compared to the Linux version.
Signed-off-by: Sam Protsenko
Reviewed-by: Chanho Park
---
Changes in v2:
- Corrected Thomas Abraham's e-mail
- Added R-b tag
drivers/clk/exynos/Makefile | 9 +-
drivers/clk/exynos/clk-pll.c | 167 +
drivers/clk/exynos/clk-pll.h | 23
drivers/clk/exynos/clk.c | 121 +++
drivers/clk/exynos/clk.h | 228 +++
5 files changed, 546 insertions(+), 2 deletions(-)
create mode 100644 drivers/clk/exynos/clk-pll.c
create mode 100644 drivers/clk/exynos/clk-pll.h
create mode 100644 drivers/clk/exynos/clk.c
create mode 100644 drivers/clk/exynos/clk.h
diff --git a/drivers/clk/exynos/Makefile b/drivers/clk/exynos/Makefile
index 7faf238571ef..04c5b9a39e16 100644
--- a/drivers/clk/exynos/Makefile
+++ b/drivers/clk/exynos/Makefile
@@ -1,6 +1,11 @@
# SPDX-License-Identifier: GPL-2.0+
#
# Copyright (C) 2016 Samsung Electronics
-# Thomas Abraham
+# Copyright (C) 2023 Linaro Ltd.
+#
+# Authors:
+# Thomas Abraham
+# Sam Protsenko
-obj-$(CONFIG_CLK_EXYNOS7420) += clk-exynos7420.o
+obj-$(CONFIG_$(SPL_TPL_)CLK_CCF) += clk.o clk-pll.o
+obj-$(CONFIG_CLK_EXYNOS7420) += clk-exynos7420.o
diff --git a/drivers/clk/exynos/clk-pll.c b/drivers/clk/exynos/clk-pll.c
new file mode 100644
index ..4aacbc26b25d
--- /dev/null
+++ b/drivers/clk/exynos/clk-pll.c
@@ -0,0 +1,167 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2016 Samsung Electronics
+ * Copyright (C) 2023 Linaro Ltd.
+ *
+ * Authors:
+ * Thomas Abraham
+ * Sam Protsenko
+ *
+ * This file contains the utility functions to register the pll clocks.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include "clk.h"
+
+#define UBOOT_DM_CLK_SAMSUNG_PLL0822X "samsung_clk_pll0822x"
+#define UBOOT_DM_CLK_SAMSUNG_PLL0831X "samsung_clk_pll0831x"
+
+struct samsung_clk_pll {
+ struct clk clk;
+ void __iomem*con_reg;
+ enum samsung_pll_type type;
+};
+
+#define to_clk_pll(_clk) container_of(_clk, struct samsung_clk_pll, clk)
+
+/*
+ * PLL0822x Clock Type
+ */
+
+#define PLL0822X_MDIV_MASK 0x3ff
+#define PLL0822X_PDIV_MASK 0x3f
+#define PLL0822X_SDIV_MASK 0x7
+#define PLL0822X_MDIV_SHIFT16
+#define PLL0822X_PDIV_SHIFT8
+#define PLL0822X_SDIV_SHIFT0
+
+static unsigned long samsung_pll0822x_recalc_rate(struct clk *clk)
+{
+ struct samsung_clk_pll *pll = to_clk_pll(clk);
+ u32 mdiv, pdiv, sdiv, pll_con3;
+ u64 fvco = clk_get_parent_rate(clk);
+
+ pll_con3 = readl_relaxed(pll->con_reg);
+ mdiv = (pll_con3 >> PLL0822X_MDIV_SHIFT) & PLL0822X_MDIV_MASK;
+ pdiv = (pll_con3 >> PLL0822X_PDIV_SHIFT) & PLL0822X_PDIV_MASK;
+ sdiv = (pll_con3 >> PLL0822X_SDIV_SHIFT) & PLL0822X_SDIV_MASK;
+
+ fvco *= mdiv;
+ do_div(fvco, (pdiv << sdiv));
+ return (unsigned long)fvco;
+}
+
+static const struct clk_ops samsung_pll0822x_clk_min_ops = {
+ .get_rate = samsung_pll0822x_recalc_rate,
+};
+
+/*
+ * PLL0831x Clock Type
+ */
+
+#define PLL0831X_KDIV_MASK 0x
+#define PLL0831X_MDIV_MASK 0x1ff
+#define PLL0831X_PDIV_MASK 0x3f
+#define PLL0831X_SDIV_MASK 0x7
+#define PLL0831X_MDIV_SHIFT16
+#define PLL0831X_PDIV_SHIFT8
+#define PLL0831X_SDIV_SHIFT0
+#define PLL0831X_KDIV_SHIFT0
+
+static unsigned long samsung_pll0831x_recalc_rate(struct clk *clk)
+{
+ struct samsung_clk_pll *pll = to_clk_pll(clk);
+ u32 mdiv, pdiv, sdiv, pll_con3, pll_con5;
+ s16 kdiv;
+ u64 fvco = clk_get_parent_rate(clk);
+
+ pll_con3 = readl_relaxed(pll->con_reg);
+ pll_con5 = readl_relaxed(pll->con_reg + 8);
+ mdiv = (pll_con3 >> PLL0831X_MDIV_SHIFT) & PLL0831X_MDIV_MASK;
+ pdiv = (pll_con3 >> PLL0831X_PDIV_SHIFT) & PLL0831X_PDIV_MASK;
+ sdiv = (pll_con3 >> PLL0831X_SDIV_SHIFT) & PLL0831X_SDIV_MASK;
+ kdiv = (s16)((pll_con5 >> PLL0831X_KDIV_SHIFT) & PLL0831X_KDIV_MASK);
+
+ fvco *= (mdiv << 16) + kdiv;
+ do_div(fvco, (pdiv << sdiv));
+ fvco >>= 16;
+
+ return (unsigned long)fvco;
+}
+
+static const struct clk_ops samsung_pll0831x_clk_min_ops = {
+ .get_rate = samsung_pll0831x_recalc_rate,
+};
+
+static struct clk *_samsung_clk_register_pll(void __iomem *base,
+ const struct samsung_pll_clock *pll_clk)
+{
+ struct samsung_clk_pll *pll;
+ struct clk *clk;
+ const char *drv_name;
+ int ret;
+
+ pll = kzalloc(sizeof(*pll), GFP_KERNEL);
+ if (!pll)
+ return ERR_PTR(-ENOMEM);
+
+ pll->con_reg = base + pll_clk->con_offset;
+
[PATCH v2 05/13] soc: samsung: Add Exynos PMU driver
Add basic Power Management Unit (PMU) driver for Exynos SoCs. For now
it's only capable of changing UART path in PMU, which is needed for
E850-96 board. The driver's structure resembles the exynos-pmu driver
from Linux kernel, and although it's very basic and slim at the moment,
it can be easily extended in future if the need arises.
UCLASS_NOP is used, as there are no benefits in using more elaborate
classes like UCLASS_MISC in this case. The DM_FLAG_PROBE_AFTER_BIND flag
is added in bind function, as the probe function must be always called
for this driver.
Signed-off-by: Sam Protsenko
Reviewed-by: Chanho Park
---
Changes in v2:
- Added R-b tag
drivers/soc/samsung/Kconfig | 10 +++
drivers/soc/samsung/Makefile | 1 +
drivers/soc/samsung/exynos-pmu.c | 102 +++
3 files changed, 113 insertions(+)
create mode 100644 drivers/soc/samsung/exynos-pmu.c
diff --git a/drivers/soc/samsung/Kconfig b/drivers/soc/samsung/Kconfig
index ffb87fe79316..737b7ca8cd19 100644
--- a/drivers/soc/samsung/Kconfig
+++ b/drivers/soc/samsung/Kconfig
@@ -5,6 +5,16 @@ menuconfig SOC_SAMSUNG
if SOC_SAMSUNG
+config EXYNOS_PMU
+ bool "Exynos PMU controller driver"
+ depends on ARCH_EXYNOS
+ select REGMAP
+ select SYSCON
+ help
+ Enable support for system controller configuration driver. It allows
+ one to configure system controller registers (e.g. some register in
+ PMU syscon) by providing register's offset, mask and value.
+
config EXYNOS_USI
bool "Exynos USI (Universal Serial Interface) driver"
depends on ARCH_EXYNOS
diff --git a/drivers/soc/samsung/Makefile b/drivers/soc/samsung/Makefile
index 833ac073fbfa..0eb3ed8353b0 100644
--- a/drivers/soc/samsung/Makefile
+++ b/drivers/soc/samsung/Makefile
@@ -1,3 +1,4 @@
# SPDX-License-Identifier: GPL-2.0+
+obj-$(CONFIG_EXYNOS_PMU) += exynos-pmu.o
obj-$(CONFIG_EXYNOS_USI) += exynos-usi.o
diff --git a/drivers/soc/samsung/exynos-pmu.c b/drivers/soc/samsung/exynos-pmu.c
new file mode 100644
index ..233ad4a908f5
--- /dev/null
+++ b/drivers/soc/samsung/exynos-pmu.c
@@ -0,0 +1,102 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2023 Linaro Ltd.
+ * Author: Sam Protsenko
+ *
+ * Exynos PMU (Power Management Unit) driver.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define EXYNOS850_UART_IO_SHARE_CTRL 0x0760
+#define SEL_RXD_AP_UART_SHIFT 16
+#define SEL_RXD_AP_UART_MASK GENMASK(17, 16)
+#define SEL_TXD_GPIO_1_SHIFT 20
+#define SEL_TXD_GPIO_1_MASKGENMASK(21, 20)
+#define RXD_GPIO_1 0x3
+#define TXD_AP_UART0x0
+
+struct exynos_pmu {
+ struct udevice *dev;
+ const struct exynos_pmu_data *pmu_data;
+ struct regmap *regmap;
+};
+
+struct exynos_pmu_data {
+ int (*pmu_init)(struct exynos_pmu *priv);
+};
+
+static int exynos850_pmu_init(struct exynos_pmu *priv)
+{
+ ofnode node;
+ bool uart_debug_1;
+ unsigned int offset, mask, value;
+
+ node = dev_ofnode(priv->dev);
+ uart_debug_1 = ofnode_read_bool(node, "samsung,uart-debug-1");
+ if (!uart_debug_1)
+ return 0;
+
+ /*
+* If uart1_pins are used for serial, AP UART lines have to be muxed
+* in PMU block to UART_DEBUG_1 path (GPIO_1). By default (reset value)
+* UART_DEBUG_0 path (uart0_pins) is connected to AP UART lines.
+*/
+ offset = EXYNOS850_UART_IO_SHARE_CTRL;
+ mask = SEL_RXD_AP_UART_MASK | SEL_TXD_GPIO_1_MASK;
+ value = RXD_GPIO_1 << SEL_RXD_AP_UART_SHIFT |
+ TXD_AP_UART << SEL_TXD_GPIO_1_SHIFT;
+ return regmap_update_bits(priv->regmap, offset, mask, value);
+}
+
+static const struct exynos_pmu_data exynos850_pmu_data = {
+ .pmu_init = exynos850_pmu_init,
+};
+
+static int exynos_pmu_bind(struct udevice *dev)
+{
+ dev_or_flags(dev, DM_FLAG_PROBE_AFTER_BIND);
+ return 0;
+}
+
+static int exynos_pmu_probe(struct udevice *dev)
+{
+ ofnode node;
+ struct exynos_pmu *priv;
+
+ priv = dev_get_priv(dev);
+ priv->dev = dev;
+
+ node = dev_ofnode(dev);
+ priv->regmap = syscon_node_to_regmap(node);
+ if (IS_ERR(priv->regmap))
+ return PTR_ERR(priv->regmap);
+
+ priv->pmu_data = (struct exynos_pmu_data *)dev_get_driver_data(dev);
+ if (priv->pmu_data && priv->pmu_data->pmu_init)
+ return priv->pmu_data->pmu_init(priv);
+
+ return 0;
+}
+
+static const struct udevice_id exynos_pmu_ids[] = {
+ {
+ .compatible = "samsung,exynos850-pmu",
+ .data = (ulong)_pmu_data
+ },
+ { /* sentinel */ }
+};
+
+U_BOOT_DRIVER(exynos_pmu) = {
+ .name = "exynos-pmu",
+ .id = UCLASS_NOP,
+ .of_match = exynos_pmu_ids,
+ .bind = exynos_pmu_bind,
[PATCH v2 04/13] soc: samsung: Add Exynos USI driver
USIv2 IP-core is found on modern ARM64 Exynos SoCs (like Exynos850) and provides selectable serial protocol (one of: UART, SPI, I2C). USIv2 registers usually reside in the same register map as a particular underlying protocol it implements, but have some particular offset. E.g. on Exynos850 the USI_UART has 0x1382 base address, where UART registers have 0x00..0x40 offsets, and USI registers have 0xc0..0xdc offsets. Desired protocol can be chosen via SW_CONF register from System Register block of the same domain as USI. Before starting to use a particular protocol, USIv2 must be configured properly: 1. Select protocol to be used via System Register 2. Clear "reset" flag in USI_CON 3. Configure HWACG behavior (e.g. for UART Rx the HWACG must be disabled, so that the IP clock is not gated automatically); this is done using USI_OPTION register 4. Keep both USI clocks (PCLK and IPCLK) running during USI registers modification This driver implements the above behavior. Of course, USIv2 driver should be probed before UART/I2C/SPI drivers. It can be achieved by embedding UART/I2C/SPI nodes inside of the USI node (in Device Tree); driver then walks underlying nodes and instantiates those. Driver also handles USI configuration on PM resume, as register contents can be lost during CPU suspend. This driver is designed with different USI versions in mind. So it should be relatively easy to add new USI revisions to it later. Driver's code was copied over from Linux kernel [1] and adapted correspondingly for U-Boot API. UCLASS_MISC is used, and although no misc operations are implemented, it makes it easier to probe the driver this way (as compared to UCLASS_NOP) and keep the code compact. [1] drivers/soc/samsung/exynos-usi.c Signed-off-by: Sam Protsenko Reviewed-by: Chanho Park Reviewed-by: Simon Glass --- Changes in v2: - Removed unnecessary 'mode' param in exynos_usi_set_sw_conf() - Removed usi->dev and used priv data instead - Used .of_plat_data callback for dts parsing - Added R-b tags drivers/soc/Kconfig | 1 + drivers/soc/Makefile | 1 + drivers/soc/samsung/Kconfig | 23 drivers/soc/samsung/Makefile | 3 + drivers/soc/samsung/exynos-usi.c | 208 +++ 5 files changed, 236 insertions(+) create mode 100644 drivers/soc/samsung/Kconfig create mode 100644 drivers/soc/samsung/Makefile create mode 100644 drivers/soc/samsung/exynos-usi.c diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig index 85dac9de78a4..03433bc0e6d2 100644 --- a/drivers/soc/Kconfig +++ b/drivers/soc/Kconfig @@ -40,6 +40,7 @@ config SOC_XILINX_VERSAL_NET This allows other drivers to verify the SoC familiy & revision using matching SoC attributes. +source "drivers/soc/samsung/Kconfig" source "drivers/soc/ti/Kconfig" endmenu diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile index 84385650d46d..610bf816d40a 100644 --- a/drivers/soc/Makefile +++ b/drivers/soc/Makefile @@ -2,6 +2,7 @@ # # Makefile for the U-Boot SOC specific device drivers. +obj-$(CONFIG_SOC_SAMSUNG) += samsung/ obj-$(CONFIG_SOC_TI) += ti/ obj-$(CONFIG_SOC_DEVICE) += soc-uclass.o obj-$(CONFIG_SOC_DEVICE_TI_K3) += soc_ti_k3.o diff --git a/drivers/soc/samsung/Kconfig b/drivers/soc/samsung/Kconfig new file mode 100644 index ..ffb87fe79316 --- /dev/null +++ b/drivers/soc/samsung/Kconfig @@ -0,0 +1,23 @@ +# SPDX-License-Identifier: GPL-2.0+ + +menuconfig SOC_SAMSUNG + bool "Samsung SoC drivers support" + +if SOC_SAMSUNG + +config EXYNOS_USI + bool "Exynos USI (Universal Serial Interface) driver" + depends on ARCH_EXYNOS + select MISC + select REGMAP + select SYSCON + help + Enable support for USI block. USI (Universal Serial Interface) is an + IP-core found in modern Samsung Exynos SoCs, like Exynos850 and + ExynosAutoV9. USI block can be configured to provide one of the + following serial protocols: UART, SPI or High Speed I2C. + + This driver allows one to configure USI for desired protocol, which + is usually done in USI node in Device Tree. + +endif diff --git a/drivers/soc/samsung/Makefile b/drivers/soc/samsung/Makefile new file mode 100644 index ..833ac073fbfa --- /dev/null +++ b/drivers/soc/samsung/Makefile @@ -0,0 +1,3 @@ +# SPDX-License-Identifier: GPL-2.0+ + +obj-$(CONFIG_EXYNOS_USI) += exynos-usi.o diff --git a/drivers/soc/samsung/exynos-usi.c b/drivers/soc/samsung/exynos-usi.c new file mode 100644 index ..b746a7838e1f --- /dev/null +++ b/drivers/soc/samsung/exynos-usi.c @@ -0,0 +1,208 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Copyright (c) 2023 Linaro Ltd. + * Author: Sam Protsenko + * + * Samsung Exynos USI driver (Universal Serial Interface). + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include + +/* USIv2: System
[PATCH v2 03/13] dt-bindings: clock: Add Exynos850 clock controller
Add bindings documentation and the header file for Exynos850 clock controller. It was taken from Linux kernel [1,2]. [1] Documentation/devicetree/bindings/clock/samsung,exynos850-clock.yaml [2] include/dt-bindings/clock/exynos850.h Signed-off-by: Sam Protsenko --- Changes in v2: - (none) .../clock/samsung,exynos850-clock.yaml| 307 include/dt-bindings/clock/exynos850.h | 337 ++ 2 files changed, 644 insertions(+) create mode 100644 doc/device-tree-bindings/clock/samsung,exynos850-clock.yaml create mode 100644 include/dt-bindings/clock/exynos850.h diff --git a/doc/device-tree-bindings/clock/samsung,exynos850-clock.yaml b/doc/device-tree-bindings/clock/samsung,exynos850-clock.yaml new file mode 100644 index ..a0906efe1223 --- /dev/null +++ b/doc/device-tree-bindings/clock/samsung,exynos850-clock.yaml @@ -0,0 +1,307 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/samsung,exynos850-clock.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung Exynos850 SoC clock controller + +maintainers: + - Sam Protsenko + +description: | + Exynos850 clock controller is comprised of several CMU units, generating + clocks for different domains. Those CMU units are modeled as separate device + tree nodes, and might depend on each other. Root clocks in that clock tree are + two external clocks:: OSCCLK (26 MHz) and RTCCLK (32768 Hz). Those external + clocks must be defined as fixed-rate clocks in dts. + + CMU_TOP is a top-level CMU, where all base clocks are prepared using PLLs and + dividers; all other leaf clocks (other CMUs) are usually derived from CMU_TOP. + + Each clock is assigned an identifier and client nodes can use this identifier + to specify the clock which they consume. All clocks available for usage + in clock consumer nodes are defined as preprocessor macros in + 'dt-bindings/clock/exynos850.h' header. + +properties: + compatible: +enum: + - samsung,exynos850-cmu-top + - samsung,exynos850-cmu-apm + - samsung,exynos850-cmu-aud + - samsung,exynos850-cmu-cmgp + - samsung,exynos850-cmu-core + - samsung,exynos850-cmu-dpu + - samsung,exynos850-cmu-g3d + - samsung,exynos850-cmu-hsi + - samsung,exynos850-cmu-is + - samsung,exynos850-cmu-mfcmscl + - samsung,exynos850-cmu-peri + + clocks: +minItems: 1 +maxItems: 5 + + clock-names: +minItems: 1 +maxItems: 5 + + "#clock-cells": +const: 1 + + reg: +maxItems: 1 + +allOf: + - if: + properties: +compatible: + contains: +const: samsung,exynos850-cmu-top + +then: + properties: +clocks: + items: +- description: External reference clock (26 MHz) + +clock-names: + items: +- const: oscclk + + - if: + properties: +compatible: + contains: +const: samsung,exynos850-cmu-apm + +then: + properties: +clocks: + items: +- description: External reference clock (26 MHz) +- description: CMU_APM bus clock (from CMU_TOP) + +clock-names: + items: +- const: oscclk +- const: dout_clkcmu_apm_bus + + - if: + properties: +compatible: + contains: +const: samsung,exynos850-cmu-aud + +then: + properties: +clocks: + items: +- description: External reference clock (26 MHz) +- description: AUD clock (from CMU_TOP) + +clock-names: + items: +- const: oscclk +- const: dout_aud + + - if: + properties: +compatible: + contains: +const: samsung,exynos850-cmu-cmgp + +then: + properties: +clocks: + items: +- description: External reference clock (26 MHz) +- description: CMU_CMGP bus clock (from CMU_APM) + +clock-names: + items: +- const: oscclk +- const: gout_clkcmu_cmgp_bus + + - if: + properties: +compatible: + contains: +const: samsung,exynos850-cmu-core + +then: + properties: +clocks: + items: +- description: External reference clock (26 MHz) +- description: CMU_CORE bus clock (from CMU_TOP) +- description: CCI clock (from CMU_TOP) +- description: eMMC clock (from CMU_TOP) +- description: SSS clock (from CMU_TOP) + +clock-names: + items: +- const: oscclk +- const: dout_core_bus +- const: dout_core_cci +- const: dout_core_mmc_embd +- const: dout_core_sss + + - if: + properties: +compatible: + contains: +const: samsung,exynos850-cmu-dpu + +then:
[PATCH v2 01/13] dt-bindings: soc: samsung: Add Exynos USI
Add USI bindings documentation and header file. Those are taken from
Linux kernel [1,2], but the documentation was reworked a bit to only
describe the compatibles that will be supported in U-Boot soon.
[1] Documentation/devicetree/bindings/soc/samsung/exynos-usi.yaml
[2] include/dt-bindings/soc/samsung,exynos-usi.h
Signed-off-by: Sam Protsenko
---
Changes in v2:
- (none)
.../soc/samsung/exynos-usi.yaml | 162 ++
include/dt-bindings/soc/samsung,exynos-usi.h | 17 ++
2 files changed, 179 insertions(+)
create mode 100644 doc/device-tree-bindings/soc/samsung/exynos-usi.yaml
create mode 100644 include/dt-bindings/soc/samsung,exynos-usi.h
diff --git a/doc/device-tree-bindings/soc/samsung/exynos-usi.yaml
b/doc/device-tree-bindings/soc/samsung/exynos-usi.yaml
new file mode 100644
index ..8e6423f11568
--- /dev/null
+++ b/doc/device-tree-bindings/soc/samsung/exynos-usi.yaml
@@ -0,0 +1,162 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/samsung/exynos-usi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Samsung's Exynos USI (Universal Serial Interface)
+
+maintainers:
+ - Sam Protsenko
+
+description: |
+ USI IP-core provides selectable serial protocol (UART, SPI or High-Speed
I2C).
+ USI shares almost all internal circuits within each protocol, so only one
+ protocol can be chosen at a time. USI is modeled as a node with zero or more
+ child nodes, each representing a serial sub-node device. The mode setting
+ selects which particular function will be used.
+
+properties:
+ $nodename:
+pattern: "^usi@[0-9a-f]+$"
+
+ compatible:
+enum:
+ - samsung,exynos850-usi
+
+ reg: true
+
+ clocks: true
+
+ clock-names: true
+
+ ranges: true
+
+ "#address-cells":
+const: 1
+
+ "#size-cells":
+const: 1
+
+ samsung,sysreg:
+$ref: /schemas/types.yaml#/definitions/phandle-array
+items:
+ - items:
+ - description: phandle to System Register syscon node
+ - description: offset of SW_CONF register for this USI controller
+description:
+ Should be phandle/offset pair. The phandle to System Register syscon node
+ (for the same domain where this USI controller resides) and the offset
+ of SW_CONF register for this USI controller.
+
+ samsung,mode:
+$ref: /schemas/types.yaml#/definitions/uint32
+description:
+ Selects USI function (which serial protocol to use). Refer to
+ for valid USI mode values.
+
+ samsung,clkreq-on:
+type: boolean
+description:
+ Enable this property if underlying protocol requires the clock to be
+ continuously provided without automatic gating. As suggested by SoC
+ manual, it should be set in case of SPI/I2C slave, UART Rx and I2C
+ multi-master mode. Usually this property is needed if USI mode is set
+ to "UART".
+
+ This property is optional.
+
+patternProperties:
+ "^i2c@[0-9a-f]+$":
+$ref: /schemas/i2c/i2c-exynos5.yaml
+description: Child node describing underlying I2C
+
+ "^serial@[0-9a-f]+$":
+$ref: /schemas/serial/samsung_uart.yaml
+description: Child node describing underlying UART/serial
+
+ "^spi@[0-9a-f]+$":
+$ref: /schemas/spi/samsung,spi.yaml
+description: Child node describing underlying SPI
+
+required:
+ - compatible
+ - ranges
+ - "#address-cells"
+ - "#size-cells"
+ - samsung,sysreg
+ - samsung,mode
+
+if:
+ properties:
+compatible:
+ contains:
+enum:
+ - samsung,exynos850-usi
+
+then:
+ properties:
+reg:
+ maxItems: 1
+
+clocks:
+ items:
+- description: Bus (APB) clock
+- description: Operating clock for UART/SPI/I2C protocol
+
+clock-names:
+ items:
+- const: pclk
+- const: ipclk
+
+ required:
+- reg
+- clocks
+- clock-names
+
+else:
+ properties:
+reg: false
+clocks: false
+clock-names: false
+samsung,clkreq-on: false
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+
+usi0: usi@138200c0 {
+compatible = "samsung,exynos850-usi";
+reg = <0x138200c0 0x20>;
+samsung,sysreg = <_peri 0x1010>;
+samsung,mode = ;
+samsung,clkreq-on; /* needed for UART mode */
+#address-cells = <1>;
+#size-cells = <1>;
+ranges;
+clocks = <_peri 32>, <_peri 31>;
+clock-names = "pclk", "ipclk";
+
+serial_0: serial@1382 {
+compatible = "samsung,exynos850-uart";
+reg = <0x1382 0xc0>;
+interrupts = ;
+clocks = <_peri 32>, <_peri 31>;
+clock-names = "uart", "clk_uart_baud0";
+status = "disabled";
+};
+
+hsi2c_0: i2c@1382 {
+compatible = "samsung,exynosautov9-hsi2c";
+reg = <0x1382 0xc0>;
+interrupts = ;
+
[PATCH v2 02/13] dt-bindings: soc: samsung: Add Exynos PMU
Add bindings documentation for Exynos PMU hardware block. It was taken
from Linux kernel [1], but minimized and modified to reflect features
that will be actually supported in U-Boot soon. For example,
the "samsung,uart-debug-1" property is not available in Linux kernel
bindings and only present in U-Boot.
[1] Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml
Signed-off-by: Sam Protsenko
---
Changes in v2:
- (none)
.../soc/samsung/exynos-pmu.yaml | 85 +++
1 file changed, 85 insertions(+)
create mode 100644 doc/device-tree-bindings/soc/samsung/exynos-pmu.yaml
diff --git a/doc/device-tree-bindings/soc/samsung/exynos-pmu.yaml
b/doc/device-tree-bindings/soc/samsung/exynos-pmu.yaml
new file mode 100644
index ..c3e95c33b01d
--- /dev/null
+++ b/doc/device-tree-bindings/soc/samsung/exynos-pmu.yaml
@@ -0,0 +1,85 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/samsung/exynos-pmu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Samsung Exynos SoC series Power Management Unit (PMU)
+
+maintainers:
+ - Sam Protsenko
+
+description: |+
+ PMU block controls the power and operation states of Exynos SoC. It contains
+ registers for changing the state of next features::
+
+ - Local power control. Exynos SoCs have various power domains, and it's
+possible to turn them on and off independently, using corresponding
+registers in PMU block
+ - System-level power control. That allows putting the system into power-down
+modes (sleep) by turning off the power for most of the domains
+ - Miscellaneous PMU related features
+
+# Custom select to avoid matching all nodes with 'syscon'
+select:
+ properties:
+compatible:
+ contains:
+enum:
+ - samsung,exynos850-pmu
+ required:
+- compatible
+
+properties:
+ compatible:
+oneOf:
+ - items:
+ - enum:
+ - samsung,exynos850-pmu
+ - const: syscon
+
+ reg:
+maxItems: 1
+
+ samsung,uart-debug-1:
+type: boolean
+description:
+ Enable this property if AP UART lines (Application Processor UART) must
be
+ connected to UART_DEBUG_1 path in PMU block. That's usually needed when
+ the serial console is provided by uart1_pins. If this property is not
+ specified, the default behavior will be used (AP UART lines connected to
+ UART_DEBUG_0 path, which usually means uart0_pins are used for the serial
+ console).
+
+ syscon-poweroff:
+$ref: /schemas/power/reset/syscon-poweroff.yaml#
+type: object
+description:
+ Node for power off method
+
+ syscon-reboot:
+$ref: /schemas/power/reset/syscon-reboot.yaml#
+type: object
+description:
+ Node for reboot method
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+pmu_system_controller: system-controller@1186 {
+compatible = "samsung,exynos850-pmu", "syscon";
+reg = <0x1186 0x1>;
+
+reboot: syscon-reboot {
+compatible = "syscon-reboot";
+regmap = <_system_controller>;
+offset = <0x3a00>; /* SYSTEM_CONFIGURATION */
+mask = <0x2>; /* SWRESET_SYSTEM */
+value = <0x2>; /* reset value */
+};
+};
--
2.39.2
Re: [PATCH v2 1/2] efi_loader: auto-generate boot option for each blkio device
Hi Heinrich,
On Wed, 10 Jan 2024 at 22:53, Heinrich Schuchardt wrote:
>
> On 26.12.23 07:28, Masahisa Kojima wrote:
> > Current efibootmgr auto-generates the boot option for all
> > disks and partitions installing EFI_SIMPLE_FILE_SYSTEM_PROTOCOL,
> > while EDK II reference implementation auto-generates the boot option
> > for all devices installing EFI_BLOCK_IO_PROTOCOL with
> > eliminating logical partitions.
> >
> > This commit modifies the efibootmgr to get aligned to EDK II.
> >
> > Signed-off-by: Masahisa Kojima
> > ---
> > lib/efi_loader/efi_bootmgr.c | 94 +++-
> > 1 file changed, 71 insertions(+), 23 deletions(-)
> >
> > diff --git a/lib/efi_loader/efi_bootmgr.c b/lib/efi_loader/efi_bootmgr.c
> > index 56d97f2382..747f75ee82 100644
> > --- a/lib/efi_loader/efi_bootmgr.c
> > +++ b/lib/efi_loader/efi_bootmgr.c
> > @@ -560,6 +560,50 @@ err:
> > return ret;
> > }
> >
> > +/**
> > + * try_load_from_media() - load file from media
> > + *
> > + * @file_path: file path
> > + * @handle: pointer to handle for newly installed image
>
> Please, use the same description as in try_load_entry():
>
> on return handle for the newly installed image
OK.
>
> > + *
> > + * If @file_path contains a file name, load the file.
> > + * If @file_path does not have a file name, search the
> > architecture-specific
> > + * default file and load it.
> > + * TODO: If the FilePathList[0] device does not support
> > + * EFI_SIMPLE_FILE_SYSTEM_PROTOCOL but supports EFI_BLOCK_IO_PROTOCOL,
> > + * call EFI_BOOT_SERVICES.ConnectController()
> > + * TODO: FilePathList[0] device supports EFI_SIMPLE_FILE_SYSTEM_PROTOCOL
> > + * not based on EFI_BLOCK_IO_PROTOCOL
> > + *
> > + * Return: status code
> > + */
> > +static efi_status_t try_load_from_media(struct efi_device_path *file_path,
> > + efi_handle_t *handle)
>
> %s/handle/handle_img/
OK.
>
> or h_img
>
> > +{
> > + efi_handle_t h;
>
> %s/h/handle_blkdev/
OK.
>
> or h_blkdev
>
>
> > + efi_status_t ret = EFI_SUCCESS;
> > + struct efi_device_path *rem, *dp = NULL;
> > + struct efi_device_path *final_dp = file_path;
> > +
> > + h = efi_dp_find_obj(file_path, _block_io_guid, );
> > + if (h) {
> > + if (rem->type == DEVICE_PATH_TYPE_END) {
> > + /* no file name present, try default file */
> > + ret = check_disk_has_default_file(h->dev, );
>
> check_disk_has_default_file() does not only check for a default file
> path , i.e. EFI/BOOT/BOO.EFI, but will check for a given file
> path, if provided. In a later patch we should rename this function to
> something less misleading.
OK. I will include a renaming patch in this series.
>
> > + if (ret != EFI_SUCCESS)
> > + return ret;
> > +
> > + final_dp = dp;
> > + }
> > + }
> > +
> > + ret = EFI_CALL(efi_load_image(true, efi_root, final_dp, NULL, 0,
> > handle));
> > +
> > + efi_free_pool(dp);
> > +
> > + return ret;
> > +}
> > +
> > /**
> >* try_load_entry() - try to load image for boot option
> >*
> > @@ -594,7 +638,6 @@ static efi_status_t try_load_entry(u16 n, efi_handle_t
> > *handle,
> > }
> >
> > if (lo.attributes & LOAD_OPTION_ACTIVE) {
> > - struct efi_device_path *file_path;
> > u32 attributes;
> >
> > log_debug("trying to load \"%ls\" from %pD\n", lo.label,
> > @@ -611,10 +654,7 @@ static efi_status_t try_load_entry(u16 n, efi_handle_t
> > *handle,
> > else
> > ret = EFI_LOAD_ERROR;
> > } else {
> > - file_path = expand_media_path(lo.file_path);
> > - ret = EFI_CALL(efi_load_image(true, efi_root,
> > file_path,
> > - NULL, 0, handle));
> > - efi_free_pool(file_path);
> > + ret = try_load_from_media(lo.file_path, handle);
> > }
> > if (ret != EFI_SUCCESS) {
> > log_warning("Loading %ls '%ls' failed\n",
> > @@ -748,19 +788,19 @@ error:
> >* efi_bootmgr_enumerate_boot_option() - enumerate the possible bootable
> > media
>
> %s/efi_bootmgr_enumerate_boot_option/efi_bootmgr_enumerate_boot_options/
OK.
>
> >*
> >* @opt:pointer to the media boot option structure
> > - * @volume_handles: pointer to the efi handles
> > + * @handles: pointer to the efi handles
>
> %s/efi/EFI/
>
> "pointer to the efi handles" could be handles for anything.
>
> %s/pointer to the efi handles/pointer to block device handles/
OK.
>
> We should move the call to LocateBufferHandle into this function as the
> caller does not use handles.
But no_handles is required in the
caller(efi_bootmgr_update_media_device_boot_option)
to allocate an opt array.
opt =
[PATCH v2 00/13] arm: exynos: Add E850-96 board
Add Exynos850 SoC and WinLink's E850-96 board support. A short overview
of series additions and modifications:
* USI driver: configures UART block
* PMU driver: connects AP UART lines to uart1 pins)
* Exynos850 clock driver: generates UART clocks
* Exynos850 pinctrl driver: mux UART pins
* serial_s5p: UART driver
* Exynos850 SoC: dtsi files and MMU maps
* E850-96 board: dts files, defconfig, board file and doc
Most of the code was borrowed from mainline Linux kernel (where this
board is already enabled) and adapted for U-Boot. Preliminary
preparation for this series includes next patches / series (already
merged):
* commit 585a2aaac2ac ("arm: exynos: Include missing CPU header in
soc.c")
* commit c9ab9f30c8e4 ("arm: exynos: Include missing CPU header in
gpio.h")
* commit 11bd2787deff ("watchdog: s5p_wdt: Include missing CPU
header")
* commit 08cfa971a717 ("exynos: Avoid duplicate reset_cpu with
SYSRESET enabled")
* commit f655090901dc ("clk: exynos: Add header guard for clk-pll.h")
* commit 2227f4c0afed ("serial: s5p: Fix clk_get_by_index() error code
check")
* commit a0615ffc99a5 ("serial: s5p: Remove common.h inclusion")
* commit 5ad21de6bae0 ("serial: s5p: Use livetree API to get "id"
property")
* commit e79f630dbf67 ("serial: s5p: Use named constants for register
values")
* commit a627f2802a71 ("serial: s5p: Improve coding style")
* commit 33e7ca5a9b6a ("serial: s5p: Use dev_read_addr_ptr() to get
base address")
* commit 6219b47c4d91 ("board: samsung: Fix SYS_CONFIG_NAME configs in
axy17lte Kconfig")
* commit 470682ace1e0 ("configs: Remove unneeded SYS_CONFIG_NAME from
a*y17lte defconfigs")
and series [1]. For more detailed description please see the board
documentation (added in PATCH #12) and corresponding commit messages.
Changes in v2:
- PATCH 4: Removed unnecessary mode param
- PATCH 4: Removed usi->dev and used priv data instead
- PATCH 4: Used .of_plat_data callback for dts parsing
- PATCH 7: Fixed Thomas Abraham e-mail
- PATCH 9: Fixed incorrect driver description (comment)
- Collected Reviewed-by tags
- Rebased on top of most recent U-Boot/master
[1] https://lists.denx.de/pipermail/u-boot/2023-November/539033.html
Sam Protsenko (13):
dt-bindings: soc: samsung: Add Exynos USI
dt-bindings: soc: samsung: Add Exynos PMU
dt-bindings: clock: Add Exynos850 clock controller
soc: samsung: Add Exynos USI driver
soc: samsung: Add Exynos PMU driver
clk: exynos: Move pll code into clk-exynos7420
clk: exynos: Add Samsung clock framework
clk: exynos: Add Exynos850 clock driver
pinctrl: exynos: Add pinctrl support for Exynos850
serial: s5p: Add Exynos850 compatible
arm: exynos: Add Exynos850 SoC support
board: samsung: Add support for E850-96 board
MAINTAINERS: Add new Samsung subsystems
MAINTAINERS | 25 +
arch/arm/dts/Makefile |1 +
arch/arm/dts/exynos-pinctrl.h | 79 +
arch/arm/dts/exynos850-e850-96-u-boot.dtsi| 37 +
arch/arm/dts/exynos850-e850-96.dts| 273
arch/arm/dts/exynos850-pinctrl.dtsi | 663 +
arch/arm/dts/exynos850.dtsi | 809 +++
arch/arm/mach-exynos/Kconfig | 28 +-
arch/arm/mach-exynos/mmu-arm64.c | 34 +
board/samsung/e850-96/Kconfig | 16 +
board/samsung/e850-96/MAINTAINERS |9 +
board/samsung/e850-96/Makefile|6 +
board/samsung/e850-96/e850-96.c | 22 +
configs/e850-96_defconfig | 21 +
doc/board/samsung/e850-96.rst | 87 ++
.../img/exynos850-boot-architecture.svg | 1283 +
doc/board/samsung/index.rst |1 +
.../clock/samsung,exynos850-clock.yaml| 307
.../soc/samsung/exynos-pmu.yaml | 85 ++
.../soc/samsung/exynos-usi.yaml | 162 +++
drivers/clk/exynos/Kconfig|7 +
drivers/clk/exynos/Makefile | 11 +-
drivers/clk/exynos/clk-exynos7420.c | 25 +-
drivers/clk/exynos/clk-exynos850.c| 189 +++
drivers/clk/exynos/clk-pll.c | 167 ++-
drivers/clk/exynos/clk-pll.h | 16 +-
drivers/clk/exynos/clk.c | 121 ++
drivers/clk/exynos/clk.h | 228 +++
drivers/pinctrl/exynos/Kconfig|8 +
drivers/pinctrl/exynos/Makefile |1 +
drivers/pinctrl/exynos/pinctrl-exynos850.c| 125 ++
drivers/serial/serial_s5p.c |1 +
drivers/soc/Kconfig |1 +
[PATCH v2] xilinx: r5: Include the sys_r5_proto.h header for future use
Currently when using "W=1" with xilinx_zynqmp_r5_defconfig, getting below warnings. cc1.real: warning: ./arch/arm/mach-zynqmp-r5/include: No such file or directory [-Wmissing-include-dirs] Fix W=1 missing-include-dirs warnings by including the headers and sys_r5_proto.h file which can be used. Signed-off-by: Venkatesh Yadav Abbarapu --- Changes in v2: - Fixed the copyright and other minor syntax issues. --- arch/arm/mach-zynqmp-r5/include/mach/sys_r5_proto.h | 5 + 1 file changed, 5 insertions(+) create mode 100644 arch/arm/mach-zynqmp-r5/include/mach/sys_r5_proto.h diff --git a/arch/arm/mach-zynqmp-r5/include/mach/sys_r5_proto.h b/arch/arm/mach-zynqmp-r5/include/mach/sys_r5_proto.h new file mode 100644 index 00..0f7a47bf24 --- /dev/null +++ b/arch/arm/mach-zynqmp-r5/include/mach/sys_r5_proto.h @@ -0,0 +1,5 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +/* + * Copyright (C) 2024, Advanced Micro Devices, Inc. + * Michal Simek + */ -- 2.25.1
Re: [PATCH 07/13] clk: exynos: Add Samsung clock framework
On Tue, Dec 19, 2023 at 5:38 AM Chanho Park wrote: > [snip] > > diff --git a/drivers/clk/exynos/clk-pll.c b/drivers/clk/exynos/clk-pll.c > > new file mode 100644 > > index ..9e496ff83aaf > > --- /dev/null > > +++ b/drivers/clk/exynos/clk-pll.c > > @@ -0,0 +1,167 @@ > > +// SPDX-License-Identifier: GPL-2.0+ > > +/* > > + * Copyright (C) 2016 Samsung Electronics > > + * Copyright (C) 2023 Linaro Ltd. > > + * > > + * Authors: > > + * Thomas Abraham > > Need to correct Thomas's email to samsung.com if you want to keep his > original credit even though his e-mail was already stale since he left the > company. > Thanks for the review, will do in v2! [snip] > > + * > > + * Authors: > > + * Thomas Abraham > > Ditto. > > Othewise, > Reviewed-by: Chanho Park >
Re: [PATCH 04/13] soc: samsung: Add Exynos USI driver
On Wed, Dec 27, 2023 at 11:49 AM Simon Glass wrote:
>
> Hi Sam,
>
[snip]
>
> Just a few nits here
>
> Reviewed-by: Simon Glass
>
[snip]
> > +
> > +struct exynos_usi {
> > + struct udevice *dev;
>
> Can we drop this? It doesn't seem very useful and we try to avoid
> having bidirectional pointers. since it is possible to get the 'priv'
> pointer from the device.
>
Sure. I tried to keep the driver as close as possible to Linux
kernel's version, where I borrowed it from. But if it's the current
preference in U-Boot, I'll fix this in v2.
[snip]
> > +static int exynos_usi_parse_dt(struct exynos_usi *usi)
>
> Use of_to_plat() method?
>
Will do in v2. Thanks for the review!
[snip]
Re: [PATCH v2 2/2] efi_loader: support fmp versioning for multi bank update
On Wed, 10 Jan 2024 at 18:10, Ilias Apalodimas
wrote:
>
> On Wed, 10 Jan 2024 at 02:53, Masahisa Kojima
> wrote:
> >
> > On Tue, 9 Jan 2024 at 22:02, Ilias Apalodimas
> > wrote:
> > >
> > > On Tue, 9 Jan 2024 at 03:00, Masahisa Kojima
> > > wrote:
> > > >
> > > > Hi Ilias,
> > > >
> > > > On Thu, 28 Dec 2023 at 00:14, Ilias Apalodimas
> > > > wrote:
> > > > >
> > > > > Kojima-san
> > > > >
> > > > > On Thu, Dec 21, 2023 at 06:52:58PM +0900, Masahisa Kojima wrote:
> > > > > > This commit stores the firmware version into the array
> > > > > > of fmp_state structure to support the fmp versioning
> > > > > > for multi bank update. The index of the array is identified
> > > > > > by the bank index.
> > > > >
> > > > > Why do we all of them? Can't we just always store/use the version of
> > > > > the active
> > > > > bank?
> > > >
> > > > Sorry for the late reply.
> > > > When the capsule update is reverted, the active bank is back to the
> > > > previous active bank.
> > > > So I think versions for all banks should be stored.
> > >
> > > But even in that case, the active bank should point to the correct
> > > version when the ESRT tables are generated. Wouldn't it be simpler to
> > > just set the FmpState variable accordingly when that happens?
> >
> > The fw_version in FmpState variable comes from UEFI Capsule Header and
> > FmpState variable is set when the UEFI capsule update is performed.
> > If we only store the fw_version of the active bank, the fw_version of
> > the previous active bank is overwritten. When the capsule is reverted,
> > we can not get the fw_version of the previous active bank.
> >
> > Thanks,
> > Masahisa Kojima
>
> Ah yes, that makes sense. In that case, the patch looks fine, apart
> from the return value of the getvariable call which is never checked
>
>
> > > > > >
> > > > > > image_type_id = efi_firmware_get_image_type_id(image_index);
> > > > > > if (!image_type_id)
> > > > > > @@ -372,19 +392,38 @@ efi_status_t
> > > > > > efi_firmware_set_fmp_state_var(struct fmp_state *state, u8 image_in
> > > > > > efi_create_indexed_name(varname, sizeof(varname), "FmpState",
> > > > > > image_index);
> > > > > >
> > > > > > + if (IS_ENABLED(CONFIG_FWU_MULTI_BANK_UPDATE)) {
> > > > > > + ret = fwu_plat_get_update_index(_bank);
> > > > > > + if (ret)
> > > > > > + return EFI_INVALID_PARAMETER;
> > > > > > +
> > > > > > + num_banks = CONFIG_FWU_NUM_BANKS;
> > > > > > + }
> > > > > > +
> > > > > > + size = num_banks * sizeof(*var_state);
> > > > > > + var_state = calloc(1, size);
> > > > > > + if (!var_state)
> > > > > > + return EFI_OUT_OF_RESOURCES;
> > > > > > +
> > > > > > + ret = efi_get_variable_int(varname, image_type_id, NULL,
> > > > > > ,
> > > > > > +var_state, NULL);
> > > > > > +
>
> We should be checking the return value here.
I will fix it.
Thanks,
Masahisa Kojima
>
> > > > > > /*
> > > > > >* Only the fw_version is set here.
> > > > > >* lowest_supported_version in FmpState variable is ignored
> > > > > > since
> > > > > >* it can be tampered if the file based EFI variable storage
> > > > > > is used.
> > > > > >*/
> > > > > > - var_state.fw_version = state->fw_version;
> > > > > > + var_state[update_bank].fw_version = state->fw_version;
> > > > > >
> > > > > > + size = num_banks * sizeof(*var_state);
> > > > > > ret = efi_set_variable_int(varname, image_type_id,
> > > > > > EFI_VARIABLE_READ_ONLY |
> > > > > > EFI_VARIABLE_NON_VOLATILE |
> > > > > > EFI_VARIABLE_BOOTSERVICE_ACCESS |
> > > > > > EFI_VARIABLE_RUNTIME_ACCESS,
> > > > > > -sizeof(var_state), _state,
> > > > > > false);
> > > > > > +size, var_state, false);
> > > > > > +
> > > > > > + free(var_state);
> > > > > >
> > > > > > return ret;
> > > > > > }
> > > > > > --
> > > > > > 2.34.1
> > > > > >
>
> Thanks
> /Ilias
Re: [PATCH 04/13] soc: samsung: Add Exynos USI driver
On Wed, Dec 27, 2023 at 3:11 AM Minkyu Kang wrote:
>
> Hi
>
>
> 2023년 12월 13일 (수) 12:42, Sam Protsenko 님이 작성:
>>
[snip]
>> +
>> +/**
>> + * exynos_usi_set_sw_conf - Set USI block configuration mode
>> + * @usi: USI driver object
>> + * @mode: Mode index
>> + *
>> + * Select underlying serial protocol (UART/SPI/I2C) in USI IP-core.
>> + *
>> + * Return: 0 on success, or negative error code on failure.
>> + */
>> +static int exynos_usi_set_sw_conf(struct exynos_usi *usi, size_t mode)
>
>
> The value of mode is same as usi->mode, but is there a reason to pass it as a
> parameter?
>
>>
>> +{
>> + unsigned int val;
>> + int ret;
>> +
>> + if (mode < usi->data->min_mode || mode > usi->data->max_mode)
>> + return -EINVAL;
>> +
>> + val = exynos_usi_modes[mode].val;
>> + ret = regmap_update_bits(usi->sysreg, usi->sw_conf,
>> +usi->data->sw_conf_mask, val);
>> + if (ret)
>> + return ret;
>> +
>> + usi->mode = mode;
>
>
> This will obviously be the same value always.
>
Thanks for the review! Yes, you are right. This code was copy-pasted
from Linux kernel. So at the time I thought it was better to leave it
as is, for backporting reasons. But now that I look at it, this won't
be too helpful. So I'll get rid of it in v2.
[snip]
Re: [PATCH 07/13] clk: exynos: Add Samsung clock framework
On Wed, Dec 27, 2023 at 3:12 AM Minkyu Kang wrote:
>
> Hi,
>
>
> 2023년 12월 13일 (수) 12:27, Sam Protsenko 님이 작성:
>>
>> Heavily based on Linux kernel Samsung clock framework, with some changes
>> to accommodate the differences in U-Boot CCF implementation. It's also
>> quite minimal as compared to the Linux version.
>>
>> Signed-off-by: Sam Protsenko
>> ---
[snip]
>> diff --git a/drivers/clk/exynos/clk-pll.h b/drivers/clk/exynos/clk-pll.h
>> new file mode 100644
>> index ..3b477369aeb8
>> --- /dev/null
>> +++ b/drivers/clk/exynos/clk-pll.h
>> @@ -0,0 +1,23 @@
>> +/* SPDX-License-Identifier: GPL-2.0+ */
>> +/*
>> + * Copyright (C) 2016 Samsung Electronics
>> + * Copyright (C) 2023 Linaro Ltd.
>> + *
>> + * Authors:
>> + * Thomas Abraham
>> + * Sam Protsenko
>> + *
>> + * Common Clock Framework support for all PLL's in Samsung platforms.
>> + */
>> +
>> +#ifndef __EXYNOS_CLK_PLL_H
>> +#define __EXYNOS_CLK_PLL_H
>> +
>> +#include
>> +
>> +enum samsung_pll_type {
>> + pll_0822x,
>> + pll_0831x,
>
>
> why don't you modify to uppercase?
>
That code was basically copied over from Linux kernel (from
drivers/clk/samsung/clk-pll.h file). I'm trying to keep it as close to
the original as possible, to ease any possible backporting in future.
Although kernel coding style indeed tends to stick to uppercase in
enums, in my opinion the backporting/compatibility concern outweighs
the style one. Hope it's ok with you if I keep it as is in v2?
>>
>> +};
>> +
>> +#endif /* __EXYNOS_CLK_PLL_H */
>> diff --git a/drivers/clk/exynos/clk.c b/drivers/clk/exynos/clk.c
>> new file mode 100644
>> index ..430767f072d8
>> --- /dev/null
>> +++ b/drivers/clk/exynos/clk.c
>> @@ -0,0 +1,121 @@
>> +// SPDX-License-Identifier: GPL-2.0-only
>> +/*
>> + * Copyright (C) 2023 Linaro Ltd.
>> + * Sam Protsenko
>> + *
>> + * This file includes utility functions to register clocks to common
>> + * clock framework for Samsung platforms.
>> + */
>> +
>> +#include
>> +#include "clk.h"
>> +
>> +void samsung_clk_register_mux(void __iomem *base,
>> + const struct samsung_mux_clock *clk_list,
>> + unsigned int nr_clk)
>> +{
>> + unsigned int cnt;
>> +
>> + for (cnt = 0; cnt < nr_clk; cnt++) {
>> + struct clk *clk;
>> + const struct samsung_mux_clock *m;
>
>
> wouldn't it be better if use a more meaningful name like mux?
>
My reasoning for choosing the name that short in this case was because
of super-short scope (3 lines of code), and OTOH this variable is
massively used during that scope, like this:
clk = clk_register_mux(NULL, m->name, m->parent_names,
m->num_parents, m->flags, base + m->offset, m->shift,
m->width, m->mux_flags);
Hope it makes sense. If you still prefer 'mux', please let me know and
I'll use it in v2.
>>
>> +
>> + m = _list[cnt];
>
>
> Is there any possibility that the value is null or wrong (e.g. overflow)
>
I decided to keep it with no error handling because I didn't feel like
it would bring much value. Because this code is supposed to be used
via samsung_cmu_register_one(), and the CMU structure passed to that
function is usually going to be defined in this idiomatic way (as can
be seen in clk-exynos850.c driver):
static const struct samsung_clk_group top_cmu_clks[] = {
{ S_CLK_PLL, top_pure_pll_clks, ARRAY_SIZE(top_pure_pll_clks) },
{ S_CLK_MUX, top_pure_mux_clks, ARRAY_SIZE(top_pure_mux_clks) },
...
and the corresponding clocks structures are also defined like this:
static const struct samsung_mux_clock top_pure_mux_clks[] = {
MUX(CLK_MOUT_SHARED0_PLL, "mout_shared0_pll",
mout_shared0_pll_p,
PLL_CON0_PLL_SHARED0, 4, 1),
MUX(CLK_MOUT_SHARED1_PLL, "mout_shared1_pll",
mout_shared1_pll_p,
PLL_CON0_PLL_SHARED1, 4, 1),
...
I'd say the odds for messing this up are next to none, because of
using ARRAY_SIZE() and clock macros like MUX(). Especially because the
example is already set in clk-exynos850 driver and I assume everybody
would just use it as a template, which usually happens. So after
exploring the alternative approach (with added error handling) I felt
it was unjustifiable cluttered comparing to the more concise version
present in this series, at least in this particular code. Also, that
code resembles its kernel counterpart, where the clock pointer isn't
checked as well.
I'm not even sure how to handle possible errors here, as it's the
critical platform code. So maybe letting it just crash is not a bad
decision too. But if you have a strong opinion on this one, please let
me know how you would like me to handle that.
>> + clk = clk_register_mux(NULL, m->name, m->parent_names,
>> + m->num_parents, m->flags, base + m->offset, m->shift,
>> +
Re: [PATCH 09/13] pinctrl: exynos: Add pinctrl support for Exynos850
On Tue, Dec 19, 2023 at 5:32 AM Chanho Park wrote: > > > -Original Message- > > From: U-Boot On Behalf Of Sam Protsenko > > Sent: Wednesday, December 13, 2023 12:17 PM > > To: Minkyu Kang ; Tom Rini ; > > Lukasz Majewski ; Sean Anderson > > Cc: Simon Glass ; Heinrich Schuchardt > > ; u-boot@lists.denx.de > > Subject: [PATCH 09/13] pinctrl: exynos: Add pinctrl support for Exynos850 > > > > Add pinctrl support for Exynos850 SoC. It was mostly extracted from > > corresponding Linux kernel code [1]. Power down modes and external > > interrupt data were removed while converting the code for U-Boot, but > > everything else was kept almost unchanged. > > > > [1] drivers/pinctrl/samsung/pinctrl-exynos-arm64.c > > > > Signed-off-by: Sam Protsenko > > --- > > drivers/pinctrl/exynos/Kconfig | 8 ++ > > drivers/pinctrl/exynos/Makefile| 1 + > > drivers/pinctrl/exynos/pinctrl-exynos850.c | 125 + > > 3 files changed, 134 insertions(+) > > create mode 100644 drivers/pinctrl/exynos/pinctrl-exynos850.c > > > > diff --git a/drivers/pinctrl/exynos/Kconfig > > b/drivers/pinctrl/exynos/Kconfig > > index a60f49869b45..1b7fb62bc4ba 100644 > > --- a/drivers/pinctrl/exynos/Kconfig > > +++ b/drivers/pinctrl/exynos/Kconfig > > @@ -16,3 +16,11 @@ config PINCTRL_EXYNOS78x0 > > help > > Support pin multiplexing and pin configuration control on > > Samsung's Exynos78x0 SoC. > > + > > +config PINCTRL_EXYNOS850 > > + bool "Samsung Exynos850 pinctrl driver" > > + depends on ARCH_EXYNOS && PINCTRL_FULL > > + select PINCTRL_EXYNOS > > + help > > + Support pin multiplexing and pin configuration control on > > + Samsung's Exynos850 SoC. > > diff --git a/drivers/pinctrl/exynos/Makefile > > b/drivers/pinctrl/exynos/Makefile > > index 07db970ca942..3abe1226eb74 100644 > > --- a/drivers/pinctrl/exynos/Makefile > > +++ b/drivers/pinctrl/exynos/Makefile > > @@ -6,3 +6,4 @@ > > obj-$(CONFIG_PINCTRL_EXYNOS) += pinctrl-exynos.o > > obj-$(CONFIG_PINCTRL_EXYNOS7420) += pinctrl-exynos7420.o > > obj-$(CONFIG_PINCTRL_EXYNOS78x0) += pinctrl-exynos78x0.o > > +obj-$(CONFIG_PINCTRL_EXYNOS850) += pinctrl-exynos850.o > > diff --git a/drivers/pinctrl/exynos/pinctrl-exynos850.c > > b/drivers/pinctrl/exynos/pinctrl-exynos850.c > > new file mode 100644 > > index ..2445dd752ea8 > > --- /dev/null > > +++ b/drivers/pinctrl/exynos/pinctrl-exynos850.c > > @@ -0,0 +1,125 @@ > > +// SPDX-License-Identifier: GPL-2.0 > > +/* > > + * Copyright (c) 2023 Linaro Ltd. > > + * Author: Sam Protsenko > > + * > > + * Samsung Exynos USI driver (Universal Serial Interface). > > Typo. It should be a subject for the pinctrl driver. > Nice catch! Will be fixed in v2. > Otherwise, > Reviewed-by: Chanho Park Thanks for the review! >
Re: [PATCH] arm64: xilinx: Move address/size-cells to proper locations
On 10/01/2024 14:35, Michal Simek wrote: > Move cells to board dtsi files from generic zynqmp.dtsi. Changes are > related to qspi, spi, nand, i2c and ethernet nodes. > > All errors are generated when dtbs are compiled with W=1. > I don't see any errors on some other platforms, like Samsung. Isn't the actual problem that you do not disable the nodes (I2C, SPI etc) in DTSI? Best regards, Krzysztof
[PATCH] riscv: qemu: enable booting on a second virtio device
QEMU RISC-V supports multiple virtio devices, but only tries to boot to the first one. Enable support for a second virtio device, that is useful for instance to boot on a disk image + an installer. Ideally that should be made dynamic, but that's a first step. Signed-off-by: Aurelien Jarno --- include/configs/qemu-riscv.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/configs/qemu-riscv.h b/include/configs/qemu-riscv.h index 584559cfa3..2f594bfcfd 100644 --- a/include/configs/qemu-riscv.h +++ b/include/configs/qemu-riscv.h @@ -23,6 +23,7 @@ #define BOOT_TARGET_DEVICES(func) \ func(VIRTIO, virtio, 0) \ + func(VIRTIO, virtio, 1) \ func(SCSI, scsi, 0) \ func(DHCP, dhcp, na) -- 2.42.0
[PATCH] board: starfive: handle compatible property in dynamic DT configuration
The difference between the StarFive VisionFive 2 1.2A and 1.3B boards is
handled dynamically by looking at the PCB version in the EEPROM in order
to have a single u-boot version for both versions of the board. While
the "model" property is correctly handled, the "compatible" one is
always the the one of version 1.3b.
This patch add support for dynamically configuring that property.
Fixes: 9b7060bd15e7 ("riscv: dts: jh7110: Combine the board device tree files
of 1.2A and 1.3B")
Signed-off-by: Aurelien Jarno
---
board/starfive/visionfive2/spl.c | 4
1 file changed, 4 insertions(+)
diff --git a/board/starfive/visionfive2/spl.c b/board/starfive/visionfive2/spl.c
index 336f0cdfc9..911add429d 100644
--- a/board/starfive/visionfive2/spl.c
+++ b/board/starfive/visionfive2/spl.c
@@ -61,11 +61,13 @@ static const struct starfive_vf2_pro starfive_verb[] = {
void spl_fdt_fixup_version_a(void *fdt)
{
+ static const char compat[] =
"starfive,visionfive-2-v1.2a\0starfive,jh7110";
u32 phandle;
u8 i;
int offset;
int ret;
+ fdt_setprop(fdt, fdt_path_offset(fdt, "/"), "compatible", compat,
sizeof(compat));
fdt_setprop_string(fdt, fdt_path_offset(fdt, "/"), "model",
"StarFive VisionFive 2 v1.2A");
@@ -106,11 +108,13 @@ void spl_fdt_fixup_version_a(void *fdt)
void spl_fdt_fixup_version_b(void *fdt)
{
+ static const char compat[] =
"starfive,visionfive-2-v1.3b\0starfive,jh7110";
u32 phandle;
u8 i;
int offset;
int ret;
+ fdt_setprop(fdt, fdt_path_offset(fdt, "/"), "compatible", compat,
sizeof(compat));
fdt_setprop_string(fdt, fdt_path_offset(fdt, "/"), "model",
"StarFive VisionFive 2 v1.3B");
--
2.42.0
Re: [PATCH v2] boot: add support for button commands
On 10/01/2024 18:08, Dragan Simic wrote: > On 2024-01-09 12:51, Caleb Connolly wrote: >> With the relatively new button API in U-Boot, it's now much easier to >> model the common usecase of mapping arbitrary actions to different >> buttons during boot - for example entering fastboot mode, setting some >> additional kernel cmdline arguments, or booting with a custom recovery >> ramdisk, to name a few. >> >> Historically, this functionality has been implemented in board code, >> making it fixed for a given U-Boot binary and requiring the code be >> duplicated and modified for every board. >> >> Implement a generic abstraction to run an arbitrary command during boot >> when a specific button is pressed. The button -> command mapping is >> configured via environment variables with the following format: >> >> button_cmd_N_name= >> button_cmd_N= >> >> Where N is the mapping number starting from 0. For example: >> >> button_cmd_0_name=vol_down >> button_cmd_0=fastboot usb 0 >> >> This will cause the device to enter fastboot mode if volume down is held >> during boot. > > This is simply awesome, but I see one possible issue -- the need to have > proper environment variables defined for a particular board or device, > to make the buttons work as expected. Obviously, those environment > variables can be absent or can become missing for numerous reasons. Is CFG_EXTRA_ENV_SETTINGS not persistent enough? > > I think that we should have an additional mechanism in place that > defines the buttons and the associated commands even if no environment > variables are found. Like a set of fallback defaults for a particular > board or device, built into the U-Boot image. For example, Rockchip > boards have those defaults pretty well defined. A programmatic API for register button/cmd mapping from board_late_init() (for example) sounds sensible to me. Is this really an issue that invalidates the implementation proposed here though? It feels much more like a nice-to-have addition that maybe we could leave out for now? It also has a MUCH wider scope imo - should board override env or vice versa? What about triggering default AND custom actions for one button press? What if a board wants to register a callback function instead of running a command?) - these are questions I don't want to answer with this patch. > >> After we enter the cli loop the button commands are no longer valid, >> this allows the buttons to additionally be used for navigating a boot >> menu. >> >> Tested-by: Svyatoslav Ryhel # Tegra30 >> Signed-off-by: Caleb Connolly >> --- >> Changes since v1: >> * make get_button_cmd() static. >> * use #if IS_ENABLED(CONFIG_BUTTON_CMD) instead of #ifdef >> CONFIG_BUTTON_CMD. >> * Kconfig fixes >> --- >> boot/Kconfig | 15 +++ >> common/Makefile | 1 + >> common/button_cmd.c | 83 +++ >> common/main.c | 3 ++ >> doc/usage/environment.rst | 4 ++ >> include/button.h | 9 + >> 6 files changed, 115 insertions(+) >> create mode 100644 common/button_cmd.c >> >> diff --git a/boot/Kconfig b/boot/Kconfig >> index fbc49c5bca47..882835731ea9 100644 >> --- a/boot/Kconfig >> +++ b/boot/Kconfig >> @@ -20,6 +20,21 @@ config TIMESTAMP >> loaded that does not, the message 'Wrong FIT format: no timestamp' >> is shown. >> >> +config BUTTON_CMD >> + bool "Support for running a command if a button is held during boot" >> + depends on CMDLINE >> + depends on BUTTON >> + help >> + For many embedded devices it's useful to enter a special >> flashing mode >> + such as fastboot mode when a button is held during boot. This >> option >> + allows arbitrary commands to be assigned to specific buttons. >> These will >> + be run after "preboot" if the button is held. Configuration is >> done via >> + the environment variables "button_cmd_N_name" and >> "button_cmd_N" where n is >> + the button number (starting from 0). e.g: >> + >> + "button_cmd_0_name=vol_down" >> + "button_cmd_0=fastboot usb 0" >> + >> menuconfig FIT >> bool "Flattened Image Tree (FIT)" >> select HASH >> diff --git a/common/Makefile b/common/Makefile >> index cdeadf72026c..53105a6ce12a 100644 >> --- a/common/Makefile >> +++ b/common/Makefile >> @@ -10,6 +10,7 @@ obj-y += main.o >> obj-y += exports.o >> obj-$(CONFIG_HUSH_PARSER) += cli_hush.o >> obj-$(CONFIG_AUTOBOOT) += autoboot.o >> +obj-$(CONFIG_BUTTON_CMD) += button_cmd.o >> >> # # boards >> obj-y += board_f.o >> diff --git a/common/button_cmd.c b/common/button_cmd.c >> new file mode 100644 >> index ..b6a8434d6f29 >> --- /dev/null >> +++ b/common/button_cmd.c >> @@ -0,0 +1,83 @@ >> +// SPDX-License-Identifier: GPL-2.0+ >> +/* >> + * Copyright (c) 2023 Linaro Ltd. >> + * Author: Caleb Connolly >> + */ >> + >> +#include >> +#include >> +#include >> +#include >> +#include >> + >> +/* Some sane limit "just
Re: [PATCH v3] clk: meson: add Hardware Clock measure driver
On 10/01/2024 16:41, Sean Anderson wrote:
On 1/10/24 04:23, Neil Armstrong wrote:
Hi Sean,
On 18/12/2023 10:47, Neil Armstrong via groups.io wrote:
Amlogic SoCs embeds an hardware clock measure block, port it
from Linux and implement it as a UCLK_CLK with only the dump
op and fail-only xlate.
Based on the Linux driver introduced in [1].
[1] commit 2b45ebef39a2 ("soc: amlogic: Add Meson Clock Measure driver").
Reviewed-by: Sean Anderson
Signed-off-by: Neil Armstrong
Should I take this via the amlogic tree ?
If you like.
I will be doing a PR sometime before the merge window ends.
If you're making a PR, I won't except for this, so please take it then!
Neil
--Sean
[PATCH 5/5] mtd: Make CONFIG_MTD be the gate symbol for the menu
The help for CONFIG_MTD explains that it needs to be enabled for various things like NAND, etc to be available. It however then doesn't enforce this dependency and so if you have none of these systems present you still need to disable a number of options. Fix this by making places that select/imply one type of flash, but did not do the same, also do this for "MTD". Make boards which hadn't been enabling MTD already but need it now, do so. In a few places, disable CONFIG_CMD_MTDPARTS as it wasn't previously enabled but was now being implied. Signed-off-by: Tom Rini --- arch/Kconfig | 2 ++ arch/arm/Kconfig | 11 ++- arch/arm/mach-at91/Kconfig | 3 +++ arch/arm/mach-imx/mx6/Kconfig| 3 +++ arch/arm/mach-omap2/am33xx/Kconfig | 1 + arch/arm/mach-tegra/Kconfig | 1 + arch/microblaze/Kconfig | 1 + arch/mips/Kconfig| 2 ++ board/microchip/mpfs_icicle/Kconfig | 1 + configs/3c120_defconfig | 1 + configs/A20-OLinuXino-Lime2-eMMC_defconfig | 1 + configs/M5208EVBE_defconfig | 1 + configs/M5235EVB_Flash32_defconfig | 1 + configs/M5235EVB_defconfig | 1 + configs/M5249EVB_defconfig | 1 + configs/M5253DEMO_defconfig | 1 + configs/M5272C3_defconfig| 1 + configs/M5275EVB_defconfig | 1 + configs/M5282EVB_defconfig | 1 + configs/M53017EVB_defconfig | 1 + configs/MPC837XERDB_defconfig| 1 + configs/MPC8548CDS_36BIT_defconfig | 1 + configs/MPC8548CDS_defconfig | 1 + configs/MPC8548CDS_legacy_defconfig | 1 + configs/am43xx_evm_defconfig | 1 - configs/am43xx_evm_rtconly_defconfig | 1 - configs/am43xx_evm_usbhost_boot_defconfig| 1 - configs/am43xx_hs_evm_defconfig | 1 - configs/am62ax_evm_r5_defconfig | 1 + configs/am62x_evm_a53_defconfig | 1 + configs/am62x_evm_r5_defconfig | 1 + configs/am64x_evm_a53_defconfig | 1 + configs/am64x_evm_r5_defconfig | 1 + configs/am65x_evm_r5_defconfig | 1 + configs/amcore_defconfig | 1 + configs/arbel_evb_defconfig | 1 + configs/arndale_defconfig| 1 - configs/astro_mcf5373l_defconfig | 1 + configs/axm_defconfig| 1 - configs/bitmain_antminer_s9_defconfig| 1 - configs/chromebit_mickey_defconfig | 1 - configs/chromebook_jerry_defconfig | 1 - configs/chromebook_minnie_defconfig | 1 - configs/chromebook_speedy_defconfig | 1 - configs/clearfog_defconfig | 1 - configs/clearfog_sata_defconfig | 1 - configs/clearfog_spi_defconfig | 1 - configs/cobra5272_defconfig | 1 + configs/colibri_t20_defconfig| 1 - configs/comtrend_ct5361_ram_defconfig| 1 + configs/comtrend_wap5813n_ram_defconfig | 1 + configs/corstone1000_defconfig | 1 + configs/crs305-1g-4s-bit_defconfig | 1 - configs/crs305-1g-4s_defconfig | 1 - configs/crs326-24g-2s-bit_defconfig | 1 - configs/crs326-24g-2s_defconfig | 1 - configs/crs328-4c-20s-4s-bit_defconfig | 1 - configs/crs328-4c-20s-4s_defconfig | 1 - configs/d2net_v2_defconfig | 1 + configs/db-88f6820-amc_defconfig | 1 - configs/db-88f6820-amc_nand_defconfig| 1 - configs/db-mv784mp-gp_defconfig | 1 - configs/db-xc3-24g4xg_defconfig | 1 - configs/display5_defconfig | 1 - configs/display5_factory_defconfig | 1 - configs/ds116_defconfig | 1 - configs/ds414_defconfig | 1 - configs/eDPU_defconfig | 1 - configs/eb_cpu5282_defconfig | 1 + configs/eb_cpu5282_internal_defconfig| 1 + configs/evb-ast2500_defconfig| 1 + configs/evb-ast2600_defconfig| 1 + configs/evb-rk3036_defconfig | 1 - configs/evb-rk3128_defconfig | 1 - configs/evb-rk3229_defconfig | 1 - configs/evb-rk3288_defconfig | 1 - configs/evb-rv1108_defconfig | 1 -
[PATCH 4/5] cmd/flash: Make this default y for CFI and NOR only
This command is only useful on CFI and NOR type flashes and not others. Update the dependency so that it's not enabled by default in other cases. This will lead to a number of platforms no longer building this command, where it was not useful. Signed-off-by: Tom Rini --- cmd/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/cmd/Kconfig b/cmd/Kconfig index d837b0990484..944a03336efc 100644 --- a/cmd/Kconfig +++ b/cmd/Kconfig @@ -1080,7 +1080,7 @@ config CMD_FASTBOOT config CMD_FLASH bool "flinfo, erase, protect" default y - depends on MTD || FLASH_CFI_DRIVER || MTD_NOR_FLASH + depends on FLASH_CFI_DRIVER || MTD_NOR_FLASH help NOR flash support. flinfo - print FLASH memory information -- 2.34.1
[PATCH 3/5] env: Make ENV_IS_IN_SPI_FLASH depend on SPI flash being present
In order for our environment to be present on SPI flash we need to depend not on the symbol for a SPI controller but rather that SPI flash of some sort is present. Update the dependencies. Signed-off-by: Tom Rini --- env/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/env/Kconfig b/env/Kconfig index f5f09692332d..7885c8bf8311 100644 --- a/env/Kconfig +++ b/env/Kconfig @@ -342,7 +342,7 @@ config ENV_IS_IN_REMOTE config ENV_IS_IN_SPI_FLASH bool "Environment is in SPI flash" - depends on !CHAIN_OF_TRUST && SPI + depends on !CHAIN_OF_TRUST && (SPI_FLASH || DM_SPI_FLASH) default y if ARMADA_XP default y if INTEL_BAYTRAIL default y if INTEL_BRASWELL -- 2.34.1
[PATCH 2/5] cmd/mtdparts: Make this select MTD_PARTITIONS
Rather than rely on someone selecting or implying this hidden symbol that the command requires, select it explicitly. Signed-off-by: Tom Rini --- board/microchip/mpfs_icicle/Kconfig | 1 - cmd/Kconfig | 1 + 2 files changed, 1 insertion(+), 1 deletion(-) diff --git a/board/microchip/mpfs_icicle/Kconfig b/board/microchip/mpfs_icicle/Kconfig index 7cd5a597bbad..ce510e22e81a 100644 --- a/board/microchip/mpfs_icicle/Kconfig +++ b/board/microchip/mpfs_icicle/Kconfig @@ -55,7 +55,6 @@ config BOARD_SPECIFIC_OPTIONS # dummy imply MICROCHIP_COREQSPI imply MTD_SPI_NAND imply CMD_MTD - imply MTD_PARTITIONS imply CMD_MTDPARTS endif diff --git a/cmd/Kconfig b/cmd/Kconfig index 26ad03b6..d837b0990484 100644 --- a/cmd/Kconfig +++ b/cmd/Kconfig @@ -2697,6 +2697,7 @@ config JFFS2_PART_SIZE config CMD_MTDPARTS bool "MTD partition support" depends on MTD + select MTD_PARTITIONS help MTD partitioning tool support. It is strongly encouraged to avoid using this command -- 2.34.1
[PATCH 1/5] omap3: Make SPL_OMAP3_ID_NAND depend on NAND_OMAP_GPMC
This specific bit logic is used to determine what NAND chip is present on a board in order to then know what revision of the board we have and so what DDR chips are present. We can only do this if we have a NAND chip, and so we will have NAND_OMAP_GPMC enabled. Signed-off-by: Tom Rini --- arch/arm/mach-omap2/omap3/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/mach-omap2/omap3/Kconfig b/arch/arm/mach-omap2/omap3/Kconfig index bd524f8c9f95..850ee76746ee 100644 --- a/arch/arm/mach-omap2/omap3/Kconfig +++ b/arch/arm/mach-omap2/omap3/Kconfig @@ -144,6 +144,7 @@ endchoice config SPL_OMAP3_ID_NAND bool "Support OMAP3-specific ID and MFR function" + depends on NAND_OMAP_GPMC help Support for an OMAP3-specific set of functions to return the ID and MFR of the first attached NAND chip, if present. -- 2.34.1
Re: [PATCH V2 10/10] include: env: ti: Drop default_findfdt
On 19:31-20240110, Roger Quadros wrote:
>
>
[..]
> FYI. findfdt is still used in:
>
> am335x_baltos_defconfig:CONFIG_BOOTCOMMAND="run findfdt; run usbboot;run
> mmcboot;setenv mmcdev 1; setenv bootpart 1:2; run mmcboot;run nandboot;"
> am335x_boneblack_vboot_defconfig:CONFIG_BOOTCOMMAND="run findfdt; run
> init_console; run finduuid; run distro_bootcmd"
> am335x_evm_defconfig:CONFIG_BOOTCOMMAND="run findfdt; run init_console; run
> finduuid; run distro_bootcmd"
> am335x_evm_spiboot_defconfig:CONFIG_BOOTCOMMAND="run findfdt; run
> init_console; run finduuid; run distro_bootcmd"
> am335x_hs_evm_defconfig:CONFIG_BOOTCOMMAND="run findfdt; run init_console;
> run finduuid; run distro_bootcmd"
> am335x_hs_evm_uart_defconfig:CONFIG_BOOTCOMMAND="run findfdt; run
> init_console; run finduuid; run distro_bootcmd"
> am335x_igep003x_defconfig:CONFIG_BOOTCOMMAND="run findfdt;run mmcboot;run
> nandboot;run netboot;"
> am43xx_evm_defconfig:CONFIG_BOOTCOMMAND="run findfdt; run finduuid; run
> distro_bootcmd"
> am43xx_evm_qspiboot_defconfig:CONFIG_BOOTCOMMAND="run findfdt; run finduuid;
> run distro_bootcmd"
> am43xx_evm_rtconly_defconfig:CONFIG_BOOTCOMMAND="run findfdt; run finduuid;
> run distro_bootcmd"
> am43xx_evm_usbhost_boot_defconfig:CONFIG_BOOTCOMMAND="run findfdt; run
> finduuid; run distro_bootcmd"
> am43xx_hs_evm_defconfig:CONFIG_BOOTCOMMAND="run findfdt; run finduuid; run
> distro_bootcmd"
> am43xx_hs_evm_qspi_defconfig:CONFIG_BOOTCOMMAND="run findfdt; run finduuid;
> run distro_bootcmd"
> am57xx_evm_defconfig:CONFIG_BOOTCOMMAND="if test ${dofastboot} -eq 1; then
> echo Boot fastboot requested, resetting dofastboot ...;setenv dofastboot 0;
> saveenv;echo Booting into fastboot ...; fastboot 1;fi;if test ${boot_fit} -eq
> 1; then run update_to_fit;fi;run findfdt; run finduuid; run
> distro_bootcmd;run emmc_android_boot; "
> am57xx_hs_evm_defconfig:CONFIG_BOOTCOMMAND="if test ${dofastboot} -eq 1; then
> echo Boot fastboot requested, resetting dofastboot ...;setenv dofastboot 0;
> saveenv;echo Booting into fastboot ...; fastboot 1;fi;if test ${boot_fit} -eq
> 1; then run update_to_fit;fi;run findfdt; run finduuid; run
> distro_bootcmd;run emmc_android_boot; "
> am57xx_hs_evm_usb_defconfig:CONFIG_BOOTCOMMAND="if test ${dofastboot} -eq 1;
> then echo Boot fastboot requested, resetting dofastboot ...;setenv dofastboot
> 0; saveenv;echo Booting into fastboot ...; fastboot 1;fi;if test ${boot_fit}
> -eq 1; then run update_to_fit;fi;run findfdt; run finduuid; run
> distro_bootcmd;run emmc_android_boot; "
> am65x_evm_a53_defconfig:CONFIG_BOOTCOMMAND="run findfdt; run distro_bootcmd;
> run init_${boot}; run boot_rprocs; if test ${boot_fit} -eq 1; then run
> get_fit_${boot}; run get_overlaystring; run run_fit; else; run
> get_kern_${boot}; run get_fdt_${boot}; run get_overlay_${boot}; run run_kern;
> fi;"
> dra7xx_evm_defconfig:CONFIG_BOOTCOMMAND="if test ${dofastboot} -eq 1; then
> echo Boot fastboot requested, resetting dofastboot ...;setenv dofastboot 0;
> saveenv;echo Booting into fastboot ...; fastboot 1;fi;if test ${boot_fit} -eq
> 1; then run update_to_fit;fi;run findfdt; run finduuid; run
> distro_bootcmd;run emmc_android_boot; "
> dra7xx_hs_evm_defconfig:CONFIG_BOOTCOMMAND="if test ${dofastboot} -eq 1; then
> echo Boot fastboot requested, resetting dofastboot ...;setenv dofastboot 0;
> saveenv;echo Booting into fastboot ...; fastboot 1;fi;if test ${boot_fit} -eq
> 1; then run update_to_fit;fi;run findfdt; run finduuid; run
> distro_bootcmd;run emmc_android_boot; "
> dra7xx_hs_evm_usb_defconfig:CONFIG_BOOTCOMMAND="if test ${dofastboot} -eq 1;
> then echo Boot fastboot requested, resetting dofastboot ...;setenv dofastboot
> 0; saveenv;echo Booting into fastboot ...; fastboot 1;fi;if test ${boot_fit}
> -eq 1; then run update_to_fit;fi;run findfdt; run finduuid; run
> distro_bootcmd;run emmc_android_boot; "
> k2g_evm_defconfig:CONFIG_BOOTCOMMAND="run findfdt; run envboot; run
> init_${boot}; run get_mon_${boot} run_mon; run set_name_pmmc get_pmmc_${boot}
> run_pmmc; run get_kern_${boot}; run init_fw_rd_${boot}; run get_fdt_${boot};
> run run_kern"
> k2g_hs_evm_defconfig:CONFIG_BOOTCOMMAND="run findfdt; run envboot; run
> run_mon_hs; run init_${boot}; run get_fit_${boot}; bootm
> ${addr_fit}#${name_fdt}"
> omap3_beagle_defconfig:CONFIG_BOOTCOMMAND="run findfdt; run distro_bootcmd"
> omap4_panda_defconfig:CONFIG_BOOTCOMMAND="if test ${boot_fit} -eq 1; then run
> update_to_fit; fi; run findfdt; run init_console; run
Re: [PATCH v2] boot: add support for button commands
On 2024-01-09 12:51, Caleb Connolly wrote:
With the relatively new button API in U-Boot, it's now much easier to
model the common usecase of mapping arbitrary actions to different
buttons during boot - for example entering fastboot mode, setting some
additional kernel cmdline arguments, or booting with a custom recovery
ramdisk, to name a few.
Historically, this functionality has been implemented in board code,
making it fixed for a given U-Boot binary and requiring the code be
duplicated and modified for every board.
Implement a generic abstraction to run an arbitrary command during boot
when a specific button is pressed. The button -> command mapping is
configured via environment variables with the following format:
button_cmd_N_name=
button_cmd_N=
Where N is the mapping number starting from 0. For example:
button_cmd_0_name=vol_down
button_cmd_0=fastboot usb 0
This will cause the device to enter fastboot mode if volume down is
held
during boot.
This is simply awesome, but I see one possible issue -- the need to have
proper environment variables defined for a particular board or device,
to make the buttons work as expected. Obviously, those environment
variables can be absent or can become missing for numerous reasons.
I think that we should have an additional mechanism in place that
defines the buttons and the associated commands even if no environment
variables are found. Like a set of fallback defaults for a particular
board or device, built into the U-Boot image. For example, Rockchip
boards have those defaults pretty well defined.
After we enter the cli loop the button commands are no longer valid,
this allows the buttons to additionally be used for navigating a boot
menu.
Tested-by: Svyatoslav Ryhel # Tegra30
Signed-off-by: Caleb Connolly
---
Changes since v1:
* make get_button_cmd() static.
* use #if IS_ENABLED(CONFIG_BUTTON_CMD) instead of #ifdef
CONFIG_BUTTON_CMD.
* Kconfig fixes
---
boot/Kconfig | 15 +++
common/Makefile | 1 +
common/button_cmd.c | 83 +++
common/main.c | 3 ++
doc/usage/environment.rst | 4 ++
include/button.h | 9 +
6 files changed, 115 insertions(+)
create mode 100644 common/button_cmd.c
diff --git a/boot/Kconfig b/boot/Kconfig
index fbc49c5bca47..882835731ea9 100644
--- a/boot/Kconfig
+++ b/boot/Kconfig
@@ -20,6 +20,21 @@ config TIMESTAMP
loaded that does not, the message 'Wrong FIT format: no timestamp'
is shown.
+config BUTTON_CMD
+ bool "Support for running a command if a button is held during boot"
+ depends on CMDLINE
+ depends on BUTTON
+ help
+ For many embedded devices it's useful to enter a special flashing
mode
+ such as fastboot mode when a button is held during boot. This
option
+ allows arbitrary commands to be assigned to specific buttons. These
will
+ be run after "preboot" if the button is held. Configuration is done
via
+ the environment variables "button_cmd_N_name" and "button_cmd_N"
where n is
+ the button number (starting from 0). e.g:
+
+ "button_cmd_0_name=vol_down"
+ "button_cmd_0=fastboot usb 0"
+
menuconfig FIT
bool "Flattened Image Tree (FIT)"
select HASH
diff --git a/common/Makefile b/common/Makefile
index cdeadf72026c..53105a6ce12a 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -10,6 +10,7 @@ obj-y += main.o
obj-y += exports.o
obj-$(CONFIG_HUSH_PARSER) += cli_hush.o
obj-$(CONFIG_AUTOBOOT) += autoboot.o
+obj-$(CONFIG_BUTTON_CMD) += button_cmd.o
# # boards
obj-y += board_f.o
diff --git a/common/button_cmd.c b/common/button_cmd.c
new file mode 100644
index ..b6a8434d6f29
--- /dev/null
+++ b/common/button_cmd.c
@@ -0,0 +1,83 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2023 Linaro Ltd.
+ * Author: Caleb Connolly
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+/* Some sane limit "just in case" */
+#define MAX_BTN_CMDS 32
+
+struct button_cmd {
+ bool pressed;
+ const char *btn_name;
+ const char *cmd;
+};
+
+/*
+ * Button commands are set via environment variables, e.g.:
+ * button_cmd_N_name=Volume Up
+ * button_cmd_N=fastboot usb 0
+ *
+ * This function will retrieve the command for the given button N
+ * and populate the cmd struct with the command string and pressed
+ * state of the button.
+ *
+ * Returns 1 if a command was found, 0 otherwise.
+ */
+static int get_button_cmd(int n, struct button_cmd *cmd)
+{
+ const char *cmd_str;
+ struct udevice *btn;
+ char buf[24];
+
+ snprintf(buf, sizeof(buf), "button_cmd_%d_name", n);
+ cmd->btn_name = env_get(buf);
+ if (!cmd->btn_name)
+ return 0;
+
+ button_get_by_label(cmd->btn_name, );
+ if (!btn) {
+ log_err("No button labelled '%s'\n", cmd->btn_name);
+ return 0;
+ }
+
+
Re: [PATCH v4 2/6] rpi5: Use devicetree as alternative way to read IO base addresses
On 1/10/24 04:29, Ivan T. Ivanov wrote: From: Dmitry Malkin MBOX and Watchdog on RPi5/bcm2712 has a different base IO offsets. s/has a/have a / Find them via devicetree blob passed by bootloader. Signed-off-by: Dmitry Malkin Reviewed-by: Matthias Brugger Signed-off-by: Ivan T. Ivanov --- arch/arm/mach-bcm283x/include/mach/base.h | 5 ++- arch/arm/mach-bcm283x/include/mach/mbox.h | 3 +- arch/arm/mach-bcm283x/include/mach/sdhci.h | 3 +- arch/arm/mach-bcm283x/include/mach/timer.h | 3 +- arch/arm/mach-bcm283x/include/mach/wdog.h | 3 +- arch/arm/mach-bcm283x/init.c | 43 ++ 6 files changed, 43 insertions(+), 17 deletions(-) diff --git a/arch/arm/mach-bcm283x/include/mach/base.h b/arch/arm/mach-bcm283x/include/mach/base.h index 4ccaf69693..6de99e7ea1 100644 --- a/arch/arm/mach-bcm283x/include/mach/base.h +++ b/arch/arm/mach-bcm283x/include/mach/base.h @@ -6,7 +6,10 @@ #ifndef _BCM283x_BASE_H_ #define _BCM283x_BASE_H_ -extern unsigned long rpi_bcm283x_base; +extern unsigned long rpi_mbox_base; +extern unsigned long rpi_timer_base; +extern unsigned long rpi_sdhci_base; +extern unsigned long rpi_wdog_base; Maybe suffix those variables with _phys_base to denote they are physical addresses, even if you seem to use a 1:1 mapping between virtual and physical, knowing which type of address we are dealing with right away is clearer. -- Florian smime.p7s Description: S/MIME Cryptographic Signature
Re: [PATCH v4 1/6] rpi5: add initial memory map for bcm2712
On 1/10/24 04:29, Ivan T. Ivanov wrote: From: Dmitry Malkin This includes: * 1GB of RAM (from 4GB or 8GB total) * AXI ranges (main peripherals) When HDMI cable is plugged in at boot time firmware will insert "simple-framebuffer" device into devicetree and will shrink first memory region to 0x3f80UL. Board setup then will properly reserve frameboofer region. s/frameboofer/framebuffer/ When no HDMI cable is plugged in size of the region will be 0x3fc0UL. s/in size/in the size/ -- Florian smime.p7s Description: S/MIME Cryptographic Signature
Re: [PATCH V2 10/10] include: env: ti: Drop default_findfdt
On 09/01/2024 21:15, Nishanth Menon wrote:
> We shouldn't need finfdt anymore. Drop the env script.
>
> Signed-off-by: Nishanth Menon
> ---
> Changes from V1: None.
>
> V1: https://lore.kernel.org/r/20240108173301.2692332-11...@ti.com
> include/env/ti/default_findfdt.env | 12
> 1 file changed, 12 deletions(-)
> delete mode 100644 include/env/ti/default_findfdt.env
>
> diff --git a/include/env/ti/default_findfdt.env
> b/include/env/ti/default_findfdt.env
> deleted file mode 100644
> index a2b51dd923bb..
> --- a/include/env/ti/default_findfdt.env
> +++ /dev/null
> @@ -1,12 +0,0 @@
> -default_device_tree=CONFIG_DEFAULT_DEVICE_TREE
> -default_device_tree_arch=ti
> -#ifdef CONFIG_ARM64
> -findfdt=
> - setenv name_fdt ${default_device_tree_arch}/${default_device_tree}.dtb;
> - setenv fdtfile ${name_fdt}
> -#else
> -default_device_tree_subarch=omap
> -findfdt=
> - setenv name_fdt
> ${default_device_tree_arch}/${default_device_tree_subarch}/${default_device_tree}.dtb;
> - setenv fdtfile ${name_fdt}
> -#endif
FYI. findfdt is still used in:
am335x_baltos_defconfig:CONFIG_BOOTCOMMAND="run findfdt; run usbboot;run
mmcboot;setenv mmcdev 1; setenv bootpart 1:2; run mmcboot;run nandboot;"
am335x_boneblack_vboot_defconfig:CONFIG_BOOTCOMMAND="run findfdt; run
init_console; run finduuid; run distro_bootcmd"
am335x_evm_defconfig:CONFIG_BOOTCOMMAND="run findfdt; run init_console; run
finduuid; run distro_bootcmd"
am335x_evm_spiboot_defconfig:CONFIG_BOOTCOMMAND="run findfdt; run init_console;
run finduuid; run distro_bootcmd"
am335x_hs_evm_defconfig:CONFIG_BOOTCOMMAND="run findfdt; run init_console; run
finduuid; run distro_bootcmd"
am335x_hs_evm_uart_defconfig:CONFIG_BOOTCOMMAND="run findfdt; run init_console;
run finduuid; run distro_bootcmd"
am335x_igep003x_defconfig:CONFIG_BOOTCOMMAND="run findfdt;run mmcboot;run
nandboot;run netboot;"
am43xx_evm_defconfig:CONFIG_BOOTCOMMAND="run findfdt; run finduuid; run
distro_bootcmd"
am43xx_evm_qspiboot_defconfig:CONFIG_BOOTCOMMAND="run findfdt; run finduuid;
run distro_bootcmd"
am43xx_evm_rtconly_defconfig:CONFIG_BOOTCOMMAND="run findfdt; run finduuid; run
distro_bootcmd"
am43xx_evm_usbhost_boot_defconfig:CONFIG_BOOTCOMMAND="run findfdt; run
finduuid; run distro_bootcmd"
am43xx_hs_evm_defconfig:CONFIG_BOOTCOMMAND="run findfdt; run finduuid; run
distro_bootcmd"
am43xx_hs_evm_qspi_defconfig:CONFIG_BOOTCOMMAND="run findfdt; run finduuid; run
distro_bootcmd"
am57xx_evm_defconfig:CONFIG_BOOTCOMMAND="if test ${dofastboot} -eq 1; then echo
Boot fastboot requested, resetting dofastboot ...;setenv dofastboot 0;
saveenv;echo Booting into fastboot ...; fastboot 1;fi;if test ${boot_fit} -eq
1; then run update_to_fit;fi;run findfdt; run finduuid; run distro_bootcmd;run
emmc_android_boot; "
am57xx_hs_evm_defconfig:CONFIG_BOOTCOMMAND="if test ${dofastboot} -eq 1; then
echo Boot fastboot requested, resetting dofastboot ...;setenv dofastboot 0;
saveenv;echo Booting into fastboot ...; fastboot 1;fi;if test ${boot_fit} -eq
1; then run update_to_fit;fi;run findfdt; run finduuid; run distro_bootcmd;run
emmc_android_boot; "
am57xx_hs_evm_usb_defconfig:CONFIG_BOOTCOMMAND="if test ${dofastboot} -eq 1;
then echo Boot fastboot requested, resetting dofastboot ...;setenv dofastboot
0; saveenv;echo Booting into fastboot ...; fastboot 1;fi;if test ${boot_fit}
-eq 1; then run update_to_fit;fi;run findfdt; run finduuid; run
distro_bootcmd;run emmc_android_boot; "
am65x_evm_a53_defconfig:CONFIG_BOOTCOMMAND="run findfdt; run distro_bootcmd;
run init_${boot}; run boot_rprocs; if test ${boot_fit} -eq 1; then run
get_fit_${boot}; run get_overlaystring; run run_fit; else; run
get_kern_${boot}; run get_fdt_${boot}; run get_overlay_${boot}; run run_kern;
fi;"
dra7xx_evm_defconfig:CONFIG_BOOTCOMMAND="if test ${dofastboot} -eq 1; then echo
Boot fastboot requested, resetting dofastboot ...;setenv dofastboot 0;
saveenv;echo Booting into fastboot ...; fastboot 1;fi;if test ${boot_fit} -eq
1; then run update_to_fit;fi;run findfdt; run finduuid; run distro_bootcmd;run
emmc_android_boot; "
dra7xx_hs_evm_defconfig:CONFIG_BOOTCOMMAND="if test ${dofastboot} -eq 1; then
echo Boot fastboot requested, resetting dofastboot ...;setenv dofastboot 0;
saveenv;echo Booting into fastboot ...; fastboot 1;fi;if test ${boot_fit} -eq
1; then run update_to_fit;fi;run findfdt; run finduuid; run distro_bootcmd;run
emmc_android_boot; "
dra7xx_hs_evm_usb_defconfig:CONFIG_BOOTCOMMAND="if test ${dofastboot} -eq 1;
then echo Boot fastboot requested, resetting dofastboot ...;setenv dofastboot
0; saveenv;echo Booting into fastboot ...; fastboot 1;fi;if test ${boot_fit}
-eq 1; then run update_to_fit;fi;run findfdt; run finduuid; run
distro_bootcmd;run emmc_android_boot; "
k2g_evm_defconfig:CONFIG_BOOTCOMMAND="run findfdt; run envboot; run
init_${boot}; run get_mon_${boot} run_mon; run set_name_pmmc get_pmmc_${boot}
run_pmmc; run get_kern_${boot}; run
Re: [PATCH 4/4] configs: am64x_evm_a53_defconfig: Enable NAND
On Wed, Jan 10, 2024 at 06:06:45PM +0200, Roger Quadros wrote: > +Lukasz & Mattijs > > On 10/01/2024 11:34, Roger Quadros wrote: > > > > > > On 09/01/2024 22:00, Francesco Dolcini wrote: > >> On Tue, Jan 09, 2024 at 02:54:00PM -0500, Tom Rini wrote: > >>> On Tue, Jan 09, 2024 at 01:18:59PM -0600, Nishanth Menon wrote: > On 14:26-20240109, Roger Quadros wrote: > > CONFIG_CMD_PMIC=y > > CONFIG_CMD_REGULATOR=y > > +CONFIG_CMD_MTDPARTS=y > > +CONFIG_MTDIDS_DEFAULT="nand0=omap2-nand.0" > > +CONFIG_MTDPARTS_DEFAULT="mtdparts=omap2-nand.0:2m(NAND.tiboot3),2m(NAND.tispl),2m(NAND.tiboot3.backup),4m(NAND.u-boot),256k(NAND.u-boot-env),256k(NAND.u-boot-env.backup),-(NAND.file-system)" > > Why not handle this as device tree partitions? > >>> > >>> I honestly forget what the preferred way of defining and passing NAND > >>> partition information is these days. It might even be the funny case > >>> that passing as cmdline args is "best" rather than fixed-partitions > >>> binding? > >> > >> According to past discussions [1] doing the fixup in U-Boot is not advised. > >> > >> Using the command line or having the partition fixed in the DT are both > >> valid options. > >> > >> [1] > >> https://lore.kernel.org/all/20230206224838.75963-1-france...@dolcini.it/ > >> > >> Francesco > >> > > > > This was not about passing mtdparts to kernel but about getting 'mtdparts' > > command > > to work at u-boot. I need to figure out why OF partition parser didn't work > > here. > > > > For a start I didn't have CONFIG_MTD_PARTITIONS set. Maybe I'm missing > > something more. > > > > The issue was the NAND driver was not setting chip->dev and chip->ofnode > correctly. > Now 'mtd list' shows partitions from the DT. > But, 'dfu 0 nand list' still fails like so. > "mtdparts variable not set, see 'help mtdparts'" > > Looks like dfu_nand driver doesn't fall back to OF partitions if mtdparts > environment > is not defined. > > Should we add OF partitions support to dfu_nand driver or is it deprecated > in favor of dfu_mtd driver? I would rather not have to populate the env variable as that will lead to confusion later on I fear (make a change and it's not populated onward). -- Tom signature.asc Description: PGP signature
[PATCH v3 1/1] clk: clk-gpio: add actual gated clock
Existing gpio-gate-clock driver acts like a simple GPIO switch without any
effect on gated clock. Add actual clock actions into enable/disable ops and
implement get_rate op by passing gated clock if it is enabled.
Signed-off-by: Svyatoslav Ryhel
---
drivers/clk/clk-gpio.c | 40 ++--
1 file changed, 34 insertions(+), 6 deletions(-)
diff --git a/drivers/clk/clk-gpio.c b/drivers/clk/clk-gpio.c
index 26d795b978..d2dd8070fa 100644
--- a/drivers/clk/clk-gpio.c
+++ b/drivers/clk/clk-gpio.c
@@ -3,19 +3,23 @@
* Copyright (C) 2023 Marek Vasut
*/
-#include
-#include
-#include
+#include
#include
+#include
+#include
+
+#include
struct clk_gpio_priv {
- struct gpio_descenable;
+ struct gpio_descenable; /* GPIO, controlling the gate */
+ struct clk *clk; /* Gated clock */
};
static int clk_gpio_enable(struct clk *clk)
{
struct clk_gpio_priv *priv = dev_get_priv(clk->dev);
+ clk_enable(priv->clk);
dm_gpio_set_value(>enable, 1);
return 0;
@@ -26,21 +30,45 @@ static int clk_gpio_disable(struct clk *clk)
struct clk_gpio_priv *priv = dev_get_priv(clk->dev);
dm_gpio_set_value(>enable, 0);
+ clk_disable(priv->clk);
return 0;
}
+static ulong clk_gpio_get_rate(struct clk *clk)
+{
+ struct clk_gpio_priv *priv = dev_get_priv(clk->dev);
+
+ return clk_get_rate(priv->clk);
+}
+
const struct clk_ops clk_gpio_ops = {
.enable = clk_gpio_enable,
.disable= clk_gpio_disable,
+ .get_rate = clk_gpio_get_rate,
};
static int clk_gpio_probe(struct udevice *dev)
{
struct clk_gpio_priv *priv = dev_get_priv(dev);
+ int ret;
- return gpio_request_by_name(dev, "enable-gpios", 0,
- >enable, GPIOD_IS_OUT);
+ priv->clk = devm_clk_get(dev, NULL);
+ if (IS_ERR(priv->clk)) {
+ log_debug("%s: Could not get gated clock: %ld\n",
+ __func__, PTR_ERR(priv->clk));
+ return PTR_ERR(priv->clk);
+ }
+
+ ret = gpio_request_by_name(dev, "enable-gpios", 0,
+ >enable, GPIOD_IS_OUT);
+ if (ret) {
+ log_debug("%s: Could not decode enable-gpios (%d)\n",
+ __func__, ret);
+ return ret;
+ }
+
+ return 0;
}
/*
--
2.40.1
[PATCH v3 0/1] Fix clk-gpio driver
Existing gpio-gate-clock driver acts like a simple GPIO switch without any effect on gated clock. Add actual clock actions into enable/disable ops and implement get_rate op by passing gated clock if it is enabled. Testing current driver implementation shows that it is not fully capable and lacks gated clock manipulations. --- Changes from v2 - restored probe Changes from v1 - added comments for priv struct members - return gatet clock rate unconditionally - switch log_err > log_debug on of_to_plat --- Svyatoslav Ryhel (1): clk: clk-gpio: add actual gated clock drivers/clk/clk-gpio.c | 40 ++-- 1 file changed, 34 insertions(+), 6 deletions(-) -- 2.40.1
Re: [PATCH 4/4] configs: am64x_evm_a53_defconfig: Enable NAND
+Lukasz & Mattijs On 10/01/2024 11:34, Roger Quadros wrote: > > > On 09/01/2024 22:00, Francesco Dolcini wrote: >> On Tue, Jan 09, 2024 at 02:54:00PM -0500, Tom Rini wrote: >>> On Tue, Jan 09, 2024 at 01:18:59PM -0600, Nishanth Menon wrote: On 14:26-20240109, Roger Quadros wrote: > CONFIG_CMD_PMIC=y > CONFIG_CMD_REGULATOR=y > +CONFIG_CMD_MTDPARTS=y > +CONFIG_MTDIDS_DEFAULT="nand0=omap2-nand.0" > +CONFIG_MTDPARTS_DEFAULT="mtdparts=omap2-nand.0:2m(NAND.tiboot3),2m(NAND.tispl),2m(NAND.tiboot3.backup),4m(NAND.u-boot),256k(NAND.u-boot-env),256k(NAND.u-boot-env.backup),-(NAND.file-system)" Why not handle this as device tree partitions? >>> >>> I honestly forget what the preferred way of defining and passing NAND >>> partition information is these days. It might even be the funny case >>> that passing as cmdline args is "best" rather than fixed-partitions >>> binding? >> >> According to past discussions [1] doing the fixup in U-Boot is not advised. >> >> Using the command line or having the partition fixed in the DT are both >> valid options. >> >> [1] https://lore.kernel.org/all/20230206224838.75963-1-france...@dolcini.it/ >> >> Francesco >> > > This was not about passing mtdparts to kernel but about getting 'mtdparts' > command > to work at u-boot. I need to figure out why OF partition parser didn't work > here. > > For a start I didn't have CONFIG_MTD_PARTITIONS set. Maybe I'm missing > something more. > The issue was the NAND driver was not setting chip->dev and chip->ofnode correctly. Now 'mtd list' shows partitions from the DT. But, 'dfu 0 nand list' still fails like so. "mtdparts variable not set, see 'help mtdparts'" Looks like dfu_nand driver doesn't fall back to OF partitions if mtdparts environment is not defined. Should we add OF partitions support to dfu_nand driver or is it deprecated in favor of dfu_mtd driver? -- cheers, -roger
Re: [PATCH v2 1/1] clk: clk-gpio: add actual gated clock
On 1/10/24 10:53, Svyatoslav wrote:
10 січня 2024 р. 17:45:57 GMT+02:00, Sean Anderson
написав(-ла):
On 12/16/23 10:37, Sean Anderson wrote:
On 12/16/23 03:48, Svyatoslav Ryhel wrote:
Existing gpio-gate-clock driver acts like a simple GPIO switch without any
effect on gated clock. Add actual clock actions into enable/disable ops and
implement get_rate op by passing gated clock if it is enabled.
Signed-off-by: Svyatoslav Ryhel
---
drivers/clk/clk-gpio.c | 44 ++
1 file changed, 36 insertions(+), 8 deletions(-)
diff --git a/drivers/clk/clk-gpio.c b/drivers/clk/clk-gpio.c
index 26d795b978..72d9747a47 100644
--- a/drivers/clk/clk-gpio.c
+++ b/drivers/clk/clk-gpio.c
@@ -3,19 +3,23 @@
* Copyright (C) 2023 Marek Vasut
*/
-#include
-#include
-#include
+#include
#include
+#include
+#include
+
+#include
struct clk_gpio_priv {
- struct gpio_desc enable;
+ struct gpio_desc enable; /* GPIO, controlling the gate */
+ struct clk *clk; /* Gated clock */
};
static int clk_gpio_enable(struct clk *clk)
{
struct clk_gpio_priv *priv = dev_get_priv(clk->dev);
+ clk_enable(priv->clk);
dm_gpio_set_value(>enable, 1);
return 0;
@@ -26,21 +30,45 @@ static int clk_gpio_disable(struct clk *clk)
struct clk_gpio_priv *priv = dev_get_priv(clk->dev);
dm_gpio_set_value(>enable, 0);
+ clk_disable(priv->clk);
return 0;
}
+static ulong clk_gpio_get_rate(struct clk *clk)
+{
+ struct clk_gpio_priv *priv = dev_get_priv(clk->dev);
+
+ return clk_get_rate(priv->clk);
+}
+
const struct clk_ops clk_gpio_ops = {
.enable = clk_gpio_enable,
.disable = clk_gpio_disable,
+ .get_rate = clk_gpio_get_rate,
};
-static int clk_gpio_probe(struct udevice *dev)
+static int clk_gpio_of_to_plat(struct udevice *dev)
Same comment as the first time:
Why the conversion from probe to of_to_plat?
Same answer as the first time.
Last time you said
-static int clk_gpio_probe(struct udevice *dev)
+static int clk_gpio_of_to_plat(struct udevice *dev)
This change should be a separate commit.
This actually should not be accepted first place
.of_to_plat - convert device tree data to plat
.probe - make a device ready for use
https://github.com/u-boot/u-boot/blob/master/doc/develop/driver-model/design.rst
and I thought "This actually should not be accepted first place" was referring
to
the conversion (i.e. that you would be removing it next time).
This sort of conversion should be mentioned in the commit message.
And the weird thing to me is that I would expect of_to_plat to fill in a
platdata
struct. If you are not doing that, why use this function?
You propose to spam commits for this small adjustment?
Yes. One change per commit.
--Sean
Re: [PATCH v2 1/1] clk: clk-gpio: add actual gated clock
10 січня 2024 р. 17:45:57 GMT+02:00, Sean Anderson
написав(-ла):
>On 12/16/23 10:37, Sean Anderson wrote:
>> On 12/16/23 03:48, Svyatoslav Ryhel wrote:
>>> Existing gpio-gate-clock driver acts like a simple GPIO switch without any
>>> effect on gated clock. Add actual clock actions into enable/disable ops and
>>> implement get_rate op by passing gated clock if it is enabled.
>>>
>>> Signed-off-by: Svyatoslav Ryhel
>>> ---
>>> drivers/clk/clk-gpio.c | 44 ++
>>> 1 file changed, 36 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/drivers/clk/clk-gpio.c b/drivers/clk/clk-gpio.c
>>> index 26d795b978..72d9747a47 100644
>>> --- a/drivers/clk/clk-gpio.c
>>> +++ b/drivers/clk/clk-gpio.c
>>> @@ -3,19 +3,23 @@
>>> * Copyright (C) 2023 Marek Vasut
>>> */
>>> -#include
>>> -#include
>>> -#include
>>> +#include
>>> #include
>>> +#include
>>> +#include
>>> +
>>> +#include
>>> struct clk_gpio_priv {
>>> - struct gpio_desc enable;
>>> + struct gpio_desc enable; /* GPIO, controlling the gate */
>>> + struct clk *clk; /* Gated clock */
>>> };
>>> static int clk_gpio_enable(struct clk *clk)
>>> {
>>> struct clk_gpio_priv *priv = dev_get_priv(clk->dev);
>>> + clk_enable(priv->clk);
>>> dm_gpio_set_value(>enable, 1);
>>> return 0;
>>> @@ -26,21 +30,45 @@ static int clk_gpio_disable(struct clk *clk)
>>> struct clk_gpio_priv *priv = dev_get_priv(clk->dev);
>>> dm_gpio_set_value(>enable, 0);
>>> + clk_disable(priv->clk);
>>> return 0;
>>> }
>>> +static ulong clk_gpio_get_rate(struct clk *clk)
>>> +{
>>> + struct clk_gpio_priv *priv = dev_get_priv(clk->dev);
>>> +
>>> + return clk_get_rate(priv->clk);
>>> +}
>>> +
>>> const struct clk_ops clk_gpio_ops = {
>>> .enable = clk_gpio_enable,
>>> .disable = clk_gpio_disable,
>>> + .get_rate = clk_gpio_get_rate,
>>> };
>>> -static int clk_gpio_probe(struct udevice *dev)
>>> +static int clk_gpio_of_to_plat(struct udevice *dev)
>
>Same comment as the first time:
>
>Why the conversion from probe to of_to_plat?
>
Same answer as the first time. You propose to spam commits for this small
adjustment?
>--Sean
>
>>> {
>>> struct clk_gpio_priv *priv = dev_get_priv(dev);
>>> + int ret;
>>> - return gpio_request_by_name(dev, "enable-gpios", 0,
>>> - >enable, GPIOD_IS_OUT);
>>> + priv->clk = devm_clk_get(dev, NULL);
>>> + if (IS_ERR(priv->clk)) {
>>> + log_debug("%s: Could not get gated clock: %ld\n",
>>> + __func__, PTR_ERR(priv->clk));
>>> + return PTR_ERR(priv->clk);
>>> + }
>>> +
>>> + ret = gpio_request_by_name(dev, "enable-gpios", 0,
>>> + >enable, GPIOD_IS_OUT);
>>> + if (ret) {
>>> + log_debug("%s: Could not decode enable-gpios (%d)\n",
>>> + __func__, ret);
>>> + return ret;
>>> + }
>>> +
>>> + return 0;
>>> }
>>> /*
>>> @@ -59,7 +87,7 @@ U_BOOT_DRIVER(gpio_gate_clock) = {
>>> .name = "gpio_clock",
>>> .id = UCLASS_CLK,
>>> .of_match = clk_gpio_match,
>>> - .probe = clk_gpio_probe,
>>> + .of_to_plat = clk_gpio_of_to_plat,
>>> .priv_auto = sizeof(struct clk_gpio_priv),
>>> .ops = _gpio_ops,
>>> .flags = DM_FLAG_PRE_RELOC,
>>
>> +CC Marek
>
Re: Please pull u-boot-marvell/master
On Wed, Jan 10, 2024 at 03:47:24PM +0100, Stefan Roese wrote: > Hi Tom, > > please pull this next batch of Marvell related patches: > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 1/1] clk: clk-gpio: add actual gated clock
On 12/16/23 10:37, Sean Anderson wrote:
On 12/16/23 03:48, Svyatoslav Ryhel wrote:
Existing gpio-gate-clock driver acts like a simple GPIO switch without any
effect on gated clock. Add actual clock actions into enable/disable ops and
implement get_rate op by passing gated clock if it is enabled.
Signed-off-by: Svyatoslav Ryhel
---
drivers/clk/clk-gpio.c | 44 ++
1 file changed, 36 insertions(+), 8 deletions(-)
diff --git a/drivers/clk/clk-gpio.c b/drivers/clk/clk-gpio.c
index 26d795b978..72d9747a47 100644
--- a/drivers/clk/clk-gpio.c
+++ b/drivers/clk/clk-gpio.c
@@ -3,19 +3,23 @@
* Copyright (C) 2023 Marek Vasut
*/
-#include
-#include
-#include
+#include
#include
+#include
+#include
+
+#include
struct clk_gpio_priv {
- struct gpio_desc enable;
+ struct gpio_desc enable; /* GPIO, controlling the gate */
+ struct clk *clk; /* Gated clock */
};
static int clk_gpio_enable(struct clk *clk)
{
struct clk_gpio_priv *priv = dev_get_priv(clk->dev);
+ clk_enable(priv->clk);
dm_gpio_set_value(>enable, 1);
return 0;
@@ -26,21 +30,45 @@ static int clk_gpio_disable(struct clk *clk)
struct clk_gpio_priv *priv = dev_get_priv(clk->dev);
dm_gpio_set_value(>enable, 0);
+ clk_disable(priv->clk);
return 0;
}
+static ulong clk_gpio_get_rate(struct clk *clk)
+{
+ struct clk_gpio_priv *priv = dev_get_priv(clk->dev);
+
+ return clk_get_rate(priv->clk);
+}
+
const struct clk_ops clk_gpio_ops = {
.enable = clk_gpio_enable,
.disable = clk_gpio_disable,
+ .get_rate = clk_gpio_get_rate,
};
-static int clk_gpio_probe(struct udevice *dev)
+static int clk_gpio_of_to_plat(struct udevice *dev)
Same comment as the first time:
Why the conversion from probe to of_to_plat?
--Sean
{
struct clk_gpio_priv *priv = dev_get_priv(dev);
+ int ret;
- return gpio_request_by_name(dev, "enable-gpios", 0,
- >enable, GPIOD_IS_OUT);
+ priv->clk = devm_clk_get(dev, NULL);
+ if (IS_ERR(priv->clk)) {
+ log_debug("%s: Could not get gated clock: %ld\n",
+ __func__, PTR_ERR(priv->clk));
+ return PTR_ERR(priv->clk);
+ }
+
+ ret = gpio_request_by_name(dev, "enable-gpios", 0,
+ >enable, GPIOD_IS_OUT);
+ if (ret) {
+ log_debug("%s: Could not decode enable-gpios (%d)\n",
+ __func__, ret);
+ return ret;
+ }
+
+ return 0;
}
/*
@@ -59,7 +87,7 @@ U_BOOT_DRIVER(gpio_gate_clock) = {
.name = "gpio_clock",
.id = UCLASS_CLK,
.of_match = clk_gpio_match,
- .probe = clk_gpio_probe,
+ .of_to_plat = clk_gpio_of_to_plat,
.priv_auto = sizeof(struct clk_gpio_priv),
.ops = _gpio_ops,
.flags = DM_FLAG_PRE_RELOC,
+CC Marek
Re: [PATCH v3] clk: meson: add Hardware Clock measure driver
On 1/10/24 04:23, Neil Armstrong wrote:
Hi Sean,
On 18/12/2023 10:47, Neil Armstrong via groups.io wrote:
Amlogic SoCs embeds an hardware clock measure block, port it
from Linux and implement it as a UCLK_CLK with only the dump
op and fail-only xlate.
Based on the Linux driver introduced in [1].
[1] commit 2b45ebef39a2 ("soc: amlogic: Add Meson Clock Measure driver").
Reviewed-by: Sean Anderson
Signed-off-by: Neil Armstrong
Should I take this via the amlogic tree ?
If you like.
I will be doing a PR sometime before the merge window ends.
--Sean
Re: [PATCH v4 4/6] bcm2835: Dynamically calculate bytes per pixel parameter
On 10/01/2024 13:29, Ivan T. Ivanov wrote:
brcm,bcm2708-fb device provided by firmware on RPi5 uses
16 bits per pixel, so lets calculate framebuffer bytes
per pixel dynamically based on queried information.
Tested to work for RPi2b v1.2, RPi3b v1.3, RPi4b v1.1,
RPi2 Zero W, RPi5b v1.0.
Signed-off-by: Ivan T. Ivanov
Reviewed-by: Matthias Brugger
---
drivers/video/bcm2835.c | 18 --
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/drivers/video/bcm2835.c b/drivers/video/bcm2835.c
index 14942526f1..63efa762db 100644
--- a/drivers/video/bcm2835.c
+++ b/drivers/video/bcm2835.c
@@ -16,7 +16,7 @@ static int bcm2835_video_probe(struct udevice *dev)
struct video_uc_plat *plat = dev_get_uclass_plat(dev);
struct video_priv *uc_priv = dev_get_uclass_priv(dev);
int ret;
- int w, h, pitch;
+ int w, h, pitch, bpp;
ulong fb_base, fb_size, fb_start, fb_end;
debug("bcm2835: Query resolution...\n");
@@ -41,9 +41,23 @@ static int bcm2835_video_probe(struct udevice *dev)
DCACHE_WRITEBACK);
video_set_flush_dcache(dev, true);
+ bpp = pitch / w;
+ switch (bpp) {
+ case 2:
+ uc_priv->bpix = VIDEO_BPP16;
+ break;
+ case 4:
+ uc_priv->bpix = VIDEO_BPP32;
+ break;
+ default:
+ printf("bcm2835: unexpected bpp %d, pitch %d, width %d\n",
+ bpp, pitch, w);
+ uc_priv->bpix = VIDEO_BPP32;
+ break;
+ }
+
uc_priv->xsize = w;
uc_priv->ysize = h;
- uc_priv->bpix = VIDEO_BPP32;
plat->base = fb_base;
plat->size = fb_size;
Re: [PATCH v1 1/3] arm: config: xea: Update environment variables for XEA board (imx287)
On Wed, Jan 10, 2024 at 03:48:47PM +0100, Lukasz Majewski wrote: > As the XEA now supports fitImage, the default envs shall reflect this > as well. > > Moreover, some SPI-NOR layout re-organization has took place. > > Signed-off-by: Lukasz Majewski > --- > > include/configs/xea.h | 45 --- > 1 file changed, 25 insertions(+), 20 deletions(-) Please migrate this to a plain text environment. -- Tom signature.asc Description: PGP signature
[PATCH v1 3/3] arm: xea: Add support for boot image source descriptor in SPL
From: Anatolij Gustschin
We load two boot image source descriptor structures from last
two sectors in the SPI NOR flash and determine the boot source
for loading the kernel/DTB images, then adjust the boot order for
loading image from eMMC boot0 or boot1 partition.
Signed-off-by: Anatolij Gustschin
Signed-off-by: Lukasz Majewski
---
board/liebherr/xea/boot_img_scr.h | 27 ++
board/liebherr/xea/xea.c | 85 +++
2 files changed, 112 insertions(+)
create mode 100644 board/liebherr/xea/boot_img_scr.h
diff --git a/board/liebherr/xea/boot_img_scr.h
b/board/liebherr/xea/boot_img_scr.h
new file mode 100644
index 00..baa3072b49
--- /dev/null
+++ b/board/liebherr/xea/boot_img_scr.h
@@ -0,0 +1,27 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Struct for boot image source description for placing in last
+ * two SPI NOR flash sectors on legcom.
+ */
+
+struct boot_img_src {
+ u8 magic; /* Must be 'B' = 0x42 */
+ u8 flags; /* flags to specify mmcblk[0|1] boot[0|1] */
+ u8 crc8;/* CRC-8 over above two bytes */
+} __packed;
+
+/*
+ * Bit definition in boot_img_src.flags:
+ * Bit 0: mmcblk device 0 or 1 (1 - if this bit set)
+ * Bit 1: mmcblk boot partition 0 or 1.
+ * for eMMC: boot0 if this bit is cleared, boot1 - if set
+ * for SD-card the boot partition value will always be 0
+ * (independent of the value of this bit)
+ *
+ */
+#define BOOT_SRC_MMC1 BIT(0)
+#define BOOT_SRC_PART1 BIT(1)
+
+/* Offset of the first boot image source descriptor in SPI NOR */
+#define SPI_FLASH_BOOT_SRC_OFFS0xFE
+#define SPI_FLASH_SECTOR_SIZE 0x1
diff --git a/board/liebherr/xea/xea.c b/board/liebherr/xea/xea.c
index e4d2eb65cc..c8ac526cb4 100644
--- a/board/liebherr/xea/xea.c
+++ b/board/liebherr/xea/xea.c
@@ -32,6 +32,11 @@
#include
#include
#include
+#include
+#include "boot_img_scr.h"
+
+#include
+#include
#ifdef CONFIG_SPL_BUILD
#include
@@ -66,6 +71,52 @@ void board_init_f(ulong arg)
preloader_console_init();
}
+static struct boot_img_src img_src[2];
+static int spi_load_boot_info(void)
+{
+ struct spi_flash *flash;
+ int err;
+
+ flash = spi_flash_probe(CONFIG_SF_DEFAULT_BUS,
+ CONFIG_SF_DEFAULT_CS,
+ CONFIG_SF_DEFAULT_SPEED,
+ CONFIG_SF_DEFAULT_MODE);
+ if (!flash) {
+ printf("%s: SPI probe err\n", __func__);
+ return -ENODEV;
+ }
+
+ /*
+* Load both boot info structs from SPI flash
+*/
+ err = spi_flash_read(flash, SPI_FLASH_BOOT_SRC_OFFS,
+sizeof(img_src[0]),
+(void *)_src[0]);
+ if (err) {
+ debug("%s: First boot info NOR sector read error %d\n",
+ __func__, err);
+ return err;
+ }
+
+ err = spi_flash_read(flash,
+SPI_FLASH_BOOT_SRC_OFFS + SPI_FLASH_SECTOR_SIZE,
+sizeof(img_src[0]),
+(void *)_src[1]);
+ if (err) {
+ debug("%s: First boot info NOR sector read error %d\n",
+ __func__, err);
+ return err;
+ }
+
+ debug("%s: BI0 0x%x 0x%x 0x%x\n", __func__,
+ img_src[0].magic, img_src[0].flags, img_src[0].crc8);
+
+ debug("%s: BI1 0x%x 0x%x 0x%x\n", __func__,
+ img_src[1].magic, img_src[1].flags, img_src[1].crc8);
+
+ return 0;
+}
+
static int boot_tiva0, boot_tiva1;
/* Check if TIVAs request booting via U-Boot proper */
@@ -114,6 +165,40 @@ void spl_board_init(void)
boot_tiva1 = dm_gpio_get_value();
}
+int spl_mmc_emmc_boot_partition(struct mmc *mmc)
+{
+ int i, src_idx = -1, ret;
+
+ ret = spi_load_boot_info();
+ if (ret) {
+ printf("%s: Cannot read XEA boot info! [%d]\n", __func__, ret);
+ /* To avoid bricking board - by default boot from boot0 eMMC */
+ return 1;
+ }
+
+ for (i = 0; i < 2; i++) {
+ if (img_src[i].magic == 'B' &&
+ img_src[i].crc8 == crc8(0, _src[i].magic, 2)) {
+ src_idx = i;
+ break;
+ }
+ }
+
+ debug("%s: src idx: %d\n", __func__, src_idx);
+
+ if (src_idx < 0)
+ /*
+* Always use eMMC (mmcblkX) boot0 if no
+* valid image source description found
+*/
+ return 1;
+
+ if (img_src[src_idx].flags & BOOT_SRC_PART1)
+ return 2;
+
+ return 1;
+}
+
void board_boot_order(u32 *spl_boot_list)
{
spl_boot_list[0] = BOOT_DEVICE_MMC1;
--
2.39.2
[PATCH v1 2/3] arm: config: Enable CRC8 support in SPL on imx287 XEA board
The boot0/1 feature uses simple CRC8 to check (in SPL) if SPI-NOR content is not corrupted, hence the need to enable it. Signed-off-by: Lukasz Majewski --- configs/imx28_xea_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/imx28_xea_defconfig b/configs/imx28_xea_defconfig index c1b0487f7e..64a0561a34 100644 --- a/configs/imx28_xea_defconfig +++ b/configs/imx28_xea_defconfig @@ -123,4 +123,5 @@ CONFIG_DM_SERIAL=y CONFIG_SPI=y CONFIG_DM_SPI=y CONFIG_MXS_SPI=y +CONFIG_SPL_CRC8=y # CONFIG_SPL_OF_LIBFDT is not set -- 2.39.2
[PATCH v1 1/3] arm: config: xea: Update environment variables for XEA board (imx287)
As the XEA now supports fitImage, the default envs shall reflect this
as well.
Moreover, some SPI-NOR layout re-organization has took place.
Signed-off-by: Lukasz Majewski
---
include/configs/xea.h | 45 ---
1 file changed, 25 insertions(+), 20 deletions(-)
diff --git a/include/configs/xea.h b/include/configs/xea.h
index 04ca5aa12a..a11bb522cd 100644
--- a/include/configs/xea.h
+++ b/include/configs/xea.h
@@ -33,17 +33,21 @@
"bootsec=sf_swu\0" \
"consdev=ttyAMA0\0" \
"baudrate=115200\0" \
- "dtbaddr=0x4400\0" \
- "dtbfile=imx28-xea.dtb\0" \
"rootdev=/dev/mmcblk0p2\0" \
"netdev=eth0\0" \
- "rdaddr=0x4300\0" \
- "swufile=swupdate.img\0"\
- "sf_kernel_offset=0x10\0" \
- "sf_kernel_size=0x40\0" \
- "sf_swu_offset=0x50\0" \
- "sf_swu_size=0x80\0"\
- "rootpath=/opt/eldk-5.5/armv5te/rootfs-qte-sdk\0" \
+ "swufile=swupdate-image-xea-upd.itb\0" \
+ "sf_kernel_offset=0xA\0"\
+ "sf_swu_size=0xF4\0"\
+ "ethact=FEC\0" \
+ "arch=xea\0"\
+ "serverip=10.8.217.79\0"\
+ "nfs_serverip=10.8.218.113\0" \
+ "gatewayip=10.8.209.250\0" \
+ "lwe_env=" \
+ "if dhcp ${loadaddr} ${hostname}/${lwe_uenv} ; then " \
+ "source ${loadaddr}; " \
+ "fi\0" \
+ "lwe_uenv=env_uboot_xea.bin\0" \
"do_update_mmc="\
"if mmc rescan ; then " \
"mmc dev 0 ${update_mmc_part} ; " \
@@ -60,6 +64,12 @@
"sf write ${loadaddr} ${update_offset} ${filesize} ; " \
"fi ; " \
"fi\0" \
+ "factory_reset="\
+ "if sf probe ; then " \
+ "run update_swu ; " \
+ "setenv bootmode update ; " \
+ "saveenv ; "\
+ "fi\0" \
"update_spl_filename=u-boot.sb\0" \
"update_spl=" \
"setenv update_filename ${update_spl_filename} ; " \
@@ -72,6 +82,8 @@
"run do_update_sf ; " \
"setenv update_mmc_part 1 ; " \
"setenv update_offset 0 ; " \
+ "run do_update_mmc ; " \
+ "setenv update_mmc_part 2 ; " \
"run do_update_mmc\0" \
"update_kernel_filename=uImage\0" \
"update_kernel="\
@@ -82,13 +94,9 @@
"setenv update_filename ${dtbfile} ; " \
"setenv update_offset 0x400 ; " \
"run do_update_mmc\0" \
- "update_sfkernel=" \
- "setenv update_filename fitImage ; "\
- "setenv update_offset ${sf_kernel_offset} ; " \
- "run do_update_sf\0"\
"update_swu=" \
"setenv update_filename ${swufile} ; " \
- "setenv update_offset ${sf_swu_offset} ; " \
+ "setenv
Please pull u-boot-marvell/master
Hi Tom, please pull this next batch of Marvell related patches: - AC5: Use finer grained memory map (Chris) - Espressobin: Misc improvements (Robert) - eDPU: Support new board revision (Robert) Here the Azure build, without any issues: https://dev.azure.com/sr0718/u-boot/_build/results?buildId=331=results Thanks, Stefan The following changes since commit 344667db6450de838bd83f0f57e177e6d4744d89: Merge tag 'smbios-2024-04-rc1' of https://source.denx.de/u-boot/custodians/u-boot-efi (2024-01-09 12:50:04 -0500) are available in the Git repository at: g...@source.denx.de:u-boot/custodians/u-boot-marvell.git for you to fetch changes up to 46471e6c1d58442140259f7e44a5c3e0d6e02351: arm: mvebu: eDPU: support new board revision (2024-01-10 09:38:55 +0100) Chris Packham (1): arm: mvebu: AC5: Use finer grained memory map Robert Marko (3): arm: mvebu: Espressobin: move FDT fixup into a separate function arm: mvebu: Espressobin: move network setup into a separate function arm: mvebu: eDPU: support new board revision arch/arm/dts/armada-3720-eDPU-u-boot.dtsi | 13 ++- arch/arm/dts/armada-3720-eDPU.dts | 47 + arch/arm/mach-mvebu/alleycat5/cpu.c | 66 ++--- board/Marvell/mvebu_armada-37xx/board.c | 159 -- configs/eDPU_defconfig| 1 + 5 files changed, 256 insertions(+), 30 deletions(-)
Re: [PATCH v3 3/3] arm: mvebu: eDPU: support new board revision
On 11/29/23 11:11, Robert Marko wrote:
There is a new eDPU revision that uses Marvell 88E6361 switch onboard.
We can rely on detecting the switch to enable and fixup the Linux DTS
so a single DTS can be used.
There is currently no support for the 88E6361 switch and thus no working
networking in U-Boot, so we disable both ports.
Signed-off-by: Robert Marko
Reviewed-by: Stefan Roese
Applied to u-boot-marvell/master
Thanks,
Stefan
---
Changes in v3:
* Add check for DM_MDIO
arch/arm/dts/armada-3720-eDPU-u-boot.dtsi | 13 ++-
arch/arm/dts/armada-3720-eDPU.dts | 47
board/Marvell/mvebu_armada-37xx/board.c | 128 ++
configs/eDPU_defconfig| 1 +
4 files changed, 184 insertions(+), 5 deletions(-)
diff --git a/arch/arm/dts/armada-3720-eDPU-u-boot.dtsi
b/arch/arm/dts/armada-3720-eDPU-u-boot.dtsi
index cb02b70e54..c3d450dd83 100644
--- a/arch/arm/dts/armada-3720-eDPU-u-boot.dtsi
+++ b/arch/arm/dts/armada-3720-eDPU-u-boot.dtsi
@@ -32,14 +32,17 @@
bootph-all;
};
- {
- /* G.hn does not work without additional configuration */
- status = "disabled";
-};
-
{
fixed-link {
speed = <1000>;
full-duplex;
};
};
+
+/*
+ * eDPU v2 has a MV88E6361 switch on the MDIO bus and U-boot is used
+ * to patch the Linux DTS if its found so enable MDIO by default.
+ */
+ {
+ status = "okay";
+};
diff --git a/arch/arm/dts/armada-3720-eDPU.dts
b/arch/arm/dts/armada-3720-eDPU.dts
index 57fc698e55..d6d37a1f6f 100644
--- a/arch/arm/dts/armada-3720-eDPU.dts
+++ b/arch/arm/dts/armada-3720-eDPU.dts
@@ -12,3 +12,50 @@
{
phy-mode = "2500base-x";
};
+
+/*
+ * External MV88E6361 switch is only available on v2 of the board.
+ * U-Boot will enable the MDIO bus and switch nodes.
+ */
+ {
+ status = "disabled";
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins>;
+
+ /* Actual device is MV88E6361 */
+ switch: switch@0 {
+ compatible = "marvell,mv88e6190";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ label = "cpu";
+ phy-mode = "2500base-x";
+ managed = "in-band-status";
+ ethernet = <>;
+ };
+
+ port@9 {
+ reg = <9>;
+ label = "downlink";
+ phy-mode = "2500base-x";
+ managed = "in-band-status";
+ };
+
+ port@a {
+ reg = <10>;
+ label = "uplink";
+ phy-mode = "2500base-x";
+ managed = "in-band-status";
+ sfp = <_eth1>;
+ };
+ };
+ };
+};
diff --git a/board/Marvell/mvebu_armada-37xx/board.c
b/board/Marvell/mvebu_armada-37xx/board.c
index f532486b70..1685b12b84 100644
--- a/board/Marvell/mvebu_armada-37xx/board.c
+++ b/board/Marvell/mvebu_armada-37xx/board.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -50,6 +51,7 @@ DECLARE_GLOBAL_DATA_PTR;
/* Single-chip mode */
/* Switch Port Registers */
#define MVEBU_SW_LINK_CTRL_REG(1)
+#define MVEBU_SW_PORT_SWITCH_ID(3)
#define MVEBU_SW_PORT_CTRL_REG(4)
#define MVEBU_SW_PORT_BASE_VLAN (6)
@@ -57,6 +59,8 @@ DECLARE_GLOBAL_DATA_PTR;
#define MVEBU_G2_SMI_PHY_CMD_REG (24)
#define MVEBU_G2_SMI_PHY_DATA_REG (25)
+#define SWITCH_88E6361_PRODUCT_NUMBER 0x2610
+
/*
* Memory Controller Registers
*
@@ -73,6 +77,30 @@ DECLARE_GLOBAL_DATA_PTR;
#define A3700_MC_CTRL2_SDRAM_TYPE_DDR32
#define A3700_MC_CTRL2_SDRAM_TYPE_DDR43
+static bool is_edpu_plus(void)
+{
+ struct udevice *bus;
+ ofnode node;
+ int val;
+
+ if (!CONFIG_IS_ENABLED(DM_MDIO))
+ return false;
+
+ node = ofnode_by_compatible(ofnode_null(), "marvell,orion-mdio");
+ if (!ofnode_valid(node) ||
+ uclass_get_device_by_ofnode(UCLASS_MDIO, node, ) ||
+ device_probe(bus)) {
+ printf("Cannot find MDIO bus\n");
+ return -ENODEV;
+ }
+
+ val = dm_mdio_read(bus, 0x0, MDIO_DEVAD_NONE, MVEBU_SW_PORT_SWITCH_ID);
+ if (val == SWITCH_88E6361_PRODUCT_NUMBER)
+ return true;
+ else
+ return false;
+}
+
int board_early_init_f(void)
{
Re: [PATCH v3 2/3] arm: mvebu: Espressobin: move network setup into a separate function
On 11/29/23 11:11, Robert Marko wrote:
Currently, Esspresobin switch is being setup directly in last_stage_init()
which makes it hard to add support for any other board to be setup.
So, lets just move the switch setup code to a separate function and call it
if compatible matches, there should be no functional change.
Signed-off-by: Robert Marko
Reviewed-by: Stefan Roese
Applied to u-boot-marvell/master
Thanks,
Stefan
---
Changes in v2:
* Rebase on top of current master and resolve conflicts
board/Marvell/mvebu_armada-37xx/board.c | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/board/Marvell/mvebu_armada-37xx/board.c
b/board/Marvell/mvebu_armada-37xx/board.c
index 1471caa9a6..f532486b70 100644
--- a/board/Marvell/mvebu_armada-37xx/board.c
+++ b/board/Marvell/mvebu_armada-37xx/board.c
@@ -301,14 +301,12 @@ static int mii_multi_chip_mode_write(struct udevice *bus,
int dev_smi_addr,
return 0;
}
-/* Bring-up board-specific network stuff */
-static int last_stage_init(void)
+static int espressobin_last_stage_init(void)
{
struct udevice *bus;
ofnode node;
- if (!CONFIG_IS_ENABLED(DM_MDIO) ||
- !of_machine_is_compatible("globalscale,espressobin"))
+ if (!CONFIG_IS_ENABLED(DM_MDIO))
return 0;
node = ofnode_by_compatible(ofnode_null(), "marvell,orion-mdio");
@@ -358,8 +356,17 @@ static int last_stage_init(void)
return 0;
}
-EVENT_SPY_SIMPLE(EVT_LAST_STAGE_INIT, last_stage_init);
+/* Bring-up board-specific network stuff */
+static int last_stage_init(void)
+{
+
+ if (of_machine_is_compatible("globalscale,espressobin"))
+ return espressobin_last_stage_init();
+
+ return 0;
+}
+EVENT_SPY_SIMPLE(EVT_LAST_STAGE_INIT, last_stage_init);
#endif
#ifdef CONFIG_OF_BOARD_SETUP
Viele Grüße,
Stefan Roese
--
DENX Software Engineering GmbH, Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: [PATCH v4 8/9] fdt: update the document and Kconfig description
I think this isn't needed anymore after https://lore.kernel.org/u-boot/CAC_iWjJ6=NjqwcFzVvV4DzMWy5nY_QAeD=vfqrrsjodlbvq...@mail.gmail.com/ On Wed, 3 Jan 2024 at 00:14, Raymond Mao wrote: > > Update the document and Kconfig to describe the behavior of board > specific custom functions when CONFIG_OF_BOARD is defined. > > Signed-off-by: Raymond Mao > --- > Changes in v4 > - Refine the description. > > doc/develop/devicetree/control.rst | 6 +++--- > dts/Kconfig| 7 +-- > 2 files changed, 8 insertions(+), 5 deletions(-) > > diff --git a/doc/develop/devicetree/control.rst > b/doc/develop/devicetree/control.rst > index cbb65c9b17..2b968a6b01 100644 > --- a/doc/develop/devicetree/control.rst > +++ b/doc/develop/devicetree/control.rst > @@ -104,9 +104,9 @@ in u-boot.bin so you can still just flash u-boot.bin onto > your board. If you are > using CONFIG_SPL_FRAMEWORK, then u-boot.img will be built to include the > device > tree binary. > > -If CONFIG_OF_BOARD is defined, a board-specific routine will provide the > -devicetree at runtime, for example if an earlier bootloader stage creates > -it and passes it to U-Boot. > +If CONFIG_OF_BOARD is defined, arch-specific routine and board-specific > routine > +will provide the bloblist and devicetree respectively at runtime, for > example if > +an earlier bootloader stage creates it and passes it to U-Boot. > > If CONFIG_SANDBOX is defined, then it will be read from a file on > startup. Use the -d flag to U-Boot to specify the file to read, -D for the > diff --git a/dts/Kconfig b/dts/Kconfig > index 00c0aeff89..ac6e1752bb 100644 > --- a/dts/Kconfig > +++ b/dts/Kconfig > @@ -110,8 +110,11 @@ config OF_BOARD > default y if SANDBOX || OF_HAS_PRIOR_STAGE > help > If this option is enabled, the device tree is provided at runtime by > - a custom function called board_fdt_blob_setup(). The board must > - implement this function if it wishes to provide special behaviour. > + a board custom function called board_fdt_blob_setup(). > + If this option is enabled, bloblist is provided at runtime by an > + arch custom function called xferlist_from_boot_arg(). > + An arch or board must implement these functions if it wishes to > + provide special behaviours. > > With this option, the device tree build by U-Boot may be overridden > or > ignored. See OF_HAS_PRIOR_STAGE. > -- > 2.25.1 >
Re: [PATCH v4 2/9] bloblist: check bloblist with specified buffer size
Hi Raymond
I think my r-b tag got lost across versions
On Wed, 3 Jan 2024 at 00:13, Raymond Mao wrote:
>
> Instead of expecting the bloblist total size to be the same as the
> pre-allocated buffer size, practically we are more interested in
> whether the pre-allocated buffer size is bigger than the bloblist
> total size.
>
> Signed-off-by: Raymond Mao
> ---
> Changes in v2
> - New patch file created for v2.
> Changes in v4
> - Update function header of bloblist_check().
>
> common/bloblist.c | 2 +-
> include/bloblist.h | 9 +
> test/bloblist.c| 2 +-
> 3 files changed, 7 insertions(+), 6 deletions(-)
>
> diff --git a/common/bloblist.c b/common/bloblist.c
> index acf67304d0..4039eb3a03 100644
> --- a/common/bloblist.c
> +++ b/common/bloblist.c
> @@ -384,7 +384,7 @@ int bloblist_check(ulong addr, uint size)
> return log_msg_ret("Bad magic", -ENOENT);
> if (hdr->version != BLOBLIST_VERSION)
> return log_msg_ret("Bad version", -EPROTONOSUPPORT);
> - if (!hdr->total_size || (size && hdr->total_size != size))
> + if (!hdr->total_size || (size && hdr->total_size > size))
> return log_msg_ret("Bad total size", -EFBIG);
> if (hdr->used_size > hdr->total_size)
> return log_msg_ret("Bad used size", -ENOENT);
> diff --git a/include/bloblist.h b/include/bloblist.h
> index bf9e12ebf8..1906847c15 100644
> --- a/include/bloblist.h
> +++ b/include/bloblist.h
> @@ -348,12 +348,13 @@ int bloblist_new(ulong addr, uint size, uint flags,
> uint align_log2);
> * bloblist_check() - Check if a bloblist exists
> *
> * @addr: Address of bloblist
> - * @size: Expected size of blobsize, or 0 to detect the size
> + * @size: Reserved space size for blobsize, or 0 to use the total size
> * Return: 0 if OK, -ENOENT if the magic number doesn't match (indicating
> that
> - * there problem is no bloblist at the given address), -EPROTONOSUPPORT
> + * there problem is no bloblist at the given address) or any fields for
> header
> + * size, used size and total size do not match, -EPROTONOSUPPORT
> * if the version does not match, -EIO if the checksum does not match,
> - * -EFBIG if the expected size does not match the detected size, -ENOSPC
> - * if the size is not large enough to hold the headers
> + * -EFBIG if the reserved space size is small than the total size or total
> size
> + * is 0
> */
> int bloblist_check(ulong addr, uint size);
>
> diff --git a/test/bloblist.c b/test/bloblist.c
> index 17d9dd03d0..7dab9addf8 100644
> --- a/test/bloblist.c
> +++ b/test/bloblist.c
> @@ -207,7 +207,7 @@ static int bloblist_test_checksum(struct unit_test_state
> *uts)
> hdr->flags++;
>
> hdr->total_size--;
> - ut_asserteq(-EFBIG, bloblist_check(TEST_ADDR, TEST_BLOBLIST_SIZE));
> + ut_asserteq(-EIO, bloblist_check(TEST_ADDR, TEST_BLOBLIST_SIZE));
> hdr->total_size++;
>
> hdr->spare++;
> --
> 2.25.1
>
Reviewed-by: Ilias Apalodimas
Re: [PATCH v3 1/3] arm: mvebu: Espressobin: move FDT fixup into a separate function
On 11/29/23 11:11, Robert Marko wrote:
Currently, Esspresobin FDT is being fixed up directly in ft_board_setup()
which makes it hard to add support for any other board to be fixed up.
So, lets just move the FDT fixup code to a separate function and call it
if compatible matches, there should be no functional change.
Signed-off-by: Robert Marko
Reviewed-by: Stefan Roese
Applied to u-boot-marvell/master
Thanks,
Stefan
---
board/Marvell/mvebu_armada-37xx/board.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/board/Marvell/mvebu_armada-37xx/board.c
b/board/Marvell/mvebu_armada-37xx/board.c
index 04124d8014..1471caa9a6 100644
--- a/board/Marvell/mvebu_armada-37xx/board.c
+++ b/board/Marvell/mvebu_armada-37xx/board.c
@@ -363,18 +363,14 @@ EVENT_SPY_SIMPLE(EVT_LAST_STAGE_INIT, last_stage_init);
#endif
#ifdef CONFIG_OF_BOARD_SETUP
-int ft_board_setup(void *blob, struct bd_info *bd)
+static int espressobin_fdt_setup(void *blob)
{
-#ifdef CONFIG_ENV_IS_IN_SPI_FLASH
int ret;
int spi_off;
int parts_off;
int part_off;
/* Fill SPI MTD partitions for Linux kernel on Espressobin */
- if (!of_machine_is_compatible("globalscale,espressobin"))
- return 0;
-
spi_off = fdt_node_offset_by_compatible(blob, -1, "jedec,spi-nor");
if (spi_off < 0)
return 0;
@@ -459,6 +455,14 @@ int ft_board_setup(void *blob, struct bd_info *bd)
return 0;
}
+ return 0;
+}
+
+int ft_board_setup(void *blob, struct bd_info *bd)
+{
+#ifdef CONFIG_ENV_IS_IN_SPI_FLASH
+ if (of_machine_is_compatible("globalscale,espressobin"))
+ return espressobin_fdt_setup(blob);
#endif
return 0;
}
Viele Grüße,
Stefan Roese
--
DENX Software Engineering GmbH, Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: [PATCH] arm: mvebu: AC5: Use finer grained memory map
On 10/27/23 02:44, Chris Packham wrote:
The ATF implementation for AC5/AC5X ends up with bl31 living in some
internal SRAM. This is in the middle of the large MMIO region that we
were using. Adjust this to be finer grained blocks based on the address
map from the AC5X Family Control and Management Subsystem Functional
Datasheet.
Signed-off-by: Chris Packham
Applied to u-boot-marvell/master
Thanks,
Stefan
---
arch/arm/mach-mvebu/alleycat5/cpu.c | 66 ++---
1 file changed, 51 insertions(+), 15 deletions(-)
diff --git a/arch/arm/mach-mvebu/alleycat5/cpu.c
b/arch/arm/mach-mvebu/alleycat5/cpu.c
index 8204d9627515..0f72ae1709be 100644
--- a/arch/arm/mach-mvebu/alleycat5/cpu.c
+++ b/arch/arm/mach-mvebu/alleycat5/cpu.c
@@ -16,7 +16,10 @@
DECLARE_GLOBAL_DATA_PTR;
-#define RAM_SIZE SZ_1G
+#define AC5_PTE_BLOCK_DEVICE \
+ (PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) | \
+PTE_BLOCK_NON_SHARE | \
+PTE_BLOCK_PXN | PTE_BLOCK_UXN)
static struct mm_region ac5_mem_map[] = {
{
@@ -31,30 +34,63 @@ static struct mm_region ac5_mem_map[] = {
.phys = 0x,
.virt = 0xa000,
.size = 0x10,
-
- .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
-PTE_BLOCK_NON_SHARE |
-PTE_BLOCK_PXN | PTE_BLOCK_UXN
+ .attrs = AC5_PTE_BLOCK_DEVICE,
},
{
/* MMIO regions */
.phys = 0x10,
.virt = 0x10,
.size = 0x3ff0,
-
- .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
-PTE_BLOCK_NON_SHARE |
-PTE_BLOCK_PXN | PTE_BLOCK_UXN
+ .attrs = AC5_PTE_BLOCK_DEVICE,
},
{
- /* MMIO regions */
.phys = 0x7F00,
.virt = 0x7F00,
- .size = 0x2100,
-
- .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
-PTE_BLOCK_NON_SHARE |
-PTE_BLOCK_PXN | PTE_BLOCK_UXN
+ .size = SZ_8M,
+ .attrs = AC5_PTE_BLOCK_DEVICE,
+ },
+ {
+ .phys = 0x7F80,
+ .virt = 0x7F80,
+ .size = SZ_4M,
+ .attrs = AC5_PTE_BLOCK_DEVICE,
+ },
+ {
+ .phys = 0x7FC0,
+ .virt = 0x7FC0,
+ .size = SZ_512K,
+ .attrs = AC5_PTE_BLOCK_DEVICE,
+ },
+ {
+ .phys = 0x7FC8,
+ .virt = 0x7FC8,
+ .size = SZ_512K,
+ .attrs = AC5_PTE_BLOCK_DEVICE,
+ },
+ {
+ .phys = 0x7FD0,
+ .virt = 0x7FD0,
+ .size = SZ_512K,
+ .attrs = AC5_PTE_BLOCK_DEVICE,
+ },
+ /* ATF region 0x7FE0-0x7FE2 not mapped */
+ {
+ .phys = 0x7FE8,
+ .virt = 0x7FE8,
+ .size = SZ_512K,
+ .attrs = AC5_PTE_BLOCK_DEVICE,
+ },
+ {
+ .phys = 0x7FFF,
+ .virt = 0x7FFF,
+ .size = SZ_1M,
+ .attrs = AC5_PTE_BLOCK_DEVICE,
+ },
+ {
+ .phys = 0x8000,
+ .virt = 0x8000,
+ .size = SZ_2G,
+ .attrs = AC5_PTE_BLOCK_DEVICE,
},
{
0,
Viele Grüße,
Stefan Roese
--
DENX Software Engineering GmbH, Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: [PATCH v2 1/2] efi_loader: auto-generate boot option for each blkio device
On 26.12.23 07:28, Masahisa Kojima wrote:
Current efibootmgr auto-generates the boot option for all
disks and partitions installing EFI_SIMPLE_FILE_SYSTEM_PROTOCOL,
while EDK II reference implementation auto-generates the boot option
for all devices installing EFI_BLOCK_IO_PROTOCOL with
eliminating logical partitions.
This commit modifies the efibootmgr to get aligned to EDK II.
Signed-off-by: Masahisa Kojima
---
lib/efi_loader/efi_bootmgr.c | 94 +++-
1 file changed, 71 insertions(+), 23 deletions(-)
diff --git a/lib/efi_loader/efi_bootmgr.c b/lib/efi_loader/efi_bootmgr.c
index 56d97f2382..747f75ee82 100644
--- a/lib/efi_loader/efi_bootmgr.c
+++ b/lib/efi_loader/efi_bootmgr.c
@@ -560,6 +560,50 @@ err:
return ret;
}
+/**
+ * try_load_from_media() - load file from media
+ *
+ * @file_path: file path
+ * @handle:pointer to handle for newly installed image
Please, use the same description as in try_load_entry():
on return handle for the newly installed image
+ *
+ * If @file_path contains a file name, load the file.
+ * If @file_path does not have a file name, search the architecture-specific
+ * default file and load it.
+ * TODO: If the FilePathList[0] device does not support
+ * EFI_SIMPLE_FILE_SYSTEM_PROTOCOL but supports EFI_BLOCK_IO_PROTOCOL,
+ * call EFI_BOOT_SERVICES.ConnectController()
+ * TODO: FilePathList[0] device supports EFI_SIMPLE_FILE_SYSTEM_PROTOCOL
+ * not based on EFI_BLOCK_IO_PROTOCOL
+ *
+ * Return: status code
+ */
+static efi_status_t try_load_from_media(struct efi_device_path *file_path,
+ efi_handle_t *handle)
%s/handle/handle_img/
or h_img
+{
+ efi_handle_t h;
%s/h/handle_blkdev/
or h_blkdev
+ efi_status_t ret = EFI_SUCCESS;
+ struct efi_device_path *rem, *dp = NULL;
+ struct efi_device_path *final_dp = file_path;
+
+ h = efi_dp_find_obj(file_path, _block_io_guid, );
+ if (h) {
+ if (rem->type == DEVICE_PATH_TYPE_END) {
+ /* no file name present, try default file */
+ ret = check_disk_has_default_file(h->dev, );
check_disk_has_default_file() does not only check for a default file
path , i.e. EFI/BOOT/BOO.EFI, but will check for a given file
path, if provided. In a later patch we should rename this function to
something less misleading.
+ if (ret != EFI_SUCCESS)
+ return ret;
+
+ final_dp = dp;
+ }
+ }
+
+ ret = EFI_CALL(efi_load_image(true, efi_root, final_dp, NULL, 0,
handle));
+
+ efi_free_pool(dp);
+
+ return ret;
+}
+
/**
* try_load_entry() - try to load image for boot option
*
@@ -594,7 +638,6 @@ static efi_status_t try_load_entry(u16 n, efi_handle_t
*handle,
}
if (lo.attributes & LOAD_OPTION_ACTIVE) {
- struct efi_device_path *file_path;
u32 attributes;
log_debug("trying to load \"%ls\" from %pD\n", lo.label,
@@ -611,10 +654,7 @@ static efi_status_t try_load_entry(u16 n, efi_handle_t
*handle,
else
ret = EFI_LOAD_ERROR;
} else {
- file_path = expand_media_path(lo.file_path);
- ret = EFI_CALL(efi_load_image(true, efi_root, file_path,
- NULL, 0, handle));
- efi_free_pool(file_path);
+ ret = try_load_from_media(lo.file_path, handle);
}
if (ret != EFI_SUCCESS) {
log_warning("Loading %ls '%ls' failed\n",
@@ -748,19 +788,19 @@ error:
* efi_bootmgr_enumerate_boot_option() - enumerate the possible bootable media
%s/efi_bootmgr_enumerate_boot_option/efi_bootmgr_enumerate_boot_options/
*
* @opt: pointer to the media boot option structure
- * @volume_handles:pointer to the efi handles
+ * @handles: pointer to the efi handles
%s/efi/EFI/
"pointer to the efi handles" could be handles for anything.
%s/pointer to the efi handles/pointer to block device handles/
We should move the call to LocateBufferHandle into this function as the
caller does not use handles.
* @count:number of efi handle
On entry number of handles to block devices.
On exit number of boot options.
* Return:status code
*/
static efi_status_t efi_bootmgr_enumerate_boot_option(struct
eficonfig_media_boot_option *opt,
- efi_handle_t
*volume_handles,
- efi_status_t count)
+ efi_handle_t *handles,
+ efi_uintn_t *count)
{
- u32 i;
+ u32 i, num = 0;
struct
[PATCH] arm64: xilinx: Move address/size-cells to proper locations
Move cells to board dtsi files from generic zynqmp.dtsi. Changes are
related to qspi, spi, nand, i2c and ethernet nodes.
All errors are generated when dtbs are compiled with W=1.
Signed-off-by: Michal Simek
---
arch/arm/dts/zynqmp-a2197-revA.dts | 4
arch/arm/dts/zynqmp-dlc21-revA.dts | 4
arch/arm/dts/zynqmp-e-a2197-00-revA.dts | 4
arch/arm/dts/zynqmp-g-a2197-00-revA.dts | 2 ++
arch/arm/dts/zynqmp-m-a2197-01-revA.dts | 8 +++-
arch/arm/dts/zynqmp-m-a2197-02-revA.dts | 8 +++-
arch/arm/dts/zynqmp-m-a2197-03-revA.dts | 8 +++-
arch/arm/dts/zynqmp-p-a2197-00-revA.dts | 4
arch/arm/dts/zynqmp-sc-revB.dts | 4
arch/arm/dts/zynqmp-sc-vn-p-b2197-00-revA.dtso | 3 ---
arch/arm/dts/zynqmp-sm-k26-revA.dts | 6 ++
.../arm/dts/zynqmp-topic-miamimp-xilinx-xdp-v1r1.dts | 2 ++
arch/arm/dts/zynqmp-vp-x-a2785-00-revA.dts | 6 ++
arch/arm/dts/zynqmp-vpk120-revA.dts | 6 ++
arch/arm/dts/zynqmp-zc1232-revA.dts | 2 ++
arch/arm/dts/zynqmp-zc1254-revA.dts | 2 ++
arch/arm/dts/zynqmp-zc1751-xm015-dc1.dts | 4
arch/arm/dts/zynqmp-zc1751-xm016-dc2.dts | 8
arch/arm/dts/zynqmp-zc1751-xm017-dc3.dts | 4
arch/arm/dts/zynqmp-zc1751-xm018-dc4.dts | 2 ++
arch/arm/dts/zynqmp-zcu100-revC.dts | 2 ++
arch/arm/dts/zynqmp-zcu102-revA.dts | 6 ++
arch/arm/dts/zynqmp-zcu104-revA.dts | 4
arch/arm/dts/zynqmp-zcu104-revC.dts | 4
arch/arm/dts/zynqmp-zcu106-revA.dts | 6 ++
arch/arm/dts/zynqmp-zcu111-revA.dts | 6 ++
arch/arm/dts/zynqmp-zcu1275-revA.dts | 2 ++
arch/arm/dts/zynqmp-zcu1275-revB.dts | 2 ++
arch/arm/dts/zynqmp-zcu1285-revA.dts | 2 ++
arch/arm/dts/zynqmp-zcu208-revA.dts | 6 ++
arch/arm/dts/zynqmp-zcu216-revA.dts | 6 ++
arch/arm/dts/zynqmp-zcu670-revA.dts | 6 ++
arch/arm/dts/zynqmp-zcu670-revB.dts | 6 ++
arch/arm/dts/zynqmp.dtsi | 12
34 files changed, 143 insertions(+), 18 deletions(-)
diff --git a/arch/arm/dts/zynqmp-a2197-revA.dts
b/arch/arm/dts/zynqmp-a2197-revA.dts
index 84167050d10e..d88fd1266005 100644
--- a/arch/arm/dts/zynqmp-a2197-revA.dts
+++ b/arch/arm/dts/zynqmp-a2197-revA.dts
@@ -39,6 +39,8 @@
};
{
+ #address-cells = <1>;
+ #size-cells = <0>;
status = "okay";
bootph-all;
clock-frequency = <40>;
@@ -64,6 +66,8 @@
};
{
+ #address-cells = <1>;
+ #size-cells = <0>;
status = "okay";
bootph-all;
clock-frequency = <40>;
diff --git a/arch/arm/dts/zynqmp-dlc21-revA.dts
b/arch/arm/dts/zynqmp-dlc21-revA.dts
index 2076271ac993..d7549078d889 100644
--- a/arch/arm/dts/zynqmp-dlc21-revA.dts
+++ b/arch/arm/dts/zynqmp-dlc21-revA.dts
@@ -139,6 +139,8 @@
};
{ /* MIO34/35 */
+ #address-cells = <1>;
+ #size-cells = <0>;
status = "okay";
clock-frequency = <40>;
@@ -196,6 +198,8 @@
};
{
+ #address-cells = <1>;
+ #size-cells = <0>;
status = "okay";
is-decoded-cs = <0>;
num-cs = <1>;
diff --git a/arch/arm/dts/zynqmp-e-a2197-00-revA.dts
b/arch/arm/dts/zynqmp-e-a2197-00-revA.dts
index f1b0a4aa65dd..f1bb07555923 100644
--- a/arch/arm/dts/zynqmp-e-a2197-00-revA.dts
+++ b/arch/arm/dts/zynqmp-e-a2197-00-revA.dts
@@ -206,6 +206,8 @@
};
{ /* MIO 34-35 - can't stay here */
+ #address-cells = <1>;
+ #size-cells = <0>;
status = "okay";
clock-frequency = <40>;
@@ -476,6 +478,8 @@
};
{ /* i2c1 MIO 36-37 */
+ #address-cells = <1>;
+ #size-cells = <0>;
status = "okay";
clock-frequency = <40>;
diff --git a/arch/arm/dts/zynqmp-g-a2197-00-revA.dts
b/arch/arm/dts/zynqmp-g-a2197-00-revA.dts
index 36a0db44fd28..54f70337fb5d 100644
--- a/arch/arm/dts/zynqmp-g-a2197-00-revA.dts
+++ b/arch/arm/dts/zynqmp-g-a2197-00-revA.dts
@@ -133,6 +133,8 @@
};
{ /* MIO 34-35 - can't stay here */
+ #address-cells = <1>;
+ #size-cells = <0>;
status = "okay";
clock-frequency = <40>;
scl-gpios = < 34 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
diff --git a/arch/arm/dts/zynqmp-m-a2197-01-revA.dts
b/arch/arm/dts/zynqmp-m-a2197-01-revA.dts
index 83b8a98d80ca..5f74afafa090 100644
--- a/arch/arm/dts/zynqmp-m-a2197-01-revA.dts
+++ b/arch/arm/dts/zynqmp-m-a2197-01-revA.dts
@@ -70,6 +70,8 @@
};
{
+ #address-cells = <1>;
+ #size-cells = <0>;
status = "okay";
num-cs = <2>;
flash@0 {
@@ -163,6 +165,8
[PATCH v2 2/3] doc: board: phytec: Add phyGATE-Tauri board documentation
Add brief documentation on how to build a bootable U-Boot image for the phyGATE-Tauri-L. Signed-off-by: Yannic Moog --- board/phytec/phycore_imx8mm/MAINTAINERS | 2 + doc/board/phytec/imx8mm-phygate-tauri-l.rst | 60 + doc/board/phytec/index.rst | 1 + 3 files changed, 63 insertions(+) diff --git a/board/phytec/phycore_imx8mm/MAINTAINERS b/board/phytec/phycore_imx8mm/MAINTAINERS index 05d48ba2472..cf6f92c07e5 100644 --- a/board/phytec/phycore_imx8mm/MAINTAINERS +++ b/board/phytec/phycore_imx8mm/MAINTAINERS @@ -10,4 +10,6 @@ F:arch/arm/dts/imx8mm-phygate-tauri-l-u-boot.dtsi F: board/phytec/phycore_imx8mm/ F: configs/imx8mm-phygate-tauri-l_defconfig F: configs/phycore-imx8mm_defconfig +F: doc/board/phytec/imx8mm-phygate-tauri-l.rst +F: doc/board/phytec/index.rst F: include/configs/phycore_imx8mm.h diff --git a/doc/board/phytec/imx8mm-phygate-tauri-l.rst b/doc/board/phytec/imx8mm-phygate-tauri-l.rst new file mode 100644 index 000..28b614fd144 --- /dev/null +++ b/doc/board/phytec/imx8mm-phygate-tauri-l.rst @@ -0,0 +1,60 @@ +.. SPDX-License-Identifier: GPL-2.0+ + +phyGATE-Tauri-L-i.MX 8M Mini + + +The phyGATE-Tauri-L-i.MX 8M Mini with 2GB of main memory is supported. + +Quick Start +--- + +- Build the ARM Trusted firmware binary +- Get ddr firmware +- Build U-Boot +- Boot + +Build the ARM Trusted firmware binary +- + +.. code-block:: bash + + $ git clone https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git + $ cd trusted-firmware-a + $ export CROSS_COMPILE=aarch64-linux-gnu + $ export IMX_BOOT_UART_BASE=0x3088 + $ make PLAT=imx8mm bl31 + +Get the ddr firmware + + +.. code-block:: bash + + $ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-8.23.bin + $ chmod +x firmware-imx-8.23.bin + $ ./firmware-imx-8.23.bin + +Build U-Boot for SD card + + +Copy binaries +^ + +.. code-block:: bash + + $ cp /build/imx8mm/release/bl31.bin . + $ cp firmware-imx-8.23/firmware/ddr/synopsys/lpddr4*.bin . + +Build U-Boot + + +.. code-block:: bash + + $ make imx8mm-phygate-tauri-l_defconfig + $ make flash.bin + +Flash SD card +^ + +.. code-block:: bash + + $ sudo dd if=flash.bin of=/dev/sd[x] bs=1024 seek=33 conv=sync diff --git a/doc/board/phytec/index.rst b/doc/board/phytec/index.rst index a5b442045ed..9996bce9741 100644 --- a/doc/board/phytec/index.rst +++ b/doc/board/phytec/index.rst @@ -6,5 +6,6 @@ PHYTEC .. toctree:: :maxdepth: 2 + imx8mm-phygate-tauri-l phycore-imx8mm phycore-imx8mp -- 2.34.1
[PATCH v2 3/3] board: phytec: MAINTAINERS: add missing phytec doc files
Add rst documentation files to the respective MAINTAINERS file for PHYTEC boards. Signed-off-by: Yannic Moog --- board/phytec/phycore_imx8mm/MAINTAINERS | 1 + board/phytec/phycore_imx8mp/MAINTAINERS | 1 + 2 files changed, 2 insertions(+) diff --git a/board/phytec/phycore_imx8mm/MAINTAINERS b/board/phytec/phycore_imx8mm/MAINTAINERS index cf6f92c07e5..e46e3691bac 100644 --- a/board/phytec/phycore_imx8mm/MAINTAINERS +++ b/board/phytec/phycore_imx8mm/MAINTAINERS @@ -12,4 +12,5 @@ F:configs/imx8mm-phygate-tauri-l_defconfig F: configs/phycore-imx8mm_defconfig F: doc/board/phytec/imx8mm-phygate-tauri-l.rst F: doc/board/phytec/index.rst +F: doc/board/phytec/phycore_imx8mm.rst F: include/configs/phycore_imx8mm.h diff --git a/board/phytec/phycore_imx8mp/MAINTAINERS b/board/phytec/phycore_imx8mp/MAINTAINERS index cb7ce558a81..d3beb978d3a 100644 --- a/board/phytec/phycore_imx8mp/MAINTAINERS +++ b/board/phytec/phycore_imx8mp/MAINTAINERS @@ -6,4 +6,5 @@ F: arch/arm/dts/imx8mp-phyboard-pollux-rdk.dts F: arch/arm/dts/imx8mp-phyboard-pollux-rdk-u-boot.dtsi F: board/phytec/phycore_imx8mp/ F: configs/phycore-imx8mp_defconfig +F: doc/board/phytec/phycore-imx8mp.rst F: include/configs/phycore_imx8mp.h -- 2.34.1
[PATCH v2 1/3] Add support for phyGATE-Tauri-L-iMX8MM
phyGATE-Tauri-L-iMX8MM is a Gateway based on the phycore-imx8mm SoM.
As a result, all the board code of the phycore-imx8mm is used.
Device tree synced with kernel v6.7.
Signed-off-by: Yannic Moog
---
arch/arm/dts/Makefile | 1 +
arch/arm/dts/imx8mm-phygate-tauri-l-u-boot.dtsi | 70
arch/arm/dts/imx8mm-phygate-tauri-l.dts | 489
board/phytec/phycore_imx8mm/MAINTAINERS | 3 +
configs/imx8mm-phygate-tauri-l_defconfig| 115 ++
5 files changed, 678 insertions(+)
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 773c2546131..d456a524b36 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1076,6 +1076,7 @@ dtb-$(CONFIG_ARCH_IMX8M) += \
imx8mm-mx8menlo.dtb \
imx8mm-phg.dtb \
imx8mm-phyboard-polis-rdk.dtb \
+ imx8mm-phygate-tauri-l.dtb \
imx8mm-venice.dtb \
imx8mm-venice-gw71xx-0x.dtb \
imx8mm-venice-gw72xx-0x.dtb \
diff --git a/arch/arm/dts/imx8mm-phygate-tauri-l-u-boot.dtsi
b/arch/arm/dts/imx8mm-phygate-tauri-l-u-boot.dtsi
new file mode 100644
index 000..f59f119374f
--- /dev/null
+++ b/arch/arm/dts/imx8mm-phygate-tauri-l-u-boot.dtsi
@@ -0,0 +1,70 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2024 PHYTEC Messtechnik GmbH
+ */
+
+#include "imx8mm-u-boot.dtsi"
+
+/ {
+ wdt-reboot {
+ compatible = "wdt-reboot";
+ wdt = <>;
+ bootph-pre-ram;
+ };
+};
+
+_uart3 {
+ bootph-pre-ram;
+};
+
+_usdhc2_gpio {
+ bootph-pre-ram;
+};
+
+_usdhc2 {
+ bootph-pre-ram;
+};
+
+_usdhc3 {
+ bootph-pre-ram;
+};
+
+_wdog {
+ bootph-pre-ram;
+};
+
+ {
+ bootph-pre-ram;
+};
+
+ {
+ bootph-pre-ram;
+};
+
+ {
+ bootph-pre-ram;
+};
+
+ {
+ bootph-pre-ram;
+};
+
+ {
+ bootph-pre-ram;
+};
+
+ {
+ bootph-pre-ram;
+};
+
+ {
+ bootph-pre-ram;
+};
+
+ {
+ bootph-pre-ram;
+};
+
+ {
+ bootph-pre-ram;
+};
diff --git a/arch/arm/dts/imx8mm-phygate-tauri-l.dts
b/arch/arm/dts/imx8mm-phygate-tauri-l.dts
new file mode 100644
index 000..968f475b9a9
--- /dev/null
+++ b/arch/arm/dts/imx8mm-phygate-tauri-l.dts
@@ -0,0 +1,489 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2023 PHYTEC Messtechnik GmbH
+ */
+
+/dts-v1/;
+
+#include
+#include
+#include "imx8mm-phycore-som.dtsi"
+
+/ {
+ model = "PHYTEC phyGATE-Tauri-L-iMX8MM";
+ compatible = "phytec,imx8mm-phygate-tauri-l",
+"phytec,imx8mm-phycore-som", "fsl,imx8mm";
+
+ chosen {
+ stdout-path =
+ };
+
+ can_osc_40m: clock-can {
+ compatible = "fixed-clock";
+ clock-frequency = <4000>;
+ clock-output-names = "can_osc_40m";
+ #clock-cells = <0>;
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys";
+ pinctrl-names = "default";
+ pinctrl-0 = <_gpiokeys>;
+
+ key {
+ gpios = < 9 GPIO_ACTIVE_LOW>;
+ label = "KEY-A";
+ linux,code = ;
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <_leds>;
+
+ led-1 {
+ color = ;
+ gpios = < 5 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "none";
+ };
+
+ led-2 {
+ color = ;
+ gpios = < 30 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "none";
+ };
+ };
+
+ usdhc1_pwrseq: pwr-seq {
+ compatible = "mmc-pwrseq-simple";
+ post-power-on-delay-ms = <100>;
+ power-off-delay-us = <60>;
+ reset-gpios = < 7 GPIO_ACTIVE_LOW>;
+ };
+
+ reg_usb_hub_vbus: regulator-hub-otg1 {
+ compatible = "regulator-fixed";
+ gpio = < 14 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ pinctrl-names = "default";
+ pinctrl-0 = <_usbhubpwr>;
+ regulator-name = "usb_hub_vbus";
+ regulator-max-microvolt = <500>;
+ regulator-min-microvolt = <500>;
+ };
+
+ reg_usb_otg1_vbus: regulator-usb-otg1 {
+ compatible = "regulator-fixed";
+ gpio = < 12 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ pinctrl-names = "default";
+ pinctrl-0 = <_usbotg1pwr>;
+ regulator-name = "usb_otg1_vbus";
+ regulator-max-microvolt = <500>;
+ regulator-min-microvolt = <500>;
+ };
+
+ reg_usdhc2_vmmc: regulator-usdhc2 {
+ compatible = "regulator-fixed";
+ gpio = < 19
[PATCH v2 0/3] This series adds support for the phyGATE-Tauri-L.
The config is minimal and mostly a copy from the phycore-imx8mm. SPI
(flash) is disabled as it is not populated by default.
Also add documentation for the phyGATE-Tauri-L board. While at it, add
the other PHYTEC doc files to MAINTAINERS; they were missing for
existing phycore-imx8m{m,p} doc.
---
Changes in v2:
- readd TIDP83867; is populated on the SoM by default
- remove remnants from SPI config options (savedefconfig)
- add doc/board/phytec files to MAINTAINERS
---
Yannic Moog (3):
Add support for phyGATE-Tauri-L-iMX8MM
doc: board: phytec: Add phyGATE-Tauri board documentation
board: phytec: MAINTAINERS: add missing phytec doc files
arch/arm/dts/Makefile | 1 +
arch/arm/dts/imx8mm-phygate-tauri-l-u-boot.dtsi | 70
arch/arm/dts/imx8mm-phygate-tauri-l.dts | 489
board/phytec/phycore_imx8mm/MAINTAINERS | 6 +
board/phytec/phycore_imx8mp/MAINTAINERS | 1 +
configs/imx8mm-phygate-tauri-l_defconfig| 115 ++
doc/board/phytec/imx8mm-phygate-tauri-l.rst | 60 +++
doc/board/phytec/index.rst | 1 +
8 files changed, 743 insertions(+)
---
base-commit: c5e461fbf7cc72f0c1c8a79226b6a5170e56cb4d
change-id: 20231220-wip-y-moog-phytec-de-tauri-l_upstream-08c9648ac653
Best regards,
--
Yannic Moog
Re: [PATCH 0/2] arm: dts: Add Itap Delay Value For High Speed DDR
On January 10, 2024 thus sayeth Bhavya Kapoor: > > On 08/01/24 7:35 pm, Bryan Brattlof wrote: > > Hi Bhavya! > > > > On January 8, 2024 thus sayeth Bhavya Kapoor: > > > This Series adds Itap Delay Value for DDR52 speed mode for eMMC in > > > J7200 SoC and for DDR50 speed mode for MMCSD in J721s2 SoC. > > > > > > Bhavya Kapoor (2): > > >arm: dts: k3-j7200-main: Add Itap Delay Value For DDR52 speed mode > > >arm: dts: k3-j721s2-main: Add Itap Delay Value For DDR50 speed mode > > > > > > arch/arm/dts/k3-j7200-main.dtsi | 1 + > > > arch/arm/dts/k3-j721s2-main.dtsi | 1 + > > Because of the periodic syncs with the kernel, modifying these dt files > > in U-Boot will cause confusion. (Which node is correct why did we have > > to do this in U-Boot and not in the Kernel... bla bla bla) If they > > absolutely need to go in now please override these nodes in the > > *-u-boot.dtsi files with a comment so we can keep track of these changes > > during the next sync with Linux. > > > > ~Bryan > > Hi Bryan, Fyi, This patch went in kernel as well. > > Can be tracked below- > > https://lore.kernel.org/all/170266085077.3490141.14935960940418963459.b4...@ti.com/ > > So , kernel and uboot dt files will remain in sync. > Sorry I may be missing something. Why do we need these properties in U-Boot now? Why not wait 2 weeks for the v6.8-rc1 tag in Linux and sync everything all at once? ~Bryan
Re: [PATCH v1] fastboot: introduce 'oem board' subcommand
Sorry, my e-mail client is lagging and I sent two replies.
On Wed, Jan 10, 2024 at 08:03:39AM +, Alexey Romanov wrote:
> Hi,
>
> On Tue, Jan 09, 2024 at 10:45:46AM -0500, Sean Anderson wrote:
> > On 1/9/24 05:27, Alexey Romanov wrote:
> > > Hello Sean!
> > >
> > > Thanks for you reply.
> > >
> > > On Thu, Dec 28, 2023 at 11:45:04AM -0500, Sean Anderson wrote:
> > >> On 12/28/23 10:25, Alexey Romanov wrote:
> > >> > Currently, fastboot protocol in U-Boot has no opportunity
> > >> > to execute vendor custom code with verifed boot.
> > >>
> > >> Well, I would say the most conventional way to do this would be
> > >> something like
> > >>
> > >> => fastboot 0
> > >> => source \# CONFIG_FASTBOOT_BUF_ADDR
> > >>
> > >> and on your host machine,
> > >>
> > >> $ fastboot stage my_script.itb
> > >>
> > >> where my_script.its looks like
> > >>
> > >> /dts-v1/;
> > >>
> > >> / {
> > >> description = "my script";
> > >> #address-cells = <1>;
> > >>
> > >> images {
> > >> my-script {
> > >> data = /incbin/("my_script.scr");
> > >> type = "script";
> > >> arch = "arm64";
> > >> compression = "none";
> > >> hash-1 {
> > >> algo = "sha256";
> > >> };
> > >> };
> > >> };
> > >>
> > >> configurations {
> > >> default = "conf";
> > >> conf {
> > >> description = "Load my script";
> > >> script = "my-script";
> > >> signature {
> > >> algo = "sha256,rsa2048";
> > >> key-name-hint = "vboot";
> > >> sign-images = "script";
> > >> };
> > >> };
> > >> };
> > >> };
> > >>
> > >> This method is especially useful to pass complex parameters to your
> > >> command.
> > >> This method of course requires commit bcc85b96b5f ("cmd: source: Support
> > >> specifying config name").
> > >>
> > >> Would it be possible to use the above method for your use case?
> > >
> > > This method sounds good for some cases, but we have encountered some
> > > problems that prevent us from applying it:
> > >
> > > 1. Looks like this method requires access to UART (for typing 'source'
> > > command). Open the UART is unsafe at devices with verified boot.
> >
> > Generally the idea is that you run source after you run fastboot. E.g. you
> > set
> > your altbootcmd (or whatever) to something like
> >
> > while true; fastboot 0; source \# || boot; done
> >
> > so you try to source whatever gets staged, and boot it otherwise.
>
> If I understand right, U-Boot always will try fastboot mode?
> Yes, it seems like it will work. But the code for complex
> fastboot scripts will be complex and difficult to read.
>
> I think my version looks more elegant and simple.
>
> >
> > > 2. We use automation scripts to flash our devices using fastboot
> > > protocol. A typical example of flashing scripts (device is already in
> > > fastboot mode):
> > >
> > > $ fastboot erase bootloader
> > > $ fastboot stage bootloader.img
> > > $ fastboot oem board:write_bootloader
> > >
> > > $ fastboot reboot-bootloader
> > >
> > > $ fastboot erase super
> > > $ fastboot flash super super.bin
> > >
> > > $ fastboot reboot
> > >
> > > This method doesn't assume what something typing additional command in
> > > U-Boot shell, even if we have access to UART.
> >
> > I'm curious what you actual usage for this is? That is, what do you need
> > a custom command for.
>
> Our SoC vendor use custom scheme for flashing bootloader partition.
> So we can't just use fastbooot flash command - we have to use custom
> flashing logic. We also don't want to use hacks in generic fastboot
> code, for example something like this in _fb_nand_write():
>
> ...
>
> if (!strcmp(part->name, "bootloader"))
> write_bootloader_custom_logic(...)
> else
> nand_write_skip_bad(...)
>
> ...
>
> >
> > --Sean
> >
> > >>
> > >> --Sean
> > >>
> > >> > This patch
> > >> > introduce new fastboot subcommand fastboot oem board:,
> > >> > which allow to run custom oem_board function.
> > >> > =
> > >> > Default implementation is __weak. Vendor must redefine it in
> > >> > board/ folder with his own logic.
> > >> >
> > >> > For example, some vendors have their custom nand/emmc partition
> > >> > flashing or erasing. Here some typical command for such use cases:
> > >> >
> > >> > - flashing:
> > >> >
> > >> > $ fastboot stage bootloader.img
> > >> > $ fastboot oem board:write_bootloader
> > >> >
> > >> > - erasing:
> > >> >
> > >> > $ fastboot oem board:erase_env
> > >> >
> > >> > Signed-off-by: Alexey Romanov
> > >> > ---
> > >> > drivers/fastboot/Kconfig | 7 +++
> > >> > drivers/fastboot/fb_command.c | 15 +++
> > >> > include/fastboot.h| 1 +
> > >> > 3 files changed, 23 insertions(+)
> > >> >
> > >> > diff --git a/drivers/fastboot/Kconfig b/drivers/fastboot/Kconfig
Re: [PATCH v1] fastboot: introduce 'oem board' subcommand
Hi,
On Tue, Jan 09, 2024 at 10:45:46AM -0500, Sean Anderson wrote:
> On 1/9/24 05:27, Alexey Romanov wrote:
> > Hello Sean!
> >
> > Thanks for you reply.
> >
> > On Thu, Dec 28, 2023 at 11:45:04AM -0500, Sean Anderson wrote:
> >> On 12/28/23 10:25, Alexey Romanov wrote:
> >> > Currently, fastboot protocol in U-Boot has no opportunity
> >> > to execute vendor custom code with verifed boot.
> >>
> >> Well, I would say the most conventional way to do this would be something
> >> like
> >>
> >> => fastboot 0
> >> => source \# CONFIG_FASTBOOT_BUF_ADDR
> >>
> >> and on your host machine,
> >>
> >> $ fastboot stage my_script.itb
> >>
> >> where my_script.its looks like
> >>
> >> /dts-v1/;
> >>
> >> / {
> >> description = "my script";
> >> #address-cells = <1>;
> >>
> >> images {
> >> my-script {
> >> data = /incbin/("my_script.scr");
> >> type = "script";
> >> arch = "arm64";
> >> compression = "none";
> >> hash-1 {
> >> algo = "sha256";
> >> };
> >> };
> >> };
> >>
> >> configurations {
> >> default = "conf";
> >> conf {
> >> description = "Load my script";
> >> script = "my-script";
> >> signature {
> >> algo = "sha256,rsa2048";
> >> key-name-hint = "vboot";
> >> sign-images = "script";
> >> };
> >> };
> >> };
> >> };
> >>
> >> This method is especially useful to pass complex parameters to your
> >> command.
> >> This method of course requires commit bcc85b96b5f ("cmd: source: Support
> >> specifying config name").
> >>
> >> Would it be possible to use the above method for your use case?
> >
> > This method sounds good for some cases, but we have encountered some
> > problems that prevent us from applying it:
> >
> > 1. Looks like this method requires access to UART (for typing 'source'
> > command). Open the UART is unsafe at devices with verified boot.
>
> Generally the idea is that you run source after you run fastboot. E.g. you set
> your altbootcmd (or whatever) to something like
>
> while true; fastboot 0; source \# || boot; done
>
> so you try to source whatever gets staged, and boot it otherwise.
If I understand right, U-Boot always will try fastboot mode?
Yes, it seems like it will work. But the code for complex
fastboot scripts will be complex and difficult to read.
I think my version looks more elegant and simple.
>
> > 2. We use automation scripts to flash our devices using fastboot
> > protocol. A typical example of flashing scripts (device is already in
> > fastboot mode):
> >
> > $ fastboot erase bootloader
> > $ fastboot stage bootloader.img
> > $ fastboot oem board:write_bootloader
> >
> > $ fastboot reboot-bootloader
> >
> > $ fastboot erase super
> > $ fastboot flash super super.bin
> >
> > $ fastboot reboot
> >
> > This method doesn't assume what something typing additional command in
> > U-Boot shell, even if we have access to UART.
>
> I'm curious what you actual usage for this is? That is, what do you need
> a custom command for.
Our SoC vendor use custom scheme for flashing bootloader partition.
So we can't just use fastbooot flash command - we have to use custom
flashing logic. We also don't want to use hacks in generic fastboot
code, for example something like this in _fb_nand_write():
...
if (!strcmp(part->name, "bootloader"))
write_bootloader_custom_logic(...)
else
nand_write_skip_bad(...)
...
>
> --Sean
>
> >>
> >> --Sean
> >>
> >> > This patch
> >> > introduce new fastboot subcommand fastboot oem board:,
> >> > which allow to run custom oem_board function.
> >> > =
> >> > Default implementation is __weak. Vendor must redefine it in
> >> > board/ folder with his own logic.
> >> >
> >> > For example, some vendors have their custom nand/emmc partition
> >> > flashing or erasing. Here some typical command for such use cases:
> >> >
> >> > - flashing:
> >> >
> >> > $ fastboot stage bootloader.img
> >> > $ fastboot oem board:write_bootloader
> >> >
> >> > - erasing:
> >> >
> >> > $ fastboot oem board:erase_env
> >> >
> >> > Signed-off-by: Alexey Romanov
> >> > ---
> >> > drivers/fastboot/Kconfig | 7 +++
> >> > drivers/fastboot/fb_command.c | 15 +++
> >> > include/fastboot.h| 1 +
> >> > 3 files changed, 23 insertions(+)
> >> >
> >> > diff --git a/drivers/fastboot/Kconfig b/drivers/fastboot/Kconfig
> >> > index 3cfeea4837..4c955cabab 100644
> >> > --- a/drivers/fastboot/Kconfig
> >> > +++ b/drivers/fastboot/Kconfig
> >> > @@ -241,6 +241,13 @@ config FASTBOOT_OEM_RUN
> >> >this feature if you are using verified boot, as it will allow
> >> > an
> >> >attacker to bypass any restrictions you have in place.
> >> >
> >> > +config FASTBOOT_OEM_BOARD
> >> > +bool "Enable the 'oem board' command"
>
Re: [PATCH 0/2] arm: dts: Add Itap Delay Value For High Speed DDR
On 08/01/24 7:35 pm, Bryan Brattlof wrote: Hi Bhavya! On January 8, 2024 thus sayeth Bhavya Kapoor: This Series adds Itap Delay Value for DDR52 speed mode for eMMC in J7200 SoC and for DDR50 speed mode for MMCSD in J721s2 SoC. Bhavya Kapoor (2): arm: dts: k3-j7200-main: Add Itap Delay Value For DDR52 speed mode arm: dts: k3-j721s2-main: Add Itap Delay Value For DDR50 speed mode arch/arm/dts/k3-j7200-main.dtsi | 1 + arch/arm/dts/k3-j721s2-main.dtsi | 1 + Because of the periodic syncs with the kernel, modifying these dt files in U-Boot will cause confusion. (Which node is correct why did we have to do this in U-Boot and not in the Kernel... bla bla bla) If they absolutely need to go in now please override these nodes in the *-u-boot.dtsi files with a comment so we can keep track of these changes during the next sync with Linux. ~Bryan Hi Bryan, Fyi, This patch went in kernel as well. Can be tracked below- https://lore.kernel.org/all/170266085077.3490141.14935960940418963459.b4...@ti.com/ So , kernel and uboot dt files will remain in sync. ~B-Kapoor
[PATCH 2/2] doc: board: phytec: Add phyGATE-Tauri board documentation
Add brief documentation on how to build a bootable U-Boot image for the phyGATE-Tauri-L. Signed-off-by: Yannic Moog --- doc/board/phytec/imx8mm-phygate-tauri-l.rst | 60 + doc/board/phytec/index.rst | 1 + 2 files changed, 61 insertions(+) diff --git a/doc/board/phytec/imx8mm-phygate-tauri-l.rst b/doc/board/phytec/imx8mm-phygate-tauri-l.rst new file mode 100644 index 000..28b614fd144 --- /dev/null +++ b/doc/board/phytec/imx8mm-phygate-tauri-l.rst @@ -0,0 +1,60 @@ +.. SPDX-License-Identifier: GPL-2.0+ + +phyGATE-Tauri-L-i.MX 8M Mini + + +The phyGATE-Tauri-L-i.MX 8M Mini with 2GB of main memory is supported. + +Quick Start +--- + +- Build the ARM Trusted firmware binary +- Get ddr firmware +- Build U-Boot +- Boot + +Build the ARM Trusted firmware binary +- + +.. code-block:: bash + + $ git clone https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git + $ cd trusted-firmware-a + $ export CROSS_COMPILE=aarch64-linux-gnu + $ export IMX_BOOT_UART_BASE=0x3088 + $ make PLAT=imx8mm bl31 + +Get the ddr firmware + + +.. code-block:: bash + + $ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-8.23.bin + $ chmod +x firmware-imx-8.23.bin + $ ./firmware-imx-8.23.bin + +Build U-Boot for SD card + + +Copy binaries +^ + +.. code-block:: bash + + $ cp /build/imx8mm/release/bl31.bin . + $ cp firmware-imx-8.23/firmware/ddr/synopsys/lpddr4*.bin . + +Build U-Boot + + +.. code-block:: bash + + $ make imx8mm-phygate-tauri-l_defconfig + $ make flash.bin + +Flash SD card +^ + +.. code-block:: bash + + $ sudo dd if=flash.bin of=/dev/sd[x] bs=1024 seek=33 conv=sync diff --git a/doc/board/phytec/index.rst b/doc/board/phytec/index.rst index a5b442045ed..9996bce9741 100644 --- a/doc/board/phytec/index.rst +++ b/doc/board/phytec/index.rst @@ -6,5 +6,6 @@ PHYTEC .. toctree:: :maxdepth: 2 + imx8mm-phygate-tauri-l phycore-imx8mm phycore-imx8mp -- 2.34.1
[PATCH 1/2] Add support for phyGATE-Tauri-L-iMX8MM
phyGATE-Tauri-L-iMX8MM is a Gateway based on the phycore-imx8mm SoM.
As a result, all the board code of the phycore-imx8mm is used.
Device tree synced with kernel v6.7.
Signed-off-by: Yannic Moog
---
arch/arm/dts/Makefile | 1 +
arch/arm/dts/imx8mm-phygate-tauri-l-u-boot.dtsi | 70
arch/arm/dts/imx8mm-phygate-tauri-l.dts | 489
board/phytec/phycore_imx8mm/MAINTAINERS | 3 +
configs/imx8mm-phygate-tauri-l_defconfig| 117 ++
5 files changed, 680 insertions(+)
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 773c2546131..d456a524b36 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1076,6 +1076,7 @@ dtb-$(CONFIG_ARCH_IMX8M) += \
imx8mm-mx8menlo.dtb \
imx8mm-phg.dtb \
imx8mm-phyboard-polis-rdk.dtb \
+ imx8mm-phygate-tauri-l.dtb \
imx8mm-venice.dtb \
imx8mm-venice-gw71xx-0x.dtb \
imx8mm-venice-gw72xx-0x.dtb \
diff --git a/arch/arm/dts/imx8mm-phygate-tauri-l-u-boot.dtsi
b/arch/arm/dts/imx8mm-phygate-tauri-l-u-boot.dtsi
new file mode 100644
index 000..f59f119374f
--- /dev/null
+++ b/arch/arm/dts/imx8mm-phygate-tauri-l-u-boot.dtsi
@@ -0,0 +1,70 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2024 PHYTEC Messtechnik GmbH
+ */
+
+#include "imx8mm-u-boot.dtsi"
+
+/ {
+ wdt-reboot {
+ compatible = "wdt-reboot";
+ wdt = <>;
+ bootph-pre-ram;
+ };
+};
+
+_uart3 {
+ bootph-pre-ram;
+};
+
+_usdhc2_gpio {
+ bootph-pre-ram;
+};
+
+_usdhc2 {
+ bootph-pre-ram;
+};
+
+_usdhc3 {
+ bootph-pre-ram;
+};
+
+_wdog {
+ bootph-pre-ram;
+};
+
+ {
+ bootph-pre-ram;
+};
+
+ {
+ bootph-pre-ram;
+};
+
+ {
+ bootph-pre-ram;
+};
+
+ {
+ bootph-pre-ram;
+};
+
+ {
+ bootph-pre-ram;
+};
+
+ {
+ bootph-pre-ram;
+};
+
+ {
+ bootph-pre-ram;
+};
+
+ {
+ bootph-pre-ram;
+};
+
+ {
+ bootph-pre-ram;
+};
diff --git a/arch/arm/dts/imx8mm-phygate-tauri-l.dts
b/arch/arm/dts/imx8mm-phygate-tauri-l.dts
new file mode 100644
index 000..968f475b9a9
--- /dev/null
+++ b/arch/arm/dts/imx8mm-phygate-tauri-l.dts
@@ -0,0 +1,489 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2023 PHYTEC Messtechnik GmbH
+ */
+
+/dts-v1/;
+
+#include
+#include
+#include "imx8mm-phycore-som.dtsi"
+
+/ {
+ model = "PHYTEC phyGATE-Tauri-L-iMX8MM";
+ compatible = "phytec,imx8mm-phygate-tauri-l",
+"phytec,imx8mm-phycore-som", "fsl,imx8mm";
+
+ chosen {
+ stdout-path =
+ };
+
+ can_osc_40m: clock-can {
+ compatible = "fixed-clock";
+ clock-frequency = <4000>;
+ clock-output-names = "can_osc_40m";
+ #clock-cells = <0>;
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys";
+ pinctrl-names = "default";
+ pinctrl-0 = <_gpiokeys>;
+
+ key {
+ gpios = < 9 GPIO_ACTIVE_LOW>;
+ label = "KEY-A";
+ linux,code = ;
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <_leds>;
+
+ led-1 {
+ color = ;
+ gpios = < 5 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "none";
+ };
+
+ led-2 {
+ color = ;
+ gpios = < 30 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "none";
+ };
+ };
+
+ usdhc1_pwrseq: pwr-seq {
+ compatible = "mmc-pwrseq-simple";
+ post-power-on-delay-ms = <100>;
+ power-off-delay-us = <60>;
+ reset-gpios = < 7 GPIO_ACTIVE_LOW>;
+ };
+
+ reg_usb_hub_vbus: regulator-hub-otg1 {
+ compatible = "regulator-fixed";
+ gpio = < 14 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ pinctrl-names = "default";
+ pinctrl-0 = <_usbhubpwr>;
+ regulator-name = "usb_hub_vbus";
+ regulator-max-microvolt = <500>;
+ regulator-min-microvolt = <500>;
+ };
+
+ reg_usb_otg1_vbus: regulator-usb-otg1 {
+ compatible = "regulator-fixed";
+ gpio = < 12 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ pinctrl-names = "default";
+ pinctrl-0 = <_usbotg1pwr>;
+ regulator-name = "usb_otg1_vbus";
+ regulator-max-microvolt = <500>;
+ regulator-min-microvolt = <500>;
+ };
+
+ reg_usdhc2_vmmc: regulator-usdhc2 {
+ compatible = "regulator-fixed";
+ gpio = < 19
[PATCH 0/2] This series adds support for the phyGATE-Tauri-L.
The config is minimal and mostly a copy from the phycore-imx8mm. TI PHY and SPI (flash) are disabled as they are not populated by default. --- Yannic Moog (2): Add support for phyGATE-Tauri-L-iMX8MM doc: board: phytec: Add phyGATE-Tauri board documentation arch/arm/dts/Makefile | 1 + arch/arm/dts/imx8mm-phygate-tauri-l-u-boot.dtsi | 70 arch/arm/dts/imx8mm-phygate-tauri-l.dts | 489 board/phytec/phycore_imx8mm/MAINTAINERS | 3 + configs/imx8mm-phygate-tauri-l_defconfig| 117 ++ doc/board/phytec/imx8mm-phygate-tauri-l.rst | 60 +++ doc/board/phytec/index.rst | 1 + 7 files changed, 741 insertions(+) --- base-commit: c5e461fbf7cc72f0c1c8a79226b6a5170e56cb4d change-id: 20231220-wip-y-moog-phytec-de-tauri-l_upstream-08c9648ac653 Best regards, -- Yannic Moog
Re: [PATCH v4 07/11] doc: devicetree: Align documentation to use Kconfig options
On Wed, 10 Jan 2024 at 18:01, Fabio Estevam wrote: > > On Wed, Jan 10, 2024 at 7:37 AM Sumit Garg wrote: > > > History > > --- > > > > -U-Boot configuration was previous done using CONFIG options in the board > > +U-Boot configuration was previous done using Kconfig options in the board > > config file. This eventually got out of hand with nearly 10,000 options. > > It seems that the original text should be preserved here. Ah, you are right. I can preserve that in the next spin if I receive further feedback otherwise I hope Tom can fix it up while applying. -Sumit
[PATCH v4 5/6] mmc: bcmstb: Add support for bcm2712 SD controller
Borrow SD quirks from vendor Linux driver.
"BCM2712 unfortunately carries with it a perennial bug with the SD
controller register interface present on previous chips (2711/2709/2708).
Accesses must be dword-sized and a read-modify-write cycle to the 32-bit
registers containing the COMMAND, TRANSFER_MODE, BLOCK_SIZE and
BLOCK_COUNT registers tramples the upper/lower 16 bits of data written.
BCM2712 does not seem to need the extreme delay between each write as on
previous chips, just the serialisation of writes to these registers in a
single 32-bit operation."
Signed-off-by: Ivan T. Ivanov
---
drivers/mmc/bcmstb_sdhci.c | 173 -
1 file changed, 172 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/bcmstb_sdhci.c b/drivers/mmc/bcmstb_sdhci.c
index dc96818cff..21489e66c0 100644
--- a/drivers/mmc/bcmstb_sdhci.c
+++ b/drivers/mmc/bcmstb_sdhci.c
@@ -38,6 +38,16 @@
*/
#define BCMSTB_SDHCI_MINIMUM_CLOCK_FREQUENCY 40
+#define SDIO_CFG_CTRL 0x0
+#define SDIO_CFG_CTRL_SDCD_N_TEST_EN BIT(31)
+#define SDIO_CFG_CTRL_SDCD_N_TEST_LEV BIT(30)
+
+#define SDIO_CFG_SD_PIN_SEL0x44
+#define SDIO_CFG_SD_PIN_SEL_MASK 0x3
+#define SDIO_CFG_SD_PIN_SEL_CARD BIT(1)
+
+#define REG_OFFSET_IN_BITS(reg) ((reg) << 3 & 0x18)
+
/*
* This driver has only been tested with eMMC devices; SD devices may
* not work.
@@ -47,6 +57,53 @@ struct sdhci_bcmstb_plat {
struct mmc mmc;
};
+struct sdhci_bcmstb_host {
+ struct sdhci_host host;
+ u32 shadow_cmd;
+ u32 shadow_blk;
+ bool is_cmd_shadowed;
+ bool is_blk_shadowed;
+};
+
+struct sdhci_brcmstb_dev_priv {
+ int (*init)(struct udevice *dev);
+ struct sdhci_ops *ops;
+};
+
+static inline struct sdhci_bcmstb_host *to_bcmstb_host(struct sdhci_host *host)
+{
+ return container_of(host, struct sdhci_bcmstb_host, host);
+}
+
+static int sdhci_brcmstb_init_2712(struct udevice *dev)
+{
+ struct sdhci_host *host = dev_get_priv(dev);
+ void *cfg_regs;
+ u32 reg;
+
+ /* Map in the non-standard CFG registers */
+ cfg_regs = dev_remap_addr_name(dev, "cfg");
+ if (!cfg_regs)
+ return -ENOENT;
+
+ if ((host->mmc->host_caps & MMC_CAP_NONREMOVABLE) ||
+ (host->mmc->host_caps & MMC_CAP_NEEDS_POLL)) {
+ /* Force presence */
+ reg = readl(cfg_regs + SDIO_CFG_CTRL);
+ reg &= ~SDIO_CFG_CTRL_SDCD_N_TEST_LEV;
+ reg |= SDIO_CFG_CTRL_SDCD_N_TEST_EN;
+ writel(reg, cfg_regs + SDIO_CFG_CTRL);
+ } else {
+ /* Enable card detection line */
+ reg = readl(cfg_regs + SDIO_CFG_SD_PIN_SEL);
+ reg &= ~SDIO_CFG_SD_PIN_SEL_MASK;
+ reg |= SDIO_CFG_SD_PIN_SEL_CARD;
+ writel(reg, cfg_regs + SDIO_CFG_SD_PIN_SEL);
+ }
+
+ return 0;
+}
+
static int sdhci_bcmstb_bind(struct udevice *dev)
{
struct sdhci_bcmstb_plat *plat = dev_get_plat(dev);
@@ -58,10 +115,14 @@ static int sdhci_bcmstb_probe(struct udevice *dev)
{
struct mmc_uclass_priv *upriv = dev_get_uclass_priv(dev);
struct sdhci_bcmstb_plat *plat = dev_get_plat(dev);
- struct sdhci_host *host = dev_get_priv(dev);
+ struct sdhci_bcmstb_host *bcmstb = dev_get_priv(dev);
+ struct sdhci_host *host = >host;
+ struct sdhci_brcmstb_dev_priv *dev_priv;
fdt_addr_t base;
int ret;
+ dev_priv = (struct sdhci_brcmstb_dev_priv *)dev_get_driver_data(dev);
+
base = dev_read_addr(dev);
if (base == FDT_ADDR_T_NONE)
return -EINVAL;
@@ -75,6 +136,10 @@ static int sdhci_bcmstb_probe(struct udevice *dev)
host->mmc = >mmc;
host->mmc->dev = dev;
+
+ if (dev_priv && dev_priv->ops)
+ host->ops = dev_priv->ops;
+
ret = sdhci_setup_cfg(>cfg, host,
BCMSTB_SDHCI_MAXIMUM_CLOCK_FREQUENCY,
BCMSTB_SDHCI_MINIMUM_CLOCK_FREQUENCY);
@@ -84,10 +149,116 @@ static int sdhci_bcmstb_probe(struct udevice *dev)
upriv->mmc = >mmc;
host->mmc->priv = host;
+ if (dev_priv && dev_priv->init) {
+ ret = dev_priv->init(dev);
+ if (ret)
+ return ret;
+ }
+
return sdhci_probe(dev);
}
+static u16 sdhci_brcmstb_32bits_readw(struct sdhci_host *host, int reg)
+{
+ struct sdhci_bcmstb_host *bcmstb = to_bcmstb_host(host);
+ u16 word;
+ u32 val;
+
+ if (reg == SDHCI_TRANSFER_MODE && bcmstb->is_cmd_shadowed) {
+ /* Get the saved transfer mode */
+ val = bcmstb->shadow_cmd;
+ } else if ((reg == SDHCI_BLOCK_SIZE || reg == SDHCI_BLOCK_COUNT) &&
+ bcmstb->is_blk_shadowed) {
+ /* Get the saved block info */
+ val =
[PATCH] arm64: zynqmp: Remove ltc2954 node
Remove already disabled node. GPIO connections are handled by pmufw that's
why there is no reason to have it described for non secure firmware.
If someone wants to handle it from OS revert this patch and also update
PMUFW configuration and pinctrl setting for these GPIO pins.
Signed-off-by: Michal Simek
---
arch/arm/dts/zynqmp-zcu100-revC.dts | 9 -
1 file changed, 9 deletions(-)
diff --git a/arch/arm/dts/zynqmp-zcu100-revC.dts
b/arch/arm/dts/zynqmp-zcu100-revC.dts
index 49d5cdbba585..c5945067cd57 100644
--- a/arch/arm/dts/zynqmp-zcu100-revC.dts
+++ b/arch/arm/dts/zynqmp-zcu100-revC.dts
@@ -103,15 +103,6 @@
};
};
- ltc2954: ltc2954 { /* U7 */
- compatible = "lltc,ltc2954", "lltc,ltc2952";
- status = "disabled";
- trigger-gpios = < 26 GPIO_ACTIVE_LOW>; /* INT line - input
*/
- /* If there is HW watchdog on mezzanine this signal should be
connected there */
- watchdog-gpios = < 35 GPIO_ACTIVE_HIGH>; /* MIO on PAD */
- kill-gpios = < 34 GPIO_ACTIVE_LOW>; /* KILL signal -
output */
- };
-
wmmcsdio_fixed: fixedregulator-mmcsdio {
compatible = "regulator-fixed";
regulator-name = "wmmcsdio_fixed";
--
2.36.1
Re: [PATCH v4 07/11] doc: devicetree: Align documentation to use Kconfig options
On Wed, Jan 10, 2024 at 7:37 AM Sumit Garg wrote: > History > --- > > -U-Boot configuration was previous done using CONFIG options in the board > +U-Boot configuration was previous done using Kconfig options in the board > config file. This eventually got out of hand with nearly 10,000 options. It seems that the original text should be preserved here.
[PATCH v4 4/6] bcm2835: Dynamically calculate bytes per pixel parameter
brcm,bcm2708-fb device provided by firmware on RPi5 uses
16 bits per pixel, so lets calculate framebuffer bytes
per pixel dynamically based on queried information.
Tested to work for RPi2b v1.2, RPi3b v1.3, RPi4b v1.1,
RPi2 Zero W, RPi5b v1.0.
Signed-off-by: Ivan T. Ivanov
---
drivers/video/bcm2835.c | 18 --
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/drivers/video/bcm2835.c b/drivers/video/bcm2835.c
index 14942526f1..63efa762db 100644
--- a/drivers/video/bcm2835.c
+++ b/drivers/video/bcm2835.c
@@ -16,7 +16,7 @@ static int bcm2835_video_probe(struct udevice *dev)
struct video_uc_plat *plat = dev_get_uclass_plat(dev);
struct video_priv *uc_priv = dev_get_uclass_priv(dev);
int ret;
- int w, h, pitch;
+ int w, h, pitch, bpp;
ulong fb_base, fb_size, fb_start, fb_end;
debug("bcm2835: Query resolution...\n");
@@ -41,9 +41,23 @@ static int bcm2835_video_probe(struct udevice *dev)
DCACHE_WRITEBACK);
video_set_flush_dcache(dev, true);
+ bpp = pitch / w;
+ switch (bpp) {
+ case 2:
+ uc_priv->bpix = VIDEO_BPP16;
+ break;
+ case 4:
+ uc_priv->bpix = VIDEO_BPP32;
+ break;
+ default:
+ printf("bcm2835: unexpected bpp %d, pitch %d, width %d\n",
+ bpp, pitch, w);
+ uc_priv->bpix = VIDEO_BPP32;
+ break;
+ }
+
uc_priv->xsize = w;
uc_priv->ysize = h;
- uc_priv->bpix = VIDEO_BPP32;
plat->base = fb_base;
plat->size = fb_size;
--
2.35.3
[PATCH v4 6/6] configs: rpi_arm64: enable SDHCI BCMSTB driver
RPi5 have "brcm,bcm2712-sdhci" controller which is handled by "sdhci-bcmstb" driver, so enable it. Signed-off-by: Ivan T. Ivanov --- configs/rpi_arm64_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/rpi_arm64_defconfig b/configs/rpi_arm64_defconfig index 08bb30b1d7..11ede9435d 100644 --- a/configs/rpi_arm64_defconfig +++ b/configs/rpi_arm64_defconfig @@ -33,6 +33,7 @@ CONFIG_BCM2835_GPIO=y CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_SDMA=y CONFIG_MMC_SDHCI_BCM2835=y +CONFIG_MMC_SDHCI_BCMSTB=y CONFIG_BCMGENET=y CONFIG_PCI_BRCMSTB=y CONFIG_PINCTRL=y -- 2.35.3
[PATCH v4 3/6] rpi5: Use devicetree to retrieve board revision
Firmware on RPi5 return error on board revision query
through firmware interface, but on the other hand it fills
"linux,revision" in "system" node, so use it to detect board
revision.
system {
linux,revision = <0xc04170>;
linux,serial = <0x6cf44e80 0x3c533ede>;
};
Reviewed-by: Matthias Brugger
Signed-off-by: Ivan T. Ivanov
---
board/raspberrypi/rpi/rpi.c | 22 +++---
1 file changed, 19 insertions(+), 3 deletions(-)
diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c
index cd823ad746..2851ebc985 100644
--- a/board/raspberrypi/rpi/rpi.c
+++ b/board/raspberrypi/rpi/rpi.c
@@ -171,6 +171,11 @@ static const struct rpi_model rpi_models_new_scheme[] = {
DTB_DIR "bcm2711-rpi-cm4.dtb",
true,
},
+ [0x17] = {
+ "5 Model B",
+ DTB_DIR "bcm2712-rpi-5-b.dtb",
+ true,
+ },
};
static const struct rpi_model rpi_models_old_scheme[] = {
@@ -429,15 +434,27 @@ static void get_board_revision(void)
int ret;
const struct rpi_model *models;
uint32_t models_count;
+ ofnode node;
BCM2835_MBOX_INIT_HDR(msg);
BCM2835_MBOX_INIT_TAG(>get_board_rev, GET_BOARD_REV);
ret = bcm2835_mbox_call_prop(BCM2835_MBOX_PROP_CHAN, >hdr);
if (ret) {
- printf("bcm2835: Could not query board revision\n");
/* Ignore error; not critical */
- return;
+ node = ofnode_path("/system");
+ if (!ofnode_valid(node)) {
+ printf("bcm2835: Could not find /system node\n");
+ return;
+ }
+
+ ret = ofnode_read_u32(node, "linux,revision", );
+ if (ret) {
+ printf("bcm2835: Could not find linux,revision\n");
+ return;
+ }
+ } else {
+ revision = msg->get_board_rev.body.resp.rev;
}
/*
@@ -451,7 +468,6 @@ static void get_board_revision(void)
*
http://www.raspberrypi.org/forums/viewtopic.php?f=63=98367=250
* http://www.raspberrypi.org/forums/viewtopic.php?f=31=20594
*/
- revision = msg->get_board_rev.body.resp.rev;
if (revision & 0x80) {
rev_scheme = 1;
rev_type = (revision >> 4) & 0xff;
--
2.35.3
[PATCH v4 2/6] rpi5: Use devicetree as alternative way to read IO base addresses
From: Dmitry Malkin
MBOX and Watchdog on RPi5/bcm2712 has a different base IO offsets.
Find them via devicetree blob passed by bootloader.
Signed-off-by: Dmitry Malkin
Reviewed-by: Matthias Brugger
Signed-off-by: Ivan T. Ivanov
---
arch/arm/mach-bcm283x/include/mach/base.h | 5 ++-
arch/arm/mach-bcm283x/include/mach/mbox.h | 3 +-
arch/arm/mach-bcm283x/include/mach/sdhci.h | 3 +-
arch/arm/mach-bcm283x/include/mach/timer.h | 3 +-
arch/arm/mach-bcm283x/include/mach/wdog.h | 3 +-
arch/arm/mach-bcm283x/init.c | 43 ++
6 files changed, 43 insertions(+), 17 deletions(-)
diff --git a/arch/arm/mach-bcm283x/include/mach/base.h
b/arch/arm/mach-bcm283x/include/mach/base.h
index 4ccaf69693..6de99e7ea1 100644
--- a/arch/arm/mach-bcm283x/include/mach/base.h
+++ b/arch/arm/mach-bcm283x/include/mach/base.h
@@ -6,7 +6,10 @@
#ifndef _BCM283x_BASE_H_
#define _BCM283x_BASE_H_
-extern unsigned long rpi_bcm283x_base;
+extern unsigned long rpi_mbox_base;
+extern unsigned long rpi_timer_base;
+extern unsigned long rpi_sdhci_base;
+extern unsigned long rpi_wdog_base;
#ifdef CONFIG_ARMV7_LPAE
#ifdef CONFIG_TARGET_RPI_4_32B
diff --git a/arch/arm/mach-bcm283x/include/mach/mbox.h
b/arch/arm/mach-bcm283x/include/mach/mbox.h
index 490664f878..35d4e2f075 100644
--- a/arch/arm/mach-bcm283x/include/mach/mbox.h
+++ b/arch/arm/mach-bcm283x/include/mach/mbox.h
@@ -38,8 +38,7 @@
/* Raw mailbox HW */
-#define BCM2835_MBOX_PHYSADDR ({ BUG_ON(!rpi_bcm283x_base); \
-rpi_bcm283x_base + 0xb880; })
+#define BCM2835_MBOX_PHYSADDR rpi_mbox_base
struct bcm2835_mbox_regs {
u32 read;
diff --git a/arch/arm/mach-bcm283x/include/mach/sdhci.h
b/arch/arm/mach-bcm283x/include/mach/sdhci.h
index 7323690687..e837c679c4 100644
--- a/arch/arm/mach-bcm283x/include/mach/sdhci.h
+++ b/arch/arm/mach-bcm283x/include/mach/sdhci.h
@@ -8,8 +8,7 @@
#include
-#define BCM2835_SDHCI_PHYSADDR ({ BUG_ON(!rpi_bcm283x_base); \
- rpi_bcm283x_base + 0x0030; })
+#define BCM2835_SDHCI_PHYSADDR rpi_sdhci_base
int bcm2835_sdhci_init(u32 regbase, u32 emmc_freq);
diff --git a/arch/arm/mach-bcm283x/include/mach/timer.h
b/arch/arm/mach-bcm283x/include/mach/timer.h
index 5567dbd7f3..60500a256d 100644
--- a/arch/arm/mach-bcm283x/include/mach/timer.h
+++ b/arch/arm/mach-bcm283x/include/mach/timer.h
@@ -11,8 +11,7 @@
#include
#endif
-#define BCM2835_TIMER_PHYSADDR ({ BUG_ON(!rpi_bcm283x_base); \
- rpi_bcm283x_base + 0x3000; })
+#define BCM2835_TIMER_PHYSADDR rpi_timer_base
#define BCM2835_TIMER_CS_M3(1 << 3)
#define BCM2835_TIMER_CS_M2(1 << 2)
diff --git a/arch/arm/mach-bcm283x/include/mach/wdog.h
b/arch/arm/mach-bcm283x/include/mach/wdog.h
index 9942666720..b950560674 100644
--- a/arch/arm/mach-bcm283x/include/mach/wdog.h
+++ b/arch/arm/mach-bcm283x/include/mach/wdog.h
@@ -8,8 +8,7 @@
#include
-#define BCM2835_WDOG_PHYSADDR ({ BUG_ON(!rpi_bcm283x_base); \
-rpi_bcm283x_base + 0x0010; })
+#define BCM2835_WDOG_PHYSADDR rpi_wdog_base
struct bcm2835_wdog_regs {
u32 unknown0[7];
diff --git a/arch/arm/mach-bcm283x/init.c b/arch/arm/mach-bcm283x/init.c
index f1a0c8588d..016bc1eb41 100644
--- a/arch/arm/mach-bcm283x/init.c
+++ b/arch/arm/mach-bcm283x/init.c
@@ -146,7 +146,11 @@ static void rpi_update_mem_map(void)
static void rpi_update_mem_map(void) {}
#endif
-unsigned long rpi_bcm283x_base = 0x3f00;
+/* Default bcm283x devices addresses */
+unsigned long rpi_mbox_base = 0x3f00b880;
+unsigned long rpi_sdhci_base = 0x3f30;
+unsigned long rpi_wdog_base = 0x3f10;
+unsigned long rpi_timer_base = 0x3f003000;
int arch_cpu_init(void)
{
@@ -157,22 +161,45 @@ int arch_cpu_init(void)
int mach_cpu_init(void)
{
- int ret, soc_offset;
+ int ret, soc, offset;
u64 io_base, size;
rpi_update_mem_map();
/* Get IO base from device tree */
- soc_offset = fdt_path_offset(gd->fdt_blob, "/soc");
- if (soc_offset < 0)
- return soc_offset;
+ soc = fdt_path_offset(gd->fdt_blob, "/soc");
+ if (soc < 0)
+ return soc;
- ret = fdt_read_range((void *)gd->fdt_blob, soc_offset, 0, NULL,
- _base, );
+ ret = fdt_read_range((void *)gd->fdt_blob, soc, 0, NULL,
+_base, );
if (ret)
return ret;
- rpi_bcm283x_base = io_base;
+ rpi_mbox_base = io_base + 0x00b880;
+ rpi_sdhci_base = io_base + 0x30;
+ rpi_wdog_base = io_base + 0x10;
+ rpi_timer_base = io_base + 0x003000;
+
+ offset = fdt_node_offset_by_compatible(gd->fdt_blob, soc,
+ "brcm,bcm2835-mbox");
+ if (offset > soc)
+ rpi_mbox_base = fdt_get_base_address(gd->fdt_blob, offset);
+
+ offset =
[PATCH v4 1/6] rpi5: add initial memory map for bcm2712
From: Dmitry Malkin
This includes:
* 1GB of RAM (from 4GB or 8GB total)
* AXI ranges (main peripherals)
When HDMI cable is plugged in at boot time firmware will
insert "simple-framebuffer" device into devicetree and will
shrink first memory region to 0x3f80UL. Board setup then
will properly reserve frameboofer region.
When no HDMI cable is plugged in size of the region will be
0x3fc0UL.
Signed-off-by: Dmitry Malkin
Signed-off-by: Ivan T. Ivanov
---
arch/arm/mach-bcm283x/init.c | 31 +++
1 file changed, 31 insertions(+)
diff --git a/arch/arm/mach-bcm283x/init.c b/arch/arm/mach-bcm283x/init.c
index 7265faf6ce..f1a0c8588d 100644
--- a/arch/arm/mach-bcm283x/init.c
+++ b/arch/arm/mach-bcm283x/init.c
@@ -68,6 +68,36 @@ static struct mm_region bcm2711_mem_map[MEM_MAP_MAX_ENTRIES]
= {
}
};
+static struct mm_region bcm2712_mem_map[MEM_MAP_MAX_ENTRIES] = {
+ {
+ /* First 1GB of DRAM */
+ .virt = 0xUL,
+ .phys = 0xUL,
+ .size = 0x4000UL,
+ .attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
+PTE_BLOCK_INNER_SHARE
+ }, {
+ /* Beginning of AXI bus where uSD controller lives */
+ .virt = 0x10UL,
+ .phys = 0x10UL,
+ .size = 0x000200UL,
+ .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
+PTE_BLOCK_NON_SHARE |
+PTE_BLOCK_PXN | PTE_BLOCK_UXN
+ }, {
+ /* SoC bus */
+ .virt = 0x107c00UL,
+ .phys = 0x107c00UL,
+ .size = 0x000400UL,
+ .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
+PTE_BLOCK_NON_SHARE |
+PTE_BLOCK_PXN | PTE_BLOCK_UXN
+ }, {
+ /* List terminator */
+ 0,
+ }
+};
+
struct mm_region *mem_map = bcm283x_mem_map;
/*
@@ -78,6 +108,7 @@ static const struct udevice_id board_ids[] = {
{ .compatible = "brcm,bcm2837", .data = (ulong)_mem_map},
{ .compatible = "brcm,bcm2838", .data = (ulong)_mem_map},
{ .compatible = "brcm,bcm2711", .data = (ulong)_mem_map},
+ { .compatible = "brcm,bcm2712", .data = (ulong)_mem_map},
{ },
};
--
2.35.3
[PATCH v4 0/6] rpi5: initial support
Hi, These patches are slight update for patches posted earlier here[1]. They are adding basic support for RPi5 and are based on v2 series from Dmitry Malkin[2]. What changed: * Initial memory map now includes whole first 1GB of DRAM. At runtime, the firmware will adjust this size depending on whether an HDMI cable is plugged in or not. If there is HDMI monitor connected it will reserve framebufer memory region and will add simple-framebuffer device into devicetree. * Dynamically calculate bits per pixel in video driver. This works on all prevous RPi's models that I have. * I am dropping PCIe patch for now. I made some progress on porting changes from vendor Linux tree to U-Boot. Unfortunatly testing it is little bit tricky. They are many devices behind PCIe, but more or less all of them requires missing either "reset-controller" or "clock-controller" or "pin-controller" drivers. I was able to probe "cdns,macb" device, but access to ethernet PHY over MDIO bus is stucking. Then I ported "raspberrypi,rp1-adc" driver from vendor Linux tree, but it requires missing clock. And on top of that machine that I used for developing this crashed and I lost my PCIe changes :-|. Anyway. These patches allows me to boot current openSUSE Tumbleweed without modification. I can see serial console log and boot process on HDMI connected monitor. I think these patches should be enough for start. Please consider for inclusion. Thanks, Ivan [1] https://lore.kernel.org/all/20231218210341.30073-1-iiva...@suse.de/ [2] https://lore.kernel.org/all/CAKRNjQ0dsWozGo4n8g58m4cCEk3n=qx1r+l24wbgpo-ip1y...@mail.gmail.com/ Dmitry Malkin (2): rpi5: add initial memory map for bcm2712 rpi5: Use devicetree as alternative way to read IO base addresses Ivan T. Ivanov (4): rpi5: Use devicetree to retrieve board revision bcm2835: Dynamically calculate bytes per pixel parameter mmc: bcmstb: Add support for bcm2712 SD controller configs: rpi_arm64: enable SDHCI BCMSTB driver arch/arm/mach-bcm283x/include/mach/base.h | 5 +- arch/arm/mach-bcm283x/include/mach/mbox.h | 3 +- arch/arm/mach-bcm283x/include/mach/sdhci.h | 3 +- arch/arm/mach-bcm283x/include/mach/timer.h | 3 +- arch/arm/mach-bcm283x/include/mach/wdog.h | 3 +- arch/arm/mach-bcm283x/init.c | 74 - board/raspberrypi/rpi/rpi.c| 22 ++- configs/rpi_arm64_defconfig| 1 + drivers/mmc/bcmstb_sdhci.c | 173 - drivers/video/bcm2835.c| 18 ++- 10 files changed, 282 insertions(+), 23 deletions(-) -- 2.35.3
Re: inconsistent wget behavior
Hi Paul, On Fri, Jan 5, 2024 at 4:19 PM Fabio Estevam wrote: > > I tried to investigate this by U-boot sandbox. But it seems to me that I > > cannot reproduce this issue. > > I put a file on localhost apache server and tried to download it from > > localhost. > > I might need a more persistent way to reproduce this bug. > > Do you still have access to the imx8mm-cl-iot-gate board? > > I am sure you would be able to reproduce it with it. One colleague from you at Linaro was able to reproduce the bug: https://lore.kernel.org/u-boot/cadq0-x_cj1ecn67u3sefcz-jm4obsymzka+jazrca3ekq84...@mail.gmail.com/ It is not specific to i.MX. Thanks
Re: [PATCH v3] arch: arm: Kconfig: Enable BOOTSTD_FULL for Rockchip SoCs
Hi Kever, On Tue, Jan 9, 2024 at 10:55 AM Kever Yang wrote: > > Hi Shantur, Tom, > > On 2023/12/10 04:45, Tom Rini wrote: > > On Sat, Dec 09, 2023 at 07:49:04PM +, Shantur Rathore wrote: > >> On Sat, Dec 9, 2023 at 7:18 PM Tom Rini wrote: > >>> On Fri, Dec 08, 2023 at 10:52:02AM +, Shantur Rathore wrote: > >>> > Hi Tom / Kever > > On Sun, Nov 19, 2023 at 5:24 PM Shantur Rathore wrote: > > Rockchip SoCs can support wide range of bootflows. > > Without full bootflow commands, it can be difficult to > > figure out issues if any, hence enable by default. > > > > Reviewed-by: Simon Glass > > > > Signed-off-by: Shantur Rathore > > --- > > > > (no changes since v1) > > > > arch/arm/Kconfig | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > > index d812685c98..fca6ef6d7e 100644 > > --- a/arch/arm/Kconfig > > +++ b/arch/arm/Kconfig > > @@ -1986,6 +1986,7 @@ config ARCH_ROCKCHIP > > imply CMD_DM > > imply DEBUG_UART_BOARD_INIT > > imply BOOTSTD_DEFAULTS > > + imply BOOTSTD_FULL if BOOTSTD_DEFAULTS > > imply FAT_WRITE > > imply SARADC_ROCKCHIP > > imply SPL_SYSRESET > Can this please be merged in ? > >>> I wonder if we shouldn't really globally default to BOOTSTD_FULL if > >>> BOOTSTD_DEFAULTS for everyone. > >>> > >> Its matter of ~21KB in size, unless any platform is really to its > >> limits it should be alright. > > Maybe I need to re-check things too, since I wonder how much of that > > growth is re-enabling things that were removed when dropping the DISTRO > > stuff, and so for platforms just migrating over now it would be smaller > > in size if much. > > A board maintainer is free to enable this option, but I don't agree to > enable this for everyone. > > Not like rk3399 and rk3588, some of other SoCs always want a clean and > simple but usable U-Boot, > > eg. rk3036 and rk3308 are still in the list. > The discussion is what we consider "usable U-Boot" By default bootstd doesn't have any options and not even to show what it's going to boot. Would it be acceptable if BOOTSTD_FULL is enabled for SoCs rather than boards? Kind regards, Shantur
Re: [RFC PATCH 12/16] arm: dts: k3-am65x-binman: Add ICSSG2 overlay and configuration
On 10/01/2024 11:02, MD Danish Anwar wrote:
>
>
> On 10/01/24 2:24 pm, Roger Quadros wrote:
>> On 10/01/2024 08:50, MD Danish Anwar wrote:
>>> Hi Roger,
>>>
>>> On 27/12/23 3:49 pm, MD Danish Anwar wrote:
On 20/12/23 4:10 pm, Roger Quadros wrote:
>
>
> On 19/12/2023 12:34, MD Danish Anwar wrote:
>> Add ICSSG2 overlay and configuration to tispl and u-boot images.
>>
>> Signed-off-by: MD Danish Anwar
>> ---
>> arch/arm/dts/k3-am65x-binman.dtsi | 85 +++
>> 1 file changed, 85 insertions(+)
>>
>> diff --git a/arch/arm/dts/k3-am65x-binman.dtsi
>> b/arch/arm/dts/k3-am65x-binman.dtsi
>> index 8cc24da1f3..9a0c0fca47 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;
>> +};
>
> This is wrong.
>
> ICSSG2 Ethernet should be part of the fdt-0 configuration as the 2
> Ethernet ports
> on the board are hardwired to ICSSG2. Not having them working by default
> is an invalid configuration.
>
ICSSG2 ethernet ports should be enabled by default. But the ICSSG2 nodes
is added in the overlay file (k3-am654-icssg2.dtso) in kernel so they
are added in same overlay file in u-boot as well.
I am keeping,
fdt-0 as k3-am654-base-board dtb,
fdt-1 as k3-am654-icssg2 dtbo,
conf-0 as k3-am654-base-board and
conf-1 as k3-am654-icssg2.
Do you want me to keep k3-am654-icssg2 dtbo as fdt-0 and
k3-am654-base-board as fdt-1? I tried doing this but this results into
u-boot getting stuck. The tispl and u-boot images are not able to load
if I swap fdt-0 and fdt-1 , and conf-0 and conf-1.
If the current combination doesn't look OK, please let me know what
should be the correct combinations for fdt-0, fdt-1, conf-0 and conf-1.
>>>
>>> Can you please comment on this. I'll send v2 with all the suggested
>>> changes once you confirm the correct fdt and configurations.
>>>
>> Sorry, I missed this.
>>
>> fdt-0 = k3-am654-base-board dtb
>> fdt-1 = k3-am654-icssg2 dtbo
>>
>> conf-0 = fdt-0 and ftd-1
>>
>
> What about conf-1? Should I leave it as it is(currently conf-1 is fdt-0
> and fdt-1)?
I don't think we need conf-1.
>
>> as icssg2 ethernet is present on the base board, and should be part of the
>> base board configuration.
>>
>
--
cheers,
-roger
