[U-Boot] [PATCH v2] drivers/sysreset: group sysreset drivers

Create drivers/sysreset and move sysreset-uclass and all sysreset drivers there. Signed-off-by: Max Filippov --- Changes v1->v2: - move RK3399 sysreset driver as well; - format patch with -M to make renames explicit. --- arch/arm/mach-rockchip/rk3036/Makefile

[U-Boot] [PATCH 4/6] x86: efi: Add EFI loader support for x86

Add the required pieces to support the EFI loader on x86. Since U-Boot only builds for 32-bit on x86, only a 32-bit EFI application is supported. If a 64-bit kernel must be booted, U-Boot supports this directly using FIT (see doc/uImage.FIT/kernel.its). U-Boot can act as a payload for both 32-bit

Re: [U-Boot] [PATCH v2 12/13] dm: mmc: Enable DM_MMC_OPS by default with DM_MMC

Hi, On 17 July 2016 at 15:00, Simon Glass wrote: > On 5 July 2016 at 17:10, Simon Glass wrote: >> These two options go together and it is best to do the conversion in one >> step. So enable DM_MMC_OPS by default if DM_MMC is enabled. >> >> Signed-off-by:

Re: [U-Boot] [PATCH v2 13/13] dm: blk: Enable CONFIG_BLK if DM_MMC is enabled

On 17 July 2016 at 15:00, Simon Glass wrote: > On 5 July 2016 at 17:10, Simon Glass wrote: >> To speed up conversion to CONFIG_BLK, enable it by default when DM_MMC is >> enabled. >> >> Signed-off-by: Simon Glass >> --- >> >> Changes in

Re: [U-Boot] [PATCH 1/2 RESEND] fdt_support: fdt_translate_address() blob const correctness

Hi Stephen, On 6 August 2016 at 00:01, Stephen Warren wrote: > On 08/05/2016 09:36 PM, Simon Glass wrote: >> >> Hi Stephen, >> >> On 5 August 2016 at 19:41, Simon Glass wrote: >>> >>> >>> On 5 August 2016 at 09:47, Stephen Warren

[U-Boot] [PATCH 6/6] x86: Enable EFI loader support

Enable this so that EFI applications (notably grub) can be run under U-Boot on x86 platforms. Signed-off-by: Simon Glass --- lib/efi_loader/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig index

[U-Boot] [PATCH 5/6] x86: efi: Add a hello world test program

It is useful to have a basic sanity check for EFI loader support. Add a 'bootefi hello' command which loads HelloWord.efi and runs it under U-Boot. Signed-off-by: Simon Glass --- arch/x86/lib/HelloWorld.efi | Bin 0 -> 11168 bytes arch/x86/lib/Makefile | 1 + 2 files

[U-Boot] [PATCH 3/6] arm: efi: Add a hello world test program

It is useful to have a basic sanity check for EFI loader support. Add a 'bootefi hello' command which loads HelloWord.efi and runs it under U-Boot. Signed-off-by: Simon Glass --- arch/arm/lib/HelloWorld32.efi | Bin 0 -> 11712 bytes arch/arm/lib/Makefile | 6

[U-Boot] [PATCH 1/6] x86: Add implementations of setjmp() and longjmp()

Bring in these functions from Linux v4.4. They will be needed for EFI loader support. Signed-off-by: Simon Glass --- arch/x86/cpu/Makefile | 2 +- arch/x86/cpu/setjmp.S | 71 +++ arch/x86/include/asm/setjmp.h | 24

[U-Boot] [PATCH 2/6] efi: Fix missing EFIAPI specifiers

These are missing in some functions. Add them to keep things consistent. Signed-off-by: Simon Glass --- cmd/bootefi.c | 7 +-- include/efi_loader.h | 2 +- lib/efi_loader/efi_boottime.c | 5 +++-- lib/efi_loader/efi_disk.c | 13

Re: [U-Boot] [PATCH 0/2] rockchip: Initial RK3368 and GeekBox support

+Tom for comment Hi Andreas, On 6 August 2016 at 10:05, Andreas Färber wrote: > Hi Simon, > > Am 06.08.2016 um 06:30 schrieb Simon Glass: >> Hi Andreas, >> >> On 17 July 2016 at 19:06, Andreas Färber wrote: >>> Hi, >>> >>> This series adds initial support

[U-Boot] [PATCH 12/12] r2dplus: fixup CONFIG_SYS_TEXT_BASE to account arch/sh changes

This change allows to reserve enough space at the end of board SDRAM to store two copies of U-Boot and malloc heap. Due to selection of the CONFIG_SYS_TEXT_BASE the second code/data copying is not avoided, first of all this may depend on a used toolchain, secondly at this point some level of

[U-Boot] [PATCH 08/12] sh: add shared relocate_code() function and call board_init_r()

Commits b61e90e6fd83 ("sh: Drop the arch-specific board init") and f41e6088eb1a ("sh: Fix build errors for generic board") left code and data relocation done in start.S, however further actual U-boot configuration is not started anymore. Practically SH boards with the code relocated into the

[U-Boot] [PATCH 11/12] sh: generate position independent code for all platforms

Finally add fpic compilation option to produce relocatable code. Note that this requires to define CONFIG_NEEDS_MANUAL_RELOC for all board files, also relocation support still has some limitations (e.g. a developer should care not to overwrite the executing code or memset() with zeroes not yet

[U-Boot] [PATCH 05/12] sh: remove undefined DEBUG preprocessor token from board config files

By default this undef is a noop, moreover at this point when the platform support is broken is prevents debugging of U-boot by manual insertion of #define DEBUG into common files, so it makes sense to remove the option from all SH boards as a harmful one. Signed-off-by: Vladimir Zapolskiy

[U-Boot] [PATCH 06/12] sh: define CONFIG_DISPLAY_BOARDINFO to print board information

All SH boards define a checkboard() function which outputs basic board information on boot, however generic board support requires to define CONFIG_DISPLAY_BOARDINFO to do that, so define it for the boards. Signed-off-by: Vladimir Zapolskiy --- include/configs/MigoR.h | 1 +

[U-Boot] [PATCH 10/12] sh: share the correct version of start.S among all cpus

It is easy to note that SH2/SH3/SH4 start.S code is practically the same with a minor difference for SH2 where a short data header is present. To avoid unwanted code duplication and to automatically convert SH2 and SH3 platforms to generic board support move fixed SH4 start.S into

[U-Boot] [PATCH 07/12] sh: add common dram_init() function for all boards

Generic board support assumes a different method of specifying DRAM size on board, also it can be shared among all boards, notably only sh7763rdp board has a custom legacy dram_init(), however the difference is only in printing some additional information, this feature can be removed.

[U-Boot] [PATCH 04/12] sh: add MEMORY command to a shared linker script

At the moment in runtime all defined sections are copied into or created in RAM, specify this explicitly to assert potential out of RAM placements of the sections. Signed-off-by: Vladimir Zapolskiy --- arch/sh/cpu/u-boot.lds | 32 1 file changed,

[U-Boot] [PATCH 01/12] sh4: use single u-boot linker script for all boards

Three supported SH4/SH4A boards with the bootloader image stored on SPI flash have own flavour of a linker script, in turn they are equal among each other. The only difference is that the text from lowlevel_init.o is placed right after start.o, which makes sense. Note that .bss section is not

[U-Boot] [PATCH 00/12] sh: change arch and boards code to generic board

The changeset implements initial support of relocatable U-Boot code for SH2/SH3/SH4 architectures and boards, as weel as it restores a possibility to boot U-Boot on SH boards, which has not been converted to generic board in time (for more details see commit f41e6088eb1 ("sh: Fix build errors for

[U-Boot] [PATCH 09/12] sh4: fix start.S by calling board_init_f() after first code relocation

Like on ARM platform keep the first code relocation from a U-boot image storage to RAM at CONFIG_SYS_TEXT_BASE, then pass execution to a generic board_init_f() with empty GD flags. If CONFIG_SYS_TEXT_BASE is equal to a calculated by board_init_f() relocation address there will be no more code and

[U-Boot] [PATCH 02/12] sh: place board lowlevel_init code in the beginning of .text

Reference lowlevel_init of all supported SH2A/SH3/SH4/SH4A boards from a shared linker script, the lowlevel_init function will be called by a relative address. Signed-off-by: Vladimir Zapolskiy --- arch/sh/cpu/u-boot.lds | 2 +-

[U-Boot] [PATCH 03/12] sh: define entry point and reloc_dst inside a linker script

No functional change, concentrate linker script commands in one place for convenience. Entry point is set to CONFIG_SYS_TEXT_BASE by default on build, so this option can be omitted from being added to the linker script. Signed-off-by: Vladimir Zapolskiy --- arch/sh/config.mk

[U-Boot] [PATCH 5/5] r2dplus: select rtl8139 driver in defconfig

CONFIG_RTL8139 was moved to a board defconfig by a commit 86e9dc86b1a2 ("net: Move CONFIG_RTL8139 to Kconfig"), however it was done incorrectly due to a missing CONFIG_NETDEVICES selection, thus virtually it was just a removal of the driver compilation. As an unlucky consequence the option was

[U-Boot] [PATCH 2/5] pci: sh7751: map PCI memory space into SDRAM

For ease of use and accounting a condition that on SH4 pci_phys_to_bus() and pci_bus_to_phys() are one in one mappings due to unimplemented __iomem() conversion, this change fixes access to SDRAM memory by PCI devices. This change also generalizes PCI system memory configuration, which is taken

[U-Boot] [PATCH 1/5] pci: sh7751: fix up PCI I/O space address

The change actually maps PCI I/O window to the same address on PCI bus as it is stated by a comment, before the change transfers to the PCI I/O space are failed due to misconfiguration of the most significant 14 bits of the PCI address in PCIIOBR (note that it is set to 0x0). Most probably the

[U-Boot] [PATCH 3/5] sh4: remove __io config options from r2dplus and r7780mp boards

Defined __io is no-op for the SH architecture and it can be removed from board files without any functional change. Signed-off-by: Vladimir Zapolskiy --- arch/sh/include/asm/io.h | 10 -- include/configs/r2dplus.h | 1 - include/configs/r7780mp.h | 1 - 3 files

[U-Boot] [PATCH 4/5] r2dplus: use P1 area space for text base and PCI system memory

While both options are acceptable use P1 area physical addresses instead of external memory space of text base and PCI system memory for unification purposes, all other supported superh boards have the same selection. This allows to easily ensure that CONFIG_SYS_TEXT_BASE is located within

[U-Boot] [PATCH 0/5] sh4: fixes to SH7751 PCI host controller

This series fixes 2 bugs found in SH7751 PCI host controller driver, also it restores r2dplus defconfig and slightly simplifies the code related to the SH7751 PCI controller, more improvements may follow in future. The change is independent on the following conversion to generic board, however it

[U-Boot] [PATCH] common: sh: add necessary define bits to board_f

Since a platform conversion to generic board support has not been accomplished some architecture specific bits are missing from board_f init sequence, the change adds a number of basic expected callbacks into early init sequence. Signed-off-by: Vladimir Zapolskiy ---

Re: [U-Boot] [PATCH v3 6/6] xtensa: add support for the 'xtfpga' evaluation board

On Sat, Aug 06, 2016 at 02:00:44AM +0300, Max Filippov wrote: > From: Chris Zankel > > The 'xtfpga' board is actually a set of FPGA evaluation boards that > can be configured to run an Xtensa processor. > > - Avnet Xilinx LX60 > - Avnet Xilinx LX110 > - Avnet Xilinx LX200

Re: [U-Boot] [PATCH v3 5/6] xtensa: add core information for the de212 processor

On Sat, Aug 06, 2016 at 02:00:43AM +0300, Max Filippov wrote: > DE212 is a general purpose xtensa processor without full MMU. > Core information files are autogenerated from the processor description > and are not meant to be edited. > > Signed-off-by: Max Filippov

Re: [U-Boot] [PATCH v3 4/6] xtensa: add core information for the dc233c processor

On Sat, Aug 06, 2016 at 02:00:42AM +0300, Max Filippov wrote: > DC233C is an xtensa processor with full MMUv3 capable of running Linux. > Core information files are autogenerated from the processor description > and are not meant to be edited. > > Signed-off-by: Max Filippov

Re: [U-Boot] [PATCH v3 3/6] xtensa: add core information for the dc232b processor

On Sat, Aug 06, 2016 at 02:00:41AM +0300, Max Filippov wrote: > From: Chris Zankel > > DC232B is an xtensa processor with full MMUv2 capable of running Linux. > Core information files are autogenerated from the processor description > and are not meant to be edited. > >

Re: [U-Boot] Please pull u-boot-rockchip

On Fri, Aug 05, 2016 at 09:36:06PM -0600, Simon Glass wrote: > Hi Tom, > > There are still a few patches waiting for revision, but this is most > of them. It includes additional rk3399 support, a new miniarm board > and some refactoring. > > > The following changes since commit

Re: [U-Boot] [PATCH v3 1/6] xtensa: add support for the xtensa processor architecture [1/2]

On Sat, Aug 06, 2016 at 02:00:39AM +0300, Max Filippov wrote: > From: Chris Zankel > > The Xtensa processor architecture is a configurable, extensible, > and synthesizable 32-bit RISC processor core provided by Cadence. > > This is the first part of the basic architecture

Re: [U-Boot] [PATCH 1/2] bdinfo: Don't print out empty DRAM banks

On Fri, Aug 05, 2016 at 09:57:27PM -0600, Simon Glass wrote: > There is no sense in printing out DRAM banks of size 0 since this means they > are empty. Skip them. > > Signed-off-by: Simon Glass Reviewed-by: Tom Rini -- Tom signature.asc Description:

Re: [U-Boot] [PATCH v3 2/6] xtensa: add support for the xtensa processor architecture [2/2]

On Sat, Aug 06, 2016 at 02:00:40AM +0300, Max Filippov wrote: > From: Chris Zankel > > The Xtensa processor architecture is a configurable, extensible, > and synthesizable 32-bit RISC processor core provided by Tensilica, inc. > > This is the second part of the basic

Re: [U-Boot] [PATCH] tiny-printf: Adjust to avoid using data section

On Thu, Aug 04, 2016 at 09:58:14PM -0600, Simon Glass wrote: > We can pass all the variables down to the functions that need them, and > then everything is on the stack. This is safer than using the data section. > > At least on firefly-rk3288, the code size is the same and the data size is > 12

Re: [U-Boot] [PATCH 0/2] rockchip: Initial RK3368 and GeekBox support

Hi Simon, Am 06.08.2016 um 06:30 schrieb Simon Glass: > Hi Andreas, > > On 17 July 2016 at 19:06, Andreas Färber wrote: >> Hi, >> >> This series adds initial support for RK3368 SoC and GeekBox. >> For more details see the commit message. >> >> Will need to be rebased onto

[U-Boot] Prospective contributer

Hi All, I have been working as a Software/Firmware engineer for 10 years now, and keen to contribute to UBoot code base with some peripheral device driver patches. I would like to know the procedure to follow, and where should I create my patches (from main git repo or Custodians

Re: [U-Boot] [PATCH] sf: Disable 4-KB erase command for SPANSION S25FS128

Hi On Sat, Aug 6, 2016 at 5:08 PM, Jagan Teki wrote: > On 6 August 2016 at 20:10, Michael Trimarchi > wrote: > > I understand your point but I don't have enough part number and I can > only to > test on this one. I will

Re: [U-Boot] [PATCH] sf: Disable 4-KB erase command for SPANSION S25FS128

On 6 August 2016 at 20:10, Michael Trimarchi wrote: I understand your point but I don't have enough part number and I can only to test on this one. I will verify this patch too and put my review and drop my personal one. Anyway can you

Re: [U-Boot] [PATCH] sf: Disable 4-KB erase command for SPANSION S25FS128

On 22 June 2016 at 15:44, Yao Yuan wrote: > On 06/22/2016 06:08 PM, Michael Trimarchi wrote: >> On Wed, Jun 22, 2016 at 10:00:49AM +, Yao Yuan wrote: >> > On 06/22/2016 03:59 PM, Michael Trimarchi wrote: >> > > The S25FS128 is part of S25FS-S family physical sectors may be

Re: [U-Boot] [PATCH v3 6/6] xtensa: add support for the 'xtfpga' evaluation board

On Sat, Aug 6, 2016 at 4:41 AM, Simon Glass wrote: > On 5 August 2016 at 17:00, Max Filippov wrote: >> From: Chris Zankel >> >> The 'xtfpga' board is actually a set of FPGA evaluation boards that >> can be configured to run an Xtensa

Re: [U-Boot] [PATCH v3 2/6] xtensa: add support for the xtensa processor architecture [2/2]

On Sat, Aug 6, 2016 at 4:41 AM, Simon Glass wrote: > On 5 August 2016 at 17:00, Max Filippov wrote: >> From: Chris Zankel >> >> The Xtensa processor architecture is a configurable, extensible, >> and synthesizable 32-bit RISC processor

[U-Boot] [PATCH] drivers/sysreset: group sysreset drivers

Create drivers/sysreset and move sysreset-uclass and all sysreset drivers there. Signed-off-by: Max Filippov --- arch/arm/mach-rockchip/rk3036/Makefile | 1 - arch/arm/mach-rockchip/rk3036/reset_rk3036.c | 45 arch/arm/mach-rockchip/rk3288/Makefile

Re: [U-Boot] [PATCH v7] dm: at91: Add driver model support for the spi driver

On 31 July 2016 at 17:05, Jagan Teki wrote: > On 29 July 2016 at 06:08, Wenyou Yang wrote: >> Add driver model support while retaining the existing legacy code. >> This allows the driver to support boards that have converted to >> driver model as

Re: [U-Boot] [PATCH 1/2 RESEND] fdt_support: fdt_translate_address() blob const correctness

On 08/05/2016 09:36 PM, Simon Glass wrote: Hi Stephen, On 5 August 2016 at 19:41, Simon Glass wrote: On 5 August 2016 at 09:47, Stephen Warren wrote: From: Stephen Warren The next patch will call fdt_translate_address() from