Commit graph

66531 commits

Author SHA1 Message Date
Masahiro Yamada
e2bb0be2fc bus: uniphier-system-bus: add UniPhier System Bus driver
Since commit 1517126fda ("ARM: uniphier: select DM_ETH"), DM-based
drivers/net/smc911x.c is compiled, but it is never probed because the
parent node lacks the DM-based driver.

I need a skeleton driver to populate child devices (but the next commit
will move more hardware settings to the this driver).

I put this to drivers/bus/uniphier-system-bus.c because this is the
same path as the driver in Linux kernel.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2020-07-11 21:30:21 +09:00
Masahiro Yamada
d69d49d3ec ARM: uniphier: remove support for NOR Flash on support card
I actually do not see this used these days because eMMC or NAND is used
for non-volatile devices. Dump the burden to maintain this crappy code.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2020-07-11 21:30:21 +09:00
Masahiro Yamada
f95237bb02 ARM: uniphier: remove unused uniphier_sbc_init_admulti()
This was used by the old sLD3 SoC, the support of which was removed
by commit 00aa453ebf ("ARM: uniphier: remove sLD3 SoC support").

There is no more user of this function.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2020-07-11 21:30:21 +09:00
Masahiro Yamada
43db571b2d ARM: uniphier: fix build error when CONFIG_MICRO_SUPPORT_CARD=n
If CONFIG_MICRO_SUPPORT_CARD is unset, the build fails due to
function redefinition.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2020-07-11 21:30:21 +09:00
Masahiro Yamada
0852033309 ARM: uniphier: sync with Linux 5.8-rc4
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2020-07-11 21:30:21 +09:00
Masahiro Yamada
56d463bdba ARM: uniphier: consolidate SoC select menu
Currently, the supports for the following two ARMv7 SoC groups
are exclusive, because the boot ROM loads the SPL to a different
address:

 - LD4, sLD8                 (SPL is loaded at 0x00040000)
 - Pro4, Pro5, PXs2, LD6b    (SPL is loaded at 0x00100000)

This limitation exists only when CONFIG_SPL=y.

Instead of using crappy CONFIG options, checking SPL and SPL_TEXT_BASE
is cleaner.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2020-07-11 21:30:21 +09:00
Masahiro Yamada
e3e9d5e8d7 ARM: uniphier: increase CONFIG_SYS_MONITOR_LEN to 2MB
I increased the maximum U-Boot proper size from time to time, but
configs/uniphier_v7_defconfig hit the current limit 832KB.

Some historical info:

In the initial support, the max size was 512MB.

Commit 58d702274c ("ARM: uniphier: increase CONFIG_SYS_MONITOR_LEN")
increased it to 576KB, and commit 3ce5b1a8d8 ("ARM: uniphier: move
SPL stack address") moved the SPL stack location to avoid the memory
map conflict. It was the solution to increase the size without changing
the NOR boot image map.

commit 1a4bd3a095 ("ARM: uniphier: increase CONFIG_SYS_MONITOR_LEN
again") ended up with increasing the max size again, breaking the NOR
boot image map. The limit was set to 832KB, otherwise the SPL stack
would overwrite the U-Boot proper image:
 CONFIG_SPL_STACK - CONFIG_SYS_UBOOT_BASE + sizeof(struct image_header) = 0xd0000

To increase CONFIG_SYS_MONITOR_LEN even more, the SPL stack must be
moved somewhere. I put it back to the original location prior to
commit 3ce5b1a8d8.

With this change, there is no more practical size limit.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2020-07-11 21:30:21 +09:00
Masahiro Yamada
1f8e6a670c Revert "ARM: uniphier: add weird workaround code for LD20"
This reverts commit 45f41c134b.

This weird workaround was the best I came up with at that time
to boot U-Boot from TF-A.

I noticed U-Boot successfully boots on LD20 (i.e. CA72 CPU) by using
the latest TF-A.

Specifically, since the following TF-A commit, U-Boot runs at EL2
instead of EL1, and this issue went away as a side-effect.

|commit f998a052fd94ea082833109f25b94ed5bfa24e8b
|Author: Masahiro Yamada <yamada.masahiro@socionext.com>
|Date:   Thu Jul 25 10:57:38 2019 +0900
|
|    uniphier: run BL33 at EL2
|
|    All the SoCs in 64-bit UniPhier SoC family support EL2.
|
|    Just hard-code MODE_EL2 instead of using el_implemented() helper.
|
|    Change-Id: I7ab48002c5205bc8c013e1b46313b57d6c431db0
|    Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

However, if I reverted that, this problem would come back, presumably
because some EL1 code in U-Boot triggers this issue.

Now that commit f8ddd8cbb5 ("arm64: issue ISB after updating system
registers") fixed this issue properly, this weird workaround is no
longer needed irrespective of the exception level at which U-Boot runs.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2020-07-11 21:30:21 +09:00
Tom Rini
4a9146c295 of-platdata: better phandle and compatible-string support
patman support for Python3 on Ubuntu 14.04
 new checkpatch check to avoid #ifdefs
 -----BEGIN PGP SIGNATURE-----
 
 iQFFBAABCgAvFiEEslwAIq+Gp8wWVbYnfxc6PpAIreYFAl8InaQRHHNqZ0BjaHJv
 bWl1bS5vcmcACgkQfxc6PpAIreazvAgAgqyvPY2o+BNHscrx9/6sEOHSAVty/D5t
 SdaphzRezlJOWy9MC/ZyqyevZjogN7fgGNQVgh/I4BklIc/N5Omn68/+JWylSFVP
 taJKiJD1IVSThTXGOMTxlDiTxY7NfVDUDjtFIpCDswBrnSJlX+2v/RsehUwVIrYn
 NJwiRXd33IdS1vh1mqqNgwbZNBo+zGWn5LApq71vLSVkiQlmcpMG9FmYYRcg/AhG
 3Xd2HB2ANcvb13fMMcwd3s4WPNYoiJvwjSHScNDUPEip7XeZNDiNeq4gC6d2Uw+J
 zC3/vOCP3eRtAnr6syJ5QcGN/eeKwLtnTE+fOuOm6s5Y98po4iMykA==
 =3fC5
 -----END PGP SIGNATURE-----

Merge tag 'dm-pull-10jul20' of https://gitlab.denx.de/u-boot/custodians/u-boot-dm

of-platdata: better phandle and compatible-string support
patman support for Python3 on Ubuntu 14.04
new checkpatch check to avoid #ifdefs
2020-07-10 16:22:57 -04:00
Heinrich Schuchardt
f309247399 CI: show skipped Python tests
Call pytest3 with argument -ra to display the reason why Python tests are
skipped.

The -r flag displays a test summary info for each test. -ra eliminates
this info for passed tests.

Pros an cons were discussed in:
https://lists.denx.de/pipermail/u-boot/2020-June/417090.html

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2020-07-10 16:22:37 -04:00
Tom Rini
3113c84ba2 - add support for PCI and XHCI for RPi4 (64 bit only)
- optionally reset XHCI device on registration
 - enable USB_KEYBOARD for rpi_4_defconfig
 -----BEGIN PGP SIGNATURE-----
 
 iQJGBAABCAAwFiEEUdvKHhzqrUYPB/u8L21+TfbCqH4FAl8Ifk0SHG1icnVnZ2Vy
 QHN1c2UuY29tAAoJEC9tfk32wqh+160QAK85hENUpOft76dZ+SwKp1EF4K6yn7Uq
 7OuO3k9PlzYamWDrJuRlvUp2ZkQPU0umT7NA+DfIOCrcXpdU/nltlhZMlaSXIXIp
 NbsoSLZxGz1xKdKITZJupCMTj+rHP4/ZO96EQ9ajuNQ56TLmxSbbU6rpJtwm98Gx
 mXOUTSx3UOHRyRv7R1U/LGNfxHnXwK8tpP+sCppHGRkl2ypkKSM9mjPRmBfPLGgM
 s0TDm2XcPtiTK/YOR5FpuXsjlg+eUxhpSkH9Tvj49BkGPgIUeGYgWkc/1d6Aip1E
 liuQYvRtK/cZLhtaWPyW8JPentyv54rIbFQ7weZbsTMDGUfX4k5VJC+ucsWiG3aa
 XaWO83woOG+nYIv6hNodXT9i5TmfOJYHHC64nqMMGx0n5Ouz3oQ2UhXVLMFihyG0
 xgOprEVqMBvgxdOGVyEyFO3qtut2zPQTkFTZZoUNrEYcGO3rtrhAMI2KY4TVMfQe
 CyZ4DMMMAC3aSvL2VD5s3YkD//j8sXdt75qnSeS3AVbEKJgmcWP6A59FFDZ6cCmY
 Nturw8Cfn8axvQAkR9v7yhX2HeItO6n5YWhayoxa+Bo5mjjEZEMT5mrZhKAWposl
 XBZgb4Xr6fp1N2AZf7/b60jxwD0ogTIjxX4Ez2d43ehhHqPNZ5sGrC6kIrpu0U9U
 NKcCxgGjlQBA
 =2aS6
 -----END PGP SIGNATURE-----

Merge tag 'rpi-next-2020.10' of https://gitlab.denx.de/u-boot/custodians/u-boot-raspberrypi

- add support for PCI and XHCI for RPi4 (64 bit only)
- optionally reset XHCI device on registration
- enable USB_KEYBOARD for rpi_4_defconfig
2020-07-10 14:31:22 -04:00
Tom Rini
618c306790 Merge branch '2020-08-10-arbitrary-virt-phys-mappings'
- Bring in Marek Szyprowski's series to allow for arbitrary
  virtual-physical address mappings.
2020-07-10 14:30:46 -04:00
Marek Szyprowski
c1b0bcc870 config: Enable support for the XHCI controller on RPI4 board
This requires enabling BRCMSTB PCIe and XHCI_PCI drivers as well as PCI
and USB commands. To get it working one has to call the following commands:
"pci enum; usb start;", thus such commands have been added to the default
"preboot" environment variable. One has to update their environment if it
is already configured to get this feature working out of the box.

Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
2020-07-10 14:11:49 -04:00
Marek Szyprowski
814e1a4b8c rpi4: add a mapping for the PCIe XHCI controller MMIO registers (ARM 32bit)
Create a non-cacheable mapping for the 0x600000000 physical memory region,
where MMIO registers for the PCIe XHCI controller are instantiated by the
PCIe bridge. Due to 32bit limit in the CPU virtual address space in ARM
32bit mode, this region is mapped at 0xff800000 CPU virtual address.

Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
2020-07-10 14:10:43 -04:00
Seung-Woo Kim
221c5e42a6 mmc: bcm283x: fix int to pointer cast
On build with 32 bit, there is a warning for int-to-pointer-cast.
Fix the int to pointer cast by using uintptr_t.

Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
2020-07-10 14:10:43 -04:00
Marek Szyprowski
d877f8fd0f arm: provide a function for boards init code to modify MMU virtual-physical map
Provide function for setting arbitrary virtual-physical MMU mapping
and cache settings for the given region.

Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
2020-07-10 14:10:43 -04:00
Marek Szyprowski
f5a9fcc602 arm: update comments to the common style
Update the comments in include/asm/system.h to the common style.

Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
2020-07-10 14:10:43 -04:00
Marek Szyprowski
69be8fd164 powerpc: move ADDR_MAP to Kconfig
Move ADDR_MAP related config options from include/configs/*.h to the
proper place in lib/Kconfig. This has been done using
./tools/moveconfig.py and manual inspection of the generated changes.
This is a preparation to use ADDR_MAP helper on ARM 32bit Raspberry Pi4
board for mapping the PCIe XHCI MMIO, which is above the 4GiB identity
mapping limit.

Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
2020-07-10 14:10:43 -04:00
Nicolas Saenz Julienne
d6ecb71a1f config: Enable USB Keyboard support on RPi4
Supporting USB keyboards out of the box is both handy for development
and production. Notably if u-boot is used to boot into GRUB.

Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Reviewed-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
[mb: drop rpi_4_32b_defconfig hunk]
Signed-off-by: Matthias Brugger <mbrugger@suse.com>
2020-07-10 11:50:36 +02:00
Nicolas Saenz Julienne
0b80371b35 usb: xhci: Add reset controller support
Some atypical users of xhci might need to manually reset their xHCI
controller before starting the HCD setup. Check if a reset controller
device is available to the PCI bus and trigger a reset.

Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
[mb: squash fix to only build xhci_reset_hw() if CONFIG_DM_BUS]
Signed-off-by: Matthias Brugger <mbrugger@suse.com>
2020-07-10 11:49:28 +02:00
Nicolas Saenz Julienne
6836d59094 configs: Enable support for reset controllers on RPi4
This is required in order to access the reset controller used to
initialize the board's xHCI chip.

Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Signed-off-by: Matthias Brugger <mbrugger@suse.com>
2020-07-10 11:49:28 +02:00
Nicolas Saenz Julienne
f676eb217b reset: Add Raspberry Pi 4 firmware reset controller
Raspberry Pi 4's co-processor controls some of the board's HW
initialization process, but it's up to Linux to trigger it when
relevant. Introduce a reset controller capable of interfacing with
RPi4's co-processor that models these firmware initialization routines as
reset lines.

Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Signed-off-by: Matthias Brugger <mbrugger@suse.com>
2020-07-10 11:49:28 +02:00
Nicolas Saenz Julienne
d774da08dc arm: rpi: Add function to trigger VL805's firmware load
On the Raspberry Pi 4, after a PCI reset, VL805's (a xHCI chip) firmware
may either be loaded directly from an EEPROM or, if not present, by the
SoC's VideCore (the SoC's co-processor). Introduce the function that
informs VideCore that VL805 may need its firmware loaded.

Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Signed-off-by: Matthias Brugger <mbrugger@suse.com>
2020-07-10 11:49:28 +02:00
Marek Szyprowski
440bca81f0 configs: Enable support for the XHCI controller on RPI4 board (ARM 64-bit)
This requires enabling BRCMSTB PCIe and XHCI_PCI drivers as well as PCI
and USB commands. To get it working one has to call the following commands:
"pci enum; usb start;", thus such commands have been added to the default
"preboot" environment variable. One has to update their environment if it
is already configured to get this feature working out of the box.

Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Matthias Brugger <mbrugger@suse.com>
2020-07-10 11:49:28 +02:00
Sylwester Nawrocki
7b1c3f6f65 pci: Add driver for Broadcom BCM2711 SoC PCIe controller
This patch adds basic driver PCI Express controller found on Broadcom
set-top-box SoCs, e.g. BCM2711.
The code is based on Linux upstream driver (pcie-brcmstb.c) with MSI
handling removed. The inbound access memory region is not currently
parsed from dma-ranges DT property and a fixed 3GB region is used.

The patch has been tested on RPI4 board, i.e. on BCM2711 SoC with VL805
USB Host Controller.

Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Matthias Brugger <mbrugger@suse.com>
2020-07-10 11:49:28 +02:00
Sylwester Nawrocki
db75485f5c pci: Add some PCI Express capability register offset definitions
Add PCI Express capability definitions required by the Broadcom
STB PCIe controller driver.

Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Signed-off-by: Matthias Brugger <mbrugger@suse.com>
2020-07-10 11:49:28 +02:00
Nicolas Saenz Julienne
c92921bb52 linux/bitfield.h: Add primitives for manipulating bitfields both in host- and fixed-endian
Imports Al Viro's original Linux commit 00b0c9b82663a, which contains
an in depth explanation and two fixes from Johannes Berg:
 e7d4a95da86e0 "bitfield: fix *_encode_bits()",
 37a3862e12382 "bitfield: add u8 helpers".

Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
[s.nawrocki: added empty lines between functions and macros]
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
[mb: squash fix including byteorder.h]
Signed-off-by: Matthias Brugger <mbrugger@suse.com>
2020-07-10 11:47:12 +02:00
Jagan Teki
18c56605c6 doc: driver-model: Update SPI migration status
All SPI drivers are converted to DM_SPI but 3 drivers
still operate in nondm mode for SPL due to footprint
constraints.

Update the migration status for it.

Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
2020-07-10 12:39:54 +05:30
Bhargav Shah
a58c7ffcad spi: kirkwood: Drop nondm code
Drop the nondm code from kirkwood_spi.c since there
is no board or any other code using for it.

Signed-off-by: Bhargav Shah <bhargavshah1988@gmail.com>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
2020-07-10 12:39:54 +05:30
Walter Lozano
6c3fc50ee5 dtoc: add test for cd-gpios
Add a test for dtoc taking into account the cd-gpios property.

Signed-off-by: Walter Lozano <walter.lozano@collabora.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
2020-07-09 22:00:29 -06:00
Walter Lozano
ad34017c8c dtoc: update dtb_platdata to support cd-gpios
Currently dtoc does not support the property cd-gpios used to declare
the gpios for card detect in mmc.

This patch adds support to cd-gpios property.

Signed-off-by: Walter Lozano <walter.lozano@collabora.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
2020-07-09 22:00:29 -06:00
Walter Lozano
407009a426 arm: dts: include gpio nodes for card detect
Several MMC drivers use GPIO for card detection with cd-gpios property in
the MMC node pointing to a GPIO node. However, as U-Boot tries to save
space by keeping only required nodes using u-boot* properties, several
devices tree result in having only in the MMC node but not the GPIO node
associated to cd-gpios.

This patch, fixes several ocurrence of this issue.

Signed-off-by: Walter Lozano <walter.lozano@collabora.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Adam Ford <aford173@gmail.com> #da850-evm
2020-07-09 22:00:29 -06:00
Walter Lozano
cbd484f0eb dm: doc: update of-plat with new phandle support
Update documentation to reflect the new phandle support when OF_PLATDATA
is used. Now phandles are implemented as pointers to U_BOOT_DEVICE,
which makes it possible to get a pointer to the actual device.

Signed-off-by: Walter Lozano <walter.lozano@collabora.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
2020-07-09 22:00:29 -06:00
Walter Lozano
51f1263d89 dtoc: extend dtoc to use struct driver_info when linking nodes
In the current implementation, when dtoc parses a dtb to generate a struct
platdata it converts the information related to linked nodes as pointers
to struct platdata of destination nodes. By doing this, it makes
difficult to get pointer to udevices created based on these
information.

This patch extends dtoc to use struct driver_info when populating
information about linked nodes, which makes it easier to later get
the devices created. In this context, reimplement functions like
clk_get_by_index_platdata() which made use of the previous approach.

Signed-off-by: Walter Lozano <walter.lozano@collabora.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
2020-07-09 22:00:29 -06:00
Walter Lozano
df29730410 sandbox: Move section u_boot_list to make it RW
In order to be able to update data in u_boot_list, move this section to
make it RW.

Signed-off-by: Walter Lozano <walter.lozano@collabora.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
2020-07-09 22:00:29 -06:00
Walter Lozano
fed0f891c6 core: extend struct driver_info to point to device
Currently when creating an U_BOOT_DEVICE entry a struct driver_info
is declared, which contains the data needed to instantiate the device.
However, the actual device is created at runtime and there is no proper
way to get the device based on its struct driver_info.

This patch extends struct driver_info adding a pointer to udevice which
is populated during the bind process, allowing to generate a set of
functions to get the device based on its struct driver_info.

Signed-off-by: Walter Lozano <walter.lozano@collabora.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
2020-07-09 22:00:29 -06:00
Walter Lozano
908d0243ac core: drop const for struct driver_info
In order to prepare for a new support of phandle when OF_PLATDATA is used
drop the const for struct driver_info as this struct will need to be
updated on runtime.

Signed-off-by: Walter Lozano <walter.lozano@collabora.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
2020-07-09 22:00:29 -06:00
Walter Lozano
6397427c47 dm: doc: update of-plat with the support for driver aliases
Update the documentation with the support for driver aliases using
U_BOOT_DRIVER_ALIAS.

Signed-off-by: Walter Lozano <walter.lozano@collabora.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
2020-07-09 22:00:29 -06:00
Walter Lozano
361e733596 dtoc: add option to disable warnings
As dtoc now performs checks for valid driver names, when running dtoc
tests several warnings arise as these tests don't use valid driver
names.

This patch adds an option to disable those warning, which is only
intended for running tests.

Signed-off-by: Walter Lozano <walter.lozano@collabora.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
2020-07-09 22:00:29 -06:00
Walter Lozano
dac8228df9 dtoc: add support to scan drivers
Currently dtoc scans dtbs to convert them to struct platdata and
to generate U_BOOT_DEVICE entries. These entries need to be filled
with the driver name, but at this moment the information used is the
compatible name present in the dtb. This causes that only nodes with
a compatible name that matches a driver name generate a working
entry.

In order to improve this behaviour, this patch adds to dtoc the
capability of scan drivers source code to generate a list of valid driver
names and aliases. This allows to generate U_BOOT_DEVICE entries using
valid driver names and rise a warning in the case a name is not valid.

Signed-off-by: Walter Lozano <walter.lozano@collabora.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Open files in utf-8 mode:
Signed-off-by: Simon Glass <sjg@chromium.org>
2020-07-09 22:00:15 -06:00
Walter Lozano
addf358bac core: add support for U_BOOT_DRIVER_ALIAS
Currently when using OF_PLATDATA the binding between devices and drivers
is done trying to match the compatible string in the node with a driver
name. However, usually a single driver supports multiple compatible strings
which causes that only devices which its compatible string matches a
driver name get bound.

To overcome this issue, this patch adds the U_BOOT_DRIVER_ALIAS macro,
which generates no code at all, but allows an easy way to declare driver
name aliases. Thanks to this, dtoc could be improve to look for the driver
name based on its alias when it populates the U_BOOT_DEVICE entry.

Signed-off-by: Walter Lozano <walter.lozano@collabora.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
2020-07-09 18:57:22 -06:00
Walter Lozano
ace16e88d9 dtoc: add missing code comments
Add missing information about internal class members in order to make
the code easier to follow.

Signed-off-by: Walter Lozano <walter.lozano@collabora.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
2020-07-09 18:57:22 -06:00
Walter Lozano
e3e2470fdd drivers: rename drivers to match compatible string
When using OF_PLATDATA, the bind process between devices and drivers
is performed trying to match compatible string with driver names.
However driver names are not strictly defined, and also there are different
names used when declaring a driver with U_BOOT_DRIVER, the name of the
symbol used in the linker list and the used in the struct driver_info.

In order to make things a bit more clear, rename the drivers names. This
will also help for further OF_PLATDATA improvements, such as checking
for valid driver names.

Signed-off-by: Walter Lozano <walter.lozano@collabora.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Add a fix for sandbox of-platdata to avoid using an invalid ANSI colour:
Signed-off-by: Simon Glass <sjg@chromium.org>
2020-07-09 18:57:22 -06:00
Bin Meng
229806f759 test/dm: fdtdec: Add tests for fdtdec_add_reserved_memory()
This adds a test case to test the functionality of the fdtdec API
fdtdec_add_reserved_memory().

Signed-off-by: Bin Meng <bin.meng@windriver.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
2020-07-09 18:57:22 -06:00
Bin Meng
866f11efd7 test/dm: fdtdec: Corect a typo in dm_test_fdtdec_set_carveout()
It should be "writable".

Signed-off-by: Bin Meng <bin.meng@windriver.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
2020-07-09 18:57:22 -06:00
Bin Meng
c9a1df027a test/dm: fdtdec: Add the missing gd declaration
Add DECLARE_GLOBAL_DATA_PTR since it is referenced in the test codes.

Signed-off-by: Bin Meng <bin.meng@windriver.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
2020-07-09 18:57:22 -06:00
Heinrich Schuchardt
43913f01b9 cmd: fdt: remove CMD_FDT_MAX_DUMP
When printing the device tree we want to get an output that can be used as
input for the device tree compiler. This requires that we do not write
bogus lines like

    pcie@10000000 {
            interrupt-map = * 0x4000127c [0x00000280];

For instance the QEMU virt device has a property interrupt-map with 640
bytes which exceeds CMD_FDT_MAX_DUMP=64.

So lets do away with the artificial limitation to 64 bytes.

As indicated in commit f0a29d4331 ("fdt: Limit printed hex in fdt print
and list commands") if a device tree contains binary blobs, it may still
be desirable to limit the output length. Provide environment variable
fdt_max_dump for this purpose.

Fixes: 5d927b4286 ("Kconfig: Drop CONFIG_CMD_FDT_MAX_DUMP")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
2020-07-09 18:57:22 -06:00
Heinrich Schuchardt
dde173a204 log: use BIT() instead of 1 <<
Use the BIT() macro when creating a bitmask for the logging fields.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
2020-07-09 18:57:22 -06:00
Heinrich Schuchardt
3c21d7738a log: don't show function by default
The name of the function emitting a log message may be of interest for a
developer but is distracting for normal users. See the example below:

    try_load_entry() Booting: Debian

Make the default format for log messages customizable. By default show
only the message text.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
2020-07-09 18:57:22 -06:00
Simon Glass
8af45b1f20 checkpatch: Don't warn about PREFER_IF in headers/DT files
This warning should only be displayed for C files. Fix it and update the
test.

Signed-off-by: Simon Glass <sjg@chromium.org>
2020-07-09 18:57:22 -06:00