[PATCH v3 5/6] button: add a simple ADC-based button driver

Add a simple Analog to Digital Converter device based button driver. This driver binds to the 'adc-keys' device tree node. Signed-off-by: Marek Szyprowski --- drivers/button/Kconfig | 8 +++ drivers/button/Makefile | 1 + drivers/button/button-adc.c | 117

[PATCH v3 6/6] configs: khadas-vim3: enable Function button support

Add options required to check the 'Function' button state. Signed-off-by: Marek Szyprowski --- configs/khadas-vim3_defconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/configs/khadas-vim3_defconfig b/configs/khadas-vim3_defconfig index 5d16652fd6..bc17430569 100644 ---

[PATCH v3 0/6] VIM3: add support for checking 'Function' button state

Hi All, This patchset adds all building blocks needed for checking the 'Function' button state in the boot script on Amlogic A311D based VIM3 board. This button is connected to the ADC lines of the SoC, so it required to enable meson SARADC, the clocks needed for it and a simple button-adc

[PATCH v3 4/6] configs: khadas-vim3: enable ADC device support

Analog to Digital Converter device (Meson SARADC) will be used for probing 'Function' button state. Signed-off-by: Marek Szyprowski --- configs/khadas-vim3_defconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/configs/khadas-vim3_defconfig b/configs/khadas-vim3_defconfig index

[PATCH v3 3/6] adc: meson-saradc: skip hardware init only if ADC is enabled

The driver skips hardware initialization if it is already configured by the earlier bootloader stage (BL30). Skip the initialization only if the hardware is really initialized and enabled. Signed-off-by: Marek Szyprowski Reviewed-by: Neil Armstrong Tested-by: Jaehoon Chung Reviewed-by: Jaehoon

[PATCH v3 2/6] adc: meson-saradc: add G12A variant

Add support for the SARADC variant found on the G12A SoCs family. Signed-off-by: Marek Szyprowski Reviewed-by: Neil Armstrong Tested-by: Jaehoon Chung Reviewed-by: Jaehoon Chung --- drivers/adc/meson-saradc.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/adc/meson-saradc.c

[PATCH v3 1/6] clk: meson: add minimal driver for g12a-ao clocks

Add minimal driver AO clocks on meson G12A family. Only ADC related clocks are supported. Signed-off-by: Marek Szyprowski Reviewed-by: Neil Armstrong Tested-by: Jaehoon Chung Reviewed-by: Jaehoon Chung --- drivers/clk/meson/Makefile | 1 + drivers/clk/meson/g12a-ao.c | 83

Re: [PATCH v2 6/7 RESEND] cmd: button: store button state in the 'button' env

On 16.12.2020 08:29, Heinrich Schuchardt wrote: > On 12/16/20 8:08 AM, Marek Szyprowski wrote: >> On 15.12.2020 20:07, Heinrich Schuchardt wrote: >>> On 12/15/20 5:54 PM, Marek Szyprowski wrote: Save examined button state in 'button' environment variable to enable checking button state

Re: [PATCH v2 6/7 RESEND] cmd: button: store button state in the 'button' env

On 12/16/20 8:08 AM, Marek Szyprowski wrote: On 15.12.2020 20:07, Heinrich Schuchardt wrote: On 12/15/20 5:54 PM, Marek Szyprowski wrote: Save examined button state in 'button' environment variable to enable checking button state in the scripts. Signed-off-by: Marek Szyprowski --- Resend

Re: [PATCH 1/6] net: macb: use dummy descriptor for RBQP

Hi Eugen, On Wed, Dec 16, 2020 at 2:55 PM wrote: > > On 03.12.2020 11:25, Claudiu Beznea wrote: > > In case of multiple queues on RX side the queue scheduler > > will try to use all the available configured queues (with > > descriptors having TX_USED bit cleared). If at least one RBQP > > points

RE: [PATCH 1/8] spl: fit: Drop 'length' argument to board_spl_fit_post_load()

> Subject: [PATCH 1/8] spl: fit: Drop 'length' argument to > board_spl_fit_post_load() > > The size is derived from the FIT image itself. Any alignment requirements are > machine-specific and known by the board code. Thus the total length can be > derived from the FIT image and knowledge of the

Re: [PATCH v2 6/7 RESEND] cmd: button: store button state in the 'button' env

On 15.12.2020 20:07, Heinrich Schuchardt wrote: > On 12/15/20 5:54 PM, Marek Szyprowski wrote: >> Save examined button state in 'button' environment variable to enable >> checking button state in the scripts. >> >> Signed-off-by: Marek Szyprowski >> --- >> Resend reason: get rid of the Change-Id

RE: [PATCH v2 2/2] board: imx8mm: add boot.cmd for distro boot on iMX8MM

> Subject: [PATCH v2 2/2] board: imx8mm: add boot.cmd for distro boot on > iMX8MM > > From: Alice Guo > > Distro Boot requires a U-Boot-specific script named boot.scr or boot.scr.uimg > which contains boot commands to boot the system. The boot.cmd is such a > file. Use mkimage to generate

RE: [PATCH v2 1/2] imx8mm: configs: add support for distro boot commands

> Subject: [PATCH v2 1/2] imx8mm: configs: add support for distro boot > commands > > From: Alice Guo > > Supported boot device types in iMX8MM: MMC, DHCP. > > CONFIG_CMD_PART is added for command part and > CONFIG_CMD_FS_GENERIC is for command fstype. > > CONFIG_BOOTCOMMAND which is defined

Re: [PATCH v2 2/2] x86: edison: Switch to DM_USB_GADGET

On Wed, Dec 16, 2020 at 11:40 AM Bin Meng wrote: > > On Fri, Dec 4, 2020 at 1:45 AM Andy Shevchenko > wrote: > > > > DM is the modern default approach for the drivers in U-Boot. > > It also allows to configure code via Device Tree. > > > > Move Intel Edison to use DM_USB_GADGET and drop hard

Re: [PATCH v2 1/2] x86: edison: Use dwc3-generic driver for Intel Edison

On Wed, Dec 16, 2020 at 11:39 AM Bin Meng wrote: > > On Fri, Dec 4, 2020 at 1:45 AM Andy Shevchenko > wrote: > > > > Use generic Synopsys DesignWare 3 driver on Intel Edison. > > For now it's just a stub which allows future refactoring. > > > > Signed-off-by: Andy Shevchenko > > --- > > v2: no

Re: [PATCH v1] x86: edison: BINMAN selection is specific to the board

On Wed, Dec 16, 2020 at 11:34 AM Bin Meng wrote: > > On Thu, Dec 3, 2020 at 11:40 PM Andy Shevchenko > wrote: > > > > The platforms based on Intel Tangier may have different requirements > > how to create bootloader bundle to supply to a device. Currently > > the BINMAN approach is for Intel

Re: [PATCH v1] x86: edison: Add CPU to compatible string

On Wed, Dec 16, 2020 at 11:34 AM Bin Meng wrote: > > On Wed, Dec 2, 2020 at 6:35 PM Andy Shevchenko > wrote: > > > > Like in the rest of x86 boards append CPU to the board compatible string. > > > > Signed-off-by: Andy Shevchenko > > --- > > arch/x86/dts/edison.dts | 2 +- > > 1 file changed,

Re: [PATCH v1] x86: edison: Drop unneeded DM_PCI_COMPAT

On Wed, Dec 16, 2020 at 11:33 AM Bin Meng wrote: > > On Fri, Nov 27, 2020 at 8:41 PM Andy Shevchenko > wrote: > > > > None of the driver for Edison is using DM_PCI_COMPAT, hence drop it. > > > > Signed-off-by: Andy Shevchenko > > --- > > configs/edison_defconfig | 1 - > > 1 file changed, 1

Re: [PATCH v1] x86: tangier: Find proper memory region for relocation

On Wed, Dec 16, 2020 at 11:32 AM Bin Meng wrote: > > On Fri, Nov 27, 2020 at 8:40 PM Andy Shevchenko > wrote: > > > > It appears that U-Boot works by luck on Intel Edison board because the > > amount > > of RAM is less than 1 GB and standard way of calculating the top of it work > > for this

Re: [PATCH 3/3] x86: coral: Update the boot script

On Wed, Dec 16, 2020 at 11:26 AM Bin Meng wrote: > > On Mon, Nov 9, 2020 at 10:12 PM Simon Glass wrote: > > > > Make use of the new bootargs substitution mechanism and zboot command > > syntax. > > > > Signed-off-by: Simon Glass > > --- > > > > include/configs/chromebook_coral.h | 11

Re: [PATCH 2/3] x86: zimage: Update cmdline parameter to be an env var

On Wed, Dec 16, 2020 at 11:26 AM Bin Meng wrote: > > On Mon, Nov 9, 2020 at 10:12 PM Simon Glass wrote: > > > > With the updated changes to bootargs substitution[1], the zboot command > > needs to be updated to get its command line from an environment variable > > instead of a memory address.

[PATCH v2 2/2] board: imx8mm: add boot.cmd for distro boot on iMX8MM

From: Alice Guo Distro Boot requires a U-Boot-specific script named boot.scr or boot.scr.uimg which contains boot commands to boot the system. The boot.cmd is such a file. Use mkimage to generate boot.scr or boot.scr.uimg from boot.cmd, and the command is: mkimage -A arm -O linux -T script -C

[PATCH v2 1/2] imx8mm: configs: add support for distro boot commands

From: Alice Guo Supported boot device types in iMX8MM: MMC, DHCP. CONFIG_CMD_PART is added for command part and CONFIG_CMD_FS_GENERIC is for command fstype. CONFIG_BOOTCOMMAND which is defined in include/configs/imx8mm_evk.h is deleted because "run distro_bootcmd" is required to be the default

Re: [PATCH v2 2/2] x86: edison: Switch to DM_USB_GADGET

On Fri, Dec 4, 2020 at 1:45 AM Andy Shevchenko wrote: > > DM is the modern default approach for the drivers in U-Boot. > It also allows to configure code via Device Tree. > > Move Intel Edison to use DM_USB_GADGET and drop hard coded values. > > Signed-off-by: Andy Shevchenko > --- > v2: cleaned

Re: [PATCH v2 1/2] x86: edison: Use dwc3-generic driver for Intel Edison

On Fri, Dec 4, 2020 at 1:45 AM Andy Shevchenko wrote: > > Use generic Synopsys DesignWare 3 driver on Intel Edison. > For now it's just a stub which allows future refactoring. > > Signed-off-by: Andy Shevchenko > --- > v2: no changes > arch/x86/cpu/tangier/Kconfig| 3 +++ >

Re: [PATCH v1] x86: edison: BINMAN selection is specific to the board

On Thu, Dec 3, 2020 at 11:40 PM Andy Shevchenko wrote: > > The platforms based on Intel Tangier may have different requirements > how to create bootloader bundle to supply to a device. Currently > the BINMAN approach is for Intel Edison only. > Reviewed-by: Bin Meng

Re: [PATCH v1] x86: edison: Add CPU to compatible string

On Wed, Dec 2, 2020 at 6:35 PM Andy Shevchenko wrote: > > Like in the rest of x86 boards append CPU to the board compatible string. > > Signed-off-by: Andy Shevchenko > --- > arch/x86/dts/edison.dts | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > Reviewed-by: Bin Meng

Re: [PATCH v1] x86: edison: Drop unneeded DM_PCI_COMPAT

On Fri, Nov 27, 2020 at 8:41 PM Andy Shevchenko wrote: > > None of the driver for Edison is using DM_PCI_COMPAT, hence drop it. > > Signed-off-by: Andy Shevchenko > --- > configs/edison_defconfig | 1 - > 1 file changed, 1 deletion(-) > Reviewed-by: Bin Meng

Re: [PATCH v1] x86: tangier: Find proper memory region for relocation

On Fri, Nov 27, 2020 at 8:40 PM Andy Shevchenko wrote: > > It appears that U-Boot works by luck on Intel Edison board because the amount > of RAM is less than 1 GB and standard way of calculating the top of it work > for this configuration. However, this won't work if the amount of RAM is >

Re: [PATCH 3/3] x86: coral: Update the boot script

On Mon, Nov 9, 2020 at 10:12 PM Simon Glass wrote: > > Make use of the new bootargs substitution mechanism and zboot command > syntax. > > Signed-off-by: Simon Glass > --- > > include/configs/chromebook_coral.h | 11 +++ > 1 file changed, 7 insertions(+), 4 deletions(-) > Reviewed-by:

Re: [PATCH 2/3] x86: zimage: Update cmdline parameter to be an env var

On Mon, Nov 9, 2020 at 10:12 PM Simon Glass wrote: > > With the updated changes to bootargs substitution[1], the zboot command > needs to be updated to get its command line from an environment variable > instead of a memory address. This is because the command-line string must > be updated to

Re: [PATCH v4] usb: xhci: fix lack of short packet event trb handling

Hi Marek, On Thu, Dec 3, 2020 at 6:52 AM Marek Vasut wrote: > > On 11/18/20 8:49 AM, Ran Wang wrote: > > For bulk IN transfer, the codes will set ISP flag to request event TRB > > being generated by xHC for the case of short packet. So when encountering > > buffer-cross-64K-boundary (which we

Re: [PATCH] Travis-CI: Drop support

On Wed, Dec 16, 2020 at 8:06 AM Tom Rini wrote: > > Travis-CI is changing their support for FOSS (understandably) to have a > limited per-month number of build minutes. Unfortunately for us, the > matrix of jobs we run will exhaust that very quickly. Remove the yml > file. Thanks for all the

fatal error: configs/.h: No such file or directory

Hi I'm in the processes of porting u-boot 2020 to an iMX6-Q7-Plus board from MSC technologies so that I have access to u-boot. I worked meticulously though the instructions provided here to add the board support to uboot:

[PATCH 8/8] spl: fit: Load devicetree when a Linux payload is found

When a FIT config specifies a devicetree, we should load it, no questions asked. In the case of the "simple" FIT loading path, a difficulty arises in selecting the load address of the FDT. The default FDT location is right after the "kernel" or "firmware" image. However, if that is an OP-TEE

[PATCH 7/8] spl: fit: Replace #ifdef blocks with more readable constructs

Use the IS_ENABLED() macro to control code flow, instead of the caveman approach of sprinkling #ifdefs. Code size is not affected, as the linker garbage-collects unused functions. However, readability is improved significantly. Signed-off-by: Alexandru Gagniuc --- common/spl/spl_fit.c | 53

[PATCH 4/8] spl: fit: Remove useless loop in spl_fit_get_image_name()

When a desired configuration is not found, conf_node will have a negative value. Thus the for loop will start at the root "/" node of the image, print the "/description" property, and stop. It appears the intent of the loop was to print the names of the subnodes under "/configurations". We would

[PATCH 6/8] image: Do not #if guard board_fit_config_name_match() prototype

There's no point in guarding function prototypes with #ifdefs. If a function is not defined, the linker will notice. Having the prototype does not affect code size. What the #if guard takes away is the ability to use IS_ENABLED: if (CONFIG_IS ENABLED(FIT_IMAGE_POST_PROCESS))

[PATCH 5/8] spl: fit: Only look up FIT configuration node once

The configuration node a sub node under "/configurations", which describes the components to load from "/images". We only need to locate this node once. However, for each component, spl_fit_get_image_name() would parse the FIT image, looking for the correct node. Such work duplication is not

[PATCH 3/8] spl: fit: Pass FIT context via a structure pointer

Several loose arguments describe the FIT image. They are thus related, and it makes sense to pass them together, in a structure. Examples include the FIT blob pointer, offset to FDT nodes, and the offset to external data. Use a spl_fit_info structure to group these parameters. Signed-off-by:

[PATCH 2/8] spl: fit: Factor out FIT parsing and use a context struct

The logical steps in spl_load_simple_fit() are difficult to follow. I think the long comments, ifdefs, and ungodly number of variables seriously affect the readability. In particular, it violates section 6 of the coding style, paragraphs (3), and (4). The purpose of this patch is to improve the

[PATCH 1/8] spl: fit: Drop 'length' argument to board_spl_fit_post_load()

The size is derived from the FIT image itself. Any alignment requirements are machine-specific and known by the board code. Thus the total length can be derived from the FIT image and knowledge of the platform. The 'length' argument is redundant. Remove it. Signed-off-by: Alexandru Gagniuc ---

[PATCH 0/8] spl: fit: Play nicely with OP-TEE and Linux

This patch series is part of a larger effort to get linux to boot really fast alongside a secure OS. One piece of the puzzle is getting Linux and OP-TEE to boot straight from SPL. This is where the FIT image comes in. The "simple" fit code was mostly ready for this, although it was quite

[PATCH] Travis-CI: Drop support

Travis-CI is changing their support for FOSS (understandably) to have a limited per-month number of build minutes. Unfortunately for us, the matrix of jobs we run will exhaust that very quickly. Remove the yml file. Thanks for all the builds, Travis-CI! Signed-off-by: Tom Rini ---

[PATCH V2] cmd: mmc: update the mmc command's usage about argument

It's confusing whether arguments are optional or mandatory. Update the command's usage to clarify how to use. Signed-off-by: Jaehoon Chung Reviewed-by: Simon Glass --- Changed on V2 - Update commit-msg - Add Simon's Reviewed-by tag --- cmd/mmc.c | 6 +++--- 1 file changed, 3 insertions(+), 3

Re: [SPECIFICATION RFC] The firmware and bootloader log specification

Hi Daniel, On Fri, 13 Nov 2020 at 19:07, Daniel Kiper wrote: > > Hey, > > This is next attempt to create firmware and bootloader log specification. > Due to high interest among industry it is an extension to the initial > bootloader log only specification. It takes into the account most of the >

RE: [PATCH 3/4] Revert "lpc32xx: cpu: add support for soft reset"

Hi, This functionality (soft vs hard reset) is used in multiple LPC32xx products with our custom hardware. If this support is remove from upstream, we will have to maintain this patch locally (out of tree). Sylvain Lemieux -Original Message- From: Harald Seiler Sent: Tuesday,

Re: [PATCH v2 1/2] rng: Add iProc RNG200 driver

On 12/15/20 10:49 AM, matthias@kernel.org wrote: From: Matthias Brugger Add support for random number generator RNG200. This is for example found on RPi4. Signed-off-by: Matthias Brugger The rng command shows random data: U-Boot> rng : 25 50 2d a3 c2 9b 1e ac a7 be 01 aa e5 05

Re: [PATCH v2 5/7] button: add a simple ADC-based button driver

On 12/15/20 3:42 PM, Marek Szyprowski wrote: Add a simple ADC-based button driver. This driver binds to the 'adc-keys' device tree node. Signed-off-by: Marek Szyprowski --- drivers/button/Kconfig | 8 +++ drivers/button/Makefile | 1 + drivers/button/button-adc.c | 117

[PATCH] doc: FIT image: Clarify format and simplify syntax

** Introduction There are currently four ways to load an OS image with u-boot 1. SPL -> u-boot -> bootm 2. SPL blue falcon mode 3. "Basic" FIT image (CONFIG_LOAD_FIT) 4. "Full-featured" FIT image (CONFIG_LOAD_FIT_FULL) These four code paths were developed independently, and share very

Re: [PATCH v2 6/7 RESEND] cmd: button: store button state in the 'button' env

On 12/15/20 5:54 PM, Marek Szyprowski wrote: Save examined button state in 'button' environment variable to enable checking button state in the scripts. Signed-off-by: Marek Szyprowski --- Resend reason: get rid of the Change-Id tag, that was still in v2. --- cmd/button.c | 4 +++- 1 file

Re: [PULL u-boot] Please pull u-boot-amlogic-20201215

15:55:17 > -0500) > > are available in the Git repository at: > > https://gitlab.denx.de/u-boot/custodians/u-boot-amlogic.git > tags/u-boot-amlogic-20201215 > > for you to fetch changes up to 5ccd5d2cc98224108ae9fb09593a862c9caa5e80: > > pinctrl: meson

[PATCH v3 12/12] configs: rpi4: Enable DM_DMA across all RPi4 configurations

The DM_DMA option is needed in order to translate physical address into bus addresses on a per-device basis. Signed-off-by: Nicolas Saenz Julienne --- configs/rpi_4_32b_defconfig | 1 + configs/rpi_4_defconfig | 1 + configs/rpi_arm64_defconfig | 1 + 3 files changed, 3 insertions(+) diff

[PATCH v3 10/12] xhci: translate virtual addresses into the bus's address space

So far we've been content with passing physical addresses when configuring memory addresses into XHCI controllers, but not all platforms have buses with transparent mappings. Specifically the Raspberry Pi 4 might introduce an offset to memory accesses incoming from its PCIe port. Introduce

[PATCH v3 11/12] mmc: Introduce mmc_phys_to_bus()/mmc_bus_to_phys()

This will allow us to use DM variants of phys_to_bus()/bus_to_phys() when relevant. Signed-off-by: Nicolas Saenz Julienne --- drivers/mmc/sdhci.c | 7 --- include/mmc.h | 10 ++ 2 files changed, 14 insertions(+), 3 deletions(-) diff --git a/drivers/mmc/sdhci.c

[PATCH v3 09/12] dm: test: Add test case for dev_phys_to_bus()/dev_bus_to_phys()

By reusing DT nodes already available in sandbox's test DT introduce a test to validate dev_phys_to_bus()/dev_bus_to_phys(). Signed-off-by: Nicolas Saenz Julienne --- test/dm/Makefile | 1 + test/dm/phys2bus.c | 36 2 files changed, 37 insertions(+)

[PATCH v3 08/12] dm: Introduce dev_phys_to_bus()/dev_bus_to_phys()

These functions, instead of relying on hard-coded platform-specific address translations, make use of the DMA constraints provided by the DM core. This allows for per-device translations. We can't yet get rid of the legacy phys_to_bus()/bus_to_phys() implementations as some of its users are not

[PATCH v3 07/12] dm: test: Add test case for dev->dma_offset

Add test to validate dev->dma_offset is properly set on devices. Signed-off-by: Nicolas Saenz Julienne --- arch/sandbox/dts/test.dts | 4 configs/sandbox64_defconfig| 1 + configs/sandbox_defconfig | 1 + configs/sandbox_flattree_defconfig | 1 +

[PATCH v3 04/12] dm: Introduce xxx_get_dma_range()

Add the following functions to get a specific device's DMA ranges: - dev_get_dma_range() - ofnode_get_dma_range() - of_get_dma_range() - fdt_get_dma_range() They are specially useful in oder to be able validate a physical address space range into a bus's and to convert addresses from and to

[PATCH v3 06/12] dm: Introduce DMA constraints into the core device model

Calculating the DMA offset between a bus address space and CPU's every time we call phys_to_bus() and bus_to_phys() isn't ideal performance wise, as it implies traversing the device tree from the device's node up to the root. Since this information is static and available before the device's

[PATCH v3 03/12] pci: pcie-brcmstb: Fix inbound window configurations

So far we've assumed a fixed configuration for inbound windows as we had a single user for this controller. But the controller's DMA constraints were improved starting with BCM2711's B1 revision of the SoC, notably available in CM4 and Pi400. They allow for wider inbound windows. We can now cover

[PATCH v3 05/12] dm: test: Add test case for dev_get_dma_ranges()

Introduce some new nodes in sandbox's test device-tree and dm tests in order to validate dev_get_dma_range(). Signed-off-by: Nicolas Saenz Julienne --- arch/sandbox/dts/test.dts | 17 ++ test/dm/Makefile | 1 + test/dm/read.c| 49

[PATCH v3 02/12] rpi: Add identifier for the new CM4

The Raspberry Pi Foundation released the new Compute Module 4 which we want to detect, so we can enable Ethernet on it and know the correct device tree file name. Note that this sets the Ethernet option to true since the official CM4 IO board has an Ethernet port. But that might not be the case

[PATCH v3 00/12] Raspberry Pi 400/Compute Module 4 support

This series could be split into at least two or even three parts, but I kept it as is for now as it contains all the changes needed in order to have u-boot working on the new Raspberry Pi 400 and Raspberry Pi Compute Module 4. There are core changes, specifically with regard to cpu to bus address

[PATCH v3 01/12] rpi: Add identifier for the new RPi400

The Raspberry Pi Foundation released the new RPi400 which we want to detect, so we can enable Ethernet on it and know the correct device tree file name. Signed-off-by: Nicolas Saenz Julienne --- Changes since v1: - The RPi Foundation introduced a RPi400 specific device tree, so use that

[PATCH v2 6/7 RESEND] cmd: button: store button state in the 'button' env

Save examined button state in 'button' environment variable to enable checking button state in the scripts. Signed-off-by: Marek Szyprowski --- Resend reason: get rid of the Change-Id tag, that was still in v2. --- cmd/button.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff

Documentation fixes for v2020.01-rc4

Hello Tom, this is just a collection of documentation changes. Please, pull them. The following changes since commit f40825e18e0a8560991072114b9b10b33fdad95b: Merge https://gitlab.denx.de/u-boot/custodians/u-boot-riscv (2020-12-14 15:11:05 -0500) are available in the Git repository at:

Re: [PATCH v2 00/26] dm: Change the way sequence numbers are implemented

Hi Michael, On Tue, 15 Dec 2020 at 01:58, Michael Walle wrote: > > Hi Simon, > > Am 2020-12-15 05:28, schrieb Simon Glass: > > On Sat, 12 Dec 2020 at 11:38, Simon Glass wrote: > >> On Sat, 12 Dec 2020 at 10:53, Michael Walle wrote: > >> > Am 2020-12-12 16:39, schrieb Simon Glass: > >> > >>

Re: Please pull u-boot-dm/next into -next

Hi Tom, On Tue, 15 Dec 2020 at 07:06, Tom Rini wrote: > > On Mon, Dec 14, 2020 at 08:50:53AM -0700, Simon Glass wrote: > > > Hi Tom, > > > > https://gitlab.denx.de/u-boot/custodians/u-boot-dm/-/pipelines/5567 > > > > > > Note this is for the 'next' tree. > > > > It includes the rename series

[PATCH 4/4] reset: Remove addr parameter from reset_cpu()

Historically, the reset_cpu() function had an `addr` parameter which was meant to pass in an address of the reset vector location, where the CPU should reset to. This feature is no longer used anywhere in U-Boot as all reset_cpu() implementations now ignore the passed value. Generic code has

[PATCH 2/4] board: ns3: Remove superfluous reset logic

The current implementation of reset_cpu() in the ns3 board code does not archieve what it is supposed to (according to the comments), due to a number of reasons: 1. The argument to reset_cpu() is _not_ actually passed from the `reset` command, but is set to 0 in all call-sites (in this

[PATCH 3/4] Revert "lpc32xx: cpu: add support for soft reset"

This reverts commit 576007aec9a4a5f4f3dd1f690fb26a8c05ceb75f. The paramter passed to reset_cpu() no longer holds a meaning as all call-sites now pass the value 0. Thus, branching on it is essentially dead code and will just confuse future readers. Revert soft-reset support and just always

[PATCH 1/4] nds32: Remove dead reset_cpu() implementation

nds32 is one of the only architectures which still have a reset_cpu() implementation that makes use of the `addr` parameter. The rest of U-Boot now ignores it and passes 0 everywhere. It turns out that even here, reset_cpu() is no longer referenced anywhere; reset is either not implemented (e.g.

[PATCH 0/4] Remove addr parameter from reset_cpu()

Hi, this is something I had on my mind for a longer time but never got around to actually do until now ... A while back, while working on the patchset that led to commit c5635a032a4b ("ARM: imx8m: Don't use the addr parameter of reset_cpu()"), I noticed that the `addr` parameter of reset_cpu()

Re: [PATCH 01/14] qemu: arm: Use the generated DTB only when CONGIG_OF_BOARD is defined

On Tue, 15 Dec 2020 at 18:25, Heinrich Schuchardt wrote: > On 15.12.20 12:10, Sughosh Ganu wrote: > > > > On Wed, 9 Dec 2020 at 03:24, Heinrich Schuchardt > > wrote: > > > > On 12/8/20 10:19 AM, Sughosh Ganu wrote: > > > > > > On Tue, 8 Dec 2020 at 14:32,

Re: [PATCH v1] distro_bootcmd: set devtype for dhcp boot

Hi Tom, On Thu, Oct 29, 2020 at 12:59 PM Igor Opaniuk wrote: > > From: Igor Opaniuk > > Set $devtype for DHCP boot, which can be handy for the boot.scr > for detection of devtype used (for example, when the same boot.scr is > used for both mmc/dhcp boot): > > if test ${devtype} = "dhcp"; then >

Re: [PATCH 3/4] console: remove #ifdef CONFIG_CONSOLE_RECORD

On 12/12/20 4:39 PM, Simon Glass wrote: Hi Patrick, On Thu, 3 Dec 2020 at 02:20, Patrick Delaunay wrote: Add helper functions to access to gd->console_out and gd->console_in with membuff API and replace the #ifdef CONFIG_CONSOLE_RECORD test by if (IS_ENABLED(CONFIG_CONSOLE_RECORD)) to

[PATCH v2 5/7] button: add a simple ADC-based button driver

Add a simple ADC-based button driver. This driver binds to the 'adc-keys' device tree node. Signed-off-by: Marek Szyprowski --- drivers/button/Kconfig | 8 +++ drivers/button/Makefile | 1 + drivers/button/button-adc.c | 117 3 files changed,

[PATCH v2 1/7] clk: meson: add minimal driver for g12a-ao clocks

Add minimal driver AO clocks on meson G12A family. Only ADC related clocks are supported. Signed-off-by: Marek Szyprowski Reviewed-by: Neil Armstrong Tested-by: Jaehoon Chung Reviewed-by: Jaehoon Chung --- drivers/clk/meson/Makefile | 1 + drivers/clk/meson/g12a-ao.c | 83

[PATCH v2 4/7] configs: khadas-vim3: enable ADC device support

ADC device (Meson SARADC) will be used for probing 'Function' button state. Signed-off-by: Marek Szyprowski --- configs/khadas-vim3_defconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/configs/khadas-vim3_defconfig b/configs/khadas-vim3_defconfig index 9d7ba72d44..5d16652fd6 100644

[PATCH v2 0/7] VIM3: add support for checking 'Function' button state

Hi All, This patchset adds all building blocks needed for checking the 'Function' button state in the boot script on Amlogic A311D based VIM3 board. This button is connected to the ADC lines of the SoC, so it required to enable meson SARADC, the clocks needed for it and a simple button-adc

[PATCH v2 2/7] adc: meson-saradc: add G12A variant

Add support for the SARADC variant found on the G12A SoCs family. Signed-off-by: Marek Szyprowski Reviewed-by: Neil Armstrong Tested-by: Jaehoon Chung Reviewed-by: Jaehoon Chung --- drivers/adc/meson-saradc.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/adc/meson-saradc.c

[PATCH v2 7/7] configs: khadas-vim3: enable Function button support

Add options needed to check the 'Function' button state. Signed-off-by: Marek Szyprowski --- configs/khadas-vim3_defconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/configs/khadas-vim3_defconfig b/configs/khadas-vim3_defconfig index 5d16652fd6..bc17430569 100644 ---

[PATCH v2 6/7] cmd: button: store button state in the 'button' env

Save examined button state in 'button' environment variable to enable checking button state in the scripts. Signed-off-by: Marek Szyprowski Change-Id: I78b539e1516573fcfea4401f75469291844daae4 --- cmd/button.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/cmd/button.c

[PATCH v2 3/7] adc: meson-saradc: skip hardware init only if ADC is enabled

The driver skips hardware initialization if it is already configured by the earlier bootloader stage (BL30). Skip the initialization only if the hardware is really initialized and enabled. Signed-off-by: Marek Szyprowski Reviewed-by: Neil Armstrong Tested-by: Jaehoon Chung Reviewed-by: Jaehoon

Re: [Uboot-stm32] [PATCH 2/2] console: sandbox: remove unnecessary sandbox code

Hi Simon, On 12/12/20 4:39 PM, Simon Glass wrote: Hi Patrick, On Wed, 2 Dec 2020 at 07:08, Patrick DELAUNAY wrote: Hi Simon, From: Simon Glass Sent: lundi 30 novembre 2020 21:12 Hi Patrick, On Fri, 27 Nov 2020 at 03:49, Patrick Delaunay wrote: Remove the specific sandbox code in

Re: [PATCH 3/3] video: seps525: Add seps525 SPI driver

Hi Simon, On 15. 12. 20 4:55, Simon Glass wrote: > Hi Michal, > > On Mon, 14 Dec 2020 at 00:30, Michal Simek wrote: >> >> >> >> On 12. 12. 20 16:35, Simon Glass wrote: >>> Hi Michal, >>> >>> On Thu, 3 Dec 2020 at 02:13, Michal Simek wrote: Add support for the WiseChip Semiconductor

[PATCH v3 6/6] video: Call video_sync in video_clear()

There is a need to call sync when anybody asking for clearing display. For example via cls command. Signed-off-by: Michal Simek --- Changes in v3: - new patch in this series drivers/video/video-uclass.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH v3 5/6] video: seps525: Add seps525 SPI driver

Add support for the WiseChip Semiconductor Inc. (UG-6028GDEBF02) display using the SEPS525 (Syncoam) LCD Controller. Syncoam Seps525 PM-Oled is RGB 160x128 display. This driver has been tested through zynq-spi driver. ZynqMP> load mmc 1 10 rainbow.bmp 61562 bytes read in 20 ms (2.9 MiB/s)

[PATCH v3 4/6] video: seps525: Add dt binding description

From: Vikhyat Goyal Added dt binding for seps525 display driver. Signed-off-by: Vikhyat Goyal Signed-off-by: Michal Simek Reviewed-by: Simon Glass --- (no changes since v1) MAINTAINERS | 1 + .../video/syncoam,seps525.txt | 24

[PATCH v3 3/6] video: Introduce video_sync operation

Some drivers like LCD connected via SPI requires explicit sync function which copy framebuffer content over SPI to controller to display. This hook doesn't exist yet that's why introduce it via video operations. Signed-off-by: Michal Simek Reviewed-by: Simon Glass --- (no changes since v2)

[PATCH v3 2/6] video: Let video_sync to return error value

This patch is preparation for follow up one to support cases where synchronization can fail. Suggested-by: Simon Glass Signed-off-by: Michal Simek Reviewed-by: Simon Glass --- Changes in v3: - also fix video_bmp call. Changes in v2: - New patch is series drivers/video/vidconsole-uclass.c

[PATCH v3 1/6] video: Fix video sync kernel-doc format

Place description below function parameters to make kernel-doc stript happy. Also rename dev to vid to be aligned with function parameters. Fixes: 1acafc73bfc7 ("dm: video: Add a video uclass") Signed-off-by: Michal Simek Reviewed-by: Simon Glass --- (no changes since v2) Changes in v2: - New

[PATCH v3 0/6] video: seps525: Add new driver for seps525 OLED display

Hi, This driver is connected via spi on one ZynqMP board. Only 8bit SPI connection is supported now. Spi zynq driver was used for testing this driver. We have tested load image via BMP command and also using it as console as is visible from log in the last patch. Thanks, Michal Changes in v3: -

Re: Please pull u-boot-dm/next into -next

On Mon, Dec 14, 2020 at 08:50:53AM -0700, Simon Glass wrote: > Hi Tom, > > https://gitlab.denx.de/u-boot/custodians/u-boot-dm/-/pipelines/5567 > > > Note this is for the 'next' tree. > > It includes the rename series which would be good to get in early. > > Regards, > Simon > > The

[PATCH 3/3] boards: amlogic: update documentation for WeTek Core2

Update the device matrix and add build instructions. Signed-off-by: Christian Hewitt --- doc/board/amlogic/index.rst | 3 +- doc/board/amlogic/wetek-core2.rst | 90 +++ 2 files changed, 92 insertions(+), 1 deletion(-) create mode 100644

[PATCH 2/3] boards: amlogic: add WeTek Core2 support

Add a config for the WeTek Core2, largely based on the VIM2 config. Signed-off-by: Christian Hewitt --- configs/wetek-core2_defconfig | 70 +++ 1 file changed, 70 insertions(+) create mode 100644 configs/wetek-core2_defconfig diff --git

[PATCH 1/3] ARM: dts: import WeTek Core2 DTs from Linux 5.10

Import the WeTek Core2 and supporting meson-gx-p23x-q20x.dtsi files from Linux 5.10. Signed-off-by: Christian Hewitt --- arch/arm/dts/Makefile | 1 + arch/arm/dts/meson-gx-p23x-q20x.dtsi | 324 ++ .../arm/dts/meson-gxm-wetek-core2-u-boot.dtsi |

[PATCH 0/3] board: amlogic: add WeTek Core2 support

This patchset adds support for the WeTek Core2 box which is based on the Amlogic S912 (GXM) SoC. Patches are based on u-boot-amlogic-next branch in the custodians tree. Christian Hewitt (3): ARM: dts: import WeTek Core2 DTs from Linux 5.10 boards: amlogic: add WeTek Core2 support boards:

  1   2   >