On 10/26/21 5:30 AM, Simon Glass wrote:
Most modern platforms use 64-bit EFI so it is useful to have a U-Boot app
that runs under that. Add a (non-functional) build for this.
Note that --whole-archive causes the gcc 9.2 linker to crash, so disable
this for now. Once this is resolved, things
On 10/26/21 5:30 AM, Simon Glass wrote:
For the EFI app, we must embed the devicetree in the ELF file since that
is the only thing that is run by UEFI. Drop the warning to avoid
confusion.
Signed-off-by: Simon Glass
Reviewed-by: Heinrich Schuchardt
---
(no changes since v2)
Changes in
On 10/26/21 5:30 AM, Simon Glass wrote:
There is no need to avoid driver model for networking. Drop this.
Signed-off-by: Simon Glass
This seems to be an unrelated problem in building efi-x86_app_defconfig:
LD u-boot
ld.bfd: arch/x86/lib/bios_asm.o: warning: relocation against
On 10/26/21 5:30 AM, Simon Glass wrote:
It is quite complicated to run U-Boot on QEMU since we have four
different builds and they must use different versions of qemu and the
UEFI binaries.
Add a script to help.
Signed-off-by: Simon Glass
It seems that you missed some of my review comments:
On 10/27/21 9:52 PM, Anatolij Gustschin wrote:
Hi Heinrich,
On Wed, 27 Oct 2021 20:10:36 +0200
Heinrich Schuchardt xypron.g...@gmx.de wrote:
Dear Anatolij,
somehow you lost track of this patch since March:
With the patch accurate positioning is possible for mono-typed fonts:
Fix the return value of console_truetype_putc_xy(). The current position
is passed as parameter x. Some part of x represents a fractional pixel.
The return value represents how much the character position must be
advanced. This
Hello Tom,
we have some trouble with Gitlab CI:
In https://source.denx.de/u-boot/custodians/u-boot-efi/-/jobs/342220
sandbox: + sandbox_spl
+/usr/bin/ld: /tmp/u-boot-spl.Z4D5y0.ltrans0.ltrans.o: in function
`dm_setup_inst.lto_priv.0':
+drivers/core/root.c:134: undefined reference to
On Wed, Oct 27, 2021 at 5:19 AM Bin Meng wrote:
>
> On Sun, Oct 17, 2021 at 2:26 AM Ramon Fried wrote:
> >
> > On Wed, Sep 29, 2021 at 4:32 PM Vladimir Oltean
> > wrote:
> > >
> > > On Wed, Sep 29, 2021 at 01:50:44PM +0800, Bin Meng wrote:
> > > > set_promisc() call accepts the parameter of a
From: Marek Behún
ESPRESSObin's board code uses an ad-hoc solution for ensuring that
ethaddrs are not overwritten by `env default -a` command and that the
`fdtfile` is set to correct value when `env default -a` is called.
This ad-hoc solution is overwriting the default_environment[] buffer in
From: Marek Behún
The default_environment[] buffer is built at compile time, but sometimes
it makes sense for some default environment variables to be determined
at runtime, for example:
- one board code may support different boards, and needs that
fdtfile, board, board_name
are set
From: Marek Behún
Instead of pretending that we don't have environment to force searching
default environment in env_get_default(), get the data from the
default_environment[] buffer directly.
Signed-off-by: Marek Behún
---
env/common.c | 45 -
1
From: Marek Behún
Do not set GD_FLG_ENV_READY nor GD_FLG_ENV_DEFAULT if failed importing
in env_set_default().
Signed-off-by: Marek Behún
---
env/common.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/env/common.c b/env/common.c
index 99729ca002..2aa23545ba 100644
---
From: Marek Behún
The env_get_f() function returns -1 on failure. Returning 0 means that
the variable exists, and is empty string.
Signed-off-by: Marek Behún
---
env/common.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/env/common.c b/env/common.c
index
From: Marek Behún
Hello Simon, Stefan, Pali,
this series adds support for board specific runtime determined
default environment variables.
IMPORTANT: This series depends on the series
http://patchwork.ozlabs.org/project/uboot/list/?series=268452
Currently the
env default [-a]
command uses
Hi Marek,
Ah. That makes sense! I don't have the km_kirkwood_xxx boards.
Thanks,
Tony
On Wed, Oct 27, 2021 at 6:28 PM Marek Behún wrote:
>
> On Wed, 27 Oct 2021 16:06:58 -0700
> Tony Dinh wrote:
>
> > Hi Marek,
> >
> > In reference to:
> >
On Wed, 27 Oct 2021 16:06:58 -0700
Tony Dinh wrote:
> Hi Marek,
>
> In reference to:
> https://lists.denx.de/pipermail/u-boot/2021-October/465221.html
>
> I have several Kirkwood boards, and currently support these boards in
> mainline: Sheevaplug, Zyxel NSA310S, GoFlex Home, Dockstar. I also
> From: Heinrich Schuchardt
> Sent: Monday, October 25, 2021 9:10 PM
> To: Rick Jian-Zhi Chen(陳建志) ; Leo Yu-Chi Liang(梁育齊)
>
> Cc: u-boot@lists.denx.de; Heinrich Schuchardt
>
> Subject: [PATCH 2/2] cmd: sbi: show SBI implementation version
>
> Let the sbi command show the SBI implementation
> From: Heinrich Schuchardt
> Sent: Monday, October 25, 2021 9:10 PM
> To: Rick Jian-Zhi Chen(陳建志) ; Leo Yu-Chi Liang(梁育齊)
>
> Cc: u-boot@lists.denx.de; Heinrich Schuchardt
>
> Subject: [PATCH 1/2] riscv: function to retrieve SBI implementation version
>
> Provide function
Hi Marek,
In reference to:
https://lists.denx.de/pipermail/u-boot/2021-October/465221.html
I have several Kirkwood boards, and currently support these boards in
mainline: Sheevaplug, Zyxel NSA310S, GoFlex Home, Dockstar. I also
have a few out-of-tree Kirkwood u-boots that have not been submitted
> From: Simon Glass
> Date: Wed, 27 Oct 2021 12:23:21 -0600
>
> Hi François,
>
> On Wed, 27 Oct 2021 at 09:14, François Ozog wrote:
> >
> >
> >
> > On Wed, 27 Oct 2021 at 16:08, Simon Glass wrote:
> >>
> >> Hi François,
> >>
> >> On Tue, 26 Oct 2021 at 00:07, François Ozog
> >> wrote:
> >>
From: Mike Karels
Using mmc.dtbo from rpi-firmware to switch the controller for the SD
card slot from sdhci to sdhost causes the numbering to change; the
SD card is then not recognized at boot. Add to the range checked.
---
include/configs/rpi.h | 3 ++-
1 file changed, 2 insertions(+), 1
Hello Stefan,
do you have some ARM Kirkwood board? I am working on some env patches,
because the code in the env/ directory is a pain in the ass of old
relics, and Kirkwood is the only platform using the eeprom environment
driver.
I would like to ask about Kirkwood stack size.
In
Hi Tom
Le mer. 27 oct. 2021 à 21:06, Tom Rini a écrit :
> On Wed, Oct 27, 2021 at 06:02:19PM +0200, François Ozog wrote:
> > Hi Mark,
> >
> > On Wed, 27 Oct 2021 at 17:10, Mark Kettenis
> wrote:
> >
> > > > From: François Ozog
> > > > Date: Wed, 27 Oct 2021 15:15:01 +0200
> > > >
> > > > Hi,
> From: Simon Glass
> Date: Wed, 27 Oct 2021 09:24:25 -0600
>
> Hi Mark,
>
> On Wed, 27 Oct 2021 at 09:11, Mark Kettenis wrote:
> >
> > > From: François Ozog
> > > Date: Wed, 27 Oct 2021 15:15:01 +0200
> > >
> > > In my view U-Boot shall be able to leverage device tree format
> > > (source
On Wed, Oct 27, 2021 at 11:33:53PM +0200, François Ozog wrote:
> Hi Tom
>
> Le mer. 27 oct. 2021 à 21:12, Tom Rini a écrit :
>
> > On Wed, Oct 27, 2021 at 10:17:05AM +0300, Ilias Apalodimas wrote:
> > > Hi Simon,
> > >
> > > On Tue, 26 Oct 2021 at 18:27, Simon Glass wrote:
> > > >
> > > > Hi
Hi Tom
Le mer. 27 oct. 2021 à 21:12, Tom Rini a écrit :
> On Wed, Oct 27, 2021 at 10:17:05AM +0300, Ilias Apalodimas wrote:
> > Hi Simon,
> >
> > On Tue, 26 Oct 2021 at 18:27, Simon Glass wrote:
> > >
> > > Hi Ilias,
> > >
> > > On Tue, 26 Oct 2021 at 07:56, Ilias Apalodimas
> > > wrote:
> >
On Wednesday 27 October 2021 17:27:41 Stefan Roese wrote:
> Still I see no speed change. But this is a different story...
Could you try to upload some file in u-boot via xmodem at different
speeds? E.g. via loadx command:
loadx 921600
and
loadx 115200
And compare if xmodem transfer is in
On Wed, Oct 27, 2021 at 10:11:36PM +0200, Robert Marko wrote:
> On Wed, Oct 27, 2021 at 10:07 PM Tom Rini wrote:
> >
> > On Wed, Oct 27, 2021 at 09:53:24PM +0200, Robert Marko wrote:
> > > On Wed, Oct 27, 2021 at 9:48 PM Marek Behún wrote:
> > > >
> > > > On Wed, 27 Oct 2021 21:40:11 +0200
> > >
Hi Tom
Le mer. 27 oct. 2021 à 21:48, Tom Rini a écrit :
> On Wed, Oct 27, 2021 at 05:38:28PM +0200, François Ozog wrote:
> > Hi Simon,
> >
> > On Wed, 27 Oct 2021 at 16:13, Simon Glass wrote:
> >
> > > Hi François,
> > >
> > > On Tue, 26 Oct 2021 at 09:57, François Ozog
> > > wrote:
> > > >
>
On Wed, Oct 27, 2021 at 10:07 PM Tom Rini wrote:
>
> On Wed, Oct 27, 2021 at 09:53:24PM +0200, Robert Marko wrote:
> > On Wed, Oct 27, 2021 at 9:48 PM Marek Behún wrote:
> > >
> > > On Wed, 27 Oct 2021 21:40:11 +0200
> > > Robert Marko wrote:
> > >
> > > > To me, it also doesn't make sense to
> > >> I also have been doing some packaging of u-boot for GNU Guix, where I
> > >> suspect the stance wouldn't be as willing to accept such a compromise...
> > >>
> > >> So... I would *love* an option to be able to build a board-only config
> > >> without any of the tools;
> > >
> > > Why is this
Hi Simon
Le mer. 27 oct. 2021 à 20:23, Simon Glass a écrit :
> Hi François,
>
> On Wed, 27 Oct 2021 at 09:14, François Ozog
> wrote:
> >
> >
> >
> > On Wed, 27 Oct 2021 at 16:08, Simon Glass wrote:
> >>
> >> Hi François,
> >>
> >> On Tue, 26 Oct 2021 at 00:07, François Ozog
> wrote:
> >> >
>
On Wed, Oct 27, 2021 at 09:53:24PM +0200, Robert Marko wrote:
> On Wed, Oct 27, 2021 at 9:48 PM Marek Behún wrote:
> >
> > On Wed, 27 Oct 2021 21:40:11 +0200
> > Robert Marko wrote:
> >
> > > To me, it also doesn't make sense to do it like that as what's the
> > > purpose of having stuff that is
On Wed, Oct 27, 2021 at 9:48 PM Marek Behún wrote:
>
> On Wed, 27 Oct 2021 21:40:11 +0200
> Robert Marko wrote:
>
> > To me, it also doesn't make sense to do it like that as what's the
> > purpose of having stuff that is completely unsupported in U-boot in
> > DTS?
>
> It makes sense because the
Hi Ilias,
On Wed, 27 Oct 2021 at 13:13, Ilias Apalodimas
wrote:
>
> On Wed, 27 Oct 2021 at 21:33, Simon Glass wrote:
> >
> > Hi François,
> >
> > On Wed, 27 Oct 2021 at 09:38, François Ozog
> > wrote:
> > >
> > > Hi Simon,
> > >
> > > On Wed, 27 Oct 2021 at 16:13, Simon Glass wrote:
> > >>
>
Hi Heinrich,
On Wed, 27 Oct 2021 20:10:36 +0200
Heinrich Schuchardt xypron.g...@gmx.de wrote:
> Dear Anatolij,
>
> somehow you lost track of this patch since March:
>
> https://patchwork.ozlabs.org/project/uboot/patch/20210203161254.970-1-xypron.g...@gmx.de/
>
> Could you, please, review it
On Wed, 27 Oct 2021 21:40:11 +0200
Robert Marko wrote:
> To me, it also doesn't make sense to do it like that as what's the
> purpose of having stuff that is completely unsupported in U-boot in
> DTS?
It makes sense because the device tree should compeltely describe the
device. It doesn't
On Wed, Oct 27, 2021 at 05:38:28PM +0200, François Ozog wrote:
> Hi Simon,
>
> On Wed, 27 Oct 2021 at 16:13, Simon Glass wrote:
>
> > Hi François,
> >
> > On Tue, 26 Oct 2021 at 09:57, François Ozog
> > wrote:
> > >
> > >
> > >
> > > On Tue, 26 Oct 2021 at 17:27, Simon Glass wrote:
> > >>
> >
Hi Simon,
Le mer. 27 oct. 2021 à 20:33, Simon Glass a écrit :
> Hi François,
>
> On Wed, 27 Oct 2021 at 09:38, François Ozog
> wrote:
> >
> > Hi Simon,
> >
> > On Wed, 27 Oct 2021 at 16:13, Simon Glass wrote:
> >>
> >> Hi François,
> >>
> >> On Tue, 26 Oct 2021 at 09:57, François Ozog
>
There are QEMU targets that have fixed hardware which do rely on the
firmware to have a fixed view of the hardware. sbsa-ref is one such board
although there will be some versioning required for later levels.
On Wed, 27 Oct 2021, 19:39 Tom Rini, wrote:
> On Wed, Oct 27, 2021 at 12:34:26PM
On Wed, Oct 27, 2021 at 8:32 PM Pali Rohár wrote:
>
> On Wednesday 27 October 2021 20:01:33 Robert Marko wrote:
> > Globalscale MOCHAbin is a Armada 7040 based development board.
> >
> > Specifications:
> > * Armada 7040 Quad core ARMv8 Cortex A-72 @ 1.4GHz
> > * 2 / 4 / 8 GB of DDR4 DRAM
> > *
On Wed, Oct 27, 2021 at 12:23:21PM -0600, Simon Glass wrote:
> Hi François,
>
> On Wed, 27 Oct 2021 at 09:14, François Ozog wrote:
> >
> >
> >
> > On Wed, 27 Oct 2021 at 16:08, Simon Glass wrote:
> >>
> >> Hi François,
> >>
> >> On Tue, 26 Oct 2021 at 00:07, François Ozog
> >> wrote:
> >> >
>
On Wed, Oct 27, 2021 at 06:36:12PM +0300, Tuomas Tynkkynen wrote:
> Hi,
>
> On 27.10.2021 17.08, Simon Glass wrote:
> > Hi François,
> >
> > On Tue, 26 Oct 2021 at 00:07, François Ozog
> > wrote:
> > >
> > > Hi Simon
> > >
> > > Position unchanged on this series: adding fake dts for boards
On Wed, 27 Oct 2021 at 21:33, Simon Glass wrote:
>
> Hi François,
>
> On Wed, 27 Oct 2021 at 09:38, François Ozog wrote:
> >
> > Hi Simon,
> >
> > On Wed, 27 Oct 2021 at 16:13, Simon Glass wrote:
> >>
> >> Hi François,
> >>
> >> On Tue, 26 Oct 2021 at 09:57, François Ozog
> >> wrote:
> >> >
>
On Wed, Oct 27, 2021 at 10:17:05AM +0300, Ilias Apalodimas wrote:
> Hi Simon,
>
> On Tue, 26 Oct 2021 at 18:27, Simon Glass wrote:
> >
> > Hi Ilias,
> >
> > On Tue, 26 Oct 2021 at 07:56, Ilias Apalodimas
> > wrote:
> > >
> > > Hi Simon,
> > >
> > > As I said here [1], this is moving on an
On Wed, Oct 27, 2021 at 06:02:19PM +0200, François Ozog wrote:
> Hi Mark,
>
> On Wed, 27 Oct 2021 at 17:10, Mark Kettenis wrote:
>
> > > From: François Ozog
> > > Date: Wed, 27 Oct 2021 15:15:01 +0200
> > >
> > > Hi,
> > >
> > > On Wed, 27 Oct 2021 at 14:48, Tom Rini wrote:
> > >
> > > > On
From: Pali Rohár
The ARM code we inject into the image to change baudrate back to the
default value of 115200 Baud, which is run after successful UART transfer
of the whole image, cannot use stack as at this stage stack pointer is not
initialized yet.
Stack can only be used when BootROM is
From: Pali Rohár
Older Armada SoCs have custom ARMv5te compatible core which does not
support movt instruction. So replace mov + movt instruction pair used for
immediate move construction by mov + orr instructions which are supported
also by ARMv5te.
After this change kwboot ARM code should be
From: Pali Rohár
Kwboot puts each xmodem packet to kernel queue, then waits until all bytes
of that packet are transmitted over UART and then waits for xmodem reply
until it is received into kernel queue.
If some reply is received during the time we are waiting until all bytes
are transmitted,
From: Pali Rohár
Increase loop cycles from 60 to 2998272, which should increase delay
from 1ms to about 5ms on 1200 MHz CPU.
The Number 2998272 was chosen as the nearest value around 300 which can
be encoded into one ARM mov instruction. It avoids usage of movt instruction
which is not
From: Pali Rohár
After the trasfer of last header packet, it is possible that baudrate
change pattern is received, and also that NAK byte is received so that
the packet should be sent again.
Thus we should not clear the baudrate change state when sending retry
of that packet.
Move code for
From: Marek Behún
Hi Stefan,
here are some more Pali's changes for kwboot, reviewed by me. The last
one should fix boot on AXP.
Marek
Pali Rohár (5):
tools: kwboot: Fix sending retry of last header packet
tools: kwboot: Do not call tcdrain() after each sent packet
tools: kwboot:
On Wed, Oct 27, 2021 at 12:34:26PM -0600, Simon Glass wrote:
> Hi all,
>
> On Wed, 27 Oct 2021 at 08:56, Tom Rini wrote:
> >
> > On Wed, Oct 27, 2021 at 03:44:08PM +0100, Alex Bennée wrote:
> > >
> > > François Ozog writes:
> > >
> > > > Hi Simon
> > > >
> > > > The only place I could agree
Hi Ilias,
On Wed, 27 Oct 2021 at 08:48, Ilias Apalodimas
wrote:
>
> Hi Simon,
>
> On Wed, Oct 27, 2021 at 08:09:04AM -0600, Simon Glass wrote:
> > Hi Ilias,
> >
> > On Wed, 27 Oct 2021 at 02:36, Ilias Apalodimas
> > wrote:
> > >
> > > Hi Simon,
> > >
> > > On Sun, 24 Oct 2021 at 02:27, Simon
On Wed, 27 Oct 2021 at 08:23, Andy Shevchenko
wrote:
>
> Move is_protected assignment closer to its user.
> This increases readability and makes maintenance easier.
>
> Signed-off-by: Andy Shevchenko
> ---
> arch/x86/cpu/tangier/pinmux.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
On Wed, 27 Oct 2021 at 08:23, Andy Shevchenko
wrote:
>
> Move error message to the caller of mrfld_pinconfig*() in order
> to unify them in the future.
>
> Signed-off-by: Andy Shevchenko
> ---
> arch/x86/cpu/tangier/pinmux.c | 10 +++---
> 1 file changed, 3 insertions(+), 7 deletions(-)
Hi all,
On Wed, 27 Oct 2021 at 08:56, Tom Rini wrote:
>
> On Wed, Oct 27, 2021 at 03:44:08PM +0100, Alex Bennée wrote:
> >
> > François Ozog writes:
> >
> > > Hi Simon
> > >
> > > The only place I could agree with this file presence is in the
> > > documentation directory, not in dts. It
Hi Heinrich,
On Wed, 27 Oct 2021 at 05:38, Heinrich Schuchardt
wrote:
>
>
>
> On 10/24/21 01:25, Simon Glass wrote:
> >
> > The bootflow feature provide a built-in way for U-Boot to automatically
> > boot an Operating System without custom scripting and other customisation.
> > This is called
Hi François,
On Wed, 27 Oct 2021 at 09:38, François Ozog wrote:
>
> Hi Simon,
>
> On Wed, 27 Oct 2021 at 16:13, Simon Glass wrote:
>>
>> Hi François,
>>
>> On Tue, 26 Oct 2021 at 09:57, François Ozog wrote:
>> >
>> >
>> >
>> > On Tue, 26 Oct 2021 at 17:27, Simon Glass wrote:
>> >>
>> >> Hi
On Wednesday 27 October 2021 20:01:33 Robert Marko wrote:
> Globalscale MOCHAbin is a Armada 7040 based development board.
>
> Specifications:
> * Armada 7040 Quad core ARMv8 Cortex A-72 @ 1.4GHz
> * 2 / 4 / 8 GB of DDR4 DRAM
> * 16 GB eMMC
> * 4MB SPI-NOR (Bootloader)
> * 1x M.2-2280 B-key
Hi Tom
Le mer. 27 oct. 2021 à 20:06, Tom Rini a écrit :
> On Wed, Oct 27, 2021 at 09:24:25AM -0600, Simon Glass wrote:
> > Hi Mark,
> >
> > On Wed, 27 Oct 2021 at 09:11, Mark Kettenis
> wrote:
> > >
> > > > From: François Ozog
> > > > Date: Wed, 27 Oct 2021 15:15:01 +0200
> > > >
> > > > Hi,
On Wed, Oct 27, 2021 at 08:08:19AM -0600, Simon Glass wrote:
[snip]
> But trying to do any driver / core work for a board where you don't
> have the devicetree is currently not possible. The devicetree is a
> core component and being unable to modify it is simply not practical.
> We are talking
Hi François,
On Wed, 27 Oct 2021 at 09:14, François Ozog wrote:
>
>
>
> On Wed, 27 Oct 2021 at 16:08, Simon Glass wrote:
>>
>> Hi François,
>>
>> On Tue, 26 Oct 2021 at 00:07, François Ozog wrote:
>> >
>> > Hi Simon
>> >
>> > Position unchanged on this series: adding fake dts for boards that
On Wed, Oct 27, 2021 at 08:08:19AM -0600, Simon Glass wrote:
> Hi François,
>
> On Tue, 26 Oct 2021 at 00:07, François Ozog wrote:
> >
> > Hi Simon
> >
> > Position unchanged on this series: adding fake dts for boards that generate
> > their device tree in the dts directory is not good. If you
Dear Anatolij,
somehow you lost track of this patch since March:
https://patchwork.ozlabs.org/project/uboot/patch/20210203161254.970-1-xypron.g...@gmx.de/
Could you, please, review it and consider it for merging.
Best regards
Heinrich
On 2/3/21 17:12, Heinrich Schuchardt wrote:
With the
On Wed, Oct 27, 2021 at 09:24:25AM -0600, Simon Glass wrote:
> Hi Mark,
>
> On Wed, 27 Oct 2021 at 09:11, Mark Kettenis wrote:
> >
> > > From: François Ozog
> > > Date: Wed, 27 Oct 2021 15:15:01 +0200
> > >
> > > Hi,
> > >
> > > On Wed, 27 Oct 2021 at 14:48, Tom Rini wrote:
> > >
> > > > On
On Wed, Oct 27, 2021 at 05:02:39PM +0200, Heinrich Schuchardt wrote:
> On 10/27/21 16:55, Tom Rini wrote:
> > On Wed, Oct 27, 2021 at 03:23:01PM +0200, Heinrich Schuchardt wrote:
> >
> > [snip]
> > > One passed to U-Boot for fixups and further passed to the OS. This
> > > devicetree may originate
On Wed, 27 Oct 2021 10:58:35 -0700
Roman Bacik wrote:
> Thank you very much for your suggestion. To simplify, we will decouple
> this issue from the current bnxt driver submission.
Very well, that seems reasonable.
I am willing to help you with this afterwards.
Marek
Globalscale MOCHAbin is a Armada 7040 based development board.
Specifications:
* Armada 7040 Quad core ARMv8 Cortex A-72 @ 1.4GHz
* 2 / 4 / 8 GB of DDR4 DRAM
* 16 GB eMMC
* 4MB SPI-NOR (Bootloader)
* 1x M.2-2280 B-key socket (for SSD expansion, SATA3 only)
* 1x M.2-2250 B-key socket (for modems,
From: Luka Kovacic
The mac command is implemented to enable parsing Marvell hw_info formatted
environments. This format is often used on Marvell Armada devices to store
parameters like the board serial number, factory MAC addresses and some
other information.
These parameters are usually written
Hi Marek,
> -Original Message-
> From: Marek Behún
> Sent: Wednesday, October 27, 2021 10:40 AM
> To: Roman Bacik
> Cc: Simon Glass ; U-Boot Mailing List b...@lists.denx.de>; Bharat Gooty ;
> Aswath Govindraju ; Bin Meng
> ; Franck LENORMAND
> ; Heinrich Schuchardt
> ; Kory Maincent ;
On Wed, 27 Oct 2021 10:02:41 -0700
Roman Bacik wrote:
> Marek, Simon,
>
> Thank you very much for your comments. We will remove bnxt commands and will
> probe bnxt driver each boot in the next version.
> Thanks,
Roman
I think that the idea of not loading fw or initializing the controller
On Fri, Oct 22, 2021 at 12:46:59PM -0700, Vagrant Cascadian wrote:
> On 2021-10-22, Andre Przywara wrote:
> > On Fri, 22 Oct 2021 09:47:35 -0700
> > Vagrant Cascadian wrote:
> >> On 2021-10-22, Tom Rini wrote:
> >> > On Fri, Oct 22, 2021 at 04:56:09PM +0100, Andre Przywara wrote:
> >> >> On
Marek, Simon,
Thank you very much for your comments. We will remove bnxt commands and will
probe bnxt driver each boot in the next version.
Thanks,
Roman
> -Original Message-
> From: Roman Bacik
> Sent: Wednesday, October 27, 2021 9:47 AM
> To: Marek Behún
> Cc: Simon Glass ; U-Boot
Stop using the device tree as a source for ad-hoc information.
This reverts commit 2ae7adc659f7fca9ea65df4318e5bca2b8274310.
Signed-off-by: Michael Walle
---
arch/arm/Kconfig| 2 -
arch/arm/cpu/armv8/fsl-layerscape/soc.c | 27 +-
arch/arm/include/asm/gic-v3.h
From: Tom Rini
Ad-hoc bindings that are not part of the upstream device tree / bindings
are not allowed in-tree. Only bindings that are in-progress with
upstream and then re-synced once agreed upon are.
This reverts commit af288cb291da3abef6be0875527729296f7de7a0.
Cc: Hou Zhiqiang
Cc:
Please stop throwing every ad-hoc information in the device tree. Use the
official bindings (or maybe some bindings which will get approved soon).
On the quest of syncing the device tree used in u-boot with the one used in
linux, there is this nice piece:
gic_lpi_base: syscon@0x8000
Hi Marek
> -Original Message-
> From: Marek Behún
> Sent: Wednesday, October 27, 2021 9:36 AM
> To: Roman Bacik
> Cc: Simon Glass ; U-Boot Mailing List b...@lists.denx.de>; Bharat Gooty ;
> Aswath Govindraju ; Bin Meng
> ; Franck LENORMAND
> ; Heinrich Schuchardt
> ; Kory Maincent ;
>
On Wed, 27 Oct 2021 08:05:11 -0700
Roman Bacik wrote:
> chimp_ld_secure #this command loads FW, which is necessary for PCIe to
> enumerate it
> pci enum #this command is necessary to call bnxt_bind
Wait, so what is this firmware for? Is it firmware for the netXtreme
controller or for PCIe
Hi Mark,
On Wed, 27 Oct 2021 at 17:10, Mark Kettenis wrote:
> > From: François Ozog
> > Date: Wed, 27 Oct 2021 15:15:01 +0200
> >
> > Hi,
> >
> > On Wed, 27 Oct 2021 at 14:48, Tom Rini wrote:
> >
> > > On Fri, Oct 15, 2021 at 12:03:44PM -0600, Simon Glass wrote:
> > > > Hi all,
> > > >
> > >
Hi Simon,
> -Original Message-
> From: Simon Glass
> Sent: Wednesday, October 27, 2021 8:41 AM
> To: Roman Bacik
> Cc: Marek Behún ; U-Boot Mailing List b...@lists.denx.de>; Bharat Gooty ;
> Aswath Govindraju ; Bin Meng
> ; Franck LENORMAND
> ; Heinrich Schuchardt
> ; Kory Maincent ;
>
Hi Mark,
On Wed, 27 Oct 2021 at 09:11, Mark Kettenis wrote:
>
> > From: François Ozog
> > Date: Wed, 27 Oct 2021 15:15:01 +0200
> >
> > Hi,
> >
> > On Wed, 27 Oct 2021 at 14:48, Tom Rini wrote:
> >
> > > On Fri, Oct 15, 2021 at 12:03:44PM -0600, Simon Glass wrote:
> > > > Hi all,
> > > >
> > >
> From: François Ozog
> Date: Wed, 27 Oct 2021 15:15:01 +0200
>
> Hi,
>
> On Wed, 27 Oct 2021 at 14:48, Tom Rini wrote:
>
> > On Fri, Oct 15, 2021 at 12:03:44PM -0600, Simon Glass wrote:
> > > Hi all,
> > >
> > > On Thu, 14 Oct 2021 at 09:28, Tom Rini wrote:
> > > >
> > > > On Thu, Oct 14,
On 10/27/21 16:55, Tom Rini wrote:
On Wed, Oct 27, 2021 at 03:23:01PM +0200, Heinrich Schuchardt wrote:
[snip]
One passed to U-Boot for fixups and further passed to the OS. This
devicetree may originate from a prior boot stage, from a file loaded by
U-Boot, or from a later bootstage, e.g
Hi Roman,
On Wed, 27 Oct 2021 at 09:05, Roman Bacik wrote:
>
> > -Original Message-
> > From: Marek Behún
> > Sent: Tuesday, October 26, 2021 9:50 AM
> > To: Roman Bacik
> > Cc: Simon Glass ; U-Boot Mailing List > b...@lists.denx.de>; Bharat Gooty ;
> > Aswath Govindraju ; Bin Meng
>
Hi Simon,
On Wed, 27 Oct 2021 at 16:13, Simon Glass wrote:
> Hi François,
>
> On Tue, 26 Oct 2021 at 09:57, François Ozog
> wrote:
> >
> >
> >
> > On Tue, 26 Oct 2021 at 17:27, Simon Glass wrote:
> >>
> >> Hi François,
> >>
> >> On Tue, 26 Oct 2021 at 08:31, François Ozog
> wrote:
> >> >
>
Hi,
On 27.10.2021 17.08, Simon Glass wrote:
Hi François,
On Tue, 26 Oct 2021 at 00:07, François Ozog wrote:
Hi Simon
Position unchanged on this series: adding fake dts for boards that generate
their device tree in the dts directory is not good. If you have them in
documentation the it is
On Wednesday 27 October 2021 17:27:41 Stefan Roese wrote:
> On 27.10.21 16:10, Pali Rohár wrote:
>
>
>
> > > Perfect! So it really looks like that issue is in the code which resets
> > > baudrate back to the value 115200.
> > >
> > > I have there another diff which removes usage of the stack
On 27.10.21 16:10, Pali Rohár wrote:
Perfect! So it really looks like that issue is in the code which resets
baudrate back to the value 115200.
I have there another diff which removes usage of the stack in code which
resets baudrate back to default value:
diff --git a/tools/kwboot.c
Hi Heinrich,
On Wed, 27 Oct 2021 at 13:38, Heinrich Schuchardt <
heinrich.schucha...@canonical.com> wrote:
>
>
> On 10/24/21 01:25, Simon Glass wrote:
> >
> > The bootflow feature provide a built-in way for U-Boot to automatically
> > boot an Operating System without custom scripting and other
>
On Wed, 27 Oct 2021 at 16:08, Simon Glass wrote:
> Hi François,
>
> On Tue, 26 Oct 2021 at 00:07, François Ozog
> wrote:
> >
> > Hi Simon
> >
> > Position unchanged on this series: adding fake dts for boards that
> generate their device tree in the dts directory is not good. If you have
> them
On Wednesday 27 October 2021 17:08:35 Marek Behún wrote:
> On Wed, 27 Oct 2021 16:10:21 +0200
> Pali Rohár wrote:
>
> > On Wednesday 27 October 2021 15:52:47 Pali Rohár wrote:
> > > On Wednesday 27 October 2021 07:09:42 Stefan Roese wrote:
> > > > On 26.10.21 20:48, Pali Rohár wrote:
> > > >
On Wed, 27 Oct 2021 16:10:21 +0200
Pali Rohár wrote:
> On Wednesday 27 October 2021 15:52:47 Pali Rohár wrote:
> > On Wednesday 27 October 2021 07:09:42 Stefan Roese wrote:
> > > On 26.10.21 20:48, Pali Rohár wrote:
> > > > On Tuesday 26 October 2021 16:21:02 Stefan Roese wrote:
> > > > >
> -Original Message-
> From: Marek Behún
> Sent: Tuesday, October 26, 2021 9:50 AM
> To: Roman Bacik
> Cc: Simon Glass ; U-Boot Mailing List b...@lists.denx.de>; Bharat Gooty ;
> Aswath Govindraju ; Bin Meng
> ; Franck LENORMAND
> ; Heinrich Schuchardt
> ; Kory Maincent ;
> Michal Simek
On Wed, Oct 27, 2021 at 03:23:01PM +0200, Heinrich Schuchardt wrote:
[snip]
> One passed to U-Boot for fixups and further passed to the OS. This
> devicetree may originate from a prior boot stage, from a file loaded by
> U-Boot, or from a later bootstage, e.g systemd-boot's devicetree command.
I
On Wed, Oct 27, 2021 at 03:15:01PM +0200, François Ozog wrote:
> Hi,
>
> On Wed, 27 Oct 2021 at 14:48, Tom Rini wrote:
>
> > On Fri, Oct 15, 2021 at 12:03:44PM -0600, Simon Glass wrote:
> > > Hi all,
> > >
> > > On Thu, 14 Oct 2021 at 09:28, Tom Rini wrote:
> > > >
> > > > On Thu, Oct 14, 2021
On Wed, Oct 27, 2021 at 03:44:08PM +0100, Alex Bennée wrote:
>
> François Ozog writes:
>
> > Hi Simon
> >
> > The only place I could agree with this file presence is in the
> > documentation directory, not in dts. It creates a mental picture for the
> > reader
> > an entirely bad mind scheme
Hi Simon,
On Wed, Oct 27, 2021 at 08:09:04AM -0600, Simon Glass wrote:
> Hi Ilias,
>
> On Wed, 27 Oct 2021 at 02:36, Ilias Apalodimas
> wrote:
> >
> > Hi Simon,
> >
> > On Sun, 24 Oct 2021 at 02:27, Simon Glass wrote:
> > >
> > > Add a bootmeth driver which handles EFI boot, using EFI_LOADER.
François Ozog writes:
> Hi Simon
>
> The only place I could agree with this file presence is in the documentation
> directory, not in dts. It creates a mental picture for the reader
> an entirely bad mind scheme around Qemu and DT.
>
> And even in a documentation directory I would place a
On Wed, Oct 27, 2021 at 4:04 PM Pali Rohár wrote:
>
> On Wednesday 27 October 2021 12:08:13 Robert Marko wrote:
> > Globalscale MOCHAbin is a Armada 7040 based development board.
> >
> > Specifications:
> > * Armada 7040 Quad core ARMv8 Cortex A-72 @ 1.4GHz
> > * 2 / 4 / 8 GB of DDR4 DRAM
> > *
1 - 100 of 177 matches
Mail list logo
