Re: [PATCH v2 7/9] imx8mm_evk: spl: enable pwm clock
On Wed, Mar 16, 2022 at 8:55 PM Fabio Estevam wrote: > > Hi Tommaso, > > On Wed, Mar 16, 2022 at 12:28 PM Tommaso Merciai > wrote: > > > > Enable pwm1 clock into spl > > Please improve the commit log and explain why you need to enable the > PWM clock in SPL. > > What is the PWM use case in PWM that you plan to use? I meant: "What is the PWM use case in SPL that you plan to use?"
Re: ARM A53 and initial MMU mapping for EL0/1/2/3 ?
On Wed, 16 Mar 2022 20:28:31 + Joakim Tjernlund wrote: Hi, > Got something I cannot figure out and was hoping to pick your brain: > timeofday does not count. > I can now boot fine into user space but then I tested the date command > and my time stands still on 1970. I can set date but the time still does not > count. > Normal sleep 1 works though. Using 32 bit user space with musl libc. > > Since I boot/reset directly into u-boot I guess I have forgotten to configure > something. > Any ideas? So depending on your platform the arch time clock base might need to be enabled explicitly (some clock gate or extra register)? It should be fairly easy to just read the virt counter and see it progressing (mrs x0, CNTVCT_EL0). Another thing to check for is whether CNTFRQ_EL0 has been setup by U-Boot: define COUNTER_FREQUENCY to the frequency of the arch timer clock, see arch/arm/cpu/armv8/start.S. Cheers, Andre > Jocke > > On Thu, 2022-02-17 at 15:13 +, Andre Przywara wrote: > > On Fri, 11 Feb 2022 17:00:48 + > > Joakim Tjernlund wrote: > > > > Hi, > > > > > On Fri, 2022-02-11 at 15:00 +0100, Joakim Tjernlund wrote: > > > > On Fri, 2022-02-11 at 01:26 +, Andre Przywara wrote: > > > > > On Fri, 11 Feb 2022 00:22:25 + > > > > > Joakim Tjernlund wrote: > > > > > > > > > > > On Thu, 2022-02-10 at 22:43 +, Andre Przywara wrote: > > > > > > > On Thu, 10 Feb 2022 21:58:30 + > > > > > > > Joakim Tjernlund wrote: > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > On Thu, 2022-02-10 at 10:22 +, Andre Przywara wrote: > > > > > > > > > On Wed, 9 Feb 2022 12:03:47 + > > > > > > > > > Joakim Tjernlund wrote: > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > On Wed, 2022-02-09 at 10:45 +, Andre Przywara wrote: > > > > > > > > > > > > > > > > > > > > > On Wed, 9 Feb 2022 08:35:04 + > > > > > > > > > > > Joakim Tjernlund wrote: > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > > > > On Wed, 2022-02-09 at 00:33 +, Andre Przywara > > > > > > > > > > > > wrote: > > > > > > > > > > > > > On Tue, 8 Feb 2022 22:05:00 + > > > > > > > > > > > > > Joakim Tjernlund > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Joakim, > > > > > > > > > > > > > > > > > > > > > > > > > > > Trying to figure out how I should map the MMU for > > > > > > > > > > > > > > normal RAM so it acessible > > > > > > > > > > > > > > from all ELx security states. > > > > > > > > > > > > > > > > > > > > > > > > > >^^^ > > > > > > > > > > > > > > > > > > > > > > > > > > This does not make much sense. U-Boot is typically > > > > > > > > > > > > > running in one > > > > > > > > > > > > > exception level only, and sets up the page table for > > > > > > > > > > > > > exactly that EL. > > > > > > > > > > > > > Each EL uses a separate translation regime (with some > > > > > > > > > > > > > twists for stage > > > > > > > > > > > > > 2 EL2 and combined EL1/0, plus VHE). If you map your > > > > > > > > > > > > > memory in EL3, then > > > > > > > > > > > > > drop to EL2, the EL3 page tables become irrelevant. > > > > > > > > > > > > > > > > > > > > > > > > > > So in U-Boot we just set up the page tables for the > > > > > > > > > > > > > EL we are running > > > > > > > > > > > > > in, and leave the paging for the lower exception > > > > > > > > > > > > > levels to be set up at > > > > > > > > > > > > > the discretion of our payloads (kernels, hypervisors). > > > > > > > > > > > > > > > > > > > > > > > > > > Please not that *secure* memory is a separate > > > > > > > > > > > > > concept, and handled by > > > > > > > > > > > > > external hardware, typically using regions, not page > > > > > > > > > > > > > tables. > > > > > > > > > > > > > > > > > > > > > > > > I am a beginner w.r.t ARM and Secure/Non secure so > > > > > > > > > > > > thank you for above. > > > > > > > > > > > > > > > > > > > > > > > > The problem I have is that I boot a custom SOC into > > > > > > > > > > > > u-boot and when u-boot tries > > > > > > > > > > > > to boot linux I get an error exception when u-boot > > > > > > > > > > > > calls armv8_switch_to_el2 to enter linux. > > > > > > > > > > > > > > > > > > > > > > So that means that U-Boot runs in EL3, is that the first > > > > > > > > > > > and only firmware > > > > > > > > > > > that you run? I think the EL3 part of U-Boot is not > > > > > > > > > > > widely used and tested > > > > > > > > > > > beyond the very few platforms that use it. > > > > > > > > > > > > > > > > > > > > Yes, u-boot is first firmware and runs in EL3(ATM, may > > > > > > > > > > change once initial bringup is complete) > > > > > > > > > > Maybe u-boot then lacks some critical init? Do you have an > > > > > > > > > > example of a board in
Re: [PATCH 1/1] cmd: sbi: add Performance Monitoring Unit Extension
On Thu, Mar 17, 2022 at 4:21 AM Heinrich Schuchardt wrote: > > Version 1.0-rc3 of the RISC-V Supervisor Binary Interface Specification > has added the Performance Monitoring Unit Extension. > > The sbi command should be able to detect it. > > Signed-off-by: Heinrich Schuchardt > --- > At this point it is not necessary to add the full interface descritption > of the PMU extension in sbi.h. We can add it later if we ever have to > make use of the extension. > --- > arch/riscv/include/asm/sbi.h | 1 + > cmd/riscv/sbi.c | 1 + > 2 files changed, 2 insertions(+) > Reviewed-by: Bin Meng
Re: [PATCH] test/py: efi_capsule: Handle expected reset after capsule on disk
Hi Heinrich, On Wed, 16 Mar 2022 at 14:47, Heinrich Schuchardt wrote: > > > > Am 16. März 2022 20:23:37 MEZ schrieb Simon Glass : > >Hi Masami, > > > >On Wed, 16 Mar 2022 at 00:09, Masami Hiramatsu > > wrote: > >> > >> Hi Simon, > >> > >> 2022年3月16日(水) 12:13 Simon Glass : > >> > > >> > Hi Masami, > >> > > >> > On Tue, 15 Mar 2022 at 02:36, Masami Hiramatsu > >> > wrote: > >> > > > >> > > Hi Simon, > >> > > > >> > > 2022年3月15日(火) 14:04 Simon Glass : > >> > > > > >> > > > Hi Masami, > >> > > > > >> > > > On Mon, 14 Mar 2022 at 18:40, Masami Hiramatsu > >> > > > wrote: > >> > > > > > >> > > > > Hi Simon, > >> > > > > > >> > > > > 2022年3月15日(火) 3:24 Simon Glass : > >> > > > > > > >> > > > > > > > OK, well 'reset by a user' presumably starts the board up > >> > > > > > > > and then > >> > > > > > > > runs some code to do the update in U-Boot? Is that right? If > >> > > > > > > > so, we > >> > > > > > > > just need to trigger that update from the test. We don't > >> > > > > > > > need to test > >> > > > > > > > the actual reset, at least not with sandbox. As I said, we > >> > > > > > > > need to > >> > > > > > > > write the code so that it is easy to test. > >> > > > > > > > >> > > > > > > Actually, we already have that command, "efidebug capsule > >> > > > > > > disk-update" > >> > > > > > > which kicks the capsule update code even without the 'reset by > >> > > > > > > a > >> > > > > > > user'. So we can just kick this command for checking whether > >> > > > > > > the > >> > > > > > > U-Boot UEFI code correctly find the capsule file from ESP which > >> > > > > > > specified by UEFI vars. > >> > > > > > > > >> > > > > > > However, the 'capsule update on-disk' feature is also expected > >> > > > > > > (and > >> > > > > > > defined in the spec?) to run when the UEFI subsystem is > >> > > > > > > initialized. > >> > > > > > > This behavior will not be tested if we skip the 'reset by a > >> > > > > > > user'. I > >> > > > > > > guess Takahiro's current test case tries to check it. > >> > > > > > > >> > > > > > The 'UEFI subsystem is intialised' is a problem, actually, since > >> > > > > > if it > >> > > > > > were better integrated into driver model, it would not have > >> > > > > > separate > >> > > > > > structures or they would be present and enabled when driver > >> > > > > > model is. > >> > > > > > I hope that it can be fixed and Takahiro's series is a start in > >> > > > > > that > >> > > > > > direction. > >> > > > > > >> > > > > OK. > >> > > > > > >> > > > > > But as to a test that an update is called when UEFI starts, that > >> > > > > > seems > >> > > > > > like a single line of code. Sure it is nice to test it, but it > >> > > > > > is much > >> > > > > > more important to test the installation of the update and the > >> > > > > > execution of the update. I suppose another way to test that is > >> > > > > > to > >> > > > > > shut down the UEFI subsystem and start it up? > >> > > > > > >> > > > > Yes, currently we call do_reset() after install the capsule file. > >> > > > > (This reset can be avoided if we replace it with > >> > > > > sysreset_walk_halt(SYSRESET_COLD) as you said, right?) > >> > > > > > >> > > > > Here is how I tested it on my machine; > >> > > > > > >> > > > > > usb start > >> > > > > > fatload usb 0 $kernel_addr_r test.cap > >> > > > > > fatwrite mmc 0 $fileaddr EFI/UpdateCapsule/test.cap $filesize > >> > > > > > efidebug capsule disk-update > >> > > > > (run install process and reboot the machine) > >> > > > > > >> > > > > So, if we can avoid the last reset, we can test the below without > >> > > > > reset on sandbox (depends on scenarios). > >> > > > > - confirm that the capsule update on disk can find the capsule file > >> > > > > from ESP specified by the BOOT EFI variable. > >> > > > > - confirm that the capsule update on disk writes the firmware > >> > > > > correctly to the storage which specified by DFU. > >> > > > > - confirm that the capsule update on disk success if the capsule > >> > > > > image > >> > > > > type is supported. > >> > > > > - confirm that the capsule update on disk fails if the capsule > >> > > > > image > >> > > > > type is not supported. > >> > > > > - confirm that the capsule update on disk will reboot after update > >> > > > > even if the update is failed. > >> > > > > > >> > > > > The only spec we can not test is > >> > > > > - confirm that the capsule update on disk is kicked when the UEFI > >> > > > > is > >> > > > > initialized. > >> > > > > >> > > > Even that could be tested, by installing an update and then initing > >> > > > UEFI? > >> > > > >> > > yeah, if the UEFI is not initialized yet, we can run some UEFI related > >> > > command (e.g. printenv -e) instead of efidebug capsule... to execute > >> > > the capsule update on disk. > >> > > But anyway, this is only available at the first time. We need a way to > >> > > reset UEFI subsystem without system reset. > >> > > >> > Yes. It is certainly possible, but I'm not
Re: [PATCH 8/9] arm: dts: imx8mm_evk: add pwm1/backlight support
On Wed, Mar 16, 2022 at 6:00 AM Tommaso Merciai wrote: > > Add pwm1/backlight support nodes for imx8mm_evk board Why do you enable backlight given that the board does not support splash screen?
Re: [PATCH v2 7/9] imx8mm_evk: spl: enable pwm clock
Hi Tommaso, On Wed, Mar 16, 2022 at 12:28 PM Tommaso Merciai wrote: > > Enable pwm1 clock into spl Please improve the commit log and explain why you need to enable the PWM clock in SPL. What is the PWM use case in PWM that you plan to use?
Re: [PATCH v2 4/9] arm: imx: imx8mm: add enable_pwm_clk function
On 3/16/22 16:27, Tommaso Merciai wrote: Add function enable_pwm_clk into in clock_imx8mm.c. This function first configure, then enable pwm clock from clock control register. The following configuration is used: source(0) -> 24 MHz ref clock div(0)-> no division for this clock References: - iMX8MMRM.pdf p 303 Signed-off-by: Tommaso Merciai --- Changes since v1: - Fix enable_pwm_clk function implementation. Now is generic for all pwm clks arch/arm/mach-imx/imx8m/clock_imx8mm.c | 53 ++ 1 file changed, 53 insertions(+) Why is this not in drivers/clk/imx/ DM driver ?
Re: [PATCH] test/py: efi_capsule: Handle expected reset after capsule on disk
Am 16. März 2022 20:23:37 MEZ schrieb Simon Glass : >Hi Masami, > >On Wed, 16 Mar 2022 at 00:09, Masami Hiramatsu > wrote: >> >> Hi Simon, >> >> 2022年3月16日(水) 12:13 Simon Glass : >> > >> > Hi Masami, >> > >> > On Tue, 15 Mar 2022 at 02:36, Masami Hiramatsu >> > wrote: >> > > >> > > Hi Simon, >> > > >> > > 2022年3月15日(火) 14:04 Simon Glass : >> > > > >> > > > Hi Masami, >> > > > >> > > > On Mon, 14 Mar 2022 at 18:40, Masami Hiramatsu >> > > > wrote: >> > > > > >> > > > > Hi Simon, >> > > > > >> > > > > 2022年3月15日(火) 3:24 Simon Glass : >> > > > > > >> > > > > > > > OK, well 'reset by a user' presumably starts the board up and >> > > > > > > > then >> > > > > > > > runs some code to do the update in U-Boot? Is that right? If >> > > > > > > > so, we >> > > > > > > > just need to trigger that update from the test. We don't need >> > > > > > > > to test >> > > > > > > > the actual reset, at least not with sandbox. As I said, we >> > > > > > > > need to >> > > > > > > > write the code so that it is easy to test. >> > > > > > > >> > > > > > > Actually, we already have that command, "efidebug capsule >> > > > > > > disk-update" >> > > > > > > which kicks the capsule update code even without the 'reset by a >> > > > > > > user'. So we can just kick this command for checking whether the >> > > > > > > U-Boot UEFI code correctly find the capsule file from ESP which >> > > > > > > specified by UEFI vars. >> > > > > > > >> > > > > > > However, the 'capsule update on-disk' feature is also expected >> > > > > > > (and >> > > > > > > defined in the spec?) to run when the UEFI subsystem is >> > > > > > > initialized. >> > > > > > > This behavior will not be tested if we skip the 'reset by a >> > > > > > > user'. I >> > > > > > > guess Takahiro's current test case tries to check it. >> > > > > > >> > > > > > The 'UEFI subsystem is intialised' is a problem, actually, since >> > > > > > if it >> > > > > > were better integrated into driver model, it would not have >> > > > > > separate >> > > > > > structures or they would be present and enabled when driver model >> > > > > > is. >> > > > > > I hope that it can be fixed and Takahiro's series is a start in >> > > > > > that >> > > > > > direction. >> > > > > >> > > > > OK. >> > > > > >> > > > > > But as to a test that an update is called when UEFI starts, that >> > > > > > seems >> > > > > > like a single line of code. Sure it is nice to test it, but it is >> > > > > > much >> > > > > > more important to test the installation of the update and the >> > > > > > execution of the update. I suppose another way to test that is to >> > > > > > shut down the UEFI subsystem and start it up? >> > > > > >> > > > > Yes, currently we call do_reset() after install the capsule file. >> > > > > (This reset can be avoided if we replace it with >> > > > > sysreset_walk_halt(SYSRESET_COLD) as you said, right?) >> > > > > >> > > > > Here is how I tested it on my machine; >> > > > > >> > > > > > usb start >> > > > > > fatload usb 0 $kernel_addr_r test.cap >> > > > > > fatwrite mmc 0 $fileaddr EFI/UpdateCapsule/test.cap $filesize >> > > > > > efidebug capsule disk-update >> > > > > (run install process and reboot the machine) >> > > > > >> > > > > So, if we can avoid the last reset, we can test the below without >> > > > > reset on sandbox (depends on scenarios). >> > > > > - confirm that the capsule update on disk can find the capsule file >> > > > > from ESP specified by the BOOT EFI variable. >> > > > > - confirm that the capsule update on disk writes the firmware >> > > > > correctly to the storage which specified by DFU. >> > > > > - confirm that the capsule update on disk success if the capsule >> > > > > image >> > > > > type is supported. >> > > > > - confirm that the capsule update on disk fails if the capsule image >> > > > > type is not supported. >> > > > > - confirm that the capsule update on disk will reboot after update >> > > > > even if the update is failed. >> > > > > >> > > > > The only spec we can not test is >> > > > > - confirm that the capsule update on disk is kicked when the UEFI is >> > > > > initialized. >> > > > >> > > > Even that could be tested, by installing an update and then initing >> > > > UEFI? >> > > >> > > yeah, if the UEFI is not initialized yet, we can run some UEFI related >> > > command (e.g. printenv -e) instead of efidebug capsule... to execute >> > > the capsule update on disk. >> > > But anyway, this is only available at the first time. We need a way to >> > > reset UEFI subsystem without system reset. >> > >> > Yes. It is certainly possible, but I'm not sure how easy it is. >> > Perhaps just drop all the EFI data structures and run the EFI init >> > again? We have something similar with driver model. See >> > dm_test_pre_run() >> >> EFI has the ExitBootServices call, but I'm not sure it is actually >> clear all resources. Maybe we need to check what resources are >> released by the ExitBootServices. >> >> > > > > > >> > > > > >
Re: ARM A53 and initial MMU mapping for EL0/1/2/3 ?
Hi again Got something I cannot figure out and was hoping to pick your brain: timeofday does not count. I can now boot fine into user space but then I tested the date command and my time stands still on 1970. I can set date but the time still does not count. Normal sleep 1 works though. Using 32 bit user space with musl libc. Since I boot/reset directly into u-boot I guess I have forgotten to configure something. Any ideas? Jocke On Thu, 2022-02-17 at 15:13 +, Andre Przywara wrote: > On Fri, 11 Feb 2022 17:00:48 + > Joakim Tjernlund wrote: > > Hi, > > > On Fri, 2022-02-11 at 15:00 +0100, Joakim Tjernlund wrote: > > > On Fri, 2022-02-11 at 01:26 +, Andre Przywara wrote: > > > > On Fri, 11 Feb 2022 00:22:25 + > > > > Joakim Tjernlund wrote: > > > > > > > > > On Thu, 2022-02-10 at 22:43 +, Andre Przywara wrote: > > > > > > On Thu, 10 Feb 2022 21:58:30 + > > > > > > Joakim Tjernlund wrote: > > > > > > > > > > > > Hi, > > > > > > > > > > > > > On Thu, 2022-02-10 at 10:22 +, Andre Przywara wrote: > > > > > > > > On Wed, 9 Feb 2022 12:03:47 + > > > > > > > > Joakim Tjernlund wrote: > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > On Wed, 2022-02-09 at 10:45 +, Andre Przywara wrote: > > > > > > > > > > On Wed, 9 Feb 2022 08:35:04 + > > > > > > > > > > Joakim Tjernlund wrote: > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > > On Wed, 2022-02-09 at 00:33 +, Andre Przywara wrote: > > > > > > > > > > > > > > > > > > > > > > > On Tue, 8 Feb 2022 22:05:00 + > > > > > > > > > > > > Joakim Tjernlund wrote: > > > > > > > > > > > > > > > > > > > > > > > > Hi Joakim, > > > > > > > > > > > > > > > > > > > > > > > > > Trying to figure out how I should map the MMU for > > > > > > > > > > > > > normal RAM so it acessible > > > > > > > > > > > > > from all ELx security states. > > > > > > > > > > > > > > > > > > > > > > > >^^^ > > > > > > > > > > > > > > > > > > > > > > > > This does not make much sense. U-Boot is typically > > > > > > > > > > > > running in one > > > > > > > > > > > > exception level only, and sets up the page table for > > > > > > > > > > > > exactly that EL. > > > > > > > > > > > > Each EL uses a separate translation regime (with some > > > > > > > > > > > > twists for stage > > > > > > > > > > > > 2 EL2 and combined EL1/0, plus VHE). If you map your > > > > > > > > > > > > memory in EL3, then > > > > > > > > > > > > drop to EL2, the EL3 page tables become irrelevant. > > > > > > > > > > > > > > > > > > > > > > > > So in U-Boot we just set up the page tables for the EL > > > > > > > > > > > > we are running > > > > > > > > > > > > in, and leave the paging for the lower exception levels > > > > > > > > > > > > to be set up at > > > > > > > > > > > > the discretion of our payloads (kernels, hypervisors). > > > > > > > > > > > > > > > > > > > > > > > > Please not that *secure* memory is a separate concept, > > > > > > > > > > > > and handled by > > > > > > > > > > > > external hardware, typically using regions, not page > > > > > > > > > > > > tables. > > > > > > > > > > > > > > > > > > > > > > I am a beginner w.r.t ARM and Secure/Non secure so thank > > > > > > > > > > > you for above. > > > > > > > > > > > > > > > > > > > > > > The problem I have is that I boot a custom SOC into > > > > > > > > > > > u-boot and when u-boot tries > > > > > > > > > > > to boot linux I get an error exception when u-boot calls > > > > > > > > > > > armv8_switch_to_el2 to enter linux. > > > > > > > > > > > > > > > > > > > > So that means that U-Boot runs in EL3, is that the first > > > > > > > > > > and only firmware > > > > > > > > > > that you run? I think the EL3 part of U-Boot is not widely > > > > > > > > > > used and tested > > > > > > > > > > beyond the very few platforms that use it. > > > > > > > > > > > > > > > > > > Yes, u-boot is first firmware and runs in EL3(ATM, may change > > > > > > > > > once initial bringup is complete) > > > > > > > > > Maybe u-boot then lacks some critical init? Do you have an > > > > > > > > > example of a board in u-boot > > > > > > > > > that starts in EL3(from reset) using an A53 cpu? > > > > > > > > > > > > > > > > As you have probably figured out by now, the whole Layerscape > > > > > > > > family uses > > > > > > > > that approach. However most other platforms go with > > > > > > > > Trusted-Firmware as the > > > > > > > > EL3 setup and secure runtime service provider, so the U-Boot > > > > > > > > EL3 code in > > > > > > > > here is not well tested or looked after. For initial bringup it > > > > > > > > might be > > > > > > > > OK, but maybe the problems you run into are due to issues in > > > > > > > > this code. > > > > > > > > > > > > > > > > > > Do you have the exact address that fails? That should be in > > >
[PATCH 1/1] cmd: sbi: add Performance Monitoring Unit Extension
Version 1.0-rc3 of the RISC-V Supervisor Binary Interface Specification
has added the Performance Monitoring Unit Extension.
The sbi command should be able to detect it.
Signed-off-by: Heinrich Schuchardt
---
At this point it is not necessary to add the full interface descritption
of the PMU extension in sbi.h. We can add it later if we ever have to
make use of the extension.
---
arch/riscv/include/asm/sbi.h | 1 +
cmd/riscv/sbi.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/arch/riscv/include/asm/sbi.h b/arch/riscv/include/asm/sbi.h
index bfcd204953..76453121ea 100644
--- a/arch/riscv/include/asm/sbi.h
+++ b/arch/riscv/include/asm/sbi.h
@@ -27,6 +27,7 @@ enum sbi_ext_id {
SBI_EXT_RFENCE = 0x52464E43,
SBI_EXT_HSM = 0x48534D,
SBI_EXT_SRST = 0x53525354,
+ SBI_EXT_PMU = 0x504D55,
};
enum sbi_ext_base_fid {
diff --git a/cmd/riscv/sbi.c b/cmd/riscv/sbi.c
index c4a9c840f3..8349123925 100644
--- a/cmd/riscv/sbi.c
+++ b/cmd/riscv/sbi.c
@@ -44,6 +44,7 @@ static struct sbi_ext extensions[] = {
{ SBI_EXT_RFENCE, "RFENCE Extension" },
{ SBI_EXT_HSM,"Hart State Management Extension"
},
{ SBI_EXT_SRST, "System Reset Extension" },
+ { SBI_EXT_PMU,"Performance Monitoring Unit
Extension" },
};
static int do_sbi(struct cmd_tbl *cmdtp, int flag, int argc,
--
2.34.1
Re: [PATCH 9/9] arm64: Import from Linux
On 3/16/22 11:39 AM, Pierre-Clément Tosi wrote: Import the header from version 5.16 of the kernel: commit df0cc57e057f18e44dac8e6c18aba47ab53202f9 Signed-off-by: Pierre-Clément Tosi Cc: Tom Rini --- arch/arm/include/asm/esr.h | 343 + 1 file changed, 343 insertions(+) create mode 100644 arch/arm/include/asm/esr.h diff --git a/arch/arm/include/asm/esr.h b/arch/arm/include/asm/esr.h new file mode 100644 index 00..d52a0b269e --- /dev/null +++ b/arch/arm/include/asm/esr.h @@ -0,0 +1,343 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ +/* + * Copyright (C) 2013 - ARM Ltd + * Author: Marc Zyngier + */ + +#ifndef __ASM_ESR_H +#define __ASM_ESR_H + +#include +#include I think this is just needed for the UL macros. See e.g. [1]. --Sean [1] https://lore.kernel.org/u-boot/20220310205059.499269-22-sean.ander...@seco.com/ + +#define ESR_ELx_EC_UNKNOWN (0x00) +#define ESR_ELx_EC_WFx (0x01) +/* Unallocated EC: 0x02 */ +#define ESR_ELx_EC_CP15_32 (0x03) +#define ESR_ELx_EC_CP15_64 (0x04) +#define ESR_ELx_EC_CP14_MR (0x05) +#define ESR_ELx_EC_CP14_LS (0x06) +#define ESR_ELx_EC_FP_ASIMD(0x07) +#define ESR_ELx_EC_CP10_ID (0x08) /* EL2 only */ +#define ESR_ELx_EC_PAC (0x09) /* EL2 and above */ +/* Unallocated EC: 0x0A - 0x0B */ +#define ESR_ELx_EC_CP14_64 (0x0C) +#define ESR_ELx_EC_BTI (0x0D) +#define ESR_ELx_EC_ILL (0x0E) +/* Unallocated EC: 0x0F - 0x10 */ +#define ESR_ELx_EC_SVC32 (0x11) +#define ESR_ELx_EC_HVC32 (0x12) /* EL2 only */ +#define ESR_ELx_EC_SMC32 (0x13) /* EL2 and above */ +/* Unallocated EC: 0x14 */ +#define ESR_ELx_EC_SVC64 (0x15) +#define ESR_ELx_EC_HVC64 (0x16) /* EL2 and above */ +#define ESR_ELx_EC_SMC64 (0x17) /* EL2 and above */ +#define ESR_ELx_EC_SYS64 (0x18) +#define ESR_ELx_EC_SVE (0x19) +#define ESR_ELx_EC_ERET(0x1a) /* EL2 only */ +/* Unallocated EC: 0x1B */ +#define ESR_ELx_EC_FPAC(0x1C) /* EL1 and above */ +/* Unallocated EC: 0x1D - 0x1E */ +#define ESR_ELx_EC_IMP_DEF (0x1f) /* EL3 only */ +#define ESR_ELx_EC_IABT_LOW(0x20) +#define ESR_ELx_EC_IABT_CUR(0x21) +#define ESR_ELx_EC_PC_ALIGN(0x22) +/* Unallocated EC: 0x23 */ +#define ESR_ELx_EC_DABT_LOW(0x24) +#define ESR_ELx_EC_DABT_CUR(0x25) +#define ESR_ELx_EC_SP_ALIGN(0x26) +/* Unallocated EC: 0x27 */ +#define ESR_ELx_EC_FP_EXC32(0x28) +/* Unallocated EC: 0x29 - 0x2B */ +#define ESR_ELx_EC_FP_EXC64(0x2C) +/* Unallocated EC: 0x2D - 0x2E */ +#define ESR_ELx_EC_SERROR (0x2F) +#define ESR_ELx_EC_BREAKPT_LOW (0x30) +#define ESR_ELx_EC_BREAKPT_CUR (0x31) +#define ESR_ELx_EC_SOFTSTP_LOW (0x32) +#define ESR_ELx_EC_SOFTSTP_CUR (0x33) +#define ESR_ELx_EC_WATCHPT_LOW (0x34) +#define ESR_ELx_EC_WATCHPT_CUR (0x35) +/* Unallocated EC: 0x36 - 0x37 */ +#define ESR_ELx_EC_BKPT32 (0x38) +/* Unallocated EC: 0x39 */ +#define ESR_ELx_EC_VECTOR32(0x3A) /* EL2 only */ +/* Unallocated EC: 0x3B */ +#define ESR_ELx_EC_BRK64 (0x3C) +/* Unallocated EC: 0x3D - 0x3F */ +#define ESR_ELx_EC_MAX (0x3F) + +#define ESR_ELx_EC_SHIFT (26) +#define ESR_ELx_EC_WIDTH (6) +#define ESR_ELx_EC_MASK(UL(0x3F) << ESR_ELx_EC_SHIFT) +#define ESR_ELx_EC(esr)(((esr) & ESR_ELx_EC_MASK) >> ESR_ELx_EC_SHIFT) + +#define ESR_ELx_IL_SHIFT (25) +#define ESR_ELx_IL (UL(1) << ESR_ELx_IL_SHIFT) +#define ESR_ELx_ISS_MASK (ESR_ELx_IL - 1) + +/* ISS field definitions shared by different classes */ +#define ESR_ELx_WNR_SHIFT (6) +#define ESR_ELx_WNR(UL(1) << ESR_ELx_WNR_SHIFT) + +/* Asynchronous Error Type */ +#define ESR_ELx_IDS_SHIFT (24) +#define ESR_ELx_IDS(UL(1) << ESR_ELx_IDS_SHIFT) +#define ESR_ELx_AET_SHIFT (10) +#define ESR_ELx_AET(UL(0x7) << ESR_ELx_AET_SHIFT) + +#define ESR_ELx_AET_UC (UL(0) << ESR_ELx_AET_SHIFT) +#define ESR_ELx_AET_UEU(UL(1) << ESR_ELx_AET_SHIFT) +#define ESR_ELx_AET_UEO(UL(2) << ESR_ELx_AET_SHIFT) +#define ESR_ELx_AET_UER(UL(3) << ESR_ELx_AET_SHIFT) +#define ESR_ELx_AET_CE (UL(6) << ESR_ELx_AET_SHIFT) + +/* Shared ISS field definitions for Data/Instruction aborts */ +#define ESR_ELx_SET_SHIFT (11) +#define ESR_ELx_SET_MASK (UL(3) << ESR_ELx_SET_SHIFT) +#define ESR_ELx_FnV_SHIFT (10) +#define ESR_ELx_FnV(UL(1) << ESR_ELx_FnV_SHIFT) +#define ESR_ELx_EA_SHIFT (9) +#define ESR_ELx_EA (UL(1) << ESR_ELx_EA_SHIFT) +#define ESR_ELx_S1PTW_SHIFT(7) +#define ESR_ELx_S1PTW (UL(1) << ESR_ELx_S1PTW_SHIFT) + +/* Shared ISS fault status code(IFSC/DFSC) for Data/Instruction aborts */ +#define ESR_ELx_FSC(0x3F) +#define ESR_ELx_FSC_TYPE (0x3C) +#define ESR_ELx_FSC_LEVEL (0x03) +#define ESR_ELx_FSC_EXTABT (0x10) +#define ESR_ELx_FSC_MTE
Re: [PATCH 2/9] lib: crypt: Avoid redefining static_assert
On 3/16/22 20:23, Simon Glass wrote:
On Wed, 16 Mar 2022 at 09:40, Pierre-Clément Tosi wrote:
Use the macro introduced by commit ef0f4e834c66 ("build_bug.h: add
wrapper for _Static_assert") by importing .
Signed-off-by: Pierre-Clément Tosi
Cc: Simon Glass
Cc: Steffen Jaeckel
---
lib/crypt/crypt-port.h | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
Reviewed-by: Simon Glass
Reviewed-by: Steffen Jaeckel
[PATCH v2] boot: image: fixup zstd decompression buffer initialization typo
The code was mistakenly initializing the input buffer twice.
Tested to be working on BeagleBone by adjusting CONFIG_SYS_BOOTM_LEN to
64MiB (probably works with less) and preparing uImage with:
cat arch/arm/boot/Image \
| zstd --ultra -22 --zstd=windowLog=22 \
> linux.bin.zst
mkimage -A arm -T kernel uImage -C zstd -d linux.bin.zst \
-a 0x80008000 -e 0x80008000
Without the windowLog restriction, bootm fails with a zstd decompression
error 7 (window too large), which I haven't troubleshooted.
There should be a bit more documentation on the feature...
Reviewed-by: Simon Glass
Fixes: 458b30af66c image: Update image_decomp() to avoid ifdefs
---
boot/image.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/boot/image.c b/boot/image.c
index 07fa2d3160..121df0c838 100644
--- a/boot/image.c
+++ b/boot/image.c
@@ -500,7 +500,7 @@ int image_decomp(int comp, ulong load, ulong image_start,
int type,
struct abuf in, out;
abuf_init_set(, image_buf, image_len);
- abuf_init_set(, load_buf, unc_len);
+ abuf_init_set(, load_buf, unc_len);
ret = zstd_decompress(, );
if (ret >= 0) {
image_len = ret;
--
2.35.1
Re: [PATCH 1/7] clk: Make rfree return void
HI Sean, On Wed, 16 Mar 2022 at 10:18, Sean Anderson wrote: > > On 3/1/22 9:58 AM, Simon Glass wrote: > > Hi Sean, > > > > On Sun, 27 Feb 2022 at 12:38, Sean Anderson wrote: > >> > >> On 2/26/22 1:36 PM, Simon Glass wrote: > >>> Hi Sean, > >>> > >>> On Tue, 1 Feb 2022 at 21:24, Sean Anderson wrote: > > On 2/1/22 10:59 PM, Simon Glass wrote: > > Hi Sean, > > > > On Tue, 1 Feb 2022 at 07:49, Sean Anderson wrote: > >> > >> On 1/27/22 4:35 PM, Simon Glass wrote: > >>> Hi Sean, > >>> > >>> On Thu, 27 Jan 2022 at 08:43, Sean Anderson wrote: > > On 1/27/22 10:05 AM, Simon Glass wrote: > > Hi Sean, > > > > On Sat, 15 Jan 2022 at 15:25, Sean Anderson > > wrote: > >> > >> When freeing a clock there is not much we can do if there is an > >> error, and > >> most callers do not actually check the return value. Even e.g. > >> checking to > >> make sure that clk->id is valid should have been done in request() > >> in the > >> first place (unless someone is messing with the driver behind our > >> back). > >> Just return void and don't bother returning an error. > >> > >> Signed-off-by: Sean Anderson > >> --- > >> > >> drivers/clk/clk-uclass.c | 7 +++ > >> drivers/clk/clk_sandbox.c | 6 +++--- > >> include/clk-uclass.h | 8 +++- > >> 3 files changed, 9 insertions(+), 12 deletions(-) > >> > > > > We have the same thing in other places too, but I am a little > > worried > > about removing error checking. We try to avoid checking arguments > > too > > much in U-Boot, due to code-size concerns, so I suppose I agree that > > an invalid clk should be caught by a debug assertion rather than a > > full check. But with driver model we have generally added an error > > return to every uclass method, for consistency and to permit > > returning > > error information if needed. > > > > Regards, > > Simon > > > > So there are a few reasons why I don't think a return value is useful > here. To illustrate this, consider a typical user of the clock API: > > struct clk a, b; > > ret = clk_get_by_name(dev, "a", ); > if (ret) > return ret; > > ret = clk_get_by_name(dev, "b", ); > if (ret) > goto free_a; > > ret = clk_set_rate(, 500); > if (ret) > goto free_b; > > ret = clk_enable(); > > free_b: > clk_free(); > free_a: > clk_free(); > return ret; > > - Because a and b are "thick pointers" they do not need any cleanup > to > free their own resources. The only cleanup might be if the > clock > driver has allocated something in clk_request (more on this > below) > - By the time we call clk_free, the mutable portions of the function > have already completed. In effect, the function has succeeded, > regardless of whether clk_free fails. Additionally, we cannot > take any > action if it fails, since we still have to free both clocks. > - clk_free occurs during the error path of the function. Even if it > errored, we do not want to override the existing error from > one of the > functions doing "real" work. > > The last thing is that no clock driver actually does anything in > rfree. > The only driver with this function is the sandbox driver. I would > like > to remove the function altogether. As I understand it, the existing > API > is inspired by the reset drivers, so I would like to review its > usage in > the reset subsystem before removing it for the clock subsystem. I > also > want to make some changes to how rates and enables/disables are > calculated which might provide a case for rfree. But once that is > complete I think there will be no users still. > >>> > >>> What does this all look like in Linux? > >> > >> Their equivalent (clk_put) returns void, and generally so do most other > >> cleanup functions, since .device_remove also returns void. > > > > We really cannot ignore errors from device_remove(). > > Once you are at device_remove, all the users are
Re: [PATCH 6/9] include: Carve out of compat.h
On Wed, 16 Mar 2022 at 09:41, Pierre-Clément Tosi wrote: > > As Linux source code might include that header directly and as it is a > simple "leaf header" (probably won't include other headers) that is > unlikely to be relevant to U-Boot, replicate the upstream header > definitions in a dedicated and include it in the > pre-existing compat.h for existing users. > > Signed-off-by: Pierre-Clément Tosi > Cc: Simon Glass > Cc: Tom Rini > --- > include/linux/compat.h | 4 +--- > include/linux/export.h | 25 + > 2 files changed, 26 insertions(+), 3 deletions(-) > create mode 100644 include/linux/export.h Reviewed-by: Simon Glass
Re: [PATCH] boot: image: fixup zstd decompression buffer initialization typo
Hi Jérôme,
On Wed, 16 Mar 2022 at 12:16, Jérôme Carretero wrote:
>
Thanks for the fix! Please add a commit message.
> Fixes: 458b30af66cd41ca8e6f8a52ea4c09cb50d3413d
> Cc: Simon Glass
> ---
> boot/image.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Reviewed-by: Simon Glass
Fixes: 458b30af66c image: Update image_decomp() to avoid ifdefs
>
> diff --git a/boot/image.c b/boot/image.c
> index 07fa2d3160..121df0c838 100644
> --- a/boot/image.c
> +++ b/boot/image.c
> @@ -500,7 +500,7 @@ int image_decomp(int comp, ulong load, ulong image_start,
> int type,
> struct abuf in, out;
>
> abuf_init_set(, image_buf, image_len);
> - abuf_init_set(, load_buf, unc_len);
> + abuf_init_set(, load_buf, unc_len);
> ret = zstd_decompress(, );
> if (ret >= 0) {
> image_len = ret;
> --
> 2.35.1
>
Regards,
Simon
Re: [PATCH 4/9] linux/const.h: Upgrade & Merge vDSO and uAPI
Hi Pierre-Clément,
On Wed, 16 Mar 2022 at 09:40, Pierre-Clément Tosi wrote:
>
> Import the header from version 5.16 of the kernel:
>
> commit df0cc57e057f18e44dac8e6c18aba47ab53202f9
>
> Inline and . This is wrapped in
> "#ifndef __UBOOT__/#include/#else/{inline}" to better document the
> origin of the code being added to the U-Boot header (but not present in
> the original header) and make diff tools happier when comparing the file
> with its reference, which should be useful when porting future changes
> from the Linux header and/or if we decide to also import those included
> headers into the U-Boot codebase.
>
> Signed-off-by: Pierre-Clément Tosi
> Cc: Simon Glass
> Cc: Tom Rini
> ---
> include/linux/const.h | 22 +-
> 1 file changed, 21 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/const.h b/include/linux/const.h
> index 379c889232..3e3803d767 100644
> --- a/include/linux/const.h
> +++ b/include/linux/const.h
> @@ -2,8 +2,13 @@
> #ifndef _LINUX_CONST_H
> #define _LINUX_CONST_H
>
> -/* const.h: Macros for dealing with constants. */
> +#ifndef __UBOOT__
> +#include
> +#else
>
> +#ifndef __UBOOT__
> +#include
> +#else
> /* Some constant macros are used in both assembler and
> * C code. Therefore we cannot annotate them always with
> * 'UL' and other type specifiers unilaterally. We
> @@ -28,7 +33,22 @@
> #define _BITUL(x) (_UL(1) << (x))
> #define _BITULL(x) (_ULL(1) << (x))
>
> +#define __ALIGN_KERNEL(x, a) __ALIGN_KERNEL_MASK(x, (typeof(x))(a)
> - 1)
> +#define __ALIGN_KERNEL_MASK(x, mask) (((x) + (mask)) & ~(mask))
How does this compare to the existing ALIGN()? It looks the same to me.
> +
> +#define __KERNEL_DIV_ROUND_UP(n, d) (((n) + (d) - 1) / (d))
> +#endif
> +
> #define UL(x) (_UL(x))
> #define ULL(x) (_ULL(x))
> +#endif
> +
> +/*
> + * This returns a constant expression while determining if an argument is
> + * a constant expression, most importantly without evaluating the argument.
> + * Glory to Martin Uecker
> + */
> +#define __is_constexpr(x) \
> + (sizeof(int) == sizeof(*(8 ? ((void *)((long)(x) * 0l)) : (int *)8)))
>
> #endif /* _LINUX_CONST_H */
> --
> 2.35.1.723.g4982287a31-goog
>
REgards,
Simon
Re: [PATCH 3/9] scripts: Makefile.lib: Pass __UBOOT__ to DTC's CPP
Hi Pierre-Clément, On Wed, 16 Mar 2022 at 09:40, Pierre-Clément Tosi wrote: > > Some headers included (possibly indirectly) from .dts files might have > U-Boot specific content relying on the __UBOOT__ macro passed to CPP > when building C code. In that case, it would be sensible for DTC to see > that content instead of the non-U-Boot one. To do so, pass the macro to > the pre-processor when generate DTC inputs. Can you give an example of such a situation? > > Signed-off-by: Pierre-Clément Tosi > Cc: Simon Glass > --- > scripts/Makefile.lib | 1 + > 1 file changed, 1 insertion(+) Reviewed-by: Simon Glass > > diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib > index c14da10de7..d7b548dce8 100644 > --- a/scripts/Makefile.lib > +++ b/scripts/Makefile.lib > @@ -192,6 +192,7 @@ dtc_cpp_flags = -Wp,-MD,$(depfile).pre.tmp -nostdinc >\ > -I$(srctree)/arch/$(ARCH)/include \ > -include $(srctree)/include/linux/kconfig.h \ > -D__ASSEMBLY__ \ > +-D__UBOOT__ \ > -undef -D__DTS__ > > # Finds the multi-part object the current object will be linked into > -- > 2.35.1.723.g4982287a31-goog >
Re: [PATCH 2/9] lib: crypt: Avoid redefining static_assert
On Wed, 16 Mar 2022 at 09:40, Pierre-Clément Tosi wrote:
>
> Use the macro introduced by commit ef0f4e834c66 ("build_bug.h: add
> wrapper for _Static_assert") by importing .
>
> Signed-off-by: Pierre-Clément Tosi
> Cc: Simon Glass
> Cc: Steffen Jaeckel
> ---
> lib/crypt/crypt-port.h | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
Reviewed-by: Simon Glass
Re: [PATCH 5/9] include: Import & Update bitops.h
On Wed, 16 Mar 2022 at 09:40, Pierre-Clément Tosi wrote: > > Import the header from version 5.16 of the kernel: > > commit df0cc57e057f18e44dac8e6c18aba47ab53202f9 > > Inline the included and prevent U-Boot from including > as BITS_PER_LONG is defined in . > > Remove now-duplicate definitions from . > > Note: This brings extra compile-time checks through GENMASK_INPUT_CHECK. > > Signed-off-by: Pierre-Clément Tosi > Cc: Simon Glass > Cc: Tom Rini > --- > include/linux/bitops.h | 27 ++--- > include/linux/bits.h | 55 ++ > 2 files changed, 62 insertions(+), 20 deletions(-) > create mode 100644 include/linux/bits.h > Reviewed-by: Simon Glass
Re: [PATCH 7/9] include: Upgrade
Hi,
On Wed, 16 Mar 2022 at 09:41, Pierre-Clément Tosi wrote:
>
> Upgrade the header to version 5.16 of the kernel:
>
> commit df0cc57e057f18e44dac8e6c18aba47ab53202f9
>
> Signed-off-by: Pierre-Clément Tosi
> Cc: Simon Glass
> Cc: Tom Rini
> ---
> include/linux/typecheck.h | 10 ++
> 1 file changed, 10 insertions(+)
Reviewed-by: Simon Glass
But I don't understand how this works at all. Could you add a comment?
>
> diff --git a/include/linux/typecheck.h b/include/linux/typecheck.h
> index eb5b74a575..46b15e2aae 100644
> --- a/include/linux/typecheck.h
> +++ b/include/linux/typecheck.h
> @@ -1,3 +1,4 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> #ifndef TYPECHECK_H_INCLUDED
> #define TYPECHECK_H_INCLUDED
>
> @@ -21,4 +22,13 @@
> (void)__tmp; \
> })
>
> +/*
> + * Check at compile time that something is a pointer type.
> + */
> +#define typecheck_pointer(x) \
> +({ typeof(x) __dummy; \
> + (void)sizeof(*__dummy); \
> + 1; \
> +})
> +
> #endif /* TYPECHECK_H_INCLUDED */
> --
> 2.35.1.723.g4982287a31-goog
>
Regards,
Simon
Re: [PATCH] test/py: efi_capsule: Handle expected reset after capsule on disk
Hi Masami, On Wed, 16 Mar 2022 at 00:09, Masami Hiramatsu wrote: > > Hi Simon, > > 2022年3月16日(水) 12:13 Simon Glass : > > > > Hi Masami, > > > > On Tue, 15 Mar 2022 at 02:36, Masami Hiramatsu > > wrote: > > > > > > Hi Simon, > > > > > > 2022年3月15日(火) 14:04 Simon Glass : > > > > > > > > Hi Masami, > > > > > > > > On Mon, 14 Mar 2022 at 18:40, Masami Hiramatsu > > > > wrote: > > > > > > > > > > Hi Simon, > > > > > > > > > > 2022年3月15日(火) 3:24 Simon Glass : > > > > > > > > > > > > > > OK, well 'reset by a user' presumably starts the board up and > > > > > > > > then > > > > > > > > runs some code to do the update in U-Boot? Is that right? If > > > > > > > > so, we > > > > > > > > just need to trigger that update from the test. We don't need > > > > > > > > to test > > > > > > > > the actual reset, at least not with sandbox. As I said, we need > > > > > > > > to > > > > > > > > write the code so that it is easy to test. > > > > > > > > > > > > > > Actually, we already have that command, "efidebug capsule > > > > > > > disk-update" > > > > > > > which kicks the capsule update code even without the 'reset by a > > > > > > > user'. So we can just kick this command for checking whether the > > > > > > > U-Boot UEFI code correctly find the capsule file from ESP which > > > > > > > specified by UEFI vars. > > > > > > > > > > > > > > However, the 'capsule update on-disk' feature is also expected > > > > > > > (and > > > > > > > defined in the spec?) to run when the UEFI subsystem is > > > > > > > initialized. > > > > > > > This behavior will not be tested if we skip the 'reset by a > > > > > > > user'. I > > > > > > > guess Takahiro's current test case tries to check it. > > > > > > > > > > > > The 'UEFI subsystem is intialised' is a problem, actually, since if > > > > > > it > > > > > > were better integrated into driver model, it would not have separate > > > > > > structures or they would be present and enabled when driver model > > > > > > is. > > > > > > I hope that it can be fixed and Takahiro's series is a start in that > > > > > > direction. > > > > > > > > > > OK. > > > > > > > > > > > But as to a test that an update is called when UEFI starts, that > > > > > > seems > > > > > > like a single line of code. Sure it is nice to test it, but it is > > > > > > much > > > > > > more important to test the installation of the update and the > > > > > > execution of the update. I suppose another way to test that is to > > > > > > shut down the UEFI subsystem and start it up? > > > > > > > > > > Yes, currently we call do_reset() after install the capsule file. > > > > > (This reset can be avoided if we replace it with > > > > > sysreset_walk_halt(SYSRESET_COLD) as you said, right?) > > > > > > > > > > Here is how I tested it on my machine; > > > > > > > > > > > usb start > > > > > > fatload usb 0 $kernel_addr_r test.cap > > > > > > fatwrite mmc 0 $fileaddr EFI/UpdateCapsule/test.cap $filesize > > > > > > efidebug capsule disk-update > > > > > (run install process and reboot the machine) > > > > > > > > > > So, if we can avoid the last reset, we can test the below without > > > > > reset on sandbox (depends on scenarios). > > > > > - confirm that the capsule update on disk can find the capsule file > > > > > from ESP specified by the BOOT EFI variable. > > > > > - confirm that the capsule update on disk writes the firmware > > > > > correctly to the storage which specified by DFU. > > > > > - confirm that the capsule update on disk success if the capsule image > > > > > type is supported. > > > > > - confirm that the capsule update on disk fails if the capsule image > > > > > type is not supported. > > > > > - confirm that the capsule update on disk will reboot after update > > > > > even if the update is failed. > > > > > > > > > > The only spec we can not test is > > > > > - confirm that the capsule update on disk is kicked when the UEFI is > > > > > initialized. > > > > > > > > Even that could be tested, by installing an update and then initing > > > > UEFI? > > > > > > yeah, if the UEFI is not initialized yet, we can run some UEFI related > > > command (e.g. printenv -e) instead of efidebug capsule... to execute > > > the capsule update on disk. > > > But anyway, this is only available at the first time. We need a way to > > > reset UEFI subsystem without system reset. > > > > Yes. It is certainly possible, but I'm not sure how easy it is. > > Perhaps just drop all the EFI data structures and run the EFI init > > again? We have something similar with driver model. See > > dm_test_pre_run() > > EFI has the ExitBootServices call, but I'm not sure it is actually > clear all resources. Maybe we need to check what resources are > released by the ExitBootServices. > > > > > > > > > > > > > Anyway we should design subsystems so they are easy to test. > > > > > > > > > > Here I guess you mean the unit test, not system test, am I correct? > > > > > > > > Yes. Easy testing is so important for developer
Re: [PATCH v2] efi_loader: Use sysreset instead of reset command
On Wed, 16 Mar 2022 at 06:35, Heinrich Schuchardt wrote:
>
> On 3/16/22 09:03, Masami Hiramatsu wrote:
> > Use sysreset_walk_halt() directly from reset-after-capsule-on-disk
> > feature to reboot (cold reset) machine instead of using reset command
> > interface, since this is not a command.
> > Note that this will make CONFIG_EFI_CAPSULE_ON_DISK depending on
> > the CONFIG_SYSRESET.
> >
> > Signed-off-by: Masami Hiramatsu
>
> Reviewed-by: Heinrich Schuchardt
>
> > ---
> > Changes in v2:
> >- Add CONFIG_SYSRESET dependency.
> >- Fix to add #include
> > ---
> > lib/efi_loader/Kconfig |1 +
> > lib/efi_loader/efi_capsule.c |5 +++--
> > 2 files changed, 4 insertions(+), 2 deletions(-)
Reviewed-by: Simon Glass
> >
> > diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
> > index e5e35fe51f..33138237cc 100644
> > --- a/lib/efi_loader/Kconfig
> > +++ b/lib/efi_loader/Kconfig
> > @@ -130,6 +130,7 @@ config EFI_RUNTIME_UPDATE_CAPSULE
> >
> > config EFI_CAPSULE_ON_DISK
> > bool "Enable capsule-on-disk support"
> > + depends on SYSRESET
> > select EFI_HAVE_CAPSULE_SUPPORT
> > help
> > Select this option if you want to use capsule-on-disk feature,
> > diff --git a/lib/efi_loader/efi_capsule.c b/lib/efi_loader/efi_capsule.c
> > index 613b531b82..a3d1d7e95a 100644
> > --- a/lib/efi_loader/efi_capsule.c
> > +++ b/lib/efi_loader/efi_capsule.c
> > @@ -18,6 +18,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> >
> > #include
> > @@ -1150,9 +1151,9 @@ efi_status_t efi_launch_capsules(void)
> >* UEFI spec requires to reset system after complete processing
> > capsule
> >* update on the storage.
> >*/
> > - log_info("Reboot after firmware update");
> > + log_info("Reboot after firmware update.\n");
> > /* Cold reset is required for loading the new firmware. */
> > - do_reset(NULL, 0, 0, NULL);
> > + sysreset_walk_halt(SYSRESET_COLD);
> > hang();
> > /* not reach here */
> >
> >
>
Re: [PATCH v2 4/9] arm: imx: imx8mm: add enable_pwm_clk function
Hi Tommaaso
On Wed, Mar 16, 2022 at 4:28 PM Tommaso Merciai
wrote:
>
> Add function enable_pwm_clk into in clock_imx8mm.c. This
> function first configure, then enable pwm clock from clock control
> register. The following configuration is used:
>
> source(0) -> 24 MHz ref clock
> div(0)-> no division for this clock
>
> References:
> - iMX8MMRM.pdf p 303
>
> Signed-off-by: Tommaso Merciai
> ---
> Changes since v1:
> - Fix enable_pwm_clk function implementation. Now is generic for all pwm clks
>
> arch/arm/mach-imx/imx8m/clock_imx8mm.c | 53 ++
> 1 file changed, 53 insertions(+)
>
> diff --git a/arch/arm/mach-imx/imx8m/clock_imx8mm.c
> b/arch/arm/mach-imx/imx8m/clock_imx8mm.c
> index 49945faf2c..ffb9456607 100644
> --- a/arch/arm/mach-imx/imx8m/clock_imx8mm.c
> +++ b/arch/arm/mach-imx/imx8m/clock_imx8mm.c
> @@ -313,6 +313,59 @@ void enable_usboh3_clk(unsigned int enable)
> }
> }
>
> +void enable_pwm_clk(u32 index, unsigned char enable)
> +{
> + switch (index) {
> + case 0:
> + if (enable) {
> + clock_enable(CCGR_PWM1, false);
> + clock_set_target_val(PWM1_CLK_ROOT, CLK_ROOT_ON |
> + CLK_ROOT_SOURCE_SEL(0) |
> +
> CLK_ROOT_PRE_DIV(CLK_ROOT_PRE_DIV1));
> + clock_enable(CCGR_PWM1, true);
> + } else {
> + clock_enable(CCGR_PWM1, false);
Pwm is alway before set to false and then enable. Make sense to move
out. Then all the code is look quite the same apart
minior change
Can you clean up in order to have a more compact implementation?
Michael
> + }
> + return;
> + case 1:
> + if (enable) {
> + clock_enable(CCGR_PWM2, false);
> + clock_set_target_val(PWM2_CLK_ROOT, CLK_ROOT_ON |
> + CLK_ROOT_SOURCE_SEL(0) |
> +
> CLK_ROOT_PRE_DIV(CLK_ROOT_PRE_DIV1));
> + clock_enable(CCGR_PWM2, true);
> + } else {
> + clock_enable(CCGR_PWM2, false);
> + }
> + return;
> + case 2:
> + if (enable) {
> + clock_enable(CCGR_PWM3, false);
> + clock_set_target_val(PWM3_CLK_ROOT, CLK_ROOT_ON |
> + CLK_ROOT_SOURCE_SEL(0) |
> +
> CLK_ROOT_PRE_DIV(CLK_ROOT_PRE_DIV1));
> + clock_enable(CCGR_PWM3, true);
> + } else {
> + clock_enable(CCGR_PWM3, false);
> + }
> + return;
> + case 3:
> + if (enable) {
> + clock_enable(CCGR_PWM4, false);
> + clock_set_target_val(PWM4_CLK_ROOT, CLK_ROOT_ON |
> + CLK_ROOT_SOURCE_SEL(0) |
> +
> CLK_ROOT_PRE_DIV(CLK_ROOT_PRE_DIV1));
> + clock_enable(CCGR_PWM4, true);
> + } else {
> + clock_enable(CCGR_PWM4, false);
> + }
> + return;
> + default:
> + printf("Invalid pwm index\n");
> + return;
> + }
> +}
> +
Please factorize things that are always eegual
> void init_uart_clk(u32 index)
> {
> /*
> --
> 2.25.1
>
--
Michael Nazzareno Trimarchi
Co-Founder & Chief Executive Officer
M. +39 347 913 2170
mich...@amarulasolutions.com
__
Amarula Solutions BV
Joop Geesinkweg 125, 1114 AB, Amsterdam, NL
T. +31 (0)85 111 9172
i...@amarulasolutions.com
www.amarulasolutions.com
[PATCH] boot: image: fixup zstd decompression buffer initialization typo
Fixes: 458b30af66cd41ca8e6f8a52ea4c09cb50d3413d
Cc: Simon Glass
---
boot/image.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/boot/image.c b/boot/image.c
index 07fa2d3160..121df0c838 100644
--- a/boot/image.c
+++ b/boot/image.c
@@ -500,7 +500,7 @@ int image_decomp(int comp, ulong load, ulong image_start,
int type,
struct abuf in, out;
abuf_init_set(, image_buf, image_len);
- abuf_init_set(, load_buf, unc_len);
+ abuf_init_set(, load_buf, unc_len);
ret = zstd_decompress(, );
if (ret >= 0) {
image_len = ret;
--
2.35.1
Re: [PATCH 1/2] sunxi: Fix old GMAC pinmux setup
On Wed, 16 Mar 2022 17:55:16 +0100
Jernej Škrabec wrote:
> Dne sreda, 16. marec 2022 ob 01:54:42 CET je Andre Przywara napisal(a):
> > Commit 5bc4cd05d7d4 ("sunxi: move non-essential code out of s_init()")
> > moved the call to eth_init_board() from s_init() into board_init_f().
> > This means it's now only called from the SPL, which makes sense for
> > most of the other moved low-level functions. However the GMAC pinmux and
> > clock setup in eth_init_board() was not happy about that, so it broke
> > the sun7i GMAC.
> >
> > Since Ethernet is of no use in the SPL anyway, just move the call into
> > board_init(), which is only run in U-Boot proper.
> >
> > This fixes Ethernet operation for the A20 SoCs, which broke in
> > v2022.04-rc1, with the above mentioned commit.
> >
> > Signed-off-by: Andre Przywara
>
> Reviewed-by: Jernej Skrabec
Thanks!
> I guess this function will soon go away with introduction of clock and
> pinctrl
> driver.
Yes, indeed, forgot to mention this. This is just a stop-gap measure to
fix Ethernet before the 2022.04 release.
Cheers,
Andre
>
> Best regards,
> Jernej
>
> > ---
> > arch/arm/mach-sunxi/board.c | 1 -
> > board/sunxi/board.c | 3 +++
> > 2 files changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/mach-sunxi/board.c b/arch/arm/mach-sunxi/board.c
> > index 0071de19ffd..9a7673d82dc 100644
> > --- a/arch/arm/mach-sunxi/board.c
> > +++ b/arch/arm/mach-sunxi/board.c
> > @@ -333,7 +333,6 @@ void board_init_f(ulong dummy)
> > clock_init();
> > timer_init();
> > gpio_init();
> > - eth_init_board();
> >
> > spl_init();
> > preloader_console_init();
> > diff --git a/board/sunxi/board.c b/board/sunxi/board.c
> > index a0961590479..28f702bc296 100644
> > --- a/board/sunxi/board.c
> > +++ b/board/sunxi/board.c
> > @@ -30,6 +30,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -308,6 +309,8 @@ int board_init(void)
> > #endif
> > #endif /* CONFIG_DM_MMC */
> >
> > + eth_init_board();
> > +
> > return 0;
> > }
> >
> > --
> > 2.35.1
> >
> >
>
>
Re: [PATCH 1/2] sunxi: Fix old GMAC pinmux setup
Dne sreda, 16. marec 2022 ob 01:54:42 CET je Andre Przywara napisal(a):
> Commit 5bc4cd05d7d4 ("sunxi: move non-essential code out of s_init()")
> moved the call to eth_init_board() from s_init() into board_init_f().
> This means it's now only called from the SPL, which makes sense for
> most of the other moved low-level functions. However the GMAC pinmux and
> clock setup in eth_init_board() was not happy about that, so it broke
> the sun7i GMAC.
>
> Since Ethernet is of no use in the SPL anyway, just move the call into
> board_init(), which is only run in U-Boot proper.
>
> This fixes Ethernet operation for the A20 SoCs, which broke in
> v2022.04-rc1, with the above mentioned commit.
>
> Signed-off-by: Andre Przywara
Reviewed-by: Jernej Skrabec
I guess this function will soon go away with introduction of clock and pinctrl
driver.
Best regards,
Jernej
> ---
> arch/arm/mach-sunxi/board.c | 1 -
> board/sunxi/board.c | 3 +++
> 2 files changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-sunxi/board.c b/arch/arm/mach-sunxi/board.c
> index 0071de19ffd..9a7673d82dc 100644
> --- a/arch/arm/mach-sunxi/board.c
> +++ b/arch/arm/mach-sunxi/board.c
> @@ -333,7 +333,6 @@ void board_init_f(ulong dummy)
> clock_init();
> timer_init();
> gpio_init();
> - eth_init_board();
>
> spl_init();
> preloader_console_init();
> diff --git a/board/sunxi/board.c b/board/sunxi/board.c
> index a0961590479..28f702bc296 100644
> --- a/board/sunxi/board.c
> +++ b/board/sunxi/board.c
> @@ -30,6 +30,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -308,6 +309,8 @@ int board_init(void)
> #endif
> #endif /* CONFIG_DM_MMC */
>
> + eth_init_board();
> +
> return 0;
> }
>
> --
> 2.35.1
>
>
[GIT PULL] xilinx patches for v2022.07-rc1
Hi Tom, please pull these patches to your next branch. CI doesn't show any issue. https://source.denx.de/u-boot/custodians/u-boot-microblaze/-/pipelines/11311 There are couple of enhancements but also new pinctrl driver for supporting Xilinx SOM. Thanks, Michal The following changes since commit 6d3c46ed0e230d999c3f20f7fd4f3a88c03b14ca: Merge https://source.denx.de/u-boot/custodians/u-boot-sunxi (2022-03-05 20:46:55 -0500) are available in the Git repository at: g...@source.denx.de:u-boot/custodians/u-boot-microblaze.git tags/xilinx-for-v2022.07-rc1 for you to fetch changes up to 0ac03fbab51c72fa978569a831c001c4ddad8e2a: arm64: zynqmp: Add pinctrl emmc description to SM-K26 (2022-03-16 16:14:34 +0100) Xilinx changes for v2022.07-rc1 microblaze: - Add support for reserved memory xilinx: - Update FRU code with MAC reading zynqmp: - Remove double AMS setting - DT updates (mostly for SOMs) - Add support for zcu106 rev 1.0 zynq: - Update nand binding nand: - Aligned zynq_nand to upstream DT binding net: - Add support for ethernet-phy-id mmc: - Workaround CD in zynq_sdhci driver also for ZynqMP - Add support for dynamic/run-time SD config for SOMs gpio: - Add driver for slg7xl45106 firmware: - Add support for dynamic SD config power-domain: - Update zynqmp driver with the latest firmware video: - Add skeleton driver for DP and DPDMA i2c: - Fix i2c to work with QEMU pinctrl: - Add driver for zynqmp pinctrl driver Ashok Reddy Soma (14): fru: ops: Clear fru table before storing data fru: ops: Return error from checksum if data is all zero's xilinx: common: Optimise updating ethaddr from eeprom fru: ops: Add support to read mac addresses from multirecord dm: pinctrl: Use explicit values for enums mmc: zynq_sdhci: Fix timeout issue mmc: zynq_sdhci: Change granularity of timeout to 1us mmc: zynq_sdhci: Enable card detect workaround for ZynqMP firmware: zynqmp: Add and update firmware enums firmware: zynqmp: Add support for set sd config and is function supported lib: div64: Add support for round up of div64_u64 mmc: zynq_sdhci: Add support for dynamic configuration pinctrl: Increase length of pinmux status buffer pinctrl: zynqmp: Add pinctrl driver Michael Walle (1): ARM: dts: zynq: add NAND flash controller node Michal Simek (18): mtd: nand: Update driver to match new DT binding power: zynqmp: Use zynqmp_pmufw_node() from firmware microblaze: Do not place u-boot to reserved memory location arm64: zynqmp: Move usb hub from i2c to usb node arm64: zynqmp: Setup clock for DP and DPDMA arm64: zynqmp: Use assigned-clock-rates for setting up clock in SOM arm64: zynqmp: Switch to ethernet-phy-id in kv260 arm64: zynqmp: Enable DP driver for SOMs arm64: zynqmp: Fix level of gpio reset for usb on kv260 boards video: Add skeleton driver for ZynqMP Display port driver dma: xilinx: Add Display Port DMA driver MAINTAINERS: Remove duplicated entry for ehci-zynq.c net: phy: Add new read ethernet phy id function net: phy: Remove static return type for phy_device_create() net: phy: Add support for ethernet-phy-id with gpio reset cmd: test: pinmux: Do not check all empty spaces arm64: zynqmp: Fix i2c addresses for zynqmp-p-a2197 arm64: zynqmp: Add pinctrl emmc description to SM-K26 Neal Frager (1): arm64: zynqmp: add support for zcu106 rev1.0 Sai Pavan Boddu (3): i2c: i2c-cdns: Start read transaction after write to transfer_size reg i2c: i2c-cdns: Fix write transaction state i2c: i2c-cdns: Prevent early termination of write T Karthik Reddy (2): Revert "board: zynqmp: Fix for wrong AMS setting by ROM" gpio: slg7xl45106: Add support for slg7xl45106 i2c gpo expander MAINTAINERS | 4 +- arch/arm/dts/Makefile | 1 + arch/arm/dts/bitmain-antminer-s9.dts| 2 +- arch/arm/dts/zynq-7000.dtsi | 57 +- arch/arm/dts/zynq-zc770-xm011.dts | 2 +- arch/arm/dts/zynqmp-clk-ccf.dtsi| 8 + arch/arm/dts/zynqmp-p-a2197-00-revA.dts | 8 +- arch/arm/dts/zynqmp-sck-kv-g-revA.dts | 12 +- arch/arm/dts/zynqmp-sck-kv-g-revB.dts | 26 +- arch/arm/dts/zynqmp-sm-k26-revA.dts | 25 + arch/arm/dts/zynqmp-zcu106-rev1.0.dts | 16 + arch/microblaze/include/asm/system.h| 2 + board/xilinx/common/board.c | 11 +- board/xilinx/common/fru.h | 21 + board/xilinx/common/fru_ops.c | 49 +-
Re: GPMI NAND Regression on i.MX6S
On Wed, Mar 16, 2022 at 7:09 AM Fabio Estevam wrote: > > Adding Han Xu's NXP email on Cc. > > On Mon, Mar 14, 2022 at 10:31 AM Frieder Schrempf > wrote: > > > > Hello everyone, > > > > sorry to dig out an old thread, but the below patch which was applied > > upstream as 616f03dabacb causes a regression for me when trying to > > attach an UBI volume with U-Boot 2022.01 on a board with i.MX6 Solo and > > AMD/Spansion parallel NAND. > > > > The failure looks like this: > > > > ubi0: attaching mtd2 > > ubi0 error: ubi_io_read: error -74 (ECC error) while reading 64 bytes > > from PEB 0:0, read 64 bytes > > ubi0 error: ubi_io_read: error -74 (ECC error) while reading 2048 bytes > > from PEB 0:2048, read 2048 bytes > > ubi0 error: ubi_io_read: error -74 (ECC error) while reading 64 bytes > > from PEB 1:0, read 64 bytes > > ubi0 error: ubi_io_read: error -74 (ECC error) while reading 2048 bytes > > from PEB 1:2048, read 2048 bytes > > > > The NAND as reported by Linux is: > > > > nand: device found, Manufacturer ID: 0x01, Chip ID: 0xdc > > nand: AMD/Spansion S34ML04G1 > > nand: 512 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64 > > > > A different revision of the same board with a different NAND from > > manufacturer ESMT doesn't show the issue: > > > > nand: device found, Manufacturer ID: 0xc8, Chip ID: 0xdc > > nand: ESMT NAND 512MiB 3,3V 8-bit > > nand: 512 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64 > > > > When I revert the mentioned commit (see patch here: [1]), the UBI boot > > starts working again. > > > > Does anyone know what the problem is and how to properly solve it? > > > > Thanks for any help! > > Frieder > > > > [1] > > https://zerobin.net/?57a57a322bbdcf3c#rZa3vHlWi+RxtRomoljtrngqWwiv6v4Js/2LNfdV10o= > > Frieder, I see the same issue here with IMX6Q/DL GPMI NAND. If I re-flash the ubi within U-Boot (tftpboot $loadaddr rootfs.ubi && nand erase.part rootfs && nand write $loadaddr rootfs $filesize) I find that U-Boot can attach and mount the ubi fine but Linux will have issues Ventana > ubi part rootfs ubi0: attaching mtd3 ubi0: scanning is finished ubi0: attached mtd3 (name "rootfs", size 2031 MiB) ubi0: PEB size: 262144 bytes (256 KiB), LEB size: 253952 bytes ubi0: min./max. I/O unit sizes: 4096/4096, sub-page size 4096 ubi0: VID header offset: 4096 (aligned 4096), data offset: 8192 ubi0: good PEBs: 8123, bad PEBs: 1, corrupted PEBs: 0 ubi0: user volume: 3, internal volumes: 1, max. volumes count: 128 ubi0: max/mean erase counter: 1/0, WL threshold: 4096, image sequence number: 1632759352 ubi0: available PEBs: 0, total reserved PEBs: 8123, PEBs reserved for bad PEB handling: 159 Ventana > ubifsmount ubi0:boot Ventana > ubifsls 38158 Mon Sep 27 17:18:10 2021 gateworks-imx6-imx6q-gw5400-a.dtb 41659 Mon Sep 27 17:18:07 2021 gateworks-imx6-imx6dl-gw53xx.dtb 42964 Mon Sep 27 17:18:10 2021 gateworks-imx6-imx6q-gw53xx.dtb ... [2.065328] ubi0: attaching mtd2 [2.092015] ubi0 warning: ubi_io_read: error -74 (ECC error) while reading 253952 bytes from PEB 11:8192, read only 253952 bytes, retry [2.096132] mmc0: host does not support reading read-only switch, assuming write-enable [2.119427] mmc0: new high speed SDHC card at address 0007 [2.126035] mmcblk0: mmc0:0007 SD32G 29.9 GiB [2.130221] ubi0 warning: ubi_io_read: error -74 (ECC error) while reading 253952 bytes from PEB 11:8192, read only 253952 bytes, retry [2.131746] mmcblk0: p1 [2.164579] ubi0 warning: ubi_io_read: error -74 (ECC error) while reading 253952 bytes from PEB 11:8192, read only 253952 bytes, retry [2.197969] ubi0 error: ubi_io_read: error -74 (ECC error) while reading 253952 bytes from PEB 11:8192, read 253952 bytes Best regards, Tim > > Am 04.05.20 um 16:08 schrieb Peng Fan: > > > From: Ye Li > > > > > > The code change updated the NAND driver BCH ECC layout algorithm to > > > support large oob size NAND chips(oob > 1024 bytes) and proposed a new > > > way to set ECC layout. > > > > > > Current implementation requires each chunk size larger than oob size so > > > the bad block marker (BBM) can be guaranteed located in data chunk. The > > > ECC layout always using the unbalanced layout(Ecc for both meta and > > > Data0 chunk), but for the NAND chips with oob larger than 1k, the driver > > > cannot support because BCH doesn’t support GF 15 for 2K chunk. > > > > > > The change keeps the data chunk no larger than 1k and adjust the ECC > > > strength or ECC layout to locate the BBM in data chunk. General idea for > > > large oob NAND chips is > > > > > > 1.Try all ECC strength from the minimum value required by NAND spec to > > > the maximum one that works, any ECC makes the BBM locate in data chunk > > > can be chosen. > > > > > > 2.If none of them works, using separate ECC for meta, which will add one > > > extra ecc with the same ECC strength as other data chunks. This extra > > > ECC can guarantee BBM located in data
Re: [PATCH v4 2/4] clk: imx8mq: Add a clock driver for the imx8mq
Am 2022-03-16 17:00, schrieb Angus Ainslie: Hi Heiko, On 2022-03-16 08:55, Heiko Thiery wrote: Hi Angus, [snip] > > But then something went wrong when probing uart3 ... the baudrate > > switched for the uart2 (console) and the serial output became broken. > > Later when the kernel starts the output becomes correct again. So the > > kernel seems to configure it correctly. > > > > see here: https://pastebin.com/raw/qXVShb3Q > > > > When I remove the "assigned-clock-parents = < > > IMX8MQ_SYS1_PLL_80M>;" for uart3 the output of uart2 (console) keeps > > ok. > > If that "fixes" it then it means that the parent IMX8MQ_SYS1_PLL_80M > clock rate is getting changed by the uart3 stanza. > > Are you using the mainline devicetree file for your board ? If not could > you provide a link ? I use the mainline u-boot/linux one. We (thanks to Michael) found the issue. For the imx8mq the imx_get_uartclk() returns always the values for UART1_CLK_ROOT [1]. This is wrong. Here we have to get the value dependent on the used UART. [1] https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/mach-imx/imx8m/clock_imx8mq.c#L381 Yeah that driver could do with an overhaul as it also does that for the ECSPI clocks which can also break things. IMHO the imx serial driver should get its clock from the device tree. Not sure about the debug serial part though. -michael
Re: [PATCH 1/7] clk: Make rfree return void
On 3/1/22 9:58 AM, Simon Glass wrote: Hi Sean, On Sun, 27 Feb 2022 at 12:38, Sean Anderson wrote: On 2/26/22 1:36 PM, Simon Glass wrote: Hi Sean, On Tue, 1 Feb 2022 at 21:24, Sean Anderson wrote: On 2/1/22 10:59 PM, Simon Glass wrote: Hi Sean, On Tue, 1 Feb 2022 at 07:49, Sean Anderson wrote: On 1/27/22 4:35 PM, Simon Glass wrote: Hi Sean, On Thu, 27 Jan 2022 at 08:43, Sean Anderson wrote: On 1/27/22 10:05 AM, Simon Glass wrote: Hi Sean, On Sat, 15 Jan 2022 at 15:25, Sean Anderson wrote: When freeing a clock there is not much we can do if there is an error, and most callers do not actually check the return value. Even e.g. checking to make sure that clk->id is valid should have been done in request() in the first place (unless someone is messing with the driver behind our back). Just return void and don't bother returning an error. Signed-off-by: Sean Anderson --- drivers/clk/clk-uclass.c | 7 +++ drivers/clk/clk_sandbox.c | 6 +++--- include/clk-uclass.h | 8 +++- 3 files changed, 9 insertions(+), 12 deletions(-) We have the same thing in other places too, but I am a little worried about removing error checking. We try to avoid checking arguments too much in U-Boot, due to code-size concerns, so I suppose I agree that an invalid clk should be caught by a debug assertion rather than a full check. But with driver model we have generally added an error return to every uclass method, for consistency and to permit returning error information if needed. Regards, Simon So there are a few reasons why I don't think a return value is useful here. To illustrate this, consider a typical user of the clock API: struct clk a, b; ret = clk_get_by_name(dev, "a", ); if (ret) return ret; ret = clk_get_by_name(dev, "b", ); if (ret) goto free_a; ret = clk_set_rate(, 500); if (ret) goto free_b; ret = clk_enable(); free_b: clk_free(); free_a: clk_free(); return ret; - Because a and b are "thick pointers" they do not need any cleanup to free their own resources. The only cleanup might be if the clock driver has allocated something in clk_request (more on this below) - By the time we call clk_free, the mutable portions of the function have already completed. In effect, the function has succeeded, regardless of whether clk_free fails. Additionally, we cannot take any action if it fails, since we still have to free both clocks. - clk_free occurs during the error path of the function. Even if it errored, we do not want to override the existing error from one of the functions doing "real" work. The last thing is that no clock driver actually does anything in rfree. The only driver with this function is the sandbox driver. I would like to remove the function altogether. As I understand it, the existing API is inspired by the reset drivers, so I would like to review its usage in the reset subsystem before removing it for the clock subsystem. I also want to make some changes to how rates and enables/disables are calculated which might provide a case for rfree. But once that is complete I think there will be no users still. What does this all look like in Linux? Their equivalent (clk_put) returns void, and generally so do most other cleanup functions, since .device_remove also returns void. We really cannot ignore errors from device_remove(). Once you are at device_remove, all the users are gone and it's up to the device to clean up after itself. And often there is nothing we can do once remove is called. As you yourself say in device_remove, /* We can't put the children back */ Well this assumes that device_remove() is actually removing the device, not just disabling DMA, etc. Really the only sensible thing is to print an error and continue booting if possible. And of course no clock drivers actually use this function anyway, nor do (all but 5) users check it. Anyway I think what you say about the 'thick pointer' makes sense. But my expectation was that removing a clock might turn off a clock above it in the tree, for example. No, this just frees resources (as is documented). If you want to turn off a clock, you have to call clk_disable. In fact, a very common use case is just like the example above, where the consmer frees the clock after enabling it. (This is also why clk->enable_count/rate are basically useless for anything other than CCF clocks) How about a clock provided by an audio codec on an I2C bus? Should clk_free() do anything in that case? I assume not. I think the compelling part of your argument is that it is a 'think pointer' and disable does nothing. So can you update clk_rfree() etc. to document what is allowed to be done in that function? The ideal case would be if
Re: [PATCH v2 5/5] clk: scmi: register scmi clocks with CCF
On 3/7/22 5:17 AM, Etienne Carriere wrote:
Hello Sean,
Thanks for the feedback.
Sorry I missed your post end Feb.
On Fri, 25 Feb 2022 at 07:33, Sean Anderson wrote:
Hi Etienne,
On 2/21/22 3:22 AM, Etienne Carriere wrote:
Implements SCMI APIs to retrieve the number exposed SCMI clocks using
SCMI_PROTOCOL_ATTRIBUTES messages and the names of the clocks using
SCMI_CLOCK_ATTRIBUTES messages.
This change updates sandbox SCMI clock test driver to manage these
2 new message IDs.
Cc: Lukasz Majewski
Cc: Sean Anderson
Cc: Clement Leger
Cc: Patrick Delaunay
Reviewed-by: Patrick Delaunay
Signed-off-by: Gabriel Fernandez
Signed-off-by: Etienne Carriere
---
Changes since v1:
- Remove Series-links tag and apply R-b tag.
---
drivers/clk/clk_scmi.c | 90 ++
drivers/firmware/scmi/sandbox-scmi_agent.c | 53 +
include/scmi_protocols.h | 43 +++
3 files changed, 186 insertions(+)
diff --git a/drivers/clk/clk_scmi.c b/drivers/clk/clk_scmi.c
index 42fbab0d21..57022685e2 100644
--- a/drivers/clk/clk_scmi.c
+++ b/drivers/clk/clk_scmi.c
@@ -11,6 +11,52 @@
#include
#include
#include
+#include
+
+static int scmi_clk_get_num_clock(struct udevice *dev, size_t *num_clocks)
+{
+ struct scmi_clk_protocol_attr_out out;
+ struct scmi_msg msg = {
+ .protocol_id = SCMI_PROTOCOL_ID_CLOCK,
+ .message_id = SCMI_PROTOCOL_ATTRIBUTES,
+ .out_msg = (u8 *),
+ .out_msg_sz = sizeof(out),
+ };
+ int ret;
+
+ ret = devm_scmi_process_msg(dev, );
+ if (ret)
+ return ret;
+
+ *num_clocks = out.attributes & SCMI_CLK_PROTO_ATTR_COUNT_MASK;
+
+ return 0;
+}
+
+static int scmi_clk_get_attibute(struct udevice *dev, int clkid, char **name)
nit: scmi_clk_get_attribute
right!
+{
+ struct scmi_clk_attribute_in in = {
+ .clock_id = clkid,
+ };
+ struct scmi_clk_attribute_out out;
+ struct scmi_msg msg = {
+ .protocol_id = SCMI_PROTOCOL_ID_CLOCK,
+ .message_id = SCMI_CLOCK_ATTRIBUTES,
+ .in_msg = (u8 *),
+ .in_msg_sz = sizeof(in),
+ .out_msg = (u8 *),
+ .out_msg_sz = sizeof(out),
+ };
+ int ret;
+
+ ret = devm_scmi_process_msg(dev, );
+ if (ret)
+ return ret;
+
+ *name = out.clock_name;
+
+ return 0;
+}
static int scmi_clk_gate(struct clk *clk, int enable)
{
@@ -88,6 +134,49 @@ static ulong scmi_clk_set_rate(struct clk *clk, ulong rate)
return scmi_clk_get_rate(clk);
}
+static int scmi_clk_probe(struct udevice *dev)
+{
+ struct clk *clk;
+ size_t num_clocks, i;
+ int ret;
+
+ if (!CONFIG_IS_ENABLED(CLK_CCF))
+ return 0;
+
+ /* register CCF children: CLK UCLASS, no probed again */
+ if (device_get_uclass_id(dev->parent) == UCLASS_CLK)
+ return 0;
+
+ ret = scmi_clk_get_num_clock(dev, _clocks);
+ if (ret)
+ return ret;
+
+ for (i = 0; i < num_clocks; i++) {
+ char *name;
+
+ if (!scmi_clk_get_attibute(dev, i, )) {
+ char *clock_name = strdup(name);
+
+ clk = kzalloc(sizeof(*clk), GFP_KERNEL);
+ if (!clk || !clock_name)
+ ret = -ENOMEM;
+ else
+ ret = clk_register(clk, dev->driver->name,
+clock_name, dev->name);
+
+ if (ret) {
+ free(clk);
+ free(clock_name);
+ return ret;
+ }
+
+ clk_dm(i, clk);
+ }
+ }
+
+ return 0;
+}
+
So why not call scmi_clk_get_num_clock during probe() and then check against
it in xlate? I don't really see why we need CCF. This also means you don't
have a driver with copies of itself as children, and is lighter on memory.
There is no specific need for CCF for the scmi clock driver itself.
The goal of these changes is rather to allow platforms that do already
enable CCF (for an u-boot native clock driver)
to be able to also embed SCMI clocks support, for clocks controlled
from an external firmware.
Sure, but you can still use non-CCF clocks in a CCF clock.
--Sean
Re: [PATCH v2] efi_loader: Set variable attributes when EFI_BUFFER_TOO_SMALL is returned
On 3/16/22 16:13, Ilias Apalodimas wrote:
Starting UEFI Spec 2.8 we must fill in the variable attributes when
GetVariable() returns EFI_BUFFER_TOO_SMALL and Attributes is non-NULL.
This code was written with 2.7 in mind so let's move the code around a
bit and fill in the attributes EFI_BUFFER_TOO_SMALL is returned
Signed-off-by: Ilias Apalodimas
Reviewed-by: Heinrich Schuchardt
---
Changes since v1:
- tmp variables switched to efi_status_t instead of int
- switched (ret == EFI_SUCCESS || ret == EFI_BUFFER_TOO_SMALL)
to (ret != EFI_SUCCESS && ret != EFI_BUFFER_TOO_SMALL) to
make the code easier to read
- Only call get_property_int() if attributes != NULL
lib/efi_loader/efi_variable_tee.c | 31 ---
1 file changed, 20 insertions(+), 11 deletions(-)
diff --git a/lib/efi_loader/efi_variable_tee.c
b/lib/efi_loader/efi_variable_tee.c
index 58931c4efd74..dfef18435dfa 100644
--- a/lib/efi_loader/efi_variable_tee.c
+++ b/lib/efi_loader/efi_variable_tee.c
@@ -368,7 +368,7 @@ efi_status_t efi_get_variable_int(const u16 *variable_name,
efi_uintn_t name_size;
efi_uintn_t tmp_dsize;
u8 *comm_buf = NULL;
- efi_status_t ret;
+ efi_status_t ret, tmp;
if (!variable_name || !vendor || !data_size) {
ret = EFI_INVALID_PARAMETER;
@@ -407,23 +407,32 @@ efi_status_t efi_get_variable_int(const u16
*variable_name,
/* Communicate */
ret = mm_communicate(comm_buf, payload_size);
- if (ret == EFI_SUCCESS || ret == EFI_BUFFER_TOO_SMALL) {
- /* Update with reported data size for trimmed case */
- *data_size = var_acc->data_size;
- }
- if (ret != EFI_SUCCESS)
- goto out;
-
- ret = get_property_int(variable_name, name_size, vendor, _property);
- if (ret != EFI_SUCCESS)
+ if (ret != EFI_SUCCESS && ret != EFI_BUFFER_TOO_SMALL)
goto out;
+ /* Update with reported data size for trimmed case */
+ *data_size = var_acc->data_size;
+ /*
+* UEFI > 2.7 needs the attributes set even if the buffer is
+* smaller
+*/
if (attributes) {
+ tmp = get_property_int(variable_name, name_size, vendor,
+ _property);
+ if (tmp != EFI_SUCCESS) {
+ ret = tmp;
+ goto out;
+ }
*attributes = var_acc->attr;
- if (var_property.property &
VAR_CHECK_VARIABLE_PROPERTY_READ_ONLY)
+ if (var_property.property &
+ VAR_CHECK_VARIABLE_PROPERTY_READ_ONLY)
*attributes |= EFI_VARIABLE_READ_ONLY;
}
+ /* return if ret is EFI_BUFFER_TOO_SMALL */
+ if (ret != EFI_SUCCESS)
+ goto out;
+
if (data)
memcpy(data, (u8 *)var_acc->name + var_acc->name_size,
var_acc->data_size);
Re: [PATCH v4 2/4] clk: imx8mq: Add a clock driver for the imx8mq
Hi Heiko, On 2022-03-16 08:55, Heiko Thiery wrote: Hi Angus, [snip] > > But then something went wrong when probing uart3 ... the baudrate > > switched for the uart2 (console) and the serial output became broken. > > Later when the kernel starts the output becomes correct again. So the > > kernel seems to configure it correctly. > > > > see here: https://pastebin.com/raw/qXVShb3Q > > > > When I remove the "assigned-clock-parents = < > > IMX8MQ_SYS1_PLL_80M>;" for uart3 the output of uart2 (console) keeps > > ok. > > If that "fixes" it then it means that the parent IMX8MQ_SYS1_PLL_80M > clock rate is getting changed by the uart3 stanza. > > Are you using the mainline devicetree file for your board ? If not could > you provide a link ? I use the mainline u-boot/linux one. We (thanks to Michael) found the issue. For the imx8mq the imx_get_uartclk() returns always the values for UART1_CLK_ROOT [1]. This is wrong. Here we have to get the value dependent on the used UART. [1] https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/mach-imx/imx8m/clock_imx8mq.c#L381 Yeah that driver could do with an overhaul as it also does that for the ECSPI clocks which can also break things. Angus
Re: [PATCH v4 2/4] clk: imx8mq: Add a clock driver for the imx8mq
Hi Angus, [snip] > > > But then something went wrong when probing uart3 ... the baudrate > > > switched for the uart2 (console) and the serial output became broken. > > > Later when the kernel starts the output becomes correct again. So the > > > kernel seems to configure it correctly. > > > > > > see here: https://pastebin.com/raw/qXVShb3Q > > > > > > When I remove the "assigned-clock-parents = < > > > IMX8MQ_SYS1_PLL_80M>;" for uart3 the output of uart2 (console) keeps > > > ok. > > > > If that "fixes" it then it means that the parent IMX8MQ_SYS1_PLL_80M > > clock rate is getting changed by the uart3 stanza. > > > > Are you using the mainline devicetree file for your board ? If not could > > you provide a link ? > > I use the mainline u-boot/linux one. We (thanks to Michael) found the issue. For the imx8mq the imx_get_uartclk() returns always the values for UART1_CLK_ROOT [1]. This is wrong. Here we have to get the value dependent on the used UART. [1] https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/mach-imx/imx8m/clock_imx8mq.c#L381 -- Heiko
[PATCH 5/9] include: Import & Update bitops.h
Import the header from version 5.16 of the kernel: commit df0cc57e057f18e44dac8e6c18aba47ab53202f9 Inline the included and prevent U-Boot from including as BITS_PER_LONG is defined in . Remove now-duplicate definitions from . Note: This brings extra compile-time checks through GENMASK_INPUT_CHECK. Signed-off-by: Pierre-Clément Tosi Cc: Simon Glass Cc: Tom Rini --- include/linux/bitops.h | 27 ++--- include/linux/bits.h | 55 ++ 2 files changed, 62 insertions(+), 20 deletions(-) create mode 100644 include/linux/bits.h diff --git a/include/linux/bitops.h b/include/linux/bitops.h index d2e5ca026e..6d465077d6 100644 --- a/include/linux/bitops.h +++ b/include/linux/bitops.h @@ -5,37 +5,24 @@ #include #include +#include #include #ifdef __KERNEL__ -#define BIT(nr)(1UL << (nr)) -#define BIT_ULL(nr)(1ULL << (nr)) -#define BIT_MASK(nr) (1UL << ((nr) % BITS_PER_LONG)) -#define BIT_WORD(nr) ((nr) / BITS_PER_LONG) -#define BIT_ULL_MASK(nr) (1ULL << ((nr) % BITS_PER_LONG_LONG)) -#define BIT_ULL_WORD(nr) ((nr) / BITS_PER_LONG_LONG) -#define BITS_PER_BYTE 8 #define BITS_TO_LONGS(nr) DIV_ROUND_UP(nr, BITS_PER_BYTE * sizeof(long)) #endif /* kernel.h includes log.h which include bitops.h */ #include -/* - * Create a contiguous bitmask starting at bit position @l and ending at - * position @h. For example - * GENMASK_ULL(39, 21) gives us the 64bit vector 0x00e0. - */ #ifdef CONFIG_SANDBOX -#define GENMASK(h, l) \ - (((~0UL) << (l)) & (~0UL >> (CONFIG_SANDBOX_BITS_PER_LONG - 1 - (h -#else -#define GENMASK(h, l) \ - (((~0UL) << (l)) & (~0UL >> (BITS_PER_LONG - 1 - (h +#ifdef __GENMASK +#undef __GENMASK +#endif +#define __GENMASK(h, l) \ + (((~UL(0)) - (UL(1) << (l)) + 1) & \ +(~UL(0) >> (CONFIG_SANDBOX_BITS_PER_LONG - 1 - (h #endif - -#define GENMASK_ULL(h, l) \ - (((~0ULL) << (l)) & (~0ULL >> (BITS_PER_LONG_LONG - 1 - (h /* * ffs: find first bit set. This is defined the same way as diff --git a/include/linux/bits.h b/include/linux/bits.h new file mode 100644 index 00..04e7dae7f9 --- /dev/null +++ b/include/linux/bits.h @@ -0,0 +1,55 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +#ifndef __LINUX_BITS_H +#define __LINUX_BITS_H + +#include +#ifndef __UBOOT__ +#include +#else +#define BIT(nr) (UL(1) << (nr)) +#endif +#ifndef __UBOOT__ +#include +#else +/* U-Boot defines BITS_PER_LONG in . */ +#include +#endif + +#define BIT_ULL(nr)(ULL(1) << (nr)) +#define BIT_MASK(nr) (UL(1) << ((nr) % BITS_PER_LONG)) +#define BIT_WORD(nr) ((nr) / BITS_PER_LONG) +#define BIT_ULL_MASK(nr) (ULL(1) << ((nr) % BITS_PER_LONG_LONG)) +#define BIT_ULL_WORD(nr) ((nr) / BITS_PER_LONG_LONG) +#define BITS_PER_BYTE 8 + +/* + * Create a contiguous bitmask starting at bit position @l and ending at + * position @h. For example + * GENMASK_ULL(39, 21) gives us the 64bit vector 0x00e0. + */ +#if !defined(__ASSEMBLY__) +#include +#define GENMASK_INPUT_CHECK(h, l) \ + (BUILD_BUG_ON_ZERO(__builtin_choose_expr( \ + __is_constexpr((l) > (h)), (l) > (h), 0))) +#else +/* + * BUILD_BUG_ON_ZERO is not available in h files included from asm files, + * disable the input check if that is the case. + */ +#define GENMASK_INPUT_CHECK(h, l) 0 +#endif + +#define __GENMASK(h, l) \ + (((~UL(0)) - (UL(1) << (l)) + 1) & \ +(~UL(0) >> (BITS_PER_LONG - 1 - (h +#define GENMASK(h, l) \ + (GENMASK_INPUT_CHECK(h, l) + __GENMASK(h, l)) + +#define __GENMASK_ULL(h, l) \ + (((~ULL(0)) - (ULL(1) << (l)) + 1) & \ +(~ULL(0) >> (BITS_PER_LONG_LONG - 1 - (h +#define GENMASK_ULL(h, l) \ + (GENMASK_INPUT_CHECK(h, l) + __GENMASK_ULL(h, l)) + +#endif /* __LINUX_BITS_H */ -- 2.35.1.723.g4982287a31-goog
[PATCH 2/9] lib: crypt: Avoid redefining static_assert
Use the macro introduced by commit ef0f4e834c66 ("build_bug.h: add
wrapper for _Static_assert") by importing .
Signed-off-by: Pierre-Clément Tosi
Cc: Simon Glass
Cc: Steffen Jaeckel
---
lib/crypt/crypt-port.h | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/lib/crypt/crypt-port.h b/lib/crypt/crypt-port.h
index 6b9542d75b..e85d3c132c 100644
--- a/lib/crypt/crypt-port.h
+++ b/lib/crypt/crypt-port.h
@@ -1,6 +1,7 @@
/* SPDX-License-Identifier: GPL-2.0+ */
/* Copyright (C) 2020 Steffen Jaeckel */
+#include
#include
#include
@@ -10,8 +11,6 @@
#define ARG_UNUSED(x) (x)
-#define static_assert(a, b) _Static_assert(a, b)
-
#define strtoul(cp, endp, base) simple_strtoul(cp, endp, base)
extern const unsigned char ascii64[65];
--
2.35.1.723.g4982287a31-goog
[PATCH v2 9/9] configs: imx8mm_evk: add pwm backlight support
Enable support for backlight/pwm-imx driver Signed-off-by: Tommaso Merciai --- configs/imx8mm_evk_defconfig | 5 + 1 file changed, 5 insertions(+) diff --git a/configs/imx8mm_evk_defconfig b/configs/imx8mm_evk_defconfig index 01395fc7eb..cfba6cc673 100644 --- a/configs/imx8mm_evk_defconfig +++ b/configs/imx8mm_evk_defconfig @@ -84,3 +84,8 @@ CONFIG_SYSRESET_PSCI=y CONFIG_SYSRESET_WATCHDOG=y CONFIG_DM_THERMAL=y CONFIG_IMX_WATCHDOG=y +CONFIG_DM_VIDEO=y +CONFIG_BACKLIGHT=y +CONFIG_BACKLIGHT_PWM=y +CONFIG_DM_PWM=y +CONFIG_PWM_IMX=y \ No newline at end of file -- 2.25.1
[PATCH v2 7/9] imx8mm_evk: spl: enable pwm clock
Enable pwm1 clock into spl Signed-off-by: Tommaso Merciai --- Changes since v1: - Fix enable_pwm_clk call board/freescale/imx8mm_evk/spl.c | 4 1 file changed, 4 insertions(+) diff --git a/board/freescale/imx8mm_evk/spl.c b/board/freescale/imx8mm_evk/spl.c index 4ef7f6f180..cf173b885f 100644 --- a/board/freescale/imx8mm_evk/spl.c +++ b/board/freescale/imx8mm_evk/spl.c @@ -135,6 +135,10 @@ void board_init_f(ulong dummy) init_uart_clk(1); +#ifdef CONFIG_PWM_IMX + enable_pwm_clk(0, 1); +#endif + board_early_init_f(); timer_init(); -- 2.25.1
[PATCH v2 8/9] arm: dts: imx8mm_evk: add pwm1/backlight support
Add pwm1/backlight support nodes for imx8mm_evk board
Signed-off-by: Tommaso Merciai
---
arch/arm/dts/imx8mm-evk.dtsi | 21 +
1 file changed, 21 insertions(+)
diff --git a/arch/arm/dts/imx8mm-evk.dtsi b/arch/arm/dts/imx8mm-evk.dtsi
index 60179e006d..e7a2bd8a64 100644
--- a/arch/arm/dts/imx8mm-evk.dtsi
+++ b/arch/arm/dts/imx8mm-evk.dtsi
@@ -41,6 +41,15 @@
enable-active-high;
};
+ backlight: backlight {
+ status = "disabled";
+ compatible = "pwm-backlight";
+ pwms = < 0 500>;
+ brightness-levels = <0 255>;
+ num-interpolated-steps = <255>;
+ default-brightness-level = <250>;
+ };
+
ir-receiver {
compatible = "gpio-ir-receiver";
gpios = < 13 GPIO_ACTIVE_LOW>;
@@ -350,6 +359,12 @@
status = "okay";
};
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_backlight>;
+ status = "disabled";
+};
+
{
pinctrl_fec1: fec1grp {
fsl,pins = <
@@ -491,4 +506,10 @@
MX8MM_IOMUXC_GPIO1_IO02_WDOG1_WDOG_B0x166
>;
};
+
+ pinctrl_backlight: backlightgrp {
+ fsl,pins = <
+ MX8MM_IOMUXC_GPIO1_IO01_PWM1_OUT0x06
+ >;
+ };
};
--
2.25.1
[PATCH v2 6/9] configs: imx8mm_evk: add CONFIG_IMX6_PWM_PER_CLK config
In order to support pwm-imx-util CONFIG_IMX6_PWM_PER_CLK is needed. At the moment driver don't support clock framework Signed-off-by: Tommaso Merciai --- include/configs/imx8mm_evk.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/include/configs/imx8mm_evk.h b/include/configs/imx8mm_evk.h index c7022ef0f7..3c17dd3773 100644 --- a/include/configs/imx8mm_evk.h +++ b/include/configs/imx8mm_evk.h @@ -91,4 +91,7 @@ #define IMX_FEC_BASE 0x30BE +#ifdef CONFIG_PWM_IMX + #define CONFIG_IMX6_PWM_PER_CLK 6600 +#endif #endif -- 2.25.1
[PATCH v2 5/9] imx8m: clock: add enable_pwm_clk function
Add enable_pwm_clk function in clock.h Signed-off-by: Tommaso Merciai --- Changes since v1: - Fix enable_pwm_clk function implementation. Now is generic for all pwm clks arch/arm/include/asm/arch-imx8m/clock.h | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/include/asm/arch-imx8m/clock.h b/arch/arm/include/asm/arch-imx8m/clock.h index 50359d8e46..e320025990 100644 --- a/arch/arm/include/asm/arch-imx8m/clock.h +++ b/arch/arm/include/asm/arch-imx8m/clock.h @@ -278,3 +278,4 @@ int set_clk_enet(enum enet_freq type); int set_clk_eqos(enum enet_freq type); void hab_caam_clock_enable(unsigned char enable); void enable_usboh3_clk(unsigned int enable); +void enable_pwm_clk(u32 index, unsigned char enable); -- 2.25.1
[PATCH v2 4/9] arm: imx: imx8mm: add enable_pwm_clk function
Add function enable_pwm_clk into in clock_imx8mm.c. This
function first configure, then enable pwm clock from clock control
register. The following configuration is used:
source(0) -> 24 MHz ref clock
div(0)-> no division for this clock
References:
- iMX8MMRM.pdf p 303
Signed-off-by: Tommaso Merciai
---
Changes since v1:
- Fix enable_pwm_clk function implementation. Now is generic for all pwm clks
arch/arm/mach-imx/imx8m/clock_imx8mm.c | 53 ++
1 file changed, 53 insertions(+)
diff --git a/arch/arm/mach-imx/imx8m/clock_imx8mm.c
b/arch/arm/mach-imx/imx8m/clock_imx8mm.c
index 49945faf2c..ffb9456607 100644
--- a/arch/arm/mach-imx/imx8m/clock_imx8mm.c
+++ b/arch/arm/mach-imx/imx8m/clock_imx8mm.c
@@ -313,6 +313,59 @@ void enable_usboh3_clk(unsigned int enable)
}
}
+void enable_pwm_clk(u32 index, unsigned char enable)
+{
+ switch (index) {
+ case 0:
+ if (enable) {
+ clock_enable(CCGR_PWM1, false);
+ clock_set_target_val(PWM1_CLK_ROOT, CLK_ROOT_ON |
+ CLK_ROOT_SOURCE_SEL(0) |
+
CLK_ROOT_PRE_DIV(CLK_ROOT_PRE_DIV1));
+ clock_enable(CCGR_PWM1, true);
+ } else {
+ clock_enable(CCGR_PWM1, false);
+ }
+ return;
+ case 1:
+ if (enable) {
+ clock_enable(CCGR_PWM2, false);
+ clock_set_target_val(PWM2_CLK_ROOT, CLK_ROOT_ON |
+ CLK_ROOT_SOURCE_SEL(0) |
+
CLK_ROOT_PRE_DIV(CLK_ROOT_PRE_DIV1));
+ clock_enable(CCGR_PWM2, true);
+ } else {
+ clock_enable(CCGR_PWM2, false);
+ }
+ return;
+ case 2:
+ if (enable) {
+ clock_enable(CCGR_PWM3, false);
+ clock_set_target_val(PWM3_CLK_ROOT, CLK_ROOT_ON |
+ CLK_ROOT_SOURCE_SEL(0) |
+
CLK_ROOT_PRE_DIV(CLK_ROOT_PRE_DIV1));
+ clock_enable(CCGR_PWM3, true);
+ } else {
+ clock_enable(CCGR_PWM3, false);
+ }
+ return;
+ case 3:
+ if (enable) {
+ clock_enable(CCGR_PWM4, false);
+ clock_set_target_val(PWM4_CLK_ROOT, CLK_ROOT_ON |
+ CLK_ROOT_SOURCE_SEL(0) |
+
CLK_ROOT_PRE_DIV(CLK_ROOT_PRE_DIV1));
+ clock_enable(CCGR_PWM4, true);
+ } else {
+ clock_enable(CCGR_PWM4, false);
+ }
+ return;
+ default:
+ printf("Invalid pwm index\n");
+ return;
+ }
+}
+
void init_uart_clk(u32 index)
{
/*
--
2.25.1
[PATCH v2 3/9] arch: mach-imx: imx8m: add pwm_regs struct in imx-regs
Add pwm_regs struct for i.MX8MM SOC
Signed-off-by: Tommaso Merciai
---
arch/arm/include/asm/arch-imx8m/imx-regs.h | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/include/asm/arch-imx8m/imx-regs.h
b/arch/arm/include/asm/arch-imx8m/imx-regs.h
index 13538ba5f6..9217f93a50 100644
--- a/arch/arm/include/asm/arch-imx8m/imx-regs.h
+++ b/arch/arm/include/asm/arch-imx8m/imx-regs.h
@@ -361,6 +361,15 @@ struct src {
#define PWMCR_CLKSRC_IPG (1 << 16)
#define PWMCR_EN (1 << 0)
+struct pwm_regs {
+ u32 cr;
+ u32 sr;
+ u32 ir;
+ u32 sar;
+ u32 pr;
+ u32 cnr;
+};
+
#define WDOG_WDT_MASK BIT(3)
#define WDOG_WDZST_MASKBIT(0)
struct wdog_regs {
--
2.25.1
[PATCH v2 2/9] arch: mach-imx: imx8m: add pwm ctrl registers fields defines
Add pwm control registers fields defines into imx-regs.h:
- prescaler
- dozeen
- waiten
- dbgen
- clksrc_ipg_high
- clksrc_ipg, en field
References:
- iMX8MMRM.pdf p 3884
Signed-off-by: Tommaso Merciai
---
arch/arm/include/asm/arch-imx8m/imx-regs.h | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/include/asm/arch-imx8m/imx-regs.h
b/arch/arm/include/asm/arch-imx8m/imx-regs.h
index 38f8ba41c3..13538ba5f6 100644
--- a/arch/arm/include/asm/arch-imx8m/imx-regs.h
+++ b/arch/arm/include/asm/arch-imx8m/imx-regs.h
@@ -353,6 +353,14 @@ struct src {
u32 ddr2_rcr;
};
+#define PWMCR_PRESCALER(x) (((x - 1) & 0xFFF) << 4)
+#define PWMCR_DOZEEN (1 << 24)
+#define PWMCR_WAITEN (1 << 23)
+#define PWMCR_DBGEN(1 << 22)
+#define PWMCR_CLKSRC_IPG_HIGH (2 << 16)
+#define PWMCR_CLKSRC_IPG (1 << 16)
+#define PWMCR_EN (1 << 0)
+
#define WDOG_WDT_MASK BIT(3)
#define WDOG_WDZST_MASKBIT(0)
struct wdog_regs {
--
2.25.1
[PATCH v2 1/9] arch: mach-imx: imx8m: add pwm1/pwm2 base address
Add pwm1/pwm2 base address defines into imx-regs file References: - IMX8MMRM.pdf p 3882 Signed-off-by: Tommaso Merciai --- arch/arm/include/asm/arch-imx8m/imx-regs.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/include/asm/arch-imx8m/imx-regs.h b/arch/arm/include/asm/arch-imx8m/imx-regs.h index 11389a0f4d..38f8ba41c3 100644 --- a/arch/arm/include/asm/arch-imx8m/imx-regs.h +++ b/arch/arm/include/asm/arch-imx8m/imx-regs.h @@ -31,6 +31,8 @@ #define SRC_BASE_ADDR 0x3039 #define GPC_BASE_ADDR 0x303A +#define PWM1_BASE_ADDR 0x3066 +#define PWM2_BASE_ADDR 0x3067 #define SYSCNT_RD_BASE_ADDR0x306A #define SYSCNT_CMP_BASE_ADDR 0x306B #define SYSCNT_CTRL_BASE_ADDR 0x306C -- 2.25.1
[PATCH v2 0/9] imx8mm: add pwm-imx backlight support
Hi, This series add support for pwm/backlight on i.MX8MM evk: 1. Add pwm1/pwm2 base address registers defines 2. Add defines for pwm control register field 3. Add struct pwm_regs 4. Add enable_pwm_clk function, configure and enable pwm clock control register 5. Add enable_pwm_clk function in clock.h 6. Add CONFIG_IMX6_PWM_PER_CLK in imx8mm_evk.h 7. Add backlight/pwm1 dts nodes support for iMX8MM evk 8. Enable pwm clk into spl 9. Enable support for pwm-imx/backlight for iMX8MM evk Regards, Tommaso Tommaso Merciai (9): arch: mach-imx: imx8m: add pwm1/pwm2 base address arch: mach-imx: imx8m: add pwm ctrl registers fields defines arch: mach-imx: imx8m: add pwm_regs struct in imx-regs arm: imx: imx8mm: add enable_pwm_clk function imx8m: clock: add enable_pwm_clk function configs: imx8mm_evk: add CONFIG_IMX6_PWM_PER_CLK config imx8mm_evk: spl: enable pwm clock arm: dts: imx8mm_evk: add pwm1/backlight support configs: imx8mm_evk: add pwm backlight support arch/arm/dts/imx8mm-evk.dtsi | 21 + arch/arm/include/asm/arch-imx8m/clock.h| 1 + arch/arm/include/asm/arch-imx8m/imx-regs.h | 19 arch/arm/mach-imx/imx8m/clock_imx8mm.c | 53 ++ board/freescale/imx8mm_evk/spl.c | 4 ++ configs/imx8mm_evk_defconfig | 5 ++ include/configs/imx8mm_evk.h | 3 ++ 7 files changed, 106 insertions(+) -- 2.25.1
Re: [PATCH] arm64: zynqmp: Add pinctrl emmc description to SM-K26
po 14. 3. 2022 v 15:26 odesílatel Michal Simek napsal:
>
> Production SOM has emmc on it and make sense to describe pin description to
> be able use EMMC if it is not configured via psu_init.
> (Still some regs are not handled but this is one step in that direction)
>
> Signed-off-by: Michal Simek
> ---
>
> arch/arm/dts/zynqmp-sm-k26-revA.dts | 20
> 1 file changed, 20 insertions(+)
>
> diff --git a/arch/arm/dts/zynqmp-sm-k26-revA.dts
> b/arch/arm/dts/zynqmp-sm-k26-revA.dts
> index b437d713ca8f..e904cd8ea093 100644
> --- a/arch/arm/dts/zynqmp-sm-k26-revA.dts
> +++ b/arch/arm/dts/zynqmp-sm-k26-revA.dts
> @@ -14,6 +14,7 @@
> #include
> #include
> #include
> +#include
>
> / {
> model = "ZynqMP SM-K26 Rev1/B/A";
> @@ -92,6 +93,23 @@
> status = "okay";
> };
>
> + {
> + status = "okay";
> + pinctrl_sdhci0_default: sdhci0-default {
> + conf {
> + groups = "sdio0_0_grp";
> + slew-rate = ;
> + power-source = ;
> + bias-disable;
> + };
> +
> + mux {
> + groups = "sdio0_0_grp";
> + function = "sdio0";
> + };
> + };
> +};
> +
> { /* MIO 0-5 - U143 */
> status = "okay";
> flash@0 { /* MT25QU512A */
> @@ -185,6 +203,8 @@
>
> { /* MIO13-23 - 16GB emmc MTFC16GAPALBH-IT - U133A */
> status = "okay";
> + pinctrl-names = "default";
> + pinctrl-0 = <_sdhci0_default>;
> non-removable;
> disable-wp;
> bus-width = <8>;
> --
> 2.35.1
>
Applied.
M
--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs
[PATCH v2] efi_loader: Set variable attributes when EFI_BUFFER_TOO_SMALL is returned
Starting UEFI Spec 2.8 we must fill in the variable attributes when
GetVariable() returns EFI_BUFFER_TOO_SMALL and Attributes is non-NULL.
This code was written with 2.7 in mind so let's move the code around a
bit and fill in the attributes EFI_BUFFER_TOO_SMALL is returned
Signed-off-by: Ilias Apalodimas
---
Changes since v1:
- tmp variables switched to efi_status_t instead of int
- switched (ret == EFI_SUCCESS || ret == EFI_BUFFER_TOO_SMALL)
to (ret != EFI_SUCCESS && ret != EFI_BUFFER_TOO_SMALL) to
make the code easier to read
- Only call get_property_int() if attributes != NULL
lib/efi_loader/efi_variable_tee.c | 31 ---
1 file changed, 20 insertions(+), 11 deletions(-)
diff --git a/lib/efi_loader/efi_variable_tee.c
b/lib/efi_loader/efi_variable_tee.c
index 58931c4efd74..dfef18435dfa 100644
--- a/lib/efi_loader/efi_variable_tee.c
+++ b/lib/efi_loader/efi_variable_tee.c
@@ -368,7 +368,7 @@ efi_status_t efi_get_variable_int(const u16 *variable_name,
efi_uintn_t name_size;
efi_uintn_t tmp_dsize;
u8 *comm_buf = NULL;
- efi_status_t ret;
+ efi_status_t ret, tmp;
if (!variable_name || !vendor || !data_size) {
ret = EFI_INVALID_PARAMETER;
@@ -407,23 +407,32 @@ efi_status_t efi_get_variable_int(const u16
*variable_name,
/* Communicate */
ret = mm_communicate(comm_buf, payload_size);
- if (ret == EFI_SUCCESS || ret == EFI_BUFFER_TOO_SMALL) {
- /* Update with reported data size for trimmed case */
- *data_size = var_acc->data_size;
- }
- if (ret != EFI_SUCCESS)
- goto out;
-
- ret = get_property_int(variable_name, name_size, vendor, _property);
- if (ret != EFI_SUCCESS)
+ if (ret != EFI_SUCCESS && ret != EFI_BUFFER_TOO_SMALL)
goto out;
+ /* Update with reported data size for trimmed case */
+ *data_size = var_acc->data_size;
+ /*
+* UEFI > 2.7 needs the attributes set even if the buffer is
+* smaller
+*/
if (attributes) {
+ tmp = get_property_int(variable_name, name_size, vendor,
+ _property);
+ if (tmp != EFI_SUCCESS) {
+ ret = tmp;
+ goto out;
+ }
*attributes = var_acc->attr;
- if (var_property.property &
VAR_CHECK_VARIABLE_PROPERTY_READ_ONLY)
+ if (var_property.property &
+ VAR_CHECK_VARIABLE_PROPERTY_READ_ONLY)
*attributes |= EFI_VARIABLE_READ_ONLY;
}
+ /* return if ret is EFI_BUFFER_TOO_SMALL */
+ if (ret != EFI_SUCCESS)
+ goto out;
+
if (data)
memcpy(data, (u8 *)var_acc->name + var_acc->name_size,
var_acc->data_size);
--
2.32.0
Re: [PATCH v1 0/5] Move board specific files to board directory
On Tue, Mar 15, 2022 at 01:23:42PM -0700, Troy Kisky wrote:
> On 3/15/2022 1:01 PM, Tom Rini wrote:
> > On Tue, Mar 15, 2022 at 12:08:02PM -0700, Troy Kisky wrote:
> >> On 2/8/2022 6:30 AM, Tom Rini wrote:
> >>> On Fri, Jan 07, 2022 at 10:33:34AM -0800, Troy Kisky wrote:
> On 1/7/2022 7:12 AM, Tom Rini wrote:
> > On Thu, Jan 06, 2022 at 01:14:40PM -0800, Troy Kisky wrote:
> >> On 12/28/2021 5:11 AM, Tom Rini wrote:
> >>> On Tue, Dec 28, 2021 at 01:33:05AM -0700, Simon Glass wrote:
> Hi Troy,
>
> On Fri, 17 Dec 2021 at 16:02, Troy Kisky
> wrote:
> >
> > This series intends to let board specific files live in the boards
> > directory. The last patch moves files for nitrogen6x.
> > I have tested it with buildman
> >
> > ./tools/buildman/buildman boundary -b denx_master
> >
> > But it is likely the more scripts then just tools/genboardscfg.py
> > would
> > need to be updated.
> >
> > Troy Kisky (5):
> > kconfig: allow defconfigs to live in board directory
> > dts: allow dts files in board directory
> > scripts: Makefile.autoconf: allow CONFIG_SYS_CONFIG_NAME file to
> > live
> > in board directory
> > genboardcfg: allow defconfigs in board directory
> > nitrogen6x: move board specific files to nitrogen6x directory
> >
> > arch/arm/dts/Makefile | 3 --
> > board/boundary/nitrogen6x/MAINTAINERS | 13 ---
> > board/boundary/nitrogen6x/Makefile| 13 +++
> > .../nitrogen6x}/imx6dl-nitrogen6x.dts | 0
> > .../boundary/nitrogen6x}/imx6q-nitrogen6x.dts | 0
> > .../boundary/nitrogen6x}/imx6q-sabrelite.dts | 0
> > .../nitrogen6x}/imx6qdl-nitrogen6x.dtsi | 0
> > .../nitrogen6x}/imx6qdl-sabrelite.dtsi| 0
> > .../nitrogen6x}/mx6qsabrelite_defconfig | 0
> > .../nitrogen6x}/nitrogen6dl2g_defconfig | 0
> > .../nitrogen6x}/nitrogen6dl_defconfig | 0
> > .../nitrogen6x}/nitrogen6q2g_defconfig| 0
> > .../boundary/nitrogen6x}/nitrogen6q_defconfig | 0
> > .../nitrogen6x}/nitrogen6s1g_defconfig| 0
> > .../boundary/nitrogen6x}/nitrogen6s_defconfig | 0
> > .../boundary/nitrogen6x}/nitrogen6x.h | 2 +-
> > dts/Makefile | 11 +-
> > scripts/Makefile.autoconf | 9 -
> > scripts/Makefile.lib | 1 +
> > scripts/kconfig/Makefile | 9 -
> > tools/genboardscfg.py | 37
> > ++-
> > 21 files changed, 75 insertions(+), 23 deletions(-)
> > rename {arch/arm/dts =>
> > board/boundary/nitrogen6x}/imx6dl-nitrogen6x.dts (100%)
> > rename {arch/arm/dts =>
> > board/boundary/nitrogen6x}/imx6q-nitrogen6x.dts (100%)
> > rename {arch/arm/dts =>
> > board/boundary/nitrogen6x}/imx6q-sabrelite.dts (100%)
> > rename {arch/arm/dts =>
> > board/boundary/nitrogen6x}/imx6qdl-nitrogen6x.dtsi (100%)
> > rename {arch/arm/dts =>
> > board/boundary/nitrogen6x}/imx6qdl-sabrelite.dtsi (100%)
> > rename {configs =>
> > board/boundary/nitrogen6x}/mx6qsabrelite_defconfig (100%)
> > rename {configs =>
> > board/boundary/nitrogen6x}/nitrogen6dl2g_defconfig (100%)
> > rename {configs =>
> > board/boundary/nitrogen6x}/nitrogen6dl_defconfig (100%)
> > rename {configs =>
> > board/boundary/nitrogen6x}/nitrogen6q2g_defconfig (100%)
> > rename {configs => board/boundary/nitrogen6x}/nitrogen6q_defconfig
> > (100%)
> > rename {configs =>
> > board/boundary/nitrogen6x}/nitrogen6s1g_defconfig (100%)
> > rename {configs => board/boundary/nitrogen6x}/nitrogen6s_defconfig
> > (100%)
> > rename {include/configs => board/boundary/nitrogen6x}/nitrogen6x.h
> > (98%) I'm not about the goal.
>
> Can you please add a few notes about the motivation for this change?
> >>>
> >>> Sorry for the delayed reply here. I'm also not entirely sure this is
> >>> a
> >>> good idea. Moving the defconfig files? Maybe. It does make checking
> >>> all configs a bit more tricky, but indeed the configs directory is
> >>> unwieldy. Moving the dts files? Those should be a direct cp from the
> >>> kernel, so that makes things less clear to me. Especially since it
> >>> will
> >>> need other common files that will still be elsewhere.
> >>>
> >>
> >> They will still be a direct copy. Notice the 100% rename. Common
Re: [PATCH v2 02/13] Makefile: Allow LTO to be disabled for a build
On Wed, Mar 16, 2022 at 10:15:17AM +1300, Simon Glass wrote: > Hi Tom, > > On Mon, 14 Mar 2022 at 16:42, Tom Rini wrote: > > > > On Mon, Mar 14, 2022 at 03:43:05PM -0600, Simon Glass wrote: > > > Hi Tom, > > > > > > On Mon, 14 Mar 2022 at 14:23, Tom Rini wrote: > > > > > > > > On Mon, Mar 14, 2022 at 02:18:14PM -0600, Simon Glass wrote: > > > > > Hi Tom, > > > > > > > > > > On Mon, 14 Mar 2022 at 13:45, Tom Rini wrote: > > > > > > > > > > > > On Mon, Mar 14, 2022 at 01:21:02PM -0600, Simon Glass wrote: > > > > > > > Hi Tom, > > > > > > > > > > > > > > On Mon, 14 Mar 2022 at 12:29, Tom Rini wrote: > > > > > > > > > > > > > > > > On Mon, Mar 14, 2022 at 12:24:42PM -0600, Simon Glass wrote: > > > > > > > > > Hi Tom, > > > > > > > > > > > > > > > > > > On Mon, 14 Mar 2022 at 06:49, Tom Rini > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > On Sat, Mar 12, 2022 at 10:58:44AM -0700, Simon Glass wrote: > > > > > > > > > > > Hi Tom, > > > > > > > > > > > > > > > > > > > > > > On Mon, 7 Mar 2022 at 07:33, Tom Rini > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > On Fri, Mar 04, 2022 at 08:42:57AM -0700, Simon Glass > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > LTO (Link-Time Optimisation) is an very useful > > > > > > > > > > > > > feature which can > > > > > > > > > > > > > significantly reduce the size of U-Boot binaries. So > > > > > > > > > > > > > far it has been > > > > > > > > > > > > > made available for selected ARM boards and sandbox. > > > > > > > > > > > > > > > > > > > > > > > > > > However, incremental builds are much slower when LTO > > > > > > > > > > > > > is used. For example, > > > > > > > > > > > > > an incremental build of sandbox takes 2.1 seconds on > > > > > > > > > > > > > my machine, but 6.7 > > > > > > > > > > > > > seconds with LTO enabled. > > > > > > > > > > > > > > > > > > > > > > > > > > Add a LTO_BUILD=n parameter to the build, so it can > > > > > > > > > > > > > be disabled during > > > > > > > > > > > > > development if needed, for faster builds. > > > > > > > > > > > > > > > > > > > > > > > > > > Add some documentation about LTO while we are here. > > > > > > > > > > > > > > > > > > > > > > > > > > Signed-off-by: Simon Glass > > > > > > > > > > > > > > > > > > > > > > > > We don't need this since you can do: > > > > > > > > > > > > make EXTRA_CFLAGS="-fno-lto" EXTRA_LDFLAGS="-fno-lto" > > > > > > > > > > > > to pass -fno-lto to compile/linking and disable lto and > > > > > > > > > > > > per > > > > > > > > > > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46905 this > > > > > > > > > > > > has been working > > > > > > > > > > > > for some time. > > > > > > > > > > > > > > > > > > > > > > Thanks for that, it is a big pain point for me, picking > > > > > > > > > > > up this patch > > > > > > > > > > > for every series I write. The incremental build time for > > > > > > > > > > > sandbox goes > > > > > > > > > > > from 3 seconds to 27 seconds on my laptop with LTO, which > > > > > > > > > > > is > > > > > > > > > > > intolerable. > > > > > > > > > > > > > > > > > > > > Yeah, I noticed it's visible on my laptop, but not at all > > > > > > > > > > on my desktop > > > > > > > > > > (i7 vs Ryzen 7). > > > > > > > > > > > > > > > > > > > > > The EXTRA_CFLAGS says it is for 'Backward compatibility' > > > > > > > > > > > and it still > > > > > > > > > > > does the various LTO things (i.e. it changes the build > > > > > > > > > > > logic). It > > > > > > > > > > > > > > > > > > > > We're unlikely to move to newer Linux kernel kbuild logic > > > > > > > > > > so this isn't > > > > > > > > > > going away, and there's not much in the way of logic that's > > > > > > > > > > changed for > > > > > > > > > > LTO that I see. > > > > > > > > > > > > > > > > > > > > > seems odd to me to enable the option and then disable it > > > > > > > > > > > later in the > > > > > > > > > > > command line. It is therefore not quite equivalent. But > > > > > > > > > > > it seems to > > > > > > > > > > > work well enough for me fom a small amount of testing. If > > > > > > > > > > > you are > > > > > > > > > > > really set on not having a special option for it, I can > > > > > > > > > > > live with it > > > > > > > > > > > for now. I'm also not convinced that my patch entirely > > > > > > > > > > > removes the LTO > > > > > > > > > > > stuff in a consistent way. > > > > > > > > > > > > > > > > > > > > Yeah, I really don't want to go down the path of overriding > > > > > > > > > > CONFIG > > > > > > > > > > options via make/environment logic. I'm also open to > > > > > > > > > > turning off LTO on > > > > > > > > > > sandbox and on with qemu-* so it gets wider CI testing. > > > > > > > > > > > > > > > > > > Yes you did mention that, but the problem is that LTO is very > > > > > > > > > handy > > > > > > > > > with sandbox, to test the strange things that happen. For > > > > > > > > > example, I > > >
Re: [GIT PULL] Please pull u-boot-mmc master
On Wed, Mar 16, 2022 at 07:30:11PM +0900, Jaehoon Chung wrote: > Dear Tom, > > Please pull u-boot-mmc master into u-boot master branch. > If there is any problem, let me know, plz. > Sorry for late. > > Best Regards, > Jaehoon Chung > > CI: https://source.denx.de/u-boot/custodians/u-boot-mmc/-/pipelines/11304 > > The following changes since commit 4dc9b1771b152838ddfc4ae86a0ab9fd53ea16f7: > > Merge https://source.denx.de/u-boot/custodians/u-boot-usb (2022-03-14 > 22:54:53 -0400) > > are available in the Git repository at: > > g...@source.denx.de:u-boot/custodians/u-boot-mmc.git master > > for you to fetch changes up to c48021d184097ea4a1bb6bab8c24653de2477fde: > > rockchip: sdhci: Add HS400 Enhanced Strobe support for RK3568 (2022-03-16 > 18:10:41 +0900) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: Please pull u-boot-marvell/master
On Wed, Mar 16, 2022 at 10:52:41AM +0100, Stefan Roese wrote: > Hi Tom, > > please pull this MVEBU turris_mox fixes: > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PULL] u-boot-riscv/master
On Wed, Mar 16, 2022 at 10:56:40AM +0800, Leo Liang wrote: > Hi Tom, > > The following changes since commit c149bf41404e34014e37de32fac332892b11bd4a: > > Prepare v2022.04-rc4 (2022-03-14 16:39:08 -0400) > > are available in the Git repository at: > > https://source.denx.de/u-boot/custodians/u-boot-riscv.git > > for you to fetch changes up to aa34e13346cf727197981c599f688b406005049a: > > pinctrl: k210: Fix bias-pull-up (2022-03-15 17:43:11 +0800) > > CI result shows no issue: > https://source.denx.de/u-boot/custodians/u-boot-riscv/-/pipelines/11297 > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PULL] u-boot-sh/master
On Tue, Mar 15, 2022 at 09:43:26PM +0100, Marek Vasut wrote: > Config tweaks to enable the right I2C driver > > The following changes since commit c96137000e4cf486dcb164fd67a1a0b5b2fb99c6: > > Merge tag 'efi-2022-04-rc3-2' of > https://source.denx.de/u-boot/custodians/u-boot-efi (2022-03-13 08:18:17 > -0400) > > are available in the Git repository at: > > git://source.denx.de/u-boot-sh.git master > > for you to fetch changes up to 23fd0bb987c781d2f87af6b546fb219b40ad1057: > > configs: condor: Enabled I2C support for R-Car V3H (2022-03-14 11:49:17 > +0100) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v4 2/4] clk: imx8mq: Add a clock driver for the imx8mq
Am Mi., 16. März 2022 um 15:15 Uhr schrieb Angus Ainslie : > > On 2022-03-16 07:02, Heiko Thiery wrote: > > Hi Angus, > > > > [snip] > > > >> > > >> > Meanwhile I figured out what the problem is with the 'No serial driver > >> > found'. In the used dtb there are 'assigned-clocks' and > >> > 'assigned-clock-parents' set in the uart nodes. When removing this the > >> > serial will work. I have to admit that I do not know why this is set > >> > that way. I can only imagine that this was taken from the uboot-imx > >> > tree. > >> > > >> > --- > >> > assigned-clocks = < IMX8MQ_CLK_UART1>; > >> > assigned-clock-parents = < IMX8MQ_SYS1_PLL_80M>; > >> > --- > >> > > >> > >> Does that solve the reboot ? > > > > Yes, when I remove these assigned-clocks from my dtb the issue is > > solved and the board finds the serial driver and starts correctly. > > > >> > >> > see also here: > >> > https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/dts/imx8mq-kontron-pitx-imx8m.dts#L315 > >> > >> If that works for Linux it should also work for u-boot. It may be that > >> the SYS1_PLL_80M isn't set correctly or that the CLK_UART1 mux isn't > >> correctly setup. If you enable DEBUG in clk-uclass I might be able to > >> figure out were the problem is. > > > > The problem is that the IMX8MQ_CLK_UART1 is not found and that is the > > reason that the probe fails. I tried to add the missing clocks to how > > it is done in the kernel. > > > > see here: https://pastebin.com/raw/iYYMHEdy > > Looking at that you shouldn't need > > + clk_dm(IMX8MQ_CLK_25M, clk_register_fixed_rate(NULL, > "clock-osc-25m", 2500)); > + clk_dm(IMX8MQ_CLK_25M, clk_register_fixed_rate(NULL, > "clock-osc-27m", 2700)); > > Those get correctly probed by the clock-controller. > > The rest of it looks OK and could be a follow on patch to the clock > driver, > > > > > But then something went wrong when probing uart3 ... the baudrate > > switched for the uart2 (console) and the serial output became broken. > > Later when the kernel starts the output becomes correct again. So the > > kernel seems to configure it correctly. > > > > see here: https://pastebin.com/raw/qXVShb3Q > > > > When I remove the "assigned-clock-parents = < > > IMX8MQ_SYS1_PLL_80M>;" for uart3 the output of uart2 (console) keeps > > ok. > > If that "fixes" it then it means that the parent IMX8MQ_SYS1_PLL_80M > clock rate is getting changed by the uart3 stanza. > > Are you using the mainline devicetree file for your board ? If not could > you provide a link ? I use the mainline u-boot/linux one.
Re: [PATCH v4 2/4] clk: imx8mq: Add a clock driver for the imx8mq
On 2022-03-16 07:02, Heiko Thiery wrote: Hi Angus, [snip] > > Meanwhile I figured out what the problem is with the 'No serial driver > found'. In the used dtb there are 'assigned-clocks' and > 'assigned-clock-parents' set in the uart nodes. When removing this the > serial will work. I have to admit that I do not know why this is set > that way. I can only imagine that this was taken from the uboot-imx > tree. > > --- > assigned-clocks = < IMX8MQ_CLK_UART1>; > assigned-clock-parents = < IMX8MQ_SYS1_PLL_80M>; > --- > Does that solve the reboot ? Yes, when I remove these assigned-clocks from my dtb the issue is solved and the board finds the serial driver and starts correctly. > see also here: > https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/dts/imx8mq-kontron-pitx-imx8m.dts#L315 If that works for Linux it should also work for u-boot. It may be that the SYS1_PLL_80M isn't set correctly or that the CLK_UART1 mux isn't correctly setup. If you enable DEBUG in clk-uclass I might be able to figure out were the problem is. The problem is that the IMX8MQ_CLK_UART1 is not found and that is the reason that the probe fails. I tried to add the missing clocks to how it is done in the kernel. see here: https://pastebin.com/raw/iYYMHEdy Looking at that you shouldn't need + clk_dm(IMX8MQ_CLK_25M, clk_register_fixed_rate(NULL, "clock-osc-25m", 2500)); + clk_dm(IMX8MQ_CLK_25M, clk_register_fixed_rate(NULL, "clock-osc-27m", 2700)); Those get correctly probed by the clock-controller. The rest of it looks OK and could be a follow on patch to the clock driver, But then something went wrong when probing uart3 ... the baudrate switched for the uart2 (console) and the serial output became broken. Later when the kernel starts the output becomes correct again. So the kernel seems to configure it correctly. see here: https://pastebin.com/raw/qXVShb3Q When I remove the "assigned-clock-parents = < IMX8MQ_SYS1_PLL_80M>;" for uart3 the output of uart2 (console) keeps ok. If that "fixes" it then it means that the parent IMX8MQ_SYS1_PLL_80M clock rate is getting changed by the uart3 stanza. Are you using the mainline devicetree file for your board ? If not could you provide a link ?
Re: GPMI NAND Regression on i.MX6S
Adding Han Xu's NXP email on Cc.
On Mon, Mar 14, 2022 at 10:31 AM Frieder Schrempf
wrote:
>
> Hello everyone,
>
> sorry to dig out an old thread, but the below patch which was applied
> upstream as 616f03dabacb causes a regression for me when trying to
> attach an UBI volume with U-Boot 2022.01 on a board with i.MX6 Solo and
> AMD/Spansion parallel NAND.
>
> The failure looks like this:
>
> ubi0: attaching mtd2
> ubi0 error: ubi_io_read: error -74 (ECC error) while reading 64 bytes
> from PEB 0:0, read 64 bytes
> ubi0 error: ubi_io_read: error -74 (ECC error) while reading 2048 bytes
> from PEB 0:2048, read 2048 bytes
> ubi0 error: ubi_io_read: error -74 (ECC error) while reading 64 bytes
> from PEB 1:0, read 64 bytes
> ubi0 error: ubi_io_read: error -74 (ECC error) while reading 2048 bytes
> from PEB 1:2048, read 2048 bytes
>
> The NAND as reported by Linux is:
>
> nand: device found, Manufacturer ID: 0x01, Chip ID: 0xdc
> nand: AMD/Spansion S34ML04G1
> nand: 512 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
>
> A different revision of the same board with a different NAND from
> manufacturer ESMT doesn't show the issue:
>
> nand: device found, Manufacturer ID: 0xc8, Chip ID: 0xdc
> nand: ESMT NAND 512MiB 3,3V 8-bit
> nand: 512 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
>
> When I revert the mentioned commit (see patch here: [1]), the UBI boot
> starts working again.
>
> Does anyone know what the problem is and how to properly solve it?
>
> Thanks for any help!
> Frieder
>
> [1]
> https://zerobin.net/?57a57a322bbdcf3c#rZa3vHlWi+RxtRomoljtrngqWwiv6v4Js/2LNfdV10o=
>
> Am 04.05.20 um 16:08 schrieb Peng Fan:
> > From: Ye Li
> >
> > The code change updated the NAND driver BCH ECC layout algorithm to
> > support large oob size NAND chips(oob > 1024 bytes) and proposed a new
> > way to set ECC layout.
> >
> > Current implementation requires each chunk size larger than oob size so
> > the bad block marker (BBM) can be guaranteed located in data chunk. The
> > ECC layout always using the unbalanced layout(Ecc for both meta and
> > Data0 chunk), but for the NAND chips with oob larger than 1k, the driver
> > cannot support because BCH doesn’t support GF 15 for 2K chunk.
> >
> > The change keeps the data chunk no larger than 1k and adjust the ECC
> > strength or ECC layout to locate the BBM in data chunk. General idea for
> > large oob NAND chips is
> >
> > 1.Try all ECC strength from the minimum value required by NAND spec to
> > the maximum one that works, any ECC makes the BBM locate in data chunk
> > can be chosen.
> >
> > 2.If none of them works, using separate ECC for meta, which will add one
> > extra ecc with the same ECC strength as other data chunks. This extra
> > ECC can guarantee BBM located in data chunk, of course, we need to check
> > if oob can afford it.
> >
> > Previous code has two methods for ECC layout setting, the
> > legacy_calc_ecc_layout and calc_ecc_layout_by_info, the difference
> > between these two methods is, legacy_calc_ecc_layout set the chunk size
> > larger chan oob size and then set the maximum ECC strength that oob can
> > afford. While the calc_ecc_layout_by_info set chunk size and ECC
> > strength according to NAND spec. It has been proved that the first
> > method cannot provide safe ECC strength for some modern NAND chips, so
> > in current code,
> >
> > 1. Driver read NAND parameters first and then chose the proper ECC
> > layout setting method.
> >
> > 2. If the oob is large or NAND required data chunk larger than oob size,
> > chose calc_ecc_for_large_oob, otherwise use calc_ecc_layout_by_info
> >
> > 3. legacy_calc_ecc_layout only used for some NAND chips does not contains
> > necessary information. So this is only a backup plan, it is NOT
> > recommended to use these NAND chips.
> >
> > Signed-off-by: Han Xu
> > Signed-off-by: Ye Li
> > Signed-off-by: Peng Fan
> > ---
> > drivers/mtd/nand/raw/mxs_nand.c | 205
> > ++--
> > include/mxs_nand.h | 12 ++-
> > 2 files changed, 144 insertions(+), 73 deletions(-)
> >
> > diff --git a/drivers/mtd/nand/raw/mxs_nand.c
> > b/drivers/mtd/nand/raw/mxs_nand.c
> > index fe8097c146..8da59e39c0 100644
> > --- a/drivers/mtd/nand/raw/mxs_nand.c
> > +++ b/drivers/mtd/nand/raw/mxs_nand.c
> > @@ -112,53 +112,32 @@ static uint32_t mxs_nand_aux_status_offset(void)
> > return (MXS_NAND_METADATA_SIZE + 0x3) & ~0x3;
> > }
> >
> > -static inline int mxs_nand_calc_mark_offset(struct bch_geometry *geo,
> > - uint32_t page_data_size)
> > +static inline bool mxs_nand_bbm_in_data_chunk(struct bch_geometry *geo,
> > struct mtd_info *mtd,
> > + unsigned int *chunk_num)
> > {
> > - uint32_t chunk_data_size_in_bits = geo->ecc_chunk_size * 8;
> > - uint32_t chunk_ecc_size_in_bits = geo->ecc_strength * geo->gf_len;
> > - uint32_t chunk_total_size_in_bits;
> > - uint32_t block_mark_chunk_number;
Re: [PATCH] efi_loader: Set variable attributes when EFI_BUFFER_TOO_SMALL is returned
On Wed, Mar 16, 2022 at 02:40:20PM +0100, Heinrich Schuchardt wrote:
> On 3/16/22 13:55, Ilias Apalodimas wrote:
> > Starting UEFI Spec 2.8 we must fill in the variable attributes when
> > GetVariable() returns EFI_BUFFER_TOO_SMALL and Attributes is non-NULL.
> >
> > This code was written with 2.7 in mind so let's move the code around a
> > bit and fill in the attributes EFI_BUFFER_TOO_SMALL is returned
>
> In the UEFI spec changelog:
>
> 1954 set (*Attributes) when GetVariable() returns EFI_BUFFER_TOO_SMALL
> and Attributes is non-NULL
>
> In efi_get_variable_mem() this already works correctly.
>
> >
> > Signed-off-by: Ilias Apalodimas
> > ---
> > lib/efi_loader/efi_variable_tee.c | 27 ++-
> > 1 file changed, 18 insertions(+), 9 deletions(-)
> >
> > diff --git a/lib/efi_loader/efi_variable_tee.c
> > b/lib/efi_loader/efi_variable_tee.c
> > index 58931c4efd74..33c7dfc53d14 100644
> > --- a/lib/efi_loader/efi_variable_tee.c
> > +++ b/lib/efi_loader/efi_variable_tee.c
> > @@ -408,22 +408,31 @@ efi_status_t efi_get_variable_int(const u16
> > *variable_name,
> > /* Communicate */
> > ret = mm_communicate(comm_buf, payload_size);
> > if (ret == EFI_SUCCESS || ret == EFI_BUFFER_TOO_SMALL) {
>
> You could make the code easier to read with:
>
> if (ret != EFI_SUCCESS && ret != EFI_BUFFER_TOO_SMALL)
> goto out;
>
Sure
> > + int tmp;
> > /* Update with reported data size for trimmed case */
> > *data_size = var_acc->data_size;
> > + /*
> > +* UEFI > 2.7 needs the attributes set even if the buffer is
> > +* smaller
> > +*/
> > + tmp = get_property_int(variable_name, name_size, vendor,
> > + _property);
>
> Why call get_property_int() if (!attributes)?
> You don't use the data in this case.
>
Good point. I just moved the code around, but i'll fix that along the way
Thanks
/Ilias
> Best regards
>
> Heinrich
>
> > + if (tmp != EFI_SUCCESS) {
> > + ret = tmp;
> > + goto out;
> > + }
> > +
> > + if (attributes) {
> > + *attributes = var_acc->attr;
> > + if (var_property.property &
> > + VAR_CHECK_VARIABLE_PROPERTY_READ_ONLY)
> > + *attributes |= EFI_VARIABLE_READ_ONLY;
> > + }
> > }
> > - if (ret != EFI_SUCCESS)
> > - goto out;
> >
> > - ret = get_property_int(variable_name, name_size, vendor, _property);
> > if (ret != EFI_SUCCESS)
> > goto out;
> >
> > - if (attributes) {
> > - *attributes = var_acc->attr;
> > - if (var_property.property &
> > VAR_CHECK_VARIABLE_PROPERTY_READ_ONLY)
> > - *attributes |= EFI_VARIABLE_READ_ONLY;
> > - }
> > -
> > if (data)
> > memcpy(data, (u8 *)var_acc->name + var_acc->name_size,
> >var_acc->data_size);
>
Re: [PATCH v4 2/4] clk: imx8mq: Add a clock driver for the imx8mq
Hi Angus, [snip] > > > > Meanwhile I figured out what the problem is with the 'No serial driver > > found'. In the used dtb there are 'assigned-clocks' and > > 'assigned-clock-parents' set in the uart nodes. When removing this the > > serial will work. I have to admit that I do not know why this is set > > that way. I can only imagine that this was taken from the uboot-imx > > tree. > > > > --- > > assigned-clocks = < IMX8MQ_CLK_UART1>; > > assigned-clock-parents = < IMX8MQ_SYS1_PLL_80M>; > > --- > > > > Does that solve the reboot ? Yes, when I remove these assigned-clocks from my dtb the issue is solved and the board finds the serial driver and starts correctly. > > > see also here: > > https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/dts/imx8mq-kontron-pitx-imx8m.dts#L315 > > If that works for Linux it should also work for u-boot. It may be that > the SYS1_PLL_80M isn't set correctly or that the CLK_UART1 mux isn't > correctly setup. If you enable DEBUG in clk-uclass I might be able to > figure out were the problem is. The problem is that the IMX8MQ_CLK_UART1 is not found and that is the reason that the probe fails. I tried to add the missing clocks to how it is done in the kernel. see here: https://pastebin.com/raw/iYYMHEdy But then something went wrong when probing uart3 ... the baudrate switched for the uart2 (console) and the serial output became broken. Later when the kernel starts the output becomes correct again. So the kernel seems to configure it correctly. see here: https://pastebin.com/raw/qXVShb3Q When I remove the "assigned-clock-parents = < IMX8MQ_SYS1_PLL_80M>;" for uart3 the output of uart2 (console) keeps ok. -- Heiko
Re: [PATCH] efi_loader: Set variable attributes when EFI_BUFFER_TOO_SMALL is returned
On 3/16/22 13:55, Ilias Apalodimas wrote:
Starting UEFI Spec 2.8 we must fill in the variable attributes when
GetVariable() returns EFI_BUFFER_TOO_SMALL and Attributes is non-NULL.
This code was written with 2.7 in mind so let's move the code around a
bit and fill in the attributes EFI_BUFFER_TOO_SMALL is returned
In the UEFI spec changelog:
1954 set (*Attributes) when GetVariable() returns EFI_BUFFER_TOO_SMALL
and Attributes is non-NULL
In efi_get_variable_mem() this already works correctly.
Signed-off-by: Ilias Apalodimas
---
lib/efi_loader/efi_variable_tee.c | 27 ++-
1 file changed, 18 insertions(+), 9 deletions(-)
diff --git a/lib/efi_loader/efi_variable_tee.c
b/lib/efi_loader/efi_variable_tee.c
index 58931c4efd74..33c7dfc53d14 100644
--- a/lib/efi_loader/efi_variable_tee.c
+++ b/lib/efi_loader/efi_variable_tee.c
@@ -408,22 +408,31 @@ efi_status_t efi_get_variable_int(const u16
*variable_name,
/* Communicate */
ret = mm_communicate(comm_buf, payload_size);
if (ret == EFI_SUCCESS || ret == EFI_BUFFER_TOO_SMALL) {
You could make the code easier to read with:
if (ret != EFI_SUCCESS && ret != EFI_BUFFER_TOO_SMALL)
goto out;
+ int tmp;
/* Update with reported data size for trimmed case */
*data_size = var_acc->data_size;
+ /*
+* UEFI > 2.7 needs the attributes set even if the buffer is
+* smaller
+*/
+ tmp = get_property_int(variable_name, name_size, vendor,
+ _property);
Why call get_property_int() if (!attributes)?
You don't use the data in this case.
Best regards
Heinrich
+ if (tmp != EFI_SUCCESS) {
+ ret = tmp;
+ goto out;
+ }
+
+ if (attributes) {
+ *attributes = var_acc->attr;
+ if (var_property.property &
+ VAR_CHECK_VARIABLE_PROPERTY_READ_ONLY)
+ *attributes |= EFI_VARIABLE_READ_ONLY;
+ }
}
- if (ret != EFI_SUCCESS)
- goto out;
- ret = get_property_int(variable_name, name_size, vendor, _property);
if (ret != EFI_SUCCESS)
goto out;
- if (attributes) {
- *attributes = var_acc->attr;
- if (var_property.property &
VAR_CHECK_VARIABLE_PROPERTY_READ_ONLY)
- *attributes |= EFI_VARIABLE_READ_ONLY;
- }
-
if (data)
memcpy(data, (u8 *)var_acc->name + var_acc->name_size,
var_acc->data_size);
booting of renesas rcar v3u
Good morning, I am doing my master thesis /w the rcar v3u of renesas and I am facing the issue that the booting of the linux does stop at one point. It seems to be a problem with *Starting Rebuild Dynamic Linker Cache...* and *Starting Network Time Synchronization...*. It gives me the output, that Network Time Synchronization is stopped, because it is not able to be started correctly (even NTP messages are not being sent). It also gives a log like: A start job is running for…amic Linker Cache Is this still part of the u-boot code? Do you have any clue how to resolve this? Or where I could look for a resolution at least? Best regards Thilo Tuschik
RE: Submitting patches for QorIQ components
> -Original Message- > From: Sean Anderson > Sent: Friday, March 4, 2022 1:36 PM > Cc: U-Boot Mailing List ; linux-arm-kernel ker...@lists.infradead.org>; meta-freesc...@lists.yoctoproject.org; Shawn > Guo ; Leo Li ; Ting Liu > ; Jun Zhu ; Ahmed Mansour > ; Zhenhua Luo ; > Priyanka Jain ; Rajesh Bhagat > ; Pramod Kumar ; > Alison Wang ; Mingkai Hu ; > Udit Agarwal ; Otavio Salvador > ; Chunrong Guo > > Subject: Submitting patches for QorIQ components > > Hi all, > > Where should patches for QorIQ components [1] go? I have some patches > for meta-qoriq [2] and dce [3], but I can't figure out where to send them to. > There is no mailing list in the READMEs, and there is no way to send pull > requests like on the former github repos [4]. I tried emailing the most recent > committers directly, but got no response. Hi Sean, These repos are holding stuff that went into formal SDK releases. To get patches in there, patch will need to go into our internal development tree first, and go through the testing and release cycle. Please send your patches to the NXP people included in this thread. And we will try to figure out the people to review and pick it up. Thanks. Regards, Leo
[PATCH] efi_loader: Set variable attributes when EFI_BUFFER_TOO_SMALL is returned
Starting UEFI Spec 2.8 we must fill in the variable attributes when
GetVariable() returns EFI_BUFFER_TOO_SMALL and Attributes is non-NULL.
This code was written with 2.7 in mind so let's move the code around a
bit and fill in the attributes EFI_BUFFER_TOO_SMALL is returned
Signed-off-by: Ilias Apalodimas
---
lib/efi_loader/efi_variable_tee.c | 27 ++-
1 file changed, 18 insertions(+), 9 deletions(-)
diff --git a/lib/efi_loader/efi_variable_tee.c
b/lib/efi_loader/efi_variable_tee.c
index 58931c4efd74..33c7dfc53d14 100644
--- a/lib/efi_loader/efi_variable_tee.c
+++ b/lib/efi_loader/efi_variable_tee.c
@@ -408,22 +408,31 @@ efi_status_t efi_get_variable_int(const u16
*variable_name,
/* Communicate */
ret = mm_communicate(comm_buf, payload_size);
if (ret == EFI_SUCCESS || ret == EFI_BUFFER_TOO_SMALL) {
+ int tmp;
/* Update with reported data size for trimmed case */
*data_size = var_acc->data_size;
+ /*
+* UEFI > 2.7 needs the attributes set even if the buffer is
+* smaller
+*/
+ tmp = get_property_int(variable_name, name_size, vendor,
+ _property);
+ if (tmp != EFI_SUCCESS) {
+ ret = tmp;
+ goto out;
+ }
+
+ if (attributes) {
+ *attributes = var_acc->attr;
+ if (var_property.property &
+ VAR_CHECK_VARIABLE_PROPERTY_READ_ONLY)
+ *attributes |= EFI_VARIABLE_READ_ONLY;
+ }
}
- if (ret != EFI_SUCCESS)
- goto out;
- ret = get_property_int(variable_name, name_size, vendor, _property);
if (ret != EFI_SUCCESS)
goto out;
- if (attributes) {
- *attributes = var_acc->attr;
- if (var_property.property &
VAR_CHECK_VARIABLE_PROPERTY_READ_ONLY)
- *attributes |= EFI_VARIABLE_READ_ONLY;
- }
-
if (data)
memcpy(data, (u8 *)var_acc->name + var_acc->name_size,
var_acc->data_size);
--
2.32.0
Re: Problem to build u-boot
On Wed, Mar 16, 2022 at 3:21 AM Sarmad Ahmad wrote: > > I used the version 2021 now I used the 2022.01 unfortunately still the same > error > followed the instructions on > https://u-boot.readthedocs.io/en/stable/build/source.html > > 1. > git clone https://github.com/u-boot/u-boot > > 2. > cd u-boot > > 3. > git checkout 2022.01 > > 4. > sudo apt-get install gcc gcc-aarch64-linux-gnu > i also tried this > apt-get install crossbuild-essential-armhf > > 5. > sudo apt-get install bc bison build-essential coccinelle \ > device-tree-compiler dfu-util efitools flex gdisk liblz4-tool \ > libguestfs-tools libncurses-dev libpython3-dev libsdl2-dev libssl-dev \ > lzma-alone openssl python3 python3-coverage python3-pyelftools \ > python3-pytest python3-sphinxcontrib.apidoc python3-sphinx-rtd-theme swig > > 6. > export ARCH=arm > > export CROSS_COMPILE=/usr/bin/arm-linux-gnueabihf- > also have export CROSS_COMPILE=arm-linux-gnueabihf- > also have export CROSS_COMPILE=gcc-7-arm-linux-gnueabihf- > > make xilinx_zynq_virt_defconfig > make What is the output you get for the following commands? /usr/bin/arm-linux-gnueabihf-gcc --version export ARCH=arm export CROSS_COMPILE=/usr/bin/arm-linux-gnueabihf- make mrproper make xilinx_zynq_virt_defconfig make
Re: u-boot v2022.01 and Arria-10 socdk not booting
Adding the arria10-socdk board maintainers on Cc On Wed, Mar 16, 2022 at 9:25 AM Marcel Gielen [Celestia-STS] wrote: > > I am working on an Enclustra mercury board and had some issues with booting, > which stopped after (successful) FPGA configuration. (Console: FPGA: Enter > user mode is the last line printed) > > Since we also have an Arria10 socdk available, I decided to try that one. > For the sockdk I have a working sdcard, which also includes a FitImage > containing a peripheral and core rbf. I tried the card (boots) > replaced the bootloader with a vanilla built socfpga_arria10_defconfig and > booting seems to stop at a similar point. Last console message: "early > release succeeded" and then it stops. > > > Am I overlooking something, or are there issues with mainline u-boot and > arria10 ? > > > Any suggestions where to look ? > > > > > >
Re: [PATCH v4 2/4] clk: imx8mq: Add a clock driver for the imx8mq
On 2022-03-16 05:26, Heiko Thiery wrote: Hi, Am Mi., 16. März 2022 um 08:14 Uhr schrieb Heiko Thiery : Hi Angus, Am Di., 15. März 2022 um 16:46 Uhr schrieb Angus Ainslie : > > Hi Heiko, > > On 2022-03-15 08:35, Heiko Thiery wrote: > > Hi Angus and all, > > > > > Am Di., 15. März 2022 um 14:09 Uhr schrieb Angus Ainslie : >> >> This is a DM clock driver based off the imx8mm u-boot driver and the linux >> kernel driver. >> >> All of the PLLs and clocks are initialized so the subsystems below are >> functional and tested. >> >> 1) USB host and peripheral >> 2) ECSPI >> 3) UART >> 4) I2C all busses >> 5) USDHC for eMMC support >> 6) USB storage >> 7) GPIO >> 8) DRAM >> >> > Snip > > > when adding this patch and enabling CLK_IMX8MQ I see the following on my board .. Any idea what I missed here? > > --- >8 --- > U-Boot SPL 2022.04-rc4-8-g390d9bf9a1 (Mar 15 2022 - 16:26:59 +0100) > Trying to boot from SD card > > > U-Boot 2022.04-rc4-8-g390d9bf9a1 (Mar 15 2022 - 16:26:59 +0100) > > CPU: Freescale i.MX8MQ rev2.1 at 800 MHz > Reset cause: POR > Model: Kontron pITX-imx8m > DRAM: alloc space exhausted > alloc space exhausted > alloc space exhausted > alloc space exhausted > alloc space exhausted > alloc space exhausted > alloc space exhausted > alloc space exhausted > alloc space exhausted > alloc space exhausted > alloc space exhausted > alloc space exhausted > 4 GiB > > My guess is that there was static code that was setting up the DRAM pll that isn't get executed now that there's a DM clock driver. > > I'd try enabling DEBUG in the clk-uclass and clk-composite drivers. > > Also look at what DRAM initialization code is not being run now. Our board doesn't have an DRAM specific initialization so there could be a bug in the DRAM setup. The problem was the MALLOC_F_LEN value. Increasing that the "alloc space exhausted" is gone. But with the enabled DM_SERIAL the problem of "No serial driver found" is still there and the board reboots. You said you have DM_SERIAL enabled and it works? Meanwhile I figured out what the problem is with the 'No serial driver found'. In the used dtb there are 'assigned-clocks' and 'assigned-clock-parents' set in the uart nodes. When removing this the serial will work. I have to admit that I do not know why this is set that way. I can only imagine that this was taken from the uboot-imx tree. --- assigned-clocks = < IMX8MQ_CLK_UART1>; assigned-clock-parents = < IMX8MQ_SYS1_PLL_80M>; --- Does that solve the reboot ? see also here: https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/dts/imx8mq-kontron-pitx-imx8m.dts#L315 If that works for Linux it should also work for u-boot. It may be that the SYS1_PLL_80M isn't set correctly or that the CLK_UART1 mux isn't correctly setup. If you enable DEBUG in clk-uclass I might be able to figure out were the problem is.
Re: [PATCH v2] efi_loader: Use sysreset instead of reset command
On 3/16/22 09:03, Masami Hiramatsu wrote:
Use sysreset_walk_halt() directly from reset-after-capsule-on-disk
feature to reboot (cold reset) machine instead of using reset command
interface, since this is not a command.
Note that this will make CONFIG_EFI_CAPSULE_ON_DISK depending on
the CONFIG_SYSRESET.
Signed-off-by: Masami Hiramatsu
Reviewed-by: Heinrich Schuchardt
---
Changes in v2:
- Add CONFIG_SYSRESET dependency.
- Fix to add #include
---
lib/efi_loader/Kconfig |1 +
lib/efi_loader/efi_capsule.c |5 +++--
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
index e5e35fe51f..33138237cc 100644
--- a/lib/efi_loader/Kconfig
+++ b/lib/efi_loader/Kconfig
@@ -130,6 +130,7 @@ config EFI_RUNTIME_UPDATE_CAPSULE
config EFI_CAPSULE_ON_DISK
bool "Enable capsule-on-disk support"
+ depends on SYSRESET
select EFI_HAVE_CAPSULE_SUPPORT
help
Select this option if you want to use capsule-on-disk feature,
diff --git a/lib/efi_loader/efi_capsule.c b/lib/efi_loader/efi_capsule.c
index 613b531b82..a3d1d7e95a 100644
--- a/lib/efi_loader/efi_capsule.c
+++ b/lib/efi_loader/efi_capsule.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include
#include
@@ -1150,9 +1151,9 @@ efi_status_t efi_launch_capsules(void)
* UEFI spec requires to reset system after complete processing capsule
* update on the storage.
*/
- log_info("Reboot after firmware update");
+ log_info("Reboot after firmware update.\n");
/* Cold reset is required for loading the new firmware. */
- do_reset(NULL, 0, 0, NULL);
+ sysreset_walk_halt(SYSRESET_COLD);
hang();
/* not reach here */
Re: [PATCH v4 2/4] clk: imx8mq: Add a clock driver for the imx8mq
Hi, Am Mi., 16. März 2022 um 08:14 Uhr schrieb Heiko Thiery : > > Hi Angus, > > Am Di., 15. März 2022 um 16:46 Uhr schrieb Angus Ainslie > : > > > > Hi Heiko, > > > > On 2022-03-15 08:35, Heiko Thiery wrote: > > > > Hi Angus and all, > > > > > > > > > > Am Di., 15. März 2022 um 14:09 Uhr schrieb Angus Ainslie : > >> > >> This is a DM clock driver based off the imx8mm u-boot driver and the linux > >> kernel driver. > >> > >> All of the PLLs and clocks are initialized so the subsystems below are > >> functional and tested. > >> > >> 1) USB host and peripheral > >> 2) ECSPI > >> 3) UART > >> 4) I2C all busses > >> 5) USDHC for eMMC support > >> 6) USB storage > >> 7) GPIO > >> 8) DRAM > >> > >> > > Snip > > > > > > when adding this patch and enabling CLK_IMX8MQ I see the following on my > > board .. Any idea what I missed here? > > > > --- >8 --- > > U-Boot SPL 2022.04-rc4-8-g390d9bf9a1 (Mar 15 2022 - 16:26:59 +0100) > > Trying to boot from SD card > > > > > > U-Boot 2022.04-rc4-8-g390d9bf9a1 (Mar 15 2022 - 16:26:59 +0100) > > > > CPU: Freescale i.MX8MQ rev2.1 at 800 MHz > > Reset cause: POR > > Model: Kontron pITX-imx8m > > DRAM: alloc space exhausted > > alloc space exhausted > > alloc space exhausted > > alloc space exhausted > > alloc space exhausted > > alloc space exhausted > > alloc space exhausted > > alloc space exhausted > > alloc space exhausted > > alloc space exhausted > > alloc space exhausted > > alloc space exhausted > > 4 GiB > > > > My guess is that there was static code that was setting up the DRAM pll > > that isn't get executed now that there's a DM clock driver. > > > > I'd try enabling DEBUG in the clk-uclass and clk-composite drivers. > > > > Also look at what DRAM initialization code is not being run now. Our board > > doesn't have an DRAM specific initialization so there could be a bug in the > > DRAM setup. > > The problem was the MALLOC_F_LEN value. Increasing that the "alloc > space exhausted" is gone. > > But with the enabled DM_SERIAL the problem of "No serial driver found" > is still there and the board reboots. You said you have DM_SERIAL > enabled and it works? Meanwhile I figured out what the problem is with the 'No serial driver found'. In the used dtb there are 'assigned-clocks' and 'assigned-clock-parents' set in the uart nodes. When removing this the serial will work. I have to admit that I do not know why this is set that way. I can only imagine that this was taken from the uboot-imx tree. --- assigned-clocks = < IMX8MQ_CLK_UART1>; assigned-clock-parents = < IMX8MQ_SYS1_PLL_80M>; --- see also here: https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/dts/imx8mq-kontron-pitx-imx8m.dts#L315 -- Heiko
u-boot v2022.01 and Arria-10 socdk not booting
I am working on an Enclustra mercury board and had some issues with booting, which stopped after (successful) FPGA configuration. (Console: FPGA: Enter user mode is the last line printed) Since we also have an Arria10 socdk available, I decided to try that one. For the sockdk I have a working sdcard, which also includes a FitImage containing a peripheral and core rbf. I tried the card (boots) replaced the bootloader with a vanilla built socfpga_arria10_defconfig and booting seems to stop at a similar point. Last console message: "early release succeeded" and then it stops. Am I overlooking something, or are there issues with mainline u-boot and arria10 ? Any suggestions where to look ?
Re: [PATCH] CI, Docker: Update to latest focal tag
On Tue, Mar 15, 2022 at 04:18:27PM -0400, Tom Rini wrote: > Signed-off-by: Tom Rini Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v4 5/5] test/py: Add tests for the erofs
On Sat, Feb 26, 2022 at 03:05:51PM +0800, Huang Jianan wrote: > Add Python scripts to test 'ls' and 'load' commands, as well as > test related filesystem functions. > > Signed-off-by: Huang Jianan Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v4 4/5] fs/erofs: add filesystem commands
On Sat, Feb 26, 2022 at 03:05:50PM +0800, Huang Jianan wrote: > Add 'ls' and 'load' commands. > > Signed-off-by: Huang Jianan Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v4 3/5] fs/erofs: add lz4 decompression support
On Sat, Feb 26, 2022 at 03:05:49PM +0800, Huang Jianan wrote: > Support EROFS lz4 compressed files. > > Signed-off-by: Huang Jianan Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v4 2/5] lib/lz4: update LZ4 decompressor module
On Sat, Feb 26, 2022 at 03:05:48PM +0800, Huang Jianan wrote: > Update the LZ4 compression module based on LZ4 v1.8.3 in order to > use the newest LZ4_decompress_safe_partial() which can now decode > exactly the nb of bytes requested. > > Signed-off-by: Huang Jianan Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 8/9] arm: dts: imx8mm_evk: add pwm1/backlight support
On Wed, Mar 16, 2022 at 12:54:06PM +0100, Michael Walle wrote:
> Am 2022-03-16 12:51, schrieb Tommaso Merciai:
> > On Wed, Mar 16, 2022 at 12:45:22PM +0100, Michael Walle wrote:
> > > Am 2022-03-16 12:42, schrieb Tommaso Merciai:
> > > > On Wed, Mar 16, 2022 at 11:30:19AM +0100, Michael Walle wrote:
> > > > > > Add pwm1/backlight support nodes for imx8mm_evk board
> > > > > >
> > > > > > Signed-off-by: Tommaso Merciai
> > > > > >
> > > > > > ---
> > > > > > arch/arm/dts/imx8mm-evk.dtsi | 21 +
> > > > > > 1 file changed, 21 insertions(+)
> > > > > >
> > > > > > diff --git a/arch/arm/dts/imx8mm-evk.dtsi
> > > > > > b/arch/arm/dts/imx8mm-evk.dtsi
> > > > > > index 60179e006d..e7a2bd8a64 100644
> > > > > > --- a/arch/arm/dts/imx8mm-evk.dtsi
> > > > > > +++ b/arch/arm/dts/imx8mm-evk.dtsi
> > > > > > @@ -41,6 +41,15 @@
> > > > > > enable-active-high;
> > > > > > };
> > > > > >
> > > > > > + backlight: backlight {
> > > > > > + status = "disabled";
> > > > > > + compatible = "pwm-backlight";
> > > > > > + pwms = < 0 500>;
> > > > > > + brightness-levels = <0 255>;
> > > > > > + num-interpolated-steps = <255>;
> > > > > > + default-brightness-level = <250>;
> > > > > > + };
> > > > > > +
> > > > > > ir-receiver {
> > > > > > compatible = "gpio-ir-receiver";
> > > > > > gpios = < 13 GPIO_ACTIVE_LOW>;
> > > > > > @@ -350,6 +359,12 @@
> > > > > > status = "okay";
> > > > > > };
> > > > > >
> > > > > > + {
> > > > > > + pinctrl-names = "default";
> > > > > > + pinctrl-0 = <_backlight>;
> > > > > > + status = "disabled";
> > > > > > +};
> > > > > > +
> > > > > > {
> > > > > > pinctrl_fec1: fec1grp {
> > > > > > fsl,pins = <
> > > > > > @@ -491,4 +506,10 @@
> > > > > > MX8MM_IOMUXC_GPIO1_IO02_WDOG1_WDOG_B0x166
> > > > > > >;
> > > > > > };
> > > > > > +
> > > > > > + pinctrl_backlight: backlightgrp {
> > > > > > + fsl,pins = <
> > > > > > + MX8MM_IOMUXC_GPIO1_IO01_PWM1_OUT0x06
> > > > > > + >;
> > > > > > + };
> > > > >
> > > > > Will this also be submitted to upstream linux? Otherwise, the device
> > > > > trees will diverge.
> > > > >
> > > > > -michael
> > > >
> > > > Hi,
> > > > At the moment on upstream linux, backlight on pwm1 is not handle. This
> > > > will also be submitted on upstream Linux once will merged on U-Boot.
> > >
> > > Actually, it should be the other way around, because the device trees
> > > should be synced with linux once in a while. So while I don't oppose
> > > to do it this way, your changes might eventually be overwritten if
> > > this won't be merged with linux.
> > >
> > > -michael
> >
> > Hi Michael,
> > Then you suggest to submit to the Kernel also?
>
> The goal should be to have the kernel device trees in sync with
> the kernel. So yes, it should also be submitted to the kernel
> device tree.
>
> -michael
Hi Michael,
Thanks for your suggestion, then I will also send this on the Kernel :)
Tommaso
--
Tommaso Merciai
Embedded Linux Engineer
tommaso.merc...@amarulasolutions.com
__
Amarula Solutions SRL
Via Le Canevare 30, 31100 Treviso, Veneto, IT
T. +39 042 243 5310
i...@amarulasolutions.com
www.amarulasolutions.com
Re: [PATCH v4 1/5] fs/erofs: add erofs filesystem support
On Sat, Feb 26, 2022 at 03:05:47PM +0800, Huang Jianan wrote: > This patch mainly deals with uncompressed files. > > Signed-off-by: Huang Jianan Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] doc: uefi: Fix reference to CONFIG_EFI_SECURE_BOOT
On 3/16/22 12:12, Jan Kiszka wrote: From: Jan Kiszka There is no CONFIG_UEFI_SECURE_BOOT, and there was never any. Signed-off-by: Jan Kiszka Reviewed-by: Heinrich Schuchardt --- Was briefly nervous finding only the documentation but no implementation yet. ;) doc/develop/uefi/uefi.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/develop/uefi/uefi.rst b/doc/develop/uefi/uefi.rst index b7bf1356276..fe337c88bda 100644 --- a/doc/develop/uefi/uefi.rst +++ b/doc/develop/uefi/uefi.rst @@ -105,7 +105,7 @@ The UEFI specification[1] defines a secure way of executing UEFI images by verifying a signature (or message digest) of image with certificates. This feature on U-Boot is enabled with:: -CONFIG_UEFI_SECURE_BOOT=y +CONFIG_EFI_SECURE_BOOT=y To make the boot sequence safe, you need to establish a chain of trust; In UEFI secure boot the chain trust is defined by the following UEFI variables
Re: [PATCH 8/9] arm: dts: imx8mm_evk: add pwm1/backlight support
Am 2022-03-16 12:51, schrieb Tommaso Merciai:
On Wed, Mar 16, 2022 at 12:45:22PM +0100, Michael Walle wrote:
Am 2022-03-16 12:42, schrieb Tommaso Merciai:
> On Wed, Mar 16, 2022 at 11:30:19AM +0100, Michael Walle wrote:
> > > Add pwm1/backlight support nodes for imx8mm_evk board
> > >
> > > Signed-off-by: Tommaso Merciai
> > > ---
> > > arch/arm/dts/imx8mm-evk.dtsi | 21 +
> > > 1 file changed, 21 insertions(+)
> > >
> > > diff --git a/arch/arm/dts/imx8mm-evk.dtsi b/arch/arm/dts/imx8mm-evk.dtsi
> > > index 60179e006d..e7a2bd8a64 100644
> > > --- a/arch/arm/dts/imx8mm-evk.dtsi
> > > +++ b/arch/arm/dts/imx8mm-evk.dtsi
> > > @@ -41,6 +41,15 @@
> > > enable-active-high;
> > > };
> > >
> > > +backlight: backlight {
> > > +status = "disabled";
> > > +compatible = "pwm-backlight";
> > > +pwms = < 0 500>;
> > > +brightness-levels = <0 255>;
> > > +num-interpolated-steps = <255>;
> > > +default-brightness-level = <250>;
> > > +};
> > > +
> > > ir-receiver {
> > > compatible = "gpio-ir-receiver";
> > > gpios = < 13 GPIO_ACTIVE_LOW>;
> > > @@ -350,6 +359,12 @@
> > > status = "okay";
> > > };
> > >
> > > + {
> > > +pinctrl-names = "default";
> > > +pinctrl-0 = <_backlight>;
> > > +status = "disabled";
> > > +};
> > > +
> > > {
> > > pinctrl_fec1: fec1grp {
> > > fsl,pins = <
> > > @@ -491,4 +506,10 @@
> > > MX8MM_IOMUXC_GPIO1_IO02_WDOG1_WDOG_B0x166
> > > >;
> > > };
> > > +
> > > +pinctrl_backlight: backlightgrp {
> > > +fsl,pins = <
> > > +MX8MM_IOMUXC_GPIO1_IO01_PWM1_OUT0x06
> > > +>;
> > > +};
> >
> > Will this also be submitted to upstream linux? Otherwise, the device
> > trees will diverge.
> >
> > -michael
>
> Hi,
> At the moment on upstream linux, backlight on pwm1 is not handle. This
> will also be submitted on upstream Linux once will merged on U-Boot.
Actually, it should be the other way around, because the device trees
should be synced with linux once in a while. So while I don't oppose
to do it this way, your changes might eventually be overwritten if
this won't be merged with linux.
-michael
Hi Michael,
Then you suggest to submit to the Kernel also?
The goal should be to have the kernel device trees in sync with
the kernel. So yes, it should also be submitted to the kernel
device tree.
-michael
Re: [PATCH 8/9] arm: dts: imx8mm_evk: add pwm1/backlight support
On Wed, Mar 16, 2022 at 12:45:22PM +0100, Michael Walle wrote:
> Am 2022-03-16 12:42, schrieb Tommaso Merciai:
> > On Wed, Mar 16, 2022 at 11:30:19AM +0100, Michael Walle wrote:
> > > > Add pwm1/backlight support nodes for imx8mm_evk board
> > > >
> > > > Signed-off-by: Tommaso Merciai
> > > > ---
> > > > arch/arm/dts/imx8mm-evk.dtsi | 21 +
> > > > 1 file changed, 21 insertions(+)
> > > >
> > > > diff --git a/arch/arm/dts/imx8mm-evk.dtsi b/arch/arm/dts/imx8mm-evk.dtsi
> > > > index 60179e006d..e7a2bd8a64 100644
> > > > --- a/arch/arm/dts/imx8mm-evk.dtsi
> > > > +++ b/arch/arm/dts/imx8mm-evk.dtsi
> > > > @@ -41,6 +41,15 @@
> > > > enable-active-high;
> > > > };
> > > >
> > > > + backlight: backlight {
> > > > + status = "disabled";
> > > > + compatible = "pwm-backlight";
> > > > + pwms = < 0 500>;
> > > > + brightness-levels = <0 255>;
> > > > + num-interpolated-steps = <255>;
> > > > + default-brightness-level = <250>;
> > > > + };
> > > > +
> > > > ir-receiver {
> > > > compatible = "gpio-ir-receiver";
> > > > gpios = < 13 GPIO_ACTIVE_LOW>;
> > > > @@ -350,6 +359,12 @@
> > > > status = "okay";
> > > > };
> > > >
> > > > + {
> > > > + pinctrl-names = "default";
> > > > + pinctrl-0 = <_backlight>;
> > > > + status = "disabled";
> > > > +};
> > > > +
> > > > {
> > > > pinctrl_fec1: fec1grp {
> > > > fsl,pins = <
> > > > @@ -491,4 +506,10 @@
> > > > MX8MM_IOMUXC_GPIO1_IO02_WDOG1_WDOG_B0x166
> > > > >;
> > > > };
> > > > +
> > > > + pinctrl_backlight: backlightgrp {
> > > > + fsl,pins = <
> > > > + MX8MM_IOMUXC_GPIO1_IO01_PWM1_OUT0x06
> > > > + >;
> > > > + };
> > >
> > > Will this also be submitted to upstream linux? Otherwise, the device
> > > trees will diverge.
> > >
> > > -michael
> >
> > Hi,
> > At the moment on upstream linux, backlight on pwm1 is not handle. This
> > will also be submitted on upstream Linux once will merged on U-Boot.
>
> Actually, it should be the other way around, because the device trees
> should be synced with linux once in a while. So while I don't oppose
> to do it this way, your changes might eventually be overwritten if
> this won't be merged with linux.
>
> -michael
Hi Michael,
Then you suggest to submit to the Kernel also?
Thanks,
Tommaso
--
Tommaso Merciai
Embedded Linux Engineer
tommaso.merc...@amarulasolutions.com
__
Amarula Solutions SRL
Via Le Canevare 30, 31100 Treviso, Veneto, IT
T. +39 042 243 5310
i...@amarulasolutions.com
www.amarulasolutions.com
Re: [PATCH 8/9] arm: dts: imx8mm_evk: add pwm1/backlight support
Am 2022-03-16 12:42, schrieb Tommaso Merciai:
On Wed, Mar 16, 2022 at 11:30:19AM +0100, Michael Walle wrote:
> Add pwm1/backlight support nodes for imx8mm_evk board
>
> Signed-off-by: Tommaso Merciai
> ---
> arch/arm/dts/imx8mm-evk.dtsi | 21 +
> 1 file changed, 21 insertions(+)
>
> diff --git a/arch/arm/dts/imx8mm-evk.dtsi b/arch/arm/dts/imx8mm-evk.dtsi
> index 60179e006d..e7a2bd8a64 100644
> --- a/arch/arm/dts/imx8mm-evk.dtsi
> +++ b/arch/arm/dts/imx8mm-evk.dtsi
> @@ -41,6 +41,15 @@
>enable-active-high;
>};
>
> + backlight: backlight {
> + status = "disabled";
> + compatible = "pwm-backlight";
> + pwms = < 0 500>;
> + brightness-levels = <0 255>;
> + num-interpolated-steps = <255>;
> + default-brightness-level = <250>;
> + };
> +
>ir-receiver {
>compatible = "gpio-ir-receiver";
>gpios = < 13 GPIO_ACTIVE_LOW>;
> @@ -350,6 +359,12 @@
>status = "okay";
> };
>
> + {
> + pinctrl-names = "default";
> + pinctrl-0 = <_backlight>;
> + status = "disabled";
> +};
> +
> {
>pinctrl_fec1: fec1grp {
>fsl,pins = <
> @@ -491,4 +506,10 @@
>MX8MM_IOMUXC_GPIO1_IO02_WDOG1_WDOG_B0x166
>>;
>};
> +
> + pinctrl_backlight: backlightgrp {
> + fsl,pins = <
> + MX8MM_IOMUXC_GPIO1_IO01_PWM1_OUT0x06
> + >;
> + };
Will this also be submitted to upstream linux? Otherwise, the device
trees will diverge.
-michael
Hi,
At the moment on upstream linux, backlight on pwm1 is not handle. This
will also be submitted on upstream Linux once will merged on U-Boot.
Actually, it should be the other way around, because the device trees
should be synced with linux once in a while. So while I don't oppose
to do it this way, your changes might eventually be overwritten if
this won't be merged with linux.
-michael
Re: [PATCH 8/9] arm: dts: imx8mm_evk: add pwm1/backlight support
On Wed, Mar 16, 2022 at 11:30:19AM +0100, Michael Walle wrote:
> > Add pwm1/backlight support nodes for imx8mm_evk board
> >
> > Signed-off-by: Tommaso Merciai
> > ---
> > arch/arm/dts/imx8mm-evk.dtsi | 21 +
> > 1 file changed, 21 insertions(+)
> >
> > diff --git a/arch/arm/dts/imx8mm-evk.dtsi b/arch/arm/dts/imx8mm-evk.dtsi
> > index 60179e006d..e7a2bd8a64 100644
> > --- a/arch/arm/dts/imx8mm-evk.dtsi
> > +++ b/arch/arm/dts/imx8mm-evk.dtsi
> > @@ -41,6 +41,15 @@
> > enable-active-high;
> > };
> >
> > + backlight: backlight {
> > + status = "disabled";
> > + compatible = "pwm-backlight";
> > + pwms = < 0 500>;
> > + brightness-levels = <0 255>;
> > + num-interpolated-steps = <255>;
> > + default-brightness-level = <250>;
> > + };
> > +
> > ir-receiver {
> > compatible = "gpio-ir-receiver";
> > gpios = < 13 GPIO_ACTIVE_LOW>;
> > @@ -350,6 +359,12 @@
> > status = "okay";
> > };
> >
> > + {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <_backlight>;
> > + status = "disabled";
> > +};
> > +
> > {
> > pinctrl_fec1: fec1grp {
> > fsl,pins = <
> > @@ -491,4 +506,10 @@
> > MX8MM_IOMUXC_GPIO1_IO02_WDOG1_WDOG_B0x166
> > >;
> > };
> > +
> > + pinctrl_backlight: backlightgrp {
> > + fsl,pins = <
> > + MX8MM_IOMUXC_GPIO1_IO01_PWM1_OUT0x06
> > + >;
> > + };
>
> Will this also be submitted to upstream linux? Otherwise, the device
> trees will diverge.
>
> -michael
Hi,
At the moment on upstream linux, backlight on pwm1 is not handle. This
will also be submitted on upstream Linux once will merged on U-Boot.
Regards,
Tommaso
--
Tommaso Merciai
Embedded Linux Engineer
tommaso.merc...@amarulasolutions.com
__
Amarula Solutions SRL
Via Le Canevare 30, 31100 Treviso, Veneto, IT
T. +39 042 243 5310
i...@amarulasolutions.com
www.amarulasolutions.com
Re: [PATCH 8/9] arm: dts: imx8mm_evk: add pwm1/backlight support
On Wed, Mar 16, 2022 at 11:30:19AM +0100, Michael Walle wrote:
> > Add pwm1/backlight support nodes for imx8mm_evk board
> >
> > Signed-off-by: Tommaso Merciai
> > ---
> > arch/arm/dts/imx8mm-evk.dtsi | 21 +
> > 1 file changed, 21 insertions(+)
> >
> > diff --git a/arch/arm/dts/imx8mm-evk.dtsi b/arch/arm/dts/imx8mm-evk.dtsi
> > index 60179e006d..e7a2bd8a64 100644
> > --- a/arch/arm/dts/imx8mm-evk.dtsi
> > +++ b/arch/arm/dts/imx8mm-evk.dtsi
> > @@ -41,6 +41,15 @@
> > enable-active-high;
> > };
> >
> > + backlight: backlight {
> > + status = "disabled";
> > + compatible = "pwm-backlight";
> > + pwms = < 0 500>;
> > + brightness-levels = <0 255>;
> > + num-interpolated-steps = <255>;
> > + default-brightness-level = <250>;
> > + };
> > +
> > ir-receiver {
> > compatible = "gpio-ir-receiver";
> > gpios = < 13 GPIO_ACTIVE_LOW>;
> > @@ -350,6 +359,12 @@
> > status = "okay";
> > };
> >
> > + {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <_backlight>;
> > + status = "disabled";
> > +};
> > +
> > {
> > pinctrl_fec1: fec1grp {
> > fsl,pins = <
> > @@ -491,4 +506,10 @@
> > MX8MM_IOMUXC_GPIO1_IO02_WDOG1_WDOG_B0x166
> > >;
> > };
> > +
> > + pinctrl_backlight: backlightgrp {
> > + fsl,pins = <
> > + MX8MM_IOMUXC_GPIO1_IO01_PWM1_OUT0x06
> > + >;
> > + };
>
> Will this also be submitted to upstream linux? Otherwise, the device
> trees will diverge.
>
> -michael
Hi Michael,
Thanks for review, I'll check and update in v2.
Tommaso
--
Tommaso Merciai
Embedded Linux Engineer
tommaso.merc...@amarulasolutions.com
__
Amarula Solutions SRL
Via Le Canevare 30, 31100 Treviso, Veneto, IT
T. +39 042 243 5310
i...@amarulasolutions.com
www.amarulasolutions.com
[PATCH] doc: uefi: Fix reference to CONFIG_EFI_SECURE_BOOT
From: Jan Kiszka There is no CONFIG_UEFI_SECURE_BOOT, and there was never any. Signed-off-by: Jan Kiszka --- Was briefly nervous finding only the documentation but no implementation yet. ;) doc/develop/uefi/uefi.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/develop/uefi/uefi.rst b/doc/develop/uefi/uefi.rst index b7bf1356276..fe337c88bda 100644 --- a/doc/develop/uefi/uefi.rst +++ b/doc/develop/uefi/uefi.rst @@ -105,7 +105,7 @@ The UEFI specification[1] defines a secure way of executing UEFI images by verifying a signature (or message digest) of image with certificates. This feature on U-Boot is enabled with:: -CONFIG_UEFI_SECURE_BOOT=y +CONFIG_EFI_SECURE_BOOT=y To make the boot sequence safe, you need to establish a chain of trust; In UEFI secure boot the chain trust is defined by the following UEFI variables -- 2.34.1
Re: [PATCH v4] wdt: nuvoton: Add support for Nuvoton
On Tue, 15 Mar 2022 10:14:16 +0800
Jim Liu wrote:
> Add watchdog controller driver for NPCM7xx/npcm8xx
>
> Signed-off-by: Jim Liu
> Reviewed-by: Stefan Roese
>
> Changes for v4:
>- add a bit of detail about the device in Kconfig
>- lower-case hex change
>- remove the reset function delay.Actually when
> setting writel NPCM_WTR the watchdog is resetting the BMC
> ---
> drivers/watchdog/Kconfig| 8 +++
> drivers/watchdog/Makefile | 1 +
> drivers/watchdog/npcm_wdt.c | 117
> 3 files changed, 126 insertions(+)
> create mode 100644 drivers/watchdog/npcm_wdt.c
>
> diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
> index f90f0ca02b..d33882fb6a 100644
> --- a/drivers/watchdog/Kconfig
> +++ b/drivers/watchdog/Kconfig
> @@ -196,6 +196,14 @@ config WDT_MTK
> The watchdog timer is stopped when initialized.
> It performs full SoC reset.
>
> +config WDT_NPCM
> + bool "Nuvoton watchdog timer support"
> + depends on WDT && ARCH_NPCM
> + help
> + This enables Nuvoton npcm7xx/npcm8xx watchdog timer driver,
> + The watchdog timer is stopped when initialized.
> + It performs full SoC reset.
> +
> config WDT_OCTEONTX
> bool "OcteonTX core watchdog support"
> depends on WDT && (ARCH_OCTEONTX || ARCH_OCTEONTX2)
> diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
> index a35bd559f5..1089cd21f5 100644
> --- a/drivers/watchdog/Makefile
> +++ b/drivers/watchdog/Makefile
> @@ -31,6 +31,7 @@ obj-$(CONFIG_WDT_MPC8xx) += mpc8xx_wdt.o
> obj-$(CONFIG_WDT_MT7620) += mt7620_wdt.o
> obj-$(CONFIG_WDT_MT7621) += mt7621_wdt.o
> obj-$(CONFIG_WDT_MTK) += mtk_wdt.o
> +obj-$(CONFIG_WDT_NPCM) += npcm_wdt.o
> obj-$(CONFIG_WDT_OCTEONTX) += octeontx_wdt.o
> obj-$(CONFIG_WDT_OMAP3) += omap_wdt.o
> obj-$(CONFIG_WDT_SBSA) += sbsa_gwdt.o
> diff --git a/drivers/watchdog/npcm_wdt.c b/drivers/watchdog/npcm_wdt.c
> new file mode 100644
> index 00..0aedb2fbe7
> --- /dev/null
> +++ b/drivers/watchdog/npcm_wdt.c
> @@ -0,0 +1,117 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (c) 2022 Nuvoton Technology, Inc
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define NPCM_WTCLK (BIT(10) | BIT(11)) /* Clock divider */
> +#define NPCM_WTE BIT(7) /* Enable */
> +#define NPCM_WTIEBIT(6) /* Enable irq */
> +#define NPCM_WTIS(BIT(4) | BIT(5)) /* Interval selection */
> +#define NPCM_WTIFBIT(3) /* Interrupt flag*/
> +#define NPCM_WTRFBIT(2) /* Reset flag */
> +#define NPCM_WTREBIT(1) /* Reset enable */
> +#define NPCM_WTR BIT(0) /* Reset counter */
> +
> +struct npcm_wdt_priv {
> + void __iomem *regs;
> +};
> +
> +static int npcm_wdt_start(struct udevice *dev, u64 timeout_ms, ulong flags)
> +{
> + struct npcm_wdt_priv *priv = dev_get_priv(dev);
> + u32 time_out, val;
> +
> + time_out = (u32)(timeout_ms) / 1000;
> + if (time_out < 2)
> + val = 0x800;
> + else if (time_out < 3)
> + val = 0x420;
> + else if (time_out < 6)
> + val = 0x810;
> + else if (time_out < 11)
> + val = 0x430;
> + else if (time_out < 22)
> + val = 0x820;
> + else if (time_out < 44)
> + val = 0xc00;
> + else if (time_out < 87)
> + val = 0x830;
> + else if (time_out < 173)
> + val = 0xc10;
> + else if (time_out < 688)
> + val = 0xc20;
> + else
> + val = 0xc30;
> +
> + val |= NPCM_WTRE | NPCM_WTE | NPCM_WTR | NPCM_WTIE;
> + writel(val, priv->regs);
> +
> + return 0;
> +}
> +
> +static int npcm_wdt_stop(struct udevice *dev)
> +{
> + struct npcm_wdt_priv *priv = dev_get_priv(dev);
> +
> + writel(0, priv->regs);
> +
> + return 0;
> +}
> +
> +static int npcm_wdt_reset(struct udevice *dev)
> +{
> + struct npcm_wdt_priv *priv = dev_get_priv(dev);
> +
> + writel(NPCM_WTR | NPCM_WTRE | NPCM_WTE, priv->regs);
> +
> + return 0;
> +}
> +
> +static int npcm_wdt_of_to_plat(struct udevice *dev)
> +{
> + struct npcm_wdt_priv *priv = dev_get_priv(dev);
> +
> + priv->regs = dev_read_addr_ptr(dev);
> + if (!priv->regs)
> + return -EINVAL;
> +
> + return 0;
> +}
> +
> +static const struct wdt_ops npcm_wdt_ops = {
> + .start = npcm_wdt_start,
> + .reset = npcm_wdt_reset,
> + .stop = npcm_wdt_stop,
> +};
> +
> +static const struct udevice_id npcm_wdt_ids[] = {
> + { .compatible = "nuvoton,npcm750-wdt" },
> + { .compatible = "nuvoton,npcm845-wdt" },
Do we really need a second compatible string listed here? From this
driver's perspective both seem to be compatible, are there other
features (not used by U-Boot) which differ?
From a quick search I couldn't find a binding or other
Re: [PATCH 8/9] arm: dts: imx8mm_evk: add pwm1/backlight support
> Add pwm1/backlight support nodes for imx8mm_evk board
>
> Signed-off-by: Tommaso Merciai
> ---
> arch/arm/dts/imx8mm-evk.dtsi | 21 +
> 1 file changed, 21 insertions(+)
>
> diff --git a/arch/arm/dts/imx8mm-evk.dtsi b/arch/arm/dts/imx8mm-evk.dtsi
> index 60179e006d..e7a2bd8a64 100644
> --- a/arch/arm/dts/imx8mm-evk.dtsi
> +++ b/arch/arm/dts/imx8mm-evk.dtsi
> @@ -41,6 +41,15 @@
> enable-active-high;
> };
>
> + backlight: backlight {
> + status = "disabled";
> + compatible = "pwm-backlight";
> + pwms = < 0 500>;
> + brightness-levels = <0 255>;
> + num-interpolated-steps = <255>;
> + default-brightness-level = <250>;
> + };
> +
> ir-receiver {
> compatible = "gpio-ir-receiver";
> gpios = < 13 GPIO_ACTIVE_LOW>;
> @@ -350,6 +359,12 @@
> status = "okay";
> };
>
> + {
> + pinctrl-names = "default";
> + pinctrl-0 = <_backlight>;
> + status = "disabled";
> +};
> +
> {
> pinctrl_fec1: fec1grp {
> fsl,pins = <
> @@ -491,4 +506,10 @@
> MX8MM_IOMUXC_GPIO1_IO02_WDOG1_WDOG_B0x166
> >;
> };
> +
> + pinctrl_backlight: backlightgrp {
> + fsl,pins = <
> + MX8MM_IOMUXC_GPIO1_IO01_PWM1_OUT0x06
> + >;
> + };
Will this also be submitted to upstream linux? Otherwise, the device
trees will diverge.
-michael
[GIT PULL] Please pull u-boot-mmc master
Dear Tom, Please pull u-boot-mmc master into u-boot master branch. If there is any problem, let me know, plz. Sorry for late. Best Regards, Jaehoon Chung CI: https://source.denx.de/u-boot/custodians/u-boot-mmc/-/pipelines/11304 The following changes since commit 4dc9b1771b152838ddfc4ae86a0ab9fd53ea16f7: Merge https://source.denx.de/u-boot/custodians/u-boot-usb (2022-03-14 22:54:53 -0400) are available in the Git repository at: g...@source.denx.de:u-boot/custodians/u-boot-mmc.git master for you to fetch changes up to c48021d184097ea4a1bb6bab8c24653de2477fde: rockchip: sdhci: Add HS400 Enhanced Strobe support for RK3568 (2022-03-16 18:10:41 +0900) Alper Nebi Yasak (3): mmc: sdhci: Add HS400 Enhanced Strobe support rockchip: sdhci: Add HS400 Enhanced Strobe support for RK3399 rockchip: sdhci: Add HS400 Enhanced Strobe support for RK3568 Haibo Chen (1): mmc: fsl_esdhc_imx: use VENDORSPEC_FRC_SDCLK_ON when necessary Max Merchel (1): cmd/mmc: fix output of mmc info for e-MMC Robert Marko (1): mmc: xenon_sdhci: remove wait_dat0 SDHCI OP cmd/mmc.c| 16 -- drivers/mmc/fsl_esdhc_imx.c | 25 +++-- drivers/mmc/rockchip_sdhci.c | 117 --- drivers/mmc/sdhci.c | 18 +++ drivers/mmc/xenon_sdhci.c| 7 ++- include/fsl_esdhc_imx.h | 2 + include/sdhci.h | 12 + 7 files changed, 183 insertions(+), 14 deletions(-)
Re: [PATCH v5 0/3] rockchip: sdhci: Add HS400 Enhanced Strobe support
Hi, On 3/16/22 02:46, Alper Nebi Yasak wrote: > This series implements support for the HS400 Enhanced Strobe mode on the > Rockchip SDHCI driver, for both RK3399 and RK3568. To test, I'm building > for chromebook_kevin with the following configs enabled: > > +CONFIG_MMC_SPEED_MODE_SET=y > [...] > CONFIG_MMC_PWRSEQ=y > +CONFIG_MMC_IO_VOLTAGE=y > +CONFIG_MMC_UHS_SUPPORT=y > +CONFIG_MMC_HS400_ES_SUPPORT=y > +CONFIG_MMC_HS400_SUPPORT=y > CONFIG_MMC_DW=y > CONFIG_MMC_DW_ROCKCHIP=y > CONFIG_MMC_SDHCI=y > +CONFIG_MMC_SDHCI_SDMA=y > CONFIG_MMC_SDHCI_ROCKCHIP=y > > and running roughly: > > $ mmc rescan [0|1|3|10|11|12] > $ mmc info > $ mmc part > $ load mmc 0:1 0xd000 256MiB.bin > $ load mmc 0:1 0xd000 16MiB.bin > $ load mmc 0:1 0xd000 8MiB.bin > > Here's the differences in info and speeds I get with this: > > Mode | Bus Speed| Bus Width > ---+--+-- > MMC Legacy | 2500 | 8-bit > MMC High Speed (26MHz) | 2600 | 8-bit > MMC High Speed (52MHz) | 5200 | 8-bit > HS200 (200MHz) | 2| 8-bit > HS400 (200MHz) | 2| 8-bit DDR > HS400ES (200MHz) | 2| 8-bit DDR > > Mode | 256 MiB Load | 16 MiB Load | 8 MiB Load > ---+--+--+-- > MMC Legacy | ~22.1 MiB/s | ~21.9 MiB/s | ~21.6 MiB/s > MMC High Speed (26MHz) | ~22.1 MiB/s | ~21.9 MiB/s | ~21.6 MiB/s > MMC High Speed (52MHz) | ~43.7 MiB/s | ~42.8 MiB/s | ~41.7 MiB/s > HS200 (200MHz) | ~161.2 MiB/s | ~149.5 MiB/s | ~137.9 MiB/s > HS400 (200MHz) | ~254.5 MiB/s | ~235.3 MiB/s | ~216.2 MiB/s > HS400ES (200MHz) | ~254.7 MiB/s | ~238.8 MiB/s | ~216.2 MiB/s > > Hope I haven't missed anything. Enabling the configs above for each > board is left to board maintainers as I can't test on those boards. > > Changes in v5: > - Incorporate RK3568 HS400ES fixes from Yifeng Zhao: > - Use DWCMSHC_CTRL_HS400 = 0x7, instead of SDHCI_CTRL_HS400 = 0x5 > - Configure DWCMSHC_CARD_IS_EMMC in rk3568_sdhci_set_ios_post() > - Configure DLL_STRBIN and DLL_TXCLK for HS400. > - Drop re-init fix already merged to master > > v4: > https://protect2.fireeye.com/v1/url?k=1188e6ba-7003f38c-11896df5-74fe485cbff1-62638f65a0b40d18=1=1d5ef967-0e2c-4678-89d3-9c866ce2121b=https%3A%2F%2Fpatchwork.ozlabs.org%2Fproject%2Fuboot%2Flist%2F%3Fseries%3D283482%26state%3D%2A > > Changes in v4: > - Add comment for SDHCI set_enhanced_strobe() operation > - Add comment for Rockchip SDHCI set_enhanced_strobe() driver data op > > v3: > https://protect2.fireeye.com/v1/url?k=e0d60bb1-815d1e87-e0d780fe-74fe485cbff1-ae754d5cb8424c27=1=1d5ef967-0e2c-4678-89d3-9c866ce2121b=https%3A%2F%2Fpatchwork.ozlabs.org%2Fproject%2Fuboot%2Flist%2F%3Fseries%3D281327%26state%3D%2A > > Changes in v3: > - Set DWCMSHC_CARD_IS_EMMC bit in rk3568_emmc_phy_init() > > v2: > https://protect2.fireeye.com/v1/url?k=418d7235-20066703-418cf97a-74fe485cbff1-5208c5c7e2a5cf22=1=1d5ef967-0e2c-4678-89d3-9c866ce2121b=https%3A%2F%2Fpatchwork.ozlabs.org%2Fproject%2Fuboot%2Flist%2F%3Fseries%3D280494%26state%3D%2A > > Changes in v2: > - Unset ES bit in rk3399 set_control_reg() to fix a reinit issue > - Don't use unnecessary & for function pointer in ops struct > - Rename rk3399_set_enhanced_strobe -> rk3399_sdhci_set_enhanced_strobe > - Rename rk3568_set_enhanced_strobe -> rk3568_sdhci_set_enhanced_strobe > - Let set_enhanced_strobe() unset the ES bit if mode is not HS400_ES > - Rewrote cover letter > > v1: > https://protect2.fireeye.com/v1/url?k=7057862b-11dc931d-70560d64-74fe485cbff1-6d7b0ff32c53c391=1=1d5ef967-0e2c-4678-89d3-9c866ce2121b=https%3A%2F%2Fpatchwork.ozlabs.org%2Fproject%2Fuboot%2Flist%2F%3Fseries%3D269768%26state%3D%2A > > Alper Nebi Yasak (3): > mmc: sdhci: Add HS400 Enhanced Strobe support > rockchip: sdhci: Add HS400 Enhanced Strobe support for RK3399 > rockchip: sdhci: Add HS400 Enhanced Strobe support for RK3568 > > drivers/mmc/rockchip_sdhci.c | 117 +-- > drivers/mmc/sdhci.c | 18 ++ > include/sdhci.h | 12 > 3 files changed, 141 insertions(+), 6 deletions(-) Applied to u-boot-mmc. Best Regards, Jaehoon Chung >
Re: [PATCH 2/2] pmic: pca9450: Add regulator driver
On 3/16/22 08:40, Jaehoon Chung wrote: Hi Marek, Hi, On 3/11/22 05:28, Marek Vasut wrote: Add PCA9450 regulator driver. This is complementary driver for the BUCKn and LDOn regulators provided by the PCA9450 PMIC driver. Currently the driver permits reading the settngs and configuring the BUCKn and LDOn regulators. This patch can't apply from patchwork. Is there any other patches before apply this? Try https://patchwork.ozlabs.org/project/uboot/patch/20220226033708.95518-1-ma...@denx.de/
Re: [PATCH] mtd: spi-nor-ids: Add Winbond W25Q128JW ID
On 3/16/22 04:55, tudor.amba...@microchip.com wrote:
Hi,
[...]
drivers/mtd/spi/spi-nor-ids.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
index b551ebd75ef..e2d09fc747d 100644
--- a/drivers/mtd/spi/spi-nor-ids.c
+++ b/drivers/mtd/spi/spi-nor-ids.c
@@ -345,6 +345,11 @@ const struct flash_info spi_nor_ids[] = {
SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB)
},
+ {
+ INFO("w25q128jw", 0xef8018, 0, 64 * 1024, 256,
I'm glad I can discuss with you about the name of these winbond flashes,
you can help with an advice. In linux we name this flash "w25q128jwm",
but maybe we should change it.
How did you arrive at "jwm" suffix ? Per both [1] and [2] "11.1 Valid
by checking sections "8.1.1 Manufacturer and Device Identification" and
"11. ORDERING INFORMATION" from the datasheets.
Package type and temperature info doesn't matter for naming convention,
but seems that the last suffix does: when M, QE = 0 (and it is programmable),
when Q or N, Quad Enable is fixed and always enabled (QE = 1).
Oh, so that would be w25q128jw--m / w25q128jw--q then ?
Part Numbers and Top Side Marking" there is no "M" PACKAGE TYPE, so that
seems wrong.
mm, ok.
See above.
Winbond names this flash "W25Q128JW_DTR", you can find the name on the
top right of each page from [1].
Per 8.1 the IDs are the same for both _DTR [1] and non-DTR [2] variants.
What I propose:
1/ according to [1] W25Q128JW_IM/JM is W25Q128JW_DTR, let's use "-dtr"
for the M flavor.
2/ according to [2] W25Q128JW has two flavors: W25Q128JW-IQ/JQ and
W25Q128JW-IM/JM*. Since W25Q128JW_IM/JM is called W25Q128JW_DTR, let's
use just "W25Q128JW" for W25Q128JW-IQ/JQ, as winbond uses too.
1/ That looks wrong to me. The W25Q128JW and W25Q128JW_DTR are two
different products of Winbond, see "Features" column in:
https://www.winbond.com/hq/product/code-storage-flash-memory/serial-nor-flash/
Density -> 128Mb
W25Q128JW
1.7V - 1.95V
133MHz
SPI 4 I/O Fixed <--
W25Q128JW_DTR
1.7V - 1.95V
133MHz
SPI / QPI / DTR <--
Then, compare the datasheets [1] and [2], notice how the _DTR variant
supports more functionality compared to the non-DTR variant:
8.1.4 Instruction Set Table 3 (QPI Instructions)
8.1.5 Instruction Set Table 4 (DTR with SPI Instructions)
8.1.6 Instruction Set Table 5 (DTR with QPI Instructions)
So my counter-proposal would be to call it just "w25q128jw" , that's the
lowest common denominator of the DTR and non-DTR variant. And then, use
SFDP to determine whether the QPI/DTR extras are supported by the flash
(and thus whether it is the DTR variant or not).
The only downside is, I only have the non-DTR variant, so I cannot dump
the SFDP tables of the DTR variant and check whether it differs from the
non-DTR variant. I would expect it does.
2/ That looks wrong to me too. Look at [1] for the meaning of -xM/-xQ
suffix of the flash, it has nothing to do with the DTR support. It just
says what is the QE bit setting in SR2:
11. ORDERING INFORMATION
Q ... with QE = 1 (fixed) in Status register-2.
N ... with QE = 1 (fixed) in Status register-2 & DRV=75%. Backward
compatible to FW family.
M ... with QE = 0 (programmable) in Status register-2. New device ID is
used to identify FW family
Looking at [3], I see that W25Q128JV and W25Q128FV use the same flash ID,
I wonder what's the difference between them. I made a proposal in linux on
how to handle flash collisions, a v5 will follow.
https://www.winbond.com/hq/product/code-storage-flash-memory/serial-nor-flash/
Density -> 128Mb
W25Q128FV
2.7V - 3.6V
104MHz <---
SPI / QPI <
W25Q128JV
2.7V - 3.6V
133MHz <---
SPI 4 I/O Fixed <--
Unlike the -JV, the -FV has
Instruction Set Table 3 (QPI Instructions)
See my suggestion above, use the lowest common denominator flash (in
this case JV) as a base and then use SFDP to determine whether extra
features are available. Would that work ?
I don't think it will work because the -DTR and non-DTR have different flash
IDs.
Be careful, I think you are conflating -xM/-xQ and _DTR and non-DTR
variants of this W25Q128 flash. Look at [1] and [2] again, the ID 0x8018:
8.1.1 Manufacturer and Device Identification
Device ID | (ID7 - ID0)| (ID15 - ID0)
Instruction | ABh, 90h, 92h, 94h | 9Fh
(non-DTR variant)
W25Q128JW-IQ/JQ | 17h| 6018h
W25Q128JW-IM/JM*| 17h| 8018h
-DTR variant:
W25Q128JW_IM/JM | 17h| 8018h
So you should be able to tell the non-DTR variant of w25q128jw based
purely on flash ID . You should also be able to tell whether the 0x8018
flash is in fact DTR variant based on the presence of the extra DTR
opcodes in SFDP. This:
if (id == 0x6018) {
return W25Q128JWxxQ with QE=1
} else if (id == 0x8018) {
if (SFDP indicates DTR commands present)
Re: [PATCH u-boot-marvell] arm: mvebu: dts: turris_mox: fix non-working network / MDIO
On Tuesday 15 March 2022 16:37:27 Marek Behún wrote:
> From: Marek Behún
>
> Commit 0934dddc6436 ("arm: a37xx: Update DTS files to version from
> upstream Linux kernel") ported Linux's device-tree files for Armada 3720
> SOCs. This broke network on Turris MOX, because the SOC's MDIO bus in
> U-Boot currently isn't probed via DM as it's own device, but is
> registered as part of mvneta's driver, which means that pinctrl
> definitions are not parsed for the MDIO bus node. Also mvneta driver
> does not consider "phy-handle" property, only "phy".
>
> For now, fix this by adding armada-3720-turris-mox-u-boot.dtsi file
> returning the MDIO to how it was defined previously.
>
> A better solution (using proper mvmdio DM driver) is being work on, but
> will need testing on various boards, and we need the bug fixed now for
> the upcoming release.
>
> Fixes: 0934dddc6436 ("arm: a37xx: Update DTS files to version from upstream
> Linux kernel")
> Signed-off-by: Marek Behún
Reviewed-by: Pali Rohár
This is my mistake as I probably tested network with my patch series
only on EspressoBin. EspressoBin is not really affected by this issue as
it uses fixed settings in DT. Network is really working fine with U-Boot
master branch.
> ---
> Dear Stefan,
>
> this fix is needed for the upcoming release, is it still possible?
> Thanks.
>
> Marek
> ---
> .../dts/armada-3720-turris-mox-u-boot.dtsi| 23 +++
> 1 file changed, 23 insertions(+)
> create mode 100644 arch/arm/dts/armada-3720-turris-mox-u-boot.dtsi
>
> diff --git a/arch/arm/dts/armada-3720-turris-mox-u-boot.dtsi
> b/arch/arm/dts/armada-3720-turris-mox-u-boot.dtsi
> new file mode 100644
> index 00..2e05b973d2
> --- /dev/null
> +++ b/arch/arm/dts/armada-3720-turris-mox-u-boot.dtsi
> @@ -0,0 +1,23 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * 2022 by Marek Behún
> + */
> +
> +/ {
> + mdio {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + old_binding_phy1: ethernet-phy@1 {
> + reg = <1>;
> + };
> + };
> +};
> +
> + {
> + pinctrl-0 = <_pins>, <_pins>;
> + /delete-property/ phy-handle;
> + phy = <_binding_phy1>;
> +};
> +
> +/delete-node/
> --
> 2.34.1
>
Please pull u-boot-marvell/master
Hi Tom, please pull this MVEBU turris_mox fixes: - mvebu: dts: turris_mox: fix non-working network / MDIO (Marek) Here the Azure build, without any issues: https://dev.azure.com/sr0718/u-boot/_build/results?buildId=166=results Thanks, Stefan The following changes since commit 4dc9b1771b152838ddfc4ae86a0ab9fd53ea16f7: Merge https://source.denx.de/u-boot/custodians/u-boot-usb (2022-03-14 22:54:53 -0400) are available in the Git repository at: g...@source.denx.de:u-boot/custodians/u-boot-marvell.git for you to fetch changes up to 351729ca445d4822502ff7117f8213832e753f91: arm: mvebu: dts: turris_mox: fix non-working network / MDIO (2022-03-16 07:24:28 +0100) Marek Behún (1): arm: mvebu: dts: turris_mox: fix non-working network / MDIO arch/arm/dts/armada-3720-turris-mox-u-boot.dtsi | 23 +++ 1 file changed, 23 insertions(+) create mode 100644 arch/arm/dts/armada-3720-turris-mox-u-boot.dtsi
Re: [PATCH u-boot-marvell] arm: mvebu: dts: turris_mox: fix non-working network / MDIO
On 3/15/22 16:37, Marek Behún wrote:
From: Marek Behún
Commit 0934dddc6436 ("arm: a37xx: Update DTS files to version from
upstream Linux kernel") ported Linux's device-tree files for Armada 3720
SOCs. This broke network on Turris MOX, because the SOC's MDIO bus in
U-Boot currently isn't probed via DM as it's own device, but is
registered as part of mvneta's driver, which means that pinctrl
definitions are not parsed for the MDIO bus node. Also mvneta driver
does not consider "phy-handle" property, only "phy".
For now, fix this by adding armada-3720-turris-mox-u-boot.dtsi file
returning the MDIO to how it was defined previously.
A better solution (using proper mvmdio DM driver) is being work on, but
will need testing on various boards, and we need the bug fixed now for
the upcoming release.
Fixes: 0934dddc6436 ("arm: a37xx: Update DTS files to version from upstream Linux
kernel")
Signed-off-by: Marek Behún
---
Dear Stefan,
this fix is needed for the upcoming release, is it still possible?
Thanks.
Applied to u-boot-marvell/master
Thanks,
Stefan
Marek
---
.../dts/armada-3720-turris-mox-u-boot.dtsi| 23 +++
1 file changed, 23 insertions(+)
create mode 100644 arch/arm/dts/armada-3720-turris-mox-u-boot.dtsi
diff --git a/arch/arm/dts/armada-3720-turris-mox-u-boot.dtsi
b/arch/arm/dts/armada-3720-turris-mox-u-boot.dtsi
new file mode 100644
index 00..2e05b973d2
--- /dev/null
+++ b/arch/arm/dts/armada-3720-turris-mox-u-boot.dtsi
@@ -0,0 +1,23 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * 2022 by Marek Behún
+ */
+
+/ {
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ old_binding_phy1: ethernet-phy@1 {
+ reg = <1>;
+ };
+ };
+};
+
+ {
+ pinctrl-0 = <_pins>, <_pins>;
+ /delete-property/ phy-handle;
+ phy = <_binding_phy1>;
+};
+
+/delete-node/
Viele Grüße,
Stefan Roese
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: [PATCH v2] dm: Add docs to explain how to enable DM_SERIAL for a board
Hi Simon, On 16/03/2022 00:03, Simon Glass wrote: This is an attempt to cover the common cases found when enabling driver model for serial on a new board. Signed-off-by: Simon Glass Reviewed-by: Fabio Estevam
Re: [PATCH 4/9] arm: imx: imx8mm: add enable_pwm_clk function
On Wed, Mar 16, 2022 at 10:05:47AM +0100, Michael Nazzareno Trimarchi wrote:
> Hi
>
> On Wed, Mar 16, 2022 at 10:02 AM Tommaso Merciai
> wrote:
> >
> > Add function to enable_pwm_clck function into clock_imx8mm.c. This
> > function first configure, then enable pwm1 clock from clock control
> > register. The following configuration is used:
> >
> > source(0) -> 24 MHz ref clock
> > div(0)-> no division for this clock
> >
> > References:
> > - iMX8MMRM.pdf p 303
> >
> > Signed-off-by: Tommaso Merciai
> > ---
> > arch/arm/mach-imx/imx8m/clock_imx8mm.c | 11 +++
> > 1 file changed, 11 insertions(+)
> >
> > diff --git a/arch/arm/mach-imx/imx8m/clock_imx8mm.c
> > b/arch/arm/mach-imx/imx8m/clock_imx8mm.c
> > index 49945faf2c..5f2eddf715 100644
> > --- a/arch/arm/mach-imx/imx8m/clock_imx8mm.c
> > +++ b/arch/arm/mach-imx/imx8m/clock_imx8mm.c
> > @@ -313,6 +313,17 @@ void enable_usboh3_clk(unsigned int enable)
> > }
> > }
> >
> > +void enable_pwm_clk(unsigned char enable)
> > +{
> > + if (enable) {
> > + clock_enable(CCGR_PWM1, false);
> > + clock_set_target_val(PWM1_CLK_ROOT, CLK_ROOT_ON |
> > CLK_ROOT_SOURCE_SEL(0) |CLK_ROOT_PRE_DIV(CLK_ROOT_PRE_DIV1));
> > + clock_enable(CCGR_PWM1, true);
> > + } else {
> > + clock_enable(CCGR_PWM1, false);
> > + }
> > +}
> > +
>
> Show not be somenthing like
> enable_pwm_clk(enum pwm_id, bool enable)
>
> ?
Hi,
Like init_clk_usdhc(u32 index) function in clock_imx8mm.c?
Ack, I'll send v2.
Thanks,
Tommaso
>
> > void init_uart_clk(u32 index)
> > {
> > /*
> > --
> > 2.25.1
> >
>
>
> --
> Michael Nazzareno Trimarchi
> Co-Founder & Chief Executive Officer
> M. +39 347 913 2170
> mich...@amarulasolutions.com
> __
>
> Amarula Solutions BV
> Joop Geesinkweg 125, 1114 AB, Amsterdam, NL
> T. +31 (0)85 111 9172
> i...@amarulasolutions.com
> www.amarulasolutions.com
--
Tommaso Merciai
Embedded Linux Engineer
tommaso.merc...@amarulasolutions.com
__
Amarula Solutions SRL
Via Le Canevare 30, 31100 Treviso, Veneto, IT
T. +39 042 243 5310
i...@amarulasolutions.com
www.amarulasolutions.com
Re: [PATCH 4/9] arm: imx: imx8mm: add enable_pwm_clk function
Hi
On Wed, Mar 16, 2022 at 10:02 AM Tommaso Merciai
wrote:
>
> Add function to enable_pwm_clck function into clock_imx8mm.c. This
> function first configure, then enable pwm1 clock from clock control
> register. The following configuration is used:
>
> source(0) -> 24 MHz ref clock
> div(0)-> no division for this clock
>
> References:
> - iMX8MMRM.pdf p 303
>
> Signed-off-by: Tommaso Merciai
> ---
> arch/arm/mach-imx/imx8m/clock_imx8mm.c | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/arch/arm/mach-imx/imx8m/clock_imx8mm.c
> b/arch/arm/mach-imx/imx8m/clock_imx8mm.c
> index 49945faf2c..5f2eddf715 100644
> --- a/arch/arm/mach-imx/imx8m/clock_imx8mm.c
> +++ b/arch/arm/mach-imx/imx8m/clock_imx8mm.c
> @@ -313,6 +313,17 @@ void enable_usboh3_clk(unsigned int enable)
> }
> }
>
> +void enable_pwm_clk(unsigned char enable)
> +{
> + if (enable) {
> + clock_enable(CCGR_PWM1, false);
> + clock_set_target_val(PWM1_CLK_ROOT, CLK_ROOT_ON |
> CLK_ROOT_SOURCE_SEL(0) |CLK_ROOT_PRE_DIV(CLK_ROOT_PRE_DIV1));
> + clock_enable(CCGR_PWM1, true);
> + } else {
> + clock_enable(CCGR_PWM1, false);
> + }
> +}
> +
Show not be somenthing like
enable_pwm_clk(enum pwm_id, bool enable)
?
> void init_uart_clk(u32 index)
> {
> /*
> --
> 2.25.1
>
--
Michael Nazzareno Trimarchi
Co-Founder & Chief Executive Officer
M. +39 347 913 2170
mich...@amarulasolutions.com
__
Amarula Solutions BV
Joop Geesinkweg 125, 1114 AB, Amsterdam, NL
T. +31 (0)85 111 9172
i...@amarulasolutions.com
www.amarulasolutions.com
[PATCH 7/9] imx8mm_evk: spl: enable pwm clock
Enable pwm clock into spl Signed-off-by: Tommaso Merciai --- board/freescale/imx8mm_evk/spl.c | 4 1 file changed, 4 insertions(+) diff --git a/board/freescale/imx8mm_evk/spl.c b/board/freescale/imx8mm_evk/spl.c index 4ef7f6f180..5aabdba0b0 100644 --- a/board/freescale/imx8mm_evk/spl.c +++ b/board/freescale/imx8mm_evk/spl.c @@ -135,6 +135,10 @@ void board_init_f(ulong dummy) init_uart_clk(1); +#ifdef CONFIG_PWM_IMX + enable_pwm_clk(1); +#endif + board_early_init_f(); timer_init(); -- 2.25.1
[PATCH 8/9] arm: dts: imx8mm_evk: add pwm1/backlight support
Add pwm1/backlight support nodes for imx8mm_evk board
Signed-off-by: Tommaso Merciai
---
arch/arm/dts/imx8mm-evk.dtsi | 21 +
1 file changed, 21 insertions(+)
diff --git a/arch/arm/dts/imx8mm-evk.dtsi b/arch/arm/dts/imx8mm-evk.dtsi
index 60179e006d..e7a2bd8a64 100644
--- a/arch/arm/dts/imx8mm-evk.dtsi
+++ b/arch/arm/dts/imx8mm-evk.dtsi
@@ -41,6 +41,15 @@
enable-active-high;
};
+ backlight: backlight {
+ status = "disabled";
+ compatible = "pwm-backlight";
+ pwms = < 0 500>;
+ brightness-levels = <0 255>;
+ num-interpolated-steps = <255>;
+ default-brightness-level = <250>;
+ };
+
ir-receiver {
compatible = "gpio-ir-receiver";
gpios = < 13 GPIO_ACTIVE_LOW>;
@@ -350,6 +359,12 @@
status = "okay";
};
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_backlight>;
+ status = "disabled";
+};
+
{
pinctrl_fec1: fec1grp {
fsl,pins = <
@@ -491,4 +506,10 @@
MX8MM_IOMUXC_GPIO1_IO02_WDOG1_WDOG_B0x166
>;
};
+
+ pinctrl_backlight: backlightgrp {
+ fsl,pins = <
+ MX8MM_IOMUXC_GPIO1_IO01_PWM1_OUT0x06
+ >;
+ };
};
--
2.25.1
[PATCH 9/9] configs: imx8mm_evk: add pwm backlight support
Enable support for backlight/pwm-imx driver Signed-off-by: Tommaso Merciai --- configs/imx8mm_evk_defconfig | 5 + 1 file changed, 5 insertions(+) diff --git a/configs/imx8mm_evk_defconfig b/configs/imx8mm_evk_defconfig index 01395fc7eb..cfba6cc673 100644 --- a/configs/imx8mm_evk_defconfig +++ b/configs/imx8mm_evk_defconfig @@ -84,3 +84,8 @@ CONFIG_SYSRESET_PSCI=y CONFIG_SYSRESET_WATCHDOG=y CONFIG_DM_THERMAL=y CONFIG_IMX_WATCHDOG=y +CONFIG_DM_VIDEO=y +CONFIG_BACKLIGHT=y +CONFIG_BACKLIGHT_PWM=y +CONFIG_DM_PWM=y +CONFIG_PWM_IMX=y \ No newline at end of file -- 2.25.1
[PATCH 6/9] configs: imx8mm_evk: add CONFIG_IMX6_PWM_PER_CLK config
In order to support pwm-imx-util CONFIG_IMX6_PWM_PER_CLK is needed. At the moment driver don't support clock framework Signed-off-by: Tommaso Merciai --- include/configs/imx8mm_evk.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/include/configs/imx8mm_evk.h b/include/configs/imx8mm_evk.h index c7022ef0f7..3c17dd3773 100644 --- a/include/configs/imx8mm_evk.h +++ b/include/configs/imx8mm_evk.h @@ -91,4 +91,7 @@ #define IMX_FEC_BASE 0x30BE +#ifdef CONFIG_PWM_IMX + #define CONFIG_IMX6_PWM_PER_CLK 6600 +#endif #endif -- 2.25.1
