On Wed, Aug 26, 2020 at 5:31 PM Chunfeng Yun wrote:
>
> There some vendor quirks for MTK xHCI 0.96 host controller:
> 1. It defines some extra SW scheduling parameters for HW
>to minimize the scheduling effort for synchronous and
>interrupt endpoints. The parameters are put into reseved
t
On Wed, Sep 2, 2020 at 2:15 PM Frank Wunderlich wrote:
>
> From: Chunfeng Yun
>
> Use HCS_MAX_PORTS(p) instead of
> ((p & HCS_MAX_PORTS_MASK) >> HCS_MAX_PORTS_SHIFT)
>
> Signed-off-by: Chunfeng Yun
> ---
> drivers/usb/host/xhci.c | 3 +--
> include/usb/xhci.h | 2 --
> 2 files changed, 1 i
On Wed, Aug 26, 2020 at 5:31 PM Chunfeng Yun wrote:
>
> Use TRB_TYPE(p) instead of ((p) << TRB_TYPE_SHIFT)
>
> Signed-off-by: Chunfeng Yun
> ---
> v2: no changes
> ---
> drivers/usb/host/xhci-mem.c | 3 +--
> drivers/usb/host/xhci-ring.c | 11 +--
> include/usb/xhci.h | 1 -
On Fri, 4 Sep 2020, 12:16 AM Tom Rini, wrote:
> 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
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 0042e57
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
@@ -552,7
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 4G
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 a/arch/x86/dt
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: S
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 1aee2a1fc0d..40acd8
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 +
arch/x86
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 Glass
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 image
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 follow
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 wa
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 wha
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
functi
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 wrot
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.
>>
>> Sig
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:
>
> git://git.denx.
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 09
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: Atish
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 boot_from_devices(struct
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 Yamada
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 07:15:59AM
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
compila
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]: https://edison-fw.gi
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 04:1
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 s
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
@@ -495
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 insertio
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 insertion
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 spec
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 02
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 03:43:0
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 ide
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
> >> 23e333a5c083a000d0cabc53f7c0d261ba
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 ta
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 02/09/
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:
>>> /mnt/disk/u-boot/arch/ar
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 (2020-08-3
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
>> t
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 them.
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: Started
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 repo
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 fo
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 f5ba5c90d4b9c4d691a62e
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 202
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 recor
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 b/arch/a
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 s
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 FIT
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 the
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 support
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':
>> fs/
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 | s
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 3.0
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
> `__um
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,
77 matches
Mail list logo
