On 24/01/19 8:12 PM, Jean-Jacques Hiblot wrote:
>
> The AM43xx is able to get its SPL from an external USB storage. There is a
> dedicated defconfig (am43xx_evm_usbhost_boot_defconfig) but it doesn't use
> DM_USB. Converting this defconfig to DM_USB.
For the whole series
Reviewed-by: Lokesh Vu
Enable USB host controllers for Amarula A64-Relic board,
the respective nodes are already present in DTS.
Signed-off-by: Jagan Teki
---
configs/amarula_a64_relic_defconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/configs/amarula_a64_relic_defconfig
b/configs/amarula_a64_relic_defco
On Sat, Jan 19, 2019 at 7:03 AM Andre Przywara wrote:
>
> If a board DT describes a cd-gpios property, but also marks the storage
> as non-removable, we must ignore the GPIO (as Linux does).
>
> Teach the DM_MMC part of the Allwinner MMC driver about the
> non-removable DT property, to fix DM_MMC
Hi Patrick
I checked with Patrice the other boards and most of the cases the modified spl
binay
(u-boot-spl.bin/ u-boot-spl.ais / u-boot-spl.img / u-boot-spl.pbl /
u-boot-spl.gph)
are generated in spl directory.
So I done the same for u-boot-spl.stm32.
All the NXP iMX6 variant boards deploy
Hi Tom,
The following changes since commit ce0d1e48165fdd3bde4bb431f1d2e100b1617a6e:
Merge tag 'xilinx-for-v2019.04' of git://git.denx.de/u-boot-microblaze
(2019-01-24 10:47:05 -0500)
are available in the Git repository at:
git://git.denx.de/u-boot-arc.git tags/arc-fixes-for-2019.04-rc1
f
This patch is to add a new udimm for T1040DRDB board
Signed-off-by: Peng Ma
---
board/freescale/t104xrdb/ddr.h |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/board/freescale/t104xrdb/ddr.h b/board/freescale/t104xrdb/ddr.h
index 319fc59..f9d667f 100644
--- a/board/freesc
Heinrich,
On Thu, Jan 24, 2019 at 10:19:28PM +0100, Heinrich Schuchardt wrote:
> On 1/24/19 9:18 PM, Simon Glass wrote:
> > Hi Takahiro,
> >
> > On Thu, 24 Jan 2019 at 13:53, AKASHI Takahiro
> > wrote:
> >>
> >> Simon,
> >>
> >> On Thu, Jan 24, 2019 at 10:58:53AM +1300, Simon Glass wrote:
> >>>
On 01/22/2019 05:53 AM, Simon Glass wrote:
> Quite a wide range of Rockchip SoCs are supported in mainline U-Boot now,
> so drop the comment about needing to add more.
>
> Signed-off-by: Simon Glass
This patch looks good to me.
Reviewed-by: Kever Yang
Thanks,
- Kever
> ---
>
> Changes in v2:
On 01/22/2019 05:53 AM, Simon Glass wrote:
> At present some Rockchip SoCs and boards are not mentioned in the README.
> So that people can see which SoCs are supported, expand the list to
> include everything.
>
> Signed-off-by: Simon Glass
This patch looks good to me.
Reviewed-by: Kever Yang
On 01/22/2019 05:53 AM, Simon Glass wrote:
> We use every second block when creating a SPI image, so update the text to
> say this explicitly.
>
> Signed-off-by: Simon Glass
> ---
>
> Changes in v2: None
>
> doc/README.rockchip | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --
Hi Simon,
On 01/22/2019 05:53 AM, Simon Glass wrote:
> Add mention of a prerequisite needed to build the image. Also adjust the
> English wording in a few places.
>
> Ideally this should move to using binman to produce images, and avoid the
> manual steps.
>
> Signed-off-by: Simon Glass
This pa
On 1/24/19 8:16 AM, Joe Hershberger wrote:
> On Wed, Jan 23, 2019 at 5:46 PM Vladimir Oltean
> wrote:
>>
>> Signed-off-by: Vladimir Oltean
>> ---
>> Changes in v2:
>> * Patch added in this version.
>>
>> drivers/net/phy/atheros.c | 8 +++-
>> 1 file changed, 3 insertions(+), 5 deletions
On 1/24/19 8:20 AM, Joe Hershberger wrote:
> On Wed, Jan 23, 2019 at 5:47 PM Vladimir Oltean
> wrote:
>> static int ar8021_config(struct phy_device *phydev)
>> {
>> phy_write(phydev, MDIO_DEVAD_NONE, 0x00, 0x1200);
>> - phy_write(phydev, MDIO_DEVAD_NONE, 0x1d, 0x05);
>> -
On 1/24/19 10:01 PM, Carlo Caione wrote:
> On 24/01/2019 19:56, Vladimir Oltean wrote:
>> On 1/24/19 10:56 AM, Carlo Caione wrote:
>
>> It works for me, but I do have a question.
>> Is there any limitation preventing you to add this functionality via the
>> standard "mdio read x.y" instead of "mdi
On 1/24/19 10:08 PM, Carlo Caione wrote:
> On 24/01/2019 20:04, Vladimir Oltean wrote:
>> On 1/24/19 10:01 PM, Carlo Caione wrote:
>>> On 24/01/2019 19:56, Vladimir Oltean wrote:
On 1/24/19 10:56 AM, Carlo Caione wrote:
>>
>> No, I mean instead of doing "mdio rmmd 3.1" to do "mdio read 3.1"
>>
On 1/24/19 10:19 PM, Carlo Caione wrote:
> On 24/01/2019 20:12, Vladimir Oltean wrote:
>>
>> I still think I haven't successfully made my point.
>> If "mdio read 3.1" is a C45-only thing, "mdio read 1" is a C22-only
>> thing, then why do you need a new command "mdio rmmd 3.1" to do C45
>> emulation
On 1/24/19 10:56 AM, Carlo Caione wrote:
> Two new parameters (rmmd and wmmd) are added to allow the `mdio` command
> to access the content of the MMD PHY registers.
>
> Signed-off-by: Carlo Caione
> Acked-by: Joe Hershberger
> ---
> cmd/mdio.c | 52 +---
On 24.01.19 13:21, Andre Przywara wrote:
> On Thu, 24 Jan 2019 13:07:54 +0100
> Alexander Graf wrote:
>
>> On 24.01.19 12:31, Andre Przywara wrote:
>>
>> Ok, that did not help. I guess the next best useful thing to do now
>> would be to measure what the MISO line shows in each situation.
>> Unf
On 1/24/19 9:18 PM, Simon Glass wrote:
> Hi Takahiro,
>
> On Thu, 24 Jan 2019 at 13:53, AKASHI Takahiro
> wrote:
>>
>> Simon,
>>
>> On Thu, Jan 24, 2019 at 10:58:53AM +1300, Simon Glass wrote:
>>> Hi Heinrich,
>>>
>>> On Wed, 23 Jan 2019 at 10:05, Heinrich Schuchardt
>>> wrote:
On 1/2
The OMAP36 and DM37 TRM state to disable extneded drain IO before
changing the PBIAS. This patch does this before pmic writes if
the CONFIG_MMC_OMAP36XX_PINS flag is set and the cpu family is
omap36xx
Signed-off-by: Adam Ford
diff --git a/drivers/power/regulator/pbias_regulator.c
b/drivers/pow
On Thu, Jan 24, 2019 at 04:27:33PM +0100, Michal Simek wrote:
> Hi Tom,
>
> Here are several patches which I have in my queue.
> Buildman looks good and travis is also clear.
> https://travis-ci.org/michalsimek/u-boot/builds/483796826
>
> I have also sent several other patches to be able to fini
On 24/01/2019 20:12, Vladimir Oltean wrote:
I still think I haven't successfully made my point.
If "mdio read 3.1" is a C45-only thing, "mdio read 1" is a C22-only
thing, then why do you need a new command "mdio rmmd 3.1" to do C45
emulation over C22? Is there any overlap I'm missing that mandat
On Fri, 25 Jan 2019 at 03:30, Marcel Ziswiler wrote:
>
> From: Marcel Ziswiler
>
> Calling sata_scan() with a null pointer probably won't make much sense.
>
> Signed-off-by: Marcel Ziswiler
>
> ---
>
> cmd/sata.c | 4
> 1 file changed, 4 insertions(+)
>
Reviewed-by: Simon Glass
_
Hi Marcel,
On Fri, 25 Jan 2019 at 03:30, Marcel Ziswiler wrote:
>
> From: Marcel Ziswiler
>
> Given ahci_get_ops() being a macro not checking anything make sure we
> only call it if we do indeed have a dev pointer.
>
> Signed-off-by: Marcel Ziswiler
>
> ---
>
> drivers/ata/sata.c | 27
Hi Marcel,
On Fri, 25 Jan 2019 at 03:30, Marcel Ziswiler wrote:
>
> From: Marcel Ziswiler
>
> While uclass_find_device() fails with -ENODEV in case of list_empty
> strangely uclass_find_first_device() returns 0.
>
> Fix uclass_find_first_device() to also fail with -ENODEV instead.
The fix sees
Hi Takahiro,
On Thu, 24 Jan 2019 at 13:53, AKASHI Takahiro
wrote:
>
> Simon,
>
> On Thu, Jan 24, 2019 at 10:58:53AM +1300, Simon Glass wrote:
> > Hi Heinrich,
> >
> > On Wed, 23 Jan 2019 at 10:05, Heinrich Schuchardt
> > wrote:
> > >
> > > On 1/22/19 8:39 PM, Simon Glass wrote:
> > > > Hi Alex,
arch/x86/dts/qemu-x86_i440fx.dts reserves memory for PCI at 0x100.
Loading via the `dhcp` command to this address leads to a crash on
qemu-x86_64_defconfig. So let's define CONFIG_LOADADDR as 0x110.
Reported-by: Alexander Graf
Signed-off-by: Heinrich Schuchardt
---
compatible='pci-x86' i
Hi Tom,
Please pull this PR.
thanks,
Jagan.
The following changes since commit f83ef0dac83110d20389eb71f09285f009f3d198:
Merge tag 'mips-pull-2019-11-16' of git://git.denx.de/u-boot-mips (2019-01-17
19:12:55 -0500)
are available in the Git repository at:
git://git.denx.de/u-boot-sunxi.gi
On 24/01/2019 20:04, Vladimir Oltean wrote:
On 1/24/19 10:01 PM, Carlo Caione wrote:
On 24/01/2019 19:56, Vladimir Oltean wrote:
On 1/24/19 10:56 AM, Carlo Caione wrote:
No, I mean instead of doing "mdio rmmd 3.1" to do "mdio read 3.1"
(basically not define a new command).
Ooooh, I think yo
On 1/24/19 11:38 AM, Simon Goldschmidt wrote:
This unbreaks dfu mmc_file_op which is currently broken since using the
load cmd on a buffer from heap is not allowed.
Tested-by: Stephen Warren
diff --git a/drivers/dfu/dfu_mmc.c b/drivers/dfu/dfu_mmc.c
static int mmc_file_op(enum dfu_op op
Am Do., 24. Jan. 2019, 21:05 hat Stephen Warren
geschrieben:
> On 1/24/19 11:38 AM, Simon Goldschmidt wrote:
> > This unbreaks dfu mmc_file_op which is currently broken since using the
> > load cmd on a buffer from heap is not allowed.
>
> Tested-by: Stephen Warren
>
That was fast, thanks!
>
On 24/01/2019 19:56, Vladimir Oltean wrote:
On 1/24/19 10:56 AM, Carlo Caione wrote:
It works for me, but I do have a question.
Is there any limitation preventing you to add this functionality via the
standard "mdio read x.y" instead of "mdio rmmd x.y" if the PHY is known
to be C22?
You can
Steven,
Am Do., 24. Jan. 2019, 19:39 hat Simon Goldschmidt <
simon.k.r.goldschm...@gmail.com> geschrieben:
> This unbreaks dfu mmc_file_op which is currently broken since using the
> load cmd on a buffer from heap is not allowed.
>
> Signed-off-by: Simon Goldschmidt
>
I'd be very thankful if y
This unbreaks dfu mmc_file_op which is currently broken since using the
load cmd on a buffer from heap is not allowed.
Signed-off-by: Simon Goldschmidt
---
drivers/dfu/dfu_mmc.c | 67 ---
1 file changed, 31 insertions(+), 36 deletions(-)
diff --git a/dri
On Thu, Jan 24, 2019 at 2:07 AM Michal Simek wrote:
>
> On 23. 01. 19 19:20, Joe Hershberger wrote:
> > On Tue, Nov 27, 2018 at 12:20 AM Siva Durga Prasad Paladugu
> > wrote:
> >>
> >> This patch adds support for gmiitorgmii converter.
> >> This converter sits between the MAC and the external phy
Hi Chris,
https://patchwork.ozlabs.org/patch/1003048/ was applied to
http://git.denx.de/?p=u-boot/u-boot-net.git
Thanks!
-Joe
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Hi Chris,
https://patchwork.ozlabs.org/patch/1003050/ was applied to
http://git.denx.de/?p=u-boot/u-boot-net.git
Thanks!
-Joe
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Hi Carlo,
https://patchwork.ozlabs.org/patch/1025909/ was applied to
http://git.denx.de/?p=u-boot/u-boot-net.git
Thanks!
-Joe
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Hi Valentin-catalin,
https://patchwork.ozlabs.org/patch/990715/ was applied to
http://git.denx.de/?p=u-boot/u-boot-net.git
Thanks!
-Joe
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Hi Ramon,
https://patchwork.ozlabs.org/patch/1018949/ was applied to
http://git.denx.de/?p=u-boot/u-boot-net.git
Thanks!
-Joe
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Hi Andreas,
https://patchwork.ozlabs.org/patch/1005603/ was applied to
http://git.denx.de/?p=u-boot/u-boot-net.git
Thanks!
-Joe
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Hi Simon,
https://patchwork.ozlabs.org/patch/1001862/ was applied to
http://git.denx.de/?p=u-boot/u-boot-net.git
Thanks!
-Joe
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Hi Aditya,
https://patchwork.ozlabs.org/patch/1007736/ was applied to
http://git.denx.de/?p=u-boot/u-boot-net.git
Thanks!
-Joe
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Hi Valentin-catalin,
https://patchwork.ozlabs.org/patch/993651/ was applied to
http://git.denx.de/?p=u-boot/u-boot-net.git
Thanks!
-Joe
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Hi Baruch,
https://patchwork.ozlabs.org/patch/1001095/ was applied to
http://git.denx.de/?p=u-boot/u-boot-net.git
Thanks!
-Joe
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Hi Simon,
https://patchwork.ozlabs.org/patch/999267/ was applied to
http://git.denx.de/?p=u-boot/u-boot-net.git
Thanks!
-Joe
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Hi Tom,
Passed the travis build...
https://travis-ci.org/jhershbe/u-boot/builds/483483372
The following changes since commit aff66f22d6eeb27c6329c0a3c1ebc52914c8affa:
Merge tag 'mips-pull-2019-01-23' of git://git.denx.de/u-boot-mips (2019-01-23
17:24:31 -0500)
are available in the git repos
Hi Baruch,
https://patchwork.ozlabs.org/patch/1001096/ was applied to
http://git.denx.de/?p=u-boot/u-boot-net.git
Thanks!
-Joe
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Hi Chris,
https://patchwork.ozlabs.org/patch/1007466/ was applied to
http://git.denx.de/?p=u-boot/u-boot-net.git
Thanks!
-Joe
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Hi Pankaj,
https://patchwork.ozlabs.org/patch/998770/ was applied to
http://git.denx.de/?p=u-boot/u-boot-net.git
Thanks!
-Joe
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Hi Simon,
https://patchwork.ozlabs.org/patch/1001866/ was applied to
http://git.denx.de/?p=u-boot/u-boot-net.git
Thanks!
-Joe
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Hi Thomas,
https://patchwork.ozlabs.org/patch/1001188/ was applied to
http://git.denx.de/?p=u-boot/u-boot-net.git
Thanks!
-Joe
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
This patch sync's the U-Boot SPI NAND GigaDevice GD5F1GQ4UExxG support
with the latest Linux version (v5.0-rc3) plus the chip supported posted
on the MTD list. Only the currently in U-Boot available chip is
supported with this sync.
The changes for the GD5F1GQ4UExxG are:
- Name of NAND device chan
Hi Simon,
https://patchwork.ozlabs.org/patch/999268/ was applied to
http://git.denx.de/?p=u-boot/u-boot-net.git
Thanks!
-Joe
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Tom,
The following changes since commit 7794fe2c8c1303d303dbc515955c6c5be706da88:
Merge git://git.denx.de/u-boot-nds32 (2019-01-22 22:00:20 -0500)
are available in the Git repository at:
git://git.denx.de/u-boot-mpc85xx.git tags/mpc85xx-for-v2019.04-rc1
for you to fetch changes up to 45e81
On 12/6/18 8:20 AM, Joakim Tjernlund wrote:
> -msingle-pic-base is a new gcc(from 4.6) option for ppc and
> it reduces the size of my u-boot with about 4-5 KB.
> While at it, add -fno-jump-tables too to save a
> few more bytes.
>
> e5500 core:
> size u-boot.bef
>text data bss
Hi,
On 24.1.2019 12.57, Andre Przywara wrote:
> On Thu, 24 Jan 2019 11:17:03 +0100
> Alexander Graf wrote:
>
>> On 22.01.19 17:37, Alexander Graf wrote:
>>>
>>> On 22.01.19 17:28, Alexander Graf wrote:
On 22.01.19 17:17, Oskari Lemmelä wrote:
> Hi,
>
> On 22.1.2019 16.54
Hi Sean,
> From: Sean Nyekjaer
> Sent: jeudi 24 janvier 2019 13:38
>
> Hi Patrice
>
> >>> What about keeping spl binary in /spl directory and copying it in
> >>> root directory instead ? It would avoid us to update our environment
> >>> regarding your proposal.
> >
> >
> > You didn't answer to
On Wed, Jan 23, 2019 at 3:21 PM Tom Rini wrote:
>
> On Wed, Jan 23, 2019 at 03:13:52PM -0600, Adam Ford wrote:
>
> > By removing EXT support from SPL, it makes room for the extra
> > overhead of enabling OF_CONTROL in SPL. With SPL_OF_CONTROL
> > enabled, extra options need to be added to the dev
From: Siva Durga Prasad Paladugu
This patch adds distro boot commands for qspi and nand. The
distro boot commands now reads the script from flash offset
of 63.5MB and executes it.
Setup default location via script_offset_f to 63.5MB to match the most
xilinx reference boards. 512kB allocated spac
This patch is doing two things.
1. Exchanging order of boot commands. distro_bootcmd is run first
followed by Xilinx boot command.
2. Remove CONFIG_BOOTCOMMAND from configs (and follow mainline) by
creating Xilinx distribution bootcommand and wiring it as the last
bootcommand.
QSPI, NAND distribut
Hi Tom,
Here are several patches which I have in my queue.
Buildman looks good and travis is also clear.
https://travis-ci.org/michalsimek/u-boot/builds/483796826
I have also sent several other patches to be able to finish transition
to DM_I2C to reach the state that I can enable it for all board
Enable DM_USB support in u-boot and in SPL.
This brings this configuration closer to am43xx_evm_defconfig.
Signed-off-by: Jean-Jacques Hiblot
---
configs/am43xx_evm_usbhost_boot_defconfig | 12
1 file changed, 12 insertions(+)
diff --git a/configs/am43xx_evm_usbhost_boot_defconfi
commit 801f1fa442 "dm: usb: udc: Use SEQ_ALIAS to index the USB gadget
ports" changed the way the udevice if found. It uses the alias to find
a udevice for a given USB port number. In the commit log it was stated
that if no alias is provided, the bind order will be used instead. However
it doesn't
This is required to enable the USB port #2 in SPL when DM_USB is used.
Signed-off-by: Jean-Jacques Hiblot
---
arch/arm/dts/am4372-u-boot.dtsi | 20
1 file changed, 20 insertions(+)
diff --git a/arch/arm/dts/am4372-u-boot.dtsi b/arch/arm/dts/am4372-u-boot.dtsi
index 0e6d41f
The AM43xx is able to get its SPL from an external USB storage. There is a
dedicated defconfig (am43xx_evm_usbhost_boot_defconfig) but it doesn't use
DM_USB. Converting this defconfig to DM_USB.
Jean-Jacques Hiblot (3):
ARM: DTS: am43xx: Add aliases for the USB ports
ARM: DTS: am43xx: Enable
Although not required, it doesn't hurt to explicitly map the USB ports to
a USB controller. Without this, the port number will be derived from the
binding order of the peripheral devices.
Signed-off-by: Jean-Jacques Hiblot
---
arch/arm/dts/am4372-u-boot.dtsi | 7 +++
1 file changed, 7 inser
From: Marcel Ziswiler
Given ahci_get_ops() being a macro not checking anything make sure we
only call it if we do indeed have a dev pointer.
Signed-off-by: Marcel Ziswiler
---
drivers/ata/sata.c | 27 +--
1 file changed, 21 insertions(+), 6 deletions(-)
diff --git a/
From: Marcel Ziswiler
Calling sata_scan() with a null pointer probably won't make much sense.
Signed-off-by: Marcel Ziswiler
---
cmd/sata.c | 4
1 file changed, 4 insertions(+)
diff --git a/cmd/sata.c b/cmd/sata.c
index 6d62ba8f74..a73cc54bd3 100644
--- a/cmd/sata.c
+++ b/cmd/sata.c
@@
From: Marcel Ziswiler
While uclass_find_device() fails with -ENODEV in case of list_empty
strangely uclass_find_first_device() returns 0.
Fix uclass_find_first_device() to also fail with -ENODEV instead.
Signed-off-by: Marcel Ziswiler
---
drivers/core/uclass.c | 2 +-
1 file changed, 1 inse
crashing in case no SATA driver is actually there:
Apalis iMX6 # sata init
data abort
pc : [<8ff78e1a>] lr : [<8ff78e1b>]
reloc pc : [<1781be1a>]lr : [<1781be1b>]
sp : 8df53068 ip : 0001 fp : 0002
r10: 8df612e8 r9 : 8df5ceb0 r8 : 8ffc2b28
r7 : 8ff746ed r6 :
Watchdog is not handled while waiting for fastboot commands.
Tested on a i.MX6 ULL EVK board.
Signed-off-by: Sean Nyekjaer
---
cmd/fastboot.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/cmd/fastboot.c b/cmd/fastboot.c
index e6ae0570d5..f520d907ff 100644
--- a/cmd/fastboot.c
+++ b/cmd/
On Jan 24 2019, Alexander Graf wrote:
> On 24.01.19 14:38, Andreas Schwab wrote:
>> On Jan 24 2019, Alexander Graf wrote:
>>
>>> Board_init() is too late. This needs to go into early_board_init_f().
>>
>> I don't think we can modify the DT that early.
>
> I'm sure we can. Worst case we have to
On 24.01.19 14:38, Andreas Schwab wrote:
> On Jan 24 2019, Alexander Graf wrote:
>
>> Board_init() is too late. This needs to go into early_board_init_f().
>
> I don't think we can modify the DT that early.
I'm sure we can. Worst case we have to copy it over to RAM first.
What obstacle exact
Hi,
i ran also in same problem, after resize environment (4k to 8k), because my 4k
is no more enough for my environment.
i did not understand my CRC have to be checked if i want to save (and the
checked part will be overridden). It makes sense to check the CRC of current
environment-block whic
On Jan 24 2019, Alexander Graf wrote:
> Board_init() is too late. This needs to go into early_board_init_f().
I don't think we can modify the DT that early.
Andreas.
--
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now
Hello Adam,
On 23.01.2019 22:13, Adam Ford wrote:
> By removing EXT support from SPL, it makes room for the extra
> overhead of enabling OF_CONTROL in SPL. With SPL_OF_CONTROL
> enabled, extra options need to be added to the device tree to
> tell it which portions of the tree are needed early in
On Thu, Jan 24, 2019 at 4:48 PM Alexander Graf wrote:
>
>
>
> On 24.01.19 12:05, Anup Patel wrote:
> > On Thu, Jan 24, 2019 at 4:16 PM Alexander Graf wrote:
> >>
> >>
> >>
> >> On 24.01.19 11:43, Anup Patel wrote:
> >>>
> >>>
> -Original Message-
> From: Andreas Schwab [mailto:s
Hi Patrice
What about keeping spl binary in /spl directory and copying it in root
directory instead ? It would avoid us to update our environment
regarding your proposal.
You didn't answer to the above question.
Patrice
Sorry.
I really don't care how it's done :-)
But the I think the best
Hi Sean
On 1/24/19 12:30 PM, Sean Nyekjaer wrote:
> ping
>
> On 04.01.2019 16.18, Patrice CHOTARD wrote:
>> Hi Sean
>>
>> +Patrick Delaunay
>>
>> What about keeping spl binary in /spl directory and copying it in root
>> directory instead ? It would avoid us to update our environment
>> regarding
On Thu, 24 Jan 2019 13:07:54 +0100
Alexander Graf wrote:
> On 24.01.19 12:31, Andre Przywara wrote:
> > On Thu, 24 Jan 2019 12:21:17 +0100
> > Alexander Graf wrote:
> >
> >> On 24.01.19 12:07, Andre Przywara wrote:
> >>> On Thu, 24 Jan 2019 11:59:32 +0100
> >>> Alexander Graf wrote:
> >>>
On Thu, Jan 24, 2019 at 12:40:14PM +0100, Simon Goldschmidt wrote:
> On Mon, Aug 13, 2018 at 12:07 PM Simon Goldschmidt
> wrote:
> >
> > Signed-off-by: Simon Goldschmidt
>
> Gentle ping for:
> https://patchwork.ozlabs.org/patch/956901/
> https://patchwork.ozlabs.org/patch/956902/
>
> Who is res
On Thu, Jan 24, 2019 at 12:46:32PM +0100, Simon Goldschmidt wrote:
> On Tue, Jan 22, 2019 at 11:10 PM Tom Rini wrote:
> >
> > Make use of "IMAGE_MAX_SIZE" and "IMAGE_TEXT_BASE" rather than
> > CONFIG_SPL_MAX_SIZE and CONFIG_SPL_TEXT_BASE. This lets us re-use the
> > same script for both SPL and T
On 24.01.19 12:31, Andre Przywara wrote:
> On Thu, 24 Jan 2019 12:21:17 +0100
> Alexander Graf wrote:
>
>> On 24.01.19 12:07, Andre Przywara wrote:
>>> On Thu, 24 Jan 2019 11:59:32 +0100
>>> Alexander Graf wrote:
>>>
On 24.01.19 11:57, Andre Przywara wrote:
> On Thu, 24 Jan 2019
On Tue, Jan 22, 2019 at 11:10 PM Tom Rini wrote:
>
> Make use of "IMAGE_MAX_SIZE" and "IMAGE_TEXT_BASE" rather than
> CONFIG_SPL_MAX_SIZE and CONFIG_SPL_TEXT_BASE. This lets us re-use the
> same script for both SPL and TPL. Add logic to scripts/Makefile.spl to
> pass in the right value when prep
On Mon, Aug 13, 2018 at 12:07 PM Simon Goldschmidt
wrote:
>
> Signed-off-by: Simon Goldschmidt
Gentle ping for:
https://patchwork.ozlabs.org/patch/956901/
https://patchwork.ozlabs.org/patch/956902/
Who is responsible for the gitdm repo?
Thanks,
Simon
> ---
> u-boot-config/domain-map | 1 +
>
On 21/01/2019 17:55, Jack Mitchell wrote:
> Hi,
>
> Has anyone successfully used DFU on an rk3288 or dwc2_otg based board?
> When trying to download a binary to the board over DFU it currently
> seems to timeout and the transfer fails. I have tested the
> firefly-rk3288 and also the Tinkerboard.
>
On 21/01/2019 17:55, Jack Mitchell wrote:
> Hi,
>
> Has anyone successfully used DFU on an rk3288 or dwc2_otg based board?
> When trying to download a binary to the board over DFU it currently
> seems to timeout and the transfer fails. I have tested the
> firefly-rk3288 and also the Tinkerboard.
>
ping
On 04.01.2019 16.18, Patrice CHOTARD wrote:
Hi Sean
+Patrick Delaunay
What about keeping spl binary in /spl directory and copying it in root
directory instead ? It would avoid us to update our environment
regarding your proposal.
Just a minor remark, don't forget to add maintainers in co
I was wondering wtaht teh status is of the u-boot configuration of the
Intel/Altera Arria-10 development kit.
When building the defconfig and copying the SFP to the SD card the preloader
starts, but after this it does not detect the MMC.
Has anyone ever tested the defconfig (which is for this de
On Thu, 24 Jan 2019 12:21:17 +0100
Alexander Graf wrote:
> On 24.01.19 12:07, Andre Przywara wrote:
> > On Thu, 24 Jan 2019 11:59:32 +0100
> > Alexander Graf wrote:
> >
> >> On 24.01.19 11:57, Andre Przywara wrote:
> >>> On Thu, 24 Jan 2019 11:17:03 +0100
> >>> Alexander Graf wrote:
> >>>
On 24.01.19 12:07, Andre Przywara wrote:
> On Thu, 24 Jan 2019 11:59:32 +0100
> Alexander Graf wrote:
>
>> On 24.01.19 11:57, Andre Przywara wrote:
>>> On Thu, 24 Jan 2019 11:17:03 +0100
>>> Alexander Graf wrote:
>>>
On 22.01.19 17:37, Alexander Graf wrote:
>
>
> On 22.01
On 24.01.19 12:05, Anup Patel wrote:
> On Thu, Jan 24, 2019 at 4:16 PM Alexander Graf wrote:
>>
>>
>>
>> On 24.01.19 11:43, Anup Patel wrote:
>>>
>>>
-Original Message-
From: Andreas Schwab [mailto:sch...@suse.de]
Sent: Thursday, January 24, 2019 3:24 PM
To: Atish Pat
On Thu, 24 Jan 2019 11:59:32 +0100
Alexander Graf wrote:
> On 24.01.19 11:57, Andre Przywara wrote:
> > On Thu, 24 Jan 2019 11:17:03 +0100
> > Alexander Graf wrote:
> >
> >> On 22.01.19 17:37, Alexander Graf wrote:
> >>>
> >>>
> >>> On 22.01.19 17:28, Alexander Graf wrote:
>
>
"images" command prints loaded images-related information.
Signed-off-by: AKASHI Takahiro
---
cmd/efidebug.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/cmd/efidebug.c b/cmd/efidebug.c
index a1852e8ea4b9..81ab3654f746 100644
--- a/cmd/efidebug.c
+++ b/cmd/e
"memmap" command prints uefi-specific memory map information.
=> efi memmap
Type StartEnd Attributes
==
CONVENTIONAL 4000-7de27000 WB
RUNTIME DATA 7de27000-7de
On Thu, Jan 24, 2019 at 4:16 PM Alexander Graf wrote:
>
>
>
> On 24.01.19 11:43, Anup Patel wrote:
> >
> >
> >> -Original Message-
> >> From: Andreas Schwab [mailto:sch...@suse.de]
> >> Sent: Thursday, January 24, 2019 3:24 PM
> >> To: Atish Patra
> >> Cc: Anup Patel ; Anup Patel ;
> >> J
"env [print|set] -e" allows for handling uefi variables without
knowing details about mapping to corresponding u-boot variables.
Signed-off-by: AKASHI Takahiro
---
MAINTAINERS | 1 +
cmd/Kconfig | 6 +
cmd/Makefile | 1 +
cmd/nvedit.c | 28 +++-
cmd/nvedit_efi.c | 3
"drivers" command prints all the uefi drivers on the system.
=> efi drivers
Driver Name Image Path
7ef003d0
Signed-off-by: AKASHI Takahiro
---
cmd/efidebug.c | 80 +++
"devices" command prints all the uefi variables on the system.
=> efi devices
Scanning disk ahci_scsi.id0lun0...
Scanning disk ahci_scsi.id1lun0...
Found 4 disks
Device Device Path
7ef07ea0 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)
000
1 - 100 of 121 matches
Mail list logo
