Hi Martin,
On Sat, Feb 25, 2023 at 6:17 PM Martin Rowe wrote:
>
> > > > I'm not sure how to run proper timing tests on the process, but
> > > > stopwatch timing just between seeing "Trying to boot" and "U-Boot
> > > > 2023.04-rc2" showed the return to BootROM under 1 second, and the
> > > > direc
Bit layout decipered from
https://github.com/rockchip-linux/u-boot/commit/c69667e0e2bf4290ab1f408fcde58b8806ac266b
Tested on a rk3568 device.
Signed-off-by: Recursive G
---
arch/arm/include/asm/arch-rockchip/sdram.h | 3 +++
arch/arm/mach-rockchip/sdram.c | 1 +
2 files changed, 4 in
On Sat, Feb 25, 2023 at 11:38 AM Simon Glass wrote:
>
> +Masahiro Yamada
I do not know.
This seems a shorthand in Kconfig level.
masahiro@zoe:~/ref/u-boot(master)$ rgrep '^config SPL_' | wc
5401080 24872
masahiro@zoe:~/ref/u-boot(master)$ rgrep '^config TPL_' | wc
163 326
> > > I'm not sure how to run proper timing tests on the process, but
> > > stopwatch timing just between seeing "Trying to boot" and "U-Boot
> > > 2023.04-rc2" showed the return to BootROM under 1 second, and the
> > > direct from SPI around 4 seconds. I thought the goal of loading from
> > > SPI
On Sat, 25 Feb 2023 at 21:16, Pali Rohár wrote:
> I think that the remaining part is to patch linux DTB file at runtime
> for emmc support. So if u-boot mmc device is of eMMC type then fixup
> linux dtb file and others do nothing.
One question I didn't think of when suggesting this: does runtime
On Sat, 25 Feb 2023 at 22:14, Pali Rohár wrote:
> On Saturday 25 February 2023 22:49:56 Pali Rohár wrote:
> > On Saturday 25 February 2023 11:42:19 Martin Rowe wrote:
> > > A388 Clearfog MMC is either SD Card or eMMC with different behaviour for
> > > both. Setting MMC_BROKEN_CD allows both to cor
Add a command to display the tables provided by EFI.
Signed-off-by: Simon Glass
---
cmd/efi.c | 40 +++-
doc/usage/cmd/efi.rst | 22 ++
2 files changed, 61 insertions(+), 1 deletion(-)
diff --git a/cmd/efi.c b/cmd/efi.c
index
Add an option to package a kernel into the debugging script used for
EFI.
The name of the kernel must be added to the script. Bd efault it is
assumed that the kernel is built in the /tmp/kernel directory.
Signed-off-by: Simon Glass
---
scripts/build-efi.sh | 14 +-
1 file changed,
This command currently has no help. Add some.
Signed-off-by: Simon Glass
---
doc/usage/cmd/efi.rst | 197 ++
doc/usage/index.rst | 1 +
2 files changed, 198 insertions(+)
create mode 100644 doc/usage/cmd/efi.rst
diff --git a/doc/usage/cmd/efi.rst b/
Provide information about the GUIDs supplied by QEMU, so far as it is
known.
Signed-off-by: Simon Glass
---
include/efi_api.h | 28
lib/uuid.c| 12
2 files changed, 40 insertions(+)
diff --git a/include/efi_api.h b/include/efi_api.h
index 2d18d
These have been disabled due to the rudimentary support available. It is
a little better now, so enable these options.
Signed-off-by: Simon Glass
---
configs/efi-x86_app32_defconfig | 2 +-
configs/efi-x86_app64_defconfig | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/co
When running the EFI app, we need to exit boot services before jumping
to Linux.
At some point it may be possible to jump to Linux and pass on the boot
services, so that the Linux efistub can be used. For now, this is not
implemented.
Signed-off-by: Simon Glass
---
arch/x86/lib/bootm.c | 18 ++
Add the missing code to handle this. For a 64-bit kernel the entry
address is 0x200 bytes after the normal entry.
Rename the parameter to boot_linux_kernel() accordingly. Update the
comments to indicate that these are addresses, not pointers.
Signed-off-by: Simon Glass
---
arch/x86/include/asm
This does not mention what it returns. Add the missing documentation.
Signed-off-by: Simon Glass
---
arch/x86/include/asm/cpu.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/x86/include/asm/cpu.h b/arch/x86/include/asm/cpu.h
index 3346012d335..aa03ef598e1 100644
--- a/arch/x86/includ
This likely came from Linux originally, so update it to match v6.2 more.
This has no functional change.
Signed-off-by: Simon Glass
---
arch/x86/include/asm/bootparam.h | 70 +---
arch/x86/lib/zimage.c| 2 +-
2 files changed, 47 insertions(+), 25 deletion
The U-Boot EFI app can run as a 64-bit program, so set the Kconfig
correctly in that case. Make sure it doesn't build SPL, since there is
no need to switch from 32 to 64 bit when running.
Signed-off-by: Simon Glass
---
arch/x86/Kconfig| 4 ++--
configs/efi-x86_app64_defconfig |
This series provides support for booting a kernel from the EFI app. So
far this is pretty basic, since it only supports the actual booting, not
providing ACPI tables, etc. But it is a start.
It also includes an enhancement to the 'efi' command and a few other
clean-ups.
Simon Glass (10):
efi:
On 2/25/23 20:19, Johan Jonker wrote:
> The fdt_addr_t and phys_addr_t size have been decoupled.
> A 32bit CPU can expect 64-bit data from the device tree parser,
> so use dev_read_addr_ptr instead of the dev_read_addr
> function in the various files in the drivers directory that cast
> to a poi
Hi Pali,
Hi Martin,
On Sat, Feb 25, 2023 at 5:41 AM Pali Rohár wrote:
>
> On Saturday 25 February 2023 11:47:07 Martin Rowe wrote:
> > > While I haven't tested this patchset - I have tested SPI booting with
> > > v2022.01 after applying lots of patches.
> > > I found that the magic value reporte
Hi Pali,
On Sat, Feb 25, 2023 at 1:13 PM Pali Rohár wrote:
>
> On Friday 24 February 2023 19:58:37 Tony Dinh wrote:
> > Hi Pali,
> >
> > On Tue, Feb 21, 2023 at 12:22 PM Pali Rohár wrote:
> > >
> > > Proper U-Boot moves SPI0 CS0 Flash mapping from 0xD400 to 0xF400
> > > and change its si
Add the timer and vendor/model information.
Signed-off-by: Simon Glass
---
Changes in v3:
- Show the CPU vendor name also
arch/x86/lib/bdinfo.c | 6 ++
cmd/bdinfo.c | 5 +
include/init.h| 3 +++
3 files changed, 14 insertions(+)
diff --git a/arch/x86/lib/bdinfo.c b/ar
The cls command is broken. Previous discussion about this was at [1] and
[2]. For now, add a note to the source code.
[1] https://patchwork.ozlabs.org/project/uboot/patch/
20221022092058.106052-1-heinrich.schucha...@canonical.com/
[2] https://patchwork.ozlabs.org/project/uboot/patch/
There are two functions for positioning the cursor on the console. Remove
one of them.
Signed-off-by: Simon Glass
---
(no changes since v1)
drivers/video/vidconsole-uclass.c | 44 +++
1 file changed, 10 insertions(+), 34 deletions(-)
diff --git a/drivers/video/vidc
If the copy framebuffer is enabled, show its size.
Signed-off-by: Simon Glass
---
(no changes since v2)
Changes in v2:
- Add new patch to show the size of the copy framebuffer with bdinfo
cmd/bdinfo.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/cmd/bdinfo.c b/cmd/
When running with video enabled, the pre-relocation output of U-Boot is
currently lost. Add a -serial flag to show it on the terminal.
Signed-off-by: Simon Glass
---
(no changes since v1)
scripts/build-efi.sh | 2 ++
1 file changed, 2 insertions(+)
diff --git a/scripts/build-efi.sh b/scripts/
Add these options to provide some performance measurement, see cache
status and slightly speed up the appallingly slow console.
Signed-off-by: Simon Glass
---
(no changes since v1)
configs/efi-x86_app64_defconfig | 3 +++
1 file changed, 3 insertions(+)
diff --git a/configs/efi-x86_app64_defc
It is better to clear the console device rather than the video device,
since the console has the text display. We also need to reset the cursor
position with the console, but not with the video device.
Add a new function to handle this and update the 'cls' command to use it.
Signed-off-by: Simon
At present it is not possible for the video driver to use a pre-allocated
frame buffer (such as is done with EFI) with the copy framebuffer. This
can be useful to speed up the display.
Adjust the implementation so that copy_size can be set to the required
size, with this being allocated if the nor
Add support for this to EFI in case it becomes useful. At present it just
slows things down. You can enable CONFIG_VIDEO_COPY to turn it on.
Signed-off-by: Simon Glass
---
Changes in v3:
- Add a comment about the fallback
Changes in v2:
- Obtain copy framebuffer size from EFI instead of using a
Put this into a function, as we have done for the app implementation.
Comment both functions. FOr now the app still does not access it
correctly.
Signed-off-by: Simon Glass
---
(no changes since v1)
drivers/video/efi.c | 83 +++--
1 file changed, 57 inse
It is not yet clear how to read the timer via EFI. The current value seems
much too high on a Framework laptop I tried. Adjust it to a lower
hard-coded value for now.
Signed-off-by: Simon Glass
---
Changes in v3:
- Add a comment about the value
drivers/timer/tsc_timer.c | 9 +
1 file c
The current vesa structure only provides a 32-bit value for the frame
buffer. Many modern machines use an address outside the range.
It is still useful to have this common struct, but add a separate
frame-buffer address as well.
Add a comment for vesa_setup_video_priv() while we are here.
Signed
The mode info is currently not initialised for the app. Fix this by
returning it from the function.
Signed-off-by: Simon Glass
---
(no changes since v1)
drivers/video/efi.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/video/efi.c b/drivers/video/efi.c
inde
This does not work on some 64-bit machines since only a 32-bit address for
the framebuffer is supported in the VESA structure.
This series corrects this and makes a few other minor, video-related
improvements.
Changes in v3:
- Use Returns instead of @return
- Show the CPU vendor name also
- Add a
On Saturday 25 February 2023 22:49:56 Pali Rohár wrote:
> On Saturday 25 February 2023 11:42:19 Martin Rowe wrote:
> > A388 Clearfog MMC is either SD Card or eMMC with different behaviour for
> > both. Setting MMC_BROKEN_CD allows both to correctly detect MMC.
> >
> > Signed-off-by: Martin Rowe
>
On Tuesday 21 February 2023 21:18:26 Pali Rohár wrote:
> This patch series contains various improvements and fixes for existing
> logical errors. Boot phase was adjusted to match behavior of Armada 385
> BootROM by inspecting and disassembling of BootROM binary dump itself.
> Important information
On Saturday 25 February 2023 11:51:28 Josua Mayer wrote:
> While I haven't tested this patchset
Are you going to test it?
> I have tested SPI booting with
> v2022.01 after applying lots of patches.
> I found that the magic value reported by bootrom when booting from SPI will
> be 0x34 on clearfog
On Saturday 25 February 2023 11:42:19 Martin Rowe wrote:
> A388 Clearfog MMC is either SD Card or eMMC with different behaviour for
> both. Setting MMC_BROKEN_CD allows both to correctly detect MMC.
>
> Signed-off-by: Martin Rowe
It looks like a hack but I think we do not have a better option fo
On Friday 24 February 2023 19:23:23 Tony Dinh wrote:
> Enable 512MB PXA3XX NAND flash when u-boot is running.
>
> Signed-off-by: Tony Dinh
Acked-by: Pali Rohár
> ---
>
> configs/n2350_defconfig | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/configs/n2350_defconfig b/configs/n235
On Saturday 25 February 2023 13:48:25 Tom Rini wrote:
> On Sat, Feb 25, 2023 at 07:35:28PM +0100, Pali Rohár wrote:
> > On Saturday 25 February 2023 13:23:33 Tom Rini wrote:
> > > On Tue, Feb 21, 2023 at 11:22:29AM -0500, Tom Rini wrote:
> > >
> > > > From: Pali Rohár
> > > >
> > > > Now that th
On Saturday 25 February 2023 01:18:26 Martin Rowe wrote:
> > When generating this patch, use git options -M, -C and
> > --find-copies-harder. It will detect that you created this file as copy
> > from other file and generate better diff.
>
> Will do.
>
> This thread has gotten quite long! I've:
>
On Friday 24 February 2023 19:58:37 Tony Dinh wrote:
> Hi Pali,
>
> On Tue, Feb 21, 2023 at 12:22 PM Pali Rohár wrote:
> >
> > Proper U-Boot moves SPI0 CS0 Flash mapping from 0xD400 to 0xF400
> > and change its size from 64 MB to 8 MB. Definitions are already in
> > MBUS_SPI_BASE/MBUS_SPI
Hi Johan
On Sat, Feb 25, 2023 at 8:19 PM Johan Jonker wrote:
>
> The fdt_addr_t and phys_addr_t size have been decoupled.
> A 32bit CPU can expect 64-bit data from the device tree parser,
> so use devfdt_get_addr_index_ptr instead of
> the devfdt_get_addr_index function in the various files
> in
Hi
On Sat, Feb 25, 2023 at 8:19 PM Johan Jonker wrote:
>
> The fdt_addr_t and phys_addr_t size have been decoupled.
> A 32bit CPU can expect 64-bit data from the device tree parser,
> so use devfdt_get_addr_size_index_ptr instead of
> the devfdt_get_addr_size_index function in the various files
>
On Sat, Feb 25, 2023 at 8:16 PM Johan Jonker wrote:
>
> The fdt_addr_t and phys_addr_t size have been decoupled.
> A 32bit CPU can expect 64-bit data from the device tree parser,
> so use dev_read_addr_index_ptr instead of the dev_read_addr_index
> function in the various files in the drivers dire
The fdt_addr_t and phys_addr_t size have been decoupled.
A 32bit CPU can expect 64-bit data from the device tree parser,
so use devfdt_get_addr_index_ptr instead of
the devfdt_get_addr_index function in the various files
in the drivers directory that cast to a pointer.
Signed-off-by: Johan Jonker
The fdt_addr_t and phys_addr_t size have been decoupled.
A 32bit CPU can expect 64-bit data from the device tree parser,
so use devfdt_get_addr_size_index_ptr instead of
the devfdt_get_addr_size_index function in the various files
in the drivers directory that cast to a pointer.
Signed-off-by: Joh
The fdt_addr_t and phys_addr_t size have been decoupled.
A 32bit CPU can expect 64-bit data from the device tree parser,
so use dev_read_addr_ptr instead of the dev_read_addr
function in the various files in the drivers directory that cast
to a pointer.
Signed-off-by: Johan Jonker
---
Note:
Thi
The fdt_addr_t and phys_addr_t size have been decoupled.
A 32bit CPU can expect 64-bit data from the device tree parser,
so use dev_read_addr_index_ptr instead of the dev_read_addr_index
function in the various files in the drivers directory that cast
to a pointer.
Signed-off-by: Johan Jonker
---
On 2023-02-23 10:05, Jonas Karlman wrote:
> Hi Kever,
> On 2023-02-23 05:38, Kever Yang wrote:
>> Hi Jonas, Simon,
>>
>> I got below error in buildman with BINMAN_ALLOW_MISSING=1
>>
>> Building current source for 1 boards (1 thread, 16 jobs per thread)
>> aarch64: + evb-rk3568
>> +binma
Rockchip SoCs typically use U-Boot TPL to initialize DRAM, then jumps
back to BootRom to load next stage, U-Boot SPL, into DRAM. BootRom then
jumps to U-Boot SPL to continue the boot flow.
For RK356x there is no support to initialize DRAM using U-Boot
TPL and instead an external TPL binary must be
Using the mkimage entry with the multiple-data-files prop and having a
missing external blob result in an unexpected ValueError exception using
the --allow-missing flag.
ValueError: Filename 'missing.bin' not found in input path (...)
Fix this by using _pathname that is resolved by ObtainConten
The rockchip-tpl entry can be used when an external TPL binary should be
used instead of the normal U-Boot TPL.
Signed-off-by: Jonas Karlman
Reviewed-by: Simon Glass
Reviewed-by: Kever Yang
Tested-by: Eugen Hristev
---
v5:
- No change
v4:
- No change
v3:
- Move test function last
- Collect r
The current init size limit of 76KiB is too big to fit in the 64KiB SRAM
on RK3568, sync init size limit from vendor u-boot to fix this.
Set init size limit to 60KiB (-16KiB) for RK3568.
Signed-off-by: Jonas Karlman
Reviewed-by: Kever Yang
---
v5:
- Split patch in two
- Collect r-b tag
v4:
- O
Latest vendor TPL for RK3328 has grown past the current init size limit
of 28KiB, sync the init size limit from vendor u-boot to fix this.
Set init size limit to 30KiB (+2KiB) for RK3328.
This makes it possible to use latest vendor TPL on RK3328 without
getting a size limit error running the mkim
An external TPL binary is now expected to be provided using ROCKCHIP_TPL
when building RK3568 targets.
This reverts commit 31500e7bcfaca08ab7c2879f502a6cf852410244.
Signed-off-by: Jonas Karlman
Reviewed-by: Simon Glass
Reviewed-by: Kever Yang
---
v5:
- No change
v4:
- No change
v3:
- Collect
Rockchip SoCs typically use U-Boot TPL to initialize DRAM, then jumps
back to BootRom to load next stage, U-Boot SPL, into DRAM. BootRom then
jumps to U-Boot SPL to continue the normal boot flow.
However, there is no support to initialize DRAM on RK35xx SoCs using
U-Boot TPL and instead an externa
On Sat, Feb 25, 2023 at 07:35:28PM +0100, Pali Rohár wrote:
> On Saturday 25 February 2023 13:23:33 Tom Rini wrote:
> > On Tue, Feb 21, 2023 at 11:22:29AM -0500, Tom Rini wrote:
> >
> > > From: Pali Rohár
> > >
> > > Now that the Dockerfile creates images which have the binaries we
> > > require
On Saturday 25 February 2023 13:23:33 Tom Rini wrote:
> On Tue, Feb 21, 2023 at 11:22:29AM -0500, Tom Rini wrote:
>
> > From: Pali Rohár
> >
> > Now that the Dockerfile creates images which have the binaries we
> > require included, have CI make symlinks for them and update the existing
> > scri
On Tue, Feb 21, 2023 at 11:22:29AM -0500, Tom Rini wrote:
> From: Pali Rohár
>
> Now that the Dockerfile creates images which have the binaries we
> require included, have CI make symlinks for them and update the existing
> script to support this.
>
> Signed-off-by: Tom Rini
> Signed-off-by: P
On Fri, Jan 13, 2023 at 08:31:33PM +0100, Heinrich Schuchardt wrote:
> Using a pre-built QEMU saves a lot of time when testing.
>
> Signed-off-by: Heinrich Schuchardt
Applied to u-boot/next, thanks!
--
Tom
signature.asc
Description: PGP signature
On Fri, Jan 13, 2023 at 07:25:01PM +0100, Heinrich Schuchardt wrote:
> Downloading files for a test may fail if the server is offline.
> It is preferable to provide the files in our Docker image.
>
> Signed-off-by: Heinrich Schuchardt
> Reviewed-by: Simon Glass
Applied to u-boot/next, thanks!
Hi Johan
On Sat, Feb 25, 2023 at 12:47 PM Michael Nazzareno Trimarchi
wrote:
>
> Hi
>
> On Sat, Feb 25, 2023 at 12:43 PM Johan Jonker wrote:
> >
> > Add devfdt_get_addr_size_index_ptr function with the same
> > functionality as devfdt_get_addr_size_index, but instead
> > a return pointer is give
On Sat, Feb 25, 2023 at 9:38 AM Dario Binacchi
wrote:
>
> During some tests to check the pixel clock rate in the transition from
> U-Boot to the Linux kernel, I noticed that with the same configuration
> of the registers the debug messages reported different rates.
>
> The same Linux kernel calcul
On Saturday 25 February 2023 11:47:07 Martin Rowe wrote:
> > While I haven't tested this patchset - I have tested SPI booting with
> > v2022.01 after applying lots of patches.
> > I found that the magic value reported by bootrom when booting from SPI will
> > be 0x34 on clearfog.
> > The current
Hi
On Sat, Feb 25, 2023 at 12:43 PM Johan Jonker wrote:
>
> Add devfdt_get_addr_size_index_ptr function with the same
> functionality as devfdt_get_addr_size_index, but instead
> a return pointer is given.
>
> Suggested-by: Michael Nazzareno Trimarchi
> Signed-off-by: Johan Jonker
> ---
> driv
> While I haven't tested this patchset - I have tested SPI booting with
> v2022.01 after applying lots of patches.
> I found that the magic value reported by bootrom when booting from SPI will
> be 0x34 on clearfog.
> The current sources only handle 0x32, hence having or not having SPL_SPI will
Hi
On Sat, Feb 25, 2023 at 12:44 PM Johan Jonker wrote:
>
> The fdt_addr_t and phys_addr_t size have been decoupled.
> A 32bit CPU can expect 64-bit data from the device tree parser,
> so use devfdt_get_addr_index_ptr and devfdt_get_addr_size_index_ptr
> function in the spi-aspeed-smc.c file. Als
The fdt_addr_t and phys_addr_t size have been decoupled.
A 32bit CPU can expect 64-bit data from the device tree parser,
so use devfdt_get_addr_index_ptr and devfdt_get_addr_size_index_ptr
function in the spi-aspeed-smc.c file. Also fix dev_dbg to be able
to handle both sizes.
Signed-off-by: Johan
Add devfdt_get_addr_size_index_ptr function with the same
functionality as devfdt_get_addr_size_index, but instead
a return pointer is given.
Suggested-by: Michael Nazzareno Trimarchi
Signed-off-by: Johan Jonker
---
drivers/core/fdtaddr.c | 8
include/dm/fdtaddr.h | 15 +
Hi Johan
On Sat, Feb 25, 2023 at 10:53 AM Michael Nazzareno Trimarchi
wrote:
>
> Hi Johan
>
> On Sat, Feb 25, 2023 at 10:50 AM Johan Jonker wrote:
> >
> >
> >
> > On 2/25/23 10:26, Michael Nazzareno Trimarchi wrote:
> > > Hi Johan
> > >
> > > On Thu, Feb 23, 2023 at 3:06 PM Johan Jonker wrote:
Hi Pali, Martin,
Am 25.02.23 um 10:48 schrieb Martin Rowe:
On Sat, 25 Feb 2023 at 07:41, Pali Rohár wrote:
On Saturday 25 February 2023 11:42:20 Martin Rowe wrote:
This new clearfog_spi_defconfig file is copy of existing
clearfog_defconfig file and changed to instruct build system to
generate
Hi Johan
On Sat, Feb 25, 2023 at 10:50 AM Johan Jonker wrote:
>
>
>
> On 2/25/23 10:26, Michael Nazzareno Trimarchi wrote:
> > Hi Johan
> >
> > On Thu, Feb 23, 2023 at 3:06 PM Johan Jonker wrote:
> >>
> >> The fdt_addr_t and phys_addr_t size have been decoupled.
> >> A 32bit CPU can expect 64-bi
On 2/25/23 10:26, Michael Nazzareno Trimarchi wrote:
> Hi Johan
>
> On Thu, Feb 23, 2023 at 3:06 PM Johan Jonker wrote:
>>
>> The fdt_addr_t and phys_addr_t size have been decoupled.
>> A 32bit CPU can expect 64-bit data from the device tree parser,
>> so convert devfdt_get_addr_index output t
On Sat, 25 Feb 2023 at 07:41, Pali Rohár wrote:
>
> On Saturday 25 February 2023 11:42:20 Martin Rowe wrote:
> > This new clearfog_spi_defconfig file is copy of existing
> > clearfog_defconfig file and changed to instruct build system to
> > generate final kwbimage for SPI booting and to store the
Hi Johan
On Thu, Feb 23, 2023 at 3:06 PM Johan Jonker wrote:
>
> The fdt_addr_t and phys_addr_t size have been decoupled.
> A 32bit CPU can expect 64-bit data from the device tree parser,
> so convert devfdt_get_addr_index output to phys_addr_t in the
> spi-aspeed-smc.c file. Also fix dev_dbg to
On 2/25/23 10:15, Michael Nazzareno Trimarchi wrote:
> Hi Johan
>
> On Sat, Feb 25, 2023 at 10:11 AM Johan Jonker wrote:
>>
>>
>>
>> On 2/23/23 01:47, Kever Yang wrote:
>>> Hi Johan,
>>>
>>> This update will cause below error on evb-ast2500/2600:
>>
>> Hi Kever, Simon,
>>
>> For "spi-aspee
Hi Johan
On Sat, Feb 25, 2023 at 10:11 AM Johan Jonker wrote:
>
>
>
> On 2/23/23 01:47, Kever Yang wrote:
> > Hi Johan,
> >
> > This update will cause below error on evb-ast2500/2600:
>
> Hi Kever, Simon,
>
> For "spi-aspeed-smc.c" I have submitted a patch proposal.
> The changes in patch 1 p
On 2/23/23 01:47, Kever Yang wrote:
> Hi Johan,
>
> This update will cause below error on evb-ast2500/2600:
Hi Kever, Simon,
For "spi-aspeed-smc.c" I have submitted a patch proposal.
The changes in patch 1 possible involves a lot more boards that might need a
change to which the external
Add debug messages to print the real pixel clock rate, which may not be
the requested one.
Signed-off-by: Dario Binacchi
---
arch/arm/mach-imx/mx6/clock.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/mach-imx/mx6/clock.c b/arch/arm/mach-imx/mx6/clock.c
index 267d86ab4194..1bd
Add the get_lcd_clk() function to get the LCD pixel clock rate.
The patch has been tested on imx6ul platform.
Signed-off-by: Dario Binacchi
---
arch/arm/include/asm/arch-mx6/clock.h | 2 +
arch/arm/mach-imx/mx6/clock.c | 58 +++
2 files changed, 60 insertions(+
During some tests to check the pixel clock rate in the transition from
U-Boot to the Linux kernel, I noticed that with the same configuration
of the registers the debug messages reported different rates.
The same Linux kernel calculations are now used to get the PLL video
rate.
Signed-off-by: Dar
The series adds a function to get the LCD pixel clock rate. Also
improves video PLLL rate calculation.
Dario Binacchi (3):
imx6: clock: improve calculations to get the PLL video rate
imx6: clock: add support to get LCD pixel clock rate
imx6: clock: print real pixel clock rate
arch/arm/inc
83 matches
Mail list logo
