At present the number of configuration tables is set to 2. By
looking at which tables the Linux EFI stub or iPXE can process,
it looks 16 is a reasonable number.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
On x86 traditional E820 table is used to pass the memory information
to kernel. With EFI loader we can build the EFI memory map from it.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Built without a ROM image with FSP (u-boot.rom), the U-Boot loader applies
the microcode update data block encoded in Device Tree to the bootstrap
processor but not passed to the other CPUs when multiprocessing is enabled.
If the bootstrap processor successfully performs a microcode update
from Device Tree, use the same data block for the other processors.
Signed-off-by: Ivan Gorinov <ivan.gorinov@intel.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
[bmeng: fixed build errors on edison and qemu-x86]
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
This adds the scsi command to coreboot and qemu, to be in consistent
with other x86 targets.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
With the introduction of early timer support in the TSC driver,
the capability of getting clock rate from device tree was lost
unfortunately. Now we bring such functionality back, but with a
limitation that when TSC is used as early timer, specifying clock
rate from device tree does not work.
This fixes random boot failures seen on QEMU targets: printing "TSC
frequency is ZERO" and reset forever.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Enable CVE-2017-5715 option to set the IBE bit. This enables kernel
workarounds necessary for the said CVE.
With this enabled, Linux reports:
CPU0: Spectre v2: using BPIALL workaround
This workaround may need to be re-applied in OS environment around low
power transition resume states where context of ACR would be lost (off-mode
etc).
Signed-off-by: Nishanth Menon <nm@ti.com>
Enable CVE_2017_5715 and since we have our own v7_arch_cp15_set_acr
function to setup the bits, we are able to override the settings.
Without this enabled, Linux kernel reports:
CPU0: Spectre v2: firmware did not set auxiliary control register IBE bit, system vulnerable
With this enabled, Linux kernel reports:
CPU0: Spectre v2: using ICIALLU workaround
NOTE: This by itself does not enable the workaround for CPU1 (on
OMAP5 and DRA72/AM572 SoCs) and may require additional kernel patches.
Signed-off-by: Nishanth Menon <nm@ti.com>
As recommended by Arm in [1], ACTLR[0] (Enable invalidates of BTB)
needs to be set[2] for BTB to be invalidated on ICIALLU. This needs to
be done unconditionally for Cortex-A15 processors. Provide a config
option for platforms to enable this option based on impact analysis
for products.
NOTE: This patch in itself is NOT the final solution, this requires:
a) Implementation of v7_arch_cp15_set_acr on SoCs which may not
provide direct access to ACR register.
b) Operating Systems such as Linux to provide adequate workaround in the
right locations.
c) This workaround applies to only the boot processor. It is important
to apply workaround as necessary (context-save-restore) around low
power context loss OR additional processors as necessary in either
firmware support OR elsewhere in OS.
[1] https://developer.arm.com/support/security-update
[2] http://infocenter.arm.com/help/topic/com.arm.doc.ddi0438c/BABGHIBG.html
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Robin Murphy <robin.murphy@arm.com>
Cc: Florian Fainelli <f.fainelli@gmail.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Christoffer Dall <christoffer.dall@linaro.org>
Cc: Andre Przywara <Andre.Przywara@arm.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Tom Rini <trini@konsulko.com>
Cc: Michael Nazzareno Trimarchi <michael@amarulasolutions.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Tested-by: Fabio Estevam <fabio.estevam@nxp.com>
As recommended by Arm in [1], IBE[2] has to be enabled unconditionally
for BPIALL to be functional on Cortex-A8 processors. Provide a config
option for platforms to enable this option based on impact analysis
for products.
NOTE: This patch in itself is NOT the final solution, this requires:
a) Implementation of v7_arch_cp15_set_acr on SoCs which may not
provide direct access to ACR register.
b) Operating Systems such as Linux to provide adequate workaround in the right
locations.
c) This workaround applies to only the boot processor. It is important
to apply workaround as necessary (context-save-restore) around low
power context loss OR additional processors as necessary in either
firmware support OR elsewhere in OS.
[1] https://developer.arm.com/support/security-update
[2] http://infocenter.arm.com/help/topic/com.arm.doc.ddi0344k/Bgbffjhh.html
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Robin Murphy <robin.murphy@arm.com>
Cc: Florian Fainelli <f.fainelli@gmail.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Christoffer Dall <christoffer.dall@linaro.org>
Cc: Andre Przywara <Andre.Przywara@arm.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Tom Rini <trini@konsulko.com>
Cc: Michael Nazzareno Trimarchi <michael@amarulasolutions.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Tested-by: Fabio Estevam <fabio.estevam@nxp.com>
This bug is the combination of dwc2 USB controller and lan78xx
USB ethernet controller, which is the combination in use on
the Raspberry Pi Model 3 B+.
When the host attempts to receive a packet, but a packet has not
arrived, the lan78xx controller responds by setting BIR
(Bulk-In Empty Response) to NAK. Unfortunately, this hangs
the USB controller and requires the USB controller to
be reset.
The fix proposed is to have the lan78xx controller respond
by setting BIR to ZLP.
Signed-off-by: Andrew Thomas <andrew.thomas@oracle.com>
Tested-by: Peter Robinson <pbrobinson@gmail.com>
Reviewed-by: Alexander Graf <agraf@suse.de>
When using a redundant environment a read error should simply mean to
not use that copy instead of giving up completely. The other copy may
be just fine.
Signed-off-by: Joe Hershberger <joe.hershberger@ni.com>
Signed-off-by: Ioan-Adrian Ratiu <adrian.ratiu@ni.com>
For now, the existing SPL MXS NAND driver only supports to identify
ONFi-compliant NAND chips. In order to allow identifying
non-ONFi-compliant chips add `mxs_flash_full_ident()` which uses the
`nand_get_flash_type()` functionality from `nand_base.c` to lookup
for supported NAND chips in the chip ID list.
For compatibility reason the full identification support is only
available if the config option `CONFIG_SPL_NAND_IDENT` is enabled.
The lookup was tested on a custom i.MX6ULL board with a Toshiba
TC58NVG1S3HTAI0 NAND chip.
Signed-off-by: Jörg Krause <joerg.krause@embedded.rocks>
The existing `mxs_flash_ident()` is limited to identify ONFi compliant
NAND chips only. In order to support non-ONFi NAND chips refactor the
function and rename it to `mxs_flash_onfi_ident()`.
A follow-up patch will add `mxs_flash_full_ident()` which allows to use
the chip ID list to lookup for supported NAND flashs.
Signed-off-by: Jörg Krause <joerg.krause@embedded.rocks>
Add the config option `CONFIG_SPL_NAND_IDENT` for using the NAND chip ID list
to identify the NAND flash in SPL.
Signed-off-by: Jörg Krause <joerg.krause@embedded.rocks>
`nand_get_flash_type()` allows identification of supported NAND flashs.
The function is useful in SPL (like mxs_nand_spl.c) to lookup for a NAND
flash (which does not support ONFi) instead of using nand_simple.c and
hard-coding all required NAND parameters.
Signed-off-by: Jörg Krause <joerg.krause@embedded.rocks>
Since commit 1da1938d57 ("spl: Add default values for ARCH_MX7")
CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR is selected by default on
i.MX7 platforms, so remove it from the board defconfig.
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
fdt_file is looking for imx6ul-geam-kit.dtb but Linux
has imx6ul-geam.dtb, since Linux skipped -kit on file name
by below commit.
"ARM: dts: imx6ul-geam: Skip suffix -kit from dts name"
(sha1: 182de5ebce71e469cfa686fcdf08c9cbe11ece97)
So, due to this mismatch U-Boot failed to pick the
proper dtb which eventually break the Linux boot.
This patch fixed this mismatch by
- renaming dts files
- update config option to use new dtb file
- update fdt_file to new dtb file name
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
The PFUZE3000 uses registers addresses up to 0xff.
The DM pfuze100 driver supports both pfuze100 and pfuze3000. Allow it
to use the device type to return the correct number of registers.
Also rename the too generic PMIC_NUM_OF_REGS enumeration value for
pfuze3000 to match the other "PFUZE3000_" prefixed enumerations and the
pfuze100 enumeration value PFUZE100_NUM_OF_REGS.
Cc: Peng Fan <Peng.Fan@freescale.com>
Cc: Jaehoon Chung <jh80.chung@samsung.com>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Fabio Estevam <fabio.estevam@nxp.com>
Signed-off-by: Trent Piepho <tpiepho@impinj.com>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
Add support for specified ECC strength/size using device tree
properties nand-ecc-strength/nand-ecc-step-size.
This aligns behavior with the mainline driver, such that:
- If fsl,use-minimal-ecc is requested it will use data from
data sheet/ONFI. If this is not available the driver will fail.
- If nand-ecc-strength/nand-ecc-step-size are specified those
value will be used.
- By default maximum possible ECC strength is used
Signed-off-by: Stefan Agner <stefan.agner@toradex.com>
Support driver data from device tree. Also support fsl,use-minimal-ecc
similar to Linux' GPMI NAND driver.
Signed-off-by: Stefan Agner <stefan.agner@toradex.com>
In preparation for device tree support separate board init
from controller init similar to other raw NAND drivers.
Signed-off-by: Stefan Agner <stefan.agner@toradex.com>
This function initializes DMA descriptors so mxs_nand_init_dma is
more precise. It also frees up the rather generic name mxs_nand_init.
Signed-off-by: Stefan Agner <stefan.agner@toradex.com>
Move GPMI and BCH register structs to the driver struct mxs_nand_info
in prepartion for device tree support.
Signed-off-by: Stefan Agner <stefan.agner@toradex.com>
Add support for minimum ECC strength supported by the NAND chip.
This aligns with the behavior when using the fsl,use-minimum-ecc
device tree property in Linux.
Signed-off-by: Stefan Agner <stefan.agner@toradex.com>
Report correct ECC parameters back to the stack. Do not report
bytes as we have it not immeaditly available and the Linux version
also does not report it. It seems to have no aversive effect.
Signed-off-by: Stefan Agner <stefan.agner@toradex.com>
Calculate BCH geometry at start and store the information in
a structure. This avoids recalculation on every page access
and allows to calculate ECC relevant information in one place.
This patch does not change ECC layout or driver behavior in
any way.
The patch aligns the driver somewhat with the Linux GPMI NAND
driver which drives the same IP.
Signed-off-by: Stefan Agner <stefan.agner@toradex.com>
Add config option which allows to enable on flash bad block table
support. This has the same effect as when using the device tree
property "nand-on-flash-bbt" in Linux.
Signed-off-by: Stefan Agner <stefan.agner@toradex.com>
Instead of completing initialization via scan_bbt callback use
NAND self init to initialize the GPMI (MXS) NAND controller.
Suggested-by: Scott Wood <oss@buserror.net>
Signed-off-by: Stefan Agner <stefan.agner@toradex.com>
In preparation to convert the driver to use NAND self init
provide a new minimal init for SPL builds. As a side effect
this also reduces size of SPL by about 4KiB.
Signed-off-by: Stefan Agner <stefan.agner@toradex.com>
commit 8480792287
("spi: omap3: Skip set_mode, set_speed from claim") did break SPI
support on my AM335x board.
The named commit:
- ignored the responsible arguments (speed, mode)
The set speed/mode function must use the supplied function arguments to
work properly. With this commit we take those arguments and transfer
them to the priv-data.
- used wrong udevice pointer for getting priv data
the udevice-pointer within function argument is already the spi-bus
device, so it is wrong looking here for some parent (ocp-bus in this
case) and getting priv-pointer from there.
Signed-off-by: Hannes Schmelzer <oe5hpm@oevsv.at>
Reviewed-by: Jagan Teki <jagan@openedev.com>
Otherwise the frequency is zero and the clock divider cannot be setup by
'omap3_spi_set_speed' function.
Signed-off-by: Hannes Schmelzer <oe5hpm@oevsv.at>
Reviewed-by: Jagan Teki <jagan@openedev.com>
CS GPIO activation low/high is determinated by the device tree
so we don't need to take in accoung in cs_activate and cs_deactivate
Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Jagan Teki <jagan@openedev.com>
This patch replaced "return 0" with "return status" to fix the
incorrect return value error reported by the coverity.
Reviewed-by: Michal Simek <michal.simek@xilinx.com>
Signed-off-by: Vipul Kumar <vipul.kumar@xilinx.com>
[jagan: rebased on master]
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Each entry of the EFI memory descriptors occupies map->desc_size,
not sizeof(struct efi_mem_desc).
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
At present in dram_init_banksize() it ignores conventional memory
above 4GB. This leads to wrong DRAM size is printed during boot.
Remove such limitation.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Enable PRE_CONSOLE_BUFFER so that the full boot output can be viewed
on the video console for the EFI payload.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The use_uart assignment should follow immediately after the call to
exit_boot_services(), in case we want some debug output after that.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Since commit bb0bb91cf0 ("efi_stub: Use efi_uintn_t"), EFI x86
64-bit payload does not work anymore. The call to GetMemoryMap()
in efi_stub.c fails with return code EFI_INVALID_PARAMETER. Since
the payload itself is still 32-bit U-Boot, efi_uintn_t gets wrongly
interpreted as int, but it should actually be long in a 64-bit EFI
environment.
This changes the x86 __kernel_size_t conditionals to use compiler
provided defines instead. That way we always adhere to the build
environment we're in and the definitions adjust automatically.
Fixes: bb0bb91cf0 ("efi_stub: Use efi_uintn_t")
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
