Allwinner devices support SPI flash as one of the possible
bootable media type. The SPI flash chip needs to be connected
to SPI0 pins (port C) to make this work. More information is
available at:
https://linux-sunxi.org/Bootable_SPI_flash
This patch adds the initial support for booting from SPI flash.
The existing SPI frameworks are not used in order to reduce the
SPL code size. Right now the SPL size grows by ~370 bytes when
CONFIG_SPL_SPI_SUNXI option is enabled.
While there are no popular Allwinner devices with SPI flash at
the moment, testing can be done using a SPI flash module (it
can be bought for ~2$ on ebay) and jumper wires with the boards,
which expose relevant pins on the expansion header. The SPI flash
chips themselves are very cheap (some prices are even listed as
low as 4 cents) and should not cost much if somebody decides to
design a development board with an SPI flash chip soldered on
the PCB.
Another nice feature of the SPI flash is that it can be safely
accessed in a device-independent way (since we know that the
boot ROM is already probing these pins during the boot time).
And if, for example, Olimex boards opted to use SPI flash instead
of EEPROM, then they would have been able to have U-Boot installed
in the SPI flash now and boot the rest of the system from the SATA
hard drive. Hopefully we may see new interesting Allwinner based
development boards in the future, now that the software support
for the SPI flash is in a better shape :-)
Testing can be done by enabling the CONFIG_SPL_SPI_SUNXI option
in a board defconfig, then building U-Boot and finally flashing
the resulting u-boot-sunxi-with-spl.bin binary over USB OTG with
a help of the sunxi-fel tool:
sunxi-fel spiflash-write 0 u-boot-sunxi-with-spl.bin
The device needs to be switched into FEL (USB recovery) mode first.
The most suitable boards for testing are Orange Pi PC and Pine64.
Because these boards are cheap, have no built-in NAND/eMMC and
expose SPI0 pins on the Raspberry Pi compatible expansion header.
The A13-OLinuXino-Micro board also can be used.
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Add an implementation of this function which mirrors the functions of the
automatic device-tree implementation. This can be used with of-platdata to
create regmaps.
Signed-off-by: Simon Glass <sjg@chromium.org>
Devices which use of-platdata have their own platdata. However, in many
cases the driver will have its own auto-alloced platdata, for use with the
device tree. The ofdata_to_platdata() method converts the device tree
settings to platdata.
With of-platdata we would not normally allocate the platdata since it is
provided by the U_BOOT_DEVICE() declaration. However this is inconvenient
since the of-platdata struct is closely tied to the device tree properties.
It is unlikely to exactly match the platdata needed by the driver.
In fact a useful approach is to declare platdata in the driver like this:
struct r3288_mmc_platdata {
struct dtd_rockchip_rk3288_dw_mshc of_platdata;
/* the 'normal' fields go here */
};
In this case we have dt_platadata available, but the normal fields are not
present, since ofdata_to_platdata() is never called. In fact driver model
doesn't allocate any space for the 'normal' fields, since it sees that there
is already platform data attached to the device.
To make this easier, adjust driver model to allocate the full size of the
struct (i.e. platdata_auto_alloc_size from the driver) and copy in the
of-platdata. This means that when the driver's bind() method is called,
the of-platdata will be present, followed by zero bytes for the empty
'normal field' portion.
A new DM_FLAG_OF_PLATDATA flag is available that indicates that the platdata
came from of-platdata. When the allocation/copy happens, the
DM_FLAG_ALLOC_PDATA flag will be set as well. The dtoc tool is updated to
output the platdata_size field, since U-Boot has no other way of knowing
the size of the of-platdata struct.
Signed-off-by: Simon Glass <sjg@chromium.org>
This header can be included from anywhere, but will only pull in the
of-platdata struct definitions when this feature is enabled (and only in
SPL).
Signed-off-by: Simon Glass <sjg@chromium.org>
Provide a new function which can cope with obtaining information from
of-platdata instead of the device tree.
Signed-off-by: Simon Glass <sjg@chromium.org>
Start up the test devices. These print out of-platdata contents, providing a
check that the of-platdata feature is working correctly.
The device-tree changes are made to sandbox.dts rather than test.dts. since
the former controls the of-platdata generation.
Signed-off-by: Simon Glass <sjg@chromium.org>
It is useful to be able to build SPL for sandbox. It provides additional
build coverage and allows SPL features to be tested in sandbox. However
it does not need worthwhile to always create an SPL build. It nearly
doubles the build time and the feature is (so far) seldom used.
So for now, create a separate build target for sandbox SPL. This allows
experimentation with this new feature without impacting existing workflows.
Signed-off-by: Simon Glass <sjg@chromium.org>
SPL is expected to load and run U-Boot. This needs to work with sandbox also.
Provide a function to locate the U-Boot image, and another to start it. This
allows SPL to function on sandbox as it does on other archs.
Signed-off-by: Simon Glass <sjg@chromium.org>
SPL tends to be more space-constrained that U-Boot proper. Some error
messages are best suppressed in SPL. Add a macros to make this easy.
warn_non_spl() does nothing when built in SPL code.
Signed-off-by: Simon Glass <sjg@chromium.org>
This patch adds SDRAM support for stm32f746 discovery board.
This patch depends on previous patch.
This patch is based on STM32F4 and emcraft's[1].
[1]: https://github.com/EmcraftSystems/u-boot
Signed-off-by: Toshifumi NISHINAGA <tnishinaga.dev@gmail.com>
This patch adds 200MHz clock configuration for stm32f746 discovery board.
This patch is based on STM32F4 and emcraft's[1].
[1]: https://github.com/EmcraftSystems/u-boot
Signed-off-by: Toshifumi NISHINAGA <tnishinaga.dev@gmail.com>
Make the external devices the preferred ones when booting the system
(usb is already the first option). This allows users to easily boot
custom distributions without requiring them to reflash/customize u-boot.
Cc: Mateusz Kulikowski <mateusz.kulikowski@gmail.com>
Signed-off-by: Ricardo Salveti <rsalveti@rsalveti.net>
Reviewed-by: Andreas Färber <afaerber@suse.de>
Tested-by: Andreas Färber <afaerber@suse.de>
Acked-by: Mateusz Kulikowski <mateusz.kulikowski@gmail.com>
Add generic functions which can look up information about a category:
- the number of items in the category
- the category description
- an item long time
- an item short time
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Add a table that contains the category name, the number of items in each
category and a pointer to the table of items. This will allow us to use
generic code to deal with the categories.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
We need to know the number of values of each category (architecture,
compression, OS and image type). To make this value easier to maintain,
convert all values to enums. The count is then automatic.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
For most of architectures in U-Boot, virtual address is straight
mapped to physical address. So, it makes sense to have generic
defines of ioremap and friends in <linux/io.h>.
All of them are just empty and will disappear at compile time, but
they will be helpful to implement drivers which are counterparts of
Linux ones.
I notice MIPS already has its own implementation, so I added a
Kconfig symbol CONFIG_HAVE_ARCH_IOREMAP which MIPS (and maybe
Sandbox as well) can select.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Currently, this is only defined in arch/arm/include/asm/types.h,
so move it to include/linux/types.h to make it available for all
architectures.
I defined it with phys_addr_t as Linux does. I needed to surround
the define with #ifdef __KERNEL__ ... #endif to avoid build errors
in tools building. (Host tools should not include <linux/types.h>
in the first place, but this is already messy in U-Boot...)
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The next stage boot loader image and the selected FDT can be post-
processed by board/platform/device-specific code, which can include
modifying the size and altering the starting source address before
copying these binary blobs to their final destination. This might be
desired to do things like strip headers or footers attached to the
images before they were packaged into the FIT, or to perform operations
such as decryption or authentication. Introduce new configuration
option CONFIG_SPL_FIT_IMAGE_POST_PROCESS to allow controlling this
feature. If enabled, a platform-specific post-process function must
be provided.
Signed-off-by: Daniel Allred <d-allred@ti.com>
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Define a default board_run_command() function. This function contains
the commands needed to boot the board when CLI is disabled (CONFIG_CMDLINE=n).
Signed-off-by: Andrej Rosano <andrej@inversepath.com>
Add USB host support.
Tested by connecting a USB pen drive:
=> usb start
starting USB...
USB0: Port not available.
USB1: USB EHCI 1.00
scanning bus 1 for devices... 2 USB Device(s) found
scanning usb for storage devices... 1 Storage Device(s) found
Signed-off-by: Vanessa Maegima <vanessa.maegima@nxp.com>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
Add script for retrieving the kernel via TFTP and mounting the
rootfs via NFS.
Signed-off-by: Diego Dorta <diego.dorta@nxp.com>
Acked-by: Fabio Estevam <fabio.estevam@nxp.com>
DFU is a convenient way to program U-boot binary into the eMMC.
Add support for it.
Signed-off-by: Vanessa Maegima <vanessa.maegima@nxp.com>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
Pico-imx6ul has a KSZ8081 Ethernet PHY.
Add support for it.
Signed-off-by: Diego Dorta <diego.dorta@nxp.com>
Acked-by: Fabio Estevam <fabio.estevam@nxp.com>
Reviewed-by: Stefano Babic <sbabic@denx.de>
Instead of passing the total RAM size via PHYS_SDRAM_SIZE option,
we should better use imx_ddr_size() function, which automatically
determines the RAM size.
Signed-off-by: Vanessa Maegima <vanessa.maegima@nxp.com>
Instead of passing the total RAM size via PHYS_SDRAM_SIZE option,
we should better use imx_ddr_size() function, which automatically
determines the RAM size.
Signed-off-by: Vanessa Maegima <vanessa.maegima@nxp.com>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
Instead of passing the total RAM size via PHYS_SDRAM_SIZE option,
we should better use imx_ddr_size() function, which automatically
determines the RAM size.
Signed-off-by: Vanessa Maegima <vanessa.maegima@nxp.com>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
Instead of passing the total RAM size via PHYS_SDRAM_SIZE option,
we should better use imx_ddr_size() function, which automatically
determines the RAM size.
Signed-off-by: Vanessa Maegima <vanessa.maegima@nxp.com>
Acked-by: Fabio Estevam <fabio.estevam@nxp.com>
Custom Board based on MX6 Dual, 1GB RAM and eMMC.
There are two variants of the board with and without
PCIe (ZC5202 and ZC5601).
Signed-off-by: Stefano Babic <sbabic@denx.de>
Add support for Advantech SOM-DB5800 with the SOM-6867 installed.
This is very similar to conga-qeval20-qa3-e3845 in that there is a
reference carrier board (SOM-DB5800) with a Baytrail based SoM (SOM-6867)
installed.
Currently supported:
- 2x UART (From ITE EC on SOM-6867) routed to COM3/4 connectors on
SOM-DB5800.
- 4x USB 2.0 (EHCI)
- Video
- SATA
- Ethernet
- PCIe
- Realtek ALC892 HD Audio
Pad configuration for HDA_RSTB, HDA_SYNC, HDA_CLK, HDA_SDO
HDA_SDI0 is set in DT to enable HD Audio codec.
Pin defaults for codec pin complexs are not changed.
Not supported:
- Winbond Super I/O (Must be disabled with jumpers on SOM-DB8500)
- USB 3.0 (XHCI)
- TPM
Signed-off-by: George McCollister <george.mccollister@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Some uclass ids are out of order. Per the comments, sort them
in alphabetical order.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
The cros-ec keyboard is always a child of the cros-ec node. Rather than
searching the device tree, looking at the children. Remove the compat string
which is now unused.
Signed-off-by: Simon Glass <sjg@chromium.org>
A few drivers have moved to driver model, so we can drop these strings.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Jaehoon Chung <jh80.chung@samsung.com>
We have drivers for several more devices now, so drop the strings which are
no-longer used.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
The driver model conversion for MMC has moved in small steps. The first step
was to have an MMC device (CONFIG_DM_MMC). The second was to use a child
block device (CONFIG_BLK). The final one is to use driver model for MMC
operations (CONFIG_DM_MMC_OP). Add support for this.
The immediate priority is to make all boards that use DM_MMC also use those
other two options. This will allow them to be removed.
Signed-off-by: Simon Glass <sjg@chromium.org>
This option is not actually needed for rockchip boards. Drop it, since it
will not support driver-model MMC operation support.
Signed-off-by: Simon Glass <sjg@chromium.org>
These comments were missed when the original code was written. Add them to
help people port their drivers over.
Signed-off-by: Simon Glass <sjg@chromium.org>
