from MMC(%d)... ", dev);
+
ret = env_import(buf, 1, H_EXTERNAL);
if (!ret) {
ep = (env_t *)buf;
---
base-commit: b03b49046af5dfca599d2ce8f0aafed89b97aa91
change-id: 20240415-mmc-loadenv-dev-ced678171e98
Best regards,
On Mon, Apr 15, 2024 at 4:50 AM Heinrich Schuchardt
wrote:
>
> The EEPROM provides information about the size of the EEPROM.
"The EEPROM provides information about the size of the eMMC."
> Provide a new function get_mmc_size_from_eeprom() to read it.
>
> Signed-off-by: Heinrich Schuchardt
>
Hi Michael,
On Mon, 15 Apr 2024 at 22:55, Michael Nazzareno Trimarchi
wrote:
>
> Very good job ;) to fix it. Just add Suggest-by: ;)
Thank you for your advice.
I sent following v2 patch.
https://lore.kernel.org/u-boot/20240416002624.1909-1-yasuharu.shib...@gmail.com/
--
Best regards,
Yasuharu
On Mon, Apr 15, 2024 at 02:49:13PM +0200, Michal Simek wrote:
>
>
> On 4/15/24 14:22, Heinrich Schuchardt wrote:
> > On 15.04.24 13:35, Michal Simek wrote:
> > > Some of Kconfigs are using utf-8 encoding because of used chars. Convert
> > > all of them to ascii enconging.
> > >
> > >
On Mon, Apr 15, 2024 at 02:22:02PM +0200, Heinrich Schuchardt wrote:
> On 15.04.24 13:35, Michal Simek wrote:
> > Some of Kconfigs are using utf-8 encoding because of used chars. Convert
> > all of them to ascii enconging.
> >
> > Signed-off-by: Michal Simek
[snip]
> > diff --git
On Mon, Apr 15, 2024 at 02:43:57PM +0200, Quentin Schulz wrote:
> From: Quentin Schulz
>
> This prints the MMC device being read similar to how we print the MMC
> device we write to when e.g. calling saveenv.
>
> One of the side effects is that the boot log now shows from which MMC
> device
024-04-14
> 15:58:31 -0600)
>
> are available in the Git repository at:
>
> https://gitlab.denx.de/u-boot/custodians/u-boot-imx.git
> tags/u-boot-imx-master-20240415
>
> for you to fetch changes up to 8ecb0931940cc19728d686b9dba06585f4d93709:
>
> clk: imx93: fix
On Mon, Apr 15, 2024 at 06:52:30PM +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.
>
> BTW, I'm checking other pending patches in more detail.
> After checking, I will apply them into u-boot-mmc.
ince commit b03b49046af5dfca599d2ce8f0aafed89b97aa91:
>
> Merge https://source.denx.de/u-boot/custodians/u-boot-usb (2024-04-14
> 15:58:31 -0600)
>
> are available in the Git repository at:
>
> https://source.denx.de/u-boot/custodians/u-boot-socfpga.
If tcp_seq_num is wrap around, tcp_seq_num >= initial_data_seq_num
isn't satisfied and store_block() isn't called.
The condition has a wrap around issue, so it is fixed in this patch.
Signed-off-by: Yasuharu Shibata
Reviewed-by: Michael Trimarchi
Suggested-by: Michael Trimarchi
Reported-by:
Hi Marek,
I'm running a regression test with this patch on another Armada 385
board (Synology DS116). And
it is running without problem.
I noticed that there is no version bump. Is this still 14.0.0? It's kind of
hard to see which version we are using without a minor revision such as 14.0.1.
From: Fabio Estevam
The following information printed on every boot is not very
helpful for the users:
SOC: 0xa0009300
LC: 0x40040
Move them to debug() level.
Signed-off-by: Fabio Estevam
---
board/freescale/imx93_evk/spl.c | 4 ++--
board/phytec/phycore_imx93/spl.c| 4 ++--
Dne ponedeljek, 15. april 2024 ob 02:22:45 GMT +2 je Andre Przywara napisal(a):
> On Sat, 13 Apr 2024 21:43:52 +0800
> da...@189.cn wrote:
>
> Hi,
>
> thanks for sending a patch!
>
> > From: lalakii
> >
> > Add "DRAM_SUN50I_H616_TRIM_SIZE" option for 1.5gb board.
> >
> > Signed-off-by:
From: Nitin Yadav
U-Boot is failing to boot class U1 UHS SD cards due to incorrect
OTAP and ITAP delay select values. Update OTAP and ITAP delay select
values from DT.
Fixes: c7d106b4eb3 ("mmc: am654_sdhci: Update output tap delay writes")
Signed-off-by: Nitin Yadav
Signed-off-by: Judith
According to the device datasheet [0], ENDLL=1 for
DDR52 mode, so call am654_sdhci_setup_dll() and write
itapdly after since we do not carry out tuning.
[0] https://www.ti.com/lit/ds/symlink/am62p.pdf
Fixes: c964447ea3d6 ("mmc: am654_sdhci: Add support for input tap delay")
Signed-off-by: Judith
Currently the sdhci_am654 driver only supports one tuning
algorithm which should be used only when DLL is enabled. The
ITAPDLY is selected from the largest passing window and the
buffer is viewed as a circular buffer.
The new tuning algorithm should be used when the delay chain
is enabled; the
The following patch series includes a MMC tuning algorithm
fix according to the following published paper [0].
This seris also includes fixes for OTAP/ITAP delay values
in j721e_4bit_sdhci_set_ios_post and for HS400 mode.
For DDR52 mode, also set ENDLL=1 and call am654_sdhci_setup_dll()
instead
At HS400 mode the ITAPDLY value is that from High Speed mode
which is incorrect and may cause boot failures.
The ITAPDLY for HS400 speed mode should be the same as ITAPDLY
as HS200 timing after tuning is executed. Add the functionality
to save ITAPDLY from HS200 tuning and save as HS400 ITAPDLY.
Set itap_del_ena if ITAPDLY is found in DT or if the tuning
algorithm was executed and found the optimal ITAPDLY. Add the
functionality to save ITAPDLYENA that can be referenced later
by storing the bit in array itap_del_ena[].
Signed-off-by: Judith Mendez
---
drivers/mmc/am654_sdhci.c | 30
Hi Francesco
On Mon, 2024-04-15 at 09:54 +0200, Francesco Dolcini wrote:
> From: Parth Pancholi
>
> Adds tifsstub binaries, this is required for deepsleep functionality.
>
> This implements the same change as commit 128f81290b7d ("arm: dts: k3:
> binman: am625: add support for signing TIFSSTUB
Hi Tom,
On 12-Apr-24 8:20 PM, Tom Rini wrote:
On Fri, Mar 22, 2024 at 06:40:07PM +0530, Neha Malcom Francis wrote:
This series does primarily three things:
1. Split out the common J721E defconfig for both EVM and SK
2. Cleanup k3-j721e-binman.dtsi to be SoC specific binman
On Mon, 15 Apr 2024 16:03:37 +0100, Caleb Connolly wrote:
> The msm serial UART controller has a bit clock divider register which
> much be programmed based on the UART clock. This changes per soc and
> currently is expected to be specified in DT or otherwise selected per
> board.
>
> This
On Mon, 15 Apr 2024 12:49:25 +0200, Robert Marko wrote:
> Currently, DEBUG_UART_MSM depends on ARCH_SNAPDRAGON only, but IPQ40XX
> devices also use the same UART HW so they can also use the debug UART.
>
> So, allow selecting DEBUG_UART_MSM when using ARCH_IPQ40XX as well.
>
>
Applied,
Hey,
> Do I need to switch back to only convert i.MX93 11x11 EVK to
> OF_UPSTREM?
That could be an idea. I can take over the switch for the other devices
when I have some time to perform the debugging.
Mathieu
Support old DDR3 training code on Turris Omnia, selectable by U-Boot
enviroment variable.
Users experiencing DDR3 initialization failures or random crashes of the
operating system due to incorrect DDR3 configuration can select the old
DDR3 training implementation to fix those issues by setting
Add optional support for using old DDR3 training code from 2017.
The code lives in drivers/ddr/marvell/a38x/old/. To prevent symbol
clashing with new DDR3 training code, a special header which renames all
clashing symbols via macros is included and the symbols are prefixed
with 'old_'.
If old
Backport the option to compile with immutable debug settings also to
the old implementation of the DDR3 training code.
The original PR for mv-ddr-marvell can be seen at
https://github.com/MarvellEmbeddedProcessors/mv-ddr-marvell/pull/45/
Signed-off-by: Marek Behún
---
Fix some compilation warning in the old DDR training code.
Signed-off-by: Marek Behún
---
drivers/ddr/marvell/a38x/old/ddr3_a38x.c | 1 +
drivers/ddr/marvell/a38x/old/ddr3_init.h | 2 ++
drivers/ddr/marvell/a38x/old/ddr3_training.c | 1 +
Save 10 KiB in Turris Omnia's SPL binary by enabling immutable debug
settings for DDR3 training code.
Signed-off-by: Marek Behún
---
configs/turris_omnia_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/configs/turris_omnia_defconfig b/configs/turris_omnia_defconfig
index
Allow compiling with immutable debug settings:
- DEBUG_LEVEL is always set to DEBUG_LEVEL_ERROR
- register dumps are disabled
This can save around 10 KiB of space in the resulting binary, which is a
lot in U-Boot SPL.
Signed-off-by: Marek Behún
---
arch/arm/mach-mvebu/Kconfig | 10
The variables is_validate_window_per_if, is_validate_window_per_pup,
sweep_cnt and is_run_leveling_sweep_tests are only used if
DDR_VIEWER_TOOL macro is defined, so define them only in that case.
Make them static since they are only used in ddr3_debug.c.
Signed-off-by: Marek Behún
---
Return from ddr3_tip_print_log() early if we won't print anything
anyway.
This way the compiler can optimize away the VALIDATE_IF_ACTIVE() calls
in the for-loop, so if the SILENT_LIB macro is defined, no code is
generated for the rest of the function, which saves some space.
Signed-off-by: Marek
The variables is_default_centralization, is_tune_result and
is_bist_reset_bit are never used.
Signed-off-by: Marek Behún
---
drivers/ddr/marvell/a38x/ddr3_debug.c | 3 ---
drivers/ddr/marvell/a38x/ddr3_init.h | 1 -
2 files changed, 4 deletions(-)
diff --git
Hi Stefan,
this series adds some changes to DDR3 training for Armada 38x and
Turris Omnia.
- patches 1-4 are meant to allow for reducing another 10 KiB in the
SPL binary. They were also sent to mv-ddr-marvell, via PR on github,
On Mon, Apr 15, 2024 at 1:21 PM Caleb Connolly
wrote:
>
> Hi Robert,
>
> Happy to see someone working on those IPQ platforms. If it makes sense
> to then I'd be happy to adopt them under ARCH_SNAPDRAGON at some point?
> I'm not hugely familiar with the usecase here (but eager to learn more!).
The driver currently requires the bit clock divider be hardcoded in
devicetree (or use the hardcoded default from apq8016).
The bit clock divider is used to derive the baud rate from the core
clock:
baudrate = clk_rate / csr_div
clk_rate is the actual programmed core clock rate which is
clk_set_rate() should return the clock rate that was set. The IPQ4019
clock driver doesn't set any rates yet but it should still return the
expected value so that drivers can work properly.
For a baud rate of 115200 with an expected bit clock divisor of 16, the
clock rate should be 1843200 so
The clk_init_uart() helper always returns 0, but we're meant to return a
real clock rate. Given that we hardcode 115200 baud, just return the
clock rate that we set.
Signed-off-by: Caleb Connolly
---
drivers/clk/qcom/clock-apq8016.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
/20240415-b4-msm-serial-bitrate-v1-0-5a89f84fd...@linaro.org
---
Caleb Connolly (3):
clk/qcom: apq8016: return valid rate when setting UART clock
clk/qcom: ipq4019: return valid rate when setting UART clock
serial: msm: calculate bit clock divider
doc/device-tree-bindings/serial
On 4/12/24 15:26, curtis.mach...@intel.com wrote:
> [You don't often get email from curtis.mach...@intel.com. Learn why this is
> important at
>
On Mon, Apr 15, 2024 at 4:18 PM Caleb Connolly
wrote:
>
>
>
> On 15/04/2024 14:05, Robert Marko wrote:
> > On Mon, Apr 15, 2024 at 2:44 PM Caleb Connolly
> > wrote:
> >>
> >> The driver currently requires the bit clock divider be hardcoded in
> >> devicetree (or use the hardcoded default from
> From: Janne Grunau via B4 Relay
> Date: Sun, 17 Mar 2024 15:54:50 +0100
>
> From: Janne Grunau
>
> Use standard boot instead of the distro boot scripts.
>
> Signed-off-by: Janne Grunau
As per a somewhat recent discussion about this for the rockchip SoCs,
I think we want BOOTSTD_FULL
On 15/04/2024 14:05, Robert Marko wrote:
> On Mon, Apr 15, 2024 at 2:44 PM Caleb Connolly
> wrote:
>>
>> The driver currently requires the bit clock divider be hardcoded in
>> devicetree (or use the hardcoded default from apq8016).
>>
>> The bit clock divider is used to derive the baud rate
Hi Quentin and Dragan,
On 2024-04-15 11:10, Quentin Schulz wrote:
> Hi Dragan,
>
> On 4/15/24 11:04, Dragan Simic wrote:
>> On 2024-04-15 10:58, Quentin Schulz wrote:
>>> On 4/13/24 20:13, Jonas Karlman wrote:
Add .dtb-file entry to Makefile and enable Kconfig options required to
From: Quentin Schulz
RK356x-based devices now support creating DRAM banks with proper holes
by reading the ATAGS from Rockchip TPL blob, so let's use that mechanism
instead.
The CONFIG_NR_DRAM_BANK now defaults to 10 which is a safe bet for
reading banks from ATAGS, so let's use the default
From: Quentin Schulz
RK3588-based devices now support creating DRAM banks with proper holes
by reading the ATAGS from Rockchip TPL blob, so let's use that mechanism
instead.
The CONFIG_NR_DRAM_BANK now defaults to 10 which is a safe bet for
reading banks from ATAGS, so let's use the default
From: Quentin Schulz
RK3588-based devices now support creating DRAM banks with proper holes
by reading the ATAGS from Rockchip TPL blob, so let's use that mechanism
instead.
Since ft_board_setup isn't defined anymore, there's no need for
selecting CONFIG_OF_BOARD_SETUP.
Similarly, because the
From: Quentin Schulz
RK3588-based devices now support creating DRAM banks with proper holes
by reading the ATAGS from Rockchip TPL blob, so let's use that mechanism
instead.
Since ft_board_setup isn't defined anymore, there's no need for
selecting CONFIG_OF_BOARD_SETUP.
Similarly, because the
From: Quentin Schulz
RK3588-based devices now support creating DRAM banks with proper holes
by reading the ATAGS from Rockchip TPL blob, so let's use that mechanism
instead.
Since ft_board_setup isn't defined anymore, there's no need for
selecting CONFIG_OF_BOARD_SETUP.
Similarly, because the
From: Quentin Schulz
RK3588-based devices now support creating DRAM banks with proper holes
by reading the ATAGS from Rockchip TPL blob, so let's use that mechanism
instead.
Since ft_board_setup isn't defined anymore, there's no need for
selecting CONFIG_OF_BOARD_SETUP.
Similarly, because the
From: Quentin Schulz
RK3588-based devices now support creating DRAM banks with proper holes
by reading the ATAGS from Rockchip TPL blob, so let's use that mechanism
instead.
Since ft_board_setup isn't defined anymore, there's no need for
selecting CONFIG_OF_BOARD_SETUP.
Similarly, because the
From: Quentin Schulz
RK3588-based devices now support creating DRAM banks with proper holes
by reading the ATAGS from Rockchip TPL blob, so let's use that mechanism
instead.
Since ft_board_setup isn't defined anymore, there's no need for
selecting CONFIG_OF_BOARD_SETUP.
Similarly, because the
From: Quentin Schulz
RK3588-based devices now support creating DRAM banks with proper holes
by reading the ATAGS from Rockchip TPL blob, so let's use that mechanism
instead.
Since ft_board_setup isn't defined anymore, there's no need for
selecting CONFIG_OF_BOARD_SETUP.
Similarly, because the
From: Quentin Schulz
When Rockchip TPL blob is used, the memory areas that can be used for
DRAM is gotten from ATAGS passed through the DRAM at a specific address.
The DDR_MEM tag contains at most 10 areas, so we should default to 10 if
Rockchip TPL blob is used. Note that it is technically
From: Quentin Schulz
Allow RK3568 and RK3588 based boards to get the RAM bank configuration
from the ROCKCHIP_TPL stage instead of the current logic. This fixes
both an issue where 256MB of RAM is blocked for devices with >= 4GB
of RAM and where memory holes need to be defined for devices with
243 insertions(+), 356 deletions(-)
---
base-commit: b03b49046af5dfca599d2ce8f0aafed89b97aa91
change-id: 20240415-rk35xx-dram-atags-35c9f19f4c38
Best regards,
--
Quentin Schulz
Hi Quentin and Dragan,
On 2024-04-15 10:58, Dragan Simic wrote:
> Hello Quentin,
>
> On 2024-04-15 10:56, Quentin Schulz wrote:
>> Hi Jonas,
>>
>> On 4/13/24 20:13, Jonas Karlman wrote:
>>> Add the CoolPi 4 Model B and CoolPi CM5 EVB board to the
>>> documentation.
>>> Also fix .dtb-file
Hi Yasuharu,
On Mon, Apr 15, 2024 at 10:01 AM Yasuharu Shibata
wrote:
>
> If tcp_seq_num is wrap around, tcp_seq_num >= initial_data_seq_num
> isn't satisfied and store_block() isn't called.
> The condition has a wrap around issue, so it is fixed in this patch.
>
> Signed-off-by: Yasuharu
Hi
On Mon, Apr 15, 2024 at 3:55 PM Michael Nazzareno Trimarchi
wrote:
>
> Hi
>
> On Mon, Apr 15, 2024 at 3:48 PM Yasuharu Shibata
> wrote:
> >
> > Hi Michael,
> >
> > On Mon, 15 Apr 2024 at 22:03, Michael Nazzareno Trimarchi
> > wrote:
> > >
> > > I think I have sent some time ago ;)
> > >
> >
On 4/15/24 11:48 AM, Patrice CHOTARD wrote:
On 4/14/24 20:39, Marek Vasut wrote:
In case of an OTP-CLOSED STM32MP15xx system, the CPU core 1 cannot be
released from endless loop in BootROM only by populating TAMP BKPxR 4
and 5 with magic and branch address and sending SGI0 interrupt from
core
Hi
On Mon, Apr 15, 2024 at 3:48 PM Yasuharu Shibata
wrote:
>
> Hi Michael,
>
> On Mon, 15 Apr 2024 at 22:03, Michael Nazzareno Trimarchi
> wrote:
> >
> > I think I have sent some time ago ;)
> >
> > Anyway look sane. I was having the same feeling on code inspection
> >
> > Reviewed-by: Michael
> From: Janne Grunau via B4 Relay
> Date: Sun, 17 Mar 2024 15:54:49 +0100
>
> From: Janne Grunau
>
> Apple devices have high DPI displays so the larger fonts are preferable
> for improved readability. This does not yet change the used font based
> on the display's pixel density so the standard
> From: Janne Grunau via B4 Relay
> Date: Sun, 17 Mar 2024 15:54:48 +0100
>
> From: Janne Grunau
>
> The display size querying in efi_console relies on this order. The
> display should be the primary output device and should be used to
> display more than 80x25 chars.
>
> Signed-off-by: Janne
Hi Michael,
On Mon, 15 Apr 2024 at 22:03, Michael Nazzareno Trimarchi
wrote:
>
> I think I have sent some time ago ;)
>
> Anyway look sane. I was having the same feeling on code inspection
>
> Reviewed-by: Michael Trimarchi
Thank you for your review.
I already checked the thread, sorry I
> From: Janne Grunau via B4 Relay
> Date: Sun, 17 Mar 2024 15:54:47 +0100
>
> From: Hector Martin
>
> This makes USB HDDs >2TiB work. The only reason this hasn't bitten us
> for the internal NVMe yet is the 4K sector size, because the largest SSD
> Apple sells is 8TB and we can handle up to
On Mon, Apr 15, 2024 at 2:44 PM Caleb Connolly
wrote:
>
> The driver currently requires the bit clock divider be hardcoded in
> devicetree (or use the hardcoded default from apq8016).
>
> The bit clock divider is used to derive the baud rate from the core
> clock:
>
> baudrate = clk_rate /
Hi
On Mon, Apr 15, 2024 at 3:01 PM Yasuharu Shibata
wrote:
>
> If tcp_seq_num is wrap around, tcp_seq_num >= initial_data_seq_num
> isn't satisfied and store_block() isn't called.
> The condition has a wrap around issue, so it is fixed in this patch.
>
> Signed-off-by: Yasuharu Shibata
> ---
>
If tcp_seq_num is wrap around, tcp_seq_num >= initial_data_seq_num
isn't satisfied and store_block() isn't called.
The condition has a wrap around issue, so it is fixed in this patch.
Signed-off-by: Yasuharu Shibata
---
net/wget.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff
Hi,
I send a patch fixing the wget issue.
There is a wrap around issue as already mentioned in [1].
The log in [2] indicates the following packets.
- Success packet
Packets received 64368, Transfer Successful
Bytes transferred = 93198937 (58e1a59 hex)
- Failed packet
Packets received 64368,
In case of an OTP-CLOSED STM32MP15xx system, the CPU core 1 cannot be
released from endless loop in BootROM only by populating TAMP BKPxR 4
and 5 with magic and branch address and sending SGI0 interrupt from
core 0 to core 1 twice. TAMP_SMCR BKP..PROT fields must be initialized
as well to release
> Subject: Re: [PATCH v6 0/5] imx93: Conver to OF_UPSTREAM
>
> Hi Peng,
>
> On Fri, Apr 12, 2024 at 10:40 AM Fabio Estevam
> wrote:
> >
> > On Fri, Apr 12, 2024 at 10:24 AM Peng Fan (OSS)
> wrote:
> > >
> > > A few nodes were added to soc and board u-boot.dtsi(lpi2c, usbotg),
> > > those nodes
On 15/04/2024 12:56, Robert Marko wrote:
> Recent addition of vbus-supply support has broke platform which dont use
> controllable regulators for USB.
>
> Issue is that even withou DM_REGULATOR being enabled regulator related
> functions will still build as there is a stub in regulator.h but
On 4/15/24 14:22, Heinrich Schuchardt wrote:
On 15.04.24 13:35, Michal Simek wrote:
Some of Kconfigs are using utf-8 encoding because of used chars. Convert
all of them to ascii enconging.
Signed-off-by: Michal Simek
---
There are other files which are using utf-8 enconding and pretty
On 4/15/24 14:44, Heinrich Schuchardt wrote:
On 15.04.24 13:35, Michal Simek wrote:
All errors are generated by ./tools/qconfig.py -b -j8 -i whatever.
Error look like this:
drivers/crypto/Kconfig:9: warning: style: quotes recommended around
'drivers/crypto/nuvoton/Kconfig' in 'source
On 15.04.24 13:35, Michal Simek wrote:
All errors are generated by ./tools/qconfig.py -b -j8 -i whatever.
Error look like this:
drivers/crypto/Kconfig:9: warning: style: quotes recommended around
'drivers/crypto/nuvoton/Kconfig' in 'source drivers/crypto/nuvoton/Kconfig'
Should we add a
The driver currently requires the bit clock divider be hardcoded in
devicetree (or use the hardcoded default from apq8016).
The bit clock divider is used to derive the baud rate from the core
clock:
baudrate = clk_rate / csr_div
clk_rate is the actual programmed core clock rate which is
clk_set_rate() should return the clock rate that was set. The IPQ4019
clock driver doesn't set any rates yet but it should still return the
expected value so that drivers can work properly.
For a baud rate of 115200 with an expected bit clock divisor of 16, the
clock rate should be 1843200 so
The clk_init_uart() helper always returns 0, but we're meant to return a
real clock rate. Given that we hardcode 115200 baud, just return the
clock rate that we set.
Signed-off-by: Caleb Connolly
---
drivers/clk/qcom/clock-apq8016.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
The msm serial UART controller has a bit clock divider register which
much be programmed based on the UART clock. This changes per soc and
currently is expected to be specified in DT or otherwise selected per
board.
This series fixes the apq8016 and ipq4019 clock drivers to return the
programmed
ep = (env_t *)buf;
---
base-commit: b03b49046af5dfca599d2ce8f0aafed89b97aa91
change-id: 20240415-mmc-loadenv-dev-ced678171e98
Best regards,
--
Quentin Schulz
On 15.04.24 13:35, Michal Simek wrote:
All errors are generated by ./tools/qconfig.py -b -j8 -i whatever.
Error look like this:
warning: style: quotes recommended around default value for string symbol
EFI_VAR_SEED_FILE (defined at lib/efi_loader/Kconfig:130)
Signed-off-by: Michal Simek
---
Hi Quentin,
On 2024-04-15 10:55, Quentin Schulz wrote:
> Hi Jonas,
>
> On 4/13/24 20:13, Jonas Karlman wrote:
>> After the commit aca95282c1b7 ("Makefile: Use the fdtgrep -u flag")
>> bootph props is propagating to parent nodes.
>>
>> Update bootph props to ensure eMMC, SD-card and SPI flash is
Hi Peng,
On Fri, Apr 12, 2024 at 10:40 AM Fabio Estevam wrote:
>
> On Fri, Apr 12, 2024 at 10:24 AM Peng Fan (OSS) wrote:
> >
> > A few nodes were added to soc and board u-boot.dtsi(lpi2c, usbotg), those
> > nodes
> > could be dropped after upstream linux supports them.
> >
> > To support
/custodians/u-boot-imx.git
tags/u-boot-imx-master-20240415
for you to fetch changes up to 8ecb0931940cc19728d686b9dba06585f4d93709:
clk: imx93: fix anatop base (2024-04-15 08:09:41 -0300)
u-boot-imx-master-20240415
--
CI: https://source.denx.de/u-boot/custodians/u-boot-imx
On 15.04.24 13:35, Michal Simek wrote:
Some of Kconfigs are using utf-8 encoding because of used chars. Convert
all of them to ascii enconging.
Signed-off-by: Michal Simek
---
There are other files which are using utf-8 enconding and pretty much I
think we should convert all of them because
I looked as cleaning up some dependencies and I found that qconfig is
reporting some issues. This series is fixing some of them. But there are
still some other pending. That's why please go and fix them if they are
related to your board.
Thanks,
Michal
drivers/pinctrl/intel/Kconfig:12: warning:
On 4/15/24 08:09, Takahiro Kuwano wrote:
> Hi Tudor,
Hi!
>
> On 4/15/2024 3:47 PM, Tudor Ambarus wrote:
>>
>>
>> On 4/15/24 05:33, tkuw584...@gmail.com wrote:
>>> From: Takahiro Kuwano
>>>
>>> default_init() fixup hook should be used to initialize flash parameters
>>> when its information
On 4/15/24 05:33, tkuw584...@gmail.com wrote:
> From: Takahiro Kuwano
>
> This series is equivalent to the one for Linux MTD submitted by
> Pratyush Yadav.
>
> https://patchwork.ozlabs.org/project/linux-mtd/list/?series=217759=*
Ah, I see you specified it here. I'd argue it's better to
On 4/15/24 05:33, tkuw584...@gmail.com wrote:
> diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
> index 8f371a5213..773afd4040 100644
> --- a/drivers/mtd/spi/spi-nor-core.c
> +++ b/drivers/mtd/spi/spi-nor-core.c
> @@ -3459,6 +3459,13 @@ static void
Hi, Takahiro!
On 4/15/24 05:33, tkuw584...@gmail.com wrote:
> From: Takahiro Kuwano
>
> Some flashes like the Infineon SEMPER NOR flash family use ECC. Under
> this ECC scheme, multi-pass writes to an ECC block is not allowed.
> In other words, once data is programmed to an ECC block, it can't
On 4/15/24 05:33, tkuw584...@gmail.com wrote:
> From: Takahiro Kuwano
>
> default_init() fixup hook should be used to initialize flash parameters
> when its information is not provided in SFDP. To support that case, it
> needs to take flash_parameter structure like as other hooks.
>
>
Hi, Takahiro,
On 4/15/24 05:33, tkuw584...@gmail.com wrote:
> From: Takahiro Kuwano
>
> For NOR flashes EC and VID are zeroed out before an erase is issued to
> make sure UBI does not mistakenly treat the PEB as used and associate it
> with an LEB.
>
> But on some flashes, like the Infineon
Recent addition of vbus-supply support has broke platform which dont use
controllable regulators for USB.
Issue is that even withou DM_REGULATOR being enabled regulator related
functions will still build as there is a stub in regulator.h but they will
simply return -ENOSYS which will then make
Provide a man-page describing the usage of U-Boot on
the Milk-V Mars CM and Milk-V Mars CM Lite boards.
Signed-off-by: Heinrich Schuchardt
---
doc/board/starfive/index.rst | 1 +
doc/board/starfive/milk-v_mars_cm.rst | 125 ++
2 files changed, 126
We can use U-Boot for recovering JH7110 based boards via UART
if CONFIG_SPL_YMODEM_SUPPORT=y.
* Send u-boot-spl.normal.out via XMODEM.
* Send u-boot.itb via YMODEM.
Signed-off-by: Heinrich Schuchardt
---
configs/starfive_visionfive2_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git
We already support the VisionFive 2 and the Milk-V Mars board by
patching the VisionFive 2 device tree. With this patch the same
is done for the Milk-V Mars CM.
Signed-off-by: Heinrich Schuchardt
---
board/starfive/visionfive2/spl.c | 27 ++-
The EEPROM provides information about the size of the EEPROM.
Provide a new function get_mmc_size_from_eeprom() to read it.
Signed-off-by: Heinrich Schuchardt
---
arch/riscv/include/asm/arch-jh7110/eeprom.h| 7 +++
board/starfive/visionfive2/Kconfig | 9 +
With this series the Milk-V Mars CM board can be booted.
NVMe, SD-card, Ethernet, UART are working but not USB.
The first series Milk-V Mars CM Lite board (the version without eMMC)
uses incorrect series numbers indicating eMMC presence. For these
CONFIG_STARFIVE_NO_EMMC=y must be set to
On Mon, Apr 15, 2024 at 1:46 PM Caleb Connolly
wrote:
>
>
>
> On 15/04/2024 11:49, Robert Marko wrote:
> > Currently, .clk_bit_rate is not being set in init_serial_data for debug
> > UART, but its then used uart_dm_init() and this breaks debug UART on
> > IPQ40xx.
> >
> > So, lets populate
On 15/04/2024 11:49, Robert Marko wrote:
> Currently, .clk_bit_rate is not being set in init_serial_data for debug
> UART, but its then used uart_dm_init() and this breaks debug UART on
> IPQ40xx.
>
> So, lets populate .clk_bit_rate for debug UART as well.
> IPQ40xx requires special value of
1 - 100 of 190 matches
Mail list logo
