summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* Merge tag 'mmc-2021-2-19' of https://gitlab.denx.de/u-boot/custodians/u-boot-mmcWIP/19Feb2021Tom Rini2021-02-1916-107/+153
|\ | | | | | | | | | | | | - mmc_spi improvement - added mmc-pwrseq to remove duplicated code - fix response timeout after switch command - sdhci: skip cache invalidation if DMA is not used
| * configs: enable CONFIG_MMC_PWRSEQ configurationJaehoon Chung2021-02-195-0/+5
| | | | | | | | | | | | | | Enable CONFIG_MMC_PWRSEQ configuration about boards that is using rockchip_dw_mmc driver. Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
| * ARM: mach-meson: select MMC_PWRSEQ configJaehoon Chung2021-02-191-0/+1
| | | | | | | | | | | | | | | | | | Before time, PWRSEQ is selected since below commit. commit 262d34363373 ("board: amlogic: select PWRSEQ for all amlogic platform") Select MMC_PWRSEQ config because of introducing CONFIG_MMC_PWRSEQ for only eMMC module. Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
| * mmc: rockchip_dw_mmc: use mmc_pwrseq instead of rockchip_mmc_pwrseqJaehoon Chung2021-02-191-39/+3
| | | | | | | | | | | | Use mmc_pwrseq instead of rockchip_mmc_pwrseq. Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
| * mmc: meson_gx_mmc: use mmc_pwrseq instead of meson_mmc_pwrseqJaehoon Chung2021-02-191-42/+3
| | | | | | | | | | | | | | Use mmc_pwrseq instead of meson_mmc_pwrseq. Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com> Acked-by: Neil Armstrong <narmstrong@baylibre.com>
| * mmc: pwrseq: add mmc-pwrseq file to provide a generic interfaceJaehoon Chung2021-02-194-0/+73
| | | | | | | | | | | | Add mmc-pwrseq file to provide a generic interface. Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
| * mmc: mmc_spi: Document the 3 local functionsBin Meng2021-02-191-1/+35
| | | | | | | | | | | | | | | | | | mmc_spi_sendcmd(), mmc_spi_readdata() and mmc_spi_writedata() are currently undocumented. Add comment blocks to explain the arguments and the return value. Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
| * mmc: mmc_spi: Fix potential spec violation in receiving card responseBin Meng2021-02-191-15/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | After command is sent and before card response shows up on the line, there is a variable number of clock cycles in between called Ncr. The spec [1] says the minimum is 1 byte and the maximum is 8 bytes. Current logic in mmc_spi_sendcmd() has a flaw that it could only work with certain SD cards with their Ncr being just 1 byte. When resp_match is false, the codes try to receive only 1 byte from the SD card. On the other hand when resp_match is true, the logic happens to be no problem as it loops until timeout to receive as many bytes as possible to see a match of the expected resp_match_value. However not every call to mmc_spi_sendcmd() is made with resp_match being true hence this exposes a potential issue with SD cards that have a larger Ncr value. Given no issue was reported as of today, we can reasonably conclude that all cards being used on the supported boards happen to have a 1 byte Ncr timing requirement. But a broken case can be triggered by utilizing QEMU to emulate a larger value of Ncr (by default 1 byte Ncr is used on QEMU). This commit fixes such potential spec violation to improve the card compatibility. [1] "Physical Layer Specification Version 8.00" chapter 7.5.1: Command / Response chapter 7.5.4: Timing Values Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
| * mmc: mmc_spi: Move argument check to the beginning of mmc_spi_sendcmd()Bin Meng2021-02-191-3/+3
| | | | | | | | | | | | | | The argument check should happen before any transfer on the SPI lines. Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
| * mmc: mmc_spi: Print verbose debug output when crc16 check failsBin Meng2021-02-191-2/+4
| | | | | | | | | | | | | | Add some verbose debug output when crc16 check fails. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
| * mmc: fix response timeout after switch commandStefan Bosch2021-02-192-1/+3
| | | | | | | | | | | | | | | | | | After issuing the switch command: Wait until 'current state' of the card status becomes 'tran'. This prevents from response timeout at the next command because of 'current state' = 'data'. Signed-off-by: Stefan Bosch <stefan_b@posteo.net> Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
| * mmc: sdhci: skip cache invalidation if DMA is not usedYuezhang.Mo@sony.com2021-02-191-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | If DMA(SDMA or ADMA) is not used, the cache invalidation after reading is no need, should be skipped. Otherwise U-Boot may hang at the cache invalidation. Found this issue and tested this fix on DragonBoard 410c. Fixes: commit 4155ad9aac94 ("mmc: sdhci: fix missing cache invalidation after reading by DMA") Signed-off-by: Yuezhang.Mo <Yuezhang.Mo@sony.com> Reviewed-by: Andy Wu <Andy.Wu@sony.com>
| * cmd: mmc: update the mmc command's usage about argumentJaehoon Chung2021-02-191-3/+3
| | | | | | | | | | | | | | | | It's confusing whether arguments are optional or mandatory. Update the command's usage to clarify how to use. Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com> Reviewed-by: Simon Glass <sjg@chromium.org>
| * mmc: initialize an err variableJaehoon Chung2021-02-191-1/+1
| | | | | | | | | | | | | | | | Initialize an err variable to 0. Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com> Reported-by: Coverity (CID: 313548) Reviewed-by: Tom Rini <trini@konsulko.com>
* | Merge branch '2021-02-18-SPL-FIT-OP-TEE-Linux-improvements'WIP/18Feb2021Tom Rini2021-02-184-137/+142
|\ \ | |/ |/| | | - Improve interactions between SPL / OP-TEE and Linux in FIT images
| * spl: fit: Load devicetree when a Linux payload is foundWIP/2021-02-17-SPL-FIT-improvementsAlexandru Gagniuc2021-02-171-3/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When a FIT config specifies a devicetree, we should load it, no questions asked. In the case of the "simple" FIT loading path, a difficulty arises in selecting the load address of the FDT. The default FDT location is right after the "kernel" or "firmware" image. However, if that is an OP-TEE image, then the FDT may end up in secure DRAM, and not be accessible to normal world kernels. Although the best solution is to be more careful about the FDT address, a viable workaround is to only append the FDT after a u-boot or Linux image. This is identical to the previous logic, except that FDT loading is extended to IH_OS_LINUX images. Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
| * spl: fit: Replace #ifdef blocks with more readable constructsAlexandru Gagniuc2021-02-171-29/+24
| | | | | | | | | | | | | | | | | | | | Use the IS_ENABLED() macro to control code flow, instead of the caveman approach of sprinkling #ifdefs. Code size is not affected, as the linker garbage-collects unused functions. However, readability is improved significantly. Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
| * image: Do not #if guard board_fit_image_post_process() prototypeAlexandru Gagniuc2021-02-171-7/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There's no point in guarding function prototypes with #ifdefs. If a function is not defined, the linker will notice. Having the prototype does not affect code size. What the #if guard takes away is the ability to use IS_ENABLED: if (CONFIG_IS ENABLED(FIT_IMAGE_POST_PROCESS)) board_fit_image_post_process(...) When the prototype is guarded, the above form cannot be used. This leads to the proliferation of #ifdefs, and unreadable code. The opportunity cost of the #if guard outweighs any benefits. Remove it. Since the original version of this patch, an empty definition was added by commit f14e6eec6c7f ("image: cleanup pre-processor usage"). The empty definition can cause silent failures, when an implementation of board_fit_image_post_process() is expected because the linker will not catch the missing function. Thus this patch removes this empty inline declaration. Fixes: f14e6eec6c7f ("image: cleanup pre-processor usage") Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
| * spl: fit: Only look up FIT configuration node onceAlexandru Gagniuc2021-02-171-10/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | The configuration node a sub node under "/configurations", which describes the components to load from "/images". We only need to locate this node once. However, for each component, spl_fit_get_image_name() would parse the FIT image, looking for the correct node. Such work duplication is not necessary. Instead, once the node is found, cache it, and re-use it. Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
| * spl: fit: Remove useless loop in spl_fit_get_image_name()Alexandru Gagniuc2021-02-171-11/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When a desired configuration is not found, conf_node will have a negative value. Thus the for loop will start at the root "/" node of the image, print the "/description" property, and stop. It appears the intent of the loop was to print the names of the subnodes under "/configurations". We would need the offset to the "/configurations" node, which is abstracted by fit_find_config_node(). This change agrees that abstracting the node offset is the correct design, and we shouldn't be parsing the configurations manually. Thus the loop in spl_fit_get_image_name() is useless. Remove it. Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
| * spl: fit: Pass FIT context via a structure pointerAlexandru Gagniuc2021-02-171-58/+43
| | | | | | | | | | | | | | | | | | | | | | | | Several loose arguments describe the FIT image. They are thus related, and it makes sense to pass them together, in a structure. Examples include the FIT blob pointer, offset to FDT nodes, and the offset to external data. Use a spl_fit_info structure to group these parameters. Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
| * spl: fit: Factor out FIT parsing and use a context structAlexandru Gagniuc2021-02-171-30/+60
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The logical steps in spl_load_simple_fit() are difficult to follow. I think the long comments, ifdefs, and ungodly number of variables seriously affect the readability. In particular, it violates section 6 of the coding style, paragraphs (3), and (4). The purpose of this patch is to improve the situation by - Factoring out initialization and parsing to separate functions - Reduce the number of variables by using a context structure This change introduces no functional changes. Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
| * spl: fit: Drop 'length' argument to board_spl_fit_post_load()Alexandru Gagniuc2021-02-173-7/+8
| | | | | | | | | | | | | | | | | | | | | | | | The size is derived from the FIT image itself. Any alignment requirements are machine-specific and known by the board code. Thus the total length can be derived from the FIT image and knowledge of the platform. The 'length' argument is redundant. Remove it. Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-by: Peng Fan <peng.fan@nxp.com> Reviewed-by: Simon Glass <sjg@chromium.org> CC: Matt Porter <mporter@konsulko.com>
* | net: tftp: Avoid sending extra ack on completionRamon Fried2021-02-181-5/+6
| | | | | | | | | | | | | | | | | | | | | | | | in tftpboot, if ack was already sent previously for this packet, don't send again. Fixes: cc6b87ecaa96 ("net: tftp: Add client support for RFC 7440") Reported-by: Suneel Garapati <suneelglinux@gmail.com> Signed-off-by: Ramon Fried <rfried.dev@gmail.com> Tested-by: Suneel Garapati <suneelglinux@gmail.com> Tested-by: Oliver Graute <oliver.graute@kococonnector.com>
* | Merge tag 'rpi-next-2021.04' of ↵Tom Rini2021-02-1837-41/+766
|\ \ | |/ |/| | | | | | | | | https://gitlab.denx.de/u-boot/custodians/u-boot-raspberrypi - add iProc RNG2000 driver for RPi4 - add support for CM4 and RPi400
| * video: arm: rpi: Add brcm,bcm2711-hdmi0 compatibleNicolas Saenz Julienne2021-02-181-0/+1
| | | | | | | | | | | | | | | | | | | | | | The 'brcm,bcm2711-hdmi0' compatible string is used on RPi4 instead of 'brcm,bcm2835-hdmi' since the IP core was upgraded (now called VC6 instead of VC4). This has no functional change as far as u-boot driver is concerned. So simply add the compatible string. Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Tested-by: Peter Robinson <pbrobinson@gmail.com> Signed-off-by: Matthias Brugger <mbrugger@suse.com>
| * configs: rpi4: Enable DM_DMA across all RPi4 configurationsNicolas Saenz Julienne2021-02-183-0/+3
| | | | | | | | | | | | | | | | | | | | The DM_DMA option is needed in order to translate physical address into bus addresses on a per-device basis. Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Peter Robinson <pbrobinson@gmail.com> Signed-off-by: Matthias Brugger <mbrugger@suse.com>
| * mmc: Introduce mmc_phys_to_bus()/mmc_bus_to_phys()Nicolas Saenz Julienne2021-02-182-4/+12
| | | | | | | | | | | | | | | | | | | | This will allow us to use DM variants of phys_to_bus()/bus_to_phys() when relevant. Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Peter Robinson <pbrobinson@gmail.com> Signed-off-by: Matthias Brugger <mbrugger@suse.com>
| * xhci: translate virtual addresses into the bus's address spaceNicolas Saenz Julienne2021-02-184-29/+53
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | So far we've been content with passing physical addresses when configuring memory addresses into XHCI controllers, but not all platforms have buses with transparent mappings. Specifically the Raspberry Pi 4 might introduce an offset to memory accesses incoming from its PCIe port. Introduce xhci_virt_to_bus() and xhci_bus_to_virt() to cater with these limitations, and make sure we don't break non DM users. Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Stefan Roese <sr@denx.de> Tested-by: Peter Robinson <pbrobinson@gmail.com> [mb: fix compilation for 32 bit] Signed-off-by: Matthias Brugger <mbrugger@suse.com> fix from nicolas
| * dm: test: Add test case for dev_phys_to_bus()/dev_bus_to_phys()Nicolas Saenz Julienne2021-02-182-0/+38
| | | | | | | | | | | | | | | | | | | | By reusing DT nodes already available in sandbox's test DT introduce a test to validate dev_phys_to_bus()/dev_bus_to_phys(). Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Peter Robinson <pbrobinson@gmail.com> Signed-off-by: Matthias Brugger <mbrugger@suse.com>
| * dm: Introduce dev_phys_to_bus()/dev_bus_to_phys()Nicolas Saenz Julienne2021-02-181-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | These functions, instead of relying on hard-coded platform-specific address translations, make use of the DMA constraints provided by the DM core. This allows for per-device translations. We can't yet get rid of the legacy phys_to_bus()/bus_to_phys() implementations as some of its users are not integrated into the device model. Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Stefan Roese <sr@denx.de> Tested-by: Peter Robinson <pbrobinson@gmail.com> Signed-off-by: Matthias Brugger <mbrugger@suse.com>
| * dm: test: Add test case for dev->dma_offsetNicolas Saenz Julienne2021-02-186-0/+38
| | | | | | | | | | | | | | | | | | Add test to validate dev->dma_offset is properly set on devices. Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Peter Robinson <pbrobinson@gmail.com> Signed-off-by: Matthias Brugger <mbrugger@suse.com>
| * dm: Introduce DMA constraints into the core device modelNicolas Saenz Julienne2021-02-183-0/+64
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Calculating the DMA offset between a bus address space and CPU's every time we call phys_to_bus() and bus_to_phys() isn't ideal performance wise, as it implies traversing the device tree from the device's node up to the root. Since this information is static and available before the device's initialization, parse it before the probe call an provide the DMA offset in 'struct udevice' for the address translation code to use it. Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Peter Robinson <pbrobinson@gmail.com> Signed-off-by: Matthias Brugger <mbrugger@suse.com>
| * dm: test: Add test case for dev_get_dma_ranges()Nicolas Saenz Julienne2021-02-183-0/+67
| | | | | | | | | | | | | | | | | | | | Introduce some new nodes in sandbox's test device-tree and dm tests in order to validate dev_get_dma_range(). Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Peter Robinson <pbrobinson@gmail.com> Signed-off-by: Matthias Brugger <mbrugger@suse.com>
| * dm: Introduce xxx_get_dma_range()Nicolas Saenz Julienne2021-02-188-0/+234
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add the following functions to get a specific device's DMA ranges: - dev_get_dma_range() - ofnode_get_dma_range() - of_get_dma_range() - fdt_get_dma_range() They are specially useful in oder to be able validate a physical address space range into a bus's and to convert addresses from and to address spaces. Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Peter Robinson <pbrobinson@gmail.com> Signed-off-by: Matthias Brugger <mbrugger@suse.com>
| * pci: pcie-brcmstb: Fix inbound window configurationsNicolas Saenz Julienne2021-02-181-7/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | So far we've assumed a fixed configuration for inbound windows as we had a single user for this controller. But the controller's DMA constraints were improved starting with BCM2711's B1 revision of the SoC, notably available in CM4 and Pi400. They allow for wider inbound windows. We can now cover the whole address space, whereas before we where limited to the lower 3GB. This information is passed to us through DT's 'dma-ranges' property and it's specially important for us to honor it since some interactions with the board's co-processor assume we're doing so (specifically the XHCI firmware load operation, which is handled by the co-processor after u-boot has correctly configured the PCIe controller). Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Tested-by: Peter Robinson <pbrobinson@gmail.com> Signed-off-by: Matthias Brugger <mbrugger@suse.com>
| * rpi: Add identifier for the new CM4Nicolas Saenz Julienne2021-02-181-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Raspberry Pi Foundation released the new Compute Module 4 which we want to detect, so we can enable Ethernet on it and know the correct device tree file name. Note that this sets the Ethernet option to true since the official CM4 IO board has an Ethernet port. But that might not be the case when using custom ones. Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Reviewed-by: Peter Robinson <pbrobinson@gmail.com> Tested-by: Peter Robinson <pbrobinson@gmail.com> Signed-off-by: Matthias Brugger <mbrugger@suse.com>
| * rpi: Add identifier for the new RPi400Nicolas Saenz Julienne2021-02-181-0/+5
| | | | | | | | | | | | | | | | | | | | | | The Raspberry Pi Foundation released the new RPi400 which we want to detect, so we can enable Ethernet on it and know the correct device tree file name. Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Reviewed-by: Peter Robinson <pbrobinson@gmail.com> Tested-by: Peter Robinson <pbrobinson@gmail.com> Signed-off-by: Matthias Brugger <mbrugger@suse.com>
| * rpi: limit size of the RAM to the multiple of the MMU_SECTION_SIZEMarek Szyprowski2021-02-181-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When RPi4 is booted from USB Mass Storage, the firmware reports 947MiB of the ARM memory (948 in case of the standard SD-card boot). This value is not MMU_SECTION_SIZE aligned, so the dram_bank_mmu_setup() skips mapping of the last 1MiB. This later causes u-boot in ARM 32bit mode to freeze, because it relocated itself into that unmapped memory and fails to execute. Fix this by limiting the size of the first bank to the multiple of MMU_SECTION_SIZE. Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Tested-by: Jaehoon Chung <jh80.chung@samsung.com> Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com> Signed-off-by: Matthias Brugger <mbrugger@suse.com>
| * pci: brcmstb: Cleanup controller state before handoverNicolas Saenz Julienne2021-02-181-0/+20
| | | | | | | | | | | | | | | | | | | | | | | | Make sure we handover the PCIe controller in a clean state. Some of the devices hanging from the PCIe bus might need to be properly reset through #PERST in order for Linux to be able to initialize them. This is specially important in order to properly initialize Raspberry Pi 4 B and 400's USB chip. Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Signed-off-by: Matthias Brugger <mbrugger@suse.com>
| * usb: xhci-pci: Add DM_FLAG_OS_PREPARE flagNicolas Saenz Julienne2021-02-181-1/+1
| | | | | | | | | | | | | | | | | | The PCIe bus the controller is connected to might need to be removed prior the handover. Make sure xhci-pci is also removed so as to avoid unexpected timeouts or hangs. Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Signed-off-by: Matthias Brugger <mbrugger@suse.com>
| * config: Enable iProc RNG200 driver in RPi4 configsMatthias Brugger2021-02-183-1/+4
| | | | | | | | | | | | | | | | | | | | We find the iProc RNG200 in the Raspberry Pi 4. Add it to all it's config so that it can be used. Signed-off-by: Matthias Brugger <mbrugger@suse.com> Tested-by: Peter Robinson <pbrobinson@gmail.com> [mb: drop rpi_4_32b_defconfig] Signed-off-by: Matthias Brugger <mbrugger@suse.com>
| * rng: Add iProc RNG200 driverMatthias Brugger2021-02-163-0/+193
|/ | | | | | | | | | | Add support for random number generator RNG200. This is for example found on RPi4. Signed-off-by: Matthias Brugger <mbrugger@suse.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Peter Robinson <pbrobinson@gmail.com> [mb: adapt to new struct driver memebers] Signed-off-by: Matthias Brugger <mbrugger@suse.com>
* Merge branch '2021-02-16-assorted-improvements'Tom Rini2021-02-1638-105/+1834
|\ | | | | | | | | | | - DSA switch support (Layerscape platforms) - IOMUX cleanup / fixes - i2c OP-TEE trampoline driver
| * configs: ls1028a: Enable the Ethernet switch driver in defconfigWIP/2021-02-16-assorted-improvements-v1Alex Marginean2021-02-165-0/+15
| | | | | | | | | | | | | | | | | | | | The switch driver for LS1028A Ethernet switch is now compiled in for the NXP LS1028A reference design boards and for the Kontron SMARC-sAL28. Signed-off-by: Alex Marginean <alexandru.marginean@nxp.com> Signed-off-by: Claudiu Manoil <claudiu.manoil@nxp.com> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Acked-by: Michael Walle <michael@walle.cc>
| * arm: dts: ls1028a: Add Ethernet switch node and dependenciesAlex Marginean2021-02-162-1/+119
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The definition follows the DSA binding in kernel and describes the switch, its ports and PHYs. The switch node has the same structure as in Linux and this patch enables it (and relevant ports) for the LS1028A RDB board. ENETC PF6 is the 2nd Eth controller linked to the switch on LS1028A, it is not used in U-Boot and was disabled. Ethernet port aliases were also added to better manage the multitude of ports available now. Signed-off-by: Alex Marginean <alexandru.marginean@nxp.com> Signed-off-by: Claudiu Manoil <claudiu.manoil@nxp.com> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Michael Walle <michael@walle.cc>
| * drivers: net: Add Felix DSA switch driverAlex Marginean2021-02-164-0/+428
| | | | | | | | | | | | | | | | | | | | | | | | This driver is used for the Ethernet switch integrated into LS1028A NXP. Felix on LS1028A has 4 front panel ports and two internal ports, I/O to/from the switch is done through an ENETC Ethernet interface. The 4 front panel ports are available as Ethernet interfaces and can be used with the typical network commands like tftp. Signed-off-by: Alex Marginean <alexandru.marginean@nxp.com> Signed-off-by: Claudiu Manoil <claudiu.manoil@nxp.com> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
| * net: Introduce DSA class for Ethernet switchesClaudiu Manoil2021-02-166-0/+666
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | DSA stands for Distributed Switch Architecture and it covers switches that are connected to the CPU through an Ethernet link and generally use frame tags to pass information about the source/destination ports to/from CPU. Front panel ports are presented as regular ethernet devices in U-Boot and they are expected to support the typical networking commands. DSA switches may be cascaded, DSA class code does not currently support this. Signed-off-by: Alex Marginean <alexandru.marginean@nxp.com> Signed-off-by: Claudiu Manoil <claudiu.manoil@nxp.com> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
| * net: phy: introduce fixed_phy_create for DSA CPU portsVladimir Oltean2021-02-162-0/+52
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The DSA (Distributed Switch Architecture) implementation has made a design decision when it got introduced to the Linux kernel in 2008. That was to hide away from the user the CPU-facing Ethernet MAC, since it does not make sense to register it as a struct net_device (UCLASS_ETH udevice for U-Boot), because that would never be beneficial for a user: they would not be able to use it for traffic, since conceptually, a packet delivered to the CPU port should loop back into the system. Nonetheless, DSA has had numerous growing pains due to the lack of a struct net_device for the CPU port, but so far it has overcome them. It is unlikely at this stage of maturity that this aspect of it will change. We would like U-Boot to present the same information as Linux, to be at parity in terms of number of interfaces, so that ethNaddr environment variables could directly be associated between U-Boot and Linux. Therefore, we would implicitly like U-Boot to hide the CPU port from the user as well. But the paradox is that DSA still needs a struct phy_device to inform the driver of the parameters of the link that it should configure the CPU port to. The problem is that the phy_device is typically returned via a call to phy_connect, which needs an udevice to attach the PHY to, and to search its ofnode for the 'fixed-link' property. But we don't have an udevice to present for the CPU port. Since 99% of DSA setups are MAC-to-MAC connections between the switch and the host Ethernet controller, the struct phy_device is going to be a fixed PHY. This simplifies things quite a bit. In U-Boot, a fixed PHY does not need an MDIO bus, and does not need an attached dev either. Basically, the phy_connect call doesn't do any connection, it just creates the fixed PHY. The proposal of this patch is to introduce a new fixed_phy_create function which will take a single argument: the ofnode that holds this: port@4 { reg = <4>; phy-mode = "internal"; fixed-link { speed = <2500>; full-duplex; }; }; and probe a fixed PHY driver using the information from this ofnode. DSA will probably be the only user of this function. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Claudiu Manoil <claudiu.manoil@nxp.com>
| * net: phy: fixed: support speeds of 2500 and 10000Vladimir Oltean2021-02-161-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | Unlike the Linux fixed PHY driver, the one in U-Boot does not attempt to emulate the clause 22 register set of a gigabit copper PHY driver through the swphy framework. Therefore, the limitation of being unable to support speeds higher than gigabit in fixed-link does not apply to the U-Boot fixed PHY driver. This makes the fixed-link U-Boot implementation more similar to the one from phylink, which can work with any valid link speed. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Claudiu Manoil <claudiu.manoil@nxp.com>
View Lorry Controller Status