Re: [PATCH 0/5] DFU: new entity types and minor improvements
Hi Jaehoon, On 20.12.2020 23:17, Jaehoon Chung wrote: > On 12/17/20 9:10 PM, Marek Szyprowski wrote: >> This patchset adds support for SKIP and SCRIPT entity types to the DFU >> subsystem. They significantly extends the flexibility of the DFU >> subsystem. Together with the recently posted 'Add MBR partition table >> creation and verify command' patchset it allows to create the whole >> partition table during the board flashing when one prepares a proper >> script. It also easies the flashing by allowing to use the same images >> for different board variants/types, as each board can now use only the >> relevant images and skip the other ones without returning a failure. > I sent the patch about skip entity. At that time, Lukasz mentioned to update > dfu documentation. > > https://patchwork.ozlabs.org/project/uboot/patch/20201109115757.24601-1-jh80.ch...@samsung.com/ > > Could you update also README.dfu and Minkyu's reviewed-tag about my patch? Thanks for pointing this. I missed that. I will include your v2 patch and also update the readme about the SCRIPT type. Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland
Re: [PATCH 4/6] button: add a simple ADC-based button driver
Hi Simon,
On 19.12.2020 03:28, Simon Glass wrote:
> On Mon, 14 Dec 2020 at 04:25, Marek Szyprowski
> wrote:
>> Add a simple ADC-based button driver. This driver binds to the 'adc-keys'
>> device tree node.
>>
>> Signed-off-by: Marek Szyprowski
>> Change-Id: I6da7101eff3ce53766d899f49f5839d728d52fb3
>> ---
>> drivers/button/Kconfig | 8 +++
>> drivers/button/Makefile | 1 +
>> drivers/button/button-adc.c | 117
>> 3 files changed, 126 insertions(+)
>> create mode 100644 drivers/button/button-adc.c
>>
>> diff --git a/drivers/button/Kconfig b/drivers/button/Kconfig
>> index 6b3ec7e55de..283367f2bd3 100644
>> --- a/drivers/button/Kconfig
>> +++ b/drivers/button/Kconfig
>> @@ -9,6 +9,14 @@ config BUTTON
>>can provide access to board-specific buttons. Use of the device
>> tree
>>for configuration is encouraged.
>>
>> +config BUTTON_ADC
>> + bool "Button adc"
>> + depends on BUTTON
>> + help
>> + Enable support for buttons which are connected to ADC lines. The
>> ADC
>> + driver must use driver model. Buttons are configured using the
>> device
>> + tree.
>> +
>> config BUTTON_GPIO
>> bool "Button gpio"
>> depends on BUTTON
>> diff --git a/drivers/button/Makefile b/drivers/button/Makefile
>> index fcc10ebe8db..bbd18af1494 100644
>> --- a/drivers/button/Makefile
>> +++ b/drivers/button/Makefile
>> @@ -3,4 +3,5 @@
>> # Copyright (C) 2020 Philippe Reynes
>>
>> obj-$(CONFIG_BUTTON) += button-uclass.o
>> +obj-$(CONFIG_BUTTON_ADC) += button-adc.o
>> obj-$(CONFIG_BUTTON_GPIO) += button-gpio.o
>> diff --git a/drivers/button/button-adc.c b/drivers/button/button-adc.c
>> new file mode 100644
>> index 000..086c676c02a
>> --- /dev/null
>> +++ b/drivers/button/button-adc.c
>> @@ -0,0 +1,117 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * Copyright (C) 2020 Samsung Electronics Co., Ltd.
>> + * http://www.samsung.com
>> + * Author: Marek Szyprowski
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
> Please check header order
>
> https://protect2.fireeye.com/v1/url?k=0827922c-57bcaba3-08261963-0cc47a31307c-c2add94742a708a4&q=1&e=e6ddd072-23a6-4591-9ca7-8d41aa498536&u=https%3A%2F%2Fwww.denx.de%2Fwiki%2FU-Boot%2FCodingStyle
>
>> +
>> +struct button_adc_priv {
>> + struct udevice *adc;
>> + int channel;
> comments
>
>> +};
>> +
>> +static enum button_state_t button_adc_get_state(struct udevice *dev)
>> +{
>> + struct button_adc_priv *priv = dev_get_priv(dev);
>> + unsigned int val, mask;
>> + int ret;
>> +
>> + ret = adc_start_channel(priv->adc, priv->channel);
>> + if (ret)
>> + return ret;
>> +
>> + ret = adc_channel_data(priv->adc, priv->channel, &val);
>> + if (ret)
>> + return ret;
>> +
>> + ret = adc_data_mask(priv->adc, &mask);
>> + if (ret)
>> + return ret;
>> +
>> + /* getting state is simplified a bit */
>> + if (ret == 0)
>> + return (val < mask / 2) ? BUTTON_ON : BUTTON_OFF;
>> +
>> + return ret;
>> +}
>> +
>> +static int button_adc_probe(struct udevice *dev)
>> +{
>> + struct button_uc_plat *uc_plat = dev_get_uclass_platdata(dev);
>> + struct button_adc_priv *priv = dev_get_priv(dev);
>> + struct ofnode_phandle_args args;
>> + int ret;
>> +
>> + /* Ignore the top-level button node */
>> + if (!uc_plat->label)
>> + return 0;
>> +
>> + ret = dev_read_phandle_with_args(dev->parent, "io-channels",
>> +"#io-channel-cells", 0, 0, &args);
>> + if (ret)
>> + return ret;
>> +
>> + ret = uclass_get_device_by_name(UCLASS_ADC,
>> ofnode_get_name(args.node),
>> + &priv->adc);
> How about uclass_get_device_by_ofnode() ?
>
>> + if (ret)
>> + return ret;
>> +
>> + priv->channel = args.args[0];
>> +
>> + return ret;
>&
[PATCH v4 1/3] dt-bindings: input: adc-keys bindings documentation
Dump adc-keys bindings documentation from Linux kernel source tree v5.10.
Signed-off-by: Marek Szyprowski
---
doc/device-tree-bindings/input/adc-keys.txt | 49 +
1 file changed, 49 insertions(+)
create mode 100644 doc/device-tree-bindings/input/adc-keys.txt
diff --git a/doc/device-tree-bindings/input/adc-keys.txt
b/doc/device-tree-bindings/input/adc-keys.txt
new file mode 100644
index 00..e551814629
--- /dev/null
+++ b/doc/device-tree-bindings/input/adc-keys.txt
@@ -0,0 +1,49 @@
+ADC attached resistor ladder buttons
+
+
+Required properties:
+ - compatible: "adc-keys"
+ - io-channels: Phandle to an ADC channel
+ - io-channel-names = "buttons";
+ - keyup-threshold-microvolt: Voltage at which all the keys are considered up.
+
+Optional properties:
+ - poll-interval: Poll interval time in milliseconds
+ - autorepeat: Boolean, Enable auto repeat feature of Linux input
+ subsystem.
+
+Each button (key) is represented as a sub-node of "adc-keys":
+
+Required subnode-properties:
+ - label: Descriptive name of the key.
+ - linux,code: Keycode to emit.
+ - press-threshold-microvolt: Voltage ADC input when this key is pressed.
+
+Example:
+
+#include
+
+ adc-keys {
+ compatible = "adc-keys";
+ io-channels = <&lradc 0>;
+ io-channel-names = "buttons";
+ keyup-threshold-microvolt = <200>;
+
+ button-up {
+ label = "Volume Up";
+ linux,code = ;
+ press-threshold-microvolt = <150>;
+ };
+
+ button-down {
+ label = "Volume Down";
+ linux,code = ;
+ press-threshold-microvolt = <100>;
+ };
+
+ button-enter {
+ label = "Enter";
+ linux,code = ;
+ press-threshold-microvolt = <50>;
+ };
+ };
--
2.17.1
[PATCH v4 0/3] VIM3: add support for checking 'Function' button state
Hi All, This patchset adds all building blocks needed for checking the 'Function' button state in the boot script on Amlogic A311D based VIM3 board. This button is connected to the ADC lines of the SoC, so it required to enable meson SARADC, the clocks needed for it and a simple button-adc drivers. Once applied, one can use following commands in the boot scripts: -->8--- echo Checking Func button state: \\c if button Function then echo Selected alternative boot ... fi --->8--- Best regards Marek Szyprowski Samsung R&D Institute Poland Changelog: v4: - rebased onto uboot-amlogic/u-boot-amlogic-next and dropped merged patches - added adc-keys bindings docs (copied from Linux kernel) - minor code adjustments pointed by Simon - enabled driver also in khadas-vim3l_defconfig v3: https://lists.denx.de/pipermail/u-boot/2020-December/435072.html - removed 'button' env variable - extended kconfig and patch descriptions v2: https://lists.denx.de/pipermail/u-boot/2020-December/434991.html - removed Change-Id tags - split defconfig changes into ADC and button related v1: https://lists.denx.de/pipermail/u-boot/2020-December/434875.html - initial submission Patch summary: Marek Szyprowski (3): dt-bindings: input: adc-keys bindings documentation button: add a simple Analog to Digital Converter device based button driver configs: khadas-vim3(l): enable Function button support configs/khadas-vim3_defconfig | 2 + configs/khadas-vim3l_defconfig | 2 + doc/device-tree-bindings/input/adc-keys.txt | 49 drivers/button/Kconfig | 8 ++ drivers/button/Makefile | 1 + drivers/button/button-adc.c | 121 6 files changed, 183 insertions(+) create mode 100644 doc/device-tree-bindings/input/adc-keys.txt create mode 100644 drivers/button/button-adc.c -- 2.17.1
[PATCH v4 2/3] button: add a simple Analog to Digital Converter device based button driver
Add a simple Analog to Digital Converter device based button driver. This
driver binds to the 'adc-keys' device tree node.
Signed-off-by: Marek Szyprowski
---
drivers/button/Kconfig | 8 +++
drivers/button/Makefile | 1 +
drivers/button/button-adc.c | 121
3 files changed, 130 insertions(+)
create mode 100644 drivers/button/button-adc.c
diff --git a/drivers/button/Kconfig b/drivers/button/Kconfig
index 6b3ec7e55d..6db3c5e93a 100644
--- a/drivers/button/Kconfig
+++ b/drivers/button/Kconfig
@@ -9,6 +9,14 @@ config BUTTON
can provide access to board-specific buttons. Use of the device tree
for configuration is encouraged.
+config BUTTON_ADC
+ bool "Button adc"
+ depends on BUTTON
+ help
+ Enable support for buttons which are connected to Analog to Digital
+ Converter device. The ADC driver must use driver model. Buttons are
+ configured using the device tree.
+
config BUTTON_GPIO
bool "Button gpio"
depends on BUTTON
diff --git a/drivers/button/Makefile b/drivers/button/Makefile
index fcc10ebe8d..bbd18af149 100644
--- a/drivers/button/Makefile
+++ b/drivers/button/Makefile
@@ -3,4 +3,5 @@
# Copyright (C) 2020 Philippe Reynes
obj-$(CONFIG_BUTTON) += button-uclass.o
+obj-$(CONFIG_BUTTON_ADC) += button-adc.o
obj-$(CONFIG_BUTTON_GPIO) += button-gpio.o
diff --git a/drivers/button/button-adc.c b/drivers/button/button-adc.c
new file mode 100644
index 00..bf99dd8b43
--- /dev/null
+++ b/drivers/button/button-adc.c
@@ -0,0 +1,121 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2020 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ * Author: Marek Szyprowski
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+/**
+ * struct button_adc_priv - private data for button-adc driver.
+ *
+ * @adc: Analog to Digital Converter device to which button is connected.
+ * @channel: channel of the ADC device to probe the button state.
+ */
+struct button_adc_priv {
+ struct udevice *adc;
+ int channel;
+};
+
+static enum button_state_t button_adc_get_state(struct udevice *dev)
+{
+ struct button_adc_priv *priv = dev_get_priv(dev);
+ unsigned int val, mask;
+ int ret;
+
+ ret = adc_start_channel(priv->adc, priv->channel);
+ if (ret)
+ return ret;
+
+ ret = adc_channel_data(priv->adc, priv->channel, &val);
+ if (ret)
+ return ret;
+
+ ret = adc_data_mask(priv->adc, &mask);
+ if (ret)
+ return ret;
+
+ /* getting state is simplified a bit */
+ if (ret == 0)
+ return (val < mask / 2) ? BUTTON_ON : BUTTON_OFF;
+
+ return ret;
+}
+
+static int button_adc_probe(struct udevice *dev)
+{
+ struct button_uc_plat *uc_plat = dev_get_uclass_platdata(dev);
+ struct button_adc_priv *priv = dev_get_priv(dev);
+ struct ofnode_phandle_args args;
+ int ret;
+
+ /* Ignore the top-level button node */
+ if (!uc_plat->label)
+ return 0;
+
+ ret = dev_read_phandle_with_args(dev->parent, "io-channels",
+"#io-channel-cells", 0, 0, &args);
+ if (ret)
+ return ret;
+
+ ret = uclass_get_device_by_ofnode(UCLASS_ADC, args.node, &priv->adc);
+ if (ret)
+ return ret;
+
+ priv->channel = args.args[0];
+
+ return ret;
+}
+
+static int button_adc_bind(struct udevice *parent)
+{
+ struct udevice *dev;
+ ofnode node;
+ int ret;
+
+ dev_for_each_subnode(node, parent) {
+ struct button_uc_plat *uc_plat;
+ const char *label;
+
+ label = ofnode_read_string(node, "label");
+ if (!label) {
+ debug("%s: node %s has no label\n", __func__,
+ ofnode_get_name(node));
+ return -EINVAL;
+ }
+ ret = device_bind_driver_to_node(parent, "button_adc",
+ofnode_get_name(node),
+node, &dev);
+ if (ret)
+ return ret;
+ uc_plat = dev_get_uclass_platdata(dev);
+ uc_plat->label = label;
+ }
+
+ return 0;
+}
+
+static const struct button_ops button_adc_ops = {
+ .get_state = button_adc_get_state,
+};
+
+static const struct udevice_id button_adc_ids[] = {
+ { .compatible = "adc-keys" },
+ { }
+};
+
+U_BOOT_DRIVER(button_adc) = {
+ .name = "button_adc",
+ .id = UCLASS_BUTTON,
+ .of_match = button_adc_ids,
+ .op
[PATCH v4 3/3] configs: khadas-vim3(l): enable Function button support
Add options required to check the 'Function' button state. Signed-off-by: Marek Szyprowski --- configs/khadas-vim3_defconfig | 2 ++ configs/khadas-vim3l_defconfig | 2 ++ 2 files changed, 4 insertions(+) diff --git a/configs/khadas-vim3_defconfig b/configs/khadas-vim3_defconfig index 5d16652fd6..bc17430569 100644 --- a/configs/khadas-vim3_defconfig +++ b/configs/khadas-vim3_defconfig @@ -31,6 +31,8 @@ CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_NET_RANDOM_ETHADDR=y CONFIG_ADC=y CONFIG_SARADC_MESON=y +CONFIG_BUTTON=y +CONFIG_BUTTON_ADC=y CONFIG_DM_I2C=y CONFIG_SYS_I2C_MESON=y CONFIG_DM_MMC=y diff --git a/configs/khadas-vim3l_defconfig b/configs/khadas-vim3l_defconfig index 6b13ce045c..c1877922c7 100644 --- a/configs/khadas-vim3l_defconfig +++ b/configs/khadas-vim3l_defconfig @@ -31,6 +31,8 @@ CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_NET_RANDOM_ETHADDR=y CONFIG_ADC=y CONFIG_SARADC_MESON=y +CONFIG_BUTTON=y +CONFIG_BUTTON_ADC=y CONFIG_DM_I2C=y CONFIG_SYS_I2C_MESON=y CONFIG_DM_MMC=y -- 2.17.1
[PATCH v2 0/5] DFU: new entity types and minor improvements
Hi All, This patchset adds support for SKIP and SCRIPT entity types to the DFU subsystem. They significantly extends the flexibility of the storage flashing commands. Together with the recently posted 'Add MBR partition table creation and verify command' patchset and proper script it allows to create the whole partition table during the board flashing. It also easies the flashing by allowing to use the same images for different board variants/types, as each board can now use only the relevant images and skip the other ones without returning a failure. Best regards Marek Szyprowski Samsung R&D Institute Poland Changelog: v2: - updated the "dfu: add 'SKIP' entity" patch to the latest version - added 'SCRIPT' DFU entity docs v1: https://lists.denx.de/pipermail/u-boot/2020-December/435214.html - initial version Patch summary: Jaehoon Chung (1): dfu: add 'SKIP' entity Marek Szyprowski (4): dfu: mmc: use the default MMC device if entity specifies it as -1 dfu: add 'SCRIPT' entity dfu: add support for the dfu_alt_info reintialization from the flashed script thor: add support for the dfu_alt_info reintialization from the flashed script cmd/dfu.c | 14 - cmd/thordown.c | 19 +++--- common/dfu.c| 3 +++ doc/README.dfu | 30 +++- drivers/dfu/dfu.c | 7 ++- drivers/dfu/dfu_mmc.c | 39 - drivers/usb/gadget/f_thor.c | 3 +++ include/dfu.h | 4 include/thor.h | 2 ++ 9 files changed, 106 insertions(+), 15 deletions(-) -- 2.17.1
[PATCH v2 2/5] dfu: add 'SKIP' entity
From: Jaehoon Chung
Define a new 'SKIP' type for the DFU entities. The flashed data for that
entity is simply ignored without returning any error values.
This allows to have one flashing procedure and images for the different
board types or variants, where each board uses only the images relevant
to it and skips the rest. This is especially usefull for the THOR
protocol, which usually transfers more than one file in a single session.
Signed-off-by: Jaehoon Chung
Reviewed-by: Minkyu Kang
[mszyprow: rephrased commit message and docs for easier reading, changed
subject to "dfu: add 'SKIP' entity"]
Signed-off-by: Marek Szyprowski
---
Original version of this patch is available here:
https://patchwork.ozlabs.org/project/uboot/patch/20201109115757.24601-1-jh80.ch...@samsung.com/
---
doc/README.dfu| 15 ++-
drivers/dfu/dfu.c | 2 +-
drivers/dfu/dfu_mmc.c | 9 +
include/dfu.h | 1 +
4 files changed, 25 insertions(+), 2 deletions(-)
diff --git a/doc/README.dfu b/doc/README.dfu
index be53b5b393..6cb1cba9d7 100644
--- a/doc/README.dfu
+++ b/doc/README.dfu
@@ -17,7 +17,7 @@ Overview:
- The access to mediums is done in DFU backends (driver/dfu)
Today the supported DFU backends are:
- - MMC (RAW or FAT / EXT2 / EXT3 / EXT4 file system)
+ - MMC (RAW or FAT / EXT2 / EXT3 / EXT4 file system / SKIP)
- NAND
- RAM
- SF (serial flash)
@@ -91,6 +91,7 @@ Commands:
part [mmcpart ] raw access to partition
fat [mmcpart ] file in FAT partition
ext4 [mmcpart ] file in EXT4 partition
+ skip 0 0 ignore flashed data
with being the GPT or DOS partition index,
with being the eMMC hardware partition number.
@@ -103,6 +104,18 @@ Commands:
"u-boot raw 0x80 0x800;uImage ext4 0 2"
+If don't want to flash given image file to storage, use "skip" type
+entity.
+- It can be used to protect flashing wrong image for the specific board.
+- Especailly, this layout will be useful when thor protocol is used,
+ which performs flashing in batch mode, where more than one file is
+ processed.
+For example, if one makes a single tar file with support for the two
+boards with u-boot-.bin and u-boot-.bin files, one
+can use it to flash a proper u-boot image on both without a failure:
+
+ "u-boot-.bin raw 0x80 0x800; u-boot-.bin skip 0 0"
+
"nand" (raw slc nand device)
cmd: dfu 0 nand
each element in "dfu_alt_info" =
diff --git a/drivers/dfu/dfu.c b/drivers/dfu/dfu.c
index 501a60b344..fc32a53323 100644
--- a/drivers/dfu/dfu.c
+++ b/drivers/dfu/dfu.c
@@ -614,7 +614,7 @@ const char *dfu_get_dev_type(enum dfu_device_type t)
const char *dfu_get_layout(enum dfu_layout l)
{
const char *const dfu_layout[] = {NULL, "RAW_ADDR", "FAT", "EXT2",
- "EXT3", "EXT4", "RAM_ADDR" };
+ "EXT3", "EXT4", "RAM_ADDR", "SKIP" };
return dfu_layout[l];
}
diff --git a/drivers/dfu/dfu_mmc.c b/drivers/dfu/dfu_mmc.c
index 784d0ec76b..d1af11d94c 100644
--- a/drivers/dfu/dfu_mmc.c
+++ b/drivers/dfu/dfu_mmc.c
@@ -108,6 +108,8 @@ static int mmc_file_op(enum dfu_op op, struct dfu_entity
*dfu,
case DFU_FS_EXT4:
fstype = FS_TYPE_EXT;
break;
+ case DFU_SKIP:
+ return 0;
default:
printf("%s: Layout (%s) not (yet) supported!\n", __func__,
dfu_get_layout(dfu->layout));
@@ -204,6 +206,9 @@ int dfu_write_medium_mmc(struct dfu_entity *dfu,
case DFU_FS_EXT4:
ret = mmc_file_buf_write(dfu, offset, buf, len);
break;
+ case DFU_SKIP:
+ ret = 0;
+ break;
default:
printf("%s: Layout (%s) not (yet) supported!\n", __func__,
dfu_get_layout(dfu->layout));
@@ -238,6 +243,8 @@ int dfu_get_medium_size_mmc(struct dfu_entity *dfu, u64
*size)
if (ret < 0)
return ret;
return 0;
+ case DFU_SKIP:
+ return 0;
default:
printf("%s: Layout (%s) not (yet) supported!\n", __func__,
dfu_get_layout(dfu->layout));
@@ -399,6 +406,8 @@ int dfu_fill_entity_mmc(struct dfu_entity *dfu, char
*devstr, char *s)
dfu->layout = DFU_FS_FAT;
} else if (!strcmp(entity_type, "ext4")) {
dfu->layout = DFU_FS_EXT4;
+ } else if (!strcmp(entity_type, "skip")) {
+ dfu->layout = DFU_SKIP;
} else {
pr_err("Memory layout (%s)
[PATCH v2 5/5] thor: add support for the dfu_alt_info reintialization from the flashed script
Reinitialize dfu_env_entities after flashing the 'SCRIPT' entity to
ensure that the potential changes to the 'dfu_alt_info' environment
variable are applied.
Signed-off-by: Marek Szyprowski
---
cmd/thordown.c | 19 ---
drivers/usb/gadget/f_thor.c | 3 +++
include/thor.h | 2 ++
3 files changed, 17 insertions(+), 7 deletions(-)
diff --git a/cmd/thordown.c b/cmd/thordown.c
index ae20dddfdd..838764ccef 100644
--- a/cmd/thordown.c
+++ b/cmd/thordown.c
@@ -52,13 +52,18 @@ int do_thor_down(struct cmd_tbl *cmdtp, int flag, int argc,
char *const argv[])
goto exit;
}
- ret = thor_handle();
- if (ret) {
- pr_err("THOR failed: %d\n", ret);
- ret = CMD_RET_FAILURE;
- goto exit;
- }
-
+ do {
+ ret = thor_handle();
+ if (ret == THOR_DFU_REINIT_NEEDED) {
+ dfu_free_entities();
+ ret = dfu_init_env_entities(interface, devstring);
+ }
+ if (ret) {
+ pr_err("THOR failed: %d\n", ret);
+ ret = CMD_RET_FAILURE;
+ goto exit;
+ }
+ } while (ret == 0);
exit:
g_dnl_unregister();
usb_gadget_release(controller_index);
diff --git a/drivers/usb/gadget/f_thor.c b/drivers/usb/gadget/f_thor.c
index 88fc87f2e9..3e69746ee6 100644
--- a/drivers/usb/gadget/f_thor.c
+++ b/drivers/usb/gadget/f_thor.c
@@ -30,6 +30,7 @@
#include
#include
#include
+#include
#include "f_thor.h"
@@ -735,6 +736,8 @@ int thor_handle(void)
printf("%s: No data received!\n", __func__);
break;
}
+ if (dfu_reinit_needed)
+ return THOR_DFU_REINIT_NEEDED;
}
return 0;
diff --git a/include/thor.h b/include/thor.h
index 62501bda17..ee67ab0a27 100644
--- a/include/thor.h
+++ b/include/thor.h
@@ -12,6 +12,8 @@
#include
+#define THOR_DFU_REINIT_NEEDED 0xFFFE
+
int thor_handle(void);
int thor_init(void);
int thor_add(struct usb_configuration *c);
--
2.17.1
[PATCH v2 4/5] dfu: add support for the dfu_alt_info reintialization from the flashed script
Reinitialize DFU USB gadget after flashing the 'SCRIPT' entity to ensure
that the potential changes to the 'dfu_alt_info' environment variable are
applied.
Signed-off-by: Marek Szyprowski
---
cmd/dfu.c| 14 +-
common/dfu.c | 3 +++
2 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/cmd/dfu.c b/cmd/dfu.c
index 7310595a02..89b1b2268e 100644
--- a/cmd/dfu.c
+++ b/cmd/dfu.c
@@ -34,6 +34,7 @@ static int do_dfu(struct cmd_tbl *cmdtp, int flag, int argc,
char *const argv[])
#if defined(CONFIG_DFU_TIMEOUT) || defined(CONFIG_DFU_OVER_TFTP)
unsigned long value = 0;
#endif
+ bool retry = false;
if (argc >= 4) {
interface = argv[2];
@@ -68,7 +69,18 @@ static int do_dfu(struct cmd_tbl *cmdtp, int flag, int argc,
char *const argv[])
int controller_index = simple_strtoul(usb_controller, NULL, 0);
- run_usb_dnl_gadget(controller_index, "usb_dnl_dfu");
+ do {
+ retry = false;
+ run_usb_dnl_gadget(controller_index, "usb_dnl_dfu");
+
+ if (dfu_reinit_needed) {
+ dfu_free_entities();
+ ret = dfu_init_env_entities(interface, devstring);
+ if (ret)
+ goto done;
+ retry = true;
+ }
+ } while (retry);
done:
dfu_free_entities();
diff --git a/common/dfu.c b/common/dfu.c
index d23cf67f19..16bd1ba588 100644
--- a/common/dfu.c
+++ b/common/dfu.c
@@ -98,6 +98,9 @@ int run_usb_dnl_gadget(int usbctrl_index, char
*usb_dnl_gadget)
}
#endif
+ if (dfu_reinit_needed)
+ goto exit;
+
WATCHDOG_RESET();
usb_gadget_handle_interrupts(usbctrl_index);
}
--
2.17.1
[PATCH v2 3/5] dfu: add 'SCRIPT' entity
Define a new 'SCRIPT' type for DFU entities. The downloaded data are
treated as simple u-boot's scripts and executed with run_command_list()
function.
Flashing the 'SCRIPT' entity might result in changing the 'dfu_alt_info'
environment variable from the flashed script, so add a global variable
for tracking the potential need to reinitialize the dfu_alt_info related
structures.
Signed-off-by: Marek Szyprowski
---
doc/README.dfu| 17 -
drivers/dfu/dfu.c | 7 ++-
drivers/dfu/dfu_mmc.c | 23 +--
include/dfu.h | 3 +++
4 files changed, 46 insertions(+), 4 deletions(-)
diff --git a/doc/README.dfu b/doc/README.dfu
index 6cb1cba9d7..eacd5bbfb4 100644
--- a/doc/README.dfu
+++ b/doc/README.dfu
@@ -17,7 +17,7 @@ Overview:
- The access to mediums is done in DFU backends (driver/dfu)
Today the supported DFU backends are:
- - MMC (RAW or FAT / EXT2 / EXT3 / EXT4 file system / SKIP)
+ - MMC (RAW or FAT / EXT2 / EXT3 / EXT4 file system / SKIP / SCRIPT)
- NAND
- RAM
- SF (serial flash)
@@ -92,6 +92,7 @@ Commands:
fat [mmcpart ] file in FAT partition
ext4 [mmcpart ] file in EXT4 partition
skip 0 0 ignore flashed data
+ script 0 0execute commands in shell
with being the GPT or DOS partition index,
with being the eMMC hardware partition number.
@@ -116,6 +117,20 @@ Commands:
"u-boot-.bin raw 0x80 0x800; u-boot-.bin skip 0 0"
+When flashing new system image requires do some more complex things
+than just writing data to the storage medium, one can use 'script'
+type. Data written to such entity will be executed as a command list
+in the u-boot's shell. This for example allows to re-create partition
+layout and even set new dfu_alt_info for the newly created paritions.
+Such script would look like:
+ --->8---
+ setenv dfu_alt_info ...
+ setenv mbr_parts ...
+ mbr write ...
+ --->8---
+Please note that this means that user will be able to execute any
+arbitrary commands just like in the u-boot's shell.
+
"nand" (raw slc nand device)
cmd: dfu 0 nand
each element in "dfu_alt_info" =
diff --git a/drivers/dfu/dfu.c b/drivers/dfu/dfu.c
index fc32a53323..213a20e7bc 100644
--- a/drivers/dfu/dfu.c
+++ b/drivers/dfu/dfu.c
@@ -26,6 +26,8 @@ static struct hash_algo *dfu_hash_algo;
static unsigned long dfu_timeout = 0;
#endif
+bool dfu_reinit_needed = false;
+
/*
* The purpose of the dfu_flush_callback() function is to
* provide callback for dfu user
@@ -139,6 +141,8 @@ int dfu_init_env_entities(char *interface, char *devstr)
char *env_bkp;
int ret = 0;
+ dfu_reinit_needed = false;
+
#ifdef CONFIG_SET_DFU_ALT_INFO
set_dfu_alt_info(interface, devstr);
#endif
@@ -614,7 +618,8 @@ const char *dfu_get_dev_type(enum dfu_device_type t)
const char *dfu_get_layout(enum dfu_layout l)
{
const char *const dfu_layout[] = {NULL, "RAW_ADDR", "FAT", "EXT2",
- "EXT3", "EXT4", "RAM_ADDR", "SKIP" };
+ "EXT3", "EXT4", "RAM_ADDR", "SKIP",
+ "SCRIPT" };
return dfu_layout[l];
}
diff --git a/drivers/dfu/dfu_mmc.c b/drivers/dfu/dfu_mmc.c
index d1af11d94c..e63fa84ce4 100644
--- a/drivers/dfu/dfu_mmc.c
+++ b/drivers/dfu/dfu_mmc.c
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
static unsigned char *dfu_file_buf;
static u64 dfu_file_buf_len;
@@ -206,6 +207,9 @@ int dfu_write_medium_mmc(struct dfu_entity *dfu,
case DFU_FS_EXT4:
ret = mmc_file_buf_write(dfu, offset, buf, len);
break;
+ case DFU_SCRIPT:
+ ret = run_command_list(buf, *len, 0);
+ break;
case DFU_SKIP:
ret = 0;
break;
@@ -221,9 +225,21 @@ int dfu_flush_medium_mmc(struct dfu_entity *dfu)
{
int ret = 0;
- if (dfu->layout != DFU_RAW_ADDR) {
- /* Do stuff here. */
+ switch (dfu->layout) {
+ case DFU_FS_FAT:
+ case DFU_FS_EXT4:
ret = mmc_file_buf_write_finish(dfu);
+ break;
+ case DFU_SCRIPT:
+ /* script may have changed the dfu_alt_info */
+ dfu_reinit_needed = true;
+ break;
+ case DFU_RAW_ADDR:
+ case DFU_SKIP:
+ break;
+ default:
+ printf("%s: Layout (%s) not (yet) supported!\n", __func__,
+ dfu_get_layout(dfu->layout));
}
return ret;
@@ -243,6 +259,7 @@ int dfu_get_medium_size_m
[PATCH v2 1/5] dfu: mmc: use the default MMC device if entity specifies it as -1
Use the default MMC device set in the command line if entity specifies it
as -1. This allows to use the same dfu_alt_info string for different MMC
devices (like embedded eMMC and external SD card if data layout is the
same on both devices).
Signed-off-by: Marek Szyprowski
---
drivers/dfu/dfu_mmc.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/dfu/dfu_mmc.c b/drivers/dfu/dfu_mmc.c
index 691d01c7eb..784d0ec76b 100644
--- a/drivers/dfu/dfu_mmc.c
+++ b/drivers/dfu/dfu_mmc.c
@@ -316,7 +316,7 @@ void dfu_free_entity_mmc(struct dfu_entity *dfu)
int dfu_fill_entity_mmc(struct dfu_entity *dfu, char *devstr, char *s)
{
const char *entity_type;
- size_t second_arg;
+ ssize_t second_arg;
size_t third_arg;
struct mmc *mmc;
@@ -339,7 +339,7 @@ int dfu_fill_entity_mmc(struct dfu_entity *dfu, char
*devstr, char *s)
* Base 0 means we'll accept (prefixed with 0x or 0) base 16, 8,
* with default 10.
*/
- second_arg = simple_strtoul(argv[1], NULL, 0);
+ second_arg = simple_strtol(argv[1], NULL, 0);
third_arg = simple_strtoul(argv[2], NULL, 0);
mmc = find_mmc_device(dfu->data.mmc.dev_num);
@@ -406,7 +406,8 @@ int dfu_fill_entity_mmc(struct dfu_entity *dfu, char
*devstr, char *s)
/* if it's NOT a raw write */
if (strcmp(entity_type, "raw")) {
- dfu->data.mmc.dev = second_arg;
+ dfu->data.mmc.dev = (second_arg != -1) ? second_arg :
+dfu->data.mmc.dev_num;
dfu->data.mmc.part = third_arg;
}
--
2.17.1
[PATCH v2 2/6] disk: dos: add some defines for the hardcoded numbers
Add some handy defines for some hardcoded magic numbers related to
extended partition handling.
Signed-off-by: Marek Szyprowski
---
disk/part_dos.c | 6 +++---
disk/part_dos.h | 3 +++
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/disk/part_dos.c b/disk/part_dos.c
index ef706fb59c..20d35dc9cd 100644
--- a/disk/part_dos.c
+++ b/disk/part_dos.c
@@ -42,9 +42,9 @@ static inline unsigned int le32_to_int(unsigned char *le32)
static inline int is_extended(int part_type)
{
-return (part_type == 0x5 ||
- part_type == 0xf ||
- part_type == 0x85);
+return (part_type == DOS_PART_TYPE_EXTENDED ||
+ part_type == DOS_PART_TYPE_EXTENDED_LBA ||
+ part_type == DOS_PART_TYPE_EXTENDED_LINUX);
}
static int get_bootable(dos_partition_t *p)
diff --git a/disk/part_dos.h b/disk/part_dos.h
index 434b021ae8..dd909a9317 100644
--- a/disk/part_dos.h
+++ b/disk/part_dos.h
@@ -15,6 +15,9 @@
#define DOS_PBR_MEDIA_TYPE_OFFSET 0x15
#define DOS_MBR0
#define DOS_PBR1
+#define DOS_PART_TYPE_EXTENDED 0x05
+#define DOS_PART_TYPE_EXTENDED_LBA 0x0F
+#define DOS_PART_TYPE_EXTENDED_LINUX 0x85
typedef struct dos_partition {
unsigned char boot_ind; /* 0x80 - active
*/
--
2.17.1
[PATCH v2 1/6] disk: dos: rename write_mbr_partition to write_mbr_sector
write_mbr_partition() function name is a bit misleading, so rename it to
write_mbr_sector(). This is a preparation for adding code for writing a
complete MBR partition layout.
Signed-off-by: Marek Szyprowski
---
disk/part_dos.c | 2 +-
drivers/fastboot/fb_mmc.c | 2 +-
include/part.h| 4 ++--
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/disk/part_dos.c b/disk/part_dos.c
index 04f53106f7..ef706fb59c 100644
--- a/disk/part_dos.c
+++ b/disk/part_dos.c
@@ -329,7 +329,7 @@ int is_valid_dos_buf(void *buf)
return test_block_type(buf) == DOS_MBR ? 0 : -1;
}
-int write_mbr_partition(struct blk_desc *dev_desc, void *buf)
+int write_mbr_sector(struct blk_desc *dev_desc, void *buf)
{
if (is_valid_dos_buf(buf))
return -1;
diff --git a/drivers/fastboot/fb_mmc.c b/drivers/fastboot/fb_mmc.c
index ae8e8e512f..4e26cef941 100644
--- a/drivers/fastboot/fb_mmc.c
+++ b/drivers/fastboot/fb_mmc.c
@@ -508,7 +508,7 @@ void fastboot_mmc_flash_write(const char *cmd, void
*download_buffer,
fastboot_fail("invalid MBR partition", response);
return;
}
- if (write_mbr_partition(dev_desc, download_buffer)) {
+ if (write_mbr_sector(dev_desc, download_buffer)) {
printf("%s: writing MBR partition failed\n", __func__);
fastboot_fail("writing MBR partition failed",
response);
diff --git a/include/part.h b/include/part.h
index 55be724d20..67b8b2a5cc 100644
--- a/include/part.h
+++ b/include/part.h
@@ -465,14 +465,14 @@ int get_disk_guid(struct blk_desc *dev_desc, char *guid);
int is_valid_dos_buf(void *buf);
/**
- * write_mbr_partition() - write DOS MBR
+ * write_mbr_sector() - write DOS MBR
*
* @param dev_desc - block device descriptor
* @param buf - buffer which contains the MBR
*
* @return - '0' on success, otherwise error
*/
-int write_mbr_partition(struct blk_desc *dev_desc, void *buf);
+int write_mbr_sector(struct blk_desc *dev_desc, void *buf);
#endif
--
2.17.1
[PATCH v2 4/6] disk: dos: make some functions static
Make functions not used outside this file static.
Signed-off-by: Marek Szyprowski
---
disk/part_dos.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/disk/part_dos.c b/disk/part_dos.c
index 3b79b9b1b8..2c4ad0b6ba 100644
--- a/disk/part_dos.c
+++ b/disk/part_dos.c
@@ -302,13 +302,13 @@ static int part_get_info_extended(struct blk_desc
*dev_desc,
return -1;
}
-void part_print_dos(struct blk_desc *dev_desc)
+static void part_print_dos(struct blk_desc *dev_desc)
{
printf("Part\tStart Sector\tNum Sectors\tUUID\t\tType\n");
print_partition_extended(dev_desc, 0, 0, 1, 0);
}
-int part_get_info_dos(struct blk_desc *dev_desc, int part,
+static int part_get_info_dos(struct blk_desc *dev_desc, int part,
struct disk_partition *info)
{
return part_get_info_extended(dev_desc, 0, 0, 1, part, info, 0);
--
2.17.1
[PATCH v2 5/6] disk: dos: add code for creating MBR partition layout
Add a code for creating and writing MBR partition layout. The code
generates similar layout of EBRs (Exteneded Block Records) and logical
volumes as Linux's fdisk utility.
Signed-off-by: Marek Szyprowski
---
disk/part_dos.c | 167
disk/part_dos.h | 2 +
include/part.h | 5 ++
3 files changed, 174 insertions(+)
diff --git a/disk/part_dos.c b/disk/part_dos.c
index 2c4ad0b6ba..f77f927995 100644
--- a/disk/part_dos.c
+++ b/disk/part_dos.c
@@ -319,6 +319,173 @@ int is_valid_dos_buf(void *buf)
return test_block_type(buf) == DOS_MBR ? 0 : -1;
}
+#if CONFIG_IS_ENABLED(CMD_MBR)
+static void lba_to_chs(lbaint_t lba, unsigned char *rc, unsigned char *rh,
+ unsigned char *rs)
+{
+ unsigned int c, h, s;
+ /* use fixed CHS geometry */
+ unsigned int sectpertrack = 63;
+ unsigned int heads = 255;
+
+ c = (lba + 1) / sectpertrack / heads;
+ h = (lba + 1) / sectpertrack - c * heads;
+ s = (lba + 1) - (c * heads + h) * sectpertrack;
+
+ if (c > 1023) {
+ c = 1023;
+ h = 254;
+ s = 63;
+ }
+
+ *rc = c & 0xff;
+ *rh = h;
+ *rs = s + ((c & 0x300) >> 2);
+}
+
+static void mbr_fill_pt_entry(dos_partition_t *pt, lbaint_t start,
+ lbaint_t relative, lbaint_t size, uchar sys_ind, bool bootable)
+{
+ pt->boot_ind = bootable ? 0x80 : 0x00;
+ pt->sys_ind = sys_ind;
+ lba_to_chs(start, &pt->cyl, &pt->head, &pt->sector);
+ lba_to_chs(start + size - 1, &pt->end_cyl, &pt->end_head,
&pt->end_sector);
+ put_unaligned_le32(relative, &pt->start4);
+ put_unaligned_le32(size, &pt->size4);
+}
+
+int write_mbr_partitions(struct blk_desc *dev,
+ struct disk_partition *p, int count, unsigned int disksig)
+{
+ ALLOC_CACHE_ALIGN_BUFFER(unsigned char, buffer, dev->blksz);
+ lbaint_t ext_part_start = 0, ext_part_size = 0, ext_part_sect = 0;
+ dos_partition_t *pt;
+ int i;
+
+ memset(buffer, 0, dev->blksz);
+ buffer[DOS_PART_MAGIC_OFFSET] = 0x55;
+ buffer[DOS_PART_MAGIC_OFFSET + 1] = 0xaa;
+ put_unaligned_le32(disksig, &buffer[DOS_PART_DISKSIG_OFFSET]);
+ pt = (dos_partition_t *) (buffer + DOS_PART_TBL_OFFSET);
+
+ /* create all primary partitions */
+ for (i = 0; i < 4 && i < count; i++, pt++) {
+ mbr_fill_pt_entry(pt, p[i].start, p[i].start, p[i].size,
+ p[i].sys_ind, p[i].bootable);
+ if (is_extended(p[i].sys_ind)) {
+ ext_part_start = p[i].start;
+ ext_part_size = p[i].size;
+ ext_part_sect = p[i].start;
+ }
+ }
+
+ if (i < count && !ext_part_start) {
+ printf("%s: extended partition is needed for more than 4
partitions\n",
+ __func__);
+ return -1;
+ }
+
+ /* write MBR */
+ if (blk_dwrite(dev, 0, 1, buffer) != 1) {
+ printf("%s: failed writing 'MBR' (1 blks at 0x0)\n",
+ __func__);
+ return -1;
+ }
+
+ /* create extended volumes */
+ for (; i < count; i++) {
+ lbaint_t next_ebr = 0;
+
+ memset(buffer, 0, dev->blksz);
+ buffer[DOS_PART_MAGIC_OFFSET] = 0x55;
+ buffer[DOS_PART_MAGIC_OFFSET + 1] = 0xaa;
+ pt = (dos_partition_t *) (buffer + DOS_PART_TBL_OFFSET);
+
+ mbr_fill_pt_entry(pt, p[i].start, p[i].start - ext_part_sect,
+ p[i].size, p[i].sys_ind, p[i].bootable);
+
+ if (i + 1 < count) {
+ pt++;
+ next_ebr = p[i].start + p[i].size;
+ mbr_fill_pt_entry(pt, next_ebr,
+ next_ebr - ext_part_start,
+ p[i+1].start + p[i+1].size - next_ebr,
+ DOS_PART_TYPE_EXTENDED, 0);
+ }
+
+ /* write EBR */
+ if (blk_dwrite(dev, ext_part_sect, 1, buffer) != 1) {
+ printf("%s: failed writing 'EBR' (1 blks at 0x%lx)\n",
+ __func__, ext_part_sect);
+ return -1;
+ }
+ ext_part_sect = next_ebr;
+ }
+
+ return 0;
+}
+
+int layout_mbr_partitions(struct disk_partition *p, int count,
+ lbaint_t total_sectors)
+{
+ struct disk_partition *ext = NULL;
+ int i, j;
+ lbaint_t ext_vol_start;
+
+ /* calculate primary partitions start and size if needed */
+ if (!p[0].start)
+
[PATCH v2 3/6] disk: dos: use generic macro for unaligned le32 access
Use a generic helper for reading LE32 integers.
Signed-off-by: Marek Szyprowski
---
disk/part_dos.c | 28 +---
1 file changed, 9 insertions(+), 19 deletions(-)
diff --git a/disk/part_dos.c b/disk/part_dos.c
index 20d35dc9cd..3b79b9b1b8 100644
--- a/disk/part_dos.c
+++ b/disk/part_dos.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include "part_dos.h"
#include
@@ -29,17 +30,6 @@
* to use large numbers of partitions */
#define MAX_EXT_PARTS 256
-/* Convert char[4] in little endian format to the host format integer
- */
-static inline unsigned int le32_to_int(unsigned char *le32)
-{
-return ((le32[3] << 24) +
- (le32[2] << 16) +
- (le32[1] << 8) +
-le32[0]
- );
-}
-
static inline int is_extended(int part_type)
{
return (part_type == DOS_PART_TYPE_EXTENDED ||
@@ -61,8 +51,8 @@ static int get_bootable(dos_partition_t *p)
static void print_one_part(dos_partition_t *p, lbaint_t ext_part_sector,
int part_num, unsigned int disksig)
{
- lbaint_t lba_start = ext_part_sector + le32_to_int (p->start4);
- lbaint_t lba_size = le32_to_int (p->size4);
+ lbaint_t lba_start = ext_part_sector + get_unaligned_le32(p->start4);
+ lbaint_t lba_size = get_unaligned_le32(p->size4);
printf("%3d\t%-10" LBAFlength "u\t%-10" LBAFlength
"u\t%08x-%02x\t%02x%s%s\n",
@@ -171,7 +161,7 @@ static void print_partition_extended(struct blk_desc
*dev_desc,
}
if (!ext_part_sector)
- disksig = le32_to_int(&buffer[DOS_PART_DISKSIG_OFFSET]);
+ disksig = get_unaligned_le32(&buffer[DOS_PART_DISKSIG_OFFSET]);
/* Print all primary/logical partitions */
pt = (dos_partition_t *) (buffer + DOS_PART_TBL_OFFSET);
@@ -198,7 +188,7 @@ static void print_partition_extended(struct blk_desc
*dev_desc,
for (i = 0; i < 4; i++, pt++) {
if (is_extended (pt->sys_ind)) {
lbaint_t lba_start
- = le32_to_int (pt->start4) + relative;
+ = get_unaligned_le32 (pt->start4) + relative;
print_partition_extended(dev_desc, lba_start,
ext_part_sector == 0 ? lba_start : relative,
@@ -244,7 +234,7 @@ static int part_get_info_extended(struct blk_desc *dev_desc,
#if CONFIG_IS_ENABLED(PARTITION_UUIDS)
if (!ext_part_sector)
- disksig = le32_to_int(&buffer[DOS_PART_DISKSIG_OFFSET]);
+ disksig = get_unaligned_le32(&buffer[DOS_PART_DISKSIG_OFFSET]);
#endif
/* Print all primary/logical partitions */
@@ -260,8 +250,8 @@ static int part_get_info_extended(struct blk_desc *dev_desc,
(ext_part_sector == 0 || is_extended(pt->sys_ind) == 0)) {
info->blksz = DOS_PART_DEFAULT_SECTOR;
info->start = (lbaint_t)(ext_part_sector +
- le32_to_int(pt->start4));
- info->size = (lbaint_t)le32_to_int(pt->size4);
+ get_unaligned_le32(pt->start4));
+ info->size = (lbaint_t)get_unaligned_le32(pt->size4);
part_set_generic_name(dev_desc, part_num,
(char *)info->name);
/* sprintf(info->type, "%d, pt->sys_ind); */
@@ -286,7 +276,7 @@ static int part_get_info_extended(struct blk_desc *dev_desc,
for (i = 0; i < 4; i++, pt++) {
if (is_extended (pt->sys_ind)) {
lbaint_t lba_start
- = le32_to_int (pt->start4) + relative;
+ = get_unaligned_le32 (pt->start4) + relative;
return part_get_info_extended(dev_desc, lba_start,
ext_part_sector == 0 ? lba_start : relative,
--
2.17.1
[PATCH v2 6/6] cmd: Add MBR partition layout control utility
Add a 'mbr' command to let user create or verify MBR partition layout
based on the provided text description. The partition layout is
altearnatively read from 'mbr_parts' environment variable. This can be
used in scripts to help system image flashing tools to ensure proper
partition layout.
The syntax of the text description of the partition list is similar to
the one used by the 'gpt' command. Supported parameters are: name
(currently ignored), start (partition start offset in bytes), size (in
bytes or '-' to expand it to the whole free area), bootable (boolean
flag) and id (MBR partition system ID). If one wants to create more than
4 partitions, an 'Extended' primary partition (with 0x05 ID) has to be
explicitely provided as a one of the first 4 entries.
Here is the example how to create a 6 partitions (3 on the 'extended
volume'), some of the predefined sizes:
> setenv mbr_parts 'name=boot,start=4M,size=128M,bootable,id=0x0e;
name=rootfs,size=3072M,id=0x83;
name=system-data,size=512M,id=0x83;
name=[ext],size=-,id=0x05;
name=user,size=-,id=0x83;
name=modules,size=100M,id=0x83;
name=ramdisk,size=8M,id=0x83'
> mbr write mmc 0
Signed-off-by: Marek Szyprowski
---
cmd/Kconfig | 8 ++
cmd/Makefile| 1 +
cmd/mbr.c | 314
doc/usage/index.rst | 1 +
doc/usage/mbr.rst | 93 +
5 files changed, 417 insertions(+)
create mode 100644 cmd/mbr.c
create mode 100644 doc/usage/mbr.rst
diff --git a/cmd/Kconfig b/cmd/Kconfig
index 1595de999b..2c3358e359 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -1025,6 +1025,14 @@ config CMD_LSBLK
Print list of available block device drivers, and for each, the list
of known block devices.
+config CMD_MBR
+ bool "MBR (Master Boot Record) command"
+ select DOS_PARTITION
+ select HAVE_BLOCK_DEVICE
+ help
+ Enable the 'mbr' command to ready and write MBR (Master Boot Record)
+ style partition tables.
+
config CMD_MISC
bool "misc"
depends on MISC
diff --git a/cmd/Makefile b/cmd/Makefile
index dd86675bf2..41379d9a0e 100644
--- a/cmd/Makefile
+++ b/cmd/Makefile
@@ -178,6 +178,7 @@ obj-$(CONFIG_CMD_ZFS) += zfs.o
obj-$(CONFIG_CMD_DFU) += dfu.o
obj-$(CONFIG_CMD_GPT) += gpt.o
+obj-$(CONFIG_CMD_MBR) += mbr.o
obj-$(CONFIG_CMD_ETHSW) += ethsw.o
obj-$(CONFIG_CMD_AXI) += axi.o
obj-$(CONFIG_CMD_PVBLOCK) += pvblock.o
diff --git a/cmd/mbr.c b/cmd/mbr.c
new file mode 100644
index 00..da2e3a4722
--- /dev/null
+++ b/cmd/mbr.c
@@ -0,0 +1,314 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * cmd_mbr.c -- MBR (Master Boot Record) handling command
+ *
+ * Copyright (C) 2020 Samsung Electronics
+ * author: Marek Szyprowski
+ *
+ * based on the gpt command.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+/**
+ * extract_val() - Extract a value from the key=value pair list
+ * @str: pointer to string with key=values pairs
+ * @key: pointer to the key to search for
+ *
+ * The list of parameters is come separated, only a value for
+ * the given key is returend.
+ *
+ * Function allocates memory for the value, remember to free!
+ *
+ * Return: Pointer to allocated string with the value.
+ */
+static char *extract_val(const char *str, const char *key)
+{
+ char *v, *k;
+ char *s, *strcopy;
+ char *new = NULL;
+
+ strcopy = strdup(str);
+ if (strcopy == NULL)
+ return NULL;
+
+ s = strcopy;
+ while (s) {
+ v = strsep(&s, ",");
+ if (!v)
+ break;
+ k = strsep(&v, "=");
+ if (!k)
+ break;
+ if (strcmp(k, key) == 0) {
+ new = strdup(v);
+ break;
+ }
+ }
+
+ free(strcopy);
+
+ return new;
+}
+
+/**
+ * found_key() - Search for a key without a value in the parameter list
+ * @str: pointer to string with key
+ * @key: pointer to the key to search for
+ *
+ * The list of parameters is come separated.
+ *
+ * Return: True if key has been found.
+ */
+static bool found_key(const char *str, const char *key)
+{
+ char *k;
+ char *s, *strcopy;
+ bool result = false;
+
+ strcopy = strdup(str);
+ if (!strcopy)
+ return NULL;
+
+ s = strcopy;
+ while (s) {
+ k = strsep(&s, ",");
+ if (!k)
+ break;
+ if (strcmp(k, key) == 0) {
+ result = true;
+ break;
+ }
+ }
+
+ free(strcopy);
+
+ return result;
+}
+
+static int str_to_partitions(const char *str_part, int blksz,
+ unsigned long *disk_uuid, struct disk_partition **partitions
[PATCH v2 0/6] Add MBR partition table creation and verify command
Hi All, This patchset adds 'mbr' command to let one create or verify MBR (Master Boot Record) partition layout based on the provided text description. This can be used in scripts to help system flashing tools/scripts to ensure proper partition layout. It has been inspired by the 'gpt' command already present in u-boot. Best regards Marek Szyprowski Samsung R&D Institute Poland Changelog: v2: - added docs and minor fixes in the code style v1: https://lists.denx.de/pipermail/u-boot/2020-December/435208.html - initial version Patch summary: Marek Szyprowski (6): disk: dos: rename write_mbr_partition to write_mbr_sector disk: dos: add some defines for the hardcoded numbers disk: dos: use generic macro for unaligned le32 access disk: dos: make some functions static disk: dos: add code for creating MBR partition layout cmd: Add MBR partition layout control utility cmd/Kconfig | 8 + cmd/Makefile | 1 + cmd/mbr.c | 314 ++ disk/part_dos.c | 207 ++--- disk/part_dos.h | 5 + doc/usage/index.rst | 1 + doc/usage/mbr.rst | 93 +++ drivers/fastboot/fb_mmc.c | 2 +- include/part.h| 9 +- 9 files changed, 612 insertions(+), 28 deletions(-) create mode 100644 cmd/mbr.c create mode 100644 doc/usage/mbr.rst -- 2.17.1
[PATCH v3 3/6] disk: dos: use generic macro for unaligned le32 access
Use a generic helper for reading LE32 integers.
Signed-off-by: Marek Szyprowski
---
disk/part_dos.c | 28 +---
1 file changed, 9 insertions(+), 19 deletions(-)
diff --git a/disk/part_dos.c b/disk/part_dos.c
index 20d35dc9cd..3b79b9b1b8 100644
--- a/disk/part_dos.c
+++ b/disk/part_dos.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include "part_dos.h"
#include
@@ -29,17 +30,6 @@
* to use large numbers of partitions */
#define MAX_EXT_PARTS 256
-/* Convert char[4] in little endian format to the host format integer
- */
-static inline unsigned int le32_to_int(unsigned char *le32)
-{
-return ((le32[3] << 24) +
- (le32[2] << 16) +
- (le32[1] << 8) +
-le32[0]
- );
-}
-
static inline int is_extended(int part_type)
{
return (part_type == DOS_PART_TYPE_EXTENDED ||
@@ -61,8 +51,8 @@ static int get_bootable(dos_partition_t *p)
static void print_one_part(dos_partition_t *p, lbaint_t ext_part_sector,
int part_num, unsigned int disksig)
{
- lbaint_t lba_start = ext_part_sector + le32_to_int (p->start4);
- lbaint_t lba_size = le32_to_int (p->size4);
+ lbaint_t lba_start = ext_part_sector + get_unaligned_le32(p->start4);
+ lbaint_t lba_size = get_unaligned_le32(p->size4);
printf("%3d\t%-10" LBAFlength "u\t%-10" LBAFlength
"u\t%08x-%02x\t%02x%s%s\n",
@@ -171,7 +161,7 @@ static void print_partition_extended(struct blk_desc
*dev_desc,
}
if (!ext_part_sector)
- disksig = le32_to_int(&buffer[DOS_PART_DISKSIG_OFFSET]);
+ disksig = get_unaligned_le32(&buffer[DOS_PART_DISKSIG_OFFSET]);
/* Print all primary/logical partitions */
pt = (dos_partition_t *) (buffer + DOS_PART_TBL_OFFSET);
@@ -198,7 +188,7 @@ static void print_partition_extended(struct blk_desc
*dev_desc,
for (i = 0; i < 4; i++, pt++) {
if (is_extended (pt->sys_ind)) {
lbaint_t lba_start
- = le32_to_int (pt->start4) + relative;
+ = get_unaligned_le32 (pt->start4) + relative;
print_partition_extended(dev_desc, lba_start,
ext_part_sector == 0 ? lba_start : relative,
@@ -244,7 +234,7 @@ static int part_get_info_extended(struct blk_desc *dev_desc,
#if CONFIG_IS_ENABLED(PARTITION_UUIDS)
if (!ext_part_sector)
- disksig = le32_to_int(&buffer[DOS_PART_DISKSIG_OFFSET]);
+ disksig = get_unaligned_le32(&buffer[DOS_PART_DISKSIG_OFFSET]);
#endif
/* Print all primary/logical partitions */
@@ -260,8 +250,8 @@ static int part_get_info_extended(struct blk_desc *dev_desc,
(ext_part_sector == 0 || is_extended(pt->sys_ind) == 0)) {
info->blksz = DOS_PART_DEFAULT_SECTOR;
info->start = (lbaint_t)(ext_part_sector +
- le32_to_int(pt->start4));
- info->size = (lbaint_t)le32_to_int(pt->size4);
+ get_unaligned_le32(pt->start4));
+ info->size = (lbaint_t)get_unaligned_le32(pt->size4);
part_set_generic_name(dev_desc, part_num,
(char *)info->name);
/* sprintf(info->type, "%d, pt->sys_ind); */
@@ -286,7 +276,7 @@ static int part_get_info_extended(struct blk_desc *dev_desc,
for (i = 0; i < 4; i++, pt++) {
if (is_extended (pt->sys_ind)) {
lbaint_t lba_start
- = le32_to_int (pt->start4) + relative;
+ = get_unaligned_le32 (pt->start4) + relative;
return part_get_info_extended(dev_desc, lba_start,
ext_part_sector == 0 ? lba_start : relative,
--
2.17.1
[PATCH v3 1/6] disk: dos: rename write_mbr_partition to write_mbr_sector
write_mbr_partition() function name is a bit misleading, so rename it to
write_mbr_sector(). This is a preparation for adding code for writing a
complete MBR partition layout.
Signed-off-by: Marek Szyprowski
---
disk/part_dos.c | 2 +-
drivers/fastboot/fb_mmc.c | 2 +-
include/part.h| 4 ++--
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/disk/part_dos.c b/disk/part_dos.c
index 04f53106f7..ef706fb59c 100644
--- a/disk/part_dos.c
+++ b/disk/part_dos.c
@@ -329,7 +329,7 @@ int is_valid_dos_buf(void *buf)
return test_block_type(buf) == DOS_MBR ? 0 : -1;
}
-int write_mbr_partition(struct blk_desc *dev_desc, void *buf)
+int write_mbr_sector(struct blk_desc *dev_desc, void *buf)
{
if (is_valid_dos_buf(buf))
return -1;
diff --git a/drivers/fastboot/fb_mmc.c b/drivers/fastboot/fb_mmc.c
index ae8e8e512f..4e26cef941 100644
--- a/drivers/fastboot/fb_mmc.c
+++ b/drivers/fastboot/fb_mmc.c
@@ -508,7 +508,7 @@ void fastboot_mmc_flash_write(const char *cmd, void
*download_buffer,
fastboot_fail("invalid MBR partition", response);
return;
}
- if (write_mbr_partition(dev_desc, download_buffer)) {
+ if (write_mbr_sector(dev_desc, download_buffer)) {
printf("%s: writing MBR partition failed\n", __func__);
fastboot_fail("writing MBR partition failed",
response);
diff --git a/include/part.h b/include/part.h
index 55be724d20..67b8b2a5cc 100644
--- a/include/part.h
+++ b/include/part.h
@@ -465,14 +465,14 @@ int get_disk_guid(struct blk_desc *dev_desc, char *guid);
int is_valid_dos_buf(void *buf);
/**
- * write_mbr_partition() - write DOS MBR
+ * write_mbr_sector() - write DOS MBR
*
* @param dev_desc - block device descriptor
* @param buf - buffer which contains the MBR
*
* @return - '0' on success, otherwise error
*/
-int write_mbr_partition(struct blk_desc *dev_desc, void *buf);
+int write_mbr_sector(struct blk_desc *dev_desc, void *buf);
#endif
--
2.17.1
[PATCH v3 2/6] disk: dos: add some defines for the hardcoded numbers
Add some handy defines for some hardcoded magic numbers related to
extended partition handling.
Signed-off-by: Marek Szyprowski
---
disk/part_dos.c | 6 +++---
disk/part_dos.h | 3 +++
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/disk/part_dos.c b/disk/part_dos.c
index ef706fb59c..20d35dc9cd 100644
--- a/disk/part_dos.c
+++ b/disk/part_dos.c
@@ -42,9 +42,9 @@ static inline unsigned int le32_to_int(unsigned char *le32)
static inline int is_extended(int part_type)
{
-return (part_type == 0x5 ||
- part_type == 0xf ||
- part_type == 0x85);
+return (part_type == DOS_PART_TYPE_EXTENDED ||
+ part_type == DOS_PART_TYPE_EXTENDED_LBA ||
+ part_type == DOS_PART_TYPE_EXTENDED_LINUX);
}
static int get_bootable(dos_partition_t *p)
diff --git a/disk/part_dos.h b/disk/part_dos.h
index 434b021ae8..dd909a9317 100644
--- a/disk/part_dos.h
+++ b/disk/part_dos.h
@@ -15,6 +15,9 @@
#define DOS_PBR_MEDIA_TYPE_OFFSET 0x15
#define DOS_MBR0
#define DOS_PBR1
+#define DOS_PART_TYPE_EXTENDED 0x05
+#define DOS_PART_TYPE_EXTENDED_LBA 0x0F
+#define DOS_PART_TYPE_EXTENDED_LINUX 0x85
typedef struct dos_partition {
unsigned char boot_ind; /* 0x80 - active
*/
--
2.17.1
[PATCH v3 5/6] disk: dos: add code for creating MBR partition layout
Add a code for creating and writing MBR partition layout. The code generates
similar layout of EBRs (Exteneded Block Records) and logical volumes as
Linux's fdisk utility.
Signed-off-by: Marek Szyprowski
---
disk/part_dos.c | 167
disk/part_dos.h | 2 +
include/part.h | 5 ++
3 files changed, 174 insertions(+)
diff --git a/disk/part_dos.c b/disk/part_dos.c
index 2c4ad0b6ba..f77f927995 100644
--- a/disk/part_dos.c
+++ b/disk/part_dos.c
@@ -319,6 +319,173 @@ int is_valid_dos_buf(void *buf)
return test_block_type(buf) == DOS_MBR ? 0 : -1;
}
+#if CONFIG_IS_ENABLED(CMD_MBR)
+static void lba_to_chs(lbaint_t lba, unsigned char *rc, unsigned char *rh,
+ unsigned char *rs)
+{
+ unsigned int c, h, s;
+ /* use fixed CHS geometry */
+ unsigned int sectpertrack = 63;
+ unsigned int heads = 255;
+
+ c = (lba + 1) / sectpertrack / heads;
+ h = (lba + 1) / sectpertrack - c * heads;
+ s = (lba + 1) - (c * heads + h) * sectpertrack;
+
+ if (c > 1023) {
+ c = 1023;
+ h = 254;
+ s = 63;
+ }
+
+ *rc = c & 0xff;
+ *rh = h;
+ *rs = s + ((c & 0x300) >> 2);
+}
+
+static void mbr_fill_pt_entry(dos_partition_t *pt, lbaint_t start,
+ lbaint_t relative, lbaint_t size, uchar sys_ind, bool bootable)
+{
+ pt->boot_ind = bootable ? 0x80 : 0x00;
+ pt->sys_ind = sys_ind;
+ lba_to_chs(start, &pt->cyl, &pt->head, &pt->sector);
+ lba_to_chs(start + size - 1, &pt->end_cyl, &pt->end_head,
&pt->end_sector);
+ put_unaligned_le32(relative, &pt->start4);
+ put_unaligned_le32(size, &pt->size4);
+}
+
+int write_mbr_partitions(struct blk_desc *dev,
+ struct disk_partition *p, int count, unsigned int disksig)
+{
+ ALLOC_CACHE_ALIGN_BUFFER(unsigned char, buffer, dev->blksz);
+ lbaint_t ext_part_start = 0, ext_part_size = 0, ext_part_sect = 0;
+ dos_partition_t *pt;
+ int i;
+
+ memset(buffer, 0, dev->blksz);
+ buffer[DOS_PART_MAGIC_OFFSET] = 0x55;
+ buffer[DOS_PART_MAGIC_OFFSET + 1] = 0xaa;
+ put_unaligned_le32(disksig, &buffer[DOS_PART_DISKSIG_OFFSET]);
+ pt = (dos_partition_t *) (buffer + DOS_PART_TBL_OFFSET);
+
+ /* create all primary partitions */
+ for (i = 0; i < 4 && i < count; i++, pt++) {
+ mbr_fill_pt_entry(pt, p[i].start, p[i].start, p[i].size,
+ p[i].sys_ind, p[i].bootable);
+ if (is_extended(p[i].sys_ind)) {
+ ext_part_start = p[i].start;
+ ext_part_size = p[i].size;
+ ext_part_sect = p[i].start;
+ }
+ }
+
+ if (i < count && !ext_part_start) {
+ printf("%s: extended partition is needed for more than 4
partitions\n",
+ __func__);
+ return -1;
+ }
+
+ /* write MBR */
+ if (blk_dwrite(dev, 0, 1, buffer) != 1) {
+ printf("%s: failed writing 'MBR' (1 blks at 0x0)\n",
+ __func__);
+ return -1;
+ }
+
+ /* create extended volumes */
+ for (; i < count; i++) {
+ lbaint_t next_ebr = 0;
+
+ memset(buffer, 0, dev->blksz);
+ buffer[DOS_PART_MAGIC_OFFSET] = 0x55;
+ buffer[DOS_PART_MAGIC_OFFSET + 1] = 0xaa;
+ pt = (dos_partition_t *) (buffer + DOS_PART_TBL_OFFSET);
+
+ mbr_fill_pt_entry(pt, p[i].start, p[i].start - ext_part_sect,
+ p[i].size, p[i].sys_ind, p[i].bootable);
+
+ if (i + 1 < count) {
+ pt++;
+ next_ebr = p[i].start + p[i].size;
+ mbr_fill_pt_entry(pt, next_ebr,
+ next_ebr - ext_part_start,
+ p[i+1].start + p[i+1].size - next_ebr,
+ DOS_PART_TYPE_EXTENDED, 0);
+ }
+
+ /* write EBR */
+ if (blk_dwrite(dev, ext_part_sect, 1, buffer) != 1) {
+ printf("%s: failed writing 'EBR' (1 blks at 0x%lx)\n",
+ __func__, ext_part_sect);
+ return -1;
+ }
+ ext_part_sect = next_ebr;
+ }
+
+ return 0;
+}
+
+int layout_mbr_partitions(struct disk_partition *p, int count,
+ lbaint_t total_sectors)
+{
+ struct disk_partition *ext = NULL;
+ int i, j;
+ lbaint_t ext_vol_start;
+
+ /* calculate primary partitions start and size if needed */
+ if (!p[0].start)
+
[PATCH v3 6/6] cmd: Add MBR partition layout control utility
Add a 'mbr' command to let users create or verify MBR partition layout
based on the provided text description. The partition layout is
alternatively read from the 'mbr_parts' environment variable. This can be
used in scripts to help system image flashing tools to ensure proper
partition layout.
The syntax of the text description of the partition list is similar to
the one used by the 'gpt' command. Supported parameters are: name
(currently ignored), start (partition start offset in bytes), size (in
bytes or '-' to expand it to the whole free area), bootable (boolean
flag) and id (MBR partition type). If one wants to create more than 4
partitions, an 'Extended' primary partition (with 0x05 ID) has to be
explicitely provided as a one of the first 4 entries.
Here is an example how to create a 6 partitions (3 on the 'extended
volume'), some of the predefined sizes:
> setenv mbr_parts 'name=boot,start=4M,size=128M,bootable,id=0x0e;
name=rootfs,size=3072M,id=0x83;
name=system-data,size=512M,id=0x83;
name=[ext],size=-,id=0x05;
name=user,size=-,id=0x83;
name=modules,size=100M,id=0x83;
name=ramdisk,size=8M,id=0x83'
> mbr write mmc 0
Signed-off-by: Marek Szyprowski
---
cmd/Kconfig | 8 ++
cmd/Makefile| 1 +
cmd/mbr.c | 314
doc/usage/index.rst | 1 +
doc/usage/mbr.rst | 93 +
5 files changed, 417 insertions(+)
create mode 100644 cmd/mbr.c
create mode 100644 doc/usage/mbr.rst
diff --git a/cmd/Kconfig b/cmd/Kconfig
index 1595de999b..2c3358e359 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -1025,6 +1025,14 @@ config CMD_LSBLK
Print list of available block device drivers, and for each, the list
of known block devices.
+config CMD_MBR
+ bool "MBR (Master Boot Record) command"
+ select DOS_PARTITION
+ select HAVE_BLOCK_DEVICE
+ help
+ Enable the 'mbr' command to ready and write MBR (Master Boot Record)
+ style partition tables.
+
config CMD_MISC
bool "misc"
depends on MISC
diff --git a/cmd/Makefile b/cmd/Makefile
index dd86675bf2..41379d9a0e 100644
--- a/cmd/Makefile
+++ b/cmd/Makefile
@@ -178,6 +178,7 @@ obj-$(CONFIG_CMD_ZFS) += zfs.o
obj-$(CONFIG_CMD_DFU) += dfu.o
obj-$(CONFIG_CMD_GPT) += gpt.o
+obj-$(CONFIG_CMD_MBR) += mbr.o
obj-$(CONFIG_CMD_ETHSW) += ethsw.o
obj-$(CONFIG_CMD_AXI) += axi.o
obj-$(CONFIG_CMD_PVBLOCK) += pvblock.o
diff --git a/cmd/mbr.c b/cmd/mbr.c
new file mode 100644
index 00..da2e3a4722
--- /dev/null
+++ b/cmd/mbr.c
@@ -0,0 +1,314 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * cmd_mbr.c -- MBR (Master Boot Record) handling command
+ *
+ * Copyright (C) 2020 Samsung Electronics
+ * author: Marek Szyprowski
+ *
+ * based on the gpt command.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+/**
+ * extract_val() - Extract a value from the key=value pair list
+ * @str: pointer to string with key=values pairs
+ * @key: pointer to the key to search for
+ *
+ * The list of parameters is come separated, only a value for
+ * the given key is returend.
+ *
+ * Function allocates memory for the value, remember to free!
+ *
+ * Return: Pointer to allocated string with the value.
+ */
+static char *extract_val(const char *str, const char *key)
+{
+ char *v, *k;
+ char *s, *strcopy;
+ char *new = NULL;
+
+ strcopy = strdup(str);
+ if (strcopy == NULL)
+ return NULL;
+
+ s = strcopy;
+ while (s) {
+ v = strsep(&s, ",");
+ if (!v)
+ break;
+ k = strsep(&v, "=");
+ if (!k)
+ break;
+ if (strcmp(k, key) == 0) {
+ new = strdup(v);
+ break;
+ }
+ }
+
+ free(strcopy);
+
+ return new;
+}
+
+/**
+ * found_key() - Search for a key without a value in the parameter list
+ * @str: pointer to string with key
+ * @key: pointer to the key to search for
+ *
+ * The list of parameters is come separated.
+ *
+ * Return: True if key has been found.
+ */
+static bool found_key(const char *str, const char *key)
+{
+ char *k;
+ char *s, *strcopy;
+ bool result = false;
+
+ strcopy = strdup(str);
+ if (!strcopy)
+ return NULL;
+
+ s = strcopy;
+ while (s) {
+ k = strsep(&s, ",");
+ if (!k)
+ break;
+ if (strcmp(k, key) == 0) {
+ result = true;
+ break;
+ }
+ }
+
+ free(strcopy);
+
+ return result;
+}
+
+static int str_to_partitions(const char *str_part, int blksz,
+ unsigned long *disk_uuid, struct disk_partition **partitions
[PATCH v3 4/6] disk: dos: make some functions static
Make functions not used outside this file static.
Signed-off-by: Marek Szyprowski
---
disk/part_dos.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/disk/part_dos.c b/disk/part_dos.c
index 3b79b9b1b8..2c4ad0b6ba 100644
--- a/disk/part_dos.c
+++ b/disk/part_dos.c
@@ -302,13 +302,13 @@ static int part_get_info_extended(struct blk_desc
*dev_desc,
return -1;
}
-void part_print_dos(struct blk_desc *dev_desc)
+static void part_print_dos(struct blk_desc *dev_desc)
{
printf("Part\tStart Sector\tNum Sectors\tUUID\t\tType\n");
print_partition_extended(dev_desc, 0, 0, 1, 0);
}
-int part_get_info_dos(struct blk_desc *dev_desc, int part,
+static int part_get_info_dos(struct blk_desc *dev_desc, int part,
struct disk_partition *info)
{
return part_get_info_extended(dev_desc, 0, 0, 1, part, info, 0);
--
2.17.1
[PATCH v3 0/6] Add MBR partition table creation and verify command
Hi All, This patchset adds 'mbr' command to let one to create or verify MBR (Master Boot Record) partition layout based on the provided text description. This can be used in scripts to help system flashing tools/scripts to ensure proper partition layout. It has been inspired by the 'gpt' command already present in u-boot. Best regards Marek Szyprowski Samsung R&D Institute Poland Changelog: v3: - fixed minor issues in the docs v2: https://lists.denx.de/pipermail/u-boot/2020-December/435689.html - added docs and minor fixes in the code style v1: https://lists.denx.de/pipermail/u-boot/2020-December/435208.html - initial version Patch summary: Marek Szyprowski (6): disk: dos: rename write_mbr_partition to write_mbr_sector disk: dos: add some defines for the hardcoded numbers disk: dos: use generic macro for unaligned le32 access disk: dos: make some functions static disk: dos: add code for creating MBR partition layout cmd: Add MBR partition layout control utility cmd/Kconfig | 8 + cmd/Makefile | 1 + cmd/mbr.c | 314 ++ disk/part_dos.c | 207 ++--- disk/part_dos.h | 5 + doc/usage/index.rst | 1 + doc/usage/mbr.rst | 93 +++ drivers/fastboot/fb_mmc.c | 2 +- include/part.h| 9 +- 9 files changed, 612 insertions(+), 28 deletions(-) create mode 100644 cmd/mbr.c create mode 100644 doc/usage/mbr.rst -- 2.17.1
Re: [PATCH] board: amlogic: vim3: fix setup ethernet mac from efuse
Hi Artem,
On 12.01.2021 06:03, Artem Lapkin wrote:
> Fix reading built-in ethernet MAC address from efuse
>
> NOTE: MAC is stored in ASCII format, 1bytes = 2characters by 0 offset
>
> if mac from efuse not valid we use meson_generate_serial_ethaddr
>
> NOTE: remake odroid-n2.c variant from Neil Armstrong
>
> Signed-off-by: Artem Lapkin
First of all, thanks pointing again at this issue.
I've implemented reading of MAC address from EFUSE for VIM boards and I
was convinced that it is stored in binary format. I've based my
assumptions on the vendor code, especially the message from the vendor
kernel:
[ 4.028236] efusekeynum: 1
[ 4.031072] efusekeyname: mac offset: 0 size: 6
[ 4.037542] efuse efuse: probe OK!
and the vendors dts:
https://github.com/khadas/linux/blob/khadas-vims-4.9.y/arch/arm64/boot/dts/amlogic/kvim3_linux.dts#L506
which both points that the EFUSE key has only 6 bytes, what means binary
format. I didn't check it further what is really stored there.
Now I checked again and it looks that the DTS (and thus vendor's kernel
message) is incorrect, as the MAC is stored in ASCII and occupies 12
bytes in efuse. One can check that with vendor's kernel:
# cat /sys/class/efuse/userdata
0x00: 43 38 36 33 31 34 37 30 41 38 44 37 00 00 00 00
0x10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
...
This means that your patch is correct, although I would change it a bit.
BTW, the Odroid N2/C4 boards don't have MAC stored explicitly in the
EFUSE, but the boards UUID. The original code use the last bytes of the
UUID as the MAC address.
> ---
> board/amlogic/vim3/vim3.c | 22 +++---
> 1 file changed, 19 insertions(+), 3 deletions(-)
>
> diff --git a/board/amlogic/vim3/vim3.c b/board/amlogic/vim3/vim3.c
> index 824fff8262..87d9fe1f02 100644
> --- a/board/amlogic/vim3/vim3.c
> +++ b/board/amlogic/vim3/vim3.c
> @@ -139,26 +139,42 @@ int meson_ft_board_setup(void *blob, struct bd_info *bd)
> }
>
> #define EFUSE_MAC_OFFSET0
> -#define EFUSE_MAC_SIZE 6
> +#define EFUSE_MAC_SIZE 12
> +#define MAC_ADDR_LEN 6
>
> int misc_init_r(void)
> {
> - uint8_t mac_addr[EFUSE_MAC_SIZE];
> + uint8_t mac_addr[MAC_ADDR_LEN];
> + char efuse_mac_addr[EFUSE_MAC_SIZE], tmp[3];
> ssize_t len;
>
> meson_eth_init(PHY_INTERFACE_MODE_RGMII, 0);
>
> if (!eth_env_get_enetaddr("ethaddr", mac_addr)) {
> len = meson_sm_read_efuse(EFUSE_MAC_OFFSET,
> - mac_addr, EFUSE_MAC_SIZE);
> + efuse_mac_addr, EFUSE_MAC_SIZE);
> if (len != EFUSE_MAC_SIZE)
> return 0;
>
> + /* MAC is stored in ASCII format, 1bytes = 2characters */
> + for (int i = 0; i < 6; i++) {
> + tmp[0] = efuse_mac_addr[i * 2];
> + tmp[1] = efuse_mac_addr[i * 2 + 1];
> + tmp[2] = '\0';
> + mac_addr[i] = simple_strtoul(tmp, NULL, 16);
> + }
> +
> if (is_valid_ethaddr(mac_addr))
> eth_env_set_enetaddr("ethaddr", mac_addr);
> else
> meson_generate_serial_ethaddr();
Now the above code is the same as for Odroid N2/C4, so it can be moved
to arch/arm/mach-meson/board-common.c, maybe as
meson_read_efuse_mac_addr() with the offset as parameter, so it can be
directly used by Odroids and VIMs.
> +
> + eth_env_get_enetaddr("ethaddr", mac_addr);
> + printf("[i] setup onboard mac %02X:%02X:%02X:%02X:%02X:%02X\n",
> + mac_addr[0],mac_addr[1],mac_addr[2],
> + mac_addr[3],mac_addr[4],mac_addr[5]);
I'm not really convinced that this message has to be displayed. If so,
then use "%pM" for printing MAC address.
> }
>
> return 0;
> }
> +
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
Re: [PATCH 2/2] usb: xhci: Load Raspberry Pi 4 VL805's firmware
Hi Nicolas,
On 28.04.2020 19:44, Nicolas Saenz Julienne wrote:
> When needed, RPi4's co-processor (called VideoCore) has to be instructed
> to load VL805's firmware (the chip providing xHCI support). VideCore's
> firmware expects the board's PCIe bus to be already configured in order
> for it to load the xHCI chip firmware. So we have to make sure this
> happens in between the PCIe configuration and xHCI startup.
>
> Signed-off-by: Nicolas Saenz Julienne
> ---
> drivers/usb/host/xhci-pci.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
> index c1f60da541..5c17ea6932 100644
> --- a/drivers/usb/host/xhci-pci.c
> +++ b/drivers/usb/host/xhci-pci.c
> @@ -11,6 +11,8 @@
> #include
> #include
>
> +#include
> +
Does the above include works on the other archs?
> static void xhci_pci_init(struct udevice *dev, struct xhci_hccr **ret_hccr,
> struct xhci_hcor **ret_hcor)
> {
> @@ -18,6 +20,10 @@ static void xhci_pci_init(struct udevice *dev, struct
> xhci_hccr **ret_hccr,
> struct xhci_hcor *hcor;
> u32 cmd;
>
> +#ifdef CONFIG_BCM2711
> + bcm2711_load_vl805_firmware();
> +#endif
> +
> hccr = (struct xhci_hccr *)dm_pci_map_bar(dev,
> PCI_BASE_ADDRESS_0, PCI_REGION_MEM);
> hcor = (struct xhci_hcor *)((uintptr_t) hccr +
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
Re: [Patch V4 3/3] configs: rpi_4 : enable SDHCI_SDMA config
Hi Matthias and Jaehoon, On 27.03.2020 14:12, Matthias Brugger wrote: > On 27/03/2020 05:08, Jaehoon Chung wrote: >> Enable SDHCI_SDMA configuration. >> >> Signed-off-by: Jaehoon Chung >> Reviewed-by: Peng Fan >> Reviewed-by: Minkyu Kang >> --- >> configs/rpi_4_32b_defconfig | 1 + >> configs/rpi_4_defconfig | 1 + >> 2 files changed, 2 insertions(+) >> > Please address the comments I had in v3 of this patch: > https://protect2.fireeye.com/url?k=006fd2e9-5dbfda25-006e59a6-000babff3793-1cb73b2d76c550f7&u=https://patchwork.ozlabs.org/patch/1261047/ > > If you just send a new version of the patch that won't convince me to take it. > We will need to make sure that we are fine with patch. Especially I'm > concerned > about the limitation of the device to only be able to access the first GiB of > RAM for DMA. I'd like to see an explanation why this won't happen on U-Boot. According to my investigation related to the PCIe XHCI driver and its DMA: https://patchwork.ozlabs.org/project/uboot/patch/20200424165012.31915-10-s.nawro...@samsung.com/#2418327 transfers to any buffer which has been allocated with malloc/memalign are safe. Malloc region is initialized in runtime and placed nearly by the end of the first memory bank, which in case of Pi4 is always below the first GiB. Transfers to the arbitrary regions above the first GiB will fail. Adding a check for such case might be a good idea. Later one can even add a fallback with temporary malloc buffer (or PIO mode if switching on fly is possible) and memcpy for the transfers above the first GiB if there is such need. Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland
[PATCH] configs: rpi_arm64: sync env size with rpi_{3,4}_defconfig
Use the same environment size as the configs dedicated for rpi3 and rpi4. This allows to switch between the builds and not to loose the settings stored on the SD card. Signed-off-by: Marek Szyprowski --- configs/rpi_arm64_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/rpi_arm64_defconfig b/configs/rpi_arm64_defconfig index 926dfc3..7c59400 100644 --- a/configs/rpi_arm64_defconfig +++ b/configs/rpi_arm64_defconfig @@ -3,6 +3,7 @@ CONFIG_ARCH_BCM283X=y CONFIG_SYS_TEXT_BASE=0x0008 CONFIG_TARGET_RPI_ARM64=y CONFIG_SYS_MALLOC_F_LEN=0x2000 +CONFIG_ENV_SIZE=0x4000 CONFIG_NR_DRAM_BANKS=2 CONFIG_DISTRO_DEFAULTS=y CONFIG_OF_BOARD_SETUP=y -- 1.9.1
Re: [PATCH v2 10/10] config: Enable support for the XHCI controller on RPI4 board
Hi On 05.05.2020 13:15, Bin Meng wrote: > On Mon, May 4, 2020 at 8:45 PM Sylwester Nawrocki > wrote: >> From: Marek Szyprowski >> >> This requires enabling BRCMSTB PCIe and XHCI_PCI drivers as well as PCI >> and USB commands. To get it working one has to call the following commands: >> "pci enum; usb start;", thus such commands have been added to the default >> "preboot" environment variable. One has to update their environment if it >> is already configured to get this feature working out of the box. >> >> Signed-off-by: Marek Szyprowski >> Signed-off-by: Sylwester Nawrocki >> --- >> Changes since v1: >> - removed unneeded CONFIG_XHCI_64BIT_DWORD_ACCESS_ONLY entry. >> >> Changes since RFC: >> - none. >> --- >> configs/rpi_4_32b_defconfig | 9 + >> configs/rpi_4_defconfig | 9 + >> configs/rpi_arm64_defconfig | 8 +++- >> 3 files changed, 25 insertions(+), 1 deletion(-) >> > What are these 3 defconfigs files for? Seems there is no MAINTAINERS > mentioning them. > > I assume rpi_4_32b_defconfig is for 32-bit U-Boot and rpi_4_defconfig > is for 64-bit U-Boot for RPi 4? What is rpi_arm64_defconfig? rpi_arm64_defconfig is for common image, which works on both RPi 3 and RPi 4. Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland
Re: [PATCH v2 05/10] rpi4: add a mapping for the PCIe XHCI controller MMIO registers (ARM 64bit)
Hi Matthias,
On 05.05.2020 16:00, Matthias Brugger wrote:
> On 04/05/2020 14:45, Sylwester Nawrocki wrote:
>> From: Marek Szyprowski
>>
>> Create a non-cacheable mapping for the 0x6 physical memory region,
>> where MMIO registers for the PCIe XHCI controller are instantiated by the
>> PCIe bridge.
>>
>> Signed-off-by: Marek Szyprowski
>> Signed-off-by: Sylwester Nawrocki
>> Reviewed-by: Nicolas Saenz Julienne
>> ---
>> Changes since v1:
>> - none.
>> ---
>> arch/arm/mach-bcm283x/init.c | 18 +++---
>> 1 file changed, 15 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/arm/mach-bcm283x/init.c b/arch/arm/mach-bcm283x/init.c
>> index 4295356..6a748da 100644
>> --- a/arch/arm/mach-bcm283x/init.c
>> +++ b/arch/arm/mach-bcm283x/init.c
>> @@ -11,10 +11,15 @@
>> #include
>> #include
>>
>> +#define BCM2711_RPI4_PCIE_XHCI_MMIO_PHYS0x6UL
>> +#define BCM2711_RPI4_PCIE_XHCI_MMIO_SIZE0x80UL
>> +
>> #ifdef CONFIG_ARM64
>> #include
>>
>> -static struct mm_region bcm283x_mem_map[] = {
>> +#define MAX_MAP_MAX_ENTRIES (4)
> What stands the second 'MAX' for?
a simple copy/paste issue. I will fix it.
>> +
>> +static struct mm_region bcm283x_mem_map[MAX_MAP_MAX_ENTRIES] = {
>> {
>> .virt = 0xUL,
>> .phys = 0xUL,
>> @@ -34,7 +39,7 @@ static struct mm_region bcm283x_mem_map[] = {
>> }
>> };
>>
>> -static struct mm_region bcm2711_mem_map[] = {
>> +static struct mm_region bcm2711_mem_map[MAX_MAP_MAX_ENTRIES] = {
>> {
>> .virt = 0xUL,
>> .phys = 0xUL,
>> @@ -49,6 +54,13 @@ static struct mm_region bcm2711_mem_map[] = {
>> PTE_BLOCK_NON_SHARE |
>> PTE_BLOCK_PXN | PTE_BLOCK_UXN
>> }, {
> I'd prefer a comment instead of using the BCM2711_RPI4_PCIE_XHCI_MMIO_*
> defines.
Those defines are also used in ARM 32bit code.
>> +.virt = BCM2711_RPI4_PCIE_XHCI_MMIO_PHYS> + .phys =
>> BCM2711_RPI4_PCIE_XHCI_MMIO_PHYS,
>> +.size = BCM2711_RPI4_PCIE_XHCI_MMIO_SIZE,
>> +.attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
>> + PTE_BLOCK_NON_SHARE |
>> + PTE_BLOCK_PXN | PTE_BLOCK_UXN
>> +}, {
>> /* List terminator */
>> 0,
>> }
>> @@ -71,7 +83,7 @@ static void _rpi_update_mem_map(struct mm_region *pd)
>> {
>> int i;
>>
>> -for (i = 0; i < 2; i++) {
>> +for (i = 0; i < MAX_MAP_MAX_ENTRIES; i++) {
> Variable mem_map points to bcm283x_mem_map which only holds two mm_region's
> (plus list terminator). So we have an overflow here.
Nope, I've changed the bcm283x_mem_map to be large enough, see the above
diff.
> I think we should just
> define bcm2711_mem_map and bcm283x_mem_map with a fixed array size of 4 (see
> comment on the define naming above).
That's exactly what I did.
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
Re: [PATCH v2 06/10] rpi4: add a mapping for the PCIe XHCI controller MMIO registers (ARM 32bit)
Hi Matthias,
On 05.05.2020 16:25, Matthias Brugger wrote:
> On 04/05/2020 14:45, Sylwester Nawrocki wrote:
>> From: Marek Szyprowski
>>
>> Create a non-cacheable mapping for the 0x6 physical memory region,
>> where MMIO registers for the PCIe XHCI controller are instantiated by the
>> PCIe bridge. Due to 32bit limit in the CPU virtual address space in ARM
>> 32bit mode, this region is mapped at 0xff80 CPU virtual address.
>>
>> Signed-off-by: Marek Szyprowski
>> Signed-off-by: Sylwester Nawrocki
>> ---
>> Changes since v1:
>> - none.
>> ---
>> arch/arm/mach-bcm283x/Kconfig | 1 +
>> arch/arm/mach-bcm283x/include/mach/base.h | 7 +
>> arch/arm/mach-bcm283x/init.c | 52
>> +++
>> 3 files changed, 60 insertions(+)
>>
>> diff --git a/arch/arm/mach-bcm283x/Kconfig b/arch/arm/mach-bcm283x/Kconfig
>> index 00419bf..bcb7f1d 100644
>> --- a/arch/arm/mach-bcm283x/Kconfig
>> +++ b/arch/arm/mach-bcm283x/Kconfig
>> @@ -36,6 +36,7 @@ config BCM2711_32B
>> select BCM2711
>> select ARMV7_LPAE
>> select CPU_V7A
>> +select PHYS_64BIT
>>
>> config BCM2711_64B
>> bool "Broadcom BCM2711 SoC 64-bit support"
>> diff --git a/arch/arm/mach-bcm283x/include/mach/base.h
>> b/arch/arm/mach-bcm283x/include/mach/base.h
>> index c4ae398..1d10dc9 100644
>> --- a/arch/arm/mach-bcm283x/include/mach/base.h
>> +++ b/arch/arm/mach-bcm283x/include/mach/base.h
>> @@ -6,6 +6,13 @@
>> #ifndef _BCM283x_BASE_H_
>> #define _BCM283x_BASE_H_
>>
>> +#include
>> +
>> extern unsigned long rpi_bcm283x_base;
>>
>> +#ifdef CONFIG_ARMV7_LPAE
>> +extern void *rpi4_phys_to_virt(phys_addr_t paddr);
>> +#define phys_to_virt(x) rpi4_phys_to_virt(x)
>> +#endif
>> +
>> #endif
>> diff --git a/arch/arm/mach-bcm283x/init.c b/arch/arm/mach-bcm283x/init.c
>> index 6a748da..5d0d160 100644
>> --- a/arch/arm/mach-bcm283x/init.c
>> +++ b/arch/arm/mach-bcm283x/init.c
>> @@ -145,6 +145,58 @@ int mach_cpu_init(void)
>> }
>>
>> #ifdef CONFIG_ARMV7_LPAE
>> +
>> +#define BCM2711_RPI4_PCIE_XHCI_MMIO_VIRT0xff80UL
>> +
>> +void *rpi4_phys_to_virt(phys_addr_t paddr)
>> +{
>> +if (paddr >= BCM2711_RPI4_PCIE_XHCI_MMIO_PHYS)
>> +paddr = paddr - BCM2711_RPI4_PCIE_XHCI_MMIO_PHYS +
>> +BCM2711_RPI4_PCIE_XHCI_MMIO_VIRT;
>> +return (void *)(unsigned long)paddr;
>> +}
>> +
>> +static void set_section_phys(unsigned int section, phys_addr_t phys,
>> + enum dcache_option option)
>> +{
>> +u64 *page_table = (u64 *)gd->arch.tlb_addr;
>> +/* Need to set the access flag to not fault */
>> +u64 value = TTB_SECT_AP | TTB_SECT_AF;
>> +
>> +/* Add the page offset */
>> +value |= (phys);
>> +
>> +/* Add caching bits */
>> +value |= option;
>> +
>> +/* Set PTE */
>> +page_table[section] = value;
>> +}
>> +
>> +static void rpi4_create_pcie_xhci_mapping(void)
>> +{
>> +unsigned sect = BCM2711_RPI4_PCIE_XHCI_MMIO_VIRT >> MMU_SECTION_SHIFT;
>> +phys_addr_t phys_addr = BCM2711_RPI4_PCIE_XHCI_MMIO_PHYS;
>> +unsigned int size = BCM2711_RPI4_PCIE_XHCI_MMIO_SIZE;
>> +
>> +while (size) {
>> +set_section_phys(sect, phys_addr, DCACHE_OFF);
>> +sect++;
>> +phys_addr += MMU_SECTION_SIZE;
>> + size -= MMU_SECTION_SIZE;
>> +}
> Why can't we reuse mmu_set_region_dcache_behaviour()?
Because it doesn't allow to set arbirtary physical address - it only
works for the cases where phys == virt.
>
>> +}
>> +
>> +void arm_init_domains(void)
>> +{
>> +/*
>> + * Hijack this function to prepare a mappings for the PCIe MMIO
>> + * region for the XHCI controller on RPi4 board.
>> + * This code is called before enabling the MMU in ARM 32bit mode.
>> + */
>> +rpi4_create_pcie_xhci_mapping();
> I think this indirection is not necessary.
Okay.
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
Re: [PATCH v2 06/10] rpi4: add a mapping for the PCIe XHCI controller MMIO registers (ARM 32bit)
Hi Matthias,
On 08.05.2020 23:26, Matthias Brugger wrote:
> Adding Tom as he is the arm maintainer.
>
> On 04/05/2020 14:45, Sylwester Nawrocki wrote:
>> From: Marek Szyprowski
>>
>> Create a non-cacheable mapping for the 0x6 physical memory region,
>> where MMIO registers for the PCIe XHCI controller are instantiated by the
>> PCIe bridge. Due to 32bit limit in the CPU virtual address space in ARM
>> 32bit mode, this region is mapped at 0xff800000 CPU virtual address.
>>
>> Signed-off-by: Marek Szyprowski
>> Signed-off-by: Sylwester Nawrocki
>> ---
>> Changes since v1:
>> - none.
>> ---
>> arch/arm/mach-bcm283x/Kconfig | 1 +
>> arch/arm/mach-bcm283x/include/mach/base.h | 7 +
>> arch/arm/mach-bcm283x/init.c | 52
>> +++
>> 3 files changed, 60 insertions(+)
>>
>> diff --git a/arch/arm/mach-bcm283x/Kconfig b/arch/arm/mach-bcm283x/Kconfig
>> index 00419bf..bcb7f1d 100644
>> --- a/arch/arm/mach-bcm283x/Kconfig
>> +++ b/arch/arm/mach-bcm283x/Kconfig
>> @@ -36,6 +36,7 @@ config BCM2711_32B
>> select BCM2711
>> select ARMV7_LPAE
>> select CPU_V7A
>> +select PHYS_64BIT
>>
>> config BCM2711_64B
>> bool "Broadcom BCM2711 SoC 64-bit support"
>> diff --git a/arch/arm/mach-bcm283x/include/mach/base.h
>> b/arch/arm/mach-bcm283x/include/mach/base.h
>> index c4ae398..1d10dc9 100644
>> --- a/arch/arm/mach-bcm283x/include/mach/base.h
>> +++ b/arch/arm/mach-bcm283x/include/mach/base.h
>> @@ -6,6 +6,13 @@
>> #ifndef _BCM283x_BASE_H_
>> #define _BCM283x_BASE_H_
>>
>> +#include
>> +
>> extern unsigned long rpi_bcm283x_base;
>>
>> +#ifdef CONFIG_ARMV7_LPAE
>> +extern void *rpi4_phys_to_virt(phys_addr_t paddr);
>> +#define phys_to_virt(x) rpi4_phys_to_virt(x)
>> +#endif
>> +
>> #endif
>> diff --git a/arch/arm/mach-bcm283x/init.c b/arch/arm/mach-bcm283x/init.c
>> index 6a748da..5d0d160 100644
>> --- a/arch/arm/mach-bcm283x/init.c
>> +++ b/arch/arm/mach-bcm283x/init.c
>> @@ -145,6 +145,58 @@ int mach_cpu_init(void)
>> }
>>
>> #ifdef CONFIG_ARMV7_LPAE
>> +
>> +#define BCM2711_RPI4_PCIE_XHCI_MMIO_VIRT0xff80UL
>> +
>> +void *rpi4_phys_to_virt(phys_addr_t paddr)
>> +{
>> +if (paddr >= BCM2711_RPI4_PCIE_XHCI_MMIO_PHYS)
>> +paddr = paddr - BCM2711_RPI4_PCIE_XHCI_MMIO_PHYS +
>> +BCM2711_RPI4_PCIE_XHCI_MMIO_VIRT;
>> +return (void *)(unsigned long)paddr;
> I think for this cases we have addrmap_phys_to_virt() which up to now is only
> used by powerpc.
>
>> +}
>> +
>> +static void set_section_phys(unsigned int section, phys_addr_t phys,
>> + enum dcache_option option)
>> +{
>> +u64 *page_table = (u64 *)gd->arch.tlb_addr;
>> +/* Need to set the access flag to not fault */
>> +u64 value = TTB_SECT_AP | TTB_SECT_AF;
>> +
>> +/* Add the page offset */
>> +value |= (phys);
>> +
>> +/* Add caching bits */
>> +value |= option;
>> +
>> +/* Set PTE */
>> +page_table[section] = value;
>> +}
>> +
>> +static void rpi4_create_pcie_xhci_mapping(void)
>> +{
>> +unsigned sect = BCM2711_RPI4_PCIE_XHCI_MMIO_VIRT >> MMU_SECTION_SHIFT;
>> +phys_addr_t phys_addr = BCM2711_RPI4_PCIE_XHCI_MMIO_PHYS;
>> +unsigned int size = BCM2711_RPI4_PCIE_XHCI_MMIO_SIZE;
>> +
>> +while (size) {
>> +set_section_phys(sect, phys_addr, DCACHE_OFF);
>> +sect++;
>> +phys_addr += MMU_SECTION_SIZE;
>> + size -= MMU_SECTION_SIZE;
>> +}
>> +}
> I wonder if we can't do all this in the pcie driver probe function. Maybe we
> can
> create a new function like mmu_set_region_dcache_behaviour_phys which allows
> us
> to update a mapping that's not 1:1.
>
> Tom what do you think?
In theory this could be moved to pcie probe, but then how the pcie
driver would know WHERE in the virtual address space it should create a
mapping for the needed MMIO area? IMHO this is something SoC or board
specific and creating such mapping in board init is justified.
I will adapt the code to use addr_map helpers.
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
[RFC PATCH 2/2] rpi4: add a mapping for the PCIe XHCI controller MMIO registers (ARM 32bit)
Create a non-cacheable mapping for the 0x6 physical memory region,
where MMIO registers for the PCIe XHCI controller are instantiated by the
PCIe bridge. Due to 32bit limit in the CPU virtual address space in ARM
32bit mode, this region is mapped at 0xff80 CPU virtual address.
Signed-off-by: Marek Szyprowski
---
arch/arm/mach-bcm283x/Kconfig | 1 +
arch/arm/mach-bcm283x/include/mach/base.h | 6 ++
arch/arm/mach-bcm283x/init.c | 14 ++
include/configs/rpi.h | 5 +
4 files changed, 26 insertions(+)
diff --git a/arch/arm/mach-bcm283x/Kconfig b/arch/arm/mach-bcm283x/Kconfig
index 00419bf..bcb7f1d 100644
--- a/arch/arm/mach-bcm283x/Kconfig
+++ b/arch/arm/mach-bcm283x/Kconfig
@@ -36,6 +36,7 @@ config BCM2711_32B
select BCM2711
select ARMV7_LPAE
select CPU_V7A
+ select PHYS_64BIT
config BCM2711_64B
bool "Broadcom BCM2711 SoC 64-bit support"
diff --git a/arch/arm/mach-bcm283x/include/mach/base.h
b/arch/arm/mach-bcm283x/include/mach/base.h
index c4ae398..1bf89db 100644
--- a/arch/arm/mach-bcm283x/include/mach/base.h
+++ b/arch/arm/mach-bcm283x/include/mach/base.h
@@ -8,4 +8,10 @@
extern unsigned long rpi_bcm283x_base;
+#ifdef CONFIG_ARMV7_LPAE
+#include
+#define phys_to_virt addrmap_phys_to_virt
+#define virt_to_phys addrmap_virt_to_phys
+#endif
+
#endif
diff --git a/arch/arm/mach-bcm283x/init.c b/arch/arm/mach-bcm283x/init.c
index 6a748da..4b9c831 100644
--- a/arch/arm/mach-bcm283x/init.c
+++ b/arch/arm/mach-bcm283x/init.c
@@ -145,6 +145,20 @@ int mach_cpu_init(void)
}
#ifdef CONFIG_ARMV7_LPAE
+#define BCM2711_RPI4_PCIE_XHCI_MMIO_VIRT 0xff80UL
+#include
+
+void init_addr_map(void)
+{
+ mmu_set_region_dcache_behaviour_phys(BCM2711_RPI4_PCIE_XHCI_MMIO_VIRT,
+BCM2711_RPI4_PCIE_XHCI_MMIO_PHYS,
+BCM2711_RPI4_PCIE_XHCI_MMIO_SIZE,
+DCACHE_OFF);
+ addrmap_set_entry(BCM2711_RPI4_PCIE_XHCI_MMIO_VIRT,
+ BCM2711_RPI4_PCIE_XHCI_MMIO_PHYS,
+ BCM2711_RPI4_PCIE_XHCI_MMIO_SIZE, 0);
+}
+
void enable_caches(void)
{
dcache_enable();
diff --git a/include/configs/rpi.h b/include/configs/rpi.h
index b53a4b6..7da2cff 100644
--- a/include/configs/rpi.h
+++ b/include/configs/rpi.h
@@ -63,6 +63,11 @@
#define CONFIG_SYS_BOOTM_LEN SZ_64M
#endif
+#ifdef CONFIG_ARMV7_LPAE
+#define CONFIG_ADDR_MAP 1
+#define CONFIG_SYS_NUM_ADDR_MAP 2
+#endif
+
/* Devices */
/* GPIO */
#define CONFIG_BCM2835_GPIO
--
1.9.1
[RFC PATCH 1/2] arm: provide a function for boards init code to modify MMU virtual-physical map
Provide a function for setting arbitrary virtual-physical MMU mapping
for the given region.
Signed-off-by: Marek Szyprowski
---
arch/arm/include/asm/mmu.h| 8
arch/arm/include/asm/system.h | 18 --
arch/arm/lib/cache-cp15.c | 18 --
3 files changed, 36 insertions(+), 8 deletions(-)
create mode 100644 arch/arm/include/asm/mmu.h
diff --git a/arch/arm/include/asm/mmu.h b/arch/arm/include/asm/mmu.h
new file mode 100644
index 000..fe3d793
--- /dev/null
+++ b/arch/arm/include/asm/mmu.h
@@ -0,0 +1,8 @@
+#ifndef __ASM_ARM_MMU_H
+#define __ASM_ARM_MMU_H
+
+#ifdef CONFIG_ADDR_MAP
+extern void init_addr_map(void);
+#endif
+
+#endif
diff --git a/arch/arm/include/asm/system.h b/arch/arm/include/asm/system.h
index 81ccead..a513f4a 100644
--- a/arch/arm/include/asm/system.h
+++ b/arch/arm/include/asm/system.h
@@ -573,14 +573,28 @@ s32 psci_features(u32 function_id, u32 psci_fid);
void save_boot_params_ret(void);
/**
+ * Change the virt/phys mapping and cache settings for a region.
+ *
+ * \param virt virtual start address of memory region to change
+ * \param phys physical address for the memory region to set
+ * \param size size of memory region to change
+ * \param option dcache option to select
+ */
+void mmu_set_region_dcache_behaviour_phys(phys_addr_t virt, phys_addr_t phys,
+ size_t size, enum dcache_option option);
+
+/**
* Change the cache settings for a region.
*
* \param startstart address of memory region to change
* \param size size of memory region to change
* \param option dcache option to select
*/
-void mmu_set_region_dcache_behaviour(phys_addr_t start, size_t size,
-enum dcache_option option);
+static inline void mmu_set_region_dcache_behaviour(phys_addr_t start,
+ size_t size, enum dcache_option option)
+{
+ mmu_set_region_dcache_behaviour_phys(start, start, size, option);
+}
#ifdef CONFIG_SYS_NONCACHED_MEMORY
void noncached_init(void);
diff --git a/arch/arm/lib/cache-cp15.c b/arch/arm/lib/cache-cp15.c
index f8d2096..7c14d1d 100644
--- a/arch/arm/lib/cache-cp15.c
+++ b/arch/arm/lib/cache-cp15.c
@@ -24,7 +24,8 @@ __weak void arm_init_domains(void)
{
}
-void set_section_dcache(int section, enum dcache_option option)
+static void set_section_phys(int section, phys_addr_t phys,
+enum dcache_option option)
{
#ifdef CONFIG_ARMV7_LPAE
u64 *page_table = (u64 *)gd->arch.tlb_addr;
@@ -36,7 +37,7 @@ void set_section_dcache(int section, enum dcache_option
option)
#endif
/* Add the page offset */
- value |= ((u32)section << MMU_SECTION_SHIFT);
+ value |= phys;
/* Add caching bits */
value |= option;
@@ -45,13 +46,18 @@ void set_section_dcache(int section, enum dcache_option
option)
page_table[section] = value;
}
+void set_section_dcache(int section, enum dcache_option option)
+{
+ set_section_phys(section, (u32)section << MMU_SECTION_SHIFT, option);
+}
+
__weak void mmu_page_table_flush(unsigned long start, unsigned long stop)
{
debug("%s: Warning: not implemented\n", __func__);
}
-void mmu_set_region_dcache_behaviour(phys_addr_t start, size_t size,
-enum dcache_option option)
+void mmu_set_region_dcache_behaviour_phys(phys_addr_t start, phys_addr_t phys,
+ size_t size, enum dcache_option option)
{
#ifdef CONFIG_ARMV7_LPAE
u64 *page_table = (u64 *)gd->arch.tlb_addr;
@@ -70,8 +76,8 @@ void mmu_set_region_dcache_behaviour(phys_addr_t start,
size_t size,
debug("%s: start=%pa, size=%zu, option=0x%x\n", __func__, &start, size,
option);
#endif
- for (upto = start; upto < end; upto++)
- set_section_dcache(upto, option);
+ for (upto = start; upto < end; upto++, phys += MMU_SECTION_SIZE)
+ set_section_phys(upto, phys, option);
/*
* Make sure range is cache line aligned
--
1.9.1
[RFC PATCH 0/2] ARM: arbitrary virtual-physical mappings for RPi4 XHCI support
Hi All, This is a result of the following discussion: https://lists.denx.de/pipermail/u-boot/2020-May/411086.html Those 2 patches are replacement for the patch discussed there. Best regards Marek Szyprowski Samsung R&D Institute Poland Marek Szyprowski (2): arm: provide a function for boards init code to modify MMU virtual-physical map rpi4: add a mapping for the PCIe XHCI controller MMIO registers (ARM 32bit) arch/arm/include/asm/mmu.h| 8 arch/arm/include/asm/system.h | 18 -- arch/arm/lib/cache-cp15.c | 18 -- arch/arm/mach-bcm283x/Kconfig | 1 + arch/arm/mach-bcm283x/include/mach/base.h | 6 ++ arch/arm/mach-bcm283x/init.c | 14 ++ include/configs/rpi.h | 5 + 7 files changed, 62 insertions(+), 8 deletions(-) create mode 100644 arch/arm/include/asm/mmu.h -- 1.9.1
[RFC PATCH v2 0/2] ARM: arbitrary virtual-physical mappings for RPi4 XHCI support
Hi All, This is a result of the following discussion: https://lists.denx.de/pipermail/u-boot/2020-May/411086.html Those 2 patches are replacement for the patch discussed there. V2 fixes ARM64 build. Best regards Marek Szyprowski Samsung R&D Institute Poland Marek Szyprowski (2): arm: provide a function for boards init code to modify MMU virtual-physical map rpi4: add a mapping for the PCIe XHCI controller MMIO registers (ARM 32bit) arch/arm/include/asm/mmu.h| 8 arch/arm/include/asm/system.h | 11 +++ arch/arm/lib/cache-cp15.c | 24 ++-- arch/arm/mach-bcm283x/Kconfig | 1 + arch/arm/mach-bcm283x/include/mach/base.h | 6 ++ arch/arm/mach-bcm283x/init.c | 14 ++ include/configs/rpi.h | 5 + 7 files changed, 63 insertions(+), 6 deletions(-) create mode 100644 arch/arm/include/asm/mmu.h -- 1.9.1
[RFC PATCH v2 1/2] arm: provide a function for boards init code to modify MMU virtual-physical map
Provide a function for setting arbitrary virtual-physical MMU mapping
for the given region.
Signed-off-by: Marek Szyprowski
---
arch/arm/include/asm/mmu.h| 8
arch/arm/include/asm/system.h | 11 +++
arch/arm/lib/cache-cp15.c | 24 ++--
3 files changed, 37 insertions(+), 6 deletions(-)
create mode 100644 arch/arm/include/asm/mmu.h
diff --git a/arch/arm/include/asm/mmu.h b/arch/arm/include/asm/mmu.h
new file mode 100644
index 000..fe3d793
--- /dev/null
+++ b/arch/arm/include/asm/mmu.h
@@ -0,0 +1,8 @@
+#ifndef __ASM_ARM_MMU_H
+#define __ASM_ARM_MMU_H
+
+#ifdef CONFIG_ADDR_MAP
+extern void init_addr_map(void);
+#endif
+
+#endif
diff --git a/arch/arm/include/asm/system.h b/arch/arm/include/asm/system.h
index 81ccead..5b9f31c 100644
--- a/arch/arm/include/asm/system.h
+++ b/arch/arm/include/asm/system.h
@@ -573,6 +573,17 @@ s32 psci_features(u32 function_id, u32 psci_fid);
void save_boot_params_ret(void);
/**
+ * Change the virt/phys mapping and cache settings for a region.
+ *
+ * \param virt virtual start address of memory region to change
+ * \param phys physical address for the memory region to set
+ * \param size size of memory region to change
+ * \param option dcache option to select
+ */
+void mmu_set_region_dcache_behaviour_phys(phys_addr_t virt, phys_addr_t phys,
+ size_t size, enum dcache_option option);
+
+/**
* Change the cache settings for a region.
*
* \param startstart address of memory region to change
diff --git a/arch/arm/lib/cache-cp15.c b/arch/arm/lib/cache-cp15.c
index f8d2096..84ddad3 100644
--- a/arch/arm/lib/cache-cp15.c
+++ b/arch/arm/lib/cache-cp15.c
@@ -24,7 +24,8 @@ __weak void arm_init_domains(void)
{
}
-void set_section_dcache(int section, enum dcache_option option)
+static void set_section_phys(int section, phys_addr_t phys,
+enum dcache_option option)
{
#ifdef CONFIG_ARMV7_LPAE
u64 *page_table = (u64 *)gd->arch.tlb_addr;
@@ -36,7 +37,7 @@ void set_section_dcache(int section, enum dcache_option
option)
#endif
/* Add the page offset */
- value |= ((u32)section << MMU_SECTION_SHIFT);
+ value |= phys;
/* Add caching bits */
value |= option;
@@ -45,13 +46,18 @@ void set_section_dcache(int section, enum dcache_option
option)
page_table[section] = value;
}
+void set_section_dcache(int section, enum dcache_option option)
+{
+ set_section_phys(section, (u32)section << MMU_SECTION_SHIFT, option);
+}
+
__weak void mmu_page_table_flush(unsigned long start, unsigned long stop)
{
debug("%s: Warning: not implemented\n", __func__);
}
-void mmu_set_region_dcache_behaviour(phys_addr_t start, size_t size,
-enum dcache_option option)
+void mmu_set_region_dcache_behaviour_phys(phys_addr_t start, phys_addr_t phys,
+ size_t size, enum dcache_option option)
{
#ifdef CONFIG_ARMV7_LPAE
u64 *page_table = (u64 *)gd->arch.tlb_addr;
@@ -70,8 +76,8 @@ void mmu_set_region_dcache_behaviour(phys_addr_t start,
size_t size,
debug("%s: start=%pa, size=%zu, option=0x%x\n", __func__, &start, size,
option);
#endif
- for (upto = start; upto < end; upto++)
- set_section_dcache(upto, option);
+ for (upto = start; upto < end; upto++, phys += MMU_SECTION_SIZE)
+ set_section_phys(upto, phys, option);
/*
* Make sure range is cache line aligned
@@ -86,6 +92,12 @@ void mmu_set_region_dcache_behaviour(phys_addr_t start,
size_t size,
mmu_page_table_flush(startpt, stoppt);
}
+void mmu_set_region_dcache_behaviour(phys_addr_t start, size_t size,
+enum dcache_option option)
+{
+ mmu_set_region_dcache_behaviour_phys(start, start, size, option);
+}
+
__weak void dram_bank_mmu_setup(int bank)
{
bd_t *bd = gd->bd;
--
1.9.1
[RFC PATCH v2 2/2] rpi4: add a mapping for the PCIe XHCI controller MMIO registers (ARM 32bit)
Create a non-cacheable mapping for the 0x6 physical memory region,
where MMIO registers for the PCIe XHCI controller are instantiated by the
PCIe bridge. Due to 32bit limit in the CPU virtual address space in ARM
32bit mode, this region is mapped at 0xff80 CPU virtual address.
Signed-off-by: Marek Szyprowski
---
arch/arm/mach-bcm283x/Kconfig | 1 +
arch/arm/mach-bcm283x/include/mach/base.h | 6 ++
arch/arm/mach-bcm283x/init.c | 14 ++
include/configs/rpi.h | 5 +
4 files changed, 26 insertions(+)
diff --git a/arch/arm/mach-bcm283x/Kconfig b/arch/arm/mach-bcm283x/Kconfig
index 00419bf..bcb7f1d 100644
--- a/arch/arm/mach-bcm283x/Kconfig
+++ b/arch/arm/mach-bcm283x/Kconfig
@@ -36,6 +36,7 @@ config BCM2711_32B
select BCM2711
select ARMV7_LPAE
select CPU_V7A
+ select PHYS_64BIT
config BCM2711_64B
bool "Broadcom BCM2711 SoC 64-bit support"
diff --git a/arch/arm/mach-bcm283x/include/mach/base.h
b/arch/arm/mach-bcm283x/include/mach/base.h
index c4ae398..1bf89db 100644
--- a/arch/arm/mach-bcm283x/include/mach/base.h
+++ b/arch/arm/mach-bcm283x/include/mach/base.h
@@ -8,4 +8,10 @@
extern unsigned long rpi_bcm283x_base;
+#ifdef CONFIG_ARMV7_LPAE
+#include
+#define phys_to_virt addrmap_phys_to_virt
+#define virt_to_phys addrmap_virt_to_phys
+#endif
+
#endif
diff --git a/arch/arm/mach-bcm283x/init.c b/arch/arm/mach-bcm283x/init.c
index 6a748da..4b9c831 100644
--- a/arch/arm/mach-bcm283x/init.c
+++ b/arch/arm/mach-bcm283x/init.c
@@ -145,6 +145,20 @@ int mach_cpu_init(void)
}
#ifdef CONFIG_ARMV7_LPAE
+#define BCM2711_RPI4_PCIE_XHCI_MMIO_VIRT 0xff80UL
+#include
+
+void init_addr_map(void)
+{
+ mmu_set_region_dcache_behaviour_phys(BCM2711_RPI4_PCIE_XHCI_MMIO_VIRT,
+BCM2711_RPI4_PCIE_XHCI_MMIO_PHYS,
+BCM2711_RPI4_PCIE_XHCI_MMIO_SIZE,
+DCACHE_OFF);
+ addrmap_set_entry(BCM2711_RPI4_PCIE_XHCI_MMIO_VIRT,
+ BCM2711_RPI4_PCIE_XHCI_MMIO_PHYS,
+ BCM2711_RPI4_PCIE_XHCI_MMIO_SIZE, 0);
+}
+
void enable_caches(void)
{
dcache_enable();
diff --git a/include/configs/rpi.h b/include/configs/rpi.h
index b53a4b6..7da2cff 100644
--- a/include/configs/rpi.h
+++ b/include/configs/rpi.h
@@ -63,6 +63,11 @@
#define CONFIG_SYS_BOOTM_LEN SZ_64M
#endif
+#ifdef CONFIG_ARMV7_LPAE
+#define CONFIG_ADDR_MAP 1
+#define CONFIG_SYS_NUM_ADDR_MAP 2
+#endif
+
/* Devices */
/* GPIO */
#define CONFIG_BCM2835_GPIO
--
1.9.1
[PATCH] net: ping: reset stored IP once the command finishes
Reset stored ping IP address before leaving the netloop to ensure that
the subsequent calls to the netloop, especially for the other protocols,
won't be interrupted by the received ICMP_ECHO_REPLY packet.
Signed-off-by: Marek Szyprowski
---
net/ping.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/net/ping.c b/net/ping.c
index 633c942..d912e3d 100644
--- a/net/ping.c
+++ b/net/ping.c
@@ -63,6 +63,7 @@ static int ping_send(void)
static void ping_timeout_handler(void)
{
eth_halt();
+ net_ping_ip.s_addr = 0;
net_set_state(NETLOOP_FAIL);/* we did not get the reply */
}
@@ -84,8 +85,10 @@ void ping_receive(struct ethernet_hdr *et, struct ip_udp_hdr
*ip, int len)
switch (icmph->type) {
case ICMP_ECHO_REPLY:
src_ip = net_read_ip((void *)&ip->ip_src);
- if (src_ip.s_addr == net_ping_ip.s_addr)
+ if (src_ip.s_addr == net_ping_ip.s_addr) {
+ net_ping_ip.s_addr = 0;
net_set_state(NETLOOP_SUCCESS);
+ }
return;
case ICMP_ECHO_REQUEST:
eth_hdr_size = net_update_ether(et, et->et_src, PROT_IP);
--
1.9.1
[PATCH] ARM: bcm283x: change the virtual address of the XHCI PCI device base
Move the XHCI PCI device base up in the virtual address space. This fixes
initialization failure observed with newer Raspberry Pi firmware, later
than 63b1922311 ("firmware: arm_loader: Update armstubs with those from
PR 117). It looks that chosing 0xff80 as the XHCI PCI device base
conflicts with the updated ARM/VideoCore firmware.
This also requires to reduce the size of the mapped PCI device region
from 8MiB to 4MiB to fit into 32bit address space. This is still enough
for the XHCI PCI device.
Signed-off-by: Marek Szyprowski
---
This fixes the issue observed on ARM 32bit after upgrading the RPi4
firmware files, described some time ago here:
https://lists.denx.de/pipermail/u-boot/2021-February/442317.html
---
arch/arm/mach-bcm283x/init.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-bcm283x/init.c b/arch/arm/mach-bcm283x/init.c
index 49027ce0a2..9803499985 100644
--- a/arch/arm/mach-bcm283x/init.c
+++ b/arch/arm/mach-bcm283x/init.c
@@ -14,7 +14,7 @@
#include
#define BCM2711_RPI4_PCIE_XHCI_MMIO_PHYS 0x6UL
-#define BCM2711_RPI4_PCIE_XHCI_MMIO_SIZE 0x80UL
+#define BCM2711_RPI4_PCIE_XHCI_MMIO_SIZE 0x40UL
#ifdef CONFIG_ARM64
#include
@@ -148,7 +148,7 @@ int mach_cpu_init(void)
#ifdef CONFIG_ARMV7_LPAE
#ifdef CONFIG_TARGET_RPI_4_32B
-#define BCM2711_RPI4_PCIE_XHCI_MMIO_VIRT 0xff80UL
+#define BCM2711_RPI4_PCIE_XHCI_MMIO_VIRT 0xffc0UL
#include
#include
--
2.17.1
Re: u-boot on RPi4 32bit - issue after upgrading the firmware
Hi
On 04.03.2021 02:33, Jaehoon Chung wrote:
> On 2/25/21 8:11 PM, Marek Szyprowski wrote:
>> On 25.02.2021 11:55, Nicolas Saenz Julienne wrote:
>>> On Thu, 2021-02-25 at 11:43 +0100, Marek Szyprowski wrote:
>>>> Recently I've upgraded a video core firmware on my RPi4 and I've noticed
>>>> that u-boot in ARM 32bit mode stopped working properly or even randomly
>>>> crashes. I've bisected the firmware releases and the issue appears for
>>>> the first time in the commit 63b1922311 ("firmware: arm_loader: Update
>>>> armstubs with those from PR 117 See:
>>>> https://protect2.fireeye.com/v1/url?k=a201e8b0-fd9ad069-a20063ff-0cc47a3356b2-1ab72bd783ec5635&q=1&e=5f377675-c909-4cc4-a1d5-b740cbf6255e&u=https%3A%2F%2Fgithub.com%2Fraspberrypi%2Ftools%2Fpull%2F117";).
>>> Just for confirmation,
>>>> This issue can be easily observed as a failure of the xhci. See the
>>>> attached log:
>>>>
>>>> Read start4x.elf bytes 2984808 hnd 0x06e2 sha256 d21bf9d3954fea04
>>>> Read fixup4x.dat bytes 8432 hnd 0x06dd sha256 10d3b073ab232613
>>>> 0x00a03111 0x 0x001f
>>>> MEM GPU: 76 ARM: 948 TOTAL: 1024
>>>> Starting start4x.elf @ 0xfec00200 partition 0
>>>> PCI reset
>>>> +
>>>>
>>>> MESS:00:00:04.800023:0: arasan: arasan_emmc_open
>>>> MESS:00:00:04.975752:0: brfs: File read: /mfs/sd/config.txt
>>>> MESS:00:00:04.979162:0: brfs: File read: 2153 bytes
>>>> MESS:00:00:05.046081:0: brfs: File read: /mfs/sd/config.txt
>>>> MESS:00:00:06.121174:0: gpioman: gpioman_get_pin_num: pin
>>>> DISPLAY_DSI_PORT not defined
>>>> MESS:00:00:06.128433:0: *** Restart logging
>>>> MESS:00:00:06.129897:0: brfs: File read: 2153 bytes
>>>> MESS:00:00:06.148533:0: hdmi: HDMI:hdmi_get_state is deprecated, use
>>>> hdmi_get_display_state instead
>>>> MESS:00:00:06.154474:0: HDMI0: hdmi_pixel_encoding: 3
>>>> MESS:00:00:06.159948:0: HDMI1: hdmi_pixel_encoding: 3
>>>> MESS:00:00:06.166901:0: dtb_file 'bcm2711-rpi-4-b.dtb'
>>>> MESS:00:00:06.178359:0: brfs: File read: /mfs/sd/bcm2711-rpi-4-b.dtb
>>>> MESS:00:00:06.181601:0: Loading 'bcm2711-rpi-4-b.dtb' to 0x100 size 0xc901
>>>> MESS:00:00:06.201386:0: brfs: File read: 51457 bytes
>>>> MESS:00:00:06.267975:0: brfs: File read: /mfs/sd/config.txt
>>>> MESS:00:00:06.270915:0: dtparam: audio=on
>>>> MESS:00:00:06.283974:0: brfs: File read: 2153 bytes
>>>> MESS:00:00:06.286148:0: Failed to load overlay 'vc4-fkms-v3d'
>>>> MESS:00:00:06.291378:0: brfs: File read: /mfs/sd/overlays/vc4-fkms-v3d.dtbo
>>>> MESS:00:00:06.304096:0: Failed to open command line file 'cmdline.txt'
>>>> MESS:00:00:07.484256:0: brfs: File read: /mfs/sd/u-boot.bin
>>>> MESS:00:00:07.486726:0: Loading 'u-boot.bin' to 0x8000 size 0x84cf4
>>>> MESS:00:00:07.492726:0: Device tree loaded to 0x2eff3100 (size 0xce24)
>>>> MESS:00:00:07.500863:0: uart: Set PL011 baud rate to 103448.30 Hz
>>>> MESS:00:00:07.508031:0: uart: Baud rate change done...
>>>> MESS:00:00:07.510053:0:
>>>>
>>>> U-Boot 2021.04-rc2 (Feb 25 2021 - 11:21:44 +0100)
>>> Can you try with today's master branch, I'm specially interested in seeing
>>> if
>>> 56f1bcc4b7fb helps.
>> I've checked the mentioned commit, sadly nothing changes:
>>
>> U-Boot 2021.04-rc2-00041-g56f1bcc4b7 (Feb 25 2021 - 12:05:07 +0100)
>>
>> DRAM: 948 MiB
>> RPI 4 Model B (0xa03111)
>> MMC: mmcnr@7e30: 1, emmc2@7e34: 0
>> Loading Environment from FAT... OK
>> In: serial
>> Out: serial
>> Err: serial
>> Net: eth0: ethernet@7d58
>> Hit any key to stop autoboot: 0
>> U-Boot> pci enum
>> PCIe BRCM: link up, 5.0 Gbps x1 (SSC)
>> U-Boot> usb start
>> starting USB...
>> Bus xhci_pci: Host not halted after 16000 microseconds.
>> probe failed, error -16
>> No working controllers found
>> U-Boot>
>>
>> I've checked that on two RPi4 boards (one with 1GB RAM and one with 8GB).
> It seems that couldn't get hc_length from capbase.
>
> us xhci_pci: XHCI-PCI init hccr ff80 and hcor ff80 hc_length 0
> xhci_register: dev='xhci_pci', ctrl=3a3679c0, hccr=ff80, hcor=ff80
>
> When i have compared with working and not, hc_length is different.
> hc_length should be to set 0x20 when it's working fine.
>
> I don't have the knowledge of USB..So it's taking too more time for debugging.
>
> Could you share what i do to check more?
I've finally had some time to analyze it more. It looks that 0xff80
base address in ARM 32bit virtual address space chosen for XHCI PCI
device conflicts with the updated ARM/VideoCore firmware. I have no idea
why, but switching to 0xffc0 fixed the issue.
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
[PATCH] cmd: misc: Fix return value for the sleep command
If sleeping has been interrupted, return CMD_RET_FAILURE instead of -1
(CMD_RET_USAGE).
Signed-off-by: Marek Szyprowski
---
cmd/sleep.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/cmd/sleep.c b/cmd/sleep.c
index f0c78a8efb..1fff400c79 100644
--- a/cmd/sleep.c
+++ b/cmd/sleep.c
@@ -40,7 +40,7 @@ static int do_sleep(struct cmd_tbl *cmdtp, int flag, int argc,
while (get_timer(start) < delay) {
if (ctrlc())
- return (-1);
+ return CMD_RET_FAILURE;
udelay(100);
}
--
2.17.1
Re: [PATCH v4 0/3] VIM3: add support for checking 'Function' button state
Hi Neil, On 18.01.2021 13:55, Neil Armstrong wrote: > On 18/01/2021 13:48, Heinrich Schuchardt wrote: >> On 18.01.21 11:24, Neil Armstrong wrote: >>> On 22/12/2020 09:56, Marek Szyprowski wrote: >>>> Hi All, >>>> >>>> This patchset adds all building blocks needed for checking the 'Function' >>>> button state in the boot script on Amlogic A311D based VIM3 board. This >>>> button is connected to the ADC lines of the SoC, so it required to enable >>>> meson SARADC, the clocks needed for it and a simple button-adc drivers. >>>> >>>> Once applied, one can use following commands in the boot scripts: >>>> -->8--- >>>> echo Checking Func button state: \\c >>>> if button Function >>>> then >>>>echo Selected alternative boot >>>>... >>>> fi >>>> --->8--- >>>> >>>> Best regards >>>> Marek Szyprowski >>>> Samsung R&D Institute Poland >>>> >>>> >>>> Changelog: >>>> v4: >>>> - rebased onto uboot-amlogic/u-boot-amlogic-next and dropped merged patches >>>> - added adc-keys bindings docs (copied from Linux kernel) >>>> - minor code adjustments pointed by Simon >>>> - enabled driver also in khadas-vim3l_defconfig >>>> >>>> v3: >>>> https://protect2.fireeye.com/v1/url?k=fc4a4b97-a3d1734e-fc4bc0d8-0cc47a3356b2-eb4ba315795a3f17&q=1&e=b660ed0e-7d37-47e8-877d-c8391317e3e0&u=https%3A%2F%2Flists.denx.de%2Fpipermail%2Fu-boot%2F2020-December%2F435072.html >>>> - removed 'button' env variable >>>> - extended kconfig and patch descriptions >>>> >>>> v2: >>>> https://protect2.fireeye.com/v1/url?k=11f0ed69-4e6bd5b0-11f16626-0cc47a3356b2-f341d16b01448534&q=1&e=b660ed0e-7d37-47e8-877d-c8391317e3e0&u=https%3A%2F%2Flists.denx.de%2Fpipermail%2Fu-boot%2F2020-December%2F434991.html >>>> - removed Change-Id tags >>>> - split defconfig changes into ADC and button related >>>> >>>> v1: >>>> https://protect2.fireeye.com/v1/url?k=7c601119-23fb29c0-7c619a56-0cc47a3356b2-55caa8afe3085a65&q=1&e=b660ed0e-7d37-47e8-877d-c8391317e3e0&u=https%3A%2F%2Flists.denx.de%2Fpipermail%2Fu-boot%2F2020-December%2F434875.html >>>> - initial submission >>> What's the state of the patchset ? >> Hello Neil, >> >> the series is assigned to you. Patch 2 is incorrect. Patch 1 can be >> updated to match Linux. So I suggest to set the status for the series to >> "changes requested". > Sure, it was more a question to Marek, but yeah I'll tag them "changes > requested" I'm sorry for the late reply, I've been busy with other stuff. I will try to update the adc-keys driver to use the threshold values and add the updated device tree bindings soon. Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland
[PATCH v5 0/4] VIM3: add support for checking 'Function' button state
Hi All, This patchset adds all building blocks needed for checking the 'Function' button state in the boot script on Amlogic A311D based VIM3 board. This button is connected to the ADC lines of the SoC, so it required to enable meson SARADC, the clocks needed for it and a simple button-adc drivers. Once applied, one can use following commands in the boot scripts: -->8--- echo Checking Func button state: \\c if button Function then echo Selected alternative boot ... fi --->8--- Best regards Marek Szyprowski Samsung R&D Institute Poland Changelog: v5: - rebased onto latest uboot-amlogic/u-boot-amlogic-next branch - synchronized adc-keys binding with the recent version from the Linux kernel - updated adc-keys driver to match behavior from dt-bindings - added a patch for meson-saradc driver to register vdd reference supply to the ADC framework v4: https://lists.denx.de/pipermail/u-boot/2020-December/435641.html - rebased onto uboot-amlogic/u-boot-amlogic-next and dropped merged patches - added adc-keys bindings docs (copied from Linux kernel) - minor code adjustments pointed by Simon - enabled driver also in khadas-vim3l_defconfig v3: https://lists.denx.de/pipermail/u-boot/2020-December/435072.html - removed 'button' env variable - extended kconfig and patch descriptions v2: https://lists.denx.de/pipermail/u-boot/2020-December/434991.html - removed Change-Id tags - split defconfig changes into ADC and button related v1: https://lists.denx.de/pipermail/u-boot/2020-December/434875.html - initial submission Patch summary: Marek Szyprowski (4): dt-bindings: input: adc-keys bindings documentation button: add a simple Analog to Digital Converter device based button driver adc: meson-saradc: add support for getting reference voltage value configs: khadas-vim3(l): enable Function button support configs/khadas-vim3_defconfig | 2 + configs/khadas-vim3l_defconfig | 2 + doc/device-tree-bindings/input/adc-keys.txt | 67 + drivers/adc/meson-saradc.c | 21 +++ drivers/button/Kconfig | 8 + drivers/button/Makefile | 1 + drivers/button/button-adc.c | 156 7 files changed, 257 insertions(+) create mode 100644 doc/device-tree-bindings/input/adc-keys.txt create mode 100644 drivers/button/button-adc.c -- 2.17.1
[PATCH v5 1/4] dt-bindings: input: adc-keys bindings documentation
Dump adc-keys bindings documentation from Linux kernel source tree from
commit 698dc0cf9447 ("dt-bindings: input: adc-keys: clarify
description").
Signed-off-by: Marek Szyprowski
---
doc/device-tree-bindings/input/adc-keys.txt | 67 +
1 file changed, 67 insertions(+)
create mode 100644 doc/device-tree-bindings/input/adc-keys.txt
diff --git a/doc/device-tree-bindings/input/adc-keys.txt
b/doc/device-tree-bindings/input/adc-keys.txt
new file mode 100644
index 00..6c8be6a9ac
--- /dev/null
+++ b/doc/device-tree-bindings/input/adc-keys.txt
@@ -0,0 +1,67 @@
+ADC attached resistor ladder buttons
+
+
+Required properties:
+ - compatible: "adc-keys"
+ - io-channels: Phandle to an ADC channel
+ - io-channel-names = "buttons";
+ - keyup-threshold-microvolt: Voltage above or equal to which all the keys are
+ considered up.
+
+Optional properties:
+ - poll-interval: Poll interval time in milliseconds
+ - autorepeat: Boolean, Enable auto repeat feature of Linux input
+ subsystem.
+
+Each button (key) is represented as a sub-node of "adc-keys":
+
+Required subnode-properties:
+ - label: Descriptive name of the key.
+ - linux,code: Keycode to emit.
+ - press-threshold-microvolt: voltage above or equal to which this key is
+considered pressed.
+
+No two values of press-threshold-microvolt may be the same.
+All values of press-threshold-microvolt must be less than
+keyup-threshold-microvolt.
+
+Example:
+
+#include
+
+ adc-keys {
+ compatible = "adc-keys";
+ io-channels = <&lradc 0>;
+ io-channel-names = "buttons";
+ keyup-threshold-microvolt = <200>;
+
+ button-up {
+ label = "Volume Up";
+ linux,code = ;
+ press-threshold-microvolt = <150>;
+ };
+
+ button-down {
+ label = "Volume Down";
+ linux,code = ;
+ press-threshold-microvolt = <100>;
+ };
+
+ button-enter {
+ label = "Enter";
+ linux,code = ;
+ press-threshold-microvolt = <50>;
+ };
+ };
+
++++
+| 2.000.000 <= value | no key pressed |
++++
+| 1.500.000 <= value < 2.000.000 | KEY_VOLUMEUP pressed |
++++
+| 1.000.000 <= value < 1.500.000 | KEY_VOLUMEDOWN pressed |
++++
+| 500.000 <= value < 1.000.000 | KEY_ENTER pressed |
++++
+| value < 500.000 | no key pressed |
++++
--
2.17.1
[PATCH v5 4/4] configs: khadas-vim3(l): enable Function button support
Add options required to check the 'Function' button state. Signed-off-by: Marek Szyprowski --- configs/khadas-vim3_defconfig | 2 ++ configs/khadas-vim3l_defconfig | 2 ++ 2 files changed, 4 insertions(+) diff --git a/configs/khadas-vim3_defconfig b/configs/khadas-vim3_defconfig index 5d16652fd6..bc17430569 100644 --- a/configs/khadas-vim3_defconfig +++ b/configs/khadas-vim3_defconfig @@ -31,6 +31,8 @@ CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_NET_RANDOM_ETHADDR=y CONFIG_ADC=y CONFIG_SARADC_MESON=y +CONFIG_BUTTON=y +CONFIG_BUTTON_ADC=y CONFIG_DM_I2C=y CONFIG_SYS_I2C_MESON=y CONFIG_DM_MMC=y diff --git a/configs/khadas-vim3l_defconfig b/configs/khadas-vim3l_defconfig index 6b13ce045c..c1877922c7 100644 --- a/configs/khadas-vim3l_defconfig +++ b/configs/khadas-vim3l_defconfig @@ -31,6 +31,8 @@ CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_NET_RANDOM_ETHADDR=y CONFIG_ADC=y CONFIG_SARADC_MESON=y +CONFIG_BUTTON=y +CONFIG_BUTTON_ADC=y CONFIG_DM_I2C=y CONFIG_SYS_I2C_MESON=y CONFIG_DM_MMC=y -- 2.17.1
[PATCH v5 3/4] adc: meson-saradc: add support for getting reference voltage value
Add support for getting the 'vref-supply' regulator and register it as
ADC's reference voltage regulator, so clients can translate sampled ADC
values to the voltage.
Signed-off-by: Marek Szyprowski
---
drivers/adc/meson-saradc.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/drivers/adc/meson-saradc.c b/drivers/adc/meson-saradc.c
index 21db55831d..1a45a3a265 100644
--- a/drivers/adc/meson-saradc.c
+++ b/drivers/adc/meson-saradc.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#define MESON_SAR_ADC_REG0 0x00
#define MESON_SAR_ADC_REG0_PANEL_DETECT BIT(31)
@@ -656,7 +657,10 @@ static int meson_saradc_stop(struct udevice *dev)
static int meson_saradc_probe(struct udevice *dev)
{
+ struct adc_uclass_plat *uc_pdata = dev_get_uclass_plat(dev);
struct meson_saradc_priv *priv = dev_get_priv(dev);
+ struct udevice *vref;
+ int vref_uv;
int ret;
ret = regmap_init_mem(dev_ofnode(dev), &priv->regmap);
@@ -675,6 +679,23 @@ static int meson_saradc_probe(struct udevice *dev)
priv->active_channel = -1;
+ ret = device_get_supply_regulator(dev, "vref-supply", &vref);
+ if (ret) {
+ printf("can't get vref-supply: %d\n", ret);
+ return ret;
+ }
+
+ vref_uv = regulator_get_value(vref);
+ if (vref_uv < 0) {
+ printf("can't get vref-supply value: %d\n", vref_uv);
+ return vref_uv;
+ }
+
+ /* VDD supplied by common vref pin */
+ uc_pdata->vdd_supply = vref;
+ uc_pdata->vdd_microvolts = vref_uv;
+ uc_pdata->vss_microvolts = 0;
+
return 0;
}
--
2.17.1
[PATCH v5 2/4] button: add a simple Analog to Digital Converter device based button driver
Add a simple Analog to Digital Converter device based button driver. This
driver binds to the 'adc-keys' device tree node.
Signed-off-by: Marek Szyprowski
---
drivers/button/Kconfig | 8 ++
drivers/button/Makefile | 1 +
drivers/button/button-adc.c | 156
3 files changed, 165 insertions(+)
create mode 100644 drivers/button/button-adc.c
diff --git a/drivers/button/Kconfig b/drivers/button/Kconfig
index 6b3ec7e55d..6db3c5e93a 100644
--- a/drivers/button/Kconfig
+++ b/drivers/button/Kconfig
@@ -9,6 +9,14 @@ config BUTTON
can provide access to board-specific buttons. Use of the device tree
for configuration is encouraged.
+config BUTTON_ADC
+ bool "Button adc"
+ depends on BUTTON
+ help
+ Enable support for buttons which are connected to Analog to Digital
+ Converter device. The ADC driver must use driver model. Buttons are
+ configured using the device tree.
+
config BUTTON_GPIO
bool "Button gpio"
depends on BUTTON
diff --git a/drivers/button/Makefile b/drivers/button/Makefile
index fcc10ebe8d..bbd18af149 100644
--- a/drivers/button/Makefile
+++ b/drivers/button/Makefile
@@ -3,4 +3,5 @@
# Copyright (C) 2020 Philippe Reynes
obj-$(CONFIG_BUTTON) += button-uclass.o
+obj-$(CONFIG_BUTTON_ADC) += button-adc.o
obj-$(CONFIG_BUTTON_GPIO) += button-gpio.o
diff --git a/drivers/button/button-adc.c b/drivers/button/button-adc.c
new file mode 100644
index 00..1901d59a0e
--- /dev/null
+++ b/drivers/button/button-adc.c
@@ -0,0 +1,156 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2021 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ * Author: Marek Szyprowski
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/**
+ * struct button_adc_priv - private data for button-adc driver.
+ *
+ * @adc: Analog to Digital Converter device to which button is connected.
+ * @channel: channel of the ADC device to probe the button state.
+ * @min: minimal raw ADC sample value to consider button as pressed.
+ * @max: maximal raw ADC sample value to consider button as pressed.
+ */
+struct button_adc_priv {
+ struct udevice *adc;
+ int channel;
+ int min;
+ int max;
+};
+
+static enum button_state_t button_adc_get_state(struct udevice *dev)
+{
+ struct button_adc_priv *priv = dev_get_priv(dev);
+ unsigned int val;
+ int ret;
+
+ ret = adc_start_channel(priv->adc, priv->channel);
+ if (ret)
+ return ret;
+
+ ret = adc_channel_data(priv->adc, priv->channel, &val);
+ if (ret)
+ return ret;
+
+ if (ret == 0)
+ return (val >= priv->min && val < priv->max) ?
+ BUTTON_ON : BUTTON_OFF;
+
+ return ret;
+}
+
+static int button_adc_probe(struct udevice *dev)
+{
+ struct button_uc_plat *uc_plat = dev_get_uclass_plat(dev);
+ struct button_adc_priv *priv = dev_get_priv(dev);
+ struct ofnode_phandle_args args;
+ u32 treshold, up_treshold, t;
+ unsigned int mask;
+ ofnode node;
+ int ret, vdd;
+
+ /* Ignore the top-level button node */
+ if (!uc_plat->label)
+ return 0;
+
+ ret = dev_read_phandle_with_args(dev->parent, "io-channels",
+"#io-channel-cells", 0, 0, &args);
+ if (ret)
+ return ret;
+
+ ret = uclass_get_device_by_ofnode(UCLASS_ADC, args.node, &priv->adc);
+ if (ret)
+ return ret;
+
+ ret = ofnode_read_u32(dev_ofnode(dev->parent),
+ "keyup-threshold-microvolt", &up_treshold);
+ if (ret)
+ return ret;
+
+ ret = ofnode_read_u32(dev_ofnode(dev), "press-threshold-microvolt",
+ &treshold);
+ if (ret)
+ return ret;
+
+ dev_for_each_subnode(node, dev->parent) {
+ ret = ofnode_read_u32(dev_ofnode(dev),
+ "press-threshold-microvolt", &t);
+ if (ret)
+ return ret;
+
+ if (t > treshold)
+ up_treshold = t;
+ }
+
+ ret = adc_vdd_value(priv->adc, &vdd);
+ if (ret)
+ return ret;
+
+ ret = adc_data_mask(priv->adc, &mask);
+ if (ret)
+ return ret;
+
+ priv->channel = args.args[0];
+ priv->min = mask * (treshold / 1000) / (vdd / 1000);
+ priv->max = mask * (up_treshold / 1000) / (vdd / 1000);
+
+ return ret;
+}
+
+static int button_adc_bind(struct udevice *parent)
+{
+ struct udevice *dev;
+ ofnode node;
+ int ret;
+
+
Re: [PATCH v5 2/4] button: add a simple Analog to Digital Converter device based button driver
Hi Heinrich,
On 26.01.2021 12:10, Heinrich Schuchardt wrote:
> On 1/26/21 10:50 AM, Marek Szyprowski wrote:
>> Add a simple Analog to Digital Converter device based button driver.
>> This
>> driver binds to the 'adc-keys' device tree node.
>>
>> Signed-off-by: Marek Szyprowski
>> ---
>> drivers/button/Kconfig | 8 ++
>> drivers/button/Makefile | 1 +
>> drivers/button/button-adc.c | 156
>> 3 files changed, 165 insertions(+)
>> create mode 100644 drivers/button/button-adc.c
>>
>> diff --git a/drivers/button/Kconfig b/drivers/button/Kconfig
>> index 6b3ec7e55d..6db3c5e93a 100644
>> --- a/drivers/button/Kconfig
>> +++ b/drivers/button/Kconfig
>> @@ -9,6 +9,14 @@ config BUTTON
>> can provide access to board-specific buttons. Use of the
>> device tree
>> for configuration is encouraged.
>>
>> +config BUTTON_ADC
>> + bool "Button adc"
>> + depends on BUTTON
>> + help
>> + Enable support for buttons which are connected to Analog to
>> Digital
>> + Converter device. The ADC driver must use driver model.
>> Buttons are
>> + configured using the device tree.
>> +
>> config BUTTON_GPIO
>> bool "Button gpio"
>> depends on BUTTON
>> diff --git a/drivers/button/Makefile b/drivers/button/Makefile
>> index fcc10ebe8d..bbd18af149 100644
>> --- a/drivers/button/Makefile
>> +++ b/drivers/button/Makefile
>> @@ -3,4 +3,5 @@
>> # Copyright (C) 2020 Philippe Reynes
>>
>> obj-$(CONFIG_BUTTON) += button-uclass.o
>> +obj-$(CONFIG_BUTTON_ADC) += button-adc.o
>> obj-$(CONFIG_BUTTON_GPIO) += button-gpio.o
>> diff --git a/drivers/button/button-adc.c b/drivers/button/button-adc.c
>> new file mode 100644
>> index 00..1901d59a0e
>> --- /dev/null
>> +++ b/drivers/button/button-adc.c
>> @@ -0,0 +1,156 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * Copyright (C) 2021 Samsung Electronics Co., Ltd.
>> + * http://www.samsung.com
>> + * Author: Marek Szyprowski
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +/**
>> + * struct button_adc_priv - private data for button-adc driver.
>> + *
>> + * @adc: Analog to Digital Converter device to which button is
>> connected.
>> + * @channel: channel of the ADC device to probe the button state.
>> + * @min: minimal raw ADC sample value to consider button as pressed.
>> + * @max: maximal raw ADC sample value to consider button as pressed.
>> + */
>> +struct button_adc_priv {
>> + struct udevice *adc;
>> + int channel;
>> + int min;
>> + int max;
>> +};
>> +
>> +static enum button_state_t button_adc_get_state(struct udevice *dev)
>> +{
>> + struct button_adc_priv *priv = dev_get_priv(dev);
>> + unsigned int val;
>> + int ret;
>> +
>> + ret = adc_start_channel(priv->adc, priv->channel);
>> + if (ret)
>> + return ret;
>> +
>> + ret = adc_channel_data(priv->adc, priv->channel, &val);
>> + if (ret)
>> + return ret;
>> +
>> + if (ret == 0)
>> + return (val >= priv->min && val < priv->max) ?
>> + BUTTON_ON : BUTTON_OFF;
>> +
>> + return ret;
>> +}
>> +
>> +static int button_adc_probe(struct udevice *dev)
>> +{
>> + struct button_uc_plat *uc_plat = dev_get_uclass_plat(dev);
>> + struct button_adc_priv *priv = dev_get_priv(dev);
>> + struct ofnode_phandle_args args;
>> + u32 treshold, up_treshold, t;
>> + unsigned int mask;
>> + ofnode node;
>> + int ret, vdd;
>> +
>> + /* Ignore the top-level button node */
>> + if (!uc_plat->label)
>> + return 0;
>> +
>> + ret = dev_read_phandle_with_args(dev->parent, "io-channels",
>> + "#io-channel-cells", 0, 0, &args);
>> + if (ret)
>> + return ret;
>> +
>> + ret = uclass_get_device_by_ofnode(UCLASS_ADC, args.node,
>> &priv->adc);
>> + if (ret)
>> + return ret;
>> +
>> + ret = ofnode_read_u32(dev_ofnode(dev->parent),
>> + "keyup-threshold-microvolt", &up_treshold);
>> + if (ret)
&g
Re: [PATCH v2] disk: part_dos: update partition table entries after write
Hi, On 28.01.2021 09:10, Gary Bisson wrote: > Fixes issues when switching from GPT to MBR partition tables. > > Signed-off-by: Gary Bisson Acked-by: Marek Szyprowski > --- > Changes for v2: > - added part_init() inside write_mbr_partitions(), as suggested by >Heinrich > --- > disk/part_dos.c | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/disk/part_dos.c b/disk/part_dos.c > index f431925745c..60addc6e00d 100644 > --- a/disk/part_dos.c > +++ b/disk/part_dos.c > @@ -423,6 +423,9 @@ int write_mbr_partitions(struct blk_desc *dev, > ext_part_sect = next_ebr; > } > > + /* Update the partition table entries*/ > + part_init(dev_desc); > + > return 0; > } > > @@ -499,6 +502,9 @@ int write_mbr_sector(struct blk_desc *dev_desc, void *buf) > return 1; > } > > + /* Update the partition table entries*/ > + part_init(dev_desc); > + > return 0; > } > Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland
[PATCH] rpi: limit size of the RAM to the multiple of the MMU_SECTION_SIZE
When RPi4 is booted from USB Mass Storage, the firmware reports 947MiB of the ARM memory (948 in case of the standard SD-card boot). This value is not MMU_SECTION_SIZE aligned, so the dram_bank_mmu_setup() skips mapping of the last 1MiB. This later causes u-boot in ARM 32bit mode to freeze, because it relocated itself into that unmapped memory and fails to execute. Fix this by limiting the size of the first bank to the multiple of MMU_SECTION_SIZE. Signed-off-by: Marek Szyprowski --- board/raspberrypi/rpi/rpi.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c index 6b1fa5fc14..83ccd3e3fc 100644 --- a/board/raspberrypi/rpi/rpi.c +++ b/board/raspberrypi/rpi/rpi.c @@ -268,6 +268,13 @@ int dram_init(void) gd->ram_size = msg->get_arm_mem.body.resp.mem_size; + /* +* In some configurations the memory size returned by VideoCore +* is not aligned to the section size, what is mandatory for +* the u-boot's memory setup. +*/ + gd->ram_size &= ~MMU_SECTION_SIZE; + return 0; } -- 2.17.1
[PATCH] board: amlogic: odroid: add runtime detection of the N2/N2+/C4/HC4 variants
Use the ADC channel 1 to check the hardware revision of the board and
detect the N2 vs. N2+ and the C4 vs. HC4 variants. Each of them use
different dtb file, so adjust fdtfile environment variable to the
detected variant.
The ADC min/max values for each variant are taken from the vendor code,
adjusted to the 12-bit ADC driver operation mode (vendor code use 10-bit
mode).
Signed-off-by: Marek Szyprowski
---
The relevant vendor's code is here:
https://github.com/hardkernel/u-boot/blob/odroidg12-v2015.01/board/hardkernel/odroid-common/board.c#L55
---
arch/arm/dts/meson-g12b-odroid-n2-u-boot.dtsi | 6 ++
arch/arm/dts/meson-sm1-odroid-c4-u-boot.dtsi | 6 ++
board/amlogic/odroid-n2/odroid-n2.c | 80 +++
configs/odroid-c4_defconfig | 4 +-
configs/odroid-n2_defconfig | 4 +-
5 files changed, 98 insertions(+), 2 deletions(-)
diff --git a/arch/arm/dts/meson-g12b-odroid-n2-u-boot.dtsi
b/arch/arm/dts/meson-g12b-odroid-n2-u-boot.dtsi
index 236f2468dc..a92f9e9ff1 100644
--- a/arch/arm/dts/meson-g12b-odroid-n2-u-boot.dtsi
+++ b/arch/arm/dts/meson-g12b-odroid-n2-u-boot.dtsi
@@ -5,3 +5,9 @@
*/
#include "meson-g12-common-u-boot.dtsi"
+
+/* SARADC is needed for proper board variant detection */
+&saradc {
+ status = "okay";
+ vref-supply = <&vddao_1v8>;
+};
diff --git a/arch/arm/dts/meson-sm1-odroid-c4-u-boot.dtsi
b/arch/arm/dts/meson-sm1-odroid-c4-u-boot.dtsi
index fbcc8287c5..963bf96b25 100644
--- a/arch/arm/dts/meson-sm1-odroid-c4-u-boot.dtsi
+++ b/arch/arm/dts/meson-sm1-odroid-c4-u-boot.dtsi
@@ -12,6 +12,12 @@
snps,reset-active-low;
};
+/* SARADC is needed for proper board variant detection */
+&saradc {
+ status = "okay";
+ vref-supply = <&vddao_1v8>;
+};
+
&tflash_vdd {
gpio = <&gpio_ao GPIOAO_3 GPIO_OPEN_DRAIN>;
};
diff --git a/board/amlogic/odroid-n2/odroid-n2.c
b/board/amlogic/odroid-n2/odroid-n2.c
index d9955433bf..2eb7fa93be 100644
--- a/board/amlogic/odroid-n2/odroid-n2.c
+++ b/board/amlogic/odroid-n2/odroid-n2.c
@@ -6,6 +6,7 @@
#include
#include
+#include
#include
#include
#include
@@ -19,6 +20,11 @@
#define EFUSE_MAC_SIZE 12
#define MAC_ADDR_LEN 6
+#define ODROID_HW_VS_ADC_CHANNEL 1
+
+#define MESON_SOC_ID_G12B 0x29
+#define MESON_SOC_ID_SM1 0x2b
+
int mmc_get_env_dev(void)
{
if (meson_get_boot_device() == BOOT_DEVICE_EMMC)
@@ -26,6 +32,79 @@ int mmc_get_env_dev(void)
return 0;
}
+/* Variant detection is based on the ADC RAW values for the channel #1 */
+static struct meson_odroid_boards {
+ unsigned int soc_id;
+ unsigned int adc_min;
+ unsigned int adc_max;
+ char *variant;
+} boards[] = {
+ /* OdroidN2 rev 2018,7,23 */
+ { MESON_SOC_ID_G12B, 80 * 4, 90 * 4, "n2" },
+ /* OdroidN2 rev 2018,12,6 */
+ { MESON_SOC_ID_G12B, 160 * 4, 170 * 4, "n2" },
+ /* OdroidN2 rev 2019,1,17 */
+ { MESON_SOC_ID_G12B, 245 * 4, 255 * 4, "n2" },
+ /* OdroidN2 rev 2019,2,7 */
+ { MESON_SOC_ID_G12B, 330 * 4, 350 * 4, "n2" },
+ /* OdroidN2plus rev 2019,11,20 */
+ { MESON_SOC_ID_G12B, 410 * 4, 430 * 4, "n2_plus" },
+ /* OdroidC4 rev 2020,01,29 */
+ { MESON_SOC_ID_SM1, 80 * 4, 100 * 4, "c4" },
+ /* OdroidHC4 rev 2019,12,10 */
+ { MESON_SOC_ID_SM1, 300 * 4, 320 * 4, "hc4" },
+ /* OdroidC4 rev 2019,11,29 */
+ { MESON_SOC_ID_SM1, 335 * 4, 345 * 4, "c4" },
+ /* OdroidHC4 rev 2020,8,7 */
+ { MESON_SOC_ID_SM1, 590 * 4, 610 * 4, "hc4" },
+};
+
+static void odroid_set_fdtfile(char *soc, char *variant)
+{
+ char s[128];
+
+ snprintf(s, sizeof(s), "amlogic/meson-%s-odroid-%s.dtb", soc, variant);
+ env_set("fdtfile", s);
+}
+
+static int odroid_detect_variant(void)
+{
+ char *variant = "", *soc = "";
+ unsigned int adcval = 0;
+ int ret, i, soc_id = 0;
+
+ if (of_machine_is_compatible("amlogic,sm1")) {
+ soc_id = MESON_SOC_ID_SM1;
+ soc = "sm1";
+ } else if (of_machine_is_compatible("amlogic,g12b")) {
+ soc_id = MESON_SOC_ID_G12B;
+ soc = "g12b";
+ } else {
+ return -1;
+ }
+
+ ret = adc_channel_single_shot("adc@9000", ODROID_HW_VS_ADC_CHANNEL,
+ &adcval);
+ if (ret)
+ return ret;
+
+ for (i = 0 ; i < ARRAY_SIZE(boards) ; ++i) {
+ if (soc_id == boards[i].soc_id &&
+ adcval >= boards[i].adc_min &&
+ adcval < boards[i].adc_max) {
+ variant = boards[i].variant;
+
Re: [PATCH v5 2/4] button: add a simple Analog to Digital Converter device based button driver
Hi Simon,
On 01.02.2021 21:38, Simon Glass wrote:
> On Tue, 26 Jan 2021 at 06:03, Heinrich Schuchardt wrote:
>> On 26.01.21 12:25, Marek Szyprowski wrote:
>>> On 26.01.2021 12:10, Heinrich Schuchardt wrote:
>>>> On 1/26/21 10:50 AM, Marek Szyprowski wrote:
>>>>> Add a simple Analog to Digital Converter device based button driver.
>>>>> This
>>>>> driver binds to the 'adc-keys' device tree node.
>>>>>
>>>>> Signed-off-by: Marek Szyprowski
>>>>> ---
>>>>>drivers/button/Kconfig | 8 ++
>>>>>drivers/button/Makefile | 1 +
>>>>>drivers/button/button-adc.c | 156
>>>>>3 files changed, 165 insertions(+)
>>>>>create mode 100644 drivers/button/button-adc.c
>>>>>
>>>>> diff --git a/drivers/button/Kconfig b/drivers/button/Kconfig
>>>>> index 6b3ec7e55d..6db3c5e93a 100644
>>>>> --- a/drivers/button/Kconfig
>>>>> +++ b/drivers/button/Kconfig
>>>>> @@ -9,6 +9,14 @@ config BUTTON
>>>>> can provide access to board-specific buttons. Use of the
>>>>> device tree
>>>>> for configuration is encouraged.
>>>>>
>>>>> +config BUTTON_ADC
>>>>> +bool "Button adc"
>>>>> +depends on BUTTON
>>>>> +help
>>>>> + Enable support for buttons which are connected to Analog to
>>>>> Digital
>>>>> + Converter device. The ADC driver must use driver model.
>>>>> Buttons are
>>>>> + configured using the device tree.
>>>>> +
>>>>>config BUTTON_GPIO
>>>>>bool "Button gpio"
>>>>>depends on BUTTON
>>>>> diff --git a/drivers/button/Makefile b/drivers/button/Makefile
>>>>> index fcc10ebe8d..bbd18af149 100644
>>>>> --- a/drivers/button/Makefile
>>>>> +++ b/drivers/button/Makefile
>>>>> @@ -3,4 +3,5 @@
>>>>># Copyright (C) 2020 Philippe Reynes
>>>>>
>>>>>obj-$(CONFIG_BUTTON) += button-uclass.o
>>>>> +obj-$(CONFIG_BUTTON_ADC) += button-adc.o
>>>>>obj-$(CONFIG_BUTTON_GPIO) += button-gpio.o
>>>>> diff --git a/drivers/button/button-adc.c b/drivers/button/button-adc.c
>>>>> new file mode 100644
>>>>> index 00..1901d59a0e
>>>>> --- /dev/null
>>>>> +++ b/drivers/button/button-adc.c
>>>>> @@ -0,0 +1,156 @@
>>>>> +// SPDX-License-Identifier: GPL-2.0
>>>>> +/*
>>>>> + * Copyright (C) 2021 Samsung Electronics Co., Ltd.
>>>>> + *http://www.samsung.com
>>>>> + * Author: Marek Szyprowski
>>>>> + */
>>>>> +
>>>>> +#include
>>>>> +#include
>>>>> +#include
>>>>> +#include
>>>>> +#include
>>>>> +#include
>>>>> +#include
>>>>> +#include
>>>>> +
>>>>> +/**
>>>>> + * struct button_adc_priv - private data for button-adc driver.
>>>>> + *
>>>>> + * @adc: Analog to Digital Converter device to which button is
>>>>> connected.
>>>>> + * @channel: channel of the ADC device to probe the button state.
>>>>> + * @min: minimal raw ADC sample value to consider button as pressed.
>>>>> + * @max: maximal raw ADC sample value to consider button as pressed.
>>>>> + */
>>>>> +struct button_adc_priv {
>>>>> +struct udevice *adc;
>>>>> +int channel;
>>>>> +int min;
>>>>> +int max;
>>>>> +};
>>>>> +
>>>>> +static enum button_state_t button_adc_get_state(struct udevice *dev)
>>>>> +{
>>>>> +struct button_adc_priv *priv = dev_get_priv(dev);
>>>>> +unsigned int val;
>>>>> +int ret;
>>>>> +
>>>>> +ret = adc_start_channel(priv->adc, priv->channel);
>>>>> +if (ret)
>>>>> +return ret;
>>>>> +
>>>>> +ret = adc_channel_data(priv->adc, priv->channel, &val);
>>>>> +if (ret)
>>>>> +return ret;
>&
Re: [PATCH v5 2/4] button: add a simple Analog to Digital Converter device based button driver
Hi Simon,
On 06.02.2021 17:21, Simon Glass wrote:
> On Thu, 4 Feb 2021 at 03:36, Marek Szyprowski
> wrote:
>> ...
>> Could you give me a bit more hints or point where to start? I've tried
>> to build sandbox, but it fails for v2021.01 release (I've did make
>> sandbox_defconfig && make all). I assume I would need to add adc and
>> adc-keys devices to some sandbox dts and some code triggering and
>> checking the key values, but that's all I know now.
> Well you do need to be able to build sandbox or you will get
> nowhere...what error did you get? Once we understand what went wrong
> we can update the docs. Maybe it is missing a dependency.
$ gcc --version
gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ git checkout v2021.01
$ make sandbox_defconfig
#
# configuration written to .config
#
$ make
scripts/kconfig/conf --syncconfig Kconfig
CFG u-boot.cfg
GEN include/autoconf.mk
GEN include/autoconf.mk.dep
CFGCHK u-boot.cfg
UPD include/generated/timestamp_autogenerated.h
HOSTCC tools/mkenvimage.o
HOSTLD tools/mkenvimage
HOSTCC tools/fit_image.o
HOSTCC tools/image-host.o
HOSTCC tools/dumpimage.o
HOSTLD tools/dumpimage
HOSTCC tools/mkimage.o
HOSTLD tools/mkimage
HOSTLD tools/fit_info
HOSTLD tools/fit_check_sign
...
CC arch/sandbox/cpu/cpu.o
In file included from include/common.h:26:0,
from arch/sandbox/cpu/cpu.c:6:
include/asm/global_data.h:112:58: warning: call-clobbered register used
for global register variable
#define DECLARE_GLOBAL_DATA_PTR register volatile gd_t *gd asm ("r9")
^
include/dm/of.h:86:1: note: in expansion of macro ‘DECLARE_GLOBAL_DATA_PTR’
DECLARE_GLOBAL_DATA_PTR;
^~~
In file included from arch/sandbox/cpu/cpu.c:18:0:
./arch/sandbox/include/asm/state.h:98:30: error:
‘CONFIG_SANDBOX_SPI_MAX_BUS’ undeclared here (not in a function); did
you mean ‘CONFIG_SANDBOX_SPI’?
struct sandbox_spi_info spi[CONFIG_SANDBOX_SPI_MAX_BUS]
^~
CONFIG_SANDBOX_SPI
./arch/sandbox/include/asm/state.h:99:7: error:
‘CONFIG_SANDBOX_SPI_MAX_CS’ undeclared here (not in a function); did you
mean ‘CONFIG_SANDBOX_SPI_MAX_BUS’?
[CONFIG_SANDBOX_SPI_MAX_CS];
^
CONFIG_SANDBOX_SPI_MAX_BUS
arch/sandbox/cpu/cpu.c: In function ‘is_in_sandbox_mem’:
arch/sandbox/cpu/cpu.c:83:41: error: ‘volatile struct arch_global_data’
has no member named ‘ram_buf’
return (const uint8_t *)ptr >= gd->arch.ram_buf &&
^
arch/sandbox/cpu/cpu.c:84:34: error: ‘volatile struct arch_global_data’
has no member named ‘ram_buf’
(const uint8_t *)ptr < gd->arch.ram_buf + gd->ram_size;
^
arch/sandbox/cpu/cpu.c: At top level:
arch/sandbox/cpu/cpu.c:97:7: error: redefinition of ‘phys_to_virt’
void *phys_to_virt(phys_addr_t paddr)
^~~~
In file included from include/asm/io.h:495:0,
from arch/sandbox/cpu/cpu.c:15:
include/asm-generic/io.h:30:21: note: previous definition of
‘phys_to_virt’ was here
static inline void *phys_to_virt(phys_addr_t paddr)
^~~~
arch/sandbox/cpu/cpu.c: In function ‘phys_to_virt’:
arch/sandbox/cpu/cpu.c:104:27: error: ‘volatile struct arch_global_data’
has no member named ‘ram_buf’
return (void *)(gd->arch.ram_buf + paddr);
^
In file included from include/linux/posix_types.h:4:0,
from include/linux/types.h:4,
from include/time.h:7,
from include/common.h:18,
from arch/sandbox/cpu/cpu.c:6:
include/linux/stddef.h:17:33: warning: cast from pointer to integer of
different size [-Wpointer-to-int-cast]
#define offsetof(TYPE, MEMBER) ((size_t) &((TYPE *)0)->MEMBER)
^
include/linux/kernel.h:274:29: note: in expansion of macro ‘offsetof’
(type *)( (char *)__mptr - offsetof(type,member) );})
^~~~
include/linux/list.h:327:2: note: in expansion of macro ‘container_of’
container_of(ptr, type, member)
^~~~
include/linux/list.h:424:13: note: in expansion of macro ‘list_entry’
for (pos = list_entry((head)->next, typeof(*pos), member); \
^~
arch/sandbox/cpu/cpu.c:111:2: note: in expansion of macro
‘list_for_each_entry’
list_for_each_entry(mentry, &state->mapmem_head, sibling_node) {
^~~
include/linux/stddef.h:17:33: warning:
Re: [PATCH v5 2/4] button: add a simple Analog to Digital Converter device based button driver
Hi Simon,
On 08.02.2021 18:08, Simon Glass wrote:
> On Mon, 8 Feb 2021 at 09:10, Marek Szyprowski
> wrote:
>> On 06.02.2021 17:21, Simon Glass wrote:
>>> On Thu, 4 Feb 2021 at 03:36, Marek Szyprowski
>>> wrote:
>>>> ...
>>>> Could you give me a bit more hints or point where to start? I've tried
>>>> to build sandbox, but it fails for v2021.01 release (I've did make
>>>> sandbox_defconfig && make all). I assume I would need to add adc and
>>>> adc-keys devices to some sandbox dts and some code triggering and
>>>> checking the key values, but that's all I know now.
>>> Well you do need to be able to build sandbox or you will get
>>> nowhere...what error did you get? Once we understand what went wrong
>>> we can update the docs. Maybe it is missing a dependency.
>> $ gcc --version
>> gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0
>> Copyright (C) 2017 Free Software Foundation, Inc.
>> This is free software; see the source for copying conditions. There is NO
>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>>
>> $ git checkout v2021.01
>>
>> $ make sandbox_defconfig
>> #
>> # configuration written to .config
>> #
>>
>> $ make
>> scripts/kconfig/conf --syncconfig Kconfig
>> CFG u-boot.cfg
>> GEN include/autoconf.mk
>> GEN include/autoconf.mk.dep
>> CFGCHK u-boot.cfg
>> UPD include/generated/timestamp_autogenerated.h
>> HOSTCC tools/mkenvimage.o
>> HOSTLD tools/mkenvimage
>> HOSTCC tools/fit_image.o
>> HOSTCC tools/image-host.o
>> HOSTCC tools/dumpimage.o
>> HOSTLD tools/dumpimage
>> HOSTCC tools/mkimage.o
>> HOSTLD tools/mkimage
>> HOSTLD tools/fit_info
>> HOSTLD tools/fit_check_sign
>>
>> ...
>>
>> CC arch/sandbox/cpu/cpu.o
>> In file included from include/common.h:26:0,
>>from arch/sandbox/cpu/cpu.c:6:
>> include/asm/global_data.h:112:58: warning: call-clobbered register used
>> for global register variable
>>#define DECLARE_GLOBAL_DATA_PTR register volatile gd_t *gd asm ("r9")
>> ^
>> include/dm/of.h:86:1: note: in expansion of macro ‘DECLARE_GLOBAL_DATA_PTR’
>> DECLARE_GLOBAL_DATA_PTR;
> This is pretty mysterious. Are you sure you are using an x86_64 machine?
I've finally found what caused the issue on my build system. It is
x86_64 machine, but after some old cross-builds I had an 'asm' symlink
in u-boot/include directory pointing to arch/arm directory. I'm quite
surprised that it has not been removed by make clean/distclean/mrproper
combo.
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
[PATCH v6 3/5] adc: meson-saradc: add support for getting reference voltage value
Add support for getting the 'vref-supply' regulator and register it as
ADC's reference voltage regulator, so clients can translate sampled ADC
values to the voltage.
Signed-off-by: Marek Szyprowski
Reviewed-by: Simon Glass
---
drivers/adc/meson-saradc.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/drivers/adc/meson-saradc.c b/drivers/adc/meson-saradc.c
index 21db55831d..1a45a3a265 100644
--- a/drivers/adc/meson-saradc.c
+++ b/drivers/adc/meson-saradc.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#define MESON_SAR_ADC_REG0 0x00
#define MESON_SAR_ADC_REG0_PANEL_DETECT BIT(31)
@@ -656,7 +657,10 @@ static int meson_saradc_stop(struct udevice *dev)
static int meson_saradc_probe(struct udevice *dev)
{
+ struct adc_uclass_plat *uc_pdata = dev_get_uclass_plat(dev);
struct meson_saradc_priv *priv = dev_get_priv(dev);
+ struct udevice *vref;
+ int vref_uv;
int ret;
ret = regmap_init_mem(dev_ofnode(dev), &priv->regmap);
@@ -675,6 +679,23 @@ static int meson_saradc_probe(struct udevice *dev)
priv->active_channel = -1;
+ ret = device_get_supply_regulator(dev, "vref-supply", &vref);
+ if (ret) {
+ printf("can't get vref-supply: %d\n", ret);
+ return ret;
+ }
+
+ vref_uv = regulator_get_value(vref);
+ if (vref_uv < 0) {
+ printf("can't get vref-supply value: %d\n", vref_uv);
+ return vref_uv;
+ }
+
+ /* VDD supplied by common vref pin */
+ uc_pdata->vdd_supply = vref;
+ uc_pdata->vdd_microvolts = vref_uv;
+ uc_pdata->vss_microvolts = 0;
+
return 0;
}
--
2.17.1
[PATCH v6 1/5] dt-bindings: input: adc-keys bindings documentation
Dump adc-keys bindings documentation from Linux kernel source tree from
commit 698dc0cf9447 ("dt-bindings: input: adc-keys: clarify
description").
Signed-off-by: Marek Szyprowski
Reviewed-by: Simon Glass
---
doc/device-tree-bindings/input/adc-keys.txt | 67 +
1 file changed, 67 insertions(+)
create mode 100644 doc/device-tree-bindings/input/adc-keys.txt
diff --git a/doc/device-tree-bindings/input/adc-keys.txt
b/doc/device-tree-bindings/input/adc-keys.txt
new file mode 100644
index 00..6c8be6a9ac
--- /dev/null
+++ b/doc/device-tree-bindings/input/adc-keys.txt
@@ -0,0 +1,67 @@
+ADC attached resistor ladder buttons
+
+
+Required properties:
+ - compatible: "adc-keys"
+ - io-channels: Phandle to an ADC channel
+ - io-channel-names = "buttons";
+ - keyup-threshold-microvolt: Voltage above or equal to which all the keys are
+ considered up.
+
+Optional properties:
+ - poll-interval: Poll interval time in milliseconds
+ - autorepeat: Boolean, Enable auto repeat feature of Linux input
+ subsystem.
+
+Each button (key) is represented as a sub-node of "adc-keys":
+
+Required subnode-properties:
+ - label: Descriptive name of the key.
+ - linux,code: Keycode to emit.
+ - press-threshold-microvolt: voltage above or equal to which this key is
+considered pressed.
+
+No two values of press-threshold-microvolt may be the same.
+All values of press-threshold-microvolt must be less than
+keyup-threshold-microvolt.
+
+Example:
+
+#include
+
+ adc-keys {
+ compatible = "adc-keys";
+ io-channels = <&lradc 0>;
+ io-channel-names = "buttons";
+ keyup-threshold-microvolt = <200>;
+
+ button-up {
+ label = "Volume Up";
+ linux,code = ;
+ press-threshold-microvolt = <150>;
+ };
+
+ button-down {
+ label = "Volume Down";
+ linux,code = ;
+ press-threshold-microvolt = <100>;
+ };
+
+ button-enter {
+ label = "Enter";
+ linux,code = ;
+ press-threshold-microvolt = <50>;
+ };
+ };
+
++++
+| 2.000.000 <= value | no key pressed |
++++
+| 1.500.000 <= value < 2.000.000 | KEY_VOLUMEUP pressed |
++++
+| 1.000.000 <= value < 1.500.000 | KEY_VOLUMEDOWN pressed |
++++
+| 500.000 <= value < 1.000.000 | KEY_ENTER pressed |
++++
+| value < 500.000 | no key pressed |
++++
--
2.17.1
[PATCH v6 0/5] VIM3: add support for checking 'Function' button state
Hi All, This patchset adds all building blocks needed for checking the 'Function' button state in the boot script on Amlogic A311D based VIM3 board. This button is connected to the ADC line of the SoC, so it required to enable meson SARADC, the clocks needed for it and a simple button-adc drivers. Once applied, one can use following commands in the boot scripts: -->8--- echo Checking Func button state: \\c if button Function then echo Selected alternative boot ... fi --->8--- Best regards Marek Szyprowski Samsung R&D Institute Poland Changelog: v6: - added a simple sandbox test for adc-keys - use of_to_plat and adc_raw_to_uV to simplify code in the adc button driver v5: https://lists.denx.de/pipermail/u-boot/2021-January/438751.html - rebased onto latest uboot-amlogic/u-boot-amlogic-next branch - synchronized adc-keys binding with the recent version from the Linux kernel - updated adc-keys driver to match behavior from dt-bindings - added a patch for meson-saradc driver to register vdd reference supply to the ADC framework v4: https://lists.denx.de/pipermail/u-boot/2020-December/435641.html - rebased onto uboot-amlogic/u-boot-amlogic-next and dropped merged patches - added adc-keys bindings docs (copied from Linux kernel) - minor code adjustments pointed by Simon - enabled driver also in khadas-vim3l_defconfig v3: https://lists.denx.de/pipermail/u-boot/2020-December/435072.html - removed 'button' env variable - extended kconfig and patch descriptions v2: https://lists.denx.de/pipermail/u-boot/2020-December/434991.html - removed Change-Id tags - split defconfig changes into ADC and button related v1: https://lists.denx.de/pipermail/u-boot/2020-December/434875.html - initial submission Patch summary: Marek Szyprowski (5): dt-bindings: input: adc-keys bindings documentation button: add a simple Analog to Digital Converter device based button driver adc: meson-saradc: add support for getting reference voltage value configs: khadas-vim3(l): enable Function button support test: add a simple test for the adc-keys button driver arch/sandbox/dts/test.dts | 24 +++- configs/khadas-vim3_defconfig | 2 + configs/khadas-vim3l_defconfig | 2 + configs/sandbox_defconfig | 1 + doc/device-tree-bindings/input/adc-keys.txt | 67 + drivers/adc/meson-saradc.c | 21 +++ drivers/button/Kconfig | 8 ++ drivers/button/Makefile | 1 + drivers/button/button-adc.c | 146 test/dm/button.c| 50 ++- 10 files changed, 319 insertions(+), 3 deletions(-) create mode 100644 doc/device-tree-bindings/input/adc-keys.txt create mode 100644 drivers/button/button-adc.c -- 2.17.1
[PATCH v6 4/5] configs: khadas-vim3(l): enable Function button support
Add options required to check the 'Function' button state. Signed-off-by: Marek Szyprowski Reviewed-by: Simon Glass --- configs/khadas-vim3_defconfig | 2 ++ configs/khadas-vim3l_defconfig | 2 ++ 2 files changed, 4 insertions(+) diff --git a/configs/khadas-vim3_defconfig b/configs/khadas-vim3_defconfig index 5d16652fd6..bc17430569 100644 --- a/configs/khadas-vim3_defconfig +++ b/configs/khadas-vim3_defconfig @@ -31,6 +31,8 @@ CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_NET_RANDOM_ETHADDR=y CONFIG_ADC=y CONFIG_SARADC_MESON=y +CONFIG_BUTTON=y +CONFIG_BUTTON_ADC=y CONFIG_DM_I2C=y CONFIG_SYS_I2C_MESON=y CONFIG_DM_MMC=y diff --git a/configs/khadas-vim3l_defconfig b/configs/khadas-vim3l_defconfig index 6b13ce045c..c1877922c7 100644 --- a/configs/khadas-vim3l_defconfig +++ b/configs/khadas-vim3l_defconfig @@ -31,6 +31,8 @@ CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_NET_RANDOM_ETHADDR=y CONFIG_ADC=y CONFIG_SARADC_MESON=y +CONFIG_BUTTON=y +CONFIG_BUTTON_ADC=y CONFIG_DM_I2C=y CONFIG_SYS_I2C_MESON=y CONFIG_DM_MMC=y -- 2.17.1
[PATCH v6 5/5] test: add a simple test for the adc-keys button driver
Add adc-keys device to the sandbox/test.dts and connect it to the channel
#3 of the sandbox_adc driver. The default values sampled by sandbox_adc
driver determines that button3 and button4 are released and button5 is
pressed.
Signed-off-by: Marek Szyprowski
---
arch/sandbox/dts/test.dts | 24 ++-
configs/sandbox_defconfig | 1 +
test/dm/button.c | 50 +--
3 files changed, 72 insertions(+), 3 deletions(-)
diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
index e95f4631bf..a32b019ae7 100644
--- a/arch/sandbox/dts/test.dts
+++ b/arch/sandbox/dts/test.dts
@@ -69,6 +69,27 @@
};
};
+ buttons2 {
+ compatible = "adc-keys";
+ io-channels = <&adc 3>;
+ keyup-threshold-microvolt = <300>;
+
+ button-up {
+ label = "button3";
+ press-threshold-microvolt = <150>;
+ };
+
+ button-down {
+ label = "button4";
+ press-threshold-microvolt = <100>;
+ };
+
+ button-enter {
+ label = "button5";
+ press-threshold-microvolt = <50>;
+ };
+ };
+
cros_ec: cros-ec {
reg = <0 0>;
compatible = "google,cros-ec-sandbox";
@@ -587,8 +608,9 @@
i2c-eeprom = <&bootcount_i2c>;
};
- adc@0 {
+ adc: adc@0 {
compatible = "sandbox,adc";
+ #io-channel-cells = <1>;
vdd-supply = <&buck2>;
vss-microvolts = <0>;
};
diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
index 0c7674efc9..3731bf05ff 100644
--- a/configs/sandbox_defconfig
+++ b/configs/sandbox_defconfig
@@ -122,6 +122,7 @@ CONFIG_DM_BOOTCOUNT=y
CONFIG_DM_BOOTCOUNT_RTC=y
CONFIG_DM_BOOTCOUNT_I2C_EEPROM=y
CONFIG_BUTTON=y
+CONFIG_BUTTON_ADC=y
CONFIG_BUTTON_GPIO=y
CONFIG_CLK=y
CONFIG_CLK_COMPOSITE_CCF=y
diff --git a/test/dm/button.c b/test/dm/button.c
index ecaa47cf5f..f8a7fab61d 100644
--- a/test/dm/button.c
+++ b/test/dm/button.c
@@ -7,7 +7,10 @@
#include
#include
+#include
#include
+#include
+#include
#include
#include
#include
@@ -17,11 +20,20 @@ static int dm_test_button_base(struct unit_test_state *uts)
{
struct udevice *dev;
- /* Get the top-level device */
+ /* Get the top-level gpio buttons device */
ut_assertok(uclass_get_device(UCLASS_BUTTON, 0, &dev));
+ /* Get the 2 gpio buttons */
ut_assertok(uclass_get_device(UCLASS_BUTTON, 1, &dev));
ut_assertok(uclass_get_device(UCLASS_BUTTON, 2, &dev));
- ut_asserteq(-ENODEV, uclass_get_device(UCLASS_BUTTON, 3, &dev));
+
+ /* Get the top-level adc buttons device */
+ ut_assertok(uclass_get_device(UCLASS_BUTTON, 3, &dev));
+ /* Get the 3 adc buttons */
+ ut_assertok(uclass_get_device(UCLASS_BUTTON, 4, &dev));
+ ut_assertok(uclass_get_device(UCLASS_BUTTON, 5, &dev));
+ ut_assertok(uclass_get_device(UCLASS_BUTTON, 6, &dev));
+
+ ut_asserteq(-ENODEV, uclass_get_device(UCLASS_BUTTON, 7, &dev));
return 0;
}
@@ -72,3 +84,37 @@ static int dm_test_button_label(struct unit_test_state *uts)
return 0;
}
DM_TEST(dm_test_button_label, UT_TESTF_SCAN_PDATA | UT_TESTF_SCAN_FDT);
+
+/* Test adc-keys driver */
+static int dm_test_button_keys_adc(struct unit_test_state *uts)
+{
+ struct udevice *supply;
+ struct udevice *dev;
+ int uV;
+
+ ut_assertok(uclass_get_device_by_name(UCLASS_ADC, "adc@0", &dev));
+
+ ut_assertok(regulator_get_by_devname(SANDBOX_BUCK2_DEVNAME, &supply));
+ ut_assertok(regulator_set_value(supply, SANDBOX_BUCK2_SET_UV));
+ ut_asserteq(SANDBOX_BUCK2_SET_UV, regulator_get_value(supply));
+ /* Update ADC plat and get new Vdd value */
+ ut_assertok(adc_vdd_value(dev, &uV));
+ ut_asserteq(SANDBOX_BUCK2_SET_UV, uV);
+
+ /*
+* sandbox-adc returns constant value on channel 3, is used by adc-keys:
+* SANDBOX_ADC_CHANNEL3_DATA * SANDBOX_BUCK2_SET_UV /
SANDBOX_ADC_DATA_MASK =
+* 0x3000 * 330 / 0x = 618759uV
+* This means that button3 and button4 are released and button5
+* is pressed.
+*/
+ ut_assertok(button_get_by_label("button3", &dev));
+ ut_asserteq(BUTTON_OFF, button_get_state(dev));
+ ut_assertok(button_get_by_label("button4", &dev));
+ ut_asserteq(BUTTON_OFF, button_get_state(dev));
+ ut_assertok(button_get_by_label("button5", &dev));
+ ut_asserteq(BUTTON_ON, button_get_state(dev));
+
+ return 0;
+}
+DM_TEST(dm_test_button_keys_adc, UT_TESTF_SCAN_PDATA | UT_TESTF_SCAN_FDT);
--
2.17.1
[PATCH v6 2/5] button: add a simple Analog to Digital Converter device based button driver
Add a simple Analog to Digital Converter device based button driver. This
driver binds to the 'adc-keys' device tree node.
Signed-off-by: Marek Szyprowski
---
drivers/button/Kconfig | 8 ++
drivers/button/Makefile | 1 +
drivers/button/button-adc.c | 146
3 files changed, 155 insertions(+)
create mode 100644 drivers/button/button-adc.c
diff --git a/drivers/button/Kconfig b/drivers/button/Kconfig
index 6b3ec7e55d..6db3c5e93a 100644
--- a/drivers/button/Kconfig
+++ b/drivers/button/Kconfig
@@ -9,6 +9,14 @@ config BUTTON
can provide access to board-specific buttons. Use of the device tree
for configuration is encouraged.
+config BUTTON_ADC
+ bool "Button adc"
+ depends on BUTTON
+ help
+ Enable support for buttons which are connected to Analog to Digital
+ Converter device. The ADC driver must use driver model. Buttons are
+ configured using the device tree.
+
config BUTTON_GPIO
bool "Button gpio"
depends on BUTTON
diff --git a/drivers/button/Makefile b/drivers/button/Makefile
index fcc10ebe8d..bbd18af149 100644
--- a/drivers/button/Makefile
+++ b/drivers/button/Makefile
@@ -3,4 +3,5 @@
# Copyright (C) 2020 Philippe Reynes
obj-$(CONFIG_BUTTON) += button-uclass.o
+obj-$(CONFIG_BUTTON_ADC) += button-adc.o
obj-$(CONFIG_BUTTON_GPIO) += button-gpio.o
diff --git a/drivers/button/button-adc.c b/drivers/button/button-adc.c
new file mode 100644
index 00..eed86564fb
--- /dev/null
+++ b/drivers/button/button-adc.c
@@ -0,0 +1,146 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2021 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ * Author: Marek Szyprowski
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/**
+ * struct button_adc_priv - private data for button-adc driver.
+ *
+ * @adc: Analog to Digital Converter device to which button is connected.
+ * @channel: channel of the ADC device to probe the button state.
+ * @min: minimal uV value to consider button as pressed.
+ * @max: maximal uV value to consider button as pressed.
+ */
+struct button_adc_priv {
+ struct udevice *adc;
+ int channel;
+ int min;
+ int max;
+};
+
+static enum button_state_t button_adc_get_state(struct udevice *dev)
+{
+ struct button_adc_priv *priv = dev_get_priv(dev);
+ unsigned int val;
+ int ret, uV;
+
+ ret = adc_start_channel(priv->adc, priv->channel);
+ if (ret)
+ return ret;
+
+ ret = adc_channel_data(priv->adc, priv->channel, &val);
+ if (ret)
+ return ret;
+
+ ret = adc_raw_to_uV(priv->adc, val, &uV);
+ if (ret)
+ return ret;
+
+ return (uV >= priv->min && uV < priv->max) ? BUTTON_ON : BUTTON_OFF;
+}
+
+static int button_adc_of_to_plat(struct udevice *dev)
+{
+ struct button_uc_plat *uc_plat = dev_get_uclass_plat(dev);
+ struct button_adc_priv *priv = dev_get_priv(dev);
+ struct ofnode_phandle_args args;
+ u32 treshold, up_treshold, t;
+ ofnode node;
+ int ret;
+
+ /* Ignore the top-level button node */
+ if (!uc_plat->label)
+ return 0;
+
+ ret = dev_read_phandle_with_args(dev->parent, "io-channels",
+"#io-channel-cells", 0, 0, &args);
+ if (ret)
+ return ret;
+
+ ret = uclass_get_device_by_ofnode(UCLASS_ADC, args.node, &priv->adc);
+ if (ret)
+ return ret;
+
+ ret = ofnode_read_u32(dev_ofnode(dev->parent),
+ "keyup-threshold-microvolt", &up_treshold);
+ if (ret)
+ return ret;
+
+ ret = ofnode_read_u32(dev_ofnode(dev), "press-threshold-microvolt",
+ &treshold);
+ if (ret)
+ return ret;
+
+ dev_for_each_subnode(node, dev->parent) {
+ ret = ofnode_read_u32(node, "press-threshold-microvolt", &t);
+ if (ret)
+ return ret;
+
+ if (t > treshold)
+ up_treshold = t;
+ }
+
+ priv->channel = args.args[0];
+ priv->min = treshold;
+ priv->max = up_treshold;
+
+ return ret;
+}
+
+static int button_adc_bind(struct udevice *parent)
+{
+ struct udevice *dev;
+ ofnode node;
+ int ret;
+
+ dev_for_each_subnode(node, parent) {
+ struct button_uc_plat *uc_plat;
+ const char *label;
+
+ label = ofnode_read_string(node, "label");
+ if (!label) {
+ debug("%s: node %s has no label\n",
[PATCH v7 5/5] test: add a simple test for the adc-keys button driver
Add adc-keys device to the sandbox/test.dts and connect it to the channel
#3 of the sandbox_adc driver. The default values sampled by sandbox_adc
driver determines that button3 and button4 are released and button5 is
pressed.
Signed-off-by: Marek Szyprowski
Reviewed-by: Simon Glass
---
arch/sandbox/dts/test.dts | 28 +-
configs/sandbox_defconfig | 1 +
test/dm/button.c | 50 +--
3 files changed, 76 insertions(+), 3 deletions(-)
diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
index e95f4631bf..202e091841 100644
--- a/arch/sandbox/dts/test.dts
+++ b/arch/sandbox/dts/test.dts
@@ -2,6 +2,7 @@
#include
#include
+#include
#include
#include
@@ -69,6 +70,30 @@
};
};
+ buttons2 {
+ compatible = "adc-keys";
+ io-channels = <&adc 3>;
+ keyup-threshold-microvolt = <300>;
+
+ button-up {
+ label = "button3";
+ linux,code = ;
+ press-threshold-microvolt = <150>;
+ };
+
+ button-down {
+ label = "button4";
+ linux,code = ;
+ press-threshold-microvolt = <100>;
+ };
+
+ button-enter {
+ label = "button5";
+ linux,code = ;
+ press-threshold-microvolt = <50>;
+ };
+ };
+
cros_ec: cros-ec {
reg = <0 0>;
compatible = "google,cros-ec-sandbox";
@@ -587,8 +612,9 @@
i2c-eeprom = <&bootcount_i2c>;
};
- adc@0 {
+ adc: adc@0 {
compatible = "sandbox,adc";
+ #io-channel-cells = <1>;
vdd-supply = <&buck2>;
vss-microvolts = <0>;
};
diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
index 0c7674efc9..3731bf05ff 100644
--- a/configs/sandbox_defconfig
+++ b/configs/sandbox_defconfig
@@ -122,6 +122,7 @@ CONFIG_DM_BOOTCOUNT=y
CONFIG_DM_BOOTCOUNT_RTC=y
CONFIG_DM_BOOTCOUNT_I2C_EEPROM=y
CONFIG_BUTTON=y
+CONFIG_BUTTON_ADC=y
CONFIG_BUTTON_GPIO=y
CONFIG_CLK=y
CONFIG_CLK_COMPOSITE_CCF=y
diff --git a/test/dm/button.c b/test/dm/button.c
index ecaa47cf5f..f8a7fab61d 100644
--- a/test/dm/button.c
+++ b/test/dm/button.c
@@ -7,7 +7,10 @@
#include
#include
+#include
#include
+#include
+#include
#include
#include
#include
@@ -17,11 +20,20 @@ static int dm_test_button_base(struct unit_test_state *uts)
{
struct udevice *dev;
- /* Get the top-level device */
+ /* Get the top-level gpio buttons device */
ut_assertok(uclass_get_device(UCLASS_BUTTON, 0, &dev));
+ /* Get the 2 gpio buttons */
ut_assertok(uclass_get_device(UCLASS_BUTTON, 1, &dev));
ut_assertok(uclass_get_device(UCLASS_BUTTON, 2, &dev));
- ut_asserteq(-ENODEV, uclass_get_device(UCLASS_BUTTON, 3, &dev));
+
+ /* Get the top-level adc buttons device */
+ ut_assertok(uclass_get_device(UCLASS_BUTTON, 3, &dev));
+ /* Get the 3 adc buttons */
+ ut_assertok(uclass_get_device(UCLASS_BUTTON, 4, &dev));
+ ut_assertok(uclass_get_device(UCLASS_BUTTON, 5, &dev));
+ ut_assertok(uclass_get_device(UCLASS_BUTTON, 6, &dev));
+
+ ut_asserteq(-ENODEV, uclass_get_device(UCLASS_BUTTON, 7, &dev));
return 0;
}
@@ -72,3 +84,37 @@ static int dm_test_button_label(struct unit_test_state *uts)
return 0;
}
DM_TEST(dm_test_button_label, UT_TESTF_SCAN_PDATA | UT_TESTF_SCAN_FDT);
+
+/* Test adc-keys driver */
+static int dm_test_button_keys_adc(struct unit_test_state *uts)
+{
+ struct udevice *supply;
+ struct udevice *dev;
+ int uV;
+
+ ut_assertok(uclass_get_device_by_name(UCLASS_ADC, "adc@0", &dev));
+
+ ut_assertok(regulator_get_by_devname(SANDBOX_BUCK2_DEVNAME, &supply));
+ ut_assertok(regulator_set_value(supply, SANDBOX_BUCK2_SET_UV));
+ ut_asserteq(SANDBOX_BUCK2_SET_UV, regulator_get_value(supply));
+ /* Update ADC plat and get new Vdd value */
+ ut_assertok(adc_vdd_value(dev, &uV));
+ ut_asserteq(SANDBOX_BUCK2_SET_UV, uV);
+
+ /*
+* sandbox-adc returns constant value on channel 3, is used by adc-keys:
+* SANDBOX_ADC_CHANNEL3_DATA * SANDBOX_BUCK2_SET_UV /
SANDBOX_ADC_DATA_MASK =
+* 0x3000 * 330 / 0x = 618759uV
+* This means that button3 and button4 are released and button5
+* is pressed.
+*/
+ ut_assertok(button_get_by_label("button3", &dev));
+ ut_asserteq(BUTTON_OFF, button_get_state(dev));
+ ut_assertok(b
[PATCH v7 4/5] configs: khadas-vim3(l): enable Function button support
Add options required to check the 'Function' button state. Signed-off-by: Marek Szyprowski Reviewed-by: Simon Glass --- configs/khadas-vim3_defconfig | 2 ++ configs/khadas-vim3l_defconfig | 2 ++ 2 files changed, 4 insertions(+) diff --git a/configs/khadas-vim3_defconfig b/configs/khadas-vim3_defconfig index 5d16652fd6..bc17430569 100644 --- a/configs/khadas-vim3_defconfig +++ b/configs/khadas-vim3_defconfig @@ -31,6 +31,8 @@ CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_NET_RANDOM_ETHADDR=y CONFIG_ADC=y CONFIG_SARADC_MESON=y +CONFIG_BUTTON=y +CONFIG_BUTTON_ADC=y CONFIG_DM_I2C=y CONFIG_SYS_I2C_MESON=y CONFIG_DM_MMC=y diff --git a/configs/khadas-vim3l_defconfig b/configs/khadas-vim3l_defconfig index 6b13ce045c..c1877922c7 100644 --- a/configs/khadas-vim3l_defconfig +++ b/configs/khadas-vim3l_defconfig @@ -31,6 +31,8 @@ CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_NET_RANDOM_ETHADDR=y CONFIG_ADC=y CONFIG_SARADC_MESON=y +CONFIG_BUTTON=y +CONFIG_BUTTON_ADC=y CONFIG_DM_I2C=y CONFIG_SYS_I2C_MESON=y CONFIG_DM_MMC=y -- 2.17.1
[PATCH v7 2/5] button: add a simple Analog to Digital Converter device based button driver
Add a simple Analog to Digital Converter device based button driver. This
driver binds to the 'adc-keys' device tree node.
Signed-off-by: Marek Szyprowski
Reviewed-by: Simon Glass
---
drivers/button/Kconfig | 8 ++
drivers/button/Makefile | 1 +
drivers/button/button-adc.c | 146
3 files changed, 155 insertions(+)
create mode 100644 drivers/button/button-adc.c
diff --git a/drivers/button/Kconfig b/drivers/button/Kconfig
index 6b3ec7e55d..6db3c5e93a 100644
--- a/drivers/button/Kconfig
+++ b/drivers/button/Kconfig
@@ -9,6 +9,14 @@ config BUTTON
can provide access to board-specific buttons. Use of the device tree
for configuration is encouraged.
+config BUTTON_ADC
+ bool "Button adc"
+ depends on BUTTON
+ help
+ Enable support for buttons which are connected to Analog to Digital
+ Converter device. The ADC driver must use driver model. Buttons are
+ configured using the device tree.
+
config BUTTON_GPIO
bool "Button gpio"
depends on BUTTON
diff --git a/drivers/button/Makefile b/drivers/button/Makefile
index fcc10ebe8d..bbd18af149 100644
--- a/drivers/button/Makefile
+++ b/drivers/button/Makefile
@@ -3,4 +3,5 @@
# Copyright (C) 2020 Philippe Reynes
obj-$(CONFIG_BUTTON) += button-uclass.o
+obj-$(CONFIG_BUTTON_ADC) += button-adc.o
obj-$(CONFIG_BUTTON_GPIO) += button-gpio.o
diff --git a/drivers/button/button-adc.c b/drivers/button/button-adc.c
new file mode 100644
index 00..eed86564fb
--- /dev/null
+++ b/drivers/button/button-adc.c
@@ -0,0 +1,146 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2021 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ * Author: Marek Szyprowski
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/**
+ * struct button_adc_priv - private data for button-adc driver.
+ *
+ * @adc: Analog to Digital Converter device to which button is connected.
+ * @channel: channel of the ADC device to probe the button state.
+ * @min: minimal uV value to consider button as pressed.
+ * @max: maximal uV value to consider button as pressed.
+ */
+struct button_adc_priv {
+ struct udevice *adc;
+ int channel;
+ int min;
+ int max;
+};
+
+static enum button_state_t button_adc_get_state(struct udevice *dev)
+{
+ struct button_adc_priv *priv = dev_get_priv(dev);
+ unsigned int val;
+ int ret, uV;
+
+ ret = adc_start_channel(priv->adc, priv->channel);
+ if (ret)
+ return ret;
+
+ ret = adc_channel_data(priv->adc, priv->channel, &val);
+ if (ret)
+ return ret;
+
+ ret = adc_raw_to_uV(priv->adc, val, &uV);
+ if (ret)
+ return ret;
+
+ return (uV >= priv->min && uV < priv->max) ? BUTTON_ON : BUTTON_OFF;
+}
+
+static int button_adc_of_to_plat(struct udevice *dev)
+{
+ struct button_uc_plat *uc_plat = dev_get_uclass_plat(dev);
+ struct button_adc_priv *priv = dev_get_priv(dev);
+ struct ofnode_phandle_args args;
+ u32 treshold, up_treshold, t;
+ ofnode node;
+ int ret;
+
+ /* Ignore the top-level button node */
+ if (!uc_plat->label)
+ return 0;
+
+ ret = dev_read_phandle_with_args(dev->parent, "io-channels",
+"#io-channel-cells", 0, 0, &args);
+ if (ret)
+ return ret;
+
+ ret = uclass_get_device_by_ofnode(UCLASS_ADC, args.node, &priv->adc);
+ if (ret)
+ return ret;
+
+ ret = ofnode_read_u32(dev_ofnode(dev->parent),
+ "keyup-threshold-microvolt", &up_treshold);
+ if (ret)
+ return ret;
+
+ ret = ofnode_read_u32(dev_ofnode(dev), "press-threshold-microvolt",
+ &treshold);
+ if (ret)
+ return ret;
+
+ dev_for_each_subnode(node, dev->parent) {
+ ret = ofnode_read_u32(node, "press-threshold-microvolt", &t);
+ if (ret)
+ return ret;
+
+ if (t > treshold)
+ up_treshold = t;
+ }
+
+ priv->channel = args.args[0];
+ priv->min = treshold;
+ priv->max = up_treshold;
+
+ return ret;
+}
+
+static int button_adc_bind(struct udevice *parent)
+{
+ struct udevice *dev;
+ ofnode node;
+ int ret;
+
+ dev_for_each_subnode(node, parent) {
+ struct button_uc_plat *uc_plat;
+ const char *label;
+
+ label = ofnode_read_string(node, "label");
+ if (!label) {
+ debug("%s: node %s has no label\n",
[PATCH v7 3/5] adc: meson-saradc: add support for getting reference voltage value
Add support for getting the 'vref-supply' regulator and register it as
ADC's reference voltage regulator, so clients can translate sampled ADC
values to the voltage.
Signed-off-by: Marek Szyprowski
Reviewed-by: Simon Glass
---
drivers/adc/meson-saradc.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/drivers/adc/meson-saradc.c b/drivers/adc/meson-saradc.c
index 21db55831d..1a45a3a265 100644
--- a/drivers/adc/meson-saradc.c
+++ b/drivers/adc/meson-saradc.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#define MESON_SAR_ADC_REG0 0x00
#define MESON_SAR_ADC_REG0_PANEL_DETECT BIT(31)
@@ -656,7 +657,10 @@ static int meson_saradc_stop(struct udevice *dev)
static int meson_saradc_probe(struct udevice *dev)
{
+ struct adc_uclass_plat *uc_pdata = dev_get_uclass_plat(dev);
struct meson_saradc_priv *priv = dev_get_priv(dev);
+ struct udevice *vref;
+ int vref_uv;
int ret;
ret = regmap_init_mem(dev_ofnode(dev), &priv->regmap);
@@ -675,6 +679,23 @@ static int meson_saradc_probe(struct udevice *dev)
priv->active_channel = -1;
+ ret = device_get_supply_regulator(dev, "vref-supply", &vref);
+ if (ret) {
+ printf("can't get vref-supply: %d\n", ret);
+ return ret;
+ }
+
+ vref_uv = regulator_get_value(vref);
+ if (vref_uv < 0) {
+ printf("can't get vref-supply value: %d\n", vref_uv);
+ return vref_uv;
+ }
+
+ /* VDD supplied by common vref pin */
+ uc_pdata->vdd_supply = vref;
+ uc_pdata->vdd_microvolts = vref_uv;
+ uc_pdata->vss_microvolts = 0;
+
return 0;
}
--
2.17.1
[PATCH v7 0/5] VIM3: add support for checking 'Function' button state
Hi All, This patchset adds all building blocks needed for checking the 'Function' button state in the boot script on Amlogic A311D based VIM3 board. This button is connected to the ADC line of the SoC, so it required to enable meson SARADC, the clocks needed for it and a simple button-adc drivers. Once applied, one can use following commands in the boot scripts: -->8--- echo Checking Func button state: \\c if button Function then echo Selected alternative boot ... fi --->8--- Best regards Marek Szyprowski Samsung R&D Institute Poland Changelog: v7: - added linux,code properties to the test.dts v6: https://lists.denx.de/pipermail/u-boot/2021-February/441039.html - added a simple sandbox test for adc-keys - use of_to_plat and adc_raw_to_uV to simplify code in the adc button driver v5: https://lists.denx.de/pipermail/u-boot/2021-January/438751.html - rebased onto latest uboot-amlogic/u-boot-amlogic-next branch - synchronized adc-keys binding with the recent version from the Linux kernel - updated adc-keys driver to match behavior from dt-bindings - added a patch for meson-saradc driver to register vdd reference supply to the ADC framework v4: https://lists.denx.de/pipermail/u-boot/2020-December/435641.html - rebased onto uboot-amlogic/u-boot-amlogic-next and dropped merged patches - added adc-keys bindings docs (copied from Linux kernel) - minor code adjustments pointed by Simon - enabled driver also in khadas-vim3l_defconfig v3: https://lists.denx.de/pipermail/u-boot/2020-December/435072.html - removed 'button' env variable - extended kconfig and patch descriptions v2: https://lists.denx.de/pipermail/u-boot/2020-December/434991.html - removed Change-Id tags - split defconfig changes into ADC and button related v1: https://lists.denx.de/pipermail/u-boot/2020-December/434875.html - initial submission Patch summary: Marek Szyprowski (5): dt-bindings: input: adc-keys bindings documentation button: add a simple Analog to Digital Converter device based button driver adc: meson-saradc: add support for getting reference voltage value configs: khadas-vim3(l): enable Function button support test: add a simple test for the adc-keys button driver arch/sandbox/dts/test.dts | 27 +++- configs/khadas-vim3_defconfig | 2 + configs/khadas-vim3l_defconfig | 2 + configs/sandbox_defconfig | 1 + doc/device-tree-bindings/input/adc-keys.txt | 67 + drivers/adc/meson-saradc.c | 21 +++ drivers/button/Kconfig | 8 ++ drivers/button/Makefile | 1 + drivers/button/button-adc.c | 146 test/dm/button.c| 50 ++- 10 files changed, 322 insertions(+), 3 deletions(-) create mode 100644 doc/device-tree-bindings/input/adc-keys.txt create mode 100644 drivers/button/button-adc.c -- 2.17.1
[PATCH v7 1/5] dt-bindings: input: adc-keys bindings documentation
Dump adc-keys bindings documentation from Linux kernel source tree from
commit 698dc0cf9447 ("dt-bindings: input: adc-keys: clarify
description").
Signed-off-by: Marek Szyprowski
Reviewed-by: Simon Glass
---
doc/device-tree-bindings/input/adc-keys.txt | 67 +
1 file changed, 67 insertions(+)
create mode 100644 doc/device-tree-bindings/input/adc-keys.txt
diff --git a/doc/device-tree-bindings/input/adc-keys.txt
b/doc/device-tree-bindings/input/adc-keys.txt
new file mode 100644
index 00..6c8be6a9ac
--- /dev/null
+++ b/doc/device-tree-bindings/input/adc-keys.txt
@@ -0,0 +1,67 @@
+ADC attached resistor ladder buttons
+
+
+Required properties:
+ - compatible: "adc-keys"
+ - io-channels: Phandle to an ADC channel
+ - io-channel-names = "buttons";
+ - keyup-threshold-microvolt: Voltage above or equal to which all the keys are
+ considered up.
+
+Optional properties:
+ - poll-interval: Poll interval time in milliseconds
+ - autorepeat: Boolean, Enable auto repeat feature of Linux input
+ subsystem.
+
+Each button (key) is represented as a sub-node of "adc-keys":
+
+Required subnode-properties:
+ - label: Descriptive name of the key.
+ - linux,code: Keycode to emit.
+ - press-threshold-microvolt: voltage above or equal to which this key is
+considered pressed.
+
+No two values of press-threshold-microvolt may be the same.
+All values of press-threshold-microvolt must be less than
+keyup-threshold-microvolt.
+
+Example:
+
+#include
+
+ adc-keys {
+ compatible = "adc-keys";
+ io-channels = <&lradc 0>;
+ io-channel-names = "buttons";
+ keyup-threshold-microvolt = <200>;
+
+ button-up {
+ label = "Volume Up";
+ linux,code = ;
+ press-threshold-microvolt = <150>;
+ };
+
+ button-down {
+ label = "Volume Down";
+ linux,code = ;
+ press-threshold-microvolt = <100>;
+ };
+
+ button-enter {
+ label = "Enter";
+ linux,code = ;
+ press-threshold-microvolt = <50>;
+ };
+ };
+
++++
+| 2.000.000 <= value | no key pressed |
++++
+| 1.500.000 <= value < 2.000.000 | KEY_VOLUMEUP pressed |
++++
+| 1.000.000 <= value < 1.500.000 | KEY_VOLUMEDOWN pressed |
++++
+| 500.000 <= value < 1.000.000 | KEY_ENTER pressed |
++++
+| value < 500.000 | no key pressed |
++++
--
2.17.1
Re: [PATCH] button: adc: fix treshold typo
On 23.02.2021 16:10, Neil Armstrong wrote:
> Fix the treshold typo in code by threshold.
>
> Fixes: c0165c85c3 ("button: add a simple Analog to Digital Converter device
> based button driver")
> Suggested-by: Tom Rini
> Signed-off-by: Neil Armstrong
Acked-by: Marek Szyprowski
> ---
> drivers/button/button-adc.c | 14 +++---
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/button/button-adc.c b/drivers/button/button-adc.c
> index eed86564fb..fd896c76f9 100644
> --- a/drivers/button/button-adc.c
> +++ b/drivers/button/button-adc.c
> @@ -55,7 +55,7 @@ static int button_adc_of_to_plat(struct udevice *dev)
> struct button_uc_plat *uc_plat = dev_get_uclass_plat(dev);
> struct button_adc_priv *priv = dev_get_priv(dev);
> struct ofnode_phandle_args args;
> - u32 treshold, up_treshold, t;
> + u32 threshold, up_threshold, t;
> ofnode node;
> int ret;
>
> @@ -73,12 +73,12 @@ static int button_adc_of_to_plat(struct udevice *dev)
> return ret;
>
> ret = ofnode_read_u32(dev_ofnode(dev->parent),
> - "keyup-threshold-microvolt", &up_treshold);
> + "keyup-threshold-microvolt", &up_threshold);
> if (ret)
> return ret;
>
> ret = ofnode_read_u32(dev_ofnode(dev), "press-threshold-microvolt",
> - &treshold);
> + &threshold);
> if (ret)
> return ret;
>
> @@ -87,13 +87,13 @@ static int button_adc_of_to_plat(struct udevice *dev)
> if (ret)
> return ret;
>
> - if (t > treshold)
> - up_treshold = t;
> + if (t > threshold)
> + up_threshold = t;
> }
>
> priv->channel = args.args[0];
> - priv->min = treshold;
> - priv->max = up_treshold;
> + priv->min = threshold;
> + priv->max = up_threshold;
>
> return ret;
> }
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
u-boot on RPi4 32bit - issue after upgrading the firmware
Hi!
Recently I've upgraded a video core firmware on my RPi4 and I've noticed
that u-boot in ARM 32bit mode stopped working properly or even randomly
crashes. I've bisected the firmware releases and the issue appears for
the first time in the commit 63b1922311 ("firmware: arm_loader: Update
armstubs with those from PR 117 See:
https://github.com/raspberrypi/tools/pull/117";).
This issue can be easily observed as a failure of the xhci. See the
attached log:
Read start4x.elf bytes 2984808 hnd 0x06e2 sha256 d21bf9d3954fea04
Read fixup4x.dat bytes 8432 hnd 0x06dd sha256 10d3b073ab232613
0x00a03111 0x 0x001f
MEM GPU: 76 ARM: 948 TOTAL: 1024
Starting start4x.elf @ 0xfec00200 partition 0
PCI reset
+
MESS:00:00:04.800023:0: arasan: arasan_emmc_open
MESS:00:00:04.975752:0: brfs: File read: /mfs/sd/config.txt
MESS:00:00:04.979162:0: brfs: File read: 2153 bytes
MESS:00:00:05.046081:0: brfs: File read: /mfs/sd/config.txt
MESS:00:00:06.121174:0: gpioman: gpioman_get_pin_num: pin
DISPLAY_DSI_PORT not defined
MESS:00:00:06.128433:0: *** Restart logging
MESS:00:00:06.129897:0: brfs: File read: 2153 bytes
MESS:00:00:06.148533:0: hdmi: HDMI:hdmi_get_state is deprecated, use
hdmi_get_display_state instead
MESS:00:00:06.154474:0: HDMI0: hdmi_pixel_encoding: 3
MESS:00:00:06.159948:0: HDMI1: hdmi_pixel_encoding: 3
MESS:00:00:06.166901:0: dtb_file 'bcm2711-rpi-4-b.dtb'
MESS:00:00:06.178359:0: brfs: File read: /mfs/sd/bcm2711-rpi-4-b.dtb
MESS:00:00:06.181601:0: Loading 'bcm2711-rpi-4-b.dtb' to 0x100 size 0xc901
MESS:00:00:06.201386:0: brfs: File read: 51457 bytes
MESS:00:00:06.267975:0: brfs: File read: /mfs/sd/config.txt
MESS:00:00:06.270915:0: dtparam: audio=on
MESS:00:00:06.283974:0: brfs: File read: 2153 bytes
MESS:00:00:06.286148:0: Failed to load overlay 'vc4-fkms-v3d'
MESS:00:00:06.291378:0: brfs: File read: /mfs/sd/overlays/vc4-fkms-v3d.dtbo
MESS:00:00:06.304096:0: Failed to open command line file 'cmdline.txt'
MESS:00:00:07.484256:0: brfs: File read: /mfs/sd/u-boot.bin
MESS:00:00:07.486726:0: Loading 'u-boot.bin' to 0x8000 size 0x84cf4
MESS:00:00:07.492726:0: Device tree loaded to 0x2eff3100 (size 0xce24)
MESS:00:00:07.500863:0: uart: Set PL011 baud rate to 103448.30 Hz
MESS:00:00:07.508031:0: uart: Baud rate change done...
MESS:00:00:07.510053:0:
U-Boot 2021.04-rc2 (Feb 25 2021 - 11:21:44 +0100)
DRAM: 948 MiB
RPI 4 Model B (0xa03111)
MMC: mmcnr@7e30: 1, emmc2@7e34: 0
Loading Environment from FAT... OK
In: serial
Out: serial
Err: serial
Net: eth0: ethernet@7d58
Hit any key to stop autoboot: 0
U-Boot> pci enum
PCIe BRCM: link up, 5.0 Gbps x1 (SSC)
U-Boot> usb start
starting USB...
Bus xhci_pci: Host not halted after 16000 microseconds.
probe failed, error -16
No working controllers found
U-Boot>
Is it a known issue? In ARM64 mode everything works fine, but this not
very surprising, because the firmware change in the mentioned commit is
related to the ARM 32bit mode. Does anyone have an idea how to fix this
issue? I've checked also the latest version of the RPi firmware, but the
issue is still there.
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
Re: u-boot on RPi4 32bit - issue after upgrading the firmware
Hi Nicolas,
On 25.02.2021 11:55, Nicolas Saenz Julienne wrote:
> On Thu, 2021-02-25 at 11:43 +0100, Marek Szyprowski wrote:
>> Recently I've upgraded a video core firmware on my RPi4 and I've noticed
>> that u-boot in ARM 32bit mode stopped working properly or even randomly
>> crashes. I've bisected the firmware releases and the issue appears for
>> the first time in the commit 63b1922311 ("firmware: arm_loader: Update
>> armstubs with those from PR 117 See:
>> https://protect2.fireeye.com/v1/url?k=a201e8b0-fd9ad069-a20063ff-0cc47a3356b2-1ab72bd783ec5635&q=1&e=5f377675-c909-4cc4-a1d5-b740cbf6255e&u=https%3A%2F%2Fgithub.com%2Fraspberrypi%2Ftools%2Fpull%2F117";).
> Just for confirmation,
>> This issue can be easily observed as a failure of the xhci. See the
>> attached log:
>>
>> Read start4x.elf bytes 2984808 hnd 0x06e2 sha256 d21bf9d3954fea04
>> Read fixup4x.dat bytes 8432 hnd 0x06dd sha256 10d3b073ab232613
>> 0x00a03111 0x 0x001f
>> MEM GPU: 76 ARM: 948 TOTAL: 1024
>> Starting start4x.elf @ 0xfec00200 partition 0
>> PCI reset
>> +
>>
>> MESS:00:00:04.800023:0: arasan: arasan_emmc_open
>> MESS:00:00:04.975752:0: brfs: File read: /mfs/sd/config.txt
>> MESS:00:00:04.979162:0: brfs: File read: 2153 bytes
>> MESS:00:00:05.046081:0: brfs: File read: /mfs/sd/config.txt
>> MESS:00:00:06.121174:0: gpioman: gpioman_get_pin_num: pin
>> DISPLAY_DSI_PORT not defined
>> MESS:00:00:06.128433:0: *** Restart logging
>> MESS:00:00:06.129897:0: brfs: File read: 2153 bytes
>> MESS:00:00:06.148533:0: hdmi: HDMI:hdmi_get_state is deprecated, use
>> hdmi_get_display_state instead
>> MESS:00:00:06.154474:0: HDMI0: hdmi_pixel_encoding: 3
>> MESS:00:00:06.159948:0: HDMI1: hdmi_pixel_encoding: 3
>> MESS:00:00:06.166901:0: dtb_file 'bcm2711-rpi-4-b.dtb'
>> MESS:00:00:06.178359:0: brfs: File read: /mfs/sd/bcm2711-rpi-4-b.dtb
>> MESS:00:00:06.181601:0: Loading 'bcm2711-rpi-4-b.dtb' to 0x100 size 0xc901
>> MESS:00:00:06.201386:0: brfs: File read: 51457 bytes
>> MESS:00:00:06.267975:0: brfs: File read: /mfs/sd/config.txt
>> MESS:00:00:06.270915:0: dtparam: audio=on
>> MESS:00:00:06.283974:0: brfs: File read: 2153 bytes
>> MESS:00:00:06.286148:0: Failed to load overlay 'vc4-fkms-v3d'
>> MESS:00:00:06.291378:0: brfs: File read: /mfs/sd/overlays/vc4-fkms-v3d.dtbo
>> MESS:00:00:06.304096:0: Failed to open command line file 'cmdline.txt'
>> MESS:00:00:07.484256:0: brfs: File read: /mfs/sd/u-boot.bin
>> MESS:00:00:07.486726:0: Loading 'u-boot.bin' to 0x8000 size 0x84cf4
>> MESS:00:00:07.492726:0: Device tree loaded to 0x2eff3100 (size 0xce24)
>> MESS:00:00:07.500863:0: uart: Set PL011 baud rate to 103448.30 Hz
>> MESS:00:00:07.508031:0: uart: Baud rate change done...
>> MESS:00:00:07.510053:0:
>>
>> U-Boot 2021.04-rc2 (Feb 25 2021 - 11:21:44 +0100)
> Can you try with today's master branch, I'm specially interested in seeing if
> 56f1bcc4b7fb helps.
I've checked the mentioned commit, sadly nothing changes:
U-Boot 2021.04-rc2-00041-g56f1bcc4b7 (Feb 25 2021 - 12:05:07 +0100)
DRAM: 948 MiB
RPI 4 Model B (0xa03111)
MMC: mmcnr@7e30: 1, emmc2@7e34: 0
Loading Environment from FAT... OK
In: serial
Out: serial
Err: serial
Net: eth0: ethernet@7d58
Hit any key to stop autoboot: 0
U-Boot> pci enum
PCIe BRCM: link up, 5.0 Gbps x1 (SSC)
U-Boot> usb start
starting USB...
Bus xhci_pci: Host not halted after 16000 microseconds.
probe failed, error -16
No working controllers found
U-Boot>
I've checked that on two RPi4 boards (one with 1GB RAM and one with 8GB).
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
Re: [PATCH v5 0/6] ARM: arbitrary virtual-physical mappings for RPi4 XHCI support
Hi Matthias, On 11.06.2020 10:39, Matthias Brugger wrote: > ... > Series looks good to me. The problem is that on RPi4 with 8 GB the USB FW > get's > loaded via the RPi FW. Nicolas provided a series which is under review right > now. Without this series the 8 GB RPi4 won't boot. As soon as the series is > ready I'll take all the RPi4 PCI/USB related patches into the next branch. I've noticed that You took both required patchsets to rpi-next branch. May I ask for taking this one too? Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland
Re: [U-Boot] [PATCH v2 6/6] config: enable DFU over USB on Raspberry Pi4 boards
Hi Matthias, On 08.11.2019 17:57, Matthias Brugger wrote: > First of all thanks for the patch and sorry for the late response. > > On 24/09/2019 15:11, Marek Szyprowski wrote: >> Enable support for DFU over USB. This requires to enable USB gadget, >> DWC2 UDC OTG driver and DFU command. DFU entities are defined for the >> following firmware objects: u-boot.bin, uboot.env, config.txt, cmdline.txt >> and zImage/Image.gz. >> >> Signed-off-by: Marek Szyprowski >> Reviewed-by: Lukasz Majewski >> --- >> configs/rpi_4_32b_defconfig | 11 +++ >> configs/rpi_4_defconfig | 11 +++ >> include/configs/rpi.h | 17 + >> 3 files changed, 39 insertions(+) >> >> diff --git a/configs/rpi_4_32b_defconfig b/configs/rpi_4_32b_defconfig >> index a31a617a5f..0a375b9736 100644 >> --- a/configs/rpi_4_32b_defconfig >> +++ b/configs/rpi_4_32b_defconfig >> @@ -12,6 +12,7 @@ CONFIG_MISC_INIT_R=y >> # CONFIG_DISPLAY_CPUINFO is not set >> # CONFIG_DISPLAY_BOARDINFO is not set >> CONFIG_SYS_PROMPT="U-Boot> " >> +CONFIG_CMD_DFU=y >> # CONFIG_CMD_FLASH is not set >> CONFIG_CMD_GPIO=y >> CONFIG_CMD_MMC=y >> @@ -19,6 +20,7 @@ CONFIG_CMD_FS_UUID=y >> CONFIG_ENV_FAT_INTERFACE="mmc" >> CONFIG_ENV_FAT_DEVICE_AND_PART="0:1" >> CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y >> +CONFIG_DFU_MMC=y >> CONFIG_DM_KEYBOARD=y >> CONFIG_DM_MMC=y >> CONFIG_MMC_SDHCI=y >> @@ -26,6 +28,15 @@ CONFIG_MMC_SDHCI_BCM2835=y >> CONFIG_PINCTRL=y >> # CONFIG_PINCTRL_GENERIC is not set >> # CONFIG_REQUIRE_SERIAL_CONSOLE is not set >> +CONFIG_USB=y >> +CONFIG_DM_USB=y >> +CONFIG_DM_USB_GADGET=y >> +CONFIG_USB_GADGET=y >> +CONFIG_USB_GADGET_MANUFACTURER="FSL" >> +CONFIG_USB_GADGET_VENDOR_NUM=0x0525 >> +CONFIG_USB_GADGET_PRODUCT_NUM=0xa4a5 >> +CONFIG_USB_GADGET_DWC2_OTG=y >> +CONFIG_USB_GADGET_DOWNLOAD=y >> CONFIG_DM_VIDEO=y >> CONFIG_SYS_WHITE_ON_BLACK=y >> CONFIG_CONSOLE_SCROLL_LINES=10 >> diff --git a/configs/rpi_4_defconfig b/configs/rpi_4_defconfig >> index da8c960a2a..5b9be9b9c0 100644 >> --- a/configs/rpi_4_defconfig >> +++ b/configs/rpi_4_defconfig >> @@ -12,6 +12,7 @@ CONFIG_MISC_INIT_R=y >> # CONFIG_DISPLAY_CPUINFO is not set >> # CONFIG_DISPLAY_BOARDINFO is not set >> CONFIG_SYS_PROMPT="U-Boot> " >> +CONFIG_CMD_DFU=y >> # CONFIG_CMD_FLASH is not set >> CONFIG_CMD_GPIO=y >> CONFIG_CMD_MMC=y >> @@ -19,6 +20,7 @@ CONFIG_CMD_FS_UUID=y >> CONFIG_ENV_FAT_INTERFACE="mmc" >> CONFIG_ENV_FAT_DEVICE_AND_PART="0:1" >> CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y >> +CONFIG_DFU_MMC=y >> CONFIG_DM_KEYBOARD=y >> CONFIG_DM_MMC=y >> CONFIG_MMC_SDHCI=y >> @@ -26,6 +28,15 @@ CONFIG_MMC_SDHCI_BCM2835=y >> CONFIG_PINCTRL=y >> # CONFIG_PINCTRL_GENERIC is not set >> # CONFIG_REQUIRE_SERIAL_CONSOLE is not set >> +CONFIG_USB=y >> +CONFIG_DM_USB=y >> +CONFIG_DM_USB_GADGET=y >> +CONFIG_USB_GADGET=y >> +CONFIG_USB_GADGET_MANUFACTURER="FSL" >> +CONFIG_USB_GADGET_VENDOR_NUM=0x0525 >> +CONFIG_USB_GADGET_PRODUCT_NUM=0xa4a5 >> +CONFIG_USB_GADGET_DWC2_OTG=y >> +CONFIG_USB_GADGET_DOWNLOAD=y >> CONFIG_DM_VIDEO=y >> CONFIG_SYS_WHITE_ON_BLACK=y >> CONFIG_CONSOLE_SCROLL_LINES=10 >> diff --git a/include/configs/rpi.h b/include/configs/rpi.h >> index 77d2d5458a..bfe76eb392 100644 >> --- a/include/configs/rpi.h >> +++ b/include/configs/rpi.h >> @@ -70,6 +70,22 @@ >> #define CONFIG_TFTP_TSIZE >> #endif >> >> +/* DFU over USB/UDC */ >> +#ifdef CONFIG_CMD_DFU >> +#define CONFIG_SYS_DFU_DATA_BUF_SIZESZ_1M >> +#define CONFIG_SYS_DFU_MAX_FILE_SIZESZ_2M >> + >> +#ifdef CONFIG_ARM64 >> +#define KERNEL_FILENAME "Image.gz" >> +#else >> +#define KERNEL_FILENAME "zImage" >> +#endif >> +#define ENV_DFU_SETTINGS \ >> +"dfu_alt_info=u-boot.bin fat 0 1;uboot.env fat 0 1;" \ >> + "config.txt fat 0 1;cmdline.txt fat 0 1;" \ >> + KERNEL_FILENAME " fat 0 1\0" >> +#endif >> + > I'm hesitant to take this file list as I think it highly depends on what you > want to do with the board. For example at SUSE we use a ubootconfig.txt which > get's added to config.txt. We might want to update grub, our kernel is on a > different partition etc. > > What do you think? Well, the above list is just a proposal. IMHO distro maintainers should adjust it for their needs. I can add a comment about that if you want. > Other then that the patches look good, and I understand that they should go > through my tree, also I don't know much about the FAT implementation. Merging everything via a single tree will be the easiest way to handle the runtime dependencies. Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 6/6] config: enable DFU over USB on Raspberry Pi4 boards
Enable support for DFU over USB. This requires to enable USB gadget, DWC2 UDC OTG driver and DFU command. DFU entities are defined for the following firmware objects: u-boot.bin, uboot.env, config.txt and zImage/Image. Signed-off-by: Marek Szyprowski Reviewed-by: Lukasz Majewski --- Changelog: v3: - fixed non-RPi4 builds (missing #else ENV_DFU_SETTINGS def) - removed config.txt entity (not needed in uboot-based boot) - switched arm64 kernel filename to 'Image' --- configs/rpi_4_32b_defconfig | 11 +++ configs/rpi_4_defconfig | 11 +++ include/configs/rpi.h | 20 3 files changed, 42 insertions(+) diff --git a/configs/rpi_4_32b_defconfig b/configs/rpi_4_32b_defconfig index dc696906fd..a0ba8782bc 100644 --- a/configs/rpi_4_32b_defconfig +++ b/configs/rpi_4_32b_defconfig @@ -11,6 +11,7 @@ CONFIG_MISC_INIT_R=y # CONFIG_DISPLAY_CPUINFO is not set # CONFIG_DISPLAY_BOARDINFO is not set CONFIG_SYS_PROMPT="U-Boot> " +CONFIG_CMD_DFU=y # CONFIG_CMD_FLASH is not set CONFIG_CMD_GPIO=y CONFIG_CMD_MMC=y @@ -19,6 +20,7 @@ CONFIG_OF_BOARD=y CONFIG_ENV_FAT_INTERFACE="mmc" CONFIG_ENV_FAT_DEVICE_AND_PART="0:1" CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y +CONFIG_DFU_MMC=y CONFIG_DM_KEYBOARD=y CONFIG_DM_MMC=y CONFIG_MMC_SDHCI=y @@ -26,6 +28,15 @@ CONFIG_MMC_SDHCI_BCM2835=y CONFIG_PINCTRL=y # CONFIG_PINCTRL_GENERIC is not set # CONFIG_REQUIRE_SERIAL_CONSOLE is not set +CONFIG_USB=y +CONFIG_DM_USB=y +CONFIG_DM_USB_GADGET=y +CONFIG_USB_GADGET=y +CONFIG_USB_GADGET_MANUFACTURER="FSL" +CONFIG_USB_GADGET_VENDOR_NUM=0x0525 +CONFIG_USB_GADGET_PRODUCT_NUM=0xa4a5 +CONFIG_USB_GADGET_DWC2_OTG=y +CONFIG_USB_GADGET_DOWNLOAD=y CONFIG_DM_VIDEO=y CONFIG_SYS_WHITE_ON_BLACK=y CONFIG_CONSOLE_SCROLL_LINES=10 diff --git a/configs/rpi_4_defconfig b/configs/rpi_4_defconfig index 2954e17ac3..2fcd56ebf3 100644 --- a/configs/rpi_4_defconfig +++ b/configs/rpi_4_defconfig @@ -11,6 +11,7 @@ CONFIG_MISC_INIT_R=y # CONFIG_DISPLAY_CPUINFO is not set # CONFIG_DISPLAY_BOARDINFO is not set CONFIG_SYS_PROMPT="U-Boot> " +CONFIG_CMD_DFU=y # CONFIG_CMD_FLASH is not set CONFIG_CMD_GPIO=y CONFIG_CMD_MMC=y @@ -19,6 +20,7 @@ CONFIG_OF_BOARD=y CONFIG_ENV_FAT_INTERFACE="mmc" CONFIG_ENV_FAT_DEVICE_AND_PART="0:1" CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y +CONFIG_DFU_MMC=y CONFIG_DM_KEYBOARD=y CONFIG_DM_MMC=y CONFIG_MMC_SDHCI=y @@ -26,6 +28,15 @@ CONFIG_MMC_SDHCI_BCM2835=y CONFIG_PINCTRL=y # CONFIG_PINCTRL_GENERIC is not set # CONFIG_REQUIRE_SERIAL_CONSOLE is not set +CONFIG_USB=y +CONFIG_DM_USB=y +CONFIG_DM_USB_GADGET=y +CONFIG_USB_GADGET=y +CONFIG_USB_GADGET_MANUFACTURER="FSL" +CONFIG_USB_GADGET_VENDOR_NUM=0x0525 +CONFIG_USB_GADGET_PRODUCT_NUM=0xa4a5 +CONFIG_USB_GADGET_DWC2_OTG=y +CONFIG_USB_GADGET_DOWNLOAD=y CONFIG_DM_VIDEO=y CONFIG_SYS_WHITE_ON_BLACK=y CONFIG_CONSOLE_SCROLL_LINES=10 diff --git a/include/configs/rpi.h b/include/configs/rpi.h index 77d2d5458a..6723c7cc92 100644 --- a/include/configs/rpi.h +++ b/include/configs/rpi.h @@ -70,6 +70,25 @@ #define CONFIG_TFTP_TSIZE #endif +/* DFU over USB/UDC */ +#ifdef CONFIG_CMD_DFU +#define CONFIG_SYS_DFU_DATA_BUF_SIZE SZ_1M +#define CONFIG_SYS_DFU_MAX_FILE_SIZE SZ_2M + +#ifdef CONFIG_ARM64 +#define KERNEL_FILENAME"Image" +#else +#define KERNEL_FILENAME"zImage" +#endif + +#define ENV_DFU_SETTINGS \ + "dfu_alt_info=u-boot.bin fat 0 1;uboot.env fat 0 1;" \ + "config.txt fat 0 1;" \ + KERNEL_FILENAME " fat 0 1\0" +#else +#define ENV_DFU_SETTINGS "" +#endif + /* Console configuration */ #define CONFIG_SYS_CBSIZE 1024 @@ -185,6 +204,7 @@ #define CONFIG_EXTRA_ENV_SETTINGS \ "dhcpuboot=usb start; dhcp u-boot.uimg; bootm\0" \ ENV_DEVICE_SETTINGS \ + ENV_DFU_SETTINGS \ ENV_MEM_LAYOUT_SETTINGS \ BOOTENV -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [RFC PATCH 4/9] rpi4: add a mapping for the PCIe XHCI controller MMIO registers (ARM 64bit)
Hi Nicolas,
On 22.04.2020 11:46, Nicolas Saenz Julienne wrote:
> On Tue, 2020-04-21 at 18:50 +0200, Sylwester Nawrocki wrote:
>> From: Marek Szyprowski
>>
>> Create a non-cacheable mapping for the 0x6 physical memory region,
>> where MMIO registers for the PCIe XHCI controller are instantiated by the
>> PCIe bridge.
>>
>> Signed-off-by: Marek Szyprowski
>> ---
>> arch/arm/mach-bcm283x/init.c | 18 +++---
>> 1 file changed, 15 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/arm/mach-bcm283x/init.c b/arch/arm/mach-bcm283x/init.c
>> index 4295356..6a748da 100644
>> --- a/arch/arm/mach-bcm283x/init.c
>> +++ b/arch/arm/mach-bcm283x/init.c
>> @@ -11,10 +11,15 @@
>> #include
>> #include
>>
>> +#define BCM2711_RPI4_PCIE_XHCI_MMIO_PHYS0x6UL
>> +#define BCM2711_RPI4_PCIE_XHCI_MMIO_SIZE0x80UL
> Where did you got this size from? I read from the Linux device tree the
> following:
>
> pcie0: pcie@7d50 {
> compatible = "brcm,bcm2711-pcie";
> [...]
> ranges = <0x0200 0x0 0xf800 0x6 0x
> 0x0 0x0400>;
> [...]
> };
>
> Shouldn't the size be 0x400 then?
>
> Other than that the patch looks good to me.
Well, I reduced the window to 0x80 to make it fit somewhere nicely
in the 32bit address space. We can limit it even to a single section
(2MiB), that's more than needed by the XHCI controller anyway. I can add
a comment about that.
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
Re: [PATCH] fs: ext4: skip journal state if fs has metadata_csum
On 22.04.2020 12:43, Arnaud Ferraris wrote: > As u-boot doesn't support the metadata_csum feature, writing to a > filesystem with this feature enabled will fail, as expected. However, > during the process, a journal state check is performed, which could > result in: >- a fs recovery if the fs wasn't umounted properly >- the fs being marked dirty > > Both these cases result in a superblock change, leading to a mismatch > between the superblock checksum and its contents. Therefore, Linux will > consider the filesystem heavily corrupted and will require e2fsck to be > run manually to boot. > > By bypassing the journal state check, this patch ensures the superblock > won't be corrupted if the filesystem has metadata_csum feature enabled. > > Signed-off-by: Arnaud Ferraris Acked-by: Marek Szyprowski > --- > > fs/ext4/ext4_journal.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/fs/ext4/ext4_journal.c b/fs/ext4/ext4_journal.c > index 3559daf11d..f8524e5a99 100644 > --- a/fs/ext4/ext4_journal.c > +++ b/fs/ext4/ext4_journal.c > @@ -409,6 +409,9 @@ int ext4fs_check_journal_state(int recovery_flag) > char *temp_buff1 = NULL; > struct ext_filesystem *fs = get_fs(); > > + if (le32_to_cpu(fs->sb->feature_ro_compat) & > EXT4_FEATURE_RO_COMPAT_METADATA_CSUM) > + return 0; > + > temp_buff = zalloc(fs->blksz); > if (!temp_buff) > return -ENOMEM; Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland
Re: [PATCH v1 09/10] pci: Add driver for Broadcom STB PCIe controller
Hi Nicolas, On 27.04.2020 12:15, Nicolas Saenz Julienne wrote: > On Fri, 2020-04-24 at 18:50 +0200, Sylwester Nawrocki wrote: >> This patch adds basic driver for the Broadcom STB PCIe host controller. >> The code is based on Linux upstream driver (pcie-brcmstb.c) with MSI >> handling removed. The inbound access memory region is not currently >> parsed from dma-ranges DT property and a fixed 4GB region is used. >> >> The patch has been tested on RPI4 board, i.e. on BCM2711 SoC with VL805 >> USB Host Controller. >> >> Signed-off-by: Nicolas Saenz Julienne >> Signed-off-by: Sylwester Nawrocki >> --- >> Changes since RFC: >> - reworked to align with current Linux mainline version and u-boot driver >> by Nicolas Saenz Julienne > [...] > >> + >> +/* >> + * TODO: Use the base address and size(s) provided in the dma-ranges >> + * property. >> + */ >> +rc_bar2_offset = 0; >> +rc_bar2_size = 1ULL << 32; > From experience this works fine, although it highly depends on how DMA > memory is > handled in u-boot. > > For example, in arm64 Linux, DMA memory was allocated from ZONE_DMA32, which > would return memory smaller than 4GB. This was not good enough for bcm2711b0 > -- > revision b0 of rpi4's SoC, so far the most common out there -- which has an > internal wiring bug that prevents PCIe from accessing memory higher than 3GB > (RPi4 might have up to 4GB). So we had to introduce a ZONE_DMA, which covers > the lower GB of memory, in order to allocate suitable DMA memory for PCI and > other DMA limited devices. > > While playing around with u-boot's xHCI I saw that all memory is allocated is > located in the lower 1GB. But never got to look into why. I'm curious to know > if someone knows how's that handled in u-boot. Ultimately, depending on how it > works, we might be able to just disregard dma-ranges altogether. > > For some extra context xhci_malloc() gets its memory from memalign(). And it's > not clear to me how that function decides which memory to use. I think that memalign() allocates memory from the uboot's defined SDRAM (from its end). Assuming that CONFIG_SYS_SDRAM_SIZE is set to 128M in include/configs/rpi.h it should be always safe, but I will check that tomorrow to be 100% sure. Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland
Re: [PATCH v1 09/10] pci: Add driver for Broadcom STB PCIe controller
Hi All, On 27.04.2020 15:54, Marek Szyprowski wrote: > On 27.04.2020 12:15, Nicolas Saenz Julienne wrote: >> On Fri, 2020-04-24 at 18:50 +0200, Sylwester Nawrocki wrote: >>> This patch adds basic driver for the Broadcom STB PCIe host controller. >>> The code is based on Linux upstream driver (pcie-brcmstb.c) with MSI >>> handling removed. The inbound access memory region is not currently >>> parsed from dma-ranges DT property and a fixed 4GB region is used. >>> >>> The patch has been tested on RPI4 board, i.e. on BCM2711 SoC with VL805 >>> USB Host Controller. >>> >>> Signed-off-by: Nicolas Saenz Julienne >>> Signed-off-by: Sylwester Nawrocki >>> --- >>> Changes since RFC: >>> - reworked to align with current Linux mainline version and u-boot >>> driver >>> by Nicolas Saenz Julienne >> [...] >> >>> + >>> + /* >>> + * TODO: Use the base address and size(s) provided in the >>> dma-ranges >>> + * property. >>> + */ >>> + rc_bar2_offset = 0; >>> + rc_bar2_size = 1ULL << 32; >> From experience this works fine, although it highly depends on how >> DMA memory is >> handled in u-boot. >> >> For example, in arm64 Linux, DMA memory was allocated from >> ZONE_DMA32, which >> would return memory smaller than 4GB. This was not good enough for >> bcm2711b0 -- >> revision b0 of rpi4's SoC, so far the most common out there -- which >> has an >> internal wiring bug that prevents PCIe from accessing memory higher >> than 3GB >> (RPi4 might have up to 4GB). So we had to introduce a ZONE_DMA, >> which covers >> the lower GB of memory, in order to allocate suitable DMA memory for >> PCI and >> other DMA limited devices. >> >> While playing around with u-boot's xHCI I saw that all memory is >> allocated is >> located in the lower 1GB. But never got to look into why. I'm curious >> to know >> if someone knows how's that handled in u-boot. Ultimately, depending >> on how it >> works, we might be able to just disregard dma-ranges altogether. >> >> For some extra context xhci_malloc() gets its memory from memalign(). >> And it's >> not clear to me how that function decides which memory to use. > > I think that memalign() allocates memory from the uboot's defined > SDRAM (from its end). Assuming that CONFIG_SYS_SDRAM_SIZE is set to > 128M in include/configs/rpi.h it should be always safe, but I will > check that tomorrow to be 100% sure. Okay, I've checked and memalign always get memory from the malloc pool, which is set almost at the end of the first memory bank (in runtime), so it is always below the first 1GiB. So this should be safe. It is however not safe for explicit reads (and possible other transactions) above 3rd GiB, see the log below: Initialising SDRAM 'Samsung' 16Gb x2 total-size: 32 Gbit Loading recovery.elf hnd: 0x Failed to read recovery.elf error: 3 Loading start4x.elf hnd: 0x11de Loading fixup4x.dat hnd: 0x0259 MEM GPU: 76 ARM: 948 TOTAL: 1024 FIXUP src: 128 256 dst: 948 1024 Starting start4x.elf @ 0xfec00200 U-Boot 2020.04-00011-gaefcd8d-dirty (Apr 28 2020 - 10:13:31 +0200) DRAM: 3.9 GiB RPI 4 Model B (0xc03112) MMC: emmc2@7e34: 0, mmcnr@7e30: 1 Loading Environment from FAT... OK In: serial Out: serial Err: serial Net: eth0: genet@7d58 PCIe BRCM: link up, 5.0 Gbps x1 (!SSC) starting USB... Bus Register 5000420 NbrPorts 5 Starting the controller USB XHCI 1.00 scanning bus xhci_pci for devices... 3 USB Device(s) found scanning usb for storage devices... 1 Storage Device(s) found Hit any key to stop autoboot: 0 U-Boot> md 1000 1000: 0400 5402 0200 0300 ...T 1010: 0800 6502 61666564 00746c75 ...edefault. 1020: 0300 0400 5401 0f00 ...T 1030: 0100 5f697064 6f697067 0030 dpi_gpio0... 1040: 0300 7000 7302 ...p...s 1050: 0100 0200 0300 0400 1060: 0500 0600 0700 0800 1070: 0900 0a00 0b00 0c00 1080: 0d00 0e00 0f00 1000 1090: 1100 1200 1300 1400 10a0: 1500 1600 1700 1800 10b0: 1900 1a00 1b00 0300 10c0: 0400 7d02 0600 0300 ...} 10d0: 0400 5401 3900 0200 ...T...9 10e0:
Re: [PATCH] net: ping: reset stored IP once the command finishes
Hi Tom,
On 12.06.2020 18:04, Tom Rini wrote:
> On Wed, Mar 25, 2020 at 02:42:00PM +0100, Marek Szyprowski wrote:
>> Reset stored ping IP address before leaving the netloop to ensure that
>> the subsequent calls to the netloop, especially for the other protocols,
>> won't be interrupted by the received ICMP_ECHO_REPLY packet.
>>
>> Signed-off-by: Marek Szyprowski
>> ---
>> net/ping.c | 5 -
>> 1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/net/ping.c b/net/ping.c
>> index 633c942..d912e3d 100644
>> --- a/net/ping.c
>> +++ b/net/ping.c
>> @@ -63,6 +63,7 @@ static int ping_send(void)
>> static void ping_timeout_handler(void)
>> {
>> eth_halt();
>> +net_ping_ip.s_addr = 0;
>> net_set_state(NETLOOP_FAIL);/* we did not get the reply */
>> }
>>
>> @@ -84,8 +85,10 @@ void ping_receive(struct ethernet_hdr *et, struct
>> ip_udp_hdr *ip, int len)
>> switch (icmph->type) {
>> case ICMP_ECHO_REPLY:
>> src_ip = net_read_ip((void *)&ip->ip_src);
>> -if (src_ip.s_addr == net_ping_ip.s_addr)
>> +if (src_ip.s_addr == net_ping_ip.s_addr) {
>> +net_ping_ip.s_addr = 0;
>> net_set_state(NETLOOP_SUCCESS);
>> +}
>> return;
>> case ICMP_ECHO_REQUEST:
>> eth_hdr_size = net_update_ether(et, et->et_src, PROT_IP);
> This breaks a number of tests in test/dm/eth.c. Can you please adjust
> the tests as well to not rely on the behavior you're fixing? Thanks!
I've checked and it turned out that it is not possible to fix the
net_retry test. It clearly shows that the net_retry feature relies on
the fact that the state machine of the net related commands are
preserved between the calls.
I wonder how to fix this without breaking the netretry feature. The only
solution I see is to clear net_ping_ip at the beginning of the
net_loop() if the protocol is not equal to PING. Quite ugly...
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
[PATCH v2] net: ping: reset stored IP address
Reset the stored ping IP address before entering a netloop with different protocol to ensure that it won't be interrupted by the received correct ICMP_ECHO_REPLY packet. Signed-off-by: Marek Szyprowski --- v2: - Moved the net_ping_ip reset to the beginning of the net_loop() if the protocol is not equal to PING. This is required, because the netretry feature of the network framework relies on the fact that the internal state of the commands is preserved between net_loop() calls. v1: https://patchwork.ozlabs.org/project/uboot/patch/20200325134200.18959-1-m.szyprow...@samsung.com/ - Initial version --- net/net.c | 4 1 file changed, 4 insertions(+) diff --git a/net/net.c b/net/net.c index 37932919d04..72b445774f9 100644 --- a/net/net.c +++ b/net/net.c @@ -409,6 +409,10 @@ int net_loop(enum proto_t protocol) int ret = -EINVAL; enum net_loop_state prev_net_state = net_state; +#if defined(CONFIG_CMD_PING) + if (protocol != PING) + net_ping_ip.s_addr = 0; +#endif net_restarted = 0; net_dev_exists = 0; net_try_count = 1; -- 2.17.1
Re: [PATCH v5 3/6] arm: provide a function for boards init code to modify MMU virtual-physical map
Hi Patrick,
On 23.07.2020 18:32, Patrick DELAUNAY wrote:
> Hi Marek,
>
>> From: U-Boot On Behalf Of Tom Rini
>> Sent: vendredi 10 juillet 2020 22:22
>>
>> On Wed, Jun 03, 2020 at 02:43:42PM +0200, Marek Szyprowski wrote:
>>
>>> Provide function for setting arbitrary virtual-physical MMU mapping
>>> and cache settings for the given region.
>>>
>>> Signed-off-by: Marek Szyprowski
>>> Reviewed-by: Tom Rini
>> Applied to u-boot/master, thanks!
> For information, this patch break the SPL boot on stm32mp1 platform in master
> branch.
>
> It is linked to commit 7e8471cae5c6614c54b9cfae2746d7299bd47a0c
> ("arm: stm32mp: activate data cache in SPL and before relocation")
>
> For the lines:
>
> + mmu_set_region_dcache_behaviour(STM32_SYSRAM_BASE,
> + STM32_SYSRAM_SIZE,
> + DCACHE_DEFAULT_OPTION);
>
> In this patch, the STM32MP15x activate the DACACHE on SYSRAM with:
>
> #define STM32_SYSRAM_BASE 0x2FFC
> #define STM32_SYSRAM_SIZE SZ_256K
>
> Even is this address is not MMU_SECTION_SIZE aligned, the configuration of
> the MMU
> section was correctly aligned in set_section_dcache
>
> - value |= ((u32)section << MMU_SECTION_SHIFT);
>
> With caller :
>
> void mmu_set_region_dcache_behaviour (
> .
> /* div by 2 before start + size to avoid phys_addr_t overflow */
> end = ALIGN((start / 2) + (size / 2), MMU_SECTION_SIZE / 2)
> >> (MMU_SECTION_SHIFT - 1);
> start = start >> MMU_SECTION_SHIFT;
>
> - for (upto = start; upto < end; upto++)
> - set_section_dcache(upto, option);
>
>
> But today it it no more the case when the start address is not MMU_SIZE
> aligned.
>
> void mmu_set_region_dcache_behaviour(phys_addr_t start, size_t size,
>enum dcache_option option)
> {
> mmu_set_region_dcache_behaviour_phys(start, start, size, option);
> }
>
> 'start' parameter is directly used in 'phys' address in the next function:
>
> void mmu_set_region_dcache_behaviour_phys(phys_addr_t start, phys_addr_t phys,
> size_t size, enum dcache_option option)
> {
> .
> for (upto = start; upto < end; upto++, phys += MMU_SECTION_SIZE)
> set_section_phys(upto, phys, option);
>
>
> and then
>
> static void set_section_phys(int section, phys_addr_t phys,
>enum dcache_option option)
> {
>
>
> /* Add the page offset */
> value |= phys;
>
>
> So today I can solve my issue, if I align the section in my code:
>
> if (IS_ENABLED(CONFIG_SPL_BUILD))
> - mmu_set_region_dcache_behaviour(STM32_SYSRAM_BASE,
> - STM32_SYSRAM_SIZE,
> - DCACHE_DEFAULT_OPTION);
> + mmu_set_region_dcache_behaviour(
> + ALIGN(STM32_SYSRAM_BASE, MMU_SECTION_SIZE),
> + round_up(STM32_SYSRAM_SIZE, MMU_SECTION_SIZE),
> + DCACHE_DEFAULT_OPTION);
> else
>
> But I just concerned that this lib behavior is really unexpected: need to
> provided MMU_SIZE aligned
> start address when mmu_set_region_dcache_behaviour is called.
>
> Do you think we need to restore the previous behavior of the cp15 function
> mmu_set_region_dcache_behaviour() ?
> => internally aligned DACHE region on MMU_SECTION_SIZE when parameters, start
> or size, are not aligned.
>
> See also explanation for other use case, and start / end / size usage
> http://patchwork.ozlabs.org/project/uboot/patch/20200424201957.v2.3.Ic2c7c6923035711a4c653d52ae7c0f57ca6f9210@changeid/
I'm sorry for breaking your setup. However IMHO the caller should ensure
that the parameters are correctly aligned. The old behavior modified
cache parameters on the larger area of the memory than the called
wanted, what might lead to some side-effects. I would prefer aligning
parameters in the callers and maybe add some comment to the function
description that it assumes that the parameters are properly aligned.
Adding a check for the proper alignment is a bit useless, because
usually this function is called so early, that no message can be printed.
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
Re: [PATCH v2] arm: exynos: Read default MMC device from XOM[7:5] pins
Hi Minkyu,
On 23.01.2020 08:09, Minkyu Kang wrote:
> On 17/01/2020 22:02, Marek Szyprowski wrote:
>> XOM pins provide information for iROM bootloader about the boot device.
>> Those pins are mapped to lower bits of OP_MODE register (0x1008),
>> which is common for all Exynos SoC variants. Set the default MMC device id
>> to reflect the boot device selected by XOM[7:5] pins (2 for the SD or 0 for
>> the eMMC).
>>
>> Signed-off-by: Marek Szyprowski
>> ---
>> v2:
>> - store mmc boot device to ${mmcbootdev} env
>> - print information about boot mmc device
>> ---
>> arch/arm/mach-exynos/include/mach/cpu.h | 1 +
>> board/samsung/common/board.c| 28 +
>> configs/odroid-xu3_defconfig| 1 +
>> configs/odroid_defconfig| 1 +
>> 4 files changed, 31 insertions(+)
>>
>> diff --git a/arch/arm/mach-exynos/include/mach/cpu.h
>> b/arch/arm/mach-exynos/include/mach/cpu.h
>> index 766edeeb29..fb5fdaf3ba 100644
>> --- a/arch/arm/mach-exynos/include/mach/cpu.h
>> +++ b/arch/arm/mach-exynos/include/mach/cpu.h
>> @@ -17,6 +17,7 @@
>>
>> #define EXYNOS4_GPIO_PART3_BASE0x0386
>> #define EXYNOS4_PRO_ID 0x1000
>> +#define EXYNOS4_OP_MODE 0x1008
>> #define EXYNOS4_SYSREG_BASE0x1001
>> #define EXYNOS4_POWER_BASE 0x1002
>> #define EXYNOS4_SWRESET0x10020400
>> diff --git a/board/samsung/common/board.c b/board/samsung/common/board.c
>> index ee2fc7971e..cb94ced54e 100644
>> --- a/board/samsung/common/board.c
>> +++ b/board/samsung/common/board.c
>> @@ -24,6 +24,8 @@
>> #include
>> #include
>> #include
>> +#include
>> +#include
>> #include
>> #include
>> #include
>> @@ -42,6 +44,20 @@ __weak int exynos_power_init(void)
>> return 0;
>> }
>>
>> +/**
>> + * get_boot_mmc_dev() - read boot MMC device id from XOM[7:5] pins.
>> + */
>> +static int get_boot_mmc_dev(void)
>> +{
>> +u32 mode = readl(EXYNOS4_OP_MODE) & 0x1C;
>> +
>> +if (mode == 0x04)
>> +return 2; /* MMC2: SD */
>> +
>> +/* MMC0: eMMC or unknown */
>> +return 0;
>> +}
>> +
>> #if defined CONFIG_EXYNOS_TMU
>> /* Boot Time Thermal Analysis for SoC temperature threshold breach */
>> static void boot_temp_check(void)
>> @@ -280,6 +296,8 @@ int board_late_init(void)
>> {
>> struct udevice *dev;
>> int ret;
>> +int mmcbootdev = get_boot_mmc_dev();
>> +char mmcbootdev_str[16];
>>
>> stdio_print_current_devices();
>> ret = uclass_first_device_err(UCLASS_CROS_EC, &dev);
>> @@ -292,6 +310,11 @@ int board_late_init(void)
>> panic("Cannot init cros-ec device");
>> return -1;
>> }
>> +
>> +printf("Boot device: MMC(%u)\n", mmcbootdev);
>> +sprintf(mmcbootdev_str, "%u", mmcbootdev);
>> +env_set("mmcbootdev", mmcbootdev_str);
>> +
>> return 0;
>> }
>> #endif
>> @@ -359,3 +382,8 @@ int board_usb_cleanup(int index, enum usb_init_type init)
>> #endif
>> return 0;
>> }
>> +
>> +int mmc_get_env_dev(void)
>> +{
>> +return get_boot_mmc_dev();
>> +}
>> diff --git a/configs/odroid-xu3_defconfig b/configs/odroid-xu3_defconfig
>> index 20038d4197..2e982e1b53 100644
>> --- a/configs/odroid-xu3_defconfig
>> +++ b/configs/odroid-xu3_defconfig
>> @@ -14,6 +14,7 @@ CONFIG_FIT_BEST_MATCH=y
>> CONFIG_SILENT_CONSOLE=y
>> CONFIG_CONSOLE_MUX=y
>> CONFIG_MISC_INIT_R=y
>> +CONFIG_BOARD_LATE_INIT=y
> Is it a related change?
Yes, it is needed to enable the code added to board_late_init() function.
>> # CONFIG_DISPLAY_BOARDINFO is not set
>> CONFIG_DISPLAY_BOARDINFO_LATE=y
>> CONFIG_BOARD_TYPES=y
>> diff --git a/configs/odroid_defconfig b/configs/odroid_defconfig
>> index be914e4caf..e4392e477e 100644
>> --- a/configs/odroid_defconfig
>> +++ b/configs/odroid_defconfig
>> @@ -17,6 +17,7 @@ CONFIG_BOOTARGS="Please use defined boot"
>> CONFIG_SYS_CONSOLE_IS_IN_ENV=y
>> CONFIG_SYS_CONSOLE_INFO_QUIET=y
>> CONFIG_MISC_INIT_R=y
>> +CONFIG_BOARD_LATE_INIT=y
>> CONFIG_BOARD_TYPES=y
>> CONFIG_SYS_PROMPT="Odroid # "
>> # CONFIG_CMD_XIMG is not set
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
Re: [PATCH v2] arm: exynos: Read default MMC device from XOM[7:5] pins
Hi
On 23.01.2020 08:33, Minkyu Kang wrote:
> On 23/01/2020 16:20, Marek Szyprowski wrote:
>> On 23.01.2020 08:09, Minkyu Kang wrote:
>>> On 17/01/2020 22:02, Marek Szyprowski wrote:
>>>> XOM pins provide information for iROM bootloader about the boot device.
>>>> Those pins are mapped to lower bits of OP_MODE register (0x1008),
>>>> which is common for all Exynos SoC variants. Set the default MMC device id
>>>> to reflect the boot device selected by XOM[7:5] pins (2 for the SD or 0 for
>>>> the eMMC).
>>>>
>>>> Signed-off-by: Marek Szyprowski
>>>> ---
>>>> v2:
>>>> - store mmc boot device to ${mmcbootdev} env
>>>> - print information about boot mmc device
>>>> ---
>>>>arch/arm/mach-exynos/include/mach/cpu.h | 1 +
>>>>board/samsung/common/board.c| 28 +
>>>>configs/odroid-xu3_defconfig| 1 +
>>>>configs/odroid_defconfig| 1 +
>>>>4 files changed, 31 insertions(+)
>>>>
>>>> diff --git a/arch/arm/mach-exynos/include/mach/cpu.h
>>>> b/arch/arm/mach-exynos/include/mach/cpu.h
>>>> index 766edeeb29..fb5fdaf3ba 100644
>>>> --- a/arch/arm/mach-exynos/include/mach/cpu.h
>>>> +++ b/arch/arm/mach-exynos/include/mach/cpu.h
>>>> @@ -17,6 +17,7 @@
>>>>
>>>>#define EXYNOS4_GPIO_PART3_BASE 0x0386
>>>>#define EXYNOS4_PRO_ID 0x1000
>>>> +#define EXYNOS4_OP_MODE 0x1008
>>>>#define EXYNOS4_SYSREG_BASE 0x1001
>>>>#define EXYNOS4_POWER_BASE 0x1002
>>>>#define EXYNOS4_SWRESET 0x10020400
>>>> diff --git a/board/samsung/common/board.c b/board/samsung/common/board.c
>>>> index ee2fc7971e..cb94ced54e 100644
>>>> --- a/board/samsung/common/board.c
>>>> +++ b/board/samsung/common/board.c
>>>> @@ -24,6 +24,8 @@
>>>>#include
>>>>#include
>>>>#include
>>>> +#include
>>>> +#include
>>>>#include
>>>>#include
>>>>#include
>>>> @@ -42,6 +44,20 @@ __weak int exynos_power_init(void)
>>>>return 0;
>>>>}
>>>>
>>>> +/**
>>>> + * get_boot_mmc_dev() - read boot MMC device id from XOM[7:5] pins.
>>>> + */
>>>> +static int get_boot_mmc_dev(void)
>>>> +{
>>>> + u32 mode = readl(EXYNOS4_OP_MODE) & 0x1C;
>>>> +
>>>> + if (mode == 0x04)
>>>> + return 2; /* MMC2: SD */
>>>> +
>>>> + /* MMC0: eMMC or unknown */
>>>> + return 0;
>>>> +}
>>>> +
>>>>#if defined CONFIG_EXYNOS_TMU
>>>>/* Boot Time Thermal Analysis for SoC temperature threshold breach */
>>>>static void boot_temp_check(void)
>>>> @@ -280,6 +296,8 @@ int board_late_init(void)
>>>>{
>>>>struct udevice *dev;
>>>>int ret;
>>>> + int mmcbootdev = get_boot_mmc_dev();
>>>> + char mmcbootdev_str[16];
>>>>
>>>>stdio_print_current_devices();
>>>>ret = uclass_first_device_err(UCLASS_CROS_EC, &dev);
>>>> @@ -292,6 +310,11 @@ int board_late_init(void)
>>>>panic("Cannot init cros-ec device");
>>>>return -1;
>>>>}
>>>> +
>>>> + printf("Boot device: MMC(%u)\n", mmcbootdev);
>>>> + sprintf(mmcbootdev_str, "%u", mmcbootdev);
>>>> + env_set("mmcbootdev", mmcbootdev_str);
>>>> +
>>>>return 0;
>>>>}
>>>>#endif
>>>> @@ -359,3 +382,8 @@ int board_usb_cleanup(int index, enum usb_init_type
>>>> init)
>>>>#endif
>>>>return 0;
>>>>}
>>>> +
>>>> +int mmc_get_env_dev(void)
>>>> +{
>>>> + return get_boot_mmc_dev();
>>>> +}
>>>> diff --git a/configs/odroid-xu3_defconfig b/configs/odroid-xu3_defconfig
>>>> index 20038d4197..2e982e1b53 100644
>>>> --- a/configs/odroid-xu3_defconfig
>>>> +++ b/configs/odroid-xu3_defconfig
>>>> @@ -14,6 +14,7 @@ CONFIG_FIT_BEST_MATCH=y
>>>>CONFIG_SILENT_CONSOLE=y
>>>>CONFIG_CONSOLE_MUX=y
>>>>CONFIG_MISC_INIT_R=y
>>>> +CONFIG_BOARD_LATE_INIT=y
>>> Is it a related change?
>> Yes, it is needed to enable the code added to board_late_init() function.
> I mean, is your changes should located to board_late_init?
Setting mmcbootdev env is being done in board_late_init() (see the diff
a few lines above), so to make it working, one has to enable
CONFIG_BOARD_LATE_INIT.
>>>># CONFIG_DISPLAY_BOARDINFO is not set
>>>>CONFIG_DISPLAY_BOARDINFO_LATE=y
>>>>CONFIG_BOARD_TYPES=y
>>>> diff --git a/configs/odroid_defconfig b/configs/odroid_defconfig
>>>> index be914e4caf..e4392e477e 100644
>>>> --- a/configs/odroid_defconfig
>>>> +++ b/configs/odroid_defconfig
>>>> @@ -17,6 +17,7 @@ CONFIG_BOOTARGS="Please use defined boot"
>>>>CONFIG_SYS_CONSOLE_IS_IN_ENV=y
>>>>CONFIG_SYS_CONSOLE_INFO_QUIET=y
>>>>CONFIG_MISC_INIT_R=y
>>>> +CONFIG_BOARD_LATE_INIT=y
>>>>CONFIG_BOARD_TYPES=y
>>>>CONFIG_SYS_PROMPT="Odroid # "
>>>># CONFIG_CMD_XIMG is not set
>>>>
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
[PATCH] arm: exynos: Use proper ADC device name
Since commit 4213609cc7 ("drivers: core: use strcmp when find device by
name") one has to provide full name to get requested object. Fix the code
used to detect Odroid board revision to use proper ADC device name then.
Signed-off-by: Marek Szyprowski
---
board/samsung/common/exynos5-dt-types.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/board/samsung/common/exynos5-dt-types.c
b/board/samsung/common/exynos5-dt-types.c
index 516c32923e..d51cc4eedc 100644
--- a/board/samsung/common/exynos5-dt-types.c
+++ b/board/samsung/common/exynos5-dt-types.c
@@ -67,7 +67,7 @@ static int odroid_get_adc_val(unsigned int *adcval)
unsigned int adcval_prev = 0;
int ret, retries = 20;
- ret = adc_channel_single_shot("adc", CONFIG_ODROID_REV_AIN,
+ ret = adc_channel_single_shot("adc@12D1", CONFIG_ODROID_REV_AIN,
&adcval_prev);
if (ret)
return ret;
@@ -75,8 +75,8 @@ static int odroid_get_adc_val(unsigned int *adcval)
while (retries--) {
mdelay(5);
- ret = adc_channel_single_shot("adc", CONFIG_ODROID_REV_AIN,
- adcval);
+ ret = adc_channel_single_shot("adc@12D1",
+ CONFIG_ODROID_REV_AIN, adcval);
if (ret)
return ret;
--
2.17.1
[PATCH] arm: exynos: Read default MMC device from XOM[7:5] pins
XOM pins provide information for iROM bootloader about the boot device.
Those pins are mapped to lower bits of OP_MODE register (0x1008),
which is common for all Exynos SoC variants. Set the default MMC device id
to reflect the boot device selected by XOM[7:5] pins (2 for the SD or 0 for
the eMMC).
Signed-off-by: Marek Szyprowski
---
arch/arm/mach-exynos/include/mach/cpu.h | 1 +
board/samsung/common/board.c| 14 ++
2 files changed, 15 insertions(+)
diff --git a/arch/arm/mach-exynos/include/mach/cpu.h
b/arch/arm/mach-exynos/include/mach/cpu.h
index 766edeeb29..fb5fdaf3ba 100644
--- a/arch/arm/mach-exynos/include/mach/cpu.h
+++ b/arch/arm/mach-exynos/include/mach/cpu.h
@@ -17,6 +17,7 @@
#define EXYNOS4_GPIO_PART3_BASE0x0386
#define EXYNOS4_PRO_ID 0x1000
+#define EXYNOS4_OP_MODE0x1008
#define EXYNOS4_SYSREG_BASE0x1001
#define EXYNOS4_POWER_BASE 0x1002
#define EXYNOS4_SWRESET0x10020400
diff --git a/board/samsung/common/board.c b/board/samsung/common/board.c
index ee2fc7971e..ac91c0a6fb 100644
--- a/board/samsung/common/board.c
+++ b/board/samsung/common/board.c
@@ -359,3 +359,17 @@ int board_usb_cleanup(int index, enum usb_init_type init)
#endif
return 0;
}
+
+/**
+ * mmc_get_env_dev() - read boot MMC device id from XOM[7:5] pins.
+ */
+int mmc_get_env_dev(void)
+{
+ u32 mode = readl(EXYNOS4_OP_MODE) & 0x1C;
+
+ if (mode == 0x04)
+ return 2; /* MMC2: SD */
+
+ /* MMC0: eMMC or unknown */
+ return 0;
+}
--
2.17.1
[PATCH] arm: exynos: Use proper PMIC device name
Since commit 4213609cc7 ("drivers: core: use strcmp when find device by
name") one has to provide full name to get requested object. Fix the code
used to detect enable power regulators on Odroid boards to use proper PMIC
device device name then.
Signed-off-by: Marek Szyprowski
---
board/samsung/common/exynos5-dt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/board/samsung/common/exynos5-dt.c
b/board/samsung/common/exynos5-dt.c
index 87eb381345..c5e77480f5 100644
--- a/board/samsung/common/exynos5-dt.c
+++ b/board/samsung/common/exynos5-dt.c
@@ -64,7 +64,7 @@ int exynos_power_init(void)
int ret;
#ifdef CONFIG_PMIC_S2MPS11
- ret = pmic_get("s2mps11_pmic", &dev);
+ ret = pmic_get("s2mps11_pmic@66", &dev);
#else
ret = pmic_get("max77686", &dev);
if (!ret) {
--
2.17.1
[PATCH] arm: dts: exynos: Extend board description
u-boot uses the same DTS for the all Odroid XU3-based boards, so list
them in the model description to let user know that those boards are
supported.
Signed-off-by: Marek Szyprowski
---
arch/arm/dts/exynos5422-odroidxu3.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/dts/exynos5422-odroidxu3.dts
b/arch/arm/dts/exynos5422-odroidxu3.dts
index 6df6be9181..256df6d6c2 100644
--- a/arch/arm/dts/exynos5422-odroidxu3.dts
+++ b/arch/arm/dts/exynos5422-odroidxu3.dts
@@ -10,7 +10,7 @@
#include "exynos54xx.dtsi"
/ {
- model = "Odroid XU3 based on EXYNOS5422";
+ model = "Odroid XU3/XU4/HC1/HC2 based on Exynos5422";
compatible = "samsung,odroidxu3", "samsung,exynos5";
aliases {
--
2.17.1
[PATCH v2] arm: exynos: Use proper PMIC device name
Since commit 4213609cc7 ("drivers: core: use strcmp when find device by
name") one has to provide full name to get requested object. Fix the code
used to detect enable power regulators on Odroid boards to use proper PMIC
device device name then.
Signed-off-by: Marek Szyprowski
Reviewed-by: Anand Moon
---
board/samsung/common/exynos5-dt-types.c | 2 +-
board/samsung/common/exynos5-dt.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/board/samsung/common/exynos5-dt-types.c
b/board/samsung/common/exynos5-dt-types.c
index d51cc4eedc..31e23e8b07 100644
--- a/board/samsung/common/exynos5-dt-types.c
+++ b/board/samsung/common/exynos5-dt-types.c
@@ -129,7 +129,7 @@ static const char *odroid_get_type_str(void)
if (gd->board_type != EXYNOS5_BOARD_ODROID_XU3_REV02)
goto exit;
- ret = pmic_get("s2mps11", &dev);
+ ret = pmic_get("s2mps11_pmic@66", &dev);
if (ret)
goto exit;
diff --git a/board/samsung/common/exynos5-dt.c
b/board/samsung/common/exynos5-dt.c
index 87eb381345..c5e77480f5 100644
--- a/board/samsung/common/exynos5-dt.c
+++ b/board/samsung/common/exynos5-dt.c
@@ -64,7 +64,7 @@ int exynos_power_init(void)
int ret;
#ifdef CONFIG_PMIC_S2MPS11
- ret = pmic_get("s2mps11_pmic", &dev);
+ ret = pmic_get("s2mps11_pmic@66", &dev);
#else
ret = pmic_get("max77686", &dev);
if (!ret) {
--
2.17.1
[PATCH v3] arm: exynos: Use proper PMIC device names
Since commit 4213609cc7 ("drivers: core: use strcmp when find device by
name") one has to provide full name to get requested object. Fix the code
used to detect enable power regulators on the supported Exynos boards to
use proper PMIC device device name then.
Signed-off-by: Marek Szyprowski
Reviewed-by: Anand Moon
Reviewed-by: Lukasz Majewski
---
v3:
- Fixed max77686 and s5m8767 PMIC too
---
board/samsung/common/exynos5-dt-types.c | 2 +-
board/samsung/common/exynos5-dt.c | 6 +++---
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/board/samsung/common/exynos5-dt-types.c
b/board/samsung/common/exynos5-dt-types.c
index d51cc4eedc..1413dc8978 100644
--- a/board/samsung/common/exynos5-dt-types.c
+++ b/board/samsung/common/exynos5-dt-types.c
@@ -129,7 +129,7 @@ static const char *odroid_get_type_str(void)
if (gd->board_type != EXYNOS5_BOARD_ODROID_XU3_REV02)
goto exit;
- ret = pmic_get("s2mps11", &dev);
+ ret = pmic_get("s2mps11_pmic@66", &dev);
if (ret)
goto exit;
diff --git a/board/samsung/common/exynos5-dt.c
b/board/samsung/common/exynos5-dt.c
index 387d1b9180..eef46b0dc4 100644
--- a/board/samsung/common/exynos5-dt.c
+++ b/board/samsung/common/exynos5-dt.c
@@ -65,9 +65,9 @@ int exynos_power_init(void)
int ret;
#ifdef CONFIG_PMIC_S2MPS11
- ret = pmic_get("s2mps11_pmic", &dev);
+ ret = pmic_get("s2mps11_pmic@66", &dev);
#else
- ret = pmic_get("max77686", &dev);
+ ret = pmic_get("max77686_pmic@09", &dev);
if (!ret) {
/* TODO(s...@chromium.org): Move into the clock/pmic API */
ret = pmic_clrsetbits(dev, MAX77686_REG_PMIC_32KHZ, 0,
@@ -79,7 +79,7 @@ int exynos_power_init(void)
if (ret)
return ret;
} else {
- ret = pmic_get("s5m8767-pmic", &dev);
+ ret = pmic_get("s5m8767_pmic@66", &dev);
/* TODO(s...@chromium.org): Use driver model to access clock */
#ifdef CONFIG_PMIC_S5M8767
if (!ret)
--
2.17.1
[PATCH 1/3] mmc: s5p_sdhci: Read generic MMC properties from DT
Read generic MMC properties from device-tree. This allows to specify for example cd-inverted property and let MMC core to properly handle such case. Signed-off-by: Marek Szyprowski --- drivers/mmc/s5p_sdhci.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/mmc/s5p_sdhci.c b/drivers/mmc/s5p_sdhci.c index 53efa968cf..b5fe828dd6 100644 --- a/drivers/mmc/s5p_sdhci.c +++ b/drivers/mmc/s5p_sdhci.c @@ -204,8 +204,13 @@ static int s5p_sdhci_probe(struct udevice *dev) if (ret) return ret; + ret = mmc_of_parse(dev, &plat->cfg); + if (ret) + return ret; + host->mmc = &plat->mmc; host->mmc->dev = dev; + ret = sdhci_setup_cfg(&plat->cfg, host, 0, 40); if (ret) return ret; -- 2.17.1
[PATCH 3/3] arm: dts: exynos: Use common alias for Odroid U3/X2 MMC2 (SD-card)
Use MMC0 for eMMC and MMC2 for SD-card as other Exynos-based boards do.
This allows to use common code to get MMC device id based on the XOM[7:5]
pins.
Signed-off-by: Marek Szyprowski
---
arch/arm/dts/exynos4412-odroid.dts | 2 +-
include/configs/odroid.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/dts/exynos4412-odroid.dts
b/arch/arm/dts/exynos4412-odroid.dts
index e6c7222755..ce08e8dc1e 100644
--- a/arch/arm/dts/exynos4412-odroid.dts
+++ b/arch/arm/dts/exynos4412-odroid.dts
@@ -17,7 +17,7 @@
serial0 = "/serial@1380";
console = "/serial@1381";
mmc0 = &mshc_0;
- mmc1 = &sdhci2;
+ mmc2 = &sdhci2;
};
serial@1381 {
diff --git a/include/configs/odroid.h b/include/configs/odroid.h
index 77fca32fca..7989fb29d1 100644
--- a/include/configs/odroid.h
+++ b/include/configs/odroid.h
@@ -80,7 +80,7 @@
"tzsw raw 0x83f 0x138\0"
#define BOOT_TARGET_DEVICES(func) \
- func(MMC, mmc, 1) \
+ func(MMC, mmc, 2) \
func(MMC, mmc, 0)
#include
--
2.17.1
[PATCH 0/3] Fix Odroid U3/X2 SD-card boot
Hi All This patchset restores booting from SD-card on Exynos4412-based Odroid U3/X2 boards. It relies on the Exynos MMC device id auto-dectection and PMIC device name fixes: https://patchwork.ozlabs.org/patch/1223558/ https://patchwork.ozlabs.org/patch/1224228/ Best regards Marek Szyprowski Samsung R&D Institute Poland Patch summary: Marek Szyprowski (3): mmc: s5p_sdhci: Read generic MMC properties from DT arm: dts: exynos: Fix card-detect polarity for SD card on Odroid U3/X2 arm: dts: exynos: Use common alias for Odroid U3/X2 MMC2 (SD-card) arch/arm/dts/exynos4412-odroid.dts | 3 ++- drivers/mmc/s5p_sdhci.c| 5 + include/configs/odroid.h | 2 +- 3 files changed, 8 insertions(+), 2 deletions(-) -- 2.17.1
[PATCH 2/3] arm: dts: exynos: Fix card-detect polarity for SD card on Odroid U3/X2
Card detect line for SD-card on Odroid U3/X2 boards are active low, so
add cd-inverted property to indicate this, as u-boot's GPIO driver doesn't
support specifying line polarity. This restores S5P_SDHCI driver operation
on Odroid U3/X2 boards.
Signed-off-by: Marek Szyprowski
---
arch/arm/dts/exynos4412-odroid.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/dts/exynos4412-odroid.dts
b/arch/arm/dts/exynos4412-odroid.dts
index cc8e0dd041..e6c7222755 100644
--- a/arch/arm/dts/exynos4412-odroid.dts
+++ b/arch/arm/dts/exynos4412-odroid.dts
@@ -236,6 +236,7 @@
&sdhci2 {
samsung,bus-width = <4>;
samsung,timing = <1 2 3>;
+ cd-inverted;
cd-gpios = <&gpk2 2 0>;
status = "okay";
};
--
2.17.1
[PATCH v2] arm: exynos: Read default MMC device from XOM[7:5] pins
XOM pins provide information for iROM bootloader about the boot device.
Those pins are mapped to lower bits of OP_MODE register (0x1008),
which is common for all Exynos SoC variants. Set the default MMC device id
to reflect the boot device selected by XOM[7:5] pins (2 for the SD or 0 for
the eMMC).
Signed-off-by: Marek Szyprowski
---
v2:
- store mmc boot device to ${mmcbootdev} env
- print information about boot mmc device
---
arch/arm/mach-exynos/include/mach/cpu.h | 1 +
board/samsung/common/board.c| 28 +
configs/odroid-xu3_defconfig| 1 +
configs/odroid_defconfig| 1 +
4 files changed, 31 insertions(+)
diff --git a/arch/arm/mach-exynos/include/mach/cpu.h
b/arch/arm/mach-exynos/include/mach/cpu.h
index 766edeeb29..fb5fdaf3ba 100644
--- a/arch/arm/mach-exynos/include/mach/cpu.h
+++ b/arch/arm/mach-exynos/include/mach/cpu.h
@@ -17,6 +17,7 @@
#define EXYNOS4_GPIO_PART3_BASE0x0386
#define EXYNOS4_PRO_ID 0x1000
+#define EXYNOS4_OP_MODE0x1008
#define EXYNOS4_SYSREG_BASE0x1001
#define EXYNOS4_POWER_BASE 0x1002
#define EXYNOS4_SWRESET0x10020400
diff --git a/board/samsung/common/board.c b/board/samsung/common/board.c
index ee2fc7971e..cb94ced54e 100644
--- a/board/samsung/common/board.c
+++ b/board/samsung/common/board.c
@@ -24,6 +24,8 @@
#include
#include
#include
+#include
+#include
#include
#include
#include
@@ -42,6 +44,20 @@ __weak int exynos_power_init(void)
return 0;
}
+/**
+ * get_boot_mmc_dev() - read boot MMC device id from XOM[7:5] pins.
+ */
+static int get_boot_mmc_dev(void)
+{
+ u32 mode = readl(EXYNOS4_OP_MODE) & 0x1C;
+
+ if (mode == 0x04)
+ return 2; /* MMC2: SD */
+
+ /* MMC0: eMMC or unknown */
+ return 0;
+}
+
#if defined CONFIG_EXYNOS_TMU
/* Boot Time Thermal Analysis for SoC temperature threshold breach */
static void boot_temp_check(void)
@@ -280,6 +296,8 @@ int board_late_init(void)
{
struct udevice *dev;
int ret;
+ int mmcbootdev = get_boot_mmc_dev();
+ char mmcbootdev_str[16];
stdio_print_current_devices();
ret = uclass_first_device_err(UCLASS_CROS_EC, &dev);
@@ -292,6 +310,11 @@ int board_late_init(void)
panic("Cannot init cros-ec device");
return -1;
}
+
+ printf("Boot device: MMC(%u)\n", mmcbootdev);
+ sprintf(mmcbootdev_str, "%u", mmcbootdev);
+ env_set("mmcbootdev", mmcbootdev_str);
+
return 0;
}
#endif
@@ -359,3 +382,8 @@ int board_usb_cleanup(int index, enum usb_init_type init)
#endif
return 0;
}
+
+int mmc_get_env_dev(void)
+{
+ return get_boot_mmc_dev();
+}
diff --git a/configs/odroid-xu3_defconfig b/configs/odroid-xu3_defconfig
index 20038d4197..2e982e1b53 100644
--- a/configs/odroid-xu3_defconfig
+++ b/configs/odroid-xu3_defconfig
@@ -14,6 +14,7 @@ CONFIG_FIT_BEST_MATCH=y
CONFIG_SILENT_CONSOLE=y
CONFIG_CONSOLE_MUX=y
CONFIG_MISC_INIT_R=y
+CONFIG_BOARD_LATE_INIT=y
# CONFIG_DISPLAY_BOARDINFO is not set
CONFIG_DISPLAY_BOARDINFO_LATE=y
CONFIG_BOARD_TYPES=y
diff --git a/configs/odroid_defconfig b/configs/odroid_defconfig
index be914e4caf..e4392e477e 100644
--- a/configs/odroid_defconfig
+++ b/configs/odroid_defconfig
@@ -17,6 +17,7 @@ CONFIG_BOOTARGS="Please use defined boot"
CONFIG_SYS_CONSOLE_IS_IN_ENV=y
CONFIG_SYS_CONSOLE_INFO_QUIET=y
CONFIG_MISC_INIT_R=y
+CONFIG_BOARD_LATE_INIT=y
CONFIG_BOARD_TYPES=y
CONFIG_SYS_PROMPT="Odroid # "
# CONFIG_CMD_XIMG is not set
--
2.17.1
[PATCH] arm: exynos: odroid: Change autoboot script to use ${mmcbootdev}
This fixes the default boot command for the SD-card boot case.
Signed-off-by: Marek Szyprowski
---
This is the continuation of the fixes from this patchset:
https://patchwork.ozlabs.org/cover/1224290/
---
include/configs/odroid.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/include/configs/odroid.h b/include/configs/odroid.h
index 7989fb29d1..a7e2a3d9a2 100644
--- a/include/configs/odroid.h
+++ b/include/configs/odroid.h
@@ -146,13 +146,13 @@
"run kernel_args;" \
"bootz ${kernel_addr_r} ${initrd_addr} ${fdt_addr};\0" \
"autoboot=" \
- "if test -e mmc 0 boot.scr; then; " \
+ "if test -e mmc ${mmcbootdev} boot.scr; then; " \
"run boot_script; " \
- "elif test -e mmc 0 Image.itb; then; " \
+ "elif test -e mmc ${mmcbootdev} Image.itb; then; " \
"run boot_fit;" \
- "elif test -e mmc 0 zImage; then; " \
+ "elif test -e mmc ${mmcbootdev} zImage; then; " \
"run boot_zimg;" \
- "elif test -e mmc 0 uImage; then; " \
+ "elif test -e mmc ${mmcbootdev} uImage; then; " \
"run boot_uimg;" \
"fi;\0" \
"console=" CONFIG_DEFAULT_CONSOLE \
--
2.17.1
Re: [PATCH 0/3] Fix Odroid U3/X2 SD-card boot
Hi Anand On 17.01.2020 06:00, Anand Moon wrote: > On Thu, 16 Jan 2020 at 20:56, Marek Szyprowski > wrote: >> This patchset restores booting from SD-card on Exynos4412-based Odroid >> U3/X2 boards. It relies on the Exynos MMC device id auto-dectection and >> PMIC device name fixes: >> https://patchwork.ozlabs.org/patch/1223558/ >> https://patchwork.ozlabs.org/patch/1224228/ >> >> Best regards >> Marek Szyprowski >> Samsung R&D Institute Poland >> > Thanks for this fix, I have am issue with my odroid u3 boards, > All my board will not boot up until I connect UART to usb port. > basically the fan spin but will not load the kernel. > So it their a solution to this problem. > > I tried the patch from Tobias Jakobi (odroid: defconfig: configure > keyed autoboot) > but this did not work at my end. I remember I observed a few times the lack of boot when uart adapter was not connect, but now I didn't manage to reproduce it. Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland
Re: [RFC 1/4] mmc: bcm2835_sdhci: use phys2bus macro when dma address is accessed
Hi Jaehoon, On 20.01.2020 11:20, Jaehoon Chung wrote: > Use phys2bus macro when dma address is accessed. > After applied it, SDMA mode can be used. > > When thor download is used, > - Before : 1.8MB/s > - After : 7.23MB/s > > Signed-off-by: Jaehoon Chung > --- > drivers/mmc/bcm2835_sdhci.c | 7 ++- > 1 file changed, 6 insertions(+), 1 deletion(-) > > diff --git a/drivers/mmc/bcm2835_sdhci.c b/drivers/mmc/bcm2835_sdhci.c > index 39c93db275..222ba22d66 100644 > --- a/drivers/mmc/bcm2835_sdhci.c > +++ b/drivers/mmc/bcm2835_sdhci.c > @@ -46,6 +46,7 @@ > #include > #include > #include > +#include > > /* 400KHz is max freq for card ID etc. Use that as min */ > #define MIN_FREQ 40 > @@ -86,7 +87,11 @@ static inline void bcm2835_sdhci_raw_writel(struct > sdhci_host *host, u32 val, > ; > } > > - writel(val, host->ioaddr + reg); > + if (reg == SDHCI_DMA_ADDRESS) > + writel(phys_to_bus((unsigned long)val), host->ioaddr + reg); > + else > + writel(val, host->ioaddr + reg); > + > bcm_host->last_write = timer_get_us(); > } It would be better to fix this directly in the place where writel with SDHCI_DMA_ADDRESS is called: simply change sdhci_writel(host, host->start_addr, SDHCI_DMA_ADDRESS) to sdhci_writel(host, phys_to_bus(host->start_addr), SDHCI_DMA_ADDRESS); In such case no if statement is the needed and phys_to_bus() is safe for non-rpi users (it is identity in such case). # git grep SDHCI_DMA_ADDRESS shows 2 places where writel to SDHCI_DMA_ADDRESS is being done. Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland
Re: [PATCH 00/18] fs: fat: fix long name support
Hi On 29.11.2020 03:01, Heinrich Schuchardt wrote: > Since long name support was added to U-Boot's implementation of the > FAT file system corruption of the directories was observed when running > the UEFI Self Certifification Test. > > The following problems are addressed by this series. > > * short names were not unique > * long names directory entries were not deleted when a file was deleted > * directory entries released by file deletion were not reused > > The first four patches are just resent to indicate the import sequence. I've noticed some of those FAT issues over a year ago, but I never had enough time to start fixing it. Thanks for doing it! Feel free to add: Acked-by: Marek Szyprowski > The following problems need to be addressed in further patches: > > * When extending a file only available FAT entries after the last cluster >of the file are considered. Available FAT entries before are ignored. > * The case of no FAT entry found is not treated correctly. > * The free FAT count is not updated on FAT32. > * Some FAT related tests are not run on Gitlab CI. > * Add tests to detect directory corruption. > > Heinrich Schuchardt (18): >fs: fat: avoid NULL dereference when root dir is full >fs: fat: directory entries starting with 0x05 >fs: fat: use ATTR_ARCH instead of anonymous 0x20 >fs: fat: correct first cluster for '..' >fs: fat: export fat_next_cluster() >fs: fat: create correct short names >fs: fat: pass shortname to fill_dir_slot >fs: fat: call set_name() only once >fs: fat: generate unique short names >fs: fat: dentry iterator for fill_dir_slot() >fs: fat: set start cluster for root directory >fs: fat: flush new directory cluster >fs: fat: fat_find_empty_dentries() >fs: fat: reuse deleted directory entries >fs: fat: search file should not allocate cluster >fs: fat: use constant DELETED_FLAG >fs: fat: first dentry of long name in FAT iterator >fs: fat: deletion of long file names > > fs/fat/fat.c | 133 > fs/fat/fat_write.c | 532 + > include/fat.h | 7 +- > lib/Kconfig| 2 +- > 4 files changed, 494 insertions(+), 180 deletions(-) > > -- > 2.29.2 > > Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland
[PATCH 3/6] adc: meson-saradc: skip hardware init only if ADC is enabled
The driver skips hardware initialization if it is already configured by
the earlier bootloader stage (BL30). Skip the initialization only if the
hardware is really initialized and enabled.
Signed-off-by: Marek Szyprowski
Change-Id: I3e2e2d270ad3e7e7f38e2bc3ce2a924a47b164af
---
drivers/adc/meson-saradc.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/adc/meson-saradc.c b/drivers/adc/meson-saradc.c
index 998cef24d88..ce7ae990ad0 100644
--- a/drivers/adc/meson-saradc.c
+++ b/drivers/adc/meson-saradc.c
@@ -512,8 +512,11 @@ static int meson_saradc_init(struct meson_saradc_priv
*priv)
* reading the temperature sensor.
*/
regmap_read(priv->regmap, MESON_SAR_ADC_REG3, ®val);
- if (regval & MESON_SAR_ADC_REG3_BL30_INITIALIZED)
- return 0;
+ if (regval & MESON_SAR_ADC_REG3_BL30_INITIALIZED) {
+ regmap_read(priv->regmap, MESON_SAR_ADC_REG3, ®val);
+ if (regval & MESON_SAR_ADC_REG3_ADC_EN)
+ return 0;
+ }
meson_saradc_stop_sample_engine(priv);
--
2.17.1
