has_been_read is only used as an optimization for do_tlv_eeprom.
Explicitly use and set inside this function, thus making read_eeprom
stateless.
Signed-off-by: Josua Mayer <josua@solid-run.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Cc: Stefan Roese <sr@denx.de>
Cc: Baruch Siach <baruch@tkos.co.il>
Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
Make tlv_eeprom command device selection an explicit parameter of all
function calls.
Signed-off-by: Josua Mayer <josua@solid-run.com>
Cc: Stefan Roese <sr@denx.de>
Cc: Baruch Siach <baruch@tkos.co.il>
Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
The Anbernic RGxx3 is a "pseudo-device" that encompasses the following
devices:
- Anbernic RG353M
- Anbernic RG353P
- Anbernic RG353V
- Anbernic RG353VS
- Anbernic RG503
The rk3566-anbernic-rgxx3.dtsi is synced with upstream Linux, but
rk3566-anbernic-rgxx3.dts is a U-Boot specific devicetree that
is used for all RGxx3 devices.
Via the board.c file, the bootloader automatically sets the correct
fdtfile, board, and board_name environment variables so that the
correct devicetree can be passed to Linux. It is also possible to
simply hard-code a single devicetree in the boot.scr file and use
that to load Linux as well.
The common specifications for each device are:
- Rockchip RK3566 SoC
- 2 external SDMMC slots
- 1 USB-C host port, 1 USB-C peripheral port
- 1 mini-HDMI output
- MIPI-DSI based display panel
- ADC controlled joysticks with a GPIO mux
- GPIO buttons
- A PWM controlled vibrator
- An ADC controlled button
All of the common features are defined in the devicetree synced from
upstream Linux.
TODO: DSI panel auto-detection for the RG353 devices (requires porting
of DSI controller driver and DSI-DPHY driver to send DSI commands to
the panel).
Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Some RK3399 boards, such as newer revisions of NanoPi R4S, do not
provide an EEPROM chip containing a globally unique MAC address.
Currently, this means that a randomly generated temporary MAC address
may be generated each time the device is rebooted, leading to ARP cache
issues and other confusing bugs.
Since RK3399 CPUs provide a built-in unique serial number, we can
reliably derive a locally MAC address from it by reading the
corresponding bits from the non-secure efuse block.
Enable configuration options that allow deriving a local MAC address
from the CPU serial number.
The DT specification supports CPUs with both 32-bit and 64-bit addressing
capabilities. In U-boot the fdt_addr_t and phys_addr_t size are coupled
by a typedef. The MTD NAND drivers for 32-bit CPU's can describe partitions
with a 64-bit reg property. These partitions synced from Linux end up with
the wrong offset and sizes when only the lower 32-bit is passed.
Decouple the fdt_addr_t and phys_addr_t size as they don't necessary
match.
Signed-off-by: Johan Jonker <jbx6244@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
The fdt_addr_t and phys_addr_t size have been decoupled.
A 32bit CPU can expect 64-bit data from the device tree parser,
so fix ofnode_get_addr_size function with fdt_addr_t input to
be able to handle both sizes for stm32mp SoC in spl.c file.
Signed-off-by: Johan Jonker <jbx6244@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The fdt_addr_t and phys_addr_t size have been decoupled. A 32bit CPU
can expect 64-bit data from the device tree parser, so fix some
debug strings with fdt_addr_t to be able to handle both sizes.
Signed-off-by: Johan Jonker <jbx6244@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The fdt_addr_t and phys_addr_t size have been decoupled. A 32bit CPU
can expect 64-bit data from the device tree parser, so use
devfdt_get_addr_ptr instead of the devfdt_get_addr function in
the various files in the drivers directory that cast to a pointer.
Signed-off-by: Johan Jonker <jbx6244@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The fdt_addr_t and phys_addr_t size have been decoupled. A 32bit CPU
can expect 64-bit data from the device tree parser, so use
devfdt_get_addr_index_ptr instead of the devfdt_get_addr_index function
in the various files in the drivers directory that cast to a pointer.
As we are there also streamline the error response to -EINVAL on return.
Signed-off-by: Johan Jonker <jbx6244@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The fdt_addr_t and phys_addr_t size have been decoupled. A 32bit CPU
can expect 64-bit data from the device tree parser, so use
devfdt_get_addr_size_index_ptr instead of the devfdt_get_addr_size_index
function in the various files in the drivers directory that cast to
a pointer.
Signed-off-by: Johan Jonker <jbx6244@gmail.com>
Reviewed-by: Michael Trimarchi <michael@amarulasolutions.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The fdt_addr_t and phys_addr_t size have been decoupled. A 32bit CPU
can expect 64-bit data from the device tree parser, so use
dev_read_addr_ptr instead of the dev_read_addr function in the
various files in the drivers directory that cast to a pointer.
As we are there also streamline the error response to -EINVAL on return.
Signed-off-by: Johan Jonker <jbx6244@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The fdt_addr_t and phys_addr_t size have been decoupled. A 32bit CPU
can expect 64-bit data from the device tree parser, so use
dev_read_addr_index_ptr instead of the dev_read_addr_index function
in the various files in the drivers directory that cast to a pointer.
As we are there also streamline the error response to -EINVAL on return.
Signed-off-by: Johan Jonker <jbx6244@gmail.com>
Reviewed-by: Michael Trimarchi <michael@amarulasolutions.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The fdt_addr_t and phys_addr_t size have been decoupled.
A 32bit CPU can expect 64-bit data from the device tree parser,
so use devfdt_get_addr_index_ptr and devfdt_get_addr_size_index_ptr
function in the spi-aspeed-smc.c file. Also fix dev_dbg to be able
to handle both sizes. As we are there also streamline the error
response to -EINVAL on return.
Signed-off-by: Johan Jonker <jbx6244@gmail.com>
Reviewed-by: Michael Trimarchi <michael@amarulasolutions.com>
Add dev_read_addr_index_ptr function with the
same functionality as dev_read_addr_index,
but instead a return pointer is given.
Use map_sysmem() function as cast for the return.
Make same fix for dev_read_addr_ptr() function.
Signed-off-by: Johan Jonker <jbx6244@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Add devfdt_get_addr_size_index_ptr function with the same
functionality as devfdt_get_addr_size_index, but instead
a return pointer is given.
Suggested-by: Michael Nazzareno Trimarchi <michael@amarulasolutions.com>
Signed-off-by: Johan Jonker <jbx6244@gmail.com>
Reviewed-by: Michael Trimarchi <michael@amarulasolutions.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The Rockchip SoC rk3288 has 2 types of device trees floating around.
A 64bit reg size when synced from Linux and a 32bit for U-boot.
A pre-probe function in the syscon class driver assumes only 32bit.
For other odd reg structures the regmap must be defined in the individual
syscon driver. Store rk3288 platdata in a regmap before pre-probe
during bind.
Signed-off-by: Johan Jonker <jbx6244@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
The fdt_addr_t and phys_addr_t size have been decoupled.
A 32bit CPU can expect 64-bit data from the device tree parser,
so convert regmap_init_mem_plat() input to handel both. The
syscon class driver also makes use of the regmap_init_mem_plat()
function, but has no way of knowing the format of the
device-specific platform data. In case of odd reg structures other
then that the syscon class driver assumes the regmap must be
filled in the individual syscon driver before pre-probe.
Also fix the ARRAY_SIZE divider in the syscon class driver.
Signed-off-by: Johan Jonker <jbx6244@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
When fdt_addr_t and phys_addr_t are split it turns out that
the header don't match the functions, so fix the headers.
Signed-off-by: Johan Jonker <jbx6244@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
The fdt_addr_t and phys_addr_t size have been decoupled.
A 32bit CPU can expect 64-bit data from the device tree parser,
so use a base variable with uintptr_t size in the
rk_spi.c file.
Signed-off-by: Johan Jonker <jbx6244@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The fdt_addr_t and phys_addr_t size have been decoupled.
A 32bit CPU can expect 64-bit data from the device tree parser,
so use a base variable with uintptr_t size in the
rk_pwm.c file.
Signed-off-by: Johan Jonker <jbx6244@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The fdt_addr_t and phys_addr_t size have been decoupled.
A 32bit CPU can expect 64-bit data from the device tree parser,
so use a regs variable with uintptr_t size in the
dw-apb-timer.c file.
Signed-off-by: Johan Jonker <jbx6244@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The fdt_addr_t and phys_addr_t size have been decoupled.
A 32bit CPU can expext 64-bit data from the device tree parser,
so use dev_read_addr_ptr in the rockchip-saradc.c file.
As we are there also streamline the error response to -EINVAL on return.
Signed-off-by: Johan Jonker <jbx6244@gmail.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Sandisk SDTNQGAMA is a 8GB size, 3.3V 8 bit chip with 16KB page size,
1KB write size and 40 bit ecc support
Signed-off-by: Paweł Jarosz <paweljarosz3691@gmail.com>
Signed-off-by: Johan Jonker <jbx6244@gmail.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Acked-by: Michael Trimarchi <michael@amarulasolutions.com>
The MTD framework reserves 1 or 2 bytes for the bad block marker
depending on the bus size. The rockchip_nfc driver currently only
supports a 8 bit bus, but reserves standard 2 bytes for the BBM.
The first free OOB byte is therefore OOB2 at offset 2.
Page address(PA) bytes are moved to the last 4 positions before
ECC. Update the description for U-boot.
Signed-off-by: Johan Jonker <jbx6244@gmail.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Add flash_node to the rockchip_nfc driver chip structure in order
to find the partitions in the add_mtd_partitions_of() function.
Signed-off-by: Johan Jonker <jbx6244@gmail.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Reviewed-by: Michael Trimarchi <michael@amarulasolutions.com>
The MTD framework in U-boot is not identical for drivers ported
from Linux. The rockchip_nfc driver was ported with OOB ops functions
while the framework expects a layout structure per chip.
Fix by adding a structure with OOB data and remove unused functions.
Signed-off-by: Johan Jonker <jbx6244@gmail.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Reviewed-by: Michael Trimarchi <michael@amarulasolutions.com>
The compatible string for rk3308 has as fallback string
"rockchip,rv1108-nfc". As there is no logic in probe priority between
the SoC orientated string and the fall back, so remove the compatible
string "rockchip,rk3308-nfc" from the driver.
Signed-off-by: Johan Jonker <jbx6244@gmail.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Reviewed-by: Michael Trimarchi <michael@amarulasolutions.com>
The fdt_addr_t and phys_addr_t size have been decoupled.
A 32bit CPU can expext 64-bit data from the device tree parser,
so use dev_read_addr_ptr in the rockchip_nfc.c file.
Signed-off-by: Johan Jonker <jbx6244@gmail.com>
Reviewed-by: Michael Trimarchi <michael@amarulasolutions.com>
Request the reset gpio of the rgmii-id phy as output to be consistent
with the eth-phy-uclass driver.
Signed-off-by: Stefan Herbrechtsmeier <stefan.herbrechtsmeier@weidmueller.com>
Reviewed-by: Michal Simek <michal.simek@amd.com>
Add minimal support for 8125B version.
Changes are based on the Linux driver.
Tested on Radxa Rock 5B Rk3588 board.
Connection to a laptop worked fine in 100 Mbps mode.
1000 Mbps mode is not working at the moment.
Signed-off-by: Eugen Hristev <eugen.hristev@collabora.com>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
Test the IPv6 network discovery feature if indicated by boardenv file.
Signed-off-by: Ehsan Mohandesi <emohandesi@linux.microsoft.com>
Reviewed-by: Viacheslav Mitrofanov <v.v.mitrofanov@yadro.com>
In IPv6, the default gateway and prefix length are determined by receiving
a router advertisement as defined in -
https://www.rfc-editor.org/rfc/rfc4861.
Add support for sending router solicitation (RS) and processing router
advertisements (RA).
If the RA has prefix info option and following conditions are met, then
gatewayip6 and net_prefix_length of ip6addr env variables are initialized.
These are later consumed by IPv6 code for non-local destination IP.
- "Router Lifetime" != 0
- Prefix is NOT link-local prefix (0xfe80::/10)
- L flag is 1
- "Valid Lifetime" != 0
Timing Parameters:
- MAX_RTR_SOLICITATION_DELAY (0-1s)
- RTR_SOLICITATION_INTERVAL (4s) (min retransmit delay)
- MAX_RTR_SOLICITATIONS (3 RS transmissions)
The functionality is enabled by CONFIG_IPV6_ROUTER_DISCOVERY and invoked
automatically from net_init_loop().
Signed-off-by: Ehsan Mohandesi <emohandesi@linux.microsoft.com>
Tested-by: Viacheslav Mitrofanov <v.v.mitrofanov@yadro.com>Reviewed-by:
Tested-by: Viacheslav Mitrofanov <v.v.mitrofanov@yadro.com>
Reviewed-by: Viacheslav Mitrofanov <v.v.mitrofanov@yadro.com>
Tested-by: Sergei Antonov <saproj@gmail.com>
Reviewed-by: Sergei Antonov <saproj@gmail.com>
Recent commit 75d28899e3 ("net: phy: Synchronize PHY interface modes
with Linux") reordered the enum definitions. This exposed a problem
in range checking functions to identify the interface type. Though
this specific api wasn't impacted (all the RGMII definitions remained
within range), this experience should be used to never to have to face
this kind of challenge again.
While it is possible for the phy drivers to use the enums directly,
drivers such as dp83867, dp83869, marvell, micrel_ksz90x1 etc use this
api.
Reported-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Marek Behún <kabel@kernel.org>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
Recent commit 75d28899e3 ("net: phy: Synchronize PHY interface modes
with Linux") reordered the enum definitions. This caused the range of
enums that this api was checking to go bad.
There aren't anymore users of phy_interface_is_sgmii, so, just drop
it. Also the protocols are so very different that it makes no sense to
provide a helper wrapper in the hope of reuse for phy drivers.
Reported-by: Tom Rini <trini@konsulko.com>
Suggested-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Suggested-by: Marek Behún <kabel@kernel.org>
Link: https://lore.kernel.org/all/20230414103852.38705065@dellmb/
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
dp83867 driver only supports sgmii and not all the newer protocols.
Drop the usage of the generic phy_interface_is_sgmii function and just
matchup to the specific mode supported.
Reported-by: Tom Rini <trini@konsulko.com>
Suggested-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Suggested-by: Marek Behún <kabel@kernel.org>
Link: https://lore.kernel.org/all/b82ac325-4818-8e72-054b-640268dbf806@mailbox.org/
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
Introduce reboot, boot and continue commands support to
TCP fastboot by moving existing UDP logic into the common module.
Signed-off-by: Dmitrii Merkurev <dimorinny@google.com>
Cc: Ying-Chun Liu (PaulLiu) <paul.liu@linaro.org>
Cc: Simon Glass <sjg@chromium.org>
Сс: Joe Hershberger <joe.hershberger@ni.com>
Сс: Ramon Fried <rfried.dev@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Known limitations are
1. fastboot reboot doesn't work (answering OK but not rebooting)
2. flashing isn't supported (TCP transport only limitation)
The command syntax is
fastboot tcp
Signed-off-by: Dmitrii Merkurev <dimorinny@google.com>
Cc: Ying-Chun Liu (PaulLiu) <paul.liu@linaro.org>
Cc: Simon Glass <sjg@chromium.org>
Сс: Joe Hershberger <joe.hershberger@ni.com>
Сс: Ramon Fried <rfried.dev@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Make following changes to unblock TCP fastboot support:
1. Implement being a TCP server support
2. Introduce dedicated TCP traffic handler (get rid of UDP signature)
3. Ensure seq_num and ack_num are respected in net_send_tcp_packet
function (make sure existing wget_cmd code is reflected with the fix)
Signed-off-by: Dmitrii Merkurev <dimorinny@google.com>
Cc: Ying-Chun Liu (PaulLiu) <paul.liu@linaro.org>
Cc: Simon Glass <sjg@chromium.org>
Сс: Joe Hershberger <joe.hershberger@ni.com>
Сс: Ramon Fried <rfried.dev@gmail.com>
Reviewed-by: Ying-Chun Liu (PaulLiu) <paul.liu@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
Requires proper environment with DHCP6 server provisioned.
Signed-off-by: Sean Edmond <seanedmond@microsoft.com>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
Adds commands to support DHCP and PXE with IPv6.
New configs added:
- CMD_DHCP6
- DHCP6_PXE_CLIENTARCH
- DHCP6_PXE_DHCP_OPTION
- DHCP6_ENTERPRISE_ID
New commands added (when IPv6 is enabled):
- dhcp6
- pxe get -ipv6
- pxe boot -ipv6
Signed-off-by: Sean Edmond <seanedmond@microsoft.com>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
Adds DHCPv6 protocol to u-boot.
Allows for address assignement with DHCPv6 4-message exchange
(SOLICIT->ADVERTISE->REQUEST->REPLY). Includes DHCPv6 options
required by RFC 8415. Also adds DHCPv6 options required
for PXE boot.
Possible enhancements:
- Duplicate address detection on DHCPv6 assigned address
- IPv6 address assignement through SLAAC
- Sending/parsing other DHCPv6 options (NTP, DNS, etc...)
Signed-off-by: Sean Edmond <seanedmond@microsoft.com>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
rtl8211e_startup() is an exact copy of genphy_startup(). Use that
instead of duplicating it.
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Read the phy mode of the external phy from the device tree if available
and check that it is a RGMII variant.
Signed-off-by: Stefan Herbrechtsmeier <stefan.herbrechtsmeier@weidmueller.com>
NFSv1 support added by Christian Gmeiner, Thomas Rienoessl,
September 27, 2018. As of now, NFSv3 is the default choice.
if the server does not support NFSv3, we fall back to
versions 2 or 1.
Signed-off-by: Thomas RIENOESSL <thomas.rienoessl@bachmann.info>
