On Thu, 14 Mar 2024 at 09:45, Marek Vasut wrote:
>
> On 3/12/24 8:03 AM, Sumit Garg wrote:
> > pcie_imx doesn't seem to share any useful code for iMX8 SoC and it is
> > tied to quite old port of pcie_designware driver from Linux which
> > suffices only iMX6 specific needs.
> >
> > But currently
On Thu, 14 Mar 2024 at 09:45, Marek Vasut wrote:
>
> On 3/12/24 8:03 AM, Sumit Garg wrote:
> > Expose the high performance PLL as a regular Linux clock
>
> ... as clock framework clock ...
>
Ack.
> > , so the
> > PCIe PHY can use it when there is no external refclock provided.
> >
> > Inspired
On Thu, 14 Mar 2024 at 09:46, Marek Vasut wrote:
>
> On 3/12/24 8:03 AM, Sumit Garg wrote:
> > Add initial support for i.MX8M{M/P} PCIe PHY. On i.MX8M{M/P} SoCs PCIe
> > PHY initialization moved to this standalone PHY driver.
> >
> > Inspired from counterpart Linux kernel v6.8-rc3 driver:
> >
On Thu, 14 Mar 2024 at 09:45, Marek Vasut wrote:
>
> On 3/12/24 8:03 AM, Sumit Garg wrote:
> > imx7_reset_{deassert/assert}_imx* are a bit more confusing when compared
> > with imx*_reset_{deassert/assert}. So refactor driver to use function
> > names easier to understand. This shouldn't affect
On Thu, 14 Mar 2024 at 09:45, Marek Vasut wrote:
>
> On 3/12/24 8:03 AM, Sumit Garg wrote:
> > Add support for i.MX8MP reset controller, it has same reset IP inside
> > as the other iMX7 and iMX8 variants but with different module layout.
>
> iMX8M , iMX8 is a different SoC .
Ack.
>
> >
On Thu, 14 Mar 2024 at 09:45, Marek Vasut wrote:
>
> On 3/12/24 8:03 AM, Sumit Garg wrote:
> > power_domain_on/off() isn't refcounted and power domain bus shouldn't be
> > turned off for a single peripheral domain as it would negatively affect
> > other peripheral domains. So lets just skip
On Thu, 14 Mar 2024 at 21:28, Tim Harvey wrote:
>
> On Thu, Mar 14, 2024 at 12:50 AM Sumit Garg wrote:
> >
> > + Tom
> >
> > Hi Tim,
> >
> > On Wed, 13 Mar 2024 at 22:01, Tim Harvey wrote:
> > >
> > > On Wed, Mar 13, 2024 at 6:20 AM Sumit Garg wrote:
> > > >
> > > > On Wed, 13 Mar 2024 at
This moves us to our latest container image, which is now based on the
current "Jammy" tag.
Signed-off-by: Tom Rini
---
.azure-pipelines.yml| 2 +-
.gitlab-ci.yml | 2 +-
tools/docker/Dockerfile | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git
Conor Dooley 于2024年3月12日周二 21:20写道：
>
> On Tue, Mar 12, 2024 at 05:59:44PM +0800, Leo Liang wrote:
> > On Sun, Mar 10, 2024 at 01:56:45PM +0800, Kongyang Liu wrote:
> > > Add ethernet node for cv1800b SoC
> > >
> > > Signed-off-by: Kongyang Liu
> > > ---
> > >
> > > arch/riscv/dts/cv18xx.dtsi |
Leo Liang 于2024年3月12日周二 17:59写道：
>
> On Sun, Mar 10, 2024 at 01:56:45PM +0800, Kongyang Liu wrote:
> > Add ethernet node for cv1800b SoC
> >
> > Signed-off-by: Kongyang Liu
> > ---
> >
> > arch/riscv/dts/cv18xx.dtsi | 6 ++
> > 1 file changed, 6 insertions(+)
>
> Hi KongYang,
>
> Will
Hi Tom,
This is for next;
Please pull the updates for rockchip platform:
- Add board: rk3588 Generic, Cool Pi CM5, Theobroma-Systems RK3588 Jaguar SBC,
Toybrick TB-RK3588X;
rk3588s Cool Pi 4B;
rk3566 Pine64 PineTab2;
- Add saradc v2 support;
- Add PMIC RK806
Hi Ilias,
> -Original Message-
> From: Ilias Apalodimas
> Sent: Thursday, March 14, 2024 10:54 PM
> To: Kojima, Masahisa/小島 雅久
> Cc: u-boot@lists.denx.de; Heinrich Schuchardt
> Subject: Re: [PATCH] efi_loader: accept append write with valid size and data
>
> Hi Kojima-san
>
>
Hi Detlev,
On 2024-03-14 15:43, Detlev Casanova wrote:
> Set the MAC address based on the CPU ID only if the ethernet device has
> no ROM or DT address set.
This patch changes behavior and once again require CONFIG_NET to fixup
the device tree with local-mac-address for the ethernet0/1 alias
On 3/14/24 3:43 PM, Detlev Casanova wrote:
Set the MAC address based on the CPU ID only if the ethernet device has
no ROM or DT address set.
Signed-off-by: Detlev Casanova
More of a general design question -- how much of this can be done in MAC
driver specific .read_rom_hwaddr callback ?
On 3/14/24 3:43 PM, Detlev Casanova wrote:
On some boards, a MAC address is set based on the CPU ID or other
information. This is usually done in the misc_init_r() function.
This becomes a problem for net devices that are probed after the call to
misc_init_r(), for example, when the ethernet is
On Thu, Mar 14, 2024 at 12:50 AM Sumit Garg wrote:
>
> + Tom
>
> Hi Tim,
>
> On Wed, 13 Mar 2024 at 22:01, Tim Harvey wrote:
> >
> > On Wed, Mar 13, 2024 at 6:20 AM Sumit Garg wrote:
> > >
> > > On Wed, 13 Mar 2024 at 06:46, Fabio Estevam wrote:
> > > >
> > > > Hi Tim,
> > > >
> > > > On Tue,
Some net driver, like rtl8169, can set/get the MAC address from the
registers and store it in pdata->enetaddr.
When that happens, if there is a mismatch with the environment MAC
address, u-boot will show that the MAC address source is DT. This patch
ensures that the shown source is "driver"
Set the MAC address based on the CPU ID only if the ethernet device has
no ROM or DT address set.
Signed-off-by: Detlev Casanova
---
arch/arm/Kconfig | 1 +
arch/arm/include/asm/arch-rockchip/misc.h | 1 +
arch/arm/mach-rockchip/board.c| 30
On some boards, a MAC address is set based on the CPU ID or other
information. This is usually done in the misc_init_r() function.
This becomes a problem for net devices that are probed after the call to
misc_init_r(), for example, when the ethernet is on a PCI port, which
needs to be enumerated.
Basically, the MAC address generation needs to use a board function in
its decision algorithm so that there is no MAC mismatch between ROM and
environment depending on the order of function calling.
See the first commit message for details.
Detlev Casanova (3):
net: Add a
On 3/14/2024 6:16 PM, Tom Rini wrote:
> On Tue, Mar 12, 2024 at 02:02:08PM +0530, MD Danish Anwar wrote:
>>
>>
>> On 11/03/24 10:34 am, Anwar, Md Danish wrote:
>>>
>>>
>>> On 3/7/2024 6:16 PM, Tom Rini wrote:
On Wed, Feb 28, 2024 at 05:36:45PM +0530, MD Danish Anwar wrote:
> Add APIs
load_firmware() API calls fs-loader APIs and checks for CONFIG_FS_LOADER
before calling those APIs. The if check only checks for CONFIG_FS_LOADER
but not for CONFIG_SPL_FS_LOADER.
When CONFIG_FS_LOADER is enabled, load_firmware() API calls fs-loader APIs
but this is done at SPL stage and at this
load_firmware() API calls fs-loader APIs and checks for CONFIG_FS_LOADER
before calling those APIs. The if check only checks for CONFIG_FS_LOADER
but not for CONFIG_SPL_FS_LOADER.
When CONFIG_FS_LOADER is enabled, load_firmware() API calls fs-loader APIs
but this is done at SPL stage and at this
On Tue, 12 Mar 2024 15:20:18 -0500, Bryan Brattlof wrote:
> The AM62Px is an extension of the existing Sitara AM62x low-cost family
> of application processors built for Automotive and Linux Application
> development. Scalable Arm Cortex-A53 performance and embedded features,
> such as: multi
Hi Kojima-san
Apologies for the late reply
On Mon, 4 Mar 2024 at 08:10, Masahisa Kojima
wrote:
>
> Current "variables" efi_selftest result is inconsistent
> between the U-Boot file storage and the tee-based StandaloneMM
> RPMB secure storage.
> U-Boot file storage implementation does not accept
Hi Christopher,
On 3/14/24 12:57, Christopher Obbard wrote:
When debugging the SPL boot order, the node ID of a device which hasn't
been found is printed but it can be quite hard to relate that to the
specific devicetree node. To aid debugging, print the node path instead of
the cryptic node
On Tue, Mar 12, 2024 at 02:02:08PM +0530, MD Danish Anwar wrote:
>
>
> On 11/03/24 10:34 am, Anwar, Md Danish wrote:
> >
> >
> > On 3/7/2024 6:16 PM, Tom Rini wrote:
> >> On Wed, Feb 28, 2024 at 05:36:45PM +0530, MD Danish Anwar wrote:
> >>> Add APIs to set a firmware_name to a rproc and boot
On Thu, Mar 14, 2024 at 01:19:40AM +0100, Heinrich Schuchardt wrote:
> Dear Tom,
>
> The following changes since commit f3c979dd0053c082d2df170446923e7ce5edbc2d:
>
> Prepare v2024.04-rc4 (2024-03-11 13:11:46 -0400)
>
> are available in the Git repository at:
>
>
On Wed, Mar 13, 2024 at 10:14:01PM +0100, Daniel Schwierzeck wrote:
> Hi Tom,
>
> please pull two bugfixes for MIPS, thanks.
>
> CI: https://source.denx.de/u-boot/custodians/u-boot-mips/-/pipelines/19933
>
> The following changes since commit f3c979dd0053c082d2df170446923e7ce5edbc2d:
>
>
On Thu, 14 Mar 2024 at 12:58, Christopher Obbard
wrote:
>
> When debugging the SPL boot order, the node ID of a device which hasn't
> been found is printed but it can be quite hard to relate that to the
> specific devicetree node. To aid debugging, print the node path instead of
> the cryptic
On 13/Mar/2024 Milan P. Stanić wrote:
> On Wed, 2024-02-21 at 13:00, Nam Cao wrote:
> > Distro boot scripts are deprecated. Use standard boot instead.
> I had to enable 'CONFIG_CMD_SYSBOOT=y' in
> configs/starfive_visionfive2_defconfig because it doesn't boot without
> it. With this option it
When debugging the SPL boot order, the node ID of a device which hasn't
been found is printed but it can be quite hard to relate that to the
specific devicetree node. To aid debugging, print the node path instead of
the cryptic node ID.
Original debug message:
board_boot_order: could not map
Fix a simple spelling mistake in a comment.
Reviewed-by: Dragan Simic
Reviewed-by: Quentin Schulz
Signed-off-by: Christopher Obbard
---
Changes in v2:
- Improve patch subject (suggested by Dragan S).
- Collect Reviewed-by tags from Dragan S and Quentin S.
This series contains some trivial fixes for the Rockchip SPL boot order
driver.
The first patch fixes a typo in a comment.
The second patch prints the full devicetree node path (rather than just
the node ID) in the debug message when a boot device can't be found.
This series may be found at
On Thu, Mar 14, 2024 at 02:41:29PM +0800, Jixiong Hu wrote:
> Modified the ext4fs_write function to create a new file that
> inherits the inode->mode of existing file. To fix an issue
> where file permissions are changed after modifying the contents
> of an existing file.
I'm not an expert, but
Modified the ext4fs_write function to create a new file that
inherits the inode->mode of existing file. To fix an issue
where file permissions are changed after modifying the contents
of an existing file.
---
fs/ext4/ext4_write.c | 20 ++--
1 file changed, 18 insertions(+), 2
From: Quentin Schulz
ADC support is implied by the Rockchip arch Kconfig but that means it
should be possible to disable ADC support and still be able to build.
However the weak implementation of rockchip_dnl_key_pressed() currently
blindly use functions from the ADC subsystem which do not
From: Quentin Schulz
The BUTTON_ADC symbol guards the compilation of button-adc driver whose
name very well makes it explicit that it requires ADC support to be
enabled.
Fix build issue of button-adc driver when ADC support isn't enabled by
making sure it cannot be built without ADC support.
From: Quentin Schulz
The ADC controller drivers are obviously all depending on ADC symbol
being selected.
While they don't seem to fail to build without, they won't be useful
without that symbol selected, so let's make sure the options aren't
shown in menuconfig when ADC isn't selected.
Cc:
From: Quentin Schulz
The SARADC is used on Jaguar for multiple things:
- channel 0 is used (at runtime) as a BIOS button,
- channel 2 is exposed on the Mezzanine connector for customer specific
logic,
- channel 5 and 6 are used for identification,
Since the SARADC requires a vref-supply
From: Quentin Schulz
SPL_PMIC_RK8XX and PMIC_RK8XX both share the same prompt making it
difficult to know at first glance in menuconfig what's for what, let's
fix this by adding "in SPL" at the end of the prompt for the SPL symbol.
Cc: Quentin Schulz
Reviewed-by: Kever Yang
Signed-off-by:
From: Quentin Schulz
This adds support for the SARADCv2 found on RK3588.
There is no stop callback as it is currently configured in single
conversion mode, where the ADC is powered down after a single conversion
has been made.
Due to what seems to be a silicon bug, a controller reset needs to
From: Quentin Schulz
SARADC v2 doesn't have a stop mechanism once in single mode. In series
conversion, the logic is different anyway. Therefore, let's abstract
this function so that it can be provided from the udevice.data pointer.
Cc: Quentin Schulz
Reviewed-by: Kever Yang
Signed-off-by:
From: Quentin Schulz
SARADC v1 and v2 have a different way of starting a channel, therefore
let's abstract this function so that it can be provided from the
udevice.data pointer.
Cc: Quentin Schulz
Reviewed-by: Kever Yang
Signed-off-by: Quentin Schulz
---
drivers/adc/rockchip-saradc.c | 30
From: Quentin Schulz
SARADC v1 and v2 have a different way of reading data, therefore let's
abstract this function so that it can be provided from the udevice.data
pointer.
Cc: Quentin Schulz
Reviewed-by: Kever Yang
Signed-off-by: Quentin Schulz
---
drivers/adc/rockchip-saradc.c | 37
From: Quentin Schulz
The registers are entirely different between SARADC v1 and SARADC v2, so
let's prepare to add another struct for accessing v2 registers by adding
a union.
Cc: Quentin Schulz
Reviewed-by: Kever Yang
Signed-off-by: Quentin Schulz
---
drivers/adc/rockchip-saradc.c | 23
From: Quentin Schulz
This adds support for RK806, only the SPI variant has been tested.
The communication "protocol" over SPI is the following:
- write three bytes:
- 1 byte: [0:3] length of the payload, [6] Enable CRC, [7] Write
- 1 byte: LSB register address
- 1 byte: MSB register
From: Quentin Schulz
Reword the help text for the pmic read and pmic write commands to better
match what's expected from the user.
Cc: Quentin Schulz
Reviewed-by: Kever Yang
Signed-off-by: Quentin Schulz
---
cmd/pmic.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
From: Quentin Schulz
By passing a rk8xx_reg_info directly to the internal get_value, it'd be
possible to call this same function with a logic for getting the
rk8xx_reg_info different from the current get_ldo_reg, e.g. for NLDO and
PLDO support for RK806.
No logic change is expected.
Cc:
From: William Wu
On RK809 in PMIC_POWER_ENX registers, in order to set or clear a bit N,
the bit at offset N + 4 needs to be set otherwise nothing is done.
This fixes the inability to modify the SWITCH state on RK809.
Cc: Quentin Schulz
Signed-off-by: William Wu
[reworded commit log]
From: Quentin Schulz
Those two functions had their last user removed in commit f9c68a566c4d
("rockchip: phycore_rk3288: remove phycore_init() function") part of
v2023.01 release, so let's do some cleanup here.
Cc: Quentin Schulz
Reviewed-by: Kever Yang
Signed-off-by: Quentin Schulz
---
From: Quentin Schulz
The read-only mode is currently supported but only for 16b-aligned
buffers. For unaligned buffers, the last byte will be read in RW mode
right now, which isn't what is desired. Instead, let's put the
controller back into RO mode for that last byte and skip any write in
the
The RK3588 has a new IP for SARADC compared to older SoCs of the same
vendor but most of the boilerplate is shared, so rockchip-saradc.c
driver is adapted instead of creating a new one.
Because the SARADC requires a vref-supply which is commonly coming from
a regulator of the RK806 PMIC, support
Hi Anatolij,
On Mon, Feb 19, 2024 at 5:19 PM Jagan Teki wrote:
>
> Hi Anatolij,
>
> On Wed, Jan 17, 2024 at 1:22 PM Jagan Teki wrote:
> >
> > From: Jagan Teki
> >
> > Unlike RK3399, Sunxi/Meson DW HDMI the new Rockchip SoC Rk3328 would
> > support external vendor PHY with DW HDMI chip.
> >
> >
On 2/27/24 15:43, Mihai Sain wrote:
> This patch series adds initial support for Microchip SAMA7G54 Curiosity board.
>
> Changes in v2:
> --
>
> * Update flexcom 10 node in order to match previous flexcom definitions.
> * Sort in alphabetical order all nodes and pinctrl.
> * Remove
Hi,
On 3/14/24 09:34, Ilias Apalodimas wrote:
Hi Michal
On Wed, 13 Mar 2024 at 09:01, Ilias Apalodimas
wrote:
On Wed, 13 Mar 2024 at 08:42, Michal Simek wrote:
On 3/12/24 20:12, Ilias Apalodimas wrote:
On Tue, 12 Mar 2024 at 17:55, Michal Simek wrote:
On 3/12/24 07:14, Ilias
Hi Michal
On Wed, 13 Mar 2024 at 09:01, Ilias Apalodimas
wrote:
>
> On Wed, 13 Mar 2024 at 08:42, Michal Simek wrote:
> >
> >
> >
> > On 3/12/24 20:12, Ilias Apalodimas wrote:
> > > On Tue, 12 Mar 2024 at 17:55, Michal Simek wrote:
> > >>
> > >>
> > >>
> > >> On 3/12/24 07:14, Ilias Apalodimas
Hi Richard,
On Thu, 14 Mar 2024 at 00:43, Richard Henderson
wrote:
>
> On 3/13/24 11:43, Ilias Apalodimas wrote:
> > Hi Richard,
> >
> > On Wed, 13 Mar 2024 at 22:19, Richard Henderson
> > wrote:
> >>
> >> On 3/13/24 06:23, Ilias Apalodimas wrote:
> >>> +++ b/arch/arm/cpu/armv8/u-boot-spl.lds
Hi Love,
On Thu, 2024-03-14 at 12:15 +0530, Love Kumar wrote:
> Hi,
>
> When we run in el3 for zynqmp board, we are seeing below issue with this
> patch:
>
>
> Model: ZynqMP MINI EMMC0
> Board: Xilinx ZynqMP
> DRAM: 512 MiB
> EL Level: EL3
> Secure Boot: not authenticated, not
+ Tom
Hi Tim,
On Wed, 13 Mar 2024 at 22:01, Tim Harvey wrote:
>
> On Wed, Mar 13, 2024 at 6:20 AM Sumit Garg wrote:
> >
> > On Wed, 13 Mar 2024 at 06:46, Fabio Estevam wrote:
> > >
> > > Hi Tim,
> > >
> > > On Tue, Mar 12, 2024 at 4:05 PM Tim Harvey wrote:
> > > >
> > > > Move to
On 2024/3/8 11:00, Ben Wolsieffer wrote:
Currently, if the environment is stored on an MMC device, the device
number is hardcoded by CONFIG_SYS_MMC_ENV_DEV. This is problematic
because many boards can choose between booting from an SD card or a
removable eMMC. For example, the Rock64 defconfig
Hi Kever,
On 2024-03-14 08:33, Kever Yang wrote:
> Hi Jonas,
>
> On 2024/3/14 15:04, Jonas Karlman wrote:
>> Hi Kever,
>>
>> On 2024-03-14 07:58, Kever Yang wrote:
>>> On 2024/2/1 06:08, Jonas Karlman wrote:
Add a minimal generic RK3588S/RK3588 board that only have eMMC and SDMMC
Hi Jonas,
On 2024/3/14 15:04, Jonas Karlman wrote:
Hi Kever,
On 2024-03-14 07:58, Kever Yang wrote:
On 2024/2/1 06:08, Jonas Karlman wrote:
Add a minimal generic RK3588S/RK3588 board that only have eMMC and SDMMC
enabled. This defconfig can be used to boot from eMMC or SD-card on most
Hi Kever,
On 2024-03-13 11:39, Kever Yang wrote:
> Hi Jonas,
>
> This patch does not able to apply on next, could you help to take a
> look.
>
> And also add document of memory layout in rockchip.rst if possible.
I will send a follow-up patch that adds details about this memory layout
Hi Kever,
On 2024-03-14 07:58, Kever Yang wrote:
>
> On 2024/2/1 06:08, Jonas Karlman wrote:
>> Add a minimal generic RK3588S/RK3588 board that only have eMMC and SDMMC
>> enabled. This defconfig can be used to boot from eMMC or SD-card on most
>> RK3588S/RK3588 boards that follow reference
Hi Kever,
On 2024-03-14 07:50, Kever Yang wrote:
>
> On 2024/2/5 01:30, Jonas Karlman wrote:
>> The Pine64 PineTab2 is a tablet computer based on the Rockchip RK3566
>> SoC. The table features 4/8 GB LPDDR4 RAM and 64/128 GB eMMC storage.
>>
>> Features tested on a Pine64 PineTab2 8GB v2.0:
>> -
On 2024/2/1 06:08, Jonas Karlman wrote:
Add a minimal generic RK3588S/RK3588 board that only have eMMC and SDMMC
enabled. This defconfig can be used to boot from eMMC or SD-card on most
RK3588S/RK3588 boards that follow reference board design.
Also fix the alphabetical order of RK3588 boards
On 2024/2/6 02:58, Chris Morgan wrote:
From: Chris Morgan
Add ADC button detect for early SPL stage for RGxx3 device. This is
important because on at least the RG353P and RG353V a clk pin is not
exposed that would allow us to take the eMMC out of the boot path.
Signed-off-by: Chris Morgan
On 2024/2/6 02:58, Chris Morgan wrote:
From: Chris Morgan
Remove unnecessary clock frequency defines from the RGxx3 u-boot dts.
Move the necessary defines to the RGxx3 main dts file.
Signed-off-by: Chris Morgan
Reviewed-by: Kever Yang
Thanks,
- Kever
---
On 2024/2/5 01:30, Jonas Karlman wrote:
The Pine64 PineTab2 is a tablet computer based on the Rockchip RK3566
SoC. The table features 4/8 GB LPDDR4 RAM and 64/128 GB eMMC storage.
Features tested on a Pine64 PineTab2 8GB v2.0:
- SD-card boot
- eMMC boot
- SPI Flash boot
- USB host
Device
On 2024/3/13 23:32, Jonas Karlman wrote:
Hi Kever and Chen-Yu,
On 2024-03-13 15:43, Chen-Yu Tsai wrote:
Hi,
On Wed, Mar 13, 2024 at 6:29 PM Kever Yang wrote:
Hi Chen-Yu,
On 2024/2/12 21:51, Chen-Yu Tsai wrote:
From: Chen-Yu Tsai
Regenerate RK3328 defconfigs after adding imply
Hi,
When we run in el3 for zynqmp board, we are seeing below issue with this
patch:
Model: ZynqMP MINI EMMC0
Board: Xilinx ZynqMP
DRAM: 512 MiB
EL Level: EL3
Secure Boot: not authenticated, not encrypted
Multiboot: 0
Core: 10 devices, 9 uclasses, devicetree: embed
MMC:
72 matches
Mail list logo
