Re: [PATCH 1/4] Respect that some compression algos can be enabled separately for SPL
On 26.01.21 18:53, Tim Harvey wrote: On Sat, Jan 23, 2021 at 4:39 AM Stefano Babic wrote: Hi Tim, there is a weird side effect with this patch, breaking m68k architecture. For some reason, image.c is not compiled clean because gd is not declared anymore. In file included from tools/common/image.c:1: ./tools/../common/image.c: In function ‘get_table_entry_id’: ./tools/../common/image.c:982:41: error: ‘gd’ undeclared (first use in this function) 982 | if (t->sname && strcasecmp(t->sname + gd->reloc_off, name) == 0) | ^~ ./tools/../common/image.c:982:41: note: each undeclared identifier is reported only once for each functi Can you take a look ? Thanks ! Stefano, I have no idea what could cause this... must be something to do with including kconfig.h? What board/target would I build to reproduce this? Frieder, do you have any ideas? I can't remember if I did a full test on all platforms when I wrote this patch. Probably not. And I have no idea what is causing this, nor do I currently have the time to have a closer look, sorry. BTW, this is a very good example for what I said earlier: "I failed to do upstreaming work for U-Boot for quite some time. Mainly because whenever I try to, I end up fixing/cleaning some weird U-Boot code/behavior and spending way more time than I actually have available."
Re: [PATCH] disk: part_efi: update partition table entries after write
On Tue, Jan 26, 2021 at 04:08:13PM +0100, Heinrich Schuchardt wrote: > On 26.01.21 14:56, Gary Bisson wrote: > > Fixes fastboot issues when switching from mbr to gpt partition tables. > > > > Signed-off-by: Gary Bisson > > --- > > Hi, > > > > I hesitated calling this a RFC as I'm not sure everyone will like the > > idea. > > > > Basically the issue encountered was the following: > > - Device with its storage flashed with a MBR partition table > > - Run fastboot to flash a new OS (and new partition table) > > - After flashing a GPT partition table, U-Boot couldn't find any of the > > partition names from the GPT > > -> reason is that the partition table entries aren't updated > > -> so U-Boot still believes it's a MBR table inside and so its parsing > > fails > > > > This commit adds an update of the table entries inside the > > write_mbr_and_gpt_partitions() function. At first I thought maybe this > > should be added in fastboot file (fb_mmc.c) but couldn't think of a good > > reason why this shouldn't happened in part_efi directly. > > > > Let me know if you have any questions. > > > > Regards, > > Gary > > --- > > disk/part_efi.c | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/disk/part_efi.c b/disk/part_efi.c > > index 2f922662e6e..7a24e33d189 100644 > > --- a/disk/part_efi.c > > +++ b/disk/part_efi.c > > @@ -867,6 +867,9 @@ int write_mbr_and_gpt_partitions(struct blk_desc > > *dev_desc, void *buf) > > return 1; > > } > > > > + /* Update the partition table entries*/ > > + part_init(dev_desc); > > + > > return 0; > > } > > #endif > > > > This change is for GPT only. Don't we need the same for MBR partition > tables (write_mbr_partitions())? > > @Simon: > > Essentially this reflashing is similar to changing media. What I am > missing in part_init() is setting a field with a counter to indicate the > media change. The EFI_BLOCK_IO_PROTOCOL has a u32 field media_id. Would > struct blk_desc be the right place to add such a field. As far as "efi_loader" is concerned, none of partitions on the media, either in case of repartitioning or changing media, will no longer be recognized as a "efi disk" after efi subsystem is initialized. All we can and have to do is to just reboot the system. I think we should take one step further to fixing the issue along with this patch. I have posted a couple of proposals in the past, for example, see [1]. [1] https://lists.denx.de/pipermail/u-boot/2019-January/356499.html -Takahiro Akashi > Best regards > > Heinrich >
Re: arm: rk3399: add support nanopi r4s【请注意，邮件由u-boot-boun...@lists.denx.de代发】
Hi Xiaobo,
Please reference the requirement to below document for patch submit.
http://www.denx.de/wiki/U-Boot/Patches
Tips, you can reference to other patches for new board support, eg.
using cmd: git log arch/arm/dts/Makefile
Thanks,
- Kever
On 2021/1/27 上午12:12, alex tian wrote:
From 0c1b6b9c696f7bbdb91119af033e598e4b8d2f81 Mon Sep 17 00:00:00 2001
From: Xiaobo Tian
Date: Sat, 26 Dec 2020 00:13:37 +0800
Subject: [PATCH] arm: rk3399: add support nanopi r4s
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
SoC – Rockchip RK3399 hexa-core processor with dual-Core Cortex-A72 up to
2.0GHz, quad-core Cortex-A53 up to 1.5GHz, Mali-T864 GPU with OpenGL
ES1.1/2.0/3.0/3.1, OpenCL, DX11, and AFBC support, 4K VP9 and 4K 10-bit
H265/H264 60fps video decoder
System Memory – 1GB DDR3 or 4GB LPDDR4
Storage – MicroSD card slot
Networking – 2x GbE(RTL8211E 1Gbps - RTL8111H 1Gbps), including one native
Gigabit Ethernet, and one PCIe Gigabit Ethernet
USB – 2x USB 3.0 Type-A ports, USB 2.0 via 4-pin header
Expansion – 2×5-pin header with 1x SPI, 1x I2C
Debugging – 3-pin debug UART header
Misc- 1x power LED, and 3x user LEDs (SYS, LAN, WAN), user button, 2-pin
RTC battery connector, 5V fan connector
Power Supply
5V/3A via USB-C connector or pin header
RK808-D PMIC and independent DC/DC enabling DVFS, software power-down, RTC
wake-up, system sleep mode
Dimensions – 66 x 66 mm (8-layer PCB)
Temperature Range – -20°C to 70°C
The detailed information for NanoPi R4S <
https://wiki.friendlyarm.com/wiki/index.php/NanoPi_R4S>
Signed-off-by: Xiaobo Tian
---
arch/arm/dts/Makefile | 1 +
arch/arm/dts/rk3399-nanopi-r4s-u-boot.dtsi | 7 ++
arch/arm/dts/rk3399-nanopi-r4s.dts | 120 +
configs/nanopi-r4s-rk3399_defconfig| 62 +++
4 files changed, 190 insertions(+)
create mode 100644 arch/arm/dts/rk3399-nanopi-r4s-u-boot.dtsi
create mode 100644 arch/arm/dts/rk3399-nanopi-r4s.dts
create mode 100644 configs/nanopi-r4s-rk3399_defconfig
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index e320c2254e..507b1e4ec9 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -92,6 +92,7 @@ dtb-$(CONFIG_ROCKCHIP_RK3288) += \
rk3288-evb.dtb \
rk3288-firefly.dtb \
rk3288-miqi.dtb \
+ rk3399-nanopi-r4s.dtb \
rk3288-phycore-rdk.dtb \
rk3288-popmetal.dtb \
rk3288-rock2-square.dtb \
diff --git a/arch/arm/dts/rk3399-nanopi-r4s-u-boot.dtsi
b/arch/arm/dts/rk3399-nanopi-r4s-u-boot.dtsi
new file mode 100644
index 00..05f785e662
--- /dev/null
+++ b/arch/arm/dts/rk3399-nanopi-r4s-u-boot.dtsi
@@ -0,0 +1,7 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2020 Xiaobo
+ */
+
+#include "rk3399-nanopi4-u-boot.dtsi"
+#include "rk3399-sdram-lpddr4-100.dtsi"
diff --git a/arch/arm/dts/rk3399-nanopi-r4s.dts
b/arch/arm/dts/rk3399-nanopi-r4s.dts
new file mode 100644
index 00..5c65447f0e
--- /dev/null
+++ b/arch/arm/dts/rk3399-nanopi-r4s.dts
@@ -0,0 +1,120 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2020 FriendlyElec Computer Tech. Co., Ltd.
+ * (http://www.friendlyarm.com)
+ *
+ * Copyright (C) 2020 Xiaobo
+ */
+
+/dts-v1/;
+#include "rk3399-nanopi4.dtsi"
+
+/ {
+ model = "FriendlyElec NanoPi R4S";
+ compatible = "friendlyarm,nanopi-r4s", "rockchip,rk3399";
+
+ vdd_5v: vdd-5v {
+ compatible = "regulator-fixed";
+ regulator-name = "vdd_5v";
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ fan: pwm-fan {
+ compatible = "pwm-fan";
+ /* FIXME: adjust leveles for the connected fan */
+ cooling-levels = <0 12 18 255>;
+ #cooling-cells = <2>;
+ fan-supply = <_5v>;
+ pwms = < 0 5 0>;
+ };
+};
+
+_thermal {
+ trips {
+ cpu_warm: cpu_warm {
+ temperature = <55000>;
+ hysteresis = <2000>;
+ type = "active";
+ };
+
+ cpu_hot: cpu_hot {
+ temperature = <65000>;
+ hysteresis = <2000>;
+ type = "active";
+ };
+ };
+
+ cooling-maps {
+ map2 {
+ trip = <_warm>;
+ cooling-device = < THERMAL_NO_LIMIT 1>;
+ };
+
+ map3 {
+ trip = <_hot>;
+ cooling-device = < 2 THERMAL_NO_LIMIT>;
+ };
+ };
+};
+
+_phy {
+ status = "disabled";
+};
+
+ {
+ status = "disabled";
+};
+
+ {
+ lan_led: led-1 {
+ gpios = < RK_PA1 GPIO_ACTIVE_HIGH>;
+ label = "nanopi-r4s:green:lan";
+ };
+
+ wan_led: led-2 {
+ gpios = < RK_PA0 GPIO_ACTIVE_HIGH>;
+ label = "nanopi-r4s:green:wan";
+ };
+};
+
+_gpio {
+ rockchip,pins =
+ <0 RK_PB5 RK_FUNC_GPIO _pull_none>,
+ <1 RK_PA0 RK_FUNC_GPIO _pull_none>,
+ <1 RK_PA1 RK_FUNC_GPIO _pull_none>;
+};
+
+ {
+ max-link-speed = <1>;
+ num-lanes = <1>;
+ vpcie3v3-supply = <_sys>;
+};
+
+ {
+ status = "disabled";
+};
+
+ {
+ status = "disabled";
+};
+
+ {
+ host-index-min = <1>;
+};
+
+_host {
+ phy-supply = <_5v>;
+};
+
+_host {
+ status = "disabled";
+};
+
+_dwc3_0 {
+ dr_mode = "host";
+};
+
+_sys {
+ vin-supply = <_sys>;
+};
diff --git a/configs/nanopi-r4s-rk3399_defconfig
b/configs/nanopi-r4s-rk3399_defconfig
new file mode 100644
index
Re: [PATCH] common: board_f: fix to display wrong memory information
Hi,
On 12/30/20 9:05 AM, Jaehoon Chung wrote:
> On 12/30/20 8:48 AM, Sean Anderson wrote:
>> On 12/29/20 6:24 PM, Jaehoon Chung wrote:
>>> When run meminfo command, it's displayed wrong memory information.
>>> Because it's using gd->ram_size what didn't configure ram size.
>>
>> what -> which?
>
> Will update
>
>>
>>>
>>> On 4G RPI4 target
>>> - Before
>>> U-Boot> meminfo
>>> DRAM: 948MiB
>>> - After
>>> U-Boot> meminfo
>>> DRAM: 3.9GiB
>>>
>>> Signed-off-by: Jaehoon Chung
>>> ---
>>> common/board_f.c | 1 +
>>> 1 file changed, 1 insertion(+)
>>>
>>> diff --git a/common/board_f.c b/common/board_f.c
>>> index 9f441c44f176..96c675ea28e4 100644
>>> --- a/common/board_f.c
>>> +++ b/common/board_f.c
>>> @@ -228,6 +228,7 @@ static int show_dram_config(void)
>>> }
>>> debug("\nDRAM: ");
>>> + gd->ram_size = size;
>>
>> Shouldn't this be set by dram_init?
>
> Yes, it's set by dram_init(), I didn't think about only rpi's problem.
> I will check other target. (I have checked only RPI..) Thanks for pointing
> out.
Sorry for late checking. I have checked other boards with meminfo command.
In VIM3 4G
Model: Khadas VIM3
SoC: Amlogic Meson G12B (A311D) Revision 29:b (10:2)
DRAM: 3.8 GiB
..[snip]..
> meminfo
DRAM: 1.9 GiB
There is a bug to display information. I will resend patch v2.
Best Regards,
Jaehoon Chung
>
> Best Regards,
> Jaehoon Chung
>
>>
>> --Sean
>>
>>> print_size(size, "");
>>> board_add_ram_info(0);
>>> putc('\n');
>>>
>>
>>
>
>
[PATCH v2 3/3] sunxi: OrangePi Zero 2: Enable Ethernet
With the fixes to the sun8i-emac driver, we can now enable Ethernet support on the OrangePi Zero2. Signed-off-by: Andre Przywara --- configs/orangepi_zero2_defconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/configs/orangepi_zero2_defconfig b/configs/orangepi_zero2_defconfig index 0c20b5ff28f..5af964bf100 100644 --- a/configs/orangepi_zero2_defconfig +++ b/configs/orangepi_zero2_defconfig @@ -11,3 +11,5 @@ CONFIG_R_I2C_ENABLE=y CONFIG_DEFAULT_DEVICE_TREE="sun50i-h616-orangepi-zero2" # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set CONFIG_SPL_I2C_SUPPORT=y +CONFIG_PHY_REALTEK=y +CONFIG_SUN8I_EMAC=y -- 2.17.5
[PATCH v2 2/3] net: sun8i-emac: Determine pinmux based on SoC, not EMAC type
The pinmux choice for the RMII/RGMII pins the EMAC is connected to is
not dependent on the EMAC IP, but on the SoC it is integrated in.
Deriving the pinmux from the DT compatible string (as we do at the
moment) will thus cause problems with certain EMAC IP / SoC combinations.
To avoid this exact issue with the H616, let's use our Kconfig MACH
symbols to choose the correct pinmux setup.
Signed-off-by: Andre Przywara
---
drivers/net/sun8i_emac.c | 28
1 file changed, 20 insertions(+), 8 deletions(-)
diff --git a/drivers/net/sun8i_emac.c b/drivers/net/sun8i_emac.c
index 2344525bf52..0f6b6bb537e 100644
--- a/drivers/net/sun8i_emac.c
+++ b/drivers/net/sun8i_emac.c
@@ -85,7 +85,9 @@
/* IO mux settings */
#define SUN8I_IOMUX_H3 2
-#define SUN8I_IOMUX_R405
+#define SUN8I_IOMUX_R405
+#define SUN8I_IOMUX_H6 5
+#define SUN8I_IOMUX_H616 2
#define SUN8I_IOMUX4
/* H3/A64 EMAC Register's offset */
@@ -517,10 +519,10 @@ static int sun8i_emac_eth_start(struct udevice *dev)
static int parse_phy_pins(struct udevice *dev)
{
- struct emac_eth_dev *priv = dev_get_priv(dev);
int offset;
const char *pin_name;
int drive, pull = SUN4I_PINCTRL_NO_PULL, i;
+ u32 iomux;
offset = fdtdec_lookup_phandle(gd->fdt_blob, dev_of_offset(dev),
"pinctrl-0");
@@ -547,6 +549,21 @@ static int parse_phy_pins(struct udevice *dev)
else if (fdt_get_property(gd->fdt_blob, offset, "bias-pull-down", NULL))
pull = SUN4I_PINCTRL_PULL_DOWN;
+ /*
+* The GPIO pinmux value is an integration choice, so depends on the
+* SoC, not the EMAC variant.
+*/
+ if (IS_ENABLED(CONFIG_MACH_SUN8I_H3))
+ iomux = SUN8I_IOMUX_H3;
+ else if (IS_ENABLED(CONFIG_MACH_SUN8I_R40))
+ iomux = SUN8I_IOMUX_R40;
+ else if (IS_ENABLED(CONFIG_MACH_SUN50I_H6))
+ iomux = SUN8I_IOMUX_H6;
+ else if (IS_ENABLED(CONFIG_MACH_SUN50I_H616))
+ iomux = SUN8I_IOMUX_H616;
+ else
+ iomux = SUN8I_IOMUX;
+
for (i = 0; ; i++) {
int pin;
@@ -559,12 +576,7 @@ static int parse_phy_pins(struct udevice *dev)
if (pin < 0)
continue;
- if (priv->variant == H3_EMAC)
- sunxi_gpio_set_cfgpin(pin, SUN8I_IOMUX_H3);
- else if (priv->variant == R40_GMAC || priv->variant == H6_EMAC)
- sunxi_gpio_set_cfgpin(pin, SUN8I_IOMUX_R40);
- else
- sunxi_gpio_set_cfgpin(pin, SUN8I_IOMUX);
+ sunxi_gpio_set_cfgpin(pin, iomux);
if (drive != ~0)
sunxi_gpio_set_drv(pin, drive);
--
2.17.5
[PATCH v2 1/3] net: sun8i-emac: Always clear syscon EPHY register
At the moment we only consider the EPHY register for those SoCs were
we actually have an internal PHY to configure. However even other SoCs
have this register, an expect the EPHY select bit to be cleared for
proper operation with an external PHY.
Rework sun8i_emac_set_syscon_ephy() to be called regardless of the EMAC
model, and clear the H3_EPHY_SELECT bit if no internal PHY is used.
We get away without it so far because SoCs like the A64 clear this bit
on reset, but we need to explicitly clear it on the H616, for instance.
The Linux driver does so as well.
Signed-off-by: Andre Przywara
---
drivers/net/sun8i_emac.c | 31 +--
1 file changed, 13 insertions(+), 18 deletions(-)
diff --git a/drivers/net/sun8i_emac.c b/drivers/net/sun8i_emac.c
index 9f91a20d1d1..2344525bf52 100644
--- a/drivers/net/sun8i_emac.c
+++ b/drivers/net/sun8i_emac.c
@@ -297,30 +297,29 @@ static void sun8i_adjust_link(struct emac_eth_dev *priv,
writel(v, priv->mac_reg + EMAC_CTL0);
}
-static int sun8i_emac_set_syscon_ephy(struct emac_eth_dev *priv, u32 *reg)
+static u32 sun8i_emac_set_syscon_ephy(struct emac_eth_dev *priv, u32 reg)
{
if (priv->use_internal_phy) {
/* H3 based SoC's that has an Internal 100MBit PHY
* needs to be configured and powered up before use
*/
- *reg &= ~H3_EPHY_DEFAULT_MASK;
- *reg |= H3_EPHY_DEFAULT_VALUE;
- *reg |= priv->phyaddr << H3_EPHY_ADDR_SHIFT;
- *reg &= ~H3_EPHY_SHUTDOWN;
- *reg |= H3_EPHY_SELECT;
- } else
- /* This is to select External Gigabit PHY on
-* the boards with H3 SoC.
- */
- *reg &= ~H3_EPHY_SELECT;
+ reg &= ~H3_EPHY_DEFAULT_MASK;
+ reg |= H3_EPHY_DEFAULT_VALUE;
+ reg |= priv->phyaddr << H3_EPHY_ADDR_SHIFT;
+ reg &= ~H3_EPHY_SHUTDOWN;
+ return reg | H3_EPHY_SELECT;
+ }
- return 0;
+ /* This is to select External Gigabit PHY on those boards with
+* an internal PHY. Does not hurt on other SoCs. Linux does
+* it as well.
+*/
+ return reg & ~H3_EPHY_SELECT;
}
static int sun8i_emac_set_syscon(struct sun8i_eth_pdata *pdata,
struct emac_eth_dev *priv)
{
- int ret;
u32 reg;
if (priv->variant == R40_GMAC) {
@@ -336,11 +335,7 @@ static int sun8i_emac_set_syscon(struct sun8i_eth_pdata
*pdata,
reg = readl(priv->sysctl_reg + 0x30);
- if (priv->variant == H3_EMAC || priv->variant == H6_EMAC) {
- ret = sun8i_emac_set_syscon_ephy(priv, );
- if (ret)
- return ret;
- }
+ reg = sun8i_emac_set_syscon_ephy(priv, reg);
reg &= ~(SC_ETCS_MASK | SC_EPIT);
if (priv->variant == H3_EMAC ||
--
2.17.5
[PATCH v2 0/3] sunxi: OrangePi Zero 2: Ethernet support
The first two patches prepare the sun8i-emac driver to deal with the EMAC as integrated into the H616 SoC. This IP block is compatible with the A64 version, but the current driver prevents us from using that: - The EPHY syscon register needs to have a bit cleared to select the external PHY. On the A64 it is cleared on reset, but we should not rely on that. The Linux driver does so as well. Fixed in patch 1/3. - The pinmux setting is tied to the compatible string, but the H616 requires a different value. Fixed in patch 2/3. The final patch enables Ethernet support for the OrangePi Zero 2 board, which now works without further ado. Cheers, Andre Andre Przywara (3): net: sun8i-emac: Always clear syscon EPHY register net: sun8i-emac: Determine pinmux based on SoC, not EMAC type sunxi: OrangePi Zero 2: Enable Ethernet configs/orangepi_zero2_defconfig | 2 ++ drivers/net/sun8i_emac.c | 59 ++-- 2 files changed, 35 insertions(+), 26 deletions(-) -- 2.17.5
[PATCH] remoteproc: k3_r5: Sync to upstreamed kernel DT property names
The K3 R5F remoteproc driver in U-Boot was upstreamed prior to the
equivalent remoteproc driver in the Linux kernel. Some of the DT
properties used in U-Boot got upstreamed using different names
in Linux kernel.
The modified property names include the R5F cluster mode configuration
property "lockstep-mode"; and three different individual R5F core config
properties - "atcm-enable", "btcm-enable" and "loczrama". The property
names were updated as follows:
lockstep-mode => ti,cluster-mode
atcm-enable => ti,atcm-enable
btcm-enable => ti,btcm-enable
loczrama => ti,loczrama
Update the K3 R5F remoteproc driver, the corresponding binding, and
all the existing usage in AM65x, J721E and J7200 dts files all at
once to use the new properties and to not break any bisectability.
Signed-off-by: Suman Anna
---
Hi Lokesh,
As agreed offline, this patch syncs the U-Boot K3 R5F driver and all
the related pieces in a single patch to the equivalent property names
in the latest upstream Linux kernel. Note that the kernel bindings in
general define a few more properties which have no presence so far in
U-Boot. So, only the common properties are synched. No changes are
required to the K3 DSP remoteproc driver.
Tested on AM65x, J721E and J7200 using appropriate SYSFW. Patch is on
top of latest U-Boot master commit e262b2973e22.
regards
Suman
arch/arm/dts/k3-am65-mcu.dtsi | 14 +-
arch/arm/dts/k3-j7200-main.dtsi | 14 +-
arch/arm/dts/k3-j7200-mcu-wakeup.dtsi | 14 +-
arch/arm/dts/k3-j721e-main.dtsi | 28 +--
arch/arm/dts/k3-j721e-mcu-wakeup.dtsi | 14 +-
.../remoteproc/ti,k3-r5f-rproc.txt| 26 -
drivers/remoteproc/ti_k3_r5f_rproc.c | 8 +++---
7 files changed, 59 insertions(+), 59 deletions(-)
diff --git a/arch/arm/dts/k3-am65-mcu.dtsi b/arch/arm/dts/k3-am65-mcu.dtsi
index 0b07e188b59f..84c8f34e24a2 100644
--- a/arch/arm/dts/k3-am65-mcu.dtsi
+++ b/arch/arm/dts/k3-am65-mcu.dtsi
@@ -43,7 +43,7 @@
mcu_r5fss0: r5fss@4100 {
compatible = "ti,am654-r5fss";
- lockstep-mode = <0>;
+ ti,cluster-mode = <0>;
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x4100 0x00 0x4100 0x2>,
@@ -59,9 +59,9 @@
ti,sci-dev-id = <159>;
ti,sci-proc-ids = <0x01 0xFF>;
resets = <_reset 159 1>;
- atcm-enable = <1>;
- btcm-enable = <1>;
- loczrama = <1>;
+ ti,atcm-enable = <1>;
+ ti,btcm-enable = <1>;
+ ti,loczrama = <1>;
};
mcu_r5fss0_core1: r5f@4140 {
@@ -73,9 +73,9 @@
ti,sci-dev-id = <245>;
ti,sci-proc-ids = <0x02 0xFF>;
resets = <_reset 245 1>;
- atcm-enable = <1>;
- btcm-enable = <1>;
- loczrama = <1>;
+ ti,atcm-enable = <1>;
+ ti,btcm-enable = <1>;
+ ti,loczrama = <1>;
};
};
diff --git a/arch/arm/dts/k3-j7200-main.dtsi b/arch/arm/dts/k3-j7200-main.dtsi
index c25f03cf23d9..ed9f1a7b8259 100644
--- a/arch/arm/dts/k3-j7200-main.dtsi
+++ b/arch/arm/dts/k3-j7200-main.dtsi
@@ -343,7 +343,7 @@
main_r5fss0: r5fss@5c0 {
compatible = "ti,j7200-r5fss";
- lockstep-mode = <0>;
+ ti,cluster-mode = <0>;
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x5c0 0x00 0x5c0 0x2>,
@@ -360,9 +360,9 @@
ti,sci-proc-ids = <0x06 0xFF>;
resets = <_reset 245 1>;
firmware-name = "j7200-main-r5f0_0-fw";
- atcm-enable = <1>;
- btcm-enable = <1>;
- loczrama = <1>;
+ ti,atcm-enable = <1>;
+ ti,btcm-enable = <1>;
+ ti,loczrama = <1>;
};
main_r5fss0_core1: r5f@5d0 {
@@ -375,9 +375,9 @@
ti,sci-proc-ids = <0x07 0xFF>;
resets = <_reset 246 1>;
firmware-name = "j7200-main-r5f0_1-fw";
- atcm-enable = <1>;
- btcm-enable = <1>;
- loczrama = <1>;
+ ti,atcm-enable = <1>;
+ ti,btcm-enable = <1>;
+ ti,loczrama = <1>;
};
};
};
diff --git a/arch/arm/dts/k3-j7200-mcu-wakeup.dtsi
b/arch/arm/dts/k3-j7200-mcu-wakeup.dtsi
index 75c0c8597dc9..1faffe62fe80 100644
---
Re: [PATCH] cmd: misc: Fix return value for the sleep command
On 1/22/21 8:27 PM, Marek Szyprowski wrote:
> If sleeping has been interrupted, return CMD_RET_FAILURE instead of -1
> (CMD_RET_USAGE).
>
> Signed-off-by: Marek Szyprowski
Reviewed-by: Jaehoon Chung
Best Regards,
Jaehoon Chung
> ---
> 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);
> }
>
Re: [RESEND PATCH v1 1/1] mmc: fix response timeout after switch command
Hi, On 1/23/21 9:37 PM, Stefan Bosch wrote: > After issuing the switch command: Wait until 'current state' of the card > status becomes 'tran'. This prevents from response timeout at the next > command because of 'current state' = 'data'.> > Signed-off-by: Stefan Bosch > --- > > drivers/mmc/mmc.c | 3 ++- > include/mmc.h | 1 + > 2 files changed, 3 insertions(+), 1 deletion(-) > > diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c > index a47700e313..8ccd2058a9 100644 > --- a/drivers/mmc/mmc.c > +++ b/drivers/mmc/mmc.c > @@ -823,7 +823,8 @@ static int __mmc_switch(struct mmc *mmc, u8 set, u8 > index, u8 value, >value); > return -EIO; > } > - if (!ret && (status & MMC_STATUS_RDY_FOR_DATA)) > + if (!ret && (status & MMC_STATUS_RDY_FOR_DATA) && > + (status & MMC_STATUS_CURR_STATE) == MMC_STATE_TRANS) AFAIK, MMC_STATUS_RDY_FOR_DATA bit means the signaling about "buffer is empty". Even though its bit was set, does it need to check TRANS state? Best Regards, Jaehoon Chung > return 0; > udelay(100); > } while (get_timer(start) < timeout_ms); > diff --git a/include/mmc.h b/include/mmc.h > index 1d377e0281..18402494c6 100644 > --- a/include/mmc.h > +++ b/include/mmc.h > @@ -178,6 +178,7 @@ static inline bool mmc_is_tuning_cmd(uint cmdidx) > #define MMC_STATUS_ERROR (1 << 19) > > #define MMC_STATE_PRG(7 << 9) > +#define MMC_STATE_TRANS (4 << 9) > > #define MMC_VDD_165_195 0x0080 /* VDD voltage 1.65 - > 1.95 */ > #define MMC_VDD_20_210x0100 /* VDD voltage 2.0 ~ > 2.1 */ >
[PATCH v2 7/7] fastboot: Implement generic fastboot_set_reboot_flag
It is possible to implement fastboot_set_reboot_flag in a generic way
if BCB commands are turned on for a target. Using
bcb_set_reboot_reason allows to do this by simply passing string with
correct reboot reason that should be handled during next boot process.
If BCB are turned off, then bcb_set_reboot_reason would simply return
error, so it won't introduce any new behaviour for such targets.
Signed-off-by: Roman Kovalivskyi
---
drivers/fastboot/fb_common.c | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/drivers/fastboot/fb_common.c b/drivers/fastboot/fb_common.c
index 736ce1cd024f..cbcc3683c471 100644
--- a/drivers/fastboot/fb_common.c
+++ b/drivers/fastboot/fb_common.c
@@ -10,6 +10,7 @@
* Rob Herring
*/
+#include
#include
#include
#include
@@ -90,7 +91,20 @@ void fastboot_okay(const char *reason, char *response)
*/
int __weak fastboot_set_reboot_flag(enum fastboot_reboot_reason reason)
{
- return -ENOSYS;
+#if CONFIG_IS_ENABLED(FASTBOOT_FLASH_MMC_DEV)
+ static const char * const boot_cmds[] = {
+ [FASTBOOT_REBOOT_REASON_BOOTLOADER] = "bootonce-bootloader",
+ [FASTBOOT_REBOOT_REASON_FASTBOOTD] = "boot-fastboot",
+ [FASTBOOT_REBOOT_REASON_RECOVERY] = "boot-recovery"
+ };
+
+ if (reason >= FASTBOOT_REBOOT_REASONS_COUNT)
+ return -EINVAL;
+
+ return bcb_write_reboot_reason(CONFIG_FASTBOOT_FLASH_MMC_DEV, "misc",
boot_cmds[reason]);
+#else
+return -EINVAL;
+#endif
}
/**
--
2.17.1
[PATCH v2 6/7] Revert "fastboot: Add default fastboot_set_reboot_flag implementation"
This reverts commit 0ebf9842e56c5b8cb7cb1f990bb452cc14af6225.
Current generic implementation of fastboot_set_reboot_flag is somewhat
messy and requires some additional configuration option to be enabled
besides CMD_BCB, so it reverts that implementtion in order to bring a
new cleaner one.
Next commit introduces new generic implementation of
fastboot_set_reboot_flag.
Signed-off-by: Roman Kovalivskyi
---
drivers/fastboot/Kconfig | 12 --
drivers/fastboot/Makefile | 1 -
drivers/fastboot/fb_bcb_impl.c | 43 --
include/fastboot.h | 9 ---
4 files changed, 65 deletions(-)
delete mode 100644 drivers/fastboot/fb_bcb_impl.c
diff --git a/drivers/fastboot/Kconfig b/drivers/fastboot/Kconfig
index 4352ba67a713..d4436dfc9173 100644
--- a/drivers/fastboot/Kconfig
+++ b/drivers/fastboot/Kconfig
@@ -165,18 +165,6 @@ config FASTBOOT_CMD_OEM_FORMAT
relies on the env variable partitions to contain the list of
partitions as required by the gpt command.
-config FASTBOOT_USE_BCB_SET_REBOOT_FLAG
- bool "Use BCB by fastboot to set boot reason"
- depends on CMD_BCB && !ARCH_MESON && !ARCH_ROCKCHIP && !TARGET_KC1 && \
- !TARGET_SNIPER && !TARGET_AM57XX_EVM && !TARGET_DRA7XX_EVM
- default y
- help
- Fastboot could implement setting of reboot reason in a generic fashion
- via BCB commands. BCB commands are able to write reboot reason into
- command field of boot control block. In general case it is sufficient
- implementation if your platform supports BCB commands and doesn't
- require any specific reboot reason handling.
-
endif # FASTBOOT
endmenu
diff --git a/drivers/fastboot/Makefile b/drivers/fastboot/Makefile
index 2b2c390fe4de..048af5aa8234 100644
--- a/drivers/fastboot/Makefile
+++ b/drivers/fastboot/Makefile
@@ -5,4 +5,3 @@ obj-y += fb_getvar.o
obj-y += fb_command.o
obj-$(CONFIG_FASTBOOT_FLASH_MMC) += fb_mmc.o
obj-$(CONFIG_FASTBOOT_FLASH_NAND) += fb_nand.o
-obj-$(CONFIG_FASTBOOT_USE_BCB_SET_REBOOT_FLAG) += fb_bcb_impl.o
diff --git a/drivers/fastboot/fb_bcb_impl.c b/drivers/fastboot/fb_bcb_impl.c
deleted file mode 100644
index 89ec3601b6f6..
--- a/drivers/fastboot/fb_bcb_impl.c
+++ /dev/null
@@ -1,43 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+
-/*
- * Copyright 2020 GlobalLogic.
- * Roman Kovalivskyi
- */
-
-#include
-#include
-
-/**
- * fastboot_set_reboot_flag() - Set flag to indicate reboot-bootloader
- *
- * Set flag which indicates that we should reboot into the bootloader
- * following the reboot that fastboot executes after this function.
- *
- * This function should be overridden in your board file with one
- * which sets whatever flag your board specific Android bootloader flow
- * requires in order to re-enter the bootloader.
- */
-int fastboot_set_reboot_flag(enum fastboot_reboot_reason reason)
-{
- char cmd[64];
-
- if (reason >= FASTBOOT_REBOOT_REASONS_COUNT)
- return -EINVAL;
-
- snprintf(cmd, sizeof(cmd), "bcb load %d misc",
-CONFIG_FASTBOOT_FLASH_MMC_DEV);
-
- if (run_command(cmd, 0))
- return -ENODEV;
-
- snprintf(cmd, sizeof(cmd), "bcb set command %s",
-fastboot_boot_cmds[reason]);
-
- if (run_command(cmd, 0))
- return -ENOEXEC;
-
- if (run_command("bcb store", 0))
- return -EIO;
-
- return 0;
-}
diff --git a/include/fastboot.h b/include/fastboot.h
index 8e9ee80907df..b86b508e69fd 100644
--- a/include/fastboot.h
+++ b/include/fastboot.h
@@ -52,15 +52,6 @@ enum fastboot_reboot_reason {
FASTBOOT_REBOOT_REASONS_COUNT
};
-/**
- * BCB boot commands
- */
-static const char * const fastboot_boot_cmds[] = {
- [FASTBOOT_REBOOT_REASON_BOOTLOADER] = "bootonce-bootloader",
- [FASTBOOT_REBOOT_REASON_FASTBOOTD] = "boot-fastboot",
- [FASTBOOT_REBOOT_REASON_RECOVERY] = "boot-recovery"
-};
-
/**
* fastboot_response() - Writes a response of the form "$tag$reason".
*
--
2.17.1
[PATCH v2 5/7] cmd: bcb: Add support for processing const string literals in bcb_set()
From: Eugeniu Rosca
On request/suggestion from Simon Glass back in May 22 2019 [1], the
'strsep' mechanism implemented in bcb_set() was set to work directly
with user-provided argv strings, to avoid duplicating memory and for
the sake of simpler implementation.
However, since we recently exposed bcb_write_reboot_reason() API to be
called by U-Boot fastboot, the idea is to be able to pass const string
literals to this new BCB API, carrying the reboot reason.
Since 'strsep' (just like its older/superseded sibling 'strtok')
modifies the input string passed as parameter, BCB command in its
current state would attempt to perform in-place modifications in a
readonly string, which might lead to unexpected results.
Fix the above with the cost of one dynamic memory allocation ('strdup').
This will also ensure no compiler warnings when passing string literals
to bcb_write_reboot_reason().
[1]
http://u-boot.10912.n7.nabble.com/PATCH-v2-0-2-Add-bcb-command-to-read-modify-write-Android-BCB-td369934i20.html#a370456
Cc: Simon Glass
Signed-off-by: Eugeniu Rosca
Signed-off-by: Roman Kovalivskyi
---
cmd/bcb.c | 17 -
include/bcb.h | 4 ++--
2 files changed, 14 insertions(+), 7 deletions(-)
diff --git a/cmd/bcb.c b/cmd/bcb.c
index 5da3526142ad..6b6f1e9a2f10 100644
--- a/cmd/bcb.c
+++ b/cmd/bcb.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
enum bcb_cmd {
BCB_CMD_LOAD,
@@ -179,10 +180,10 @@ static int do_bcb_load(struct cmd_tbl *cmdtp, int flag,
int argc,
return __bcb_load(devnum, argv[2]);
}
-static int __bcb_set(char *fieldp, char *valp)
+static int __bcb_set(char *fieldp, const char *valp)
{
int size, len;
- char *field, *str, *found;
+ char *field, *str, *found, *tmp;
if (bcb_field_get(fieldp, , ))
return CMD_RET_FAILURE;
@@ -193,14 +194,20 @@ static int __bcb_set(char *fieldp, char *valp)
valp, len, size, fieldp);
return CMD_RET_FAILURE;
}
- str = valp;
+ str = strdup(valp);
+ if (!str) {
+ printf("Error: Out of memory while strdup\n");
+ return CMD_RET_FAILURE;
+ }
+ tmp = str;
field[0] = '\0';
- while ((found = strsep(, ":"))) {
+ while ((found = strsep(, ":"))) {
if (field[0] != '\0')
strcat(field, "\n");
strcat(field, found);
}
+ free(str);
return CMD_RET_SUCCESS;
}
@@ -308,7 +315,7 @@ static int do_bcb_store(struct cmd_tbl *cmdtp, int flag,
int argc,
return __bcb_store();
}
-int bcb_write_reboot_reason(int devnum, char *partp, char *reasonp)
+int bcb_write_reboot_reason(int devnum, char *partp, const char *reasonp)
{
int ret;
diff --git a/include/bcb.h b/include/bcb.h
index 05db5935e0e7..c91edb91265a 100644
--- a/include/bcb.h
+++ b/include/bcb.h
@@ -11,9 +11,9 @@
#include
#if CONFIG_IS_ENABLED(CMD_BCB)
-int bcb_write_reboot_reason(int devnum, char *partp, char *reasonp);
+int bcb_write_reboot_reason(int devnum, char *partp, const char *reasonp);
#else
-static inline int bcb_write_reboot_reason(int devnum, char *partp, char
*reasonp)
+static inline int bcb_write_reboot_reason(int devnum, char *partp, const char
*reasonp)
{
return -EOPNOTSUPP;
}
--
2.17.1
[PATCH v2 4/7] cmd: bcb: Expose 'bcb_write_reboot_reason' to external callers
From: Eugeniu Rosca
Fastboot is evolving and beginning with commit [1], the
upstream implementation expects bootloaders to offer support for:
- reboot-recovery
- reboot-fastboot
The most natural way to achieve the above is through a set of
pre-defined "reboot reason" strings, written into / read from
the BCB "command" field, e.g.:
- bootonce-bootloader [2]
- boot-fastboot [3]
- boot-recovery [4]
Expose the first 'bcb' API meant to be called by e.g. fastboot stack,
to allow updating the BCB reboot reason via the BCB 'command' field.
[1] https://android.googlesource.com/platform/system/core/+/dea91b4b5354af2
("Add fastbootd.")
[2] https://android.googlesource.com/platform/bootable/recovery/+/cba7fa88d8b9
("Add 'reboot bootloader' to bootloader_message.")
[3] https://android.googlesource.com/platform/bootable/recovery/+/eee4e260f9f6
("recovery: Add "boot-fastboot" command to BCB.")
[4] https://android.googlesource.com/platform/system/core/+/5e98b633a748695f
("init: Write the reason in BCB on "reboot recovery"")
Signed-off-by: Eugeniu Rosca
Signed-off-by: Roman Kovalivskyi
---
cmd/bcb.c | 20
include/bcb.h | 22 ++
2 files changed, 42 insertions(+)
create mode 100644 include/bcb.h
diff --git a/cmd/bcb.c b/cmd/bcb.c
index b9cd20ea3d56..5da3526142ad 100644
--- a/cmd/bcb.c
+++ b/cmd/bcb.c
@@ -6,6 +6,7 @@
*/
#include
+#include
#include
#include
#include
@@ -307,6 +308,25 @@ static int do_bcb_store(struct cmd_tbl *cmdtp, int flag,
int argc,
return __bcb_store();
}
+int bcb_write_reboot_reason(int devnum, char *partp, char *reasonp)
+{
+ int ret;
+
+ ret = __bcb_load(devnum, partp);
+ if (ret != CMD_RET_SUCCESS)
+ return ret;
+
+ ret = __bcb_set("command", reasonp);
+ if (ret != CMD_RET_SUCCESS)
+ return ret;
+
+ ret = __bcb_store();
+ if (ret != CMD_RET_SUCCESS)
+ return ret;
+
+ return 0;
+}
+
static struct cmd_tbl cmd_bcb_sub[] = {
U_BOOT_CMD_MKENT(load, CONFIG_SYS_MAXARGS, 1, do_bcb_load, "", ""),
U_BOOT_CMD_MKENT(set, CONFIG_SYS_MAXARGS, 1, do_bcb_set, "", ""),
diff --git a/include/bcb.h b/include/bcb.h
new file mode 100644
index ..05db5935e0e7
--- /dev/null
+++ b/include/bcb.h
@@ -0,0 +1,22 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2020 Eugeniu Rosca
+ *
+ * Android Bootloader Control Block Header
+ */
+
+#ifndef __BCB_H__
+#define __BCB_H__
+
+#include
+
+#if CONFIG_IS_ENABLED(CMD_BCB)
+int bcb_write_reboot_reason(int devnum, char *partp, char *reasonp);
+#else
+static inline int bcb_write_reboot_reason(int devnum, char *partp, char
*reasonp)
+{
+ return -EOPNOTSUPP;
+}
+#endif
+
+#endif /* __BCB_H__ */
--
2.17.1
[PATCH v2 3/7] cmd: bcb: Extract '__bcb_store' from 'do_bcb_store' for internal needs
From: Eugeniu Rosca
Enriching the functionality of U-Boot 'bcb' may assume using the
existing sub-commands as building blocks for the next ones.
A clean way to achive the above is to expose a number of static
routines, each mapped to an existing user command (e.g. load/set/store),
with a user/caller-friendly prototype (i.e. do not force the caller
to wrap an integer into a string).
This third patch makes '__bcb_store' available for internal needs.
No functional change intended.
Signed-off-by: Eugeniu Rosca
Signed-off-by: Roman Kovalivskyi
---
cmd/bcb.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/cmd/bcb.c b/cmd/bcb.c
index 113f04ffe6b2..b9cd20ea3d56 100644
--- a/cmd/bcb.c
+++ b/cmd/bcb.c
@@ -270,8 +270,7 @@ static int do_bcb_dump(struct cmd_tbl *cmdtp, int flag, int
argc,
return CMD_RET_SUCCESS;
}
-static int do_bcb_store(struct cmd_tbl *cmdtp, int flag, int argc,
- char *const argv[])
+static int __bcb_store(void)
{
struct blk_desc *desc;
struct disk_partition info;
@@ -302,6 +301,12 @@ err:
return CMD_RET_FAILURE;
}
+static int do_bcb_store(struct cmd_tbl *cmdtp, int flag, int argc,
+ char * const argv[])
+{
+ return __bcb_store();
+}
+
static struct cmd_tbl cmd_bcb_sub[] = {
U_BOOT_CMD_MKENT(load, CONFIG_SYS_MAXARGS, 1, do_bcb_load, "", ""),
U_BOOT_CMD_MKENT(set, CONFIG_SYS_MAXARGS, 1, do_bcb_set, "", ""),
--
2.17.1
[PATCH v2 2/7] cmd: bcb: Extract '__bcb_set' from 'do_bcb_set' for internal needs
From: Eugeniu Rosca
Enriching the functionality of U-Boot 'bcb' may assume using the
existing sub-commands as building blocks for the next ones.
A clean way to achive the above is to expose a number of static
routines, each mapped to an existing user command (e.g. load/set/store),
with a user/caller-friendly prototype (i.e. do not force the caller
to wrap an integer into a string).
This second patch makes '__bcb_set' available for internal needs.
No functional change intended.
Signed-off-by: Eugeniu Rosca
Signed-off-by: Roman Kovalivskyi
---
cmd/bcb.c | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/cmd/bcb.c b/cmd/bcb.c
index 2ed8b801a3e2..113f04ffe6b2 100644
--- a/cmd/bcb.c
+++ b/cmd/bcb.c
@@ -178,22 +178,21 @@ static int do_bcb_load(struct cmd_tbl *cmdtp, int flag,
int argc,
return __bcb_load(devnum, argv[2]);
}
-static int do_bcb_set(struct cmd_tbl *cmdtp, int flag, int argc,
- char *const argv[])
+static int __bcb_set(char *fieldp, char *valp)
{
int size, len;
char *field, *str, *found;
- if (bcb_field_get(argv[1], , ))
+ if (bcb_field_get(fieldp, , ))
return CMD_RET_FAILURE;
- len = strlen(argv[2]);
+ len = strlen(valp);
if (len >= size) {
printf("Error: sizeof('%s') = %d >= %d = sizeof(bcb.%s)\n",
- argv[2], len, size, argv[1]);
+ valp, len, size, fieldp);
return CMD_RET_FAILURE;
}
- str = argv[2];
+ str = valp;
field[0] = '\0';
while ((found = strsep(, ":"))) {
@@ -205,6 +204,12 @@ static int do_bcb_set(struct cmd_tbl *cmdtp, int flag, int
argc,
return CMD_RET_SUCCESS;
}
+static int do_bcb_set(struct cmd_tbl *cmdtp, int flag, int argc,
+ char * const argv[])
+{
+ return __bcb_set(argv[1], argv[2]);
+}
+
static int do_bcb_clear(struct cmd_tbl *cmdtp, int flag, int argc,
char *const argv[])
{
--
2.17.1
[PATCH v2 1/7] cmd: bcb: Extract '__bcb_load' from 'do_bcb_load' for internal needs
From: Eugeniu Rosca
Enriching the functionality of U-Boot 'bcb' may assume using the
existing sub-commands as building blocks for the next ones.
A clean way to achive the above is to expose a number of static
routines, each mapped to an existing user command (e.g. load/set/store),
with a user/caller-friendly prototype (i.e. do not force the caller
to wrap an integer into a string).
This first patch makes '__bcb_load' available for internal needs.
No functional change, except for a tiny update in error handling.
Signed-off-by: Eugeniu Rosca
Signed-off-by: Roman Kovalivskyi
---
cmd/bcb.c | 31 +++
1 file changed, 23 insertions(+), 8 deletions(-)
diff --git a/cmd/bcb.c b/cmd/bcb.c
index e03218066bf2..2ed8b801a3e2 100644
--- a/cmd/bcb.c
+++ b/cmd/bcb.c
@@ -110,8 +110,7 @@ static int bcb_field_get(char *name, char **fieldp, int
*sizep)
return 0;
}
-static int do_bcb_load(struct cmd_tbl *cmdtp, int flag, int argc,
- char *const argv[])
+static int __bcb_load(int devnum, const char *partp)
{
struct blk_desc *desc;
struct disk_partition info;
@@ -119,17 +118,19 @@ static int do_bcb_load(struct cmd_tbl *cmdtp, int flag,
int argc,
char *endp;
int part, ret;
- ret = blk_get_device_by_str("mmc", argv[1], );
- if (ret < 0)
+ desc = blk_get_devnum_by_type(IF_TYPE_MMC, devnum);
+ if (!desc) {
+ ret = -ENODEV;
goto err_read_fail;
+ }
- part = simple_strtoul(argv[2], , 0);
+ part = simple_strtoul(partp, , 0);
if (*endp == '\0') {
ret = part_get_info(desc, part, );
if (ret)
goto err_read_fail;
} else {
- part = part_get_info_by_name(desc, argv[2], );
+ part = part_get_info_by_name(desc, partp, );
if (part < 0) {
ret = part;
goto err_read_fail;
@@ -151,10 +152,10 @@ static int do_bcb_load(struct cmd_tbl *cmdtp, int flag,
int argc,
return CMD_RET_SUCCESS;
err_read_fail:
- printf("Error: mmc %s:%s read failed (%d)\n", argv[1], argv[2], ret);
+ printf("Error: mmc %d:%s read failed (%d)\n", devnum, partp, ret);
goto err;
err_too_small:
- printf("Error: mmc %s:%s too small!", argv[1], argv[2]);
+ printf("Error: mmc %d:%s too small!", devnum, partp);
goto err;
err:
bcb_dev = -1;
@@ -163,6 +164,20 @@ err:
return CMD_RET_FAILURE;
}
+static int do_bcb_load(struct cmd_tbl *cmdtp, int flag, int argc,
+ char * const argv[])
+{
+ char *endp;
+ int devnum = simple_strtoul(argv[1], , 0);
+
+ if (*endp != '\0') {
+ printf("Error: Device id '%s' not a number\n", argv[1]);
+ return CMD_RET_FAILURE;
+ }
+
+ return __bcb_load(devnum, argv[2]);
+}
+
static int do_bcb_set(struct cmd_tbl *cmdtp, int flag, int argc,
char *const argv[])
{
--
2.17.1
[PATCH v2 0/7] Refactor generic fastboot_set_reboot_flag implementation
Current generic implementation of fastboot_set_reboot_flag is somewhat messy and requires some additional configuration option to be enabled besides CMD_BCB, so it reverts that implementtion in order to bring a new cleaner one. New function called bcb_set_reboot_reason should be exposed by BCB commands, so that all of the details could be put there instead of dealing with it in fastboot implementation directly. After that, fastboot_set_reboot_flag could simply pass correct reboot reason string to the BCB implementation. If CMD_BCB is disabled then the whole operation would return error code, which is no different behaviour than the current implementation. Changes since v1[1] * Fixed compilation issue for sandbox platform caused by undefined FASTBOOT_FLASH_MMC_DEV Kconfig option. * Fixed compilation issue in bcb.h caused by missing common.h header for sandbox platform [1]: https://patchwork.ozlabs.org/project/uboot/cover/cover.1603442753.git.roman.kovalivs...@globallogic.com/ Eugeniu Rosca (5): cmd: bcb: Extract '__bcb_load' from 'do_bcb_load' for internal needs cmd: bcb: Extract '__bcb_set' from 'do_bcb_set' for internal needs cmd: bcb: Extract '__bcb_store' from 'do_bcb_store' for internal needs cmd: bcb: Expose 'bcb_write_reboot_reason' to external callers cmd: bcb: Add support for processing const string literals in bcb_set() Roman Kovalivskyi (2): Revert "fastboot: Add default fastboot_set_reboot_flag implementation" fastboot: Implement generic fastboot_set_reboot_flag cmd/bcb.c | 88 +++--- drivers/fastboot/Kconfig | 12 - drivers/fastboot/Makefile | 1 - drivers/fastboot/fb_bcb_impl.c | 43 - drivers/fastboot/fb_common.c | 16 ++- include/bcb.h | 22 + include/fastboot.h | 9 7 files changed, 107 insertions(+), 84 deletions(-) delete mode 100644 drivers/fastboot/fb_bcb_impl.c create mode 100644 include/bcb.h -- 2.17.1
[PATCH v2 4/4] doc: update Kernel documentation build system
Update the documentation build system according to Linux v5.11-rc1.
Deactive the automarkup.py extension module which on Gitlab CI is
incompatible with Unicode.
With this patch we can build the HTML documentation using either of
Sphinx 2 and Sphinx 3.
Signed-off-by: Heinrich Schuchardt
---
v2:
Deactive the automarkup.py extension module
---
doc/conf.py | 141 --
doc/sphinx/automarkup.py | 290 +++
doc/sphinx/cdomain.py | 93 +-
doc/sphinx/kernel_abi.py | 194 +
doc/sphinx/kernel_feat.py | 169 +++
doc/sphinx/kerneldoc.py | 15 +-
doc/sphinx/kernellog.py | 6 +-
doc/sphinx/kfigure.py | 6 +-
doc/sphinx/load_config.py | 27 +-
doc/sphinx/maintainers_include.py | 197 +
doc/sphinx/parallel-wrapper.sh| 33 +++
doc/sphinx/parse-headers.pl | 6 +-
doc/sphinx/requirements.txt | 5 +-
scripts/kernel-doc| 450 ++
14 files changed, 1476 insertions(+), 156 deletions(-)
create mode 100644 doc/sphinx/automarkup.py
create mode 100644 doc/sphinx/kernel_abi.py
create mode 100644 doc/sphinx/kernel_feat.py
create mode 100755 doc/sphinx/maintainers_include.py
create mode 100644 doc/sphinx/parallel-wrapper.sh
diff --git a/doc/conf.py b/doc/conf.py
index ee7f201724..3f456a18f5 100644
--- a/doc/conf.py
+++ b/doc/conf.py
@@ -16,6 +16,8 @@ import sys
import os
import sphinx
+from subprocess import check_output
+
# Get Sphinx version
major, minor, patch = sphinx.version_info[:3]
@@ -31,39 +33,98 @@ from load_config import loadConfig
# If your documentation needs a minimal Sphinx version, state it here.
needs_sphinx = '1.3'
-latex_engine = 'xelatex'
-
# Add any Sphinx extension module names here, as strings. They can be
# extensions coming with Sphinx (named 'sphinx.ext.*') or your custom
# ones.
-extensions = ['kerneldoc', 'rstFlatTable', 'kernel_include', 'kfigure']
+extensions = ['kerneldoc', 'rstFlatTable', 'kernel_include',
+ 'kfigure', 'sphinx.ext.ifconfig', # 'automarkup',
+ 'maintainers_include', 'sphinx.ext.autosectionlabel',
+ 'kernel_abi', 'kernel_feat']
#
-# cdomain is badly broken in Sphinx 3+. Leaving it out generates *most*
-# of the docs correctly, but not all.
+# cdomain is badly broken in Sphinx 3+. Leaving it out generates *most*
+# of the docs correctly, but not all. Scream bloody murder but allow
+# the process to proceed; hopefully somebody will fix this properly soon.
#
if major >= 3:
+sys.stderr.write('''WARNING: The kernel documentation build process
+support for Sphinx v3.0 and above is brand new. Be prepared for
+possible issues in the generated output.
+''')
if (major > 3) or (minor > 0 or patch >= 2):
-sys.stderr.write('''The build process with Sphinx 3+ is broken.
-You will have to remove -W in doc/Makefile.
-''')
# Sphinx c function parser is more pedantic with regards to type
# checking. Due to that, having macros at c:function cause problems.
-# Those needed to be escaped by using c_id_attributes[] array
+# Those needed to be scaped by using c_id_attributes[] array
c_id_attributes = [
-
-# include/linux/compiler.h
+# GCC Compiler types not parsed by Sphinx:
+"__restrict__",
+
+# include/linux/compiler_types.h:
+"__iomem",
+"__kernel",
+"noinstr",
+"notrace",
+"__percpu",
+"__rcu",
+"__user",
+
+# include/linux/compiler_attributes.h:
+"__alias",
+"__aligned",
+"__aligned_largest",
+"__always_inline",
+"__assume_aligned",
+"__cold",
+"__attribute_const__",
+"__copy",
+"__pure",
+"__designated_init",
+"__visible",
+"__printf",
+"__scanf",
+"__gnu_inline",
+"__malloc",
+"__mode",
+"__no_caller_saved_registers",
+"__noclone",
+"__nonstring",
+"__noreturn",
+"__packed",
+"__pure",
+"__section",
+"__always_unused",
"__maybe_unused",
+"__used",
+"__weak",
+"noinline",
# include/efi.h
"EFIAPI",
# include/efi_loader.h
"__efi_runtime",
+
+# include/linux/memblock.h:
+"__init_memblock",
+"__meminit",
+
+# include/linux/init.h:
+"__init",
+"__ref",
+
+# include/linux/linkage.h:
+"asmlinkage",
]
else:
extensions.append('cdomain')
+if major == 1 and minor < 7:
+
[PATCH v2 1/4] doc: board: fix Microchip MPFS Icicle Kit doc
Two sibling headings (here eMMC) cannot have the same title.
Warning, treated as error:
doc/board/microchip/mpfs_icicle.rst:423:duplicate label
board/microchip/mpfs_icicle:emmc, other instance in
doc/board/microchip/mpfs_icicle.rst
make[1]: *** [doc/Makefile:69: htmldocs] Error 2
* Correct the heading levels.
* Add missing empty lines after headings.
Fixes: 9e550e18305f ("doc: board: Add Microchip MPFS Icicle Kit doc")
Signed-off-by: Heinrich Schuchardt
---
v2:
no change
---
doc/board/microchip/mpfs_icicle.rst | 51 +++--
1 file changed, 33 insertions(+), 18 deletions(-)
diff --git a/doc/board/microchip/mpfs_icicle.rst
b/doc/board/microchip/mpfs_icicle.rst
index 7489761501..c71c2f3cab 100644
--- a/doc/board/microchip/mpfs_icicle.rst
+++ b/doc/board/microchip/mpfs_icicle.rst
@@ -5,6 +5,7 @@ Microchip PolarFire SoC Icicle Kit
RISC-V PolarFire SoC
+
The PolarFire SoC is the 4+1 64-bit RISC-V SoC from Microchip.
The Icicle Kit development platform is based on PolarFire SoC and capable
@@ -12,6 +13,7 @@ of running Linux.
Mainline support
+
The support for following drivers are already enabled:
1. NS16550 UART Driver.
@@ -23,7 +25,7 @@ Booting from eMMC using HSS
---
Building U-Boot
+~~~
1. Add the RISC-V toolchain to your PATH.
2. Setup ARCH & cross compilation environment variable:
@@ -36,7 +38,7 @@ Building U-Boot
4. make
Flashing
-
+
The current U-Boot port is supported in S-mode only and loaded from DRAM.
@@ -48,11 +50,13 @@ boot-flow) and OpenSBI generic platform fw_payload.bin
(with u-boot.bin embedded
as HSS payload (Custom boot-flow)
Microchip boot-flow
+~~~
+
HSS with OpenSBI (M-Mode) -> U-Boot (S-Mode) -> Linux (S-Mode)
Build the HSS (Hart Software Services) - Microchip boot-flow
-
+
+
(Note: HSS git repo is at
https://github.com/polarfire-soc/hart-software-services)
1. Configure
@@ -74,13 +78,15 @@ Alternatively, copy the default config for Microchip
boot-flow.
The FPGA design will use the hss.hex or hss.bin.
FPGA design with HSS programming file
--
+'
+
https://github.com/polarfire-soc/polarfire-soc-documentation/blob/master/boards/mpfs-icicle-kit-es/updating-icicle-kit/updating-icicle-kit-design-and-linux.md
The HSS firmware runs from the PolarFire SoC eNVM on reset.
Creating the HSS payload - Microchip boot-flow
---
+''
+
1. You will be creating a payload from `u-boot-dtb.bin`.
Copy this file to the HSS/tools/hss-payload-generator/test directory.
2. Go to hss-payload-generator source directory.
@@ -108,11 +114,12 @@ Please refer to HSS documenation to build the HSS
firmware for payload.
(Note: HSS git repo is at
https://github.com/polarfire-soc/hart-software-services/blob/master/tools/hss-payload-generator/README.md)
Custom boot-flow
-
+
+
HSS without OpenSBI (M-Mode) -> OpenSBI (M-Mode) -> U-Boot (S-Mode) -> Linux
(S-Mode)
Build OpenSBI
--
+'
1. Get the OpenSBI source
@@ -132,7 +139,8 @@ Build OpenSBI
"/build/platform/generic/firmware/fw_payload.bin"
Build the HSS (Hart Software Services)- Custom boot-flow
-
+
+
(Note: HSS git repo is at
https://github.com/polarfire-soc/hart-software-services)
1. Configure
@@ -154,7 +162,8 @@ Alternatively, copy the default custom config for Custom
boot-flow.
The FPGA design will use the hss.hex or hss.bin.
Creating the HSS payload - Custom boot-flow
+'''
+
1. You will be creating a payload from `fw_payload.bin`.
Copy this file to the HSS/tools/hss-payload-generator/test directory.
2. Go to hss-payload-generator source directory.
@@ -183,7 +192,8 @@ Please refer to HSS documenation to build the HSS firmware
for payload.
and also refer the HSS payload generator at
https://github.com/polarfire-soc/polarfire-soc-documentation/blob/master/software-development/hss-payloads.md)
eMMC
-
+
+
Program eMMC with payload binary is explained in the PolarFire SoC
documentation.
(Note: PolarFire SoC Documentation git repo is at
https://github.com/polarfire-soc/polarfire-soc-documentation/blob/master/boards/mpfs-icicle-kit-es/updating-icicle-kit/updating-icicle-kit-design-and-linux.md#eMMC)
@@ -195,17 +205,19 @@ line interface, then type 'boot' and enter to boot the
newly copied image.
sudo dd if= of=/dev/sdX bs=512
GUID type
--
+~
+
The HSS always
[PATCH v2 3/4] .gitlab-ci: install doc/sphinx/requirements.txt
Install all requirements according to doc/sphinx/requirements.txt in the virtual environment used for testing 'make htmldocs'. Signed-off-by: Heinrich Schuchardt --- v2: no change --- .azure-pipelines.yml | 6 +- .gitlab-ci.yml | 3 +++ 2 files changed, 8 insertions(+), 1 deletion(-) diff --git a/.azure-pipelines.yml b/.azure-pipelines.yml index 620696c22e..7a3eb78a5e 100644 --- a/.azure-pipelines.yml +++ b/.azure-pipelines.yml @@ -67,7 +67,11 @@ jobs: image: $(ci_runner_image) options: $(container_option) steps: - - script: make htmldocs + - script: | + virtualenv -p /usr/bin/python3 /tmp/venvhtml + . /tmp/venvhtml/bin/activate + pip install -r doc/sphinx/requirements.txt + make htmldocs - job: todo displayName: 'Search for TODO within source tree' diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml index 4b0680887b..2cdcd864c8 100644 --- a/.gitlab-ci.yml +++ b/.gitlab-ci.yml @@ -122,6 +122,9 @@ htmldocs: tags: [ 'all' ] stage: testsuites script: +- virtualenv -p /usr/bin/python3 /tmp/venvhtml +- . /tmp/venvhtml/bin/activate +- pip install -r doc/sphinx/requirements.txt - make htmldocs # some statistics about the code base -- 2.29.2
[PATCH v2 2/4] doc: fix doc/develop/logging.rst
Sphinx 3 builds fail due to doc/develop/logging.rst producing duplicate labels. Include logging.h only once in the API section and use cross-references for the enums log_level_t and log_category_t. Signed-off-by: Heinrich Schuchardt --- v2: no change --- doc/api/index.rst | 1 + doc/api/logging.rst | 6 ++ doc/develop/logging.rst | 13 +++-- 3 files changed, 10 insertions(+), 10 deletions(-) create mode 100644 doc/api/logging.rst diff --git a/doc/api/index.rst b/doc/api/index.rst index cbecd10755..ea02aa5715 100644 --- a/doc/api/index.rst +++ b/doc/api/index.rst @@ -10,6 +10,7 @@ U-Boot API documentation efi getopt linker_lists + logging pinctrl rng sandbox diff --git a/doc/api/logging.rst b/doc/api/logging.rst new file mode 100644 index 00..1e6cbc4931 --- /dev/null +++ b/doc/api/logging.rst @@ -0,0 +1,6 @@ +.. SPDX-License-Identifier: GPL-2.0+ + +Logging API +=== + +.. kernel-doc:: include/log.h diff --git a/doc/develop/logging.rst b/doc/develop/logging.rst index 7fdd1132ef..60c18c5b3a 100644 --- a/doc/develop/logging.rst +++ b/doc/develop/logging.rst @@ -26,8 +26,7 @@ Logging levels There are a number logging levels available. -.. kernel-doc:: include/log.h - :identifiers: log_level_t +See enum :c:type:`log_level_t` Logging category @@ -36,8 +35,7 @@ Logging can come from a wide variety of places within U-Boot. Each log message has a category which is intended to allow messages to be filtered according to their source. -.. kernel-doc:: include/log.h - :identifiers: log_category_t +See enum :c:type:`log_category_t` Enabling logging @@ -67,7 +65,7 @@ to enable building in of all logging statements in a single file. Put it at the top of the file, before any #includes. To actually get U-Boot to output this you need to also set the default logging -level - e.g. set CONFIG_LOG_DEFAULT_LEVEL to 7 (:c:type:`LOGL_DEBUG`) or more. +level - e.g. set CONFIG_LOG_DEFAULT_LEVEL to 7 (:c:data:`LOGL_DEBUG`) or more. Otherwise debug output is suppressed and will not be generated. Using DEBUG @@ -290,8 +288,3 @@ number dropped due to them being generated before the log system was ready. Add a printf() format string pragma so that log statements are checked properly Add a command to delete existing log records. - -Logging API -.. kernel-doc:: include/log.h - :internal: -- 2.29.2
[PATCH v2 0/4] doc: update Kernel documentation build system
Update the documentation build system according to Linux v5.11-rc1. Deactive the automarkup.py extension module which on Gitlab CI is incompatible with Unicode. With this patch we can build the HTML documentation using either of Sphinx 2 and Sphinx 3. Fix two non-conformant documents. Heinrich Schuchardt (4): doc: board: fix Microchip MPFS Icicle Kit doc doc: fix doc/develop/logging.rst .gitlab-ci: install doc/sphinx/requirements.txt doc: update Kernel documentation build system .azure-pipelines.yml| 6 +- .gitlab-ci.yml | 3 + doc/api/index.rst | 1 + doc/api/logging.rst | 6 + doc/board/microchip/mpfs_icicle.rst | 51 ++-- doc/conf.py | 141 +++-- doc/develop/logging.rst | 13 +- doc/sphinx/automarkup.py| 290 ++ doc/sphinx/cdomain.py | 93 +- doc/sphinx/kernel_abi.py| 194 doc/sphinx/kernel_feat.py | 169 +++ doc/sphinx/kerneldoc.py | 15 +- doc/sphinx/kernellog.py | 6 +- doc/sphinx/kfigure.py | 6 +- doc/sphinx/load_config.py | 27 +- doc/sphinx/maintainers_include.py | 197 doc/sphinx/parallel-wrapper.sh | 33 ++ doc/sphinx/parse-headers.pl | 6 +- doc/sphinx/requirements.txt | 5 +- scripts/kernel-doc | 450 +--- 20 files changed, 1527 insertions(+), 185 deletions(-) create mode 100644 doc/api/logging.rst create mode 100644 doc/sphinx/automarkup.py create mode 100644 doc/sphinx/kernel_abi.py create mode 100644 doc/sphinx/kernel_feat.py create mode 100755 doc/sphinx/maintainers_include.py create mode 100644 doc/sphinx/parallel-wrapper.sh -- 2.29.2
arm: rk3399: add support nanopi r4s
>From 0c1b6b9c696f7bbdb91119af033e598e4b8d2f81 Mon Sep 17 00:00:00 2001
From: Xiaobo Tian
Date: Sat, 26 Dec 2020 00:13:37 +0800
Subject: [PATCH] arm: rk3399: add support nanopi r4s
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
SoC – Rockchip RK3399 hexa-core processor with dual-Core Cortex-A72 up to
2.0GHz, quad-core Cortex-A53 up to 1.5GHz, Mali-T864 GPU with OpenGL
ES1.1/2.0/3.0/3.1, OpenCL, DX11, and AFBC support, 4K VP9 and 4K 10-bit
H265/H264 60fps video decoder
System Memory – 1GB DDR3 or 4GB LPDDR4
Storage – MicroSD card slot
Networking – 2x GbE(RTL8211E 1Gbps - RTL8111H 1Gbps), including one native
Gigabit Ethernet, and one PCIe Gigabit Ethernet
USB – 2x USB 3.0 Type-A ports, USB 2.0 via 4-pin header
Expansion – 2×5-pin header with 1x SPI, 1x I2C
Debugging – 3-pin debug UART header
Misc- 1x power LED, and 3x user LEDs (SYS, LAN, WAN), user button, 2-pin
RTC battery connector, 5V fan connector
Power Supply
5V/3A via USB-C connector or pin header
RK808-D PMIC and independent DC/DC enabling DVFS, software power-down, RTC
wake-up, system sleep mode
Dimensions – 66 x 66 mm (8-layer PCB)
Temperature Range – -20°C to 70°C
The detailed information for NanoPi R4S <
https://wiki.friendlyarm.com/wiki/index.php/NanoPi_R4S>
Signed-off-by: Xiaobo Tian
---
arch/arm/dts/Makefile | 1 +
arch/arm/dts/rk3399-nanopi-r4s-u-boot.dtsi | 7 ++
arch/arm/dts/rk3399-nanopi-r4s.dts | 120 +
configs/nanopi-r4s-rk3399_defconfig| 62 +++
4 files changed, 190 insertions(+)
create mode 100644 arch/arm/dts/rk3399-nanopi-r4s-u-boot.dtsi
create mode 100644 arch/arm/dts/rk3399-nanopi-r4s.dts
create mode 100644 configs/nanopi-r4s-rk3399_defconfig
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index e320c2254e..507b1e4ec9 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -92,6 +92,7 @@ dtb-$(CONFIG_ROCKCHIP_RK3288) += \
rk3288-evb.dtb \
rk3288-firefly.dtb \
rk3288-miqi.dtb \
+ rk3399-nanopi-r4s.dtb \
rk3288-phycore-rdk.dtb \
rk3288-popmetal.dtb \
rk3288-rock2-square.dtb \
diff --git a/arch/arm/dts/rk3399-nanopi-r4s-u-boot.dtsi
b/arch/arm/dts/rk3399-nanopi-r4s-u-boot.dtsi
new file mode 100644
index 00..05f785e662
--- /dev/null
+++ b/arch/arm/dts/rk3399-nanopi-r4s-u-boot.dtsi
@@ -0,0 +1,7 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2020 Xiaobo
+ */
+
+#include "rk3399-nanopi4-u-boot.dtsi"
+#include "rk3399-sdram-lpddr4-100.dtsi"
diff --git a/arch/arm/dts/rk3399-nanopi-r4s.dts
b/arch/arm/dts/rk3399-nanopi-r4s.dts
new file mode 100644
index 00..5c65447f0e
--- /dev/null
+++ b/arch/arm/dts/rk3399-nanopi-r4s.dts
@@ -0,0 +1,120 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2020 FriendlyElec Computer Tech. Co., Ltd.
+ * (http://www.friendlyarm.com)
+ *
+ * Copyright (C) 2020 Xiaobo
+ */
+
+/dts-v1/;
+#include "rk3399-nanopi4.dtsi"
+
+/ {
+ model = "FriendlyElec NanoPi R4S";
+ compatible = "friendlyarm,nanopi-r4s", "rockchip,rk3399";
+
+ vdd_5v: vdd-5v {
+ compatible = "regulator-fixed";
+ regulator-name = "vdd_5v";
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ fan: pwm-fan {
+ compatible = "pwm-fan";
+ /* FIXME: adjust leveles for the connected fan */
+ cooling-levels = <0 12 18 255>;
+ #cooling-cells = <2>;
+ fan-supply = <_5v>;
+ pwms = < 0 5 0>;
+ };
+};
+
+_thermal {
+ trips {
+ cpu_warm: cpu_warm {
+ temperature = <55000>;
+ hysteresis = <2000>;
+ type = "active";
+ };
+
+ cpu_hot: cpu_hot {
+ temperature = <65000>;
+ hysteresis = <2000>;
+ type = "active";
+ };
+ };
+
+ cooling-maps {
+ map2 {
+ trip = <_warm>;
+ cooling-device = < THERMAL_NO_LIMIT 1>;
+ };
+
+ map3 {
+ trip = <_hot>;
+ cooling-device = < 2 THERMAL_NO_LIMIT>;
+ };
+ };
+};
+
+_phy {
+ status = "disabled";
+};
+
+ {
+ status = "disabled";
+};
+
+ {
+ lan_led: led-1 {
+ gpios = < RK_PA1 GPIO_ACTIVE_HIGH>;
+ label = "nanopi-r4s:green:lan";
+ };
+
+ wan_led: led-2 {
+ gpios = < RK_PA0 GPIO_ACTIVE_HIGH>;
+ label = "nanopi-r4s:green:wan";
+ };
+};
+
+_gpio {
+ rockchip,pins =
+ <0 RK_PB5 RK_FUNC_GPIO _pull_none>,
+ <1 RK_PA0 RK_FUNC_GPIO _pull_none>,
+ <1 RK_PA1 RK_FUNC_GPIO _pull_none>;
+};
+
+ {
+ max-link-speed = <1>;
+ num-lanes = <1>;
+ vpcie3v3-supply = <_sys>;
+};
+
+ {
+ status = "disabled";
+};
+
+ {
+ status = "disabled";
+};
+
+ {
+ host-index-min = <1>;
+};
+
+_host {
+ phy-supply = <_5v>;
+};
+
+_host {
+ status = "disabled";
+};
+
+_dwc3_0 {
+ dr_mode = "host";
+};
+
+_sys {
+ vin-supply = <_sys>;
+};
diff --git a/configs/nanopi-r4s-rk3399_defconfig
b/configs/nanopi-r4s-rk3399_defconfig
new file mode 100644
index 00..0a3c28b012
--- /dev/null
+++ b/configs/nanopi-r4s-rk3399_defconfig
@@ -0,0 +1,62 @@
+CONFIG_ARM=y
+CONFIG_ARCH_ROCKCHIP=y
+CONFIG_SYS_TEXT_BASE=0x0020
+CONFIG_ENV_OFFSET=0x3F8000
+CONFIG_ROCKCHIP_RK3399=y
+CONFIG_TARGET_EVB_RK3399=y
+CONFIG_NR_DRAM_BANKS=1
+CONFIG_DEBUG_UART_BASE=0xFF1A
Re: [PATCH 1/4] Respect that some compression algos can be enabled separately for SPL
On Sat, Jan 23, 2021 at 4:39 AM Stefano Babic wrote:
>
> Hi Tim,
>
> there is a weird side effect with this patch, breaking m68k
> architecture. For some reason, image.c is not compiled clean because gd
> is not declared anymore.
>
> In file included from tools/common/image.c:1:
> ./tools/../common/image.c: In function ‘get_table_entry_id’:
> ./tools/../common/image.c:982:41: error: ‘gd’ undeclared (first use in
> this function)
> 982 | if (t->sname && strcasecmp(t->sname + gd->reloc_off, name) == 0)
> | ^~
> ./tools/../common/image.c:982:41: note: each undeclared identifier is
> reported only once for each functi
>
> Can you take a look ? Thanks !
>
Stefano,
I have no idea what could cause this... must be something to do with
including kconfig.h?
What board/target would I build to reproduce this?
Frieder, do you have any ideas?
Tim
> Best regards,
> Stefano
>
> On 13.01.21 18:00, Tim Harvey wrote:
> > From: Frieder Schrempf
> >
> > Some compression algorithms currently can be enabled for SPL and
> > U-Boot proper separately. Therefore we need to use
> > CONFIG_IS_ENABLED() in these cases and also prevent compiling these
> > functions in case of a host tool build.
> >
> > Signed-off-by: Frieder Schrempf > Signed-off-by: Tim Harvey
> > ---
> > common/image.c | 13 +++--
> > 1 file changed, 7 insertions(+), 6 deletions(-)
> >
> > diff --git a/common/image.c b/common/image.c
> > index 451fc68..bda19c0 100644
> > --- a/common/image.c
> > +++ b/common/image.c
> > @@ -72,6 +72,7 @@ static const image_header_t *image_get_ramdisk(ulong
> > rd_addr, uint8_t arch,
> >
> > #include
> > #include
> > +#include
> >
> > #ifndef CONFIG_SYS_BARGSIZE
> > #define CONFIG_SYS_BARGSIZE 512
> > @@ -460,13 +461,13 @@ int image_decomp(int comp, ulong load, ulong
> > image_start, int type,
> > else
> > ret = -ENOSPC;
> > break;
> > -#ifdef CONFIG_GZIP
> > +#if CONFIG_IS_ENABLED(GZIP) && !defined(USE_HOSTCC)
> > case IH_COMP_GZIP: {
> > ret = gunzip(load_buf, unc_len, image_buf, _len);
> > break;
> > }
> > #endif /* CONFIG_GZIP */
> > -#ifdef CONFIG_BZIP2
> > +#if CONFIG_IS_ENABLED(BZIP2) && !defined(USE_HOSTCC)
> > case IH_COMP_BZIP2: {
> > uint size = unc_len;
> >
> > @@ -482,7 +483,7 @@ int image_decomp(int comp, ulong load, ulong
> > image_start, int type,
> > break;
> > }
> > #endif /* CONFIG_BZIP2 */
> > -#ifdef CONFIG_LZMA
> > +#if CONFIG_IS_ENABLED(LZMA) && !defined(USE_HOSTCC)
> > case IH_COMP_LZMA: {
> > SizeT lzma_len = unc_len;
> >
> > @@ -492,7 +493,7 @@ int image_decomp(int comp, ulong load, ulong
> > image_start, int type,
> > break;
> > }
> > #endif /* CONFIG_LZMA */
> > -#ifdef CONFIG_LZO
> > +#if CONFIG_IS_ENABLED(LZO) && !defined(USE_HOSTCC)
> > case IH_COMP_LZO: {
> > size_t size = unc_len;
> >
> > @@ -501,7 +502,7 @@ int image_decomp(int comp, ulong load, ulong
> > image_start, int type,
> > break;
> > }
> > #endif /* CONFIG_LZO */
> > -#ifdef CONFIG_LZ4
> > +#if CONFIG_IS_ENABLED(LZ4) && !defined(USE_HOSTCC)
> > case IH_COMP_LZ4: {
> > size_t size = unc_len;
> >
> > @@ -510,7 +511,7 @@ int image_decomp(int comp, ulong load, ulong
> > image_start, int type,
> > break;
> > }
> > #endif /* CONFIG_LZ4 */
> > -#ifdef CONFIG_ZSTD
> > +#if CONFIG_IS_ENABLED(ZSTD) && !defined(USE_HOSTCC)
> > case IH_COMP_ZSTD: {
> > size_t size = unc_len;
> > ZSTD_DStream *dstream;
> >
>
>
> --
> =
> DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
> =
Re: [scan-ad...@coverity.com: New Defects reported by Coverity Scan for Das U-Boot]
On Thu, Jan 21, 2021 at 11:09:16AM +0900, AKASHI Takahiro wrote:
> Tom,
>
> Regarding EFI capsule update,
[snip]
> > > ** CID 316360: Uninitialized variables (UNINIT)
> > > /tools/mkeficapsule.c: 298 in create_fwbin()
> > >
> > >
> > >
> > > *** CID 316360: Uninitialized variables (UNINIT)
> > > /tools/mkeficapsule.c: 298 in create_fwbin()
> > > 292 goto err_3;
> > > 293 }
> > > 294
> > > 295 capsule.version = 0x0001;
> > > 296 capsule.embedded_driver_count = 0;
> > > 297 capsule.payload_item_count = 1;
> > > > > > CID 316360: Uninitialized variables (UNINIT)
> > > > > > Using uninitialized value "capsule". Field
> > > > > > "capsule.item_offset_list" is uninitialized when calling "fwrite".
> > > 298 size = fwrite(, 1, sizeof(capsule), f);
>
> This code is safe because capsule.item_offset_list is actually
> defined as "item_offset_list[]" (null array) at the end of the structure
> and the data will be filled in by the succeeding fwrite()'s.
>
> What action should be taken to suppress this warning?
>
> > > 299 if (size < (sizeof(capsule))) {
> > > 300 printf("write failed (%lx)\n", size);
> > > 301 goto err_3;
> > > 302 }
> > > 303 offset = sizeof(capsule) + sizeof(u64);
> > >
> > > ** CID 316359: Null pointer dereferences (FORWARD_NULL)
> > >
> > >
> > >
> > > *** CID 316359: Null pointer dereferences (FORWARD_NULL)
> > > /lib/efi_loader/efi_capsule.c: 380 in efi_capsule_update_firmware()
> > > 374 ret = EFI_UNSUPPORTED;
> > > 375 goto out;
> > > 376 }
> > > 377
> > > 378 /* find a device for update firmware */
> > > 379 /* TODO: should we pass index as well, or nothing but
> > > type? */
> > > > > > CID 316359: Null pointer dereferences (FORWARD_NULL)
> > > > > > Passing null pointer "handles" to "efi_fmp_find", which
> > > > > > dereferences it.
> > > 380 fmp = efi_fmp_find(>update_image_type_id,
> > > 381 image->update_hardware_instance,
> > > 382 handles, no_handles);
>
> This code is safe because "handles" is actually an array of pointers
> and "no_handles" indicates the number of elements in this array.
> efi_fmp_find() will not dereference handles at all if no_handles is zero.
>
> What action should be taken to suppress this warning?
I've updated Coverity to list both of these as intentional / ignore,
thanks.
--
Tom
signature.asc
Description: PGP signature
[PATCH v2 1/1] doc: exception command
Create man-page for exception command. Signed-off-by: Heinrich Schuchardt --- v2: add missing exception.rst --- doc/usage/exception.rst | 68 + doc/usage/index.rst | 1 + 2 files changed, 69 insertions(+) create mode 100644 doc/usage/exception.rst diff --git a/doc/usage/exception.rst b/doc/usage/exception.rst new file mode 100644 index 00..412a03ba0f --- /dev/null +++ b/doc/usage/exception.rst @@ -0,0 +1,68 @@ +exception command += + +Synopsis + + +:: + +exception + +Description +--- + +The exception command is used to test the handling of exceptions like undefined +instructions, segmentation faults or alignment faults. + +type + type of exception to be generated. The available types are architecture + dependent. Use 'help exception' to determine which are available. + + **ARM:** + + breakpoint +prefetch abort + + unaligned +data abort + + undefined +undefined instruction + + **RISC-V:** + + unaligned +load address misaligned + + undefined +undefined instruction + + **Sandbox:** + + sigsegv +illegal memory access + + undefined +undefined instruction + + **x86:** + + undefined +undefined instruction + +Examples + + +:: + +=> exception undefined + +Illegal instruction +pc = 0x56076dd1a0f9, pc_reloc = 0x540f9 + +resetting ... + +Return value + + +The return value $? is always set to 0 (true). diff --git a/doc/usage/index.rst b/doc/usage/index.rst index f75bd08237..83cfbafd90 100644 --- a/doc/usage/index.rst +++ b/doc/usage/index.rst @@ -19,6 +19,7 @@ Shell commands button conitrace echo + exception exit false for -- 2.29.2
[PATCH 1/1] doc: exception command
Create man-page for exception command. Signed-off-by: Heinrich Schuchardt --- doc/usage/index.rst | 1 + 1 file changed, 1 insertion(+) diff --git a/doc/usage/index.rst b/doc/usage/index.rst index f75bd08237..83cfbafd90 100644 --- a/doc/usage/index.rst +++ b/doc/usage/index.rst @@ -19,6 +19,7 @@ Shell commands button conitrace echo + exception exit false for -- 2.29.2
[PATCH] cmd: pwm: Rework argc sanity checking
Currently, we check argc in a number of places to make sure that we have
all of the required arguments for each of the pwm sub-commands.
However, there's at least one place where we've got dead code as we'll
never have argc == 0, due to checking that argc was at least 4 earlier
and having only subtracted 3. Rework things so that when we have
determined our subcommand make sure we have the right number of
arguments for it, or error out. This means we can stop checking against
argc again later.
Reported-by: Coverity (CID: 316601)
Cc: Pragnesh Patel
Signed-off-by: Tom Rini
---
cmd/pwm.c | 41 +++--
1 file changed, 19 insertions(+), 22 deletions(-)
diff --git a/cmd/pwm.c b/cmd/pwm.c
index 5849fc57b666..e1f97c759d2c 100644
--- a/cmd/pwm.c
+++ b/cmd/pwm.c
@@ -34,11 +34,9 @@ static int do_pwm(struct cmd_tbl *cmdtp, int flag, int argc,
argc -= 2;
argv += 2;
- if (argc > 0) {
- str_pwm = *argv;
- argc--;
- argv++;
- }
+ str_pwm = *argv;
+ argc--;
+ argv++;
if (!str_pwm)
return CMD_RET_USAGE;
@@ -46,15 +44,23 @@ static int do_pwm(struct cmd_tbl *cmdtp, int flag, int argc,
switch (*str_cmd) {
case 'i':
sub_cmd = PWM_SET_INVERT;
+ if (argc != 2)
+ return CMD_RET_USAGE;
break;
case 'c':
sub_cmd = PWM_SET_CONFIG;
+ if (argc != 3)
+ return CMD_RET_USAGE;
break;
case 'e':
sub_cmd = PWM_SET_ENABLE;
+ if (argc != 1)
+ return CMD_RET_USAGE;
break;
case 'd':
sub_cmd = PWM_SET_DISABLE;
+ if (argc != 1)
+ return CMD_RET_USAGE;
break;
default:
return CMD_RET_USAGE;
@@ -67,38 +73,29 @@ static int do_pwm(struct cmd_tbl *cmdtp, int flag, int argc,
return cmd_process_error(cmdtp, ret);
}
- if (argc > 0) {
- str_channel = *argv;
- channel = simple_strtoul(str_channel, NULL, 10);
- argc--;
- argv++;
- } else {
- return CMD_RET_USAGE;
- }
+ str_channel = *argv;
+ channel = simple_strtoul(str_channel, NULL, 10);
+ argc--;
+ argv++;
- if (sub_cmd == PWM_SET_INVERT && argc > 0) {
+ if (sub_cmd == PWM_SET_INVERT) {
str_enable = *argv;
pwm_enable = simple_strtoul(str_enable, NULL, 10);
ret = pwm_set_invert(dev, channel, pwm_enable);
- } else if (sub_cmd == PWM_SET_CONFIG && argc == 2) {
+ } else if (sub_cmd == PWM_SET_CONFIG) {
str_period = *argv;
argc--;
argv++;
period_ns = simple_strtoul(str_period, NULL, 10);
- if (argc > 0) {
- str_duty = *argv;
- duty_ns = simple_strtoul(str_duty, NULL, 10);
- }
+ str_duty = *argv;
+ duty_ns = simple_strtoul(str_duty, NULL, 10);
ret = pwm_set_config(dev, channel, period_ns, duty_ns);
} else if (sub_cmd == PWM_SET_ENABLE) {
ret = pwm_set_enable(dev, channel, 1);
} else if (sub_cmd == PWM_SET_DISABLE) {
ret = pwm_set_enable(dev, channel, 0);
- } else {
- printf("PWM arguments missing\n");
- return CMD_RET_FAILURE;
}
if (ret) {
--
2.17.1
[scan-ad...@coverity.com: New Defects reported by Coverity Scan for Das U-Boot]
One new issue since the last time I ran this, and I think after reading
the code myself, argc counting / sanity checking should be handled a
little more clearly as well. I'm going to take a quick attempt at
updating this.
- Forwarded message from scan-ad...@coverity.com -
Date: Tue, 26 Jan 2021 14:49:09 + (UTC)
From: scan-ad...@coverity.com
To: tom.r...@gmail.com
Subject: New Defects reported by Coverity Scan for Das U-Boot
Hi,
Please find the latest report on new defect(s) introduced to Das U-Boot found
with Coverity Scan.
1 new defect(s) introduced to Das U-Boot found with Coverity Scan.
11 defect(s), reported by Coverity Scan earlier, were marked fixed in the
recent build analyzed by Coverity Scan.
New defect(s) Reported-by: Coverity Scan
Showing 1 of 1 defect(s)
** CID 316601: Control flow issues (DEADCODE)
/cmd/pwm.c: 76 in do_pwm()
*** CID 316601: Control flow issues (DEADCODE)
/cmd/pwm.c: 76 in do_pwm()
70 if (argc > 0) {
71 str_channel = *argv;
72 channel = simple_strtoul(str_channel, NULL, 10);
73 argc--;
74 argv++;
75 } else {
>>> CID 316601: Control flow issues (DEADCODE)
>>> Execution cannot reach this statement: "return CMD_RET_USAGE;".
76 return CMD_RET_USAGE;
77 }
78
79 if (sub_cmd == PWM_SET_INVERT && argc > 0) {
80 str_enable = *argv;
81 pwm_enable = simple_strtoul(str_enable, NULL, 10);
To view the defects in Coverity Scan visit,
https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P0qcxCbhZ31OYv50yoA22WlOQ-2By3ieUvdbKmOyw68TMVT4Kip-2BBzfOGWXJ5yIiYplmPF9KAnKIja4Zd7tU-3DLCWK_EEm8SbLgSDsaDZif-2Bv7ch8WqhKpLoKErHi4nXpwDNTuq9MPVHh3L32qrt5Ip1XnD-2FT7d2mqiVO5we8a7GYUflN8rPcFOvcPpmp7-2BHI-2FiMfMO0wZQJtLM0dmCxiZNLE1W2LBnroP7MP6w9NyH2xFZ9xER-2BYILtC7OORWk6E4iIWZD9NlPZovnnox2hXNU-2BrT4CJt7BMGDQWZi6SpY7EYshq4VQFMnD2W10PtfVsO5xns-3D
To manage Coverity Scan email notifications for "tom.r...@gmail.com", click
https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P0qcxCbhZ31OYv50yped04pjJnmXOsUBtKYNIXxWeIHzDeopm-2BEWQ6S6K-2FtUHv9ZTk8qZbuzkkz9sa-2BJFw4elYDyedRVZOC-2ButxjBZdouVmTGuWB6Aj6G7lm7t25-2Biv1B-2B9082pHzCCex2kqMs-3D96A1_EEm8SbLgSDsaDZif-2Bv7ch8WqhKpLoKErHi4nXpwDNTuq9MPVHh3L32qrt5Ip1XnD3WtWkNhMk8aqtcWpx18kz28O3aHVrPlQ7m76aTH42S-2FV-2BF-2BKKCm-2FUrVIBSGsRbPXbwCAkWzmG8EDOELQylE3c1UBFxOE6UpyBOxSvs1gNr-2BGyVbFqpLnYutK4cobU8DJEv-2BJRff57Ua6iETxKItKuhEjwidyxUp7lL-2FPx1HSxdY-3D
- End forwarded message -
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH 1/1] doc: update Kernel documentation build system
On Tue, Jan 26, 2021 at 04:28:24PM +0100, Heinrich Schuchardt wrote: > On 25.01.21 02:56, Simon Glass wrote: > > Hi, > > > > On Sun, 24 Jan 2021 at 18:37, Tom Rini wrote: > >> > >> On Mon, Jan 25, 2021 at 01:41:18AM +0100, Heinrich Schuchardt wrote: > >>> On 1/25/21 12:59 AM, Tom Rini wrote: > On Sun, Jan 24, 2021 at 10:05:27PM +0100, Heinrich Schuchardt wrote: > > On 1/23/21 6:53 PM, Tom Rini wrote: > >> On Sat, Jan 23, 2021 at 12:46:23PM -0500, Tom Rini wrote: > >>> On Fri, Jan 01, 2021 at 01:21:11AM +0100, Heinrich Schuchardt wrote: > >>> > Update the docomentation build system according to Linux v5.11-rc1. > > With this patch we can build the HTML documentation using either of > Sphinx 2 and Sphinx 3. > > Signed-off-by: Heinrich Schuchardt > Reviewed-by: Simon Glass > >>> > >>> Applied to u-boot/master, thanks! > >> > >> I've had to revert this. While I caught and fixed up in a semi-logical > >> way one duplicate label problem, there's another now that I see, and > >> probably many more once I rework that one. It's unclear as well how > >> best to handle these otherwise logical duplicate labels, such as "eMMC" > >> in doc/board/microchip/mpfs_icicle.rst for example. > > > > Sphinx 2 is not available for current Linux distributions. Without this > > patch we cannot build with Sphinx 3. > > We need to be careful when saying "current". Ubuntu 18.04 is still > quite current enough and will be until 2022 (as it doesn't go EOL until > 2023). I'm not sure I can even get Sphinx 3. > >>> > >>> Developers will not be able to test the documentation if 'make htmldocs' > >>> fails on their machines because their distribution does not provide > >>> Sphinx 2. > >>> > >>> The current Ubuntu release is 20.10 and provides Sphinx 3.2. > >>> https://packages.ubuntu.com/groovy/sphinx-common. > >>> > >>> Arch Linux is on Sphinx 3.4. > >>> https://archlinux.org/packages/community/any/python-sphinx/ > >> > >> And 18.04 is an LTS that doesn't go EOL until April 2023. Developers > >> will not be test their documentation if they don't have Sphinx 3 > >> available. Either side can do as Sean notes and use venv to provide > >> whatever, and we need to make the error in that case much clearer. I > >> would assume that the "still works with gcc-4.9!" Linux kernel has a bit > >> clearer of an error out in that case. If not perhaps they would take a > >> patch :) > >> > >> But much more importantly: > > All pages must be deduplicated. Instead of duplicate information > > references have to be used. > > So long as it can be done in a way where documentation reads well still, > yes. For example, how should we re-write the example I mentioned so > that "eMMC" isn't duplicated? > >> > >> Is what really needs to be solved. Show me how the document in question > >> gets updated to read well and not have the duplicated heading message. > > > > I agree we have to support Sphinx 2 for a while. So we need both! > > > > Minor niggle - is it possible to fix the need for the -w flag? Can the > > Makefile check the version and pass the correct flags itself? > > Do you mean "-W Turn warnings into errors" which never changed its > meaning in Sphinx since version 1.0? > > Yes, we want to this flag to reject any patch with broken reStructered text. So it is not like dtc/gcc/etc where we can do -Wno-some-specific-check, OK. -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/1] doc: update Kernel documentation build system
On 25.01.21 02:56, Simon Glass wrote: > Hi, > > On Sun, 24 Jan 2021 at 18:37, Tom Rini wrote: >> >> On Mon, Jan 25, 2021 at 01:41:18AM +0100, Heinrich Schuchardt wrote: >>> On 1/25/21 12:59 AM, Tom Rini wrote: On Sun, Jan 24, 2021 at 10:05:27PM +0100, Heinrich Schuchardt wrote: > On 1/23/21 6:53 PM, Tom Rini wrote: >> On Sat, Jan 23, 2021 at 12:46:23PM -0500, Tom Rini wrote: >>> On Fri, Jan 01, 2021 at 01:21:11AM +0100, Heinrich Schuchardt wrote: >>> Update the docomentation build system according to Linux v5.11-rc1. With this patch we can build the HTML documentation using either of Sphinx 2 and Sphinx 3. Signed-off-by: Heinrich Schuchardt Reviewed-by: Simon Glass >>> >>> Applied to u-boot/master, thanks! >> >> I've had to revert this. While I caught and fixed up in a semi-logical >> way one duplicate label problem, there's another now that I see, and >> probably many more once I rework that one. It's unclear as well how >> best to handle these otherwise logical duplicate labels, such as "eMMC" >> in doc/board/microchip/mpfs_icicle.rst for example. > > Sphinx 2 is not available for current Linux distributions. Without this > patch we cannot build with Sphinx 3. We need to be careful when saying "current". Ubuntu 18.04 is still quite current enough and will be until 2022 (as it doesn't go EOL until 2023). I'm not sure I can even get Sphinx 3. >>> >>> Developers will not be able to test the documentation if 'make htmldocs' >>> fails on their machines because their distribution does not provide >>> Sphinx 2. >>> >>> The current Ubuntu release is 20.10 and provides Sphinx 3.2. >>> https://packages.ubuntu.com/groovy/sphinx-common. >>> >>> Arch Linux is on Sphinx 3.4. >>> https://archlinux.org/packages/community/any/python-sphinx/ >> >> And 18.04 is an LTS that doesn't go EOL until April 2023. Developers >> will not be test their documentation if they don't have Sphinx 3 >> available. Either side can do as Sean notes and use venv to provide >> whatever, and we need to make the error in that case much clearer. I >> would assume that the "still works with gcc-4.9!" Linux kernel has a bit >> clearer of an error out in that case. If not perhaps they would take a >> patch :) >> >> But much more importantly: > All pages must be deduplicated. Instead of duplicate information > references have to be used. So long as it can be done in a way where documentation reads well still, yes. For example, how should we re-write the example I mentioned so that "eMMC" isn't duplicated? >> >> Is what really needs to be solved. Show me how the document in question >> gets updated to read well and not have the duplicated heading message. > > I agree we have to support Sphinx 2 for a while. So we need both! > > Minor niggle - is it possible to fix the need for the -w flag? Can the > Makefile check the version and pass the correct flags itself? Do you mean "-W Turn warnings into errors" which never changed its meaning in Sphinx since version 1.0? Yes, we want to this flag to reject any patch with broken reStructered text. Best regards Heinrich
Re: [PATCH] disk: part_efi: update partition table entries after write
Hi Heinrich, On Tue, Jan 26, 2021 at 04:08:13PM +0100, Heinrich Schuchardt wrote: > On 26.01.21 14:56, Gary Bisson wrote: > > Fixes fastboot issues when switching from mbr to gpt partition tables. > > > > Signed-off-by: Gary Bisson > > --- > > Hi, > > > > I hesitated calling this a RFC as I'm not sure everyone will like the > > idea. > > > > Basically the issue encountered was the following: > > - Device with its storage flashed with a MBR partition table > > - Run fastboot to flash a new OS (and new partition table) > > - After flashing a GPT partition table, U-Boot couldn't find any of the > > partition names from the GPT > > -> reason is that the partition table entries aren't updated > > -> so U-Boot still believes it's a MBR table inside and so its parsing > > fails > > > > This commit adds an update of the table entries inside the > > write_mbr_and_gpt_partitions() function. At first I thought maybe this > > should be added in fastboot file (fb_mmc.c) but couldn't think of a good > > reason why this shouldn't happened in part_efi directly. > > > > Let me know if you have any questions. > > > > Regards, > > Gary > > --- > > disk/part_efi.c | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/disk/part_efi.c b/disk/part_efi.c > > index 2f922662e6e..7a24e33d189 100644 > > --- a/disk/part_efi.c > > +++ b/disk/part_efi.c > > @@ -867,6 +867,9 @@ int write_mbr_and_gpt_partitions(struct blk_desc > > *dev_desc, void *buf) > > return 1; > > } > > > > + /* Update the partition table entries*/ > > + part_init(dev_desc); > > + > > return 0; > > } > > #endif > > > > This change is for GPT only. Don't we need the same for MBR partition > tables (write_mbr_partitions())? I actually have another commit for the MBR partition[1], I just wanted to send the GPT one first to see if it was an acceptable approach. Regards, Gary [1] https://github.com/boundarydevices/u-boot-imx6/commit/5fc23bce
Re: [PATCH 1/1] fs: fat: remove superfluous assignments
On 26.01.21 08:53, Christian Gmeiner wrote:
> Hi
>
> Am Di., 26. Jan. 2021 um 00:14 Uhr schrieb Heinrich Schuchardt
> :
>>
>> Do not assign a value to a variable if it is not used.
>
> I am not very happy about this commit message tbo. What you are doing
> is reducing the scope
> of variables.. so write this in your commit message.
Sure.
>
>>
>> Signed-off-by: Heinrich Schuchardt
>> ---
>> fs/fat/fat.c | 3 ++-
>> fs/fat/fat_write.c | 6 +++---
>> 2 files changed, 5 insertions(+), 4 deletions(-)
>>
>> diff --git a/fs/fat/fat.c b/fs/fat/fat.c
>> index fb6ce094ac..ccba268f61 100644
>> --- a/fs/fat/fat.c
>> +++ b/fs/fat/fat.c
>> @@ -248,7 +248,6 @@ static __u32 get_fatent(fsdata *mydata, __u32 entry)
>> static int
>> get_cluster(fsdata *mydata, __u32 clustnum, __u8 *buffer, unsigned long
>> size)
>> {
>> - __u32 idx = 0;
>> __u32 startsect;
>> int ret;
>>
>> @@ -277,6 +276,8 @@ get_cluster(fsdata *mydata, __u32 clustnum, __u8
>> *buffer, unsigned long size)
>> size -= mydata->sect_size;
>> }
>> } else {
>> + __u32 idx;
>> +
>> idx = size / mydata->sect_size;
>> if (idx == 0)
>> ret = 0;
>> diff --git a/fs/fat/fat_write.c b/fs/fat/fat_write.c
>> index aae3a6a3d1..b43a27b205 100644
>> --- a/fs/fat/fat_write.c
>> +++ b/fs/fat/fat_write.c
>> @@ -573,7 +573,6 @@ static __u32 determine_fatent(fsdata *mydata, __u32
>> entry)
>> static int
>> set_sectors(fsdata *mydata, u32 startsect, u8 *buffer, u32 size)
>> {
>> - u32 nsects = 0;
>> int ret;
>>
>> debug("startsect: %d\n", startsect);
>> @@ -595,6 +594,8 @@ set_sectors(fsdata *mydata, u32 startsect, u8 *buffer,
>> u32 size)
>> size -= mydata->sect_size;
>> }
>> } else if (size >= mydata->sect_size) {
>> + u32 nsects;
>> +
>> nsects = size / mydata->sect_size;
>> ret = disk_write(startsect, nsects, buffer);
>> if (ret != nsects) {
>> @@ -785,7 +786,6 @@ get_set_cluster(fsdata *mydata, __u32 clustnum, loff_t
>> pos, __u8 *buffer,
>> }
>>
>> size -= wsize;
>> - buffer += wsize;
>
> That looks wrong when staring at it from my mail client.
This is the last time buffer is accessed before return. Why do you think
it is wrong?
Best regards
Heinrich
>
>> *gotsize += wsize;
>> }
>>
>> @@ -1482,10 +1482,10 @@ static int delete_single_dentry(fat_itr *itr)
>> */
>> static int delete_long_name(fat_itr *itr)
>> {
>> - struct dir_entry *dent = itr->dent;
>> int seqn = itr->dent->nameext.name[0] & ~LAST_LONG_ENTRY_MASK;
>>
>> while (seqn--) {
>> + struct dir_entry *dent;
>> int ret;
>>
>> ret = delete_single_dentry(itr);
>> --
>> 2.29.2
>>
>
>
Re: [PATCH] disk: part_efi: update partition table entries after write
On 26.01.21 14:56, Gary Bisson wrote: > Fixes fastboot issues when switching from mbr to gpt partition tables. > > Signed-off-by: Gary Bisson > --- > Hi, > > I hesitated calling this a RFC as I'm not sure everyone will like the > idea. > > Basically the issue encountered was the following: > - Device with its storage flashed with a MBR partition table > - Run fastboot to flash a new OS (and new partition table) > - After flashing a GPT partition table, U-Boot couldn't find any of the > partition names from the GPT > -> reason is that the partition table entries aren't updated > -> so U-Boot still believes it's a MBR table inside and so its parsing > fails > > This commit adds an update of the table entries inside the > write_mbr_and_gpt_partitions() function. At first I thought maybe this > should be added in fastboot file (fb_mmc.c) but couldn't think of a good > reason why this shouldn't happened in part_efi directly. > > Let me know if you have any questions. > > Regards, > Gary > --- > disk/part_efi.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/disk/part_efi.c b/disk/part_efi.c > index 2f922662e6e..7a24e33d189 100644 > --- a/disk/part_efi.c > +++ b/disk/part_efi.c > @@ -867,6 +867,9 @@ int write_mbr_and_gpt_partitions(struct blk_desc > *dev_desc, void *buf) > return 1; > } > > + /* Update the partition table entries*/ > + part_init(dev_desc); > + > return 0; > } > #endif > This change is for GPT only. Don't we need the same for MBR partition tables (write_mbr_partitions())? @Simon: Essentially this reflashing is similar to changing media. What I am missing in part_init() is setting a field with a counter to indicate the media change. The EFI_BLOCK_IO_PROTOCOL has a u32 field media_id. Would struct blk_desc be the right place to add such a field. Best regards Heinrich
Re: Pull request: u-boot-sunxi/master for v2021.04 (part 2)
On Tue, Jan 26, 2021 at 12:16:01AM +, Andre Przywara wrote: > Hi Tom, > > please pull the master branch from u-boot-sunxi, containing the second > part of the sunxi pull request for the 2021.04 merge window: Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
[PATCH] disk: part_efi: update partition table entries after write
Fixes fastboot issues when switching from mbr to gpt partition tables. Signed-off-by: Gary Bisson --- Hi, I hesitated calling this a RFC as I'm not sure everyone will like the idea. Basically the issue encountered was the following: - Device with its storage flashed with a MBR partition table - Run fastboot to flash a new OS (and new partition table) - After flashing a GPT partition table, U-Boot couldn't find any of the partition names from the GPT -> reason is that the partition table entries aren't updated -> so U-Boot still believes it's a MBR table inside and so its parsing fails This commit adds an update of the table entries inside the write_mbr_and_gpt_partitions() function. At first I thought maybe this should be added in fastboot file (fb_mmc.c) but couldn't think of a good reason why this shouldn't happened in part_efi directly. Let me know if you have any questions. Regards, Gary --- disk/part_efi.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/disk/part_efi.c b/disk/part_efi.c index 2f922662e6e..7a24e33d189 100644 --- a/disk/part_efi.c +++ b/disk/part_efi.c @@ -867,6 +867,9 @@ int write_mbr_and_gpt_partitions(struct blk_desc *dev_desc, void *buf) return 1; } + /* Update the partition table entries*/ + part_init(dev_desc); + return 0; } #endif -- 2.29.2
Re: [PATCH 1/1] doc: remove illegal characters
On 26.01.21 00:41, Pali Rohár wrote: > On Tuesday 26 January 2021 00:33:29 Heinrich Schuchardt wrote: >> On 1/25/21 11:13 PM, Pali Rohár wrote: >>> Hello Heinrich! >>> >>> Does this change mean that UTF-8 is now disallowed in U-Boot? >>> >>> On Monday 25 January 2021 22:48:56 Heinrich Schuchardt wrote: Avoid errors when generating the HTML documentation like: 'ascii' codec can't decode byte 0xc2 >>> >>> This sounds like an incorrect configuration of tool which is generating >>> HTML documentation. >> >> Sphinx uses as default: >> >> source_encoding = 'utf-8-sig' > > utf-8-sig is IIRC UTF-8 encoding with leading BOM. > >> With Sphinx 3 on my machine I have no problem. But with Sphinx 2 on >> Gitlab an error is ejected for Unicode letters. >> >> I do not know if elder Sphinx versions require a BOM to mark a file as >> UTF-8 when using utf-8-sig. > > According to UNICODE standards, it is not required and moreover it is > not recommended to use BOM in UTF-8. > > So if some tool requires BOM in UTF-8 then it not compliant to UNICODE > standard and I do not think it is a good idea to stop using UNICODE just > because some tool cannot process UTF-8... But this is just my opinion > and I do not know how Sphinx 2 works or how it is configured. > > Maybe... can you check if it is possible to reconfigure Sphinx 2 to use > UTF-8 without BOM? Is not there just option source_encoding = 'utf-8' ? > The problem is caused by doc/sphinx/automarkup.py inherited from Linux. The initial commit for the module says: "Rather than fill our text files with :c:func:`function()` syntax, just do the markup via a hook into the sphinx build process." I am not able to reproduce the problem locally. We can deactivate this module. Anyway the module would have to be adjusted to match U-Boots file structure. Best regards Heinrich
Re: [PATCH v5 2/4] button: add a simple Analog to Digital Converter device based button driver
On 26.01.21 12:25, Marek Szyprowski wrote:
> 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, );
>>> + 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, );
>>> + if (ret)
>>> + return ret;
>>> +
>>> + ret = uclass_get_device_by_ofnode(UCLASS_ADC, args.node,
>>> >adc);
>>> + if (ret)
>>> + return ret;
>>> +
>>> + ret = ofnode_read_u32(dev_ofnode(dev->parent),
>>> + "keyup-threshold-microvolt", _treshold);
>>> + if (ret)
>>> + return ret;
>>> +
>>> + ret = ofnode_read_u32(dev_ofnode(dev), "press-threshold-microvolt",
>>> + );
>>> + if (ret)
>>> + return ret;
>>> +
>>> + dev_for_each_subnode(node, dev->parent) {
>>> + ret = ofnode_read_u32(dev_ofnode(dev),
>>> + "press-threshold-microvolt", );
>>> + if (ret)
>>> + return ret;
>>> +
>>> + if (t > treshold)
>>> + up_treshold = t;
>>
>> Linux' Documentation/devicetree/bindings/input/adc-keys.txt describes
>> that one virtual key is created per sub-node.
>>
>> If I read your code correctly, this is not what you are implementing.
>> Instead you only define a single key per adc-keys node.
>>
>> Why are your deviating
Re: [PATCH] fastboot: add UUU command UCmd and ACmd support
Hello Tom,
Am 26.01.21 um 12:46 schrieb Tom Rini:
> On Tue, Jan 26, 2021 at 06:23:24AM +0100, Heiko Schocher wrote:
>
>> Hello Tom,
>>
>> this patch is assigned to you ... any issues with it, or can
>> it go into master?
>
> As Lukasz is back and reviewing code and making PRs, he should take it.
> Thanks.
Ok, so I moved the patch in patchwork to Lukasz.
Thanks!
bye,
Heiko
>
>>
>> Thanks!
>>
>> bye,
>> Heiko
>>
>> Am 11.01.21 um 11:19 schrieb Heiko Schocher:
>>> add support for the UUU commands ACmd and UCmd.
>>>
>>> Enable them through the Kconfig option
>>> CONFIG_FASTBOOT_UUU_SUPPORT
>>>
>>> base was commit in NXP kernel
>>> 9b149c2a2882: ("MLK-18591-3 android: Add FSL android fastboot support")
>>>
>>> and ported it to current mainline. Tested this patch
>>> on imx6ul based board.
>>>
>>> Signed-off-by: Heiko Schocher
>>> ---
>>> azure build:
>>> https://dev.azure.com/hs0298/hs/_build/results?buildId=57=results
>>>
>>> version uuu tool used for tests:
>>> commit 3870fb781b35: ("fastboot: default to logical-block-size 4096")
>>>
>>> doc/android/fastboot-protocol.rst | 5 +++
>>> doc/android/fastboot.rst | 2 +
>>> drivers/fastboot/Kconfig | 7
>>> drivers/fastboot/fb_command.c | 62 +++
>>> drivers/usb/gadget/f_fastboot.c | 17 +
>>> include/fastboot.h| 7
>>> 6 files changed, 100 insertions(+)
>>>
>>> diff --git a/doc/android/fastboot-protocol.rst
>>> b/doc/android/fastboot-protocol.rst
>>> index e723659e49c..e8cbd7f24ea 100644
>>> --- a/doc/android/fastboot-protocol.rst
>>> +++ b/doc/android/fastboot-protocol.rst
>>> @@ -144,6 +144,11 @@ Command Reference
>>>
>>>"powerdown" Power off the device.
>>>
>>> + "ucmd" execute any bootloader command and wait until it
>>> + finishs.
>>> +
>>> + "acmd" execute any bootloader command, do not wait.
>>> +
>>> Client Variables
>>>
>>>
>>> diff --git a/doc/android/fastboot.rst b/doc/android/fastboot.rst
>>> index 2877c3cbaaa..b58d1b5b31a 100644
>>> --- a/doc/android/fastboot.rst
>>> +++ b/doc/android/fastboot.rst
>>> @@ -19,6 +19,8 @@ The current implementation supports the following
>>> standard commands:
>>> - ``reboot``
>>> - ``reboot-bootloader``
>>> - ``set_active`` (only a stub implementation which always succeeds)
>>> +- ``ucmd`` (if enabled)
>>> +- ``acmd`` (if enabled)
>>>
>>> The following OEM commands are supported (if enabled):
>>>
>>> diff --git a/drivers/fastboot/Kconfig b/drivers/fastboot/Kconfig
>>> index 4352ba67a71..b1f8cd74a15 100644
>>> --- a/drivers/fastboot/Kconfig
>>> +++ b/drivers/fastboot/Kconfig
>>> @@ -72,6 +72,13 @@ config FASTBOOT_FLASH
>>> the downloaded image to a non-volatile storage device. Define
>>> this to enable the "fastboot flash" command.
>>>
>>> +config FASTBOOT_UUU_SUPPORT
>>> + bool "Enable FASTBOOT i.MX UUU special command"
>>> + default y if ARCH_MX7 || ARCH_MX6 || ARCH_IMX8 || ARCH_IMX8M ||
>>> ARCH_MX7ULP
>>> + select FSL_FASTBOOT
>>> + help
>>> + The fastboot protocol includes "UCmd" command and "ACmd" command
>>> +
>>> choice
>>> prompt "Flash provider for FASTBOOT"
>>> depends on FASTBOOT_FLASH
>>> diff --git a/drivers/fastboot/fb_command.c b/drivers/fastboot/fb_command.c
>>> index d3c578672dc..31a47e46386 100644
>>> --- a/drivers/fastboot/fb_command.c
>>> +++ b/drivers/fastboot/fb_command.c
>>> @@ -43,6 +43,11 @@ static void reboot_recovery(char *, char *);
>>> static void oem_format(char *, char *);
>>> #endif
>>>
>>> +#if CONFIG_IS_ENABLED(FASTBOOT_UUU_SUPPORT)
>>> +static void run_ucmd(char *, char *);
>>> +static void run_acmd(char *, char *);
>>> +#endif
>>> +
>>> static const struct {
>>> const char *command;
>>> void (*dispatch)(char *cmd_parameter, char *response);
>>> @@ -99,6 +104,16 @@ static const struct {
>>> .dispatch = oem_format,
>>> },
>>> #endif
>>> +#if CONFIG_IS_ENABLED(FASTBOOT_UUU_SUPPORT)
>>> + [FASTBOOT_COMMAND_UCMD] = {
>>> + .command = "UCmd",
>>> + .dispatch = run_ucmd,
>>> + },
>>> + [FASTBOOT_COMMAND_ACMD] = {
>>> + .command = "ACmd",
>>> + .dispatch = run_acmd,
>>> + },
>>> +#endif
>>> };
>>>
>>> /**
>>> @@ -309,6 +324,53 @@ static void erase(char *cmd_parameter, char *response)
>>> }
>>> #endif
>>>
>>> +#if CONFIG_IS_ENABLED(FASTBOOT_UUU_SUPPORT)
>>> +/**
>>> + * run_ucmd() - Execute the UCmd command
>>> + *
>>> + * @cmd_parameter: Pointer to command parameter
>>> + * @response: Pointer to fastboot response buffer
>>> + */
>>> +static void run_ucmd(char *cmd_parameter, char *response)
>>> +{
>>> + if (!cmd_parameter) {
>>> + pr_err("missing slot suffix\n");
>>> + fastboot_fail("missing command", response);
>>> + return;
>>> + }
>>> +
>>> + if (run_command(cmd_parameter, 0))
>>> + fastboot_fail("", response);
>>> + else
Re: [PATCH] fastboot: add UUU command UCmd and ACmd support
On Tue, Jan 26, 2021 at 06:23:24AM +0100, Heiko Schocher wrote:
> Hello Tom,
>
> this patch is assigned to you ... any issues with it, or can
> it go into master?
As Lukasz is back and reviewing code and making PRs, he should take it.
Thanks.
>
> Thanks!
>
> bye,
> Heiko
>
> Am 11.01.21 um 11:19 schrieb Heiko Schocher:
> > add support for the UUU commands ACmd and UCmd.
> >
> > Enable them through the Kconfig option
> > CONFIG_FASTBOOT_UUU_SUPPORT
> >
> > base was commit in NXP kernel
> > 9b149c2a2882: ("MLK-18591-3 android: Add FSL android fastboot support")
> >
> > and ported it to current mainline. Tested this patch
> > on imx6ul based board.
> >
> > Signed-off-by: Heiko Schocher
> > ---
> > azure build:
> > https://dev.azure.com/hs0298/hs/_build/results?buildId=57=results
> >
> > version uuu tool used for tests:
> > commit 3870fb781b35: ("fastboot: default to logical-block-size 4096")
> >
> > doc/android/fastboot-protocol.rst | 5 +++
> > doc/android/fastboot.rst | 2 +
> > drivers/fastboot/Kconfig | 7
> > drivers/fastboot/fb_command.c | 62 +++
> > drivers/usb/gadget/f_fastboot.c | 17 +
> > include/fastboot.h| 7
> > 6 files changed, 100 insertions(+)
> >
> > diff --git a/doc/android/fastboot-protocol.rst
> > b/doc/android/fastboot-protocol.rst
> > index e723659e49c..e8cbd7f24ea 100644
> > --- a/doc/android/fastboot-protocol.rst
> > +++ b/doc/android/fastboot-protocol.rst
> > @@ -144,6 +144,11 @@ Command Reference
> >
> >"powerdown" Power off the device.
> >
> > + "ucmd" execute any bootloader command and wait until it
> > + finishs.
> > +
> > + "acmd" execute any bootloader command, do not wait.
> > +
> > Client Variables
> >
> >
> > diff --git a/doc/android/fastboot.rst b/doc/android/fastboot.rst
> > index 2877c3cbaaa..b58d1b5b31a 100644
> > --- a/doc/android/fastboot.rst
> > +++ b/doc/android/fastboot.rst
> > @@ -19,6 +19,8 @@ The current implementation supports the following
> > standard commands:
> > - ``reboot``
> > - ``reboot-bootloader``
> > - ``set_active`` (only a stub implementation which always succeeds)
> > +- ``ucmd`` (if enabled)
> > +- ``acmd`` (if enabled)
> >
> > The following OEM commands are supported (if enabled):
> >
> > diff --git a/drivers/fastboot/Kconfig b/drivers/fastboot/Kconfig
> > index 4352ba67a71..b1f8cd74a15 100644
> > --- a/drivers/fastboot/Kconfig
> > +++ b/drivers/fastboot/Kconfig
> > @@ -72,6 +72,13 @@ config FASTBOOT_FLASH
> > the downloaded image to a non-volatile storage device. Define
> > this to enable the "fastboot flash" command.
> >
> > +config FASTBOOT_UUU_SUPPORT
> > + bool "Enable FASTBOOT i.MX UUU special command"
> > + default y if ARCH_MX7 || ARCH_MX6 || ARCH_IMX8 || ARCH_IMX8M ||
> > ARCH_MX7ULP
> > + select FSL_FASTBOOT
> > + help
> > + The fastboot protocol includes "UCmd" command and "ACmd" command
> > +
> > choice
> > prompt "Flash provider for FASTBOOT"
> > depends on FASTBOOT_FLASH
> > diff --git a/drivers/fastboot/fb_command.c b/drivers/fastboot/fb_command.c
> > index d3c578672dc..31a47e46386 100644
> > --- a/drivers/fastboot/fb_command.c
> > +++ b/drivers/fastboot/fb_command.c
> > @@ -43,6 +43,11 @@ static void reboot_recovery(char *, char *);
> > static void oem_format(char *, char *);
> > #endif
> >
> > +#if CONFIG_IS_ENABLED(FASTBOOT_UUU_SUPPORT)
> > +static void run_ucmd(char *, char *);
> > +static void run_acmd(char *, char *);
> > +#endif
> > +
> > static const struct {
> > const char *command;
> > void (*dispatch)(char *cmd_parameter, char *response);
> > @@ -99,6 +104,16 @@ static const struct {
> > .dispatch = oem_format,
> > },
> > #endif
> > +#if CONFIG_IS_ENABLED(FASTBOOT_UUU_SUPPORT)
> > + [FASTBOOT_COMMAND_UCMD] = {
> > + .command = "UCmd",
> > + .dispatch = run_ucmd,
> > + },
> > + [FASTBOOT_COMMAND_ACMD] = {
> > + .command = "ACmd",
> > + .dispatch = run_acmd,
> > + },
> > +#endif
> > };
> >
> > /**
> > @@ -309,6 +324,53 @@ static void erase(char *cmd_parameter, char *response)
> > }
> > #endif
> >
> > +#if CONFIG_IS_ENABLED(FASTBOOT_UUU_SUPPORT)
> > +/**
> > + * run_ucmd() - Execute the UCmd command
> > + *
> > + * @cmd_parameter: Pointer to command parameter
> > + * @response: Pointer to fastboot response buffer
> > + */
> > +static void run_ucmd(char *cmd_parameter, char *response)
> > +{
> > + if (!cmd_parameter) {
> > + pr_err("missing slot suffix\n");
> > + fastboot_fail("missing command", response);
> > + return;
> > + }
> > +
> > + if (run_command(cmd_parameter, 0))
> > + fastboot_fail("", response);
> > + else
> > + fastboot_okay(NULL, response);
> > +}
> > +
> > +static char g_a_cmd_buff[64];
> > +
> > +void
Re: [PATCH 10/11] pinctrl: single: add get_pin_muxing operation
Hi Simon, > Il 24/01/2021 03:03 Simon Glass ha scritto: > > > Hi Dario, > > On Sat, 23 Jan 2021 at 11:27, Dario Binacchi wrote: > > > > It allows to display the muxing of a given pin. Inspired by more recent > > versions of the Linux driver, in addition to the address and the value > > of the configuration register I added the pin function retrieved from > > the DT. In doing so, the information displayed does not depend on the > > platform, being a generic type driver, and it can be useful for debug > > purposes. > > > > Signed-off-by: Dario Binacchi > > --- > > > > drivers/pinctrl/pinctrl-single.c | 220 +-- > > 1 file changed, 211 insertions(+), 9 deletions(-) > > Do we need an updated DT binding file? I would say no, the am335x DT has recently been resynced with one of the latest versions of the Linux kernel. > > Regards, > Simon Regards Dario
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, );
>> + 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, );
>> + if (ret)
>> + return ret;
>> +
>> + ret = uclass_get_device_by_ofnode(UCLASS_ADC, args.node,
>> >adc);
>> + if (ret)
>> + return ret;
>> +
>> + ret = ofnode_read_u32(dev_ofnode(dev->parent),
>> + "keyup-threshold-microvolt", _treshold);
>> + if (ret)
>> + return ret;
>> +
>> + ret = ofnode_read_u32(dev_ofnode(dev), "press-threshold-microvolt",
>> + );
>> + if (ret)
>> + return ret;
>> +
>> + dev_for_each_subnode(node, dev->parent) {
>> + ret = ofnode_read_u32(dev_ofnode(dev),
>> + "press-threshold-microvolt", );
>> + if (ret)
>> + return ret;
>> +
>> + if (t > treshold)
>> + up_treshold = t;
>
> Linux' Documentation/devicetree/bindings/input/adc-keys.txt describes
> that one virtual key is created per sub-node.
>
> If I read your code correctly, this is not what you are implementing.
> Instead you only define a single key per adc-keys node.
>
> Why are your deviating from the bindings document?
No I don't. button_adc_bind() binds to the root node with 'adc-keys'
compatible, while the dev_for_each_subnode() loop instantiates driver
for each subnode, so the
Re: [PATCH 03/11] pinctrl: single: fix debug messages formatting
Hi Pratyush,
> Il 25/01/2021 18:09 Pratyush Yadav ha scritto:
>
>
> Hi Dario,
>
> On 23/01/21 07:27PM, Dario Binacchi wrote:
> > The printf '%pa' format specifier appends the '0x' prefix to the
> > displayed address. Furthermore, the offset variable is displayed with
> > the '%x' format specifier instead of '%pa'.
>
> I agree with Simon that the commit message does not explain why this
> change is needed.
>
> > Signed-off-by: Dario Binacchi
> > ---
> >
> > drivers/pinctrl/pinctrl-single.c | 28
> > 1 file changed, 16 insertions(+), 12 deletions(-)
> >
> > diff --git a/drivers/pinctrl/pinctrl-single.c
> > b/drivers/pinctrl/pinctrl-single.c
> > index 49ed15211d..cec00e289c 100644
> > --- a/drivers/pinctrl/pinctrl-single.c
> > +++ b/drivers/pinctrl/pinctrl-single.c
> > @@ -77,15 +77,17 @@ static int single_configure_pins(struct udevice *dev,
> > struct single_pdata *pdata = dev_get_plat(dev);
> > int n, count = size / sizeof(struct single_fdt_pin_cfg);
> > phys_addr_t reg;
> > - u32 val;
> > + u32 offset, val;
> >
> > for (n = 0; n < count; n++, pins++) {
> > - reg = fdt32_to_cpu(pins->reg);
> > - if ((reg < 0) || (reg > pdata->offset)) {
> > - dev_dbg(dev, " invalid register offset 0x%pa\n", );
> > + offset = fdt32_to_cpu(pins->reg);
> > + if (offset < 0 || offset > pdata->offset) {
> > + dev_dbg(dev, " invalid register offset 0x%x\n",
> > + offset);
>
> You are not just fixing "debug messages formatting" here. You have made
> other changes to the structure of the code here. While these changes
> might all be correct, they don't belong in a commit that claims to fix
> message formatting.
>
> For example, this dev_dbg() statement in the pre-image prints "" as
> the offset. This would be the address of the variable reg on the stack.
> This looks like it is a bug. The offset is stored in "reg", not in
> "". The post-image fixes this bug. A person reading this diff might
> not look so closely at this because you only claim to change formatting.
> And some important discussion/context on this bug might be skipped over.
>
> Please re-word the commit subject and message to clearly explain why you
> are making these structural changes and separate them from the
> formatting changes (which also warrant an explanation on their own).
>
> > continue;
> > }
> > - reg += pdata->base;
> > +
> > + reg = pdata->base + offset;
> > val = fdt32_to_cpu(pins->val) & pdata->mask;
> > switch (pdata->width) {
> > case 16:
> > @@ -99,7 +101,7 @@ static int single_configure_pins(struct udevice *dev,
> > pdata->width);
> > continue;
> > }
> > - dev_dbg(dev, " reg/val 0x%pa/0x%08x\n", , val);
> > + dev_dbg(dev, " reg/val %pa/0x%08x\n", , val);
>
> In a similar fashion as above, shouldn't "" be replaced with "reg"?
> I am not too familiar with the code to say for sure. Same for the
> changes below.
>
Also I would have expected reg instead of but at the link
https://www.kernel.org/doc/html/latest/core-api/printk-formats.html is
explained:
...
"Phys_addr_t Physical Address Types"
%pa [p] 0x01234567 or 0x0123456789abcdef
For printing a phys_addr_t type (and its derivatives, such as resource_size_t)
which can vary based on build options, regardless of the width of the CPU data
path.
Passed by reference.
...
I also did some tests on the board:
dev_dbg(dev, " reg/val %pa/0x%08x\n", , val); --> reg/val
0x44e10940/0x0030
dev_dbg(dev, " reg/val %p/0x%08x\n", reg, val); --> reg/val
44e10940/0x0030
I'll continue to use the first one, which is documented.
> > }
> > return 0;
> > }
> > @@ -111,15 +113,17 @@ static int single_configure_bits(struct udevice *dev,
> > struct single_pdata *pdata = dev_get_plat(dev);
> > int n, count = size / sizeof(struct single_fdt_bits_cfg);
> > phys_addr_t reg;
> > - u32 val, mask;
> > + u32 offset, val, mask;
> >
> > for (n = 0; n < count; n++, pins++) {
> > - reg = fdt32_to_cpu(pins->reg);
> > - if ((reg < 0) || (reg > pdata->offset)) {
> > - dev_dbg(dev, " invalid register offset 0x%pa\n", );
> > + offset = fdt32_to_cpu(pins->reg);
> > + if (offset < 0 || offset > pdata->offset) {
> > + dev_dbg(dev, " invalid register offset 0x%x\n",
> > + offset);
> > continue;
> > }
> > - reg += pdata->base;
> > +
> > + reg = pdata->base + offset;
> >
> > mask = fdt32_to_cpu(pins->mask);
> > val = fdt32_to_cpu(pins->val) & mask;
> > @@ -136,7 +140,7 @@ static int single_configure_bits(struct udevice *dev,
> >
Re: [PATCH v5 2/4] button: add a simple Analog to Digital Converter device based button driver
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, );
+ 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, );
+ if (ret)
+ return ret;
+
+ ret = uclass_get_device_by_ofnode(UCLASS_ADC, args.node, >adc);
+ if (ret)
+ return ret;
+
+ ret = ofnode_read_u32(dev_ofnode(dev->parent),
+ "keyup-threshold-microvolt", _treshold);
+ if (ret)
+ return ret;
+
+ ret = ofnode_read_u32(dev_ofnode(dev), "press-threshold-microvolt",
+ );
+ if (ret)
+ return ret;
+
+ dev_for_each_subnode(node, dev->parent) {
+ ret = ofnode_read_u32(dev_ofnode(dev),
+ "press-threshold-microvolt", );
+ if (ret)
+ return ret;
+
+ if (t > treshold)
+ up_treshold = t;
Linux' Documentation/devicetree/bindings/input/adc-keys.txt describes
that one virtual key is created per sub-node.
If I read your code correctly, this is not what you are implementing.
Instead you only define a single key per adc-keys node.
Why are your deviating from the bindings document?
Best regards
Heinrich
+ }
+
+ ret = adc_vdd_value(priv->adc, );
+ if (ret)
+ return ret;
+
+ ret = adc_data_mask(priv->adc, );
+ if (ret)
+ return ret;
+
+ priv->channel = args.args[0];
+ priv->min = mask * (treshold / 1000) / (vdd / 1000);
+ priv->max = mask * (up_treshold / 1000) / (vdd / 1000);
+
+
[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, );
+ 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, );
+ if (ret)
+ return ret;
+
+ ret = uclass_get_device_by_ofnode(UCLASS_ADC, args.node, >adc);
+ if (ret)
+ return ret;
+
+ ret = ofnode_read_u32(dev_ofnode(dev->parent),
+ "keyup-threshold-microvolt", _treshold);
+ if (ret)
+ return ret;
+
+ ret = ofnode_read_u32(dev_ofnode(dev), "press-threshold-microvolt",
+ );
+ if (ret)
+ return ret;
+
+ dev_for_each_subnode(node, dev->parent) {
+ ret = ofnode_read_u32(dev_ofnode(dev),
+ "press-threshold-microvolt", );
+ if (ret)
+ return ret;
+
+ if (t > treshold)
+ up_treshold = t;
+ }
+
+ ret = adc_vdd_value(priv->adc, );
+ if (ret)
+ return ret;
+
+ ret = adc_data_mask(priv->adc, );
+ 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;
+
+ dev_for_each_subnode(node, parent) {
+ struct button_uc_plat *uc_plat;
+ const char *label;
+
+ label = ofnode_read_string(node, "label");
+ if (!label) {
+
[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), >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", );
+ 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 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 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 = < 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 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 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
Re: [GIT] Pull request: u-boot-dfu (26.01.2021)
On 1/26/21 9:10 AM, Lukasz Majewski wrote: Dear Marek, Please find this PR with gadget improvement code rebased on top of u-boot-denx-usb tree. CI: https://dev.azure.com/lukma633/U-Boot/_build/results?buildId=18=results (I've decided to send this patch set as a separate PR as it is a large one). The gitlab CI is currently timing out on binman tests, I pulled this into next for now.
[GIT] Pull request: u-boot-dfu (26.01.2021)
Dear Marek, Please find this PR with gadget improvement code rebased on top of u-boot-denx-usb tree. CI: https://dev.azure.com/lukma633/U-Boot/_build/results?buildId=18=results (I've decided to send this patch set as a separate PR as it is a large one). Merge tag data/information: https://gitlab.denx.de/u-boot/custodians/u-boot-dfu/-/tags/u-boot-dfu-26Jan2021 The following changes since commit 5f87c61588647d3884b3fdb2224e2bf226ac1039: usb: gadget: Do not export usbd_device_* arrays (2021-01-24 15:54:46 +0100) are available in the Git repository at: u-boot-denx-dfu/master for you to fetch changes up to af015c146314f0459bc6fda0f680f14f70abd4ff: usb: gaget: ci: set ep's desc when enable ep (2021-01-25 14:39:06 +0100) Jun Li (2): usb: gadget: set correct usb_configuration for os_desc_config usb: gadget: update os_desc_config when add config Li Jun (13): usb: gadget: don't change ep name for dwc3 while ep autoconfig usb: gadget: OS String support usb: gadget: move utf8_to_utf16le to header file usb: gadget: OS Feature Descriptors support usb: gadget: add WCID support for mfgtool usb: gadget: fastboot: add ext properties for WCID usb: gadget: add super speed support usb: fastboot: add super speed support usb: gadget: dnl: set dnl to be super speed usb: composite: force gadget to be USB2 for HS only function usb: udc: ci: update speed handling usb: gadget: fastboot: use correct max packet size usb: gaget: ci: set ep's desc when enable ep Peng Fan (1): usb: gadget: add Kconfig for OS descriptors Ye Li (1): usb: gadget: Add ep_config call back to usb_gadget_ops Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de pgpm76jbQ3hiZ.pgp Description: OpenPGP digital signature
