- Use device tree for FSP-M and FSP-S configuration on Intel Apollo Lake
- Add SMBIOS cbmem entry parsing for coreboot
- Various clean-ups to CBFS implementation
Simon Glass [Sun, 24 May 2020 23:38:23 +0000 (17:38 -0600)]
cbfs: Allow reading a file from a CBFS given its base addr
Currently we support reading a file from CBFS given the address of the end
of the ROM. Sometimes we only know the start of the CBFS. Add a function
to find a file given that.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Sun, 24 May 2020 23:38:22 +0000 (17:38 -0600)]
cbfs: Change file_cbfs_find_uncached() to return an error
This function currently returns a node pointer so there is no way to know
the error code. Also it uses data in BSS which seems unnecessary since the
caller might prefer to use a local variable.
Update the function and split its body out into a separate function so we
can use it later.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Sun, 24 May 2020 23:38:21 +0000 (17:38 -0600)]
cbfs: Return the error code from file_cbfs_init()
We may as well return the error code and use it directly in the command
code. CBFS still uses its own error enum which we may be able to remove,
but leave it for now.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Sun, 24 May 2020 23:38:20 +0000 (17:38 -0600)]
cbfs: Record the start address in cbfs_priv
The start address of the CBFS is used when scanning for files. It makes
sense to put this in our cbfs_priv struct and calculate it when we read
the header.
Update the code accordingly.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Sun, 24 May 2020 23:38:19 +0000 (17:38 -0600)]
cbfs: Use void * for the position pointers
It doesn't make sense to use u8 * as the pointer type for accessing the
CBFS since we do not access it as bytes, but via structures. Change it to
void *, which allows us to avoid a cast.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Sun, 24 May 2020 23:38:18 +0000 (17:38 -0600)]
cbfs: Unify the two header loaders
These two functions have mostly the same code. Pull this out into a common
function.
Also make this function zero the private data so that callers don't have
to do it. Finally, update cbfs_load_header_ptr() to take the base of the
ROM as its parameter, which makes more sense than passing the address of
the header within the ROM.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Sun, 24 May 2020 23:38:17 +0000 (17:38 -0600)]
cbfs: Adjust cbfs_load_header_ptr() to use cbfs_priv
This function is strange at the moment in that it takes a header pointer
but then accesses the cbfs_s global. Currently clients have their own priv
pointer, so update the function to take that as a parameter instead.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Sun, 24 May 2020 23:38:16 +0000 (17:38 -0600)]
cbfs: Adjust file_cbfs_load_header() to use cbfs_priv
This function is strange at the moment in that it takes a header pointer
but then accesses the cbfs_s global. Currently clients have their own priv
pointer, so update the function to take that as a parameter instead.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Sun, 24 May 2020 23:38:12 +0000 (17:38 -0600)]
cbfs: Rename the result variable
At present the result variable in the cbfs_priv is called 'result' as is
the local variable in a few functions. Change the latter to 'ret' which is
more common in U-Boot and avoids confusion.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com> Reviewed-by: Heinrich Schuchardt <xypron.gpk@gmx.de> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
A the moment the FSP-S configuration is a mix of hard coded values and
devicetree properties.
This patch makes FSP-S full configurable from devicetree by
adding binding properties for all FSP-S parameters.
Co-developed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com> Signed-off-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com> Signed-off-by: Bernhard Messerklinger <bernhard.messerklinger@br-automation.com> Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Simon Glass <sjg@chromium.org> (Tested on coral) Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
A the moment the FSP-M configuration is a mix of hard coded values and
devicetree properties.
This patch makes FSP-M full configurable from devicetree by adding
binding properties for all FSP-M parameters.
Co-developed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com> Signed-off-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com> Signed-off-by: Bernhard Messerklinger <bernhard.messerklinger@br-automation.com> Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Simon Glass <sjg@chromium.org> (Tested on coral)
[sjg: Fix a build error for coral] Signed-off-by: Simon Glass <sjg@chromium.org>
[bmeng: Add __maybe_unused to fsp_update_config_from_dtb()] Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
x86: apl: Only load VBT if CONFIG_HAVE_VBT is enabled
Only load VBT if it's present in the u-boot.rom.
Signed-off-by: Bernhard Messerklinger <bernhard.messerklinger@br-automation.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Simon Glass <sjg@chromium.org> (Tested on coral) Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Jakov Petrina [Tue, 12 May 2020 10:02:47 +0000 (12:02 +0200)]
arm: mvebu: armada-3720-uDPU: fix PHY mode definition to sgmii-2500
Commit f49ac7e1c4 switched the default PHY speed to 3.125Gbit to resolve
issues with SFP modules. However, U-Boot does not have a "2500base-x"
phy-mode.
Resolve this by using "sgmii-2500" instead.
Signed-off-by: Jakov Petrina <jakov.petrina@sartura.hr> Signed-off-by: Vladimir Vid <vladimir.vid@sartura.hr> Reviewed-by: Stefan Roese <sr@denx.de> Cc: Luka Perkov <luka.perkov@sartura.hr> Cc: Stefan Roese <sr@denx.de>
Ezra Buehler [Sat, 9 May 2020 20:05:39 +0000 (22:05 +0200)]
arm: mvebu: ds414: define CONFIG_SYS_U_BOOT_OFFS
Without CONFIG_SYS_U_BOOT_OFFS set to CONFIG_SYS_SPI_U_BOOT_OFFS, U-Boot
will be located at address 0x16000. But, SPL will try to load the
payload from 0x24000 causing the boot to hang.
Signed-off-by: Ezra Buehler <ezra@easyb.ch> Reviewed-by: Stefan Roese <sr@denx.de>
Ezra Buehler [Sat, 9 May 2020 20:05:38 +0000 (22:05 +0200)]
arm: mvebu: ds414: add u-boot,dm-pre-reloc to spi0
Without this U-Boot-specific property, booting on the Synology DS414
(or DS214+) fails in SPL. The spi0 DT node is not scanned, as a result
the SPI flash cannot be found.
Signed-off-by: Ezra Buehler <ezra@easyb.ch> Reviewed-by: Stefan Roese <sr@denx.de>
SMP support for S-mode U-Boot is enabled only if SBI_V01 is enabled.
There is no point in supporting SMP related (IPI and fences) SBI calls
when SBI_V02 is enabled.
Modify all the SMP related SBI calls to be defined only for SBI_V01.
Signed-off-by: Atish Patra <atish.patra@wdc.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tom Rini [Mon, 25 May 2020 18:09:42 +0000 (14:09 -0400)]
Merge tag 'ti-v2020.07-rc3' of https://gitlab.denx.de/u-boot/custodians/u-boot-ti
- Enable DM_ETH on omap3_logic board
- Enable Caches in SPL for K3 platforms
- Enable backup boot mode support for J721E
- Update the DDR timings for AM654 EVM
- Add automated tests for RX-51
Tom Rini [Mon, 25 May 2020 15:56:57 +0000 (11:56 -0400)]
Merge branch '2020-05-25-misc-fixes'
- A few minor Kconfig migrations / corrections
- DFU doc fixes/improvements
- Bugfix for ARMv8, env userspace building, more NULL checks in generic
PHY code
Michael Walle [Fri, 22 May 2020 12:07:37 +0000 (14:07 +0200)]
cmd: zip: fix implicit declaration warning
Fix the following warning:
cmd/zip.c: In function ‘do_zip’:
cmd/zip.c:30:6: warning: implicit declaration of function ‘gzip’; did you mean ‘do_zip’? [-Wimplicit-function-declaration]
if (gzip((void *) dst, &dst_len, (void *) src, src_len) != 0)
^~~~
do_zip
Include gzip.h header which declares the gzip() function.
Signed-off-by: Michael Walle <michael@walle.cc> Reviewed-by: Simon Glass <sjg@chromium.org>
Michael Walle [Fri, 22 May 2020 12:07:36 +0000 (14:07 +0200)]
cmd: zip: automatically pull in gzip()
Move the CONFIG_GZIP_COMPRESSED from a config.h macro to a Kconfig menu
item. It is not selectable by a user because there is no reason to do
so. Instead it will be automatically selected by the stuff which uses
gzip(), like the zip command.
Remove it from the config_whitelist.txt. Also remove
CONFIG_GZIP_COMPRESS_DEF_SZ as this was never used on any board. The
default seems to be sane, otherwise it should be added as a Kconfig
option.
Signed-off-by: Michael Walle <michael@walle.cc> Reviewed-by: Simon Glass <sjg@chromium.org>
Romain Naour [Thu, 21 May 2020 21:22:06 +0000 (23:22 +0200)]
tools/env/fw_env.h: remove env.h
As reported by Nicolas Carrier on the Buildroot mailing list [1],
there is a new build issue while building a program which interacts with
the u-boot environment. This program uses the headers of the ubootenv
library provided by uboot-tools.
This is a recent change from uboot [2] adding "#include <env.h>" to
fw_env.h. Adding env.h require a board configuration to build since
it also include compiler.h (and others uboot internal includes).
env.h include seems not needed since env_set() is not used in fw_env tool.
Nicolas removed env.h from fw_env tool and fixed it's build issue.
It is possible that users of generic_phy_*() APIs may pass a valid
struct phy pointer but phy->dev can be NULL, leading to NULL pointer
deference in phy_dev_ops().
So call generic_phy_valid() to verify that phy and phy->dev are both
valid.
The enum dcache_optoion contains a shift left 2 bits in the armv8 case
already. The PMD_ATTRINDX(option) macro will perform a left shift of 2
bits. Perform a right shift so that in the end we get the correct
value.
[trini: Reword the commit message] Reviewed-by: Ye Li <ye.li@nxp.com> Signed-off-by: Peng Fan <peng.fan@nxp.com>
Marek Vasut [Wed, 25 Mar 2020 17:47:10 +0000 (18:47 +0100)]
net: ks8851: Receive one packet per recv call
Instead of reading out the entire FIFO and possibly overwriting U-Boot
memory, read out one packet per recv call, pass it to U-Boot network
stack, and repeat. It is however necessary to cache RXFC value, because
reading that one out clears it.
Signed-off-by: Marek Vasut <marex@denx.de> Cc: Eugen Hristev <eugen.hristev@microchip.com> Cc: Joe Hershberger <joe.hershberger@ni.com>
Marek Vasut [Wed, 25 Mar 2020 16:35:00 +0000 (17:35 +0100)]
net: ks8851: Pass around driver private data
Introduce a private data structure for this driver with embedded
struct eth_device and pass it around. This prepares the driver to
work with both DM and non-DM systems.
Signed-off-by: Marek Vasut <marex@denx.de> Cc: Eugen Hristev <eugen.hristev@microchip.com> Cc: Joe Hershberger <joe.hershberger@ni.com>
Marek Vasut [Wed, 25 Mar 2020 17:15:46 +0000 (18:15 +0100)]
net: ks8851: Clean up chip ID readout
There is only one chip ID in the table of chip IDs for this chip.
Read out the chip ID instead and mask off the last "revision" bit
to check the chip ID, this works for all chips in the family. Then
drop the chip ID passing around.
Signed-off-by: Marek Vasut <marex@denx.de> Cc: Eugen Hristev <eugen.hristev@microchip.com> Cc: Joe Hershberger <joe.hershberger@ni.com>
Marek Vasut [Wed, 25 Mar 2020 16:23:11 +0000 (17:23 +0100)]
net: ks8851: Remove type_frame_head
The packet status and length information should be extracted from the
FIFO per-packet. Adjust the code such that it reads the packet meta
data and then the packet afterward, if applicable.
Signed-off-by: Marek Vasut <marex@denx.de> Cc: Eugen Hristev <eugen.hristev@microchip.com> Cc: Joe Hershberger <joe.hershberger@ni.com>
Marek Vasut [Wed, 25 Mar 2020 16:02:51 +0000 (17:02 +0100)]
net: ks8851: Use 16bit RXQCR access
Per KS8851-16MLL, the RXQCR is a 16bit register. Use 16bit accessors
to it consistently and drop the ks_wrreg8() function altogether, as
it is not used anymore.
Signed-off-by: Marek Vasut <marex@denx.de> Cc: Eugen Hristev <eugen.hristev@microchip.com> Cc: Joe Hershberger <joe.hershberger@ni.com>
Marek Vasut [Wed, 25 Mar 2020 15:52:38 +0000 (16:52 +0100)]
net: ks8851: Replace malloc()+memset() with calloc()
Replace combination of malloc()+memset() with calloc() as the behavior
is exactly the same and the amount of code is reduced. Moreover, remove
printf() in the fail path, as it is useless, and return proper -ENOMEM
return code.
Signed-off-by: Marek Vasut <marex@denx.de> Cc: Eugen Hristev <eugen.hristev@microchip.com> Cc: Joe Hershberger <joe.hershberger@ni.com>
Adam Ford [Sat, 16 May 2020 06:19:53 +0000 (01:19 -0500)]
usb: ehci-omap: Add Support for DM_USB and OF_CONTROL
The omap3.dtsi file shows the usbhshost node with two sub-nodes
for ohci and ehci. This patch file creates the usbhshost, and
pulls the portX-mode information. It then locates the EHCI
sub-node, and initializes the EHCI controller with the info
pulled from the usbhshost node.
There is still more to do since there isn't an actual link
between the 'phys' reference and the corresponding phy driver,
and there is no nop-xceiv driver yet.
In the meantime, the older style reference to
CONFIG_OMAP_EHCI_PHYx_RESET_GPIO is still needed to pull
the phy out of reset until the phy driver is completed and the
phandle reference is made.
Kurt Miller [Wed, 13 May 2020 19:55:20 +0000 (15:55 -0400)]
rockchip: rk3328: rock64 - fix gen3 SPL hang
Use the same approach as ROC-RK3328-CC which enables SPL GPIO,
pinctl and regulator support. This allows the gen3 board to
boot through SPL and does not break gen2 in the process.
Signed-off-by: Kurt Miller <kurt@intricatesoftware.com> Acked-by: Matwey V. Kornilov <matwey.kornilov@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Urja Rannikko [Wed, 13 May 2020 19:15:23 +0000 (19:15 +0000)]
defconfig: veyron: no need for CONFIG_SPL_PINCTRL_FULL
Veyrons do not need full pinctrl support for SPL.
The full pinctrl support does nothing when enabled with OF_PLATDATA,
thus was already unused.
This frees about 4kB of SPL size.
Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Urja Rannikko [Wed, 13 May 2020 19:15:22 +0000 (19:15 +0000)]
rockchip: spl-boot-order: do not attempt to access fdt if OF_PLATDATA
gd->fdt_blob is null if using OF_PLATDATA in SPL, which causes a hang
after f0921f5098 ("fdt: Sync up to the latest libfdt").
We use the same test that is used in spl_common_init on whether to call
fdtdec_setup to unconditionally avoid linking in the fdt-using code
when not necessary and thus reduce SPL size.
Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Urja Rannikko [Wed, 13 May 2020 19:15:21 +0000 (19:15 +0000)]
rockchip: veyron: move board_early_init_f to _r (after reloc)
Previously veyron_init() was called in board_init() context, which is
called after relocation. Moving it to veyron.c used board_early_init_f
which is called way earlier, and causes veyron_init to hang.
Using board_early_init_r instead fixes this.
Fixes: b678f2790c ("rockchip: rk3288: Move veyron_init() back to veyron.c") Signed-off-by: Urja Rannikko <urjaman@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Jagan Teki [Sat, 9 May 2020 16:56:22 +0000 (22:26 +0530)]
pci: Add Rockchip PCIe PHY controller driver
Yes, it is possible to have a dedicated UCLASS PHY driver
for this Rockchip PCIe PHY but there are some issues on
Generic PHY framework to support the same.
The Generic PHY framework is unable to get the PHY if
the PHY parent is of a different uclass.
Say if we try to get the PCIe PHY then the phy-uclass
will look for PHY in the first instance if it is not
in the root node it will try to probe the parent by
assuming that the actual PHY is inside the parent PHY
of UCLASS_PHY. But, in rk3399 hardware representation
PHY like emmc, usb and pcie are part of syscon which
is completely a different of UCLASS_SYSCON.
Due to this limitation, this patch adds a separate PHY
driver for Rockchip PCIe. This might be removed in future
once Generic PHY supports this limitation.
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com> Tested-by: Suniel Mahesh <sunil@amarulasolutions.com> #roc-rk3399-pc Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Andrius Štikonas [Fri, 24 Apr 2020 21:03:29 +0000 (22:03 +0100)]
rockpro64: Enable HDMI output on rockpro64 board
Reference to commit that adds HDMI to other rk3399 boards:
commit 9778edae5576 ("rockchip: Enable HDMI output on rk3399 board w/ HDMI")
Signed-off-by: Andrius Štikonas <andrius@stikonas.eu> Cc: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Cc: Jagan Teki <jagan@amarulasolutions.com> Cc: Kever Yang <kever.yang@rock-chips.com> Tested-by: Mark Kettenis <kettenis@openbsd.org> Reviewed-by: Jagan Teki <jagan@amarulasolutions.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
thermal: imx_scu_thermal: prevent boot hang with zero pdata
Should initialization of pdata values have failed for some reason,
we end up in endless loop when getting the CPU temperature value
and can not boot. Check alert value in pdata and only retry reading
temperature if alert value is not zero. Also shorten the temperature
info string.
cpu: imx8: use intended cpu-thermal device when getting temp value
This fixes getting DT alert and critical pdata values in imx_scu_thermal
driver. On i.MX8QXP using not initialized alert pdata value resulted in
boot hang and endless loop outputting:
CPU Temperature (47200C) has beyond alert (0C), close to critical (0C) waiting...
While at it, preset CPU type values once to avoid multiple calls
of device_is_compatible() for same property.
Fixes: 3ee6ea443eb4 ("cpu: imx_cpu: Print the CPU temperature for iMX8QM A72") Signed-off-by: Anatolij Gustschin <agust@denx.de> Reviewed-by: Peng Fan <peng.fan@nxp.com>
CPU type and rate detection is broken, for A35 cpu we get A53:
...
sc_pm_get_clock_rate: resource:0 clk:2: res:3
Could not read CPU frequency: -22
CPU: NXP i.MX8QXP RevB A53 at 0 MHz at 47C
Fixes: 55bc96f3b675 ("cpu: imx8: fix get core name and rate") Signed-off-by: Anatolij Gustschin <agust@denx.de> Reviewed-by: Peng Fan <peng.fan@nxp.com>
Deepak Das [Wed, 15 Apr 2020 03:25:24 +0000 (08:55 +0530)]
rockchip: rk3399: enable spl-fifo-mode for sdmmc
adapting commit fa2047c47310 ("rockchip: rk3328: enable spl-fifo-mode
for emmc and sdmmc") for rk3399.
Since mmc to sram can't do dma, add patch to prevent aborts transferring
TF-A parts.
Signed-off-by: Deepak Das <deepakdas.linux@gmail.com>
Masahiro Yamada [Wed, 20 May 2020 03:31:24 +0000 (12:31 +0900)]
ARM: uniphier: remove #include <net.h> again from micro-support-card.c
I do not understand the changes made to this file by
commit 90526e9fbac4 ("common: Drop net.h from common header").
git show 90526e9fbac4 -- arch/arm/mach-uniphier/micro-support-card.c
The necessary declaration is already included by <netdev.h> at line 112.
It also moved the <dm/of.h> inclusion, but I do not understand the
motivation of doing so, either.
If the write protect signal from this IP is connected to the NAND
device, this IP can handle the WP# pin via the WRITE_PROTECT
register.
The Denali NAND Flash Memory Controller User's Guide describes
this register like follows:
When the controller is in reset, the WP# pin is always asserted
to the device. Once the reset is removed, the WP# is de-asserted.
The software will then have to come and program this bit to
assert/de-assert the same.
The default value is 1, so the write protect is de-asserted after
the reset is removed. The driver can write to the device unless
someone has explicitly cleared register before booting the kernel.
The boot ROM of some UniPhier SoCs (LD4, Pro4, sLD8, Pro5) is the
case; the boot ROM clears the WRITE_PROTECT register when the system
is booting from the NAND device, so the NAND device becomes read-only.
Set it to 1 in the driver in order to allow the write access to the
device.
efi_loader: check device path is not installed twice
Prior to corrective patches for virtio and SATA devices the same device
path was installed on two different handles. This is not allowable.
With this patch we will throw an error if this condition occurs for
block devices.
Update a comment for the installation of the simple file system
protocol.
Reported-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
projects / u-boot.git / log
