From: Mingming Lee
The description for MT8512 has some mistake, so correct it.
Signed-off-by: Mingming Lee
---
arch/arm/mach-mediatek/Kconfig | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-mediatek/Kconfig b/arch/arm/mach-mediatek/Kconfig
index
On 03.09.20 19:25, Otavio Salvador wrote:
Signed-off-by: Otavio Salvador
---
common/spl/spl.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/common/spl/spl.c b/common/spl/spl.c
index 4840d1d367..63c48fbf33 100644
--- a/common/spl/spl.c
+++ b/common/spl/spl.c
@@
On Thu, Sep 3, 2020 at 7:23 PM Stefan Agner wrote:
>
> Any thoughts on this issue?
>
> Just to be sure, I did some memory testing on the 2GB module, but no
> issues found.
>
> I still somehow suspected that something else might be wrong with my
> hardware, so I bought a new RPi4 (this time with
We already use binman's 'multiple-images' feature with Chrome OS and we
want to use it for Edison. There is no real down-side.
Adjust x86 to always use multiple-images.
Signed-off-by: Simon Glass
---
arch/x86/dts/u-boot.dtsi | 7 ---
1 file changed, 7 deletions(-)
diff --git
In some cases it is useful to include a U-Boot environment region in an
image. This allows the board to start up with an environment ready to go.
Add a new entry type for this. The input is a text file containing the
environment entries, one per line, in the format:
var=value
Signed-off-by:
Add a description of how to flash Edison using the XFSTK tool.
Signed-off-by: Simon Glass
---
doc/board/intel/edison.rst | 120 +
1 file changed, 120 insertions(+)
diff --git a/doc/board/intel/edison.rst b/doc/board/intel/edison.rst
index
It is useful to be able to flash Edison directly without relying on the
installed U-Boot being functional.
Add a binman image for this. It includes a master-boot record, U-Boot
binary and an environment.
Signed-off-by: Simon Glass
---
arch/x86/cpu/tangier/Kconfig | 1 +
The recent support for missing external binaries does not show an error
message when a file is genuinely missing (i.e. it is missing but not
marked as 'external'). This means that when -m is passed to binman, it
will never report a missing file.
Fix this and add a test.
Signed-off-by: Simon
At present it is painful to put Edison in a hardware lab because it has
two separate recovery modes. When the board has a functioning U-Boot, DFU
can be used. Otherwise an xFSTK image must be used.
This series converts Andy's script to a binman description so that U-Boot
can produce an xFSTK
On Wed, Sep 2, 2020 at 2:14 PM Frank Wunderlich wrote:
>
> From: Chunfeng Yun
>
> Add a member to save xHCI version, it's used some times.
>
> Signed-off-by: Chunfeng Yun
> ---
> drivers/usb/host/xhci-ring.c | 4 ++--
> drivers/usb/host/xhci.c | 1 +
> include/usb/xhci.h | 1 +
>
Package: flash-kernel
Tags: patch
Control: submitter -1 a.hei...@gmail.com
X-Debbugs-Cc: Andre Heider
I'm submitting this to the Debian bug tracking system, since this isn't
directly related to u-boot. I've dropped most of the CCs on the thread,
presumably should also drop the u-boot CC on
On Thu, Sep 3, 2020 at 3:24 PM Stephen Warren wrote:
>
> On 9/3/20 2:14 PM, Dennis Gilmore wrote:
> > On Thu, Sep 3, 2020 at 2:15 PM Stephen Warren wrote:
> >>
> >> On 9/3/20 10:40 AM, Dennis Gilmore wrote:
> >>> When testing builds provided in
> >>> https://github.com/openwrt/openwrt/pull/3360
On 9/3/20 2:14 PM, Dennis Gilmore wrote:
> On Thu, Sep 3, 2020 at 2:15 PM Stephen Warren wrote:
>>
>> On 9/3/20 10:40 AM, Dennis Gilmore wrote:
>>> When testing builds provided in https://github.com/openwrt/openwrt/pull/3360
>>> I discovered that fdtfile was not set and as a result the firmware
On Thu, Sep 3, 2020 at 2:15 PM Stephen Warren wrote:
>
> On 9/3/20 10:40 AM, Dennis Gilmore wrote:
> > When testing builds provided in https://github.com/openwrt/openwrt/pull/3360
> > I discovered that fdtfile was not set and as a result the firmware was not
> > functional. So I am documenting
Hi Vagrant,
On 03/09/2020 20:59, Vagrant Cascadian wrote:
On 2020-09-03, Andre Heider wrote:
On 03/09/2020 18:40, Dennis Gilmore wrote:
When testing builds provided in https://github.com/openwrt/openwrt/pull/3360
I discovered that fdtfile was not set and as a result the firmware was not
On 9/3/20 10:40 AM, Dennis Gilmore wrote:
> When testing builds provided in https://github.com/openwrt/openwrt/pull/3360
> I discovered that fdtfile was not set and as a result the firmware was not
> functional. So I am documenting what is needed.
>
> Signed-off-by: Dennis Gilmore
>
> Cc: Atish
On Thu, Sep 03, 2020 at 01:10:48PM -0600, Stephen Warren wrote:
> On 9/3/20 1:07 PM, Edgar E. Iglesias wrote:
> > On Thu, Sep 03, 2020 at 09:45:39AM -0600, Stephen Warren wrote:
> >> On 9/3/20 7:40 AM, André Przywara wrote:
> >>> On 03/09/2020 14:35, Michal Simek wrote:
>
>
> On 02.
On 9/3/20 1:07 PM, Edgar E. Iglesias wrote:
> On Thu, Sep 03, 2020 at 09:45:39AM -0600, Stephen Warren wrote:
>> On 9/3/20 7:40 AM, André Przywara wrote:
>>> On 03/09/2020 14:35, Michal Simek wrote:
On 02. 09. 20 18:34, Stephen Warren wrote:
> On 9/2/20 5:15 AM, Michal Simek
On Thu, Sep 03, 2020 at 09:45:39AM -0600, Stephen Warren wrote:
> On 9/3/20 7:40 AM, André Przywara wrote:
> > On 03/09/2020 14:35, Michal Simek wrote:
> >>
> >>
> >> On 02. 09. 20 18:34, Stephen Warren wrote:
> >>> On 9/2/20 5:15 AM, Michal Simek wrote:
> From: "Edgar E. Iglesias"
>
>
On 2020-09-03, Andre Heider wrote:
> On 03/09/2020 18:40, Dennis Gilmore wrote:
>> When testing builds provided in https://github.com/openwrt/openwrt/pull/3360
>> I discovered that fdtfile was not set and as a result the firmware was not
>> functional. So I am documenting what is needed.
>>
>>
On Thu, Sep 03, 2020 at 02:25:15PM -0300, Otavio Salvador wrote:
> Signed-off-by: Otavio Salvador
Reviewed-by: Tom Rini
--
Tom
signature.asc
Description: PGP signature
On Thu, Sep 03, 2020 at 02:14:35PM +0200, Marek Vasut wrote:
> Mostly DFU fixes and r8152 fixes below:
>
> The following changes since commit 23e333a5c083a000d0cabc53f7c0d261bae9e5ca:
>
> MAINTAINERS: step down as maintainer of UniPhier SoCs (2020-08-31
> 17:11:24 -0400)
>
> are available in
On Thu, Sep 03, 2020 at 02:15:10PM +0200, Marek Vasut wrote:
> The following changes since commit 23e333a5c083a000d0cabc53f7c0d261bae9e5ca:
>
> MAINTAINERS: step down as maintainer of UniPhier SoCs (2020-08-31
> 17:11:24 -0400)
>
> are available in the Git repository at:
>
>
On Thu, Sep 03, 2020 at 06:53:22AM +, Tan, Ley Foon wrote:
> Hi Tom
>
> Please pull one change for u-boot SoCFPGA.
>
> Regards
> Ley Foon
>
>
> The following changes since commit 7149077353ef4837ab2fcdce5d7e52c5ed4b026a:
>
> Azure/GitLab: Update to latest Docker container (2020-09-02
On Thu, Sep 03, 2020 at 07:50:32PM +0200, Andre Heider wrote:
> Hi Dennis,
>
> On 03/09/2020 18:40, Dennis Gilmore wrote:
> > When testing builds provided in https://github.com/openwrt/openwrt/pull/3360
> > I discovered that fdtfile was not set and as a result the firmware was not
> > functional.
Hi Dennis,
On 03/09/2020 18:40, Dennis Gilmore wrote:
When testing builds provided in https://github.com/openwrt/openwrt/pull/3360
I discovered that fdtfile was not set and as a result the firmware was not
functional. So I am documenting what is needed.
Signed-off-by: Dennis Gilmore
Cc:
Signed-off-by: Otavio Salvador
---
common/spl/spl.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/common/spl/spl.c b/common/spl/spl.c
index 4840d1d367..63c48fbf33 100644
--- a/common/spl/spl.c
+++ b/common/spl/spl.c
@@ -552,7 +552,9 @@ static int
When testing builds provided in https://github.com/openwrt/openwrt/pull/3360
I discovered that fdtfile was not set and as a result the firmware was not
functional. So I am documenting what is needed.
Signed-off-by: Dennis Gilmore
Cc: Atish Patra
Cc: Lukas Auer
Cc: Tom Rini
Cc: Masahiro
On Thu, Sep 03, 2020 at 06:05:44PM +0300, Andy Shevchenko wrote:
> On Thu, Sep 03, 2020 at 08:21:23AM -0600, Simon Glass wrote:
> > On Thu, 3 Sep 2020 at 07:51, Andy Shevchenko
> > wrote:
> > > On Thu, Sep 3, 2020 at 4:40 PM Andy Shevchenko
> > > wrote:
> > > > On Thu, Sep 03, 2020 at
On 9/3/20 7:40 AM, André Przywara wrote:
> On 03/09/2020 14:35, Michal Simek wrote:
>>
>>
>> On 02. 09. 20 18:34, Stephen Warren wrote:
>>> On 9/2/20 5:15 AM, Michal Simek wrote:
From: "Edgar E. Iglesias"
When U-Boot binary exceeds 1MB with CONFIG_POSITION_INDEPENDENT=y
On Thu, Sep 03, 2020 at 08:21:23AM -0600, Simon Glass wrote:
> On Thu, 3 Sep 2020 at 07:51, Andy Shevchenko
> wrote:
> > On Thu, Sep 3, 2020 at 4:40 PM Andy Shevchenko
> > wrote:
> > > On Thu, Sep 03, 2020 at 07:15:59AM -0600, Simon Glass wrote:
...
> > > Hmm... Have you read this [1]? It may
Hi Andy,
On Thu, 3 Sep 2020 at 07:51, Andy Shevchenko wrote:
>
> On Thu, Sep 3, 2020 at 4:40 PM Andy Shevchenko
> wrote:
> > On Thu, Sep 03, 2020 at 07:15:59AM -0600, Simon Glass wrote:
>
> ...
>
> > Hmm... Have you read this [1]? It may give some hints I think.
> >
> > [1]:
On 03. 09. 20 15:59, Edgar E. Iglesias wrote:
> On Thu, Sep 03, 2020 at 02:52:39PM +0100, André Przywara wrote:
>> On 03/09/2020 14:41, Michal Simek wrote:
>>>
>>>
>>> On 02. 09. 20 20:59, André Przywara wrote:
On 02/09/2020 16:25, Edgar E. Iglesias wrote:
> On Wed, Sep 02, 2020 at
From: Laurentiu Tudor
In the current implementation, u-boot creates iommu mappings only
for PCI devices enumarated at boot time thus does not take into
account more dynamic scenarios such as SR-IOV or PCI hot-plug.
Add an u-boot env var and a device tree property (to be used for
example in more
From: Laurentiu Tudor
Add a few defines related to PCI ARI configuration.
Signed-off-by: Laurentiu Tudor
---
include/pci.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/include/pci.h b/include/pci.h
index 1c5b36617e..d1ccf6c963 100644
--- a/include/pci.h
+++ b/include/pci.h
@@
From: Laurentiu Tudor
Fix duplication of this code by placing it in a common function.
Furthermore, the resulting function will be re-used in upcoming
patches.
Signed-off-by: Laurentiu Tudor
---
drivers/pci/pcie_layerscape_fixup.c | 78 +
1 file changed, 36
From: Laurentiu Tudor
Move the pci device related fdt fixup in a function in order to
re-use it in a following patch. While at it, improve the error
handling.
Signed-off-by: Laurentiu Tudor
---
drivers/pci/pcie_layerscape_fixup.c | 60 -
1 file changed, 34
From: Laurentiu Tudor
In the current implementation, u-boot creates iommu mappings only
for PCI devices enumarated at boot time thus does not take into
account more dynamic scenarios such as SR-IOV or PCI hot-plug.
Add support for specifying extra IOMMU mappings for PCI
controllers through a
On Thu, Sep 03, 2020 at 02:52:39PM +0100, André Przywara wrote:
> On 03/09/2020 14:41, Michal Simek wrote:
> >
> >
> > On 02. 09. 20 20:59, André Przywara wrote:
> >> On 02/09/2020 16:25, Edgar E. Iglesias wrote:
> >>> On Wed, Sep 02, 2020 at 04:18:48PM +0100, Andr� Przywara wrote:
> On
On 03/09/2020 14:41, Michal Simek wrote:
>
>
> On 02. 09. 20 20:59, André Przywara wrote:
>> On 02/09/2020 16:25, Edgar E. Iglesias wrote:
>>> On Wed, Sep 02, 2020 at 04:18:48PM +0100, Andr� Przywara wrote:
On 02/09/2020 15:53, Edgar E. Iglesias wrote:
> On Wed, Sep 02, 2020 at
On Thu, Sep 3, 2020 at 4:40 PM Andy Shevchenko
wrote:
> On Thu, Sep 03, 2020 at 07:15:59AM -0600, Simon Glass wrote:
...
> Hmm... Have you read this [1]? It may give some hints I think.
>
> [1]: https://edison-fw.github.io/edison-wiki/u-boot-update (look into
> known-bugs section)
>
> > Any
On Thu, Sep 03, 2020 at 03:35:30PM +0200, Marek Vasut wrote:
> On 9/3/20 3:03 PM, Tom Rini wrote:
> > On Thu, Sep 03, 2020 at 02:14:35PM +0200, Marek Vasut wrote:
> >
> >> Mostly DFU fixes and r8152 fixes below:
> >>
> >> The following changes since commit
> >>
On Thu, Sep 03, 2020 at 01:08:13AM -0500, Samuel Holland wrote:
> Some boards, specifically 64-bit Allwinner boards (sun50i), are
> extremely limited on SPL size. One strategy that was used to make space
> was to remove the FIT "os" property parsing code, because it uses a
> rather large lookup
On 02. 09. 20 20:59, André Przywara wrote:
> On 02/09/2020 16:25, Edgar E. Iglesias wrote:
>> On Wed, Sep 02, 2020 at 04:18:48PM +0100, Andr� Przywara wrote:
>>> On 02/09/2020 15:53, Edgar E. Iglesias wrote:
On Wed, Sep 02, 2020 at 03:43:08PM +0100, Andr� Przywara wrote:
> On
On 03/09/2020 14:35, Michal Simek wrote:
>
>
> On 02. 09. 20 18:34, Stephen Warren wrote:
>> On 9/2/20 5:15 AM, Michal Simek wrote:
>>> From: "Edgar E. Iglesias"
>>>
>>> When U-Boot binary exceeds 1MB with CONFIG_POSITION_INDEPENDENT=y
>>> compilation error is shown:
>>>
On Thu, Sep 03, 2020 at 07:15:59AM -0600, Simon Glass wrote:
> Hi,
>
> I'd like to get edison running in my lab but it has resisted two
> attempts so far.
>
> My latest problem is that when I try the latest U-Boot, I get:
>
> U-Boot 2020.10-rc3-00012-g9f04a634ef3 (Sep 03 2020 - 07:06:30 -0600)
On 9/3/20 3:03 PM, Tom Rini wrote:
> On Thu, Sep 03, 2020 at 02:14:35PM +0200, Marek Vasut wrote:
>
>> Mostly DFU fixes and r8152 fixes below:
>>
>> The following changes since commit 23e333a5c083a000d0cabc53f7c0d261bae9e5ca:
>>
>> MAINTAINERS: step down as maintainer of UniPhier SoCs
On 02. 09. 20 18:34, Stephen Warren wrote:
> On 9/2/20 5:15 AM, Michal Simek wrote:
>> From: "Edgar E. Iglesias"
>>
>> When U-Boot binary exceeds 1MB with CONFIG_POSITION_INDEPENDENT=y
>> compilation error is shown:
>> /mnt/disk/u-boot/arch/arm/cpu/armv8/start.S:71:(.text+0x3c): relocation
>>
Hi Simon,
On 02. 09. 20 19:07, Simon Glass wrote:
> Hi Michal,
>
> On Wed, 2 Sep 2020 at 04:27, Michal Simek wrote:
>>
>> Hi Simon,
>>
>> On 01. 09. 20 13:13, Simon Glass wrote:
>>> This series allows binman to generate FITs that include multiple DTB
>>> images and the configuration to use
Hi,
I'd like to get edison running in my lab but it has resisted two
attempts so far.
My latest problem is that when I try the latest U-Boot, I get:
U-Boot 2020.10-rc3-00012-g9f04a634ef3 (Sep 03 2020 - 07:06:30 -0600)
CPU: Genuine Intel(R) CPU 4000 @ 500MHz
DRAM: 980.6 MiB
WDT:
On Thu, Sep 03, 2020 at 02:14:35PM +0200, Marek Vasut wrote:
> Mostly DFU fixes and r8152 fixes below:
>
> The following changes since commit 23e333a5c083a000d0cabc53f7c0d261bae9e5ca:
>
> MAINTAINERS: step down as maintainer of UniPhier SoCs (2020-08-31
> 17:11:24 -0400)
>
> are available in
Second update.
It turns out I was bit too aggressive in my "fix".
Unfortunately that is not cause of malfunction and
code is still unable to load files.
Any hint on how to proceed would be useful, current
plan is to add printouts to code to trace what happens,
but that is going to be a real PITA.
This patch makes buildman create linked working trees instead of clones
of the source repository, but keeps updating the older clones of the
repository that might already exist. These worktrees share "everything
except working directory specific files such as HEAD, index, etc." with
the source
Hi,
On 03. 09. 20 13:16, Heinrich Schuchardt wrote:
> On 9/3/20 1:03 PM, Michal Simek wrote:
>> Hi,
>>
>> We have several use cases where customers want to partition memory by
>> putting NS images above 4GB. On Xilinx arm 64bit SOC 0-2GB can be used for
>> others CPU in the systems (like R5) or
On Thu, Sep 03, 2020 at 12:02:06PM +1200, Chris Packham wrote:
> Setting CONFIG_ENV_ADDR to something other than 0 stops gd->env_addr
> from being allocated dynamically. When the environment is in SPI we need
> it to be allocated as we can't use a direct memory mapped address.
>
> Signed-off-by:
The following changes since commit 23e333a5c083a000d0cabc53f7c0d261bae9e5ca:
MAINTAINERS: step down as maintainer of UniPhier SoCs (2020-08-31
17:11:24 -0400)
are available in the Git repository at:
git://git.denx.de/u-boot-sh.git master
for you to fetch changes up to
Mostly DFU fixes and r8152 fixes below:
The following changes since commit 23e333a5c083a000d0cabc53f7c0d261bae9e5ca:
MAINTAINERS: step down as maintainer of UniPhier SoCs (2020-08-31
17:11:24 -0400)
are available in the Git repository at:
git://git.denx.de/u-boot-usb.git master
for you to
On Thu, Sep 3, 2020 at 4:23 PM Sean Anderson wrote:
>
> On 9/3/20 1:01 AM, Anup Patel wrote:
> > On Thu, Sep 3, 2020 at 8:19 AM Bin Meng wrote:
> >>
> >> Hi Anup,
> >>
> >> On Thu, Sep 3, 2020 at 10:46 AM Anup Patel wrote:
> >>>
> >>> On Thu, Sep 3, 2020 at 7:32 AM Bin Meng wrote:
>
>
Any thoughts on this issue?
Just to be sure, I did some memory testing on the 2GB module, but no
issues found.
I still somehow suspected that something else might be wrong with my
hardware, so I bought a new RPi4 (this time with 4GB of RAM) but the
very same with that:
U-Boot 2020.01 (Aug 23
On 9/3/20 1:03 PM, Michal Simek wrote:
> Hi,
>
> We have several use cases where customers want to partition memory by
> putting NS images above 4GB. On Xilinx arm 64bit SOC 0-2GB can be used for
> others CPU in the systems (like R5) or for secure sw.
> Currently there is limitation in SPL to
It was protected just for SPL_OS_BOOT but this function is only called when
SPL_ATF is enabled that's why change macro name.
Signed-off-by: Michal Simek
---
arch/arm/mach-zynqmp/handoff.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-zynqmp/handoff.c
The commit 9f45aeb93727 ("spl: fit: implement fdt_record_loadable") which
introduced fdt_record_loadable() state there spl_fit.c is not 64bit safe.
Based on my tests on Xilinx ZynqMP zcu102 platform there shouldn't be a
problem to record these addresses in 64bit format.
The patch adds support for
SPL is creating fit-images DT node when loadables are recorded in selected
configuration. Entries which are created are using entry-point and
load-addr property names. But there shouldn't be a need to use non standard
properties because entry/load are standard FIT properties. But using
standard
Hi,
We have several use cases where customers want to partition memory by
putting NS images above 4GB. On Xilinx arm 64bit SOC 0-2GB can be used for
others CPU in the systems (like R5) or for secure sw.
Currently there is limitation in SPL to record load/entry addresses in
64bit format because
Import updated device trees from Linux v5.9-rc3. This picks up new
hardware (PinePhone, PineTab); and it drops the U-Boot specific DTSI
files for the Pinebook and the Teres-I, since the ANX6345 bridge is
now supported upstream.
A couple of headers needed updates for recently-added hardware
On 9/3/20 1:01 AM, Anup Patel wrote:
> On Thu, Sep 3, 2020 at 8:19 AM Bin Meng wrote:
>>
>> Hi Anup,
>>
>> On Thu, Sep 3, 2020 at 10:46 AM Anup Patel wrote:
>>>
>>> On Thu, Sep 3, 2020 at 7:32 AM Bin Meng wrote:
Hi Anup,
On Tue, Aug 18, 2020 at 6:03 PM Sean Anderson wrote:
Small update, see below.
On 9/3/20 10:41 AM, Mauro Condarelli wrote:
> Hi,
> enabling squashfs on my target (vocore2) result in multiple errors:
>
>> /home/mcon/vocore/__V2__/Buildroot-2/recov/per-package/uboot/host/bin/mipsel-linux-ld.bfd:
>> fs/built-in.o: in function `sqfs_calc_n_blks':
>>
ATF support was all the time based on FIT image support but this dependency
is not recorded anywhere.
For !SPL_FIT && SPL_ATF there is compilation error:
common/spl/spl.c: In function 'board_init_r':
common/spl/spl.c:689:26: error: 'struct spl_image_info' has no member named
'fdt_addr'
689 |
From: Meenakshi Aggarwal
This patch add base support for LX2162AQDS board.
LX2162AQDS board supports LX2162A family SoCs.
This patch add basic support of platform.
Signed-off-by: Ioana Ciornei
Signed-off-by: Zhao Qiang
Signed-off-by: hui.song
Signed-off-by: Manish Tomar
Signed-off-by: Vikas
From: Meenakshi Aggarwal
LX2162 is LX2160 based SoC, it has same die as of LX2160
with different packaging.
LX2162A support 64-bit 2.9GT/s DDR4 memory, i2c, micro-click module,
microSD card, eMMC support, serial console, qspi nor flash, qsgmii,
sgmii, 25g, 40g, 50g network interface, one usb
From: Meenakshi Aggarwal
This patch set add support for LX2162AQDS board.
LX2162A is a variant of LX2160A.
---
Changes:
v2:
- Add Separate ARCH for LX2162A SoC
- Updated ReadMe of SoC and board
Meenakshi Aggarwal (2):
armv8: lx2162a: Add Soc changes to
Hi,
enabling squashfs on my target (vocore2) result in multiple errors:
> /home/mcon/vocore/__V2__/Buildroot-2/recov/per-package/uboot/host/bin/mipsel-linux-ld.bfd:
> fs/built-in.o: in function `sqfs_calc_n_blks':
> fs/squashfs/sqfs.c:(.text.sqfs_calc_n_blks+0x44): undefined reference to
>
Hi,
On Thu, Sep 03, 2020 at 12:07:08AM -0500, Samuel Holland wrote:
> All,
>
> This patch series implements a feature to automatically choose the
> right PinePhone device tree by probing the hardware. It then extends
> the functionality to pass the chosen DTB name to the boot command.
> Finally,
Hi Tom
Please pull one change for u-boot SoCFPGA.
Regards
Ley Foon
The following changes since commit 7149077353ef4837ab2fcdce5d7e52c5ed4b026a:
Azure/GitLab: Update to latest Docker container (2020-09-02 09:22:29 -0400)
are available in the Git repository at:
On 25/08/20 2:51 pm, Dario Binacchi wrote:
> The patch removes duplicate routines used by the two drivers.
>
> Signed-off-by: Dario Binacchi
Please squash it into previous patches.
Thanks and regards,
Lokesh
> ---
>
> drivers/clk/Makefile | 1 +
> drivers/clk/clk-ti-divider.c |
On 25/08/20 2:51 pm, Dario Binacchi wrote:
> The implementation of this driver was needed to bind the device tree
> sub-nodes of the 'clocks' node. In fact, the lack of the compatible
> property in the 'clocks' node does not allow the generic 'syscon' or
> 'simple-bus' drivers linked to the
Allwinner sun50i SoCs contain an OpenRISC 1000 CPU that functions as a
System Control Processor, or SCP. ARM Trusted Firmware (ATF)
communicates with the SCP over SCPI to implement the PSCI system suspend
and shutdown functionality. Currently, SCP firmware is optional; the
system will boot and run
Since commit d879616e9e64 ("spl: fit: simplify logic for FDT loading for
non-OS boots"), the SPL looks at the "os" properties of FIT images to
determine where to append the FDT.
The "os" property of the "firmware" image also determines how to execute
the next stage of the boot process, as in
Some boards, specifically 64-bit Allwinner boards (sun50i), are
extremely limited on SPL size. One strategy that was used to make space
was to remove the FIT "os" property parsing code, because it uses a
rather large lookup table.
However, this forces the legacy FIT parsing code path, which
79 matches
Mail list logo
