From: Rafał Miłecki
Hi,
I'm a long time OpenWrt developer and just recently I started working
with some devices using U-Boot.
I was trying to understand how environment variables are read in user
space and I had some problems understanding fw_env_open() logic. I
eventually got it but I thought
From: Rafał Miłecki
Environment variables can be stored in two formats:
1. Single entry with header containing CRC32
2. Two entries with extra flags field in each entry header
For that reason fw_env_open() has two main code paths and there are
pointers for CRC32/flags/data.
Previous
From: Rafał Miłecki
It's usually easier to understand code & follow it if all arguments are
passed explicitly. Many coding styles also discourage using global
variables.
Behaviour of flash_io() was a bit unintuitive as it was writing to a
buffer referenced in a global struct. That requ
From: Rafał Miłecki
Hi,
I'm a long time OpenWrt developer and just recently I started working
with some devices using U-Boot.
I was trying to understand how environment variables are read in user
space and I had some problems understanding fw_env_open() logic. I
eventually got it but I thought
From: Rafał Miłecki
Environment variables can be stored in two formats:
1. Single entry with header containing CRC32
2. Two entries with extra flags field in each entry header
For that reason fw_env_open() has two main code paths and there are
pointers for CRC32/flags/data.
Previous
From: Rafał Miłecki
It's usually easier to understand code & follow it if all arguments are
passed explicitly. Many coding styles also discourage using global
variables.
Behaviour of flash_io() was a bit unintuitive as it was writing to a
buffer referenced in a global struct. That requ
From: Rafał Miłecki
It's usually easier to understand code & follow it if all arguments are
passed explicitly. Many coding styles also discourage using global
variables.
Behaviour of flash_io() was a bit unintuitive as it was writing to a
buffer referenced in a global struct. That requ
From: Rafał Miłecki
Hi,
I'm a long time OpenWrt developer and just recently I started working
with some devices using U-Boot.
I was trying to understand how environment variables are read in user
space and I had some problems understanding fw_env_open() logic. I
eventually got it but I thought
From: Rafał Miłecki
Environment variables can be stored in two formats:
1. Single entry with header containing CRC32
2. Two entries with extra flags field in each entry header
For that reason fw_env_open() has two main code paths and there are
pointers for CRC32/flags/data.
Previous
On 10.01.2022 21:19, Rafał Miłecki wrote:
@@ -516,7 +516,7 @@ int fw_env_flush(struct env_opts *opts)
*environment.crc = crc32(0, (uint8_t *) environment.data, ENV_SIZE);
/* write environment back to flash */
- if (flash_io(O_RDWR)) {
+ if (flash_io(O_RDWR
Hi,
On 15.02.2022 08:41, Michal Simek wrote:
On 2/14/22 21:10, Ricardo Salveti wrote:
This is a bit similar to the issue raised on iMX8-based targets a few
days ago, which is forcing the environment location based on the boot
mode and not allowing the user to use a different option via other
From: Rafał Miłecki
U-Boot uses environment variables for storing device setup data on
flash. That data usually needs to be accessed by a bootloader, kernel
and often user-space.
This binding allows describing environment data location and its format
clearly. In some/many cases it should
On 7.03.2022 11:24, Alexander Dahl wrote:
Hei hei,
just want to give a little more background here from embedded non
openwrt point of view. See below.
Am Mon, Feb 28, 2022 at 12:32:11PM +0100 schrieb Rafał Miłecki:
On 25.02.2022 17:42, Rob Herring wrote:
On Thu, Feb 17, 2022 at 02:02:35PM
On 10.03.2022 09:45, Michal Simek wrote:
On 3/9/22 16:40, Rob Herring wrote:
On Wed, Mar 09, 2022 at 02:42:43PM +0100, Michal Simek wrote:
On 2/28/22 14:12, Rafał Miłecki wrote:
From: Rafał Miłecki
U-Boot uses environment variables for storing device setup data. It
usually needs
On 9.03.2022 14:42, Michal Simek wrote:
On 2/28/22 14:12, Rafał Miłecki wrote:
From: Rafał Miłecki
U-Boot uses environment variables for storing device setup data. It
usually needs to be accessed by a bootloader, kernel and often
user-space.
This binding allows describing environment data
On 15.02.2022 15:02, Michal Simek wrote:
On 2/15/22 14:49, Rafał Miłecki wrote:
From: Rafał Miłecki
U-Boot uses environment variables for storing device setup data on
flash. That data usually needs to be accessed by a bootloader, kernel
and often user-space.
This binding allows describing
On 15.02.2022 15:57, Sean Anderson wrote:
On 2/15/22 9:02 AM, Michal Simek wrote:
On 2/15/22 14:49, Rafał Miłecki wrote:
From: Rafał Miłecki
U-Boot uses environment variables for storing device setup data on
flash. That data usually needs to be accessed by a bootloader, kernel
and often
From: Rafał Miłecki
U-Boot uses environment variables for storing device setup data. It
usually needs to be accessed by a bootloader, kernel and often
user-space.
This binding allows describing environment data located in a raw flash
partition. It's treated as NVMEM device and can be reused
From: Rafał Miłecki
U-Boot uses environment variables for storing device setup data. It
usually needs to be accessed by a bootloader, kernel and often
user-space.
This binding allows describing environment data located in a raw flash
partition. It's treated as NVMEM device and can be reused
On 25.02.2022 17:42, Rob Herring wrote:
On Thu, Feb 17, 2022 at 02:02:35PM +0100, Rafał Miłecki wrote:
From: Rafał Miłecki
U-Boot uses environment variables for storing device setup data. It
usually needs to be accessed by a bootloader, kernel and often
user-space.
How much
From: Rafał Miłecki
UBI is often used on embedded devices to store UBI volumes with device
configuration / calibration data. Such volumes may need to be documented
and referenced for proper boot & setup.
Some examples:
1. U-Boot environment variables
2. Device calibration data
3. Default s
From: Rafał Miłecki
This is RFC and request for a help & discussion.
While reviewing patch for U-Boot env binding it has been mentioned that:
1. /Processing/ whole DT in U-Boot may be too much work
Handling flash devices, partitions, their formats & NVMEM may require
too man
On 2.03.2022 22:59, Rob Herring wrote:
On Thu, Feb 17, 2022 at 11:24:48AM +0100, Rafał Miłecki wrote:
From: Rafał Miłecki
UBI is often used on embedded devices to store UBI volumes with device
configuration / calibration data. Such volumes may need to be documented
and referenced for proper
From: Rafał Miłecki
U-Boot stores its setup as environment variables. It's a list of
key-value pairs stored on flash device with a custom header.
This commit adds an NVMEM driver that:
1. Provides NVMEM access to environment vars binary data
2. Extracts variables as NVMEM cells
It can be used
From: Rafał Miłecki
Until this change MTD subsystem supported handling partitions only with
MTD partitions parsers. That's a specific / limited API designed around
partitions.
Some MTD partitions may however require different handling. They may
contain specific data that needs to be parsed
From: Rafał Miłecki
Broadcom uses U-Boot for some of their recent platforms like BCM4908.
They decided to use modified environment variables variables format
though. Their header includes 2 extra 32 b fields at the beginning.
The first field meaning is unknown, the second one stores length
From: Rafał Miłecki
U-Boot doesn't have cells at hardcoded addresses. They are stored in
internal format. It's still important to define relevant cells in DT so
NVMEM consumers can reference them.
Update binding to allow including basic cells as NVMEM device subnodes.
Signed-off-by: Rafał
From: Rafał Miłecki
Broadcom stores environment variables blocks inside U-Boot partition
itself. This driver finds & registers them.
Signed-off-by: Rafał Miłecki
---
drivers/mtd/parsers/Kconfig | 10
drivers/mtd/parsers/Makefile | 1 +
drivers/mtd/parsers/brcm_u-boot.c
From: Rafał Miłecki
Right now there is no (known) real reason for a custom binding for
standard U-Boot partitions. Broadcom's U-Boot however requires extra
handling - looking for environment variables subblocks. This commit adds
Broadcom specific binding.
Signed-off-by: Rafał Miłecki
From: Rafał Miłecki
U-Boot stores its setup as environment variables. It's a list of
key-value pairs stored on flash device with a custom header.
This commit adds an NVMEM driver that:
1. Provides NVMEM access to environment vars binary data
2. Extracts variables as NVMEM cells
Current Linux's
From: Rafał Miłecki
MTD subsystem API allows interacting with MTD devices (e.g. reading,
writing, handling bad blocks). So far a random driver could get MTD
device only by its name (get_mtd_device_nm()). This change allows
getting them also by a DT node.
This API is required for drivers
On 14.06.2022 08:45, Ahmad Fatoum wrote:
+ if (err && !mtd_is_bitflip(err)) {
+ dev_err(dev, "Failed to read from mtd: %d\n", err);
Nitpick: %pe
My "err" variable in int, not a pointer (I don't use PTR_ERR()).
+static int u_boot_env_add_cells(struct u_boot_env *priv,
From: Rafał Miłecki
U-Boot stores its setup as environment variables. It's a list of
key-value pairs stored on flash device with a custom header.
This commit adds an NVMEM driver that:
1. Provides NVMEM access to environment vars binary data
2. Extracts variables as NVMEM cells
Current Linux's
From: Rafał Miłecki
MTD subsystem API allows interacting with MTD devices (e.g. reading,
writing, handling bad blocks). So far a random driver could get MTD
device only by its name (get_mtd_device_nm()). This change allows
getting them also by a DT node.
This API is required for drivers
From: Rafał Miłecki
A new DT binding for describing environment data block has been added in
Linux's commit 5db1c2dbc04c ("dt-bindings: nvmem: add U-Boot environment
variables binding"). Once we get a proper Linux NVMEM driver it'll be
possible to use Linux's binary interface for
On 13.06.2022 16:04, Miquel Raynal wrote:
@@ -1154,6 +1154,34 @@ int __get_mtd_device(struct mtd_info *mtd)
}
EXPORT_SYMBOL_GPL(__get_mtd_device);
+/**
+ * of_get_mtd_device_by_node - obtain an MTD device associated with a given
node
+ *
+ * @np: device tree node
+ */
+struct mtd_info
Hi Rob, could you re-review my patch as I provided answers (see below), please?
On 3.03.2022 09:32, Rafał Miłecki wrote:
On 2.03.2022 22:59, Rob Herring wrote:
On Thu, Feb 17, 2022 at 11:24:48AM +0100, Rafał Miłecki wrote:
From: Rafał Miłecki
UBI is often used on embedded devices to store
From: Rafał Miłecki
U-Boot stores its setup as environment variables. It's a list of
key-value pairs stored on flash device with a custom header.
This commit adds an NVMEM driver that:
1. Provides NVMEM access to environment vars binary data
2. Extracts variables as NVMEM cells
It can be used
On 25.04.2022 03:20, Daniel Golle wrote:
On Mon, Apr 11, 2022 at 11:00:32AM +0200, Miquel Raynal wrote:
On Wed, 2022-04-06 at 14:32:24 UTC, =?utf-8?b?UmFmYcWCIE1pxYJlY2tp?= wrote:
From: Rafał Miłecki
Until this change MTD subsystem supported handling partitions only with
MTD partitions
On 4.05.2022 11:23, Ahmad Fatoum wrote:
Hello Rafał,
On 03.05.22 18:56, Rafał Miłecki wrote:
From: Rafał Miłecki
U-Boot stores its setup as environment variables. It's a list of
key-value pairs stored on flash device with a custom header.
This commit adds an NVMEM driver that:
1. Provides
On 2.08.2022 00:03, William Zhang wrote:
This driver supports the peripheral block timer found on the Broadcom
BCA SoCs. It is 30-bit up-count timer running at 50MHz and can be used
as the system clock source such as on BCM63138.
Signed-off-by: William Zhang
(...)
+static const struct
From: Rafał Miłecki
Broadcom uses U-Boot for a lot of their bcmbca familiy chipsets. U-Boot
stores its configuration in an environment data block.
Such blocks are usually stored on flash as a separated partition at
hardcoded address. Broadcom however decided to:
1. Store env data block inside U
From: Rafał Miłecki
U-Boot partition may contain subpartitions. For example Broadcom
includes environment data block in the middle of its U-Boot partition.
This allows describing Broadcom's U-Boot env data and will allow
referencing its NVMEM cell in the future.
Reg: 118f3fbe517f4 (&qu
On 18.10.2022 12:19, Conor Dooley wrote:
On Fri, Oct 14, 2022 at 04:09:40PM -0500, Rob Herring wrote:
On Fri, 30 Sep 2022 18:36:31 +0200, Rafał Miłecki wrote:
From: Rafał Miłecki
Broadcom uses U-Boot for a lot of their bcmbca familiy chipsets. U-Boot
stores its configuration
On 18.10.2022 17:50, Conor Dooley wrote:
On Tue, Oct 18, 2022 at 05:42:01PM +0200, Rafał Miłecki wrote:
From: Rafał Miłecki
U-Boot partition may contain subpartitions. For example Broadcom
includes environment data block in the middle of its U-Boot partition.
This allows describing
From: Rafał Miłecki
Broadcom uses U-Boot for a lot of their bcmbca familiy chipsets. They
decided to store U-Boot environment data inside U-Boot partition and to
use a custom header (with "uEnv" magic and env data length).
Add support for Broadcom's specific binding and their cus
On 7.04.2022 20:17, Rob Herring wrote:
On Thu, Apr 07, 2022 at 04:55:14AM -0700, Joel Peshkin wrote:
The first 32b value is a magic number (endian swapped mnemonic of "uEnv"
short for "u-boot environment"). Finding that magic number of a 4K
boundary followed by a length and then a u-boot
From: Rafał Miłecki
DT binding allows specifying NVMEM cells as NVMEM device (provider)
subnodes. Looks for such subnodes when building NVMEM cells.
This allows NVMEM consumers to use U-Boot environment variables.
Signed-off-by: Rafał Miłecki
---
drivers/nvmem/u-boot-env.c | 1 +
1 file
From: Rafał Miłecki
Broadcom uses U-Boot for a lot of their bcmbca familiy chipsets. U-Boot
stores its configuration in an environment data block.
Such blocks are usually stored on flash as a separated partition at
hardcoded address. Broadcom however decided to:
1. Store env data block inside U
On 3.07.2022 10:48, Rafał Miłecki wrote:
U-Boot doesn't have cells at hardcoded addresses. They are stored in
internal format. It's still important to define relevant cells in DT so
NVMEM consumers can reference them.
Update binding to allow including basic cells as NVMEM device subnodes
From: Rafał Miłecki
This fixes:
drivers/nvmem/u-boot-env.c:141:17: sparse: sparse: cast to restricted __le32
Reported-by: kernel test robot
Fixes: f955dc1445069 ("nvmem: add driver handling U-Boot environment variables")
Signed-off-by: Rafał Miłecki
---
drivers/nvmem/u-boot-env.c
From: Rafał Miłecki
U-Boot environment variables are stored in ASCII format so "ethaddr"
requires parsing into binary to make it work with Ethernet interfaces.
This includes support for indexes to support #nvmem-cell-cells = <1>.
Signed-off-by: Rafał Miłecki
---
drivers/nv
From: Rafał Miłecki
U-Boot's "ethaddr" environment variable is very often used to store
*base* MAC address. It's used as a base for calculating addresses for
multiple interfaces. It's done by adding proper values. Actual offsets
are picked by manufacturers and vary across devices.
From: Rafał Miłecki
Sometimes reading NVMEM cell value involves some data reformatting. It
requires passing updated size value to the caller. Support that.
It's required e.g. to provide properly formatted MAC address in case
it's stored in a non-binary format (e.g. using ASCII).
Signed-off
From: Rafał Miłecki
U-Boot environment variables can be found on various NVMEM devices (not
just MTD) so convert this driver to a generic layout one.
This way - thanks to using NVMEM generic API - this driver can be reused
in other scenarios.
For backward DT compatibility we need to support
From: Rafał Miłecki
U-Boot environment variables are stored in ASCII format so "ethaddr"
requires parsing into binary to make it work with Ethernet interfaces.
This includes support for indexes to support #nvmem-cell-cells = <1>.
Signed-off-by: Rafał Miłecki
---
drivers/nvmem
From: Rafał Miłecki
U-Boot's "ethaddr" environment variable is very often used to store
*base* MAC address. It's used as a base for calculating addresses for
multiple interfaces. It's done by adding proper values. Actual offsets
are picked by manufacturers and vary across devices.
From: Rafał Miłecki
U-Boot environment variables can be found of various underlaying storage
entities. This binding should be defined as a layout on top on NVMEM
device not a NVMEM device itself.
Signed-off-by: Rafał Miłecki
---
.../bindings/nvmem/layouts/nvmem-layout.yaml | 1 +
.../nvmem
From: Rafał Miłecki
Sometimes reading NVMEM cell value involves some data reformatting. It
requires passing updated size value to the caller. Support that.
It's required e.g. to provide properly formatted MAC address in case
it's stored in a non-binary format (e.g. using ASCII).
Signed-off
On 10.01.2023 13:19, Michael Walle wrote:
Hi,
Am 2023-01-10 11:54, schrieb Rafał Miłecki:
From: Rafał Miłecki
U-Boot environment variables are stored in ASCII format so "ethaddr"
requires parsing into binary to make it work with Ethernet interfaces.
This includes support f
From: Rafał Miłecki
This is required by layouts that need to read whole NVMEM space. It
applies to NVMEM devices without hardcoded layout (like U-Boot
environment data block).
Signed-off-by: Rafał Miłecki
---
drivers/nvmem/core.c | 13 +
include/linux/nvmem-consumer.h
From: Rafał Miłecki
This is required by layouts that need to read whole NVMEM space. It
applies to NVMEM devices without hardcoded layout (like U-Boot
environment data block).
Signed-off-by: Rafał Miłecki
---
V2: Drop "const" from "const size_t"
---
drivers/nvmem/c
From: Rafał Miłecki
Sometimes reading NVMEM cell value involves some data reformatting. it
may require resizing available buffer. Support that.
It's required e.g. to provide properly formatted MAC address in case
it's stored in a non-binary format (e.g. using ASCII).
Signed-off-by: Rafał
From: Rafał Miłecki
U-Boot environment variables can be found on various NVMEM devices (not
just MTD) so convert this driver to a generic layout one.
This way - thanks to using NVMEM generic API - this driver can be reused
in other scenarios.
For backward DT compatibility we need to support
From: Rafał Miłecki
U-Boot environment variables are stored in ASCII format so "ethaddr"
requires parsing into binary to make it work with Ethernet interfaces.
This includes support for indexes to support #nvmem-cell-cells = <1>.
Signed-off-by: Rafał Miłecki
---
drivers/nvmem
From: Rafał Miłecki
U-Boot environment variables can be found of various underlaying storage
entities. This binding should be defined as a layout on top on NVMEM
device not a NVMEM device itself.
Signed-off-by: Rafał Miłecki
---
.../bindings/nvmem/layouts/nvmem-layout.yaml | 1 +
.../nvmem
From: Rafał Miłecki
U-Boot's "ethaddr" environment variable is very often used to store
*base* MAC address. It's used as a base for calculating addresses for
multiple interfaces. It's done by adding proper values. Actual offsets
are picked by manufacturers and vary across devices.
On 28.11.2022 20:52, Tom Rini wrote:
On Tue, Nov 08, 2022 at 02:17:28PM +0800, Ying-Chun Liu (PaulLiu) wrote:
From: "Ying-Chun Liu (PaulLiu)"
Currently file transfers are done using tftp or NFS both
over udp. This requires a request to be sent from client
(u-boot) to the boot server.
The
From: Rafał Miłecki
Pass whole NVMEM cell struct and length pointer as arguments to callback
functions.
This allows:
1. Cells content to be modified based on more info
Some cells (identified by their names) contain specific data that
needs further processing. This can be e.g. MAC address
From: Rafał Miłecki
NVMEM consumers expect MAC in a byte-based format (see e.g.
nvmem_get_mac_address()). U-Boot environment data stores all values in
ASCII form.
Add post processing callback detecting "ethaddr" reads and reformat data
as expected. This fixes Ethernet drivers readin
From: Rafał Miłecki
Pass whole NVMEM cell struct and length pointer as arguments to callback
functions.
This allows:
1. Cells content to be modified based on more info
Some cells (identified by their names) contain specific data that
needs further processing. This can be e.g. MAC address
From: Rafał Miłecki
NVMEM consumers expect MAC in a byte-based format (see e.g.
nvmem_get_mac_address()). U-Boot environment data stores all values in
ASCII form.
Add post processing callback detecting "ethaddr" reads and reformat data
as expected. This fixes Ethernet drivers readin
On 26.01.2023 02:14, William Zhang wrote:
On 01/21/2023 03:43 PM, Linus Walleij wrote:
For BRCMNAND with 1-bit BCH ECC (BCH-1) such as used on the
D-Link DIR-885L and DIR-890L routers, we need to explicitly
select the ECC like this in the device tree:
nand-ecc-algo = "bch";
On 30.01.2023 11:56, Miquel Raynal wrote:
Hi Rafał,
zaj...@gmail.com wrote on Fri, 27 Jan 2023 13:57:04 +0100:
From: Rafał Miłecki
This is required by layouts that need to read whole NVMEM space. It
applies to NVMEM devices without hardcoded layout (like U-Boot
environment data block
From: Rafał Miłecki
U-Boot environment variables can be found on various NVMEM devices (not
just MTD) so convert this driver to a generic layout one.
This way - thanks to using NVMEM generic API - this driver can be reused
in other scenarios.
For backward DT compatibility we need to support
From: Rafał Miłecki
Sometimes reading NVMEM cell value involves some data reformatting. it
may require resizing available buffer. Support that.
It's required e.g. to provide properly formatted MAC address in case
it's stored in a non-binary format (e.g. using ASCII).
Signed-off-by: Rafał
From: Rafał Miłecki
U-Boot's "ethaddr" environment variable is very often used to store
*base* MAC address. It's used as a base for calculating addresses for
multiple interfaces. It's done by adding proper values. Actual offsets
are picked by manufacturers and vary across devices.
From: Rafał Miłecki
U-Boot environment variables can be found of various underlaying storage
entities. This binding should be defined as a layout on top on NVMEM
device not a NVMEM device itself.
Signed-off-by: Rafał Miłecki
Reviewed-by: Rob Herring
---
.../bindings/nvmem/layouts/nvmem
From: Rafał Miłecki
U-Boot environment variables are stored in ASCII format so "ethaddr"
requires parsing into binary to make it work with Ethernet interfaces.
This includes support for indexes to support #nvmem-cell-cells = <1>.
Signed-off-by: Rafał Miłecki
---
drivers/nvmem
From: Rafał Miłecki
This is required by layouts that need to read whole NVMEM space. It
applies to NVMEM devices without hardcoded layout (like U-Boot
environment data block).
Signed-off-by: Rafał Miłecki
---
V2: Drop "const" from "const size_t"
---
drivers/nvmem/c
On 17.10.2022 09:17, Rafał Miłecki wrote:
From: Rafał Miłecki
Broadcom uses U-Boot for a lot of their bcmbca familiy chipsets. They
decided to store U-Boot environment data inside U-Boot partition and to
use a custom header (with "uEnv" magic and env data length).
Add support for
From: Rafał Miłecki
Callback .read_post_process() is designed to modify raw cell content
before providing it to the consumer. So far we were dealing with
modifications that didn't affect cell size (length). In some cases
however cell content needs to be reformatted and resized.
It's required
From: Rafał Miłecki
This change is required for NVMEM consumers to get expected MAC address
from U-Boot env data variable "ethaddr".
To address some previous concerns:
1. Yes, U-Boot env binding & driver should be converted to NVMEM layout
2. My priority is to get working MAC rat
From: Rafał Miłecki
U-Boot's "ethaddr" environment variable is very often used to store
*base* MAC address. It's used as a base for calculating addresses for
multiple interfaces. It's done by adding proper values. Actual offsets
are picked by manufacturers and vary across devices.
From: Rafał Miłecki
U-Boot environment variables are stored in ASCII format so "ethaddr"
requires parsing into binary to make it work with Ethernet interfaces.
This includes support for indexes to support #nvmem-cell-cells = <1>.
Signed-off-by: Rafał Miłecki
---
drive
:12:24
+:
On 22/02/2023 17:22, Rafał Miłecki wrote:
@@ -1791,11 +1792,15 @@ ssize_t nvmem_device_cell_read(struct
nvmem_device *nvmem,
if (!nvmem)
return -EINVAL;
> + /* Cells with read_post_process hook may realloc buffer we
can't allow h
, 9 Mar 2023 10:53:07 >> +:
>> >>> On 09/03/2023 10:32, Miquel Raynal wrote:
>>>> Hi Srinivas,
>>>> >>>> srinivas.kandaga...@linaro.org wrote on Thu, 9 Mar 2023 10:12:24 >>>>
+:
>>>> >>>&g
From: Rafał Miłecki
U-Boot environment variables are stored in ASCII format so "ethaddr"
requires parsing into binary to make it work with Ethernet interfaces.
This includes support for indexes to support #nvmem-cell-cells = <1>.
Signed-off-by: Rafał Miłecki
---
drive
From: Rafał Miłecki
Sometimes reading NVMEM cell value involves some data reformatting. it
may require resizing available buffer. Support that.
It's required e.g. to provide properly formatted MAC address in case
it's stored in a non-binary format (e.g. using ASCII).
Signed-off-by: Rafał
From: Rafał Miłecki
U-Boot environment variables are stored using ASCII format. One of
important entries is "ethaddr" which contains base MAC address.
That NVMEM cell requires some extra processing when reading:
1. ASCII needs translating into binary MAC format
2. Final
From: Michael Walle
Instead of relying on the name the consumer is using for the cell, like
it is done for the nvmem .cell_post_process configuration parameter,
provide a per-cell post processing hook. This can then be populated by
the NVMEM provider (or the NVMEM layout) when adding the cell.
From: Rafał Miłecki
U-Boot's "ethaddr" environment variable is very often used to store
*base* MAC address. It's used as a base for calculating addresses for
multiple interfaces. It's done by adding proper values. Actual offsets
are picked by manufacturers and vary across devices.
On 5.08.2023 05:38, Marek Vasut wrote:
It's Broadcom PHY simply described as single-port
RGMII 10/100/1000BASE-T PHY. It requires disabling
delay skew and GTXCLK bits.
Ported from Linux kernel commit
0fc9ae1076697 ("net: phy: broadcom: add support for BCM54210E")
Signed-off-by: Marek Vasut
;)
AUX/SHD/bcm54xx_config_clock_delay update ported from Linux 6.5-rc4 commit
28e219aea0b9e ("net: phy: broadcom: drop brcm_phy_setbits() and use phy_set_bits()
instead")
Signed-off-by: Marek Vasut
Reviewed-by: Rafał Miłecki
From: Rafał Miłecki
1. Use nvmem_dev_size() and nvmem_device_read() to make this driver less
mtd dependent
2. Use nvmem_add_one_cell() to simplify adding NVMEM cells
Signed-off-by: Rafał Miłecki
---
drivers/nvmem/u-boot-env.c | 79 +-
1 file changed, 35
From: Rafał Miłecki
U-Boot env data is a way of storing firmware variables. It's a format
that can be used of top of various storage devices. Its binding should
be an NVMEM layout instead of a standalone device.
This patch adds layout binding which allows using it on top of MTD NVMEM
device
From: Rafał Miłecki
This patch moves all generic (NVMEM devices independent) code from NVMEM
device driver to NVMEM layout driver. Then it adds a simple NVMEM layout
code on top of it.
Thanks to proper layout it's possible to support U-Boot env data stored
on any kind of NVMEM device
From: Rafał Miłecki
This is required by layouts that need to read whole NVMEM content. It's
especially useful for NVMEM devices without hardcoded layout (like
U-Boot environment data block).
Signed-off-by: Rafał Miłecki
---
drivers/nvmem/core.c | 13 +
include/linux
On 14.12.2023 22:27, Simon Glass wrote:
On Thu, 14 Dec 2023 at 08:36, Rafał Miłecki wrote:
From: Rafał Miłecki
So far we had a property for "ethaddr" NVMEM cell containing base
Ethernet MAC address. The problem is vendors often pick non-standard
names for storing MAC(s) (other tha
On 18.12.2023 15:48, Rob Herring wrote:
On Mon, 18 Dec 2023 14:37:19 +0100, Rafał Miłecki wrote:
From: Rafał Miłecki
U-Boot env data is a way of storing firmware variables. It's a format
that can be used of top of various storage devices. Its binding should
be an NVMEM layout instead
1 - 100 of 120 matches
Mail list logo
