The directory retrieved in ext4fs_exists() should be freed to avoid a
memory leak.
Signed-off-by: Heinrich Schuchardt
---
fs/ext4/ext4fs.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/fs/ext4/ext4fs.c b/fs/ext4/ext4fs.c
index 15587e92e3e..21714149ef5 100644
--- a/
Now that opendir, readir, closedir are implemented for ext4 we can use
fs_ls_generic() for implementing the ls command.
Adjust the unit tests:
* fs_ls_generic() produces more spaces between file size and name.
* The ext4 specific message "** Can not find directory. **\n" is not
written anymore.
* Some of our file system drivers cannot report a file size for
directories. Use a dummy value in this case.
* For SetInfo the UEFI spec requires to ignore the file size field.
Signed-off-by: Heinrich Schuchardt
---
lib/efi_loader/efi_file.c | 30 --
1 file changed,
With this series opendir, readdir, closedir are implemented for ext4.
These functions are needed for the UEFI sub-system to interact with
the ext4 file system.
To reduce code growth the functions are reused to implement the ls
command for ext4.
A memory leak in ext4fs_exists is resolved.
ext4fs_
These were missed when removing the rest of the tricorder platform.
Fixes: d137604c20a4 ("arm: Remove tricorder board")
Signed-off-by: Tom Rini
---
Kconfig | 3 ---
boot/Kconfig | 2 +-
2 files changed, 1 insertion(+), 4 deletions(-)
diff --git a/Kconfig b/Kconfig
index a7b2b6db7425..eb55f
To conform with other messages capitalize the first letter:
%s/enter description/Enter description/g
Adjust the unit tests accordingly.
Signed-off-by: Heinrich Schuchardt
---
cmd/eficonfig.c| 2 +-
test/py/tests/test_eficonfig/test_eficonfig.py | 6 +++---
2 file
On 10/25/24 10:41 AM, Rasmus Villemoes wrote:
On Thu, Oct 24 2024, Marek Vasut wrote:
On 10/24/24 5:20 PM, Tom Rini wrote:
On Thu, Oct 24, 2024 at 04:06:03PM +0200, Marek Vasut wrote:
On 10/24/24 3:18 PM, Rasmus Villemoes wrote:
On Thu, Oct 24 2024, Marek Vasut wrote:
On 10/24/24 12:01 P
On 10/25/24 1:26 PM, Fabio Estevam wrote:
Hello Fabio,
Deduplicate defconfigs for all DH i.MX8MP DHSOM by factoring out the
common parts into generic _dhsom_defconfig and including those using
the #include preprocessor macro, which is applicable to
defconfigs as well. This enables CMD_EXPORTEN
On Fri, Oct 25, 2024 at 09:20:00PM -0300, Fabio Estevam wrote:
> Hi Tom,
>
> Please pull from u-boot-imx/master, thanks.
>
> The following changes since commit 08ae12be8509daf3d1c5a148b8a50c0ffb6457c2:
>
> Mark a few functions static inline (2024-10-24 11:21:48 -0600)
>
> are available in th
On Sat, Oct 26, 2024 at 10:44:59AM +0800, Kever Yang wrote:
> Hi Heiko,
>
> On 2024/10/14 03:24, Heiko Stuebner wrote:
> > The Qnap TS433 is a 4-bay NAS based around the RK3568.
> >
> > Two SATA bays are connected to the RK3568's own SATA controllers while
> > the other two are connected to a JMi
Hi Tom,
Please pull from u-boot-imx/master, thanks.
The following changes since commit 08ae12be8509daf3d1c5a148b8a50c0ffb6457c2:
Mark a few functions static inline (2024-10-24 11:21:48 -0600)
are available in the Git repository at:
https://gitlab.denx.de/u-boot/custodians/u-boot-imx.git
t
Hi Heiko,
On 2024/10/14 03:24, Heiko Stuebner wrote:
The Qnap TS433 is a 4-bay NAS based around the RK3568.
Two SATA bays are connected to the RK3568's own SATA controllers while
the other two are connected to a JMicron SATA controller living on the
PCIe bus.
It provides one 2.5Gb and one 1Gb
Hi Heiko,
I got a ci error for this patch:
https://source.denx.de/u-boot/custodians/u-boot-rockchip/-/jobs/929839
+Image 'simple-bin-spi' is missing external blobs and is non-functional:
rockchip-tpl
+/binman/simple-bin-spi/mkimage/rockchip-tpl (rockchip-tpl):
+drivers/net/rtl8169.c:320:2
On Sun, Oct 20, 2024 at 6:01 PM Marek Vasut wrote:
>
> Select default U-Boot and SPL text base for the i.MX6 SoC. The U-Boot
> and SPL text base is picked as the one used by various i.MX6 boards.
> Update all the boards.
>
> Signed-off-by: Marek Vasut
Applied all, thanks.
On Fri, Oct 25, 2024 at 09:24:10PM -0300, Fabio Estevam wrote:
> On Thu, Oct 24, 2024 at 8:51 AM Marek Vasut wrote:
> >
> > On 10/24/24 12:01 PM, Rasmus Villemoes wrote:
> > > I enabled IMX_HAB on an imx8mp board, but even though I knew about the
> > > implementation, I forgot that I had to provid
Add booting option for Debian system.
Signed-off-by: Leo Yan
---
board/armltd/total_compute/total_compute.env | 4
1 file changed, 4 insertions(+)
diff --git a/board/armltd/total_compute/total_compute.env
b/board/armltd/total_compute/total_compute.env
index 93460aa5dc..7924632678 100644
-
On Mon, 21 Oct 2024 10:19:24 +0200, Simon Glass wrote:
> This little series adds a new 'memmap' command, intended to show the
> layout of memory within U-Boot and how much memory is available for
> loading images.
>
> Changes in v4:
> - Drop am65x patch as it is not needed
> - Add patch to export
The DRC02 carrier board does not expose PCIe in any way, disable PCIe support.
Signed-off-by: Marek Vasut
---
Cc: Andreas Geisreiter
Cc: Christoph Niedermaier
Cc: Fabio Estevam
Cc: Quentin Schulz
Cc: Sean Anderson
Cc: Simon Glass
Cc: Sumit Garg
Cc: Tom Rini
Cc: u-b...@dh-electronics.com
C
On Thu, Oct 24, 2024 at 8:51 AM Marek Vasut wrote:
>
> On 10/24/24 12:01 PM, Rasmus Villemoes wrote:
> > I enabled IMX_HAB on an imx8mp board, but even though I knew about the
> > implementation, I forgot that I had to provide a sane value for
> > SPL_LOAD_FIT_ADDRESS. The help text for IMX_HAB do
On Fri, Oct 25, 2024 at 7:56 PM Marek Vasut wrote:
>
> Make sure DM regulator support is enabled on this board, just like on all
> the other DH i.MX8MP DHCOM SoM based boards.
>
> Signed-off-by: Marek Vasut
Applied all, thanks.
Neither the DRC02 nor PicoITX carrier board contains the PCA954x I2C mux
chip, the chip is only present on PDK3 carrier board. Disable support for
the PCA954x mux chip and I2C mux altogether on both i.MX8MP DHCOM DRC02 and
PicoITX.
Signed-off-by: Marek Vasut
---
Cc: Andreas Geisreiter
Cc: Christ
Deduplicate defconfigs for all DH i.MX8MP DHSOM by factoring out the
common parts into generic _dhsom_defconfig and including those using
the #include preprocessor macro, which is applicable to
defconfigs as well. This enables CMD_EXPORTENV on all iMX8MP DHSOM
systems to be consistent with other D
Deduplicate defconfigs for all DH i.MX6 DHSOM by including common
configs/imx_dhsom_defconfig . This does introduce changes to the
board configuration, namely it enables commands used on all DHSOM
devices consistenty, the prompt is changed to u-boot=>, support for
booting non-Linux OS which was lik
Make sure DM regulator support is enabled on this board, just like on all
the other DH i.MX8MP DHCOM SoM based boards.
Signed-off-by: Marek Vasut
---
Cc: Andreas Geisreiter
Cc: Christoph Niedermaier
Cc: Fabio Estevam
Cc: Quentin Schulz
Cc: Sean Anderson
Cc: Simon Glass
Cc: Sumit Garg
Cc: T
Hi Lev,
On 10/14/24 13:15, Lev R. Oshvang wrote:
> [You don't often get email from levon...@gmail.com. Learn why this is
> important at
> https://cas5-0-urlprotect.trendmicro.com:443/wis/clicktime/v1/query?url=https%3a%2f%2faka.ms%2fLearnAboutSenderIdentification&umid=d3086c41-4950-4369-b35b-dfb
From: Boyan Karatotev
Tell the AVB command that is loading from MMC.
Signed-off-by: Boyan Karatotev
Signed-off-by: Leo Yan
---
board/armltd/total_compute/total_compute.env | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/board/armltd/total_compute/total_compute.env
b/board
From: Boyan Karatotev
Initialize the environment variables 'fdt_addr_r' and 'kernel_addr_r'
during the misc init phase. The static configurations are not needed,
remove them.
Signed-off-by: Boyan Karatotev
Signed-off-by: Leo Yan
---
arch/arm/Kconfig | 1 +
board/arm
On Fri, Oct 25, 2024 at 05:50:26PM +0200, Michal Simek wrote:
> Hi,
>
> I have collected couple of more patches and would be good for me to clean my
> queue. There are some other patches which have been sent recently which will
> come later after review.
>
> I am especially waiting for memtop se
This commit introduces build_mem_map() function for updating the mem_map
structure with copying info from gd->bd->bi_dram, so that it can keep
the consistence for DRAM info passed via DT.
The page table size is calculated prior to mem_map is ready, introduce
the get_page_table_size() function for
From: Boyan Karatotev
The boot command for Total Compute has many aspects and changes from time
to time. So move it to an .env file where it can be a proper script.
Signed-off-by: Boyan Karatotev
Signed-off-by: Leo Yan
---
board/armltd/total_compute/total_compute.env | 28
From: Boyan Karatotev
The whole DRAM bank is used for loading and U-boot can detect the
overlap between the kernel and initramfs. So it is safe to drop
bootm_size.
Signed-off-by: Boyan Karatotev
Signed-off-by: Leo Yan
---
include/configs/total_compute.h | 1 -
1 file changed, 1 deletion(-)
d
Dynamically detect block device in the boot command, this allows to
support both MMC and virtio block devices.
Signed-off-by: Leo Yan
---
board/armltd/total_compute/total_compute.env | 21 +---
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/board/armltd/total_comp
From: Boyan Karatotev
On Total Compute, TF-A passes the info via DT binding for the hardware
description - includes the serial, memory, and arm_ffa nodes.
This commit initializes the fdt base address based on the passed the
register x1.
The similar implementation has already been done for the r
This patch series is to refine the booting on Arm Total Compuate
platform.
It changes to use the info passed in DTB for initialization DRAM info,
and dynamically initializes the booting envoironment variables.
Another big change is to use an envoironment file for boot commands,
based on it, the s
Hi Ilias,
On 23/10/2024 17:22, Ilias Apalodimas wrote:
The function description says this should return 0 or -1 on failures.
When regions coalesce though this returns the number of coalescedregions
* coalesced regions
which is confusing and requires special handling of the return code.
On top
Use the get_mem_top function to compute the value of ram_top. This was
earlier done through LMB API's, which are no longer available till
after relocation. Use get_mem_top() instead to compute the ram_top
value.
Signed-off-by: Sughosh Ganu
Reviewed-by: Michal Simek
---
board/xilinx/common/board
Merge https://source.denx.de/u-boot/custodians/u-boot-watchdog (2024-10-23
> 08:33:56 -0600)
>
> are available in the Git repository at:
>
> https://source.denx.de/u-boot/custodians/u-boot-dfu.git
> tags/u-boot-dfu-20241025
>
> for you to fetch changes up to 21e7fa0
Add generic logic to determine the ram_top value for boards. Earlier,
this was achieved in an indirect manner through a set of LMB API's.
That has since changed so that the LMB code is available only after
relocation. Replace those LMB calls with a single call to
get_mem_top() to determine the valu
Changes since V1:
Remove the comment above the function definition
Sughosh Ganu (2):
common: memtop: add logic to detect ram_top
xilinx: use get_mem_top() to compute ram_top
board/xilinx/common/board.c | 25 ++
common/Makefile | 1 +
common/memtop.c | 171
On Fri, Oct 25, 2024 at 5:36 AM Yannic Moog wrote:
>
> Hey Tim
>
> On Thu, 2024-10-24 at 08:37 -0700, Tim Harvey wrote:
> > On Thu, Oct 24, 2024 at 12:04 AM Yannic Moog
> > wrote:
> > >
> > > There have been attempts to get op-tee node integrated upstream in
> > > the
> > > past [1][2]. The chall
On 25/10/2024 17:56, Tom Rini wrote:
On Fri, Oct 25, 2024 at 05:47:32PM +0100, Andrew Goodbody wrote:
The config setting CMD_BOOTEFI_HELLO_COMPILE was removed in favour
of BOOTEFI_HELLO_COMPILE but the dependency for
test_efi_helloworld_net_http was not updated and so is now incorrect
preventin
On Fri, Oct 25, 2024 at 06:07:00PM +0100, Andrew Goodbody wrote:
> The config setting CMD_BOOTEFI_HELLO_COMPILE was removed in favour
> of BOOTEFI_HELLO_COMPILE but the usage in this Makefile was not
> updated. Fix it.
>
> Fixes: 6fe80876dcc7 ("efi_loader: Rename and move CMD_BOOTEFI_HELLO_COMPIL
The config setting CMD_BOOTEFI_HELLO_COMPILE was removed in favour
of BOOTEFI_HELLO_COMPILE but the usage in this Makefile was not
updated. Fix it.
Fixes: 6fe80876dcc7 ("efi_loader: Rename and move CMD_BOOTEFI_HELLO_COMPILE")
Signed-off-by: Andrew Goodbody
---
arch/x86/lib/Makefile | 2 +-
1 fi
Thanks, Andrew
On Fri, 25 Oct 2024 at 19:47, Andrew Goodbody
wrote:
>
> The config setting CMD_BOOTEFI_HELLO_COMPILE was removed in favour
> of BOOTEFI_HELLO_COMPILE but the dependency for
> test_efi_helloworld_net_http was not updated and so is now incorrect
> preventing the test from ever runni
On Fri, Oct 25, 2024 at 05:47:32PM +0100, Andrew Goodbody wrote:
> The config setting CMD_BOOTEFI_HELLO_COMPILE was removed in favour
> of BOOTEFI_HELLO_COMPILE but the dependency for
> test_efi_helloworld_net_http was not updated and so is now incorrect
> preventing the test from ever running. Fi
The config setting CMD_BOOTEFI_HELLO_COMPILE was removed in favour
of BOOTEFI_HELLO_COMPILE but the dependency for
test_efi_helloworld_net_http was not updated and so is now incorrect
preventing the test from ever running. Fix it.
Fixes: 6fe80876dcc7 ("efi_loader: Rename and move CMD_BOOTEFI_HELLO
Hi,
I have collected couple of more patches and would be good for me to clean my
queue. There are some other patches which have been sent recently which will
come later after review.
I am especially waiting for memtop series (sent today) from Sughosh because it
is fixing issue on Kria platfo
From: Marek Vasut
Sent: Wednesday, October 23, 2024 4:05 PM
> On 10/23/24 3:20 PM, Christoph Niedermaier wrote:
>> From: Marek Vasut
>> Sent: Wednesday, October 23, 2024 2:41 PM
>>> On 10/23/24 2:18 PM, Christoph Niedermaier wrote:
>>>
>>> [...]
>>>
> You do not, the following automatically r
On Tue, Oct 8, 2024 at 6:27 AM Andre Przywara wrote:
>
> When trying to set the DCDC4 regulator, the code was accidentally
> setting the voltage register for DCDC5 (VCC-DRAM). The higher voltage
> doesn't harm the DRAM chips, but upsets the Linux regulator driver: when
> it tried to correct that,
Hi All,
we are testing QSPI flash in Cyclone V custom board. The QSPI pins used are
same like cyclone V sockit board.we are using uboot 2024.01
when we do sf probe, we got the below error. we have verified the pin mux
configuration and also enabled the clock.
=> sf probe 0:0
jedec_spi_nor flash@
On 2024/10/9 04:06, Jonas Karlman wrote:
The Hardkernel ODROID-M1S is a single-board computer based on Rockchip
RK3566 SoC. It features e.g. 4/8 GB LPDDR4 RAM, 64 GB eMMC, SD-card,
GbE LAN, HDMI 2.0, M.2 NVMe and USB 2.0/3.0.
Features tested on a ODROID-M1S 8GB rev1.0 20230906:
- SD-card boot
On Mon, Oct 7, 2024 at 6:22 AM Andre Przywara wrote:
>
> Clock gates and reset lines share a common structure in the sunxi clock
> driver descriptions, but use different flags to tell them apart.
>
> The description of the Allwinner A80 MMC clock reset lines was
> erroneously using the "GATE" macr
On 10/25/24 9:10 AM, Rasmus Villemoes wrote:
On Thu, Oct 24 2024, Marek Vasut wrote:
On 10/24/24 2:27 PM, Rasmus Villemoes wrote:
Loading flash.bin using uuu fails when flash.bin does not have the
right size.
When flash.bin is loaded from some storage medium (sd card/emmc),
SPL
just loads som
On Fri, Oct 25, 2024 at 11:51 AM Fabio Estevam wrote:
> > > Heiko, can you check if this works for you?
> >
> > Works fine for me, thanks!
>
> Applied, thanks.
Sorry, applied it too soon. I see there is an ongoing discussion.
I will wait for more time.
Hi Tom,
On Fri, Oct 25, 2024 at 11:46 AM Fabio Estevam wrote:
> Rasmus Villemoes (2):
> imx8m: set sane default value for SPL_LOAD_FIT_ADDRESS
> imx: hab: fix size of IVT+CSF blob tacked on to u-boot.itb
It seems this one needs more work/discusssion, so please disconsider this PR.
On Wed, Oct 23, 2024 at 8:54 AM Hiago De Franco wrote:
>
> From: Hiago De Franco
>
> Remove FASTBOOT_BUF_SIZE from verdin-imx8mm_defconfig and
> verdin-imx8mp_defconfig to use the default value of 0x700, aligning
> with other Toradex boards.
>
> Update FASTBOOT_BUF_ADDR to 0x4420, consist
On Fri, Oct 18, 2024 at 2:55 PM Fabio Estevam wrote:
>
> From: Fabio Estevam
>
> With CONFIG_DM_USB, there is no longer the need for any USB board code
> anymore.
>
> Remove the unneeded USB board code.
>
> While at it, also remove the uneeeded CONFIG_USB_MAX_CONTROLLER_COUNT
> option.
>
> Signed
Hi Lukasz,
On 10/25/24 4:27 PM, Łukasz Czechowski wrote:
Hi,
On 2024/10/25 14:30, Kever Yang wrote:
Hi Tom,
This is regression of "#ifdef CONFIG", is it possible for us to go
back to use "#ifdef CONFIG" in this case?
Or do you have any other suggestion for this issue?
On 2024/9/30 16
Hi Jesse,
On Thu, Oct 24, 2024 at 11:02 PM Jesse Taube wrote:
>
> Two of the clocks required by the usdhc1 controller are missing from the
> clock controller node. A recent change enables all the clocks in the
> esdhc node, which fails as they are not defined in the clock controller.
>
> Fixes: 7
On Fri, Oct 25, 2024 at 1:36 AM Heiko Schocher wrote:
>
> Hello Rasmus,
>
> On 24.10.24 14:27, Rasmus Villemoes wrote:
> > Loading flash.bin using uuu fails when flash.bin does not have the
> > right size.
> >
> > When flash.bin is loaded from some storage medium (sd card/emmc), SPL
> > just loads
On Tue, Oct 22, 2024 at 11:59 PM Peng Fan (OSS) wrote:
>
> From: Peng Fan
>
> Add 800MHz fracpll entry to support DDR 3200MTS.
>
> Signed-off-by: Peng Fan
Applied all, thanks.
On Fri, Oct 18, 2024 at 8:47 PM Peng Fan (OSS) wrote:
>
> From: Peng Fan
>
> serial_init runs into panic because no serial device found.
> Update the device tree to include bootph-some-ram for some critial
> devices needed in pre-reloc tage
>
> Fixes: 8c103c33fb1 ("dm: dts: Convert driver model t
st 23. 10. 2024 v 10:51 odesílatel Padmarao Begari
napsal:
>
> Update e-mail address.
>
> Signed-off-by: Padmarao Begari
> ---
> .mailmap | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/.mailmap b/.mailmap
> index 4d48349f0e..005e965b84 100644
> --- a/.mailmap
> +++ b/.mailmap
> @@ -89,
tags/u-boot-imx-master-20241025
for you to fetch changes up to 7ba5eef4543203d2b70c2355c79b932876aa3025:
ARM: dts: imxrt1170: Fix default cells value warnings (2024-10-25 09:08:34
-0300)
u-boot-imx-master-20241025
--
CI: https://source.denx.de/u-boot/custodians/u-boot
Hi,
On 2024/10/25 14:30, Kever Yang wrote:
>
> Hi Tom,
>
> This is regression of "#ifdef CONFIG", is it possible for us to go
> back to use "#ifdef CONFIG" in this case?
>
> Or do you have any other suggestion for this issue?
>
> On 2024/9/30 16:55, Quentin Schulz wrote:
> > Hi Kever,
> >
> >
On 10/16/24 06:44, Venkatesh Yadav Abbarapu wrote:
Add missing prototype to fix the sparse warning,
warning: no previous prototype for 'update_stripe'
[-Wmissing-prototypes].
Signed-off-by: Venkatesh Yadav Abbarapu
---
drivers/spi/zynq_qspi.c | 2 +-
1 file changed, 1 insertion(+), 1 dele
On Fri, Oct 25, 2024 at 08:30:44PM +0800, Kever Yang wrote:
> Hi Tom,
>
> This is regression of "#ifdef CONFIG", is it possible for us to go back
> to use "#ifdef CONFIG" in this case?
Yes, that's fine, thanks.
--
Tom
signature.asc
Description: PGP signature
Add generic logic to determine the ram_top value for boards. Earlier,
this was achieved in an indirect manner through a set of LMB API's.
That has since changed so that the LMB code is available only after
relocation. Replace those LMB calls with a single call to
get_mem_top() to determine the valu
On 10/25/24 14:15, Sughosh Ganu wrote:
The board_get_usable_ram_top() function is used by boards to compute
uppermost address of RAM(ram_top) that is to be used by U-Boot -- this
need not be the highest RAM address of the platform. This computation
happens before U-Boot relocates to its final
On 2024/10/9 04:06, Jonas Karlman wrote:
The vendor prefix for Hardkernel ODROID-M1 is incorrectly listed as
rockchip. Use the proper hardkernel vendor prefix for this board, while
at it also drop the redundant soc prefix.
Fixes: fd3583267703 ("arm64: dts: rockchip: Add Hardkernel ODROID-M1 bo
On 2024/9/19 22:00, Chris Morgan wrote:
From: Chris Morgan
Enable the PD_VO power domain before driver access on the rk3568 SoC.
Signed-off-by: Chris Morgan
Reviewed-by: Kever Yang
Thanks,
- Kever
---
arch/arm/mach-rockchip/rk3568/rk3568.c | 6 ++
1 file changed, 6 insertions(+)
On 2024/10/18 04:00, Jonas Karlman wrote:
From: Marcin Juszkiewicz
In the LTS (2310) version the miniPCIe slot got removed and USB 2.0
setup has changed. There are two external accessible ports and two ports
on the internal header.
There is an on-board USB hub which provides:
- one external
On 2024/10/18 04:00, Jonas Karlman wrote:
From: Marcin Juszkiewicz
FriendlyELEC NanoPC-T6 has optional SPI flash chip on-board.
It is populated with 32MB one on LTS version.
Signed-off-by: Marcin Juszkiewicz
Reviewed-by: Jonas Karlman
Link:
https://lore.kernel.org/r/20240829-friendlyelec-
On 2024/10/14 03:24, Heiko Stuebner wrote:
Contrary to the vendor-kernel the pmu-io-domains are not enabled by
default. This resulted in the value not being set according to the
regulator, which in turn made the gmac0 interface that is connected
to the vccio4 supply inoperable.
Fixes: 64b7f16f
On 2024/10/18 04:00, Jonas Karlman wrote:
Change to use vdd-microvolts prop value as voltage reference when the
supply regulator is missing or when DM_REGULATOR=n is used.
Signed-off-by: Jonas Karlman
Reviewed-by: Kever Yang
Thanks,
- Kever
---
drivers/adc/rockchip-saradc.c | 9 ++--
On 2024/10/18 04:00, Jonas Karlman wrote:
Update defconfig to enable features included in pending upstream DT and
implement board_fit_config_name_match() to load correct DT for LTS and
non-LTS version of the NanoPC-T6.
Signed-off-by: Jonas Karlman
Reviewed-by: Kever Yang
Thanks,
- Kever
-
On 2024/10/18 04:00, Jonas Karlman wrote:
Change to use vdd-microvolts prop value as voltage reference when the
supply regulator is missing or when DM_REGULATOR=n is used.
Signed-off-by: Jonas Karlman
Reviewed-by: Kever Yang
Thanks,
- Kever
---
drivers/adc/rockchip-saradc.c | 9 ++--
Hey Tim
On Thu, 2024-10-24 at 08:37 -0700, Tim Harvey wrote:
> On Thu, Oct 24, 2024 at 12:04 AM Yannic Moog
> wrote:
> >
> > There have been attempts to get op-tee node integrated upstream in
> > the
> > past [1][2]. The challenge is on how to handle the load and entry
> > addresses where the op
On 2024/10/18 04:00, Jonas Karlman wrote:
When DM_REGULATOR=n is used the device_get_supply_regulator() function
always return -ENOSYS.
Change to treat missing support for regulators as a missing optional
vdd/vss-supply regulator to reduce error messages being logged.
Signed-off-by: Jonas Kar
On 2024/10/18 04:00, Jonas Karlman wrote:
The SPI flash node has been added in upstream DT, drop all props beside
bootph-* props from the SPI flash related nodes from u-boot.dtsi.
Signed-off-by: Jonas Karlman
Reviewed-by: Kever Yang
Thanks,
- Kever
---
arch/arm/dts/rk3588-nanopc-t6-u-bo
On 2024/10/18 04:00, Jonas Karlman wrote:
From: Marcin Juszkiewicz
MiniPCIe slot is present only in first version of NanoPC-T6 (2301).
Signed-off-by: Marcin Juszkiewicz
Link:
https://lore.kernel.org/r/20240829-friendlyelec-nanopc-t6-lts-v6-3-edff247e8...@linaro.org
Signed-off-by: Heiko Stu
On 2024/10/18 04:00, Jonas Karlman wrote:
From: Marcin Juszkiewicz
FriendlyELEC introduced a second version of NanoPC-T6 SBC.
Create common include file and make NanoPC-T6 use it. Following
patches will add LTS version.
Signed-off-by: Marcin Juszkiewicz
Link:
https://lore.kernel.org/r/202
On 10/25/24 14:15, Sughosh Ganu wrote:
Add generic logic to determine the ram_top value for boards. Earlier,
this was achieved in an indirect manner through a set of LMB API's.
That has since changed so that the LMB code is available only after
relocation. Replace those LMB calls with a single
On 2024/10/9 04:06, Jonas Karlman wrote:
The Hardkernel ODROID-M1S is a single-board computer based on Rockchip
RK3566 SoC. It features e.g. 4/8 GB LPDDR4 RAM, 64 GB eMMC, SD-card,
GbE LAN, HDMI 2.0, M.2 NVMe and USB 2.0/3.0.
Add initial support for eMMC, SD-card, Ethernet, HDMI, PCIe and USB.
On 10/25/24 14:15, Sughosh Ganu wrote:
Use the get_mem_top function to compute the value of ram_top. This was
earlier done through LMB API's, which are no longer available till
after relocation. Use get_mem_top() instead to compute the ram_top
value.
Signed-off-by: Sughosh Ganu
---
board/x
On 2024/10/9 03:27, Jonas Karlman wrote:
After the full convertion of usb gadget interrupt handling to
usb_gadget_generic_ops, it is now possible to use DM_USB_GADGET,
DWC2_OTG and DWC3_GENERIC together without causing a build error.
Change to use USB_DWC3_GENERIC instead of USB_XHCI_DWC3 to c
Hi Tom,
This is regression of "#ifdef CONFIG", is it possible for us to go
back to use "#ifdef CONFIG" in this case?
Or do you have any other suggestion for this issue?
On 2024/9/30 16:55, Quentin Schulz wrote:
Hi Kever,
On 9/29/24 3:53 AM, Kever Yang wrote:
Hi Lukasz,
I think th
On Thu, 2024-10-24 at 08:32 -0700, Tim Harvey wrote:
> On Thu, Oct 24, 2024 at 12:04 AM Yannic Moog
> wrote:
> >
> > Add tee node in SoC u-boot device trees. Each board adds their
> > specific
> > load and entry addresses for the op-tee image in the respective
> > board-u-boot.dtsi file.
> >
> >
On 2024/10/14 03:24, Heiko Stuebner wrote:
Enable usb controllers and phys and add regulator infrastructure for the
usb ports on the TS433.
Of course there are no schematics available for the device, so the
regulator information comes from the vendor-devicetree with unknown
accuracy.
Tested-b
Use the get_mem_top function to compute the value of ram_top. This was
earlier done through LMB API's, which are no longer available till
after relocation. Use get_mem_top() instead to compute the ram_top
value.
Signed-off-by: Sughosh Ganu
---
board/xilinx/common/board.c | 25 +++
The board_get_usable_ram_top() function is used by boards to compute
uppermost address of RAM(ram_top) that is to be used by U-Boot -- this
need not be the highest RAM address of the platform. This computation
happens before U-Boot relocates to its final destination address in
RAM. Certain platform
On 2024/9/19 22:00, Chris Morgan wrote:
From: Chris Morgan
Some of the Powkiddy devices switched to using a different vendor for
the vdd_cpu regulator. Unfortunately the device does not have a new
revision to denote this, so users have no way of knowing in advance.
Add code to detect if a de
On 2024/9/19 22:00, Chris Morgan wrote:
From: Chris Morgan
Remove config options for ARM SCMI. It is not required to boot the
board and when using the most recent mainline A-TF it actually causes
the device to freeze during boot due to missing SCMI support.
Signed-off-by: Chris Morgan
Revi
On 2024/9/19 22:00, Chris Morgan wrote:
From: Chris Morgan
Refactor the board detection logic (again) to make it compatible with
the upstream device-trees, and switch to OF_UPSTREAM.
Now the device boots with the device-tree for the 353P, and then
loads the correct device tree (of 10) in the
On 2024/10/14 03:24, Heiko Stuebner wrote:
The Qnap TS433 is a 4-bay NAS based around the RK3568.
Two SATA bays are connected to the RK3568's own SATA controllers while
the other two are connected to a JMicron SATA controller living on the
PCIe bus.
It provides one 2.5Gb and one 1Gb ethernet
On 2024/10/14 03:24, Heiko Stuebner wrote:
The device contains two i2c-connected eeproms holding some product-
specific values. One sitting on the mainboard and one on the statically
connected backplane.
While the eeprom chips themself have a size of 512 byte, the eeprom data
only uses 256 byt
On 2024/10/14 03:24, Heiko Stuebner wrote:
From: Uwe Kleine-König
While it requires to have the right phy driver loaded (i.e. motorcomm)
to make the phy asserting the right delays, this is generally the
preferred way to define the MAC <-> PHY connection.
Signed-off-by: Uwe Kleine-König
Revi
On 2024/10/14 03:24, Heiko Stuebner wrote:
Add the two supplies for the pmu-io-domains that are defined in the
vendor devicetree for the TS433.
Tested-by: Uwe Kleine-König
Signed-off-by: Heiko Stuebner
Link: https://lore.kernel.org/r/20240723195538.1133436-15-he...@sntech.de
[ upstream comm
On 2024/10/14 03:24, Heiko Stuebner wrote:
The TS433 seems to use a silergy,syr827 regulator for the cpu supply.
At least that is the compatible used in the vendor devicetree, though
it could very well also be another fan53555 clone.
Define the needed regulator node and hook up the cpu-supply
On 2024/10/14 03:24, Heiko Stuebner wrote:
The TS433 doesn't provide display output, but the gpu nevertheless can be
used for compute tasks for example.
So there is no reason not to enable it.
Tested-by: Uwe Kleine-König
Signed-off-by: Heiko Stuebner
Link: https://lore.kernel.org/r/20240723
1 - 100 of 153 matches
Mail list logo