On Sun, Sep 6, 2020 at 4:51 AM Simon Glass wrote:
>
> There is a lot of information in the setup block and it is quite hard to
> decode manually. Add a 'zboot dump' command to decode it into a
> human-readable format.
>
> Signed-off-by: Simon Glass
> Reviewed-by: Wolfgang Wallner
> ---
>
>
On Sun, Sep 6, 2020 at 4:51 AM Simon Glass wrote:
>
> Add a subcommand that sets up the kernel ready for execution.
>
> Signed-off-by: Simon Glass
> Reviewed-by: Wolfgang Wallner
> ---
>
> Changes in v3:
> - Fix 'summary' typo
> - Move command help into the patch for each command
>
>
On Sun, Sep 6, 2020 at 4:51 AM Simon Glass wrote:
>
> This header is missing a few of the newer features from the specification.
> Add these as well as a link to the spec. Also use the BIT() macros where
> appropriate.
>
> Signed-off-by: Simon Glass
> Reviewed-by: Wolfgang Wallner
> ---
>
> (no
In functiion xhci_bulk_tx(), when buffer cross 64KB boundary, it will
send request in more than 1 Transfer TRB by chaining them, but then handle
only 1 event TRB to mark request completed.
However, on Layerscape platforms (LS1028A, LS1088A, etc), we observe xhci
controller will generated more
> This function is designed to be used when a timer used to be initialized by
> the cpu (e.g. RISC-V timers), but now is initialized by dm_timer_init. In
> such a case, the timer may prefer to use the clocks and clock-frequency
> properties, but should be able to fall back on using the cpu's
>
> The riscv-timer driver currently serves as a shim for several riscv timer
> drivers. This is not too desirable because it bypasses the usual timer
> selection via the driver model. There is no easy way to specify an
> alternate timing driver, or have the tick rate depend on the cpu's
>
Add check params function for Arria 10 (header v1).
>From [1] page 42, entry point offset should be 4 bytes aligned and
any value smaller than 0x14 is invalid.
Rename existing socfpgaimage_check_params() for v0.
[1]:
Add param entry point (ep) support for Arria 10 header. User can pass in
'e' option to mkimage to set the entry point. This is an optional option.
If not specified, default is 0x14.
Signed-off-by: Ley Foon Tan
---
tools/socfpgaimage.c | 21 +
1 file changed, 13
On 9/21/20 7:43 PM, André Przywara wrote:
> On 03/09/2020 06:07, Samuel Holland wrote:
>
> Hi,
>
>> Previously, fdtfile was always the value in CONFIG_DEFAULT_DEVICE_TREE.
>> This meant that, regardless of the DT chosen by SPL (either by changing
>> the header in the image or by the selection
On Mon, Sep 21, 2020 at 10:56:14PM +0200, Michael Walle wrote:
> Hi,
>
> Am 2020-09-21 20:50, schrieb Tom Rini:
> > On Mon, Sep 21, 2020 at 08:29:00PM +0200, Heinrich Schuchardt wrote:
> > > On 9/21/20 7:30 PM, Tom Rini wrote:
> > > > On Mon, Sep 21, 2020 at 11:01:37AM +0200, Stefan Roese wrote:
On 9/21/20 7:41 PM, André Przywara wrote:
> On 03/09/2020 06:07, Samuel Holland wrote:
>> This overwrites the name loaded from the SPL image. It will be different
>> if there was previously no name provided, or if a more accurate name was
>> determined by the board variant selection logic. This
> This ensures constructs like `if (gd & gd->...) { ... }` work when
> accessing the global data pointer. Without this change, it was possible for
> a very early trap to cause _exit_trap to directly or indirectly (through
> printf) to read arbitrary memory. This could cause a second trap,
>
> Even though we no longer call smp_function if an IPI was not sent by
> U-Boot, we still need to clear any IPIs which were pending from the
> execution environment. Otherwise, secondary harts will busy-wait in
> secondary_hart_loop, instead of relaxing.
>
> Along with the previous commit ("riscv:
> Clearing MIP.MSIP is not guaranteed to do anything by the spec. In
> addition, most existing RISC-V hardware does nothing when this bit is set.
>
> The following commits "riscv: Use a valid bit to ignore already-pending
> IPIs" and "riscv: Clear pending IPIs on initialization" should implement
>
On 9/21/20 10:56 PM, Michael Walle wrote:
> Hi,
>
> Am 2020-09-21 20:50, schrieb Tom Rini:
>> On Mon, Sep 21, 2020 at 08:29:00PM +0200, Heinrich Schuchardt wrote:
>>> On 9/21/20 7:30 PM, Tom Rini wrote:
>>> > On Mon, Sep 21, 2020 at 11:01:37AM +0200, Stefan Roese wrote:
>>> >> Hi Michael,
>>> >>
On 03/09/2020 06:07, Samuel Holland wrote:
Hi,
> Previously, fdtfile was always the value in CONFIG_DEFAULT_DEVICE_TREE.
> This meant that, regardless of the DT chosen by SPL (either by changing
> the header in the image or by the selection code at runtime), Linux
> always used the default DT.
>
On 03/09/2020 06:07, Samuel Holland wrote:
Hi,
> There are two different publicly-released revisions of the PinePhone
> hardware, versions 1.1 and 1.2; and they need different device trees.
> Since some GPIO pins were rerouted, we can use that to distinguish
> between them.
Nice one. I once had
On 03/09/2020 06:07, Samuel Holland wrote:
> This overwrites the name loaded from the SPL image. It will be different
> if there was previously no name provided, or if a more accurate name was
> determined by the board variant selection logic. This means that the DT> name
> in the SPL header now
On 03/09/2020 06:07, Samuel Holland wrote:
> Instead of using an entirely separate matching algorithm, simply update
> the name of the DT we want to match. Enabling this logic does not depend
> on the FIT config name, only on the initial guess of the board name.
Yeah, clever solution. The
On 03/09/2020 06:07, Samuel Holland wrote:
> This moves the validity checking and typecasts all to one place away
> from the string comparison logic, and it detangles the compile-time
> and runtime control flow.
>
> The new helper will also be used by U-Boot proper in a future commit.
>
>
On 03/09/2020 06:07, Samuel Holland wrote:
> The variable "cmp_str" always leaves me wondering if it is the DT name
> of the current board (yes) or DT name in the FIT config entry (no).
>
> In preparation for expanding the functionality here, rename it to
> something that obviously means "this is
On Tue, Sep 22, 2020 at 09:12:26AM +1200, Chris Packham wrote:
> Hi Tom,
>
> On Mon, Sep 7, 2020 at 10:37 AM 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
Hi Tom,
On Mon, Sep 7, 2020 at 10:37 AM 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:
On Tue, Sep 22, 2020 at 8:56 AM Michael Walle wrote:
>
> Hi,
>
> Am 2020-09-21 20:50, schrieb Tom Rini:
> > On Mon, Sep 21, 2020 at 08:29:00PM +0200, Heinrich Schuchardt wrote:
> >> On 9/21/20 7:30 PM, Tom Rini wrote:
> >> > On Mon, Sep 21, 2020 at 11:01:37AM +0200, Stefan Roese wrote:
> >> >> Hi
Hi,
Am 2020-09-21 20:50, schrieb Tom Rini:
On Mon, Sep 21, 2020 at 08:29:00PM +0200, Heinrich Schuchardt wrote:
On 9/21/20 7:30 PM, Tom Rini wrote:
> On Mon, Sep 21, 2020 at 11:01:37AM +0200, Stefan Roese wrote:
>> Hi Michael,
>> Hi Chris,
>>
>> On 15.09.20 12:44, Chris Packham wrote:
>>>
>>>
Hi Stefan,
Am 2020-09-21 11:01, schrieb Stefan Roese:
Hi Michael,
Hi Chris,
On 15.09.20 12:44, Chris Packham wrote:
On Tue, 15 Sep 2020, 7:54 PM Michael Walle, wrote:
Am 2020-09-15 09:44, schrieb Rayagonda Kokatanur:
> On Tue, Sep 15, 2020 at 12:56 PM Michael Walle
>
> From: Sean Anderson
> Sent: Monday, September 14, 2020 18:35
> To: u-boot@lists.denx.de; uboot-snps-...@synopsys.com
> Cc: Marek Vasut; Horatiu Vultur; Eugeniy Paltsev; Jagan Teki; Heinrich
> Schuchardt; Sean Anderson
> Subject: [PATCH v3 08/10] spi: dw: Add mem_ops
>
> Changes in v3:
> - Use
On Mon, Sep 21, 2020 at 08:29:00PM +0200, Heinrich Schuchardt wrote:
> On 9/21/20 7:30 PM, Tom Rini wrote:
> > On Mon, Sep 21, 2020 at 11:01:37AM +0200, Stefan Roese wrote:
> >> Hi Michael,
> >> Hi Chris,
> >>
> >> On 15.09.20 12:44, Chris Packham wrote:
> >>>
> >>>
> >>> On Tue, 15 Sep 2020, 7:54
On 9/21/20 7:30 PM, Tom Rini wrote:
> On Mon, Sep 21, 2020 at 11:01:37AM +0200, Stefan Roese wrote:
>> Hi Michael,
>> Hi Chris,
>>
>> On 15.09.20 12:44, Chris Packham wrote:
>>>
>>>
>>> On Tue, 15 Sep 2020, 7:54 PM Michael Walle, wrote:
>>>
>>> Am 2020-09-15 09:44, schrieb Rayagonda
Hey all,
It's release day and time for the final -rc prior to the final. I see a
few bugfixes out there I do want to grab related to PowerPC. I'm going
to pull this -rc in to -next as well as that should also unblock some
other changes as it pulls in a build time fix for rockchip in some
cases.
On Mon, Sep 21, 2020 at 10:14:11PM +0800, Bin Meng wrote:
> Hi Tom,
>
> This PR contains the following x86 changes for v2020.10:
>
> - Several ACPI bug fixes
> - Intel edison: Move config SYS_MALLOC_LEN to Kconfig
> - Use "emmc" in ApolloLake FSP devicetree bindings
>
> Azure results: PASS
>
On Mon, Sep 21, 2020 at 11:01:37AM +0200, Stefan Roese wrote:
> Hi Michael,
> Hi Chris,
>
> On 15.09.20 12:44, Chris Packham wrote:
> >
> >
> > On Tue, 15 Sep 2020, 7:54 PM Michael Walle, wrote:
> >
> > Am 2020-09-15 09:44, schrieb Rayagonda Kokatanur:
> > > On Tue, Sep 15, 2020 at
Hi Marek,
Thanks for the feedback.
> Subject: Re: [PATCH 1/2] arm: rmobile: Add RZ/G2M SoC
>
> On 9/21/20 12:30 PM, Biju Das wrote:
>
> [...]
>
> >> I don't think you need to modify anything then, the DT passed from
> >> TFA would contain the correct compatible string in / node, and that
> >>
The R8A774A1 is compatible with the generic rcar-gen3-xhci controller.
This patch adds the compatibility flag, to support the xHCI controller.
Signed-off-by: Lad Prabhakar
Reviewed-by: Biju Das
---
drivers/usb/host/xhci-rcar.c | 1 +
1 file changed, 1 insertion(+)
diff --git
Hi Heinrich
> From: U-Boot On Behalf Of Heinrich Schuchardt
> Sent: jeudi 17 septembre 2020 16:58
> To: Sughosh Ganu
> Cc: u-boot@lists.denx.de; Heinrich Schuchardt
> Subject: [PATCH 1/1] rng: stm32mp1: use log() instead of printf()
>
> The logging system provides flexible filtering and
On 9/21/20 12:23 PM, Heinrich Schuchardt wrote:
> On 21.09.20 13:51, Sean Anderson wrote:
>> This adds comments regarding the ordering and purpose of certain
>> instructions as I understand them.
>>
>> Signed-off-by: Sean Anderson
>> Reviewed-by: Bin Meng
>> Reviewed-by: Rick Chen
>>
This reverts commit 7c8f821e ("i2c: rcar_i2c: Set the
slave address from rcar_i2c_xfer"), as it blindly called
rcar_i2c_set_addr() with read argument always set to 1
during xfer which introduced read errors, whereas
earlier rcar_i2c_read_common() called rcar_i2c_set_addr()
with read set to 1 and
On 9/20/20 9:34 AM, Biju Das wrote:
Hi,
[...]
>>> if we remove writephyext, by looking the code at [1], rxc-skew-ps will be
>> taken from the device tree[3] and "txc-skew-pc" will be the default
>> value(0xf).
>>> [3]https://elixir.bootlin.com/u-boot/v2020.10-rc4/source/arch/arm/dts/
>>>
On 9/21/20 12:30 PM, Biju Das wrote:
[...]
>> I don't think you need to modify anything then, the DT passed from TFA
>> would contain the correct compatible string in / node, and that gets merged
>> into the U-Boot control DT early on in fdtdec_board_setup() in:
>>
On 21.09.20 13:51, Sean Anderson wrote:
> This adds comments regarding the ordering and purpose of certain
> instructions as I understand them.
>
> Signed-off-by: Sean Anderson
> Reviewed-by: Bin Meng
> Reviewed-by: Rick Chen
> Reviewed-by: Leo Liang
> ---
>
> (no changes since v2)
>
> Changes
> -Original Message-
> From: Andre Heider
> Sent: Tuesday, September 8, 2020 09:35
> To: Stefan Roese ; Kostya Porotchkin
> Cc: Pali Rohár ; u-boot@lists.denx.de
> Subject: [EXT] [PATCH] defconfig: espressobin: enable
> NET_RANDOM_ETHADDR
>
> External Email
>
>
Hi Bin,
On Sun, 20 Sep 2020 at 20:36, Bin Meng wrote:
>
> Hi Simon,
>
> On Mon, Sep 21, 2020 at 3:19 AM Simon Glass wrote:
> >
> > Hi Bin,
> >
> > At present I have a lot of x86 patches pending, such that it is very
> > difficult to make further progress.
> >
> > I'd like to suggest that we get
On Mon, Sep 21, 2020 at 03:31:14PM +0200, Pali Rohár wrote:
> On Monday 21 September 2020 15:21:44 Marek Behun wrote:
> > On Mon, 21 Sep 2020 15:05:22 +0200
> > Pali Rohár wrote:
> >
> > > Moreover CONFIG_NET_RANDOM_ETHADDR introduce another issue. In case
> > > there is no valid mac address,
Hi Tom,
This PR contains the following x86 changes for v2020.10:
- Several ACPI bug fixes
- Intel edison: Move config SYS_MALLOC_LEN to Kconfig
- Use "emmc" in ApolloLake FSP devicetree bindings
Azure results: PASS
https://dev.azure.com/bmeng/GitHub/_build/results?buildId=292=results
The
Hi Simon,
-"Simon Glass" schrieb: -
> Betreff: [PATCH v3 02/57] x86: acpi: Add base asl files for common x86 devices
>
> Add common x86 ASL files, taken from coreboot.
>
> Signed-off-by: Simon Glass
> ---
>
> (no changes since v1)
>
> arch/x86/include/asm/acpi/chromeos.asl| 108
On Monday 21 September 2020 15:21:44 Marek Behun wrote:
> On Mon, 21 Sep 2020 15:05:22 +0200
> Pali Rohár wrote:
>
> > Moreover CONFIG_NET_RANDOM_ETHADDR introduce another issue. In case
> > there is no valid mac address, U-Boot generates one. But it does not
> > pass this generates mac address
Hi Andre,
(added Simon)
On 18.09.20 19:45, Andre Przywara wrote:
The cfi-flash driver uses an open-coded version of the generic
algorithm to decode and translate multiple frames of a "reg" property.
This starts off the wrong foot by using the address-cells and size-cells
properties of *this*
On Mon, 21 Sep 2020 15:05:22 +0200
Pali Rohár wrote:
> Moreover CONFIG_NET_RANDOM_ETHADDR introduce another issue. In case
> there is no valid mac address, U-Boot generates one. But it does not
> pass this generates mac address to kernel and therefore kernel generates
> another new random mac
On Friday 11 September 2020 18:22:04 Marek Behún wrote:
> On Fri, 11 Sep 2020 17:52:26 +0200
> Andre Heider wrote:
>
> > Hi Marek,
> >
> > On 11/09/2020 13:55, Marek Behún wrote:
> > > On Wed, 9 Sep 2020 00:38:31 +0200 Pali Rohár
> > > wrote:
> > >> On Tuesday 08 September 2020 08:52:56 Tom
On Wed, Sep 16, 2020 at 05:53:35PM +0200, Martin Cerveny wrote:
> On Wed, 16 Sep 2020, Maxime Ripard wrote:
> > On Wed, Sep 16, 2020 at 04:10:51PM +0200, Martin Cerveny wrote:
> > > Add support for DE2 and TCON connected LCD display.
> > > Add support for export as "allwinner,simple-framebuffer"
>
On Wed, Sep 16, 2020 at 05:44:58PM +0200, Martin Cerveny wrote:
>
>
> On Wed, 16 Sep 2020, Maxime Ripard wrote:
> > On Wed, Sep 16, 2020 at 04:10:52PM +0200, Martin Cerveny wrote:
> > > Add PWM and dummy power regulator support.
> > > Modify data timings for LCD displays.
> > >
> > >
On Mon, Sep 21, 2020 at 02:50:56PM +0300, Andy Shevchenko wrote:
> On Sun, Sep 06, 2020 at 03:43:47PM -0600, Simon Glass wrote:
> > Generate ACPI information for this device so that Linux can use it
> > correctly.
>
> > + ret = acpi_device_write_interrupt_or_gpio(ctx, (struct udevice *)dev,
> >
This adds comments regarding the ordering and purpose of certain
instructions as I understand them.
Signed-off-by: Sean Anderson
Reviewed-by: Bin Meng
Reviewed-by: Rick Chen
Reviewed-by: Leo Liang
---
(no changes since v2)
Changes in v2:
- Clarify comments regarding tp
Even though we no longer call smp_function if an IPI was not sent by
U-Boot, we still need to clear any IPIs which were pending from the
execution environment. Otherwise, secondary harts will busy-wait in
secondary_hart_loop, instead of relaxing.
Along with the previous commit ("riscv: Use a
This ensures constructs like `if (gd & gd->...) { ... }` work when
accessing the global data pointer. Without this change, it was possible for
a very early trap to cause _exit_trap to directly or indirectly (through
printf) to read arbitrary memory. This could cause a second trap,
preventing
We can reduce the number of instructions needed to use available_harts_lock
by using the aq and rl suffixes for AMOs.
Signed-off-by: Sean Anderson
Reviewed-by: Bin Meng
Reviewed-by: Rick Chen
---
(no changes since v2)
Changes in v2:
- Remove fences after amoswaps
- Reword commit message
Clearing MIP.MSIP is not guaranteed to do anything by the spec. In
addition, most existing RISC-V hardware does nothing when this bit is set.
The following commits "riscv: Use a valid bit to ignore already-pending
IPIs" and "riscv: Clear pending IPIs on initialization" should implement
the
Without a matching barrier on the write side, the barrier in handle_ipi
does nothing. It was entirely possible for the boot hart to write to addr,
arg0, and arg1 *after* sending the IPI, because there was no barrier on the
sending side.
Fixes: 90ae281437 ("riscv: add option to wait for ack from
On the K210, the prior stage bootloader does not clear IPIs. This presents
a problem, because U-Boot up until this point assumes (with one exception)
that IPIs are cleared when it starts. This series attempts to fix this in a
robust manner, and fix several concurrency bugs I noticed while fixing
Some IPIs may already be pending when U-Boot is started. This could be a
problem if a secondary hart tries to handle an IPI before the boot hart has
initialized the IPI device.
To be specific, the Kendryte K210 ROM-based bootloader does not clear IPIs
before passing control to U-Boot. Without
On Sun, Sep 06, 2020 at 03:43:47PM -0600, Simon Glass wrote:
> Generate ACPI information for this device so that Linux can use it
> correctly.
> + ret = acpi_device_write_interrupt_or_gpio(ctx, (struct udevice *)dev,
> + "ready-gpios");
> + if
Hi Marek,
Thanks for the feedback.
> Subject: Re: [PATCH 1/2] arm: rmobile: Add RZ/G2M SoC
>
> On 9/19/20 8:35 PM, Biju Das wrote:
>
> Hi,
>
> [...]
>
> > +static const struct udevice_id *of_soc_match_compatible(void) {
> > +const struct udevice_id *of_match = soc_ids; int i;
> > +
>
Hello Rasmus,
Am 21.09.2020 um 09:48 schrieb Rasmus Villemoes:
Fix build failure, it used to get this implicitly through common.h
until f7ae49fc4f (common: Drop log.h from common header).
Signed-off-by: Rasmus Villemoes
---
drivers/gpio/mpc83xx_spisel_boot.c | 1 +
1 file changed, 1
Hi Rasmus,
Am 21.09.2020 um 10:40 schrieb Rasmus Villemoes:
On 17/09/2020 06.24, Heiko Schocher wrote:
Hello Rasmus,
Am 16.09.2020 um 21:35 schrieb Rasmus Villemoes:
We have a mpc8309-based board, currently using a U-Boot based on
v2020.04. If you have a git tree I can pull these patches
CC: linux-su...@googlegroups.com
сб, 13 июн. 2020 г. в 22:33, Roman Stratiienko :
>
> чт, 14 мая 2020 г. в 09:44, Roman Stratiienko :
> >
> > CC: ja...@amarulasolutions.com
> >
> > пт, 8 мая 2020 г. в 15:29, Roman Stratiienko :
> > >
> > > Same was done in the kernel for all devices compatible
On 17.09.20 18:07, Heinrich Schuchardt wrote:
Fix a typo
%s/interract/interact/
Use Samsung's capitalization of their trademarks
%s/onenand/OneNAND/
%s/Hyperflash/HyperFlash/
Please see nits below.
Signed-off-by: Heinrich Schuchardt
---
drivers/mtd/Kconfig | 6 +++---
1 file changed,
Hi Michael,
Hi Chris,
On 15.09.20 12:44, Chris Packham wrote:
On Tue, 15 Sep 2020, 7:54 PM Michael Walle, wrote:
Am 2020-09-15 09:44, schrieb Rayagonda Kokatanur:
> On Tue, Sep 15, 2020 at 12:56 PM Michael Walle
> wrote:
>>
>> Hi Stefan,
>>
>> it appears
On 17/09/2020 06.24, Heiko Schocher wrote:
> Hello Rasmus,
>
> Am 16.09.2020 um 21:35 schrieb Rasmus Villemoes:
>>
>> We have a mpc8309-based board, currently using a U-Boot based on
>> v2020.04. If you have a git tree I can pull these patches from I'll try
>> to test them on our hardware.
>
>
On Mon, Sep 21, 2020 at 4:34 PM Andy Shevchenko
wrote:
>
> The revisions are usually dates in hex-decimal format representing
> mmdd. Print them in hex to see this clearly.
>
> Before:
> ...
> FACP 000e5420 f4 (v06 U-BOOT U-BOOTBL 538970376 INTL 0)
> DSDT 000e4780 000ba0 (v02 U-BOOT
2d %.6s %.8s %x %.4s %x)\n", hdr->revision,
> >hdr->oem_id, hdr->oem_table_id, hdr->oem_revision,
> >hdr->aslc_id, hdr->aslc_revision);
> > } else {
> > --
>
> This unfortunately breaks the
The revisions are usually dates in hex-decimal format representing
mmdd. Print them in hex to see this clearly.
Before:
...
FACP 000e5420 f4 (v06 U-BOOT U-BOOTBL 538970376 INTL 0)
DSDT 000e4780 000ba0 (v02 U-BOOT U-BOOTBL 65536 INTL 538968870)
...
After:
...
FACP 000e5420
Hi Kosta,
On 13.09.20 11:21, Kostya Porotchkin wrote:
Good point, so let's assume the user doesn't have a mac stored.
Without CONFIG_NET_RANDOM_ETHADDR:
* u-boot refuses to do anything network related
* Linux generates a random mac, network works
With CONFIG_NET_RANDOM_ETHADDR:
* u-boot
Fix build failure, it used to get this implicitly through common.h
until f7ae49fc4f (common: Drop log.h from common header).
Signed-off-by: Rasmus Villemoes
---
drivers/gpio/mpc83xx_spisel_boot.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpio/mpc83xx_spisel_boot.c
The VIM3 on-board MCU can mux the PCIe/USB3.0 shared differential
lines using a FUSB340TMX USB 3.1 SuperSpeed Data Switch between
an USB3.0 Type A connector and a M.2 Key M slot.
The PHY driving these differential lines is shared between
the USB3.0 controller and the PCIe Controller, thus only
a
This imports the G12A & SM1 SoC and boards DT changes from the Linux
commit 9123e3a74ec7 ("Linux 5.9-rc1").
Signed-off-by: Neil Armstrong
Reviewed-by: Kevin Hilman
Tested-by: Kevin Hilman
---
arch/arm/dts/meson-g12-common.dtsi| 55 ---
arch/arm/dts/meson-g12b-odroid-n2.dts
Use the newly added VIM3 board support instead of the generic W400.
Signed-off-by: Neil Armstrong
Reviewed-by: Kevin Hilman
Tested-by: Kevin Hilman
---
configs/khadas-vim3_defconfig | 2 +-
configs/khadas-vim3l_defconfig | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git
The VIM3 on-board MCU can mux the PCIe/USB3.0 shared differential
lines using a FUSB340TMX USB 3.1 SuperSpeed Data Switch between
an USB3.0 Type A connector and a M.2 Key M slot.
The PHY driving these differential lines is shared between
the USB3.0 controller and the PCIe Controller, thus only
a
The VIM3 will need a specific code to enable PCIe if enabled in the MCU,
thus add a specific board support for VIM3 & VIM3L.
Signed-off-by: Neil Armstrong
Reviewed-by: Kevin Hilman
Tested-by: Kevin Hilman
---
board/amlogic/vim3/MAINTAINERS | 9 +
board/amlogic/vim3/Makefile| 6
> -Original Message-
> From: ChiaWei Wang
> Sent: Tuesday, September 8, 2020 3:21 PM
> To: Ryan Chen ; max...@google.com;
> u-boot@lists.denx.de
> Cc: BMC-SW
> Subject: [PATCH 1/2] reset: ast2500: Use SCU for reset control
>
> The System Control Unit (SCU) controller of Aspeed SoCs
> -Original Message-
> From: ChiaWei Wang
> Sent: Tuesday, September 8, 2020 3:21 PM
> To: Ryan Chen ; max...@google.com;
> u-boot@lists.denx.de
> Cc: BMC-SW
> Subject: [PATCH 2/2] cosmetic: reset: ast2500: Rename driver and configs
>
> 1. Rename AST2500 reset driver from
Remove NXP powerpc P5020DS board support as it is no
longer maintained.
Signed-off-by: Priyanka Jain
---
arch/powerpc/cpu/mpc85xx/Kconfig | 8 ---
board/freescale/common/Makefile| 1 -
board/freescale/corenet_ds/Kconfig | 15 --
Remove NXP powerpc P3041DS secure boot configs as they are
no longer maintained.
Signed-off-by: Priyanka Jain
---
board/freescale/corenet_ds/MAINTAINERS | 1 -
configs/P3041DS_NAND_SECURE_BOOT_defconfig | 62 --
configs/P3041DS_SECURE_BOOT_defconfig | 60
Remove NXP powerpc P5040DS secure boot configs as they are
no longer maintained.
Signed-off-by: Priyanka Jain
---
configs/P5040DS_NAND_SECURE_BOOT_defconfig | 63 --
configs/P5040DS_SECURE_BOOT_defconfig | 60 -
2 files changed, 123 deletions(-)
Remove NXP powerpc P4080DS secure boot configs as they are
no longer maintained.
Signed-off-by: Priyanka Jain
---
board/freescale/corenet_ds/MAINTAINERS | 1 -
configs/P4080DS_SECURE_BOOT_defconfig | 59 --
2 files changed, 60 deletions(-)
delete mode 100644
Remove NXP powerpc P1025RDB board support as it is no
longer maintained.
Signed-off-by: Priyanka Jain
---
arch/powerpc/cpu/mpc85xx/Kconfig| 9 ---
board/freescale/p1_p2_rdb_pc/Kconfig| 1 -
board/freescale/p1_p2_rdb_pc/MAINTAINERS| 5 --
Remove NXP powerpc P1024RDB board support as it is no
longer maintained.
Signed-off-by: Priyanka Jain
---
arch/powerpc/cpu/mpc85xx/Kconfig | 9 ---
board/freescale/p1_p2_rdb_pc/Kconfig | 1 -
board/freescale/p1_p2_rdb_pc/MAINTAINERS | 5 --
configs/P1024RDB_36BIT_defconfig
Remove NXP powerpc P1020MBG board support as it is no
longer maintained.
Signed-off-by: Priyanka Jain
---
arch/powerpc/cpu/mpc85xx/Kconfig | 9 ---
board/freescale/p1_p2_rdb_pc/Kconfig | 3 +-
board/freescale/p1_p2_rdb_pc/MAINTAINERS | 4 --
Remove NXP powerpc P1020UTM board support as it is no
longer maintained.
Signed-off-by: Priyanka Jain
---
arch/powerpc/cpu/mpc85xx/Kconfig | 9 ---
board/freescale/p1_p2_rdb_pc/Kconfig | 1 -
board/freescale/p1_p2_rdb_pc/MAINTAINERS | 4 --
Remove NXP powerpc P1021RDB board support as it is no
longer maintained.
Signed-off-by: Priyanka Jain
---
arch/powerpc/cpu/mpc85xx/Kconfig | 9 --
board/freescale/p1_p2_rdb_pc/Kconfig | 1 -
board/freescale/p1_p2_rdb_pc/MAINTAINERS | 8 --
Remove NXP powerpc P1010RDB secure boot configs as they are
no longer maintained.
Signed-off-by: Priyanka Jain
---
board/freescale/p1010rdb/MAINTAINERS | 12
.../P1010RDB-PA_36BIT_NAND_SECBOOT_defconfig | 65 --
.../P1010RDB-PA_36BIT_NOR_SECBOOT_defconfig | 64
Remove NXP powerpc p1023rdb board support as it is no
longer maintained.
Signed-off-by: Priyanka Jain
---
arch/powerpc/cpu/mpc85xx/Kconfig | 8 -
board/freescale/p1023rdb/Kconfig | 12 -
board/freescale/p1023rdb/MAINTAINERS | 6 -
board/freescale/p1023rdb/Makefile| 8 -
Remove some of NXP powerpc platforms support
which are no longer maintained.
Previous versions of uboot are recommended for use
Priyanka Jain (11):
board/freescale: Remove p1023rdb board support
configs: Remove P1010RDB secure boot configs
board/freescale: Remove P1025RDB board support
92 matches
Mail list logo
