Re: [U-Boot] cmd: gpio: Remove dead code from do_gpio
On Wed, Jun 13, 2018 at 03:06:49PM +0200, Michal Simek wrote: > gpio input/set/clear and toggle commands are already cover that's why > there is no any other case which should be handled. > > Signed-off-by: Michal Simek > --- > > Reported by: Coverity (local) > Not sure how to report this properly without CID NAK. This raises: w+(e2220-1170) ../cmd/gpio.c: In function 'do_gpio': w+(e2220-1170) ../cmd/gpio.c:199:3: warning: enumeration value 'GPIO_INPUT' not handled in switch [-Wswitch] For all platforms that use cmd/gpio.c -- 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, v2, 3/8] sandbox: Use memcpy() to move overlapping regions
On Tue, Jun 12, 2018 at 12:04:57AM -0600, Simon Glass wrote: > The use of strcpy() to remove characters at the start of a string is safe > in U-Boot, since we know the implementation. But in os.c we are using the > C library's strcpy() function, where this behaviour is not permitted. > > Update the code to use memcpy() instead. > > Reported-by: Coverity (CID: 173279) > Signed-off-by: Simon Glass > --- > > Changes in v2: > - Also remove the leading / from the "/spl" path > > arch/sandbox/cpu/os.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) This ends up breaking the sandbox_spl portions of 'make tests. -- 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, v2, 2/8] avb2.0: integrate avb 2.0 into the build system
On Sun, Jun 03, 2018 at 09:56:37PM +0300, Igor Opaniuk wrote: > Integrate libavb into the build system. Introduce CONFIG_LIBAVB > build option. > > Signed-off-by: Igor Opaniuk 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] mmc: Remove hwpartition help text when command is disabled
On Mon, Jun 11, 2018 at 04:20:09PM +, Alex Kiernan wrote: > When the `mmc hwpartition` command is disabled, remove the associated help > text. > > Signed-off-by: Alex Kiernan 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,v5,5/6] cmd: iotrace: add dump trace command
On Fri, Jun 08, 2018 at 08:53:26PM +0300, Ramon Fried wrote: > Add dump trace command which dump all trace > buffer content in a much more readable fashion > than md. > > Signed-off-by: Ramon Fried > 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] db410c: fix alignment of dts file
On Sat, Jun 09, 2018 at 11:30:30AM +0300, Ramon Fried wrote: > Alignment was wrong, missing one tab. fix it. > > 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, 1/3] configs: Remove empty #ifdef/#ifndef blocks
On Mon, Jun 04, 2018 at 09:45:21PM +1200, Chris Packham wrote: > Remove empty #ifdef/#ifndef..#endif blocks where the configuration they > guarded has been completely removed. > > Signed-off-by: Chris Packham 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, v2, 2/8] console: Fix handling of NULL global_data
On Tue, Jun 12, 2018 at 12:04:56AM -0600, Simon Glass wrote: > Both putc() and puts() can be called before global_data is set up. Some of > the code paths don't handle this correctly. Add an explicit test before > any member is accessed. > > Reported-by: Coverity (CID: 169030) > Signed-off-by: Simon Glass > Reviewed-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] arm: mach-omap2/omap3/clock.c: Enable all GPIO with CMD_GPIO
On Mon, Jun 11, 2018 at 07:56:49PM -0500, Adam Ford wrote: > When CMD_GPIO is enabled the command 'gpio status -a' can cause > a hang or reboot if GPIO banks are not enabled, because it scans > all banks. This patch enables all GPIO banks so 'gpio status -a' > can fully execute. > > Signed-off-by: Adam Ford > > diff --git a/arch/arm/mach-omap2/omap3/clock.c > b/arch/arm/mach-omap2/omap3/clock.c > index b9d92c62b1..9a03bfa9d3 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, v2, 8/8] sandbox: swap_case: Increase number of base address regs
On Tue, Jun 12, 2018 at 12:05:02AM -0600, Simon Glass wrote: > At present the code overruns the bar[] array. Fix this. > > At the same time, drop the leading / from the "/spl" path so that we can > run U-Boot SPL with: > >spl/u-boot-spl > > rather than requiring: > >/path/to/spl/u-boot-spl > > Reported-by: Coverity (CID: 131199) > > Signed-off-by: Simon Glass > Reviewed-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] common: Fix cpu nr type which is always unsigned type
On Wed, Jun 13, 2018 at 08:56:31AM +0200, Michal Simek wrote: > cpu_cmd() is reading cpu number via simple_strtoul() which is always > unsigned type. > Platform code implementations are not expecting that nr can be negative > and there is not checking in the code for that too. > > This patch is using u32 type for cpu number to make sure that platform > code get proper value range. > > 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,v5,1/6] cmd: iotrace: add set region command
On Fri, Jun 08, 2018 at 08:53:22PM +0300, Ramon Fried wrote: > Signed-off-by: Ramon Fried > 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] [U-Boot, v5, 6/6] iotrace: fix behaviour when buffer is full
On Fri, Jun 08, 2018 at 08:53:27PM +0300, Ramon Fried wrote: > Don't continue updating the offset when buffer is full. > When the buffer size exhausts and there's no space left to write > warn the user and update only the needed size and not both the > offset and needed size. > > Add needed buffer size information in the iotrace command. > > 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] [PATCH] test_avb: Add pymark.buildconfigspec information for the AVB tests
On Tue, Jun 19, 2018 at 11:55:08AM -0400, Tom Rini wrote: > Signed-off-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, 3/3] ARM: sunxi: remove empty #ifdef/endif block
On Mon, Jun 04, 2018 at 09:45:23PM +1200, Chris Packham wrote: > Whatever code this was guarding has been removed so remove the guards > too. > > Signed-off-by: Chris Packham 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, V4, 1/2] ARM: image: Add option for ignoring ep bit 3
On Wed, Jun 13, 2018 at 06:13:32AM +0200, Marek Vasut wrote: > Add option to the booti_setup() which indicates to it that the caller > requires the image to be relocated to the beginning of the RAM and > that the information whether the image can be located anywhere in RAM > at 2 MiB aligned boundary or not is to be ignored. This is useful ie. > in case the Image is wrapped in another envelope, ie. fitImage and not > relocating it but moving it would corrupt the envelope. > > Signed-off-by: Marek Vasut > Cc: Bin Chen > Cc: Masahiro Yamada > Cc: Tom Rini > Reviewed-By: Bin Chen 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, v2, 1/8] log: Fix incorect range check in log_get_cat_name()
On Tue, Jun 12, 2018 at 12:04:55AM -0600, Simon Glass wrote: > This allows access to an element after the end of the array. Fix it. > > Reported-by: Coverity (CID: 173279) > Signed-off-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,V4,2/2] bootm: Handle kernel_noload on arm64
On Wed, Jun 13, 2018 at 06:13:33AM +0200, Marek Vasut wrote: > The ARM64 has 2 MiB alignment requirement for the kernel. When using > fitImage, this requirement may by violated, the kernel will thus be > executed from unaligned address and fail to boot. Do what booti does > and run booti_setup() for kernel_noload images on arm64 to obtain a > suitable aligned address to which the image shall be relocated. > > Signed-off-by: Marek Vasut > Cc: Bin Chen > Cc: Masahiro Yamada > Cc: 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, v2, 5/8] fdtgrep: Separate out checking of two allocations
On Tue, Jun 12, 2018 at 12:04:59AM -0600, Simon Glass wrote: > The current code might succeed on the first allocation and fail on the > second. Separate the checks to avoid this problem. > > Of course, free() will never fail and the chances that (when allocating > two small areas) one will succeed and one will fail are just as remote. > But this keeps coverity happy. > > Reported-by: Coverity (CID: 131226) > > Signed-off-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, v2, 6/8] rsa: Fix missing memory leak on error in fdt_add_bignum()
On Tue, Jun 12, 2018 at 12:05:00AM -0600, Simon Glass wrote: > Thsi function can fail without freeing all its memory. Fix it. > > Reported-by: Coverity (CID: 131217) > Signed-off-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] arm: Do not clear LR on exception in SPL
On Mon, Jun 11, 2018 at 02:04:17PM -0500, Andrew F. Davis wrote: > When an exception or interrupt occurs the link register (LR) may > contain the source of the exception, although we do not print the > value it may still be extracted with a debugger. When in SPL we > loop on getting and exception, but use a linking branch, which > over-writes the LR value, use a regular branch instruction here. > > 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, v2, 8/8] doc: avb2.0: add README about AVB2.0 integration
On Sun, Jun 03, 2018 at 09:56:43PM +0300, Igor Opaniuk wrote: > Contains: > 1. Overview of Android Verified Boot 2.0 > 2. Description of avb subset of commands > 3. Examples of errors when boot/vendor/system/vbmeta partitions > are tampered > 4. Examples of enabling AVB2.0 on your setup > > Signed-off-by: Igor Opaniuk 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, V2] dm: gpio: Add DM compatibility to GPIO driver for Davinci
On Sun, Jun 10, 2018 at 10:25:57PM -0500, Adam Ford wrote: > This adds DM_GPIO support for the davinici GPIO driver with > DT support. > > Signed-off-by: Adam Ford > > diff --git a/arch/arm/mach-davinci/include/mach/gpio.h > b/arch/arm/mach-davinci/include/mach/gpio.h > index f1d4d9e9e0..d4b25c3d60 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, v2, 4/8] fdtgrep: Fix logic of free() in do_fdtgrep()
On Tue, Jun 12, 2018 at 12:04:58AM -0600, Simon Glass wrote: > This loop never actually exits, but the way the code is written this is > not obvious. Add an explicit error check. > > Reported-by: Coverity (CID: 131280) > Signed-off-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,V3] block: Add SPL_BLOCK_CACHE and default n
On Mon, Jun 11, 2018 at 05:17:48PM -0500, Adam Ford wrote:
> When enabling BLOCK_CACHE on devices with limited RAM during SPL,
> some devices may not boot. This creates an option to enable
> block caching in SPL by defaults off. It is dependent on SPL_BLK
>
> Fixes: 46960ad6d09b ("block: Have BLOCK_CACHE default to y in some cases")
>
> Signed-off-by: Adam Ford
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, u-boot, 2/5] config: meson-gx-common: Enable USB boot
On Thu, Jun 14, 2018 at 01:43:38PM +0200, Neil Armstrong wrote: > Add USB as boot target depending on the configuration. > > Signed-off-by: Neil Armstrong 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] configs: db410c: Set eMMC env partition to BOOT2
On Thu, Jun 14, 2018 at 07:04:40AM +0300, Ramon Fried wrote: > BOOT2 partition is empty and free for using to store the environment. > Use that instead of the default user partition. > > 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, v2, 7/8] spi: sandbox: Fix memory leak in sandbox_sf_bind_emul()
On Tue, Jun 12, 2018 at 12:05:01AM -0600, Simon Glass wrote: > Move the strdup() call so that it is only done when we know we will bind > the device. > > Reported-by: Coverity (CID: 131216) > > Signed-off-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,u-boot,5/5] configs: Update Meson GX configs
On Thu, Jun 14, 2018 at 01:43:41PM +0200, Neil Armstrong wrote: > Enable USB on all Amlogic Meson GXL based board. > Enable Regulator support on all boards. > Enable ADC support on the LibreTech-CC board. > > Signed-off-by: Neil Armstrong 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] [PATCH v2 2/2] net: mvneta: zero Tx descriptors on init
From: Rabeeh Khoury Make the initialization sequence consistent with the Linux kernel driver. Reviewed-by: Stefan Roese Acked-by: Joe Hershberger Signed-off-by: Rabeeh Khoury Signed-off-by: Baruch Siach --- v2: No change --- drivers/net/mvneta.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/mvneta.c b/drivers/net/mvneta.c index 254dd04697db..ab697b9bc76e 100644 --- a/drivers/net/mvneta.c +++ b/drivers/net/mvneta.c @@ -1708,6 +1708,7 @@ static int mvneta_probe(struct udevice *dev) buffer_loc.tx_descs = (struct mvneta_tx_desc *)bd_space; size = roundup(MVNETA_MAX_TXD * sizeof(struct mvneta_tx_desc), ARCH_DMA_MINALIGN); + memset(buffer_loc.tx_descs, 0, size); buffer_loc.rx_descs = (struct mvneta_rx_desc *) ((phys_addr_t)bd_space + size); size += roundup(MVNETA_MAX_RXD * sizeof(struct mvneta_rx_desc), -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 1/2] net: mvneta: dcache flush TX descriptors at init
From: Rabeeh Khoury This fixes sporadic timeout on initial packet Tx (usually ARP), with an error message like: timeout: packet not sent Reviewed-by: Stefan Roese Tested-by: Chris Packham Acked-by: Joe Hershberger Signed-off-by: Rabeeh Khoury Signed-off-by: Baruch Siach --- v2: Make the patch checkpatch compliant (Stefan Roese) --- drivers/net/mvneta.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/mvneta.c b/drivers/net/mvneta.c index 45e5eda95522..254dd04697db 100644 --- a/drivers/net/mvneta.c +++ b/drivers/net/mvneta.c @@ -1702,6 +1702,7 @@ static int mvneta_probe(struct udevice *dev) /* Align buffer area for descs and rx_buffers to 1MiB */ bd_space = memalign(1 << MMU_SECTION_SHIFT, BD_SPACE); + flush_dcache_range((ulong)bd_space, (ulong)bd_space + BD_SPACE); mmu_set_region_dcache_behaviour((phys_addr_t)bd_space, BD_SPACE, DCACHE_OFF); buffer_loc.tx_descs = (struct mvneta_tx_desc *)bd_space; -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot,v2,3/8] avb2.0: implement AVB ops
On Sun, Jun 03, 2018 at 09:56:38PM +0300, Igor Opaniuk wrote: > Implement AVB ops on top of existing mmc subsystem API. Currently there > is a full implementation of such operations, defined by [1] > AVB2.0 specification: > > .read_from_partition() - reads N bytes from a partition identified by > a name. > .write_to_partition() - Writes N bytes to a partition identified by a name. > .validate_vbmeta_public_key() - checks if the given public ‘vbmeta’ > partition is trusted. > .get_unique_guid_for_partition() - Gets the GUID for a partition identified > by a string name. > > As [1] specification recommends to use tamper-evident storage for storing > rollback indexes and device state (LOCKED/UNLOCKED), > currently are only stubs instead of full implementation for these ops: > .read_rollback_index() - Gets the rollback index for a given index location > .write_rollback_index() - Sets the rollback index to a given location > .read_is_device_unlocked() - Gets where the device is unlocked > > [1] https://android.googlesource.com/platform/external/avb/+/master/README.md > > Signed-off-by: Igor Opaniuk 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] .gitignore: sort normal pattern rules alphabetically
On Mon, Jun 11, 2018 at 04:21:49PM +0900, Masahiro Yamada wrote:
> Follow Linux commit 1377dd3e2987 (".gitignore: sort normal pattern
> rules alphabetically").
>
> This would allow us to easily catch duplicated patterns if any.
>
> Signed-off-by: Masahiro Yamada
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] m68k: Remove empty #ifdef/#ifndef block
On Mon, Jun 04, 2018 at 09:45:22PM +1200, Chris Packham wrote: > Whatever code this was guarding has been removed so remove the guards > too. > > Signed-off-by: Chris Packham 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, v2, 4/8] cmd: avb2.0: avb command for performing verification
On Sun, Jun 03, 2018 at 09:56:39PM +0300, Igor Opaniuk wrote: > Enable a "avb" command to execute Android Verified > Boot 2.0 operations. It includes such subcommands: > avb init - initialize avb2 subsystem > avb read_rb - read rollback index > avb write_rb - write rollback index > avb is_unlocked - check device lock state > avb get_uuid - read and print uuid of a partition > avb read_part - read data from partition > avb read_part_hex - read data from partition and output to stdout > avb write_part - write data to partition > avb verify - run full verification chain > > Signed-off-by: Igor Opaniuk 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, v2, 6/8] am57xx_hs: avb2.0: add support of AVB 2.0
On Sun, Jun 03, 2018 at 09:56:41PM +0300, Igor Opaniuk wrote: > 1. Add vbmeta partition info to android partition layout for am57xx SoC > 2. Add support of AVB 2.0 (including avb subset of commands) for am57xx HS > > Signed-off-by: Igor Opaniuk I re-worded this slightly as it only updates include/environment/ti/boot.h now, a follow-up is still needed to enable CMD_AVB on the platform. That said, 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, v5, 4/6] iotrace: move record definitons to header file
On Fri, Jun 08, 2018 at 08:53:25PM +0300, Ramon Fried wrote: > The header definitions are needed for reading > record information in cmd/iotrace.c > > Signed-off-by: Ramon Fried > 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] [U-Boot, v2, 1/8] avb2.0: add Android Verified Boot 2.0 library
On Sun, Jun 03, 2018 at 09:56:36PM +0300, Igor Opaniuk wrote: > Add libavb lib (3rd party library from AOSP), that implements support of > AVB 2.0. This library is used for integrity checking of Android partitions > on eMMC. > > libavb was added as it is and minimal changes were introduced to reduce > maintenance cost, because it will be deviated from AOSP upstream in the > future. > > Changes: > - license headers changed to conform SPDX-style > - avb_crc32.c dropped > - updates in avb_sysdeps_posix.c/avb_sysdeps.h > > For additional details check [1] AVB 2.0 README. > > [1] https://android.googlesource.com/platform/external/avb/+/master/README.md > > Signed-off-by: Igor Opaniuk 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, v5, 3/6] common: iotrace: add timestamp to iotrace records
On Fri, Jun 08, 2018 at 08:53:24PM +0300, Ramon Fried wrote: > Add timestamp to each iotrace record to aid in debugging > of IO timing access bugs. > > Signed-off-by: Ramon Fried > 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] [U-Boot, v2] mmc: sdhci: Fix MMC HS200 tuning command failures
On Wed, Jun 13, 2018 at 08:20:39AM +0200, Michal Simek wrote: > From: Siva Durga Prasad Paladugu > > This patch fixes the mmc tuning command failures > when tuning pattern data needs to read back for > comparision against the expected bit pattern. > > Reported-by: Masahiro Yamada > Signed-off-by: Siva Durga Prasad Paladugu > Signed-off-by: Michal Simek > Tested-by: Masahiro Yamada 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] gpio: omap_gpio: Name GPIO's by bank and index with DM_GPIO
On Mon, Jun 11, 2018 at 08:05:38PM -0500, Adam Ford wrote: > There are multiple GPIO banks with up to 32 pins / bank. When > using 'gpio status -a' to read the pins, this patch displays > both GPIO_ similar to how the device trees > display in addition to displaying gpio_# > > Signed-off-by: Adam Ford > > diff --git a/drivers/gpio/omap_gpio.c b/drivers/gpio/omap_gpio.c > index 4d54df284d..651f6994e4 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, u-boot, 1/5] adc: meson-saradc: fix regmap_init_mem call
On Thu, Jun 14, 2018 at 01:43:37PM +0200, Neil Armstrong wrote:
> The SARADC driver was merged after the following commit :
> commit d35812368a59 ("regmap: change regmap_init_mem() to take ofnode instead
> udevice")
> Thus breaking build, this patch fixes the regmap_init_mem accordingly.
>
> Signed-off-by: Neil Armstrong
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 ARM Snapdragon
On Sun, Jun 10, 2018 at 11:51:41PM +0300, Ramon Fried wrote: > Replace Mateusz as Maintainer for ARM Snapdragon arch. > > Signed-off-by: Ramon Fried > Acked-by: Mateusz Kulikowski 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, v2, 7/8] test/py: avb2.0: add tests for avb commands
On Sun, Jun 03, 2018 at 09:56:42PM +0300, Igor Opaniuk wrote: > 1. Run AVB 2.0 full verification chain, avb verify > 2. Check if 'avb get_uuid' works, compare results with > 'part list mmc 1' output > 3. Test `avb read` commands, which reads N bytes from a partition > identified by a name > > Signed-off-by: Igor Opaniuk 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, v2, 5/8] avb2.0: add boot states and dm-verity support
On Sun, Jun 03, 2018 at 09:56:40PM +0300, Igor Opaniuk wrote: > 1. Add initial support of boot states mode (red, green, yellow) > 2. Add functions for enforcing dm-verity configurations > > Signed-off-by: Igor Opaniuk 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] fs: btrfs: Do not fail when all root_backups are empty
On Mon, Jun 11, 2018 at 02:14:33PM +0300, Yevgeny Popovych wrote: > This is the case when reading freshly created filesystem. > The error message is like the following: > btrfs_read_superblock: No valid root_backup found! > > Since the data from super_roots/root_backups is not actually used - > decided to rework btrfs_newest_root_backup() into > btrfs_check_super_roots() that will only check if super_roots > array is valid and correctly handle empty scenario. > > As a result: > * btrfs_read_superblock() now only checks if super_roots array is valid; > the case when it is empty is considered OK. > * removed root_backup pointer from btrfs_info, > which would be NULL in case of empty super_roots. > * btrfs_read_superblock() verifies number of devices from the superblock > itself, not newest root_backup. > > Signed-off-by: Yevgeny Popovych > Cc: Marek Behun > Cc: Sergey Struzh 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,v5,2/6] iotrace: add IO region limit
On Fri, Jun 08, 2018 at 08:53:23PM +0300, Ramon Fried wrote: > When dealing with a lot of IO regions, sometimes > it makes sense only to trace a specific one. > This patch adds support for region limits. > If region is not set, the iotrace works the same as it was. > If region is set, the iotrace only logs io operation that falls > in the defined region. > > Signed-off-by: Ramon Fried > 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] [U-Boot, u-boot, 3/5] clk: add Amlogic meson clock driver
On Thu, Jun 14, 2018 at 01:43:39PM +0200, Neil Armstrong wrote: > From: Beniamino Galvani > > Introduce a basic clock driver for Amlogic Meson SoCs which supports > enabling/disabling clock gates and getting their frequency. > > Signed-off-by: Beniamino Galvani > Signed-off-by: Neil Armstrong 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] [PATCH v3] x86: Add 64-bit setjmp/longjmp implementation
Add setjmp/longjmp functions for x86_64.
Signed-off-by: Ivan Gorinov
---
arch/x86/cpu/x86_64/setjmp.S | 49 +++
arch/x86/cpu/x86_64/setjmp.c | 19 -
arch/x86/include/asm/setjmp.h | 17 +++
3 files changed, 66 insertions(+), 19 deletions(-)
create mode 100644 arch/x86/cpu/x86_64/setjmp.S
delete mode 100644 arch/x86/cpu/x86_64/setjmp.c
diff --git a/arch/x86/cpu/x86_64/setjmp.S b/arch/x86/cpu/x86_64/setjmp.S
new file mode 100644
index 000..97b8128
--- /dev/null
+++ b/arch/x86/cpu/x86_64/setjmp.S
@@ -0,0 +1,49 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (C) 2018 Intel Corporation
+ *
+ * See arch/x86/include/asm/setjmp.h for jmp_buf format
+ */
+
+#include
+
+.text
+.align 8
+
+ENTRY(setjmp)
+
+ pop %rcx
+ movq%rcx, (%rdi)/* Return address */
+ movq%rsp, 8(%rdi)
+ movq%rbp, 16(%rdi)
+ movq%rbx, 24(%rdi)
+ movq%r12, 32(%rdi)
+ movq%r13, 40(%rdi)
+ movq%r14, 48(%rdi)
+ movq%r15, 56(%rdi)
+ xorq%rax, %rax /* Direct invocation returns 0 */
+ jmpq*%rcx
+
+ENDPROC(setjmp)
+
+.align 8
+
+ENTRY(longjmp)
+
+ movq(%rdi), %rcx/* Return address */
+ movq8(%rdi), %rsp
+ movq16(%rdi), %rbp
+ movq24(%rdi), %rbx
+ movq32(%rdi), %r12
+ movq40(%rdi), %r13
+ movq48(%rdi), %r14
+ movq56(%rdi), %r15
+
+ movq%rsi, %rax /* Value to be returned by setjmp() */
+ testq %rax, %rax /* cannot be 0 in this case */
+ jnz 1f
+ incq%rax/* Return 1 instead */
+1:
+ jmpq*%rcx
+
+ENDPROC(longjmp)
diff --git a/arch/x86/cpu/x86_64/setjmp.c b/arch/x86/cpu/x86_64/setjmp.c
deleted file mode 100644
index 5d4a74a..000
--- a/arch/x86/cpu/x86_64/setjmp.c
+++ /dev/null
@@ -1,19 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+
-/*
- * Copyright (c) 2016 Google, Inc
- */
-
-#include
-#include
-
-int setjmp(struct jmp_buf_data *jmp_buf)
-{
- printf("WARNING: setjmp() is not supported\n");
-
- return 0;
-}
-
-void longjmp(struct jmp_buf_data *jmp_buf, int val)
-{
- printf("WARNING: longjmp() is not supported\n");
-}
diff --git a/arch/x86/include/asm/setjmp.h b/arch/x86/include/asm/setjmp.h
index f25975f..49c36c1 100644
--- a/arch/x86/include/asm/setjmp.h
+++ b/arch/x86/include/asm/setjmp.h
@@ -8,6 +8,21 @@
#ifndef __setjmp_h
#define __setjmp_h
+#ifdef CONFIG_X86_64
+
+struct jmp_buf_data {
+ unsigned long __rip;
+ unsigned long __rsp;
+ unsigned long __rbp;
+ unsigned long __rbx;
+ unsigned long __r12;
+ unsigned long __r13;
+ unsigned long __r14;
+ unsigned long __r15;
+};
+
+#else
+
struct jmp_buf_data {
unsigned int __ebx;
unsigned int __esp;
@@ -17,6 +32,8 @@ struct jmp_buf_data {
unsigned int __eip;
};
+#endif
+
int setjmp(struct jmp_buf_data *jmp_buf);
void longjmp(struct jmp_buf_data *jmp_buf, int val);
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, 2/2] configs: dragonboard410c: remove env partition offset
On Thu, Jun 14, 2018 at 07:04:41AM +0300, Ramon Fried wrote: > BOOT2 is not partitioned, no need for partition offset. > > 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,u-boot,4/5] meson: use the clock driver
On Thu, Jun 14, 2018 at 01:43:40PM +0200, Neil Armstrong wrote: > From: Beniamino Galvani > > Use the clk framework to initialize clocks from drivers that need them > instead of having hardcoded frequencies and initializations from board > code. > > Signed-off-by: Beniamino Galvani > Signed-off-by: Neil Armstrong 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] .gitignore: move *.dtb and *.dtb.S patterns to the top-level .gitignore
On Mon, Jun 11, 2018 at 04:21:50PM +0900, Masahiro Yamada wrote:
> Follow Linux commit 10b62a2f785a (".gitignore: move *.dtb and *.dtb.S
> patterns to the top-level .gitignore").
>
> Signed-off-by: Masahiro Yamada
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] [PATCH v3] x86: Add 64-bit setjmp/longjmp implementation
Add setjmp/longjmp functions for x86_64. v3: Removed the FPU control word and MXCSR; Corrected SPDX License Identifier. v2: Added the FPU control word and MXCSR to jmp_buf; Using ENTRY/ENDPROC macros. Ivan Gorinov (1): x86: Add 64-bit setjmp/longjmp implementation arch/x86/cpu/x86_64/setjmp.S | 49 +++ arch/x86/cpu/x86_64/setjmp.c | 19 - arch/x86/include/asm/setjmp.h | 17 +++ 3 files changed, 66 insertions(+), 19 deletions(-) create mode 100644 arch/x86/cpu/x86_64/setjmp.S delete mode 100644 arch/x86/cpu/x86_64/setjmp.c -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v8 14/30] efi: Don't build sandbox with __attribute__((ms_abi))
Hi Alex, On 18 June 2018 at 08:46, Alexander Graf wrote: > On 06/18/2018 04:08 PM, Simon Glass wrote: >> >> There appears to be a bug [1] in gcc when using varargs with this >> attribute. Disable it for sandbox so that functions which use that can >> work correctly, such as install_multiple_protocol_interfaces(). >> >> [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70955 >> >> Signed-off-by: Simon Glass > > > See my patch instead please. OK I see it now. Do you know what gcc fixes this problem? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] x86: efi-x86_app: Update MAINTAINERS
On 18 June 2018 at 19:43, Bin Meng wrote: > Previous rename of efi-x86 target missed the MAINTAINERS update, > which caused the buildman warnings: > > WARNING: no status info for 'efi-x86_app' > WARNING: no maintainers for 'efi-x86_app' > > This updates the board MAINTAINERS to reflect the up-to-date info. > > Signed-off-by: Bin Meng > --- > > board/efi/efi-x86_app/MAINTAINERS | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v8 12/30] sandbox: Try to start the RAM buffer at a particular address
Hi Alex, On 18 June 2018 at 08:45, Alexander Graf wrote: > On 06/18/2018 04:08 PM, Simon Glass wrote: >> >> Use a starting address of 256MB which should be available. This helps to >> make sandbox RAM buffers pointers more recognisable. >> >> Signed-off-by: Simon Glass > > > Nak, this has a non-0 chance of failing, in case something else is already > mapped at that address. You don't want to have your CI blow up 1% of the > time due to this. It's just a hint though. Everything will still work if it doesn't get this exact address. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] serial: zynq: Use platdata for storing static data instead of priv
On 15 June 2018 at 01:32, Michal Simek wrote: > Explanation from Simon Glass > "Private data is created when the device is probed and freed when the > device is removed. > > Platform data is created when the device is bound, and survives > probe/remove cycles. > > Strictly speaking, platform data should be used to hold the decoded > device tree properties. Private data should be used for run-time > things the device needs to keep track of." > > Based on description the driver needs to be switch to use platdata > instead of priv. > > Signed-off-by: Michal Simek > --- > > Apply on the top of latest zynq serial changes (soon in mainline). > > --- > drivers/serial/serial_zynq.c | 32 > 1 file changed, 16 insertions(+), 16 deletions(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 02/13] efi.h: Do not use config options
Hi Bin, On 15 June 2018 at 03:51, Bin Meng wrote: > Hi Simon, > > On Thu, Jun 14, 2018 at 8:58 PM, Simon Glass wrote: >> Hi Alex, >> >> On 13 June 2018 at 04:17, Alexander Graf wrote: >>> >>> >>> On 13.06.18 03:29, Simon Glass wrote: Hi Bin, Alex, On 12 June 2018 at 09:36, Bin Meng wrote: > From: Alexander Graf > > Currently efi.h determines a few bits of its environment according to > config options. This falls apart with the efi stub support which may > result in efi.h getting pulled into the stub as well as real U-Boot > code. In that case, one may be 32bit while the other one is 64bit. > > This patch changes the conditionals to use compiler provided defines > instead. That way we always adhere to the build environment we're in > and the definitions adjust automatically. > > Signed-off-by: Alexander Graf > Reviewed-by: Bin Meng > Tested-by: Bin Meng > Signed-off-by: Bin Meng > --- > > Changes in v2: None > > include/efi.h| 17 - > lib/efi/Makefile | 4 ++-- > 2 files changed, 6 insertions(+), 15 deletions(-) > > diff --git a/include/efi.h b/include/efi.h > index 98bddba..5e1e8ac 100644 > --- a/include/efi.h > +++ b/include/efi.h > @@ -19,12 +19,12 @@ > #include > #include > > -#if CONFIG_EFI_STUB_64BIT || (!defined(CONFIG_EFI_STUB) && > defined(__x86_64__)) > -/* EFI uses the Microsoft ABI which is not the default for GCC */ > +/* EFI on x86_64 uses the Microsoft ABI which is not the default for GCC > */ > +#ifdef __x86_64__ > #define EFIAPI __attribute__((ms_abi)) > #else > #define EFIAPI asmlinkage > -#endif > +#endif /* __x86_64__ */ I made the same comment in another patch. This is becoming too ad-hoc where making EFI builds work is distributed and hidden in such a way that no one will be able to know whether a change causes problems or not. I feel that build config should be deterministic given the CONFIG options provided by the board. Any checks of compiler predefines should be done in one place (efi.h?) and bugs in that stuff should there all be in one place too, and easier to debug and fix. >>> >>> I actually think the opposite is true. We should get rid of any #ifdef >>> CONFIG_ARCH checks throughout the code base that are not meant to >>> actually check for the "target" (sandbox for example), but instead >>> really only want to know the architecture the code is building against. >>> >>> We can easily trust the compiler to emit correct defines for the target >>> architecture it's building against. That's what every other piece of C >>> code on earth depends on. Why be different? >> >> By this logic we would check for __x86_64__ everywhere instead of >> CONFIG_X86. I can't think of a better way to explain this without >> repeating myself. >> >> Bin, do you understand what I am getting at? Are my concerns unwarranted? > > I got what you are concerned about. I guess you wanted to say "By this > logic we would check __x86_64__ everywhere instead of *CONFIG_X86_64*" > As when CONFIG_X86_64 is defined, the "-m64" flag is passed to > compiler, and __x86_64__ takes effect. But I think this can only be > applied in source codes. In makefiles, we still need CONFIG_X86_64. > > For the bug we are trying to address here, I believe current patch to > test __x86_64__ is the simplest way compared to a bunch of config > options checks. In fact, __x86_64__ contains enough information to fix > the problem, and the config options checks look superfluous. > > How about we add some comments to the changes above to explain some > more details? Does that look better? Thanks for looking at this. Yes comments would really help, thanks. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] common: print \n in initr_scsi()
Hi Heinrich, On 14 June 2018 at 23:01, Heinrich Schuchardt wrote: > Typically init_scsi() does not output anything. So initr_scsi() should > provide a \n or we may see borked output like > > SCSI: Net: No ethernet found. > > as observed with sandbox_defconfig. > > Signed-off-by: Heinrich Schuchardt > --- > common/board_r.c | 1 + > 1 file changed, 1 insertion(+) Instead of this, we should enable DM_SCSI on sandbox. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 10/11] efi_loader: Pass address to fs_read()
Hi Alex, On 14 June 2018 at 15:55, Alexander Graf wrote: > > > On 14.06.18 23:35, Simon Glass wrote: >> Hi Alex, >> >> On 14 June 2018 at 13:51, Alexander Graf wrote: >>> >>> >>> On 14.06.18 21:01, Simon Glass wrote: On 14 June 2018 at 12:22, Alexander Graf wrote: > The fs_read() function wants to get an address rather than the > pointer to a buffer. > > So let's convert the passed buffer from pointer back a the address > to make efi_loader on sandbox happier. > > Signed-off-by: Alexander Graf > > --- > > v1 -> v2: > > - Clarify address vs pointer > - include mapmem.h > --- > lib/efi_loader/efi_file.c | 5 - > 1 file changed, 4 insertions(+), 1 deletion(-) Reviewed-by: Simon Glass >>> >>> I actually think that this patch tackles the problem the wrong way >>> around. I've cooked up another one that converts fs_read() and >>> fs_write() to instead take a pointer - which really is what most users >>> of the API want in the first place: >>> >>> >>> https://github.com/agraf/u-boot/commit/eb89f036a42cea8d7aaa6d83b8ecd9d202814b0f >> >> Actually this is a pretty good exposition of why we don't want to use >> pointers everywhere. U-Boot uses addresses all over the place. Even a >> search for something as specific as "ulong addr" gets over 200 >> matches. If we go down this path we will end up changing a pretty >> fundamental part of U-Boot, and I don't think it is a good idea to do >> that. Addresses are easy to understand, can be added/subtracted >> without pointer arithmetic, can be easily converted to pointers as >> needed, can be 32-bits long on sandbox, etc. > > I tend to disagree with this. Most code in U-Boot actually consumes > pointers rather than addresses. That might be true within individual components, but addresses are the common currency in U-Boot. See for example bootm, all the image-handling stuff including FIT, commands, device tree address properties. Pointers are more often used at the lowest level of code. > >> So I think we should step back from the abyss here and stick with the >> way sandbox currently deals with addresses. It works well, is pretty >> easy to understand, allows debugging which is just as easy on sandbox >> as other archs (since they both uses addresses until basically the >> final access), the addresses are typically small values that start at >> 0 which much is easier to read than (e.g.) 7f1b58c8b008. >> >> Here for example is the output from starting U-Boot with debugging in >> board_f.c (something I have turned on a lot when refactoring and >> debugging the init sequence): >> >> U-Boot 2018.07-rc1-00142-g134ea86c7f-dirty (Jun 14 2018 - 15:04:04 -0600) >> >> DRAM: Monitor len: 00395AB0 >> Ram size: 0800 >> Ram top: 0800 >> Reserving 3670k for U-Boot at: 07c6a000 >> Reserving 32776k for malloc() at: 05c68000 >> Reserving 120 Bytes for Board Info at: 05c67f88 >> Reserving 472 Bytes for Global Data at: 05c67db0 >> Reserving 4352 Bytes for FDT at: 05c66cb0 >> Reserving 0x3c8 Bytes for bootstage at: 05c668e8 >> >> RAM Configuration: >> Bank #0: 0 128 MiB >> >> DRAM: 128 MiB >> New Stack Pointer is: 05c668d0 >> Copying bootstage from 7fdb0056e038 to 7fdb061c48f0, size 3c8 >> Relocation Offset is: 07c6a000 >> Relocating to 07c6a000, new gd at 05c67db0, sp at 05c668d0 >> >> >> If we use pointers we get things like this: >> >> Reserving 3670k for U-Boot at: 7f1b58c8b008 >> >> I just don't want to deal with 64-bit addresses when debugging things, >> and there really is no point. The map_sysmem() function provides a >> nice and easy way to cast an address to a pointer, and it works on all >> architectures. > > Ok, circling back to square 1. The main issue we're facing here is that > most code in U-Boot does not really understand the difference between > virtual and physical addresses - it just simply assumes a 1:1 map. Traditionally that was true, but over the past 5 years quite a bit of code has been converted to work correctly with sandbox. Also, almost all *tested* code supports sandbox. > > With sandbox, we do not have a 1:1 map anymore - any address is > somewhere else than its pointer. > > We have a few options: > > 1) Deal with pointers at random addresses throughout the code > > I can see why you don't want this. I find ASLR generated addresses quite > cumbersome to read as well. I'm not sure what this means. > > 2) Explicitly map RAM at VA 0x1000, then do 1:1 map > > This would be the best of all worlds still IMHO. That way we will have > easily readable addresses (that are identical in 32bit and 64bit), but > can still do a 1:1 map. The only thing we need to do is to introduce a > linker section at 0x1000. Linker section or mmap() is essentially the same thing. The former will presumably just fail to run (bus error?) if the address is not available. The latter will select a similar, available address. > > 3) Keep converting
Re: [U-Boot] sandbox: Net: No ethernet found.
+Joe On 15 June 2018 at 00:10, Heinrich Schuchardt wrote: > Hello Simon, > > when I run sandbox_defconfig I always get > Net: No ethernet found. > > The dm command shows no driver attached to uclass 21: eth. Why are the > sandbox and sandbox-raw drivers not loaded? > > device_bind_common is not called for these drivers. > > arch/sandbox/dts/sandbox.dts makes assumptions about the naming of > interfaces: > > host-raw-interface = "eth0" > > With systemd eth0 tends not to exist. The interfaces on my Debian Buster > system the interfaces are called lo, enp0s25, and wlp12s0. > > Shouldn't we use if_nameindex() to enumerate the interfaces? > > Best regards > > Heinrich > > > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] tpm TIS TPMv2.0
Hi, On 18 June 2018 at 03:47, Miquel Raynal wrote: > > Hi Martin, > > > > > Nevertheless one question: Why did you define another dts binding > > > > instead of using that one what is already available on the Linux > > > > kernel? There is "tcg,tpm_tis-spi" already defined. > > > > > > I did not know this one, actually I mostly worked on U-Boot. > > > > > > However, this compatible is misleading as it does not make any difference > > > between v1.x and v2.0 specification. > > > > But on the other hand it would give us a chance to determine the version at > > runtime what could be beneficial for firmware updates. But this is a > > special case. > > We already discussed that point on the ML and decided to choose the > version at compile time. I did not have the firmware update case in > mind though. I think we need to move to determining the version at run-time, allowing people to build U-Boot with both versions if needed. This will be helpful for testing in particular. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] U-Boot TFTP protection
Hi Stefan, On 15 June 2018 at 00:44, Stefan Johansson wrote: > > Hello, > We have been looking at protecting U-Boot from (malicious) TFTP overwrites. > We want to do this after our ARMv7 U-Boot has relocated. > > The memory map looks like this (I hope): > > --- Top of DRAM > | U-Boot (Protected) > | -- U_Boot_start > | Heap (Protected) > | -- Start_Heap = U_Boot_start - Heap_Size > | Stack (Protected) > | -- Start_Stack = Start_Heap - Stack_Size > | Buffers (Protected) > | -- ??? > | Free DRAM (Not Protected) > --- Start of DRAM > > I seem to get lost in the code trying to find possible buffers, can you > please give a hint how I can find the address "???" Well gd->start_addr_sp is the stop of the stack. The size of the stack is not necessarily fixed and will grow downwards from there. But I suppose you could set a particular size and protect from start of DRAM to to the assumed bottom of the stack area. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/5] cmd: Add bind/unbind commands to bind a device to a driver from the command line
On Mon, Jun 18, 2018 at 8:56 AM, Jean-Jacques Hiblot wrote: > In some cases it can be useful to be able to bind a device to a driver from > the command line. > The obvious example is for versatile devices such as USB gadget. > Another use case is when the devices are not yet ready at startup and > require some setup before the drivers are bound (ex: FPGA which bitsream is > fetched from a mass storage or ethernet) > > usage example: > > bind usb_dev_generic 0 usb_ether > unbind usb_dev_generic 0 usb_ether > or > unbind eth 1 > > bind /ocp/omap_dwc3@4838/usb@4839 usb_ether > unbind /ocp/omap_dwc3@4838/usb@4839 > > Signed-off-by: Jean-Jacques Hiblot > Looks great! Reviewed-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2] patman: Support using a particular SMTP server
Some environments require providing the '--smtp-server' argument to
'git send-email'. Add support for this.
Signed-off-by: Simon Glass
---
Changes in v2:
- Fix 'get' typo
tools/patman/README | 1 +
tools/patman/gitutil.py | 6 +-
tools/patman/patman.py | 5 -
3 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/tools/patman/README b/tools/patman/README
index 606780e2ed..7917fc8bdc 100644
--- a/tools/patman/README
+++ b/tools/patman/README
@@ -107,6 +107,7 @@ patman.py. For reference, the useful ones (at the moment)
shown below
ignore_errors: True
process_tags: False
verbose: True
+smtp_server: /path/to/sendmail
<<<
diff --git a/tools/patman/gitutil.py b/tools/patman/gitutil.py
index 64ac0c8d3d..9905bb0bbd 100644
--- a/tools/patman/gitutil.py
+++ b/tools/patman/gitutil.py
@@ -332,7 +332,8 @@ def BuildEmailList(in_list, tag=None, alias=None,
raise_on_error=True):
return result
def EmailPatches(series, cover_fname, args, dry_run, raise_on_error, cc_fname,
-self_only=False, alias=None, in_reply_to=None, thread=False):
+self_only=False, alias=None, in_reply_to=None, thread=False,
+smtp_server=None):
"""Email a patch series.
Args:
@@ -348,6 +349,7 @@ def EmailPatches(series, cover_fname, args, dry_run,
raise_on_error, cc_fname,
Should be a message ID that this is in reply to.
thread: True to add --thread to git send-email (make
all patches reply to cover-letter or first patch in series)
+smtp_server: SMTP server to use to send patches
Returns:
Git command that was/would be run
@@ -405,6 +407,8 @@ def EmailPatches(series, cover_fname, args, dry_run,
raise_on_error, cc_fname,
to = BuildEmailList([os.getenv('USER')], '--to', alias, raise_on_error)
cc = []
cmd = ['git', 'send-email', '--annotate']
+if smtp_server:
+cmd.append('--smtp-server=%s' % smtp_server)
if in_reply_to:
if type(in_reply_to) != str:
in_reply_to = in_reply_to.encode('utf-8')
diff --git a/tools/patman/patman.py b/tools/patman/patman.py
index 8d2c78235a..7c8ba441b3 100755
--- a/tools/patman/patman.py
+++ b/tools/patman/patman.py
@@ -60,6 +60,8 @@ parser.add_option('--no-check', action='store_false',
dest='check_patch',
help="Don't check for patch compliance")
parser.add_option('--no-tags', action='store_false', dest='process_tags',
default=True, help="Don't process subject tags as aliaes")
+parser.add_option('--smtp-server', type='str',
+ help="Specify the SMTP server to 'git send-email'")
parser.add_option('-T', '--thread', action='store_true', dest='thread',
default=False, help='Create patches as a single thread')
@@ -165,7 +167,8 @@ else:
if its_a_go:
cmd = gitutil.EmailPatches(series, cover_fname, args,
options.dry_run, not options.ignore_bad_tags, cc_file,
-in_reply_to=options.in_reply_to, thread=options.thread)
+in_reply_to=options.in_reply_to, thread=options.thread,
+smtp_server=options.smtp_server)
else:
print(col.Color(col.RED, "Not sending emails due to errors/warnings"))
--
2.18.0.rc1.244.gcf134e6275-goog
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] test_avb: Add pymark.buildconfigspec information for the AVB tests
Signed-off-by: Tom Rini
---
test/py/tests/test_avb.py | 5 +
1 file changed, 5 insertions(+)
diff --git a/test/py/tests/test_avb.py b/test/py/tests/test_avb.py
index 770bdde4ad0c..7996e4845db3 100644
--- a/test/py/tests/test_avb.py
+++ b/test/py/tests/test_avb.py
@@ -23,6 +23,7 @@ mmc_dev = 1
temp_addr = 0x9000
temp_addr2 = 0x90002000
+@pytest.mark.buildconfigspec('cmd_avb')
def test_avb_verify(u_boot_console):
"""Run AVB 2.0 boot verification chain with avb subset of commands
"""
@@ -35,6 +36,7 @@ def test_avb_verify(u_boot_console):
assert response.find(success_str)
+@pytest.mark.buildconfigspec('cmd_avb')
def test_avb_mmc_uuid(u_boot_console):
"""Check if 'avb get_uuid' works, compare results with
'part list mmc 1' output
@@ -67,6 +69,7 @@ def test_avb_mmc_uuid(u_boot_console):
assert guid == avb_guid_resp.split("UUID: ")[1]
+@pytest.mark.buildconfigspec('cmd_avb')
def test_avb_read_rb(u_boot_console):
"""Test reading rollback indexes
"""
@@ -77,6 +80,7 @@ def test_avb_read_rb(u_boot_console):
response = u_boot_console.run_command('avb read_rb 1')
+@pytest.mark.buildconfigspec('cmd_avb')
def test_avb_is_unlocked(u_boot_console):
"""Test if device is in the unlocked state
"""
@@ -87,6 +91,7 @@ def test_avb_is_unlocked(u_boot_console):
response = u_boot_console.run_command('avb is_unlocked')
+@pytest.mark.buildconfigspec('cmd_avb')
def test_avb_mmc_read(u_boot_console):
"""Test mmc read operation
"""
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] efi_loader: Fix GOP 32bpp exposure
On Tue, Jun 19, 2018 at 12:47 PM, Alexander Graf wrote: > We store pixels as BGRA in memory, as can be seen from struct efi_gop_pixel. > So we need to expose the same format to UEFI payloads to actually have them > use the correct colors. > > Reported-by: Fabian Vogt > Signed-off-by: Alexander Graf Tested-by: Peter Robinson Fixes the blue penguin feet on efi consoles for me on the RPi and Pine64. > --- > lib/efi_loader/efi_gop.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/lib/efi_loader/efi_gop.c b/lib/efi_loader/efi_gop.c > index 1afe8418e1..3a36bbcbfa 100644 > --- a/lib/efi_loader/efi_gop.c > +++ b/lib/efi_loader/efi_gop.c > @@ -472,7 +472,7 @@ efi_status_t efi_gop_register(void) > gopobj->info.version = 0; > gopobj->info.width = col; > gopobj->info.height = row; > - gopobj->info.pixel_format = EFI_GOT_RGBA8; > + gopobj->info.pixel_format = EFI_GOT_BGRA8; > gopobj->info.pixels_per_scanline = col; > > gopobj->bpix = bpix; > -- > 2.12.3 > > ___ > U-Boot mailing list > U-Boot@lists.denx.de > https://lists.denx.de/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH V2] eth: dm: fec: Add gpio phy reset binding
On Sun, Jun 17, 2018 at 8:22 AM, Michael Trimarchi wrote: > Add the missing gpio phy reset binding to the gpio and > reset time configuration > > Signed-off-by: Michael Trimarchi Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] efi_loader: Fix GOP 32bpp exposure
On 06/19/2018 01:47 PM, Alexander Graf wrote:
> We store pixels as BGRA in memory, as can be seen from struct efi_gop_pixel.
> So we need to expose the same format to UEFI payloads to actually have them
> use the correct colors.
>
> Reported-by: Fabian Vogt
> Signed-off-by: Alexander Graf
> ---
> lib/efi_loader/efi_gop.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/lib/efi_loader/efi_gop.c b/lib/efi_loader/efi_gop.c
> index 1afe8418e1..3a36bbcbfa 100644
> --- a/lib/efi_loader/efi_gop.c
> +++ b/lib/efi_loader/efi_gop.c
> @@ -472,7 +472,7 @@ efi_status_t efi_gop_register(void)
> gopobj->info.version = 0;
> gopobj->info.width = col;
> gopobj->info.height = row;
> - gopobj->info.pixel_format = EFI_GOT_RGBA8;
> + gopobj->info.pixel_format = EFI_GOT_BGRA8;
Graphic cards have been produced both with RGB and BRG bit sequence.
According to the VESA BIOS Extension Core Functions Standard 2.0
describe a pixel we need the RedFieldPosition, GreenFieldPosition,
BlueFieldPosition, and RsvdFieldPosition fields as well as RedMaskSize,
GreenMaskSize, BlueMaskSize, and RsvdMaskSize.
For the EFI implementation we only have to consider a low endian memory
model.
Currently in drivers/video/vidconsole-uclass.c we make the following
assumptions:
16bit graphic cards have
red in bits 11..15
green in bits 5..10
blue in bis 0..4
32bit graphic cards have
red in bits 16..23
green in bits 8..15
blue in bis 0..7
of an u16 or u32 pixel.
In efi_vid16_to_blt_col() we make the same assumption.
Structure efi_gop_pixel has sequence blue, green, red, reserved which
matches the 32bit assumption in drivers/video/vidconsole-uclass.c.
struct efi_gop_pixel {
u8 blue;
u8 green;
u8 red;
u8 reserved;
};
So setting pixel_format = EFI_GOT_BGRA8 provides consistency in our
implementation but will fail on RGBA graphic cards.
@Anatolij:
Do you have an overview if we have blue in the low bits of the pixels in
all low endian U-Boot supported devices?
Reviewed-by: Heinrich Schuchardt
> gopobj->info.pixels_per_scanline = col;
>
> gopobj->bpix = bpix;
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 1/1] x86: qemu: do not build car.o with start64.o
car.o can only be used with start.o, not with start64.o. Signed-off-by: Heinrich Schuchardt --- v2 rebase to current master shorten commit message --- arch/x86/cpu/qemu/Makefile | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/arch/x86/cpu/qemu/Makefile b/arch/x86/cpu/qemu/Makefile index e5ea92545e3..b1daffd4a32 100644 --- a/arch/x86/cpu/qemu/Makefile +++ b/arch/x86/cpu/qemu/Makefile @@ -2,6 +2,9 @@ # # Copyright (C) 2015, Bin Meng +ifndef CONFIG_$(SPL_)X86_64 +obj-y += car.o +endif -obj-y += car.o dram.o +obj-y += dram.o obj-y += qemu.o obj-$(CONFIG_QFW) += cpu.o e820.o -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC] ARM: rmobile: create DT memory nodes for R8A7795 3.0 and newer
Hi Laurent,
On Tue, Jun 19, 2018 at 4:15 AM Laurent Pinchart
wrote:
> On Sunday, 17 June 2018 03:08:02 EEST Marek Vasut wrote:
> > On 06/16/2018 05:44 PM, Laurent Pinchart wrote:
> > > On Saturday, 16 June 2018 02:42:30 EEST Marek Vasut wrote:
> > >> On 06/16/2018 01:21 AM, Laurent Pinchart wrote:
> > >>> On Friday, 15 June 2018 15:00:31 EEST Marek Vasut wrote:
> > On 06/15/2018 01:43 PM, Marek Vasut wrote:
> > > On 06/15/2018 12:37 PM, Ulrich Hecht wrote:
> > >> On Fri, Jun 15, 2018 at 12:09 PM, Marek Vasut wrote:
> > + arm_smccc_smc(ARM_SMCCC_RENESAS_MEMCONF,
> > + 0, 0, 0, 0, 0, 0, 0, );
> > >>>
> > >>> Will this call work on platforms without patched ATF ?
> > >>> (I think not, don't you need to handle return value?)
> > >>
> > >> I have not actually tested that, but if I understand the ATF code
> > >> correctly, unimplemented calls return
> > >> SMC_UNK (0x), which should be handled by the default case
> > >> (NOP)
> > >> below.
> > >
> > > Which means the board has a memory size of 0 and fails to boot ?
> > >
> > + switch (res.a0) {
> > + case 1:
> > + base[0] = 0x04800ULL;
> > + size[0] = 0x03800ULL;
> > + base[1] = 0x5ULL;
> > + size[1] = 0x04000ULL;
> > + base[2] = 0x6ULL;
> > + size[2] = 0x04000ULL;
> > + base[3] = 0x7ULL;
> > + size[3] = 0x04000ULL;
> > + fdt_fixup_memory_banks(blob, base, size, 4);
> > + break;
> > + case 2:
> > + base[0] = 0x04800ULL;
> > + size[0] = 0x07800ULL;
> > + base[1] = 0x5ULL;
> > + size[1] = 0x08000ULL;
> > + fdt_fixup_memory_banks(blob, base, size, 2);
> > + break;
> > + case 3:
> > + base[0] = 0x04800ULL;
> > + size[0] = 0x07800ULL;
> > + base[1] = 0x5ULL;
> > + size[1] = 0x08000ULL;
> > + base[2] = 0x6ULL;
> > + size[2] = 0x08000ULL;
> > + base[3] = 0x7ULL;
> > + size[3] = 0x08000ULL;
> > + fdt_fixup_memory_banks(blob, base, size, 4);
> > + break;
> > >>>
> > >>> Obvious design question is -- since you're adding new SMC call
> > >>> anyway,
> > >>> can't the call just return the memory layout table itself, so that
> > >>> it
> > >>> won't be duplicated both in U-Boot and ATF ?
> > >>
> > >> My gut feeling was to go with the smallest interface possible.
> > >
> > > But this doesn't scale. The API here uses some ad-hoc constants to
> > > identify memory layout tables which have to be encoded both in ATF and
> > > U-Boot, both of which must be kept in sync.
> > >
> > > The ATF already has those memory layout tables, it's only a matter of
> > > passing them to U-Boot. If you do just that, the ad-hoc constants and
> > > encoding of tables into U-Boot goes away and in fact simplifies the
> > > design.
> > >
> > > Yet, I have to wonder if ATF doesn't already contain some sort of
> > > standard SMC call to get memory topology. It surprises me that it
> > > wouldn't.
> >
> > In fact, Laurent (CCed) was solving some similar issue with lossy
> > decomp
> > and I think this involved some passing of memory layout information
> > from
> > ATF to U-Boot too, or am I mistaken ?
> > >>>
> > >>> That's correct, ATF stores information about the memory layout at a
> > >>> fixed
> > >>> address in system memory, and U-Boot can read it.
> > >>
> > >> Well, that sounds good ! Maybe we can avoid adding SMC call altogether
> > >> then? :)
> > >
> > > I'd prefer that, yes.
> > >
> > > Let's not duplicate the mechanism used to pass FCNL information from ATF
> > > to U- Boot, but instead create a data table format that can store all the
> > > information we need, in an easily extensible way.
> > >
> > > To see how the mechanism is implemented for FCNL, search for 47FD7000 in
> > > the Renesas ATF sources
> > > (git://github.com/renesas-rcar/arm-trusted-firmware.git).
> > For everyone involved, can you explain what FCNL is ? ;-)
>
> FCNL is Frame Compression Near Lossless. It's a way to reduce memory bandwidth
> by transparent
[U-Boot] [PATCH 2/6] reset: uniphier: sync reset data with Linux 4.18-rc1
Signed-off-by: Masahiro Yamada
---
drivers/reset/reset-uniphier.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/reset/reset-uniphier.c b/drivers/reset/reset-uniphier.c
index 657243a..39d684b 100644
--- a/drivers/reset/reset-uniphier.c
+++ b/drivers/reset/reset-uniphier.c
@@ -71,7 +71,7 @@ static const struct uniphier_reset_data
uniphier_ld20_sys_reset_data[] = {
UNIPHIER_RESETX(4, 0x200c, 2), /* eMMC */
UNIPHIER_RESETX(6, 0x200c, 6), /* ETHER */
UNIPHIER_RESETX(8, 0x200c, 8), /* STDMAC */
- UNIPHIER_RESETX(12, 0x200c, 5), /* GIO */
+ UNIPHIER_RESETX(14, 0x200c, 5), /* USB30 */
UNIPHIER_RESETX(16, 0x200c, 12),/* USB30-PHY0 */
UNIPHIER_RESETX(17, 0x200c, 13),/* USB30-PHY1 */
UNIPHIER_RESETX(18, 0x200c, 14),/* USB30-PHY2 */
@@ -85,10 +85,13 @@ static const struct uniphier_reset_data
uniphier_pxs3_sys_reset_data[] = {
UNIPHIER_RESETX(6, 0x200c, 9), /* ETHER0 */
UNIPHIER_RESETX(7, 0x200c, 10), /* ETHER1 */
UNIPHIER_RESETX(8, 0x200c, 12), /* STDMAC */
- UNIPHIER_RESETX(12, 0x200c, 5), /* USB30 (GIO0) */
- UNIPHIER_RESETX(13, 0x200c, 6), /* USB31 (GIO1) */
- UNIPHIER_RESETX(16, 0x200c, 16),/* USB30-PHY */
- UNIPHIER_RESETX(20, 0x200c, 17),/* USB31-PHY */
+ UNIPHIER_RESETX(12, 0x200c, 4), /* USB30 link */
+ UNIPHIER_RESETX(13, 0x200c, 5), /* USB31 link */
+ UNIPHIER_RESETX(16, 0x200c, 16),/* USB30-PHY0 */
+ UNIPHIER_RESETX(17, 0x200c, 18),/* USB30-PHY1 */
+ UNIPHIER_RESETX(18, 0x200c, 20),/* USB30-PHY2 */
+ UNIPHIER_RESETX(20, 0x200c, 17),/* USB31-PHY0 */
+ UNIPHIER_RESETX(21, 0x200c, 19),/* USB31-PHY1 */
UNIPHIER_RESET_END,
};
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] x86: qemu: do not build car.o with start64.o
Hi Heinrich,
On Tue, Jun 19, 2018 at 2:10 PM, Heinrich Schuchardt wrote:
> On 06/19/2018 04:37 AM, Bin Meng wrote:
>> Hi Heinrich,
>>
>> On Tue, Jun 12, 2018 at 11:50 PM, Heinrich Schuchardt
>> wrote:
>>> car.o can only be used with start.o, not with start64.o.
>>>
>>> So on qemu 64bit it should only be built for 32bit SPL but not for u-boot.
>>>
>>> Without this patch but with an unrelated pending patch
>>> ("x86: Add 64-bit setjmp/longjmp implementation") the
>>> following error occurred for qemu-x86_64_defconfig:
>>>
>>
>> I don't understand why Ivan's setmp/longjmp patch triggers this build
>> issue. Can you elaborate?
>
> Hello Bin,
>
> it was what I observed.
>
> As start.S calls car_init() but start_64.S does not the linker could
> eliminate car.o on x86_64. Why it does not eliminate it with the patch I
> do not know.
>
Thanks.
> But I still think that building car.o on 64bit does not make sense.
>
Yes, so please do the rebase and send v2. You can drop the commit
message mentioning Ivan's patch since it has not been applied.
Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/2] dm: mdio: add a uclass for MDIO
On Tue, Jun 12, 2018 at 11:33 PM, wrote: > From: Ken Ma > > Add a uclass which provides access to MDIO busses and includes > operations required by MDIO. > The implementation is based on the existing mii/phy/mdio data > structures and APIs. > This patch also adds evice tree binding for MDIO bus. > > Signed-off-by: Ken Ma > Reviewed-by: s...@chromium.org, joe.hershber...@ni.com A "Reviewed-by" indicates review + acceptance where the person listed is not a maintainer of said code. [1] It is not simply that it was commented on by the person. You should only include it in new versions of patches after someone has replied to a patch and included their "Reviewed-by" tag. It should be reproduced exactly as it was sent. There is no need to send a new version solely to include the tag, though. Patchwork will already take care of that for the current version. Also, the "Reviewed-by" should each be on their own line. [1] http://www.denx.de/wiki/U-Boot/Patches ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/2] dm: mdio: add a uclass for MDIO
On Tue, Jun 12, 2018 at 11:33 PM, wrote:
> From: Ken Ma
>
> Add a uclass which provides access to MDIO busses and includes
> operations required by MDIO.
> The implementation is based on the existing mii/phy/mdio data
> structures and APIs.
> This patch also adds evice tree binding for MDIO bus.
>
> Signed-off-by: Ken Ma
> Reviewed-by: s...@chromium.org, joe.hershber...@ni.com
> ---
>
> Changes in v3:
> - Move mdio uclass implementation to driver/net folder;
> - Replace flat-tree functions with livetree functions and update codes
> and comments to be consistent with driver-model codes style;
> - Put struct mii_dev to uclass platdata to avoid the mdio alloc and
> let driver model framework to alloc the memroy automatically,
> meanwhile the mii bus link initialization is added,
>
> Changes in v2: None
>
> MAINTAINERS | 1 +
> doc/device-tree-bindings/net/mdio-bus.txt | 54 ++
> drivers/Kconfig | 2 +
> drivers/net/Makefile | 1 +
> drivers/net/mdio/Kconfig | 18 +
> drivers/net/mdio/Makefile | 6 ++
> drivers/net/mdio/mdio-uclass.c| 112
> ++
> include/dm/uclass-id.h| 1 +
> include/net/mdio.h| 62 +
> 9 files changed, 257 insertions(+)
> create mode 100644 doc/device-tree-bindings/net/mdio-bus.txt
> create mode 100644 drivers/net/mdio/Kconfig
> create mode 100644 drivers/net/mdio/Makefile
> create mode 100644 drivers/net/mdio/mdio-uclass.c
> create mode 100644 include/net/mdio.h
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 642c448..9e1fc83 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -335,6 +335,7 @@ M: Simon Glass
I think it makes sense for me to maintain this, unless Simon really
wants it. He's not even Cc'ed, so maybe he doesn't know you are
assigning it to him? Adding him.
> S: Maintained
> T: git git://git.denx.de/u-boot-dm.git
> F: drivers/core/
> +F: drivers/net/mdio/
> F: include/dm/
> F: test/dm/
>
> diff --git a/doc/device-tree-bindings/net/mdio-bus.txt
> b/doc/device-tree-bindings/net/mdio-bus.txt
> new file mode 100644
> index 000..68d8b25
> --- /dev/null
> +++ b/doc/device-tree-bindings/net/mdio-bus.txt
Is it reasonable to use Documentation/devicetree/bindings/net/mdio.txt
from Linux?
> @@ -0,0 +1,54 @@
> +MDIO (Management Data Input/Output) busses
> +
> +MDIO busses can be described with a node for the MDIO master device
> +and a set of child nodes for each phy on the bus.
> +
> +The MDIO node requires the following properties:
> +- #address-cells - number of cells required to define phy address on
> +the MDIO bus.
> +- #size-cells - should be zero.
> +- compatible - name of MDIO bus controller following generic names
> +recommended practice.
> +- reg- address and length of the MDIO register.
> +
> +Optional property:
> +- mdio-name - MDIO bus name
> +
> +The child nodes of the MDIO driver are the individual PHY devices
> +connected to this MDIO bus. They must have a "reg" property given the
> +PHY address on the MDIO bus.
> +- reg - (required) phy address in MDIO bus.
> +
> +Example for cp110 MDIO node at the SoC level:
> + cp0_mdio: mdio@12a200 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "marvell,orion-mdio";
> + reg = <0x12a200 0x10>;
> + mdio-name = "cp0-mdio";
> + };
> +
> + cp0_xmdio: mdio@12a600 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "marvell,xmdio";
> + reg = <0x12a600 0x200>;
> + mdio-name = "cp0-xmdio";
> + };
> +
> +And at the board level, example for armada-8040-mcbin board:
> + _mdio {
> + ge_phy: ethernet-phy@0 {
> + reg = <0>;
> + };
> + };
> +
> + _xmdio {
> + phy0: ethernet-phy@0 {
> + reg = <0>;
> + };
> +
> + phy8: ethernet-phy@8 {
> + reg = <8>;
> + };
> + };
> diff --git a/drivers/Kconfig b/drivers/Kconfig
> index 9e21b28..0e0982c 100644
> --- a/drivers/Kconfig
> +++ b/drivers/Kconfig
> @@ -54,6 +54,8 @@ source "drivers/mtd/Kconfig"
>
> source "drivers/net/Kconfig"
>
> +source "drivers/net/mdio/Kconfig"
Seems like this should be in drivers/net/Kconfig.
> +
> source "drivers/nvme/Kconfig"
>
> source "drivers/pci/Kconfig"
> diff --git a/drivers/net/Makefile b/drivers/net/Makefile
> index 584bfdf..1cda03f 100644
> --- a/drivers/net/Makefile
> +++ b/drivers/net/Makefile
> @@ -70,3 +70,4 @@ obj-$(CONFIG_VSC9953) += vsc9953.o
> obj-$(CONFIG_PIC32_ETH) += pic32_mdio.o pic32_eth.o
> obj-$(CONFIG_DWC_ETH_QOS)
[U-Boot] [ANN] U-Boot v2018.07-rc2 released
Hey all, It's a day after when I had planned to release v2018.07-rc2, but here we are. The group of patches I applied earlier in the day took a bit longer to sort out, and that means I have a few more things I had hoped to apply still left to look at. I still think at this point we should focus on Kconfig migrations, fixes and dropping code that has reached it's "update or delete" by date. Things look on track for -rc3 on the 2nd and then release on July 9th. Thanks all! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] Make Menuconfig Error
Karsten Thanks for your lasts response. My apologies, I forget my yahoo email does not quite understand RFC email standards. Here's when I'm at with this version of u-boot. root@debian:/home/duncan/archive/u-boot# make clean root@debian:/home/duncan/archive/u-boot# make menuconfig HOSTCC scripts/basic/fixdep HOSTCC scripts/kconfig/mconf.o YACC scripts/kconfig/zconf.tab.c scripts/kconfig/zconf.y:44 parser name defined to default :"parse" "scripts/kconfig/zconf.y", line 97: junk after `%%' in definition section Segmentation fault scripts/Makefile.lib:228: recipe for target 'scripts/kconfig/zconf.tab.c' failed make[1]: *** [scripts/kconfig/zconf.tab.c] Error 139 Makefile:491: recipe for target 'menuconfig' failed make: *** [menuconfig] Error 2 root@debian:/home/duncan/archive/u-boot# Duncan Hare 714 931 7952 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v5 0/3] sunxi: fix eMMC stability issues on A64
On Mon, Jun 18, 2018 at 11:56 PM, Jagan Teki wrote: > > This what[1] I changed on top of your changes, same issue. > > [1] https://paste.ubuntu.com/p/NjYyMk68P6/ It should be tested separately. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] Makefile: Ensure we build with -std=gnu11
With the move to using at least gcc-6 for many targets we now have C code that requires the GNU11 C standard to be used in all cases. Signed-off-by: Tom Rini --- Makefile | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/Makefile b/Makefile index fe7bf11970b8..399c5a5b549d 100644 --- a/Makefile +++ b/Makefile @@ -263,8 +263,9 @@ HOSTCXXFLAGS = -O2 # Some Linux distributions (including RHEL7, SLES13, Debian 8) still # have older compilers as their default, so we make it explicit for # these that our host tools are GNU11 (i.e. C11 w/ GNU extensions). +CSTD_FLAG := -std=gnu11 ifeq ($(HOSTOS),linux) -HOSTCFLAGS += --std=gnu11 +HOSTCFLAGS += $(CSTD_FLAG) endif ifeq ($(HOSTOS),cygwin) @@ -370,7 +371,7 @@ KBUILD_CPPFLAGS := -D__KERNEL__ -D__UBOOT__ KBUILD_CFLAGS := -Wall -Wstrict-prototypes \ -Wno-format-security \ - -fno-builtin -ffreestanding + -fno-builtin -ffreestanding $(CSTD_FLAG) KBUILD_CFLAGS += -fshort-wchar KBUILD_AFLAGS := -D__ASSEMBLY__ -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] mtd: nand: denali: Replace the ad-hoc cache management with bouncebuf
On 06/19/2018 08:39 AM, Masahiro Yamada wrote: > Hi Marek, Hi, > 2018-06-08 5:17 GMT+09:00 Marek Vasut : >> Replace the ad-hoc DMA cache management functions with common bouncebuf, >> since those functions are not handling cases where unaligned buffer is >> passed in, > > > Were you hit by a problem, > or just-in-case replacement? Yes, UBI triggers unaligned cache operations on my system (SoCFPGA). > I thought I took care of the buffer alignment. > > The bounce buffer is allocated by kmalloc(): > https://github.com/u-boot/u-boot/blob/v2018.05/drivers/mtd/nand/denali.c#L1348 > > According to the lib/linux_compat.c implementation, > it returns memory aligned with ARCH_DMA_MINALIGN. > > > If the buffer is passed from the upper MTD layer, > the NAND core also makes sure the enough alignment: > https://github.com/u-boot/u-boot/blob/v2018.05/drivers/mtd/nand/denali.c#L1273 > > This is how this driver works in Linux. > > I'd rather want to keep the current code > unless this is a real problem, > > > One possible clean-up is to move dma_(un)map_single to a common place. Is there any chance you can try UBI on the denali nand on uniphier ? :) -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PULL] u-boot-sh/master
he following changes since commit 378b29cbc6607ad8246b1381bc74ec62bdb19105:
Merge git://git.denx.de/u-boot-x86 (2018-06-18 12:59:46 -0400)
are available in the Git repository at:
git://git.denx.de/u-boot-sh.git master
for you to fetch changes up to 2c84d5218e7e379dce493080a01938530b477611:
ARM: dts: rmobile: Add HS200 support to E3 Ebisu (2018-06-19 06:15:55
+0200)
Marek Vasut (9):
pinctrl: renesas: Fix register usage in sh_pfc_{read,write}
ARM: rmobile: Adjust text base on V3M Eagle
ARM: dts: rmobile: Move the PHY reset GPIO back
net: ravb: Do not shut down clock in start callback
net: ravb: Filter out supported PHY features
net: ravb: Support reset GPIO both in mac and phy node
net: sh_eth: Support reset GPIO both in mac and phy node
ARM: dts: rmobile: Move the PHY reset GPIOs into PHY nodes
ARM: dts: rmobile: Add HS200 support to E3 Ebisu
arch/arm/dts/r8a77970-eagle.dts | 2 +-
arch/arm/dts/r8a77990-ebisu.dts | 38
++
configs/r8a77970_eagle_defconfig | 2 +-
drivers/net/ravb.c | 32 +++-
drivers/net/sh_eth.c | 13 +++--
drivers/pinctrl/renesas/pfc.c| 4 ++--
6 files changed, 72 insertions(+), 19 deletions(-)
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC] ARM: rmobile: create DT memory nodes for R8A7795 3.0 and newer
On 06/19/2018 09:11 AM, Laurent Pinchart wrote: > Hi Geert, > > On Tuesday, 19 June 2018 09:58:59 EEST Geert Uytterhoeven wrote: >> On Tue, Jun 19, 2018 at 4:15 AM Laurent Pinchart wrote: >>> On Sunday, 17 June 2018 03:08:02 EEST Marek Vasut wrote: On 06/16/2018 05:44 PM, Laurent Pinchart wrote: > On Saturday, 16 June 2018 02:42:30 EEST Marek Vasut wrote: >> On 06/16/2018 01:21 AM, Laurent Pinchart wrote: >>> On Friday, 15 June 2018 15:00:31 EEST Marek Vasut wrote: On 06/15/2018 01:43 PM, Marek Vasut wrote: > > [snip] > >>> Obvious design question is -- since you're adding new SMC call >>> anyway, can't the call just return the memory layout table >>> itself, so that it won't be duplicated both in U-Boot and ATF ? >> >> My gut feeling was to go with the smallest interface possible. > > But this doesn't scale. The API here uses some ad-hoc constants to > identify memory layout tables which have to be encoded both in ATF > and U-Boot, both of which must be kept in sync. > > The ATF already has those memory layout tables, it's only a matter > of passing them to U-Boot. If you do just that, the ad-hoc > constants and encoding of tables into U-Boot goes away and in fact > simplifies the design. > > Yet, I have to wonder if ATF doesn't already contain some sort of > standard SMC call to get memory topology. It surprises me that it > wouldn't. In fact, Laurent (CCed) was solving some similar issue with lossy decomp and I think this involved some passing of memory layout information from ATF to U-Boot too, or am I mistaken ? >>> >>> That's correct, ATF stores information about the memory layout at a >>> fixed address in system memory, and U-Boot can read it. >> >> Well, that sounds good ! Maybe we can avoid adding SMC call >> altogether then? :) > > I'd prefer that, yes. > > Let's not duplicate the mechanism used to pass FCNL information from > ATF to U- Boot, but instead create a data table format that can store > all the information we need, in an easily extensible way. > > To see how the mechanism is implemented for FCNL, search for 47FD7000 > in the Renesas ATF sources > (git://github.com/renesas-rcar/arm-trusted-firmware.git). For everyone involved, can you explain what FCNL is ? ;-) >>> >>> FCNL is Frame Compression Near Lossless. It's a way to reduce memory >>> bandwidth by transparent compression and decompression of video frames. >>> Compression is handled by an IP core called FCP, and decompression is >>> handled by the DRAM controller. ATF programs the DRAM controller with >>> ranges of memory addresses that will be dynamically decompressed. The >>> registers containing those ranges are accessible in secure mode only, so >>> neither U-Boot nor Linux can read them. That's why ATF has to pass the >>> information to U-Boot, in order to add the ranges as reserved memory in >>> DT. >>> Any yes, I agree this sounds good. I had a discussion on the U-Boot IRC about passing the memory configuration around and the result is basically the same -- pass a table from ATF to U-Boot. If there's already something, great. >> >> Pass a "table"? Or an FDT containing the /memory nodes? >> The latter allows for easier future extension. > > ATF passes a table to U-Boot, and U-Boot then updates the FDT accordingly > before starting Linux. At this point, U-Boot does not parse any such table. It could be some fork does that, but mainline does not. But that code could (and probably should) be added. I don't think ATF has FDT support, but I might be wrong. And if ATF can pass DT fragment or some simple DT, that'd be neat. -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v5 0/3] sunxi: fix eMMC stability issues on A64
On Tue, Jun 19, 2018 at 11:55 AM, Vasily Khoruzhick wrote: > On Mon, Jun 18, 2018 at 12:43 AM, Jagan Teki wrote: >> >> Don't have these hardware with me. > > Could you test this patch on your hardware when you get some time? > > https://github.com/anarsoul/u-boot-pine64/commit/a3f5d175a5ed0ece7a7720f1e665809c9f140850.patch On top of your changes or separately? ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] mmc: Parse HS400 DT properties
On 19/06/2018 06:23, Marek Vasut wrote: Add HS400 properties parsing support to mmc_of_parse(). Signed-off-by: Marek Vasut Cc: Bin Meng Cc: Jaehoon Chung Cc: Jean-Jacques Hiblot Cc: Kishon Vijay Abraham I Cc: Peng Fan Cc: Simon Glass --- drivers/mmc/mmc-uclass.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/mmc/mmc-uclass.c b/drivers/mmc/mmc-uclass.c index f73f07254b..76225b7939 100644 --- a/drivers/mmc/mmc-uclass.c +++ b/drivers/mmc/mmc-uclass.c @@ -166,6 +166,10 @@ int mmc_of_parse(struct udevice *dev, struct mmc_config *cfg) cfg->host_caps |= MMC_CAP(MMC_HS_200); if (dev_read_bool(dev, "mmc-hs200-1_2v")) cfg->host_caps |= MMC_CAP(MMC_HS_200); + if (dev_read_bool(dev, "mmc-hs400-1_8v")) + cfg->host_caps |= MMC_CAP(MMC_HS_400); + if (dev_read_bool(dev, "mmc-hs400-1_2v")) + cfg->host_caps |= MMC_CAP(MMC_HS_400); return 0; } Reviewed-by: Jean-Jacques ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v5 0/3] sunxi: fix eMMC stability issues on A64
On Mon, Jun 18, 2018 at 12:43 AM, Jagan Teki wrote: > > Don't have these hardware with me. Could you test this patch on your hardware when you get some time? https://github.com/anarsoul/u-boot-pine64/commit/a3f5d175a5ed0ece7a7720f1e665809c9f140850.patch It uses calibration without using new clock mode and it fixes eMMC on Pinebook for me as well. Also works fine on Pine64-LTS. If it works for you I'll clean it up and send it out. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] mtd: nand: denali: Replace the ad-hoc cache management with bouncebuf
Hi Marek,
2018-06-08 5:17 GMT+09:00 Marek Vasut :
> Replace the ad-hoc DMA cache management functions with common bouncebuf,
> since those functions are not handling cases where unaligned buffer is
> passed in,
Were you hit by a problem,
or just-in-case replacement?
I thought I took care of the buffer alignment.
The bounce buffer is allocated by kmalloc():
https://github.com/u-boot/u-boot/blob/v2018.05/drivers/mtd/nand/denali.c#L1348
According to the lib/linux_compat.c implementation,
it returns memory aligned with ARCH_DMA_MINALIGN.
If the buffer is passed from the upper MTD layer,
the NAND core also makes sure the enough alignment:
https://github.com/u-boot/u-boot/blob/v2018.05/drivers/mtd/nand/denali.c#L1273
This is how this driver works in Linux.
I'd rather want to keep the current code
unless this is a real problem,
One possible clean-up is to move dma_(un)map_single to a common place.
> while common bouncebuf does handle all that.
>
> Signed-off-by: Marek Vasut
> Cc: Masahiro Yamada
> Cc: Tom Rini
> ---
> drivers/mtd/nand/denali.c | 41 +++--
> 1 file changed, 7 insertions(+), 34 deletions(-)
>
> diff --git a/drivers/mtd/nand/denali.c b/drivers/mtd/nand/denali.c
> index 089ebce6dd..e5e84a58aa 100644
> --- a/drivers/mtd/nand/denali.c
> +++ b/drivers/mtd/nand/denali.c
> @@ -5,6 +5,7 @@
> * Copyright (C) 2009-2010, Intel Corporation and its suppliers.
> */
>
> +#include
> #include
> #include
> #include
> @@ -16,31 +17,6 @@
>
> #include "denali.h"
>
> -static dma_addr_t dma_map_single(void *dev, void *ptr, size_t size,
> -enum dma_data_direction dir)
> -{
> - unsigned long addr = (unsigned long)ptr;
> -
> - if (dir == DMA_FROM_DEVICE)
> - invalidate_dcache_range(addr, addr + size);
> - else
> - flush_dcache_range(addr, addr + size);
> -
> - return addr;
> -}
> -
> -static void dma_unmap_single(void *dev, dma_addr_t addr, size_t size,
> -enum dma_data_direction dir)
> -{
> - if (dir != DMA_TO_DEVICE)
> - invalidate_dcache_range(addr, addr + size);
> -}
> -
> -static int dma_mapping_error(void *dev, dma_addr_t addr)
> -{
> - return 0;
> -}
> -
> #define DENALI_NAND_NAME"denali-nand"
>
> /* for Indexed Addressing */
> @@ -563,16 +539,12 @@ static int denali_pio_xfer(struct denali_nand_info
> *denali, void *buf,
> static int denali_dma_xfer(struct denali_nand_info *denali, void *buf,
>size_t size, int page, int raw, int write)
> {
> - dma_addr_t dma_addr;
> uint32_t irq_mask, irq_status, ecc_err_mask;
> - enum dma_data_direction dir = write ? DMA_TO_DEVICE : DMA_FROM_DEVICE;
> + unsigned int bbflags = write ? GEN_BB_READ : GEN_BB_WRITE;
> + struct bounce_buffer bbstate;
> int ret = 0;
>
> - dma_addr = dma_map_single(denali->dev, buf, size, dir);
> - if (dma_mapping_error(denali->dev, dma_addr)) {
> - dev_dbg(denali->dev, "Failed to DMA-map buffer. Trying
> PIO.\n");
> - return denali_pio_xfer(denali, buf, size, page, raw, write);
> - }
> + bounce_buffer_start(, buf, size, bbflags);
>
> if (write) {
> /*
> @@ -593,7 +565,8 @@ static int denali_dma_xfer(struct denali_nand_info
> *denali, void *buf,
> iowrite32(DMA_ENABLE__FLAG, denali->reg + DMA_ENABLE);
>
> denali_reset_irq(denali);
> - denali->setup_dma(denali, dma_addr, page, write);
> + denali->setup_dma(denali, virt_to_phys(bbstate.bounce_buffer),
> + page, write);
>
> irq_status = denali_wait_for_irq(denali, irq_mask);
> if (!(irq_status & INTR__DMA_CMD_COMP))
> @@ -603,7 +576,7 @@ static int denali_dma_xfer(struct denali_nand_info
> *denali, void *buf,
>
> iowrite32(0, denali->reg + DMA_ENABLE);
>
> - dma_unmap_single(denali->dev, dma_addr, size, dir);
> + bounce_buffer_stop();
>
> if (irq_status & INTR__ERASED_PAGE)
> memset(buf, 0xff, size);
> --
> 2.16.2
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
--
Best Regards
Masahiro Yamada
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v6 0/7] sunxi: sync H3, H5, A64 DTs from mainline Linux
On Wed, May 16, 2018 at 1:30 PM, Andre Przywara wrote: > This is an updated version of the series which brings the exact mainline > Linux device tree files for various Allwinner boards into U-Boot. > Apart from using the usually more correct reference DT files, this offers > the big benefit of being able to use U-Boot's DT copy for directly passing > it to the kernel. This avoids to actually load a .dtb file from somewhere, > and allows seamless and automatic UEFI booting, so distribution installer > images should just work (TM). > > This cover the ARMv8 SoCs (H5, A64), but also all boards with the H3, as > this is somewhat married to the H5 and can only be updated together. > The H3 and H5 DT files have diverged quite a bit, but as U-Boot's own > usage of the DT is (yet) quite limited, there should be no regressions. > The patches are split to first update the SoC .dtsi file, then the board > .dts files in a second patch. They are grouped to handle the A64 first, > then the H5 and H3. I put the respective kernel commit IDs in the commit > messages. > Patch 6 brings in the mainline DT for the SoPine baseboard, for which we > didn't have a separate .dts in U-Boot so far. > Patch 7 adds a separate .dts file for the Pine64-LTS board, which is > virtually identical to the SoPine baseboard, but, due to the SoC being > named differently, deserves a separate file. > > This is based on origin/master (ca70cbabdcd1). > > Maxime, I kept you Acked-by: from the previous posts, as I literally > just updated to the latest Linux master, which went through your review > anyway. Hope that's OK for you. > > Cheers, > Andre. > > Changelog v5 .. v6: > - bring back DT update patches > - update to Linux v4.17-rc5 > > Changelog v4 .. v5: > - drop Linux DT update patches for now > - fix minor checkpatch complaints > > Changelog v3 .. v4: > - remove MMC environment for all Allwinner boards (including 32 bit ones) > - keep MMC environment offset to the old values > - drop DT adjustments to use fixed MMC regulator > > Changelog v2 .. v3: > 01: added, was on the list before > 02: drop redundant H5 line > 03-08: unchanged > 09-20: added > > Changelog v1 .. v2: > 01, 02, 03: unchanged > 04, 05, 06, 07: added > > Andre Przywara (7): > sunxi: DT: A64: update device tree file for Allwinner A64 SoC > sunxi: DT: A64: update board .dts files from Linux > sunxi: DT: update device tree files for Allwinner H3 and H5 SoCs > sunxi: DT: H5: update board .dts files from Linux > sunxi: DT: H3: update board .dts files from Linux > sunxi: DT: A64: add proper SoPine baseboard device tree Reviewed-by: Jagan Teki Please rebase on master and send, files from A64, H5 and H3 has changed a bit. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] U-Boot TFTP protection
Hi Stefan, > Hello, > We have been looking at protecting U-Boot from (malicious) TFTP > overwrites. We want to do this after our ARMv7 U-Boot has relocated. > > The memory map looks like this (I hope): > > --- Top of DRAM > | U-Boot (Protected) > | -- U_Boot_start > | Heap (Protected) > | -- Start_Heap = U_Boot_start - Heap_Size > | Stack (Protected) > | -- Start_Stack = Start_Heap - Stack_Size > | Buffers (Protected) > | -- ??? > | Free DRAM (Not Protected) > --- Start of DRAM > > I seem to get lost in the code trying to find possible buffers, can > you please give a hint how I can find the address "???" By default the tftp writes its data to the address pointed by the "loadaddr" env variable. printenv loadaddr > > Best Regards, > Stefan > > ___ > U-Boot mailing list > U-Boot@lists.denx.de > https://lists.denx.de/listinfo/u-boot Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de pgp7YYkFCGuxY.pgp Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] x86: Add 64-bit setjmp/longjmp implementation
Hi Ivan,
On Thu, Jun 7, 2018 at 2:28 AM, Ivan Gorinov wrote:
> Add setjmp/longjmp functions for x86_64.
> The FPU control word and MXCSR control bits are preserved across calls.
>
> Signed-off-by: Ivan Gorinov
> ---
> arch/x86/cpu/x86_64/setjmp.S | 66
> +++
> arch/x86/cpu/x86_64/setjmp.c | 19 -
> arch/x86/include/asm/setjmp.h | 19 +
> 3 files changed, 85 insertions(+), 19 deletions(-)
> create mode 100644 arch/x86/cpu/x86_64/setjmp.S
> delete mode 100644 arch/x86/cpu/x86_64/setjmp.c
>
> diff --git a/arch/x86/cpu/x86_64/setjmp.S b/arch/x86/cpu/x86_64/setjmp.S
> new file mode 100644
> index 000..ef61a4a
> --- /dev/null
> +++ b/arch/x86/cpu/x86_64/setjmp.S
> @@ -0,0 +1,66 @@
> +/*
> + * Copyright (C) 2018 Intel Corporation
> + *
> + * SPDX-License-Identifier: GPL-2.0+
This line should be put at the first line of this file, otherwise it
causes checkpatch to report warnings.
> + *
> + * See arch/x86/include/asm/setjmp.h for jmp_buf format
> + */
> +
> +#include
> +
> +.text
> +.align 8
> +
> +ENTRY(setjmp)
> +
> + pop %rcx
> + movq%rcx, (%rdi)/* Return address */
> + movq%rsp, 8 (%rdi)
nits: can we eliminate the space between 8 and (%edi)? and others in
this file too?
> + movq%rbp, 16 (%rdi)
> + movq%rbx, 24 (%rdi)
> + movq%r12, 32 (%rdi)
> + movq%r13, 40 (%rdi)
> + movq%r14, 48 (%rdi)
> + movq%r15, 56 (%rdi)
> + fnstcw 64 (%rdi)
> + stmxcsr 68 (%rdi)
I don't think we need worry about these FP registers as U-Boot does
not enable them at all. It looks your v1 patch does not include this
but was added in v2. See the 32-bit setjmp/longjmp() implementation in
U-Boot and there is no FP save/restore too.
> + xorq%rax, %rax /* Direct invocation returns 0 */
> + jmpq*%rcx
> +
> +ENDPROC(setjmp)
> +
> +.align 8
> +
> +ENTRY(longjmp)
> +
> + subq$8, %rsp
> +
> +/* Restore the control bits of MXCSR */
nits: comment indention should align to the assembly code
> +
> + stmxcsr (%rsp)
> + movl$0x3f, %eax
> + andl%eax, (%rsp)
> + notl%eax
> + andl68 (%rdi), %eax
> + orl %eax, (%rsp)
> + ldmxcsr (%rsp)
> +
> + fldcw 64 (%rdi)
> +
> + movq(%rdi), %rcx/* Return address */
> + movq8 (%rdi), %rsp
> + movq16 (%rdi), %rbp
> + movq24 (%rdi), %rbx
> + movq32 (%rdi), %r12
> + movq40 (%rdi), %r13
> + movq48 (%rdi), %r14
> + movq56 (%rdi), %r15
> +
> + movq%rsi, %rax /* Value to be returned by setjmp() */
> + testq %rax, %rax /* cannot be 0 in this case */
> + jnz 1f
> + incq%rax/* Return 1 instead */
> +1:
> + jmpq*%rcx
> +
> +ENDPROC(longjmp)
> diff --git a/arch/x86/cpu/x86_64/setjmp.c b/arch/x86/cpu/x86_64/setjmp.c
> deleted file mode 100644
> index 5d4a74a..000
> --- a/arch/x86/cpu/x86_64/setjmp.c
> +++ /dev/null
> @@ -1,19 +0,0 @@
> -// SPDX-License-Identifier: GPL-2.0+
> -/*
> - * Copyright (c) 2016 Google, Inc
> - */
> -
> -#include
> -#include
> -
> -int setjmp(struct jmp_buf_data *jmp_buf)
> -{
> - printf("WARNING: setjmp() is not supported\n");
> -
> - return 0;
> -}
> -
> -void longjmp(struct jmp_buf_data *jmp_buf, int val)
> -{
> - printf("WARNING: longjmp() is not supported\n");
> -}
> diff --git a/arch/x86/include/asm/setjmp.h b/arch/x86/include/asm/setjmp.h
> index f25975f..eae33fb 100644
> --- a/arch/x86/include/asm/setjmp.h
> +++ b/arch/x86/include/asm/setjmp.h
> @@ -8,6 +8,23 @@
> #ifndef __setjmp_h
> #define __setjmp_h
>
> +#ifdef CONFIG_X86_64
> +
> +struct jmp_buf_data {
> + unsigned long __rip;
> + unsigned long __rsp;
> + unsigned long __rbp;
> + unsigned long __rbx;
> + unsigned long __r12;
> + unsigned long __r13;
> + unsigned long __r14;
> + unsigned long __r15;
> + unsigned int __fcw;
> + unsigned int __mxcsr;
> +};
> +
> +#else
> +
> struct jmp_buf_data {
> unsigned int __ebx;
> unsigned int __esp;
> @@ -17,6 +34,8 @@ struct jmp_buf_data {
> unsigned int __eip;
> };
>
> +#endif
> +
> int setjmp(struct jmp_buf_data *jmp_buf);
> void longjmp(struct jmp_buf_data *jmp_buf, int val);
>
> --
Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v6 0/7] sunxi: sync H3, H5, A64 DTs from mainline Linux
Hi, On 19/06/18 07:40, Jagan Teki wrote: > On Wed, May 16, 2018 at 1:30 PM, Andre Przywara > wrote: >> This is an updated version of the series which brings the exact mainline >> Linux device tree files for various Allwinner boards into U-Boot. >> Apart from using the usually more correct reference DT files, this offers >> the big benefit of being able to use U-Boot's DT copy for directly passing >> it to the kernel. This avoids to actually load a .dtb file from somewhere, >> and allows seamless and automatic UEFI booting, so distribution installer >> images should just work (TM). >> >> This cover the ARMv8 SoCs (H5, A64), but also all boards with the H3, as >> this is somewhat married to the H5 and can only be updated together. >> The H3 and H5 DT files have diverged quite a bit, but as U-Boot's own >> usage of the DT is (yet) quite limited, there should be no regressions. >> The patches are split to first update the SoC .dtsi file, then the board >> .dts files in a second patch. They are grouped to handle the A64 first, >> then the H5 and H3. I put the respective kernel commit IDs in the commit >> messages. >> Patch 6 brings in the mainline DT for the SoPine baseboard, for which we >> didn't have a separate .dts in U-Boot so far. >> Patch 7 adds a separate .dts file for the Pine64-LTS board, which is >> virtually identical to the SoPine baseboard, but, due to the SoC being >> named differently, deserves a separate file. >> >> This is based on origin/master (ca70cbabdcd1). >> >> Maxime, I kept you Acked-by: from the previous posts, as I literally >> just updated to the latest Linux master, which went through your review >> anyway. Hope that's OK for you. >> >> Cheers, >> Andre. >> >> Changelog v5 .. v6: >> - bring back DT update patches >> - update to Linux v4.17-rc5 >> >> Changelog v4 .. v5: >> - drop Linux DT update patches for now >> - fix minor checkpatch complaints >> >> Changelog v3 .. v4: >> - remove MMC environment for all Allwinner boards (including 32 bit ones) >> - keep MMC environment offset to the old values >> - drop DT adjustments to use fixed MMC regulator >> >> Changelog v2 .. v3: >> 01: added, was on the list before >> 02: drop redundant H5 line >> 03-08: unchanged >> 09-20: added >> >> Changelog v1 .. v2: >> 01, 02, 03: unchanged >> 04, 05, 06, 07: added >> >> Andre Przywara (7): >> sunxi: DT: A64: update device tree file for Allwinner A64 SoC >> sunxi: DT: A64: update board .dts files from Linux >> sunxi: DT: update device tree files for Allwinner H3 and H5 SoCs >> sunxi: DT: H5: update board .dts files from Linux >> sunxi: DT: H3: update board .dts files from Linux >> sunxi: DT: A64: add proper SoPine baseboard device tree > > Reviewed-by: Jagan Teki Thanks! > Please rebase on master and send, files from A64, H5 and H3 has changed a bit. Yes, I rebased already on Sunday against 4.18-rc1. There is an issue with the recent sunxi USB changes in U-Boot, as these patches here now enable all USB controllers, which U-Boot apparently doesn't like. Will debug this and then send ASAP. Cheers, Andre. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC PATCH] fpga: zynq: Add encrypted bitstream support with auto detect
Hi Stefan,
Yes, I checked and it looks fine functionally, I even tested it. Otherthan
this, I have few comments on this which I am going to reply to your RFC patch
mail.
Thanks,
Siva
> -Original Message-
> From: Siva Durga Prasad Paladugu
> Sent: Tuesday, June 12, 2018 9:18 AM
> To: stefan.herbrechtsme...@weidmueller.com;
> ste...@herbrechtsmeier.net
> Cc: u-boot@lists.denx.de; michal.si...@xilinx.com; mon...@monstr.eu
> Subject: RE: [RFC PATCH] fpga: zynq: Add encrypted bitstream support with
> auto detect
>
> Hi Stefan,
>
> > -Original Message-
> > From: stefan.herbrechtsme...@weidmueller.com
> > [mailto:stefan.herbrechtsme...@weidmueller.com]
> > Sent: Monday, June 11, 2018 9:33 PM
> > To: Siva Durga Prasad Paladugu ;
> > ste...@herbrechtsmeier.net
> > Cc: u-boot@lists.denx.de; michal.si...@xilinx.com; mon...@monstr.eu
> > Subject: AW: [RFC PATCH] fpga: zynq: Add encrypted bitstream support
> > with auto detect
> >
> > Hi Siva,
> >
> > > -Ursprüngliche Nachricht-
> > > Von: Siva Durga Prasad Paladugu [mailto:siva...@xilinx.com]
> > > Gesendet: Montag, 11. Juni 2018 13:40
> > > An: ste...@herbrechtsmeier.net
> > > Cc: Herbrechtsmeier Dr.-Ing. , Stefan
> > > ; u-boot@lists.denx.de;
> > Michal
> > > Simek ; mon...@monstr.eu
> > > Betreff: RE: [RFC PATCH] fpga: zynq: Add encrypted bitstream support
> > > with auto detect
> > >
> > > Interesting, I got your point. First of all, Could you please let
> > > me know on how do you created the encrypted bitstream?
> >
> > I use bootgen with the split option and the following bif file:
> >
> > bootgen -image u-boot-spl-aes.bif -o i u-boot-spl-aes.bin -w on
> > -encrypt efuse -split bin
> >
> > image:
> > {
> > [aeskeyfile]efuse.nky
> > [pskfile]psk.pem
> > [sskfile]ssk.pem
> > [bootloader, encryption=aes, authentication=rsa]u-boot-spl.elf
> > [encryption=aes]fpga.bit
> > }
> >
> > > I hope this is not the Xilinx bootgen flow(may be through other
> > > Xilinx
> > > flow)
> >
> > To my knowledge you could only use bootgen because Xilinx doesn't
> > documented the encryption even if I would like to integrate the
> > encryption into mkimage.
> >
> > > because, I don't think bootgen will update these fields while
> > > creating encrypted bitstream( need to re confirm on this) and my
> > > flow targets the Xilinx bootgen flow.
> >
> > This fields are part of the encrypted binary bitstream and are needed
> > for the fpga configuration via the pcap. They are documented inside
> > the 'ug470_7Series_Config.pdf'.
> >
> > > Please let know your comments on this, based on which, will try to
> > > review and test your patch.
> >
> > Let me know if you need more information or help.
>
> Thanks for the clarity, let me check on it and come back.
> Let me also look in to modify secure patch if required as per this.
>
> Thanks,
> Siva
>
> >
> > Regards
> >
> > Stefan Herbrechtsmeier
> > Software Developer Embedded Systems
> >
> > Weidmüller - Your partner in Industrial Connectivity We look forward
> > to sharing ideas with you - Let's connect.
> >
> > Weidmueller Interface GmbH & Co. KG
> > Klingenbergstraße 16, 32758 Detmold, Germany
> > Email: stefan.herbrechtsme...@weidmueller.com - Web:
> > www.weidmueller.com
> >
> >
> >
> > Kommanditgesellschaft - Sitz: Detmold - Amtsgericht Lemgo HRA 2790 -
> > Komplementärin: Weidmüller Interface Führungsgesellschaft mbH -
> > Sitz: Detmold - Amtsgericht Lemgo HRB 3924;
> > Geschäftsführer: José Carlos Álvarez Tobar, Elke Eckstein, Jörg
> > Timmermann; USt-ID-Nr. DE124599660
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 0/6] ARM: uniphier: some more updates for v2018.07-rc2
Masahiro Yamada (6): ARM: uniphier: enable CONFIG_SNI_AVE and disable CONFIG_SMC911X reset: uniphier: sync reset data with Linux 4.18-rc1 serial: uniphier: rename struct uniphier_serial_private_data serial: uniphier: set clock rate without clock-frequency property ARM: dts: uniphier: sync DT with Linux 4.18-rc1 ARM: dts: uniphier: enable SD card for PXs3 reference board arch/arm/dts/uniphier-ld11.dtsi| 4 --- arch/arm/dts/uniphier-ld20.dtsi| 4 --- arch/arm/dts/uniphier-ld4.dtsi | 4 --- arch/arm/dts/uniphier-pro4.dtsi| 6 + arch/arm/dts/uniphier-pro5.dtsi| 4 --- arch/arm/dts/uniphier-pxs2.dtsi| 4 --- arch/arm/dts/uniphier-pxs3-ref.dts | 4 +++ arch/arm/dts/uniphier-pxs3.dtsi| 4 --- arch/arm/dts/uniphier-sld8.dtsi| 4 --- configs/uniphier_v7_defconfig | 6 ++--- configs/uniphier_v8_defconfig | 6 ++--- drivers/reset/reset-uniphier.c | 13 ++ drivers/serial/serial_uniphier.c | 51 -- 13 files changed, 60 insertions(+), 54 deletions(-) -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 6/6] ARM: dts: uniphier: enable SD card for PXs3 reference board
Signed-off-by: Masahiro Yamada
---
arch/arm/dts/uniphier-pxs3-ref.dts | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/dts/uniphier-pxs3-ref.dts
b/arch/arm/dts/uniphier-pxs3-ref.dts
index 3b9931a..4fb12b8 100644
--- a/arch/arm/dts/uniphier-pxs3-ref.dts
+++ b/arch/arm/dts/uniphier-pxs3-ref.dts
@@ -75,6 +75,10 @@
status = "okay";
};
+ {
+ status = "okay";
+};
+
{
status = "okay";
phy-handle = <>;
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 3/6] serial: uniphier: rename struct uniphier_serial_private_data
Just for making it shorter.
Signed-off-by: Masahiro Yamada
---
drivers/serial/serial_uniphier.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/serial/serial_uniphier.c b/drivers/serial/serial_uniphier.c
index 8878079..b06fc00 100644
--- a/drivers/serial/serial_uniphier.c
+++ b/drivers/serial/serial_uniphier.c
@@ -33,17 +33,17 @@ struct uniphier_serial {
u32 dlr;/* Divisor Latch Register */
};
-struct uniphier_serial_private_data {
+struct uniphier_serial_priv {
struct uniphier_serial __iomem *membase;
unsigned int uartclk;
};
#define uniphier_serial_port(dev) \
- ((struct uniphier_serial_private_data *)dev_get_priv(dev))->membase
+ ((struct uniphier_serial_priv *)dev_get_priv(dev))->membase
static int uniphier_serial_setbrg(struct udevice *dev, int baudrate)
{
- struct uniphier_serial_private_data *priv = dev_get_priv(dev);
+ struct uniphier_serial_priv *priv = dev_get_priv(dev);
struct uniphier_serial __iomem *port = uniphier_serial_port(dev);
const unsigned int mode_x_div = 16;
unsigned int divisor;
@@ -90,7 +90,7 @@ static int uniphier_serial_pending(struct udevice *dev, bool
input)
static int uniphier_serial_probe(struct udevice *dev)
{
DECLARE_GLOBAL_DATA_PTR;
- struct uniphier_serial_private_data *priv = dev_get_priv(dev);
+ struct uniphier_serial_priv *priv = dev_get_priv(dev);
struct uniphier_serial __iomem *port;
fdt_addr_t base;
u32 tmp;
@@ -133,6 +133,6 @@ U_BOOT_DRIVER(uniphier_serial) = {
.id = UCLASS_SERIAL,
.of_match = uniphier_uart_of_match,
.probe = uniphier_serial_probe,
- .priv_auto_alloc_size = sizeof(struct uniphier_serial_private_data),
+ .priv_auto_alloc_size = sizeof(struct uniphier_serial_priv),
.ops = _serial_ops,
};
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 4/6] serial: uniphier: set clock rate without clock-frequency property
In Linux, the clock rate of the UART is given by the clock driver.
If you try to follow that in U-Boot, you would end up with adding
more u-boot,dm-pre-reloc properties, and also the clock driver would
be too big for SPL, which is used for UniPhier ARMv7 platform.
The current solution is to add 'clock-frequency' property to the
UART nodes, but it does not exist in the DT files in Linux. I do
not want to let DT diverge for U-Boot.
Check the SoC compatible and set the clock rate according to it.
This will be helpful to sync DT between Linux and U-Boot.
Signed-off-by: Masahiro Yamada
---
drivers/serial/serial_uniphier.c | 41 +---
1 file changed, 38 insertions(+), 3 deletions(-)
diff --git a/drivers/serial/serial_uniphier.c b/drivers/serial/serial_uniphier.c
index b06fc00..c7f46e5 100644
--- a/drivers/serial/serial_uniphier.c
+++ b/drivers/serial/serial_uniphier.c
@@ -7,6 +7,7 @@
#include
#include
+#include
#include
#include
#include
@@ -87,11 +88,34 @@ static int uniphier_serial_pending(struct udevice *dev,
bool input)
return !(readl(>lsr) & UART_LSR_THRE);
}
+/*
+ * SPL does not have enough memory footprint for the clock driver.
+ * Hardcode clock frequency for each SoC.
+ */
+struct uniphier_serial_clk_data {
+ const char *compatible;
+ unsigned int clk_rate;
+};
+
+static const struct uniphier_serial_clk_data uniphier_serial_clk_data[] = {
+ { .compatible = "socionext,uniphier-ld4", .clk_rate = 36864000 },
+ { .compatible = "socionext,uniphier-pro4", .clk_rate = 73728000 },
+ { .compatible = "socionext,uniphier-sld8", .clk_rate = 8000 },
+ { .compatible = "socionext,uniphier-pro5", .clk_rate = 73728000 },
+ { .compatible = "socionext,uniphier-pxs2", .clk_rate = },
+ { .compatible = "socionext,uniphier-ld6b", .clk_rate = },
+ { .compatible = "socionext,uniphier-ld11", .clk_rate = 58823529 },
+ { .compatible = "socionext,uniphier-ld20", .clk_rate = 58823529 },
+ { .compatible = "socionext,uniphier-pxs3", .clk_rate = 58823529 },
+ { /* sentinel */ },
+};
+
static int uniphier_serial_probe(struct udevice *dev)
{
- DECLARE_GLOBAL_DATA_PTR;
struct uniphier_serial_priv *priv = dev_get_priv(dev);
struct uniphier_serial __iomem *port;
+ const struct uniphier_serial_clk_data *clk_data;
+ ofnode root_node;
fdt_addr_t base;
u32 tmp;
@@ -105,8 +129,19 @@ static int uniphier_serial_probe(struct udevice *dev)
priv->membase = port;
- priv->uartclk = fdtdec_get_int(gd->fdt_blob, dev_of_offset(dev),
- "clock-frequency", 0);
+ root_node = ofnode_path("/");
+ clk_data = uniphier_serial_clk_data;
+ while (clk_data->compatible) {
+ if (ofnode_device_is_compatible(root_node,
+ clk_data->compatible))
+ break;
+ clk_data++;
+ }
+
+ if (WARN_ON(!clk_data->compatible))
+ return -ENOTSUPP;
+
+ priv->uartclk = clk_data->clk_rate;
tmp = readl(>lcr_mcr);
tmp &= ~LCR_MASK;
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] common/memsize.c: Increase save array for supporting memory size > 4GB
On 06/19/2018 07:52 AM, Chee, Tien Fong wrote:
> On Mon, 2018-06-18 at 12:59 -0400, Tom Rini wrote:
>> On Wed, Jun 13, 2018 at 03:32:43PM +0800, tien.fong.c...@intel.com
>> wrote:
>>
>>>
>>> From: Tien Fong Chee
>>>
>>> In ARM 64-bits, memory size can be supported is more than 4GB,
>>> hence increasing save array is needed to cope with testing larger
>>> memory.
>>>
>>> Signed-off-by: Tien Fong Chee
>>> ---
>>> common/memsize.c |2 +-
>>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/common/memsize.c b/common/memsize.c
>>> index 5670e95..b091203 100644
>>> --- a/common/memsize.c
>>> +++ b/common/memsize.c
>>> @@ -26,7 +26,7 @@ DECLARE_GLOBAL_DATA_PTR;
>>> long get_ram_size(long *base, long maxsize)
>>> {
>>> volatile long *addr;
>>> - long save[31];
>>> + long save[BITS_PER_LONG];
>>> long save_base;
>>> long cnt;
>>> long val;
>> Since BITS_PER_LONG is 32 or 64, shouldn't we use B_P_L - 1 here? Or
>> are you saying there's also a case where this is wrong on 32bit
>> today?
> As long as the array is large enough to cope with shifting
> implementation, then it should be fine. For 32-bit, only 31 units in
> array required for storing 31 shifting values, and this apply for 64-
> bit also as long as the implementation of first shifting value is not
> change(cnt = (maxsize / sizeof(long)) >> 1).
> IMO, for simplifying and safety purpose(may be one day implementation
> change to "cnt = (maxsize / sizeof(long))", above B_P_L is still
> workable.
That's BS reasoning and just sloppy programming. I agree with Tom.
--
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC] ARM: rmobile: create DT memory nodes for R8A7795 3.0 and newer
Hi Laurent,
On Tue, Jun 19, 2018 at 9:10 AM Laurent Pinchart
wrote:
> On Tuesday, 19 June 2018 09:58:59 EEST Geert Uytterhoeven wrote:
> > On Tue, Jun 19, 2018 at 4:15 AM Laurent Pinchart wrote:
> > > On Sunday, 17 June 2018 03:08:02 EEST Marek Vasut wrote:
> > >> On 06/16/2018 05:44 PM, Laurent Pinchart wrote:
> > >>> On Saturday, 16 June 2018 02:42:30 EEST Marek Vasut wrote:
> > On 06/16/2018 01:21 AM, Laurent Pinchart wrote:
> > > On Friday, 15 June 2018 15:00:31 EEST Marek Vasut wrote:
> > >> On 06/15/2018 01:43 PM, Marek Vasut wrote:
>
> [snip]
>
> > > Obvious design question is -- since you're adding new SMC call
> > > anyway, can't the call just return the memory layout table
> > > itself, so that it won't be duplicated both in U-Boot and ATF ?
> >
> > My gut feeling was to go with the smallest interface possible.
> > >>>
> > >>> But this doesn't scale. The API here uses some ad-hoc constants to
> > >>> identify memory layout tables which have to be encoded both in ATF
> > >>> and U-Boot, both of which must be kept in sync.
> > >>>
> > >>> The ATF already has those memory layout tables, it's only a matter
> > >>> of passing them to U-Boot. If you do just that, the ad-hoc
> > >>> constants and encoding of tables into U-Boot goes away and in fact
> > >>> simplifies the design.
> > >>>
> > >>> Yet, I have to wonder if ATF doesn't already contain some sort of
> > >>> standard SMC call to get memory topology. It surprises me that it
> > >>> wouldn't.
> > >>
> > >> In fact, Laurent (CCed) was solving some similar issue with lossy
> > >> decomp and I think this involved some passing of memory layout
> > >> information from ATF to U-Boot too, or am I mistaken ?
> > >
> > > That's correct, ATF stores information about the memory layout at a
> > > fixed address in system memory, and U-Boot can read it.
> >
> > Well, that sounds good ! Maybe we can avoid adding SMC call
> > altogether then? :)
> > >>>
> > >>> I'd prefer that, yes.
> > >>>
> > >>> Let's not duplicate the mechanism used to pass FCNL information from
> > >>> ATF to U- Boot, but instead create a data table format that can store
> > >>> all the information we need, in an easily extensible way.
> > >>>
> > >>> To see how the mechanism is implemented for FCNL, search for 47FD7000
> > >>> in the Renesas ATF sources
> > >>> (git://github.com/renesas-rcar/arm-trusted-firmware.git).
> > >>
> > >> For everyone involved, can you explain what FCNL is ? ;-)
> > >
> > > FCNL is Frame Compression Near Lossless. It's a way to reduce memory
> > > bandwidth by transparent compression and decompression of video frames.
> > > Compression is handled by an IP core called FCP, and decompression is
> > > handled by the DRAM controller. ATF programs the DRAM controller with
> > > ranges of memory addresses that will be dynamically decompressed. The
> > > registers containing those ranges are accessible in secure mode only, so
> > > neither U-Boot nor Linux can read them. That's why ATF has to pass the
> > > information to U-Boot, in order to add the ranges as reserved memory in
> > > DT.
> > >
> > >> Any yes, I agree this sounds good. I had a discussion on the U-Boot IRC
> > >> about passing the memory configuration around and the result is
> > >> basically the same -- pass a table from ATF to U-Boot. If there's
> > >> already something, great.
> >
> > Pass a "table"? Or an FDT containing the /memory nodes?
> > The latter allows for easier future extension.
>
> ATF passes a table to U-Boot, and U-Boot then updates the FDT accordingly
> before starting Linux.
I know it passes a table. A table is very easy to parse, but complicates future
extension.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC] ARM: rmobile: create DT memory nodes for R8A7795 3.0 and newer
Hi Geert, On Tuesday, 19 June 2018 09:58:59 EEST Geert Uytterhoeven wrote: > On Tue, Jun 19, 2018 at 4:15 AM Laurent Pinchart wrote: > > On Sunday, 17 June 2018 03:08:02 EEST Marek Vasut wrote: > >> On 06/16/2018 05:44 PM, Laurent Pinchart wrote: > >>> On Saturday, 16 June 2018 02:42:30 EEST Marek Vasut wrote: > On 06/16/2018 01:21 AM, Laurent Pinchart wrote: > > On Friday, 15 June 2018 15:00:31 EEST Marek Vasut wrote: > >> On 06/15/2018 01:43 PM, Marek Vasut wrote: [snip] > > Obvious design question is -- since you're adding new SMC call > > anyway, can't the call just return the memory layout table > > itself, so that it won't be duplicated both in U-Boot and ATF ? > > My gut feeling was to go with the smallest interface possible. > >>> > >>> But this doesn't scale. The API here uses some ad-hoc constants to > >>> identify memory layout tables which have to be encoded both in ATF > >>> and U-Boot, both of which must be kept in sync. > >>> > >>> The ATF already has those memory layout tables, it's only a matter > >>> of passing them to U-Boot. If you do just that, the ad-hoc > >>> constants and encoding of tables into U-Boot goes away and in fact > >>> simplifies the design. > >>> > >>> Yet, I have to wonder if ATF doesn't already contain some sort of > >>> standard SMC call to get memory topology. It surprises me that it > >>> wouldn't. > >> > >> In fact, Laurent (CCed) was solving some similar issue with lossy > >> decomp and I think this involved some passing of memory layout > >> information from ATF to U-Boot too, or am I mistaken ? > > > > That's correct, ATF stores information about the memory layout at a > > fixed address in system memory, and U-Boot can read it. > > Well, that sounds good ! Maybe we can avoid adding SMC call > altogether then? :) > >>> > >>> I'd prefer that, yes. > >>> > >>> Let's not duplicate the mechanism used to pass FCNL information from > >>> ATF to U- Boot, but instead create a data table format that can store > >>> all the information we need, in an easily extensible way. > >>> > >>> To see how the mechanism is implemented for FCNL, search for 47FD7000 > >>> in the Renesas ATF sources > >>> (git://github.com/renesas-rcar/arm-trusted-firmware.git). > >> > >> For everyone involved, can you explain what FCNL is ? ;-) > > > > FCNL is Frame Compression Near Lossless. It's a way to reduce memory > > bandwidth by transparent compression and decompression of video frames. > > Compression is handled by an IP core called FCP, and decompression is > > handled by the DRAM controller. ATF programs the DRAM controller with > > ranges of memory addresses that will be dynamically decompressed. The > > registers containing those ranges are accessible in secure mode only, so > > neither U-Boot nor Linux can read them. That's why ATF has to pass the > > information to U-Boot, in order to add the ranges as reserved memory in > > DT. > > > >> Any yes, I agree this sounds good. I had a discussion on the U-Boot IRC > >> about passing the memory configuration around and the result is > >> basically the same -- pass a table from ATF to U-Boot. If there's > >> already something, great. > > Pass a "table"? Or an FDT containing the /memory nodes? > The latter allows for easier future extension. ATF passes a table to U-Boot, and U-Boot then updates the FDT accordingly before starting Linux. -- Regards, Laurent Pinchart ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] x86: qemu: do not build car.o with start64.o
On 06/19/2018 04:37 AM, Bin Meng wrote:
> Hi Heinrich,
>
> On Tue, Jun 12, 2018 at 11:50 PM, Heinrich Schuchardt
> wrote:
>> car.o can only be used with start.o, not with start64.o.
>>
>> So on qemu 64bit it should only be built for 32bit SPL but not for u-boot.
>>
>> Without this patch but with an unrelated pending patch
>> ("x86: Add 64-bit setjmp/longjmp implementation") the
>> following error occurred for qemu-x86_64_defconfig:
>>
>
> I don't understand why Ivan's setmp/longjmp patch triggers this build
> issue. Can you elaborate?
Hello Bin,
it was what I observed.
As start.S calls car_init() but start_64.S does not the linker could
eliminate car.o on x86_64. Why it does not eliminate it with the patch I
do not know.
But I still think that building car.o on 64bit does not make sense.
Best regards
Heinrich
>
>> arch/x86/cpu/built-in.o: In function `car_init':
>> arch/x86/cpu/qemu/car.S:25: undefined reference to `car_init_ret'
>>
>> Signed-off-by: Heinrich Schuchardt
>> ---
>> arch/x86/cpu/qemu/Makefile | 5 -
>> 1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/x86/cpu/qemu/Makefile b/arch/x86/cpu/qemu/Makefile
>> index e5ea92545e3..b1daffd4a32 100644
>> --- a/arch/x86/cpu/qemu/Makefile
>> +++ b/arch/x86/cpu/qemu/Makefile
>> @@ -2,8 +2,11 @@
>> #
>> # Copyright (C) 2015, Bin Meng
>>
>> +ifndef CONFIG_$(SPL_)X86_64
>> +obj-y += car.o
>> +endif
>> ifndef CONFIG_EFI_STUB
>> -obj-y += car.o dram.o
>> +obj-y += dram.o
>> endif
>> obj-y += qemu.o
>> obj-$(CONFIG_QFW) += cpu.o e820.o
>> --
>
> BTW: the patch does not apply cleanly on latest u-boot/master. Please
> rebase. Thanks!
>
> Regards,
> Bin
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v5 0/3] sunxi: fix eMMC stability issues on A64
On Tue, Jun 19, 2018 at 12:03 PM, Jagan Teki wrote: > On Tue, Jun 19, 2018 at 11:55 AM, Vasily Khoruzhick > wrote: >> On Mon, Jun 18, 2018 at 12:43 AM, Jagan Teki >> wrote: >>> >>> Don't have these hardware with me. >> >> Could you test this patch on your hardware when you get some time? >> >> https://github.com/anarsoul/u-boot-pine64/commit/a3f5d175a5ed0ece7a7720f1e665809c9f140850.patch > > On top of your changes or separately? This what[1] I changed on top of your changes, same issue. [1] https://paste.ubuntu.com/p/NjYyMk68P6/ ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
