On 6/11/23 David Antliff wrote:
> On 6/11/23 Sean Anderson wrote:
> > On 6/11/23 23:25, David Antliff wrote:
> > > On 11/23/22 Sean Anderson wrote:
> > >> On 11/22/22 20:23, David Antliff wrote:
[snip]
> > > From a little debugging, I see that the call in eth-uclass.c around line
>515
Hi Sean, thanks for getting back to me.
On 6/11/23 Sean Anderson wrote:
> On 6/11/23 23:25, David Antliff wrote:
> > On 11/23/22 Sean Anderson wrote:
> >> On 11/22/22 20:23, David Antliff wrote:
[snip]
> > So I took up your suggestion, enabled CONFIG_NVMEM & CONFIG_I2C_EEPROM, and
> > with
On 6/11/23 23:25, David Antliff wrote:
On 11/23/22 Sean Anderson wrote:
On 11/22/22 20:23, David Antliff wrote:
> I'm looking to extract the board's MAC address from serial I2C EEPROM at
boot time, so
> I'm trying to work out how I can tell if U-Boot is actually able to
communicate
On 11/23/22 Sean Anderson wrote:
> On 11/22/22 20:23, David Antliff wrote:
> >
> > I'm looking to extract the board's MAC address from serial I2C EEPROM at
>boot time, so
> > I'm trying to work out how I can tell if U-Boot is actually able to
>communicate with this
> > EEPROM, outside of manual
Without CONFIG_CLK, the build fails with the following message:
LD u-boot
aarch64-none-linux-gnu-ld.bfd: drivers/firmware/scmi/scmi_agent-uclass.o: \
in function `scmi_bind_protocols':
.../drivers/firmware/scmi/scmi_agent-uclass.c:79: undefined reference to \
> From: Bo Gan
> Sent: Monday, June 12, 2023 7:59 AM
> To: u-boot@lists.denx.de
> Cc: Bo Gan ; samin . guo ;
> Yanhong Wang ; Rick Jian-Zhi Chen(陳建志)
> ; Leo Yu-Chi Liang(梁育齊) ; Sean
> Anderson ; Lukasz Majewski
> Subject: [RESEND PATCH v1] arch: riscv: jh7110: Correctly zero L2 LIM
>
>
> From: Bo Gan
> Sent: Monday, June 12, 2023 7:54 AM
> To: u-boot@lists.denx.de
> Cc: Bo Gan ; Rick Jian-Zhi Chen(陳建志)
> ; Leo Yu-Chi Liang(梁育齊) ; Sean
> Anderson ; Bin Meng ; Lukas Auer
>
> Subject: [RESEND PATCH v2] riscv: setup per-hart stack earlier
>
> Harts need to use per-hart stack
Background information:
JH7110 SPL runs in L2 LIM (2M in size mapped at 0x800). It
consists of 16 0x2 sized regions, each one can be used as
either L2 cache way or SRAM (not both). From top to bottom, there're
ways 0-15. The way 0 is always enabled, at most 0x1e can be used.
In
Harts need to use per-hart stack before any function call, even if that
function is a simple one. When the callee uses stack for register save/
restore, especially RA, if nested call, concurrent access by multiple
harts on the same stack will cause data-race.
This patch sets up SP before
Now that the PHY driver supports the H616 USB PHY, we can enable USB
support for the two H616 boards.
As the OrangePi Zero2 has a USB-C port hard-wired to peripheral mode,
let's enable USB gadget mode for port 0, so people can use fastboot,
ethernet or mass storage functionality.
Signed-off-by:
Now that the Allwinner USB PHY driver supports the H616 quirk, let's
enable support for USB ports on that SoC.
We connect the compatible string to a new struct describing the SoCs USB
PHY properties, and unblock the PHY driver selection in Kconfig.
A later patch will enable USB support in the
The H616 USB PHY is some kind of special snowflake: Only port2 works out
of the box, but all other ports need some help from this port2 to work
correctly: The CLK_BUS_PHY2 and RST_USB_PHY2 clock and reset need to be
enabled, and the SIDDQ bit in the PMU PHY control register needs to be
cleared.
So far we were assigning some crude "type" (SoC name, really) to each
Allwinner USB PHY model, then guarding certain quirks based on this.
This does not only look weird, but gets more or more cumbersome to
maintain.
Remove the bogus type names altogether, instead introduce flags for each
quirk,
At the moment we use "select" in each Allwinner SoC's Kconfig section to
include the USB PHY driver in the build. This means it cannot be disabled
via Kconfig, although USB is not really a strictly required core
functionality, and a particular board might not even include USB ports.
Rework the
The Allwinner F1C100s implements a single USB PHY, connected to its MUSB
OTG controller. The USB PHY is of the simpler, older type (like the A10),
the only real difference is that it's indeed only one PHY.
Add a struct describing those F1C100s USB PHY properties, and connect it
to the new
In its of_xlate() function, the Allwinner USB PHY driver compares the
args_count variable against the number of implemented USB PHYs, although
this is the *number of arguments* to the DT phandle property. Per the DT
binding for this PHY device, this number is always one, so this check
will always
Hi,
version 2 of this series does not change anything in the first three
patches adding F1C100s support (apart from adding Jernej's review tags,
many thanks for that!), but also adds support for the H616 USB PHY.
This is a bit more involved this time, since the USB PHY on this SoC
requires some
On Friday 28 April 2023 10:30:08 Pali Rohár wrote:
> On Friday 28 April 2023 15:39:20 Peng Fan wrote:
> > On 4/2/2023 12:43 AM, Pali Rohár wrote:
> > > Can anybody help with this?
> >
> > I expected Jaehoon would say some words.
Just a reminder...
> >
> > >
> > > On Saturday 25 March 2023
Ping, what to do with this patch?
It is without any response too and is a is fix for this reported issue:
https://lore.kernel.org/u-boot/20230503171456.GF1134230@bill-the-cat/
On Tuesday 16 May 2023 20:49:43 Pali Rohár wrote:
> OMAP2PLUS and BCM283X mmc controllers do not work correctly with new
On Tue, Jun 6, 2023 at 6:09 PM Jagan Teki wrote:
>
> This series support fixes for RK3328 USB.
>
> Changes for v2:
> - collect Marek RB
> - update phy driver clockout_ctl for rk3328
> - retest on Xavier patches.
>
> Any inputs?
I've done some basic testing of thing on a Rock64 and it looks good
Hi Jonas,
This regresses the Rockpro64 build for me when building with gcc 12/13
with the following error, if I remove CONFIG_LTO it builds, but
overlaps.
/usr/bin/aarch64-linux-gnu-ld:
/usr/lib/gcc/aarch64-linux-gnu/13/libgcc.a(lse-init.o): in function
`init_have_lse_atomics':
On Sun, Jun 11, 2023 at 09:24:14AM +0100, Simon Glass wrote:
> Hi,
>
> On Wed, 7 Jun 2023 at 10:47, Ilias Apalodimas
> wrote:
> >
> > Hi Maxim,
> >
> > On Tue, 6 Jun 2023 at 17:33, Maxim Uvarov wrote:
> > >
> > > Greetings,
> > >
> > > I implemented the tftp client (that was quick due to lwip
On Thu, May 25, 2023 at 2:27 PM Ondřej Jirman wrote:
>
> From: Ondrej Jirman
>
> This fixes access to camera sensor over I2C during probe time in
> the kernel. (Kernel will fix I/0 port voltage by itself, but the
> timing depends on probe order of the drivers, so the fix can
> come after the
Add the RAM_ROCKCHIP_LPDDR4 to fix the Pinephone Pro booting.
When the configs were updated in 26f92be07e2 it somehow broke
the PPP boot process so let's fix it.
Signed-off-by: Peter Robinson
CC: Jagan Teki
CC: Kever Yang
---
configs/pinephone-pro-rk3399_defconfig | 1 +
1 file changed, 1
On Sun, Jun 11, 2023 at 8:23 PM Peter Robinson wrote:
>
> On Tue, Jun 6, 2023 at 6:10 PM Jagan Teki wrote:
> >
> > Like Rockchip RK3568, the RK3328 also have single node to
> > represent the glue and ctrl for USB 3.0.
> >
> > So, use the driver data to use single ctrl for RK3328 DWC3.
> >
> >
Am So., 11. Juni 2023 um 17:10 Uhr schrieb Pali Rohár :
>
> On Sunday 11 June 2023 16:57:07 Christian Gmeiner wrote:
> > Hello
> >
> > >
> > > Hello! I must admit that this patch is broken and does not add any NFSv1
> > > support. Just look below
> > >
> >
> > So .. let see what happend here.
On Sunday 11 June 2023 16:57:07 Christian Gmeiner wrote:
> Hello
>
> >
> > Hello! I must admit that this patch is broken and does not add any NFSv1
> > support. Just look below
> >
>
> So .. let see what happend here.
>
> > On Friday 10 March 2023 10:51:55 Christian Gmeiner wrote:
> > >
Am So., 11. Juni 2023 um 15:02 Uhr schrieb Peter Robinson
:
>
> On Sun, Jun 11, 2023 at 1:54 PM Pali Rohár wrote:
> >
> > Hello! I must admit that this patch is broken and does not add any NFSv1
> > support. Just look below
> >
> > On Friday 10 March 2023 10:51:55 Christian Gmeiner wrote:
> >
Hello
>
> Hello! I must admit that this patch is broken and does not add any NFSv1
> support. Just look below
>
So .. let see what happend here.
> On Friday 10 March 2023 10:51:55 Christian Gmeiner wrote:
> > From: Thomas RIENOESSL
> >
> > NFSv1 support added by Christian Gmeiner, Thomas
On Tue, Jun 6, 2023 at 6:10 PM Jagan Teki wrote:
>
> Like Rockchip RK3568, the RK3328 also have single node to
> represent the glue and ctrl for USB 3.0.
>
> So, use the driver data to use single ctrl for RK3328 DWC3.
>
> Reviewed-by: Marek Vasut
> Signed-off-by: Jagan Teki
> ---
> Changes for
On Thursday 25 May 2023 11:49:18 Stefan Roese wrote:
> This patch adds the PCIe controller driver for the Xilinx / AMD ZynqMP
> NWL PCIe Bridge as root port. The driver source is partly copied from
> the Linux PCI driver and modified to enable usage in U-Boot (e.g.
> simplified and interrupt
On Saturday 10 June 2023 16:31:06 Mark Kettenis wrote:
> Hi Simon,
>
> In commit 32bab0eae51 you added a
>
> #define ansi 0
>
> and put the code that positions the cursor to print the "Hit any key
> to stop autoboot" message behind an
>
> if (ansi)
>
> condition. As a result that message
On Friday 02 June 2023 15:30:43 Michal Simek wrote:
> Hi Pali,
>
> On 5/25/23 11:49, Stefan Roese wrote:
> Any comment about the driver itself?
>
> Thanks,
> Michal
>
Why you are so impatient? It is common that people have to wait months
or year for review and you unhappy with needed to wait
On Thursday 25 May 2023 14:57:32 Stefan Roese wrote:
> Hi Tony,
> Hi Pali,
>
> On 5/18/23 22:55, Tony Dinh wrote:
> > Hi Stefan,
> >
> > On Wed, May 17, 2023 at 1:26 AM Stefan Roese wrote:
> > >
> > > Hi Pali,
> > >
> > > On 5/17/23 00:30, Pali Rohár wrote:
> > > > On Tuesday 16 May 2023
On Sun, Jun 11, 2023 at 1:54 PM Pali Rohár wrote:
>
> Hello! I must admit that this patch is broken and does not add any NFSv1
> support. Just look below
>
> On Friday 10 March 2023 10:51:55 Christian Gmeiner wrote:
> > From: Thomas RIENOESSL
> >
> > NFSv1 support added by Christian Gmeiner,
Hello! I must admit that this patch is broken and does not add any NFSv1
support. Just look below
On Friday 10 March 2023 10:51:55 Christian Gmeiner wrote:
> From: Thomas RIENOESSL
>
> NFSv1 support added by Christian Gmeiner, Thomas Rienoessl,
> September 27, 2018. As of now, NFSv3 is the
This reverts commit 32bab0eae51b55898d1e2804e6614d9143840581.
Signed-off-by: Pali Rohár
---
cmd/bootmenu.c | 9 ++---
cmd/eficonfig.c| 12 ++
common/cli_getch.c | 12 ++
common/menu.c | 92 +-
include/cli.h | 4 +-
This reverts commit 9e7ac0b0be5cb663e539716554d66f8f0890ca83.
Signed-off-by: Pali Rohár
---
common/menu.c | 48 ++--
include/menu.h | 10 --
2 files changed, 18 insertions(+), 40 deletions(-)
diff --git a/common/menu.c b/common/menu.c
index
This reverts commit 72a0dd8bed010bef78028ae528763f9807758e6b.
Signed-off-by: Pali Rohár
---
drivers/video/Kconfig | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 1e2f4e6de4a5..52f7eac1e6a3 100644
---
These 3 commits broke support for U-Boot Bootmenu on Nokia N900.
Issues were reported more than month ago, but nobody reacted to them.
So revert these broken commits for now, to fix U-Boot Bootmenu support.
With these revered commits, U-Boot Bootmenu from master branch is
working fine again on
On 6/9/23 20:52, Xavier Drudis Ferran wrote:
Sorry, I replied to Marek only but meant to reply to all.
El Fri, Jun 09, 2023 at 03:20:33AM +0200, Marek Vasut deia:
No. Well, in some tests yes and some no, but I got the error in all cases.
This is doubtful. It is mandatory to run 'usb start'
On Wed, Jun 7, 2023 at 8:48 AM Bruce Suen wrote:
>
> adding xtxtech part numbers
>
> Signed-off-by: Bruce Suen
> ---
Rework on commit head, it is unclear.
> drivers/mtd/spi/spi-nor-ids.c | 38 +--
> 1 file changed, 36 insertions(+), 2 deletions(-)
>
> diff
On Thu, Jun 8, 2023 at 5:08 AM William Zhang wrote:
>
> Bring the device tree binding document from Linux to u-boot
>
> Port from linux patches:
> Link:
> https://lore.kernel.org/r/20230207065826.285013-2-william.zh...@broadcom.com
> Link:
>
On Thu, Jun 8, 2023 at 5:08 AM William Zhang wrote:
>
> The newer BCMBCA SoCs such as BCM6756, BCM4912 and BCM6855 include an
> updated SPI controller that add the capability to allow the driver to
> control chip select explicitly. Driver can control and keep cs low
> between the transfers
On Thu, Jun 8, 2023 at 5:08 AM William Zhang wrote:
>
> Due to the controller limitation to keep the chip select low during the
> bus idle time between the transfer, a dummy cs workaround was used when
> this driver was first upstreamed to the u-boot based on linux kernel
> driver. It basically
On Thu, Jun 8, 2023 at 5:08 AM William Zhang wrote:
>
> New compatible string brcm,bcmbca-hsspi-v1.0 is introduced based on
> dts document brcm,bcm63xx-hsspi.yaml. Add it to the driver to support
> this new binding.
>
> Port from linux patch:
> Link:
>
On Thu, Jun 8, 2023 at 5:08 AM William Zhang wrote:
>
> Currently the driver always sets the controller to dual data bit mode
> for both tx and rx data in the profile mode control register even for
> single data bit transfer. Luckily the opcode is set correctly according
> to SPI transfer data
On Thu, Jun 8, 2023 at 5:08 AM William Zhang wrote:
>
> ARCH_BCMBCA was introduced to cover individual Broadcom broadband SoC
> for common features and IP blocks. Use this config instead of each chip
> config as the Kconfig dependency for Broadcom HSSPI driver.
>
> Signed-off-by: William Zhang
>
On Fri, May 19, 2023 at 3:52 AM Fabio Estevam wrote:
>
> From: Fabio Estevam
>
> According to Documentation/devicetree/bindings/spi/spi-gpio.yaml
> from Linux, the recommended spio-gpio properties are:
>
> sck-gpios, miso-gpios and mosi-gpios.
>
> gpio-sck, gpio-mosi and gpio-miso are considered
On Fri, May 19, 2023 at 3:52 AM Fabio Estevam wrote:
>
> From: Fabio Estevam
>
> According to Documentation/devicetree/bindings/spi/spi-gpio.yaml
> from Linux, the recommended spio-gpio properties are:
>
> sck-gpios, miso-gpios and mosi-gpios.
>
> gpio-sck, gpio-mosi and gpio-miso are considered
On Wed, May 24, 2023 at 1:03 PM Masahisa Kojima
wrote:
>
> Current code expects that SPI_TX_BYTE is single bit mode
> but it is wrong. It indicates byte program mode,
> not single bit mode.
>
> If SPI_TX_DUAL, SPI_TX_QUAD and SPI_TX_OCTAL bits are not set,
> the default transfer bus width is
Hi,
On Wed, 7 Jun 2023 at 10:47, Ilias Apalodimas
wrote:
>
> Hi Maxim,
>
> On Tue, 6 Jun 2023 at 17:33, Maxim Uvarov wrote:
> >
> > Greetings,
> >
> > I implemented the tftp client (that was quick due to lwip has example app
> > for tftp), and did some more measurements.
> > I uploaded patches
Neural Compute Module 6B(Neu6B) is a 96boards SoM-CB compute module
based on Rockchip RK3588J from Edgeble AI.
Add support for this SoM and IO board.
Signed-off-by: Jagan Teki
---
.../dts/rk3588-edgeble-neu6b-io-u-boot.dtsi | 22 +++
arch/arm/mach-rockchip/rk3588/Kconfig | 10 +++
Neural Compute Module 6B(Neu6B) is a 96boards SoM-CB compute module
based on Rockchip RK3588J from Edgeble AI.
General features:
- Rockchip RK3588J
- up to 32GB LPDDR4x
- up to 128GB eMMC
- 2x MIPI CSI2 FPC
- On module WiFi6/BT
Neural Compute Module 6B(Neu6B) IO board is an industrial form
Add rk3588j-u-boot.dtsi for adding U-Boot specific nodes and
properties for Rockchip RK3588J SoC.
Signed-off-by: Jagan Teki
---
arch/arm/dts/rk3588j-u-boot.dtsi | 6 ++
1 file changed, 6 insertions(+)
create mode 100644 arch/arm/dts/rk3588j-u-boot.dtsi
diff --git
Rockchip RK3588J is the industrial-grade version of RK3588 SoC and
is operated with -40 °C to +85 °C temparature.
Add rk3588j specific dtsi for adding rk3588j specific operating points
and other changes to be add in future.
Kernel commit:
commit <8274a04ff1dc> ("arm64: dts: rockchip: Add
Add missing suffix 'A' for Edgeble Neu6A SoM and IO boards.
Fixes: <15b2d1fb727> ("board: rockchip: Add Edgeble Neural Compute
Module 6")
Signed-off-by: Jagan Teki
---
arch/arm/mach-rockchip/rk3588/Kconfig | 10 +-
doc/board/rockchip/rockchip.rst | 2 +-
2 files changed, 6
57 matches
Mail list logo
