Re: [U-Boot] [PATCH] lmb: handle more than one DRAM BANK
On 1/26/19 10:27 PM, Heinrich Schuchardt wrote: > On 1/26/19 10:13 PM, Simon Goldschmidt wrote: >> This fixes the automatic lmb initialization and reservation for boards >> with more than one DRAM bank. >> >> This fixes the CVE-2018-18439 and -18440 fixes that only allowed to load >> files into the firs DRAM bank from fs and via tftp. >> >> Found-by: Heinrich Schuchardt >> Signed-off-by: Simon Goldschmidt > > Thanks for the patch. > > With the patch tftp to $loadaddr is possible on vexpress_ca15_tc2. > Loading to an address outside DRAM is forbidden. > > So for vexpress_ca15_tc2 > > Tested-by: Heinrich Schuchardt > I ran this patch through Travis CI together with the efi-next queue and no error occurred. https://travis-ci.org/xypron2/u-boot/builds/484859383 https://github.com/xypron2/u-boot/commits/21ea2188022313cac9db0f27d46a9dbcad0f2c19 Best regards Heinrich ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, 1/2] env: common: Return specific error code on bad CRC
On Fri, Jan 18, 2019 at 09:19:03PM +0200, Sam Protsenko wrote: > Callers of env_import*() functions might want to check the case when we > have incorrect environment (with bad CRC). For example, when environment > location is being defined in env_load(), call chain may look like this: > > env_load() -> drv->load() = env_mmc_load() -> env_import() > > Return code will be passed from env_import() all way up to env_load(). > Right now both env_mmc_load() and env_import() return -EIO error code, > so env_load() can't differentiate between two cases: > 1. Driver reports the error, because device is not accessible > 2. Device is actually accessible, but environment is broken > > Let's return -ENOMSG in env_import(), so we can distinguish two cases > mentioned above. It will make it possible to continue working with "bad > CRC" environment (like doing "env save"), instead of considering it not > functional (implemented in subsequent patch). > > Signed-off-by: Sam Protsenko > Reviewed-by: Simon Goldschmidt Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, 1/2] lib: lmb: rename lmb_get_unreserved_size to lmb_get_free_size
On Mon, Jan 21, 2019 at 08:29:55PM +0100, Simon Goldschmidt wrote: > As a follow-up, change the name of the newly introduced function > 'lmb_get_unreserved_size' to 'lmb_get_free_size', which is more > appropriate. > > Signed-off-by: Simon Goldschmidt Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] ARM: chiliboard: enable DM_SPI
On Fri, Jan 18, 2019 at 05:35:42PM +0100, Marcin Niestroj wrote: > Add DM_SPI to suppress build warning about dm conversion. > > Signed-off-by: Marcin Niestroj Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, 2/2] mmc: mtk-sd: fix SPL compilation when GPIO=y and SPL_GPIO=n
On Thu, Jan 17, 2019 at 06:06:01PM +0100, Fabien Parent wrote:
> It is not possible to link the SPL image when CONFIG_GPIO is enabled
> but CONFIG_SPL_GPIO is not. Use the IS_ENABLED macro instead to
> correctly check whether CONFIG_{SPL_}GPIO is enabled.
>
> This commit fixes the following errors:
> * undefined reference to `dm_gpio_get_value
> * undefined reference to `gpio_request_by_name'
>
> Signed-off-by: Fabien Parent
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot,1/1] hashtable: remove caps buffer
On Wed, Jan 23, 2019 at 08:17:02AM +0100, Heinrich Schuchardt wrote: > slre_match() checks if caps == NULL. In this case it does not try to > update it. So there is no need to create a buffer caps which we do not > evaluate. > > Signed-off-by: Heinrich Schuchardt Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Makefile: have "make distclean" remove CHANGELOG
On Fri, Jan 18, 2019 at 08:41:23AM -0500, Robert P. J. Day wrote: > Ensure that "make distclean" deletes an existing CHANGELOG file. > > Signed-off-by: Robert P. J. Day > > diff --git a/Makefile b/Makefile > index 3be9fc5c34..b9e8b0952c 100644 Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v3, 1/7] spl: Kconfig: Drop the _SUPPORT postfix from SPL_DFU
On Thu, Jan 17, 2019 at 01:43:02PM -0600, Andrew F. Davis wrote: > The symbol CONFIG_SPL_DFU_SUPPORT in SPL build has the same > meaning as CONFIG_DFU in regular U-Boot. Drop the _SUPPORT > to allow for cleaner use in code. > > Signed-off-by: Andrew F. Davis > Reviewed-by: Tom Rini > Acked-by: Lukasz Majewski Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, 1/2] mmc: mtk-sd: fix possible incomplete read ops
On Thu, Jan 17, 2019 at 06:06:00PM +0100, Fabien Parent wrote: > The code is checking for incomplete read when it see the INT_XFER_COMPL > flag, but it forget to first check whether there is anything left in the > FIFO to copy to the RX buffer. This means that sometimes we will get > errors because of erroneous incomplete read operation. > > This commit fixes the driver re-ordering the code so that we first > check for data inside the RX fifo and only after check the status > of the INT_XFER_COMPL flag. > > Signed-off-by: Fabien Parent Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v1, 4/5] arm: mach-snapdragon: pinctrl: clarify gpio disable bit
On Sat, Jan 12, 2019 at 11:47:27AM +0200, Ramon Fried wrote: > The TLMM_GPIO_ENABLE bit is actually use to disable > the GPIO. change it to TLMM_GPIO_DISABLE so it's clearer. > > Signed-off-by: Ramon Fried Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v3, 2/7] dfu: Make DFU support more SPL friendly
On Thu, Jan 17, 2019 at 01:43:03PM -0600, Andrew F. Davis wrote: > Do this by using $(SPL_) in Makefiles and CONFIG_IS_ENABLED in C code. > This ensures the files and features are only built into the right build > for which they are enabled. Using the macros to simplify this patch was > made possible by the config symbol rename done in the last patch. > > Signed-off-by: Andrew F. Davis > Reviewed-by: Tom Rini > Acked-by: Lukasz Majewski Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, 2/2] lib: lmb: cleanup var names and patman warnings
On Mon, Jan 21, 2019 at 08:29:56PM +0100, Simon Goldschmidt wrote: > Change multiple usages of 'j' into 'rgn'; fix whitespace/coding style > reported by patman. > > Signed-off-by: Simon Goldschmidt Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, 2/2] env: Fix saving environment to "bad CRC" location
On Fri, Jan 18, 2019 at 09:19:04PM +0200, Sam Protsenko wrote:
> In case when the environment on some location is malformed (CRC isn't
> matching), there is a chance we won't be able to save the environment to
> that location. For example, consider the case when we only have the
> environment on eMMC, but it's zeroed out. In that case, we won't be able
> to "env save" to it, because of "bad CRC" error. That's happening
> because in env_load() function we consider malformed environment as
> incorrect one, and defaulting to the location with highest (0)
> priority, which can be different from one we are dealing with right now
> (e.g., highest priority can be ENV_FAT on SD card, which is not
> inserted, but we want to use ENV_MMC on eMMC, where we were booted
> from).
>
> This issue began to reproduce after commit d30ba2315ae3 ("u-boot: remove
> driver lookup loop from env_save()") on BeagleBone Black, but that
> commit didn't introduce the wrong logic, it just changed the behavior
> for default location to use, merely revealing this issue.
>
> To fix that, let's implement next logic in env_load():
> 1. Try to find out correct environment; if found -- use it
> 2. If working environment wasn't found, but we found malformed one
> (with bad CRC), let's use it for further "env save". But make sure
> to use malformed environment location with highest priority.
> 3. If neither correct nor malformed environment was found, let's
> default to environment location with highest priority (0)
>
> Steps to reproduce mentioned issue on BeagleBone Black (fixed in this
> patch):
>
> 1. Boot from SD card and erase eMMC in U-Boot shell:
>=> mmc dev 1
>=> mmc erase 0 10
>=> gpt write mmc 1 $partitions
> 2. Write new SPL and U-Boot to eMMC; the rest of eMMC will stay filled
>with zeroes
> 3. Boot from eMMC; try to do:
>=> env save
> 4. Observe the error (incorrect behavior). Correct behavior: environment
>should be stored correctly on eMMC, in spite of it has "bad CRC"
>
> Fixes: d30ba2315ae3 ("u-boot: remove driver lookup loop from env_save()")
> Signed-off-by: Sam Protsenko
> Reviewed-by: Simon Goldschmidt
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot,v1,1/1] arm64: dt: poplar: add optee node
On Thu, Jan 17, 2019 at 04:37:40PM +0200, Igor Opaniuk wrote: > As Poplar supports running TF-A with OP-TEE as BL32 > payload, add op-tee node in DT, which enables usage of > OP-TEE driver (which provides an interface for requesting services > from OP-TEE). > > Signed-off-by: Igor Opaniuk > Reviewed-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] bcm968380gerg: disable SPI_FLASH
On Mon, Jan 21, 2019 at 06:52:05PM +0100, Philippe Reynes wrote: > The board bcm968380gerg don't have a spi flash so > we disable the spi flash support. > > Signed-off-by: Philippe Reynes Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] tests: dtoc: adapt tests to changed dtoc output
On Mon, Jan 21, 2019 at 10:07:55AM +0100, Simon Goldschmidt wrote:
> The dtoc tests need to be adapted to dtoc being changed to output platdata
> structs as const, which has been introduced in commit 7d05d3a8e35f ("dtoc:
> make generated platdata structs const").
>
> Fixes: 7d05d3a8e35f ("dtoc: make generated platdata structs const")
> Signed-off-by: Simon Goldschmidt
> Reviewed-by: Simon Glass
> Tested-by: Simon Glass
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, RESEND] drivers: esdhc: add support for ColdFire mcf5441x family
On Sat, Jan 19, 2019 at 10:40:38AM +0100, Angelo Dureghello wrote: > This patch has been tested on the mcf54415-based stmark2 > board. The eSDHC driver works reliably using DMA mode. > > Signed-off-by: Angelo Dureghello Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, 1/3] poplar: sync up device tree with kernel 4.20
On Thu, Jan 17, 2019 at 12:09:50PM +0800, Shawn Guo wrote: > It adds missing pinctrl headers, updates clock header and sync up Poplar > device tree with kernel 4.20 release. > > Signed-off-by: Shawn Guo Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] atmel: add CMD_FS_GENERIC to SAMA5D3 for EFI boot
On Sun, Jan 20, 2019 at 11:51:26PM -0500, Greg Czerniak wrote: > I'm working on getting OpenBSD to run on the Atmel SAMA5D3 Xplained. > OpenBSD uses an EFI bootloader, which requires the "load" command to > work, since "fatload" doesn't initialize the EFI memory addresses > properly. To get "load" on the SAMA5D3 version of U-Boot, I propose > adding the CONFIG_CMD_FS_GENERIC option. > > Signed-off-by: Greg Czerniak Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v3, 3/7] dfu: Remove dependency on HUSH parser in SPL
On Thu, Jan 17, 2019 at 01:43:04PM -0600, Andrew F. Davis wrote: > CLI support with the HUSH parser is not currently SPL safe due to it's > use of realloc. That function is not defined for SPLs that use > SYS_MALLOC_SIMPLE. CLI support can be built in to SPL and some functions > do work, but use of some like run_command() will cause build to fail. > When no SPL code calls this function build works as the compiler removes > this unreachable code so the unresolved symbols are ignored. > > If DFU support is enabled in SPL then MMU DFU support may get brought in > also, this code does make a call to run_command() causing build to fail > if the HUSH parser is not built-in. To break this odd and unneeded > dependency chain we use CONFIG_IS_ENABLED where appropriate to prevent > calls into HUSH code from SPL. This also removes our need to pull in the > rather unrelated source file when SPL_DFU is defined. > > Signed-off-by: Andrew F. Davis > Reviewed-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v1, 2/5] arm: mach-snapdragon: add pinctrl driver for db820c
On Sat, Jan 12, 2019 at 11:47:25AM +0200, Ramon Fried wrote: > Add pinctrl driver for Dragonboard820c, currently with only > one mux func to initialize pins for serial console. > > Signed-off-by: Ramon Fried Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] MAINTAINERS: update stm32mp1 path for arch
On Mon, Jan 21, 2019 at 05:20:00PM +0100, Patrick Delaunay wrote: > Handle correctly directory arch/arm/mach-stm32mp/ : > Add a trailing slash to include all files > and subdirectory files. > > Signed-off-by: Patrick Delaunay Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] misc: i2c_eeprom: Add atmel,24c08 to the list
On Mon, Jan 21, 2019 at 01:54:57PM +0100, Michal Simek wrote: > Linux kernel binding is using atmel,24c08 compatible string. On the > other hand there is atmel,24c08a which is not listed in the kernel. > Add compatible string without "a" suffix to be compatible with Linux > kernel binding. > > These eeproms are available on several ZynqMP development boards. > > Signed-off-by: Michal Simek Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v1, 3/5] configs: dragonboard820c: Enable pinctrl/mux config
On Sat, Jan 12, 2019 at 11:47:26AM +0200, Ramon Fried wrote: > Signed-off-by: Ramon Fried Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v3, 4/7] ARM: mach-omap2: Kconfig: Allow OMAP5 devices to set entry point
On Thu, Jan 17, 2019 at 01:43:05PM -0600, Andrew F. Davis wrote: > Like AM33xx and AM43xx, DRA7xx and AM57xx devices may need to > have an non-standard boot address in memory. This may be due > to the device being a high security variant, which place the > Initial SoftWare (ISW) after certificates and secure software. > > Allow these devices to set this from Kconfig. > > Signed-off-by: Andrew F. Davis Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, 2/3] mmc: hi6220_dw_mmc: add compatible for Poplar support
On Thu, Jan 17, 2019 at 12:09:51PM +0800, Shawn Guo wrote: > It adds compatible "hisilicon,hi3798cv200-dw-mshc" for Poplar SoC > Hi3798CV200 to probe this mmc driver. > > Signed-off-by: Shawn Guo > Acked-by: Manivannan Sadhasivam Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, PATCHv1] arm: stm32mp1: deploy spl in root folder
On Fri, Jan 04, 2019 at 11:37:24AM +, Sean Nyekjær wrote: > Deploy u-boot-spl.stm32 binary in u-boot root folder like > the rest of the boards. > This makes it more streamlined when building in Yocto, Buildroot etc.. > > Signed-off-by: Sean Nyekjaer > Signed-off-by: Sean Nyekjaer Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, 3/3] poplar: clean up board level mmc initialization code
On Thu, Jan 17, 2019 at 12:09:52PM +0800, Shawn Guo wrote: > We have converted mmc to driver model on Poplar. So let's clean up > board level mmc initialization code. > > Signed-off-by: Shawn Guo > Acked-by: Manivannan Sadhasivam Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v1, 5/5] dts: 820c: Add pinctrl node and uart mux
On Sat, Jan 12, 2019 at 11:47:28AM +0200, Ramon Fried wrote: > * Add pinctrl node for TLMM and add mux request for uart node. > * Rename uart to the actual board uart port. > * Fix indentendation of sdhc2 node. > > Signed-off-by: Ramon Fried Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] cmd: ximg: Invert check for fit image compression
On Mon, Jan 07, 2019 at 10:25:52AM +0100, Stefan Theil wrote: > The imgextract command runs a number of checks of > the specified fit. Where it checks for a load address > for compressed images the logic in the expression > is inverted as fit_image_check_comp returns 1 on > success and not 0. Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Makefile: Only build dtc if needed
On Tue, Nov 13, 2018 at 03:43:07PM -0700, Simon Glass wrote: > At present U-Boot always builds dtc if CONFIG_OF_CONTROL is defined. This > is wasteful when the system already has a suitable version available. > > Update the Makefile logic to build dtc only if the version available is > too old. > > This saves about 3 seconds of CPU time on a clean build for me. > > Signed-off-by: Simon Glass > Reviewed-by: Marek Vasut In the case of new enough host dtc this then fails on sandbox_spl, chromebook_minnie and others where we need to build spl/dts/dt-platdata.c with a python import error over lacking _libfdt. -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v1, 1/5] arm: mach-snapdragon: db820c: Actually init PLL for serial
On Sat, Jan 12, 2019 at 11:47:24AM +0200, Ramon Fried wrote: > The PLL for the UART was not set, and relied on previous > initializtion made by LK. add the appropriate initialization. > > Signed-off-by: Ramon Fried Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v3, 5/7] defconfigs: Add config for DRA7xx High Security EVM with USB Boot support
On Thu, Jan 17, 2019 at 01:43:06PM -0600, Andrew F. Davis wrote: > Add a new defconfig file for the DRA7xx High Security EVM. This config > is specific for the case of USB booting. > > Signed-off-by: Andrew F. Davis > Reviewed-by: Tom Rini OK, this an the am57xx_hs_evm_usb config no longer build on top of tree. Can you please rebase the last 3 parts of this series? Thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Please pull ARC changes
On Fri, Jan 25, 2019 at 05:52:31AM +, Alexey Brodkin wrote: > Hi Tom, > > The following changes since commit ce0d1e48165fdd3bde4bb431f1d2e100b1617a6e: > > Merge tag 'xilinx-for-v2019.04' of git://git.denx.de/u-boot-microblaze > (2019-01-24 10:47:05 -0500) > > are available in the Git repository at: > > git://git.denx.de/u-boot-arc.git tags/arc-fixes-for-2019.04-rc1 > > for you to fetch changes up to fae3798ac9f6de5a4cb1aa1e849d419a2bb8dbbe: > > ARC: cache: define CONFIG_SYS_CACHELINE_SIZE as ARCH_DMA_MINALIGN > (2019-01-25 08:41:09 +0300) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [Bug?] raspberrypi: UART issue in combination with pi3-disable-bt device-tree overlay
Hello, I ran into an issue with the UART interface and U-Boot on a Raspberry Pi 3 (rpi_3_32b_defconfig). In my config.txt I have added the following lines: dtparam=spi=on enable_uart=1 core_freq=250 dtoverlay=pi3-disable-bt This works fine when directly booting the Linux kernel, however when using U-Boot as an intermediate step, I’m running into issues when accessing the UART interface. As I’m using the Yocto meta-raspberrypi layer, Initially I opened a GitHub issue: https://github.com/agherzan/meta-raspberrypi/issues/374 I was pointed to the following lines that are used in the U-Boot device-tree for the Raspberry Pi 3: https://github.com/u-boot/u-boot/blob/master/arch/arm/dts/bcm2837-rpi-3-b.dts#L22-L34. Possibly these would conflict with the “pi3-disable-bt” overlay. After removing these lines, and making sure that the GPS module connected to the UART interface would not interrupt the boot process, all works fine. See also: https://github.com/agherzan/meta-raspberrypi/issues/374#issuecomment-457524421 Is this a bug and should this be fixed in the U-Boot repository, or is this expected behaviour and Is patching the bcm2837-rpi-3-b.dts device-tree when using the pi3-disable-bt device-tree overlay the way to go? Thanks! Cheers, Orne ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] test/py: use default load address for tftp
On 1/26/19 9:33 PM, Stephen Warren wrote:
> On 1/26/19 7:25 AM, Heinrich Schuchardt wrote:
>> On x86_64 the size of the file u-boot loaded by the tftp test has grown in
>> size such that when loading the file to 0x20 it overwrites a memory
>> area reserved for PCI.
>>
>> If no load address is specified for tftp do not use the ram base address
>> (or if zero 0x20) but the default address.
>
> I assume that default is $loadaddr? If so, then this patch seems fine.
>
Thanks for reviewing.
Yes, the address `tftp filename` uses is environment variable loadaddr.
This is specified in cmd/net.c, function netboot_common():
188 /* pre-set load_addr */
189 s = env_get("loadaddr");
Best regards
Heinrich Schuchardt
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] lmb: handle more than one DRAM BANK
On 1/26/19 10:13 PM, Simon Goldschmidt wrote: > This fixes the automatic lmb initialization and reservation for boards > with more than one DRAM bank. > > This fixes the CVE-2018-18439 and -18440 fixes that only allowed to load > files into the firs DRAM bank from fs and via tftp. > > Found-by: Heinrich Schuchardt > Signed-off-by: Simon Goldschmidt Thanks for the patch. With the patch tftp to $loadaddr is possible on vexpress_ca15_tc2. Loading to an address outside DRAM is forbidden. So for vexpress_ca15_tc2 Tested-by: Heinrich Schuchardt ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v10, 09/10] tftp: prevent overwriting reserved memory
Am 26.01.2019 um 10:56 schrieb Heinrich Schuchardt:
On 1/26/19 9:46 AM, Simon Goldschmidt wrote:
Am 26.01.2019 um 04:20 schrieb Heinrich Schuchardt:
TheOn 1/14/19 10:38 PM, Simon Goldschmidt wrote:
This fixes CVE-2018-18439 ("insufficient boundary checks in network
image boot") by using lmb to check for a valid range to store
received blocks.
Signed-off-by: Simon Goldschmidt
Acked-by: Joe Hershberger
---
Hello Simon,
due to this patch merged as a156c47e39ad7d00 on
vexpress_ca15_tc2_defconfig the command 'dhcp filename' always fails. It
was working in v2019.01
Same is true for other platforms, e.g. vexpress_ca9x4_defconfig.
OK, that's probably not expected ;-)
I'd appreciate it if you could continue to track this down to get it fixed.
Let's see how far I get.
You can easily test yourself with QEMU. I was using:
QEMU_AUDIO_DRV=none qemu-system-arm \
-M vexpress-a15 -cpu cortex-a15 -kernel u-boot \
-netdev \
user,id=net0,tftp=tftp,net=192.168.76.0/24,dhcpstart=192.168.76.9 \
-net nic,model=lan9118,netdev=net0 \
-m 1024M --nographic \
-drive if=sd,file=img.vexpress,media=disk,format=raw
Yes, this worked quite well (after creating the 'img.vexpress' file,
that is), and 'dhcp somefile' now works for me in that configuration.
Thanks for the hint.
I put in an extra printf() and got:
TFTP error: trying to overwrite reserved memory...
storeaddr 0, tftp_load_addr 0, tftp_load_size 0
I don't know the first. The latter 2 are not initialized yet in this
error path and so are expected to be zero here.
Could you run that test again if I sent you a patch enabling required
output for me to debug this?
Sure.
It is not even possible to disable the checks by undefining CONFIG_LMB
because a compile error arises without CONFIG_LMB:
cmd/bootz.c:48:21: error: ‘bootm_headers_t’ {aka ‘struct bootm_headers’}
has no member named ‘lmb’
I think the code should compile if CONFIG_LMB is undefined.
You're right, it should compile without CONFIG_LMB. It did initially, so
I guess that got lost somewhere during all the versions until v10,
sorry. I'll work on that.
Further for all boards 'dhcp filename' should be working after your
patch series if it was working before the patch series.
Well, I wouldn't say it like that. This new code is required from a
security point of view. There might be boards violating these
requirements, I can't tell. But it's true that until your ${loadaddr} is
not completely bogus, 'dhcp filename' should continue to work, yes. If
not, let's work on this.
I think we are on the same line.
Why is CONFIG_LMB hard coded? Shouldn't we try to avoid any new hard
coded CONFIG symbols? Consider moving it to Kconfig.
Ehrm, sorry, I can't follow you. Which new config symbols are you
talking about? CONFIG_LMB in ARM's config.h is more than 8 years old!
Sorry, I did not check this. So you didn't put in a new switch.
The logic you use in tftp_init_load_addr() is problematic:
Essentially it allows loading via tftp only in a single region within
the first DRAM bank. Why shouldn't I load to the second DRAM bank?
Even in a single DRAM bank we will have several reserved regions and in
between them several allowable regions for loading.
What leads you to think it's only a single region? Multiple reserved
regions should work and the 'holes' in between should be valid tftp
targets. This is tested in the unit tests.
I did not see that load_addr is a global set in cmd/net.c based on the
parameter passed to the tftp command.
You're right that currently only the first DRAM bank works. Let me work
on that...
The LMB tests do not even find all reserved regions. E.g. on x86_64 it
allows loading to 0x100 though this address is used as a reserved
region for PCI, loading to which leads to a crash.
LMB is a long established concept for U-Boot loading boot files. I added
using it to the 'load' and 'tftp' commands. If x86_64 fails to reserve
memory for LMB, I think x86_64 should be fixed to do so (e.g. via
'arch_lmb_reserve').
@Tom
This LMB patch series stops us from straightening out the Python tests
for tftp to make efi-next build without Travis CI error. Please, advise
how to proceed.
My idea of how to proceed would be: let's just sort out these issues as
fast as possible. I'll send you a patch to debug why tftp thinks it
would overwrite reserved memory. Also, I'll fix the compile error with
CONFIG_LMB disabled and I'll try to add DRAM banks other than the first.
So I just sent a patch that should fix the "multiple DRAM banks" issue.
I gave up compiling without CONFIG_LMB for now, I guess we need a more
global decision on if we want that or not, since those compiler errors
seem to be a reuslt of changes much more in the past than I thought...
I hope this new patch fixes things for you. Thanks for working on this
with me!
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo
Re: [U-Boot] [U-Boot, v10, 09/10] tftp: prevent overwriting reserved memory
Am 26.01.2019 um 14:17 schrieb Tom Rini:
On Sat, Jan 26, 2019 at 09:46:35AM +0100, Simon Goldschmidt wrote:
Am 26.01.2019 um 04:20 schrieb Heinrich Schuchardt:
TheOn 1/14/19 10:38 PM, Simon Goldschmidt wrote:
This fixes CVE-2018-18439 ("insufficient boundary checks in network
image boot") by using lmb to check for a valid range to store
received blocks.
Signed-off-by: Simon Goldschmidt
Acked-by: Joe Hershberger
---
Hello Simon,
due to this patch merged as a156c47e39ad7d00 on
vexpress_ca15_tc2_defconfig the command 'dhcp filename' always fails. It
was working in v2019.01
Same is true for other platforms, e.g. vexpress_ca9x4_defconfig.
OK, that's probably not expected ;-)
I'd appreciate it if you could continue to track this down to get it fixed.
I put in an extra printf() and got:
TFTP error: trying to overwrite reserved memory...
storeaddr 0, tftp_load_addr 0, tftp_load_size 0
I don't know the first. The latter 2 are not initialized yet in this error
path and so are expected to be zero here.
Could you run that test again if I sent you a patch enabling required output
for me to debug this?
It is not even possible to disable the checks by undefining CONFIG_LMB
because a compile error arises without CONFIG_LMB:
cmd/bootz.c:48:21: error: ‘bootm_headers_t’ {aka ‘struct bootm_headers’}
has no member named ‘lmb’
I think the code should compile if CONFIG_LMB is undefined.
You're right, it should compile without CONFIG_LMB. It did initially, so I
guess that got lost somewhere during all the versions until v10, sorry. I'll
work on that.
That might be on me. There were a few cases in the networking code
where the patch broke building the existing world.
Trying again to compile with CONFIG_LMB disabled, it didn't work at all.
It failed in places none of us touched for about 8 years, so I don't
think it was you.
OTOH, I don't know what I had been testing to think it works with
CONFIG_LMB disabled. I had to disable quite a few commands and features
to keep it compiling.
In the end, I think we'll have to decide if we want to make it work with
CONFIG_LMB disabled or if we make this mandatory.
What I did see is that some of the architectures don't overwrite
'arch_lmb_reserve' and are thus probably still affected by these CVEs...
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] lmb: handle more than one DRAM BANK
This fixes the automatic lmb initialization and reservation for boards
with more than one DRAM bank.
This fixes the CVE-2018-18439 and -18440 fixes that only allowed to load
files into the firs DRAM bank from fs and via tftp.
Found-by: Heinrich Schuchardt
Signed-off-by: Simon Goldschmidt
---
common/bootm.c | 4 ++--
fs/fs.c| 3 +--
include/lmb.h | 7 +--
lib/lmb.c | 37 -
net/tftp.c | 3 +--
5 files changed, 41 insertions(+), 13 deletions(-)
diff --git a/common/bootm.c b/common/bootm.c
index a4618b6d2e..7c7505f092 100644
--- a/common/bootm.c
+++ b/common/bootm.c
@@ -59,8 +59,8 @@ static void boot_start_lmb(bootm_headers_t *images)
mem_start = env_get_bootm_low();
mem_size = env_get_bootm_size();
- lmb_init_and_reserve(&images->lmb, (phys_addr_t)mem_start, mem_size,
-NULL);
+ lmb_init_and_reserve_range(&images->lmb, (phys_addr_t)mem_start,
+ mem_size, NULL);
}
#else
#define lmb_reserve(lmb, base, size)
diff --git a/fs/fs.c b/fs/fs.c
index 7fd22101ef..9a411c04e2 100644
--- a/fs/fs.c
+++ b/fs/fs.c
@@ -453,8 +453,7 @@ static int fs_read_lmb_check(const char *filename, ulong
addr, loff_t offset,
if (len && len < read_len)
read_len = len;
- lmb_init_and_reserve(&lmb, gd->bd->bi_dram[0].start,
-gd->bd->bi_dram[0].size, (void *)gd->fdt_blob);
+ lmb_init_and_reserve(&lmb, gd->bd, (void *)gd->fdt_blob);
lmb_dump_all(&lmb);
if (lmb_alloc_addr(&lmb, addr, read_len) == addr)
diff --git a/include/lmb.h b/include/lmb.h
index 1bb003e35e..ca235d7d9d 100644
--- a/include/lmb.h
+++ b/include/lmb.h
@@ -4,6 +4,8 @@
#ifdef __KERNEL__
#include
+#include
+
/*
* Logical memory blocks.
*
@@ -29,8 +31,9 @@ struct lmb {
};
extern void lmb_init(struct lmb *lmb);
-extern void lmb_init_and_reserve(struct lmb *lmb, phys_addr_t base,
-phys_size_t size, void *fdt_blob);
+extern void lmb_init_and_reserve(struct lmb *lmb, bd_t *bd, void *fdt_blob);
+extern void lmb_init_and_reserve_range(struct lmb *lmb, phys_addr_t base,
+ phys_size_t size, void *fdt_blob);
extern long lmb_add(struct lmb *lmb, phys_addr_t base, phys_size_t size);
extern long lmb_reserve(struct lmb *lmb, phys_addr_t base, phys_size_t size);
extern phys_addr_t lmb_alloc(struct lmb *lmb, phys_size_t size, ulong align);
diff --git a/lib/lmb.c b/lib/lmb.c
index 3407705fa7..b210c2adaa 100644
--- a/lib/lmb.c
+++ b/lib/lmb.c
@@ -98,12 +98,8 @@ void lmb_init(struct lmb *lmb)
lmb->reserved.size = 0;
}
-/* Initialize the struct, add memory and call arch/board reserve functions */
-void lmb_init_and_reserve(struct lmb *lmb, phys_addr_t base, phys_size_t size,
- void *fdt_blob)
+static void lmb_reserve_common(struct lmb *lmb, void *fdt_blob)
{
- lmb_init(lmb);
- lmb_add(lmb, base, size);
arch_lmb_reserve(lmb);
board_lmb_reserve(lmb);
@@ -111,6 +107,37 @@ void lmb_init_and_reserve(struct lmb *lmb, phys_addr_t
base, phys_size_t size,
boot_fdt_add_mem_rsv_regions(lmb, fdt_blob);
}
+/* Initialize the struct, add memory and call arch/board reserve functions */
+void lmb_init_and_reserve(struct lmb *lmb, bd_t *bd, void *fdt_blob)
+{
+#ifdef CONFIG_NR_DRAM_BANKS
+ int i;
+#endif
+
+ lmb_init(lmb);
+#ifdef CONFIG_NR_DRAM_BANKS
+ for (i = 0; i < CONFIG_NR_DRAM_BANKS; i++) {
+ if (bd->bi_dram[i].size) {
+ lmb_add(lmb, bd->bi_dram[i].start,
+ bd->bi_dram[i].size);
+ }
+ }
+#else
+ if (bd->bi_memsize)
+ lmb_add(lmb, bd->bi_memstart, bd->bi_memsize);
+#endif
+ lmb_reserve_common(lmb, fdt_blob);
+}
+
+/* Initialize the struct, add memory and call arch/board reserve functions */
+void lmb_init_and_reserve_range(struct lmb *lmb, phys_addr_t base,
+ phys_size_t size, void *fdt_blob)
+{
+ lmb_init(lmb);
+ lmb_add(lmb, base, size);
+ lmb_reserve_common(lmb, fdt_blob);
+}
+
/* This routine called with relocation disabled. */
static long lmb_add_region(struct lmb_region *rgn, phys_addr_t base,
phys_size_t size)
{
diff --git a/net/tftp.c b/net/tftp.c
index 8fab6d2650..75f3a7c141 100644
--- a/net/tftp.c
+++ b/net/tftp.c
@@ -606,8 +606,7 @@ static int tftp_init_load_addr(void)
struct lmb lmb;
phys_size_t max_size;
- lmb_init_and_reserve(&lmb, gd->bd->bi_dram[0].start,
-gd->bd->bi_dram[0].size, (void *)gd->fdt_blob);
+ lmb_init_and_reserve(&lmb, gd->bd, (void *)gd->fdt_blob);
max_size = lmb_get_unreserved_size(&lmb, load_addr);
if (!max_size)
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
htt
Re: [U-Boot] [PATCH 1/1] test/py: use default load address for tftp
On 1/26/19 7:25 AM, Heinrich Schuchardt wrote: > On x86_64 the size of the file u-boot loaded by the tftp test has grown in > size such that when loading the file to 0x20 it overwrites a memory > area reserved for PCI. > > If no load address is specified for tftp do not use the ram base address > (or if zero 0x20) but the default address. I assume that default is $loadaddr? If so, then this patch seems fine. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, RESEND, v3, 1/1] avb: add support for named persistent values
Hi Tom, Thanks for notifying, I totally forgot about sandbox tee driver emulation (I've run these tests only on real hardware :( ). Will fix and send v4 ASAP. Regards, Igor On Sat, 26 Jan 2019 at 15:14, Tom Rini wrote: > > On Thu, Jan 17, 2019 at 02:17:00PM +0200, Igor Opaniuk wrote: > > > AVB version 1.1 introduces support for named persistent values > > that must be tamper evident and allows AVB to store arbitrary key-value > > pairs [1]. > > > > Introduce implementation of two additional AVB operations > > read_persistent_value()/write_persistent_value() for retrieving/storing > > named persistent values. > > > > Correspondent pull request in the OP-TEE OS project repo [2]. > > > > [1]: > > https://android.googlesource.com/platform/external/avb/+/android-9.0.0_r22 > > [2]: https://github.com/OP-TEE/optee_os/pull/2699 > > > > Signed-off-by: Igor Opaniuk > > --- > > > > Changes in v3: > > - fix possible mem lick in avb_read_persistent/avb_write_persistent > > - added additional sanity checks > > - covered avb read_pvalue/write_pvalue commands with python tests > > > > Changes in v2: > > - fix output format for avb read_pvalue/write_pvalue commands > > - fix issue with named value buffer size > > > > cmd/avb.c | 78 > > common/avb_verify.c| 125 > > + > > include/tee.h | 2 + > > include/tee/optee_ta_avb.h | 16 ++ > > test/py/tests/test_avb.py | 16 ++ > > 5 files changed, 237 insertions(+) > > Thanks for adding a test here. It seems to fail however: > https://travis-ci.org/trini/u-boot/jobs/484486111 > https://travis-ci.org/trini/u-boot/jobs/484486112 > https://travis-ci.org/trini/u-boot/jobs/484486114 > > -- > Tom -- Regards, Igor Opaniuk ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] test/py: use default load address for tftp
On 1/26/19 4:58 PM, Tom Rini wrote:
> On Sat, Jan 26, 2019 at 03:25:12PM +0100, Heinrich Schuchardt wrote:
>> On x86_64 the size of the file u-boot loaded by the tftp test has grown in
>> size such that when loading the file to 0x20 it overwrites a memory
>> area reserved for PCI.
>>
>> If no load address is specified for tftp do not use the ram base address
>> (or if zero 0x20) but the default adI dress.
>>
>> Signed-off-by: Heinrich Schuchardt
>> ---
>> Currently there is a bug in net/tftp.c introduced by commit a156c47e39ad
>> ("tftp: prevent overwriting reserved memory") which does not allow loading
>> to the second DRAM bank. Simon Goldschmidt is working to fix it.
>
> Yes, a real bug and good job sorting it out.
>
>> Due to this bug with the proposed patch we see a Travis CI error for
>> vexpress_ca15_tc2_defconfig and vexpress_ca9x4_defconfig.
>
> It's breaking with whatever additional changes you're testing. Please
> just put this change in your WIP branch until Simon has fixed the
> problem you've found. Alternatively, fork uboot-test-hooks and make
> your WIP trees use that fork which specifies a different address to use
> for tftp? Or am I missing something else? Thanks!
>
I can well understand that you do not want to see this this patch merged
before Simon Goldschimidt's patch.
Maybe I should have also added a reference to this patch:
x86: #define CONFIG_LOADADDR 0x110
https://lists.denx.de/pipermail/u-boot/2019-January/356108.html
All three corrections are needed to let the efi-next patch queue
(https://github.com/agraf/u-boot/commits/efi-next) pass Travis CI testing.
Best regards
Heinrich
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] test/py: use default load address for tftp
On Sat, Jan 26, 2019 at 03:25:12PM +0100, Heinrich Schuchardt wrote:
> On x86_64 the size of the file u-boot loaded by the tftp test has grown in
> size such that when loading the file to 0x20 it overwrites a memory
> area reserved for PCI.
>
> If no load address is specified for tftp do not use the ram base address
> (or if zero 0x20) but the default address.
>
> Signed-off-by: Heinrich Schuchardt
> ---
> Currently there is a bug in net/tftp.c introduced by commit a156c47e39ad
> ("tftp: prevent overwriting reserved memory") which does not allow loading
> to the second DRAM bank. Simon Goldschmidt is working to fix it.
Yes, a real bug and good job sorting it out.
> Due to this bug with the proposed patch we see a Travis CI error for
> vexpress_ca15_tc2_defconfig and vexpress_ca9x4_defconfig.
It's breaking with whatever additional changes you're testing. Please
just put this change in your WIP branch until Simon has fixed the
problem you've found. Alternatively, fork uboot-test-hooks and make
your WIP trees use that fork which specifies a different address to use
for tftp? Or am I missing something else? Thanks!
--
Tom
signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/1] test/py: use default load address for tftp
On x86_64 the size of the file u-boot loaded by the tftp test has grown in
size such that when loading the file to 0x20 it overwrites a memory
area reserved for PCI.
If no load address is specified for tftp do not use the ram base address
(or if zero 0x20) but the default address.
Signed-off-by: Heinrich Schuchardt
---
Currently there is a bug in net/tftp.c introduced by commit a156c47e39ad
("tftp: prevent overwriting reserved memory") which does not allow loading
to the second DRAM bank. Simon Goldschmidt is working to fix it.
Due to this bug with the proposed patch we see a Travis CI error for
vexpress_ca15_tc2_defconfig and vexpress_ca9x4_defconfig.
---
test/py/tests/test_net.py | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/test/py/tests/test_net.py b/test/py/tests/test_net.py
index 9c395e69fa..9ca6743afd 100644
--- a/test/py/tests/test_net.py
+++ b/test/py/tests/test_net.py
@@ -145,11 +145,12 @@ def test_net_tftpboot(u_boot_console):
pytest.skip('No TFTP readable file to read')
addr = f.get('addr', None)
-if not addr:
-addr = u_boot_utils.find_ram_base(u_boot_console)
fn = f['fn']
-output = u_boot_console.run_command('tftpboot %x %s' % (addr, fn))
+if not addr:
+output = u_boot_console.run_command('tftpboot %s' % (fn))
+else:
+output = u_boot_console.run_command('tftpboot %x %s' % (addr, fn))
expected_text = 'Bytes transferred = '
sz = f.get('size', None)
if sz:
@@ -163,7 +164,7 @@ def test_net_tftpboot(u_boot_console):
if u_boot_console.config.buildconfig.get('config_cmd_crc32', 'n') != 'y':
return
-output = u_boot_console.run_command('crc32 %x $filesize' % addr)
+output = u_boot_console.run_command('crc32 $fileaddr $filesize')
assert expected_crc in output
@pytest.mark.buildconfigspec('cmd_nfs')
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v10, 09/10] tftp: prevent overwriting reserved memory
On 1/26/19 10:56 AM, Heinrich Schuchardt wrote:
> On 1/26/19 9:46 AM, Simon Goldschmidt wrote:
>> Am 26.01.2019 um 04:20 schrieb Heinrich Schuchardt:
>>> TheOn 1/14/19 10:38 PM, Simon Goldschmidt wrote:
This fixes CVE-2018-18439 ("insufficient boundary checks in network
image boot") by using lmb to check for a valid range to store
received blocks.
Signed-off-by: Simon Goldschmidt
Acked-by: Joe Hershberger
---
>>>
>>> Hello Simon,
>>>
>>> due to this patch merged as a156c47e39ad7d00 on
>>> vexpress_ca15_tc2_defconfig the command 'dhcp filename' always fails. It
>>> was working in v2019.01
>>>
>>> Same is true for other platforms, e.g. vexpress_ca9x4_defconfig.
>>
>> OK, that's probably not expected ;-)
>>
>> I'd appreciate it if you could continue to track this down to get it fixed.
>
> Let's see how far I get.
bdinfo shows:
DRAM bank = 0x
-> start= 0x8000
-> size = 0x2000
DRAM bank = 0x0001
-> start= 0xa000
-> size = 0x2000
printenv:
loadaddr=0xa0008000
So the load address is in the second DRAM bank.
I guess we need changes in the following places:
t/tftp.c:609: lmb_init_and_reserve(&lmb, gd->bd->bi_dram[0].start,
fs/fs.c:456:lmb_init_and_reserve(&lmb, gd->bd->bi_dram[0].start,
common/bootm.c:62: lmb_init_and_reserve(&images->lmb,
(phys_addr_t)mem_start, mem_size,
I wonder why bootm.c is different and why isn't the fdt considered?
I would suggest the following:
Remove parameter lmb from lmb_get_unreserved_size(). Instead let
lmb_get_unreserved_size() check if a static struct lmb in lib/lmb.c is
initialized. If not use the different DRAM banks and the fdt for
initialization.
Best regards
Heinrich
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v10, 09/10] tftp: prevent overwriting reserved memory
On Sat, Jan 26, 2019 at 09:46:35AM +0100, Simon Goldschmidt wrote:
> Am 26.01.2019 um 04:20 schrieb Heinrich Schuchardt:
> >TheOn 1/14/19 10:38 PM, Simon Goldschmidt wrote:
> >>This fixes CVE-2018-18439 ("insufficient boundary checks in network
> >>image boot") by using lmb to check for a valid range to store
> >>received blocks.
> >>
> >>Signed-off-by: Simon Goldschmidt
> >>Acked-by: Joe Hershberger
> >>---
> >
> >Hello Simon,
> >
> >due to this patch merged as a156c47e39ad7d00 on
> >vexpress_ca15_tc2_defconfig the command 'dhcp filename' always fails. It
> >was working in v2019.01
> >
> >Same is true for other platforms, e.g. vexpress_ca9x4_defconfig.
>
> OK, that's probably not expected ;-)
>
> I'd appreciate it if you could continue to track this down to get it fixed.
>
> >
> >I put in an extra printf() and got:
> >TFTP error: trying to overwrite reserved memory...
> >storeaddr 0, tftp_load_addr 0, tftp_load_size 0
>
> I don't know the first. The latter 2 are not initialized yet in this error
> path and so are expected to be zero here.
>
> Could you run that test again if I sent you a patch enabling required output
> for me to debug this?
>
> >
> >It is not even possible to disable the checks by undefining CONFIG_LMB
> >because a compile error arises without CONFIG_LMB:
> >
> >cmd/bootz.c:48:21: error: ‘bootm_headers_t’ {aka ‘struct bootm_headers’}
> >has no member named ‘lmb’
> >
> >I think the code should compile if CONFIG_LMB is undefined.
>
> You're right, it should compile without CONFIG_LMB. It did initially, so I
> guess that got lost somewhere during all the versions until v10, sorry. I'll
> work on that.
That might be on me. There were a few cases in the networking code
where the patch broke building the existing world.
--
Tom
signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, RESEND, v3, 1/1] avb: add support for named persistent values
On Thu, Jan 17, 2019 at 02:17:00PM +0200, Igor Opaniuk wrote: > AVB version 1.1 introduces support for named persistent values > that must be tamper evident and allows AVB to store arbitrary key-value > pairs [1]. > > Introduce implementation of two additional AVB operations > read_persistent_value()/write_persistent_value() for retrieving/storing > named persistent values. > > Correspondent pull request in the OP-TEE OS project repo [2]. > > [1]: > https://android.googlesource.com/platform/external/avb/+/android-9.0.0_r22 > [2]: https://github.com/OP-TEE/optee_os/pull/2699 > > Signed-off-by: Igor Opaniuk > --- > > Changes in v3: > - fix possible mem lick in avb_read_persistent/avb_write_persistent > - added additional sanity checks > - covered avb read_pvalue/write_pvalue commands with python tests > > Changes in v2: > - fix output format for avb read_pvalue/write_pvalue commands > - fix issue with named value buffer size > > cmd/avb.c | 78 > common/avb_verify.c| 125 > + > include/tee.h | 2 + > include/tee/optee_ta_avb.h | 16 ++ > test/py/tests/test_avb.py | 16 ++ > 5 files changed, 237 insertions(+) Thanks for adding a test here. It seems to fail however: https://travis-ci.org/trini/u-boot/jobs/484486111 https://travis-ci.org/trini/u-boot/jobs/484486112 https://travis-ci.org/trini/u-boot/jobs/484486114 -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] spi: Add support for the Aspeed ast2500 SPI controllers
Hi Cédric, On 25/01/19 11:30 PM, Boris Brezillon wrote: > +Vignesh > [...] >> The first is about performing direct accesses on the AHB window on which >> the flash contents is mapped. > > We have introduced the dirmap API/interface exactly for this purpose, > and the SPI NOR layer will use it in 5.1 (see [1]). > >> >> How do you distinguish a flash read (fast, dual, etc) from a RDSFPD command >> for instance ? > > Why do you need to know the access type? > >> Are the drivers expected to check the SPI OP command and >> depending on the target/command redirect to the appropriate address space ? >> > > Definitely not, the SPI MEM layer is supposed to be memory-type > agnostic, so you should not guess the operation type based on the > opcode. For direct mapping accesses, just implement the ->dirmap_xxx > hooks at the controller level and you'll be able to use the feature.>> >> Also, Aspeed SPI controllers have a Read Timing Compensation Register which >> defines different data input delay cycles depending on SPI clock rates. This >> register is supposed to be tuned when the flash chip characteristics are >> known, after the first bus scan. Is there a way to know that our SPI slave >> is alive and well detected before starting hammering successive reads on it >> to see how it behaves. > > Vignesh mentioned that a while back (couldn't find the thread where > this discussion happened) and I suggested adding a new hook to do this > "link training" process where you'd pass a spi_mem_op template + the > expected result so that the controller can test different setups until > it finds a working one. > Right, Cadence QSPI/OSPI needs PHY DLL values to be tuned for operating at higher frequencies. So idea is to use READID to read flash ID at lowest speed and use that as golden reference for tuning/link training at higher frequencies. I am guessing Aspeed SPI controller has similar need. Here is the discussion that Boris was talking about: https://lkml.org/lkml/2018/10/4/468 I haven't been able to get to implement his suggestions yet, but I think idea is generic enough. >> >> >> I think the U-Boot and Linux driver will be very similar wrt the issues >> above ? > I have submitted patches[1] to sync SPI NOR framework from kernel to U-Boot. Once that's merged then Aspeed SPI can make use of spi-mem interface in U-Boot as well. [1] https://patchwork.ozlabs.org/cover/1017335/ -- Regards Vignesh ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] imx8mq-evk: Outbound network packets lost
On Sat, 26 Jan 2019 at 01:14, Sergey Kubushyn wrote: > Thanks for a reply. The problem here is not with leftover descriptors -- it > is MDIO bus not working at all. It is either bogus speed/clock in DM mode or > something else that I haven't found yet. Reading all zeroes means there is > no communication with the PHY whatsoever, it comes from bare wire. And there > is no need for the PHY to be present at all for an MDIO transaction to > complete successfully -- PHY is a slave device with all clocks coming from > FEC MDIO so it WILL complete successfully even if it not connected to a PHY. > It is kinda like SPI that always succeeds for the master. What I found when debugging the Linux driver is that an MII interrupt was being delivered too early after the first MDIO read the driver issues, resulting in it reading back the wrong value. I was able to reliably stop this from happening by zeroing out ENET_MMFR immediately before the driver sets ENET_MSCR. If I disable networking in U-Boot then the problem in the Linux driver doesn't occur at all, so the only explanation I can come up with is that U-Boot is somehow leaving something in ENET_MMFR which is being unintentionally triggered when the Linux driver sets ENET_MSCR. You have a very good point though because the reads are still completing in U-Boot, even if they always come back zero, so I'm not really sure how there would end up being something left over in ENET_MMFR. Chris ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v10, 09/10] tftp: prevent overwriting reserved memory
On 1/26/19 9:46 AM, Simon Goldschmidt wrote:
> Am 26.01.2019 um 04:20 schrieb Heinrich Schuchardt:
>> TheOn 1/14/19 10:38 PM, Simon Goldschmidt wrote:
>>> This fixes CVE-2018-18439 ("insufficient boundary checks in network
>>> image boot") by using lmb to check for a valid range to store
>>> received blocks.
>>>
>>> Signed-off-by: Simon Goldschmidt
>>> Acked-by: Joe Hershberger
>>> ---
>>
>> Hello Simon,
>>
>> due to this patch merged as a156c47e39ad7d00 on
>> vexpress_ca15_tc2_defconfig the command 'dhcp filename' always fails. It
>> was working in v2019.01
>>
>> Same is true for other platforms, e.g. vexpress_ca9x4_defconfig.
>
> OK, that's probably not expected ;-)
>
> I'd appreciate it if you could continue to track this down to get it fixed.
Let's see how far I get.
You can easily test yourself with QEMU. I was using:
QEMU_AUDIO_DRV=none qemu-system-arm \
-M vexpress-a15 -cpu cortex-a15 -kernel u-boot \
-netdev \
user,id=net0,tftp=tftp,net=192.168.76.0/24,dhcpstart=192.168.76.9 \
-net nic,model=lan9118,netdev=net0 \
-m 1024M --nographic \
-drive if=sd,file=img.vexpress,media=disk,format=raw
>
>>
>> I put in an extra printf() and got:
>> TFTP error: trying to overwrite reserved memory...
>> storeaddr 0, tftp_load_addr 0, tftp_load_size 0
>
> I don't know the first. The latter 2 are not initialized yet in this
> error path and so are expected to be zero here.
>
> Could you run that test again if I sent you a patch enabling required
> output for me to debug this?
Sure.
>
>>
>> It is not even possible to disable the checks by undefining CONFIG_LMB
>> because a compile error arises without CONFIG_LMB:
>>
>> cmd/bootz.c:48:21: error: ‘bootm_headers_t’ {aka ‘struct bootm_headers’}
>> has no member named ‘lmb’
>>
>> I think the code should compile if CONFIG_LMB is undefined.
>
> You're right, it should compile without CONFIG_LMB. It did initially, so
> I guess that got lost somewhere during all the versions until v10,
> sorry. I'll work on that.
>
>>
>> Further for all boards 'dhcp filename' should be working after your
>> patch series if it was working before the patch series.
>
> Well, I wouldn't say it like that. This new code is required from a
> security point of view. There might be boards violating these
> requirements, I can't tell. But it's true that until your ${loadaddr} is
> not completely bogus, 'dhcp filename' should continue to work, yes. If
> not, let's work on this.
I think we are on the same line.
>
>>
>> Why is CONFIG_LMB hard coded? Shouldn't we try to avoid any new hard
>> coded CONFIG symbols? Consider moving it to Kconfig.
>
> Ehrm, sorry, I can't follow you. Which new config symbols are you
> talking about? CONFIG_LMB in ARM's config.h is more than 8 years old!
Sorry, I did not check this. So you didn't put in a new switch.
>
>>
>> The logic you use in tftp_init_load_addr() is problematic:
>>
>> Essentially it allows loading via tftp only in a single region within
>> the first DRAM bank. Why shouldn't I load to the second DRAM bank?
>>
>> Even in a single DRAM bank we will have several reserved regions and in
>> between them several allowable regions for loading.
>
> What leads you to think it's only a single region? Multiple reserved
> regions should work and the 'holes' in between should be valid tftp
> targets. This is tested in the unit tests.
I did not see that load_addr is a global set in cmd/net.c based on the
parameter passed to the tftp command.
>
> You're right that currently only the first DRAM bank works. Let me work
> on that...
>
>>
>> The LMB tests do not even find all reserved regions. E.g. on x86_64 it
>> allows loading to 0x100 though this address is used as a reserved
>> region for PCI, loading to which leads to a crash.
>
> LMB is a long established concept for U-Boot loading boot files. I added
> using it to the 'load' and 'tftp' commands. If x86_64 fails to reserve
> memory for LMB, I think x86_64 should be fixed to do so (e.g. via
> 'arch_lmb_reserve').
>
>>
>> @Tom
>> This LMB patch series stops us from straightening out the Python tests
>> for tftp to make efi-next build without Travis CI error. Please, advise
>> how to proceed.
>
> My idea of how to proceed would be: let's just sort out these issues as
> fast as possible. I'll send you a patch to debug why tftp thinks it
> would overwrite reserved memory. Also, I'll fix the compile error with
> CONFIG_LMB disabled and I'll try to add DRAM banks other than the first.
>
> Regards,
> Simon
>
Best regards
Heinrich
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] efi_loader: Patch non-runtime code out at ExitBootServices already
On 1/25/19 10:43 PM, Ard Biesheuvel wrote: > On Fri, 25 Jan 2019 at 19:21, Heinrich Schuchardt wrote: >> >> On 1/23/19 6:33 PM, Alexander Graf wrote: >>> While discussing something compeltely different, Ard pointed out >>> that it might be legal to omit calling SetVirtualAddressMap altogether. >>> >>> While that sounds great, we currently rely on that call to remove >>> all function pointers to code that we do not support outside of >>> boot services. >>> >>> So let's patch out those bits already on the call to ExitBootServices, >>> so that we can successfully run even when an OS chooses to omit >>> any call to SetVirtualAddressMap. >> >> Such an operating system would not be allowed to use any virtual >> addresses at any time because runtime drivers would not be informed >> about the mapping. >> > > No. The OS would be permitted to invoke the runtime services at their > original offset. > > For arm64, this is trivially achievable, since we already use userland > mappings for the runtime services. On 32-bit architectures, it is more > complicated, since the boot time mapping of peripherals and/or memory > may conflict with the kernel's layout of the address space (e.g., if > your NOR flash lives above 0xc000, you *have* to remap it for the > runtime services to be able to use it). > > > >> Does such an operating system exist? >> Or is this only a hypothetical case? >> >>> >>> Reported-by: Ard Biesheuvel >>> Signed-off-by: Alexander Graf >> >> I am missing a description of the side effects of the change, e.g. >> >> Our EFI unit tests call the Reset() service. >> >> So Python tests will fail on systems that do not implement Reset() in a >> runtime compatible manner. >> > > All runtime services (except SetVirtualAddresMap() and > ConvertPointer(), obviously) may be used at runtime with or without > installing a virtual address mapping. > With this patch in place Travis CI testing fails: After 'bootefi selftest' this output is not ejected: m = u_boot_console.p.expect(['resetting', 'U-Boot']) And after the reset U-Boot crashes (observed for qemu-arm64_defconfig). Best regards Heinrich ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/5] mtd: rawnand: denali: add reset handling
On 1/25/19 9:30 PM, Simon Goldschmidt wrote: > This adds reset handling to the devicetree-enabled denalid nand driver. > > For backwards compatibility, only a warning is printed when failing to > get reset handles. > > Signed-off-by: Simon Goldschmidt > --- > > drivers/mtd/nand/raw/denali_dt.c | 8 > 1 file changed, 8 insertions(+) > > diff --git a/drivers/mtd/nand/raw/denali_dt.c > b/drivers/mtd/nand/raw/denali_dt.c > index d384b974df..21c4540637 100644 > --- a/drivers/mtd/nand/raw/denali_dt.c > +++ b/drivers/mtd/nand/raw/denali_dt.c > @@ -9,6 +9,7 @@ > #include > #include > #include > +#include > > #include "denali.h" > > @@ -64,6 +65,7 @@ static int denali_dt_probe(struct udevice *dev) > const struct denali_dt_data *data; > struct clk clk, clk_x, clk_ecc; > struct resource res; > + struct reset_ctl_bulk reset_bulk; > int ret; > > data = (void *)dev_get_driver_data(dev); > @@ -131,6 +133,12 @@ static int denali_dt_probe(struct udevice *dev) > denali->clk_x_rate = 2; > } > > + ret = reset_get_bulk(bus, &reset_bulk); > + if (ret) > + dev_warn(bus, "Cant' get reset: %d\n", ret); Can't , misplaced "'" > + else > + reset_deassert_bulk(&reset_bulk); > + > return denali_init(denali); > } > > -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 5/5] arm: socfpga: implement proper peripheral reset
On 1/25/19 9:30 PM, Simon Goldschmidt wrote:
> This commit removes ad-hoc reset handling for peripheral resets from SPL
> for socfpga gen5.
>
> This is done because as U-Boot drivers support reset handling by now.
>
> For kernels that don't support taking peripherals out of reset that are
> not enabled by U-Boot, a new Kconfig option "OLD_SOCFPGA_KERNEL_COMPAT"
> is added, which keeps the old behaviour of just enabling all peripherals.
>
> This new option is enabled by default for now, as even Linux 4.20 does
> not support reset handling on all peripherals.
>
> Signed-off-by: Simon Goldschmidt
Well ew, don't we have some pre-linux-boot hook which could just flip
the reset register bits in one place ? And also, I'd prefer this to be
runtime-configurable, not compile-time configurable.
> ---
>
> arch/arm/mach-socfpga/Kconfig | 10 ++
> arch/arm/mach-socfpga/misc_gen5.c | 2 ++
> arch/arm/mach-socfpga/spl_gen5.c | 10 ++
> 3 files changed, 22 insertions(+)
>
> diff --git a/arch/arm/mach-socfpga/Kconfig b/arch/arm/mach-socfpga/Kconfig
> index 5e87371f8c..89acced8d8 100644
> --- a/arch/arm/mach-socfpga/Kconfig
> +++ b/arch/arm/mach-socfpga/Kconfig
> @@ -142,4 +142,14 @@ config SYS_CONFIG_NAME
> default "socfpga_stratix10_socdk" if TARGET_SOCFPGA_STRATIX10_SOCDK
> default "socfpga_vining_fpga" if TARGET_SOCFPGA_SAMTEC_VINING_FPGA
>
> +config OLD_SOCFPGA_KERNEL_COMPAT
> + bool "Enable workarounds for booting old kernels"
> + depends on TARGET_SOCFPGA_GEN5
> + default y
> + help
> + Set this to enable various workarounds for old kernels (e.g. take all
> + peripherals out of reset because old kernels cannot handle reset).
> + This results in sub-optimal settings for newer kernels, only enable
> + if needed.
> +
> endif
> diff --git a/arch/arm/mach-socfpga/misc_gen5.c
> b/arch/arm/mach-socfpga/misc_gen5.c
> index 04f237d100..168669923e 100644
> --- a/arch/arm/mach-socfpga/misc_gen5.c
> +++ b/arch/arm/mach-socfpga/misc_gen5.c
> @@ -243,6 +243,7 @@ int arch_early_init_r(void)
> /* Add device descriptor to FPGA device table */
> socfpga_fpga_add(&altera_fpga[0]);
>
> +#ifdef CONFIG_OLD_SOCFPGA_KERNEL_COMPAT
> #ifdef CONFIG_DESIGNWARE_SPI
> /* Get Designware SPI controller out of reset */
> socfpga_per_reset(SOCFPGA_RESET(SPIM0), 0);
> @@ -252,6 +253,7 @@ int arch_early_init_r(void)
> #ifdef CONFIG_NAND_DENALI
> socfpga_per_reset(SOCFPGA_RESET(NAND), 0);
> #endif
> +#endif /* CONFIG_OLD_SOCFPGA_KERNEL_COMPAT */
>
> return 0;
> }
> diff --git a/arch/arm/mach-socfpga/spl_gen5.c
> b/arch/arm/mach-socfpga/spl_gen5.c
> index f9bea892b1..19a211256d 100644
> --- a/arch/arm/mach-socfpga/spl_gen5.c
> +++ b/arch/arm/mach-socfpga/spl_gen5.c
> @@ -35,16 +35,22 @@ u32 spl_boot_device(void)
> return BOOT_DEVICE_RAM;
> case 0x2: /* NAND Flash (1.8V) */
> case 0x3: /* NAND Flash (3.0V) */
> +#ifdef CONFIG_OLD_SOCFPGA_KERNEL_COMPAT
> socfpga_per_reset(SOCFPGA_RESET(NAND), 0);
> +#endif
> return BOOT_DEVICE_NAND;
> case 0x4: /* SD/MMC External Transceiver (1.8V) */
> case 0x5: /* SD/MMC Internal Transceiver (3.0V) */
> +#ifdef CONFIG_OLD_SOCFPGA_KERNEL_COMPAT
> socfpga_per_reset(SOCFPGA_RESET(SDMMC), 0);
> socfpga_per_reset(SOCFPGA_RESET(DMA), 0);
> +#endif
> return BOOT_DEVICE_MMC1;
> case 0x6: /* QSPI Flash (1.8V) */
> case 0x7: /* QSPI Flash (3.0V) */
> +#ifdef CONFIG_OLD_SOCFPGA_KERNEL_COMPAT
> socfpga_per_reset(SOCFPGA_RESET(QSPI), 0);
> +#endif
> return BOOT_DEVICE_SPI;
> default:
> printf("Invalid boot device (bsel=%08x)!\n", bsel);
> @@ -98,7 +104,9 @@ void board_init_f(ulong dummy)
> socfpga_bridges_reset(1);
> }
>
> +#ifdef CONFIG_OLD_SOCFPGA_KERNEL_COMPAT
> socfpga_per_reset(SOCFPGA_RESET(UART0), 0);
> +#endif
> socfpga_per_reset(SOCFPGA_RESET(OSC1TIMER0), 0);
>
> timer_init();
> @@ -122,9 +130,11 @@ void board_init_f(ulong dummy)
> sysmgr_pinmux_init();
> sysmgr_config_warmrstcfgio(0);
>
> +#ifdef CONFIG_OLD_SOCFPGA_KERNEL_COMPAT
> /* De-assert reset for peripherals and bridges based on handoff */
> reset_deassert_peripherals_handoff();
> socfpga_bridges_reset(0);
> +#endif
>
> debug("Unfreezing/Thaw all I/O banks\n");
> /* unfreeze / thaw all IO banks */
>
--
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 4/5] spi: cadence_qspi: add reset handling
On 1/25/19 9:30 PM, Simon Goldschmidt wrote:
> This adds reset handling to the devicetree-enabled denalid nand driver.
>
> For backwards compatibility, only a warning is printed when failing to
> get reset handles.
>
> Signed-off-by: Simon Goldschmidt
> ---
>
> drivers/spi/cadence_qspi.c | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/spi/cadence_qspi.c b/drivers/spi/cadence_qspi.c
> index 11fce9c4fe..f68c827e6d 100644
> --- a/drivers/spi/cadence_qspi.c
> +++ b/drivers/spi/cadence_qspi.c
> @@ -8,6 +8,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include "cadence_qspi.h"
> @@ -154,10 +155,18 @@ static int cadence_spi_probe(struct udevice *bus)
> {
> struct cadence_spi_platdata *plat = bus->platdata;
> struct cadence_spi_priv *priv = dev_get_priv(bus);
> + struct reset_ctl_bulk reset_bulk;
> + int ret;
>
> priv->regbase = plat->regbase;
> priv->ahbbase = plat->ahbbase;
>
> + ret = reset_get_bulk(bus, &reset_bulk);
> + if (ret)
> + dev_warn(bus, "Cant' get reset: %d\n", ret);
Can't
Also, shouldn't there be some reset_release or reset_free somewhere ?
What about .remove(), shouldn't that release the reset ?
> + else
> + reset_deassert_bulk(&reset_bulk);
> +
> if (!priv->qspi_is_init) {
> cadence_qspi_apb_controller_init(plat);
> priv->qspi_is_init = 1;
>
--
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/5] arm: socfpga: move SDR reset handling to driver
On 1/25/19 9:30 PM, Simon Goldschmidt wrote: > To clean up reset handling for socfpga gen5, let's move the code snippet > taking the DDR controller out of reset from SPL to the DDR driver. > > Signed-off-by: Simon Goldschmidt > --- > > arch/arm/mach-socfpga/spl_gen5.c | 1 - > drivers/ddr/altera/sdram_gen5.c | 4 > 2 files changed, 4 insertions(+), 1 deletion(-) > > diff --git a/arch/arm/mach-socfpga/spl_gen5.c > b/arch/arm/mach-socfpga/spl_gen5.c > index ccdc661d05..f9bea892b1 100644 > --- a/arch/arm/mach-socfpga/spl_gen5.c > +++ b/arch/arm/mach-socfpga/spl_gen5.c > @@ -98,7 +98,6 @@ void board_init_f(ulong dummy) > socfpga_bridges_reset(1); > } > > - socfpga_per_reset(SOCFPGA_RESET(SDR), 0); > socfpga_per_reset(SOCFPGA_RESET(UART0), 0); > socfpga_per_reset(SOCFPGA_RESET(OSC1TIMER0), 0); > > diff --git a/drivers/ddr/altera/sdram_gen5.c b/drivers/ddr/altera/sdram_gen5.c > index 821060459c..bd54c420f8 100644 > --- a/drivers/ddr/altera/sdram_gen5.c > +++ b/drivers/ddr/altera/sdram_gen5.c > @@ -7,6 +7,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -434,6 +435,9 @@ int sdram_mmr_init_full(unsigned int sdr_phy_reg) > SDR_CTRLGRP_DRAMADDRW_ROWBITS_LSB; > int ret; > > + /* release DDR from reset */ > + socfpga_per_reset(SOCFPGA_RESET(SDR), 0); > + Can the reset framework do this ? > writel(rows, &sysmgr_regs->iswgrp_handoff[4]); > > sdr_load_regs(cfg); > -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/5] arm: socfpga: gen5: add reset handles to devicetrees
On 1/25/19 9:30 PM, Simon Goldschmidt wrote: > The SPL for socfpga gen5 currently takes all peripherals out of reset > unconditionally. To implement proper reset handling for peripherals, > some device tree nodes are missing reset handles. > > Since the socfpga gen5 devicetrees are currently in sync with Linux 4.20, > and these reset handles are not added to Linux, yet, let's add them to > U-Boot specific dtsi files to ease future merging. > > This adds a new file socfpga_u-boot.dtsi (note the '_' - if using a '-' > this file gets pulled in for some a10/s10 devicetrees) that adds the > missing reset handles. > > Signed-off-by: Simon Goldschmidt Shouldn't all this be in u-boot specific DTs, instead of the ones imported from Linux ? > --- > > arch/arm/dts/socfpga_arria5_socdk-u-boot.dtsi | 6 ++ > arch/arm/dts/socfpga_cyclone5_dbm_soc1.dts| 5 ++ > .../socfpga_cyclone5_de0_nano_soc-u-boot.dtsi | 6 ++ > arch/arm/dts/socfpga_cyclone5_de10_nano.dts | 5 ++ [...] -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3] net: phy: add TSE PCS support to dwmac-socfpga
On 1/25/19 3:35 PM, Ooi, Joyce wrote:
>> -Original Message-
>> From: Marek Vasut [mailto:ma...@denx.de]
>> Sent: Friday, January 4, 2019 10:56 PM
>> To: Ooi, Joyce ; Joe Hershberger
>>
>> Cc: See, Chin Liang ; Ong, Hean Loong
>> ; Priyanka Jain ; u-
>> b...@lists.denx.de
>> Subject: Re: [U-Boot] [PATCH v3] net: phy: add TSE PCS support to dwmac-
>> socfpga
>>
>> On 1/4/19 10:26 AM, Ooi, Joyce wrote:
-Original Message-
From: Marek Vasut [mailto:ma...@denx.de]
Sent: Friday, December 28, 2018 6:08 PM
To: Ooi, Joyce ; Joe Hershberger
Cc: See, Chin Liang ; Ong, Hean Loong
; Priyanka Jain ; u-
b...@lists.denx.de
Subject: Re: [U-Boot] [PATCH v3] net: phy: add TSE PCS support to
dwmac- socfpga
On 12/28/18 8:28 AM, Ooi, Joyce wrote:
>> -Original Message-
>> From: Marek Vasut [mailto:ma...@denx.de]
>> Sent: Thursday, December 27, 2018 2:55 AM
>> To: Ooi, Joyce ; Joe Hershberger
>>
>> Cc: See, Chin Liang ; Ong, Hean Loong
>> ; Priyanka Jain ;
>> u- b...@lists.denx.de
>> Subject: Re: [U-Boot] [PATCH v3] net: phy: add TSE PCS support to
>> dwmac- socfpga
>>
>> On 12/26/18 8:47 AM, Ooi, Joyce wrote:
>>> Adding Marek.
>>>
-Original Message-
From: U-Boot [mailto:u-boot-boun...@lists.denx.de] On Behalf Of
Ooi, Joyce
Sent: Tuesday, November 27, 2018 5:40 PM
To: Joe Hershberger
Cc: Ong, Hean Loong ; Priyanka Jain
; See, Chin Liang
;
u- b...@lists.denx.de
Subject: Re: [U-Boot] [PATCH v3] net: phy: add TSE PCS support to
dwmac- socfpga
Hi Joe,
Any comments/feedback on this v3 patch?
>>
>> I thought we already had TSE support in drivers/net/altera_tse.c ,
>> is this related ?
>>
Thanks.
Regards,
Joyce Ooi
> -Original Message-
> From: Ooi, Joyce
> Sent: Friday, November 9, 2018 6:16 PM
> To: Joe Hershberger
> Cc: Grygorii Strashko ; Neil Armstrong
> ; Mario Six ;
> Florian Fainelli ; Priyanka Jain
> ; Ooi, Joyce ; See,
> Chin Liang ; Ong, Hean Loong
> ; u-boot@lists.denx.de
> Subject: [PATCH v3] net: phy: add TSE PCS support to
> dwmac-socfpga
>
> This adds support for TSE PCS (Triple Speed Ethernet Physical
> Coding
> Sublayer) that uses SGMII adapter when the phy-mode in device
> tree is set to sgmii.
>
> Signed-off-by: Ooi, Joyce
> ---
> arch/arm/mach-socfpga/include/mach/misc.h |3 +
> arch/arm/mach-socfpga/misc_s10.c |6 +
> drivers/net/Makefile |3 +-
> drivers/net/designware.c |5 +
> drivers/net/designware.h |1 +
> drivers/net/dwmac_socfpga.c | 122 +++
> drivers/net/phy/altr_tse_pcs.c| 184
+
> drivers/net/phy/altr_tse_pcs.h| 56 +
> 8 files changed, 379 insertions(+), 1 deletions(-) create mode
> 100644 drivers/net/phy/altr_tse_pcs.c create mode 100644
> drivers/net/phy/altr_tse_pcs.h
> ---
> v2: add a __weak function to make it compatible for all socfpga
> platforms
> v3: remove __weak function and use board-specific implementation
> instead
>
> diff --git a/arch/arm/mach-socfpga/include/mach/misc.h
> b/arch/arm/mach- socfpga/include/mach/misc.h index
> 4fc9570..751705e
> 100644
> --- a/arch/arm/mach-socfpga/include/mach/misc.h
> +++ b/arch/arm/mach-socfpga/include/mach/misc.h
> @@ -30,6 +30,9 @@ void socfpga_init_security_policies(void);
> void socfpga_sdram_remap_zero(void); #endif
>
> +#ifdef CONFIG_TARGET_SOCFPGA_STRATIX10 int
> +socfpga_test_fpga_ready(void); #endif
> void do_bridge_reset(int enable);
>
> #endif /* _MISC_H_ */
> diff --git a/arch/arm/mach-socfpga/misc_s10.c b/arch/arm/mach-
> socfpga/misc_s10.c index e599362..3cd9c30 100644
> --- a/arch/arm/mach-socfpga/misc_s10.c
> +++ b/arch/arm/mach-socfpga/misc_s10.c
> @@ -11,6 +11,7 @@
> #include
> #include
> #include
> +#include
> #include #include
> #include @@ -
>> 91,6
> +92,11 @@ static int socfpga_set_phymode(void)
>
> return 0;
> }
> +
> +int socfpga_test_fpga_ready(void) {
> + return mbox_get_fpga_config_status(MBOX_CONFIG_STATUS);
> +}
> #else
> static int socfpga_set_phymode(void) { diff --git
> a/drivers/n
Re: [U-Boot] [U-Boot, v10, 09/10] tftp: prevent overwriting reserved memory
Am 26.01.2019 um 04:20 schrieb Heinrich Schuchardt:
TheOn 1/14/19 10:38 PM, Simon Goldschmidt wrote:
This fixes CVE-2018-18439 ("insufficient boundary checks in network
image boot") by using lmb to check for a valid range to store
received blocks.
Signed-off-by: Simon Goldschmidt
Acked-by: Joe Hershberger
---
Hello Simon,
due to this patch merged as a156c47e39ad7d00 on
vexpress_ca15_tc2_defconfig the command 'dhcp filename' always fails. It
was working in v2019.01
Same is true for other platforms, e.g. vexpress_ca9x4_defconfig.
OK, that's probably not expected ;-)
I'd appreciate it if you could continue to track this down to get it fixed.
I put in an extra printf() and got:
TFTP error: trying to overwrite reserved memory...
storeaddr 0, tftp_load_addr 0, tftp_load_size 0
I don't know the first. The latter 2 are not initialized yet in this
error path and so are expected to be zero here.
Could you run that test again if I sent you a patch enabling required
output for me to debug this?
It is not even possible to disable the checks by undefining CONFIG_LMB
because a compile error arises without CONFIG_LMB:
cmd/bootz.c:48:21: error: ‘bootm_headers_t’ {aka ‘struct bootm_headers’}
has no member named ‘lmb’
I think the code should compile if CONFIG_LMB is undefined.
You're right, it should compile without CONFIG_LMB. It did initially, so
I guess that got lost somewhere during all the versions until v10,
sorry. I'll work on that.
Further for all boards 'dhcp filename' should be working after your
patch series if it was working before the patch series.
Well, I wouldn't say it like that. This new code is required from a
security point of view. There might be boards violating these
requirements, I can't tell. But it's true that until your ${loadaddr} is
not completely bogus, 'dhcp filename' should continue to work, yes. If
not, let's work on this.
Why is CONFIG_LMB hard coded? Shouldn't we try to avoid any new hard
coded CONFIG symbols? Consider moving it to Kconfig.
Ehrm, sorry, I can't follow you. Which new config symbols are you
talking about? CONFIG_LMB in ARM's config.h is more than 8 years old!
The logic you use in tftp_init_load_addr() is problematic:
Essentially it allows loading via tftp only in a single region within
the first DRAM bank. Why shouldn't I load to the second DRAM bank?
Even in a single DRAM bank we will have several reserved regions and in
between them several allowable regions for loading.
What leads you to think it's only a single region? Multiple reserved
regions should work and the 'holes' in between should be valid tftp
targets. This is tested in the unit tests.
You're right that currently only the first DRAM bank works. Let me work
on that...
The LMB tests do not even find all reserved regions. E.g. on x86_64 it
allows loading to 0x100 though this address is used as a reserved
region for PCI, loading to which leads to a crash.
LMB is a long established concept for U-Boot loading boot files. I added
using it to the 'load' and 'tftp' commands. If x86_64 fails to reserve
memory for LMB, I think x86_64 should be fixed to do so (e.g. via
'arch_lmb_reserve').
@Tom
This LMB patch series stops us from straightening out the Python tests
for tftp to make efi-next build without Travis CI error. Please, advise
how to proceed.
My idea of how to proceed would be: let's just sort out these issues as
fast as possible. I'll send you a patch to debug why tftp thinks it
would overwrite reserved memory. Also, I'll fix the compile error with
CONFIG_LMB disabled and I'll try to add DRAM banks other than the first.
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
