Re: [PATCH 1/2] riscv: allow riscv timer to be instantiated via device tree
On Mon, Aug 14, 2023 at 06:05:28PM +0200, Torsten Duwe wrote: > For the architectural timer on riscv, there already is a defined > device tree binding[1]. Allow timer instances to be created from > device tree matches, but for now retain the old mechanism, which > registers the timer biggy-back with the CPU. > > [1] linux/Documentation/devicetree/bindings/timer/riscv,timer.yaml > > Signed-off-by: Torsten Duwe > --- > drivers/timer/riscv_timer.c | 28 ++-- > 1 file changed, 26 insertions(+), 2 deletions(-) Reviewed-by: Leo Yu-Chi Liang
Re: [PATCH v3 5/6] docs: board: ti: Add j721s2_evm documentation
Hi Nishanth, On 14:15-20230901, Nishanth Menon wrote: > On 12:32-20230901, Manorit Chawdhry wrote: > > The documentation is based off J7200 documentation tailored for J721S2. > > You can drop the documentation based off j7200... Just state this > documentation is for J721S2. > > > > > TRM for J721S2: https://www.ti.com/lit/pdf/spruj28 > > Product Page: https://www.ti.com/product/TDA4AL-Q1 > > > > Reviewed-by: Neha Malcom Francis > > Signed-off-by: Manorit Chawdhry > > --- > > doc/board/ti/j721s2_evm.rst | 298 > > > > doc/board/ti/k3.rst | 1 + > > 2 files changed, 299 insertions(+) > > Thanks for including am68_sk documentation > > > > > diff --git a/doc/board/ti/j721s2_evm.rst b/doc/board/ti/j721s2_evm.rst > > new file mode 100644 > > index ..6b091ad37578 > > --- /dev/null > > +++ b/doc/board/ti/j721s2_evm.rst > > @@ -0,0 +1,298 @@ > > +.. SPDX-License-Identifier: GPL-2.0+ OR BSD-3-Clause > > +.. sectionauthor:: Manorit Chawdhry > > + > > +J721S2 and AM68 Platforms > > += > > + > > +Introduction: > > +- > > +The J721S2 family of SoCs are part of K3 Multicore SoC architecture > > platform > > +targeting automotive applications. They are designed as a low power, high > > +performance and highly integrated device architecture, adding significant > > +enhancement on processing power, graphics capability, video and imaging > > +processing, virtualization and coherent memory support. > > + > > +The AM68 Starter Kit/Evaluation Module (EVM) is based on the J721S2 family > > +of SoCs. They are designed for machine vision, traffic monitoring, retail > > +automation, and factory automation. > > + > > +The device is partitioned into three functional domains, each containing > > +specific processing cores and peripherals: > > + > > +1. Wake-up (WKUP) domain: > > +* ARM Cortex-M4F processor, runs TI Foundational Security (TIFS) > > + > > +2. Microcontroller (MCU) domain: > > +* Dual core ARM Cortex-R5F processor, runs device management > > + and SoC early boot > > Just use a single space for spacing? > > > + > > +3. MAIN domain: > > +* Dual core 64-bit ARM Cortex-A72, runs HLOS > > just use a single space? > > > + > > +More info can be found in TRM: https://www.ti.com/lit/pdf/spruj28 > > + > [...] > > > + > > +Target Images > > +-- > > +In order to boot we need tiboot3.bin, tispl.bin and u-boot.img. Each SoC > > +variant (GP, HS-FS, HS-SE) requires a different source for these files. > > + > > + - GP > > + > > +* tiboot3-j721s2-gp-evm.bin from :ref:`step 3.1 > > ` > > +* tispl.bin_unsigned, u-boot.img_unsigned from :ref:`step 3.2 > > ` > > + > > + - HS-FS > > + > > +* tiboot3-j721s2-hs-fs-evm.bin from :ref:`step 3.1 > > ` > > +* tispl.bin, u-boot.img from :ref:`step 3.2 > > ` > > + > > + - HS-SE > > + > > +* tiboot3-j721s2-hs-evm.bin from :ref:`step 3.1 > > ` > > +* tispl.bin, u-boot.img from :ref:`step 3.2 > > ` > > Use a single space? to separate. I think we should probably clean up > the other docs as follow on. > > > + > > +Image formats: > > +-- > > + > [...] > > > +Switch Setting for Boot Mode > > + > > + > > +Boot Mode pins provide means to select the boot mode and options before the > > +device is powered up. After every POR, they are the main source to populate > > +the Boot Parameter Tables. > > + > > +Boot Mode Pins for J721S2 > > J721S2-EVM ? > > > +^ > > + > > [...] > > > + > > +For SW8 and SW9, the switch state in the "ON" position = 1. > > + > > +Boot Mode Pins for AM68 > > SK-AM68 ? > > [..] > > > +Debugging U-Boot > > + > > + > > +See :ref:`Common Debugging environment - OpenOCD`: > > for > > +detailed setup information. > > + > > +.. warning:: > > + > > + **OpenOCD support since**: v0.12.0 > > + > > + If the default package version of OpenOCD in your development > > + environment's distribution needs to be updated, it might be necessary to > > + build OpenOCD from the source. > > + > > +.. include:: k3.rst > > +:start-after: .. k3_rst_include_start_openocd_connect_XDS110 > > +:end-before: .. k3_rst_include_end_openocd_connect_XDS110 > > + > > +To start OpenOCD and connect to the board > > + > > +.. code-block:: bash > > + > > + openocd -f board/ti_j721s2evm.cfg > > This will work for the evm, but the am68-SK doesn't seem to have XDS110 > on board. > > You will need the following sections to help debug on SK-AM68: > k3_rst_include_start_openocd_connect_cti20 > and: > k3_rst_include_start_openocd_cfg_external_intro > > and: > openocd_connect.cfg: > > .. code-block:: tcl > > # TUMPA example: > # http://www.tiaowiki.com/w/TIAO_USB_Multi_Protocol_Adapter_User's_Manual > source [find interface/ftdi/tumpa.cfg] > > transport select jtag > > # default JTAG
Re: [PATCH 2/2] risc-v: implement DBCN based debug console
On Sat, Aug 19, 2023 at 03:12:50PM +0200, Heinrich Schuchardt wrote: > Use the DBCN SBI extension to implement a debug console. > Make it the default for S-mode RISC-V. > > Signed-off-by: Heinrich Schuchardt > --- > drivers/serial/Kconfig | 3 ++- > drivers/serial/serial_sbi.c | 19 +++ > 2 files changed, 21 insertions(+), 1 deletion(-) Reviewed-by: Leo Yu-Chi Liang
Re: [PATCH 1/2] risc-v: implement DBCN write byte
On Sat, Aug 19, 2023 at 03:12:49PM +0200, Heinrich Schuchardt wrote: > The DBCN extension provides a Console Write Byte call. > Implement function sbi_dbcn_write_byte to invoke it. > > Signed-off-by: Heinrich Schuchardt > --- > arch/riscv/include/asm/sbi.h | 1 + > arch/riscv/lib/sbi.c | 16 > 2 files changed, 17 insertions(+) Reviewed-by: Leo Yu-Chi Liang
Re: [PATCH v3 2/2] x86: Update cbmem driver
Hi Simon,
On Thu, Aug 17, 2023 at 9:58 AM Simon Glass wrote:
>
> This driver is not actually built since a Kconfig was never created for
> it.
>
> Add a Kconfig (which is already implied by COREBOOT) and update the
> implementation to avoid using unnecessary memory. Drop the #ifdef at the
> top since we can rely on Kconfig to get that right.
>
> To enable it (in addition to serial and video), use:
>
>setenv stdout serial,vidconsole,cbmem
>
> Signed-off-by: Simon Glass
> ---
>
> (no changes since v2)
>
> Changes in v2:
> - Update to support the new overflow mechanism
>
> drivers/misc/Kconfig | 8
> drivers/misc/cbmem_console.c | 38 +++-
> 2 files changed, 28 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
> index a6e3f62ecb09..c930e4a361bf 100644
> --- a/drivers/misc/Kconfig
> +++ b/drivers/misc/Kconfig
> @@ -122,6 +122,14 @@ config VEXPRESS_CONFIG
> configuration bus on the Arm Versatile Express boards via
> a sysreg driver.
>
> +config CBMEM_CONSOLE
> + bool "Write console output to coreboot cbmem"
> + depends on X86
> + help
> + Enables console output to the cbmem console, which is a memory
> + region set up by coreboot to hold a record of all console output.
> + Enable this only if booting from coreboot.
> +
> config CMD_CROS_EC
> bool "Enable crosec command"
> depends on CROS_EC
> diff --git a/drivers/misc/cbmem_console.c b/drivers/misc/cbmem_console.c
> index 8bbe33d414da..7a47a814f638 100644
> --- a/drivers/misc/cbmem_console.c
> +++ b/drivers/misc/cbmem_console.c
> @@ -5,27 +5,30 @@
>
> #include
> #include
> -#ifndef CONFIG_SYS_COREBOOT
> -#error This driver requires coreboot
> -#endif
> -
> #include
>
> -struct cbmem_console {
> - u32 buffer_size;
> - u32 buffer_cursor;
> - u8 buffer_body[0];
> -} __attribute__ ((__packed__));
> -
> -static struct cbmem_console *cbmem_console_p;
> -
> void cbmemc_putc(struct stdio_dev *dev, char data)
> {
> - int cursor;
> -
> - cursor = cbmem_console_p->buffer_cursor++;
> - if (cursor < cbmem_console_p->buffer_size)
> - cbmem_console_p->buffer_body[cursor] = data;
> + const struct sysinfo_t *sysinfo = cb_get_sysinfo();
> + struct cbmem_console *cons;
> + uint pos, flags;
> +
> + if (!sysinfo)
> + return;
> + cons = sysinfo->cbmem_cons;
> + if (!cons)
> + return;
> +
> + pos = cons->cursor & CBMC_CURSOR_MASK;
> + flags = cons->cursor & ~CBMC_CURSOR_MASK;
This line does not seem useful to me, as we don't use the extracted
flag from the higher bits of cons->cursor.
I guess we can just drop it.
> +
> + cons->body[pos++] = data;
> + if (pos >= cons->size) {
> + pos = 0;
> + flags |= CBMC_OVERFLOW;
Who is supposed to clear the overflow flag?
> + }
> +
> + cons->cursor = flags | pos;
> }
>
> void cbmemc_puts(struct stdio_dev *dev, const char *str)
> @@ -40,7 +43,6 @@ int cbmemc_init(void)
> {
> int rc;
> struct stdio_dev cons_dev;
> - cbmem_console_p = lib_sysinfo.cbmem_cons;
>
> memset(_dev, 0, sizeof(cons_dev));
>
> --
Regards,
Bin
Re: [PATCH v3 1/2] x86: coreboot: Update cbmem table
Hi Simon,
On Thu, Aug 17, 2023 at 9:58 AM Simon Glass wrote:
>
> This changed a few years ago to include an overflow flag. Bring in the
> new structure.
s/This/Coreboot
"Bring in the new structure" does not sound correct to me. The
structure is not changed. It's adding a comment block and some bit
fields.
The commit summary is not accurately reflecting what is changed in
this patch. How about:
x86: coreboot: Document cbmem console struct
>
> This comes from coreboot commit:
>
>6f5ead14b4 ("mb/google/nissa/var/joxer: Update eMMC DLL settings")
>
> Note: There are several implementations of this in coreboot. I have chosen
> to follow the one in src/lib/cbmem_console.c
>
> Signed-off-by: Simon Glass
> ---
>
> Changes in v3:
> - Drop __packed as it does nothing useful
>
> arch/x86/include/asm/coreboot_tables.h | 17 +++--
> 1 file changed, 15 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/include/asm/coreboot_tables.h
> b/arch/x86/include/asm/coreboot_tables.h
> index 4de137fbab9d..0dfb64babb96 100644
> --- a/arch/x86/include/asm/coreboot_tables.h
> +++ b/arch/x86/include/asm/coreboot_tables.h
> @@ -299,11 +299,24 @@ struct cb_vdat {
> #define CB_TAG_TIMESTAMPS 0x0016
> #define CB_TAG_CBMEM_CONSOLE 0x0017
>
> +#define CBMC_CURSOR_MASK ((1 << 28) - 1)
> +#define CBMC_OVERFLOW BIT(31)
> +
> +/*
> + * struct cbmem_console - In-memory console buffer for coreboot
> + *
> + * Structure describing console buffer. It is overlaid on a flat memory area,
> + * with body covering the extent of the memory. Once the buffer is full,
> + * output will wrap back around to the start of the buffer. The high bit of
> the
> + * cursor field gets set to indicate that this happened. If the underlying
> + * storage allows this, the buffer will persist across multiple boots and
> append
> + * to the previous log.
> + */
> struct cbmem_console {
> u32 size;
> u32 cursor;
> - char body[0];
> -} __packed;
> + u8 body[0];
> +};
>
> #define CB_TAG_MRC_CACHE 0x0018
>
> --
Regards,
Bin
Re: [PATCH 1/2] rockchip: Use an external TPL binary on RK3308
Hi Massimo, On 2023/9/3 18:04, Massimo Pegorer wrote: Il giorno sab 2 set 2023 alle ore 18:32 Massimo Pegorer ha scritto: There is no support to initialize DRAM on RK3308 SoC using U-Boot TPL and therefore an external TPL binary must be used to generate a bootable u-boot-rockchip.bin image. Imply ROCKCHIP_EXTERNAL_TPL by default for RK3308 builds. Remove useless TPL_SERIAL. Signed-off-by: Massimo Pegorer --- arch/arm/mach-rockchip/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig index a279582f4f..e8584de258 100644 --- a/arch/arm/mach-rockchip/Kconfig +++ b/arch/arm/mach-rockchip/Kconfig @@ -159,6 +159,7 @@ config ROCKCHIP_RK3308 select SPL_ATF select SPL_ATF_NO_PLATFORM_PARAM select SPL_LOAD_FIT + imply ROCKCHIP_EXTERNAL_TPL imply ROCKCHIP_COMMON_BOARD imply SPL_ROCKCHIP_COMMON_BOARD imply SPL_CLK @@ -166,7 +167,6 @@ config ROCKCHIP_RK3308 imply SPL_SYSCON imply SPL_RAM imply SPL_SERIAL - imply TPL_SERIAL imply SPL_SEPARATE_BSS help The Rockchip RK3308 is a ARM-based Soc which embedded with quad -- 2.34.1 I've just noticed that Jonas followed a different approach for RK3568 and RK3588: config ROCKCHIP_EXTERNAL_TPL bool "Use external TPL binary" default y if ROCKCHIP_RK3568 || ROCKCHIP_RK3588 You can add RK3308 to default y. Thanks, - Kever Is any one preferred? I slightly prefer the one I've done, as it gives a terse picture of what a SoC select/imply in a single place. Of course I can change it in a V2, if Jonas way is preferred, and to have a single congruent way to do things. Thanks. Regards, Massimo
[RFC PATCH 5/5] board: stm32f469-disco: add splash screen with stmicroelectronics logo
Display the STMicroelectronics logo with features VIDEO_LOGO and
SPLASH_SCREEN on stm32f469-disco board.
Signed-off-by: Dario Binacchi
---
configs/stm32f469-discovery_defconfig | 3 +++
include/configs/stm32f469-discovery.h | 2 ++
tools/logos/stm32f469-discovery.bmp | Bin 0 -> 18532 bytes
3 files changed, 5 insertions(+)
create mode 100644 tools/logos/stm32f469-discovery.bmp
diff --git a/configs/stm32f469-discovery_defconfig
b/configs/stm32f469-discovery_defconfig
index 9796b8f2d9a5..16b79371fde9 100644
--- a/configs/stm32f469-discovery_defconfig
+++ b/configs/stm32f469-discovery_defconfig
@@ -42,12 +42,15 @@ CONFIG_SPI=y
CONFIG_DM_SPI=y
CONFIG_STM32_QSPI=y
CONFIG_VIDEO=y
+CONFIG_VIDEO_LOGO=y
CONFIG_BACKLIGHT_GPIO=y
CONFIG_VIDEO_LCD_ORISETECH_OTM8009A=y
CONFIG_VIDEO_STM32=y
CONFIG_VIDEO_STM32_DSI=y
CONFIG_VIDEO_STM32_MAX_XRES=480
CONFIG_VIDEO_STM32_MAX_YRES=800
+CONFIG_SPLASH_SCREEN=y
+CONFIG_SPLASH_SCREEN_ALIGN=y
CONFIG_BMP_16BPP=y
CONFIG_BMP_24BPP=y
CONFIG_BMP_32BPP=y
diff --git a/include/configs/stm32f469-discovery.h
b/include/configs/stm32f469-discovery.h
index 62a7e9af0c56..75bb9cd8d06f 100644
--- a/include/configs/stm32f469-discovery.h
+++ b/include/configs/stm32f469-discovery.h
@@ -31,6 +31,8 @@
"scriptaddr=0x00418000\0" \
"pxefile_addr_r=0x00428000\0" \
"ramdisk_addr_r=0x00438000\0" \
+ "splashimage=0x00448000\0" \
+ "splashpos=m,m\0" \
BOOTENV
#endif /* __CONFIG_H */
diff --git a/tools/logos/stm32f469-discovery.bmp
b/tools/logos/stm32f469-discovery.bmp
new file mode 100644
index
..ecc8d984218fb13fddf0ba9cf68f2cfad829e289
GIT binary patch
literal 18532
zcmeI4cXZX(r;65wa7qNk~Y5gbqmv5Fw!j5+O7xl9*5>^j-qed+)tS@6wBaRB3{M
zG^rvTq<29PJ?imP-e<18^`MV)eL3Teaql13aUl7vHRoJ>
z%wT@IEylFuj~FL^jJa0Tn0Xc4f9!w`nis$P$Pk$_ux+`yR-Z4+5RH;%y
z?c2AH;7{iH^XL1#;d|MuNYiPtO8m=zEccuLUc7i=rj8tL{`t>;n(v=~XLfJfVn+4u
zWiDU5VCn>CGXMC;KTO@od?q<8o7uN>r}_EkpUhwX`d8EO?IiP$zyIB&6v$~VpTA)K
z_P4*8AHM`O9DaV*d2q_oiOaLS|rxcIM{w>!w$Wrlvu35%ZUye>UrvFE{t^-Zg)P
zu4|(P=Bvk#%nv{OV3y6BV{UwT&0M>3*|d4Hs`=*YZ%mJ-Y39#A{bas<_O1Ey>Q
zO)GQh++YlrF5u%3B;_H5I#N+t8>KmXYbN$+HyeD#$X(7vtNw04a-@bSkc
zEiTr4{p6{6_RTZXA*r_c```a#0boIQDx=f9h;pFTAUr%yA-4<9zSZd^A#
zn>8_KPn|OBmM%5z-l}0brY4(K)e_Cog9pvV)vLhZXVbP;b#wjNHPftO9Bcn*zBql_
z^l8;
zKHawu`se1{nKNem!2V`f*DmJAKmB07`|ew_XZv<@>a)+xl}i`Rkpl-z|F*5oiuvD!_Z!@-kU-KM2hjvLfy<0Xjj~+fS5AWYMTi1VJ9zT3}`M&^DAce
zmaS@L}fO-8*L4+)Uk${{3d@oZ0N}p;@zdu{nMGxVd!Uym|WMiP^qkqglCd
zp&8k$r#b)m=jP6>o95ydUzlwh*PB5d+ncrTzi(D8T42Tv=x06y?;n5s(QH}2*FM
z!aTTt&)mIz%Y1g|koo56*XH)k8)o5q)6FNlcA1SUSDGWN`@ynh=>5!`Vo#HX3^sEo
zO~h}$G)rdAH1nrUF(;26H6MMr(JY$r9{6p=X8X;$m_wF$t
zu2~IkpP0?-)|v@}2C#=?tasBqxOWd9dW`O8&5W_5?o`iK6<3tuxh3Gbnjm5
ze$_0WH_u!=f6hF7aNk@wd)7R9@W33{vj?6rX7aG1=GdWwX6CrDX34BsX7+^f=EAuz
z%txCxn*Dornc>~KniEG4n-M*_ne{7Im@)nOn8h<@n4Oz8n>9<8m|a^po6qshJ7BSG
z!+K)mv6(bHu|NHm1N?G|rg1=+_hC$M4*(N>?Z)qs`WFc~HNu<1h8)4r5cqQCcOoNHmft
z!SJ|bn0TqQBqQgfW9B!dl01}Z(%xaDvV1C)7+-FP5(hno6C2M!N^zw5!|Bf+KmSGQYr5wml9QdhiLQazp*)o9kHmS-K0R0+a~L!mZPzhapj|iFFKZ>4DDjmcG7H=Fw|E4xehEA`
zhFupB2M7g91<)ETPcy40T?B_}j77jTkm#r+eqc3N)_}ND#1WB4L3}&9TL&?5`{;a1-R_(?nb={4f^7G5{aW0~=9MD_}`GUD;j8sIn^Uvsk0K;rbWq$;jgb?wQ64h88L!ot
z$xa>|futPlH7_ftAw7U>SeRY+hVCG7;6hI)KK+^Mi3ZVfTPCt|nmHj0@o~7Bdr?f-%FygkJ_@IX`qa%oc_HdO4*MSn^>rEct4c_;e3t@#k
z9!%?^>r`@eDYO|*{BI@Cp9R~uWiR7ZWDeuG-TSMBm5wR4pV7WW{+le^tf81EEUAoBgoFF^OZow!9wL*;>@Jh`9=~EL_U}uLU(C!FnZ`aG;8=h>swmz^k>Q;*wX5Yap
z-SJk`#z+~(9E*0466|e=jkjvhwIQ}$?9PwKZpd>9{HChpL8ce}Qxudh+sF^Wrw>aa
zlxo#ttW)o$C{&-x@lq64;n^2C1wg=y3LK8)9C-XucJ5_y8$~5uAWMiB_2A}Gn)q%&
zg(?B%Q=*|R^==rH!Q|;Jc=lRp0tP;Kn~l>H!`#Qvo?=f$z$gGYpYVG#_T~$Quj4Oo
z3IT@CUShnPT(I%kkbSmitq&!HtXrM>6H6>PSUWegA$ZYOHYyXycn3u@=P&!slzT
zN(?_|vabpt(u;X(7h=c3$Yq|-$Qss;z&4?1oKZWxVf!Y{4qi4U_E@c>!Ej_ov1gY{
zsdEF-Ie@zHmb63b1bIXDu+wBBC=jn}$Furw0A5m8{8+Oz)<|I=FJm1n>)_c3j)ST0
z|H3+x#X1WsIk41J0cE^DE^Fc%LBBv>)^*W)?E{7#e?QUHEU6
zm#`iwnQR|CN6Mp-KQVahC8V*u_32O|vAgXZA{ZG6MTXEOmXd5=98MLa?y^z>`Fg8e
zIiC9CfFeWQM1(CS{J2WP~ref73#=Ou%
z{d>$xL9cn
z6;ks|#t;lSjl>G8t1A+vRR<`%$32W##;~{x{Zsf*l0Qde*+es1wu<%LhEUQClIm`Mrj?(90#)
z`8}hUowKWErI*bt-TZP=D_1(YqtlrG$nW-(jkFgXjd!W6iR7G#SbG@K{H24<_4TAE
zJ9Mz$jAA&(X1Y*NtS%#5x#`EwAT^9R8^+@pjdH38{S#HscvZv29zGssM(LMeW$
zWjs%A{2s|-ejgoRmhxKB5Euk#V2<*yf#@^pT6RB8gm3
z(DvSVFf}|GUt2CK(XvK{F`K4+cQ(!P1F6x9Q#Y{jLGQ8>2vWo7$9%{SFC$fw
zmX`3jk?Lle^3@RX?gp^`9fv&~$f(v8!zF8p7o+Cy6nBeL2nSvzg;K8D6n#L`8`~>QI}%4qK#c
z-6VgxdP8+1_WC)x>j`AszDBFDwTy_AkiPp=E!AmcsdMkNs!Ysz=q(L9TTRuB2C)lL0KGEXUPQaD
zm$O+35bh6O6rQGg7_JrR75H_sC*?HcI5>fqfzp@GN-JkwS0o2!qlV_ivWp7WK!+m|7!%@y>T=28c0S+g73PN;pz7X
z=3>RcAb8S7=q`Q>luFQDWIT}F1>>RGJ!VBGy{~QYJ8yQMwZq{b1cqPH*K0PKBiV`E
z-+N#Md4}ZUQW$MokPY-*!!f!dMf8ZhqpK)um>Wz*P@l;dh7QgU+u-uW3+K~wS0;A#
zgmAd*6ey*%i#U4}CIr3AlpjtgO(Lafrs=EP7a^;YyZ
zNOD@LYwtX2lJN?#({|jr=_y*z&??Kx}+$!EXDX+yUrum^U%H*>
zZ2hGqw(>!K@^KQ}dc)a^Y*0ZGK|hJEKqE7U
[RFC PATCH 4/5] ARM: dts: stm32: support display on stm32f469-disco board
Add support to Orise Tech OTM8009A display on stm32f469-disco board.
It was necessary to retrieve the framebuffer address from the device tree
because the address returned by the video-uclass driver pointed to a memory
area that was not usable.
Furthermore, unlike Linux, the DSI driver requires the LTDC clock to be
properly probed. Hence, the changes made to the DSI node in
stm32f469-disco-u-boot.dtsi.
Signed-off-by: Dario Binacchi
---
arch/arm/dts/stm32f469-disco-u-boot.dtsi | 4 +++
configs/stm32f469-discovery_defconfig| 13 +
drivers/video/stm32/stm32_ltdc.c | 37 +++-
3 files changed, 53 insertions(+), 1 deletion(-)
diff --git a/arch/arm/dts/stm32f469-disco-u-boot.dtsi
b/arch/arm/dts/stm32f469-disco-u-boot.dtsi
index 8e781c5a7b23..47ba9fa4a783 100644
--- a/arch/arm/dts/stm32f469-disco-u-boot.dtsi
+++ b/arch/arm/dts/stm32f469-disco-u-boot.dtsi
@@ -92,7 +92,9 @@
{
clocks = < 0 STM32F4_APB2_CLOCK(DSI)>,
+< 0 STM32F4_APB2_CLOCK(LTDC)>,
<_hse>;
+ clock-names = "pclk", "px_clk", "ref";
};
{
@@ -140,6 +142,8 @@
};
{
+ bootph-all;
+
clocks = < 0 STM32F4_APB2_CLOCK(LTDC)>;
};
diff --git a/configs/stm32f469-discovery_defconfig
b/configs/stm32f469-discovery_defconfig
index 35d18d58be6f..9796b8f2d9a5 100644
--- a/configs/stm32f469-discovery_defconfig
+++ b/configs/stm32f469-discovery_defconfig
@@ -21,6 +21,7 @@ CONFIG_CMD_GPT=y
# CONFIG_RANDOM_UUID is not set
CONFIG_CMD_MMC=y
# CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_BMP=y
CONFIG_CMD_CACHE=y
CONFIG_CMD_TIMER=y
# CONFIG_ISO_PARTITION is not set
@@ -40,3 +41,15 @@ CONFIG_SPI_FLASH_STMICRO=y
CONFIG_SPI=y
CONFIG_DM_SPI=y
CONFIG_STM32_QSPI=y
+CONFIG_VIDEO=y
+CONFIG_BACKLIGHT_GPIO=y
+CONFIG_VIDEO_LCD_ORISETECH_OTM8009A=y
+CONFIG_VIDEO_STM32=y
+CONFIG_VIDEO_STM32_DSI=y
+CONFIG_VIDEO_STM32_MAX_XRES=480
+CONFIG_VIDEO_STM32_MAX_YRES=800
+CONFIG_BMP_16BPP=y
+CONFIG_BMP_24BPP=y
+CONFIG_BMP_32BPP=y
+CONFIG_DM_REGULATOR=y
+CONFIG_DM_REGULATOR_FIXED=y
diff --git a/drivers/video/stm32/stm32_ltdc.c b/drivers/video/stm32/stm32_ltdc.c
index f48badc517a8..428b0addc43c 100644
--- a/drivers/video/stm32/stm32_ltdc.c
+++ b/drivers/video/stm32/stm32_ltdc.c
@@ -494,6 +494,34 @@ static void stm32_ltdc_set_layer1(struct stm32_ltdc_priv
*priv, ulong fb_addr)
setbits_le32(priv->regs + LTDC_L1CR, LXCR_LEN);
}
+#if IS_ENABLED(CONFIG_TARGET_STM32F469_DISCOVERY)
+static int stm32_ltdc_get_fb_addr(struct udevice *dev, ulong *base, uint size,
+ uint align)
+{
+ phys_addr_t cpu;
+ dma_addr_t bus;
+ u64 dma_size;
+ int ret;
+
+ ret = dev_get_dma_range(dev, , , _size);
+ if (ret) {
+ dev_err(dev, "failed to get dma address\n");
+ return ret;
+ }
+
+ *base = bus + 0x100 - ALIGN(size, align);
+ return 0;
+}
+#else
+static int stm32_ltdc_get_fb_addr(struct udevice *dev, ulong *base, uint size,
+ uint align)
+{
+ /* Delegate framebuffer allocation to video-uclass */
+ *base = 0;
+ return 0;
+}
+#endif
+
static int stm32_ltdc_probe(struct udevice *dev)
{
struct video_uc_plat *uc_plat = dev_get_uclass_plat(dev);
@@ -504,7 +532,7 @@ static int stm32_ltdc_probe(struct udevice *dev)
struct display_timing timings;
struct clk pclk;
struct reset_ctl rst;
- ulong rate;
+ ulong rate, fb_base;
int ret;
priv->regs = dev_read_addr_ptr(dev);
@@ -604,6 +632,13 @@ static int stm32_ltdc_probe(struct udevice *dev)
priv->crop_h = timings.vactive.typ;
priv->alpha = 0xFF;
+ ret = stm32_ltdc_get_fb_addr(dev, _base, uc_plat->size,
+uc_plat->align);
+ if (ret)
+ return ret;
+
+ uc_plat->base = fb_base;
+
dev_dbg(dev, "%dx%d %dbpp frame buffer at 0x%lx\n",
timings.hactive.typ, timings.vactive.typ,
VNBITS(priv->l2bpp), uc_plat->base);
--
2.34.1
[RFC PATCH 3/5] ARM: dts: stm32: make the DSI clock usable by the clock driver
As described in [1], the "clocks" property contains "a phandle to the
clock device node, an index selecting between gated clocks (0) and other
clocks (1), and an index specifying the clock to use." The current version
of the clock driver, unlike the kernel, is currently able to properly
handle nodes with "clocks" properties with an index set to 0.
This patch is preparatory for future developments that require the use
of the DSI clock.
[1] Documentation/devicetree/bindings/clock/st,stm32-rcc.txt
Signed-off-by: Dario Binacchi
---
arch/arm/dts/stm32f469-disco-u-boot.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/dts/stm32f469-disco-u-boot.dtsi
b/arch/arm/dts/stm32f469-disco-u-boot.dtsi
index dcc70369cd0d..8e781c5a7b23 100644
--- a/arch/arm/dts/stm32f469-disco-u-boot.dtsi
+++ b/arch/arm/dts/stm32f469-disco-u-boot.dtsi
@@ -90,6 +90,11 @@
bootph-all;
};
+ {
+ clocks = < 0 STM32F4_APB2_CLOCK(DSI)>,
+<_hse>;
+};
+
{
bootph-all;
};
--
2.34.1
[RFC PATCH 2/5] ARM: dts: stm32: make the LTDC clock usable by the clock driver
As described in [1], the "clocks" property contains "a phandle to the
clock device node, an index selecting between gated clocks (0) and other
clocks (1), and an index specifying the clock to use." The current version
of the clock driver, unlike the kernel, is currently able to properly
handle nodes with "clocks" properties with an index set to 0.
This patch is preparatory for future developments that require the use
of the LTDC clock.
[1] Documentation/devicetree/bindings/clock/st,stm32-rcc.txt
Signed-off-by: Dario Binacchi
---
arch/arm/dts/stm32f469-disco-u-boot.dtsi | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/dts/stm32f469-disco-u-boot.dtsi
b/arch/arm/dts/stm32f469-disco-u-boot.dtsi
index c07e2022e4a8..dcc70369cd0d 100644
--- a/arch/arm/dts/stm32f469-disco-u-boot.dtsi
+++ b/arch/arm/dts/stm32f469-disco-u-boot.dtsi
@@ -134,6 +134,10 @@
bootph-all;
};
+ {
+ clocks = < 0 STM32F4_APB2_CLOCK(LTDC)>;
+};
+
{
bootph-all;
--
2.34.1
[RFC PATCH 1/5] ARM: dts: stm32f469-disco: sync with Linux 6.5
Sync the devicetree with linux 6.5 for stm32f746-disco board.
Signed-off-by: Dario Binacchi
---
arch/arm/dts/stm32f469-disco.dts | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/dts/stm32f469-disco.dts b/arch/arm/dts/stm32f469-disco.dts
index 6e0ffc1903be..c9acabf0f530 100644
--- a/arch/arm/dts/stm32f469-disco.dts
+++ b/arch/arm/dts/stm32f469-disco.dts
@@ -119,7 +119,7 @@
};
};
- panel-dsi@0 {
+ panel@0 {
compatible = "orisetech,otm8009a";
reg = <0>; /* dsi virtual channel (0..3) */
reset-gpios = < 7 GPIO_ACTIVE_LOW>;
@@ -138,7 +138,7 @@
status = "okay";
port {
- ltdc_out_dsi: endpoint@0 {
+ ltdc_out_dsi: endpoint {
remote-endpoint = <_in>;
};
};
--
2.34.1
[RFC PATCH 0/5] Support display on stm32f469-disco board
The series adds support for the Orise Tech OTM8009A display on the stm32f469-disco board. Substantial differences in the drivers for clock management, LTDC and DSI compared to Linux, made it necessary to modify the device tree. These changes were made in stm32f469-disco-uboot.dtsi to avoid altering the Linux device tree. It is therefore desirable, as soon as possible, to add these drivers the functionalities so that they do not require device tree properties that deviate from those present in the Linux version. Dario Binacchi (5): ARM: dts: stm32f469-disco: sync with Linux 6.5 ARM: dts: stm32: make the LTDC clock usable by the clock driver ARM: dts: stm32: make the DSI clock usable by the clock driver ARM: dts: stm32: support display on stm32f469-disco board board: stm32f469-disco: add splash screen with stmicroelectronics logo arch/arm/dts/stm32f469-disco-u-boot.dtsi | 13 arch/arm/dts/stm32f469-disco.dts | 4 +-- configs/stm32f469-discovery_defconfig| 16 ++ drivers/video/stm32/stm32_ltdc.c | 37 ++- include/configs/stm32f469-discovery.h| 2 ++ tools/logos/stm32f469-discovery.bmp | Bin 0 -> 18532 bytes 6 files changed, 69 insertions(+), 3 deletions(-) create mode 100644 tools/logos/stm32f469-discovery.bmp -- 2.34.1
[PATCH 10/10] ARM: dts: stm32: support display on stm32f746-disco board
The patch applies the changes from Linux commit 10a970bc3ebfa ("ARM: dts:
stm32: support display on stm32f746-disco board") and removes the same
settings from stm32f746-disco-u-boot.dtsi.
Signed-off-by: Dario Binacchi
---
arch/arm/dts/stm32f746-disco-u-boot.dtsi | 89 ++--
arch/arm/dts/stm32f746-disco.dts | 44
2 files changed, 66 insertions(+), 67 deletions(-)
diff --git a/arch/arm/dts/stm32f746-disco-u-boot.dtsi
b/arch/arm/dts/stm32f746-disco-u-boot.dtsi
index 3c2b9fc59512..1b42d6cbbc19 100644
--- a/arch/arm/dts/stm32f746-disco-u-boot.dtsi
+++ b/arch/arm/dts/stm32f746-disco-u-boot.dtsi
@@ -23,12 +23,6 @@
spi0 =
};
- backlight: backlight {
- compatible = "gpio-backlight";
- gpios = < 3 0>;
- status = "okay";
- };
-
button1 {
compatible = "st,button1";
button-gpio = < 11 0>;
@@ -38,37 +32,10 @@
compatible = "st,led1";
led-gpio = < 1 0>;
};
-
- panel-rgb@0 {
- compatible = "simple-panel";
- backlight = <>;
- enable-gpios = < 12 0>;
- status = "okay";
-
- display-timings {
- timing@0 {
- clock-frequency = <900>;
- hactive = <480>;
- vactive = <272>;
- hfront-porch = <2>;
- hback-porch = <2>;
- hsync-len = <41>;
- vfront-porch = <2>;
- vback-porch = <2>;
- vsync-len = <10>;
- hsync-active = <0>;
- vsync-active = <0>;
- de-active = <1>;
- pixelclk-active = <1>;
- };
- };
- };
};
{
clocks = < 0 STM32F7_APB2_CLOCK(LTDC)>;
- pinctrl-0 = <_pins>;
- status = "okay";
bootph-all;
};
@@ -96,6 +63,28 @@
};
};
+_rgb {
+ compatible = "simple-panel";
+
+ display-timings {
+ timing@0 {
+ clock-frequency = <900>;
+ hactive = <480>;
+ vactive = <272>;
+ hfront-porch = <2>;
+ hback-porch = <2>;
+ hsync-len = <41>;
+ vfront-porch = <2>;
+ vback-porch = <2>;
+ vsync-len = <10>;
+ hsync-active = <0>;
+ vsync-active = <0>;
+ de-active = <1>;
+ pixelclk-active = <1>;
+ };
+ };
+};
+
{
ethernet_mii: mii@0 {
pins {
@@ -160,40 +149,6 @@
};
};
- ltdc_pins: ltdc@0 {
- pins {
- pinmux = , /* B0 */
-, /* B4 */
-, /* VSYNC */
-, /* HSYNC */
-, /* CLK */
-, /* R0 */
-, /* R1 */
-, /* R2 */
-, /* R3 */
-, /* R4 */
-, /* R5 */
-, /* R6 */
-, /* R7 */
-, /* G0 */
-, /* G1 */
-, /* G2 */
-, /* G3 */
-, /* G4 */
-, /* B1 */
-, /* B2 */
-, /* B3 */
-, /* G5 */
-, /* G6 */
-, /* G7 */
-, /* B5 */
-, /* B6 */
-, /* B7 */
-; /* DE */
- slew-rate = <2>;
- };
- };
-
qspi_pins: qspi@0 {
pins {
pinmux = , /* CLK */
diff --git a/arch/arm/dts/stm32f746-disco.dts b/arch/arm/dts/stm32f746-disco.dts
index e1564d69f9f6..431275134033 100644
--- a/arch/arm/dts/stm32f746-disco.dts
+++ b/arch/arm/dts/stm32f746-disco.dts
@@ -25,6 +25,19 @@
reg = <0xC000 0x80>;
};
+ reserved-memory {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ linux,cma {
+ compatible = "shared-dma-pool";
+
[PATCH 05/10] ARM: dts: stm32: add pin map for i2c3 controller on stm32f7
commit 0637e66f8250c61f75042131fcb7f88ead2ad436 Linux upstream.
Add pin configurations for using i2c3 controller on stm32f7.
Signed-off-by: Dario Binacchi
Signed-off-by: Alexandre Torgue
---
arch/arm/dts/stm32f7-pinctrl.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/dts/stm32f7-pinctrl.dtsi
b/arch/arm/dts/stm32f7-pinctrl.dtsi
index 000278ec2c58..607fe42f4f46 100644
--- a/arch/arm/dts/stm32f7-pinctrl.dtsi
+++ b/arch/arm/dts/stm32f7-pinctrl.dtsi
@@ -172,6 +172,16 @@
};
};
+ i2c3_pins_a: i2c3-0 {
+ pins {
+ pinmux = ,
/* I2C3_SDA */
+;
/* I2C3_SCL */
+ bias-disable;
+ drive-open-drain;
+ slew-rate = <0>;
+ };
+ };
+
usbotg_hs_pins_a: usbotg-hs-0 {
pins {
pinmux = ,
/* OTG_HS_ULPI_NXT */
--
2.34.1
[PATCH 09/10] ARM: dts: stm32: rename mmc_vcard to vcc-3v3 on stm32f746-disco
commit e4e724099f04072053cf411456e3e9aae48c4af1 Linux upstream.
In the schematics of document UM1907, the power supply for the micro SD
card is the same 3v3 voltage that is used to power other devices on the
board. By generalizing the name of the voltage regulator, it can be
referenced by other nodes in the device tree without creating
misunderstandings.
This patch is preparatory for future developments.
Signed-off-by: Dario Binacchi
Signed-off-by: Alexandre Torgue
---
arch/arm/dts/stm32f746-disco.dts | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/dts/stm32f746-disco.dts b/arch/arm/dts/stm32f746-disco.dts
index 9541f449fd0e..e1564d69f9f6 100644
--- a/arch/arm/dts/stm32f746-disco.dts
+++ b/arch/arm/dts/stm32f746-disco.dts
@@ -44,9 +44,9 @@
regulator-always-on;
};
- mmc_vcard: mmc_vcard {
+ vcc_3v3: vcc-3v3 {
compatible = "regulator-fixed";
- regulator-name = "mmc_vcard";
+ regulator-name = "vcc_3v3";
regulator-min-microvolt = <330>;
regulator-max-microvolt = <330>;
};
@@ -82,7 +82,7 @@
{
status = "okay";
- vmmc-supply = <_vcard>;
+ vmmc-supply = <_3v3>;
cd-gpios = < 13 GPIO_ACTIVE_LOW>;
pinctrl-names = "default", "opendrain";
pinctrl-0 = <_pins_a>;
--
2.34.1
[PATCH 08/10] ARM: dts: stm32: add pin map for LTDC on stm32f7
commit ba287d1a0137702a224b1f48673d529257b3c4bf Linux upstream.
Add pin configurations for using LTDC (LCD-tft Display Controller) on
stm32f746-disco board.
Signed-off-by: Dario Binacchi
Reviewed-by: Raphaël Gallais-Pou
Signed-off-by: Alexandre Torgue
---
arch/arm/dts/stm32f7-pinctrl.dtsi | 34 +++
1 file changed, 34 insertions(+)
diff --git a/arch/arm/dts/stm32f7-pinctrl.dtsi
b/arch/arm/dts/stm32f7-pinctrl.dtsi
index 607fe42f4f46..d3706ee33b5f 100644
--- a/arch/arm/dts/stm32f7-pinctrl.dtsi
+++ b/arch/arm/dts/stm32f7-pinctrl.dtsi
@@ -376,6 +376,40 @@
bias-pull-up;
};
};
+
+ ltdc_pins_a: ltdc-0 {
+ pins {
+ pinmux = ,
/* LCD_B0 */
+,
/* LCD_B4 */
+,
/* LCD_VSYNC */
+,
/* LCD_HSYNC */
+,
/* LCD_CLK */
+,
/* LCD_R0 */
+,
/* LCD_R1 */
+,
/* LCD_R2 */
+,
/* LCD_R3 */
+,
/* LCD_R4 */
+,
/* LCD_R5 */
+,
/* LCD_R6 */
+,
/* LCD_R7 */
+,
/* LCD_G0 */
+,
/* LCD_G1 */
+,
/* LCD_G2 */
+,
/* LCD_G3 */
+,
/* LCD_G4 */
+,
/* LCD_B1 */
+,
/* LCD_B2 */
+,
/* LCD_B3 */
+,
/* LCD_G5 */
+,
/* LCD_G6 */
+,
/* LCD_G7 */
+,
/* LCD_B5 */
+,
/* LCD_B6 */
+,
/* LCD_B7 */
+;
/* LCD_DE */
+ slew-rate = <2>;
+ };
+ };
};
};
};
--
2.34.1
[PATCH 07/10] ARM: dts: stm32: add ltdc support on stm32f746 MCU
The patch applies the changes from Linux commit 008ef8b3a1a00 ("Add LTDC
(Lcd-tft Display Controller) support") and removes the same settings
from stm32f746-disco-u-boot.dtsi.
Signed-off-by: Dario Binacchi
---
arch/arm/dts/stm32f746-disco-u-boot.dtsi | 18 ++
arch/arm/dts/stm32f746.dtsi | 10 ++
2 files changed, 16 insertions(+), 12 deletions(-)
diff --git a/arch/arm/dts/stm32f746-disco-u-boot.dtsi
b/arch/arm/dts/stm32f746-disco-u-boot.dtsi
index 522cffb1ac9f..3c2b9fc59512 100644
--- a/arch/arm/dts/stm32f746-disco-u-boot.dtsi
+++ b/arch/arm/dts/stm32f746-disco-u-boot.dtsi
@@ -63,19 +63,13 @@
};
};
};
+};
- soc {
- ltdc: display-controller@40016800 {
- compatible = "st,stm32-ltdc";
- reg = <0x40016800 0x200>;
- resets = < STM32F7_APB2_RESET(LTDC)>;
- clocks = < 0 STM32F7_APB2_CLOCK(LTDC)>;
- pinctrl-0 = <_pins>;
-
- status = "okay";
- bootph-all;
- };
- };
+ {
+ clocks = < 0 STM32F7_APB2_CLOCK(LTDC)>;
+ pinctrl-0 = <_pins>;
+ status = "okay";
+ bootph-all;
};
{
diff --git a/arch/arm/dts/stm32f746.dtsi b/arch/arm/dts/stm32f746.dtsi
index 7b4bd805c998..79dad3192e15 100644
--- a/arch/arm/dts/stm32f746.dtsi
+++ b/arch/arm/dts/stm32f746.dtsi
@@ -518,6 +518,16 @@
};
};
+ ltdc: display-controller@40016800 {
+ compatible = "st,stm32-ltdc";
+ reg = <0x40016800 0x200>;
+ interrupts = <88>, <89>;
+ resets = < STM32F7_APB2_RESET(LTDC)>;
+ clocks = < 1 CLK_LCD>;
+ clock-names = "lcd";
+ status = "disabled";
+ };
+
pwrcfg: power-config@40007000 {
compatible = "st,stm32-power-config", "syscon";
reg = <0x40007000 0x400>;
--
2.34.1
[PATCH 04/10] ARM: dts: stm32: use RCC macro for CRC node on stm32f746
commit 7a5f349e592c254f3c1ac34665b6c3905576efc2 Linux upstream.
The patch replaces the number 12 with the appropriate numerical constant
already defined in the file stm32f7-rcc.h.
Signed-off-by: Dario Binacchi
Signed-off-by: Alexandre Torgue
---
arch/arm/dts/stm32f746.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/dts/stm32f746.dtsi b/arch/arm/dts/stm32f746.dtsi
index dc5c257fb5fb..7b4bd805c998 100644
--- a/arch/arm/dts/stm32f746.dtsi
+++ b/arch/arm/dts/stm32f746.dtsi
@@ -526,7 +526,7 @@
crc: crc@40023000 {
compatible = "st,stm32f7-crc";
reg = <0x40023000 0x400>;
- clocks = < 0 12>;
+ clocks = < 0 STM32F7_AHB1_CLOCK(CRC)>;
status = "disabled";
};
--
2.34.1
[PATCH 06/10] ARM: dts: stm32: add touchscreen on stm32f746-disco board
commit f0215440069c4fb12958d2d321e05faa2708a11d Linux upstream.
The patch adds support for touchscreen on the stm32f746-disco board.
Signed-off-by: Dario Binacchi
Signed-off-by: Alexandre Torgue
---
arch/arm/dts/stm32f746-disco.dts | 19 ++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/arch/arm/dts/stm32f746-disco.dts b/arch/arm/dts/stm32f746-disco.dts
index 1ed58f236149..9541f449fd0e 100644
--- a/arch/arm/dts/stm32f746-disco.dts
+++ b/arch/arm/dts/stm32f746-disco.dts
@@ -7,8 +7,9 @@
/dts-v1/;
#include "stm32f746.dtsi"
#include "stm32f746-pinctrl.dtsi"
-#include
#include
+#include
+#include
/ {
model = "STMicroelectronics STM32F746-DISCO board";
@@ -63,6 +64,22 @@
status = "okay";
};
+ {
+ pinctrl-0 = <_pins_a>;
+ pinctrl-names = "default";
+ clock-frequency = <40>;
+ status = "okay";
+
+ touchscreen@38 {
+ compatible = "edt,edt-ft5306";
+ reg = <0x38>;
+ interrupt-parent = <>;
+ interrupts = <13 IRQ_TYPE_EDGE_FALLING>;
+ touchscreen-size-x = <480>;
+ touchscreen-size-y = <272>;
+ };
+};
+
{
status = "okay";
vmmc-supply = <_vcard>;
--
2.34.1
[PATCH 03/10] ARM: dts: stm32: add CAN support on stm32f746
commit 0920ccdf41e3078a4dd2567eb905ea154bc826e6 Linux upstream.
Add support for bxcan (Basic eXtended CAN controller) to STM32F746. The
chip contains three CAN peripherals, CAN1 and CAN2 in dual peripheral
configuration and CAN3 in single peripheral configuration:
- Dual CAN peripheral configuration:
* CAN1: Primary bxCAN for managing the communication between a secondary
bxCAN and the 512-byte SRAM memory.
* CAN2: Secondary bxCAN with no direct access to the SRAM memory.
This means that the two bxCAN cells share the 512-byte SRAM memory and
CAN2 can't be used without enabling CAN1.
- Single CAN peripheral configuration:
* CAN3: Primary bxCAN with dedicated Memory Access Controller unit and
512-byte SRAM memory.
-
| features | CAN1 | CAN2 | CAN 3 |
-
| SRAM | 512-byte shared between CAN1 & CAN2| 512-byte|
-
| Filters | 26 filters shared between CAN1 & CAN2 | 14 filters |
-
Signed-off-by: Dario Binacchi
Link:
https://lore.kernel.org/all/20230427204540.3126234-6-dario.binac...@amarulasolutions.com
Signed-off-by: Marc Kleine-Budde
---
arch/arm/dts/stm32f746.dtsi | 47 +
1 file changed, 47 insertions(+)
diff --git a/arch/arm/dts/stm32f746.dtsi b/arch/arm/dts/stm32f746.dtsi
index c97b3d0d07db..dc5c257fb5fb 100644
--- a/arch/arm/dts/stm32f746.dtsi
+++ b/arch/arm/dts/stm32f746.dtsi
@@ -221,6 +221,23 @@
status = "disabled";
};
+ can3: can@40003400 {
+ compatible = "st,stm32f4-bxcan";
+ reg = <0x40003400 0x200>;
+ interrupts = <104>, <105>, <106>, <107>;
+ interrupt-names = "tx", "rx0", "rx1", "sce";
+ resets = < STM32F7_APB1_RESET(CAN3)>;
+ clocks = < 0 STM32F7_APB1_CLOCK(CAN3)>;
+ st,gcan = <>;
+ status = "disabled";
+ };
+
+ gcan3: gcan@40003600 {
+ compatible = "st,stm32f4-gcan", "syscon";
+ reg = <0x40003600 0x200>;
+ clocks = < 0 STM32F7_APB1_CLOCK(CAN3)>;
+ };
+
usart2: serial@40004400 {
compatible = "st,stm32f7-uart";
reg = <0x40004400 0x400>;
@@ -301,6 +318,36 @@
status = "disabled";
};
+ can1: can@40006400 {
+ compatible = "st,stm32f4-bxcan";
+ reg = <0x40006400 0x200>;
+ interrupts = <19>, <20>, <21>, <22>;
+ interrupt-names = "tx", "rx0", "rx1", "sce";
+ resets = < STM32F7_APB1_RESET(CAN1)>;
+ clocks = < 0 STM32F7_APB1_CLOCK(CAN1)>;
+ st,can-primary;
+ st,gcan = <>;
+ status = "disabled";
+ };
+
+ gcan1: gcan@40006600 {
+ compatible = "st,stm32f4-gcan", "syscon";
+ reg = <0x40006600 0x200>;
+ clocks = < 0 STM32F7_APB1_CLOCK(CAN1)>;
+ };
+
+ can2: can@40006800 {
+ compatible = "st,stm32f4-bxcan";
+ reg = <0x40006800 0x200>;
+ interrupts = <63>, <64>, <65>, <66>;
+ interrupt-names = "tx", "rx0", "rx1", "sce";
+ resets = < STM32F7_APB1_RESET(CAN2)>;
+ clocks = < 0 STM32F7_APB1_CLOCK(CAN2)>;
+ st,can-secondary;
+ st,gcan = <>;
+ status = "disabled";
+ };
+
cec: cec@40006c00 {
compatible = "st,stm32-cec";
reg = <0x40006C00 0x400>;
--
2.34.1
[PATCH 02/10] ARM: dts: stm32: add pin map for CAN controller on stm32f7
commit 011644249686f2675e142519cd59e81e04cfc231 Linux upstream.
Add pin configurations for using CAN controller on stm32f7.
Signed-off-by: Dario Binacchi
Link:
https://lore.kernel.org/all/20230427204540.3126234-4-dario.binac...@amarulasolutions.com
Signed-off-by: Marc Kleine-Budde
---
arch/arm/dts/stm32f7-pinctrl.dtsi | 82 +++
1 file changed, 82 insertions(+)
diff --git a/arch/arm/dts/stm32f7-pinctrl.dtsi
b/arch/arm/dts/stm32f7-pinctrl.dtsi
index 8f37aefa7315..000278ec2c58 100644
--- a/arch/arm/dts/stm32f7-pinctrl.dtsi
+++ b/arch/arm/dts/stm32f7-pinctrl.dtsi
@@ -284,6 +284,88 @@
slew-rate = <2>;
};
};
+
+ can1_pins_a: can1-0 {
+ pins1 {
+ pinmux = ;
/* CAN1_TX */
+ };
+ pins2 {
+ pinmux = ;
/* CAN1_RX */
+ bias-pull-up;
+ };
+ };
+
+ can1_pins_b: can1-1 {
+ pins1 {
+ pinmux = ;
/* CAN1_TX */
+ };
+ pins2 {
+ pinmux = ;
/* CAN1_RX */
+ bias-pull-up;
+ };
+ };
+
+ can1_pins_c: can1-2 {
+ pins1 {
+ pinmux = ;
/* CAN1_TX */
+ };
+ pins2 {
+ pinmux = ;
/* CAN1_RX */
+ bias-pull-up;
+
+ };
+ };
+
+ can1_pins_d: can1-3 {
+ pins1 {
+ pinmux = ;
/* CAN1_TX */
+ };
+ pins2 {
+ pinmux = ;
/* CAN1_RX */
+ bias-pull-up;
+
+ };
+ };
+
+ can2_pins_a: can2-0 {
+ pins1 {
+ pinmux = ;
/* CAN2_TX */
+ };
+ pins2 {
+ pinmux = ;
/* CAN2_RX */
+ bias-pull-up;
+ };
+ };
+
+ can2_pins_b: can2-1 {
+ pins1 {
+ pinmux = ;
/* CAN2_TX */
+ };
+ pins2 {
+ pinmux = ;
/* CAN2_RX */
+ bias-pull-up;
+ };
+ };
+
+ can3_pins_a: can3-0 {
+ pins1 {
+ pinmux = ;
/* CAN3_TX */
+ };
+ pins2 {
+ pinmux = ;
/* CAN3_RX */
+ bias-pull-up;
+ };
+ };
+
+ can3_pins_b: can3-1 {
+ pins1 {
+ pinmux = ;
/* CAN3_TX */
+ };
+ pins2 {
+ pinmux = ;
/* CAN3_RX */
+ bias-pull-up;
+ };
+ };
};
};
};
--
2.34.1
[PATCH 01/10] dt-bindings: mfd: stm32f7: Add binding definition for CAN3
commit 8f3ef556f8e1a670895f59ef3f01e4e26edd63e3 Linux upstream. Add binding definition for CAN3 peripheral. Signed-off-by: Dario Binacchi Link: https://lore.kernel.org/r/20230423172528.1398158-2-dario.binac...@amarulasolutions.com Signed-off-by: Lee Jones --- include/dt-bindings/mfd/stm32f7-rcc.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/dt-bindings/mfd/stm32f7-rcc.h b/include/dt-bindings/mfd/stm32f7-rcc.h index ba5cb7456ee4..a4e4f9271395 100644 --- a/include/dt-bindings/mfd/stm32f7-rcc.h +++ b/include/dt-bindings/mfd/stm32f7-rcc.h @@ -64,6 +64,7 @@ #define STM32F7_RCC_APB1_TIM14 8 #define STM32F7_RCC_APB1_LPTIM19 #define STM32F7_RCC_APB1_WWDG 11 +#define STM32F7_RCC_APB1_CAN3 13 #define STM32F7_RCC_APB1_SPI2 14 #define STM32F7_RCC_APB1_SPI3 15 #define STM32F7_RCC_APB1_SPDIFRX 16 -- 2.34.1
[PATCH 00/10] ARM: dts: stm32f746 sync with Linux kernel 6.5
This series contains my patches on the device tree for stm32f746-disco board that have already been merged into the Linux mainline. Since most of them applied perfectly, and for the remaining ones, only minimal changes were made, I preferred not to merge them into a single patch, which would have been less readable. Dario Binacchi (10): dt-bindings: mfd: stm32f7: Add binding definition for CAN3 ARM: dts: stm32: add pin map for CAN controller on stm32f7 ARM: dts: stm32: add CAN support on stm32f746 ARM: dts: stm32: use RCC macro for CRC node on stm32f746 ARM: dts: stm32: add pin map for i2c3 controller on stm32f7 ARM: dts: stm32: add touchscreen on stm32f746-disco board ARM: dts: stm32: add ltdc support on stm32f746 MCU ARM: dts: stm32: add pin map for LTDC on stm32f7 ARM: dts: stm32: rename mmc_vcard to vcc-3v3 on stm32f746-disco ARM: dts: stm32: support display on stm32f746-disco board arch/arm/dts/stm32f7-pinctrl.dtsi| 126 +++ arch/arm/dts/stm32f746-disco-u-boot.dtsi | 103 +- arch/arm/dts/stm32f746-disco.dts | 69 - arch/arm/dts/stm32f746.dtsi | 59 ++- include/dt-bindings/mfd/stm32f7-rcc.h| 1 + 5 files changed, 276 insertions(+), 82 deletions(-) -- 2.34.1
[PATCH v2] bootstd: Make efi_mgr bootmeth work for non-sandbox setups
Enable the bootflow based on this bootmeth if the BootOrder EFI
variable is set.
Signed-off-by: Mark Kettenis
---
ChangeLog:
v2: - Initialize EFI subsystem to populate EFI variables
boot/bootmeth_efi_mgr.c | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/boot/bootmeth_efi_mgr.c b/boot/bootmeth_efi_mgr.c
index e9d973429f..e6c42d41fb 100644
--- a/boot/bootmeth_efi_mgr.c
+++ b/boot/bootmeth_efi_mgr.c
@@ -14,6 +14,8 @@
#include
#include
#include
+#include
+#include
/**
* struct efi_mgr_priv - private info for the efi-mgr driver
@@ -46,13 +48,26 @@ static int efi_mgr_check(struct udevice *dev, struct
bootflow_iter *iter)
static int efi_mgr_read_bootflow(struct udevice *dev, struct bootflow *bflow)
{
struct efi_mgr_priv *priv = dev_get_priv(dev);
+ efi_status_t ret;
+ efi_uintn_t size;
+ u16 *bootorder;
if (priv->fake_dev) {
bflow->state = BOOTFLOWST_READY;
return 0;
}
- /* To be implemented */
+ ret = efi_init_obj_list();
+ if (ret)
+ return log_msg_ret("init", ret);
+
+ /* Enable this method if the "BootOrder" UEFI exists. */
+ bootorder = efi_get_var(u"BootOrder", _global_variable_guid,
+ );
+ if (bootorder) {
+ bflow->state = BOOTFLOWST_READY;
+ return 0;
+ }
return -EINVAL;
}
--
2.42.0
Re: [PATCH 32/32] pci: serial: Support reading PCI-register size with base
I still have not received any reply from you.
On Wednesday 30 August 2023 20:14:59 Pali Rohár wrote:
> Simon, why you are contacting me? You have wrote to me that you would
> ignore my reviews here, so what you want now? Could you please explain
> what you are trying to achieve? I'm not going to review this or any
> other your changes.
>
> On Wednesday 30 August 2023 12:05:03 Simon Glass wrote:
> > The PCI helpers read only the base address for a PCI region. In some cases
> > the size is needed as well, e.g. to pass along to a driver which needs to
> > know the size of its register area.
> >
> > Update the functions to allow the size to be returned. For serial, record
> > the information and provided it with the serial_info() call.
> >
> > A limitation still exists in that the size is not available when OF_LIVE
> > is enabled, so take account of that in the tests.
> >
> > Signed-off-by: Simon Glass
> > ---
> >
> > arch/sandbox/dts/test.dts | 6 +++---
> > drivers/core/fdtaddr.c | 6 +++---
> > drivers/core/ofnode.c | 11 ---
> > drivers/core/read.c | 6 --
> > drivers/core/util.c | 2 +-
> > drivers/pci/pci-uclass.c| 2 +-
> > drivers/pci/pci_mvebu.c | 3 ++-
> > drivers/pci/pci_tegra.c | 2 +-
> > drivers/pci/pcie_mediatek.c | 4 ++--
> > drivers/serial/ns16550.c| 15 ++-
> > include/dm/fdtaddr.h| 3 ++-
> > include/dm/ofnode.h | 4 +++-
> > include/dm/read.h | 8 +---
> > include/ns16550.h | 4 +++-
> > include/serial.h| 2 ++
> > test/dm/pci.c | 14 ++
> > 16 files changed, 60 insertions(+), 32 deletions(-)
> >
> > diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
> > index a413cbe4989..961e8895a49 100644
> > --- a/arch/sandbox/dts/test.dts
> > +++ b/arch/sandbox/dts/test.dts
> > @@ -1087,8 +1087,8 @@
> > pci@1,0 {
> > compatible = "pci-generic";
> > /* reg 0 is at 0x14, using FDT_PCI_SPACE_MEM32 */
> > - reg = <0x02000814 0 0 0 0
> > - 0x01000810 0 0 0 0>;
> > + reg = <0x02000814 0 0 0x80 0
> > + 0x01000810 0 0 0xc0 0>;
> > sandbox,emul = <_case_emul0_1>;
> > };
> > p2sb-pci@2,0 {
> > @@ -1115,7 +1115,7 @@
> > pci@1f,0 {
> > compatible = "pci-generic";
> > /* reg 0 is at 0x10, using FDT_PCI_SPACE_IO */
> > - reg = <0x0100f810 0 0 0 0>;
> > + reg = <0x0100f810 0 0 0x100 0>;
> > sandbox,emul = <_case_emul0_1f>;
> > };
> > };
> > diff --git a/drivers/core/fdtaddr.c b/drivers/core/fdtaddr.c
> > index 546db675aaf..b79d138c419 100644
> > --- a/drivers/core/fdtaddr.c
> > +++ b/drivers/core/fdtaddr.c
> > @@ -215,7 +215,7 @@ void *devfdt_map_physmem(const struct udevice *dev,
> > unsigned long size)
> > return map_physmem(addr, size, MAP_NOCACHE);
> > }
> >
> > -fdt_addr_t devfdt_get_addr_pci(const struct udevice *dev)
> > +fdt_addr_t devfdt_get_addr_pci(const struct udevice *dev, fdt_size_t
> > *sizep)
> > {
> > ulong addr;
> >
> > @@ -226,12 +226,12 @@ fdt_addr_t devfdt_get_addr_pci(const struct udevice
> > *dev)
> > int ret;
> >
> > ret = ofnode_read_pci_addr(dev_ofnode(dev), FDT_PCI_SPACE_MEM32,
> > - "reg", _addr);
> > + "reg", _addr, sizep);
> > if (ret) {
> > /* try if there is any i/o-mapped register */
> > ret = ofnode_read_pci_addr(dev_ofnode(dev),
> >FDT_PCI_SPACE_IO, "reg",
> > - _addr);
> > + _addr, sizep);
> > if (ret)
> > return FDT_ADDR_T_NONE;
> > }
> > diff --git a/drivers/core/ofnode.c b/drivers/core/ofnode.c
> > index 2ef4114cb6f..c9cec456f43 100644
> > --- a/drivers/core/ofnode.c
> > +++ b/drivers/core/ofnode.c
> > @@ -1270,7 +1270,8 @@ const uint8_t *ofnode_read_u8_array_ptr(ofnode node,
> > const char *propname,
> > }
> >
> > int ofnode_read_pci_addr(ofnode node, enum fdt_pci_space type,
> > -const char *propname, struct fdt_pci_addr *addr)
> > +const char *propname, struct fdt_pci_addr *addr,
> > +fdt_size_t *size)
> > {
> > const fdt32_t *cell;
> > int len;
> > @@ -1298,14 +1299,18 @@ int ofnode_read_pci_addr(ofnode node, enum
> > fdt_pci_space type,
> > (ulong)fdt32_to_cpu(cell[1]),
> > (ulong)fdt32_to_cpu(cell[2]));
> > if ((fdt32_to_cpu(*cell) & type) == type) {
> > +
Re: [PATCH 32/32] pci: serial: Support reading PCI-register size with base
You are not saying truth here, you are lying and you know it. mvebu changes? ignored, no answer. ppc changes? ignored no answer in 10 months. mmc changes, no answer at all. rx-51 bug reports and regression which you and your people broke? you wrote me: fuck you and fix it yourself. So what does compromise means for you? Just "Pali has to do anything". So yes, I'm refusing to do all this dirty jobs for you. This is not any compromise, maybe just in your head or your language. Compromise is something like, you will fix regression what you and your people caused and I then I will look at some of the pending patches for which I'm listed as reviewer. Helping do debug? Nobody helped me with anything. Do you still you think that I'm such idiot who is going to review more and more of your code and you continue ignoring me?? No. On Wednesday 30 August 2023 17:42:01 Tom Rini wrote: > On Wed, Aug 30, 2023 at 11:29:34PM +0200, Pali Rohár wrote: > > > There were no answers. > > > > On Wednesday 30 August 2023 17:26:20 Tom Rini wrote: > > > I'm trimming the CC list. All of those points you list were addressed > > > and answered in your last long running argument. You need to decide what > > > is best for you moving forward and I would ask that it not involve > > > complaining that you're being asked to review code that you're a listed > > > maintainer of. > > > > > > On Wed, Aug 30, 2023 at 11:13:16PM +0200, Pali Rohár wrote: > > > > Seems that you completely miss the point of the argument, then the only > > > > option for such people is to repeat them. Or have I repeat you again > > > > that you have not answered the first question, why you are asking for > > > > review from somebody who you are ignoring and not taking into account? > > > > You do not want to answer this question, right? So you rather change a > > > > topic and talking about something totally different. > > > > > > > > On Wednesday 30 August 2023 17:08:42 Tom Rini wrote: > > > > > I don't think it's worth re-hashing the same arguments over and over. > > > > > There is no "my persons", there is the public community. If you no > > > > > longer wish to participate, I can remove you from the maintainers > > > > > entries you're listed in. But please stop with the long arguments > > > > > unrelated to the patches at hand when there's a dozen people and other > > > > > lists on CC. > > > > > > > > > > On Wed, Aug 30, 2023 at 10:51:45PM +0200, Pali Rohár wrote: > > > > > > So lets recap what you and your persons have done in last 6 months: > > > > > > > > > > > > * Ignored my changes > > > > > > * Ignored my reviews > > > > > > * Ignored my reminders > > Not ignored, changes requested and refused. Compromises refused. > Apologies from others who had said they would pick up the platform and > push it, but did not have time ignored. > > > > > > > * Ignored my regression reports > > Not ignored, debugged, problems with your platform implementation > reported and questions asked, patches provided to help you debug the > problem on the single place that seems to show a problem which no one > else can reproduce ignored. > > -- > Tom
[PATCH 2/3] ARM: dts: stm32: add pin map for CAN controller on stm32f4
commit 559a6e75b4bcf0fc9e41d34865e72cf742f67d8e Linux upstream.
Add pin configurations for using CAN controller on stm32f469-disco
board. They are located on the Arduino compatible connector CN5 (CAN1)
and on the extension connector CN12 (CAN2).
Signed-off-by: Dario Binacchi
Link:
https://lore.kernel.org/all/20230328073328.3949796-5-dario.binac...@amarulasolutions.com
Signed-off-by: Marc Kleine-Budde
---
arch/arm/dts/stm32f4-pinctrl.dtsi | 30 ++
1 file changed, 30 insertions(+)
diff --git a/arch/arm/dts/stm32f4-pinctrl.dtsi
b/arch/arm/dts/stm32f4-pinctrl.dtsi
index 46815c965d59..0adc41b2a46c 100644
--- a/arch/arm/dts/stm32f4-pinctrl.dtsi
+++ b/arch/arm/dts/stm32f4-pinctrl.dtsi
@@ -412,6 +412,36 @@
slew-rate = <2>;
};
};
+
+ can1_pins_a: can1-0 {
+ pins1 {
+ pinmux = ;
/* CAN1_TX */
+ };
+ pins2 {
+ pinmux = ;
/* CAN1_RX */
+ bias-pull-up;
+ };
+ };
+
+ can2_pins_a: can2-0 {
+ pins1 {
+ pinmux = ;
/* CAN2_TX */
+ };
+ pins2 {
+ pinmux = ;
/* CAN2_RX */
+ bias-pull-up;
+ };
+ };
+
+ can2_pins_b: can2-1 {
+ pins1 {
+ pinmux = ;
/* CAN2_TX */
+ };
+ pins2 {
+ pinmux = ;
/* CAN2_RX */
+ bias-pull-up;
+ };
+ };
};
};
};
--
2.34.1
[PATCH 3/3] ARM: dts: stm32f429: put can2 in secondary mode
commit 6b443faa313c519db755ff90be32758fd9c66453 Linux upstream. This is a preparation patch for the upcoming support to manage CAN peripherals in single configuration. The addition ensures backwards compatibility. Signed-off-by: Dario Binacchi Link: https://lore.kernel.org/all/20230427204540.3126234-3-dario.binac...@amarulasolutions.com Signed-off-by: Marc Kleine-Budde --- arch/arm/dts/stm32f429.dtsi | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/dts/stm32f429.dtsi b/arch/arm/dts/stm32f429.dtsi index 5104fca8..8133ea15b036 100644 --- a/arch/arm/dts/stm32f429.dtsi +++ b/arch/arm/dts/stm32f429.dtsi @@ -346,6 +346,7 @@ interrupt-names = "tx", "rx0", "rx1", "sce"; resets = < STM32F4_APB1_RESET(CAN2)>; clocks = < 0 STM32F4_APB1_CLOCK(CAN2)>; + st,can-secondary; st,gcan = <>; status = "disabled"; }; -- 2.34.1
[PATCH 1/3] ARM: dts: stm32: add CAN support on stm32f429
commit 7355ad1950f41e755e6dc451834be3b94f82acd4 Linux upstream.
Add support for bxcan (Basic eXtended CAN controller) to STM32F429. The
chip contains two CAN peripherals, CAN1 the primary and CAN2 the secondary,
that share some of the required logic like clock and filters. This means
that the secondary CAN can't be used without the primary CAN.
Signed-off-by: Dario Binacchi
Link:
https://lore.kernel.org/all/20230328073328.3949796-4-dario.binac...@amarulasolutions.com
Signed-off-by: Marc Kleine-Budde
---
arch/arm/dts/stm32f429.dtsi | 29 +
1 file changed, 29 insertions(+)
diff --git a/arch/arm/dts/stm32f429.dtsi b/arch/arm/dts/stm32f429.dtsi
index e5b13aca40c0..5104fca8 100644
--- a/arch/arm/dts/stm32f429.dtsi
+++ b/arch/arm/dts/stm32f429.dtsi
@@ -321,6 +321,35 @@
status = "disabled";
};
+ can1: can@40006400 {
+ compatible = "st,stm32f4-bxcan";
+ reg = <0x40006400 0x200>;
+ interrupts = <19>, <20>, <21>, <22>;
+ interrupt-names = "tx", "rx0", "rx1", "sce";
+ resets = < STM32F4_APB1_RESET(CAN1)>;
+ clocks = < 0 STM32F4_APB1_CLOCK(CAN1)>;
+ st,can-primary;
+ st,gcan = <>;
+ status = "disabled";
+ };
+
+ gcan: gcan@40006600 {
+ compatible = "st,stm32f4-gcan", "syscon";
+ reg = <0x40006600 0x200>;
+ clocks = < 0 STM32F4_APB1_CLOCK(CAN1)>;
+ };
+
+ can2: can@40006800 {
+ compatible = "st,stm32f4-bxcan";
+ reg = <0x40006800 0x200>;
+ interrupts = <63>, <64>, <65>, <66>;
+ interrupt-names = "tx", "rx0", "rx1", "sce";
+ resets = < STM32F4_APB1_RESET(CAN2)>;
+ clocks = < 0 STM32F4_APB1_CLOCK(CAN2)>;
+ st,gcan = <>;
+ status = "disabled";
+ };
+
dac: dac@40007400 {
compatible = "st,stm32f4-dac-core";
reg = <0x40007400 0x400>;
--
2.34.1
[PATCH 0/3] ARM: dts: stm32f429 sync with Linux kernel 6.5
This series contains my patches on the device tree for stm32f429 platform that have already been merged into the mainline of Linux. Since they applied perfectly, I preferred not to merge them into a single patch, which would have been less readable. Dario Binacchi (3): ARM: dts: stm32: add CAN support on stm32f429 ARM: dts: stm32: add pin map for CAN controller on stm32f4 ARM: dts: stm32f429: put can2 in secondary mode arch/arm/dts/stm32f4-pinctrl.dtsi | 30 ++ arch/arm/dts/stm32f429.dtsi | 30 ++ 2 files changed, 60 insertions(+) -- 2.34.1
Re: [PATCH 2/3] Azure: Split sandbox and qemu test.py runs
On Sun, Sep 03, 2023 at 12:09:39PM -0600, Simon Glass wrote: > Hi Tom, > > On Fri, 1 Sept 2023 at 14:41, Tom Rini wrote: > > > > Currently, most sandbox runs take a long time (due to running so many > > tests) while QEMu based test.py runs are fairly short. Split the > > pipeline here so that we get more consistent average run times. > > > > Signed-off-by: Tom Rini > > --- > > .azure-pipelines.yml | 61 > > 1 file changed, 44 insertions(+), 17 deletions(-) > > Reviewed-by: Simon Glass > > ...so far as I understand it...there seems to be a need to pass the > argos to docker again. There's not a clean way to re-use all of the logic we need prior to docker run, or move it to another type of "task" (in Azure-speak). There is a Docker task, and we could, I _think_ migrate the volume options to that (but I'm not sure), but we couldn't handle the loopback devices in that way. -- Tom signature.asc Description: PGP signature
Re: [PATCH 7/7] fs: Fix a confusing error about overlapping regions
On Sun, Sep 03, 2023 at 12:06:13PM -0600, Simon Glass wrote:
> Hi Tom,
>
> On Sun, 3 Sept 2023 at 10:42, Tom Rini wrote:
> >
> > On Thu, Aug 31, 2023 at 06:15:19PM -0600, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Wed, 23 Aug 2023 at 09:14, Tom Rini wrote:
> > > >
> > > > On Wed, Aug 23, 2023 at 07:42:03AM -0600, Simon Glass wrote:
> > > >
> > > > > When lmb runs out of space in its internal tables, it gives errors on
> > > > > every fs load operation. This is horribly confusing, as the poor user
> > > > > tries different memory regions one at a time.
> > > > >
> > > > > Use the updated API to check the error code and print a helpful
> > > > > message.
> > > > > Also, allow the operation to proceed.
> > > > >
> > > > > Update the tests accordingly.
> > > > >
> > > > > Signed-off-by: Simon Glass
> > > > [snip]
> > > > > + if (ret == -E2BIG) {
> > > > > + log_warning("Reservation tables exhausted: see
> > > > > CONFIG_LMB_USE_MAX_REGIONS\n");
> > > > > + return 0;
> > > > > + }
> > > >
> > > > This isn't the right option. Everyone has CONFIG_LMB_USE_MAX_REGIONS
> > > > set. You would want to increase CONFIG_LMB_MAX_REGIONS.
> > > >
> > > > But it sounds like what you've found and fixed is an underlying problem
> > > > as to why 16 regions isn't enough in some common cases now? So we could
> > >
> > > I don't think I have fixed anything. But I'll send v2 and perhaps it
> > > will be clearer what is going on here.
> > >
> > > > possibly avoid the string size growth here and have a comment that also
> > > > matches up with the help under LMB_MAX_REGIONS?
> > >
> > > I don't know, sorry. The size of struct(lmb) on 64-bit sandbox is
> > > about 400 bytes. There seems to be a lot of code to save not much
> > > memory.
> >
> > What do you mean here? The alternative is not unlimited ranges but
> > instead to define the limit of memory regions and limit of reserved
> > ranges.
>
> A better alternative would be not to limit the number of regions, IMO,
> i.e. have an array of regions that can grow as needed.
That's not something that we have in the code today, however.
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH 1/3] Azure: Rework test_py job to publish its wrapper script
On Fri, 1 Sept 2023 at 14:42, Tom Rini wrote: > > Both to aide in debugging of any test.py issues as well as to make it > easier to split the current matrix in two, have a new job that creates > and publishes the current wrapper script we use for test.py jobs. > > Signed-off-by: Tom Rini > --- > .azure-pipelines.yml | 161 --- > 1 file changed, 90 insertions(+), 71 deletions(-) Reviewed-by: Simon Glass
Re: [PATCH 2/3] Azure: Split sandbox and qemu test.py runs
Hi Tom, On Fri, 1 Sept 2023 at 14:41, Tom Rini wrote: > > Currently, most sandbox runs take a long time (due to running so many > tests) while QEMu based test.py runs are fairly short. Split the > pipeline here so that we get more consistent average run times. > > Signed-off-by: Tom Rini > --- > .azure-pipelines.yml | 61 > 1 file changed, 44 insertions(+), 17 deletions(-) Reviewed-by: Simon Glass ...so far as I understand it...there seems to be a need to pass the argos to docker again.
Re: [PATCH 7/7] fs: Fix a confusing error about overlapping regions
Hi Tom,
On Sun, 3 Sept 2023 at 10:42, Tom Rini wrote:
>
> On Thu, Aug 31, 2023 at 06:15:19PM -0600, Simon Glass wrote:
> > Hi Tom,
> >
> > On Wed, 23 Aug 2023 at 09:14, Tom Rini wrote:
> > >
> > > On Wed, Aug 23, 2023 at 07:42:03AM -0600, Simon Glass wrote:
> > >
> > > > When lmb runs out of space in its internal tables, it gives errors on
> > > > every fs load operation. This is horribly confusing, as the poor user
> > > > tries different memory regions one at a time.
> > > >
> > > > Use the updated API to check the error code and print a helpful message.
> > > > Also, allow the operation to proceed.
> > > >
> > > > Update the tests accordingly.
> > > >
> > > > Signed-off-by: Simon Glass
> > > [snip]
> > > > + if (ret == -E2BIG) {
> > > > + log_warning("Reservation tables exhausted: see
> > > > CONFIG_LMB_USE_MAX_REGIONS\n");
> > > > + return 0;
> > > > + }
> > >
> > > This isn't the right option. Everyone has CONFIG_LMB_USE_MAX_REGIONS
> > > set. You would want to increase CONFIG_LMB_MAX_REGIONS.
> > >
> > > But it sounds like what you've found and fixed is an underlying problem
> > > as to why 16 regions isn't enough in some common cases now? So we could
> >
> > I don't think I have fixed anything. But I'll send v2 and perhaps it
> > will be clearer what is going on here.
> >
> > > possibly avoid the string size growth here and have a comment that also
> > > matches up with the help under LMB_MAX_REGIONS?
> >
> > I don't know, sorry. The size of struct(lmb) on 64-bit sandbox is
> > about 400 bytes. There seems to be a lot of code to save not much
> > memory.
>
> What do you mean here? The alternative is not unlimited ranges but
> instead to define the limit of memory regions and limit of reserved
> ranges.
A better alternative would be not to limit the number of regions, IMO,
i.e. have an array of regions that can grow as needed.
Regards,
Simon
Re: [PATCH 7/7] fs: Fix a confusing error about overlapping regions
On Thu, Aug 31, 2023 at 06:15:19PM -0600, Simon Glass wrote:
> Hi Tom,
>
> On Wed, 23 Aug 2023 at 09:14, Tom Rini wrote:
> >
> > On Wed, Aug 23, 2023 at 07:42:03AM -0600, Simon Glass wrote:
> >
> > > When lmb runs out of space in its internal tables, it gives errors on
> > > every fs load operation. This is horribly confusing, as the poor user
> > > tries different memory regions one at a time.
> > >
> > > Use the updated API to check the error code and print a helpful message.
> > > Also, allow the operation to proceed.
> > >
> > > Update the tests accordingly.
> > >
> > > Signed-off-by: Simon Glass
> > [snip]
> > > + if (ret == -E2BIG) {
> > > + log_warning("Reservation tables exhausted: see
> > > CONFIG_LMB_USE_MAX_REGIONS\n");
> > > + return 0;
> > > + }
> >
> > This isn't the right option. Everyone has CONFIG_LMB_USE_MAX_REGIONS
> > set. You would want to increase CONFIG_LMB_MAX_REGIONS.
> >
> > But it sounds like what you've found and fixed is an underlying problem
> > as to why 16 regions isn't enough in some common cases now? So we could
>
> I don't think I have fixed anything. But I'll send v2 and perhaps it
> will be clearer what is going on here.
>
> > possibly avoid the string size growth here and have a comment that also
> > matches up with the help under LMB_MAX_REGIONS?
>
> I don't know, sorry. The size of struct(lmb) on 64-bit sandbox is
> about 400 bytes. There seems to be a lot of code to save not much
> memory.
What do you mean here? The alternative is not unlimited ranges but
instead to define the limit of memory regions and limit of reserved
ranges.
--
Tom
signature.asc
Description: PGP signature
[PATCH] doc: efi: Update for the 64-bit app
The 64-bit app is supported now, so update the documentation. Signed-off-by: Simon Glass --- doc/develop/uefi/u-boot_on_efi.rst | 26 +++--- 1 file changed, 11 insertions(+), 15 deletions(-) diff --git a/doc/develop/uefi/u-boot_on_efi.rst b/doc/develop/uefi/u-boot_on_efi.rst index acad6397e81d..1746965e7eab 100644 --- a/doc/develop/uefi/u-boot_on_efi.rst +++ b/doc/develop/uefi/u-boot_on_efi.rst @@ -31,14 +31,12 @@ Only x86 is supported at present. If you are using EFI on another architecture you may want to reconsider. However, much of the code is generic so could be ported. -U-Boot supports running as an EFI application for 32-bit EFI only. This is -not very useful since only a serial port is provided. You can look around at -memory and type 'help' but that is about it. +U-Boot supports running as an EFI application for both 32- and 64-bit EFI. -More usefully, U-Boot supports building itself as a payload for either 32-bit -or 64-bit EFI. U-Boot is packaged up and loaded in its entirety by EFI. Once -started, U-Boot changes to 32-bit mode (currently) and takes over the -machine. You can use devices, boot a kernel, etc. +U-Boot supports building itself as a payload for either 32-bit or 64-bit EFI. +U-Boot is packaged up and loaded in its entirety by EFI. Once started, U-Boot +changes to 32-bit mode (currently) and takes over the machine. You can use +devices, boot a kernel, etc. Build Instructions @@ -47,9 +45,9 @@ First choose a board that has EFI support and obtain an EFI implementation for that board. It will be either 32-bit or 64-bit. Alternatively, you can opt for using QEMU [1] and the OVMF [2], as detailed below. -To build U-Boot as an EFI application (32-bit EFI required), enable CONFIG_EFI -and CONFIG_EFI_APP. The efi-x86_app config (efi-x86_app32_defconfig) is set up -for this. Just build U-Boot as normal, e.g.:: +To build U-Boot as an EFI application, enable CONFIG_EFI and CONFIG_EFI_APP. +The efi-x86_app32 and efi-x86_app64 configs are set up for this. Just build +U-Boot as normal, e.g.:: make efi-x86_app32_defconfig make @@ -189,9 +187,9 @@ interrupts disabled at present. 32/64-bit ~ -While the EFI application can in principle be built as either 32- or 64-bit, -only 32-bit is currently supported. This means that the application can only -be used with 32-bit EFI. +While the EFI application can be built as either 32- or 64-bit, you need to be +careful to build the correct one so that your UEFI firmware can start it. Most +UEFI images are 64-bit at present. The payload stub can be build as either 32- or 64-bits. Only a small amount of code is built this way (see the extra- line in lib/efi/Makefile). @@ -261,8 +259,6 @@ This work could be extended in a number of ways: - Add ARM support -- Add 64-bit application support (in progress) - - Figure out how to solve the interrupt problem - Add more drivers to the application side (e.g.USB, environment access). -- 2.42.0.283.g2d96d420d3-goog
Re: [PATCH 1/2] rockchip: Use an external TPL binary on RK3308
Il giorno sab 2 set 2023 alle ore 18:32 Massimo Pegorer ha scritto: > > There is no support to initialize DRAM on RK3308 SoC using U-Boot > TPL and therefore an external TPL binary must be used to generate > a bootable u-boot-rockchip.bin image. > > Imply ROCKCHIP_EXTERNAL_TPL by default for RK3308 builds. Remove > useless TPL_SERIAL. > > Signed-off-by: Massimo Pegorer > --- > arch/arm/mach-rockchip/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig > index a279582f4f..e8584de258 100644 > --- a/arch/arm/mach-rockchip/Kconfig > +++ b/arch/arm/mach-rockchip/Kconfig > @@ -159,6 +159,7 @@ config ROCKCHIP_RK3308 > select SPL_ATF > select SPL_ATF_NO_PLATFORM_PARAM > select SPL_LOAD_FIT > + imply ROCKCHIP_EXTERNAL_TPL > imply ROCKCHIP_COMMON_BOARD > imply SPL_ROCKCHIP_COMMON_BOARD > imply SPL_CLK > @@ -166,7 +167,6 @@ config ROCKCHIP_RK3308 > imply SPL_SYSCON > imply SPL_RAM > imply SPL_SERIAL > - imply TPL_SERIAL > imply SPL_SEPARATE_BSS > help > The Rockchip RK3308 is a ARM-based Soc which embedded with quad > -- > 2.34.1 > I've just noticed that Jonas followed a different approach for RK3568 and RK3588: config ROCKCHIP_EXTERNAL_TPL bool "Use external TPL binary" default y if ROCKCHIP_RK3568 || ROCKCHIP_RK3588 Is any one preferred? I slightly prefer the one I've done, as it gives a terse picture of what a SoC select/imply in a single place. Of course I can change it in a V2, if Jonas way is preferred, and to have a single congruent way to do things. Thanks. Regards, Massimo
Re: [PATCH 2/2] doc: rockchip: Update and complete info about RK3308
Hi Johan, Il giorno dom 3 set 2023 alle ore 10:36 Johan Jonker ha scritto: > > > > On 9/2/23 18:32, Massimo Pegorer wrote: > > Update documentation about build steps for RK3308, using an external > > TPL. Add RK3308 case to rST document. Add ROCK Pi S in the list of > > supported boards. > > > > Signed-off-by: Massimo Pegorer > > --- > > doc/README.rockchip | 4 ++-- > > doc/board/rockchip/rockchip.rst | 10 ++ > > 2 files changed, 12 insertions(+), 2 deletions(-) > > > > diff --git a/doc/README.rockchip b/doc/README.rockchip > > index 52b5140eca..cfbd858c3b 100644 > > --- a/doc/README.rockchip > > +++ b/doc/README.rockchip > > @@ -38,16 +38,16 @@ Building > > (or you can use another cross compiler if you prefer) > > > > > 2. To build RK3308 board: > > + > > - Get the rkbin > > => git clone https://github.com/rockchip-linux/rkbin.git > > > > - Compile U-Boot > > => cd /path/to/u-boot > > => export BL31=/path/to/rkbin/bin/rk33/rk3308_bl31_v2.22.elf > > + => export > > ROCKCHIP_TPL=/path/to/rkbin/bin/rk33/rk3308_ddr_589MHz_uart2_m0_v1.26.bin > > => make roc-cc-rk3308_defconfig > > => make CROSS_COMPILE=aarch64-linux-gnu- all > > - => ./tools/mkimage -n rk3308 -T rksd -d > > /path/to/rkbin/bin/rk33/rk3308_ddr_589MHz_uart2_m0_v1.26.bin idbloader.img > > - => cat spl/u-boot-spl.bin >> idbloader.img > > > > Hi Massimo, > > The text in this document should moved to doc/board/rockchip. > This paragraph above is therefor redundant, so it can be removed I think. > > Johan OK, thanks, I agree on redundant. But I do not know if everything here - other than RK3308 info - has already been moved to doc/board/rockchip.rst, so to remove it. On the other hand, leaving as it is (i.e. not updated) would be misleading. If everybody agree I can remove it in a V2, or otherwise just delete the RK3308 section. Massimo > > 3. To build RK3399 board: > > > > diff --git a/doc/board/rockchip/rockchip.rst > > b/doc/board/rockchip/rockchip.rst > > index de9fe8e642..b38c3d3136 100644 > > --- a/doc/board/rockchip/rockchip.rst > > +++ b/doc/board/rockchip/rockchip.rst > > @@ -53,6 +53,7 @@ List of mainline supported Rockchip boards: > > - Google Speedy (chromebook_speedy) > > - Amarula Vyasa-RK3288 (vyasa-rk3288) > > * rk3308 > > + - Radxa ROCK Pi S (rock-pi-s-rk3308) > > - Rockchip Evb-RK3308 (evb-rk3308) > > - Roc-cc-RK3308 (roc-cc-rk3308) > > * rk3326 > > @@ -172,6 +173,15 @@ To build rk3288 boards: > > make evb-rk3288_defconfig > > make CROSS_COMPILE=arm-linux-gnueabihf- > > > > +To build rk3308 boards: > > + > > +.. code-block:: bash > > + > > +export BL31=../rkbin/bin/rk33/rk3308_bl31_vX.YZ.elf > > +export > > ROCKCHIP_TPL=../rkbin/bin/rk33/rk3308_ddr_589MHz_uart0_m0_vX.YZ.bin > > +make evb-rk3308_defconfig > > +make CROSS_COMPILE=aarch64-linux-gnu- > > + > > To build rk3328 boards: > > > > .. code-block:: bash
Re: [PATCH 2/2] doc: rockchip: Update and complete info about RK3308
On 9/2/23 18:32, Massimo Pegorer wrote: > Update documentation about build steps for RK3308, using an external > TPL. Add RK3308 case to rST document. Add ROCK Pi S in the list of > supported boards. > > Signed-off-by: Massimo Pegorer > --- > doc/README.rockchip | 4 ++-- > doc/board/rockchip/rockchip.rst | 10 ++ > 2 files changed, 12 insertions(+), 2 deletions(-) > > diff --git a/doc/README.rockchip b/doc/README.rockchip > index 52b5140eca..cfbd858c3b 100644 > --- a/doc/README.rockchip > +++ b/doc/README.rockchip > @@ -38,16 +38,16 @@ Building > (or you can use another cross compiler if you prefer) > > 2. To build RK3308 board: > + > - Get the rkbin > => git clone https://github.com/rockchip-linux/rkbin.git > > - Compile U-Boot > => cd /path/to/u-boot > => export BL31=/path/to/rkbin/bin/rk33/rk3308_bl31_v2.22.elf > + => export > ROCKCHIP_TPL=/path/to/rkbin/bin/rk33/rk3308_ddr_589MHz_uart2_m0_v1.26.bin > => make roc-cc-rk3308_defconfig > => make CROSS_COMPILE=aarch64-linux-gnu- all > - => ./tools/mkimage -n rk3308 -T rksd -d > /path/to/rkbin/bin/rk33/rk3308_ddr_589MHz_uart2_m0_v1.26.bin idbloader.img > - => cat spl/u-boot-spl.bin >> idbloader.img > Hi Massimo, The text in this document should moved to doc/board/rockchip. This paragraph above is therefor redundant, so it can be removed I think. Johan > 3. To build RK3399 board: > > diff --git a/doc/board/rockchip/rockchip.rst b/doc/board/rockchip/rockchip.rst > index de9fe8e642..b38c3d3136 100644 > --- a/doc/board/rockchip/rockchip.rst > +++ b/doc/board/rockchip/rockchip.rst > @@ -53,6 +53,7 @@ List of mainline supported Rockchip boards: > - Google Speedy (chromebook_speedy) > - Amarula Vyasa-RK3288 (vyasa-rk3288) > * rk3308 > + - Radxa ROCK Pi S (rock-pi-s-rk3308) > - Rockchip Evb-RK3308 (evb-rk3308) > - Roc-cc-RK3308 (roc-cc-rk3308) > * rk3326 > @@ -172,6 +173,15 @@ To build rk3288 boards: > make evb-rk3288_defconfig > make CROSS_COMPILE=arm-linux-gnueabihf- > > +To build rk3308 boards: > + > +.. code-block:: bash > + > +export BL31=../rkbin/bin/rk33/rk3308_bl31_vX.YZ.elf > +export > ROCKCHIP_TPL=../rkbin/bin/rk33/rk3308_ddr_589MHz_uart0_m0_vX.YZ.bin > +make evb-rk3308_defconfig > +make CROSS_COMPILE=aarch64-linux-gnu- > + > To build rk3328 boards: > > .. code-block:: bash
Re: [PATCH v5 05/11] spl: Convert mmc to spl_load
On 2023-08-03 18:11, Sean Anderson wrote:
> On 8/3/23 04:31, Xavier Drudis Ferran wrote:
>> El Mon, Jul 31, 2023 at 06:42:57PM -0400, Sean Anderson deia:
>>> This converts the mmc loader to spl_load. Legacy images are handled by
>>> spl_load (via spl_parse_image_header), so mmc_load_legacy can be
>>> omitted.
>>>
>>
>> Yes. I haven't used the legacy case, but by looking at the code, it
>> seems to me that mmc_load_legacy left the image at some mapped memory
>> at [ spl_image->load_addr, spl_image->load_addr + size )
>> and the new code does too, but when the image is not aligned, the
>> memory that gets written to
>> was at [ spl_image->load_addr, spl_image->load_addr + size +
>> spl_image->offset % mmc->read_bl_len )
>> and it will
>> be at [ spl_image->load_addr - spl_image->offset % mmc->read_bl_len,
>> spl_image->load_addr + size )
>> after this patch.
>>
>> Meaning both with or without this patch some memory outside the image
>> gets written when the image is not aligned on media, but before it was
>> some part of a block at the end and now is that part before the
>> beginning.
>>
>> Whether that's better or worse I don't know. It depends on whether
>> it's a problem to write in non mapped memory, whether there's
>> something worth preserving there, and whether some SOC has some sort
>> of special behaving memory just there, like it happened with the issue
>> Jerome Forissier found (note in this case it wasn't legacy, it was
>> simple fit)
>
> Fundamentally, we can't really deal with unaligned images without a
> bounce-buffer. The method used by SPL_LOAD_FIT_IMAGE_BUFFER_SIZE will
> continue working, since we call into the FIT routines to load the image.
> I would like to defer bounce buffering for other images until someone
> actually needs it.
>
> Note that in the FIT case, you can also do `mkimage -EB`, at least if
> you aren't using FIT_LOAD_FULL.
With the following two commits introduced in v2023.04-rc1, the alignment
issue for Rockchip has been fixed and all external data is now accessed
block aligned.
9b2fd2d22852 ("binman: Add support for align argument to mkimage tool")
5ad03fc77dfa ("rockchip: Align FIT image data to SD/MMC block length")
Regards,
Jonas
>
> --Sean
>
>> https://patchwork.ozlabs.org/project/uboot/patch/c941d835a85255ff81a21c72069c3a9fc9a8a255.1656489154.git.jerome.foriss...@linaro.org/
>>
>>> Signed-off-by: Sean Anderson
>>> ---
>>>
>>> Changes in v5:
>>> - Rework to load header in spl_load
>>>
>>> common/spl/spl_mmc.c | 91
>>> 1 file changed, 8 insertions(+), 83 deletions(-)
>>>
[...]
