Age | Commit message (Collapse) | Author |
|
https://source.denx.de/u-boot/custodians/u-boot-rockchip into next
CI: https://source.denx.de/u-boot/custodians/u-boot-rockchip/-/pipelines/21113
- New board: Theobroma Systems SOM-RK3588-Q7 Tiger, ArmSoM Sige7 Rk3588;
- PX30 dts migrate to OF_UPSTREAM;
- Some other update on board or config;
|
|
Tom Rini <trini@konsulko.com> says:
Rework how the BLK symbol is used now that so much DM migration has been
completed.
|
|
At this point in the DM migration, all platforms enable DM. BLK requires
DM. Make BLK "def_bool y" in the cases it had been "default y" to make
this clearer. Now remove the symbol requirement from other places as it
is redundant here.
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
The ID of the PMIC is stored in the 2 16b registers but the only part
that matters right now is the 3 MSB, which make the 3 digits (in hex) of
the part number.
Right now, only RK808 was properly displayed, with this all currently
supported PMICs should display the proper part number.
Additionally, when the PMIC variant is not found, print that value
instead of the masked unshifted value as all PMICs we support for now
have their LSB ignored to represent the actual part number.
Tested on RK806 (RK3588 Jaguar), RK808 (RK3399 Puma) and RK809 (PX30
Ringneck).
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
|
|
When bcmgenet complete to write Rx buffer with the DMA,
some U-Boot commands write data to the buffer directly.
Those write data will become dirty in CPU cache.
After this driver calls free_pkt to the buffer,
the buffer is assigned as the future Rx buffer.
At some point, if bcmgenet writes to a buffer with DMA
and CPU cache flushes dirty data to the buffer,
the buffer is corrupted.
This patch calls flush_dcache_range in free_pkt
to immediately flush the data written by U-Boot command
and prevent data corruption.
This issue can be reproduced using wget on Raspberry Pi4.
If wget receives data larger than
RX_BUF_LENGTH * RX_DESCS = 2048 * 256 bytes,
it will timeout due to data corruption.
In addition, if LOG_DEBUG is enabled in net/tcp.c,
the following error log is output.
TCP RX TCP xSum Error
Signed-off-by: Yasuharu Shibata <yasuharu.shibata@gmail.com>
|
|
Switch PHY_ANEG_TIMEOUT to CONFIG_PHY_ANEG_TIMEOUT Kconfig symbol.
This removes one more configuration headers option finalizes its
Kconfig symbol conversion. No functional change expected.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
|
|
Let users configure default auto-negotiation timeout via Kconfig
instead of specifying it in board configuration headers. This is
the first step toward converting this to Kconfig fully, so far the
legacy PHY_ANEG_TIMEOUT in configuration headers takes precedence.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
|
|
Manorit Chawdhry <m-chawdhry@ti.com> says:
The series enables ospi boot for j721s2.
Test logs: https://gist.github.com/manorit2001/6bb91885c608e3a8cb0267ab2c614781
|
|
On DTR capable flashes like Micron Xcella the writes cannot start or end
at an odd address in DTR mode. Extra 0xff bytes need to be prepended or
appended respectively to make sure both the start and end addresses are
even.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
Signed-off-by: Apurva Nandan <a-nandan@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Tested-by: Jonathan Humphreys <j-humphreys@ti.com>
Signed-off-by: Manorit Chawdhry <m-chawdhry@ti.com>
|
|
pr_info() depends on CONFIG_LOGLEVEL > 6. If user has
enabled CONFIG_TI_GPMC_DEBUG then we should print the
GPMC settings/timings regardless of CONFIG_LOGLEVEL.
So use printf() instead of pr_info().
Signed-off-by: Roger Quadros <rogerq@kernel.org>
|
|
Udit Kumar <u-kumar1@ti.com> says:
Some use case needs rproc firmware to be loaded at u-boot stage,
using following commands at u-boot shell, firmware could be loaded
=> setenv dorprocboot 1
=> run boot_rprocs
For Secure devices, secure version of rproc firmware should be loaded,
which is appended by sec keyword[0].
but currently non-secure firmware is loaded even for secure devices.
So adding support for loading secure firmware on Secured devices.
[0]: https://gist.github.com/uditkumarti/cd8bf6a448079b59145d17a0e8bf13b7
Bootlogs:
GP : https://gist.github.com/uditkumarti/23a00c313e1c28b62537aab733a585df#file-gp_device line 65 onwards
HS : https://gist.github.com/uditkumarti/23a00c313e1c28b62537aab733a585df#file-hs-device line 60 onwards
|
|
Remoteproc firmware images aren't authenticated in the current boot flow.
Authenticates remoteproc firmware images to complete the root of trust
in secure booting.
Signed-off-by: Manorit Chawdhry <m-chawdhry@ti.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> # Intel Edison
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
|
|
Prepare v2024.070-rc4
|
|
Signed-off-by: Leo Yu-Chi Liang <ycliang@andestech.com>
|
|
https://source.denx.de/u-boot/custodians/u-boot-tpm
TPM fixes
|
|
Instead of displaying what looks like an error message if a
gpio-reset dt prop is missing for a TPM display a warning that
having a gpio reset on a TPM should not be used for a secure production
device.
TCG TIS spec [1] says:
"The TPM_Init (LRESET#/SPI_RST#) signal MUST be connected to the
platform CPU Reset signal such that it complies with the requirements
specified in section 1.2.7 HOST Platform Reset in the PC Client
Implementation Specification for Conventional BIOS."
The reasoning is that you should not be able to toggle a GPIO and reset
the TPM without resetting the CPU as well because if an attacker can
break into your OS via an OS level security flaw they can then reset the
TPM via GPIO and replay the measurements required to unseal keys
that you have otherwise protected.
Additionally restructure the code for improved readability allowing for
removal of the init label.
Before:
- board with no reset gpio
u-boot=> tpm init && tpm info
tpm_tis_spi_probe: missing reset GPIO
tpm@1 v2.0: VendorID 0x1114, DeviceID 0x3205, RevisionID 0x01 [open]
- board with a reset gpio
u-boot=> tpm init && tpm info
tpm@1 v2.0: VendorID 0x1114, DeviceID 0x3205, RevisionID 0x01 [open]
After:
- board with no reset gpio
u-boot=> tpm init && tpm info
tpm@1 v2.0: VendorID 0x1114, DeviceID 0x3205, RevisionID 0x01 [open]
- board with a reset gpio
u-boot=> tpm init && tpm info
tpm@1: TPM gpio reset should not be used on secure production devices
tpm@1 v2.0: VendorID 0x1114, DeviceID 0x3205, RevisionID 0x01 [open]
[1] https://trustedcomputinggroup.org/wp-content/uploads/TCG_PCClientTPMInterfaceSpecification_TIS__1-3_27_03212013.pdf
Signed-off-by: Tim Harvey <tharvey@gateworks.com>
Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
|
|
Sughosh Ganu <sughosh.ganu@linaro.org> says:
The following patch series adds support for version 2 of the FWU
metadata. The version 2 metadata structure is defined in the latest
revision of the FWU specification [1].
The earlier versions of these patches were migrating to a version 2
only support in U-Boot, similar to TF-A. However, based on feedback
from ST [2], this series has been updated to support both versions. A
platform would still be needed to enable one of the two versions of
metadata through a config symbol.
TF-A has code which reads the FWU metadata and boots the platform from
the active partition. TF-A has decided to migrate the FWU code to a
version 2 only support. These changes have been merged in upstream
TF-A.
These changes have been tested on the ST DK2 board, which uses the GPT
based partitioning scheme. Both V1 and V2 metadata versions have been
tested on the DK2 board.
These changes need to be tested on platforms with MTD partitioned
storage devices.
|
|
The FWU metadata access driver for MTD partitioned devices currently
uses a statically allocated array for storing the updatable image
information. This array depends on the number of banks and images per
bank. With migration of the FWU metadata to version 2, these
parameters are now obtained at runtime from the metadata.
Make changes to the FWU metadata access driver for MTD devices to
allocate memory for the image information dynamically in the driver's
probe function, after having obtained the number of banks and images
per bank by reading the metadata. Move the image information as part
of the driver's private structure, instead of using a global variable.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Tested-by: Michal Simek <michal.simek@amd.com>
|
|
In version 2 of the metadata structure, the size of the structure
cannot be determined statically at build time. The structure is now
broken into the top level structure which contains a field indicating
the total size of the structure.
Add a size parameter to the metadata access API functions to indicate
the number of bytes to be accessed. This is then used to either read
the entire structure, or only the top level structure.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Tested-by: Michal Simek <michal.simek@amd.com>
|
|
All parts expect the SPLL to run at 702MHz. In U-Boot it's the SPLL_HZ
declaring this rate and in the kernel it's a fixed clock definition.
While everything is expecting 702MHz, the SPLL is not running that
frequency when coming from the bootrom though, instead it's running
at 351MHz and the vendor-u-boot just sets it to the expected frequency.
The SPLL itself is located inside the secure-BUSCRU and in theory
accessible as an SCMI clock, though this requires an unknown amount
of cooperation from trusted-firmware to set at a later stage, though
during the SPL stage we can still access the relevant CRU directly.
The SPLL is for example necessary for the DSI controllers to produce
output.
As the SPLL is "just" another rk3588 pll, just set the desired rate
directly during the SPL stage.
Tested on rk3588-rock5b and rk3588-tiger by reading back the PLL rate
and also observing working DSI output with this change.
Fixes: 6737771600d4 ("rockchip: rk3588: Add support for sdmmc clocks in SPL")
Suggested-by: Andy Yan <andy.yan@rock-chips.com>
Signed-off-by: Heiko Stuebner <heiko.stuebner@cherry.de>
Cc: Jonas Karlman <jonas@kwiboo.se>
Cc: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
|
Raymond Mao <raymond.mao@linaro.org> says:
This patch set is picked from the previously posted serie:
"[RFC] Integrate MbedTLS v3.6 LTS with U-Boot"
They are not directly related to MbedTLS integration, but the
prerequisite for a few clean-up, refactoring and minor fixes.
For V2, the linker script patch is dropped and added one patch
to move the snprintf to stdio.h
|
|
Move snprintf to stdio.h since it is needed by exteranl libraries.
Signed-off-by: Raymond Mao <raymond.mao@linaro.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
|
|
Use of typedef is beneficial for porting with other crypto libs
without changing the API callers.
Secondly, it is for the code consistency with other digest libs.
SHA1, SHA256 and SHA512 are all using typedef for their context.
Signed-off-by: Raymond Mao <raymond.mao@linaro.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
|
|
As part of bringing the master branch back in to next, we need to allow
for all of these changes to exist here.
Reported-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
Prepare v2024.07-rc3
|
|
When bringing in the series 'arm: dts: am62-beagleplay: Fix Beagleplay
Ethernet"' I failed to notice that b4 noticed it was based on next and
so took that as the base commit and merged that part of next to master.
This reverts commit c8ffd1356d42223cbb8c86280a083cc3c93e6426, reversing
changes made to 2ee6f3a5f7550de3599faef9704e166e5dcace35.
Reported-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
Use dt-binding definations for the phy switch connection.
It declares the target usb controller it is connected to.
Signed-off-by: Jim Liu <JJLIU0@nuvoton.com>
|
|
Linux kernel Documentation/devicetree/bindings/gpio/gpio.txt define the
format of the gpio-ranges prop as:
The format is: <[pin controller phandle], [GPIO controller offset],
[pin controller offset], [number of pins]>;
Example:
gpio-ranges = <&foo 0 20 10>, <&bar 10 50 20>;
This means:
- pins 20..29 on pin controller "foo" is mapped to GPIO line 0..9 and
- pins 50..69 on pin controller "bar" is mapped to GPIO line 10..29
For this example, a call to pinctrl_gpio_get_pinctrl_and_offset() using
offset 10 incorrectly return pin controller "foo" instead of "bar".
Fix this by using an exclusive range check.
Fixes: d0bb00adccb8 ("pinctrl: fix pinctrl_gpio_get_pinctrl_and_offset for gpio-ranges array")
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Quanyang Wang <quanyang.wang@windriver.com>
|
|
https://source.denx.de/u-boot/custodians/u-boot-dfu
u-boot-dfu-20240516
- Fix cdns3 low power hang via fast access bit
- Multiple dwc3 gadget fixes, mainly for USB support on TI AM6232
- Consistent USB_GADGET_MANUFACTURER for PHYTEC boards
- MAINTAINERS file update for u-boot-dfu
|
|
Upstream Linux commit 3aa07f72894d.
If there's a disconnection while operating in eSS, there may be a delay
in VBUS drop response from the connector. In that case, the internal
link state may drop to operate in usb2 speed while the controller thinks
the VBUS is still high. The driver must make sure to disable
GUSB2PHYCFG.SUSPHY when sending endpoint command while in usb2 speed.
The End Transfer command may be called, and only that command needs to
go through at this point. Let's keep it simple and unconditionally
disable GUSB2PHYCFG.SUSPHY whenever we issue the command.
This scenario is not seen in real hardware. In a rare case, our
prototype type-c controller/interface may have a slow response
triggerring this issue.
Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Link: https://lore.kernel.org/r/5651117207803c26e2f22ddf4e5ce9e865dcf7c7.1668045468.git.Thinh.Nguyen@synopsys.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Alexander Sverdlin <alexander.sverdlin@siemens.com>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Link: https://lore.kernel.org/r/20240412202611.3565052-7-alexander.sverdlin@siemens.com
Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
|
|
Upstream Linux commit 5999914f227b.
The cmd argument we pass to
dwc3_send_gadget_ep_cmd() could contain extra
arguments embedded. When checking for StartTransfer
command, we need to make sure to match only lower 4
bits which contain the actual command and ignore the
rest.
Reported-by: Janusz Dziedzic <januszx.dziedzic@intel.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
[A. Sverdlin: cherry-picked only DWC3_DEPCMD_CMD() define]
Signed-off-by: Alexander Sverdlin <alexander.sverdlin@siemens.com>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Link: https://lore.kernel.org/r/20240412202611.3565052-6-alexander.sverdlin@siemens.com
Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
|
|
Upstream Linux commit 87dd96111b0b.
When operating in USB 2.0 speeds (HS/FS), if GUSB2PHYCFG.ENBLSLPM or
GUSB2PHYCFG.SUSPHY is set, it must be cleared before issuing an endpoint
command.
Current implementation only save and restore GUSB2PHYCFG.SUSPHY
configuration. We must save and clear both GUSB2PHYCFG.ENBLSLPM and
GUSB2PHYCFG.SUSPHY settings. Restore them after the command is
completed.
DWC_usb3 3.30a and DWC_usb31 1.90a programming guide section 3.2.2
Signed-off-by: Thinh Nguyen <thinhn@synopsys.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Alexander Sverdlin <alexander.sverdlin@siemens.com>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Link: https://lore.kernel.org/r/20240412202611.3565052-5-alexander.sverdlin@siemens.com
Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
|
|
Upstream Linux commit ab2a92e7a608.
As a micro-power optimization, let's only resume the
USB2 PHY if we're working on <=HIGHSPEED. If we're
gonna work on SUPERSPEED or SUPERSPEED+, there's no
point in resuming the USB2 PHY.
Fixes: 2b0f11df84bb ("usb: dwc3: gadget: clear SUSPHY bit before ep cmds")
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Alexander Sverdlin <alexander.sverdlin@siemens.com>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Link: https://lore.kernel.org/r/20240412202611.3565052-4-alexander.sverdlin@siemens.com
Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
|
|
Upstream Linux commit 2b0f11df84bb.
Synopsys Databook 2.60a has a note that if we're
sending an endpoint command we _must_ make sure that
DWC3_GUSB2PHY(n).SUSPHY bit is cleared.
This patch implements that particular detail.
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Alexander Sverdlin <alexander.sverdlin@siemens.com>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Link: https://lore.kernel.org/r/20240412202611.3565052-3-alexander.sverdlin@siemens.com
Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
|
|
Upstream Linux commit c0ca324d09a0.
dwc3_send_gadget_ep_cmd() had three return
points. That becomes a pain to track when we need to
debug something or if we need to add more code
before returning.
Let's combine all three return points into a single
one just by introducing a local 'ret' variable.
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Alexander Sverdlin <alexander.sverdlin@siemens.com>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Link: https://lore.kernel.org/r/20240412202611.3565052-2-alexander.sverdlin@siemens.com
Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
|
|
Buffers must not have an unclean cache before being used for DMA - a
pending write-back may corrupt the next dev-to-mem transfer otherwise.
This was consistently noticeable during long TFTP transfers, when an ARP
request is answered by U-Boot in the middle of the transfer:
As U-Boot's arp_receive() reuses the receive buffer to prepare its
reply packet, the beginning of one of the next incoming TFTP packets
is overwritten by the ARP reply. The corrupted packet is ignored, but
the TFTP transfer stalls for a few seconds until a timeout is detected
and a retransmit is triggered.
Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com>
Tested-by: Alexander Sverdlin <alexander.sverdlin@siemens.com>
|
|
net.h is needed for PKTBUFSRX. Without this definition, the driver will
always use 4 RX buffers, causing am65-cpsw-nuss initialization to fail
when a higher number of buffers is requested.
Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com>
|
|
The RX DMA channel has been requested at this point already, so it must
be freed.
Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com>
|
|
The eth-uclass state machine doesn't prevent imbalanced start()/stop()
calls - to the contrary, it even provides eth_init_state_only() and
eth_halt_state_only() functions that change the state without any calls
into the driver. This means that the driver must be robust against
duplicate start() and stop() calls as well as send/recv calls while the
interface is down.
We decide not to print error messages but just to return an error in the
latter case, as trying to send packets on a disabled interface commonly
happens when the netconsole is still active after the Ethernet has been
halted during bootm.
Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com>
|
|
Hari Nagalla <hnagalla@ti.com> says:
This series adds relevant ip data in remoteproc driver for AM62a devices.
Logs: https://paste.sr.ht/~hnagalla/5e20838705c1d688bca81886dad56451b56d3913
|
|
AM62A has a R5F core in MCU voltage domain.
Extend support for R5F remote proc driver on AM62A with compatible
strings.
Signed-off-by: Hari Nagalla <hnagalla@ti.com>
Reviewed-by: Devarsh Thakkar <devarsht@ti.com>
|
|
AM62A SoC has a single C71x DSP subsystem with analytics engine in
main voltage domain. Extend support to AM62A with compatible strings.
Signed-off-by: Hari Nagalla <hnagalla@ti.com>
Reviewed-by: Devarsh Thakkar <devarsht@ti.com>
|
|
Martyn Welch <martyn.welch@collabora.com> says:
This series adds DFU support for TI AM62 SK and beagleplay boards.
I have picked this series up from Sjoerd due to time constraints.
Since the last revision:
* Removed dwc3 mode setting in favour of reinstating forced peripheral
mode for usb0
* Use of config fragments for both r5 and a53 DFU configuration to
reduce duplication
* Typographical improvements to documentation
We plan to also submit the dts changes to linux so that those can be
dropped again in the near future (hopefully)
|
|
Add glue code for TI AM62 to the dwc3 driver; Most code adopted from
TI vendor u-boot code.
Signed-off-by: Sjoerd Simons <sjoerd@collabora.com>
Tested-by: Alexander Sverdlin <alexander.sverdlin@siemens.com>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Tested-by: Mattijs Korpershoek <mkorpershoek@baylibre.com> # on beagle play
|
|
Signed-off-by: Leo Yu-Chi Liang <ycliang@andestech.com>
|
|
Without the NULL check, if the devicetree that u-boot loads does not have a
compatible property then a store access fault will be raised and force the
machine to reset, due to the NULL pointer we passed to strlen. This commit
adds this check and will return -ENOSPC to indicate the get_desc failed.
Signed-off-by: Hanyuan Zhao <zhaohy22@mails.tsinghua.edu.cn>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
|
|
When the device port is in a low power state [U3/L2/Not Connected],
accesses to usb device registers may take a long time. This could lead to
potential core hang when the controller registers are accessed after the
port is disabled by setting DEVDS field. Setting the fast register access
bit ensures that the PHY clock is keeping up in active state.
Therefore, set fast access bit to ensure the accesses to device registers
are quick even in low power states.
commit b5148d946f45 ("usb: cdns3: gadget: set fast access bit") in the
upstream kernel is taken as reference.
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Signed-off-by: Ravi Gunasekaran <r-gunasekaran@ti.com>
Reviewed-by: Roger Quadros <rogerq@kernel.org>
Reviewed-by: Marek Vasut <marex@denx.de>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Link: https://lore.kernel.org/r/20240424073911.1943-1-r-gunasekaran@ti.com
Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
|
|
1. Use vendor naming rule to rename each function
2. add SHA 384/512 support
Signed-off-by: Jim Liu <JJLIU0@nuvoton.com>
|
|
Roger Quadros <rogerq@kernel.org> says:
Sync AM62 device tree files with Linux v6.9 and
add in the missing bits in -u-boot.dtsi to get CPSW
Ethernet working.
CI testing: https://github.com/u-boot/u-boot/pull/534
|
|
MD Danish Anwar <danishanwar@ti.com> says:
This series adds AM64x related compatibles to PRUSS and PRU_RPROC drivers.
This series is a prerequisite for ICSSG Ethernet driver.
Once Support for AM64x is added to PRUSS and PRU_RPROC driver, I'll send
another series to enable ICSSG Ethernet driver for AM64x as well.
|