On Tue, 16 Jul 2024 at 18:21, Tom Rini wrote:
>
> On Tue, Jul 16, 2024 at 02:16:02PM -0300, Walter Lozano wrote:
>
> > ARM and Aarch64 have different restrictions and trying to accommodate
> > larger kernels like the ones used in distros can be challenging. For this
> > reason, separate the
Hi Philippe,
It might be useful to have a cover letter explaining what the plans
for this code are, great that there are tests but adding code in
without it being used isn't always a feature so a cover letter with
some details often helps with the context.
Also if you're not aware there's work
> > I can't find these patches (and v1) in patchworks. Do you have an
> > idea, why this is the case?
> >
>
> Perhaps because they (v2) have already been merged to master via a PR from
> Peter? commit 1ca216522d4.
They were there, although weirdly they weren't assigned to me and I
had to dig for
On Fri, 12 Jul 2024 at 18:25, Michael Walle wrote:
>
> Right now, the maximal transfer speed from an SPI flash on a V3s is
> about 240kb/s. That is pretty slow. It turns out, that due to an
> error u-boot is setting the maximum frequency to 1MHz. By fixing
> that another bug is unearthed: one
Hi Tom,
Please pull the updates for the Raspberry Pi:
Updates for RPi for 2024.10:
- board: rpi: remove leftover CONFIG_HW_WATCHDOG block
- arm: bcm283x: remove unused empty hw_watchdog_disable
- board: raspberrypi: Fix format specifier for printing rev_scheme
- Revert "arm: dts: bcm283x: Add
On Tue, 9 Jul 2024 at 13:20, Francois Berder wrote:
>
> rev_scheme is an unsigned integer and must not be printed
> as a signed integer.
>
Reviewed-by: Peter Robinson
> Signed-off-by: Francois Berder
> ---
> board/raspberrypi/rpi/rpi.c | 2 +-
> 1 file changed, 1
or the cleanup and updated commit.
Reviewed-by: Peter Robinson
> Signed-off-by: Rasmus Villemoes
> ---
> board/raspberrypi/rpi/rpi.c | 4
> 1 file changed, 4 deletions(-)
>
> diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c
> index d996eb0cf69..9a83cf2d
t;
> Reviewed-by: Stefan Roese
Reviewed-by: Peter Robinson
Thanks!
> Signed-off-by: Rasmus Villemoes
> ---
> arch/arm/mach-bcm283x/reset.c | 7 ++-
> 1 file changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm/mach-bcm283x/reset.c b/arch/arm/mach-bcm2
On Wed, 10 Jul 2024 at 22:17, Rasmus Villemoes
wrote:
>
> This empty stub was originally added as one branch of an #ifdef in
> commit 45a6d231b2f (bcm2835_wdt: support for the BCM2835/2836
> watchdog). That incarnation of the rpi watchdog driver was later
> removed in c7adc0b5f98 (watchdog:
On Fri, 5 Jul 2024 at 22:16, Mikhail Kshevetskiy
wrote:
>
>
> On 05.07.2024 20:56, Peter Robinson wrote:
> > Hi Mikhail,
> >
> >> This series of patches greatly improve TCP support.
> > Where's the changelog of what changed from v1?
>
> no changes, just
Hi Mikhail,
> This series of patches greatly improve TCP support.
Where's the changelog of what changed from v1?
> The benefits:
> * a lot of bug was fixed
> * tcp cliens becomes smaller/simpler
> * fix data uploading (now it's possible to transmit a huge
>array of data from the board to
Please don't put the only detail in the subject, please outline the
fix here too, that should allow a more concise subject.
> Signed-off-by: Mikhail Kshevetskiy
> ---
> net/tftp.c | 9 -
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/net/tftp.c b/net/tftp.c
> index
Hi Mikhail,
> This patch adds HTTP/1.1 compatible web-server that can be used
> by other. Server supports GET, POST, and HEAD requests. On client
> request it will call user specified GET/POST callback. Then results
> will be transmitted to client.
Why are we adding a HTTP server? I don't see a
On Sun, 23 Jun 2024 at 13:21, Dragan Simic wrote:
>
> Hello Fukaumi,
>
> On 2024-06-23 06:15, FUKAUMI Naoki wrote:
> > rk3328-rock-pi-e-v3.dts is identical to rk3328-rock-pi-e.dts in
> > upstream. only difference between v3.0 and prior ver. is, using
> > rk3328-sdram-ddr4-666.dtsi instead of
> > Well it could go there, but I currently build ATF for all Rockchip
> > platforms we support.
> >
>
> That's nice to hear :)
>
> >> It doesn't matter whose fault it is for not being upstreamed earlier,
> >
> > I agree. There's also no reason something can't be included and then
> > dropped at
On Fri, 21 Jun 2024 at 09:56, Peter Robinson wrote:
>
> > > rk3568 is now upstream, there was a PR upstream for this for some
> > > time, similar to rk3588, albeit not as long as rk56x. In some cases
> > > the issue here is the speed of review of upstream ATF.
> > rk3568 is now upstream, there was a PR upstream for this for some
> > time, similar to rk3588, albeit not as long as rk56x. In some cases
> > the issue here is the speed of review of upstream ATF. I don't think
> > that means it should go into something like this.
> >
>
> If the BL31 blob
On Fri, 21 Jun 2024 at 00:05, Simon Glass wrote:
>
> Hi Nishanth,
>
> On Thu, 20 Jun 2024 at 15:35, Nishanth Menon wrote:
> >
> > Hi Team,
> >
> > We have briefly discussed this topic on IRC[1]. I would like to
> > propose a new boot-firmware repository similar to the Linux-firmware
> >
On Thu, 20 Jun 2024 at 23:22, Quentin Schulz wrote:
>
> Hi Nishanth Menon,
>
> +Cc Kever from Rockchip as maintainer of the arch in U-Boot
> +Cc Heiko as maintainer of many things Rockchip in many projects
>
> On 6/20/24 11:35 PM, Nishanth Menon wrote:
> > Hi Team,
> >
> > We have briefly
Hi Nishanth,
Thanks for starting this conversation.
> We have briefly discussed this topic on IRC[1]. I would like to
> propose a new boot-firmware repository similar to the Linux-firmware
> repository under the aegis of u-boot hosting.
>
> In addition to TI, it looks like some NXP[2] and
On Thu, 20 Jun 2024 at 18:41, Alex Bee wrote:
>
>
> Am 20.06.24 um 19:08 schrieb Tom Rini:
> > On Thu, Jun 20, 2024 at 07:03:26PM +0200, Alex Bee wrote:
> >> Am 20.06.24 um 12:24 schrieb Quentin Schulz:
> >>> From: Quentin Schulz
> >>>
> >>> No meaningful changes were made to this SoM since
On Wed, 12 Jun 2024 at 03:33, Christian Marangi wrote:
>
> This series expand the STATUS LED framework with a new color
> and a big new feature. One thing that many device need is a way
> to communicate to the user that the device is actually doing
> something.
>
> This is especially useful for
On Thu, 20 Jun 2024 at 02:51, Christian Marangi wrote:
>
> Add a warning when an invalid Status LED ID is used to make the user
> aware of bad configurations.
>
> Signed-off-by: Christian Marangi
> ---
> drivers/misc/status_led.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
>
On Wed, 19 Jun 2024 at 16:06, Jerome Forissier
wrote:
>
>
>
> On 6/19/24 09:24, Ilias Apalodimas wrote:
> > Hi Tom
> >
> > On Tue, 18 Jun 2024 at 23:21, Tom Rini wrote:
> >>
> >> On Mon, Jun 17, 2024 at 05:32:52PM +0200, Jerome Forissier wrote:
> >>
> >>> This is a rework of a patch series by
On Tue, 18 Jun 2024 at 02:06, FUKAUMI Naoki wrote:
>
> no functional change is intended.
Can you please explain what the patch is doing then, the subject of
"cosmetic changes for rk3308, rk3328, rk3399, rk3568, and rk3588"
doesn't really explain it either. Something like "adjust indentation
for
On Wed, 5 Jun 2024 at 20:51, Christian Marangi wrote:
>
> Implement support for LED status activity. If the feature is enabled,
> make the defined ACTIVITY LED to signal traffic.
Would this not just duplicate the activity on the NIC LED?
> Signed-off-by: Christian Marangi
> ---
> net/tftp.c |
> On Fri, May 24, 2024 at 06:19:54PM +0200, Jerome Forissier wrote:
> > - Make the support of HTTPS in the wget command easier. Javier T. (CC'd)
> > has some additional lwIP and Mbed TLS patches to do so. With that it
> > becomes possible to fetch and launch a distro installer such as Debian
> >
On Thu, 23 May 2024 at 16:39, Jiaxun Yang wrote:
>
>
>
> 在2024年5月23日五月 下午4:25，Tom Rini写道：
> > On Wed, May 22, 2024 at 04:34:43PM +0100, Jiaxun Yang wrote:
> >
> >> Hi all,
> >>
> >> Sorry for flooding the mailing list recently, yet another huge RFC series
> >> ahead.
> >>
> >> So after working
On Wed, 22 May 2024 at 19:08, Ilias Apalodimas
wrote:
>
> Hi Jerome,
>
> On Wed, 22 May 2024 at 19:04, Jerome Forissier
> wrote:
> >
> > Some sandbox tests make strong assumptions on how the network stack is
> > implemented. For example, the ping tests assume that ARP resolution
> > occurs upon
On Mon, 20 May 2024 at 15:18, Andre Przywara wrote:
>
> On Mon, 20 May 2024 13:48:41 +0100
> Peter Robinson wrote:
>
> Hi Peter,
>
> thanks for having a look!
>
> > Hi Andre,
> >
> > > this is the first series in an attempt to clean up the X-
Hi Andre,
> this is the first series in an attempt to clean up the X-Powers AXP PMIC
> drivers used by the SPL for sunxi boards. So far we have a separate
> driver file for each AXP variant, but the code was largely the same,
> just differing by the regulator ranges.
>
> This adds a new generic
This reverts commit 33041972727e84d3f95e26c83322521f61827584.
With the ability to generate this SMBIOS details autmotically the
small amount of details that this patch provided are generated
automatically so this is now obsolete so we can just drop it.
Signed-off-by: Peter Robinson
---
arch
Hi Tom,
Please pull the updates for the Raspberry Pi:
Updates for RPi for 2024.07:
- Switch to OF_HAS_PRIOR_STAGE by default
The following changes since commit 52835266d3e933656a217233eaf672dd9ccd7352:
Prepare v2024.07-rc2 (2024-05-06 13:54:17 -0600)
are available in the Git repository at:
On Tue, 7 May 2024 at 19:30, Raymond Mao wrote:
>
> Integrate MbedTLS v3.6 LTS (currently v3.6.0-RC1) with U-Boot.
>
> Motivations:
>
> 1. MbedTLS is well maintained with LTS versions.
> 2. LWIP is integrated with MbedTLS and easily to enable HTTPS.
> 3. MbedTLS recently switched
On Thu, 2 May 2024 at 02:33, Tom Rini wrote:
>
> Remove from this driver directory and when needed
> add missing include files directly.
>
> Signed-off-by: Tom Rini
Reviewed-by: Peter Robinson
Looks good.
> ---
> Cc: Tom Rini
> Cc: Simon Glass
> Cc: Matthias Br
On Thu, 2 May 2024 at 02:33, Tom Rini wrote:
>
> Remove from this driver directory and when needed
> add missing include files directly.
>
> Signed-off-by: Tom Rini
Reviewed-by: Peter Robinson
Looks fine
> ---
> Cc: Ryan Chen
> Cc: Chia-Wei Wang
> Cc: Aspeed BMC
On Thu, 2 May 2024 at 02:32, Tom Rini wrote:
>
> Remove from this driver directory and when needed
> add missing include files directly.
>
> Signed-off-by: Tom Rini
Reviewed-by: Peter Robinson
Looks good.
> ---
> Cc: Peng Fan
> Cc: Jaehoon Chung
> Cc: Tom Rini
On Thu, 2 May 2024 at 02:32, Tom Rini wrote:
>
> Remove from this driver directory and when needed
> add missing include files directly.
>
> Signed-off-by: Tom Rini
Reviewed-by: Peter Robinson
Looks fine to me.
> ---
> Cc: Tom Rini
> Cc: Matthias Brugger
> Cc:
On Thu, 2 May 2024 at 02:34, Tom Rini wrote:
>
> Remove from this driver directory and when needed
> add missing include files directly.
>
> Signed-off-by: Tom Rini
Reviewed-by: Peter Robinson
LGTM.
> ---
> Cc: Anatolij Gustschin
> Cc: Tom Rini
> Cc: Matthias Br
On Wed, 1 May 2024 at 17:25, Jonas Karlman wrote:
>
> Remove the obsolete ethernet0 alias now that all board device tree files
> have been fully synced with Linux kernel v6.8.
>
> Signed-off-by: Jonas Karlman
Reviewed-by: Peter Robinson
> ---
> v2: New patch
> ---
On Sun, 31 Mar 2024 at 21:34, Jonas Karlman wrote:
>
> Sync rk3399-rock960 related device tree from linux v6.8.
TBH I wouldn't class this as "Sync device tree from linux v6.8", it
does a dozen other things as well!
> Add DM_RESET=y to support reset signals.
>
> Add PCI=y, CMD_PCI=y and
se TPL+SPL and use common bss and stack addresses to allow
> for more options to be enabled in a future patch. Also add the missing
> DEFAULT_FDT_FILE option.
>
> Signed-off-by: Jonas Karlman
Reviewed-by: Peter Robinson
I believe I have one of these if you need anything test
Jonas Karlman
Reviewed-by: Peter Robinson
Looks good, I meant to do this ages ago.
> ---
> arch/arm/mach-rockchip/Kconfig | 2 ++
> configs/chromebook_bob_defconfig | 2 --
> configs/chromebook_kevin_defconfig | 2 --
> configs/evb-rk3399_defconfig | 2
Hi Jonas,
Overall this series looks good, and I'll be able to test it fro next
week when I'm back near devices.
> This series adds support for new clocks used in linux v6.8 device trees,
> enables use of FIT signature check for checksum validation and fixes
> loading FIT from SD-card when
Hi Martin,
> I reworked the commit message because I noticed the upstream Linux kernel has
> a
> difference with the Raspberry Pi fork of the kernel regarding the algorithm
> used to determine the MAC address of the smsc95xx.
So looking at this on an original 3B because that's what I had booted
On Tue, 12 Mar 2024 at 09:55, Sumit Garg wrote:
>
> Hi Peter,
>
> On Tue, 12 Mar 2024 at 15:13, Peter Robinson wrote:
> >
> > Hi Sumit,
> >
> > > pcie_imx doesn't seem to share any useful code for iMX8MP SoC and it is
> > > rather tied to quite old
Hi Sumit,
> pcie_imx doesn't seem to share any useful code for iMX8MP SoC and it is
> rather tied to quite old port of pcie_designware driver from Linux which
> suffices only iMX6 specific needs.
>
> But currently we have the common DWC specific bits which alligns pretty
> well with DW PCIe
partition IDs as they are also
permissable for an ESP.
Signed-off-by: Peter Robinson
---
v2:
- Add 0x0c option
- Make hex constants consistent
- Move from if to switch statement
v3:
- Fix switch brain fart
v4:
- Drop boot_ind out of switch
disk/part_dos.c | 13 -
1 file changed, 12
partition IDs as they are also
permissable for an ESP.
Signed-off-by: Peter Robinson
---
v2:
- Add 0x0c option
- Make hex constants consistent
- Move from if to switch statement
v3:
- Fix switch brain fart
disk/part_dos.c | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff
On Sun, 25 Feb 2024 at 14:23, Mark Kettenis wrote:
>
> > From: Peter Robinson
> > Date: Sun, 25 Feb 2024 14:14:55 +
> >
> > The EFI spec states that the ESP can be any of FAT12/16/32 but for
> > compatibility doesn't necssarily require the partition to
On Thu, 29 Feb 2024 at 19:11, Igor Opaniuk wrote:
>
> Hi Ilias,
>
> On Wed, Feb 14, 2024 at 7:34 PM Igor Opaniuk
> wrote:
>
> > - Address some spelling errors and typos
> > - Support CMD_OPTEE_RPMB for SANDBOX configurations and add python tests
> > - Remove common.h inclusion for drivers/tee
>
On Wed, 28 Feb 2024 at 10:58, Ilias Apalodimas
wrote:
>
> The arm linker scripts had a mix of symbols and C defined variables in an
> effort to emit relative references instead of absolute ones e.g [0].
> This has led to confusion over the years, ending up with mixed section
> definitions. Some
partition IDs as they are also
permissable for an ESP.
Signed-off-by: Peter Robinson
---
v2:
- Add 0x0c option
- Make hex constants consistent
- Move from if to switch statement
disk/part_dos.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/disk/part_dos.c b
Hi,
> I have a Raspberry Pi 3B Plus which I want to integrate with U-boot
> (v2023.10) .
>
> I am using rpi_3_32b_defconfig to generate u-boot.bin. But while booting I
> am getting below error
>
> Loading Environment from FAT... Unable to read "uboot.env" from mmc0:1...
> In:serial,usbkbd
>
On Wed, 21 Feb 2024, 11:30 Bob Wolff, wrote:
> Hi there,
> I have two separate but related pull requests I'd like to contribute. They
> both have to do with ECDSA support.
> - The simple one is a lack of null-pointer check that can cause a crash in
> certain situations. Easy peasy.
>
Just send
On Thu, 15 Feb 2024 at 21:03, Caleb Connolly wrote:
>
> Add a config fragment for building U-Boot such that it can be
> chainloaded by aboot/LK rather than being flashed directly to the aboot
> partition.
How does this work in practice? I think a lot of devices, one example
I see is signed vs
On Mon, 19 Feb 2024 at 10:24, Mark Kettenis wrote:
>
> > From: Peter Robinson
> > Date: Mon, 19 Feb 2024 09:12:15 +
> >
> > The EFI spec states that the ESP can be any of FAT12/16/32 but for
> > compatibility doesn't necssarily require the partition to
partition IDs as they are also
permissable for an ESP.
Signed-off-by: Peter Robinson
---
disk/part_dos.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/disk/part_dos.c b/disk/part_dos.c
index 567ead7511d..303eb1d13ee 100644
--- a/disk/part_dos.c
+++ b/disk/part_dos.c
@@ -40,6 +40,12
This is the only board that enables it, and looking generally I don't
believe it's used. All use cases I could fine for the board rub by
default off jffs on the nand and it doesn't enable USB storage.
Signed-off-by: Peter Robinson
Cc: egnite GmbH
---
configs/ethernut5_defconfig | 1 -
1 file
It was only included by a single board which doesn't appear to have
ever used it for any default use cases so drop the filesystem now
that isn't used by any in-tree configurations.
Signed-off-by: Peter Robinson
---
cmd/Kconfig| 9 -
cmd/reiser.c | 171
actually appear to be
actively maintained either for the best part of 10+ years but I don't
remove that as part of this PR but leave it to someone who may know the
AT91 ecosystem better than me.
Peter Robinson (2):
configs: ethernut5: Drop reiserfs
fs: drop reiserfs
cmd/Kconfig
up() from the weak function
> rk_board_late_init() into the main board_late_init() function.
>
> Signed-off-by: Jonas Karlman
Reviewed-by: Peter Robinson
Looks good.
> ---
> arch/arm/mach-rockchip/board.c| 10 +++---
> arch/arm/mach-rockchip/rk3399/Kconfig
The Broadcom Northstar 2 support was removed when the
bcm958712k board was removed but the target entry was
missed so clean that up as well.
Fixes: d59bc09d829 ("arm: Remove bcm958712k board")
Signed-off-by: Peter Robinson
---
arch/arm/Kconfig | 9 -
1 file changed, 9 deletion
On Sat, 17 Feb 2024 at 16:53, John wrote:
>
> I am running Arch ARM on a RPi4B and also on a RPi5B. My RPi4B can boot the
> vanilla kernel package (linux-aarch64) with the latest uboot-raspberrypi
> (2024.04-rc2) just fine. Yet, if I take that uSD card and place it in my
> RPi5B, it does not
> I am running the NanoPi R6C. The device is not capable of booting from
> the SSD, the next best thing is to load the root filesystem from the SSD.
By booting you mean loading the firmware from SSD (by which I think
you mean NVME right).
> Using rockchip's repos, I compile from source the
On Tue, 13 Feb 2024 at 12:18, Cedric Blancher wrote:
>
> Good morning!
>
> Does U-Boot support booting from a NFSv4 file system? Explicitly
> neither NFSv2 or NFSv3 will work in our case, as both protocol
> versions are depreciated and no longer allowed by our IT department.
Not that I am aware
On Mon, 12 Feb 2024 at 14:16, Dragan Simic wrote:
>
> Hello Peter,
>
> On 2024-02-12 14:56, Peter Robinson wrote:
> > On Fri, 9 Feb 2024 at 18:57, Dragan Simic wrote:
> >> On 2024-02-09 19:36, Mark Kettenis wrote:
> >> >> Date: Fri, 09 Feb 2024
addresses for all boards.
For the series:
Reviewed-by: Peter Robinson
> This stacks on top of the recent defconfig update series [1] from Jonas.
>
> [1] https://lore.kernel.org/u-boot/20240207000301.3270722-1-jo...@kwiboo.se/
>
>
> Chen-Yu Tsai (4):
> rockchip: rk3328: R
On Fri, 9 Feb 2024 at 18:57, Dragan Simic wrote:
>
> Hello Mark,
>
> On 2024-02-09 19:36, Mark Kettenis wrote:
> >> Date: Fri, 09 Feb 2024 18:58:01 +0100
> >> From: Dragan Simic
> >> Please, see my comments below.
> >>
> >> On 2024-02-09 10:50, Quentin Schulz wrote:
> >> > From: Quentin Schulz
eak symbol instead.
Reviewed-by: Peter Robinson
> Cc: Quentin Schulz
> Reviewed-by: Kever Yang
> Signed-off-by: Quentin Schulz
> ---
> arch/arm/include/asm/arch-rockchip/misc.h | 9 -
> arch/arm/mach-rockchip/board.c| 5 -
> 2 files changed, 4 insert
On Fri, 9 Feb 2024 at 09:50, Quentin Schulz wrote:
>
> From: Quentin Schulz
>
> Only setup_iodomain() differs from the original misc_init_r from
> Rockchip mach code, so let's use rockchip_early_misc_init_r instead of
> reimplementing the whole misc_init_r from Rockchip.
d, I vaguely remember
we might have excluded rockchip_setup_macaddr because of an error but
that was some time ago.
Reviewed-by: Peter Robinson
> Cc: Quentin Schulz
> Reviewed-by: Kever Yang
> Signed-off-by: Quentin Schulz
> ---
> .../pine64/pinephone-pro-rk3399/pinephone-pro-
ould be gated on GMAC_ROCKCHIP or
something similar. Otherwise:
Reviewed-by: Peter Robinson
> Cc: Quentin Schulz
> Reviewed-by: Kever Yang
> Signed-off-by: Quentin Schulz
> ---
> board/pine64/pinebook-pro-rk3399/pinebook-pro-rk3399.c | 18
> ++
> 1 file changed, 2 in
On Sun, 11 Feb 2024 at 16:02, Andrey Skvortsov
wrote:
>
> In general any DRAM address, that isn't overwritten during a boot is
> suitable for pstore.
What's this functionality providing? The details below give the
technical reasons for the memory address but I'm not sure what
enabling pstore
On Wed, 7 Feb 2024 at 13:48, Tom Rini wrote:
>
> On Wed, Feb 07, 2024 at 02:00:16PM +0100, Igor Opaniuk wrote:
> > Hello,
> >
> > I was playing a bit with different hash functions recently, and
> > it turned out that md5sum, crc32, sha1 cmds just duplicate
> > what is already covered by generic
configs: rpi_arm64: build position independent code (2024-01-30 17:40:13
> +0100)
>
> ----
> Add RaspberryPi5 basic support.
Acked-by: Peter Robinson
>
> Dmitry Malkin (2):
On Thu, 25 Jan 2024 at 03:02, Heinrich Schuchardt
wrote:
>
> On 1/24/24 22:16, Tom Rini wrote:
> > On Wed, Jan 17, 2024 at 04:33:45PM +0100, Heinrich Schuchardt wrote:
> >
> >> U-Boot can either generated an SMBIOS table or copy it from a prior boot
> >> stage, e.g. QEMU.
> >>
> >> Provide a
On Sun, 14 Jan 2024 at 10:23, Svyatoslav Ryhel wrote:
>
> It seems that the U-Boot console entry of the bootmenu has lost
> its original meaning. Now, even if it is chosen, the probability
> that you will enter the actual U-Boot console is quite low.
> Boot env, bootflow, bootcommand script may
On Wed, Jan 3, 2024 at 2:03 PM Tom Rini wrote:
>
> On Wed, Jan 03, 2024 at 06:37:16PM +0530, Sumit Garg wrote:
>
> [snip]
> > Tom, Simon,
> >
> > Is there any U-Boot policy in regards to board code going forward? Are
> > we moving in a direction to get rid of most board specific stubs from
> >
gned-off-by: Simon Glass
Reviewed-by: Peter Robinson
It's also worth noting here the aarch64 Server Base Boot Requirements
(SBBR) has required SMBIOS v3 since version 1.0 of the spec [1].
[1] https://documentation-service.arm.com/static/5fb7e5adca04df4095c1d64d
> ---
>
> Changes in v5:
On Mon, Oct 23, 2023 at 4:55 PM Mark Kettenis wrote:
>
> > From: Simon Glass
> > Date: Mon, 23 Oct 2023 00:08:40 -0700
> >
> > > > fdt_node_check_compatible() does most of the work...then you need to
> > > > check which FDT has the most specific match (i.e. latest in the string
> > > > list).
On Sat, Dec 23, 2023 at 12:53 AM Heinrich Schuchardt wrote:
>
> U-Boot can either generated an SMBIOS table or copy it from a prior boot
> stage, e.g. QEMU.
>
> Provide a command to display the SMBIOS information.
>
> Currently only type 1 and 2 are translated to human readable text.
> Other
On Fri, Dec 29, 2023 at 12:23 AM Tom Rini wrote:
>
> On Thu, Dec 28, 2023 at 07:48:08PM +, Simon Glass wrote:
> > Hi Tom,
> >
> > On Thu, Dec 28, 2023 at 3:40 PM Tom Rini wrote:
> > >
> > > On Thu, Dec 28, 2023 at 03:09:40PM +, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Thu,
On Fri, Dec 22, 2023 at 3:37 PM Tom Rini wrote:
>
> On Fri, 22 Dec 2023 16:01:56 +0100, Heinrich Schuchardt wrote:
>
> > If we call efi_binary_run() with size parameter set to zero, we get an error
> >
> > Not a PE-COFF file
> >
> > Fill the missing value.
> >
> >
> > [...]
>
> Applied to
On Sat, Dec 16, 2023 at 6:57 PM Simon Glass wrote:
>
> Hi Tom,
>
> On Thu, 14 Dec 2023 at 06:11, Tom Rini wrote:
> >
> > On Wed, Dec 13, 2023 at 08:19:11PM -0700, Simon Glass wrote:
> >
> > [snip]
> > > The new DT nodes / SMBIOS binding [1] allows for the correct
> > > information to be
> > > > Maybe we need to turn this discussion on its head slightly. What do you
> > > > want to do to get SMBIOS fields to be widely populated with
> > > > generally-correct information? What we have been doing has seen very
> > > > little adoption so we need something else.
> > >
> > > Well, who
Hi Simon,
> > > > > Hmm I don't know, but I wonder why I am not just checking t->bios_ver
> > > > > for Unknown.
> > > > > I'll have a look and change it
> > > >
> > > > Ok, this can't be changed as easily. smbios_add_prop() will not
> > > > return NULL in any case. It returns an integer. With
On Wed, Dec 20, 2023 at 6:37 AM Ilias Apalodimas
wrote:
>
> Hi Michael
>
> On Tue, 19 Dec 2023 at 14:47, Michael Walle wrote:
> >
> > Hi Mark,
> >
> > >> > Any runtime device drivers for variable storage should not be in the
> > >> > U-Boot runtime but live in the secure world (e.g. OP-TEE) FF-A
Move the use of md5s for recording filesystem file integrity
checks to sha256 hashes as they're preferred due to being
less likely to produce clashing hashes. In the process
generalise some of the wording to use the more generic
hash term.
Signed-off-by: Peter Robinson
---
test/fs/fs-test.sh
Hi Simon,
On Mon, Dec 18, 2023 at 3:02 PM Simon Glass wrote:
>
> Hi Ilias,
>
> On Wed, 6 Dec 2023 at 04:36, Ilias Apalodimas
> wrote:
> >
> > [...]
> >
> > >
> > >>
> > >> > str = "Unknown";
> > >> >
> > >> > for (;;) {
> > >> > @@ -151,8 +151,7 @@ static int
> > > > What do you mean wrong, exactly?
> > >
> > > "raspberrypi" instead of "Raspberry Pi", for example, or "friendlyarm"
> > > instead of "FriendlyElec"
> >
> > Heh, well, even in the x86 world vendors can't even spell their own
> > name consistently.
> >
> > > I just wonder what this
> > > > > > Not always. I am not sure if x86 does that, but on the rest of the
> > > > > > architectures, they are only initialized when the efi smbios code
> > > > > > runs. Wasn't this something you were trying to change?
> > > > >
> > > > > One of those things I keep repeating is that we don't
Hi Simon,
Sorry for the delayed response, I was out with COVID.
> I tried the instructions here with a rpi4:
>
> https://docs.fedoraproject.org/en-US/quick-docs/raspberry-pi/#_installing_fedora_on_a_raspberry_pi_for_linux_users
>
> xzcat Fedora-Workstation-39-1.5.aarch64.raw.xz | sudo dd
>
pberry Pi 4 Model B Rev 1.1
> Version: Unknown
> Serial Number: 1bb24ceb
> UUID: 30303031-3030-3030-3061-613234636435
> Wake-up Type: Reserved
> SKU Number: Unknown
> Family: Unknown
> [...]
>
> Signed-off-by: Ilia
...]
>
> While at it make smbios_add_prop_si() add a string directly if the prop
> node is NULL and replace smbios_add_string() calls with
> smbios_add_prop_si(ctx, NULL, )
>
> Signed-off-by: Ilias Apalodimas
Reviewed-by: Peter Robinson
Tested-by: Peter Robinson
> ---
On Fri, Dec 8, 2023 at 12:52 PM Shantur Rathore wrote:
>
> Hi Jagan,
>
> On Fri, Dec 8, 2023 at 11:13 AM Jagan Teki wrote:
> >
> > On Sun, Nov 19, 2023 at 10:54 PM Shantur Rathore wrote:
> > >
> > > Rockchip SoCs can support wide range of bootflows.
> > > Without full bootflow commands, it can
On Sun, Nov 19, 2023 at 6:55 PM Mark Kettenis wrote:
>
> > Date: Sat, 18 Nov 2023 23:52:11 +0100
> > From: Heinrich Schuchardt
>
> Hi Heinrich,
>
> > On 11/18/23 22:28, Shantur Rathore wrote:
> > > Hi Heinrich,
> > >
> > > On Fri, Nov 17, 2023 at 3:12 PM Heinrich Schuchardt
> > > wrote:
> > >>
On Thu, Nov 30, 2023 at 2:45 AM Simon Glass wrote:
>
> Hi Ilias,
>
> On Mon, 27 Nov 2023 at 10:11, Ilias Apalodimas
> wrote:
> >
> > In order to fill in the SMBIOS tables U-Boot currently relies on a
> > "u-boot,sysinfo-smbios" compatible node. This is fine for the boards
> > that already
pberry Pi 4 Model B Rev 1.1
> Version: Unknown
> Serial Number: 1bb24ceb
> UUID: 30303031-3030-3030-3061-613234636435
> Wake-up Type: Reserved
> SKU Number: Unknown
> Family: Unknown
> [...]
>
> Signed-off-by: I
On Wed, Dec 6, 2023 at 9:31 AM Heinrich Schuchardt
wrote:
>
> On 05.12.23 07:23, Masahisa Kojima wrote:
> > Hi Heinrich,
> >
> > On Tue, 5 Dec 2023 at 11:38, Heinrich Schuchardt
> > wrote:
> >>
> >> * Only generate removable media entries for EFI system partitions.
> >> * Only offer EFI system
1 - 100 of 960 matches
Mail list logo
