On 3/13/21 10:47 PM, Ilias Apalodimas wrote:
Document the command line options for efidebug and initrd loading
Signed-off-by: Ilias Apalodimas
---
doc/uefi/uefi.rst | 21 -
1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/doc/uefi/uefi.rst b/doc/uefi/uefi.rst
Hi Heinrich,
On Sun, Mar 14, 2021 at 08:31:20AM +0100, Heinrich Schuchardt wrote:
> On 3/13/21 10:47 PM, Ilias Apalodimas wrote:
> > A following patch introduces a different logic for loading initrd's
> > based on the EFI_LOAD_FILE2_PROTOCOL.
> > +/**
> > + * efi_get_file_size() - Get the size of
On Sun, Mar 14, 2021 at 08:19:49AM +0100, Heinrich Schuchardt wrote:
> > + * Caller must free the returned value
[...]
> > + */
> > +struct
> > +efi_device_path *efi_dp_from_lo(struct efi_load_option *lo,
> > + efi_uintn_t *size, efi_guid_t guid)
> > +{
> >
On 3/13/21 10:47 PM, Ilias Apalodimas wrote:
A following patch introduces a different logic for loading initrd's
based on the EFI_LOAD_FILE2_PROTOCOL.
Since similar logic can be applied in the future for other system files
(i.e DTBs), let's add some helper functions which will retrieve and
parse
On 3/13/21 10:47 PM, Ilias Apalodimas wrote:
On the following patches we allow for an initrd path to be stored in
Boot variables. Specifically we encode in the FIlePathList[] of
the EFI_LOAD_OPTIONS for each Boot variable.
The FilePathList[] array looks like this:
kernel - 0xff - VenMed
Document how to launch a QEMU session with eTSEC as a network device.
Signed-off-by: Bin Meng
Reviewed-by: Vladimir Oltean
---
(no changes since v1)
doc/board/emulation/qemu-ppce500.rst | 5 +
1 file changed, 5 insertions(+)
diff --git a/doc/board/emulation/qemu-ppce500.rst
b/doc/board
QEMU ppce500 target can dynamically instantiate an eTSEC device
if "-device eTSEC" is given to QEMU. This commit enables eTSEC
driver and the required fixed PHY driver to create a usable
network configuration using eTSEC.
Unlike a real world 85xx board that usually stores the eTSEC MAC
address in
QEMU ppce500 target can dynamically instantiate an eTSEC device on
a platform bus if "-device eTSEC" is given to QEMU. It is presented
as a "simple-bus" in the device tree, with an additional compatible
string "qemu,platform".
Let's create a virtual memory mapping for it in misc_init_r(), in
prepa
This adds a test case to verify reading of a simple-bus is
working as expected.
Signed-off-by: Bin Meng
Reviewed-by: Simon Glass
---
(no changes since v2)
Changes in v2:
- default y if SANDBOX for CONFIG_SIMPLE_BUS_CORRECT_RANGE
drivers/core/Kconfig | 1 +
test/dm/Makefile | 1 +
tes
At present we decode simple bus using the following assumption:
- parent #address-cells 1
- child #address-cells 1
- child #size-cells 1
However this might not always be the case.
Update to use fdt_addr_t and fdt_size_t in 'struct simple_bus_plat', and
use fdt_read_ranges() to correctly decode
At present the tsec driver uses a non-standard DT bindings to get
its base / size. The upstream Linux kernel seems to require
the base / size to be put under a subnode of the eTSEC node
with a name prefix "queue-group". This is not documented in the
kernel DT bindings, but it looks every dtsi fil
At present the Freescale TSEC node DT bindings doc requires a
property in the TSEC node. But this might not always be the case.
In the upstream Linux kernel, there is no DT bindings doc for it
but the kernel driver tests a subnode of a name prefixed with
"queue-group", as we can see from gfar_of_i
dev_remap_addr() eventually calls dev_read_addr_index(), while
pdata->iobase holds the return value of dev_read_addr() that calls
dev_read_addr_index() too. Such duplication can be avoided by using
map_physmem() directly.
Signed-off-by: Bin Meng
---
Changes in v3:
- new patch: net: tsec: Use ma
This adds a test case to test the new ofnode_phy_is_fixed_link() API.
Both the new and old DT bindings are covered.
Signed-off-by: Bin Meng
Reviewed-by: Simon Glass
---
Changes in v3:
- reuse the sandbox dsa nodes for the fixed-link testing
arch/sandbox/dts/test.dts | 6 +-
test/dm/of_e
From: Claudiu Manoil
The DSA sandbox driver is used for unit testing the DSA class code.
It implements a simple 2 port switch plus 1 CPU port, and uses a
very simple tag to identify the ports.
The DSA sandbox device is connected via CPU port to a regular Ethernet
sandbox device, called 'dsa-test
From: Vladimir Oltean
Now that the fixed phy driver has been fully adapted to OF APIs,
and dm_eth_phy_connect() already can handle the fixed phy, call
dm_eth_phy_connect() directly in the DM tsec driver.
Signed-off-by: Vladimir Oltean
Reviewed-by: Bin Meng
Tested-by: Bin Meng
Message-Id: <202
Update fixedphy_probe() to support the old DT binding.
Signed-off-by: Bin Meng
Reviewed-by: Ramon Fried
Reviewed-by: Vladimir Oltean
---
Changes in v3:
- sort variable definitions by line length
drivers/net/phy/fixed.c | 26 +++---
1 file changed, 23 insertions(+), 3 del
The printf statement doesn't end with a newline. Add it.
Signed-off-by: Bin Meng
Reviewed-by: Ramon Fried
Reviewed-by: Vladimir Oltean
---
(no changes since v1)
drivers/net/phy/fixed.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/phy/fixed.c b/drivers/net/p
The PHY driver ops should be made static.
Signed-off-by: Bin Meng
Reviewed-by: Ramon Fried
Reviewed-by: Vladimir Oltean
---
(no changes since v1)
drivers/net/phy/fixed.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/phy/fixed.c b/drivers/net/phy/fixe
Simplify the logic of phy_connect_fixed() by using the new API
ofnode_phy_is_fixed_link(), which brings additional bonus of
supporting the old DT bindings.
Signed-off-by: Bin Meng
Reviewed-by: Ramon Fried
Reviewed-by: Vladimir Oltean
---
(no changes since v1)
drivers/net/phy/phy.c | 16 +
At present phy_connect_gmii2rgmii() is implemented using a DM API
dev_of_offset() hence it cannot support a non-DM configuration.
Remove the non-DM version prototype of phy_connect_gmii2rgmii()
and make the driver depend on CONFIG_DM_ETH.
Signed-off-by: Bin Meng
Acked-by: Michal Simek
Reviewed-b
Following the same updates that were done to the fixed phy driver,
use ofnode_ APIs instead of fdt_ APIs so that the Xilinx PHY driver
can support live DT.
Signed-off-by: Bin Meng
---
(no changes since v2)
Changes in v2:
- move device tree parsing from xilinxgmiitorgmii_probe() to
xilinxgmii
From: Vladimir Oltean
On systems that use CONFIG_OF_LIVE, the "ofnode" type is defined
as const struct device_node *np, while on the flat DT systems it
is defined as a long of_offset into gd->fdt_blob.
It is desirable that the fixed PHY driver uses the higher-level
ofnode abstraction instead of
From: Vladimir Oltean
In drivers/net/phy/Kconfig, CONFIG_PHY_FIXED already depends on
CONFIG_DM_ETH, so the function prototype definition when
CONFIG_DM_ETH=n does nothing, so it can be dropped. It is also
never reachable, since the whole function is already under #ifdef
CONFIG_PHY_FIXED (which a
Switch to use the ofnode_phy_is_fixed_link() API which can support
both the new and old DT bindings.
Signed-off-by: Bin Meng
Reviewed-by: Ramon Fried
Reviewed-by: Vladimir Oltean
---
(no changes since v1)
net/mdio-uclass.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a
Introduce a helper API ofnode_phy_is_fixed_link() to detect whether
the ethernet controller connects to a fixed-link pseudo-PHY device.
Note there are two ways to describe a fixed PHY attached to an
Ethernet device:
- the new DT binding, where 'fixed-link' is a sub-node of the
Ethernet device
-
Per the upstream Linux kernel doc:
Documentation/devicetree/bindings/net/ethernet-controller.yaml
There are two ways to describe a fixed PHY attached to an Ethernet
device. This updates our dt-bindings doc to add the old DT bindings.
Signed-off-by: Bin Meng
Reviewed-by: Ramon Fried
Reviewed-
QEMU ppce500 machine can dynamically instantiate an eTSEC device
if "-device eTSEC" is given to QEMU.
This series updates the fixed-link ethernet PHY driver as well as
the Freescale eTSEC driver to support the QEMU ppce500 board.
3 patches related to fixed phy in v1 are dropped in v2 as the chang
Hi Marty,
On Sat, 13 Mar 2021 at 12:40, Marty E. Plummer wrote:
>
> On Wed, Mar 10, 2021 at 11:52:07PM -0500, Simon Glass wrote:
> > Hi,
> >
> > On Thu, 13 Aug 2020 at 13:35, Alper Nebi Yasak
> > wrote:
> > >
> > > Hi Simon, Marty,
> > >
> > > I'm interested in getting U-Boot to work with Kevin
On Wed, Mar 10, 2021 at 11:52:07PM -0500, Simon Glass wrote:
> Hi,
>
> On Thu, 13 Aug 2020 at 13:35, Alper Nebi Yasak
> wrote:
> >
> > Hi Simon, Marty,
> >
> > I'm interested in getting U-Boot to work with Kevin as well, but don't
> > have a Servo (or the willingness to open up the case yet), so
The UEFI spec allow a packed array of UEFI device paths in the
FilePathList[] of an EFI_LOAD_OPTION. The first file path must
describe the loaded image but the rest are OS specific.
Previous patches parse the device path and try to use the second
member of the array as an initrd. So let's modify e
Document the command line options for efidebug and initrd loading
Signed-off-by: Ilias Apalodimas
---
doc/uefi/uefi.rst | 21 -
1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/doc/uefi/uefi.rst b/doc/uefi/uefi.rst
index b3494c22e073..76402bc5cfaa 100644
--- a/do
Up to now we install EFI_LOAD_FILE2_PROTOCOL to load an initrd
unconditionally. Although we correctly return various EFI exit codes
depending on the file status (i.e EFI_NO_MEDIA, EFI_NOT_FOUND etc), the
kernel loader, only falls back to the cmdline interpreted initrd if the
protocol is not install
A following patch introduces a different logic for loading initrd's
based on the EFI_LOAD_FILE2_PROTOCOL.
Since similar logic can be applied in the future for other system files
(i.e DTBs), let's add some helper functions which will retrieve and
parse file paths stored in EFI variables.
Signed-off
On the following patches we allow for an initrd path to be stored in
Boot variables. Specifically we encode in the FIlePathList[] of
the EFI_LOAD_OPTIONS for each Boot variable.
The FilePathList[] array looks like this:
kernel - 0xff - VenMedia(initrd GUID) - initrd1 - 0x01 initrd2 - 0xff
We are redefining how u-boot locates the initrd to load via the kernel
LoadFile2 protocol. This selftest is not relevant any more, so remove
it. A new one will be added later
Signed-off-by: Ilias Apalodimas
Reviewed-by: Heinrich Schuchardt
---
lib/efi_selftest/Makefile | 1
Hi!
This is v2 of [1]
Changes since v1:
- minor coding style fixes from Heinrich
- changed the DP format. Instead of VenMedia - 0x01 - initrd, we skip
the 0x01 between VenMedia and the first file.
- final device path is stripped in efi_get_dp_from_boot() instead of
get_initrd_fp()
- Fi
+Tom Rini
Hi Mark,
On Sat, 13 Mar 2021 at 02:24, Mark Kettenis wrote:
>
> I'm working on support for Apple's M1 systems in U-Boot. The idea is
> that this can be used as a "payload" for the m1n1 bootloader that is
> being developed by Hector Martin for Asahi Linux in order to provide
> an UEFI
Hi,
Le 08/03/2021 à 01:12, Andre Przywara a écrit :
> On Sun, 7 Mar 2021 13:53:56 +0100
> Nicolas Boulenguez wrote:
>
> Hi,
>
>> From: Arnaud Ferraris
>>
>> The PineTab device-tree is already in u-boot, this commit adds the
>> corresponding
>> defconfig, based on pinephone_defconfig.
>>
>> Si
Hi Maxime,
Le 25/02/2021 à 21:58, Maxime Ripard a écrit :
> On Thu, Feb 25, 2021 at 05:02:40PM +, André Przywara wrote:
>> On 20/02/2021 12:14, Nicolas Boulenguez wrote:
>>> From: Arnaud Ferraris
>>>
>>> On a cellular phone, the vast majority of users can be expected to
>>> have no serial con
On Sat, Mar 13, 2021 at 10:05 AM Marek Behun wrote:
>
> On Sat, 13 Mar 2021 09:23:05 -0600
> Adam Ford wrote:
>
> > I have tested this on omap35_logic_somlv and the LTO flag removal
> > isn't necessary for the clock.o
> > Having the clock built with LTO saves 239 bytes in SPL with my
> > compiler
On Sat, 13 Mar 2021 09:23:05 -0600
Adam Ford wrote:
> I have tested this on omap35_logic_somlv and the LTO flag removal
> isn't necessary for the clock.o
> Having the clock built with LTO saves 239 bytes in SPL with my
> compiler. It's not a huge savings, but in SPL, we need as much as
> possibl
A previous patch had removed the GPIO nodes from being built
into the SPL Device tree, but CONFIG_SPL_GPIO_SUPPORT remained
which makes the MMC card detect fail and the board does not boot.
Fix this by disabling CONFIG_SPL_GPIO_SUPPORT.
Fixes: 6f1efe81aa84 ("configs: omap3/35_logic and omap3/35_lo
On Thu, Mar 4, 2021 at 10:32 AM Adam Ford wrote:
>
> With bd_info dropped from the data section, the Logic PD OMAP3 boards
> and AM3517 fail to boot. Enabling CONFIG_SPL_ALLOC_BD restores
> them.
>
> Fixes: 38d6b7ebdaee ("spl: Drop bd_info in the data section")
> Signed-off-by: Adam Ford
>
With
On Fri, Mar 12, 2021 at 7:43 AM Adam Ford wrote:
>
> On Fri, Mar 12, 2021 at 4:35 AM Marek Behún wrote:
> >
> > Adam Ford says that DM3730 needs board.c compiled without LTO flags.
> >
> > Also add clock.c, since it says in Makefile that it need different
> > flags.
> >
>
> Tested-by: Adam Ford
Hi Vladimir,
On Sat, Mar 13, 2021 at 8:29 PM Vladimir Oltean wrote:
>
> On Sat, Mar 13, 2021 at 02:14:36PM +0200, Vladimir Oltean wrote:
> > On Fri, Mar 12, 2021 at 09:35:43PM +0800, Bin Meng wrote:
> > > Introduce a helper API ofnode_phy_is_fixed_link() to detect whether
> > > the ethernet contr
Hi Vladimir,
On Sat, Mar 13, 2021 at 9:03 PM Vladimir Oltean wrote:
>
> On Fri, Mar 12, 2021 at 09:35:43PM +0800, Bin Meng wrote:
> > +bool ofnode_phy_is_fixed_link(ofnode eth_node, ofnode *phy_node)
> > +{
> > + bool found = false;
> > + ofnode node, subnode;
> > + int len;
> > +
> >
On Fri, Mar 12, 2021 at 09:36:02PM +0800, Bin Meng wrote:
> Document how to launch a QEMU session with eTSEC as a network device.
>
> Signed-off-by: Bin Meng
>
> ---
Reviewed-by: Vladimir Oltean
On Fri, Mar 12, 2021 at 09:36:01PM +0800, Bin Meng wrote:
> QEMU ppce500 target can dynamically instantiate an eTSEC device
> if "-device eTSEC" is given to QEMU. This commit enables eTSEC
> driver and the required fixed PHY driver to create a usable
> network configuration using eTSEC.
>
> Unlike
On Fri, Mar 12, 2021 at 09:36:00PM +0800, Bin Meng wrote:
> QEMU ppce500 target can dynamically instantiate an eTSEC device on
> a platform bus if "-device eTSEC" is given to QEMU. It is presented
> as a "simple-bus" in the device tree, with an additional compatible
> string "qemu,platform".
>
> L
On Fri, Mar 12, 2021 at 09:35:57PM +0800, Bin Meng wrote:
> At present the tsec driver uses a non-standard DT bindings to get
> its base / size. The upstream Linux kernel seems to require
> the base / size to be put under a subnode of the eTSEC node
> with a name prefix "queue-group". This is not
Hi Wan, I found a couple of issues while trying to apply/build this
patch series to latest v2021.04-rc branches:
- The defconfig for Unmatched has a typo:
arch/../configs/sifive_hifive_unmatched_fu740_defconfig:55:warning:
unexpected data: ONFIG_DM_PWM=y
- The DM_RESET config depends on TARGET_SI
On Fri, Mar 12, 2021 at 09:35:54PM +0800, Bin Meng wrote:
> From: Vladimir Oltean
>
> Now that the fixed phy driver has been fully adapted to OF APIs,
> and dm_eth_phy_connect() already can handle the fixed phy, call
> dm_eth_phy_connect() directly in the DM tsec driver.
>
> Signed-off-by: Vladi
On Fri, Mar 12, 2021 at 09:35:53PM +0800, Bin Meng wrote:
> Update fixedphy_probe() to support the old DT binding.
>
> Signed-off-by: Bin Meng
> Reviewed-by: Ramon Fried
> ---
>
> (no changes since v1)
>
> drivers/net/phy/fixed.c | 26 +++---
> 1 file changed, 23 insertion
On Fri, Mar 12, 2021 at 09:35:52PM +0800, Bin Meng wrote:
> The printf statement doesn't end with a newline. Add it.
>
> Signed-off-by: Bin Meng
> Reviewed-by: Ramon Fried
> ---
Reviewed-by: Vladimir Oltean
On Fri, Mar 12, 2021 at 09:35:51PM +0800, Bin Meng wrote:
> The PHY driver ops should be made static.
>
> Signed-off-by: Bin Meng
> Reviewed-by: Ramon Fried
> ---
Reviewed-by: Vladimir Oltean
On Fri, Mar 12, 2021 at 09:35:50PM +0800, Bin Meng wrote:
> Simplify the logic of phy_connect_fixed() by using the new API
> ofnode_phy_is_fixed_link(), which brings additional bonus of
> supporting the old DT bindings.
>
> Signed-off-by: Bin Meng
> Reviewed-by: Ramon Fried
> ---
Reviewed-by: V
On Fri, Mar 12, 2021 at 09:35:49PM +0800, Bin Meng wrote:
> At present phy_connect_gmii2rgmii() is implemented using a DM API
> dev_of_offset() hence it cannot support a non-DM configuration.
> Remove the non-DM version prototype of phy_connect_gmii2rgmii()
> and make the driver depend on CONFIG_DM
On Fri, Mar 12, 2021 at 09:35:47PM +0800, Bin Meng wrote:
> From: Vladimir Oltean
>
> In drivers/net/phy/Kconfig, CONFIG_PHY_FIXED already depends on
> CONFIG_DM_ETH, so the function prototype definition when
> CONFIG_DM_ETH=n does nothing, so it can be dropped. It is also
> never reachable, sinc
On Fri, Mar 12, 2021 at 09:35:46PM +0800, Bin Meng wrote:
> From: Vladimir Oltean
>
> On systems that use CONFIG_OF_LIVE, the "ofnode" type is defined
> as const struct device_node *np, while on the flat DT systems it
> is defined as a long of_offset into gd->fdt_blob.
>
> It is desirable that t
On Fri, Mar 12, 2021 at 09:35:45PM +0800, Bin Meng wrote:
> Switch to use the ofnode_phy_is_fixed_link() API which can support
> both the new and old DT bindings.
>
> Signed-off-by: Bin Meng
> Reviewed-by: Ramon Fried
> ---
Reviewed-by: Vladimir Oltean
On Fri, Mar 12, 2021 at 09:35:44PM +0800, Bin Meng wrote:
> This adds a test case to test the new ofnode_phy_is_fixed_link() API.
> Both the new and old DT bindings are covered.
>
> Signed-off-by: Bin Meng
> Reviewed-by: Simon Glass
> ---
The DSA sandbox patch adds three fixed-link nodes alread
On Fri, Mar 12, 2021 at 09:35:43PM +0800, Bin Meng wrote:
> +bool ofnode_phy_is_fixed_link(ofnode eth_node, ofnode *phy_node)
> +{
> + bool found = false;
> + ofnode node, subnode;
> + int len;
> +
> + /* new binding */
> + subnode = ofnode_find_subnode(eth_node, "fixed-link");
On Fri, Mar 12, 2021 at 09:35:42PM +0800, Bin Meng wrote:
> +- The old DT binding, where 'fixed-link' is a property with 5 cells
> + encoding various information about the fixed PHY, in the form of
> + .
> +
> + * 'phy_id', emulated PHY ID, choose any but unique to the all specified
> +fixed
On Fri, Mar 12, 2021 at 09:35:56PM +0800, Bin Meng wrote:
> At present the Freescale TSEC node DT bindings doc requires a
> property in the TSEC node. But this might not always be the case.
> In the upstream Linux kernel, there is no DT bindings doc for it
> but the kernel driver tests a subnode o
On Sat, Mar 13, 2021 at 02:14:36PM +0200, Vladimir Oltean wrote:
> On Fri, Mar 12, 2021 at 09:35:43PM +0800, Bin Meng wrote:
> > Introduce a helper API ofnode_phy_is_fixed_link() to detect whether
> > the ethernet controller connects to a fixed-link pseudo-PHY device.
> >
> > Note there are two way
On Fri, Mar 12, 2021 at 09:35:43PM +0800, Bin Meng wrote:
> Introduce a helper API ofnode_phy_is_fixed_link() to detect whether
> the ethernet controller connects to a fixed-link pseudo-PHY device.
>
> Note there are two ways to describe a fixed PHY attached to an
> Ethernet device:
>
> - the new D
On Fri, Mar 12, 2021 at 09:35:42PM +0800, Bin Meng wrote:
> Per the upstream Linux kernel doc:
>
> Documentation/devicetree/bindings/net/ethernet-controller.yaml
>
> There are two ways to describe a fixed PHY attached to an Ethernet
> device. This updates our dt-bindings doc to add the old DT b
I'm working on support for Apple's M1 systems in U-Boot. The idea is
that this can be used as a "payload" for the m1n1 bootloader that is
being developed by Hector Martin for Asahi Linux in order to provide
an UEFI implementation that can boot a standard arm64 OS.
My current code, which can be fo
69 matches
Mail list logo
