[U-Boot] [PATCH v2] arm: dts: am33xx: sync DTS with Linux 4.13-rc4
From: Suniel Mahesh This re-syncs AM33xx DTS file with current file from Linux v4.13-rc4 to ensure a consistent configuration. Upstream Linux removed the redundant Interrupt-parent property from mmc, mac, lcdc and tscadc sub nodes. Signed-off-by: Suniel Mahesh --- Changes for v2: - Made corrections as suggested by Tom Rini - Rebased and compile tested on latest u-boot mainline tree no build issues. Note: - commit information upstream Linux: arm: dts: am33xx: Remove redundant interrupt-parent property sha1: de09eb52a1cceb6f80464a008c67c7bebb242314 --- arch/arm/dts/am33xx.dtsi | 6 -- 1 file changed, 6 deletions(-) diff --git a/arch/arm/dts/am33xx.dtsi b/arch/arm/dts/am33xx.dtsi index b26e21b..14caee7 100644 --- a/arch/arm/dts/am33xx.dtsi +++ b/arch/arm/dts/am33xx.dtsi @@ -315,7 +315,6 @@ &edma 25>; dma-names = "tx", "rx"; interrupts = <64>; - interrupt-parent = <&intc>; reg = <0x4806 0x1000>; status = "disabled"; }; @@ -328,7 +327,6 @@ &edma 3>; dma-names = "tx", "rx"; interrupts = <28>; - interrupt-parent = <&intc>; reg = <0x481d8000 0x1000>; status = "disabled"; }; @@ -338,7 +336,6 @@ ti,hwmods = "mmc3"; ti,needs-special-reset; interrupts = <29>; - interrupt-parent = <&intc>; reg = <0x4781 0x1000>; status = "disabled"; }; @@ -724,7 +721,6 @@ 0x4a101200 0x100>; #address-cells = <1>; #size-cells = <1>; - interrupt-parent = <&intc>; /* * c0_rx_thresh_pend * c0_rx_pend @@ -787,7 +783,6 @@ lcdc: lcdc@4830e000 { compatible = "ti,am33xx-tilcdc"; reg = <0x4830e000 0x1000>; - interrupt-parent = <&intc>; interrupts = <36>; ti,hwmods = "lcdc"; status = "disabled"; @@ -796,7 +791,6 @@ tscadc: tscadc@44e0d000 { compatible = "ti,am3359-tscadc"; reg = <0x44e0d000 0x1000>; - interrupt-parent = <&intc>; interrupts = <16>; ti,hwmods = "adc_tsc"; status = "disabled"; -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 4/5] arm: socfpga: Add intermediate driver between flash and FPGA manager
On Jum, 2017-08-11 at 17:09 +0200, Marek Vasut wrote: > On 08/10/2017 06:43 AM, Chee, Tien Fong wrote: > > > > On Rab, 2017-08-09 at 10:29 +0200, Marek Vasut wrote: > > > > > > On 08/09/2017 06:50 AM, Chee, Tien Fong wrote: > > > [...] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If this is for some FPGA loading, can this functionality > > > > > > > be > > > > > > > scripted > > > > > > > instead? > > > > > > > > > > > > > Sorry, i'm not getting you. How functionality be scripted? > > > > > > Could > > > > > > you > > > > > > provide some example or details explanation? > > > > > ie. "load" (from fs) + "fpga load" (program FPGA) commands ? > > > > > I think the fpga command already has some support for loading > > > > > from FS > > > > > too. > > > > > > > > > Currently, we already have fpga load commands in fpga driver, > > > > fpga > > > > rbf > > > > is loaded to memory, and programmed to fpga from memory, where > > > > memory > > > > location would be decided by user, it could be OCRAM or SDRAM. > > > > > > > > for fpga loadfs command, i plan to implement it after having > > > > complete > > > > boot to U-boot console, since this is quite complex and > > > > involving > > > > some > > > > hardware workaround issue, and some use case scenarios need to > > > > be > > > > considerd. > > > So the arria10 u-boot port is still unable to boot to console ? > > > > > Still need 2 to 3 more patchsets to get it boot to console. > > > > > > > > > > > > > > > For example reconfiguring fpga with periperal rbf can > > > > corrupt the sdram since sdram IOs is part of the fpga periph > > > > rbf. I > > > > need console to run a lot different scenarios testing. > > > OK > > > > > > > > > > > > > > > We still need cff.c, because most functionality in cff.c are > > > > required > > > > by fpga loadfs command. > > > It seems a lot of stuff from this is common code, so why does it > > > have > > > to > > > be in this driver again ? > > This driver contains a lot "smart" functionality such as: > I start to cringe when I read "smart functionality". > > > > > 1: It having ability to the right memory(OCRAM or SDRAM) to achieve > > the > > best FPGA programing performance. > Did you find significant throughput difference ? > 80% performance improvement with SDRAM. > > > > 2: It can determine the right size buffer for the fpga rbf without > > info > > of buffer size defined by user. > You mean like $filesize variable in the command prompt ? > Yeah. No filesize is required. > > > > 3: It has ability to know what kind of fpga rbf type, and security > > type, such as peripheral, core, combined rbf, encryption and > > unencryption based on any fpga file user pass in . > Is this information used for anything ? I was under the impression > that > the user just needs to load in the correct RBF file into the FPGA. > Yeah, the driver would decode the RBF image to know what type of RBF user loading, and applying correct method(buffer allocation, which memory to use and configuration on FPGA manager) to program FPGA. > > > > 4: It supports the checksum. > What checksum ? Can we have a generic hook into the FPGA framework ? > This checksum is to ensure integrity of RBF file after loading from flash into SDRAM. This can help to prevent possibility system instability caused by programming corrupt rbf into FPGA. So, this should be implemented in cff.c . > > > > 5: support raw flash without fs. > This should go into common code. > raw flash is part of common codes in cff.c because it is part of mechanism like fs to determine how loading rbf from flash and program into fpga. > > > > 6: support the file name defined in DTS and U-boot environment > > variable. > I think you should extend the FPGA LOADFS here instead. > The peripheral rbf filename and DTS are generated from our bsp tool. But user can run fpga loadfs to reconfigure FPGA in U-boot console after i have supported it. > > > > > > > > Also, the ifdeffery is awful and the explicit > > > depedence on VFAT when loading from FS is real bad. > > > > > It is because a lot functions is common to sdmmc, nand and qspi in > > different fs such as vfat, ubi and raw. It is unavoidable to have > > some > > ifdeffery if we want to keep the function common to all flashes and > > fs. > Can the FPGA LOADFS be extended generically ? > Yeah, FPGA loadfs is considered when design cff.c. But, i plan to to support FPGA loadfs after having complete boot to U-boot console. > > > > > > > > [...] > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/5] arm: socfpga: Add checking function on FPGA setting in FDT
On Jum, 2017-08-11 at 17:01 +0200, Marek Vasut wrote: > On 08/10/2017 06:51 AM, Chee, Tien Fong wrote: > > > > On Rab, 2017-08-09 at 10:20 +0200, Marek Vasut wrote: > > > > > > On 08/09/2017 07:07 AM, Chee, Tien Fong wrote: > > > > > > > > > > > > On Sel, 2017-08-08 at 11:29 +0200, Marek Vasut wrote: > > > > > > > > > > > > > > > On 08/08/2017 11:12 AM, tien.fong.c...@intel.com wrote: > > > > > > > > > > > > > > > > > > > > > > > > From: Tien Fong Chee > > > > > > > > > > > > Function for checking FPGA early release setting which is > > > > > > defined > > > > > > by user in FDT chosen section. This function would be used > > > > > > by > > > > > > later driver in decision applying appropriate FPGA > > > > > > configuration in > > > > > > early release or full FPGA booting mode. > > > > > Isn't this a property of the FPGA driver ? > > This is not property of fpga driver. It acts like passing data flag > > to > > u-boot, so u-boot knows how to boot in the mode defined by user. > So it's a configuration option ? Doing what ... since there's no > binding > document, it's not clear. > Okay, i can add decription into / doc / device-tree-bindings / chosen.txt. > > > > > > > > > > > > > > > > > > > Shouldn't this have altr, prefix ? > > This node doesn't represet a real device, it acts like a place for > > passing data to U-boot. So, this flag name doesn't matter with > > prefix, > > right? > But it's altera-specific, so it should have one ? > Yeah, i can add it. > > > > > > > > > > > > > > > > > > > Did this go through DT binding review? > > No, refer my explanation above. > > > > > > > > > > > > > > > > > > > > > This is our own define under chosen section. This is flag to > > > > tell > > > > U- > > > > boot what kind of boot and what kind of fpga configuration we > > > > want > > > > during boot. > > > And you didn't answer any of the aforementioned questions :( > > > > > Sorry, it could be i misunderstand your question. please refer my > > asnwer in above. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Signed-off-by: Tien Fong Chee > > > > > > --- > > > > > > arch/arm/mach-socfpga/include/mach/misc.h | 1 + > > > > > > arch/arm/mach-socfpga/misc_arria10.c | 20 > > > > > > > > > > > > 2 files changed, 21 insertions(+) > > > > > > > > > > > > diff --git a/arch/arm/mach-socfpga/include/mach/misc.h > > > > > > b/arch/arm/mach-socfpga/include/mach/misc.h > > > > > > index 0b65783..e003f8a 100644 > > > > > > --- a/arch/arm/mach-socfpga/include/mach/misc.h > > > > > > +++ b/arch/arm/mach-socfpga/include/mach/misc.h > > > > > > @@ -26,6 +26,7 @@ static inline void socfpga_fpga_add(void) > > > > > > {} > > > > > > unsigned int dedicated_uart_com_port(const void *blob); > > > > > > unsigned int shared_uart_com_port(const void *blob); > > > > > > unsigned int uart_com_port(const void *blob); > > > > > > +int is_early_release_fpga_config(const void *blob); > > > > > > #endif > > > > > > > > > > > > #endif /* _MISC_H_ */ > > > > > > diff --git a/arch/arm/mach-socfpga/misc_arria10.c > > > > > > b/arch/arm/mach- > > > > > > socfpga/misc_arria10.c > > > > > > index 9d751f6..2d6e977 100644 > > > > > > --- a/arch/arm/mach-socfpga/misc_arria10.c > > > > > > +++ b/arch/arm/mach-socfpga/misc_arria10.c > > > > > > @@ -235,6 +235,26 @@ unsigned int uart_com_port(const void > > > > > > *blob) > > > > > > return shared_uart_com_port(blob); > > > > > > } > > > > > > > > > > > > +int is_chosen_boolean_true(const void *blob, const char > > > > > > *name) > > > > > > +{ > > > > > > + int node; > > > > > > + int rval = 0; > > > > > > + > > > > > > + node = fdt_subnode_offset(blob, 0, "chosen"); > > > > > > + > > > > > > + if (node >= 0) > > > > > > + rval = fdtdec_get_bool(blob, node, name); > > > > > > + > > > > > > + return rval; > > > > > > +} > > > > > > + > > > > > > +int is_early_release_fpga_config(const void *blob) > > > > > > +{ > > > > > > + static const char *name = "early-release-fpga- > > > > > > config"; > > > > > > + > > > > > > + return is_chosen_boolean_true(blob, name); > > > > > > +} > > > > > > + > > > > > > /* > > > > > > * Print CPU information > > > > > > */ > > > > > > > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 0/2] improve hello_world standalone application for arm
This series addresses - hardcoded entry address, use LOADADDR if available as the entry point instead - fix thumb build, jumping with 'go' to the entry point expects arm code Note that in addition to the two fixes I've seen random freezes or 'random' printed stuff when using an early linaro gcc 6 compiler. Adding an initialized variable helped in that case static int dummy_var_in_text = 1; I assume that this forces alignment of some linker sections. (e.g. I see that __bss_start points to 0x1201027e, with the variable this moves to 0x12010280) However with the current linaro compilers this does not happen so I don't propose a patch for this issue. Linaro GCC 5.4-2017.05 5.4.1 20170404 Linaro GCC 6.3-2017.05 6.3.1 20170404 Linaro GCC 7.1-2017.05 7.1.1 20170510 This series is available at http://git.toradex.com/cgit/u-boot-toradex.git/log/?h=for-next Max Krummenacher (2): arm: use $loadaddr as the standalone entry point hello_world.c: fix entry point in case of arm thumb binary arch/arm/config.mk| 4 doc/README.standalone | 2 +- examples/standalone/hello_world.c | 15 +++ 3 files changed, 20 insertions(+), 1 deletion(-) -- 2.13.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/2] hello_world.c: fix entry point in case of arm thumb binary
If compiling for thumb the U-Boot 'go' command can not jump to the entry point, as the jump will be done in the assumption that the code jumped to is using the arm instruction set. So add add a simple forwarder in arm instruction set which then jumps to the 'real' entry. Signed-off-by: Max Krummenacher --- examples/standalone/hello_world.c | 15 +++ 1 file changed, 15 insertions(+) diff --git a/examples/standalone/hello_world.c b/examples/standalone/hello_world.c index bd8b392315..0b859ca4bd 100644 --- a/examples/standalone/hello_world.c +++ b/examples/standalone/hello_world.c @@ -8,6 +8,21 @@ #include #include +/* + * Make thumb work by providing a forwarder to the (thumb) entry point + * compiled for arm instruction set. + * Don't compile this for thumb only CPUs. + */ +#if defined(__thumb__) && defined(__ARM_ARCH_ISA_ARM) +void __attribute__((unused)) __attribute__ ((naked)) dummy2(void) +{ +asm volatile( \ +" .code 32\n" \ +" .arm\n" \ +" ldr pc,=hello_world\n"); +} +#endif + int hello_world (int argc, char * const argv[]) { int i; -- 2.13.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/2] arm: use $loadaddr as the standalone entry point
Different SoCs have different RAM layouts, so providing $(CONFIG_LOADADDR) instead of the constant 0xc10 for CONFIG_STANDALONE_LOAD_ADDR is probably more appropriate. Signed-off-by: Max Krummenacher --- arch/arm/config.mk| 4 doc/README.standalone | 2 +- 2 files changed, 5 insertions(+), 1 deletion(-) diff --git a/arch/arm/config.mk b/arch/arm/config.mk index 1a9db4..8f56c7433f 100644 --- a/arch/arm/config.mk +++ b/arch/arm/config.mk @@ -9,7 +9,11 @@ ifndef CONFIG_STANDALONE_LOAD_ADDR ifneq ($(CONFIG_ARCH_OMAP2PLUS),) CONFIG_STANDALONE_LOAD_ADDR = 0x8030 else +ifndef CONFIG_LOADADDR CONFIG_STANDALONE_LOAD_ADDR = 0xc10 +else +CONFIG_STANDALONE_LOAD_ADDR = $(CONFIG_LOADADDR) +endif endif endif diff --git a/doc/README.standalone b/doc/README.standalone index 659a12f6cb..17d740c44b 100644 --- a/doc/README.standalone +++ b/doc/README.standalone @@ -53,7 +53,7 @@ Design Notes on Exporting U-Boot Functions to Standalone Applications: Load addressStart address x86 0x0004 0x0004 PowerPC 0x0004 0x00040004 - ARM 0x0c10 0x0c10 + ARM CONFIG_LOADADDR CONFIG_LOADADDR MIPS0x8020 0x8020 Blackfin0x1000 0x1000 NDS32 0x0030 0x0030 -- 2.13.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] Convert CONFIG_BCH to Kconfig
This converts the following to Kconfig: CONFIG_BCH Signed-off-by: Adam Ford --- configs/am3517_evm_defconfig | 1 + configs/igep0020_defconfig | 1 + configs/igep0030_defconfig | 1 + configs/igep0032_defconfig | 1 + configs/km_kirkwood_128m16_defconfig | 1 + configs/km_kirkwood_defconfig| 1 + configs/km_kirkwood_pci_defconfig| 1 + configs/kmcoge4_defconfig| 1 + configs/kmcoge5ne_defconfig | 1 + configs/kmcoge5un_defconfig | 1 + configs/kmlion1_defconfig| 1 + configs/kmnusa_defconfig | 1 + configs/kmsugp1_defconfig| 1 + configs/kmsuv31_defconfig| 1 + configs/kmtegr1_defconfig| 1 + configs/mgcoge3un_defconfig | 1 + configs/omap3_logic_defconfig| 1 + configs/omap3_overo_defconfig| 1 + configs/portl2_defconfig | 1 + configs/tricorder_defconfig | 1 + configs/tricorder_flash_defconfig| 1 + configs/x600_defconfig | 1 + doc/README.nand | 6 -- include/configs/am3517_evm.h | 1 - include/configs/km/km_arm.h | 1 - include/configs/km/kmp204x-common.h | 2 -- include/configs/km8360.h | 1 - include/configs/omap3_igep00x0.h | 1 - include/configs/omap3_logic.h| 1 - include/configs/omap3_overo.h| 2 -- include/configs/suvd3.h | 1 - include/configs/tricorder.h | 1 - include/configs/x600.h | 1 - lib/Kconfig | 7 +++ scripts/config_whitelist.txt | 1 - 35 files changed, 29 insertions(+), 19 deletions(-) diff --git a/configs/am3517_evm_defconfig b/configs/am3517_evm_defconfig index 4e4aadb..c7e7dc4 100644 --- a/configs/am3517_evm_defconfig +++ b/configs/am3517_evm_defconfig @@ -43,4 +43,5 @@ CONFIG_SYS_NS16550=y CONFIG_USB=y CONFIG_USB_MUSB_HOST=y CONFIG_USB_STORAGE=y +CONFIG_BCH=y CONFIG_OF_LIBFDT=y diff --git a/configs/igep0020_defconfig b/configs/igep0020_defconfig index 745d6f6..41ac579 100644 --- a/configs/igep0020_defconfig +++ b/configs/igep0020_defconfig @@ -41,5 +41,6 @@ CONFIG_SYS_NAND_BUSWIDTH_16BIT=y CONFIG_MTD_UBI_FASTMAP=y CONFIG_SYS_NS16550=y CONFIG_FAT_WRITE=y +CONFIG_BCH=y CONFIG_OF_LIBFDT=y CONFIG_FDT_FIXUP_PARTITIONS=y diff --git a/configs/igep0030_defconfig b/configs/igep0030_defconfig index 48b80ae..14397c5 100644 --- a/configs/igep0030_defconfig +++ b/configs/igep0030_defconfig @@ -40,5 +40,6 @@ CONFIG_MMC_OMAP_HS=y CONFIG_SYS_NAND_BUSWIDTH_16BIT=y CONFIG_SYS_NS16550=y CONFIG_FAT_WRITE=y +CONFIG_BCH=y CONFIG_OF_LIBFDT=y CONFIG_FDT_FIXUP_PARTITIONS=y diff --git a/configs/igep0032_defconfig b/configs/igep0032_defconfig index 8ecd6a5..c44cb15 100644 --- a/configs/igep0032_defconfig +++ b/configs/igep0032_defconfig @@ -32,5 +32,6 @@ CONFIG_MMC_OMAP_HS=y CONFIG_SYS_NAND_BUSWIDTH_16BIT=y CONFIG_SYS_NS16550=y CONFIG_FAT_WRITE=y +CONFIG_BCH=y CONFIG_OF_LIBFDT=y CONFIG_FDT_FIXUP_PARTITIONS=y diff --git a/configs/km_kirkwood_128m16_defconfig b/configs/km_kirkwood_128m16_defconfig index bbc43c0..100c337 100644 --- a/configs/km_kirkwood_128m16_defconfig +++ b/configs/km_kirkwood_128m16_defconfig @@ -28,4 +28,5 @@ CONFIG_CMD_UBI=y CONFIG_SPI_FLASH=y CONFIG_SPI_FLASH_STMICRO=y CONFIG_SYS_NS16550=y +CONFIG_BCH=y CONFIG_OF_LIBFDT=y diff --git a/configs/km_kirkwood_defconfig b/configs/km_kirkwood_defconfig index 5a0bafe..330805a 100644 --- a/configs/km_kirkwood_defconfig +++ b/configs/km_kirkwood_defconfig @@ -28,4 +28,5 @@ CONFIG_CMD_UBI=y CONFIG_SPI_FLASH=y CONFIG_SPI_FLASH_STMICRO=y CONFIG_SYS_NS16550=y +CONFIG_BCH=y CONFIG_OF_LIBFDT=y diff --git a/configs/km_kirkwood_pci_defconfig b/configs/km_kirkwood_pci_defconfig index 5c58244..85588ae 100644 --- a/configs/km_kirkwood_pci_defconfig +++ b/configs/km_kirkwood_pci_defconfig @@ -28,4 +28,5 @@ CONFIG_CMD_UBI=y CONFIG_SPI_FLASH=y CONFIG_SPI_FLASH_STMICRO=y CONFIG_SYS_NS16550=y +CONFIG_BCH=y CONFIG_OF_LIBFDT=y diff --git a/configs/kmcoge4_defconfig b/configs/kmcoge4_defconfig index 854b4d2..437990f 100644 --- a/configs/kmcoge4_defconfig +++ b/configs/kmcoge4_defconfig @@ -39,4 +39,5 @@ CONFIG_PHY_GIGE=y CONFIG_E1000=y CONFIG_SYS_NS16550=y CONFIG_FSL_ESPI=y +CONFIG_BCH=y CONFIG_OF_LIBFDT=y diff --git a/configs/kmcoge5ne_defconfig b/configs/kmcoge5ne_defconfig index 16f51da..a49e9ae 100644 --- a/configs/kmcoge5ne_defconfig +++ b/configs/kmcoge5ne_defconfig @@ -25,4 +25,5 @@ CONFIG_CMD_UBI=y CONFIG_MTD_NOR_FLASH=y # CONFIG_PCI is not set CONFIG_SYS_NS16550=y +CONFIG_BCH=y CONFIG_OF_LIBFDT=y diff --git a/configs/kmcoge5un_defconfig b/configs/kmcoge5un_defconfig index 333130e..044c06a 100644 --- a/configs/kmcoge5un_defconfig +++ b/configs/kmcoge5un_defconfig @@ -28,4 +28,5 @@ CONFIG_CMD_UBI=y CONFIG_SPI_FLASH=y CONFIG_SPI_FLASH_STMICRO=y CONFIG_SYS_NS16550=y +CONFIG_BCH=y CONFIG_OF_LIBFDT=y diff --git a/configs/kmlion1_defconfig b/configs/kmlion1_defcon
Re: [U-Boot] [PATCH v1 02/15] fs/fat: implement readdir
On 10.08.17 20:29, Rob Clark wrote: Yes, this is super-hacky. The FAT code is quite ugly, and this doesn't improve things. But it doesn't make it significantly worse either. The better option would be a massive FAT re-write to get rid of the hacky way that fat_file_ls() works. Volunteers welcome. Signed-off-by: Rob Clark What concerns me the most in patch 1/15 and this patch is the limited scope. Yes, you make readdir work for FAT, but all other file systems are still unimplemented. In fact, they're even all still implementing their own hand-written ls logic. One of the goals of the efi_loader code is to integrate with U-Boot as much as possible, to reuse code where we can. And if current interfaces are terrible, I think it's ok to just replace them for something that fits everyone's needs better. How feasible do you think it would be to implement an ls function based on readdir and just convert all file systems to it, completely replacing the current (quite crude) ls logic? Alex ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 03/15] part: extract MBR signature from partitions
On 10.08.17 20:29, Rob Clark wrote: From: Peter Jones EFI client programs need the signature information from the partition table to determine the disk a partition is on, so we need to fill that in here. Signed-off-by: Peter Jones [separated from efi_loader part, and fixed build-errors for non- CONFIG_EFI_PARTITION case] Signed-off-by: Rob Clark --- disk/part_dos.c| 12 +--- disk/part_efi.c| 20 include/blk.h | 15 +++ include/efi.h | 4 include/part.h | 3 ++- include/part_efi.h | 4 6 files changed, 50 insertions(+), 8 deletions(-) diff --git a/disk/part_dos.c b/disk/part_dos.c index 7ede15ec26..850a538e83 100644 --- a/disk/part_dos.c +++ b/disk/part_dos.c @@ -89,14 +89,20 @@ static int test_block_type(unsigned char *buffer) static int part_test_dos(struct blk_desc *dev_desc) { - ALLOC_CACHE_ALIGN_BUFFER(unsigned char, buffer, dev_desc->blksz); + ALLOC_CACHE_ALIGN_BUFFER(legacy_mbr, mbr, dev_desc->blksz); - if (blk_dread(dev_desc, 0, 1, (ulong *)buffer) != 1) + if (blk_dread(dev_desc, 0, 1, (ulong *)mbr) != 1) return -1; - if (test_block_type(buffer) != DOS_MBR) + if (test_block_type((unsigned char *)mbr) != DOS_MBR) return -1; + if (dev_desc->sig_type == SIG_TYPE_NONE && + mbr->unique_mbr_signature != 0) { + dev_desc->sig_type = SIG_TYPE_MBR; + dev_desc->mbr_sig = mbr->unique_mbr_signature; + } + return 0; } diff --git a/disk/part_efi.c b/disk/part_efi.c index 1b7ba27947..71e4188455 100644 --- a/disk/part_efi.c +++ b/disk/part_efi.c @@ -871,11 +871,19 @@ static int is_pmbr_valid(legacy_mbr * mbr) static int is_gpt_valid(struct blk_desc *dev_desc, u64 lba, gpt_header *pgpt_head, gpt_entry **pgpt_pte) { + ALLOC_CACHE_ALIGN_BUFFER(legacy_mbr, mbr, dev_desc->blksz); + if (!dev_desc || !pgpt_head) { printf("%s: Invalid Argument(s)\n", __func__); return 0; } + /* Read MBR Header from device */ + if (blk_dread(dev_desc, 0, 1, (ulong *)mbr) != 1) { + printf("*** ERROR: Can't read MBR header ***\n"); + return 0; + } + /* Read GPT Header from device */ if (blk_dread(dev_desc, (lbaint_t)lba, 1, pgpt_head) != 1) { printf("*** ERROR: Can't read GPT header ***\n"); @@ -885,6 +893,18 @@ static int is_gpt_valid(struct blk_desc *dev_desc, u64 lba, if (validate_gpt_header(pgpt_head, (lbaint_t)lba, dev_desc->lba)) return 0; + if (dev_desc->sig_type == SIG_TYPE_NONE) { + efi_guid_t empty = {}; + if (memcmp(&pgpt_head->disk_guid, &empty, sizeof(empty))) { + dev_desc->sig_type = SIG_TYPE_GUID; + memcpy(&dev_desc->guid_sig, &pgpt_head->disk_guid, + sizeof(empty)); + } else if (mbr->unique_mbr_signature != 0) { + dev_desc->sig_type = SIG_TYPE_MBR; + dev_desc->mbr_sig = mbr->unique_mbr_signature; + } + } + /* Read and allocate Partition Table Entries */ *pgpt_pte = alloc_read_gpt_entries(dev_desc, pgpt_head); if (*pgpt_pte == NULL) { diff --git a/include/blk.h b/include/blk.h index ef29a07ee2..3a5e04c00d 100644 --- a/include/blk.h +++ b/include/blk.h @@ -8,6 +8,8 @@ #ifndef BLK_H #define BLK_H +#include + #ifdef CONFIG_SYS_64BIT_LBA typedef uint64_t lbaint_t; #define LBAFlength "ll" @@ -35,6 +37,14 @@ enum if_type { IF_TYPE_COUNT, /* Number of interface types */ }; +enum sig_type { + SIG_TYPE_NONE, + SIG_TYPE_MBR, + SIG_TYPE_GUID, + + SIG_TYPE_COUNT /* Number of signature types */ +}; + /* * With driver model (CONFIG_BLK) this is uclass platform data, accessible * with dev_get_uclass_platdata(dev) @@ -62,6 +72,11 @@ struct blk_desc { charvendor[40+1]; /* IDE model, SCSI Vendor */ charproduct[20+1]; /* IDE Serial no, SCSI product */ charrevision[8+1]; /* firmware revision */ + enum sig_type sig_type; /* Partition table signature type */ + union { + uint32_t mbr_sig; /* MBR integer signature */ + efi_guid_t guid_sig;/* GPT GUID Signature */ + }; #ifdef CONFIG_BLK /* * For now we have a few functions which take struct blk_desc as a diff --git a/include/efi.h b/include/efi.h index 02b78b31b1..87b0b43f20 100644 --- a/include/efi.h +++ b/include/efi.h @@ -28,6 +28,10 @@ struct efi_device_path; +typedef struct { + u8 b[16]; +} efi_guid_t; + #define EFI_BITS_PER_LONG BITS_PER_LONG /* diff --git a/include/part.h b/include/part.h index 83bce05a43..ac5ee895e9 100644 --
Re: [U-Boot] [PATCH v1 04/15] efi: add some more device path structures
On 10.08.17 20:29, Rob Clark wrote: From: Peter Jones Signed-off-by: Peter Jones Signed-off-by: Rob Clark --- include/efi_api.h | 62 +++ 1 file changed, 58 insertions(+), 4 deletions(-) diff --git a/include/efi_api.h b/include/efi_api.h index ec1b321e8e..b761cf4822 100644 --- a/include/efi_api.h +++ b/include/efi_api.h @@ -284,28 +284,82 @@ struct efi_device_path { u8 type; u8 sub_type; u16 length; -}; +} __packed; This does not match the patch description. Please have additions in one and packed fixups in a different patch. Alex ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 08/15] efi_loader: use proper device-paths for partitions
On 10.08.17 20:29, Rob Clark wrote: Also, create disk objects for the disk itself, in addition to the partitions. (UEFI terminology is a bit confusing, a "disk" object is really a partition.) This helps grub properly identify the boot device since it is trying to match up partition "disk" object with it's parent device. Now instead of seeing devices like: /File(sd...@07864000.blk)/EndEntire /File(usb_mass_storage.lun0)/EndEntire You see: /ACPI(133741d0,0)/UnknownMessaging(1d)/EndEntire /ACPI(133741d0,0)/UnknownMessaging(1d)/HD(0,800,64000,dd904a8c,1,1)/EndEntire /ACPI(133741d0,0)/UnknownMessaging(1d)/HD(1,64800,20,dd904a8c,1,1)/EndEntire /ACPI(133741d0,0)/UnknownMessaging(1d)/HD(2,264800,19a000,dd904a8c,1,1)/EndEntire /ACPI(133741d0,0)/USB(0,0)/USB(0,0)/USB(0,0)/EndEntire /ACPI(133741d0,0)/USB(0,0)/USB(0,0)/USB(0,0)/HD(0,800,6,38ca6802,1,1)/EndEntire /ACPI(133741d0,0)/USB(0,0)/USB(0,0)/USB(0,0)/HD(1,61000,155000,38ca6802,1,1)/EndEntire /ACPI(133741d0,0)/USB(0,0)/USB(0,0)/USB(0,0)/HD(2,20fa800,1bbf8800,38ca6802,1,1)/EndEntire /ACPI(133741d0,0)/USB(0,0)/USB(0,0)/USB(0,0)/HD(3,1b6800,1f44000,38ca6802,1,1)/EndEntire This is on a board with single USB disk and single sd-card. The UnknownMessaging(1d) node in the device-path is the MMC device, but grub_efi_print_device_path() hasn't been updated yet for some of the newer device-path sub-types. This patch is inspired by a patch originally from Peter Jones, but re-worked to use efi_device_path, so it doesn't much resemble the original. Signed-off-by: Rob Clark --- lib/efi_loader/efi_disk.c | 54 +++ 1 file changed, 31 insertions(+), 23 deletions(-) diff --git a/lib/efi_loader/efi_disk.c b/lib/efi_loader/efi_disk.c index ed06485e33..eea65a402a 100644 --- a/lib/efi_loader/efi_disk.c +++ b/lib/efi_loader/efi_disk.c @@ -28,11 +28,13 @@ struct efi_disk_obj { /* EFI Interface Media descriptor struct, referenced by ops */ struct efi_block_io_media media; /* EFI device path to this block device */ - struct efi_device_path_file_path *dp; + struct efi_device_path *dp; + /* partition # */ + unsigned part; /* Offset into disk for simple partitions */ lbaint_t offset; /* Internal block device */ - const struct blk_desc *desc; + struct blk_desc *desc; }; static efi_status_t EFIAPI efi_disk_reset(struct efi_block_io *this, @@ -172,26 +174,26 @@ static const struct efi_block_io block_io_disk_template = { static void efi_disk_add_dev(const char *name, const char *if_typename, -const struct blk_desc *desc, +struct blk_desc *desc, int dev_index, -lbaint_t offset) +lbaint_t offset, +unsigned part) { struct efi_disk_obj *diskobj; - struct efi_device_path_file_path *dp; - int objlen = sizeof(*diskobj) + (sizeof(*dp) * 2); /* Don't add empty devices */ if (!desc->lba) return; - diskobj = calloc(1, objlen); + diskobj = calloc(1, sizeof(*diskobj)); /* Fill in object data */ - dp = (void *)&diskobj[1]; + diskobj->dp = efi_dp_from_part(desc, part); + diskobj->part = part; diskobj->parent.protocols[0].guid = &efi_block_io_guid; diskobj->parent.protocols[0].protocol_interface = &diskobj->ops; diskobj->parent.protocols[1].guid = &efi_guid_device_path; - diskobj->parent.protocols[1].protocol_interface = dp; + diskobj->parent.protocols[1].protocol_interface = diskobj->dp; diskobj->parent.handle = diskobj; diskobj->ops = block_io_disk_template; diskobj->ifname = if_typename; @@ -207,17 +209,6 @@ static void efi_disk_add_dev(const char *name, diskobj->media.last_block = desc->lba - offset; diskobj->ops.media = &diskobj->media; - /* Fill in device path */ - diskobj->dp = dp; - dp[0].dp.type = DEVICE_PATH_TYPE_MEDIA_DEVICE; - dp[0].dp.sub_type = DEVICE_PATH_SUB_TYPE_FILE_PATH; - dp[0].dp.length = sizeof(*dp); - ascii2unicode(dp[0].str, name); - - dp[1].dp.type = DEVICE_PATH_TYPE_END; - dp[1].dp.sub_type = DEVICE_PATH_SUB_TYPE_END; - dp[1].dp.length = sizeof(*dp); - /* Hook up to the device list */ list_add_tail(&diskobj->parent.link, &efi_obj_list); } @@ -236,14 +227,18 @@ static int efi_disk_create_eltorito(struct blk_desc *desc, if (desc->part_type != PART_TYPE_ISO) return 0; + /* and devices for each partition: */ while (!part_get_info(desc, part, &info)) { snprintf(devname, sizeof(devname), "%s:%d", pdevname, part); efi
Re: [U-Boot] [PATCH v1 14/15] efi_loader: efi variable support
On 10.08.17 20:29, Rob Clark wrote: Add EFI variable support, mapping to u-boot environment variables. Variables are pretty important for setting up boot order, among other things. If the board supports saveenv, then it will be called in ExitBootServices() to persist variables set by the efi payload. (For example, fallback.efi configuring BootOrder and Boot load-option variables.) Variables are *not* currently exposed at runtime, post ExitBootServices. On boards without a dedicated device for storage, which the loaded OS is not trying to also use, this is rather tricky. One idea, at least for boards that can persist RAM across reboot, is to keep a "journal" of modified variables in RAM, and then turn halt into a reboot into u-boot, plus store variables, plus halt. Whatever the solution, it likely involves some per-board support. Mapping between EFI variables and u-boot variables: efi_$guid_$varname = {attributes}(type)value For example: efi_8be4df61-93ca-11d2-aa0d-00e098032b8c_OsIndicationsSupported= "{ro,boot,run}(blob)" efi_8be4df61-93ca-11d2-aa0d-00e098032b8c_BootOrder= "(blob)0001" The attributes are a comma separated list of these possible attributes: + ro - read-only + boot - boot-services access + run - runtime access NOTE: with current implementation, no variables are available after ExitBootServices, and all are persisted (if possible). If not specified, the attributes default to "{boot}". The required type is one of: + utf8 - raw utf8 string + blob - arbitrary length hex string Signed-off-by: Rob Clark --- cmd/bootefi.c | 4 + include/efi.h | 19 +++ include/efi_loader.h | 10 ++ lib/efi_loader/Makefile | 2 +- lib/efi_loader/efi_boottime.c | 5 + lib/efi_loader/efi_runtime.c | 17 ++- lib/efi_loader/efi_variable.c | 342 ++ 7 files changed, 394 insertions(+), 5 deletions(-) create mode 100644 lib/efi_loader/efi_variable.c diff --git a/cmd/bootefi.c b/cmd/bootefi.c index b9e1e5e131..80f52e9e35 100644 --- a/cmd/bootefi.c +++ b/cmd/bootefi.c @@ -181,6 +181,10 @@ static unsigned long do_bootefi_exec(void *efi, void *fdt, goto exit; } + /* we don't support much: */ + setenv("efi_8be4df61-93ca-11d2-aa0d-00e098032b8c_OsIndicationsSupported", + "{ro,boot}(blob)"); + /* Call our payload! */ debug("%s:%d Jumping to 0x%lx\n", __func__, __LINE__, (long)entry); diff --git a/include/efi.h b/include/efi.h index ddd2b96417..dbd482a5db 100644 --- a/include/efi.h +++ b/include/efi.h @@ -324,6 +324,25 @@ extern char image_base[]; /* Start and end of U-Boot image (for payload) */ extern char _binary_u_boot_bin_start[], _binary_u_boot_bin_end[]; +/* + * Variable Attributes + */ +#define EFI_VARIABLE_NON_VOLATILE 0x0001 Shouldn't we honor this one too? A UEFI application may set runtime variables that should not get persisted across boots (think the UEFI shell setting some internal state thing, then booting Linux). +#define EFI_VARIABLE_BOOTSERVICE_ACCESS 0x0002 +#define EFI_VARIABLE_RUNTIME_ACCESS 0x0004 +#define EFI_VARIABLE_HARDWARE_ERROR_RECORD 0x0008 +#define EFI_VARIABLE_AUTHENTICATED_WRITE_ACCESS 0x0010 +#define EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS 0x0020 +#define EFI_VARIABLE_APPEND_WRITE 0x0040 + +#define EFI_VARIABLE_MASK (EFI_VARIABLE_NON_VOLATILE | \ + EFI_VARIABLE_BOOTSERVICE_ACCESS | \ + EFI_VARIABLE_RUNTIME_ACCESS | \ + EFI_VARIABLE_HARDWARE_ERROR_RECORD | \ + EFI_VARIABLE_AUTHENTICATED_WRITE_ACCESS | \ + EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS | \ + EFI_VARIABLE_APPEND_WRITE) + /** * efi_get_sys_table() - Get access to the main EFI system table * diff --git a/include/efi_loader.h b/include/efi_loader.h index efb93f31f7..9cb568e615 100644 --- a/include/efi_loader.h +++ b/include/efi_loader.h @@ -271,6 +271,16 @@ efi_status_t __efi_runtime EFIAPI efi_get_time( struct efi_time_cap *capabilities); void efi_get_time_init(void); +efi_status_t EFIAPI efi_get_variable(s16 *variable_name, + efi_guid_t *vendor, u32 *attributes, + unsigned long *data_size, void *data); +efi_status_t EFIAPI efi_get_next_variable( + unsigned long *variable_name_size, + s16 *variable_name, efi_guid_t *vendor); +efi_status_t EFIAPI efi_set_variable(s16 *variable_name, + efi_guid_t *vendor, u32 attributes, + unsigned long data_size, void *data); + #else /* defined(EFI_LOADER) && !defined(CONFIG_SPL_BUILD) */
Re: [U-Boot] [U-Boot, v2, 02/42] Convert CONFIG_CMD_MAX6957 to Kconfig
On Fri, Aug 04, 2017 at 04:34:26PM -0600, Simon Glass wrote: > This converts the following to Kconfig: >CONFIG_CMD_MAX6957 > > Signed-off-by: Simon Glass > Reviewed-by: Bin Meng > Reviewed-by: Philipp Tomsich Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot,v2,03/42] Kconfig: Drop CONFIG_CMD_MEM
On Fri, Aug 04, 2017 at 04:34:27PM -0600, Simon Glass wrote: > This is not actually used in U-Boot. Most likely it means > CONFIG_CMD_MEMORY so change all occurences to that. > > Signed-off-by: Simon Glass > Reviewed-by: Bin Meng > Reviewed-by: Philipp Tomsich Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 15/15] efi_loader: add bootmgr
On 10.08.17 20:29, Rob Clark wrote: Similar to a "real" UEFI implementation, the bootmgr looks at the BootOrder and Boot variables to try to find an EFI payload to load and boot. This is added as a sub-command of bootefi. The idea is that the distro bootcmd would first try loading a payload via the bootmgr, and then if that fails (ie. first boot or corrupted EFI variables) it would fallback to loading bootaa64.efi. (Which would then load fallback.efi which would look for \EFI\*\boot.csv and populate BootOrder and Boot based on what it found.) Signed-off-by: Rob Clark --- cmd/bootefi.c | 48 ++- include/config_distro_bootcmd.h | 5 ++ include/efi_api.h | 4 + include/efi_loader.h | 6 ++ lib/efi_loader/Makefile | 2 +- lib/efi_loader/efi_bootmgr.c | 169 ++ lib/efi_loader/efi_boottime.c | 6 +- lib/efi_loader/efi_image_loader.c | 1 + 8 files changed, 235 insertions(+), 6 deletions(-) create mode 100644 lib/efi_loader/efi_bootmgr.c diff --git a/cmd/bootefi.c b/cmd/bootefi.c index 80f52e9e35..02a0dd159b 100644 --- a/cmd/bootefi.c +++ b/cmd/bootefi.c @@ -219,6 +219,36 @@ exit: return ret; } +static int do_bootefi_bootmgr_exec(unsigned long fdt_addr) +{ + struct efi_device_path *device_path, *file_path; + void *addr; + efi_status_t r; + + /* Initialize and populate EFI object list */ + if (!efi_obj_list_initalized) + efi_init_obj_list(); + + /* +* gd lives in a fixed register which may get clobbered while we execute +* the payload. So save it here and restore it on every callback entry +*/ + efi_save_gd(); + + addr = efi_bootmgr_load(&device_path, &file_path); + if (!addr) + return 1; + + printf("## Starting EFI application at %p ...\n", addr); + r = do_bootefi_exec(addr, (void*)fdt_addr, device_path, file_path); + printf("## Application terminated, r = %lu\n", + r & ~EFI_ERROR_MASK); + + if (r != EFI_SUCCESS) + return 1; + + return 0; +} /* Interpreter command to boot an arbitrary EFI image from memory */ static int do_bootefi(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) @@ -237,7 +267,14 @@ static int do_bootefi(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) memcpy((char *)addr, __efi_hello_world_begin, size); } else #endif - { + if (!strcmp(argv[1], "bootmgr")) { + unsigned long fdt_addr = 0; + + if (argc > 2) + fdt_addr = simple_strtoul(argv[2], NULL, 16); + + return do_bootefi_bootmgr_exec(fdt_addr); + } else { saddr = argv[1]; addr = simple_strtoul(saddr, NULL, 16); @@ -270,7 +307,11 @@ static char bootefi_help_text[] = "hello\n" " - boot a sample Hello World application stored within U-Boot" #endif - ; + "bootmgr [fdt addr]\n" + " - load and boot EFI payload based on BootOrder/Boot variables.\n" + "\n" + "If specified, the device tree located at gets\n" + "exposed as EFI configuration table.\n"; #endif U_BOOT_CMD( @@ -308,6 +349,9 @@ void efi_set_bootdev(const char *dev, const char *devnr, const char *path) #endif } + if (!path) + return; + if (strcmp(dev, "Net")) { /* Add leading / to fs paths, because they're absolute */ snprintf(filename, sizeof(filename), "/%s", path); diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h index d8dab8e46a..94ccab02d2 100644 --- a/include/config_distro_bootcmd.h +++ b/include/config_distro_bootcmd.h @@ -112,6 +112,11 @@ #define BOOTENV_SHARED_EFI\ "boot_efi_binary="\ + "if fdt addr ${fdt_addr_r}; then "\ + "bootefi bootmgr ${fdt_addr_r};" \ This is too late. At this point you already checked that there indeed is a fallback binary. Since the bootmgr target actually knows which device it loads itself from, it can occur way before in the boot chain. Maybe we should just add a new boot_target for bootmgr. That way it naturally fits into the distro boot flow. You could then add a BOOTENV_DEV_BOOTMGR and simply run it from there. The only thing missing in that case is the device tree override - hmm... Oh well, if you need that I'm fine to leave it as hacky as it is here, but this boot protocol is definitely not what the UEFI guys had envisioned ;). Alex ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2, 09/42] Kconfig: Drop CONFIG_CMD_PCA953X_INFO
On Fri, Aug 04, 2017 at 04:34:33PM -0600, Simon Glass wrote: > It does not seem worth having an option to enable another sub-command in > this legacy driver. Drop this option so that the sub-command is always > available. > > Signed-off-by: Simon Glass > Reviewed-by: Bin Meng > Reviewed-by: Philipp Tomsich Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot,v2,20/42] Convert CONFIG_CMD_SCSI to Kconfig
On Fri, Aug 04, 2017 at 04:34:44PM -0600, Simon Glass wrote: > This converts the following to Kconfig: >CONFIG_CMD_SCSI > > Also update the Makefile to use CONFIG_CMD_SCSI instead of CONFIG_SCSI to > enable the command, fixing an earlier error. > > Signed-off-by: Simon Glass > Reviewed-by: Bin Meng > Reviewed-by: Philipp Tomsich After making this default y if SCSI, and drop from cl-som-am57x as it wasn't using really, applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2, 23/42] Convert CONFIG_CMD_SH_ZIMAGEBOOT to Kconfig
On Fri, Aug 04, 2017 at 04:34:47PM -0600, Simon Glass wrote: > This converts the following to Kconfig: >CONFIG_CMD_SH_ZIMAGEBOOT > > Signed-off-by: Simon Glass > Reviewed-by: Bin Meng > Reviewed-by: Philipp Tomsich Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2, 25/42] Convert CONFIG_CMD_SPL_NAND_OFS to Kconfig
On Fri, Aug 04, 2017 at 04:34:49PM -0600, Simon Glass wrote: > This converts the following to Kconfig: >CONFIG_CMD_SPL_NAND_OFS > > Signed-off-by: Simon Glass > Reviewed-by: Bin Meng > Reviewed-by: Philipp Tomsich Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot,v2,11/42] Kconfig: Drop CONFIG_CMD_PCI_ENUM
On Fri, Aug 04, 2017 at 04:34:35PM -0600, Simon Glass wrote: > This option enables the 'pci enum' command. It is only enabled by a few > board and these have not yet been converted to driver model, which always > enables this command. It seems easiest to just remove this option. > > The affected boards can be converted to use driver model for PCI if > needed. > > Signed-off-by: Simon Glass > Reviewed-by: Bin Meng > Reviewed-by: Philipp Tomsich Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot,v2,41/42] Drop config_cmd_all.h
On Fri, Aug 04, 2017 at 04:35:05PM -0600, Simon Glass wrote: > This file does not include all commands and has not for a while. Let's > drop it. > > Signed-off-by: Simon Glass > Reviewed-by: Bin Meng > Reviewed-by: Philipp Tomsich Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2, 28/42] Convert CONFIG_CMD_STRINGS to Kconfig
On Fri, Aug 04, 2017 at 04:34:52PM -0600, Simon Glass wrote: > This converts the following to Kconfig: >CONFIG_CMD_STRINGS > > Signed-off-by: Simon Glass > Reviewed-by: Bin Meng > Reviewed-by: Philipp Tomsich Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2, 06/42] Convert CONFIG_CMD_MTDPARTS_SPREAD to Kconfig
On Fri, Aug 04, 2017 at 04:34:30PM -0600, Simon Glass wrote: > This converts the following to Kconfig: >CONFIG_CMD_MTDPARTS_SPREAD > > Signed-off-by: Simon Glass > Reviewed-by: Bin Meng > Reviewed-by: Philipp Tomsich Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2, 34/42] Convert CONFIG_CMD_YAFFS2 to Kconfig
On Fri, Aug 04, 2017 at 04:34:58PM -0600, Simon Glass wrote: > This converts the following to Kconfig: >CONFIG_CMD_YAFFS2 > > Signed-off-by: Simon Glass > Reviewed-by: Bin Meng > Reviewed-by: Philipp Tomsich Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2, 22/42] Convert CONFIG_CMD_SF_TEST to Kconfig
On Fri, Aug 04, 2017 at 04:34:46PM -0600, Simon Glass wrote: > This converts the following to Kconfig: >CONFIG_CMD_SF_TEST > > Signed-off-by: Simon Glass > Reviewed-by: Bin Meng > Reviewed-by: Philipp Tomsich Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2, 17/42] Convert CONFIG_CMD_REISER to Kconfig
On Fri, Aug 04, 2017 at 04:34:41PM -0600, Simon Glass wrote: > This converts the following to Kconfig: >CONFIG_CMD_REISER > > Signed-off-by: Simon Glass > Reviewed-by: Bin Meng > Reviewed-by: Philipp Tomsich Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot,v2,39/42] Convert CONFIG_CMD_ZBOOT to Kconfig
On Fri, Aug 04, 2017 at 04:35:03PM -0600, Simon Glass wrote: > This converts the following to Kconfig: >CONFIG_CMD_ZBOOT > > Signed-off-by: Simon Glass > Reviewed-by: Bin Meng > Reviewed-by: Philipp Tomsich Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot,v2,35/42] Convert CONFIG_CMD_TRACE to Kconfig
On Fri, Aug 04, 2017 at 04:34:59PM -0600, Simon Glass wrote: > This converts the following to Kconfig: >CONFIG_CMD_TRACE > > Signed-off-by: Simon Glass > Reviewed-by: Bin Meng > Reviewed-by: Philipp Tomsich Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2, 04/42] Kconfig: Sort the device-access commands
On Fri, Aug 04, 2017 at 04:34:28PM -0600, Simon Glass wrote: > These are currently not quite in alphabetical order. Before adding more, > sort them. > > Signed-off-by: Simon Glass > Suggested-by: Bin Meng > Reviewed-by: Bin Meng > Reviewed-by: Philipp Tomsich Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot,v2,10/42] Convert CONFIG_CMD_PCI to Kconfig
On Fri, Aug 04, 2017 at 04:34:34PM -0600, Simon Glass wrote: > This converts the following to Kconfig: >CONFIG_CMD_PCI > > Signed-off-by: Simon Glass > Reviewed-by: Bin Meng > Reviewed-by: Philipp Tomsich Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2, 07/42] Convert CONFIG_CMD_ONENAND to Kconfig
On Fri, Aug 04, 2017 at 04:34:31PM -0600, Simon Glass wrote: > This converts the following to Kconfig: >CONFIG_CMD_ONENAND > > Signed-off-by: Simon Glass > Reviewed-by: Bin Meng > Reviewed-by: Philipp Tomsich Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot,v2,29/42] gpio: Drop sx151x driver
On Fri, Aug 04, 2017 at 04:34:53PM -0600, Simon Glass wrote: > This driver is not used in U-Boot. Drop it and its associated CONFIG > options. > > Signed-off-by: Simon Glass > Reviewed-by: Bin Meng > Reviewed-by: Philipp Tomsich Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2, 05/42] Convert CONFIG_CMD_MMC_SPI to Kconfig
On Fri, Aug 04, 2017 at 04:34:29PM -0600, Simon Glass wrote: > This converts the following to Kconfig: >CONFIG_CMD_MMC_SPI > > Signed-off-by: Simon Glass > Reviewed-by: Bin Meng > Reviewed-by: Philipp Tomsich Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot,v2,21/42] Convert CONFIG_CMD_SDRAM to Kconfig
On Fri, Aug 04, 2017 at 04:34:45PM -0600, Simon Glass wrote: > This converts the following to Kconfig: >CONFIG_CMD_SDRAM > > Signed-off-by: Simon Glass > Reviewed-by: Bin Meng > Reviewed-by: Philipp Tomsich Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2, 08/42] Convert CONFIG_CMD_PCA953X to Kconfig
On Fri, Aug 04, 2017 at 04:34:32PM -0600, Simon Glass wrote: > This converts the following to Kconfig: >CONFIG_CMD_PCA953X > > Signed-off-by: Simon Glass > Reviewed-by: Bin Meng > Reviewed-by: Philipp Tomsich Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2, 37/42] Convert CONFIG_CMD_UNIVERSE to Kconfig
On Fri, Aug 04, 2017 at 04:35:01PM -0600, Simon Glass wrote: > This converts the following to Kconfig: >CONFIG_CMD_UNIVERSE > > Since no board uses this, perhaps we should drop this command? > > Signed-off-by: Simon Glass > Reviewed-by: Bin Meng > Reviewed-by: Philipp Tomsich Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot,v2,19/42] Convert CONFIG_CMD_SAVES to Kconfig
On Fri, Aug 04, 2017 at 04:34:43PM -0600, Simon Glass wrote: > This converts the following to Kconfig: >CONFIG_CMD_SAVES > > Signed-off-by: Simon Glass > Reviewed-by: Bin Meng > Reviewed-by: Philipp Tomsich Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot,v1] at91, smartweb: use SPL_SYS_MALLOC_F_LEN
On Tue, Aug 08, 2017 at 03:10:24PM +0200, Heiko Schocher wrote: > commit f1896c45cb2f: spl: make SPL and normal u-boot stage use independent > SYS_MALLOC_F_LEN > introduced independent SYS_MALLOC_F_LEN for SPL and U-Boot. > > Use it on the smartweb board, as above commit broke > the smartweb board. > > Signed-off-by: Heiko Schocher Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot,v2,40/42] Convert CONFIG_CMD_ZFS to Kconfig
On Fri, Aug 04, 2017 at 04:35:04PM -0600, Simon Glass wrote: > This converts the following to Kconfig: >CONFIG_CMD_ZFS > > Signed-off-by: Simon Glass > Reviewed-by: Bin Meng > Reviewed-by: Philipp Tomsich Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2, 14/42] Kconfig: Drop CONFIG_CMD_PORTIO and associated command
On Fri, Aug 04, 2017 at 04:34:38PM -0600, Simon Glass wrote: > This command is not used by any board. It also looks quite similar to the > 'iod' and 'iow' commands which use the correct I/O macros. > > Drop it. > > Signed-off-by: Simon Glass > Reviewed-by: Bin Meng > Reviewed-by: Philipp Tomsich Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] board: ks2: README: Update NAND wording
On Wed, Aug 09, 2017 at 09:29:22PM -0500, Cooper Jr., Franklin wrote: > Traditional KS2 devices supported NAND via the AEMIF peripheral. However, > 66AK2G doesn't use the AEMIF but rather the GPMC for NAND. Therefore, > clarify some statements to indicate only certain devices have AEMIF and > in other places just say NAND instead of AEMIF NAND > > Signed-off-by: Franklin S Cooper Jr > Acked-by: Roger Quadros Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot,v2,27/42] Kconfig: Sort the memory commands
On Fri, Aug 04, 2017 at 04:34:51PM -0600, Simon Glass wrote: > These are currently not quite in alphabetical order. Before adding more, > sort them. Not all options have a CMD_ prefix, so ignore that when > sorting. > > Signed-off-by: Simon Glass > Suggested-by: Bin Meng > Reviewed-by: Bin Meng > Reviewed-by: Philipp Tomsich Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2, 18/42] Kconfig: sandbox: Drop CONFIG_CMD_SANDBOX option
On Fri, Aug 04, 2017 at 04:34:42PM -0600, Simon Glass wrote: > This is no-longer used. Drop it. > > Signed-off-by: Simon Glass > Reviewed-by: Bin Meng > Reviewed-by: Philipp Tomsich Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot,v2,24/42] Convert CONFIG_CMD_SPL to Kconfig
On Fri, Aug 04, 2017 at 04:34:48PM -0600, Simon Glass wrote: > This converts the following to Kconfig: >CONFIG_CMD_SPL > > Note that trats does not actually use SPL, so this option can no-longer be > set. > > Signed-off-by: Simon Glass > Reviewed-by: Bin Meng > Reviewed-by: Philipp Tomsich Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2, 16/42] Convert CONFIG_CMD_REGINFO to Kconfig
On Fri, Aug 04, 2017 at 04:34:40PM -0600, Simon Glass wrote: > From: Christophe Leroy > > This patch converts CONFIG_CMD_REGINFO to Kconfig > > Signed-off-by: Christophe Leroy > Signed-off-by: Simon Glass > Reviewed-by: Bin Meng > Reviewed-by: Philipp Tomsich With a few more changes to the imply logic to not add this on boards that didn't have it before, applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot,v2,32/42] Kconfig: Drop CONFIG_CMD_TFTP
On Fri, Aug 04, 2017 at 04:34:56PM -0600, Simon Glass wrote: > This is not a valid CONFIG option. Drop it. > > Signed-off-by: Simon Glass > Reviewed-by: Bin Meng > Reviewed-by: Philipp Tomsich Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2, 36/42] Convert CONFIG_CMD_TSI148 to Kconfig
On Fri, Aug 04, 2017 at 04:35:00PM -0600, Simon Glass wrote: > This converts the following to Kconfig: >CONFIG_CMD_TSI148 > > Signed-off-by: Simon Glass > Reviewed-by: Bin Meng > Reviewed-by: Philipp Tomsich Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] travis-ci: Emulate 'make tests'
On Mon, Aug 07, 2017 at 03:24:50PM -0400, Tom Rini wrote: > The 'tests' target will run sandbox, sandbox_spl and sandbox_flattree in > test.py and in the case of sandbox_spl ensure that we just run the > specific tests for that build. Update our matrix to perform similar > test.py runs. > > Signed-off-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] OMAP3: omap3logic: Fix DDR Pin Mux
On Tue, Aug 08, 2017 at 09:00:27AM -0500, Adam Ford wrote: > The 512 MB DDR version of SOM's use CS0 and CS1. CS1 is not correctly > setup in the pin muxing. This causes erratic behavior on suspend/resume > > This fix has been tested on both 256 and 512 MB DDR versions. > > Signed-off-by: Adam Ford > > diff --git a/board/logicpd/omap3som/omap3logic.c > b/board/logicpd/omap3som/omap3logic.c > index de6a060..af20339 100644 Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2, 37/42] Convert CONFIG_CMD_UNIVERSE to Kconfig
On Fri, Aug 04, 2017 at 04:35:01PM -0600, Simon Glass wrote: > This converts the following to Kconfig: >CONFIG_CMD_UNIVERSE > > Since no board uses this, perhaps we should drop this command? > > Signed-off-by: Simon Glass > Reviewed-by: Bin Meng > Reviewed-by: Philipp Tomsich Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2, 31/42] Convert CONFIG_CMD_TERMINAL to Kconfig
On Fri, Aug 04, 2017 at 04:34:55PM -0600, Simon Glass wrote: > This converts the following to Kconfig: >CONFIG_CMD_TERMINAL > > Signed-off-by: Simon Glass > Reviewed-by: Bin Meng > Reviewed-by: Philipp Tomsich Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2, 42/42] README: Drop information about commands
On Fri, Aug 04, 2017 at 04:35:06PM -0600, Simon Glass wrote: > Most of this is duplicated in Kconfig help. Add some of that which is not, > and remove the help from the README. > > Signed-off-by: Simon Glass > Reviewed-by: Bin Meng > Reviewed-by: Philipp Tomsich Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2, 15/42] Kconfig: Convert CMD_READ to Kconfig
On Fri, Aug 04, 2017 at 04:34:39PM -0600, Simon Glass wrote: > Convert this option and enable it in sandbox. Also correct a bug which > was introduced with the block-device driver model conversion. > > Signed-off-by: Simon Glass > Reviewed-by: Bin Meng > Reviewed-by: Philipp Tomsich Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot,v2,12/42] Kconfig; Drop CONFIG_IDE_TI_CARDBUS and associated driver
On Fri, Aug 04, 2017 at 04:34:36PM -0600, Simon Glass wrote: > This driver is not used by any board. Drop it. > > Signed-off-by: Simon Glass > Reviewed-by: Bin Meng > Reviewed-by: Philipp Tomsich Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2, 26/42] Convert CONFIG_CMD_SPL_WRITE_SIZE to Kconfig
On Fri, Aug 04, 2017 at 04:34:50PM -0600, Simon Glass wrote: > This converts the following to Kconfig: >CONFIG_CMD_SPL_WRITE_SIZE > > Signed-off-by: Simon Glass > Reviewed-by: Bin Meng > Reviewed-by: Philipp Tomsich Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2, 30/42] Convert CONFIG_CMD_TCA642X to Kconfig
On Fri, Aug 04, 2017 at 04:34:54PM -0600, Simon Glass wrote: > This converts the following to Kconfig: >CONFIG_CMD_TCA642X > > Signed-off-by: Simon Glass > Reviewed-by: Bin Meng > Reviewed-by: Philipp Tomsich Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2, 13/42] Convert CONFIG_CMD_PCMCIA to Kconfig
On Fri, Aug 04, 2017 at 04:34:37PM -0600, Simon Glass wrote: > This converts the following to Kconfig: >CONFIG_CMD_PCMCIA > > Signed-off-by: Simon Glass > Reviewed-by: Bin Meng > Reviewed-by: Philipp Tomsich Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot,v2,38/42] Convert CONFIG_CMD_UUID to Kconfig
On Fri, Aug 04, 2017 at 04:35:02PM -0600, Simon Glass wrote: > This converts the following to Kconfig: >CONFIG_CMD_UUID > > Signed-off-by: Simon Glass > Reviewed-by: Bin Meng > Reviewed-by: Philipp Tomsich Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2, 33/42] Convert CONFIG_CMD_THOR_DOWNLOAD to Kconfig
On Fri, Aug 04, 2017 at 04:34:57PM -0600, Simon Glass wrote: > This converts the following to Kconfig: >CONFIG_CMD_THOR_DOWNLOAD > > Signed-off-by: Simon Glass > Reviewed-by: Bin Meng > Reviewed-by: Philipp Tomsich Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v3] omap3: evm: Update board, defconfig, and maintainer file
On Sun, Aug 06, 2017 at 12:00:21AM -0500, Derald D. Woods wrote: > This patch brings the OMAP3 EVM to a bootable state, on master, as of > v2017.09-rc1. > > Signed-off-by: Derald D. Woods > Reviewed-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 2/3] efi_loader: open_info in OpenProtocol, CloseProtocol
On 05.08.17 22:32, Heinrich Schuchardt wrote: efi_open_protocol and close_protocol have to keep track of opened protocols. So we add an array open_info to each protocol of each handle. Cc: Rob Clark Signed-off-by: Heinrich Schuchardt --- v3: use EFI_CALL to avoid wrapper for efi_disconnect_controller use list_for_each_entry move variable declarations out of loops v2: new patch --- include/efi_loader.h | 1 + lib/efi_loader/efi_boottime.c | 164 +++--- 2 files changed, 155 insertions(+), 10 deletions(-) diff --git a/include/efi_loader.h b/include/efi_loader.h index 553c615f11..222b251a38 100644 --- a/include/efi_loader.h +++ b/include/efi_loader.h @@ -88,6 +88,7 @@ extern unsigned int __efi_runtime_rel_start, __efi_runtime_rel_stop; struct efi_handler { const efi_guid_t *guid; void *protocol_interface; + struct efi_open_protocol_info_entry open_info[4]; }; /* diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c index ebb557abb2..e969814476 100644 --- a/lib/efi_loader/efi_boottime.c +++ b/lib/efi_loader/efi_boottime.c @@ -898,23 +898,78 @@ static efi_status_t EFIAPI efi_connect_controller( return EFI_EXIT(EFI_NOT_FOUND); } -static efi_status_t EFIAPI efi_disconnect_controller(void *controller_handle, -void *driver_image_handle, -void *child_handle) +static efi_status_t EFIAPI efi_disconnect_controller( + void *controller_handle, + void *driver_image_handle, + void *child_handle) { EFI_ENTRY("%p, %p, %p", controller_handle, driver_image_handle, child_handle); return EFI_EXIT(EFI_INVALID_PARAMETER); } +static efi_status_t efi_close_protocol_int(struct efi_handler *protocol, Please either wrap _ext or use EFI_CALL :). + void *agent_handle, + void *controller_handle) +{ + size_t i; + struct efi_open_protocol_info_entry *open_info; + + for (i = 0; i < ARRAY_SIZE(protocol->open_info); ++i) { + open_info = &protocol->open_info[i]; + + if (!open_info->open_count) + continue; + + if (open_info->agent_handle == agent_handle && + open_info->controller_handle == + controller_handle) { + open_info->open_count--; + return EFI_SUCCESS; + } + } + return EFI_NOT_FOUND; +} + static efi_status_t EFIAPI efi_close_protocol(void *handle, efi_guid_t *protocol, void *agent_handle, void *controller_handle) { + struct efi_object *efiobj; + size_t i; + efi_status_t r = EFI_NOT_FOUND; + EFI_ENTRY("%p, %p, %p, %p", handle, protocol, agent_handle, controller_handle); - return EFI_EXIT(EFI_NOT_FOUND); + + if (!handle || !protocol || !agent_handle) { + r = EFI_INVALID_PARAMETER; + goto out; + } + + EFI_PRINT_GUID("protocol:", protocol); + + list_for_each_entry(efiobj, &efi_obj_list, link) { + if (efiobj->handle != handle) + continue; + + for (i = 0; i < ARRAY_SIZE(efiobj->protocols); i++) { + struct efi_handler *handler = &efiobj->protocols[i]; + const efi_guid_t *hprotocol = handler->guid; + if (!hprotocol) + continue; + if (!guidcmp(hprotocol, protocol)) { + r = efi_close_protocol_int(handler, + agent_handle, + controller_handle); + goto out; + } + } + goto out; + } +out: + return EFI_EXIT(r); } static efi_status_t EFIAPI efi_open_protocol_information(efi_handle_t handle, @@ -1119,6 +1174,96 @@ static void EFIAPI efi_set_mem(void *buffer, unsigned long size, uint8_t value) memset(buffer, value, size); } +static efi_status_t efi_open_protocol_int( Same here. Alex + struct efi_handler *protocol, + void **protocol_interface, void *agent_handle, + void *controller_handle, uint32_t attributes) +{ + bool opened_exclusive = false; + bool opened_by_driver = false; + int i; + struct efi_open
Re: [U-Boot] [PATCH v3 1/3] efi_loader: write protocol GUID in OpenProtocol
On 11.08.17 18:00, Heinrich Schuchardt wrote: On 08/11/2017 12:11 PM, Alexander Graf wrote: On 05.08.17 21:32, Heinrich Schuchardt wrote: To understand what happens in OpenProtocol it is necessary to know the protocol interface GUID. Let's write a debug message. Using uuid_guid_get_str would be quite clumsy for this purpose. This would involve evaluating _DEBUG which probably should not be used outside common.h. Cc: Rob Clark Signed-off-by: Heinrich Schuchardt I agree with Rob that a printf extension would be the nicest way to go here. We could then just use that instead of the %p in EFI_ENTRY() that we have today. Alex Hello Alex, I am aware of [PATCH 4/5] vsprintf.c: add GUID printing, I just wonder if you wnat to take this patch series as is and we modify EFI_PRINT_GUID afterwards or we I shall remove GUID printing and resend the patch series without it. I think it's best to keep changes isolated to not stall anyone. Since this is really just a debug enhancement, I think we're best off to drop the GUID printing in this patch set. Alex ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 3/3] efi_loader: implement OpenProtocolInformation
On 05.08.17 22:32, Heinrich Schuchardt wrote: efi_open_protocol_information provides the agent and controller handles as well as the attributes and open count of an protocol on a handle. Cc: Rob Clark Signed-off-by: Heinrich Schuchardt Do you have an application that leverages these interfaces? Would it be possible to add that application to our travis tests? Alex ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 02/15] fs/fat: implement readdir
On Sat, Aug 12, 2017 at 8:17 AM, Alexander Graf wrote: > > > On 10.08.17 20:29, Rob Clark wrote: >> >> Yes, this is super-hacky. The FAT code is quite ugly, and this doesn't >> improve things. But it doesn't make it significantly worse either. The >> better option would be a massive FAT re-write to get rid of the hacky >> way that fat_file_ls() works. Volunteers welcome. >> >> Signed-off-by: Rob Clark > > > What concerns me the most in patch 1/15 and this patch is the limited scope. > Yes, you make readdir work for FAT, but all other file systems are still > unimplemented. In fact, they're even all still implementing their own > hand-written ls logic. > > One of the goals of the efi_loader code is to integrate with U-Boot as much > as possible, to reuse code where we can. And if current interfaces are > terrible, I think it's ok to just replace them for something that fits > everyone's needs better. > > How feasible do you think it would be to implement an ls function based on > readdir and just convert all file systems to it, completely replacing the > current (quite crude) ls logic? So I went ahead and re-wrote the fat directory traversal[1]. I should be posting to list in the next day or two but still want to make a few small cleanups. (And to get rid of some hacks in efi_file, I think I need to add an fs_isdir() too :-/) As far as the various other filesys's, I agree that a generic ls would be a nice goal. But the scope of the efi_loader patchset has already expanded way too much, and at this point I'm pretty much limited by what I can finish this weekend. At the end of the day, FAT is all that UEFI expects, so I think it is fine to let the other filesystems catch up on their own schedule. I could write a generic ls helper, and just plug it in for FAT, which could be re-used later when other filesys's gain readdir support. BR, -R [1] https://github.com/robclark/u-boot/commits/readdir ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 15/15] efi_loader: add bootmgr
On Sat, Aug 12, 2017 at 9:10 AM, Alexander Graf wrote: > > > On 10.08.17 20:29, Rob Clark wrote: >> >> Similar to a "real" UEFI implementation, the bootmgr looks at the >> BootOrder and Boot variables to try to find an EFI payload to load >> and boot. This is added as a sub-command of bootefi. >> >> The idea is that the distro bootcmd would first try loading a payload >> via the bootmgr, and then if that fails (ie. first boot or corrupted >> EFI variables) it would fallback to loading bootaa64.efi. (Which >> would then load fallback.efi which would look for \EFI\*\boot.csv and >> populate BootOrder and Boot based on what it found.) >> >> Signed-off-by: Rob Clark >> --- >> cmd/bootefi.c | 48 ++- >> include/config_distro_bootcmd.h | 5 ++ >> include/efi_api.h | 4 + >> include/efi_loader.h | 6 ++ >> lib/efi_loader/Makefile | 2 +- >> lib/efi_loader/efi_bootmgr.c | 169 >> ++ >> lib/efi_loader/efi_boottime.c | 6 +- >> lib/efi_loader/efi_image_loader.c | 1 + >> 8 files changed, 235 insertions(+), 6 deletions(-) >> create mode 100644 lib/efi_loader/efi_bootmgr.c >> >> diff --git a/cmd/bootefi.c b/cmd/bootefi.c >> index 80f52e9e35..02a0dd159b 100644 >> --- a/cmd/bootefi.c >> +++ b/cmd/bootefi.c >> @@ -219,6 +219,36 @@ exit: >> return ret; >> } >> +static int do_bootefi_bootmgr_exec(unsigned long fdt_addr) >> +{ >> + struct efi_device_path *device_path, *file_path; >> + void *addr; >> + efi_status_t r; >> + >> + /* Initialize and populate EFI object list */ >> + if (!efi_obj_list_initalized) >> + efi_init_obj_list(); >> + >> + /* >> +* gd lives in a fixed register which may get clobbered while we >> execute >> +* the payload. So save it here and restore it on every callback >> entry >> +*/ >> + efi_save_gd(); >> + >> + addr = efi_bootmgr_load(&device_path, &file_path); >> + if (!addr) >> + return 1; >> + >> + printf("## Starting EFI application at %p ...\n", addr); >> + r = do_bootefi_exec(addr, (void*)fdt_addr, device_path, >> file_path); >> + printf("## Application terminated, r = %lu\n", >> + r & ~EFI_ERROR_MASK); >> + >> + if (r != EFI_SUCCESS) >> + return 1; >> + >> + return 0; >> +} >> /* Interpreter command to boot an arbitrary EFI image from memory */ >> static int do_bootefi(cmd_tbl_t *cmdtp, int flag, int argc, char * const >> argv[]) >> @@ -237,7 +267,14 @@ static int do_bootefi(cmd_tbl_t *cmdtp, int flag, int >> argc, char * const argv[]) >> memcpy((char *)addr, __efi_hello_world_begin, size); >> } else >> #endif >> - { >> + if (!strcmp(argv[1], "bootmgr")) { >> + unsigned long fdt_addr = 0; >> + >> + if (argc > 2) >> + fdt_addr = simple_strtoul(argv[2], NULL, 16); >> + >> + return do_bootefi_bootmgr_exec(fdt_addr); >> + } else { >> saddr = argv[1]; >> addr = simple_strtoul(saddr, NULL, 16); >> @@ -270,7 +307,11 @@ static char bootefi_help_text[] = >> "hello\n" >> " - boot a sample Hello World application stored within U-Boot" >> #endif >> - ; >> + "bootmgr [fdt addr]\n" >> + " - load and boot EFI payload based on BootOrder/Boot >> variables.\n" >> + "\n" >> + "If specified, the device tree located at >> gets\n" >> + "exposed as EFI configuration table.\n"; >> #endif >> U_BOOT_CMD( >> @@ -308,6 +349,9 @@ void efi_set_bootdev(const char *dev, const char >> *devnr, const char *path) >> #endif >> } >> + if (!path) >> + return; >> + >> if (strcmp(dev, "Net")) { >> /* Add leading / to fs paths, because they're absolute */ >> snprintf(filename, sizeof(filename), "/%s", path); >> diff --git a/include/config_distro_bootcmd.h >> b/include/config_distro_bootcmd.h >> index d8dab8e46a..94ccab02d2 100644 >> --- a/include/config_distro_bootcmd.h >> +++ b/include/config_distro_bootcmd.h >> @@ -112,6 +112,11 @@ >> #define BOOTENV_SHARED_EFI >> \ >> "boot_efi_binary=" >> \ >> + "if fdt addr ${fdt_addr_r}; then " >> \ >> + "bootefi bootmgr ${fdt_addr_r};" >> \ > > > This is too late. At this point you already checked that there indeed is a > fallback binary. Since the bootmgr target actually knows which device it > loads itself from, it can occur way before in the boot chain. > > Maybe we should just add a new boot_target for bootmgr. That way it > naturally fits into the distro boot flow. You could then add a > BOOTENV_DEV_BOOTMGR and simply run it from there. > > The only thing missing in that case is the device tree override - hmm... > > Oh well, if you need t
[U-Boot] [PATCH 3/3] mx7: add epdc qos settings
This EPDC/EPXP QoS setting is needed for EPDC stress test to pass. Signed-off-by: Peng Fan Cc: Stefano Babic Cc: Fabio Estevam --- arch/arm/include/asm/arch-mx7/imx-regs.h | 5 + arch/arm/mach-imx/mx7/soc.c | 38 2 files changed, 43 insertions(+) diff --git a/arch/arm/include/asm/arch-mx7/imx-regs.h b/arch/arm/include/asm/arch-mx7/imx-regs.h index aab3a9a..a6b2091 100644 --- a/arch/arm/include/asm/arch-mx7/imx-regs.h +++ b/arch/arm/include/asm/arch-mx7/imx-regs.h @@ -152,6 +152,11 @@ #define IP2APB_AXIMON_IPS_BASE_ADDR (AIPS2_OFF_BASE_ADDR+0x1E) #define QOSC_IPS_BASE_ADDR (AIPS2_OFF_BASE_ADDR+0x1F) +#define REGS_QOS_BASE QOSC_IPS_BASE_ADDR +#define REGS_QOS_EPDC (QOSC_IPS_BASE_ADDR + 0x3400) +#define REGS_QOS_PXP0 (QOSC_IPS_BASE_ADDR + 0x2C00) +#define REGS_QOS_PXP1 (QOSC_IPS_BASE_ADDR + 0x3C00) + /* AIPS_TZ#3 - Global enable (0) */ #define ECSPI1_BASE_ADDR(AIPS_TZ3_BASE_ADDR+0x2) #define ECSPI2_BASE_ADDR(AIPS_TZ3_BASE_ADDR+0x3) diff --git a/arch/arm/mach-imx/mx7/soc.c b/arch/arm/mach-imx/mx7/soc.c index 4307ae0..6b37848 100644 --- a/arch/arm/mach-imx/mx7/soc.c +++ b/arch/arm/mach-imx/mx7/soc.c @@ -230,6 +230,42 @@ static void imx_enet_mdio_fixup(void) } } +static void set_epdc_qos(void) +{ + /* Disable clkgate & soft_reset */ + writel(0, REGS_QOS_BASE); + /* Enable all masters */ + writel(0, REGS_QOS_BASE + 0x60); + /* Disable clkgate & soft_reset */ + writel(0, REGS_QOS_EPDC); + /* Disable clkgate & soft_reset */ + writel(0, REGS_QOS_PXP0); + /* Disable clkgate & soft_reset */ + writel(0, REGS_QOS_PXP1); + /* WR, init = 7 with red flag */ + writel(0x0f020722, REGS_QOS_EPDC + 0xd0); + /* RD, init = 7 with red flag */ + writel(0x0f020722, REGS_QOS_EPDC + 0xe0); + /* OT_CTRL_EN =1 */ + writel(1, REGS_QOS_PXP0); + /* OT_CTRL_EN =1 */ + writel(1, REGS_QOS_PXP1); + /* WR, init = 2 with red flag */ + writel(0x0f020222, REGS_QOS_PXP0 + 0x50); + /* WR, init = 2 with red flag */ + writel(0x0f020222, REGS_QOS_PXP1 + 0x50); + /* rD, init = 2 with red flag */ + writel(0x0f020222, REGS_QOS_PXP0 + 0x60); + /* rD, init = 2 with red flag */ + writel(0x0f020222, REGS_QOS_PXP1 + 0x60); + /* tOTAL, init = 4 with red flag */ + writel(0x0f020422, REGS_QOS_PXP0 + 0x70); + /* TOTAL, init = 4 with red flag */ + writel(0x0f020422, REGS_QOS_PXP1 + 0x70); + /* EPDC AW/AR CACHE ENABLE */ + writel(0xe080, IOMUXC_GPR_BASE_ADDR + 0x0034); +} + int arch_cpu_init(void) { init_aips(); @@ -240,6 +276,8 @@ int arch_cpu_init(void) imx_enet_mdio_fixup(); + set_epdc_qos(); + #ifdef CONFIG_APBH_DMA /* Start APBH DMA */ mxs_dma_init(); -- 2.6.2 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/3] imx: mx7: fix build warning when CONFIG_IMX_RDC not enabled
Fix build warning when CONFIG_IMX_RDC not defined in defconfig. Signed-off-by: Peng Fan Cc: Stefano Babic Cc: Fabio Estevam --- arch/arm/mach-imx/mx7/soc.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/arch/arm/mach-imx/mx7/soc.c b/arch/arm/mach-imx/mx7/soc.c index 4cf977e..ec74b4c 100644 --- a/arch/arm/mach-imx/mx7/soc.c +++ b/arch/arm/mach-imx/mx7/soc.c @@ -31,7 +31,7 @@ U_BOOT_DEVICE(imx7_thermal) = { }; #endif -#ifdef CONFIG_IMX_RDC +#if CONFIG_IS_ENABLED(IMX_RDC) /* * In current design, if any peripheral was assigned to both A7 and M4, * it will receive ipg_stop or ipg_wait when any of the 2 platforms enter @@ -245,8 +245,9 @@ int arch_cpu_init(void) mxs_dma_init(); #endif - if (IS_ENABLED(CONFIG_IMX_RDC)) - isolate_resource(); +#if CONFIG_IS_ENABLED(IMX_RDC) + isolate_resource(); +#endif return 0; } -- 2.6.2 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/3] imx: Enable ACTLR.SMP bit for Cortex-A7 platforms
According to the Cortex-A7 TRM, for ACTLR.SMP bit "You must ensure this bit is set to 1 before the caches and MMU are enabled, or any cache and TLB maintenance operations are performed". ROM sets this bit in normal boot flow, but when in serial download mode, it is not set. Here we set it for mx6/7/7ulp. The code will check whether the PE is A7 or not. Signed-off-by: Peng Fan Cc: Stefano Babic Cc: Fabio Estevam --- arch/arm/include/asm/mach-imx/sys_proto.h | 1 + arch/arm/mach-imx/cache.c | 28 arch/arm/mach-imx/mx6/soc.c | 2 ++ arch/arm/mach-imx/mx7/soc.c | 9 ++--- arch/arm/mach-imx/mx7ulp/soc.c| 2 ++ 5 files changed, 35 insertions(+), 7 deletions(-) diff --git a/arch/arm/include/asm/mach-imx/sys_proto.h b/arch/arm/include/asm/mach-imx/sys_proto.h index 046df62..26db1cc 100644 --- a/arch/arm/include/asm/mach-imx/sys_proto.h +++ b/arch/arm/include/asm/mach-imx/sys_proto.h @@ -87,6 +87,7 @@ static inline u8 imx6_is_bmode_from_gpr9(void) u32 imx6_src_get_boot_mode(void); #endif /* CONFIG_MX6 */ +void enable_actlr_smp(void); u32 get_nr_cpus(void); u32 get_cpu_rev(void); u32 get_cpu_speed_grade_hz(void); diff --git a/arch/arm/mach-imx/cache.c b/arch/arm/mach-imx/cache.c index c5279a7..e02f1a5 100644 --- a/arch/arm/mach-imx/cache.c +++ b/arch/arm/mach-imx/cache.c @@ -10,6 +10,34 @@ #include #include +void enable_actlr_smp(void) +{ + uint32_t val; + + /* Read MIDR */ + asm volatile ("mrc p15, 0, %0, c0, c0, 0\n\t" : "=r"(val)); + val = (val >> 4); + val &= 0xf; + + /* Only set the SMP for Cortex A7 */ + if (val == 0x7) { + /* Read auxiliary control register */ + asm volatile ("mrc p15, 0, %0, c1, c0, 1\n\t" : "=r"(val)); + + if (val & (1 << 6)) + return; + + /* Enable SMP */ + val |= (1 << 6); + + /* Write auxiliary control register */ + asm volatile ("mcr p15, 0, %0, c1, c0, 1\n\t" : : "r"(val)); + + DSB; + ISB; + } +} + #ifndef CONFIG_SYS_DCACHE_OFF void enable_caches(void) { diff --git a/arch/arm/mach-imx/mx6/soc.c b/arch/arm/mach-imx/mx6/soc.c index af31673..0ef4b29 100644 --- a/arch/arm/mach-imx/mx6/soc.c +++ b/arch/arm/mach-imx/mx6/soc.c @@ -576,6 +576,8 @@ void s_init(void) u32 mask528; u32 reg, periph1, periph2; + enable_actlr_smp(); + if (is_mx6sx() || is_mx6ul() || is_mx6ull()) return; diff --git a/arch/arm/mach-imx/mx7/soc.c b/arch/arm/mach-imx/mx7/soc.c index ec74b4c..4307ae0 100644 --- a/arch/arm/mach-imx/mx7/soc.c +++ b/arch/arm/mach-imx/mx7/soc.c @@ -447,13 +447,8 @@ int mmc_get_env_dev(void) void s_init(void) { -#if !defined CONFIG_SPL_BUILD - /* Enable SMP mode for CPU0, by setting bit 6 of Auxiliary Ctl reg */ - asm volatile( - "mrc p15, 0, r0, c1, c0, 1\n" - "orr r0, r0, #1 << 6\n" - "mcr p15, 0, r0, c1, c0, 1\n"); -#endif + enable_actlr_smp(); + /* clock configuration. */ clock_init(); diff --git a/arch/arm/mach-imx/mx7ulp/soc.c b/arch/arm/mach-imx/mx7ulp/soc.c index 454665a..71bfe36 100644 --- a/arch/arm/mach-imx/mx7ulp/soc.c +++ b/arch/arm/mach-imx/mx7ulp/soc.c @@ -100,6 +100,8 @@ void init_wdog(void) void s_init(void) { + enable_actlr_smp(); + /* Disable wdog */ init_wdog(); -- 2.6.2 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/3] armv8: ls1088a: Add NXP LS1088A SoC support
> -Original Message- > From: Ashish Kumar [mailto:ashish.ku...@nxp.com] > Sent: Friday, August 11, 2017 12:54 PM > To: u-boot@lists.denx.de > Cc: York Sun ; Ashish Kumar ; > Alison Wang ; Prabhakar Kushwaha > ; Raghav Dogra ; > Shaohui Xie > Subject: [PATCH v3 1/3] armv8: ls1088a: Add NXP LS1088A SoC support > > The QorIQ LS1088A processor is built on the Layerscape > architecture combining eight ARM A53 processor cores > with advanced, high-performance datapath acceleration > and networks, peripheral interfaces required for > networking, wireless infrastructure, and general-purpose > embedded applications. > > LS1088A is compliant to the Layerscape Chassis Generation 3. > > Features summary: > - Eight 32-bit / 64-bit ARM v8 Cortex-A53 CPUs > - Cores are in 2 cluster of 4-cores each > - Cache coherent interconnect (CCI-400) > - One 64-bit DDR4 SDRAM memory controller with ECC > - Data path acceleration architecture 2.0 (DPAA2) > - Ethernet interfaces: SGMIIs, RGMIIs, QSGMIIs, XFIs > - QSPI, IFC, 3 PCIe, 1 SATA, 2 USB, 1 SDXC, 2 DUARTs etc > > Signed-off-by: Alison Wang > Signed-off-by: Prabhakar Kushwaha > Signed-off-by: Ashish Kumar > Signed-off-by: Raghav Dogra > Signed-off-by: Shaohui Xie > --- > > v2: > Fix indentaion in commit msg > Separate RDB and Si specific file > Move Macros to Kconfig > > v3: > 1.Re-based on top of > commit d529124fdcf941c34074fd1ce600f4b1b4a7dd07 > Merge: f0ca30f 6a5691e > Author: Tom Rini > Date: Tue Aug 8 17:06:19 2017 -0400 > > Merge git://git.denx.de/u-boot-x86 > > 2.Incorporate review comments on v2 > Clean up done > > 3.Migrate changes from ls1088ardb_stream_id.h to stream_id_lsch3.h > > arch/arm/cpu/armv8/fsl-layerscape/Kconfig | 39 ++- > arch/arm/cpu/armv8/fsl-layerscape/Makefile | 4 + > .../cpu/armv8/fsl-layerscape/fsl_lsch3_serdes.c| 10 ++ > arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S | 6 +- > arch/arm/cpu/armv8/fsl-layerscape/ls1088a_serdes.c | 126 > + > arch/arm/cpu/armv8/fsl-layerscape/soc.c| 5 + > arch/arm/dts/fsl-ls1088a.dtsi | 78 + > arch/arm/include/asm/arch-fsl-layerscape/config.h | 62 +- > arch/arm/include/asm/arch-fsl-layerscape/cpu.h | 4 + > .../include/asm/arch-fsl-layerscape/fsl_serdes.h | 3 +- > .../include/asm/arch-fsl-layerscape/immap_lsch3.h | 11 ++ > arch/arm/include/asm/arch-fsl-layerscape/soc.h | 4 + > .../asm/arch-fsl-layerscape/stream_id_lsch3.h | 14 +++ > drivers/ddr/fsl/util.c | 2 +- > drivers/net/ldpaa_eth/Makefile | 1 + > drivers/net/ldpaa_eth/ls1088a.c| 87 ++ Add SoC details in arch/arm/cpu/armv8/fsl-layerscape/doc/README.soc > 16 files changed, 447 insertions(+), 9 deletions(-) > create mode 100644 arch/arm/cpu/armv8/fsl-layerscape/ls1088a_serdes.c > create mode 100644 arch/arm/dts/fsl-ls1088a.dtsi > create mode 100644 drivers/net/ldpaa_eth/ls1088a.c > > diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig > b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig > index 1132969..a3c7490 100644 > --- a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig > +++ b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig > @@ -49,6 +49,29 @@ config ARCH_LS1046A > select BOARD_EARLY_INIT_F > imply SCSI > > +config ARCH_LS1088A > + bool > + select ARMV8_SET_SMPEN > + select FSL_LSCH3 > + select SYS_FSL_DDR > + select SYS_FSL_DDR_LE > + select SYS_FSL_DDR_VER_50 > + select SYS_FSL_ERRATUM_A009803 > + select SYS_FSL_ERRATUM_A009942 > + select SYS_FSL_ERRATUM_A010165 > + select SYS_FSL_ERRATUM_A008511 > + select SYS_FSL_ERRATUM_A008850 > + select SYS_FSL_HAS_CCI400 > + select SYS_FSL_HAS_DDR4 > + select SYS_FSL_HAS_SEC > + select SYS_FSL_SEC_COMPAT_5 > + select SYS_FSL_SEC_LE > + select SYS_FSL_SRDS_1 > + select SYS_FSL_SRDS_2 > + select FSL_TZASC_1 > + select ARCH_EARLY_INIT_R > + select BOARD_EARLY_INIT_F > + > config ARCH_LS2080A > bool > select ARMV8_SET_SMPEN > @@ -60,6 +83,7 @@ config ARCH_LS2080A > select SYS_FSL_DDR > select SYS_FSL_DDR_LE > select SYS_FSL_DDR_VER_50 > + select SYS_FSL_HAS_CCN504 > select SYS_FSL_HAS_DP_DDR > select SYS_FSL_HAS_SEC > select SYS_FSL_HAS_DDR4 > @@ -98,7 +122,7 @@ config FSL_LSCH3 > > config FSL_MC_ENET > bool "Management Complex network" > - depends on ARCH_LS2080A > + depends on ARCH_LS2080A || ARCH_LS1088A > default y > select RESV_RAM > help > @@ -114,6 +138,7 @@ config FSL_PCIE_COMPAT > default "fsl,ls1043a-pcie" if ARCH_LS1043A > default "fsl,ls1046a-pcie" if ARCH_LS1046A > default "fsl,ls2080a-pcie" if ARCH_LS2080A > + default "fsl,ls1080a-pcie" if ARCH_LS1088A > help > This compatible is used to find pci controller node in Ke
Re: [U-Boot] [PATCH v2] arm: omap: Fix 'get_device_type()' for OMAP34XX
On Thu, Aug 10, 2017 at 7:50 AM, Derald Woods wrote: > On Thu, Aug 10, 2017 at 7:25 AM, Derald Woods > wrote: > >> On Mon, Aug 7, 2017 at 5:19 PM, Derald Woods >> wrote: >> >>> On Mon, Aug 7, 2017 at 7:41 AM, Tom Rini wrote: >>> On Mon, Aug 07, 2017 at 07:35:30AM -0500, Derald Woods wrote: > On Mon, Jul 31, 2017 at 7:41 AM, Derald D. Woods < woods.techni...@gmail.com> > wrote: > > > Fixes: 00bbe96ebabb ("arm: omap: Unify get_device_type() function") > > > > The control status register value is embedded in a structure somewhere > > in SRAM, with the last refactoring effort. This patch allows OMAP3 EVM > > (TMDSEVM3530) to boot again using the known control register base and > > offset for 'readl', for the OMAP34XX case. > > > > Signed-off-by: Derald D. Woods > > > > --- > > Changes in v2: > > - Added 'signed-off-by' > > - Updated description > > > > --- > > arch/arm/mach-omap2/sysinfo-common.c | 4 > > 1 file changed, 4 insertions(+) > > > > diff --git a/arch/arm/mach-omap2/sysinfo-common.c > > b/arch/arm/mach-omap2/sysinfo-common.c > > index 1dc7051ab3..3955e803ad 100644 > > --- a/arch/arm/mach-omap2/sysinfo-common.c > > +++ b/arch/arm/mach-omap2/sysinfo-common.c > > @@ -16,6 +16,10 @@ > > */ > > u32 get_device_type(void) > > { > > +#if defined(CONFIG_OMAP34XX) > > + return (readl(OMAP34XX_CTRL_BASE + 0x2f0) & DEVICE_TYPE_MASK) >> > > + DEVICE_TYPE_SHIFT; > > +#endif > > return (readl((*ctrl)->control_status) & DEVICE_TYPE_MASK) >> > > DEVICE_TYPE_SHIFT; > > } > > Is there any comment or concern with this patch? It was the simplest > means to get OMAP35XX booting again and still keep the original patch. > Basically it avoids the pointer to the OMAP_SRAM_SCRATCH_SYS_CTRL located > structure as now defined in "arch/arm/mach-omap2/omap3/hw_data.c". OMAP3 > has a larger active SOC base than just OMAP36XX and greater. Was there > anything really broken with 'get_device_type()' previously? Is the pointer value wrong for 35xx? The problem, such as it was, was having the same function duplicated in a number of places, and needing to make it more easily / readily available (rather than duplicated again) for some additional patches. I'd really rather not introduce an #if here unless we really have no other choice. Thanks! -- Tom >>> >>> I will examine/debug the new 'get_device_type()' source code again >>> tonight. Without the patch, I have two OMAP3530 boards that do not boot at >>> all. >>> >> >> >> Derald >> >> >> In "arch/arm/mach-omap2/omap3/board.c", the following routines call >> 'get_device_type': >> - v7_arch_cp15_set_l2aux_ctrl (called from >> "arch/arm/cpu/armv7/start.S") >> - v7_arch_cp15_set_acr (called from >> "arch/arm/cpu/armv7/start.S") >> - omap3_invalidate_l2_cache_secure (called from "board.c" 's_init') >> - try_unlock_memory(called from "board.c" 's_init') >> >> Each one of these calls to 'get_device_type' seems to have a purpose >> (i.e. ERRATA or setup). What it highlights is the difference in usage from >> OMAP36XX, AM33XX, and newer. The SRAM usage, L2 cache and call ordering are >> likely factors here. Figuring out the implications for OMAP34XX will take >> time. But you need to have boards that boot to address those issues. So >> 'get_device_type' usage, for OMAP34XX, is not strictly a "Apples to Apples" >> type comparison. For now I can proceed with an "out-of-tree" patch, since >> it is small. Let me know if there is something that I am missing here. >> >> Derald >> > > > Based on all of the above, I think the "#if" is still the simplest path to > booting. > > Derald > > > Are there any further thoughts about OMAP34XX calling 'get_device_type()' from "start.S"? Derald ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 08/15] efi_loader: use proper device-paths for partitions
On Sat, Aug 12, 2017 at 8:36 AM, Alexander Graf wrote: > > > On 10.08.17 20:29, Rob Clark wrote: >> >> Also, create disk objects for the disk itself, in addition to the >> partitions. (UEFI terminology is a bit confusing, a "disk" object is >> really a partition.) This helps grub properly identify the boot device >> since it is trying to match up partition "disk" object with it's parent >> device. >> >> Now instead of seeing devices like: >> >>/File(sd...@07864000.blk)/EndEntire >>/File(usb_mass_storage.lun0)/EndEntire >> >> You see: >> >>/ACPI(133741d0,0)/UnknownMessaging(1d)/EndEntire >> >> /ACPI(133741d0,0)/UnknownMessaging(1d)/HD(0,800,64000,dd904a8c,1,1)/EndEntire >> >> /ACPI(133741d0,0)/UnknownMessaging(1d)/HD(1,64800,20,dd904a8c,1,1)/EndEntire >> >> /ACPI(133741d0,0)/UnknownMessaging(1d)/HD(2,264800,19a000,dd904a8c,1,1)/EndEntire >>/ACPI(133741d0,0)/USB(0,0)/USB(0,0)/USB(0,0)/EndEntire >> >> /ACPI(133741d0,0)/USB(0,0)/USB(0,0)/USB(0,0)/HD(0,800,6,38ca6802,1,1)/EndEntire >> >> /ACPI(133741d0,0)/USB(0,0)/USB(0,0)/USB(0,0)/HD(1,61000,155000,38ca6802,1,1)/EndEntire >> >> /ACPI(133741d0,0)/USB(0,0)/USB(0,0)/USB(0,0)/HD(2,20fa800,1bbf8800,38ca6802,1,1)/EndEntire >> >> /ACPI(133741d0,0)/USB(0,0)/USB(0,0)/USB(0,0)/HD(3,1b6800,1f44000,38ca6802,1,1)/EndEntire >> >> This is on a board with single USB disk and single sd-card. The >> UnknownMessaging(1d) node in the device-path is the MMC device, >> but grub_efi_print_device_path() hasn't been updated yet for some >> of the newer device-path sub-types. >> >> This patch is inspired by a patch originally from Peter Jones, but >> re-worked to use efi_device_path, so it doesn't much resemble the >> original. >> >> Signed-off-by: Rob Clark >> --- >> lib/efi_loader/efi_disk.c | 54 >> +++ >> 1 file changed, 31 insertions(+), 23 deletions(-) >> >> diff --git a/lib/efi_loader/efi_disk.c b/lib/efi_loader/efi_disk.c >> index ed06485e33..eea65a402a 100644 >> --- a/lib/efi_loader/efi_disk.c >> +++ b/lib/efi_loader/efi_disk.c >> @@ -28,11 +28,13 @@ struct efi_disk_obj { >> /* EFI Interface Media descriptor struct, referenced by ops */ >> struct efi_block_io_media media; >> /* EFI device path to this block device */ >> - struct efi_device_path_file_path *dp; >> + struct efi_device_path *dp; >> + /* partition # */ >> + unsigned part; >> /* Offset into disk for simple partitions */ >> lbaint_t offset; >> /* Internal block device */ >> - const struct blk_desc *desc; >> + struct blk_desc *desc; >> }; >> static efi_status_t EFIAPI efi_disk_reset(struct efi_block_io *this, >> @@ -172,26 +174,26 @@ static const struct efi_block_io >> block_io_disk_template = { >> static void efi_disk_add_dev(const char *name, >> const char *if_typename, >> -const struct blk_desc *desc, >> +struct blk_desc *desc, >> int dev_index, >> -lbaint_t offset) >> +lbaint_t offset, >> +unsigned part) >> { >> struct efi_disk_obj *diskobj; >> - struct efi_device_path_file_path *dp; >> - int objlen = sizeof(*diskobj) + (sizeof(*dp) * 2); >> /* Don't add empty devices */ >> if (!desc->lba) >> return; >> - diskobj = calloc(1, objlen); >> + diskobj = calloc(1, sizeof(*diskobj)); >> /* Fill in object data */ >> - dp = (void *)&diskobj[1]; >> + diskobj->dp = efi_dp_from_part(desc, part); >> + diskobj->part = part; >> diskobj->parent.protocols[0].guid = &efi_block_io_guid; >> diskobj->parent.protocols[0].protocol_interface = &diskobj->ops; >> diskobj->parent.protocols[1].guid = &efi_guid_device_path; >> - diskobj->parent.protocols[1].protocol_interface = dp; >> + diskobj->parent.protocols[1].protocol_interface = diskobj->dp; >> diskobj->parent.handle = diskobj; >> diskobj->ops = block_io_disk_template; >> diskobj->ifname = if_typename; >> @@ -207,17 +209,6 @@ static void efi_disk_add_dev(const char *name, >> diskobj->media.last_block = desc->lba - offset; >> diskobj->ops.media = &diskobj->media; >> - /* Fill in device path */ >> - diskobj->dp = dp; >> - dp[0].dp.type = DEVICE_PATH_TYPE_MEDIA_DEVICE; >> - dp[0].dp.sub_type = DEVICE_PATH_SUB_TYPE_FILE_PATH; >> - dp[0].dp.length = sizeof(*dp); >> - ascii2unicode(dp[0].str, name); >> - >> - dp[1].dp.type = DEVICE_PATH_TYPE_END; >> - dp[1].dp.sub_type = DEVICE_PATH_SUB_TYPE_END; >> - dp[1].dp.length = sizeof(*dp); >> - >> /* Hook up to the device list */ >> list_add_tail(&diskobj->parent.link, &efi_obj_list); >> } >> @@ -2
Re: [U-Boot] [PATCH v1 14/15] efi_loader: efi variable support
On Sat, Aug 12, 2017 at 9:01 AM, Alexander Graf wrote: > > > On 10.08.17 20:29, Rob Clark wrote: >> >> Add EFI variable support, mapping to u-boot environment variables. >> Variables are pretty important for setting up boot order, among other >> things. If the board supports saveenv, then it will be called in >> ExitBootServices() to persist variables set by the efi payload. (For >> example, fallback.efi configuring BootOrder and Boot load-option >> variables.) >> >> Variables are *not* currently exposed at runtime, post ExitBootServices. >> On boards without a dedicated device for storage, which the loaded OS >> is not trying to also use, this is rather tricky. One idea, at least >> for boards that can persist RAM across reboot, is to keep a "journal" >> of modified variables in RAM, and then turn halt into a reboot into >> u-boot, plus store variables, plus halt. Whatever the solution, it >> likely involves some per-board support. >> >> Mapping between EFI variables and u-boot variables: >> >>efi_$guid_$varname = {attributes}(type)value >> >> For example: >> >>efi_8be4df61-93ca-11d2-aa0d-00e098032b8c_OsIndicationsSupported= >> "{ro,boot,run}(blob)" >>efi_8be4df61-93ca-11d2-aa0d-00e098032b8c_BootOrder= >> "(blob)0001" >> >> The attributes are a comma separated list of these possible >> attributes: >> >>+ ro - read-only >>+ boot - boot-services access >>+ run - runtime access >> >> NOTE: with current implementation, no variables are available after >> ExitBootServices, and all are persisted (if possible). >> >> If not specified, the attributes default to "{boot}". >> >> The required type is one of: >> >>+ utf8 - raw utf8 string >>+ blob - arbitrary length hex string >> >> Signed-off-by: Rob Clark >> --- >> cmd/bootefi.c | 4 + >> include/efi.h | 19 +++ >> include/efi_loader.h | 10 ++ >> lib/efi_loader/Makefile | 2 +- >> lib/efi_loader/efi_boottime.c | 5 + >> lib/efi_loader/efi_runtime.c | 17 ++- >> lib/efi_loader/efi_variable.c | 342 >> ++ >> 7 files changed, 394 insertions(+), 5 deletions(-) >> create mode 100644 lib/efi_loader/efi_variable.c >> >> diff --git a/cmd/bootefi.c b/cmd/bootefi.c >> index b9e1e5e131..80f52e9e35 100644 >> --- a/cmd/bootefi.c >> +++ b/cmd/bootefi.c >> @@ -181,6 +181,10 @@ static unsigned long do_bootefi_exec(void *efi, void >> *fdt, >> goto exit; >> } >> + /* we don't support much: */ >> + >> setenv("efi_8be4df61-93ca-11d2-aa0d-00e098032b8c_OsIndicationsSupported", >> + "{ro,boot}(blob)"); >> + >> /* Call our payload! */ >> debug("%s:%d Jumping to 0x%lx\n", __func__, __LINE__, >> (long)entry); >> diff --git a/include/efi.h b/include/efi.h >> index ddd2b96417..dbd482a5db 100644 >> --- a/include/efi.h >> +++ b/include/efi.h >> @@ -324,6 +324,25 @@ extern char image_base[]; >> /* Start and end of U-Boot image (for payload) */ >> extern char _binary_u_boot_bin_start[], _binary_u_boot_bin_end[]; >> +/* >> + * Variable Attributes >> + */ >> +#define EFI_VARIABLE_NON_VOLATILE 0x0001 > > > Shouldn't we honor this one too? A UEFI application may set runtime > variables that should not get persisted across boots (think the UEFI shell > setting some internal state thing, then booting Linux). So the thing is, we honor non-volatile (at least to the extent the board can do saveenv()). What we don't do is make volatile vars disappear on reboot... which isn't terribly easy to do since we don't have any way to mark u-boot env vars as volatile. But my reading of the spec doesn't preclude volatile variables from being persisted. It only says that non-volatile variables should be persisted. > >> +#define EFI_VARIABLE_BOOTSERVICE_ACCESS 0x0002 >> +#define EFI_VARIABLE_RUNTIME_ACCESS 0x0004 >> +#define EFI_VARIABLE_HARDWARE_ERROR_RECORD 0x0008 >> +#define EFI_VARIABLE_AUTHENTICATED_WRITE_ACCESS 0x0010 >> +#define EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS >> 0x0020 >> +#define EFI_VARIABLE_APPEND_WRITE 0x0040 >> + >> +#define EFI_VARIABLE_MASK (EFI_VARIABLE_NON_VOLATILE | \ >> + EFI_VARIABLE_BOOTSERVICE_ACCESS | \ >> + EFI_VARIABLE_RUNTIME_ACCESS | \ >> + EFI_VARIABLE_HARDWARE_ERROR_RECORD | \ >> + EFI_VARIABLE_AUTHENTICATED_WRITE_ACCESS | >> \ >> + >> EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS | \ >> + EFI_VARIABLE_APPEND_WRITE) >> + >> /** >>* efi_get_sys_table() - Get access to the main EFI system table >>* >> diff --git a/include/efi_loader.h b/include/efi_loader.h >> index efb93f31f7..9cb568e615 100644 >> --- a/include/efi_loader.h >> +++
Re: [U-Boot] [PATCH v2 2/5] arm: socfpga: Add checking function on FPGA setting in FDT
On 08/12/2017 10:05 AM, Chee, Tien Fong wrote: > On Jum, 2017-08-11 at 17:01 +0200, Marek Vasut wrote: >> On 08/10/2017 06:51 AM, Chee, Tien Fong wrote: >>> >>> On Rab, 2017-08-09 at 10:20 +0200, Marek Vasut wrote: On 08/09/2017 07:07 AM, Chee, Tien Fong wrote: > > > On Sel, 2017-08-08 at 11:29 +0200, Marek Vasut wrote: >> >> >> On 08/08/2017 11:12 AM, tien.fong.c...@intel.com wrote: >>> >>> >>> >>> From: Tien Fong Chee >>> >>> Function for checking FPGA early release setting which is >>> defined >>> by user in FDT chosen section. This function would be used >>> by >>> later driver in decision applying appropriate FPGA >>> configuration in >>> early release or full FPGA booting mode. >> Isn't this a property of the FPGA driver ? >>> This is not property of fpga driver. It acts like passing data flag >>> to >>> u-boot, so u-boot knows how to boot in the mode defined by user. >> So it's a configuration option ? Doing what ... since there's no >> binding >> document, it's not clear. >> > Okay, i can add decription into / doc / device-tree-bindings / > chosen.txt. >>> > >> >> Shouldn't this have altr, prefix ? >>> This node doesn't represet a real device, it acts like a place for >>> passing data to U-boot. So, this flag name doesn't matter with >>> prefix, >>> right? >> But it's altera-specific, so it should have one ? >> > Yeah, i can add it. OK -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/5] mmc: uniphier-sd: Factor out register IO
On 08/10/2017 09:49 AM, Masahiro Yamada wrote: > Hi. > > > 2017-08-07 17:30 GMT+09:00 Marek Vasut : >> On 08/07/2017 04:30 AM, Masahiro Yamada wrote: >>> Hi Marek, >> >> Hi Masahiro, >> >> This is gonna be a great discussion, let's wrestle about consts and ints :-) >> >>> 2017-08-06 4:23 GMT+09:00 Marek Vasut : On 08/03/2017 02:36 PM, Masahiro Yamada wrote: > Hi Marek, Hi, [...] >> +static u32 uniphier_sd_readl(struct uniphier_sd_priv *priv, const u32 >> reg) > > "const" is unneeded here. Why? The function should not modify reg , so it is const. >>> >>> >>> Because "const" is useless here. >>> >>> The "reg" is not a pointer, so it is obvious >>> that there is no impact to the callers. >>> >>> >>> >>> Moreover, whether "reg" is constant or not >>> depends on how you implement the function. >>> >>> >>> If you force "const" to the argument, the only choice for the implementation >>> will be as follows: >>> >>> >>> >>> static u32 uniphier_sd_readl(struct uniphier_sd_priv *priv, const u32 reg) >>> { >>> if (priv->caps & UNIPHIER_SD_CAP_64BIT) >>> return readl(priv->regbase + (reg << 1)); >>> else >>> return readl(priv->regbase + reg); >>> } >>> >>> >>> >>> If you want to implement the function as follows, you need to drop "const". >>> >>> static u32 uniphier_sd_readl(struct uniphier_sd_priv *priv, u32 reg) >>> { >>> if (priv->caps & UNIPHIER_SD_CAP_64BIT) >>> reg <<= 1; >>> >>> return readl(priv->regbase + reg); >>> } >> >> My argument would be that the const prevents you from accidentally >> modifying the $reg inside the function. > > > No. > The arguments of a functions are local variables. > No impact on the outside of the scope of the function. I'm not arguing about that. > If you accidentally modify a variable where it should not, > it is a bug. Just fix it. If it's const, compiler will warn the user he's doing something stupid. > If you want to wrestle more, please do it in LKML > by adding around "const". > > For example, > > drivers/base/regmap/regmap.c: > int regmap_write(struct regmap *map, unsigned int reg, unsigned int val) > > arch/arm/include/asm/io.h: > static inline void __raw_writel(u32 val, volatile void __iomem *addr) Well, there were some cocci patches adding const recently :) -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 4/5] arm: socfpga: Add intermediate driver between flash and FPGA manager
On 08/12/2017 10:03 AM, Chee, Tien Fong wrote: [...] >>> 1: It having ability to the right memory(OCRAM or SDRAM) to achieve >>> the >>> best FPGA programing performance. >> Did you find significant throughput difference ? >> > 80% performance improvement with SDRAM. This looks more like caches are not enabled ... sort of problem ? >>> 2: It can determine the right size buffer for the fpga rbf without >>> info >>> of buffer size defined by user. >> You mean like $filesize variable in the command prompt ? >> > Yeah. No filesize is required. You can use $filesize instead of reimplementing this functionality yourself though ? >>> 3: It has ability to know what kind of fpga rbf type, and security >>> type, such as peripheral, core, combined rbf, encryption and >>> unencryption based on any fpga file user pass in . >> Is this information used for anything ? I was under the impression >> that >> the user just needs to load in the correct RBF file into the FPGA. >> > Yeah, the driver would decode the RBF image to know what type of RBF > user loading, and applying correct method(buffer allocation, which > memory to use and configuration on FPGA manager) to program FPGA. If the code needs to extract some information from the RBF to correctly configure something in the FPGA manager, then that's where this should go then. >>> 4: It supports the checksum. >> What checksum ? Can we have a generic hook into the FPGA framework ? >> > This checksum is to ensure integrity of RBF file after loading from > flash into SDRAM. This can help to prevent possibility system > instability caused by programming corrupt rbf into FPGA. So, this > should be implemented in cff.c . Or the FPGA manager driver . >>> 5: support raw flash without fs. >> This should go into common code. >> > raw flash is part of common codes in cff.c because it is part of > mechanism like fs to determine how loading rbf from flash and program > into fpga. By common code I mean the stuff around FPGA LOADFS , so other FPGAs can also benefit from that. >>> 6: support the file name defined in DTS and U-boot environment >>> variable. >> I think you should extend the FPGA LOADFS here instead. >> > The peripheral rbf filename and DTS are generated from our bsp tool. > But user can run fpga loadfs to reconfigure FPGA in U-boot console > after i have supported it. And why don't you rather apply some FPGA LOADFS if this property is detected in the DT instead of reimplementing it ? >>> Also, the ifdeffery is awful and the explicit depedence on VFAT when loading from FS is real bad. >>> It is because a lot functions is common to sdmmc, nand and qspi in >>> different fs such as vfat, ubi and raw. It is unavoidable to have >>> some >>> ifdeffery if we want to keep the function common to all flashes and >>> fs. >> Can the FPGA LOADFS be extended generically ? >> > Yeah, FPGA loadfs is considered when design cff.c. But, i plan to to > support FPGA loadfs after having complete boot to U-boot console. Does that mean the Arria10 is still not even capable of booting into U-Boot console ? cff.c is unlikely to hit mainline unless there's compelling argument that it is needed . Thus far, I see most of the functionality should be added elsewhere or is already there (fpga loadfs). -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 02/15] fs/fat: implement readdir
> Am 12.08.2017 um 16:04 schrieb Rob Clark : > >> On Sat, Aug 12, 2017 at 8:17 AM, Alexander Graf wrote: >> >> >>> On 10.08.17 20:29, Rob Clark wrote: >>> >>> Yes, this is super-hacky. The FAT code is quite ugly, and this doesn't >>> improve things. But it doesn't make it significantly worse either. The >>> better option would be a massive FAT re-write to get rid of the hacky >>> way that fat_file_ls() works. Volunteers welcome. >>> >>> Signed-off-by: Rob Clark >> >> >> What concerns me the most in patch 1/15 and this patch is the limited scope. >> Yes, you make readdir work for FAT, but all other file systems are still >> unimplemented. In fact, they're even all still implementing their own >> hand-written ls logic. >> >> One of the goals of the efi_loader code is to integrate with U-Boot as much >> as possible, to reuse code where we can. And if current interfaces are >> terrible, I think it's ok to just replace them for something that fits >> everyone's needs better. >> >> How feasible do you think it would be to implement an ls function based on >> readdir and just convert all file systems to it, completely replacing the >> current (quite crude) ls logic? > > So I went ahead and re-wrote the fat directory traversal[1]. I should > be posting to list in the next day or two but still want to make a few > small cleanups. (And to get rid of some hacks in efi_file, I think I > need to add an fs_isdir() too :-/) > > As far as the various other filesys's, I agree that a generic ls would > be a nice goal. But the scope of the efi_loader patchset has already > expanded way too much, and at this point I'm pretty much limited by > what I can finish this weekend. At the end of the day, FAT is all > that UEFI expects, so I think it is fine to let the other filesystems > catch up on their own schedule. > > I could write a generic ls helper, and just plug it in for FAT, which > could be re-used later when other filesys's gain readdir support. That at least sounds much nicer than duplicating ls functionality and moves us into the right direction. Thanks! Alex ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 08/15] efi_loader: use proper device-paths for partitions
> Am 12.08.2017 um 16:31 schrieb Rob Clark : > >> On Sat, Aug 12, 2017 at 8:36 AM, Alexander Graf wrote: >> >> >>> On 10.08.17 20:29, Rob Clark wrote: >>> >>> Also, create disk objects for the disk itself, in addition to the >>> partitions. (UEFI terminology is a bit confusing, a "disk" object is >>> really a partition.) This helps grub properly identify the boot device >>> since it is trying to match up partition "disk" object with it's parent >>> device. >>> >>> Now instead of seeing devices like: >>> >>> /File(sd...@07864000.blk)/EndEntire >>> /File(usb_mass_storage.lun0)/EndEntire >>> >>> You see: >>> >>> /ACPI(133741d0,0)/UnknownMessaging(1d)/EndEntire >>> >>> /ACPI(133741d0,0)/UnknownMessaging(1d)/HD(0,800,64000,dd904a8c,1,1)/EndEntire >>> >>> /ACPI(133741d0,0)/UnknownMessaging(1d)/HD(1,64800,20,dd904a8c,1,1)/EndEntire >>> >>> /ACPI(133741d0,0)/UnknownMessaging(1d)/HD(2,264800,19a000,dd904a8c,1,1)/EndEntire >>> /ACPI(133741d0,0)/USB(0,0)/USB(0,0)/USB(0,0)/EndEntire >>> >>> /ACPI(133741d0,0)/USB(0,0)/USB(0,0)/USB(0,0)/HD(0,800,6,38ca6802,1,1)/EndEntire >>> >>> /ACPI(133741d0,0)/USB(0,0)/USB(0,0)/USB(0,0)/HD(1,61000,155000,38ca6802,1,1)/EndEntire >>> >>> /ACPI(133741d0,0)/USB(0,0)/USB(0,0)/USB(0,0)/HD(2,20fa800,1bbf8800,38ca6802,1,1)/EndEntire >>> >>> /ACPI(133741d0,0)/USB(0,0)/USB(0,0)/USB(0,0)/HD(3,1b6800,1f44000,38ca6802,1,1)/EndEntire >>> >>> This is on a board with single USB disk and single sd-card. The >>> UnknownMessaging(1d) node in the device-path is the MMC device, >>> but grub_efi_print_device_path() hasn't been updated yet for some >>> of the newer device-path sub-types. >>> >>> This patch is inspired by a patch originally from Peter Jones, but >>> re-worked to use efi_device_path, so it doesn't much resemble the >>> original. >>> >>> Signed-off-by: Rob Clark >>> --- >>> lib/efi_loader/efi_disk.c | 54 >>> +++ >>> 1 file changed, 31 insertions(+), 23 deletions(-) >>> >>> diff --git a/lib/efi_loader/efi_disk.c b/lib/efi_loader/efi_disk.c >>> index ed06485e33..eea65a402a 100644 >>> --- a/lib/efi_loader/efi_disk.c >>> +++ b/lib/efi_loader/efi_disk.c >>> @@ -28,11 +28,13 @@ struct efi_disk_obj { >>>/* EFI Interface Media descriptor struct, referenced by ops */ >>>struct efi_block_io_media media; >>>/* EFI device path to this block device */ >>> - struct efi_device_path_file_path *dp; >>> + struct efi_device_path *dp; >>> + /* partition # */ >>> + unsigned part; >>>/* Offset into disk for simple partitions */ >>>lbaint_t offset; >>>/* Internal block device */ >>> - const struct blk_desc *desc; >>> + struct blk_desc *desc; >>> }; >>>static efi_status_t EFIAPI efi_disk_reset(struct efi_block_io *this, >>> @@ -172,26 +174,26 @@ static const struct efi_block_io >>> block_io_disk_template = { >>>static void efi_disk_add_dev(const char *name, >>> const char *if_typename, >>> -const struct blk_desc *desc, >>> +struct blk_desc *desc, >>> int dev_index, >>> -lbaint_t offset) >>> +lbaint_t offset, >>> +unsigned part) >>> { >>>struct efi_disk_obj *diskobj; >>> - struct efi_device_path_file_path *dp; >>> - int objlen = sizeof(*diskobj) + (sizeof(*dp) * 2); >>>/* Don't add empty devices */ >>>if (!desc->lba) >>>return; >>> - diskobj = calloc(1, objlen); >>> + diskobj = calloc(1, sizeof(*diskobj)); >>>/* Fill in object data */ >>> - dp = (void *)&diskobj[1]; >>> + diskobj->dp = efi_dp_from_part(desc, part); >>> + diskobj->part = part; >>>diskobj->parent.protocols[0].guid = &efi_block_io_guid; >>>diskobj->parent.protocols[0].protocol_interface = &diskobj->ops; >>>diskobj->parent.protocols[1].guid = &efi_guid_device_path; >>> - diskobj->parent.protocols[1].protocol_interface = dp; >>> + diskobj->parent.protocols[1].protocol_interface = diskobj->dp; >>>diskobj->parent.handle = diskobj; >>>diskobj->ops = block_io_disk_template; >>>diskobj->ifname = if_typename; >>> @@ -207,17 +209,6 @@ static void efi_disk_add_dev(const char *name, >>>diskobj->media.last_block = desc->lba - offset; >>>diskobj->ops.media = &diskobj->media; >>> - /* Fill in device path */ >>> - diskobj->dp = dp; >>> - dp[0].dp.type = DEVICE_PATH_TYPE_MEDIA_DEVICE; >>> - dp[0].dp.sub_type = DEVICE_PATH_SUB_TYPE_FILE_PATH; >>> - dp[0].dp.length = sizeof(*dp); >>> - ascii2unicode(dp[0].str, name); >>> - >>> - dp[1].dp.type = DEVICE_PATH_TYPE_END; >>> - dp[1].dp.sub_type = DEVICE_PATH_SUB_TYPE_END; >>> - dp[1].dp
Re: [U-Boot] [PATCH v1 14/15] efi_loader: efi variable support
> Am 12.08.2017 um 16:39 schrieb Rob Clark : > >> On Sat, Aug 12, 2017 at 9:01 AM, Alexander Graf wrote: >> >> >>> On 10.08.17 20:29, Rob Clark wrote: >>> >>> Add EFI variable support, mapping to u-boot environment variables. >>> Variables are pretty important for setting up boot order, among other >>> things. If the board supports saveenv, then it will be called in >>> ExitBootServices() to persist variables set by the efi payload. (For >>> example, fallback.efi configuring BootOrder and Boot load-option >>> variables.) >>> >>> Variables are *not* currently exposed at runtime, post ExitBootServices. >>> On boards without a dedicated device for storage, which the loaded OS >>> is not trying to also use, this is rather tricky. One idea, at least >>> for boards that can persist RAM across reboot, is to keep a "journal" >>> of modified variables in RAM, and then turn halt into a reboot into >>> u-boot, plus store variables, plus halt. Whatever the solution, it >>> likely involves some per-board support. >>> >>> Mapping between EFI variables and u-boot variables: >>> >>> efi_$guid_$varname = {attributes}(type)value >>> >>> For example: >>> >>> efi_8be4df61-93ca-11d2-aa0d-00e098032b8c_OsIndicationsSupported= >>> "{ro,boot,run}(blob)" >>> efi_8be4df61-93ca-11d2-aa0d-00e098032b8c_BootOrder= >>> "(blob)0001" >>> >>> The attributes are a comma separated list of these possible >>> attributes: >>> >>> + ro - read-only >>> + boot - boot-services access >>> + run - runtime access >>> >>> NOTE: with current implementation, no variables are available after >>> ExitBootServices, and all are persisted (if possible). >>> >>> If not specified, the attributes default to "{boot}". >>> >>> The required type is one of: >>> >>> + utf8 - raw utf8 string >>> + blob - arbitrary length hex string >>> >>> Signed-off-by: Rob Clark >>> --- >>> cmd/bootefi.c | 4 + >>> include/efi.h | 19 +++ >>> include/efi_loader.h | 10 ++ >>> lib/efi_loader/Makefile | 2 +- >>> lib/efi_loader/efi_boottime.c | 5 + >>> lib/efi_loader/efi_runtime.c | 17 ++- >>> lib/efi_loader/efi_variable.c | 342 >>> ++ >>> 7 files changed, 394 insertions(+), 5 deletions(-) >>> create mode 100644 lib/efi_loader/efi_variable.c >>> >>> diff --git a/cmd/bootefi.c b/cmd/bootefi.c >>> index b9e1e5e131..80f52e9e35 100644 >>> --- a/cmd/bootefi.c >>> +++ b/cmd/bootefi.c >>> @@ -181,6 +181,10 @@ static unsigned long do_bootefi_exec(void *efi, void >>> *fdt, >>>goto exit; >>>} >>> + /* we don't support much: */ >>> + >>> setenv("efi_8be4df61-93ca-11d2-aa0d-00e098032b8c_OsIndicationsSupported", >>> + "{ro,boot}(blob)"); >>> + >>>/* Call our payload! */ >>>debug("%s:%d Jumping to 0x%lx\n", __func__, __LINE__, >>> (long)entry); >>> diff --git a/include/efi.h b/include/efi.h >>> index ddd2b96417..dbd482a5db 100644 >>> --- a/include/efi.h >>> +++ b/include/efi.h >>> @@ -324,6 +324,25 @@ extern char image_base[]; >>> /* Start and end of U-Boot image (for payload) */ >>> extern char _binary_u_boot_bin_start[], _binary_u_boot_bin_end[]; >>> +/* >>> + * Variable Attributes >>> + */ >>> +#define EFI_VARIABLE_NON_VOLATILE 0x0001 >> >> >> Shouldn't we honor this one too? A UEFI application may set runtime >> variables that should not get persisted across boots (think the UEFI shell >> setting some internal state thing, then booting Linux). > > So the thing is, we honor non-volatile (at least to the extent the > board can do saveenv()). What we don't do is make volatile vars > disappear on reboot... which isn't terribly easy to do since we don't > have any way to mark u-boot env vars as volatile. > > But my reading of the spec doesn't preclude volatile variables from > being persisted. It only says that non-volatile variables should be > persisted. The spec actually says in the non_volatile definition that volatile vars get stored in ram and will disappear after reboot. Volatile could just be an attribute like all the others and before saveenv we just search for volatile and remove them? > >> >>> +#define EFI_VARIABLE_BOOTSERVICE_ACCESS 0x0002 >>> +#define EFI_VARIABLE_RUNTIME_ACCESS 0x0004 >>> +#define EFI_VARIABLE_HARDWARE_ERROR_RECORD 0x0008 >>> +#define EFI_VARIABLE_AUTHENTICATED_WRITE_ACCESS 0x0010 >>> +#define EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS >>> 0x0020 >>> +#define EFI_VARIABLE_APPEND_WRITE 0x0040 >>> + >>> +#define EFI_VARIABLE_MASK (EFI_VARIABLE_NON_VOLATILE | \ >>> + EFI_VARIABLE_BOOTSERVICE_ACCESS | \ >>> + EFI_VARIABLE_RUNTIME_ACCESS | \ >>> + EFI_VARIABLE_HARDWARE_ERROR_RECORD | \ >>> +
Re: [U-Boot] [PATCH v1 14/15] efi_loader: efi variable support
On Sat, Aug 12, 2017 at 1:28 PM, Alexander Graf wrote: > > >> Am 12.08.2017 um 16:39 schrieb Rob Clark : >> >>> On Sat, Aug 12, 2017 at 9:01 AM, Alexander Graf wrote: >>> >>> On 10.08.17 20:29, Rob Clark wrote: Add EFI variable support, mapping to u-boot environment variables. Variables are pretty important for setting up boot order, among other things. If the board supports saveenv, then it will be called in ExitBootServices() to persist variables set by the efi payload. (For example, fallback.efi configuring BootOrder and Boot load-option variables.) Variables are *not* currently exposed at runtime, post ExitBootServices. On boards without a dedicated device for storage, which the loaded OS is not trying to also use, this is rather tricky. One idea, at least for boards that can persist RAM across reboot, is to keep a "journal" of modified variables in RAM, and then turn halt into a reboot into u-boot, plus store variables, plus halt. Whatever the solution, it likely involves some per-board support. Mapping between EFI variables and u-boot variables: efi_$guid_$varname = {attributes}(type)value For example: efi_8be4df61-93ca-11d2-aa0d-00e098032b8c_OsIndicationsSupported= "{ro,boot,run}(blob)" efi_8be4df61-93ca-11d2-aa0d-00e098032b8c_BootOrder= "(blob)0001" The attributes are a comma separated list of these possible attributes: + ro - read-only + boot - boot-services access + run - runtime access NOTE: with current implementation, no variables are available after ExitBootServices, and all are persisted (if possible). If not specified, the attributes default to "{boot}". The required type is one of: + utf8 - raw utf8 string + blob - arbitrary length hex string Signed-off-by: Rob Clark --- cmd/bootefi.c | 4 + include/efi.h | 19 +++ include/efi_loader.h | 10 ++ lib/efi_loader/Makefile | 2 +- lib/efi_loader/efi_boottime.c | 5 + lib/efi_loader/efi_runtime.c | 17 ++- lib/efi_loader/efi_variable.c | 342 ++ 7 files changed, 394 insertions(+), 5 deletions(-) create mode 100644 lib/efi_loader/efi_variable.c diff --git a/cmd/bootefi.c b/cmd/bootefi.c index b9e1e5e131..80f52e9e35 100644 --- a/cmd/bootefi.c +++ b/cmd/bootefi.c @@ -181,6 +181,10 @@ static unsigned long do_bootefi_exec(void *efi, void *fdt, goto exit; } + /* we don't support much: */ + setenv("efi_8be4df61-93ca-11d2-aa0d-00e098032b8c_OsIndicationsSupported", + "{ro,boot}(blob)"); + /* Call our payload! */ debug("%s:%d Jumping to 0x%lx\n", __func__, __LINE__, (long)entry); diff --git a/include/efi.h b/include/efi.h index ddd2b96417..dbd482a5db 100644 --- a/include/efi.h +++ b/include/efi.h @@ -324,6 +324,25 @@ extern char image_base[]; /* Start and end of U-Boot image (for payload) */ extern char _binary_u_boot_bin_start[], _binary_u_boot_bin_end[]; +/* + * Variable Attributes + */ +#define EFI_VARIABLE_NON_VOLATILE 0x0001 >>> >>> >>> Shouldn't we honor this one too? A UEFI application may set runtime >>> variables that should not get persisted across boots (think the UEFI shell >>> setting some internal state thing, then booting Linux). >> >> So the thing is, we honor non-volatile (at least to the extent the >> board can do saveenv()). What we don't do is make volatile vars >> disappear on reboot... which isn't terribly easy to do since we don't >> have any way to mark u-boot env vars as volatile. >> >> But my reading of the spec doesn't preclude volatile variables from >> being persisted. It only says that non-volatile variables should be >> persisted. > > The spec actually says in the non_volatile definition that volatile vars get > stored in ram and will disappear after reboot. > > Volatile could just be an attribute like all the others and before saveenv we > just search for volatile and remove them? > I could add it as an attribute. Although I'm not sure there is any easy way to iterate env vars without digging into internals of nvedit (otherwise I probably would have already added GetNextVariable()) Possibly I should add an nv attribute anyways, for future-compat (which was the only reason I bothered adding boot and run attributes) BR, -R ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] arm: use $loadaddr as the standalone entry point
Dear Max, In message <20170812090346.7887-2-max.krummenac...@toradex.com> you wrote: > Different SoCs have different RAM layouts, so providing > $(CONFIG_LOADADDR) instead of the constant 0xc10 for > CONFIG_STANDALONE_LOAD_ADDR is probably more appropriate. At least the wording of the Subject should be fixed. It is fundamentaaly broken to associate the names "loadaddr" and "entry point" with each other. Both are completely independent entities which mean totally different things. It is pure chance if the entry point of some loaded image should be at the very beginning of this image, but this is almost never the case. Best regards, Wolfgang Denk -- 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 "The bad reputation UNIX has gotten is totally undeserved, laid on by people who don't understand, who have not gotten in there and tried anything." -- Jim Joyce, owner of Jim Joyce's UNIX Bookstore ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 0/2] improve hello_world standalone application for arm
Dear Max, In message <20170812090346.7887-1-max.krummenac...@toradex.com> you wrote: > > This series addresses > - hardcoded entry address, use LOADADDR if available as the entry point > instead I'm not sure which sort of problem you are trying to fix, but what you describe here is inherently broken. The entry point of an image is almost never ever at the beginning of an image. Naked-by: Wolfgang Denk Sorry! Best regards, Wolfgang Denk -- 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 What is wanted is not the will to believe, but the will to find out, which is the exact opposite. -- Bertrand Russell, "Skeptical Essays", 1928 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] hello_world.c: fix entry point in case of arm thumb binary
Dear Max, In message <20170812090346.7887-3-max.krummenac...@toradex.com> you wrote: > If compiling for thumb the U-Boot 'go' command can not jump to the entry > point, as the jump will be done in the assumption that the code jumped to > is using the arm instruction set. > > So add add a simple forwarder in arm instruction set which then jumps > to the 'real' entry. This description makes no sense to me. Whatever you do, the address where the image starts executuin is what is called the entry point. Whether this is needs special code to swutch to thumb mode or not does not make any difference. Whichever address you use with the "go" command is the "entry point". Also, can the mode switching not be done inside the body of the regular hello_world() function? This would be much better as it wuld allow to always use the same method to determine the entry point address (line running "nm" on the binary and grepping for the name "hello_world"). With your code, you would have to fix all documentation and explain that the entry pooint name is suddenly domething totally different (and an unexpected, unusal name like "dummy2" as well) for thumb images. Sorry, but this does not seem a good idea to me. Naked-by: Wolfgang Denk Best regards, Wolfgang Denk -- 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 The use of anthropomorphic terminology when dealing with computing systems is a symptom of professional immaturity. -- Edsger Dijkstra ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Convert CONFIG_NAND to Kconfig
On Mon, Aug 07, 2017 at 05:37:18PM -0400, Tom Rini wrote: > From: Adam Ford > > This converts the following to Kconfig: >CONFIG_NAND > > Signed-off-by: Adam Ford > [trini: Sync up a few more, add imply's] > Signed-off-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] arm: use $loadaddr as the standalone entry point
Dear Wolfgang Am Samstag, den 12.08.2017, 20:29 +0200 schrieb Wolfgang Denk: > Dear Max, > > In message <20170812090346.7887-2-max.krummenac...@toradex.com> you wrote: > > > > Different SoCs have different RAM layouts, so providing > > $(CONFIG_LOADADDR) instead of the constant 0xc10 for > > CONFIG_STANDALONE_LOAD_ADDR is probably more appropriate. > > At least the wording of the Subject should be fixed. Ok, will do. The issue is that linking the standalone application to have its text segment at a hardcoded address is less likely to work than using an address provided by the board configuration as a possible load address. Will reword the commit message in a v2 series accordingly. Max > > It is fundamentaaly broken to associate the names "loadaddr" and > "entry point" with each other. Both are completely independent > entities which mean totally different things. It is pure chance if > the entry point of some loaded image should be at the very beginning > of this image, but this is almost never the case. > > Best regards, > > Wolfgang Denk > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 0/2] improve hello_world standalone application for arm
Dear Wolfgang Am Samstag, den 12.08.2017, 20:32 +0200 schrieb Wolfgang Denk: > Dear Max, > > In message <20170812090346.7887-1-max.krummenac...@toradex.com> you wrote: > > > > > > This series addresses > > - hardcoded entry address, use LOADADDR if available as the entry point > > instead > > I'm not sure which sort of problem you are trying to fix, but what > you describe here is inherently broken. > > The entry point of an image is almost never ever at the beginning of > an image. I was mislead by the table in point 6. of doc/README.standalone that it is a design decision that the entry point is whatever is linked to the beginning of the text segment. Thus the sloppy use of entry point and load address. Max > > Naked-by: Wolfgang Denk > > Sorry! > > > Best regards, > > Wolfgang Denk > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] hello_world.c: fix entry point in case of arm thumb binary
Dear Wolfgang Am Samstag, den 12.08.2017, 20:39 +0200 schrieb Wolfgang Denk: > Dear Max, > > In message <20170812090346.7887-3-max.krummenac...@toradex.com> you wrote: > > > > If compiling for thumb the U-Boot 'go' command can not jump to the entry > > point, as the jump will be done in the assumption that the code jumped to > > is using the arm instruction set. > > > > So add add a simple forwarder in arm instruction set which then jumps > > to the 'real' entry. > > This description makes no sense to me. Whatever you do, the address > where the image starts executuin is what is called the entry point. > Whether this is needs special code to swutch to thumb mode or not > does not make any difference. Whichever address you use with the > "go" command is the "entry point". > > Also, can the mode switching not be done inside the body of the > regular hello_world() function? This would be much better as it > wuld allow to always use the same method to determine the entry > point address (line running "nm" on the binary and grepping for the > name "hello_world"). With your code, you would have to fix all > documentation and explain that the entry pooint name is suddenly > domething totally different (and an unexpected, unusal name like > "dummy2" as well) for thumb images. This again stems from my assumption that one has to write the standalone application in a way that the entry point is actually linked to the beginning of the binary. One cannot put the mode switching from thumb to arm instruction set inside the body of a C function, as the entry code prepended by the compiler would be in thumb and thus an exception would occur before the mode switching code gets executed. Probably one can add a pragma conditionally so that the entry function gets compiled in arm instruction set. I investigate further and send a v2. Max > > Sorry, but this does not seem a good idea to me. > > Naked-by: Wolfgang Denk > > Best regards, > > Wolfgang Denk > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] arm: omap: Fix 'get_device_type()' for OMAP34XX
On Thu, Aug 10, 2017 at 07:25:29AM -0500, Derald Woods wrote: > On Mon, Aug 7, 2017 at 5:19 PM, Derald Woods > wrote: > > > On Mon, Aug 7, 2017 at 7:41 AM, Tom Rini wrote: > > > >> On Mon, Aug 07, 2017 at 07:35:30AM -0500, Derald Woods wrote: > >> > On Mon, Jul 31, 2017 at 7:41 AM, Derald D. Woods < > >> woods.techni...@gmail.com> > >> > wrote: > >> > > >> > > Fixes: 00bbe96ebabb ("arm: omap: Unify get_device_type() function") > >> > > > >> > > The control status register value is embedded in a structure somewhere > >> > > in SRAM, with the last refactoring effort. This patch allows OMAP3 EVM > >> > > (TMDSEVM3530) to boot again using the known control register base and > >> > > offset for 'readl', for the OMAP34XX case. > >> > > > >> > > Signed-off-by: Derald D. Woods > >> > > > >> > > --- > >> > > Changes in v2: > >> > > - Added 'signed-off-by' > >> > > - Updated description > >> > > > >> > > --- > >> > > arch/arm/mach-omap2/sysinfo-common.c | 4 > >> > > 1 file changed, 4 insertions(+) > >> > > > >> > > diff --git a/arch/arm/mach-omap2/sysinfo-common.c > >> > > b/arch/arm/mach-omap2/sysinfo-common.c > >> > > index 1dc7051ab3..3955e803ad 100644 > >> > > --- a/arch/arm/mach-omap2/sysinfo-common.c > >> > > +++ b/arch/arm/mach-omap2/sysinfo-common.c > >> > > @@ -16,6 +16,10 @@ > >> > > */ > >> > > u32 get_device_type(void) > >> > > { > >> > > +#if defined(CONFIG_OMAP34XX) > >> > > + return (readl(OMAP34XX_CTRL_BASE + 0x2f0) & DEVICE_TYPE_MASK) > >> >> > >> > > + DEVICE_TYPE_SHIFT; > >> > > +#endif > >> > > return (readl((*ctrl)->control_status) & DEVICE_TYPE_MASK) >> > >> > > DEVICE_TYPE_SHIFT; > >> > > } > >> > > >> > Is there any comment or concern with this patch? It was the simplest > >> > means to get OMAP35XX booting again and still keep the original patch. > >> > Basically it avoids the pointer to the OMAP_SRAM_SCRATCH_SYS_CTRL > >> located > >> > structure as now defined in "arch/arm/mach-omap2/omap3/hw_data.c". > >> OMAP3 > >> > has a larger active SOC base than just OMAP36XX and greater. Was there > >> > anything really broken with 'get_device_type()' previously? > >> > >> Is the pointer value wrong for 35xx? The problem, such as it was, was > >> having the same function duplicated in a number of places, and needing > >> to make it more easily / readily available (rather than duplicated > >> again) for some additional patches. I'd really rather not introduce > >> an #if here unless we really have no other choice. Thanks! > >> > >> -- > >> Tom > >> > > > > I will examine/debug the new 'get_device_type()' source code again > > tonight. Without the patch, I have two OMAP3530 boards that do not boot at > > all. > > > > > Derald > > > In "arch/arm/mach-omap2/omap3/board.c", the following routines call > 'get_device_type': > - v7_arch_cp15_set_l2aux_ctrl (called from > "arch/arm/cpu/armv7/start.S") > - v7_arch_cp15_set_acr (called from > "arch/arm/cpu/armv7/start.S") > - omap3_invalidate_l2_cache_secure (called from "board.c" 's_init') > - try_unlock_memory(called from "board.c" 's_init') > > Each one of these calls to 'get_device_type' seems to have a purpose (i.e. > ERRATA or setup). What it highlights is the difference in usage from > OMAP36XX, AM33XX, and newer. The SRAM usage, L2 cache and call ordering are > likely factors here. Figuring out the implications for OMAP34XX will take > time. But you need to have boards that boot to address those issues. So > 'get_device_type' usage, for OMAP34XX, is not strictly a "Apples to Apples" > type comparison. For now I can proceed with an "out-of-tree" patch, since > it is small. Let me know if there is something that I am missing here. OK, thanks for the analysis. It is indeed a bit too much overhead atm to see if we can further reconcile all of the code and should grab your patch, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2] arm: omap: Fix 'get_device_type()' for OMAP34XX
On Mon, Jul 31, 2017 at 07:41:40AM -0500, Derald D. Woods wrote: > Fixes: 00bbe96ebabb ("arm: omap: Unify get_device_type() function") > > The control status register value is embedded in a structure somewhere > in SRAM, with the last refactoring effort. This patch allows OMAP3 EVM > (TMDSEVM3530) to boot again using the known control register base and > offset for 'readl', for the OMAP34XX case. > > Signed-off-by: Derald D. Woods Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 5/5] ARM: dts: uniphier: add dr_mode property to dwc3 node
Since commit 576e3cc700c5 ("usb: host: xhci-dwc3: Add dual role mode support from DT"), warning is displayed. Signed-off-by: Masahiro Yamada --- arch/arm/dts/uniphier-ld20.dtsi | 1 + arch/arm/dts/uniphier-pro4.dtsi | 2 ++ arch/arm/dts/uniphier-pro5.dtsi | 2 ++ arch/arm/dts/uniphier-pxs2.dtsi | 2 ++ 4 files changed, 7 insertions(+) diff --git a/arch/arm/dts/uniphier-ld20.dtsi b/arch/arm/dts/uniphier-ld20.dtsi index 927340fa48d2..44257aff35b9 100644 --- a/arch/arm/dts/uniphier-ld20.dtsi +++ b/arch/arm/dts/uniphier-ld20.dtsi @@ -426,6 +426,7 @@ compatible = "snps,dwc3"; reg = <0x65a0 0x1>; interrupts = <0 134 4>; + dr_mode = "host"; tx-fifo-resize; }; }; diff --git a/arch/arm/dts/uniphier-pro4.dtsi b/arch/arm/dts/uniphier-pro4.dtsi index 60287c478f25..cbb848207cc1 100644 --- a/arch/arm/dts/uniphier-pro4.dtsi +++ b/arch/arm/dts/uniphier-pro4.dtsi @@ -587,6 +587,7 @@ compatible = "snps,dwc3"; reg = <0x65a0 0x1>; interrupts = <0 134 4>; + dr_mode = "host"; tx-fifo-resize; }; }; @@ -604,6 +605,7 @@ compatible = "snps,dwc3"; reg = <0x65c0 0x1>; interrupts = <0 137 4>; + dr_mode = "host"; tx-fifo-resize; }; }; diff --git a/arch/arm/dts/uniphier-pro5.dtsi b/arch/arm/dts/uniphier-pro5.dtsi index a29597ae88e0..498354c45f90 100644 --- a/arch/arm/dts/uniphier-pro5.dtsi +++ b/arch/arm/dts/uniphier-pro5.dtsi @@ -598,6 +598,7 @@ compatible = "snps,dwc3"; reg = <0x65a0 0x1>; interrupts = <0 134 4>; + dr_mode = "host"; tx-fifo-resize; }; }; @@ -615,6 +616,7 @@ compatible = "snps,dwc3"; reg = <0x65c0 0x1>; interrupts = <0 137 4>; + dr_mode = "host"; tx-fifo-resize; }; }; diff --git a/arch/arm/dts/uniphier-pxs2.dtsi b/arch/arm/dts/uniphier-pxs2.dtsi index 2962cb5ae7be..32844f781f5a 100644 --- a/arch/arm/dts/uniphier-pxs2.dtsi +++ b/arch/arm/dts/uniphier-pxs2.dtsi @@ -610,6 +610,7 @@ compatible = "snps,dwc3"; reg = <0x65a0 0x1>; interrupts = <0 134 4>; + dr_mode = "host"; tx-fifo-resize; }; }; @@ -627,6 +628,7 @@ compatible = "snps,dwc3"; reg = <0x65c0 0x1>; interrupts = <0 137 4>; + dr_mode = "host"; tx-fifo-resize; }; }; -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 4/5] reset: uniphier: refactor reset data and add NAND/eMMC reset lines
- Merge sys_reset data of LD4, Pro4, sLD8 and Pro5 - Merge sys_reset data of LD11 and LD20 - Use primitive UNIPHIER_RESETX() macro because bit assignments for system reset will be changed for every SoC in the future - Add NAND and eMMC resets Signed-off-by: Masahiro Yamada --- drivers/reset/reset-uniphier.c | 63 -- 1 file changed, 17 insertions(+), 46 deletions(-) diff --git a/drivers/reset/reset-uniphier.c b/drivers/reset/reset-uniphier.c index df7fa267d13c..ebb2cae5eb33 100644 --- a/drivers/reset/reset-uniphier.c +++ b/drivers/reset/reset-uniphier.c @@ -41,46 +41,20 @@ struct uniphier_reset_data { } /* System reset data */ -#define UNIPHIER_SLD3_SYS_RESET_STDMAC(id) \ - UNIPHIER_RESETX((id), 0x2000, 10) - -#define UNIPHIER_LD11_SYS_RESET_STDMAC(id) \ - UNIPHIER_RESETX((id), 0x200c, 8) - -#define UNIPHIER_PRO4_SYS_RESET_GIO(id)\ - UNIPHIER_RESETX((id), 0x2000, 6) - -#define UNIPHIER_LD20_SYS_RESET_GIO(id)\ - UNIPHIER_RESETX((id), 0x200c, 5) - -#define UNIPHIER_PRO4_SYS_RESET_USB3(id, ch) \ - UNIPHIER_RESETX((id), 0x2000 + 0x4 * (ch), 17) - -static const struct uniphier_reset_data uniphier_ld4_sys_reset_data[] = { - UNIPHIER_SLD3_SYS_RESET_STDMAC(8), /* Ether, HSC, MIO */ - UNIPHIER_RESET_END, -}; - static const struct uniphier_reset_data uniphier_pro4_sys_reset_data[] = { - UNIPHIER_SLD3_SYS_RESET_STDMAC(8), /* HSC, MIO, RLE */ - UNIPHIER_PRO4_SYS_RESET_GIO(12),/* Ether, SATA, USB3 */ - UNIPHIER_PRO4_SYS_RESET_USB3(14, 0), - UNIPHIER_PRO4_SYS_RESET_USB3(15, 1), - UNIPHIER_RESET_END, -}; - -static const struct uniphier_reset_data uniphier_pro5_sys_reset_data[] = { - UNIPHIER_SLD3_SYS_RESET_STDMAC(8), /* HSC */ - UNIPHIER_PRO4_SYS_RESET_GIO(12),/* PCIe, USB3 */ - UNIPHIER_PRO4_SYS_RESET_USB3(14, 0), - UNIPHIER_PRO4_SYS_RESET_USB3(15, 1), + UNIPHIER_RESETX(2, 0x2000, 2), /* NAND */ + UNIPHIER_RESETX(8, 0x2000, 10), /* STDMAC */ + UNIPHIER_RESETX(12, 0x2000, 6), /* GIO */ + UNIPHIER_RESETX(14, 0x2000, 17),/* USB30 */ + UNIPHIER_RESETX(15, 0x2004, 17),/* USB31 */ UNIPHIER_RESET_END, }; static const struct uniphier_reset_data uniphier_pxs2_sys_reset_data[] = { - UNIPHIER_SLD3_SYS_RESET_STDMAC(8), /* HSC, RLE */ - UNIPHIER_PRO4_SYS_RESET_USB3(14, 0), - UNIPHIER_PRO4_SYS_RESET_USB3(15, 1), + UNIPHIER_RESETX(2, 0x2000, 2), /* NAND */ + UNIPHIER_RESETX(8, 0x2000, 10), /* STDMAC */ + UNIPHIER_RESETX(14, 0x2000, 17),/* USB30 */ + UNIPHIER_RESETX(15, 0x2004, 17),/* USB31 */ UNIPHIER_RESETX(16, 0x2014, 4), /* USB30-PHY0 */ UNIPHIER_RESETX(17, 0x2014, 0), /* USB30-PHY1 */ UNIPHIER_RESETX(18, 0x2014, 2), /* USB30-PHY2 */ @@ -91,14 +65,11 @@ static const struct uniphier_reset_data uniphier_pxs2_sys_reset_data[] = { UNIPHIER_RESET_END, }; -static const struct uniphier_reset_data uniphier_ld11_sys_reset_data[] = { - UNIPHIER_LD11_SYS_RESET_STDMAC(8), /* HSC, MIO */ - UNIPHIER_RESET_END, -}; - static const struct uniphier_reset_data uniphier_ld20_sys_reset_data[] = { - UNIPHIER_LD11_SYS_RESET_STDMAC(8), /* HSC */ - UNIPHIER_LD20_SYS_RESET_GIO(12),/* PCIe, USB3 */ + UNIPHIER_RESETX(2, 0x200c, 0), /* NAND */ + UNIPHIER_RESETX(4, 0x200c, 2), /* eMMC */ + UNIPHIER_RESETX(8, 0x200c, 8), /* STDMAC */ + UNIPHIER_RESETX(12, 0x200c, 5), /* GIO */ UNIPHIER_RESETX(16, 0x200c, 12),/* USB30-PHY0 */ UNIPHIER_RESETX(17, 0x200c, 13),/* USB30-PHY1 */ UNIPHIER_RESETX(18, 0x200c, 14),/* USB30-PHY2 */ @@ -271,7 +242,7 @@ static const struct udevice_id uniphier_reset_match[] = { /* System reset */ { .compatible = "socionext,uniphier-ld4-reset", - .data = (ulong)uniphier_ld4_sys_reset_data, + .data = (ulong)uniphier_pro4_sys_reset_data, }, { .compatible = "socionext,uniphier-pro4-reset", @@ -279,11 +250,11 @@ static const struct udevice_id uniphier_reset_match[] = { }, { .compatible = "socionext,uniphier-sld8-reset", - .data = (ulong)uniphier_ld4_sys_reset_data, + .data = (ulong)uniphier_pro4_sys_reset_data, }, { .compatible = "socionext,uniphier-pro5-reset", - .data = (ulong)uniphier_pro5_sys_reset_data, + .data = (ulong)uniphier_pro4_sys_reset_data, }, { .compatible = "socionext,uniphier-pxs2-reset", @@ -291,7 +262,7 @@ static const struct udevice_id uniphier_res
[U-Boot] [PATCH 2/5] Revert "ARM: uniphier: move lowlevel debug init code after page table switch"
This reverts commit bcc51c1512a3deb6a9fdd37362c6dde32ad3da23. Commit bcc51c1512a3 ("ARM: uniphier: move lowlevel debug init code after page table switch") was intended to support lowlevel debug for sLD3. Now the sLD3 SoC support has been removed. Revert it to allow to enable lowlevel debug earlier. Signed-off-by: Masahiro Yamada --- arch/arm/mach-uniphier/arm32/lowlevel_init.S | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/arm/mach-uniphier/arm32/lowlevel_init.S b/arch/arm/mach-uniphier/arm32/lowlevel_init.S index 89bb5a6355fd..3c7c6502793c 100644 --- a/arch/arm/mach-uniphier/arm32/lowlevel_init.S +++ b/arch/arm/mach-uniphier/arm32/lowlevel_init.S @@ -25,6 +25,10 @@ ENTRY(lowlevel_init) orr r0, r0, #(CR_C | CR_M) @ enable MMU and Dcache mcr p15, 0, r0, c1, c0, 0 +#ifdef CONFIG_DEBUG_LL + bl debug_ll_init +#endif + bl setup_init_ram @ RAM area for stack and page table /* @@ -42,10 +46,6 @@ ENTRY(lowlevel_init) bl enable_mmu -#ifdef CONFIG_DEBUG_LL - bl debug_ll_init -#endif - mov lr, r8 @ restore link mov pc, lr @ back to my caller ENDPROC(lowlevel_init) -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/5] ARM: uniphier: remove sLD3 SoC support
This SoC is too old. It is difficult to maintain any longer. Signed-off-by: Masahiro Yamada --- arch/arm/dts/Makefile | 2 - arch/arm/dts/uniphier-sld3-ref.dts | 100 - arch/arm/dts/uniphier-sld3.dtsi| 458 - arch/arm/mach-uniphier/Kconfig | 4 - arch/arm/mach-uniphier/arm32/cache-uniphier.c | 3 - arch/arm/mach-uniphier/arm32/debug_ll.S| 21 - arch/arm/mach-uniphier/arm32/lowlevel_init.S | 5 +- arch/arm/mach-uniphier/arm32/psci.c| 1 - arch/arm/mach-uniphier/bcu/Makefile| 1 - arch/arm/mach-uniphier/bcu/bcu-sld3.c | 39 -- arch/arm/mach-uniphier/board_init.c| 9 - arch/arm/mach-uniphier/boards.c| 22 - arch/arm/mach-uniphier/boot-device/Makefile| 1 - .../mach-uniphier/boot-device/boot-device-sld3.c | 84 arch/arm/mach-uniphier/boot-device/boot-device.c | 9 - arch/arm/mach-uniphier/boot-device/boot-device.h | 2 - arch/arm/mach-uniphier/clk/Makefile| 14 +- .../clk/{clk-dram-sld3.c => clk-dram-ld4.c}| 2 +- .../clk/{clk-early-sld3.c => clk-early-ld4.c} | 2 +- arch/arm/mach-uniphier/clk/dpll-sld3.c | 13 - arch/arm/mach-uniphier/clk/pll-sld3.c | 14 - arch/arm/mach-uniphier/cpu-info.c | 4 - arch/arm/mach-uniphier/debug-uart/Makefile | 1 - .../arm/mach-uniphier/debug-uart/debug-uart-sld3.c | 31 -- arch/arm/mach-uniphier/debug-uart/debug-uart.c | 5 - arch/arm/mach-uniphier/debug-uart/debug-uart.h | 1 - arch/arm/mach-uniphier/dram/Makefile | 1 - arch/arm/mach-uniphier/dram/umc-sld3.c | 6 - arch/arm/mach-uniphier/dram_init.c | 9 - arch/arm/mach-uniphier/init.h | 10 +- arch/arm/mach-uniphier/memconf.c | 14 +- arch/arm/mach-uniphier/mmc-boot-mode.c | 2 +- arch/arm/mach-uniphier/sc-regs.h | 4 - arch/arm/mach-uniphier/soc-info.h | 1 - arch/arm/mach-uniphier/spl_board_init.c| 29 +- configs/uniphier_sld3_defconfig| 46 --- doc/README.uniphier| 1 - drivers/clk/uniphier/clk-uniphier-core.c | 4 - drivers/clk/uniphier/clk-uniphier-mio.c| 2 - drivers/pinctrl/uniphier/Kconfig | 6 - drivers/pinctrl/uniphier/Makefile | 1 - drivers/pinctrl/uniphier/pinctrl-uniphier-sld3.c | 129 -- drivers/reset/reset-uniphier.c | 14 +- include/configs/uniphier.h | 8 +- 44 files changed, 30 insertions(+), 1105 deletions(-) delete mode 100644 arch/arm/dts/uniphier-sld3-ref.dts delete mode 100644 arch/arm/dts/uniphier-sld3.dtsi delete mode 100644 arch/arm/mach-uniphier/bcu/bcu-sld3.c delete mode 100644 arch/arm/mach-uniphier/boot-device/boot-device-sld3.c rename arch/arm/mach-uniphier/clk/{clk-dram-sld3.c => clk-dram-ld4.c} (93%) rename arch/arm/mach-uniphier/clk/{clk-early-sld3.c => clk-early-ld4.c} (93%) delete mode 100644 arch/arm/mach-uniphier/clk/dpll-sld3.c delete mode 100644 arch/arm/mach-uniphier/clk/pll-sld3.c delete mode 100644 arch/arm/mach-uniphier/debug-uart/debug-uart-sld3.c delete mode 100644 arch/arm/mach-uniphier/dram/umc-sld3.c delete mode 100644 configs/uniphier_sld3_defconfig delete mode 100644 drivers/pinctrl/uniphier/pinctrl-uniphier-sld3.c diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile index c2dc240edf68..8f6b186df828 100644 --- a/arch/arm/dts/Makefile +++ b/arch/arm/dts/Makefile @@ -118,8 +118,6 @@ dtb-$(CONFIG_ARCH_UNIPHIER_PXS2) += \ uniphier-pxs2-vodka.dtb dtb-$(CONFIG_ARCH_UNIPHIER_PXS3) += \ uniphier-pxs3-ref.dtb -dtb-$(CONFIG_ARCH_UNIPHIER_SLD3) += \ - uniphier-sld3-ref.dtb dtb-$(CONFIG_ARCH_UNIPHIER_SLD8) += \ uniphier-sld8-ref.dtb diff --git a/arch/arm/dts/uniphier-sld3-ref.dts b/arch/arm/dts/uniphier-sld3-ref.dts deleted file mode 100644 index baf706976aca.. --- a/arch/arm/dts/uniphier-sld3-ref.dts +++ /dev/null @@ -1,100 +0,0 @@ -/* - * Device Tree Source for UniPhier sLD3 Reference Board - * - * Copyright (C) 2015-2016 Socionext Inc. - * Author: Masahiro Yamada - * - * SPDX-License-Identifier: (GPL-2.0+ OR MIT) - */ - -/dts-v1/; -/include/ "uniphier-sld3.dtsi" -/include/ "uniphier-ref-daughter.dtsi" -/include/ "uniphier-support-card.dtsi" - -/ { - model = "UniPhier sLD3 Reference Board"; - compatible = "socionext,uniphier-sld3-ref", "socionext,uniphier-sld3"; - - chosen { - stdout-path = "serial0:115200n8"; - }; - - aliases { - serial0 = &serial0; - serial1 = &serial1; - serial2 = &serial2; - i2c0 = &i2c0; - i2c1 = &i2c1;
[U-Boot] [PATCH 3/5] Revert "ARM: uniphier: fix ROM boot mode for PH1-sLD3"
This reverts commit 82d075e79fa509ffb8ecd8dd2dc216929d6e8289. Commit 82d075e79fa5 ("ARM: uniphier: fix ROM boot mode for PH1-sLD3") was a workaround for sLD3. Now the sLD3 SoC support has been removed. Revert it to allow to simplify the init code. Signed-off-by: Masahiro Yamada --- arch/arm/mach-uniphier/arm32/lowlevel_init.S | 5 - 1 file changed, 5 deletions(-) diff --git a/arch/arm/mach-uniphier/arm32/lowlevel_init.S b/arch/arm/mach-uniphier/arm32/lowlevel_init.S index 3c7c6502793c..a399a169a9da 100644 --- a/arch/arm/mach-uniphier/arm32/lowlevel_init.S +++ b/arch/arm/mach-uniphier/arm32/lowlevel_init.S @@ -98,11 +98,6 @@ ENDPROC(enable_mmu) ENTRY(setup_init_ram) ldr r1, = SSCO_BASE - mrc p15, 0, r0, c2, c0, 0 @ TTBR0 - ldr r0, [r0, #0x400]@ entry for virtual address 0x100* - bfc r0, #0, #20 - cmp r0, #0x5000 @ is sLD3 page table? - biceq r1, r1, #0xc000 @ sLD3 ROM maps 0x5*** to 0x1*** /* Touch to zero for the boot way */ 0: ldr r0, = 0x00408006@ touch to zero with address range -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 2/3] armv8: ls1088ardb: Add support for LS1088ARDB platform
Hi Ashish, > -Original Message- > From: Ashish Kumar [mailto:ashish.ku...@nxp.com] > Sent: Friday, August 11, 2017 12:54 PM > To: u-boot@lists.denx.de > Cc: York Sun ; Ashish Kumar ; > Alison Wang ; Prabhakar Kushwaha > ; Raghav Dogra ; > Shaohui Xie > Subject: [PATCH v3 2/3] armv8: ls1088ardb: Add support for LS1088ARDB > platform > > LS1088A is an ARMv8 implementation. The LS1088ARDB is an evaluatoin > platform that supports the LS1088A family SoCs. This patch add basic > support of the platform. > > Signed-off-by: Alison Wang > Signed-off-by: Prabhakar Kushwaha > Signed-off-by: Ashish Kumar > Signed-off-by: Raghav Dogra > Signed-off-by: Shaohui Xie > --- > v2: > Fix indentaion in commit msg > Separate RDB and Si specific file > > v3: > 1.Re-based on top of > commit d529124fdcf941c34074fd1ce600f4b1b4a7dd07 > Merge: f0ca30f 6a5691e > Author: Tom Rini > Date: Tue Aug 8 17:06:19 2017 -0400 > > Merge git://git.denx.de/u-boot-x86 > > 2.Incorporate review comments on v2 > Remove EMU support > Remove RAW timings > Disable default enabled CONFIG_DISPLAY_BOARDINFO and enable > LATE_CONFIG_DISPLAY_BOARDINFO > > 3.Include PPA support > > arch/arm/Kconfig | 12 ++ > arch/arm/cpu/armv8/Kconfig| 1 + > arch/arm/cpu/armv8/fsl-layerscape/Kconfig | 1 + > arch/arm/dts/Makefile | 3 +- > arch/arm/dts/fsl-ls1088a-rdb.dts | 40 > board/freescale/ls1088a/Kconfig | 15 ++ > board/freescale/ls1088a/MAINTAINERS | 9 + Please add REAdME file in ls1088a providing details of board (default switch settings, boot method + xqsgmii riser card (its port vs DPMAC mapping) --prabhakar ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 0/2] Fix get_device_type() problems
The comit 00bbe96ebabb ("arm: omap: Unify get_device_type() function") does not play nice with early errata workarounds and needs some fixes. And because it does not bring any practical improvements anyway (other than increasing the SPL size and introducing more lines of code), it's best to revert it for now. The second patch in this series improves testing coverage and should prevent similar regressions in the future. Siarhei Siamashka (2): Revert "arm: omap: Unify get_device_type() function" arm: Exercise v7_arch_cp15_set_acr even without errata fixups arch/arm/cpu/armv7/start.S | 32 arch/arm/include/asm/arch-am33xx/cpu.h | 6 ++ arch/arm/include/asm/arch-am33xx/omap.h | 3 --- arch/arm/include/asm/arch-omap3/omap.h | 3 --- arch/arm/include/asm/arch-omap4/omap.h | 1 + arch/arm/include/asm/arch-omap5/omap.h | 1 + arch/arm/include/asm/omap_common.h | 11 +-- arch/arm/mach-omap2/Makefile| 1 - arch/arm/mach-omap2/am33xx/Makefile | 2 -- arch/arm/mach-omap2/am33xx/board.c | 3 --- arch/arm/mach-omap2/am33xx/hw_data.c| 19 --- arch/arm/mach-omap2/am33xx/prcm-regs.c | 15 --- arch/arm/mach-omap2/am33xx/sys_info.c | 10 ++ arch/arm/mach-omap2/hwinit-common.c | 9 + arch/arm/mach-omap2/omap3/Makefile | 2 -- arch/arm/mach-omap2/omap3/board.c | 7 --- arch/arm/mach-omap2/omap3/hw_data.c | 19 --- arch/arm/mach-omap2/omap3/prcm-regs.c | 15 --- arch/arm/mach-omap2/omap3/sys_info.c| 9 - arch/arm/mach-omap2/sysinfo-common.c| 21 - board/ti/am335x/board.c | 1 - board/ti/am43xx/board.c | 1 - 22 files changed, 48 insertions(+), 143 deletions(-) delete mode 100644 arch/arm/mach-omap2/am33xx/hw_data.c delete mode 100644 arch/arm/mach-omap2/am33xx/prcm-regs.c delete mode 100644 arch/arm/mach-omap2/omap3/hw_data.c delete mode 100644 arch/arm/mach-omap2/omap3/prcm-regs.c delete mode 100644 arch/arm/mach-omap2/sysinfo-common.c -- 2.7.3 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/2] Revert "arm: omap: Unify get_device_type() function"
This reverts commit 00bbe96ebabbc83777cd8d6c6fd2791c5c8cf619. There were two major problems with this patch: 1. It made OMAP3530 devices non-bootable, as reported and investigated by Derald D. Woods in https://lists.denx.de/pipermail/u-boot/2017-August/302192.html 2. The SPL code size increased really a lot. SPL size for omap3_beagle_defconfig build with GCC 6: == before reverting == textdata bss dec hex filename 497211505 203200 254426 3e1da spl/u-boot-spl == after reverting == textdata bss dec hex filename 492331501 203200 253934 3dfee spl/u-boot-spl Signed-off-by: Siarhei Siamashka Reported-by: Derald D. Woods --- arch/arm/include/asm/arch-am33xx/cpu.h | 6 ++ arch/arm/include/asm/arch-am33xx/omap.h | 3 --- arch/arm/include/asm/arch-omap3/omap.h | 3 --- arch/arm/include/asm/arch-omap4/omap.h | 1 + arch/arm/include/asm/arch-omap5/omap.h | 1 + arch/arm/include/asm/omap_common.h | 11 +-- arch/arm/mach-omap2/Makefile| 1 - arch/arm/mach-omap2/am33xx/Makefile | 2 -- arch/arm/mach-omap2/am33xx/board.c | 3 --- arch/arm/mach-omap2/am33xx/hw_data.c| 19 --- arch/arm/mach-omap2/am33xx/prcm-regs.c | 15 --- arch/arm/mach-omap2/am33xx/sys_info.c | 10 ++ arch/arm/mach-omap2/hwinit-common.c | 9 + arch/arm/mach-omap2/omap3/Makefile | 2 -- arch/arm/mach-omap2/omap3/board.c | 7 --- arch/arm/mach-omap2/omap3/hw_data.c | 19 --- arch/arm/mach-omap2/omap3/prcm-regs.c | 15 --- arch/arm/mach-omap2/omap3/sys_info.c| 9 - arch/arm/mach-omap2/sysinfo-common.c| 21 - board/ti/am335x/board.c | 1 - board/ti/am43xx/board.c | 1 - 21 files changed, 36 insertions(+), 123 deletions(-) delete mode 100644 arch/arm/mach-omap2/am33xx/hw_data.c delete mode 100644 arch/arm/mach-omap2/am33xx/prcm-regs.c delete mode 100644 arch/arm/mach-omap2/omap3/hw_data.c delete mode 100644 arch/arm/mach-omap2/omap3/prcm-regs.c delete mode 100644 arch/arm/mach-omap2/sysinfo-common.c diff --git a/arch/arm/include/asm/arch-am33xx/cpu.h b/arch/arm/include/asm/arch-am33xx/cpu.h index e8d7d54..8cae291 100644 --- a/arch/arm/include/asm/arch-am33xx/cpu.h +++ b/arch/arm/include/asm/arch-am33xx/cpu.h @@ -36,6 +36,12 @@ #define TCFG_RESET BIT(0) /* software reset */ #define TCFG_EMUFREE BIT(1) /* behaviour of tmr on debug */ #define TCFG_IDLEMOD_SHIFT (2) /* power management */ +/* device type */ +#define DEVICE_MASK(BIT(8) | BIT(9) | BIT(10)) +#define TST_DEVICE 0x0 +#define EMU_DEVICE 0x1 +#define HS_DEVICE 0x2 +#define GP_DEVICE 0x3 /* cpu-id for AM43XX AM33XX and TI81XX family */ #define AM437X 0xB98C diff --git a/arch/arm/include/asm/arch-am33xx/omap.h b/arch/arm/include/asm/arch-am33xx/omap.h index d2c5df8..0dafb9e 100644 --- a/arch/arm/include/asm/arch-am33xx/omap.h +++ b/arch/arm/include/asm/arch-am33xx/omap.h @@ -41,9 +41,6 @@ struct omap_boot_parameters { unsigned char boot_device; unsigned char reset_reason; }; - -#define DEVICE_TYPE_SHIFT 0x8 -#define DEVICE_TYPE_MASK (0x7 << DEVICE_TYPE_SHIFT) #endif #endif diff --git a/arch/arm/include/asm/arch-omap3/omap.h b/arch/arm/include/asm/arch-omap3/omap.h index 8933f54..db763e4 100644 --- a/arch/arm/include/asm/arch-omap3/omap.h +++ b/arch/arm/include/asm/arch-omap3/omap.h @@ -91,9 +91,6 @@ struct s32ktimer { unsigned int s32k_cr; /* 0x10 */ }; -#define DEVICE_TYPE_SHIFT 0x8 -#define DEVICE_TYPE_MASK (0x7 << DEVICE_TYPE_SHIFT) - #endif /* __ASSEMBLY__ */ #ifndef __ASSEMBLY__ diff --git a/arch/arm/include/asm/arch-omap4/omap.h b/arch/arm/include/asm/arch-omap4/omap.h index 1a3ff7d..b86a776 100644 --- a/arch/arm/include/asm/arch-omap4/omap.h +++ b/arch/arm/include/asm/arch-omap4/omap.h @@ -100,6 +100,7 @@ struct s32ktimer { #define DEVICE_TYPE_SHIFT (0x8) #define DEVICE_TYPE_MASK (0x7 << DEVICE_TYPE_SHIFT) +#define DEVICE_GP 0x3 #endif /* __ASSEMBLY__ */ diff --git a/arch/arm/include/asm/arch-omap5/omap.h b/arch/arm/include/asm/arch-omap5/omap.h index 2f005dd..8f31da1 100644 --- a/arch/arm/include/asm/arch-omap5/omap.h +++ b/arch/arm/include/asm/arch-omap5/omap.h @@ -127,6 +127,7 @@ struct s32ktimer { #define DEVICE_TYPE_SHIFT 0x6 #define DEVICE_TYPE_MASK (0x7 << DEVICE_TYPE_SHIFT) +#define DEVICE_GP 0x3 /* Output impedance control */ #define ds_120_ohm 0x0 diff --git a/arch/arm/include/asm/omap_common.h b/arch/arm/include/asm/omap_common.h index ef5c481..6aaa1ba 100644 --- a/arch/arm/include/asm/omap_common.h +++ b/arch/arm/include/asm/omap_common.h @@ -484,7 +484,6 @@ struct omap_sys
[U-Boot] [PATCH 2/2] arm: Exercise v7_arch_cp15_set_acr even without errata fixups
By applying this patch, we are ensuring that the code paths responsible for applying errata workarounds are also exercised on CPU revisions, which actually don't need these workarounds. Only CONFIG_ARM_ERRATA_621766, CONFIG_ARM_ERRATA_454179, CONFIG_ARM_ERRATA_725233 and CONFIG_ARM_ERRATA_430973 are covered by this patch (Cortex-A8). This improves code coverage when testing U-Boot builds on newer hardware. In particular, the problematic commit 00bbe96ebabb ("arm: omap: Unify get_device_type() function") would break both BeageBoard and BeagleBoard XM rather than just older BeagleBoard. As an additional bonus, we need fewer instructins and the SPL size is reduced. Signed-off-by: Siarhei Siamashka --- arch/arm/cpu/armv7/start.S | 32 1 file changed, 12 insertions(+), 20 deletions(-) diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S index f06fd28..1442675 100644 --- a/arch/arm/cpu/armv7/start.S +++ b/arch/arm/cpu/armv7/start.S @@ -232,55 +232,47 @@ skip_errata_801819: #endif #ifdef CONFIG_ARM_ERRATA_454179 + mrc p15, 0, r0, c1, c0, 1 @ Read ACR + cmp r2, #0x21 @ Only on < r2p1 - bge skip_errata_454179 + orrlt r0, r0, #(0x3 << 6) @ Set DBSM(BIT7) and IBE(BIT6) bits - mrc p15, 0, r0, c1, c0, 1 @ Read ACR - orr r0, r0, #(0x3 << 6) @ Set DBSM(BIT7) and IBE(BIT6) bits push{r1-r5} @ Save the cpu info registers bl v7_arch_cp15_set_acr pop {r1-r5} @ Restore the cpu info - fall through - -skip_errata_454179: #endif #ifdef CONFIG_ARM_ERRATA_430973 + mrc p15, 0, r0, c1, c0, 1 @ Read ACR + cmp r2, #0x21 @ Only on < r2p1 - bge skip_errata_430973 + orrlt r0, r0, #(0x1 << 6) @ Set IBE bit - mrc p15, 0, r0, c1, c0, 1 @ Read ACR - orr r0, r0, #(0x1 << 6) @ Set IBE bit push{r1-r5} @ Save the cpu info registers bl v7_arch_cp15_set_acr pop {r1-r5} @ Restore the cpu info - fall through - -skip_errata_430973: #endif #ifdef CONFIG_ARM_ERRATA_621766 + mrc p15, 0, r0, c1, c0, 1 @ Read ACR + cmp r2, #0x21 @ Only on < r2p1 - bge skip_errata_621766 + orrlt r0, r0, #(0x1 << 5) @ Set L1NEON bit - mrc p15, 0, r0, c1, c0, 1 @ Read ACR - orr r0, r0, #(0x1 << 5) @ Set L1NEON bit push{r1-r5} @ Save the cpu info registers bl v7_arch_cp15_set_acr pop {r1-r5} @ Restore the cpu info - fall through - -skip_errata_621766: #endif #ifdef CONFIG_ARM_ERRATA_725233 + mrc p15, 1, r0, c9, c0, 2 @ Read L2ACR + cmp r2, #0x21 @ Only on < r2p1 (Cortex A8) - bge skip_errata_725233 + orrlt r0, r0, #(0x1 << 27)@ L2 PLD data forwarding disable - mrc p15, 1, r0, c9, c0, 2 @ Read L2ACR - orr r0, r0, #(0x1 << 27)@ L2 PLD data forwarding disable push{r1-r5} @ Save the cpu info registers bl v7_arch_cp15_set_l2aux_ctrl pop {r1-r5} @ Restore the cpu info - fall through - -skip_errata_725233: #endif #ifdef CONFIG_ARM_ERRATA_852421 -- 2.7.3 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [Patch V2] Convert CONFIG_NAND_OMAP_GPMC et al to Kconfig
This converts the following to Kconfig: CONFIG_NAND_OMAP_GPMC CONFIG_NAND_OMAP_GPMC_PREFETCH CONFIG_NAND_OMAP_ELM CONFIG_SYS_NAND_BUSWIDTH_16BIT CONFIG_SPL_NAND_AM33XX_BCH CONFIG_SPL_NAND_SIMPLE (ARCH_OMAP2PLUS only) Signed-off-by: Adam Ford Changes since V1: Rebased on latest Master Fixed a few missing entries where some features lacked dependancies --- cmd/Kconfig | 1 + configs/am3517_crane_defconfig| 6 -- configs/cm_t3517_defconfig| 1 + configs/cm_t35_defconfig | 1 + configs/omap3_evm_defconfig | 1 + configs/omap3_ha_defconfig| 6 -- configs/tao3530_defconfig | 6 -- configs/tricorder_defconfig | 1 + include/configs/ti_omap3_common.h | 1 - 9 files changed, 17 insertions(+), 7 deletions(-) diff --git a/cmd/Kconfig b/cmd/Kconfig index 183f932..1e218ed 100644 --- a/cmd/Kconfig +++ b/cmd/Kconfig @@ -751,6 +751,7 @@ config CMD_MMC config CMD_NAND bool "nand" default y if NAND_SUNXI + select NAND help NAND support. diff --git a/configs/am3517_crane_defconfig b/configs/am3517_crane_defconfig index 396aadd..e7d92b6 100644 --- a/configs/am3517_crane_defconfig +++ b/configs/am3517_crane_defconfig @@ -13,11 +13,11 @@ CONFIG_SYS_PROMPT="AM3517_CRANE # " # CONFIG_CMD_IMI is not set # CONFIG_CMD_IMLS is not set # CONFIG_CMD_FLASH is not set +# CONFIG_CMD_FPGA is not set +CONFIG_CMD_I2C=y CONFIG_CMD_MMC=y CONFIG_CMD_NAND=y -CONFIG_CMD_I2C=y CONFIG_CMD_USB=y -# CONFIG_CMD_FPGA is not set # CONFIG_CMD_SETEXPR is not set # CONFIG_CMD_NET is not set CONFIG_CMD_DHCP=y @@ -26,6 +26,8 @@ CONFIG_CMD_EXT2=y CONFIG_CMD_FAT=y CONFIG_CMD_JFFS2=y CONFIG_MMC_OMAP_HS=y +CONFIG_NAND=y +CONFIG_SYS_NAND_BUSWIDTH_16BIT=y CONFIG_SYS_NS16550=y CONFIG_USB=y CONFIG_USB_STORAGE=y diff --git a/configs/cm_t3517_defconfig b/configs/cm_t3517_defconfig index d5550fe..66cdc19 100644 --- a/configs/cm_t3517_defconfig +++ b/configs/cm_t3517_defconfig @@ -37,6 +37,7 @@ CONFIG_LED_STATUS_STATE=2 CONFIG_LED_STATUS_BOOT_ENABLE=y CONFIG_LED_STATUS_BOOT=0 CONFIG_MMC_OMAP_HS=y +CONFIG_NAND=y CONFIG_SYS_NS16550=y CONFIG_USB=y CONFIG_USB_MUSB_HOST=y diff --git a/configs/cm_t35_defconfig b/configs/cm_t35_defconfig index 16f1eab..21bf5c3 100644 --- a/configs/cm_t35_defconfig +++ b/configs/cm_t35_defconfig @@ -39,6 +39,7 @@ CONFIG_LED_STATUS_STATE=2 CONFIG_LED_STATUS_BOOT_ENABLE=y CONFIG_LED_STATUS_BOOT=0 CONFIG_MMC_OMAP_HS=y +CONFIG_NAND=y CONFIG_SYS_NS16550=y CONFIG_USB=y CONFIG_USB_EHCI_HCD=y diff --git a/configs/omap3_evm_defconfig b/configs/omap3_evm_defconfig index 9bbc980..40a91dd 100644 --- a/configs/omap3_evm_defconfig +++ b/configs/omap3_evm_defconfig @@ -45,6 +45,7 @@ CONFIG_SPL_DM=y CONFIG_DM_GPIO=y CONFIG_MMC_OMAP_HS=y CONFIG_MTD=y +CONFIG_NAND=y CONFIG_DM_SERIAL=y CONFIG_SYS_NS16550=y CONFIG_USB=y diff --git a/configs/omap3_ha_defconfig b/configs/omap3_ha_defconfig index f88c2e1..2884d5a 100644 --- a/configs/omap3_ha_defconfig +++ b/configs/omap3_ha_defconfig @@ -12,11 +12,11 @@ CONFIG_HUSH_PARSER=y # CONFIG_CMD_IMI is not set # CONFIG_CMD_IMLS is not set # CONFIG_CMD_FLASH is not set +# CONFIG_CMD_FPGA is not set +CONFIG_CMD_I2C=y CONFIG_CMD_MMC=y CONFIG_CMD_NAND=y -CONFIG_CMD_I2C=y CONFIG_CMD_USB=y -# CONFIG_CMD_FPGA is not set # CONFIG_CMD_SETEXPR is not set CONFIG_CMD_DHCP=y CONFIG_CMD_PING=y @@ -25,6 +25,8 @@ CONFIG_CMD_EXT2=y CONFIG_CMD_FAT=y CONFIG_CMD_MTDPARTS=y CONFIG_MMC_OMAP_HS=y +CONFIG_NAND=y +CONFIG_SYS_NAND_BUSWIDTH_16BIT=y CONFIG_SYS_NS16550=y CONFIG_USB=y CONFIG_USB_EHCI_HCD=y diff --git a/configs/tao3530_defconfig b/configs/tao3530_defconfig index e6c7e60..f8c9596 100644 --- a/configs/tao3530_defconfig +++ b/configs/tao3530_defconfig @@ -12,11 +12,11 @@ CONFIG_SYS_PROMPT="TAO-3530 # " # CONFIG_CMD_IMI is not set # CONFIG_CMD_IMLS is not set # CONFIG_CMD_FLASH is not set +# CONFIG_CMD_FPGA is not set +CONFIG_CMD_I2C=y CONFIG_CMD_MMC=y CONFIG_CMD_NAND=y -CONFIG_CMD_I2C=y CONFIG_CMD_USB=y -# CONFIG_CMD_FPGA is not set # CONFIG_CMD_SETEXPR is not set CONFIG_CMD_DHCP=y CONFIG_CMD_PING=y @@ -25,6 +25,8 @@ CONFIG_CMD_EXT2=y CONFIG_CMD_FAT=y CONFIG_CMD_MTDPARTS=y CONFIG_MMC_OMAP_HS=y +CONFIG_NAND=y +CONFIG_SYS_NAND_BUSWIDTH_16BIT=y CONFIG_SYS_NS16550=y CONFIG_USB=y CONFIG_USB_EHCI_HCD=y diff --git a/configs/tricorder_defconfig b/configs/tricorder_defconfig index de42b4d..ad07dbc 100644 --- a/configs/tricorder_defconfig +++ b/configs/tricorder_defconfig @@ -35,5 +35,6 @@ CONFIG_LED_STATUS_BIT2=4 CONFIG_LED_STATUS_STATE2=2 CONFIG_LED_STATUS_CMD=y CONFIG_MMC_OMAP_HS=y +CONFIG_NAND=y CONFIG_SYS_NS16550=y CONFIG_OF_LIBFDT=y diff --git a/include/configs/ti_omap3_common.h b/include/configs/ti_omap3_common.h index 393d867..2373727 100644 --- a/include/configs/ti_omap3_common.h +++ b/include/configs/ti_omap3_common.h @@ -65,7 +65,6 @@ (64 << 20)) #ifdef CONFIG_NAND -#define CONFI
[U-Boot] [Patch V3] Convert CONFIG_NAND_OMAP_GPMC et al to Kconfig
This converts the following to Kconfig: CONFIG_NAND_OMAP_GPMC CONFIG_NAND_OMAP_GPMC_PREFETCH CONFIG_NAND_OMAP_ELM CONFIG_SYS_NAND_BUSWIDTH_16BIT CONFIG_SPL_NAND_AM33XX_BCH CONFIG_SPL_NAND_SIMPLE (ARCH_OMAP2PLUS only) Signed-off-by: Adam Ford V3: Remove selection from CMD_NAND Changes since V1: Rebased on latest Master Fixed a few missing entries where some features lacked dependancies --- configs/am3517_crane_defconfig| 6 -- configs/cm_t3517_defconfig| 1 + configs/cm_t35_defconfig | 1 + configs/omap3_evm_defconfig | 1 + configs/omap3_ha_defconfig| 6 -- configs/tao3530_defconfig | 6 -- configs/tricorder_defconfig | 1 + include/configs/ti_omap3_common.h | 1 - 8 files changed, 16 insertions(+), 7 deletions(-) diff --git a/configs/am3517_crane_defconfig b/configs/am3517_crane_defconfig index 396aadd..e7d92b6 100644 --- a/configs/am3517_crane_defconfig +++ b/configs/am3517_crane_defconfig @@ -13,11 +13,11 @@ CONFIG_SYS_PROMPT="AM3517_CRANE # " # CONFIG_CMD_IMI is not set # CONFIG_CMD_IMLS is not set # CONFIG_CMD_FLASH is not set +# CONFIG_CMD_FPGA is not set +CONFIG_CMD_I2C=y CONFIG_CMD_MMC=y CONFIG_CMD_NAND=y -CONFIG_CMD_I2C=y CONFIG_CMD_USB=y -# CONFIG_CMD_FPGA is not set # CONFIG_CMD_SETEXPR is not set # CONFIG_CMD_NET is not set CONFIG_CMD_DHCP=y @@ -26,6 +26,8 @@ CONFIG_CMD_EXT2=y CONFIG_CMD_FAT=y CONFIG_CMD_JFFS2=y CONFIG_MMC_OMAP_HS=y +CONFIG_NAND=y +CONFIG_SYS_NAND_BUSWIDTH_16BIT=y CONFIG_SYS_NS16550=y CONFIG_USB=y CONFIG_USB_STORAGE=y diff --git a/configs/cm_t3517_defconfig b/configs/cm_t3517_defconfig index d5550fe..66cdc19 100644 --- a/configs/cm_t3517_defconfig +++ b/configs/cm_t3517_defconfig @@ -37,6 +37,7 @@ CONFIG_LED_STATUS_STATE=2 CONFIG_LED_STATUS_BOOT_ENABLE=y CONFIG_LED_STATUS_BOOT=0 CONFIG_MMC_OMAP_HS=y +CONFIG_NAND=y CONFIG_SYS_NS16550=y CONFIG_USB=y CONFIG_USB_MUSB_HOST=y diff --git a/configs/cm_t35_defconfig b/configs/cm_t35_defconfig index 16f1eab..21bf5c3 100644 --- a/configs/cm_t35_defconfig +++ b/configs/cm_t35_defconfig @@ -39,6 +39,7 @@ CONFIG_LED_STATUS_STATE=2 CONFIG_LED_STATUS_BOOT_ENABLE=y CONFIG_LED_STATUS_BOOT=0 CONFIG_MMC_OMAP_HS=y +CONFIG_NAND=y CONFIG_SYS_NS16550=y CONFIG_USB=y CONFIG_USB_EHCI_HCD=y diff --git a/configs/omap3_evm_defconfig b/configs/omap3_evm_defconfig index 9bbc980..40a91dd 100644 --- a/configs/omap3_evm_defconfig +++ b/configs/omap3_evm_defconfig @@ -45,6 +45,7 @@ CONFIG_SPL_DM=y CONFIG_DM_GPIO=y CONFIG_MMC_OMAP_HS=y CONFIG_MTD=y +CONFIG_NAND=y CONFIG_DM_SERIAL=y CONFIG_SYS_NS16550=y CONFIG_USB=y diff --git a/configs/omap3_ha_defconfig b/configs/omap3_ha_defconfig index f88c2e1..2884d5a 100644 --- a/configs/omap3_ha_defconfig +++ b/configs/omap3_ha_defconfig @@ -12,11 +12,11 @@ CONFIG_HUSH_PARSER=y # CONFIG_CMD_IMI is not set # CONFIG_CMD_IMLS is not set # CONFIG_CMD_FLASH is not set +# CONFIG_CMD_FPGA is not set +CONFIG_CMD_I2C=y CONFIG_CMD_MMC=y CONFIG_CMD_NAND=y -CONFIG_CMD_I2C=y CONFIG_CMD_USB=y -# CONFIG_CMD_FPGA is not set # CONFIG_CMD_SETEXPR is not set CONFIG_CMD_DHCP=y CONFIG_CMD_PING=y @@ -25,6 +25,8 @@ CONFIG_CMD_EXT2=y CONFIG_CMD_FAT=y CONFIG_CMD_MTDPARTS=y CONFIG_MMC_OMAP_HS=y +CONFIG_NAND=y +CONFIG_SYS_NAND_BUSWIDTH_16BIT=y CONFIG_SYS_NS16550=y CONFIG_USB=y CONFIG_USB_EHCI_HCD=y diff --git a/configs/tao3530_defconfig b/configs/tao3530_defconfig index e6c7e60..f8c9596 100644 --- a/configs/tao3530_defconfig +++ b/configs/tao3530_defconfig @@ -12,11 +12,11 @@ CONFIG_SYS_PROMPT="TAO-3530 # " # CONFIG_CMD_IMI is not set # CONFIG_CMD_IMLS is not set # CONFIG_CMD_FLASH is not set +# CONFIG_CMD_FPGA is not set +CONFIG_CMD_I2C=y CONFIG_CMD_MMC=y CONFIG_CMD_NAND=y -CONFIG_CMD_I2C=y CONFIG_CMD_USB=y -# CONFIG_CMD_FPGA is not set # CONFIG_CMD_SETEXPR is not set CONFIG_CMD_DHCP=y CONFIG_CMD_PING=y @@ -25,6 +25,8 @@ CONFIG_CMD_EXT2=y CONFIG_CMD_FAT=y CONFIG_CMD_MTDPARTS=y CONFIG_MMC_OMAP_HS=y +CONFIG_NAND=y +CONFIG_SYS_NAND_BUSWIDTH_16BIT=y CONFIG_SYS_NS16550=y CONFIG_USB=y CONFIG_USB_EHCI_HCD=y diff --git a/configs/tricorder_defconfig b/configs/tricorder_defconfig index de42b4d..ad07dbc 100644 --- a/configs/tricorder_defconfig +++ b/configs/tricorder_defconfig @@ -35,5 +35,6 @@ CONFIG_LED_STATUS_BIT2=4 CONFIG_LED_STATUS_STATE2=2 CONFIG_LED_STATUS_CMD=y CONFIG_MMC_OMAP_HS=y +CONFIG_NAND=y CONFIG_SYS_NS16550=y CONFIG_OF_LIBFDT=y diff --git a/include/configs/ti_omap3_common.h b/include/configs/ti_omap3_common.h index 393d867..2373727 100644 --- a/include/configs/ti_omap3_common.h +++ b/include/configs/ti_omap3_common.h @@ -65,7 +65,6 @@ (64 << 20)) #ifdef CONFIG_NAND -#define CONFIG_SPL_NAND_SIMPLE #define CONFIG_SYS_NAND_BASE 0x3000 #endif -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot