The current short description has a typo. Let it stand out clear that we
provide unit tests.
Improve the description of the CMD_BOOTEFI_SELFTEST configuration option.
Signed-off-by: Heinrich Schuchardt
---
lib/efi_selftest/Kconfig | 8
1 file changed, 4 insertions(+), 4 deletions(-)
d
Add gcc-8.1.0 support to buildman toolchain.
The old gcc-7.3.0 has shared libraries issues on Ubuntu 18.04 and 19.04.
Signed-off-by: Thomas Chou
---
tools/buildman/toolchain.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/buildman/toolchain.py b/tools/buildman/toolc
Add gcc-8.1.0 support to buildman toolchain.
The old gcc-7.3.0 has shared libraries issues on Ubuntu 18.04LTS and
19.04.
Though both 7.3.0 and 8.1.0 have arc and nds32 compilers, the following
errors were generated on Ubuntu 19.04.
arc: + iot_devkit
It is perfectly fine for the read(2) syscall to return with less than
the requested number of bytes read (short read, see the "RETURN VALUE"
section of the man page). This typically happens with slow input
(keyboard, network) or with complex pipes.
So far mkenvimage expects the exact number of req
At the moment mkenvimage has two separate read paths: One to read from
a potential pipe, while dynamically increasing the buffer size, and a
second one using mmap(2), using the input file's size. This is
problematic for two reasons:
- The "pipe" path will be chosen if the input filename is missing
This fixes two issues I had when trying to create an envimage from a
more complex pipe:
- The read process stops when the read(2) syscall returns less bytes
than requested.
- Specifying an input filename expects this to be a regular file.
See the respective commit messages for more details.
Tha
On 30/06/2019 00:03, Marek Vasut wrote:
Marek,
you seem to be quite defensive in your answer, but I was just talking
against merging ATF into U-Boot, not against U-Boot - I think we agree
on this. I don't think there is much of a point in comparing ATF and
U-Boot, as the two do not compete agains
On 6/29/19 8:49 PM, André Przywara wrote:
> On 29/06/2019 16:02, Jagan Teki wrote:
>> In terms of code maintenance and development feasibility it is always
>> a better approach to have out-of-tree code or binary to be part of
>> in-house source tree.
>
> I am not sure this is really true. If I get
Hi Guys,
I have just built a u-boot.bin for rpi_3_32b_defconfig using all the
defaults. I then used this on the new Raspbian Buster image that was
released a few days ago i.e. 2019-06-20-raspbian-buster-lite.zip.
This same u-boot.bin works fine on the old Raspbian Stretch version (
2019-04-08-ra
On 29/06/2019 16:02, Jagan Teki wrote:
> In terms of code maintenance and development feasibility it is always
> a better approach to have out-of-tree code or binary to be part of
> in-house source tree.
I am not sure this is really true. If I get you right, you want to
mirror and sync the ATF sou
On 6/29/19 5:02 PM, Jagan Teki wrote:
> In terms of code maintenance and development feasibility it is always
> a better approach to have out-of-tree code or binary to be part of
> in-house source tree.
You are free to do so locally, but following this train of thought would
possibly lead to putti
Hello Leif,
the Wandboard Quad rev B1 cannot be booted via U-Boot, GRUB-efi-arm.
GRUB loads the initial ramdisk into an area which the the mainline
4.19.55 kernel simply does not accept because it thinks the minimum
address is 0x6800 and not 0x1000. Booting via bootz works
without problem
Hi Park
On Wed, Jun 19, 2019 at 7:26 PM Park, Aiden wrote:
>
> Hi Bin,
>
> Thanks for asking about Slim Bootloader.
> It is an open-source boot firmware(BSD-2-Clause-Patent license) and one of
> UEFI BIOS alternatives like coreboot and bare-metal u-boot. Slim Bootloader
> is leveraging EDK2 fra
On Sat, Jun 29, 2019 at 5:30 PM Mark Kettenis wrote:
>
> Ever since the dts files were synchronized in commit 0a09f2f1173d
> ("rockchip: Adjust rk3399 device tree to be closer to linux") USB3
> support on Rockchip RK3399 boards has been broken.
>
> This series restores the functionality by adoptin
> From: Jagan Teki
> Date: Sat, 29 Jun 2019 20:32:00 +0530
>
> In terms of code maintenance and development feasibility it is always
> a better approach to have out-of-tree code or binary to be part of
> in-house source tree.
I disagree. This strategy often leads to diverging codebases where
lo
Remove RK3399 compatible strings as this driver is no longer
used on that SoC.
Signed-off-by: Mark Kettenis
---
drivers/usb/host/xhci-rockchip.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/usb/host/xhci-rockchip.c b/drivers/usb/host/xhci-rockchip.c
index f19bea3a91..e7b0dbcca5 1
Configure USB2 PHY register based on "phy_type" property and
handle all the quirks that are relevant for Rockchip RK3399 SoCs.
Signed-off-by: Mark Kettenis
---
drivers/usb/host/xhci-dwc3.c | 20
1 file changed, 20 insertions(+)
diff --git a/drivers/usb/host/xhci-dwc3.c b/dr
Add compatible string for RK3399 and enable it by default on
Rockchip platforms with USB3 support.
Signed-off-by: Mark Kettenis
---
drivers/usb/host/Kconfig | 1 +
drivers/usb/host/dwc3-of-simple.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/usb/host/Kconfig b/drivers/
The "simple" OF glue layer for the Designware USB3 core enables
all refernced clocks. These need to be need to be implemented
otherwise the driver fails to probe. A dummy implementation
that simply returns success is sufficient since the RK3399 comes
out of reset with all clock gates open.
Signe
Ever since the dts files were synchronized in commit 0a09f2f1173d
("rockchip: Adjust rk3399 device tree to be closer to linux") USB3
support on Rockchip RK3399 boards has been broken.
This series restores the functionality by adopting the dwc3-of-simple
glue driver.
Mark Kettenis (4):
rockchip:
Hello u-boot community,
I am working on a custom board with a LCD from FTDI ( FT81x graphics
controller). I have a lot of examples from applicaition layer and its
working from linux. However, i want to display a logo upon startup and i
want to do it in the bootloader. I am using the 2018.05 versio
In terms of code maintenance and development feasibility it is always
a better approach to have out-of-tree code or binary to be part of
in-house source tree.
This is what exactly it was done for SPL, if I'm not wrong. So can we
do the same thing for ATF on ARM64 SoCs?
We are using ATF (on Allwin
Hi Eugen,
On Tue, Jun 25, 2019 at 9:10 PM Jagan Teki wrote:
>
> On Tue, Jun 25, 2019 at 5:05 PM wrote:
> >
> > Hello Jagan,
> >
> > I can only take these patches through u-boot-atmel tree if you
> > Ack/Review them.
> > Otherwise you can consider taking them through u-boot-spi ?
>
> I would need
On Tue, Jun 18, 2019 at 2:21 PM wrote:
>
> From: Tudor Ambarus
>
> Describe the DT bindings for the driver of the Atmel QSPI
> controller. Taken form linux v5.1-rc5.
>
> Signed-off-by: Tudor Ambarus
> ---
> v5: no change
> v4: no change
> v3: no change
> v2: no change
>
> doc/device-tree-bindin
On Tue, Jun 18, 2019 at 2:22 PM wrote:
>
> From: Tudor Ambarus
>
> Add the default config file of QSPI media. The config is based on
> sama5d27_som1_ek_mmc_defconfig.
>
> Signed-off-by: Tudor Ambarus
> ---
> v5: no change
> v4: no change
> v3: fix the following:
> ./tools/genboardscfg.py
> WARNI
On Tue, Jun 18, 2019 at 2:22 PM wrote:
>
> From: Tudor Ambarus
>
> Add the default config file of QSPI media. The config is based on
> sama5d2_xplained_mmc_defconfig.
>
> Signed-off-by: Tudor Ambarus
> ---
On Tue, Jun 18, 2019 at 2:22 PM wrote:
>
> From: Tudor Ambarus
>
> We use a sst spi-nor
On Tue, Jun 18, 2019 at 2:22 PM wrote:
>
> From: Cyrille Pitchen
>
> Fix the following:
> - use "jedec,spi-nor" binding, we use jedec compatible flashes
> - set bus width to 4, we use quad capable flashes
> - differentiate bewteen data and clk and cs pins
> - drop partions as we don't use them in
On Tue, Jun 18, 2019 at 2:22 PM wrote:
>
> From: Tudor Ambarus
>
> We use a sst spi-nor flash memory on sama5d27_som1_ek. Select
> the others for testing purposes.
>
> Signed-off-by: Tudor Ambarus
> ---
> v5: no change
> v4: no change
> v3: no change
> v2: new patch
>
> configs/sama5d27_som1_ek
On Tue, Jun 18, 2019 at 2:21 PM wrote:
>
> From: Tudor Ambarus
>
> We have a macronix spi-nor flash on sama5d2_xplained RevB and
> a sst spi-nor flash on RevC. Select the rest for testing purposes.
>
> Signed-off-by: Tudor Ambarus
> ---
> v5: no change
> v4: no change
> v3: no change
> v2: new p
On Tue, Jun 18, 2019 at 2:21 PM wrote:
>
> From: Tudor Ambarus
>
> Backport the driver from linux v5.1-rc5 and adapt it for u-boot.
> Tested on sama5d2_xplained Rev B with mx25l25635e spi-nor flash.
>
> Signed-off-by: Tudor Ambarus
> ---
Reviewed-by: Jagan Teki
Hi Tom,
Please pull some updates before the release.
All of them are trivial enough.
Thanks.
The following changes since commit 69492fb4c56d82142e0312474369d8da97d5182d:
ARM: uniphier: move sg_set_{pinsel, iectrl} to more relevant places
(2019-06-29 22:31:18 +0900)
are available in the Git r
The following changes since commit 0352e878d2b80b2575e02310e891e936251b3992:
Merge tag 'u-boot-imx-20190628' of
https://gitlab.denx.de/u-boot/custodians/u-boot-imx (2019-06-28 08:00:22
-0400)
are available in the Git repository at:
https://gitlab.denx.de/u-boot/custodians/u-boot-efi
tags/ef
this patch adds basic changes for adding a erase-subcommand to env
with this command the environment stored on non-volatile storage written
by saveenv can be cleared.
Signed-off-by: Frank Wunderlich
squashed fixes
- start message with "Erasing"
- mark erase-function as optional
- env: separa
sometimes it is needed to erase the non-volatile environment
e.g. for boot-up with builtin-environment or after resizing env
this series add basic functionality for erasing environment from
storage as a first storage-driver mmc is introduced, other needs to be added
later
changes since v6:
- fix
this adds erase environment for mmc storage
squashed fixes:
- add CONFIG_CMD_ERASEENV
- env: erase redundant offset if defined
- changes mentioned by Simon
- fix whitespaces around errmsg
Suggested-by: Simon Goldschmidt
Signed-off-by: Frank Wunderlich
---
env/mmc.c | 51 +++
Hi Frank,
On 29.06.19 10:44, Frank Wunderlich wrote:
Hi Stefan/Tom
this Patch in combination with https://patchwork.ozlabs.org/patch/1113120/
This one already is applied in mainline:
https://gitlab.denx.de/u-boot/u-boot/commit/2bc1821e8662f9ed67cc6eeb680148bb5c148379
Even though the coding
Hi Stefan/Tom
this Patch in combination with https://patchwork.ozlabs.org/patch/1113120/ seem
to fix issues on bananapi-r2 /mt7623 (bootloop/hang on WDT servicing) if
CONFIG_WATCHDOG is not set to "n" (else it will be set to y because of new
"imply WATCHDOG" inside of "config WDT").
@tom can y
Cc'ing a few people
On 16.05.19 11:19, Weijie Gao wrote:
The initr_watchdog is currently placed before initr_serial. The
initr_watchdog calls printf and printf finally calls ops->putc of a serial
driver.
However, gd->cur_serial_dev points to a udevice allocated in board_f. The
gd->cur_serial_de
This patch removes SiFive SPI driver and MMC SPI drive from the TODO
list in SiFive FU540 README.
Signed-off-by: Anup Patel
---
doc/README.sifive-fu540 | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/doc/README.sifive-fu540 b/doc/README.sifive-fu540
index 33e03dc861..944ba
39 matches
Mail list logo
