On Wed, Feb 05, 2020 at 06:13:51AM +, Priyanka Jain wrote:
> Dear Tom,
>
> Please find my pull-request for u-boot-fsl-qoriq/master
> https://travis-ci.org/p-priyanka-jain/u-boot/builds/645892188
>
> Summary
> Bug fixes on ls1012a, ls1021a, ls1028ardb platforms
> Integrate fspi for ls1028a ,
On 2/5/20 7:10 AM, Simon Glass wrote:
Hi Tom,
On Wed, 4 Dec 2019 at 15:30, Tom Rini wrote:
On Fri, Nov 29, 2019 at 09:23:43PM -0700, Simon Glass wrote:
Hi Tom,
I have been meaning to have a crack at setting up a little hardware
lab for a while.
I made some progress recently and hooked up
Hello Bin,
> -Original Message-
> From: Bin Meng
> Sent: Tuesday, February 4, 2020 5:21 PM
> To: Sagar Kadam
> Cc: U-Boot Mailing List ; Rick Chen
> ; Paul Walmsley ( Sifive) ;
> Jagan Teki ; Anup Patel
>
> Subject: Re: [U-Boot Patch v2 0/4] Fix currently available support for flash
>
Hi Rasmus,
On Tue, 4 Feb 2020 at 18:08, Rasmus Villemoes
wrote:
>
> Currently, there's no way to fetch the value of an environment
> variable whose name is stored in some other variable, or generated from
> such - in non-working pseudo-code,
>
> ${${varname}}
> ${array${index}}
>
> This
Hi Schrempf,
On Wed, 5 Feb 2020 at 08:12, Schrempf Frieder
wrote:
>
> From: Frieder Schrempf
>
> In order to auto-select an option from the pxe boot menu, that
> matches the detected board, we check the board model string in the
> devicetree and set the default menu selection, if it matches the
On Tue, 4 Feb 2020 at 23:21, Heiko Schocher wrote:
>
> dm_gpio_lookup_name() searches for a gpio through
> the bank name. But we have also gpio labels, and it
> makes sense to search for a gpio also in the labels
> we have defined, if no gpio is found through the
> bank name definition.
>
> This
On Tue, 4 Feb 2020 at 23:20, Heiko Schocher wrote:
>
> currently gpio hog function is not tested with "ut dm gpio"
> so add some basic tests for gpio hog functionality.
>
> For this enable GPIO_HOG in sandbox_defconfig, add
> in DTS some gpio hog entries, and add testcase in
> "ut dm gpio"
Hi Schrempf,
On Wed, 5 Feb 2020 at 08:12, Schrempf Frieder
wrote:
>
> From: Frieder Schrempf
>
> In order to make it possible to auto select a default entry by
> matching the data of the menu entries by an external matching
> function, we add some helpers and expose the
>
On Tue, 4 Feb 2020 at 17:16, Simon Glass wrote:
>
> ]Hi Thirupathaiah,
>
> On Tue, 4 Feb 2020 at 10:09, Thirupathaiah Annapureddy
> wrote:
> >
> > Thank You Simon for the review.
> >
> > May I know what are the next steps in making forward progress on this?
>
> The patch is in my queue but I've
L_PRESENT */
>
> So, as OF_CONTROL is defined for me, the flag "u-boot,dm-pre-reloc" seems
> not working anymore ...
>
> Adding this back:
>
> hs@xmglap:u-boot-secu [20200205-temp] $ git diff
> diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c
> ind
Currently the size of pci_addr_t and pci_size_t depends on
CONFIG_SYS_PCI_64BIT. For qemu_arm64_defconfig with 4 GiB RAM this leads
to an error
pci_hose_phys_to_bus: invalid physical address
which is due to the truncation of the bus address in _dm_pci_phys_to_bus.
Defining
Hi Anatolij,
On Wed, Feb 5, 2020 at 2:00 PM Anatolij Gustschin wrote:
> I tried to extend the BMP code to fix this, but my testing with
> sandbox SDL end of last week has shown incorrect colors in 24bpp
> mode, and I didn't find the reason for it. I do not see what is
> wrong in the code, maybe
On 2/5/20 9:05 PM, Simon Glass wrote:
Hi Heinrich,
On Wed, 5 Feb 2020 at 12:07, Heinrich Schuchardt wrote:
Currently the size of pci_addr_t and pci_size_t depends on
CONFIG_SYS_PCI_64BIT. For qemu_arm64_defconfig with 4 GiB RAM this leads
to an error
pci_hose_phys_to_bus: invalid
Currently the size of pci_addr_t and pci_size_t depends on
CONFIG_SYS_PCI_64BIT. For qemu_arm64_defconfig with 4 GiB RAM this leads
to an error
pci_hose_phys_to_bus: invalid physical address
which is due to the truncation of the bus address in _dm_pci_phys_to_bus.
Defining
These functions do not modify the device so should use a const pointer to
it. Update the code accordingly.
Signed-off-by: Simon Glass
---
drivers/core/read.c | 97 +++--
include/dm/read.h | 205 +++-
2 files changed, 159 insertions(+),
These functions do not modify the device so should use a const pointer to
it. Update the code accordingly.
Signed-off-by: Simon Glass
---
drivers/core/fdtaddr.c | 26 +-
include/dm/fdtaddr.h | 26 +-
2 files changed, 26 insertions(+), 26
Hi Bin,
On Mon, 3 Feb 2020 at 21:52, Bin Meng wrote:
>
> Hi Simon,
>
> On Tue, Feb 4, 2020 at 1:15 AM Simon Glass wrote:
> >
> > Hi Bin,
> >
> > On Mon, 3 Feb 2020 at 10:10, Bin Meng wrote:
> > >
> > > Hi Simon,
> > >
> > > On Tue, Feb 4, 2020 at 12:20 AM Simon Glass wrote:
> > > >
> > > > Hi
Hi Vignesh,
On Tue, 4 Feb 2020 at 00:58, Vignesh Raghavendra wrote:
>
> Faiz,
>
> On 31/01/20 11:44 pm, Simon Glass wrote:
> > Hi Vignesh,
> >
> > On Thu, 30 Jan 2020 at 22:12, Vignesh Raghavendra wrote:
> >>
> >> Hi Simon,
> >>
> >> On 31/01/20 7:57 am, Simon Glass wrote:
> >>> Hi Faiz,
> >>>
Hi Sean,
On Mon, 3 Feb 2020 at 13:51, Sean Anderson wrote:
>
> This adds a subcommand to dm to dump out what drivers are installed, and their
> compatible strings. I have found this useful in ensuring that I have the
> correct
> drivers compiled, and that I have put in the correct compatible
On Wed, Feb 05, 2020 at 10:33:18AM +0100, Matthias Brugger wrote:
> Hi Tom,
>
> Please take into account the following commits for RPi boards.
>
> It includes support for DFU on RPi4 as well as network support on that board.
>
> You can find the CI output here:
>
On 2/4/20 7:03 PM, Simon Glass wrote:
Now that we have uclass_first_device_drvdata(), use it from the I2C driver
to reduce code duplication.
Acked-by: Stephen Warren
On Wed, 5 Feb 2020 at 13:59, Heinrich Schuchardt wrote:
>
> Currently the size of pci_addr_t and pci_size_t depends on
> CONFIG_SYS_PCI_64BIT. For qemu_arm64_defconfig with 4 GiB RAM this leads
> to an error
>
> pci_hose_phys_to_bus: invalid physical address
>
> which is due to the truncation
Hi Anatolij,
On Wed, Feb 5, 2020 at 1:50 PM Anatolij Gustschin wrote:
>
> Before DM_VIDEO conversion this board used 24bpp
> display configuration, so use it again.
>
> Signed-off-by: Anatolij Gustschin
> ---
> arch/arm/dts/imx6ul-14x14-evk-u-boot.dtsi | 2 +-
> 1 file changed, 1 insertion(+),
Hello Bin,
> -Original Message-
> From: Bin Meng
> Sent: Tuesday, February 4, 2020 5:43 PM
> To: Sagar Kadam
> Cc: U-Boot Mailing List ; Rick Chen
> ; Paul Walmsley ( Sifive) ;
> Jagan Teki ; Anup Patel
>
> Subject: Re: [U-Boot Patch v2 1/4] fu540: dtsi: spi: add num-cs info to device
On Mon, Feb 3, 2020 at 5:48 AM Jon Nettleton wrote:
> I have a working port of the Linux usb phy driver for the iMX8MQ
> already. I think the only piece that is missing to use dwc3-generic
> for iMX8MQ is the common clk driver. Has anyone started work on this?
Not that I am aware of.
Peng,
When recording the console output for testing it is useful to be able to
read the output a line at a time to check that the output is correct. Also
we need to check that we get to the end of the output.
Add a console function to return the next line and another to see how must
data is left.
At present we reset the console buffer before each test but do not
actually set the recording flag. Without this, the output is not
recorded.
Update the code to set the flag before the test and clear it afterwards.
Signed-off-by: Simon Glass
---
test/dm/test-main.c | 4 ++--
1 file changed, 2
On Wed, 29 Jan 2020 at 10:45, Fabio Estevam wrote:
>
> Following the recommendation of adding '#define DEBUG' at the top
> of drivers/core/lists.c does not cause the debug messages to be
> shown. Change it to '#define LOG_DEBUG' instead, which actually
> makes it work as per doc/README.log.
>
>
On Tue, 28 Jan 2020 10:07:18 -0700
Simon Glass wrote:
Hi Simon,
> On Sat, 25 Jan 2020 at 16:18, André Przywara wrote:
> >
> > On 25/01/2020 16:20, Tom Rini wrote:
> >
> > Hi Tom,
> >
> > thanks for having a look!
> >
> >
> > > On Tue, Jan 21, 2020 at 10:23:17AM +, Andre Przywara wrote:
> >
Hi Thirupathaiah,
On Tue, 4 Feb 2020 at 10:08, Thirupathaiah Annapureddy
wrote:
>
> Hi All,
>
> May I know what are the next steps in making forward progress on this?
Can you please add a test for this? We need a sandbox driver of some
sort - see the existing sandbox TPM driver.
Regards,
Simon
On Fri, 17 Jan 2020 at 02:53, wrote:
>
> From: Matthias Brugger
>
> At kernel.org aarch64 toolchains are published in folder
> arm64. Fix the URL for that case, so that we can fetch
> toolchains on aarch64 machines.
>
> Signed-off-by: Matthias Brugger
>
> ---
>
> tools/buildman/toolchain.py |
Tidy up a few places where const * should be used.
Signed-off-by: Simon Glass
---
drivers/pci/pci-uclass.c | 18 +-
include/fdtdec.h | 2 +-
include/pci.h| 16
lib/fdtdec.c | 2 +-
4 files changed, 19 insertions(+), 19
Update this header file to use const devices where possible, to permit
callers to also use const.
Signed-off-by: Simon Glass
---
drivers/core/device.c | 27 ++-
include/dm/device.h | 30 --
include/dm/read.h | 4 ++--
3 files changed,
Hi Heinrich,
On Wed, 5 Feb 2020 at 12:07, Heinrich Schuchardt wrote:
>
> Currently the size of pci_addr_t and pci_size_t depends on
> CONFIG_SYS_PCI_64BIT. For qemu_arm64_defconfig with 4 GiB RAM this leads
> to an error
>
> pci_hose_phys_to_bus: invalid physical address
>
> which is due to
On Mon, 3 Feb 2020 at 10:12, Michael Walle wrote:
>
> If there are aliases for an uclass, set the base for the "dynamically"
> allocated numbers next to the highest alias.
>
> Please note, that this might lead to holes in the sequences, depending
> on the device tree. For example if there is only
Hi Heinrich,
On Wed, 5 Feb 2020 at 13:18, Heinrich Schuchardt wrote:
>
>
>
> On 2/5/20 9:05 PM, Simon Glass wrote:
> > Hi Heinrich,
> >
> > On Wed, 5 Feb 2020 at 12:07, Heinrich Schuchardt wrote:
> >>
> >> Currently the size of pci_addr_t and pci_size_t depends on
> >> CONFIG_SYS_PCI_64BIT. For
On Sat, Jan 11, 2020 at 1:32 AM Sean Anderson wrote:
>
> If CONFIG_CMDLINE=n, common/cli.c calls board_run_command. This fails to
> link on most architectures. However, the sandbox architecture has an
> implementation which we can use.
>
> Signed-off-by: Sean Anderson
> ---
> Changes for v2:
>
Hi Bin
> Hi Rick,
>
> When going through all patches in the RISC-V queue, I found this old
> patch was not applied. Is it still needed?
It is unnecessary now.
>
> Anyway, see my review comments below.
Thanks for your review!
Thanks
Rick
>
> On Mon, Oct 8, 2018 at 1:43 PM Andes wrote:
> >
>
I am not sure how to add libsdl2-dev to the gitlab image, so disable
building sandbox with SDL for now.
Signed-off-by: Simon Glass
---
Changes in v2: None
.gitlab-ci.yml | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
Applied to u-boot-dm, thanks!
> Subject: Re: [PATCH v2 1/4] clock_imx8mq: Delete not used init_usb_clk()
>
> On Mon, Feb 3, 2020 at 5:48 AM Jon Nettleton wrote:
>
> > I have a working port of the Linux usb phy driver for the iMX8MQ
> > already. I think the only piece that is missing to use dwc3-generic
> > for iMX8MQ is
> From: Masahiro Yamada [mailto:yamada.masah...@socionext.com]
> Sent: Tuesday, February 04, 2020 7:09 PM
> To: u-boot@lists.denx.de
> Cc: Masahiro Yamada; Bin Meng; Rick Jian-Zhi Chen(陳建志); Simon Glass
> Subject: [PATCH 1/9] dma-mapping: fix the prototype of dma_map_single()
>
> Make
> From: Masahiro Yamada [mailto:yamada.masah...@socionext.com]
> Sent: Tuesday, February 04, 2020 7:09 PM
> To: u-boot@lists.denx.de
> Cc: Masahiro Yamada; Bin Meng; Joe Hershberger; Lukasz Majewski; Marek Vasut;
> Peng Fan; Rick Jian-Zhi Chen(陳建志); Simon Glass
> Subject: [PATCH 2/9] dma-mapping:
The following changes since commit d4827fcd4c1b04c338e4019e412f495aa4231d24:
Merge https://gitlab.denx.de/u-boot/custodians/u-boot-x86 (2020-02-04
11:36:49 -0500)
are available in the Git repository at:
https://gitlab.denx.de/u-boot/custodians/u-boot-efi.git
tags/efi-2020-04-rc2
for you
> -Original Message-
> From: Peng Fan
> Sent: Wednesday, February 5, 2020 3:08 PM
> To: Rasmus Villemoes ; u-boot@lists.denx.de;
> Y.b. Lu
> Cc: Mario Six
> Subject: RE: [PATCH] mmc: fsl_esdhc: actually enable cache snooping on
> mpc830x
>
> > Subject: [PATCH] mmc: fsl_esdhc: actually
t; seems
not working anymore ...
Adding this back:
hs@xmglap:u-boot-secu [20200205-temp] $ git diff
diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c
index 9851663dc5..386ca9cffa 100644
--- a/drivers/serial/ns16550.c
+++ b/drivers/serial/ns16550.c
@@ -528,7 +528,7 @@ U_BOOT_D
On Wed, Feb 5, 2020 at 10:04 AM Simon Glass wrote:
>
> H1 is a Google security chip present in recent Chromebooks, Pixel phones
> and other devices. Cr50 is the name of the software that runs on H1 in
> Chromebooks.
>
> This chip is used to handle TPM-like functionality and also has quite a
> few
On Tue, Feb 4, 2020 at 4:21 PM Bin Meng wrote:
>
> On Tue, Feb 4, 2020 at 4:04 PM Wolfgang Wallner
> wrote:
> >
> > The Primary to Sideband Bridge (P2SB) is not specific to Apollo Lake, so
> > move its driver to a common location within arch/x86.
> >
> > Signed-off-by: Wolfgang Wallner
> >
> >
Hi Stephen,
On Wed, 5 Feb 2020 at 11:21, Stephen Warren wrote:
>
> On 2/5/20 7:10 AM, Simon Glass wrote:
> > Hi Tom,
> >
> > On Wed, 4 Dec 2019 at 15:30, Tom Rini wrote:
> >>
> >> On Fri, Nov 29, 2019 at 09:23:43PM -0700, Simon Glass wrote:
> >>
> >>> Hi Tom,
> >>>
> >>> I have been meaning to
Hi Simon,
On Wed, Feb 5, 2020 at 10:03 AM Simon Glass wrote:
>
> This series adds a driver for the Cr50 security chip and enables it on
> coral. This supports the 'tpm' command.
>
> In order to make this work a few other changes are included:
> - Additional UCLASS_IRQ operations to support
Hi Rick,
On Thu, Feb 6, 2020 at 9:41 AM Rick Chen wrote:
>
> Hi Bin
>
> > Hi Rick,
> >
> > When going through all patches in the RISC-V queue, I found this old
> > patch was not applied. Is it still needed?
>
> It is unnecessary now.
Thanks. I updated the patch status on patchwork.
>
> >
> >
Hi Fabio,
On Mon, 3 Feb 2020 12:15:09 -0300
Fabio Estevam feste...@gmail.com wrote:
> Hi Anatolij,
>
> On Sat, Jan 25, 2020 at 3:36 PM Anatolij Gustschin wrote:
>
> > Before DM_VIDEO conversion cfb_console driver was used and
> > it supports such rendering. I'm working on a fix for this.
> >
.flags = DM_FLAG_PRE_RELOC,
+#endif
};
#endif
#endif /* SERIAL_PRESENT */
So, as OF_CONTROL is defined for me, the flag "u-boot,dm-pre-reloc" seems
not working anymore ...
Adding this back:
hs@xmglap:u-boot-secu [20200205-temp] $ git diff
diff --git a/drivers/serial/ns16550.c b/dr
Hi Tom,
Please take into account the following commits for RPi boards.
It includes support for DFU on RPi4 as well as network support on that board.
You can find the CI output here:
https://gitlab.denx.de/u-boot/custodians/u-boot-raspberrypi/pipelines/2065
and here
On 04/02/20 12:06 PM, Keerthy wrote:
> This patch series enables mcu_r5fss0_core0 & main_r5fss0_core0.
> Tested for firmware loading and execution on J721e.
I still see build error with multiple imx boards:
===
arm: + mx7dsabresd_qspi
Timid reminder...
Is there any reason why these could *not* get into mainline?
These work for me, should I add a "tested-by" annotation?
Many Thanks
Mauro
On 1/30/20 3:28 PM, Mauro Condarelli wrote:
> Hi,
> I would like to have a tentative time frame for inclusion
> of Wiijie Gao "Refactor the
> u-boot@lists.denx.de
> Subject: RE: [v8 1/8] rtc: pcf8563: Add driver model support
>
> >-Original Message-
> >From: Biwen Li
> >Sent: Wednesday, February 5, 2020 7:39 AM
> >To: Biwen Li ; Jagdish Gediya
> >; Priyanka Jain ;
> >h...@denx.de; ja...@amarulasolutions.com;
On 2/5/20 8:43 AM, Ard Biesheuvel wrote:
On Wed, 5 Feb 2020 at 05:53, Heinrich Schuchardt wrote:
RISC-V booting currently is based on a per boot stage lottery to determine
the active CPU. The Hart State Management (HSM) SBI extension replaces
this lottery by using a dedicated primary CPU.
Hello Daniel, hello Leif,
what is the GRUB view on this discussion?
Best regards
Heinrich
On 2/5/20 12:32 PM, Heinrich Schuchardt wrote:
On 2/5/20 8:43 AM, Ard Biesheuvel wrote:
On Wed, 5 Feb 2020 at 05:53, Heinrich Schuchardt
wrote:
RISC-V booting currently is based on a per boot stage
From: Frieder Schrempf
The current implementation in arch/arm/mach-imx/cpu.c uses non-DM
code to retrieve the core clock frequency. As the root clock is not
listed we currently get:
CPU: Freescale i.MX8MMQ rev1.0 at 0 MHz
Fix this by adding the missing entry, which results in:
CPU:
On 24/01/20 5:33 PM, Keerthy wrote:
>
>
> On 23/01/20 10:49 pm, Keerthy wrote:
>>
>>
>> On 23/01/20 10:35 pm, Andrew F. Davis wrote:
>>> On 1/23/20 11:44 AM, Keerthy wrote:
On 23/01/20 6:54 pm, Andrew F. Davis wrote:
> On 1/22/20 11:10 PM, Keerthy wrote:
>>
>>
On Tue, Feb 4, 2020 at 10:52 PM Igor Opaniuk wrote:
>
> From: Igor Opaniuk
>
> Remove 'fdt_high' and 'initrd_high' environment variables (set to 0x)
> from default environment which prevents relocation of FDT and initrd.
> Rely on 'bootm_size' value instead to safely relocate kernel,
On Tue, Feb 4, 2020 at 10:52 PM Igor Opaniuk wrote:
>
> From: Igor Opaniuk
>
> Remove 'fdt_high' and 'initrd_high' environment variables (set to 0x)
> from default environment which prevents relocation of FDT and initrd.
> Rely on 'bootm_size' value instead to safely relocate kernel,
On Tue, Feb 4, 2020 at 10:52 PM Igor Opaniuk wrote:
>
> From: Igor Opaniuk
>
> Remove 'fdt_high' and 'initrd_high' environment variables (set to 0x)
> from default environment which prevents relocation of FDT and initrd.
> Rely on 'bootm_size' value instead to safely relocate kernel,
Hi Baruch,
Thanks for your comments. My replay below.
On 4/2/20 10:41, Baruch Siach wrote:
Hi Walter,
Thanks for the patch.
One comment below.
On Wed, Jan 29, 2020 at 10:58:07AM -0300, Walter Lozano wrote:
Make an additional step to add full DM support to mx6cuboxi, including its
support
Hi Bin,
Bin Meng 於 2020年2月4日 週二 下午11:50寫道：
>
> On Thu, Jun 6, 2019 at 5:06 PM Eric Lin wrote:
> >
> > This patch adds Kconfig entries for the F (Single-Precision)
> > and D (Double-Precision) floating point instruction-set extensions.
> >
> > Signed-off-by: Eric Lin
> > ---
> > Changes for v2:
On Sat, Feb 1, 2020 at 8:55 AM Heinrich Schuchardt wrote:
>
> RISC-V patches are developed for OpenSBI and Linux to replace random boot
> by sequential CPU bring-up.
>
> In this scenario the id of the active hart has to be passed from boot stage
> to boot stage. Using a UEFI variable would
Hello,
I am using a Linux evaluation board MBa6x with the TQMa6x module. The system is
configured in order to boot from eMMC. I would like to use the tool fw_printenv
and get following result:
fw_printenv
Warning: Bad CRC, using default environment
bootargs=
bootcmd=
bootdelay=2
Hi Bin,
On Tue, 4 Feb 2020 at 02:08, Bin Meng wrote:
>
> On Tue, Feb 4, 2020 at 8:20 AM Simon Glass wrote:
> >
> > ACPI GPEs are used to signal interrupts from peripherals that are accessed
> > via ACPI. In U-Boot these are modelled as interrupts using a separate
> > interrupt controller.
Hi Frieder,
On Wed, Feb 5, 2020 at 8:45 AM Schrempf Frieder
wrote:
>
> From: Frieder Schrempf
>
> The current implementation in arch/arm/mach-imx/cpu.c uses non-DM
> code to retrieve the core clock frequency. As the root clock is not
> listed we currently get:
>
> CPU: Freescale i.MX8MMQ
On Wed, 5 Feb 2020 10:09:40 +
Robert Varga robert.va...@getinge.com wrote:
...
> The content of /etc/fw_env.config is as follows:
> cat /etc/fw_env.config
> # Configuration file for fw_(printenv/setenv) utility.
> # Up to two entries are valid, in this case the redundant
> # environment sector
On Tue, Feb 4, 2020 at 10:52 PM Igor Opaniuk wrote:
>
> From: Igor Opaniuk
>
> Remove 'fdt_high' and 'initrd_high' environment variables (set to 0x)
> from default environment which prevents relocation of FDT and initrd.
> Rely on 'bootm_size' value instead to safely relocate kernel,
On Tue, Feb 4, 2020 at 10:52 PM Igor Opaniuk wrote:
>
> From: Igor Opaniuk
>
> Remove 'fdt_high' and 'initrd_high' environment variables (set to 0x)
> from default environment which prevents relocation of FDT and initrd.
> Rely on 'bootm_size' value instead to safely relocate kernel,
On Tue, Feb 4, 2020 at 10:52 PM Igor Opaniuk wrote:
>
> From: Igor Opaniuk
>
> Remove 'fdt_high' and 'initrd_high' environment variables (set to 0x)
> from default environment which prevents relocation of FDT and initrd.
> Rely on 'bootm_size' value instead to safely relocate kernel,
Hi Simon,
On 30.12.19 02:21, Simon Glass wrote:
> Hi Schrempf,
>
> On Tue, 10 Dec 2019 at 08:47, Schrempf Frieder
> wrote:
>>
>> From: Frieder Schrempf
>>
>> In order to iterate over the menu entries and match for a specific
>> name in the pxe boot, we need to properly export the needed
This supports i2c DM and enables CONFIG_DM_I2C
for SoC LS1043A
Reviewed-by: Priyanka Jain
Signed-off-by: Biwen Li
---
Changes in RESEND v8:
- fix build warning
Changes in v8:
- none
Changes in v7:
- none
Changes in v6:
- correct dependencies
Changes in v5:
This supports i2c DM and enables CONFIG_DM_I2C
for SoC LS1046A
Reviewed-by: Priyanka Jain
Signed-off-by: Biwen Li
---
Changes in RESEND v8:
- fix build warning
Changes in v8:
- none
Changes in v7:
- none
Changes in v6:
- correct dependencies
Changes in v5:
Hi Tom,
On Wed, 4 Dec 2019 at 15:30, Tom Rini wrote:
>
> On Fri, Nov 29, 2019 at 09:23:43PM -0700, Simon Glass wrote:
>
> > Hi Tom,
> >
> > I have been meaning to have a crack at setting up a little hardware
> > lab for a while.
> >
> > I made some progress recently and hooked up a rpi_3 with
On Wed, Feb 05, 2020 at 03:51:42PM +, Oliver Graute wrote:
> Remove 'fdt_high' and 'initrd_high' environment variables (set to 0x)
> from default environment which prevents relocation of FDT and initrd.
>
> Signed-off-by: Oliver Graute
> Cc: Stefano Babic
> Cc: Fabio Estevam
> Cc:
Hi Anatolij,
Thank you very much for solving the problem. After commenting out the line
within /etc/fw_env.config the fw_printenv tool now works as expected.
Regards,
Robert
-Original Message-
From: Anatolij Gustschin [mailto:ag...@denx.de]
Sent: Wednesday, February 05, 2020 3:03 PM
Hi Olivier,
On Wed, Feb 5, 2020 at 11:01 AM Olivier BERTON <
olivier.ber...@etu.univ-nantes.fr> wrote:
> Hi,
>
> I'm a student working on ZedBoard FPGA, and I have to install a custom
> Linux on the ZedBoard.
> I have to build u-boot, so I'm following this Wiki :
>
cfb_console driver supported 8bpp bitmap drawing on 24bpp/32bpp
displays and some boards used this configuration for drawing
the logo. After conversion to DM_VIDEO the logo drawing on such
boards doesn't work any more due to missing rendering code in the
updated bmp command code for DM_VIDEO. Add
On boards with small displays (i.e. 480x272) the banner
output on video console can sometimes overwrite the logo
(depending on the logo size and banner length). Check
for free space right of the logo before drawing the
banner and adjust the starting position to draw the
banner string below the
Before DM_VIDEO conversion this board used 24bpp
display configuration, so use it again.
Signed-off-by: Anatolij Gustschin
---
arch/arm/dts/imx6ul-14x14-evk-u-boot.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/dts/imx6ul-14x14-evk-u-boot.dtsi
On 2/5/2020 2:45 PM, Lokesh Vutla wrote:
On 04/02/20 12:06 PM, Keerthy wrote:
This patch series enables mcu_r5fss0_core0 & main_r5fss0_core0.
Tested for firmware loading and execution on J721e.
I still see build error with multiple imx boards:
From: Frieder Schrempf
In order to auto-select an option from the pxe boot menu, that
matches the detected board, we check the board model string in the
devicetree and set the default menu selection, if it matches the
label of the menu entry and there is no default selection already
set.
This
From: Frieder Schrempf
In order to make it possible to auto select a default entry by
matching the data of the menu entries by an external matching
function, we add some helpers and expose the
menu_set_default_by_item_data_match() function.
Signed-off-by: Frieder Schrempf
---
Changes in v2:
*
Remove 'fdt_high' and 'initrd_high' environment variables (set to 0x)
from default environment which prevents relocation of FDT and initrd.
Signed-off-by: Oliver Graute
Cc: Stefano Babic
Cc: Fabio Estevam
Cc: Peng Fan
Cc: Simon Glass
Cc: Ye Li
Cc: uboot-imx
---
On 05.02.20 14:44, Frieder Schrempf wrote:
> Hi Simon,
>
> On 30.12.19 02:21, Simon Glass wrote:
>> Hi Schrempf,
>>
>> On Tue, 10 Dec 2019 at 08:47, Schrempf Frieder
>> wrote:
>>>
>>> From: Frieder Schrempf
>>>
>>> In order to iterate over the menu entries and match for a specific
>>> name in
On 04/02/20, Tom Rini wrote:
> On Mon, Feb 03, 2020 at 01:59:14PM +, Oliver Graute wrote:
> > As proposed here:
> >
> > https://lists.denx.de/pipermail/u-boot/2020-January/396749.html
> >
> > Both of my imx8qm boards (Advantech and Congatec) aren't booting
> > 2020.01 without this change.
Hi,
I'm a student working on ZedBoard FPGA, and I have to install a custom
Linux on the ZedBoard.
I have to build u-boot, so I'm following this Wiki :
https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18841973/Build+U-Boot
In the third command I have to enter "Make", and I get this error :
90 matches
Mail list logo
