Re: [U-Boot] [PATCH 3/3][v3] [RESEND] arm: ls1046ardb: Add SD secure boot target
> -Original Message- > From: york sun > Sent: Monday, April 03, 2017 9:01 PM > To: Ruchika Gupta ; u-boot@lists.denx.de > Cc: Vini Pillai ; Sumit Garg > Subject: Re: [PATCH 3/3][v3] [RESEND] arm: ls1046ardb: Add SD secure boot > target > > On 04/03/2017 12:00 AM, Ruchika Gupta wrote: > > > > > >> -Original Message- > >> From: york sun > >> Sent: Saturday, April 01, 2017 1:44 AM > >> To: Ruchika Gupta ; u-boot@lists.denx.de > >> Cc: Vini Pillai ; Sumit Garg > >> > >> Subject: Re: [PATCH 3/3][v3] [RESEND] arm: ls1046ardb: Add SD secure > >> boot target > >> > >> On 03/29/2017 07:21 AM, Ruchika Gupta wrote: > >>> From: Vinitha Pillai-B57223 > >>> > >>> - Add SD secure boot target for ls1046ardb. > >>> - Implement board specific spl_board_init() to setup CAAM stream ID > and > >>> corresponding stream ID in SMMU. > >>> - Change the u-boot size defined by a macro for copying the main > >>> U-Boot > >> by SPL > >>> to also include the u-boot Secure Boot header size as header is > >>> appended > >> to > >>> u-boot image. So header will also be copied from SD to DDR. > >>> - CONFIG_MAX_SPL_SIZE is limited to 90K.SPL is copied to OCRAM > >>> (128K) > >> where 32K > >>> are reserved for use by boot ROM and 6K for the header > >>> - Reduce the size of CAAM driver for SPL. Since the size of spl image > >>> was about 94K, Blobification functions and descriptors, that are > >>> not > >> required > >>> at the time of SPL are disabled. Further error code conversion to > >>> strings > >>> is disabled for SPL build. This reduces the spl image size to 92K. > >>> > >>> Signed-off-by: Vinitha Pillai > >>> Signed-off-by: Sumit Garg > >>> Signed-off-by: Ruchika Gupta > >>> --- > >>> Changes from v1: > >>> - Rebased patches to latest dependent patch set > >>> - With the dependent path set , spl imag size increased to 94K. So > >>> - additionally reduce the spl image size by removing the functions > >>> from > >>> - CAAM driver that are not required in SPL flow > >>> > >> > >> > >> > >>> +#if defined(CONFIG_SPL_BUILD) > >>> +void spl_board_init(void) > >>> +{ > >>> +#ifdef CONFIG_SECURE_BOOT > >>> + /* > >>> + * In case of Secure Boot, the IBR configures the SMMU > >>> + * to allow only Secure transactions. > >>> + * SMMU must be reset in bypass mode. > >>> + * Set the ClientPD bit and Clear the USFCFG Bit > >>> + */ > >>> + u32 val; > >>> + val = (in_le32(SMMU_SCR0) | SCR0_CLIENTPD_MASK) & > >> ~(SCR0_USFCFG_MASK); > >>> + out_le32(SMMU_SCR0, val); > >>> + val = (in_le32(SMMU_NSCR0) | SCR0_CLIENTPD_MASK) & > >> ~(SCR0_USFCFG_MASK); > >>> + out_le32(SMMU_NSCR0, val); > >>> +#endif > >>> +} > >> > >> Is this the same as LS1043A? Can we move this function to > >> arch/arm/cpu/armv8/fsl-layerscape/spl.c? > > This is true for LS1043, LS1046, however wouldn't hold good for Chassis > gen3 SoC's like LS2088 , LS1088 etc. Is this file arch/arm/cpu/armv8/fsl- > layerscape/spl.c common for the Chassis Gen 3 SoC's also ? > > > > Yes, it is common for lsch3. > Since it is common for lsh3, please suggest if we should move this configuration under if defined(CONGIF_LS1043) || defined(CONFIG_LS1046) in arch/arm/cpu/armv8/fsl-layerscape/spl.c or leave it in this file. Ruchika ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] arm64: zynqmp: fail SPL build if no psu_init found
On 3.4.2017 13:38, Jean-Francois Dagenais wrote: > >> On Apr 3, 2017, at 02:55, Michal Simek wrote: >> >> This is not only one way how to configure system. You can use >> psu_init*.tcl and configure chip through jtag and then you don't need >> this .c/.h files. >> You should be able to see warning already about it if you miss that files. > > Mmh. I had thought of that, but it seemed like this scenario might have been a > minority issue. I guess this is a very yocto-centric problem. Warnings emitted > inside builds that bitbake spawns are only visible in a log file for each > steps > (configure, compile, etc.) inside each recipe's work dir and so they are > completely invisible to the operator that invokes bitbake. > > Perhaps I should come up with a strategy to emerge this particular warning in > the u-boot-xlnx_%.bb recipe? > > Thoughts? No idea but u-boot does it IMHO right. M ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/9] sunxi: Remove SYS_EXTRA_OPTIONS
Hi, On Sun, Apr 02, 2017 at 12:59:02PM +0200, Mylène Josserand wrote: > This a V3 for my patchset that removes the SYS_EXTRA_OPTIONS from all > sunxi defconfigs. > The values in this variable are converted to Kconfig or simply removed. > > Based on u-boot sunxi repository: git://git.denx.de/u-boot-sunxi.git > "master" branch, from last commit: 6f72a951cdd07e3f9d214b189762b978cd2acf45 Thanks for sending this again. There was a build breakage for all the non-sunxi boards in your last patch. I've fixed it by adding a depends on ARCH_SUNXI to avoid multiple definitions of CONS_INDEX on the other architectures, and applied it. Thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Remove global variable env_t *env_ptr ?
On Mon, 2017-04-03 at 22:17 +0200, Wolfgang Denk wrote: > Dear Joakim, Dear Wolfgang, > > In message <1491221969.4177.81.ca...@infinera.com> you wrote: > > I am looking at adding support for runtime sizing of CONFIG_ENV_ADDR as > > we need to replace out flash but we don't want to create a new u-boot > > binairy > > just for this simple change. > > I doubt this will work for configurations that use embedded > environment. I see, I don't think so but will look closer. > > > While converting env_flash.c I noted the global variable > > env_t *env_ptr = (env_t *)CONFIG_ENV_ADDR; > > which cannot be runtime decided. > > Looking at users of this variable I only find one in pmc405de.c(not sure > > what that board is doing) > > and for what I can tell this variable is not correct for redundant env. > > either. > > Did you look in the code only, or in all files? code only, for the use of the env_ptr variable only as this is the variable I looking at. > > > Anyhow, I am faced wit two choices, either remove the env_ptr or > > convert it to a function call. > > Probably neither will work for all use cases. You remember the good > old times when we had parallel NOR flash with a few smaller sectors > somewhere near the beginning or the end of the device? It was Sure do, this is the reason I am having this problem. The new flashes do not have such smaller sectors, they are all uniform :( > pretty usual to use these small sectors for the environment, and it > was the task of thelinker script to "wrap" the rest of the code > around these reserved sectors. For this, the environment location > must be known not only in the code, but also in the linker script. After a brief look I think we are good. Let me explain, I am only making it possible to #define CONFIG_ENV_ADDR, CONFIG_ENV_SECT_SIZE etc. as non constant data by moving the assignment of flash_addr etc. to runtime, removing the static variable(less relocs to perform too :), I not forcing anyone to do so and only for env_flash.c The only variable that I can't do away with it the: env_t *env_ptr = (env_t *)CONFIG_ENV_ADDR; as it is global. Nothing really uses this global variable(except pmc405de.c which is EPROM), not even the linker scripts below. They use #defines directly(CONFIG_ENV_OFFSET, CONFIG_SYS_FLASH_BASE etc. except for env_embedded.c which uses other variables) As nothing really uses env_ptr and a variable isn't really a good interface(compare with the errno variable) I propose that the env_ptr variable in code is removed but lets start with removing it for env_flash.c first. > > Without thorough checking , at least these files look suspicious to > me: > > arch/powerpc/cpu/mpc5xx/u-boot.lds: . = env_start; > arch/powerpc/cpu/mpc5xx/u-boot.lds: .ppcenv : > arch/powerpc/cpu/mpc5xx/u-boot.lds:common/env_embedded.o (.ppcenv) > arch/powerpc/cpu/mpc5xxx/u-boot-customlayout.lds:. = DEFINED(env_offset) > ? env_offset : .; > arch/powerpc/cpu/mpc5xxx/u-boot-customlayout.lds:common/env_embedded.o > (.ppcenv*) > board/tqc/tqm8xx/u-boot.lds:. = DEFINED(env_offset) ? env_offset : .; > board/tqc/tqm8xx/u-boot.lds:common/env_embedded.o (.ppcenv*) > board/freescale/mx31ads/u-boot.lds: . = DEFINED(env_offset) ? > env_offset : .; > board/freescale/mx31ads/u-boot.lds: common/env_embedded.o(.text*) > > Please have a look at these, and verify that the image layout does > not change for these with any such changes. > > 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/3] imx: bootaux elf firmware support
Hi Stefan, > Hi Lukasz, > > On 2017-04-03 04:20, Lukasz Majewski wrote: > > Hi Stefan, > > > > Thanks for your patch. Please allow me to share some ideas for > > improvements. > > > >> From: Stefan Agner > >> > >> This patchset enables to boot elf binaries on secondary Cortex-M > >> class cores available on i.MX 6SoloX/7Solo/7Dual. This makes > >> handling and loading firmwares much more convinient since all > >> information where the firmware has to be loaded to is contained in > >> the elf headers. A typical usage looks like this: > >> > >> Colibri iMX7 # tftp ${loadaddr} firmware.elf && bootaux > >> ${loadaddr} Using FEC0 device > >> TFTP from server 192.168.10.1; our IP address is 192.168.10.2 > >> Filename 'firmware.elf'. > >> Load address: 0x8080 > >> Loading: ## 88.3 > >> KiB 5.4 MiB/s > >> done > >> Bytes transferred = 90424 (16138 hex) > >> ## Starting auxiliary core at 0x1FFF8311 ... > >> Colibri iMX7 # > > > > I can find some other platforms (not only IMX), which would benefit > > from this code - the generic 'bootaux' command. > > > > One good example would to allow multiple binaries for different SoC > > Cores (e.g. 2x Cortex-A8) to be loaded and started by u-boot. > > > > Hence, I'm wondering if you could make those patches usable for > > other platforms as well? > > I don't think that this is a good idea. bootaux is meant for auxiliary > cores, which often use a different architecture and are not cache > coherent (hence the cache flushes). I do remember, that I saw similar "tiny" patch to add "just one" ad-hoc command to do the same (conceptually) for TI SoC floating on the u-boot mailing list. Please correct me if I'm wrong, but bootaux is IMX specific and does work, which very likely, will be also required by other SoC vendors (TI's Sitara is also equipped with Cortex-M4 and PRUSS). Unification of such effort can save us all a lot of trouble in a very near future. > > On SMP systems the main operating system normally starts the secondary > core. I think that there are some conceptual similarities between loading code to SMP core and Cortex M3. Of course some "tweaks" would be needed. > Otherwise, if you want to run them separately using U-Boot, > maybe a new command such as bootsmp would be more suited. Hmm - I do think that it would be too much: - bootm for generic single core - bootaux for IMX - bootsmp for SMP (on IMX/TI/RK?) - boot?? for ?? I would like to avoid adding new commands for doing conceptually the same work. Even better, we could extend bootm to support the "multi binary" case too, but IMHO it would be also correct to have "bootaux" to handle generic binaries loading. > > > > >> > >> Note that the bootaux command retrieved the entry point (PC) from > >> the elf binary. > > > > Could you make this code flexible enough to handle not only elf > > binaries, but also other data (e.g. FPGA bitstreams)? > > The code of bootaux is rather small, I don't see much value into stuff > boot code for other peripherals into it. But I'm not asking to write support for other vendor's SoC/use cases. I'm just wondering if you could write generic command (framework) to support this use case and as an example add support for your IMX's Cortex-M3/4. We would kill two birds with one stone - IMX is supported from the very beginning and we do have generic code to extend it by other vendors. > I don't know how FPGA > bistream loading typically works, but I guess it is quite different > from loading a firmware into RAM/SRAM and flush caches... FPGA quirks would be handled in arch/SoC specific code. > > I am not against reuse and unification, I just feel that this is not > really a case where we gain much. With generic "bootaux/bootm" command we can point other developers who would like to add such booting code to the already available framework. Also, we would prevent other "ad-hoc" commands adding to u-boot. > > > > > Maybe it would better to: > > - > > > > Embrace those binaries into FIT file (*.itb)? And allow multiple > > binaries loading? I'm thinking of work similar to one already did by > > Andre Przywara for SPL: > > > > "[PATCH v3 00/19] SPL: extend FIT loading support" posted on > > 31.03.2017? > > > > In that way we would "open" many new use cases, and other platforms > > (e.g. FPGA's, TI, etc) could benefit from it. > > One solid use case is to load different Linux binaries (or/and bare > > metal programs) to different SoC cores. > > > > The "meta data" (i.e. load address, data type, description), could > > be extracted from the FIT format (the code is already in u-boot). > > > > IMHO, this is very generic approach. > > I did some experiments with using FIT images for auxiliary core > firmware, however, it did not add a lot of advantage over using elf: > http://git.toradex.com/cgit/u-boot-toradex.git/commit/?h=2015.04-toradex-next&id=d1d416f272e840e8139
Re: [U-Boot] [PATCH 0/3] imx: bootaux elf firmware support
Hi Marek, Stefan, > On 04/03/2017 11:36 PM, Stefan Agner wrote: > > Hi Lukasz, > > > > On 2017-04-03 04:20, Lukasz Majewski wrote: > >> Hi Stefan, > >> > >> Thanks for your patch. Please allow me to share some ideas for > >> improvements. > >> > >>> From: Stefan Agner > >>> > >>> This patchset enables to boot elf binaries on secondary Cortex-M > >>> class cores available on i.MX 6SoloX/7Solo/7Dual. This makes > >>> handling and loading firmwares much more convinient since all > >>> information where the firmware has to be loaded to is contained in > >>> the elf headers. A typical usage looks like this: > >>> > >>> Colibri iMX7 # tftp ${loadaddr} firmware.elf && bootaux > >>> ${loadaddr} Using FEC0 device > >>> TFTP from server 192.168.10.1; our IP address is 192.168.10.2 > >>> Filename 'firmware.elf'. > >>> Load address: 0x8080 > >>> Loading: ## > >>> 88.3 KiB 5.4 MiB/s > >>> done > >>> Bytes transferred = 90424 (16138 hex) > >>> ## Starting auxiliary core at 0x1FFF8311 ... > >>> Colibri iMX7 # > >> > >> I can find some other platforms (not only IMX), which would benefit > >> from this code - the generic 'bootaux' command. > >> > >> One good example would to allow multiple binaries for different SoC > >> Cores (e.g. 2x Cortex-A8) to be loaded and started by u-boot. > >> > >> Hence, I'm wondering if you could make those patches usable for > >> other platforms as well? > > > > I don't think that this is a good idea. bootaux is meant for > > auxiliary cores, which often use a different architecture and are > > not cache coherent (hence the cache flushes). > > > > On SMP systems the main operating system normally starts the > > secondary core. Otherwise, if you want to run them separately using > > U-Boot, maybe a new command such as bootsmp would be more suited. > > > Admitedly, I didn't look at the patch, but if you want to boot ad-hoc > cores, you can very well also boot secondary cores on the current CPU > complex with the same command. Why not ? > > Also, I think this might come useful when booting stuff like "Altera > Sparrow" ... This is one of already available use cases in my mind. That is why I do see the need to add generic approach here. Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 0/3] imx: bootaux elf firmware support
Hi Stefan, > On 2017-04-03 16:34, Marek Vasut wrote: > > On 04/04/2017 12:42 AM, Stefan Agner wrote: > >> On 2017-04-03 15:07, Marek Vasut wrote: > >>> On 04/03/2017 11:36 PM, Stefan Agner wrote: > Hi Lukasz, > > On 2017-04-03 04:20, Lukasz Majewski wrote: > > Hi Stefan, > > > > Thanks for your patch. Please allow me to share some ideas for > > improvements. > > > >> From: Stefan Agner > >> > >> This patchset enables to boot elf binaries on secondary > >> Cortex-M class cores available on i.MX 6SoloX/7Solo/7Dual. > >> This makes handling and loading firmwares much more convinient > >> since all information where the firmware has to be loaded to > >> is contained in the elf headers. A typical usage looks like > >> this: > >> > >> Colibri iMX7 # tftp ${loadaddr} firmware.elf && bootaux > >> ${loadaddr} Using FEC0 device > >> TFTP from server 192.168.10.1; our IP address is 192.168.10.2 > >> Filename 'firmware.elf'. > >> Load address: 0x8080 > >> Loading: ## > >> 88.3 KiB 5.4 MiB/s > >> done > >> Bytes transferred = 90424 (16138 hex) > >> ## Starting auxiliary core at 0x1FFF8311 ... > >> Colibri iMX7 # > > > > I can find some other platforms (not only IMX), which would > > benefit from this code - the generic 'bootaux' command. > > > > One good example would to allow multiple binaries for different > > SoC Cores (e.g. 2x Cortex-A8) to be loaded and started by > > u-boot. > > > > Hence, I'm wondering if you could make those patches usable for > > other platforms as well? > > I don't think that this is a good idea. bootaux is meant for > auxiliary cores, which often use a different architecture and > are not cache coherent (hence the cache flushes). > > On SMP systems the main operating system normally starts the > secondary core. Otherwise, if you want to run them separately > using U-Boot, maybe a new command such as bootsmp would be more > suited. > > >>> Admitedly, I didn't look at the patch, but if you want to boot > >>> ad-hoc cores, you can very well also boot secondary cores on the > >>> current CPU complex with the same command. Why not ? > >> > >> Sure, it could be done. I just feel it is not the right design. > >> > >> Auxiliary cores have usually a different view to memory, this is > >> why I had to add the get_host_mapping callback in the elf loader > >> code to let architecture dependent code translate to host > >> addresses. SMP systems don't need that. > >> > >> Also flush caches is not necessary on some cache coherent CPU's > >> (depending on how your cache coherence between I and D cache looks > >> like). > > > > So SMP is just a reduced special-case of this , yes ? > > Yeah, I guess you can get away with dummy callback implementation and > a performance hit due to cash flushes. > > > > >> Creating a new command like bootaux comes with very few overhead. > > > > The overhead is the new command, we already have many ad-hoc > > commands. > > > > Agreed, and I really wished that this got discussed when that command > initially got added. I brought it up back then... > https://lists.denx.de/pipermail/u-boot/2016-January/240323.html I can only regret that this discussion did not happened then... > > It seemed to be acceptable to just add this ad hoc command, with some > "random binary format" support back then... Ok, it is not entirely > random, since it is the format of a binary how it ends up in > microcontrollers execute in place flash (stack pointer and reset > vector are the two first words) However, making this ad hoc > command now generic really feels weird to me, since we would end up > supporting that format for A class CPUs etc... bootaux is really > suited for auxiliary M-class cores on ARM, as it is right now. Maybe > we should have named it bootm ;-) Please refer to my reply to an earlier mail in this thread. > > >> This are the reasons why I feel creating a new command for a SMP > >> boot case makes more sense. We can still reuse functions which are > >> very similar by moving them into some common location, where it > >> makes sense. > >> > >>> > >>> Also, I think this might come useful when booting stuff like > >>> "Altera Sparrow" ... > >> > >> I am not familiar with that architecture, what kind of core does it > >> provide which needs to be booted by U-Boot? > > > > The secondary ARM core in the SoCFPGA C-A9 complex or Nios2 core in > > the FPGA. > > In my thinking, the Nios2 core seems like such a remote processor well > suited for the bootaux command. For the secondary A9, I would create a > new command. > > If we want to support the two with the same command, we already have a > first problem: How do we address them? Of course, we could add just a > index or something, but this would al
Re: [U-Boot] [PATCH] libfdt: fix build with Python 3
Hi Stefan, On 03/04/2017 23:02, Stefan Agner wrote: > But then, I don't expect that "/usr/bin/env python" is looking at > PYTHON. > > As far as I understand env, it just looks up the current environment to > run its COMMAND argument. Agree, this is also mz understanding. > It is helpful as a shebang, but it does not > seem to make any difference to calling "python" directly (since that > also just looks up the current environment PATH and executes the first > python it finds... Agree - so that is disturbing is the fix calls to "python" inside Makefile. That means it remains to change: tools/_libfdt.so: $(patsubst %.o,%.c,$(LIBFDT_OBJS)) tools/libfdt_wrap.c LDFLAGS="$(HOSTLDFLAGS)" CFLAGS= python $(srctree)/lib/libfdt/setup.py to: tools/_libfdt.so: $(patsubst %.o,%.c,$(LIBFDT_OBJS)) tools/libfdt_wrap.c LDFLAGS="$(HOSTLDFLAGS)" CFLAGS= ${PYTHON} $(srctree)/lib/libfdt/setup.py Regards, Stefano -- = DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/9] sunxi: Remove SYS_EXTRA_OPTIONS
On Tuesday 04 April 2017 01:42 PM, Maxime Ripard wrote: Hi, On Sun, Apr 02, 2017 at 12:59:02PM +0200, Mylène Josserand wrote: This a V3 for my patchset that removes the SYS_EXTRA_OPTIONS from all sunxi defconfigs. The values in this variable are converted to Kconfig or simply removed. Based on u-boot sunxi repository: git://git.denx.de/u-boot-sunxi.git "master" branch, from last commit: 6f72a951cdd07e3f9d214b189762b978cd2acf45 Thanks for sending this again. There was a build breakage for all the non-sunxi boards in your last patch. I've fixed it by adding a depends on ARCH_SUNXI to avoid multiple definitions of CONS_INDEX on the other architectures, and applied it. These need to to send-again on top of master-pr, I'm running buildman on top of u-boot/master with sunxi/master changes. Observed errors while applying these 9 patches, thanks! -- Jagan Teki Free Software Engineer | www.openedev.com U-Boot, Linux | Upstream Maintainer Hyderabad, India. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Remove global variable env_t *env_ptr ?
Hi Joakim, > I am looking at adding support for runtime sizing of CONFIG_ENV_ADDR > as we need to replace out flash but we don't want to create a new > u-boot binairy just for this simple change. Please correct me if I did not understand your use case correctly. Other boards have separate regions in flash to store ENV variables - even redundancy is supported (from ./include/mccmon6.h) /* Envs are stored in NOR flash */ #define CONFIG_ENV_IS_IN_FLASH #define CONFIG_ENV_SECT_SIZE(SZ_128K) #define CONFIG_ENV_ADDR (CONFIG_SYS_FLASH_BASE + 0x4) #define CONFIG_SYS_REDUNDAND_ENVIRONMENT #define CONFIG_ENV_ADDR_REDUND (CONFIG_SYS_FLASH_BASE + 0x6) #define CONFIG_ENV_SIZE_REDUND CONFIG_ENV_SIZE You can extract the ENV variables by using following script: scripts/get_default_envs.sh > default_envs.txt and then create updated env image (with [*]) to be stored on flash. Note: [*] ./tools/mkenvimage -s 131072 -o ${UBOOT_ENVS_DEFAULT} default_envs.txt Best regards, Łukasz Majewski > > While converting env_flash.c I noted the global variable > env_t *env_ptr = (env_t *)CONFIG_ENV_ADDR; > which cannot be runtime decided. > Looking at users of this variable I only find one in pmc405de.c(not > sure what that board is doing) and for what I can tell this variable > is not correct for redundant env. either. > > Anyhow, I am faced wit two choices, either remove the env_ptr or > convert it to a function call. > > What do fellow u-booters think about env_ptr? > > Jocke > > PS. Adding my work so far here: > From 5d3791099fb6a2c503b83298ac1f6135331466dc Mon Sep 17 00:00:00 2001 > From: David Gounaris > Date: Fri, 31 Mar 2017 11:31:40 +0200 > Subject: [PATCH 2/4] env_flash.c: Support dynamic sector size > > This lay the ground work for supporting a non constant > sector size environment data. > --- > common/env_flash.c | 152 > + 1 file changed, > 83 insertions(+), 69 deletions(-) > > diff --git a/common/env_flash.c b/common/env_flash.c > index 004e884..306ef42 100644 > --- a/common/env_flash.c > +++ b/common/env_flash.c > @@ -36,31 +36,20 @@ char *env_name_spec = "Flash"; > #ifdef ENV_IS_EMBEDDED > env_t *env_ptr = &environment; > > -static env_t *flash_addr = (env_t *)CONFIG_ENV_ADDR; > - > #else /* ! ENV_IS_EMBEDDED */ > > env_t *env_ptr = (env_t *)CONFIG_ENV_ADDR; > -static env_t *flash_addr = (env_t *)CONFIG_ENV_ADDR; > #endif /* ENV_IS_EMBEDDED */ > > -#if defined(CMD_SAVEENV) || defined(CONFIG_ENV_ADDR_REDUND) > -/* CONFIG_ENV_ADDR is supposed to be on sector boundary */ > -static ulong end_addr = CONFIG_ENV_ADDR + CONFIG_ENV_SECT_SIZE - 1; > -#endif > - > -#ifdef CONFIG_ENV_ADDR_REDUND > -static env_t *flash_addr_new = (env_t *)CONFIG_ENV_ADDR_REDUND; > - > -/* CONFIG_ENV_ADDR_REDUND is supposed to be on sector boundary */ > -static ulong end_addr_new = CONFIG_ENV_ADDR_REDUND + > CONFIG_ENV_SECT_SIZE - 1; -#endif /* CONFIG_ENV_ADDR_REDUND */ > - > - > #ifdef CONFIG_ENV_ADDR_REDUND > int env_init(void) > { > int crc1_ok = 0, crc2_ok = 0; > + env_t *flash_addr; > + env_t *flash_addr_new; > + > + flash_addr = (env_t *)CONFIG_ENV_ADDR; > + flash_addr_new = (env_t *)CONFIG_ENV_ADDR_REDUND; > > uchar flag1 = flash_addr->flags; > uchar flag2 = flash_addr_new->flags; > @@ -109,9 +98,28 @@ int saveenv(void) > char*saved_data = NULL; > charflag = OBSOLETE_FLAG, new_flag = ACTIVE_FLAG; > int rc = 1; > -#if CONFIG_ENV_SECT_SIZE > CONFIG_ENV_SIZE > - ulong up_data = 0; > -#endif > + ulong up_data = 0; > + env_t *flash_addr; > + env_t *flash_addr_new; > + ulong end_addr; > + ulong end_addr_new; > + > + flash_addr = (env_t *)CONFIG_ENV_ADDR; > + flash_addr_new = (env_t *)CONFIG_ENV_ADDR_REDUND; > + end_addr = CONFIG_ENV_ADDR + CONFIG_ENV_SECT_SIZE - 1; > + end_addr_new = CONFIG_ENV_ADDR_REDUND + CONFIG_ENV_SECT_SIZE > - 1; + > + if (gd->env_addr != (ulong)&(flash_addr->data)) { > + /* Swap new and old ptrs */ > + env_t *etmp = flash_addr; > + ulong ltmp = end_addr; > + > + flash_addr = flash_addr_new; > + flash_addr_new = etmp; > + > + end_addr = end_addr_new; > + end_addr_new = ltmp; > + } > > debug("Protect off %08lX ... %08lX\n", (ulong)flash_addr, > end_addr); > @@ -129,24 +137,25 @@ int saveenv(void) > return rc; > env_new.flags = new_flag; > > -#if CONFIG_ENV_SECT_SIZE > CONFIG_ENV_SIZE > - up_data = end_addr_new + 1 - ((long)flash_addr_new + > CONFIG_ENV_SIZE); > - debug("Data to save 0x%lX\n", up_data); > - if (up_data) { > - saved_data = malloc(up_data); > - if (saved_data == NULL) { > - printf("Unable to save the rest of sector > (%ld)\n", > - up_data); > - goto done; > + if(CONFIG_ENV_SECT_
Re: [U-Boot] [PATCH 0/3] imx: bootaux elf firmware support
On 04/04/2017 02:02 AM, Stefan Agner wrote: [...] Admitedly, I didn't look at the patch, but if you want to boot ad-hoc cores, you can very well also boot secondary cores on the current CPU complex with the same command. Why not ? >>> >>> Sure, it could be done. I just feel it is not the right design. >>> >>> Auxiliary cores have usually a different view to memory, this is why I >>> had to add the get_host_mapping callback in the elf loader code to let >>> architecture dependent code translate to host addresses. SMP systems >>> don't need that. >>> >>> Also flush caches is not necessary on some cache coherent CPU's >>> (depending on how your cache coherence between I and D cache looks >>> like). >> >> So SMP is just a reduced special-case of this , yes ? > > Yeah, I guess you can get away with dummy callback implementation and a > performance hit due to cash flushes. Or you can abstract things out ? >>> Creating a new command like bootaux comes with very few overhead. >> >> The overhead is the new command, we already have many ad-hoc commands. >> > > Agreed, and I really wished that this got discussed when that command > initially got added. I brought it up back then... > https://lists.denx.de/pipermail/u-boot/2016-January/240323.html > > It seemed to be acceptable to just add this ad hoc command, with some > "random binary format" support back then... Based on that discussion, I only see that noone opposed, but I don't see any agreement. > Ok, it is not entirely > random, since it is the format of a binary how it ends up in > microcontrollers execute in place flash (stack pointer and reset vector > are the two first words) I thought this command was starting the core by loading data to RAM , not flash ? > However, making this ad hoc command now > generic really feels weird to me, since we would end up supporting that > format for A class CPUs etc... bootaux is really suited for auxiliary > M-class cores on ARM, as it is right now. Maybe we should have named it > bootm ;-) We always try to avoid one-off hacks, so it's not weird. I still don't quite understand how it is a problem to abstract things out . I am not asking you to support CA, but to avoid CM specific implementation which cannot be extended to support CA or even MIPS/Nios2/etc . >>> This are the reasons why I feel creating a new command for a SMP boot >>> case makes more sense. We can still reuse functions which are very >>> similar by moving them into some common location, where it makes sense. >>> Also, I think this might come useful when booting stuff like "Altera Sparrow" ... >>> >>> I am not familiar with that architecture, what kind of core does it >>> provide which needs to be booted by U-Boot? >> >> The secondary ARM core in the SoCFPGA C-A9 complex or Nios2 core in the >> FPGA. > > In my thinking, the Nios2 core seems like such a remote processor well > suited for the bootaux command. For the secondary A9, I would create a > new command. Uh, why, that does not make any sense to me. Both the random core in FPGA and the secondary CA9 core have almost the same bringup sequence. What is so different about this stuff ? > If we want to support the two with the same command, we already have a > first problem: How do we address them? Of course, we could add just a > index or something, but this would already break backward compatibility > of the bootaux command. So we already accepted a command which has shit commandline semantics and we're stuck with it , hrm. You can always specify a default core index for those two iMX boards and it's done. Or just fix the semantics in their default environment, which is not awesome, but I doubt this is wildly used yet. -- 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 0/5] Patches to reduce TPL code size
Am Sonntag, 2. April 2017, 09:50:27 CEST schrieb Simon Glass: > With the rockchip 'rock' board some build and code size problems have come > to light with TPL. This series provides a few ideas to improve things. great stuff! With these patches applied, rk3188-rock still boots and the TPL has come down to 616byte on gcc-4.9 and 592bytes on gcc-6.3, so Tested-by: Heiko Stuebner We have like vast amounts of free space in tpl now ;-) I guess I should fold your TINY_MEMSET option into my rock board, once you've applied the core patch? Heiko > > Changes in v2: > - Adjust the option to be SPL-only > - Change the option to default to off (name it CONFIG_SPL_TINY_MEMSET) > - Add a new patch to enable CONFIG_SPL_TINY_MEMSET > - Add new patch to allow driver model to be disabled for TPL > - Add new patch to allow driver-model serial to be disabled for TPL > > Simon Glass (5): > string: Provide a slimmed-down memset() > rockchip: rock: Enable CONFIG_SPL_TINY_MEMSET > Makefile: Provide an option to select SPL or TPL > dm: core: Allow driver model to be disabled for TPL > dm: serial: Allow driver-model serial to be disabled for TPL > > configs/rock_defconfig | 1 + > drivers/Makefile| 2 +- > drivers/core/Kconfig| 14 ++ > drivers/serial/Kconfig | 20 > drivers/serial/Makefile | 2 +- > lib/Kconfig | 8 > lib/string.c| 6 -- > scripts/Kbuild.include | 6 ++ > scripts/Makefile.spl| 6 ++ > 9 files changed, 61 insertions(+), 4 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/5] string: Provide a slimmed-down memset()
Am Sonntag, 2. April 2017, 09:50:28 CEST schrieb Simon Glass: > Most of the time the optimised memset() is what we want. For extreme > situations such as TPL it may be too large. For example on the 'rock' > board, using a simple loop saves a useful 48 bytes. With gcc 4.9 and > the rodata bug, this patch is enough to reduce the TPL image below the > limit. > > Signed-off-by: Simon Glass > --- > > Changes in v2: > - Adjust the option to be SPL-only > - Change the option to default to off (name it CONFIG_SPL_TINY_MEMSET) > > lib/Kconfig | 8 > lib/string.c | 6 -- > 2 files changed, 12 insertions(+), 2 deletions(-) > > diff --git a/lib/Kconfig b/lib/Kconfig > index 65c01573e1..58b5717dcd 100644 > --- a/lib/Kconfig > +++ b/lib/Kconfig > @@ -52,6 +52,14 @@ config LIB_RAND > help > This library provides pseudo-random number generator functions. > > +config SPL_TINY_MEMSET > + bool "Use a very small memset() in SPL" > + help > + The faster memset() is the arch-specific one (if available) enabled > + by CONFIG_USE_ARCH_MEMSET. If that is not enabled, we can still get > + better performance by write a word at a time. Enable this option > + to reduce code size slightly at the cost of some speed. Wording sounds off, I guess we could do something like [...better performance by] writing a word at a time. In very size-constrained environments even this may be to big though. [Enable this option...] Otherwise Reviewed-by: Heiko Stuebner > + > source lib/dhry/Kconfig > > source lib/rsa/Kconfig > diff --git a/lib/string.c b/lib/string.c > index 67d5f6a421..c1a28c14ce 100644 > --- a/lib/string.c > +++ b/lib/string.c > @@ -437,8 +437,10 @@ char *strswab(const char *s) > void * memset(void * s,int c,size_t count) > { > unsigned long *sl = (unsigned long *) s; > - unsigned long cl = 0; > char *s8; > + > +#if !CONFIG_IS_ENABLED(TINY_MEMSET) > + unsigned long cl = 0; > int i; > > /* do it one word at a time (32 bits or 64 bits) while possible */ > @@ -452,7 +454,7 @@ void * memset(void * s,int c,size_t count) > count -= sizeof(*sl); > } > } > - /* fill 8 bits at a time */ > +#endif /* fill 8 bits at a time */ > s8 = (char *)sl; > while (count--) > *s8++ = c; ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/9] sunxi: Remove SYS_EXTRA_OPTIONS
On Tue, Apr 04, 2017 at 02:25:09PM +0530, Jagan Teki wrote: > On Tuesday 04 April 2017 01:42 PM, Maxime Ripard wrote: > > Hi, > > > > On Sun, Apr 02, 2017 at 12:59:02PM +0200, Mylène Josserand wrote: > > > This a V3 for my patchset that removes the SYS_EXTRA_OPTIONS from all > > > sunxi defconfigs. > > > The values in this variable are converted to Kconfig or simply removed. > > > > > > Based on u-boot sunxi repository: git://git.denx.de/u-boot-sunxi.git > > > "master" branch, from last commit: > > > 6f72a951cdd07e3f9d214b189762b978cd2acf45 > > > > Thanks for sending this again. > > > > There was a build breakage for all the non-sunxi boards in your last > > patch. I've fixed it by adding a depends on ARCH_SUNXI to avoid > > multiple definitions of CONS_INDEX on the other architectures, and > > applied it. > > These need to to send-again on top of master-pr, I'm running buildman on top > of u-boot/master with sunxi/master changes. Observed errors while applying > these 9 patches, I ran buildman on the patches that have been pushed, there's no errors, which errors did you encounter. The branches are kind of weird too, afaik, there's three of them, master, master-pr (that has been created today), master-next (that has kind of the same patches than master, but doesn't share the same history for some reason) and next (with yet again a different set of patches than master, but definitely not the same than master-next). Can we agree on *one* branch to push patches too? Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/9] sunxi: Remove SYS_EXTRA_OPTIONS
On Tue, Apr 4, 2017 at 3:11 PM, Maxime Ripard wrote: > On Tue, Apr 04, 2017 at 02:25:09PM +0530, Jagan Teki wrote: >> On Tuesday 04 April 2017 01:42 PM, Maxime Ripard wrote: >> > Hi, >> > >> > On Sun, Apr 02, 2017 at 12:59:02PM +0200, Mylène Josserand wrote: >> > > This a V3 for my patchset that removes the SYS_EXTRA_OPTIONS from all >> > > sunxi defconfigs. >> > > The values in this variable are converted to Kconfig or simply removed. >> > > >> > > Based on u-boot sunxi repository: git://git.denx.de/u-boot-sunxi.git >> > > "master" branch, from last commit: >> > > 6f72a951cdd07e3f9d214b189762b978cd2acf45 >> > >> > Thanks for sending this again. >> > >> > There was a build breakage for all the non-sunxi boards in your last >> > patch. I've fixed it by adding a depends on ARCH_SUNXI to avoid >> > multiple definitions of CONS_INDEX on the other architectures, and >> > applied it. >> >> These need to to send-again on top of master-pr, I'm running buildman on top >> of u-boot/master with sunxi/master changes. Observed errors while applying >> these 9 patches, > > I ran buildman on the patches that have been pushed, there's no > errors, which errors did you encounter. > > The branches are kind of weird too, afaik, there's three of them, > master, master-pr (that has been created today), master-next (that has > kind of the same patches than master, but doesn't share the same > history for some reason) and next (with yet again a different set of > patches than master, but definitely not the same than master-next). > > Can we agree on *one* branch to push patches too? [1] these are buildman issues, I rebased master with sunxi/master and ran the buildman. Now, re-arranged and squashed few commits and running master-pr, once this is fine I will copy this as master and send the PR. So-that we can apply patches on top of this. [1] https://www.mail-archive.com/u-boot@lists.denx.de/msg243580.html thanks! -- Jagan Teki Free Software Engineer | www.openedev.com U-Boot, Linux | Upstream Maintainer Hyderabad, India. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Remove global variable env_t *env_ptr ?
On Tue, 2017-04-04 at 10:55 +0200, Lukasz Majewski wrote: > Hi Joakim, > > > I am looking at adding support for runtime sizing of CONFIG_ENV_ADDR > > as we need to replace out flash but we don't want to create a new > > u-boot binairy just for this simple change. > > Please correct me if I did not understand your use case correctly. > > Other boards have separate regions in flash to store ENV variables - > even redundancy is supported (from ./include/mccmon6.h) > > /* Envs are stored in NOR flash */ > #define CONFIG_ENV_IS_IN_FLASH > #define CONFIG_ENV_SECT_SIZE(SZ_128K) > #define CONFIG_ENV_ADDR (CONFIG_SYS_FLASH_BASE + 0x4) > > #define CONFIG_SYS_REDUNDAND_ENVIRONMENT > #define CONFIG_ENV_ADDR_REDUND (CONFIG_SYS_FLASH_BASE + 0x6) > #define CONFIG_ENV_SIZE_REDUND CONFIG_ENV_SIZE Use case is when CONFIG_ENV_SECT_SIZE and/or CONFIG_ENV_ADDR are non constants. Then, in my case, these becomes: #define CONFIG_ENV_SECT_SIZE(get_env_sect_size()) #define CONFIG_ENV_ADDR(get_env_address()) Jocke > > You can extract the ENV variables by using following script: > > scripts/get_default_envs.sh > default_envs.txt > > and then create updated env image (with [*]) to be stored on flash. > > > Note: > > [*] > ./tools/mkenvimage -s 131072 -o ${UBOOT_ENVS_DEFAULT} default_envs.txt > > Best regards, > Łukasz Majewski > > > > > While converting env_flash.c I noted the global variable > > env_t *env_ptr = (env_t *)CONFIG_ENV_ADDR; > > which cannot be runtime decided. > > Looking at users of this variable I only find one in pmc405de.c(not > > sure what that board is doing) and for what I can tell this variable > > is not correct for redundant env. either. > > > > Anyhow, I am faced wit two choices, either remove the env_ptr or > > convert it to a function call. > > > > What do fellow u-booters think about env_ptr? > > > > Jocke > > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Remove global variable env_t *env_ptr ?
Dear Joakim, In message <1491293863.4177.92.ca...@infinera.com> you wrote: > > After a brief look I think we are good. Let me explain, I am only > making it possible to #define CONFIG_ENV_ADDR, CONFIG_ENV_SECT_SIZE etc. > as non constant data by moving the assignment of flash_addr etc. to runtime, > removing the static variable(less relocs to perform too :), I not forcing > anyone to do so and only for env_flash.c > > The only variable that I can't do away with it the: > env_t *env_ptr = (env_t *)CONFIG_ENV_ADDR; > as it is global. Nothing really uses this global variable(except pmc405de.c > which is EPROM), > not even the linker scripts below. They use #defines > directly(CONFIG_ENV_OFFSET, > CONFIG_SYS_FLASH_BASE etc. except for env_embedded.c which uses other > variables) But CONFIG_ENV_ADDR and CONFIG_ENV_OFFSET are somewhat related, aren't they? > As nothing really uses env_ptr and a variable isn't really a good > interface(compare > with the errno variable) I propose that the env_ptr variable in code is > removed but > lets start with removing it for env_flash.c first. But if you make it possible to change flash_addr at runtime, then the assumptions of the linker and the actual placeent of the environment sector in flash would no longer be in sync with the code's view of thing. Maybe you could be so kind and explain your use case? To me it looks as if you want to "switch" to a different location, i. e. to alternative environment settings. If this is what you want to do I wonder if it's not easier (at least it does not require code changes) to switch "profiles" by using "env import" ? 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 Just about every computer on the market today runs Unix, except the Mac (and nobody cares about it). - Bill Joy 6/21/85 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Remove global variable env_t *env_ptr ?
Dear Joakim, In message <1491301459.28343.1.ca...@infinera.com> you wrote: > > Use case is when CONFIG_ENV_SECT_SIZE and/or CONFIG_ENV_ADDR are non > constants. That is my exact question - when would this happen? Flash sectors do now wander around in memory or change size :-) So you attempt to switch between different settings? 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 Shakespeare's Law of Prototyping: (Hamlet III, iv, 156-160) O, throw away the worser part of it, And live the purer with the other half. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/7] arm: omap-common: sata: prepare driver for DM conversion
On 01/04/2017 06:21, Simon Glass wrote: Hi, On 24 March 2017 at 06:24, Jean-Jacques Hiblot wrote: From: Mugunthan V N Prepare sata driver for DM conversion by abstracting sata phy init to seperate function. Signed-off-by: Mugunthan V N Signed-off-by: Jean-Jacques Hiblot --- arch/arm/mach-omap2/sata.c | 13 + include/sata.h | 2 ++ 2 files changed, 11 insertions(+), 4 deletions(-) diff --git a/arch/arm/mach-omap2/sata.c b/arch/arm/mach-omap2/sata.c index 217f1c9..dce432b 100644 --- a/arch/arm/mach-omap2/sata.c +++ b/arch/arm/mach-omap2/sata.c @@ -32,16 +32,21 @@ struct omap_pipe3 sata_phy = { .dpll_map = dpll_map_sata, }; +int enable_sata_phy(void) We should not be calling board functions from the driver. Can you instead add a SATA PHY uclass / driver? Simon, thanks for the review. I'll re-work the series in that direction. We already have all the required entries in the dts for this. Jean-Jacques +{ + sata_phy.power_reg = (void __iomem *)(*ctrl)->control_phy_power_sata; + + /* Power up the PHY */ + return phy_pipe3_power_on(&sata_phy); +} + #ifndef CONFIG_DM_SCSI int init_sata(int dev) { int ret; u32 val; - sata_phy.power_reg = (void __iomem *)(*ctrl)->control_phy_power_sata; - - /* Power up the PHY */ - phy_pipe3_power_on(&sata_phy); + enable_sata_phy(); /* Enable SATA module, No Idle, No Standby */ val = TI_SATA_IDLE_NO | TI_SATA_STANDBY_NO; diff --git a/include/sata.h b/include/sata.h index d18cc9a..583b72d 100644 --- a/include/sata.h +++ b/include/sata.h @@ -18,4 +18,6 @@ int sata_port_status(int dev, int port); extern struct blk_desc sata_dev_desc[]; #endif +int enable_sata_phy(void); + #endif -- 1.9.1 Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/5] Patches to reduce TPL code size
Am Dienstag, 4. April 2017, 11:34:52 CEST schrieb Heiko Stübner: > Am Sonntag, 2. April 2017, 09:50:27 CEST schrieb Simon Glass: > > With the rockchip 'rock' board some build and code size problems have come > > to light with TPL. This series provides a few ideas to improve things. > > great stuff! > > With these patches applied, rk3188-rock still boots and the TPL has > come down to 616byte on gcc-4.9 and 592bytes on gcc-6.3, so Actually, after finding out that I should add a # CONFIG_TPL_DM_SERIAL is not set to my defconfig, the size goes down even more - to 488 bytes on both gcc-4.9 and gcc-6.3. Still works and all. > Tested-by: Heiko Stuebner > > We have like vast amounts of free space in tpl now ;-) > > I guess I should fold your TINY_MEMSET option into my rock board, > once you've applied the core patch? > > > Heiko > > > > > > Changes in v2: > > - Adjust the option to be SPL-only > > - Change the option to default to off (name it CONFIG_SPL_TINY_MEMSET) > > - Add a new patch to enable CONFIG_SPL_TINY_MEMSET > > - Add new patch to allow driver model to be disabled for TPL > > - Add new patch to allow driver-model serial to be disabled for TPL > > > > Simon Glass (5): > > string: Provide a slimmed-down memset() > > rockchip: rock: Enable CONFIG_SPL_TINY_MEMSET > > Makefile: Provide an option to select SPL or TPL > > dm: core: Allow driver model to be disabled for TPL > > dm: serial: Allow driver-model serial to be disabled for TPL > > > > configs/rock_defconfig | 1 + > > drivers/Makefile| 2 +- > > drivers/core/Kconfig| 14 ++ > > drivers/serial/Kconfig | 20 > > drivers/serial/Makefile | 2 +- > > lib/Kconfig | 8 > > lib/string.c| 6 -- > > scripts/Kbuild.include | 6 ++ > > scripts/Makefile.spl| 6 ++ > > 9 files changed, 61 insertions(+), 4 deletions(-) > > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Remove global variable env_t *env_ptr ?
On Tue, 2017-04-04 at 12:31 +0200, Wolfgang Denk wrote: > Dear Joakim, > > In message <1491301459.28343.1.ca...@infinera.com> you wrote: > > > > Use case is when CONFIG_ENV_SECT_SIZE and/or CONFIG_ENV_ADDR are non > > constants. > > That is my exact question - when would this happen? Flash sectors > do now wander around in memory or change size :-) No, but they happens when you are forced to update you HW with new type of flashes with different layout so you have to move where the environment is stored. Sure, this can be fixed by having two different u-boot images but that will in our case be just painful to carry around an extra u-boot img, then in field devise a method to chose the right img. for what looks like the same HW but the flash. What I have done is not that earth shattering, basically just move from: static env_t *flash_addr = (env_t *)CONFIG_ENV_ADDR; to int env_init(void) { ... env_t *flash_addr = (env_t *)CONFIG_ENV_ADDR; This allows CONFIG_ENV_ADDR to be a function but it does not have to, you also lose a relocation entry as a static variable is removed. Jocke ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 6/7] dm: scsi: fix scan
On 01/04/2017 06:22, Simon Glass wrote: Hi Jean-Jacques, On 24 March 2017 at 06:24, Jean-Jacques Hiblot wrote: With DM_SCSI enabled, scsi scan suffers 2 problems: * blk_create_devicef is called with blkz = 0, leading to a divide-by-0 exception * new blk devices are created at each scan. To fix this we start by removing all known SCSI devices at the beginning of the scan. Then a detection process is started for each possible device only to get the blksz and lba of the device (no call to part_init() yet). If a device is found, we can call blk_create_devicef() with the right parameters and continue the process. Signed-off-by: Jean-Jacques Hiblot --- common/scsi.c | 35 +-- 1 file changed, 29 insertions(+), 6 deletions(-) diff --git a/common/scsi.c b/common/scsi.c index fb5b407..3385cc2 100644 --- a/common/scsi.c +++ b/common/scsi.c @@ -480,7 +480,7 @@ static void scsi_init_dev_desc(struct blk_desc *dev_desc, int devnum) * * Return: 0 on success, error value otherwise */ -static int scsi_detect_dev(int target, struct blk_desc *dev_desc) +static int scsi_detect_dev(int target, struct blk_desc *dev_desc, int init_part) { unsigned char perq, modi; lbaint_t capacity; @@ -539,7 +539,8 @@ static int scsi_detect_dev(int target, struct blk_desc *dev_desc) dev_desc->blksz = blksz; dev_desc->log2blksz = LOG2(dev_desc->blksz); dev_desc->type = perq; - part_init(&dev_desc[0]); + if (init_part) + part_init(&dev_desc[0]); Do you need this in here? The caller could just do it and avoid the extra parameter. I simply tried as much as possible to avoid code duplication. But agreed it's not a very elegant solution. I'll rework this. Thanks again for the comments removable: return 0; } @@ -565,6 +566,9 @@ int scsi_scan(int mode) if (ret) return ret; + /* remove all SCSI interfaces since we're going to (re)create them */ + blk_unbind_all(IF_TYPE_SCSI); + This seems to already be done a few lines up...is it needed? No. It's just a rebase issue. I started the work on v2017.01 and didn't see the introduction of the unbind. uclass_foreach_dev(dev, uc) { struct scsi_platdata *plat; /* scsi controller platdata */ @@ -580,9 +584,20 @@ int scsi_scan(int mode) for (lun = 0; lun < plat->max_lun; lun++) { struct udevice *bdev; /* block device */ /* block device description */ + struct blk_desc _bd; struct blk_desc *bdesc; char str[10]; + scsi_init_dev_desc_priv(&_bd); + _bd.lun = lun; + ret = scsi_detect_dev(i, &_bd, 0); + if (ret) + /* +* no device detected? +* check the next lun. +*/ + continue; + /* * Create only one block device and do detection * to make sure that there won't be a lot of @@ -590,17 +605,25 @@ int scsi_scan(int mode) */ snprintf(str, sizeof(str), "id%dlun%d", i, lun); ret = blk_create_devicef(dev, "scsi_blk", - str, IF_TYPE_SCSI, - -1, 0, 0, &bdev); + str, IF_TYPE_SCSI, + -1, + _bd.blksz, + _bd.blksz * _bd.lba, + &bdev); But why put these in here when... if (ret) { debug("Can't create device\n"); return ret; } bdesc = dev_get_uclass_platdata(bdev); + /* +* perform the detection once more but this +* time, let's initialize do the initialization +* of the partitions +*/ scsi_init_dev_desc_priv(bdesc); ...they are overwritten here? bdesc->lun = lun; - ret = scsi_detect_dev(i, bdesc); + ret = scsi_detect_dev(i, bdes
Re: [U-Boot] Remove global variable env_t *env_ptr ?
Dear Joakim, In message <1491302640.30240.1.ca...@infinera.com> you wrote: > > > That is my exact question - when would this happen? Flash sectors > > do now wander around in memory or change size :-) > > No, but they happens when you are forced to update you HW with new type of > flashes > with different layout so you have to move where the environment is stored. > Sure, this can be fixed by having two different u-boot images but that will > in our case be just painful to carry around an extra u-boot img, then in field > devise a method to chose the right img. for what looks like the same HW but > the flash. I see. Well, this obviously means that you are _not_ using an embedded environment, as otherwise the linker generated image would be wrong for the "other" type of flash chips - which means, the environment is somewhare outside, separate from the U-Boot image. So you have old hardware, running old U-Boot, which does not support the new flash. For this, you need a new U-Boot, which then shall support both the old and the new flash, right? But why can you then not simply come up with a new flash layout, which is compatoble with the old and new flashes, so it can use a common configuration, without code changes? I'm aware that embedded environment is not used very often these days any more, as is parallel NOR flash, but changes in this are have caused trouble more than once in the past, so I am not convinced that it's wise to touch such ancient, "stable" code for an exotic feature that probably nobody else will ever need? 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 explanation requiring the fewest assumptions is the most likely to be correct.-- William of Occam ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/9] sunxi: Remove SYS_EXTRA_OPTIONS
On Tue, Apr 04, 2017 at 03:26:55PM +0530, Jagan Teki wrote: > On Tue, Apr 4, 2017 at 3:11 PM, Maxime Ripard > wrote: > > On Tue, Apr 04, 2017 at 02:25:09PM +0530, Jagan Teki wrote: > >> On Tuesday 04 April 2017 01:42 PM, Maxime Ripard wrote: > >> > Hi, > >> > > >> > On Sun, Apr 02, 2017 at 12:59:02PM +0200, Mylène Josserand wrote: > >> > > This a V3 for my patchset that removes the SYS_EXTRA_OPTIONS from all > >> > > sunxi defconfigs. > >> > > The values in this variable are converted to Kconfig or simply removed. > >> > > > >> > > Based on u-boot sunxi repository: git://git.denx.de/u-boot-sunxi.git > >> > > "master" branch, from last commit: > >> > > 6f72a951cdd07e3f9d214b189762b978cd2acf45 > >> > > >> > Thanks for sending this again. > >> > > >> > There was a build breakage for all the non-sunxi boards in your last > >> > patch. I've fixed it by adding a depends on ARCH_SUNXI to avoid > >> > multiple definitions of CONS_INDEX on the other architectures, and > >> > applied it. > >> > >> These need to to send-again on top of master-pr, I'm running buildman on > >> top > >> of u-boot/master with sunxi/master changes. Observed errors while applying > >> these 9 patches, > > > > I ran buildman on the patches that have been pushed, there's no > > errors, which errors did you encounter. > > > > The branches are kind of weird too, afaik, there's three of them, > > master, master-pr (that has been created today), master-next (that has > > kind of the same patches than master, but doesn't share the same > > history for some reason) and next (with yet again a different set of > > patches than master, but definitely not the same than master-next). > > > > Can we agree on *one* branch to push patches too? > > [1] these are buildman issues, I rebased master with sunxi/master and > ran the buildman. See the answers from Chen-Yu, those issues are already fixed. > Now, re-arranged and squashed few commits and running master-pr, once > this is fine I will copy this as master and send the PR. > So-that we can apply patches on top of this. So, where am I supposed to apply patches? master, master-pr, next, master-next? What are those branches for? Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Remove global variable env_t *env_ptr ?
On Tue, 2017-04-04 at 13:27 +0200, Wolfgang Denk wrote: > Dear Joakim, > > In message <1491302640.30240.1.ca...@infinera.com> you wrote: > > > > > That is my exact question - when would this happen? Flash sectors > > > do now wander around in memory or change size :-) > > > > No, but they happens when you are forced to update you HW with new type of > > flashes > > with different layout so you have to move where the environment is stored. > > Sure, this can be fixed by having two different u-boot images but that will > > in our case be just painful to carry around an extra u-boot img, then in > > field > > devise a method to chose the right img. for what looks like the same HW but > > the flash. > > I see. Well, this obviously means that you are _not_ using an > embedded environment, as otherwise the linker generated image would > be wrong for the "other" type of flash chips - which means, the > environment is somewhare outside, separate from the U-Boot image. Right. The env. is on separate sectors not in u-boot's own space. > > So you have old hardware, running old U-Boot, which does not support > the new flash. For this, you need a new U-Boot, which then shall > support both the old and the new flash, right? But why can you then > not simply come up with a new flash layout, which is compatoble with > the old and new flashes, so it can use a common configuration, > without code changes? Because the old flash has its env. in "small" sectors which does not exist on new flash so the layout on the new flash has both different env. address as well as a bigger env. sector size. I cannot move the old env. either as there is no free space for that(the rest of the flash is a JFFS2 FS) > > I'm aware that embedded environment is not used very often these > days any more, as is parallel NOR flash, but changes in this are > have caused trouble more than once in the past, so I am not > convinced that it's wise to touch such ancient, "stable" code for > an exotic feature that probably nobody else will ever need? Again, I don't think I am changing much(if anything) for your embedded case. Please read the WIP patch I sent earlier and perhaps you can point me to a potential problem area? Not sure about "nobody else will ever need" as Micron are terminating the Intel/cmdset0001 flashes(don't know if this applies to all Intel chips though) and we have to swap to AMD/cmd0002, we are just early with this change. Jocke ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 11/17] aspeed: Add I2C Driver
On Mon, 2017-03-27 at 21:40 +1100, Benjamin Herrenschmidt wrote: > On Wed, 2017-03-22 at 07:05 -0600, Simon Glass wrote: > > On 16 March 2017 at 15:36, Maxim Sloyko wrote: > > > Add Device Model based I2C driver for ast2500/ast2400 SoCs. > > > The driver is very limited, it only supports master mode and > > > synchronous byte-by-byte reads/writes, no DMA or Pool Buffers. > > > > > > Signed-off-by: Maxim Sloyko > > > --- > > Ah interesting, I was just rewriting that driver last week ... I'll > review yours ASAP. Ignore me, I was talking about the Linux one. > > > > drivers/i2c/Kconfig | 9 ++ > > > drivers/i2c/Makefile | 1 + > > > drivers/i2c/ast_i2c.c | 355 > > > ++ > > > drivers/i2c/ast_i2c.h | 132 +++ > > > 4 files changed, 497 insertions(+) > > > create mode 100644 drivers/i2c/ast_i2c.c > > > create mode 100644 drivers/i2c/ast_i2c.h > > > > Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/3] armv8: ls1043a: Drop macro CONFIG_LS1043A
Use CONFIG_ARCH_LS1043A instead. Signed-off-by: York Sun --- arch/arm/cpu/armv8/fsl-layerscape/Makefile| 2 +- arch/arm/include/asm/arch-fsl-layerscape/config.h | 2 +- arch/arm/include/asm/fsl_secure_boot.h| 4 ++-- drivers/net/fm/Makefile | 2 +- include/configs/ls1043a_common.h | 1 - include/linux/usb/xhci-fsl.h | 2 +- scripts/config_whitelist.txt | 1 - 7 files changed, 6 insertions(+), 8 deletions(-) diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Makefile b/arch/arm/cpu/armv8/fsl-layerscape/Makefile index 04354d7..e3ce018 100644 --- a/arch/arm/cpu/armv8/fsl-layerscape/Makefile +++ b/arch/arm/cpu/armv8/fsl-layerscape/Makefile @@ -26,7 +26,7 @@ ifneq ($(CONFIG_ARCH_LS2080A),) obj-$(CONFIG_SYS_HAS_SERDES) += ls2080a_serdes.o endif -ifneq ($(CONFIG_LS1043A),) +ifneq ($(CONFIG_ARCH_LS1043A),) obj-$(CONFIG_SYS_HAS_SERDES) += ls1043a_serdes.o obj-$(CONFIG_ARMV8_PSCI) += ls1043a_psci.o endif diff --git a/arch/arm/include/asm/arch-fsl-layerscape/config.h b/arch/arm/include/asm/arch-fsl-layerscape/config.h index 898bd84..e1c01cd 100644 --- a/arch/arm/include/asm/arch-fsl-layerscape/config.h +++ b/arch/arm/include/asm/arch-fsl-layerscape/config.h @@ -132,7 +132,7 @@ #define CONFIG_SYS_FSL_PEX_LUT_BE /* SoC related */ -#ifdef CONFIG_LS1043A +#ifdef CONFIG_ARCH_LS1043A #define CONFIG_SYS_FMAN_V3 #define CONFIG_SYS_NUM_FMAN1 #define CONFIG_SYS_NUM_FM1_DTSEC 7 diff --git a/arch/arm/include/asm/fsl_secure_boot.h b/arch/arm/include/asm/fsl_secure_boot.h index 6a21396..479696b 100644 --- a/arch/arm/include/asm/fsl_secure_boot.h +++ b/arch/arm/include/asm/fsl_secure_boot.h @@ -46,7 +46,7 @@ #endif -#if defined(CONFIG_LS1043A) || defined(CONFIG_ARCH_LS2080A) +#if defined(CONFIG_ARCH_LS1043A) || defined(CONFIG_ARCH_LS2080A) /* For LS1043 (ARMv8), ESBC image Address in Header is 64 bit * Similiarly for LS2080 */ @@ -110,7 +110,7 @@ #ifdef CONFIG_FSL_LS_PPA #ifdef CONFIG_SYS_LS_PPA_FW_IN_XIP -#ifdef CONFIG_LS1043A +#ifdef CONFIG_ARCH_LS1043A #define CONFIG_SYS_LS_PPA_ESBC_ADDR0x600c #elif defined(CONFIG_FSL_LSCH3) #define CONFIG_SYS_LS_PPA_ESBC_ADDR 0x580c4 diff --git a/drivers/net/fm/Makefile b/drivers/net/fm/Makefile index fa96bad..fc7a6da 100644 --- a/drivers/net/fm/Makefile +++ b/drivers/net/fm/Makefile @@ -34,5 +34,5 @@ obj-$(CONFIG_ARCH_T4240) += t4240.o obj-$(CONFIG_ARCH_T4160) += t4240.o obj-$(CONFIG_ARCH_B4420) += b4860.o obj-$(CONFIG_ARCH_B4860) += b4860.o -obj-$(CONFIG_LS1043A) += ls1043.o +obj-$(CONFIG_ARCH_LS1043A) += ls1043.o obj-$(CONFIG_ARCH_LS1046A) += ls1046.o diff --git a/include/configs/ls1043a_common.h b/include/configs/ls1043a_common.h index 46d54a0..9f93fb3 100644 --- a/include/configs/ls1043a_common.h +++ b/include/configs/ls1043a_common.h @@ -9,7 +9,6 @@ #define CONFIG_REMAKE_ELF #define CONFIG_FSL_LAYERSCAPE -#define CONFIG_LS1043A #define CONFIG_MP #define CONFIG_GICV2 diff --git a/include/linux/usb/xhci-fsl.h b/include/linux/usb/xhci-fsl.h index 23e5939..e0dff30 100644 --- a/include/linux/usb/xhci-fsl.h +++ b/include/linux/usb/xhci-fsl.h @@ -62,7 +62,7 @@ struct fsl_xhci { #define CONFIG_SYS_FSL_XHCI_USB1_ADDR CONFIG_SYS_XHCI_USB1_ADDR #define CONFIG_SYS_FSL_XHCI_USB2_ADDR CONFIG_SYS_XHCI_USB2_ADDR #define CONFIG_SYS_FSL_XHCI_USB3_ADDR 0 -#elif defined(CONFIG_LS1043A) || defined(CONFIG_ARCH_LS1046A) +#elif defined(CONFIG_ARCH_LS1043A) || defined(CONFIG_ARCH_LS1046A) #define CONFIG_SYS_FSL_XHCI_USB1_ADDR CONFIG_SYS_XHCI_USB1_ADDR #define CONFIG_SYS_FSL_XHCI_USB2_ADDR CONFIG_SYS_XHCI_USB2_ADDR #define CONFIG_SYS_FSL_XHCI_USB3_ADDR CONFIG_SYS_XHCI_USB3_ADDR diff --git a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt index 0f39c65..55bdaa0 100644 --- a/scripts/config_whitelist.txt +++ b/scripts/config_whitelist.txt @@ -1808,7 +1808,6 @@ CONFIG_LQ035Q1_USE_RGB888_8_BIT_PPI CONFIG_LQ038J7DH53 CONFIG_LS102XA CONFIG_LS102XA_STREAM_ID -CONFIG_LS1043A CONFIG_LSCHLV2 CONFIG_LSXHL CONFIG_LUAN -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/3] armv8: ls2080a: Drop macro CONFIG_LS2080A
Use CONFIG_ARCH_LS2080A instead. Signed-off-by: York Sun --- arch/arm/cpu/armv8/fsl-layerscape/Makefile| 2 +- arch/arm/cpu/armv8/fsl-layerscape/cpu.c | 6 +++--- arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S | 2 +- arch/arm/cpu/armv8/fsl-layerscape/spl.c | 2 +- arch/arm/include/asm/arch-fsl-layerscape/config.h | 2 +- arch/arm/include/asm/arch-fsl-layerscape/cpu.h| 2 +- arch/arm/include/asm/arch-fsl-layerscape/fsl_serdes.h | 2 +- arch/arm/include/asm/fsl_secure_boot.h| 4 ++-- configs/ls2080a_emu_defconfig | 2 +- configs/ls2080a_simu_defconfig| 2 +- configs/ls2080aqds_SECURE_BOOT_defconfig | 1 - configs/ls2080aqds_defconfig | 1 - configs/ls2080aqds_nand_defconfig | 2 +- configs/ls2080aqds_qspi_defconfig | 2 +- configs/ls2080ardb_SECURE_BOOT_defconfig | 1 - configs/ls2080ardb_defconfig | 1 - configs/ls2080ardb_nand_defconfig | 2 +- drivers/crypto/fsl/jr.c | 2 +- drivers/net/ldpaa_eth/Makefile| 2 +- include/linux/usb/xhci-fsl.h | 2 +- scripts/config_whitelist.txt | 1 - 21 files changed, 19 insertions(+), 24 deletions(-) diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Makefile b/arch/arm/cpu/armv8/fsl-layerscape/Makefile index c9ab93e..04354d7 100644 --- a/arch/arm/cpu/armv8/fsl-layerscape/Makefile +++ b/arch/arm/cpu/armv8/fsl-layerscape/Makefile @@ -22,7 +22,7 @@ obj-$(CONFIG_SYS_HAS_SERDES) += fsl_lsch2_serdes.o endif endif -ifneq ($(CONFIG_LS2080A),) +ifneq ($(CONFIG_ARCH_LS2080A),) obj-$(CONFIG_SYS_HAS_SERDES) += ls2080a_serdes.o endif diff --git a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c index cebbb0f..606403a 100644 --- a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c +++ b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c @@ -91,7 +91,7 @@ static inline void early_mmu_setup(void) static void fix_pcie_mmu_map(void) { -#ifdef CONFIG_LS2080A +#ifdef CONFIG_ARCH_LS2080A unsigned int i; u32 svr, ver; struct ccsr_gur __iomem *gur = (void *)(CONFIG_SYS_FSL_GUTS_ADDR); @@ -522,7 +522,7 @@ int timer_init(void) #ifdef CONFIG_FSL_LSCH3 u32 __iomem *cltbenr = (u32 *)CONFIG_SYS_FSL_PMU_CLTBENR; #endif -#ifdef CONFIG_LS2080A +#ifdef CONFIG_ARCH_LS2080A u32 __iomem *pctbenr = (u32 *)FSL_PMU_PCTBENR_OFFSET; u32 svr_dev_id; #endif @@ -540,7 +540,7 @@ int timer_init(void) out_le32(cltbenr, 0xf); #endif -#ifdef CONFIG_LS2080A +#ifdef CONFIG_ARCH_LS2080A /* * In certain Layerscape SoCs, the clock for each core's * has an enable bit in the PMU Physical Core Time Base Enable diff --git a/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S b/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S index a2185f2..fa6b6e6 100644 --- a/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S +++ b/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S @@ -76,7 +76,7 @@ ENTRY(lowlevel_init) #ifdef CONFIG_FSL_LSCH3 /* Set Wuo bit for RN-I 20 */ -#ifdef CONFIG_LS2080A +#ifdef CONFIG_ARCH_LS2080A ldr x0, =CCI_AUX_CONTROL_BASE(20) ldr x1, =0x0010 bl ccn504_set_aux diff --git a/arch/arm/cpu/armv8/fsl-layerscape/spl.c b/arch/arm/cpu/armv8/fsl-layerscape/spl.c index 73a8680..2434860 100644 --- a/arch/arm/cpu/armv8/fsl-layerscape/spl.c +++ b/arch/arm/cpu/armv8/fsl-layerscape/spl.c @@ -47,7 +47,7 @@ void board_init_f(ulong dummy) memset((void *)gd, 0, sizeof(gd_t)); board_early_init_f(); timer_init(); -#ifdef CONFIG_LS2080A +#ifdef CONFIG_ARCH_LS2080A env_init(); #endif get_clocks(); diff --git a/arch/arm/include/asm/arch-fsl-layerscape/config.h b/arch/arm/include/asm/arch-fsl-layerscape/config.h index b5b08aa..898bd84 100644 --- a/arch/arm/include/asm/arch-fsl-layerscape/config.h +++ b/arch/arm/include/asm/arch-fsl-layerscape/config.h @@ -18,7 +18,7 @@ */ #define CONFIG_SYS_MEM_RESERVE_SECURE (2048 * 1024) /* 2MB */ -#ifdef CONFIG_LS2080A +#ifdef CONFIG_ARCH_LS2080A #define CONFIG_SYS_FSL_CLUSTER_CLOCKS { 1, 1, 4, 4 } #defineSRDS_MAX_LANES 8 #define CONFIG_SYS_PAGE_SIZE 0x1 diff --git a/arch/arm/include/asm/arch-fsl-layerscape/cpu.h b/arch/arm/include/asm/arch-fsl-layerscape/cpu.h index bcf3e38..95c3e2f 100644 --- a/arch/arm/include/asm/arch-fsl-layerscape/cpu.h +++ b/arch/arm/include/asm/arch-fsl-layerscape/cpu.h @@ -249,7 +249,7 @@ static struct mm_region final_map[] = { PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) | PTE_BLOCK_NON_SHARE | PTE_BLOCK_PXN | PTE_BLOCK_UXN }, -#ifdef CONFIG_LS2080A +#ifdef CONFIG_ARCH_LS2080A { CONFIG_SYS_PCIE4_PHYS_ADDR, CONFIG_SYS_PCIE4_PHYS_ADDR, CONFIG_SYS_PCIE4_PHYS
[U-Boot] [PATCH 3/3] armv7: ls1021a: Drop macro CONFIG_LS102XA
Use CONFIG_ARCH_LS1021A instead. Signed-off-by: York Sun --- arch/arm/cpu/armv7/Makefile | 2 +- arch/arm/dts/Makefile | 2 +- arch/arm/include/asm/arch-ls102xa/config.h | 2 +- arch/arm/include/asm/config.h | 2 +- board/freescale/common/arm_sleep.c | 6 +++--- board/freescale/common/fsl_chain_of_trust.c | 2 +- board/freescale/common/fsl_validate.c | 2 +- drivers/i2c/mxc_i2c.c | 2 +- drivers/qe/qe.c | 6 +++--- drivers/usb/common/fsl-errata.c | 2 +- include/configs/ls1021aiot.h| 2 -- include/configs/ls1021aqds.h| 2 -- include/configs/ls1021atwr.h| 2 -- include/fsl_errata.h| 4 ++-- include/linux/immap_qe.h| 2 +- include/linux/usb/xhci-fsl.h| 2 +- include/tsec.h | 2 +- include/usb/ehci-ci.h | 2 +- scripts/config_whitelist.txt| 1 - 19 files changed, 20 insertions(+), 27 deletions(-) diff --git a/arch/arm/cpu/armv7/Makefile b/arch/arm/cpu/armv7/Makefile index 02e8778..da491d4 100644 --- a/arch/arm/cpu/armv7/Makefile +++ b/arch/arm/cpu/armv7/Makefile @@ -12,7 +12,7 @@ obj-y += cache_v7.o cache_v7_asm.o obj-y += cpu.o cp15.o obj-y += syslib.o -ifneq ($(CONFIG_AM43XX)$(CONFIG_AM33XX)$(CONFIG_OMAP44XX)$(CONFIG_OMAP54XX)$(CONFIG_TEGRA)$(CONFIG_MX6)$(CONFIG_MX7)$(CONFIG_TI81XX)$(CONFIG_AT91FAMILY)$(CONFIG_ARCH_SUNXI)$(CONFIG_ARCH_SOCFPGA)$(CONFIG_ARCH_MX7ULP)$(CONFIG_LS102XA),) +ifneq ($(CONFIG_AM43XX)$(CONFIG_AM33XX)$(CONFIG_OMAP44XX)$(CONFIG_OMAP54XX)$(CONFIG_TEGRA)$(CONFIG_MX6)$(CONFIG_MX7)$(CONFIG_TI81XX)$(CONFIG_AT91FAMILY)$(CONFIG_ARCH_SUNXI)$(CONFIG_ARCH_SOCFPGA)$(CONFIG_ARCH_MX7ULP)$(CONFIG_ARCH_LS102XA),) ifneq ($(CONFIG_SKIP_LOWLEVEL_INIT),y) obj-y += lowlevel_init.o endif diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile index 0fbbb9b..6f18fd2 100644 --- a/arch/arm/dts/Makefile +++ b/arch/arm/dts/Makefile @@ -162,7 +162,7 @@ dtb-$(CONFIG_TARGET_AM57XX_EVM) += am57xx-beagle-x15.dtb \ am571x-idk.dtb dtb-$(CONFIG_TARGET_STV0991) += stv0991.dtb -dtb-$(CONFIG_LS102XA) += ls1021a-qds-duart.dtb \ +dtb-$(CONFIG_ARCH_LS1021A) += ls1021a-qds-duart.dtb \ ls1021a-qds-lpuart.dtb \ ls1021a-twr-duart.dtb ls1021a-twr-lpuart.dtb \ ls1021a-iot-duart.dtb diff --git a/arch/arm/include/asm/arch-ls102xa/config.h b/arch/arm/include/asm/arch-ls102xa/config.h index 2f7233f..5c4da0f 100644 --- a/arch/arm/include/asm/arch-ls102xa/config.h +++ b/arch/arm/include/asm/arch-ls102xa/config.h @@ -108,7 +108,7 @@ #define DCU_LAYER_MAX_NUM 16 -#ifdef CONFIG_LS102XA +#ifdef CONFIG_ARCH_LS1021A #define CONFIG_USB_MAX_CONTROLLER_COUNT1 #define CONFIG_SYS_FSL_MAX_NUM_OF_SEC 1 #else diff --git a/arch/arm/include/asm/config.h b/arch/arm/include/asm/config.h index 1ad221a..5674d37 100644 --- a/arch/arm/include/asm/config.h +++ b/arch/arm/include/asm/config.h @@ -14,7 +14,7 @@ #define CONFIG_STATIC_RELA #endif -#if defined(CONFIG_LS102XA) || \ +#if defined(CONFIG_ARCH_LS1021A) || \ defined(CONFIG_CPU_PXA27X) || \ defined(CONFIG_CPU_MONAHANS) || \ defined(CONFIG_CPU_PXA25X) || \ diff --git a/board/freescale/common/arm_sleep.c b/board/freescale/common/arm_sleep.c index 16fd445..6ed5d9e 100644 --- a/board/freescale/common/arm_sleep.c +++ b/board/freescale/common/arm_sleep.c @@ -13,7 +13,7 @@ #endif #include -#if defined(CONFIG_LS102XA) +#if defined(CONFIG_ARCH_LS1021A) #include #endif @@ -66,7 +66,7 @@ static void dp_ddr_restore(void) *dst++ = *src++; } -#if defined(CONFIG_ARMV7_PSCI) && defined(CONFIG_LS102XA) +#if defined(CONFIG_ARMV7_PSCI) && defined(CONFIG_ARCH_LS1021A) void ls1_psci_resume_fixup(void) { u32 tmp; @@ -104,7 +104,7 @@ static void dp_resume_prepare(void) #ifdef CONFIG_U_QE u_qe_resume(); #endif -#if defined(CONFIG_ARMV7_PSCI) && defined(CONFIG_LS102XA) +#if defined(CONFIG_ARMV7_PSCI) && defined(CONFIG_ARCH_LS1021A) ls1_psci_resume_fixup(); #endif } diff --git a/board/freescale/common/fsl_chain_of_trust.c b/board/freescale/common/fsl_chain_of_trust.c index 438e781..aad1b93 100644 --- a/board/freescale/common/fsl_chain_of_trust.c +++ b/board/freescale/common/fsl_chain_of_trust.c @@ -22,7 +22,7 @@ #include #endif -#ifdef CONFIG_LS102XA +#ifdef CONFIG_ARCH_LS1021A #include #endif diff --git a/board/freescale/common/fsl_validate.c b/board/freescale/common/fsl_validate.c index 7396aa2..d814b66 100644 --- a/board/freescale/common/fsl_validate.c +++ b/board/freescale/common/fsl_validate.c @@ -15,7 +15,7 @@ #include #include #include -#ifdef CONFIG_LS102XA +#ifdef CONFIG_ARCH_LS1021A #include #endif diff --git a/drivers/i2c/mxc_i2c.c b/drivers/i2c/mxc_i2c.c index eb789f5..13ec0e6 100644 --- a/drivers/i2c/m
[U-Boot] U-Boot Application that can access all files on USB
I just started learning about U-Boot and being able to write applications that can be run with U-Boot, so please be patient and if possible add more details to help me learn. I wanted to ask for help, as I am trying to connect USB flash drive to my Arm Cortex A9 device, which then connects to my laptop via Ethernet. I want to be able to have access to all files on that drive through my U-Boot script. For example My script will just run after U-Boot loads, and my script will parse through all files. Then I'd like to be able to access the files from my host laptop through TFTP commands, but feel will need to write functions that translate TFTP request to a USB read? I plan to use a U-Boot application, so that I have access to all U-Boot drivers. U-boot supports USB, and I am able to see my USB Flash Drive on the U-boot command line. How can this be done, any help is HIGHLY appreciated please. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] sf: Remove spansion_s25fss_disable_4KB_erase
> -Original Message- > From: Jagan Teki [mailto:jagannadh.t...@gmail.com] > Sent: Tuesday, March 28, 2017 1:57 AM > To: york sun > Cc: Jagan Teki ; u-boot@lists.denx.de; Mingkai Hu > > Subject: Re: [U-Boot] sf: Remove spansion_s25fss_disable_4KB_erase > > On Mon, Mar 27, 2017 at 11:05 PM, york sun wrote: > > On 03/15/2017 06:44 PM, york@nxp.com wrote: > >> On 01/27/2017 10:04 AM, Jagan Teki wrote: > >>> On Mon, Jan 23, 2017 at 8:05 PM, york sun wrote: > On 12/12/2016 09:32 PM, Yao Yuan wrote: > > Hi Jagan, > > > > > > > > Do you have any comments? > > > > > > > > Thanks for your work and you know it’s important for QSPI with > > S25FS512S. > > > > > > > > It seems S25FS512S can’t support the SECT_4K, right? > > > > And it better to retain the disable_4kb, but we can add a flag in > > dts to select whether enable it. > > > > > > Jagan, > > This is blocking me from using the board with this specific flash chip. > Can you take a look? By reverting this single commit 116e005c, my > board works again. > >>> > >>> I will try to work on this. > >>> > >> > >> Guys, > >> > >> Where are we on this issue? > >> > >> York > >> > > > > Can we revert this patch or have a fix? > > Just wanted to understand more about this, I've attached programming > model in previous mail about this and based on that I've fixed with all 4K. > Waiting for 'Yao Yuan' inputs on this. > +Suresh to follow up this question. Thanks, Mingkai ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 02/16] board_f: Drop return value from initdram()
On 03/31/2017 07:40 AM, Simon Glass wrote: > At present we cannot use this function as an init sequence call without a > wrapper, since it returns the RAM size. Adjust it to set the RAM size in > global_data instead, and return 0 on success. > > Signed-off-by: Simon Glass > --- > This is a _lot_ of changes. Reviewed-by: York Sun ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 03/16] board_f: Rename initdram() to dram_init()
On 03/31/2017 07:40 AM, Simon Glass wrote: > This allows us to use the same DRAM init function on all archs. > > Signed-off-by: Simon Glass > --- > Reviewed-by: York Sun ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 01/16] board_f: Drop board_type parameter from initdram()
On 03/31/2017 07:40 AM, Simon Glass wrote: > It looks like only cm5200 and tqm8xx use this feature, so we don't really > need it in generic code. Drop it and have the users access gd->board_type > directly. > > Signed-off-by: Simon Glass > --- Reviewed-by: York Sun ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v5 1/3] arm: tegra: initial support for apalis tk1
From: Marcel Ziswiler This patch adds board support for the Toradex Apalis TK1 a computer on module which can be used on different carrier boards. The module consists of a Tegra TK1 SoC, a PMIC solution, 2 GB of DDR3L RAM, a bunch of level shifters, an eMMC, a TMP451 temperature sensor chip, an I210 gigabit Ethernet controller and a SGTL5000 audio codec. Furthermore, there is a Kinetis MK20DN512 companion micro controller for analogue, CAN and resistive touch functionality. For the sake of ease of use we do not distinguish between different carrier boards for now as the base module features are deemed sufficient enough for regular booting. The following functionality is working so far: - eMMC boot, environment storage and Toradex factory config block - Gigabit Ethernet - MMC/SD cards (both MMC1 as well as SD1 slot) - USB client/host (dual role OTG port as client e.g. for DFU/UMS or host, other two ports as host) Signed-off-by: Marcel Ziswiler Reviewed-by: Simon Glass Signed-off-by: Marcel Ziswiler --- Changes in v5: - Re-enabled EFI loader support after discussion with Alexander. Changes in v4: - Re-based. - Drop patches 2 and 3: mmc: tegra: move CONFIG_TEGRA_MMC from headers to defconfigs mmc: tegra: introduce CONFIG_TEGRA_MMC to Kconfig in favor of commit 1d2c0506d31a9997e5ffc22e90942902f673b107 mmc: move more driver config options to Kconfig from Masahiro. - Meld patch 6 apalis-tk1: clean-up defconfig into first one. - Add distro boot fallback. - Enable FIT and device tree overlay support. - Explicitly drop EFI loader support. Changes in v3: - Changes involved now dropped patches. Changes in v2: - Added Simon's reviewed-by. arch/arm/dts/Makefile |1 + arch/arm/dts/tegra124-apalis.dts | 2203 arch/arm/mach-tegra/tegra124/Kconfig |7 + board/toradex/apalis-tk1/Kconfig | 30 + board/toradex/apalis-tk1/MAINTAINERS |7 + board/toradex/apalis-tk1/Makefile |5 + board/toradex/apalis-tk1/apalis-tk1.c | 175 ++ board/toradex/apalis-tk1/as3722_init.c | 117 ++ board/toradex/apalis-tk1/as3722_init.h | 41 + .../toradex/apalis-tk1/pinmux-config-apalis-tk1.h | 287 +++ configs/apalis-tk1_defconfig | 46 + include/configs/apalis-tk1.h | 176 ++ 12 files changed, 3095 insertions(+) create mode 100644 arch/arm/dts/tegra124-apalis.dts create mode 100644 board/toradex/apalis-tk1/Kconfig create mode 100644 board/toradex/apalis-tk1/MAINTAINERS create mode 100644 board/toradex/apalis-tk1/Makefile create mode 100644 board/toradex/apalis-tk1/apalis-tk1.c create mode 100644 board/toradex/apalis-tk1/as3722_init.c create mode 100644 board/toradex/apalis-tk1/as3722_init.h create mode 100644 board/toradex/apalis-tk1/pinmux-config-apalis-tk1.h create mode 100644 configs/apalis-tk1_defconfig create mode 100644 include/configs/apalis-tk1.h diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile index afeb43f..fa67c77 100644 --- a/arch/arm/dts/Makefile +++ b/arch/arm/dts/Makefile @@ -58,6 +58,7 @@ dtb-$(CONFIG_TEGRA) += tegra20-harmony.dtb \ tegra30-colibri.dtb \ tegra30-tec-ng.dtb \ tegra114-dalmore.dtb \ + tegra124-apalis.dtb \ tegra124-jetson-tk1.dtb \ tegra124-nyan-big.dtb \ tegra124-cei-tk1-som.dtb \ diff --git a/arch/arm/dts/tegra124-apalis.dts b/arch/arm/dts/tegra124-apalis.dts new file mode 100644 index 000..3853a28 --- /dev/null +++ b/arch/arm/dts/tegra124-apalis.dts @@ -0,0 +1,2203 @@ +/* + * Copyright 2016 Toradex AG + * + * This file is dual-licensed: you can use it either under the terms + * of the GPL or the X11 license, at your option. Note that this dual + * licensing only applies to this file, and not this project as a + * whole. + * + * a) This file is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * version 2 as published by the Free Software Foundation. + * + * This file is distributed in the hope that it will be useful + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * Or, alternatively + * + * b) Permission is hereby granted, free of charge, to any person + * obtaining a copy of this software and associated documentation + * files (the "Software"), to deal in the Software without + * restriction, including without limitation the rights to use + * copy, modify, merge, publish, distribute, sublicense, and/or + * sell copies of the Software, and to permit persons to whom the + * Software is furnished to do so, subject to the following + * conditions: + * + * The above copyright notice and this permission notice sha
Re: [U-Boot] [PATCHV2] tools: plbimage support generate rcw file
> -Original Message- > From: york sun [mailto:york@nxp.com] > Sent: Monday, March 27, 2017 2:44 AM > To: yuan linyu; u-boot@lists.denx.de > Cc: YUAN Linyu > Subject: Re: [PATCHV2] tools: plbimage support generate rcw file > > > Only minor cosmetic issues. I will fix them for you this time if no > issue found during further testing. > thanks. > York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/6] led: add get_status support for DM LED support
From: Ziping Chen Sometimes we need to read back the status of a LED. Add a led_get_status function for DM LED support, and add a get_status function for the driver to implement this function. Signed-off-by: Ziping Chen --- drivers/led/led-uclass.c | 10 ++ include/led.h| 15 +++ 2 files changed, 25 insertions(+) diff --git a/drivers/led/led-uclass.c b/drivers/led/led-uclass.c index 784ac87..304b92a 100644 --- a/drivers/led/led-uclass.c +++ b/drivers/led/led-uclass.c @@ -42,6 +42,16 @@ int led_set_on(struct udevice *dev, int on) return ops->set_on(dev, on); } +int led_get_status(struct udevice *dev) +{ + struct led_ops *ops = led_get_ops(dev); + + if (!ops->get_status) + return -ENOSYS; + + return ops->get_status(dev); +} + UCLASS_DRIVER(led) = { .id = UCLASS_LED, .name = "led", diff --git a/include/led.h b/include/led.h index b929d0c..cd6fe98 100644 --- a/include/led.h +++ b/include/led.h @@ -26,6 +26,13 @@ struct led_ops { * @return 0 if OK, -ve on error */ int (*set_on)(struct udevice *dev, int on); + /** +* led_get_status() - get the state of an LED +* +* @dev:LED device to query +* @return 0 if LED off, 1 if LED on, -ve on error +*/ + int (*get_status)(struct udevice *dev); }; #define led_get_ops(dev) ((struct led_ops *)(dev)->driver->ops) @@ -48,4 +55,12 @@ int led_get_by_label(const char *label, struct udevice **devp); */ int led_set_on(struct udevice *dev, int on); +/** + * led_get_status() - get the state of an LED + * + * @dev: LED device to query + * @return 0 if LED off, 1 if LED on, -ve on error + */ +int led_get_status(struct udevice *dev); + #endif -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] regression: setting the rpi mac address stopped working
Hi, u-boot 2016.11 & newer doesn't set the mac address on my raspberry pi any more, so the linux kernel picks a random mac address. Bisected to this commit: commit b91c6a1209e7da1a7f989d9ac35d0d8be0b7b710 Author: Simon Glass Date: Wed Oct 5 20:42:11 2016 -0600 Fix return value in trailing_strtoln() This function should return -1 if there is no trailing integer in the string. Instead it returns 0. Fix it by checking for this condition at the start. Signed-off-by: Simon Glass Reviewed-by: Bin Meng Appearently this change broke fdt_fixup_ethernet(). cheers, Gerd ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 11/17] aspeed: Add I2C Driver
On Wed, 2017-03-22 at 07:05 -0600, Simon Glass wrote: > On 16 March 2017 at 15:36, Maxim Sloyko wrote: > > Add Device Model based I2C driver for ast2500/ast2400 SoCs. > > The driver is very limited, it only supports master mode and > > synchronous byte-by-byte reads/writes, no DMA or Pool Buffers. > > > > Signed-off-by: Maxim Sloyko > > --- Ah interesting, I was just rewriting that driver last week ... I'll review yours ASAP. > > drivers/i2c/Kconfig | 9 ++ > > drivers/i2c/Makefile | 1 + > > drivers/i2c/ast_i2c.c | 355 > > ++ > > drivers/i2c/ast_i2c.h | 132 +++ > > 4 files changed, 497 insertions(+) > > create mode 100644 drivers/i2c/ast_i2c.c > > create mode 100644 drivers/i2c/ast_i2c.h > > Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/6] led: gpio: add support for get_status function
From: Ziping Chen The status of a GPIO-connected LED can be read back by reading the GPO value. Add the support for get_status function in led_gpio driver. Signed-off-by: Ziping Chen --- drivers/led/led_gpio.c | 11 +++ 1 file changed, 11 insertions(+) diff --git a/drivers/led/led_gpio.c b/drivers/led/led_gpio.c index 5b11990..b64721e 100644 --- a/drivers/led/led_gpio.c +++ b/drivers/led/led_gpio.c @@ -28,6 +28,16 @@ static int gpio_led_set_on(struct udevice *dev, int on) return dm_gpio_set_value(&priv->gpio, on); } +static int gpio_led_get_status(struct udevice *dev) +{ + struct led_gpio_priv *priv = dev_get_priv(dev); + + if (!dm_gpio_is_valid(&priv->gpio)) + return -EREMOTEIO; + + return dm_gpio_get_value(&priv->gpio); +} + static int led_gpio_probe(struct udevice *dev) { struct led_uclass_plat *uc_plat = dev_get_uclass_platdata(dev); @@ -88,6 +98,7 @@ static int led_gpio_bind(struct udevice *parent) static const struct led_ops gpio_led_ops = { .set_on = gpio_led_set_on, + .get_status = gpio_led_get_status, }; static const struct udevice_id led_gpio_ids[] = { -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] fatls returncode
Dear Wolfgang. 2017-03-23 16:13 GMT+01:00 Wolfgang Denk : > Dear Mirza, > > In message > you > wrote: >> >> I am running U-boot 2015.04 and experiencing some issues with "fatls" >> command. > ... >> Normally "fatls" returns "0" when it does a successful list. But we >> have found a case where it does not even though everything seems to >> work fine. Below is a log with debug enabled (obfuscated filenames >> since I got this flash drive from a customer). > > Please update to a recent versionof the code. The return code > handling has probably been fixed by this commit: > > 0a04ed8 2015-09-11 17:15:21 -0400 FIX: fat: Provide correct return code > from disk_{read|write} to upper layers I did an update (cherry-picked FAT related commits from upstream), but I still get the same result. Analyzing the code in fs/fat/fat.c:do_fat_read_at (which is called by the fatls command) one can see that "ret" is set in three locations. In my case I never reach any of these three, since my exit path is: fs/fat/fat.c: 1139 /* If end of rootdir reached */ 1140 if (rootdir_end) { 1141 if (dols == LS_ROOT) { 1142 printf("\n%d file(s), %d dir(s)\n\n", 1143files, dirs); 1144 *size = 0; 1145 } 1146 goto exit; 1147 } So either this exit path is actually an error and it is correct as-is, or this path should set "ret = 0". My knowledge of FAT is limited so I can not really tell which it should be but there is no indications in the code/comments that this exit path is an error. -- Med Vänliga Hälsningar / Best Regards *** Mirza Krak Host Mobility AB mirza.k...@hostmobility.com Anders Personsgatan 12, 416 64 Göteborg Sweden http://www.hostmobility.com Direct: +46 31 31 32 704 Phone: +46 31 31 32 700 Fax: +46 31 80 67 51 Mobile: +46 730 28 06 22 *** ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] Cannot boot without monitor connected.
Hi, I reported this to Olimex, but it seems related to u-boot. I have this board, A20-OLinuXino-MICRO-4GB, running for about 4 years. I use it rarely to build executables in ARM format. Some months ago, I found it down. I tried to boot it without success. Then I connected a monitor to the HDMI port and was able to boot without problems. I updated the system and checked everything was OK but could not boot the board without the monitor connected. I have now connected a serial debug cable to see what happens when the monitor is not connected and got this: § U-Boot SPL 2016.11 (Dec 02 2016 - 16:51:49) DRAM: 1024 MiB CPU: 91200Hz, AXI/AHB/APB: 3/2/2 Trying to boot from MMC1 U-Boot 2016.11 (Dec 02 2016 - 16:51:49 +) Allwinner Technology CPU: Allwinner A20 (SUN7I) Model: Olimex A20-Olinuxino Micro I2C: ready DRAM: 1 GiB MMC: SUNXI SD/MMC: 0, SUNXI SD/MMC: 1 *** Warning - bad CRC, using default environment Setting up a 1024x768 vga console (overscan 0x0) In:serial Out: vga Err: vga SCSI: Target spinup took 0 ms. AHCI 0001.0100 32 slots 1 ports 3 Gbps 0x1 impl SATA mode flags: ncq stag pm led clo only pmp pio slum part ccc apst Net: eth0: ethernet@01c5 starting USB... USB0: ␀ § Does anyone know what's wrong with the board? Thanks. -- João M. S. Silva ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/4] board: advantech: dms-ba16: Add the configuration options for display initialization
Add the configuration options for display initialization in case we need to do the display initialization in kernel to support different timing settings Signed-off-by: Ken Lin --- board/advantech/dms-ba16/dms-ba16.c | 3 +++ include/configs/advantech_dms-ba16.h | 2 ++ 2 files changed, 5 insertions(+) diff --git a/board/advantech/dms-ba16/dms-ba16.c b/board/advantech/dms-ba16/dms-ba16.c index 20750fb0ce..a67752f1ca 100644 --- a/board/advantech/dms-ba16/dms-ba16.c +++ b/board/advantech/dms-ba16/dms-ba16.c @@ -539,6 +539,8 @@ int board_late_init(void) #ifdef CONFIG_CMD_BMODE add_board_boot_modes(board_boot_modes); #endif + +#if defined(CONFIG_VIDEO_IPUV3) /* * We need at least 200ms between power on and backlight on * as per specifications from CHI MEI @@ -555,6 +557,7 @@ int board_late_init(void) gpio_direction_output(LVDS_BACKLIGHT_GP, 1); pwm_enable(0); +#endif #ifdef CONFIG_CMD_SATA setup_ba16_sata(); diff --git a/include/configs/advantech_dms-ba16.h b/include/configs/advantech_dms-ba16.h index 14e9c06fac..53a45b21a4 100644 --- a/include/configs/advantech_dms-ba16.h +++ b/include/configs/advantech_dms-ba16.h @@ -262,6 +262,7 @@ #define CONFIG_SYS_FSL_USDHC_NUM3 /* Framebuffer */ +#ifdef CONFIG_VIDEO #define CONFIG_VIDEO_IPUV3 #define CONFIG_VIDEO_BMP_RLE8 #define CONFIG_SPLASH_SCREEN @@ -272,6 +273,7 @@ #define CONFIG_IPUV3_CLK26000 #define CONFIG_IMX_HDMI #define CONFIG_IMX_VIDEO_SKIP +#endif #define CONFIG_PWM_IMX #define CONFIG_IMX6_PWM_PER_CLK 6600 -- 2.11.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 3/4] board: advantech: dms-ba16: fix AR8033 reset timing issue
Add the delay (10ms) to ensure the clock is stable and to meet the clock-to-reset(1ms) requirement recommended in the AR8033 datasheet Signed-off-by: Ken Lin --- board/advantech/dms-ba16/dms-ba16.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/board/advantech/dms-ba16/dms-ba16.c b/board/advantech/dms-ba16/dms-ba16.c index 8aa7ff1659..75b0bbc2cc 100644 --- a/board/advantech/dms-ba16/dms-ba16.c +++ b/board/advantech/dms-ba16/dms-ba16.c @@ -103,8 +103,9 @@ static void setup_iomux_enet(void) /* Reset AR8033 PHY */ gpio_direction_output(IMX_GPIO_NR(1, 28), 0); - udelay(500); + mdelay(10); gpio_set_value(IMX_GPIO_NR(1, 28), 1); + mdelay(1); } static iomux_v3_cfg_t const usdhc2_pads[] = { -- 2.11.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] armv7: ls1021a: Drop macro CONFIG_LS102XA
> Subject: [PATCH 3/3] armv7: ls1021a: Drop macro CONFIG_LS102XA > > Use CONFIG_ARCH_LS1021A instead. > > Signed-off-by: York Sun > --- > > arch/arm/cpu/armv7/Makefile | 2 +- > arch/arm/dts/Makefile | 2 +- > arch/arm/include/asm/arch-ls102xa/config.h | 2 +- > arch/arm/include/asm/config.h | 2 +- > board/freescale/common/arm_sleep.c | 6 +++--- > board/freescale/common/fsl_chain_of_trust.c | 2 +- > board/freescale/common/fsl_validate.c | 2 +- > drivers/i2c/mxc_i2c.c | 2 +- > drivers/qe/qe.c | 6 +++--- > drivers/usb/common/fsl-errata.c | 2 +- > include/configs/ls1021aiot.h| 2 -- > include/configs/ls1021aqds.h| 2 -- > include/configs/ls1021atwr.h| 2 -- > include/fsl_errata.h| 4 ++-- > include/linux/immap_qe.h| 2 +- > include/linux/usb/xhci-fsl.h| 2 +- > include/tsec.h | 2 +- > include/usb/ehci-ci.h | 2 +- > scripts/config_whitelist.txt| 1 - > 19 files changed, 20 insertions(+), 27 deletions(-) > [Alison Wang] Reviewed-by: Alison Wang Best Regards, Alison Wang ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 3/6] cmd: led: rename command enum value
From: Ziping Chen The "LED_OFF" constant conflicts with the constant with the same name in include/linux/compat.h. Rename all command constants' name prefix from LED_ to LED_CMD_. Signed-off-by: Ziping Chen --- cmd/led.c | 18 +- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/cmd/led.c b/cmd/led.c index 951a5e2..ef0ab1a 100644 --- a/cmd/led.c +++ b/cmd/led.c @@ -62,18 +62,18 @@ static const led_tbl_t led_commands[] = { { NULL, 0, NULL, NULL, NULL } }; -enum led_cmd { LED_ON, LED_OFF, LED_TOGGLE, LED_BLINK }; +enum led_cmd { LED_CMD_ON, LED_CMD_OFF, LED_CMD_TOGGLE, LED_CMD_BLINK }; enum led_cmd get_led_cmd(char *var) { if (strcmp(var, "off") == 0) - return LED_OFF; + return LED_CMD_OFF; if (strcmp(var, "on") == 0) - return LED_ON; + return LED_CMD_ON; if (strcmp(var, "toggle") == 0) - return LED_TOGGLE; + return LED_CMD_TOGGLE; if (strcmp(var, "blink") == 0) - return LED_BLINK; + return LED_CMD_BLINK; return -1; } @@ -106,27 +106,27 @@ int do_led (cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) (strcmp(led_commands[i].string, argv[1]) == 0)) { match = 1; switch (cmd) { - case LED_ON: + case LED_CMD_ON: if (led_commands[i].on) led_commands[i].on(); else __led_set(led_commands[i].mask, CONFIG_LED_STATUS_ON); break; - case LED_OFF: + case LED_CMD_OFF: if (led_commands[i].off) led_commands[i].off(); else __led_set(led_commands[i].mask, CONFIG_LED_STATUS_OFF); break; - case LED_TOGGLE: + case LED_CMD_TOGGLE: if (led_commands[i].toggle) led_commands[i].toggle(); else __led_toggle(led_commands[i].mask); break; - case LED_BLINK: + case LED_CMD_BLINK: if (argc != 4) return CMD_RET_USAGE; -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 6/6] cmd: led: add command led list
From: Ziping Chen Add command "led list" to list all led(s) can be operated. Signed-off-by: Ziping Chen --- cmd/led.c | 27 ++- 1 file changed, 26 insertions(+), 1 deletion(-) diff --git a/cmd/led.c b/cmd/led.c index 3849a79..3f70666 100644 --- a/cmd/led.c +++ b/cmd/led.c @@ -230,6 +230,30 @@ int do_led (cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) } if (error_count != 0) return CMD_RET_FAILURE; + } else if (strcmp("list", argv[1]) == 0) { + int node, len; + match = 1; + node = fdt_path_offset(gd->fdt_blob, "/leds"); + if (node < 0) { + printf("led: null led found\n"); + return CMD_RET_FAILURE; + } + node = fdt_first_subnode(gd->fdt_blob, node); + if (node < 0) { + printf("led: null led found\n"); + return CMD_RET_FAILURE; + } + printf(" led_name\n"); + printf("\n"); + printf(" %s\n", fdt_getprop(gd->fdt_blob, node, + "label", &len)); + while (1) { + node = fdt_next_subnode(gd->fdt_blob, node); + if (node < 0) + break; + printf(" %s\n", fdt_getprop(gd->fdt_blob, node, + "label", &len)); + } } else if (argc > 2) { match = 1; if (dm_led_set(argv[1], cmd) < 0) @@ -287,6 +311,7 @@ U_BOOT_CMD( U_BOOT_CMD( led, 4, 1, do_led, "operate led(s)", - "[all|led_name] [on|off|toggle] - sets or clears led(s)" + "[all|led_name] [on|off|toggle] - sets or clears led(s)\n" + "led list - list all led(s) can be operated" ); #endif -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [linux-sunxi] [PATCH 06/17] tools: mksunxiboot: allow larger SPL binaries
Hey Andre, On 01-03-17 03:25, Andre Przywara wrote: mksunxiboot limits the size of the resulting SPL binaries to pretty conservative values to cover all SoCs and all boot media (NAND). It turns out that we have limit checks in place in the build process, so mksunxiboot can be relaxed and allow packaging binaries up to the actual 32KB the mask boot ROM actually imposes. This allows to have a bigger SPL, which is crucial for AArch64 builds. Signed-off-by: Andre Przywara --- tools/mksunxiboot.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/mksunxiboot.c b/tools/mksunxiboot.c index 0f0b003..6bb649c 100644 --- a/tools/mksunxiboot.c +++ b/tools/mksunxiboot.c @@ -48,7 +48,7 @@ int gen_check_sum(struct boot_file_head *head_p) #define ALIGN(x, a) __ALIGN_MASK((x), (typeof(x))(a)-1) #define __ALIGN_MASK(x, mask) (((x)+(mask))&~(mask)) -#define SUN4I_SRAM_SIZE 0x7600 /* 0x7748+ is used by BROM */ +#define SUN4I_SRAM_SIZE 0x8000 /* SoC with smaller size are limited before */ This seems a little scary, but besides that, you need to rename the define to SUNXI imo too then. SUN4I, SUN5I and SUN7I (I think) all have the 24K limit imposed by the BROM. Only the later gens have a 32k limit. Since it is nice to have a single binary for all, name the define as SUNXI too I think. As a comment, I would put the responsibility elsewhere (instead of making it an assumption). With that said, why do we have to check it at all then, other then to give a warning? The size is limited before already, right? Olliver #define SRAM_LOAD_MAX_SIZE (SUN4I_SRAM_SIZE - sizeof(struct boot_file_head)) /* ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Please separated FMan from generate NET config
> > -Original Message- > From: york sun > Sent: Wednesday, March 22, 2017 3:13 AM > To: Mingkai Hu > Cc: Prabhakar Kushwaha ; u- > b...@lists.denx.de > Subject: Please separated FMan from generate NET config > > Mingkai, > > I noticed during recent debug on LS1043ARDB and LS1046ARDB that the > general network feature is combined with DPAA FMan. This is not correct. > The fix is easy. You only need to change the Makefile in board folder to build > eth.o with $(CONFIG_NET) instead of $(CONFIG_SYS_DPAA_FMAN). You > also need to adjust the board config header file to select PHY config with > generate net option vs FMan specific ones. > > Please send patches to fix them. > Sure, will send the patch out to fix it. Thanks, Mingkai ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] spl: add support to booting with ATF
Hi Kever > -Original Message- > From: Kever Yang [mailto:kever.y...@rock-chips.com] > Sent: 28 March 2017 08:23 > > Hi Andre, > > > On 03/23/2017 05:22 PM, Andre Przywara wrote: > > Hi Kever, > > > > I was wondering if we really need to copy in all those ATF definitions. > > I think this is really an *interface* between the loader (SPL or BL2) > > and the runtime services (BL31), so it's supposed to be stable and we > > wouldn't need to pull in all those headers. > > Yes, you are right, this is an interface between the loader and bl31, > and it's from ATF, just like android image header if from Android > project, so my idea copy the header definition. > > > > So given that, can't we simply model the data structure, which at the > > end of the day is just a bunch of simple data types: > > I'm sorry, I don't get your point here, what's the benefit for us to re- > define the header data types? > > I guess Andre's point was to copy just the essential data structures, not all the other baggage in that header file. ... > > > > Whenever this gets changed we are in trouble anyway (because we break > > compatibility). > > Yes, we hope it won't change, but it depends on ATF not U-Boot, no > matter what kind if data type we using in U-Boot, we can not stop this, > it's the ATF break the compatibility, not U-Boot SPL. > > > > So what are the opinions on this? Pull in the ATF source or define our > > own and mark it as an ATF copy? > > ATF is the one using all these header structure, if they change there > API and break, yes, we need/have to sync again. > > Dan in CC is ATF maintainer. > > Hi Dan, are you able to provide some information for the header > structure, for example, is it suppose to change/update in the future? > The ARM TF BL31 interface is defined here: https://github.com/ARM-software/arm-trusted-firmware/blob/master/docs/firmware-design.md#required-cpu-state-when-calling-bl31_entrypoint-during-cold-boot In summary, the arguments passed to BL31 in X0 and X1 are platform specific and not used by generic BL31 code. Conventionally, X0 has been used by TF BL2 to pass a bl31_params structure, which is used by ARM Limited platforms and possibly others but not necessarily all. This structure has now been superseded by a new structure called bl_params, which caters for AArch32 platforms and should be more futureproof. Both bl31_params and bl_params are prefixed with metadata in a param_header, which includes a version number. BL31 platform code could potentially handle both bl31_params and bl_params by checking the version number but ARM platforms expect one or the other depending on the value of a build flag (LOAD_IMAGE_V2). It's hard to say what other platforms do but I guess a lot of them use bl31_params. I suggest that U-Boot SPL mandates that platforms that wish to use TF BL31 with U-Boot SPL must use the bl_params structure. It may also need to mandate that this contains BL33 information specific to U-Boot. Alternatively, U-Boot SPL could define its own structure(s) according to its needs, and mandate that BL31 platforms it wishes to support conform to this. > Thanks, > - Kever > > Regards Dan. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 4/4] board: advantech: dms-ba16: apply the proper register setting to fix the voltage peak issue
Apply the proper setting for the reserved bits in SetDes Test and System Mode Control register to avoid the voltage peak issue while we do the IEEE PHY comformance test Signed-off-by: Ken Lin --- board/advantech/dms-ba16/dms-ba16.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/board/advantech/dms-ba16/dms-ba16.c b/board/advantech/dms-ba16/dms-ba16.c index 75b0bbc2cc..91e96ab096 100644 --- a/board/advantech/dms-ba16/dms-ba16.c +++ b/board/advantech/dms-ba16/dms-ba16.c @@ -304,7 +304,8 @@ static int mx6_rgmii_rework(struct phy_device *phydev) /* set debug port address: SerDes Test and System Mode Control */ phy_write(phydev, MDIO_DEVAD_NONE, 0x1d, 0x05); /* enable rgmii tx clock delay */ - phy_write(phydev, MDIO_DEVAD_NONE, 0x1e, 0x100); + /* set the reserved bits to avoid board specific voltage peak issue*/ + phy_write(phydev, MDIO_DEVAD_NONE, 0x1e, 0x3D47); return 0; } -- 2.11.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: socfpga: boot0 hook: remove macro from boot0 header file
On Wed, Mar 29, 2017 at 5:03 PM, Marek Vasut wrote: > On 03/29/2017 05:49 AM, tien.fong.c...@intel.com wrote: > > From: "Chee, Tien Fong" > > > > Commit ce62e57fc571 ("ARM: boot0 hook: remove macro, include whole > > header file") miss out cleaning macro in this header file, and this > > has broken implementation of a boot header capability in socfpga > > SPL. Remove the macro in this file, and recovering it back > > to proper functioning. > > > > Fixes: ce62e57fc571 ("ARM: boot0 hook: remove macro, include whole > > header file") > > > > Signed-off-by: Chee, Tien Fong > > Patch looks good, minor nit below. > > > --- > > arch/arm/mach-socfpga/include/mach/boot0.h | 24 > ++-- > > 1 file changed, 10 insertions(+), 14 deletions(-) > > > > diff --git a/arch/arm/mach-socfpga/include/mach/boot0.h > b/arch/arm/mach-socfpga/include/mach/boot0.h > > index aaada31..22d9e7f 100644 > > --- a/arch/arm/mach-socfpga/include/mach/boot0.h > > +++ b/arch/arm/mach-socfpga/include/mach/boot0.h > > @@ -8,21 +8,17 @@ > > #define __BOOT0_H > > > > #ifdef CONFIG_SPL_BUILD > > -#define ARM_SOC_BOOT0_HOOK \ > > - .balignl 64,0xf33db33f; \ > > - \ > > - .word 0x1337c0d3; /* SoCFPGA preloader validation word */ \ > > - .word 0xc01df00d; /* Version, flags, length */\ > > - .word 0xcafec0d3; /* Checksum, zero-pad */\ > > - nop;\ > > - \ > > - b reset;/* SoCFPGA jumps here */\ > > - nop;\ > > - nop;\ > > + .balignl 64,0xf33db33f; > > + > > + .word 0x1337c0d3; /* SoCFPGA preloader validation word */ > > + .word 0xc01df00d; /* Version, flags, length */ > > + .word 0xcafec0d3; /* Checksum, zero-pad */ > > nop; > > -#else > > -#define ARM_SOC_BOOT0_HOOK > > -#endif > > > > + b reset;/* SoCFPGA jumps here */ > > + nop; > > + nop; > > + nop; > > Correct me if I'm wrong, but did you add one more "nop" here ? > > no, i din't add extra "nop" here. There are 3 "nop" from original code after "b reset". > > +#endif > > > > #endif /* __BOOT0_H */ > > > > > -- > Best regards, > Marek Vasut > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 5/6] cmd: led: add DM-based implementation
From: Ziping Chen Currently the "led" command only supports the old API without DM. Add DM-based implementation of this command. Also allow this command to be select with Kconfig. Signed-off-by: Ziping Chen --- cmd/Kconfig | 6 cmd/Makefile | 4 +++ cmd/led.c| 113 +++ 3 files changed, 116 insertions(+), 7 deletions(-) diff --git a/cmd/Kconfig b/cmd/Kconfig index 25e3b78..66c94de 100644 --- a/cmd/Kconfig +++ b/cmd/Kconfig @@ -511,6 +511,12 @@ config CMD_GPIO help GPIO support. +config CMD_LED + bool "led" + depends on LED + help + LED support. + endmenu diff --git a/cmd/Makefile b/cmd/Makefile index f13bb8c..0817de5 100644 --- a/cmd/Makefile +++ b/cmd/Makefile @@ -79,7 +79,11 @@ obj-$(CONFIG_CMD_ITEST) += itest.o obj-$(CONFIG_CMD_JFFS2) += jffs2.o obj-$(CONFIG_CMD_CRAMFS) += cramfs.o obj-$(CONFIG_CMD_LDRINFO) += ldrinfo.o +ifdef CONFIG_LED +obj-$(CONFIG_CMD_LED) += led.o +else obj-$(CONFIG_LED_STATUS_CMD) += led.o +endif obj-$(CONFIG_CMD_LICENSE) += license.o obj-y += load.o obj-$(CONFIG_LOGBUFFER) += log.o diff --git a/cmd/led.c b/cmd/led.c index d50938a..3849a79 100644 --- a/cmd/led.c +++ b/cmd/led.c @@ -13,8 +13,14 @@ #include #include #include +#ifndef CONFIG_LED #include +#else +#include +DECLARE_GLOBAL_DATA_PTR; +#endif +#ifndef CONFIG_LED struct led_tbl_s { char*string;/* String for use in the command */ led_id_tmask; /* Mask used for calling __led_set() */ @@ -62,6 +68,15 @@ static const led_tbl_t led_commands[] = { { NULL, 0, NULL, NULL, NULL } }; +/* + * LED drivers providing a blinking LED functionality, like the + * PCA9551, can override this empty weak function + */ +void __weak __led_blink(led_id_t mask, int freq) +{ +} +#endif + enum led_cmd { LED_CMD_ERROR = -1, LED_CMD_ON, @@ -78,19 +93,53 @@ enum led_cmd get_led_cmd(char *var) return LED_CMD_ON; if (strcmp(var, "toggle") == 0) return LED_CMD_TOGGLE; +#ifndef CONFIG_LED if (strcmp(var, "blink") == 0) return LED_CMD_BLINK; - +#endif return -1; } -/* - * LED drivers providing a blinking LED functionality, like the - * PCA9551, can override this empty weak function - */ -void __weak __led_blink(led_id_t mask, int freq) +#ifdef CONFIG_LED +int dm_led_set(char *label, enum led_cmd cmd) { + struct udevice *dev; + char status; + if (led_get_by_label(label, &dev)) { + printf("Warning: led [ %s ] not found\n", + label); + return -1; + } + switch (cmd) { + case LED_CMD_ON: + led_set_on(dev, 1); + if (led_get_status(dev) != 1) { + printf("Warning: status of [ %s ] is still 0\n", + label); + return -1; + } + break; + case LED_CMD_OFF: + led_set_on(dev, 0); + if (led_get_status(dev) != 0) { + printf("Warning: status of [ %s ] is still 1\n", + label); + return -1; + } + break; + case LED_CMD_TOGGLE: + status = led_get_status(dev); + led_set_on(dev, !status); + if (led_get_status(dev) == status) { + printf("Warning: status of [ %s ] is still %d\n", + label, status); + return -1; + } + break; + } + return 0; } +#endif int do_led (cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) { @@ -99,14 +148,23 @@ int do_led (cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) int freq; /* Validate arguments */ +#ifndef CONFIG_LED if ((argc < 3) || (argc > 4)) +#else + if ((argc < 2) || (argc > 4)) +#endif return CMD_RET_USAGE; cmd = get_led_cmd(argv[2]); +#ifndef CONFIG_LED if (cmd < 0) { +#else + if (argc > 2 && cmd < 0) { +#endif return CMD_RET_USAGE; } +#ifndef CONFIG_LED for (i = 0; led_commands[i].string; i++) { if ((strcmp("all", argv[1]) == 0) || (strcmp(led_commands[i].string, argv[1]) == 0)) { @@ -144,7 +202,40 @@ int do_led (cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) break; } } - +#else + if (strcmp("all", argv[1]) == 0) { + char *label = ""; + int node, len, error_count = 0; + match = 1; + node = fdt_path_offset(gd->fdt_blob, "/leds"); + if (node < 0) { + printf("led: null led found\n"); + return CMD_RET_F
Re: [U-Boot] [PATCH v2 14/18] sunxi: Pine64: defconfig: enable SPL FIT support
2017年3月29日 19:17于 Andre Przywara 写道: > > Hi, > > On 29/03/17 07:57, Maxime Ripard wrote: > > On Tue, Mar 28, 2017 at 01:45:22AM +0100, Andre Przywara wrote: > >> The Pine64 (and all other 64-bit Allwinner boards) need to load an > >> ARM Trusted Firmware image beside the actual U-Boot proper. > >> This can now be easily achieved by using the just extended SPL FIT > >> loading support, so enable it in the Pine64 defconfig. > >> Also add the FIT image as a build target to 64-bit sunxi board to > >> trigger the respective Makefile rules. > >> > >> Signed-off-by: Andre Przywara > >> --- > >> configs/pine64_plus_defconfig | 6 ++ > >> include/configs/sunxi-common.h | 4 > >> 2 files changed, 10 insertions(+) > >> > >> diff --git a/configs/pine64_plus_defconfig b/configs/pine64_plus_defconfig > >> index 92bda60..8a90579 100644 > >> --- a/configs/pine64_plus_defconfig > >> +++ b/configs/pine64_plus_defconfig > >> @@ -3,9 +3,14 @@ CONFIG_ARCH_SUNXI=y > >> CONFIG_MACH_SUN50I=y > >> CONFIG_RESERVE_ALLWINNER_BOOT0_HEADER=y > >> CONFIG_DEFAULT_DEVICE_TREE="sun50i-a64-pine64-plus" > >> +CONFIG_OF_LIST="sun50i-a64-pine64 sun50i-a64-pine64-plus" > >> # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set > >> CONFIG_CONSOLE_MUX=y > >> CONFIG_SPL=y > >> +CONFIG_FIT=y > >> +CONFIG_SPL_FIT=y > >> +CONFIG_SPL_LOAD_FIT=y > >> +CONFIG_SPL_OF_LIBFDT=y > > > > Again, this doesn't make any sense to enable it in *all* our > > defconfigs. If this is something that should be enabled by default for > > the A64 support, then do so in Kconfig directly. > > Oh sorry, I think I completely misunderstood you last time. > Indeed this makes sense, especially with more defconfigs for A64/H5 > boards coming up. > > I will think about a solution that makes Icenowy happy as well, > something like BOARD_NEEDS_SPL_FIT or so - though a simple "select" > sounds tempting ;-) In fact I don't need an environment without ATF. I just mentioned the possibility ;-) > > Cheers, > Andre. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 4/6] cmd: led: add enum led_cmd member to support error code return
From: Ziping Chen Add enum led_cmd member LED_CMD_ERROR, so that the enum can contain the error code -1. Signed-off-by: Ziping Chen --- cmd/led.c | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/cmd/led.c b/cmd/led.c index ef0ab1a..d50938a 100644 --- a/cmd/led.c +++ b/cmd/led.c @@ -62,7 +62,13 @@ static const led_tbl_t led_commands[] = { { NULL, 0, NULL, NULL, NULL } }; -enum led_cmd { LED_CMD_ON, LED_CMD_OFF, LED_CMD_TOGGLE, LED_CMD_BLINK }; +enum led_cmd { + LED_CMD_ERROR = -1, + LED_CMD_ON, + LED_CMD_OFF, + LED_CMD_TOGGLE, + LED_CMD_BLINK +}; enum led_cmd get_led_cmd(char *var) { -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 01/16] board_f: Drop board_type parameter from initdram()
It looks like only cm5200 and tqm8xx use this feature, so we don't really need it in generic code. Drop it and have the users access gd->board_type directly. Signed-off-by: Simon Glass --- arch/arm/cpu/armv8/fsl-layerscape/cpu.c | 2 +- arch/mips/mach-ath79/dram.c | 2 +- arch/mips/mach-pic32/cpu.c | 2 +- arch/powerpc/cpu/mpc5xxx/spl_boot.c | 2 +- arch/powerpc/cpu/mpc85xx/cpu.c | 4 ++-- arch/powerpc/cpu/ppc4xx/44x_spd_ddr2.c | 4 ++-- arch/powerpc/cpu/ppc4xx/denali_spd_ddr2.c | 2 +- arch/powerpc/cpu/ppc4xx/sdram.c | 4 ++-- arch/powerpc/cpu/ppc4xx/spl_boot.c | 2 +- board/Arcturus/ucp1020/spl.c| 2 +- board/BuS/eb_cpu5282/eb_cpu5282.c | 2 +- board/a3m071/a3m071.c | 2 +- board/a4m072/a4m072.c | 2 +- board/amcc/acadia/memory.c | 2 +- board/amcc/bamboo/bamboo.c | 2 +- board/amcc/bubinga/bubinga.c| 4 ++-- board/amcc/sequoia/sdram.c | 2 +- board/amcc/walnut/walnut.c | 4 ++-- board/amcc/yosemite/yosemite.c | 2 +- board/astro/mcf5373l/mcf5373l.c | 2 +- board/canmb/canmb.c | 2 +- board/cm5200/cm5200.c | 4 ++-- board/cobra5272/cobra5272.c | 2 +- board/davedenx/aria/aria.c | 2 +- board/dbau1x00/dbau1x00.c | 2 +- board/esd/mecp5123/mecp5123.c | 2 +- board/esd/pmc440/sdram.c| 2 +- board/esd/vme8349/vme8349.c | 2 +- board/freescale/b4860qds/ddr.c | 2 +- board/freescale/b4860qds/spl.c | 2 +- board/freescale/c29xpcie/spl.c | 2 +- board/freescale/corenet_ds/ddr.c| 2 +- board/freescale/ls1021aqds/ddr.c| 2 +- board/freescale/ls1021aqds/ls1021aqds.c | 2 +- board/freescale/ls1043aqds/ddr.c| 2 +- board/freescale/ls1043aqds/ls1043aqds.c | 2 +- board/freescale/ls1043ardb/ddr.c| 2 +- board/freescale/ls1046aqds/ddr.c| 2 +- board/freescale/ls1046aqds/ls1046aqds.c | 2 +- board/freescale/ls1046ardb/ddr.c| 2 +- board/freescale/ls2080a/ddr.c | 2 +- board/freescale/ls2080aqds/ddr.c| 2 +- board/freescale/ls2080ardb/ddr.c| 2 +- board/freescale/m5208evbe/m5208evbe.c | 2 +- board/freescale/m52277evb/m52277evb.c | 2 +- board/freescale/m5235evb/m5235evb.c | 2 +- board/freescale/m5249evb/m5249evb.c | 3 ++- board/freescale/m5253demo/m5253demo.c | 2 +- board/freescale/m5253evbe/m5253evbe.c | 2 +- board/freescale/m5272c3/m5272c3.c | 3 ++- board/freescale/m5275evb/m5275evb.c | 2 +- board/freescale/m5282evb/m5282evb.c | 2 +- board/freescale/m53017evb/m53017evb.c | 2 +- board/freescale/m5329evb/m5329evb.c | 2 +- board/freescale/m5373evb/m5373evb.c | 2 +- board/freescale/m54418twr/m54418twr.c | 2 +- board/freescale/m54451evb/m54451evb.c | 2 +- board/freescale/m54455evb/m54455evb.c | 2 +- board/freescale/m547xevb/m547xevb.c | 2 +- board/freescale/m548xevb/m548xevb.c | 2 +- board/freescale/mpc5121ads/mpc5121ads.c | 2 +- board/freescale/mpc8308rdb/sdram.c | 2 +- board/freescale/mpc8313erdb/mpc8313erdb.c | 2 +- board/freescale/mpc8313erdb/sdram.c | 2 +- board/freescale/mpc8315erdb/mpc8315erdb.c | 2 +- board/freescale/mpc8315erdb/sdram.c | 2 +- board/freescale/mpc8323erdb/mpc8323erdb.c | 2 +- board/freescale/mpc832xemds/mpc832xemds.c | 2 +- board/freescale/mpc8349emds/mpc8349emds.c | 2 +- board/freescale/mpc8349itx/mpc8349itx.c | 2 +- board/freescale/mpc837xemds/mpc837xemds.c | 2 +- board/freescale/mpc837xerdb/mpc837xerdb.c | 2 +- board/freescale/mpc8610hpcd/mpc8610hpcd.c | 3 +-- board/freescale/mpc8641hpcn/mpc8641hpcn.c | 3 +-- board/freescale/p1010rdb/spl.c | 2 +- board/freescale/p1022ds/spl.c | 2 +- board/freescale/p1_p2_rdb_pc/spl.c | 2 +- board/freescale/p2041rdb/ddr.c | 2 +- board/freescale/t102xqds/ddr.c | 2 +- board/freescale/t102xqds/spl.c
[U-Boot] [PATCH 12/17] board_f: powerpc: Move prt_83xx_rsr() to private code
This function is called just before checkcpu() on MPX83xx. Move it to the code for that arch. Signed-off-by: Simon Glass --- arch/powerpc/cpu/mpc83xx/cpu.c | 5 + arch/powerpc/cpu/mpc83xx/cpu_init.c | 1 + arch/powerpc/include/asm/processor.h | 2 ++ common/board_f.c | 3 --- include/common.h | 2 -- 5 files changed, 8 insertions(+), 5 deletions(-) diff --git a/arch/powerpc/cpu/mpc83xx/cpu.c b/arch/powerpc/cpu/mpc83xx/cpu.c index c87f0fdd29..cb82621ec4 100644 --- a/arch/powerpc/cpu/mpc83xx/cpu.c +++ b/arch/powerpc/cpu/mpc83xx/cpu.c @@ -33,6 +33,7 @@ int checkcpu(void) u32 pvr = get_pvr(); u32 spridr; char buf[32]; + int ret; int i; const struct cpu_type { @@ -61,6 +62,10 @@ int checkcpu(void) immr = (immap_t *)CONFIG_SYS_IMMR; + ret = prt_83xx_rsr(); + if (ret) + return ret; + puts("CPU: "); switch (pvr & 0x) { diff --git a/arch/powerpc/cpu/mpc83xx/cpu_init.c b/arch/powerpc/cpu/mpc83xx/cpu_init.c index 3a0916bdbf..2a9db0c51b 100644 --- a/arch/powerpc/cpu/mpc83xx/cpu_init.c +++ b/arch/powerpc/cpu/mpc83xx/cpu_init.c @@ -8,6 +8,7 @@ #include #include #include +#include #ifdef CONFIG_USB_EHCI_FSL #include #endif diff --git a/arch/powerpc/include/asm/processor.h b/arch/powerpc/include/asm/processor.h index 81bae6f008..c032726df1 100644 --- a/arch/powerpc/include/asm/processor.h +++ b/arch/powerpc/include/asm/processor.h @@ -1354,6 +1354,8 @@ void ll_puts(const char *); /* In misc.c */ void _nmask_and_or_msr(unsigned long nmask, unsigned long or_val); +int prt_83xx_rsr(void); + #endif /* ndef ASSEMBLY*/ #ifdef CONFIG_MACH_SPECIFIC diff --git a/common/board_f.c b/common/board_f.c index cbd9f67709..74cdef0ddb 100644 --- a/common/board_f.c +++ b/common/board_f.c @@ -864,9 +864,6 @@ static const init_fnc_t init_sequence_f[] = { prt_8260_rsr, prt_8260_clks, #endif /* CONFIG_MPC8260 */ -#if defined(CONFIG_MPC83xx) - prt_83xx_rsr, -#endif #if defined(CONFIG_PPC) || defined(CONFIG_M68K) || defined(CONFIG_SH) checkcpu, #endif diff --git a/include/common.h b/include/common.h index 684083510b..6f08110b74 100644 --- a/include/common.h +++ b/include/common.h @@ -715,8 +715,6 @@ ulong cpu_init_f(void); intcpu_init_r(void); #if defined(CONFIG_MPC8260) intprt_8260_rsr (void); -#elif defined(CONFIG_MPC83xx) -intprt_83xx_rsr (void); #endif /* $(CPU)/interrupts.c */ -- 2.12.2.564.g063fe858b8-goog ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/7] system halt when we enable bucks of PMIC rk808
From: "eric.gao" if we enable PMIC rk808,the system will halt at very early stage ,log is shown as bellow. INFO:plat_rockchip_pmu_init(1211): pd status 3e INFO:BL31: Initializing runtime services INFO:BL31: Preparing for EL3 exit to normal world INFO:Entry point address = 0x20 INFO:SPSR = 0x3c9 time 44561b, 0 (<compatible) { <<-- if (!strcmp(of_match->compatible, compat)) { *of_idp = of_match; return 0; } of_match++; } Signed-off-by: eric.gao --- arch/arm/mach-rockchip/rk3399/syscon_rk3399.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/mach-rockchip/rk3399/syscon_rk3399.c b/arch/arm/mach-rockchip/rk3399/syscon_rk3399.c index d32985b..74d4552 100644 --- a/arch/arm/mach-rockchip/rk3399/syscon_rk3399.c +++ b/arch/arm/mach-rockchip/rk3399/syscon_rk3399.c @@ -14,6 +14,7 @@ static const struct udevice_id rk3399_syscon_ids[] = { { .compatible = "rockchip,rk3399-pmugrf", .data = ROCKCHIP_SYSCON_PMUGRF }, { .compatible = "rockchip,rk3399-pmusgrf", .data = ROCKCHIP_SYSCON_PMUSGRF }, { .compatible = "rockchip,rk3399-cic", .data = ROCKCHIP_SYSCON_CIC }, + { } }; U_BOOT_DRIVER(syscon_rk3399) = { -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 0/7] Enable MIPI dsi display for rk3399
From: "eric.gao" This serial patchs enable mipi dsi display for rk3399,and let the system log print to lcd. The function of each patch is decribe in the following.Thank you. Patch 1: Fix system halt when we enable bucks of PMIC rk808. Patch 2: Enable i2c for rk3399. Patch 3: Enable PMIC rk808 for display system using. Patch 4: Enable rkclk init,prepare aclk dclk for vop. Patch 5: Add mipi display,panel driver and so on. Patch 6: Enable print log to lcd. Patch 7: Fix crash when scrolling screen. eric.gao (7): system halt when we enable bucks of PMIC rk808 Enable i2c for rk3399 Enable RK808 for rk3399 evb Enable rkclk init function Add mipi display support for rk3399 && rk3288 Enable print log file to lcd crash when scroll screen arch/arm/dts/rk3399-evb.dts | 141 + arch/arm/dts/rk3399.dtsi | 88 ++ arch/arm/include/asm/arch-rockchip/cru_rk3399.h | 2 +- arch/arm/include/asm/arch-rockchip/mipi_rk3399.h | 203 + arch/arm/include/asm/arch-rockchip/vop_rk3288.h | 1 + arch/arm/mach-rockchip/rk3399/syscon_rk3399.c| 1 + configs/evb-rk3399_defconfig | 11 + drivers/clk/rockchip/clk_rk3399.c| 4 + drivers/i2c/rk_i2c.c | 1 + drivers/video/Kconfig| 2 + drivers/video/console_normal.c | 2 +- drivers/video/rockchip/Kconfig | 44 +++ drivers/video/rockchip/Makefile | 7 +- drivers/video/rockchip/panel.c | 81 + drivers/video/rockchip/rk_mipi.c | 371 +++ drivers/video/rockchip/rk_vop.c | 12 +- include/configs/rk3399_common.h | 5 +- 17 files changed, 969 insertions(+), 7 deletions(-) create mode 100644 arch/arm/include/asm/arch-rockchip/mipi_rk3399.h create mode 100644 drivers/video/rockchip/Kconfig create mode 100644 drivers/video/rockchip/panel.c create mode 100644 drivers/video/rockchip/rk_mipi.c -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 09/16] board_f: Drop setup_dram_config() wrapper
By making dram_init_banksize() return an error code we can drop the wrapper. Adjust this and clean up all implementations. Signed-off-by: Simon Glass --- arch/arm/cpu/arm926ejs/armada100/dram.c | 4 +++- arch/arm/cpu/armv8/fsl-layerscape/cpu.c | 4 +++- arch/arm/include/asm/u-boot-arm.h| 2 +- arch/arm/mach-davinci/misc.c | 4 +++- arch/arm/mach-meson/board.c | 4 +++- arch/arm/mach-mvebu/arm64-common.c | 8 +--- arch/arm/mach-mvebu/dram.c | 4 +++- arch/arm/mach-omap2/am33xx/emif4.c | 4 +++- arch/arm/mach-omap2/omap3/emif4.c| 4 +++- arch/arm/mach-omap2/omap3/sdrc.c | 4 +++- arch/arm/mach-orion5x/dram.c | 4 +++- arch/arm/mach-tegra/board2.c | 4 +++- arch/arm/mach-tegra/tegra186/nvtboot_mem.c | 4 +++- arch/arm/mach-uniphier/dram_init.c | 4 +++- arch/x86/cpu/broadwell/sdram.c | 4 +++- arch/x86/cpu/coreboot/sdram.c| 4 +++- arch/x86/cpu/efi/sdram.c | 4 +++- arch/x86/cpu/ivybridge/sdram.c | 4 +++- arch/x86/cpu/qemu/dram.c | 4 +++- arch/x86/cpu/quark/dram.c| 4 +++- arch/x86/include/asm/u-boot-x86.h| 2 +- arch/x86/lib/efi/efi.c | 6 -- arch/x86/lib/fsp/fsp_dram.c | 4 +++- board/AndesTech/adp-ag101p/adp-ag101p.c | 4 +++- board/armadeus/apf27/apf27.c | 4 +++- board/armltd/vexpress/vexpress_common.c | 4 +++- board/armltd/vexpress64/vexpress64.c | 4 +++- board/beckhoff/mx53cx9020/mx53cx9020.c | 4 +++- board/broadcom/bcm23550_w1d/bcm23550_w1d.c | 4 +++- board/broadcom/bcm28155_ap/bcm28155_ap.c | 4 +++- board/broadcom/bcm_ep/board.c| 4 +++- board/broadcom/bcmns2/northstar2.c | 4 +++- board/cadence/xtfpga/xtfpga.c| 4 +++- board/cirrus/edb93xx/edb93xx.c | 4 +++- board/compulab/cm_fx6/cm_fx6.c | 4 +++- board/denx/m53evk/m53evk.c | 4 +++- board/esd/meesc/meesc.c | 4 +++- board/freescale/ls1021aqds/ddr.c | 4 +++- board/freescale/mx35pdk/mx35pdk.c| 4 +++- board/freescale/mx53ard/mx53ard.c| 4 +++- board/freescale/mx53loco/mx53loco.c | 4 +++- board/freescale/mx53smd/mx53smd.c| 4 +++- board/hisilicon/hikey/hikey.c| 4 +++- board/mini-box/picosam9g45/picosam9g45.c | 4 +++- board/qualcomm/dragonboard410c/dragonboard410c.c | 4 +++- board/rockchip/evb_rk3328/evb-rk3328.c | 4 +++- board/rockchip/evb_rk3399/evb-rk3399.c | 4 +++- board/ronetix/pm9261/pm9261.c| 4 +++- board/ronetix/pm9263/pm9263.c| 4 +++- board/ronetix/pm9g45/pm9g45.c| 4 +++- board/samsung/arndale/arndale.c | 4 +++- board/samsung/common/board.c | 4 +++- board/samsung/goni/goni.c| 4 +++- board/samsung/smdkc100/smdkc100.c| 4 +++- board/samsung/smdkv310/smdkv310.c| 4 +++- board/spear/common/spr_misc.c| 4 +++- board/st/stih410-b2260/board.c | 4 +++- board/st/stv0991/stv0991.c | 4 +++- board/ti/dra7xx/evm.c| 4 +++- board/xilinx/microblaze-generic/microblaze-generic.c | 4 +++- board/xilinx/zynq/board.c| 4 +++- board/xilinx/zynqmp/zynqmp.c | 4 +++- board/zipitz2/zipitz2.c | 4 +++- common/board_f.c | 14 -- 64 files changed, 192 insertions(+), 76 deletions(-) diff --git a/arch/arm/cpu/arm926ejs/armada100/dram.c b/arch/arm/cpu/arm926ejs/armada100/dram.c index f3b9a66cd5..6a9000e304 100644 --- a/arch/arm/cpu/arm926ejs/armada100/dram.c +++ b/arch/arm/cpu/arm926ejs/armada100/dram.c @@ -108,7 +108,9 @@ int dram_init(void) * If this function is not defined here, * board.c alters dram bank zero configuration defined above. */ -void dram_init_banksize(void) +int dram_init_banksize(void) { dram_init(); + + return 0; } diff --git a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c index 583fa7a7e3..36e504537e 100644 --- a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c +++ b/arch/arm/cpu/
[U-Boot] [PATCH 02/16] board_f: Drop return value from initdram()
At present we cannot use this function as an init sequence call without a wrapper, since it returns the RAM size. Adjust it to set the RAM size in global_data instead, and return 0 on success. Signed-off-by: Simon Glass --- arch/arm/cpu/armv8/fsl-layerscape/cpu.c | 2 +- arch/mips/mach-ath79/dram.c | 8 ++-- arch/mips/mach-pic32/cpu.c | 6 -- arch/powerpc/cpu/mpc85xx/cpu.c | 14 +- arch/powerpc/cpu/ppc4xx/44x_spd_ddr2.c | 18 +- arch/powerpc/cpu/ppc4xx/denali_spd_ddr2.c | 8 ++-- arch/powerpc/cpu/ppc4xx/sdram.c | 18 -- board/Arcturus/ucp1020/spl.c| 2 +- board/BuS/eb_cpu5282/eb_cpu5282.c | 6 -- board/a3m071/a3m071.c | 6 -- board/a4m072/a4m072.c | 8 ++-- board/amcc/acadia/memory.c | 8 ++-- board/amcc/bamboo/bamboo.c | 8 ++-- board/amcc/bubinga/bubinga.c| 8 ++-- board/amcc/sequoia/sdram.c | 8 ++-- board/amcc/walnut/walnut.c | 8 ++-- board/amcc/yosemite/yosemite.c | 7 +-- board/astro/mcf5373l/mcf5373l.c | 6 -- board/canmb/canmb.c | 8 ++-- board/cm5200/cm5200.c | 6 -- board/cobra5272/cobra5272.c | 7 +-- board/davedenx/aria/aria.c | 6 -- board/dbau1x00/dbau1x00.c | 8 ++-- board/esd/mecp5123/mecp5123.c | 6 -- board/esd/pmc440/sdram.c| 12 board/esd/vme8349/vme8349.c | 10 +++--- board/freescale/b4860qds/ddr.c | 6 -- board/freescale/b4860qds/spl.c | 2 +- board/freescale/c29xpcie/spl.c | 2 +- board/freescale/corenet_ds/ddr.c| 6 -- board/freescale/ls1021aqds/ddr.c| 6 -- board/freescale/ls1021aqds/ls1021aqds.c | 4 +--- board/freescale/ls1043aqds/ddr.c| 6 -- board/freescale/ls1043aqds/ls1043aqds.c | 2 +- board/freescale/ls1043ardb/ddr.c| 6 -- board/freescale/ls1046aqds/ddr.c| 6 -- board/freescale/ls1046aqds/ls1046aqds.c | 2 +- board/freescale/ls1046ardb/ddr.c| 6 -- board/freescale/ls2080a/ddr.c | 8 +++- board/freescale/ls2080aqds/ddr.c| 10 -- board/freescale/ls2080ardb/ddr.c| 10 -- board/freescale/m5208evbe/m5208evbe.c | 6 -- board/freescale/m52277evb/m52277evb.c | 6 -- board/freescale/m5235evb/m5235evb.c | 6 -- board/freescale/m5249evb/m5249evb.c | 8 ++-- board/freescale/m5253demo/m5253demo.c | 8 ++-- board/freescale/m5253evbe/m5253evbe.c | 8 ++-- board/freescale/m5272c3/m5272c3.c | 7 +-- board/freescale/m5275evb/m5275evb.c | 8 ++-- board/freescale/m5282evb/m5282evb.c | 6 -- board/freescale/m53017evb/m53017evb.c | 6 -- board/freescale/m5329evb/m5329evb.c | 6 -- board/freescale/m5373evb/m5373evb.c | 6 -- board/freescale/m54418twr/m54418twr.c | 6 -- board/freescale/m54451evb/m54451evb.c | 6 -- board/freescale/m54455evb/m54455evb.c | 6 -- board/freescale/m547xevb/m547xevb.c | 6 -- board/freescale/m548xevb/m548xevb.c | 6 -- board/freescale/mpc5121ads/mpc5121ads.c | 6 -- board/freescale/mpc8308rdb/sdram.c | 8 +--- board/freescale/mpc8313erdb/sdram.c | 8 +--- board/freescale/mpc8315erdb/sdram.c | 10 ++ board/freescale/mpc8323erdb/mpc8323erdb.c | 12 board/freescale/mpc832xemds/mpc832xemds.c | 12 board/freescale/mpc8349emds/mpc8349emds.c | 12 board/freescale/mpc8349itx/mpc8349itx.c | 10 +++--- board/freescale/mpc837xemds/mpc837xemds.c | 10 +++--- board/freescale/mpc837xerdb/mpc837xerdb.c | 10 +++--- board/freescale/mpc8610hpcd/mpc8610hpcd.c | 8 ++-- board/freescale/mpc8641hpcn/mpc8641hpcn.c | 8 ++-- board/freescale/p1010rdb/spl.c | 2 +- board/freescale/p1022ds/spl.c | 2 +-
[U-Boot] [PATCH 03/16] board_f: Rename initdram() to dram_init()
This allows us to use the same DRAM init function on all archs. Signed-off-by: Simon Glass --- arch/mips/mach-ath79/dram.c | 2 +- arch/mips/mach-pic32/cpu.c | 2 +- arch/mips/mach-pic32/include/mach/ddr.h | 2 +- arch/powerpc/cpu/mpc5xxx/spl_boot.c | 4 ++-- arch/powerpc/cpu/mpc85xx/cpu.c | 4 ++-- arch/powerpc/cpu/ppc4xx/44x_spd_ddr2.c | 4 ++-- arch/powerpc/cpu/ppc4xx/denali_spd_ddr2.c | 4 ++-- arch/powerpc/cpu/ppc4xx/sdram.c | 4 ++-- arch/powerpc/cpu/ppc4xx/spl_boot.c | 2 +- arch/xtensa/cpu/cpu.c | 5 + board/Arcturus/ucp1020/spl.c| 2 +- board/BuS/eb_cpu5282/eb_cpu5282.c | 2 +- board/a3m071/a3m071.c | 2 +- board/a4m072/a4m072.c | 2 +- board/amcc/acadia/memory.c | 2 +- board/amcc/bamboo/bamboo.c | 2 +- board/amcc/bubinga/bubinga.c| 4 ++-- board/amcc/sequoia/sdram.c | 2 +- board/amcc/walnut/walnut.c | 4 ++-- board/amcc/yosemite/yosemite.c | 2 +- board/astro/mcf5373l/mcf5373l.c | 2 +- board/canmb/canmb.c | 2 +- board/cm5200/cm5200.c | 2 +- board/cobra5272/cobra5272.c | 2 +- board/davedenx/aria/aria.c | 2 +- board/dbau1x00/dbau1x00.c | 2 +- board/esd/mecp5123/mecp5123.c | 2 +- board/esd/pmc440/sdram.c| 2 +- board/esd/vme8349/vme8349.c | 2 +- board/freescale/b4860qds/ddr.c | 2 +- board/freescale/b4860qds/spl.c | 2 +- board/freescale/c29xpcie/spl.c | 2 +- board/freescale/corenet_ds/ddr.c| 2 +- board/freescale/ls1043ardb/ddr.c| 2 +- board/freescale/ls1046ardb/ddr.c| 2 +- board/freescale/ls2080a/ddr.c | 2 +- board/freescale/ls2080aqds/ddr.c| 2 +- board/freescale/ls2080ardb/ddr.c| 2 +- board/freescale/m5208evbe/m5208evbe.c | 2 +- board/freescale/m52277evb/m52277evb.c | 2 +- board/freescale/m5235evb/m5235evb.c | 2 +- board/freescale/m5249evb/m5249evb.c | 2 +- board/freescale/m5253demo/m5253demo.c | 2 +- board/freescale/m5253evbe/m5253evbe.c | 2 +- board/freescale/m5272c3/m5272c3.c | 2 +- board/freescale/m5275evb/m5275evb.c | 2 +- board/freescale/m5282evb/m5282evb.c | 2 +- board/freescale/m53017evb/m53017evb.c | 2 +- board/freescale/m5329evb/m5329evb.c | 2 +- board/freescale/m5373evb/m5373evb.c | 2 +- board/freescale/m54418twr/m54418twr.c | 2 +- board/freescale/m54451evb/m54451evb.c | 2 +- board/freescale/m54455evb/m54455evb.c | 2 +- board/freescale/m547xevb/m547xevb.c | 2 +- board/freescale/m548xevb/m548xevb.c | 2 +- board/freescale/mpc5121ads/mpc5121ads.c | 2 +- board/freescale/mpc8308rdb/sdram.c | 2 +- board/freescale/mpc8313erdb/mpc8313erdb.c | 2 +- board/freescale/mpc8313erdb/sdram.c | 2 +- board/freescale/mpc8315erdb/mpc8315erdb.c | 2 +- board/freescale/mpc8315erdb/sdram.c | 2 +- board/freescale/mpc8323erdb/mpc8323erdb.c | 2 +- board/freescale/mpc832xemds/mpc832xemds.c | 2 +- board/freescale/mpc8349emds/mpc8349emds.c | 2 +- board/freescale/mpc8349itx/mpc8349itx.c | 2 +- board/freescale/mpc837xemds/mpc837xemds.c | 2 +- board/freescale/mpc837xerdb/mpc837xerdb.c | 2 +- board/freescale/mpc8610hpcd/mpc8610hpcd.c | 2 +- board/freescale/mpc8641hpcn/mpc8641hpcn.c | 2 +- board/freescale/p1010rdb/spl.c | 2 +- board/freescale/p1022ds/spl.c | 2 +- board/freescale/p1_p2_rdb_pc/spl.c | 2 +- board/freescale/p2041rdb/ddr.c | 2 +- board/freescale/t102xqds/ddr.c | 2 +- board/freescale/t102xqds/spl.c | 2 +- board/freescale/t102xrdb/ddr.c | 2 +- board/freescale/t102xrdb/spl.c | 2 +- board/freescale/t1040qds/ddr.c | 2 +- board/freescale/t104xrdb/ddr.c | 2 +- board/freescale/t104xrdb/spl.c | 2 +- boa
[U-Boot] [PATCH 3/7] Enable RK808 for rk3399 evb
From: "eric.gao" Signed-off-by: eric.gao --- arch/arm/dts/rk3399-evb.dts | 108 +++ configs/evb-rk3399_defconfig | 5 ++ 2 files changed, 113 insertions(+) diff --git a/arch/arm/dts/rk3399-evb.dts b/arch/arm/dts/rk3399-evb.dts index a959989..7a889c7 100644 --- a/arch/arm/dts/rk3399-evb.dts +++ b/arch/arm/dts/rk3399-evb.dts @@ -51,6 +51,22 @@ regulator-name = "vcc5v0_host"; gpio = <&gpio4 25 GPIO_ACTIVE_HIGH>; }; + + vccsys: vccsys { + compatible = "regulator-fixed"; + regulator-name = "vccsys"; + regulator-boot-on; + regulator-always-on; + }; + vcc33_sys: vcc33-sys { + compatible = "regulator-fixed"; + regulator-name = "vcc33_sys"; + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <330>; + regulator-max-microvolt = <330>; + vin-supply = <&vccsys>; + }; }; &emmc_phy { @@ -110,6 +126,98 @@ status = "okay"; }; +&i2c0 { + status = "okay"; + + clock-frequency = <40>; + i2c-scl-falling-time-ns = <50>; + i2c-scl-rising-time-ns = <100>; + u-boot,dm-pre-reloc; + + rk808: pmic@1b { + compatible = "rockchip,rk808"; + clock-output-names = "xin32k", "wifibt_32kin"; + interrupt-parent = <&gpio0>; + interrupts = <4 IRQ_TYPE_LEVEL_LOW>; + pinctrl-names = "default"; + pinctrl-0 = <&pmic_int_l>; + reg = <0x1b>; + rockchip,system-power-controller; + #clock-cells = <1>; + u-boot,dm-pre-reloc; + status = "okay"; + + vcc1-supply = <&vcc33_sys>; + vcc2-supply = <&vcc33_sys>; + vcc3-supply = <&vcc33_sys>; + vcc4-supply = <&vcc33_sys>; + vcc6-supply = <&vcc33_sys>; + vcc7-supply = <&vcc33_sys>; + vcc11-supply = <&vcc33_sys>; + vcc12-supply = <&vcc33_sys>; + vddio-supply = <&vcc1v8>; + regulators { + vdd_cpu_b: DCDC_REG1 { + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <75>; + regulator-max-microvolt = <145>; + regulator-name = "vdd_cpu_b"; + }; + + vdd_cpu_l: DCDC_REG2 { + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <75>; + regulator-max-microvolt = <145>; + regulator-name = "vdd_cpu_l"; + }; + + vcc135_ddr: DCDC_REG3 { + regulator-always-on; + regulator-boot-on; + regulator-name = "vcc135_ddr"; + }; + + vcc18: DCDC_REG4 { + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <180>; + regulator-max-microvolt = <180>; + regulator-name = "vcc_18"; + }; + + vcc1v8_dvp: LDO_REG1 { + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <180>; + regulator-max-microvolt = <180>; + regulator-name = "vcc18_dvp"; + }; + + vcc1v8: LDO_REG3 { + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <180>; + regulator-max-microvolt = <180>; + regulator-name = "vdd_18"; + }; + + vcc3v0: LDO_REG8 { + regulator-min-microvolt = <300>; + regulator-max-microvolt = <300>; + regulator-name = "vcc3v0"; + }; + + vcc33_lcd: SWITCH_REG2 { + regulator-always-on; + regulator-boot-on; + regulator-name = "vcc33_lcd"; + }; + }; + }; +}; + &pinctrl { pmic { pmic_int_l: pmic-int-l { diff --git
[U-Boot] [PATCH 00/16] Clean up board_f sequence a little more
This series continues the effort to remove #ifdefs from the board_f init sequence. It follows on from the first series. With both series applied the number of references to CONFIG in board_f.c drops from 178 to 137: strings common/board_f.c |grep -c CONFIG Simon Glass (16): board_f: Drop board_type parameter from initdram() board_f: Drop return value from initdram() board_f: Rename initdram() to dram_init() xtensa: Place relocated U-Boot in the normal place board_f: Use a single condition for reserve_logbuffer() board_f: Move the extra #ifdef condition into reserve_mmu() board_f: Put video memory reservation in one function board_f: Drop CONFIG_SPL_BUILD check board_f: Drop setup_dram_config() wrapper Move dram_init_banksize() to a common header board_f: Drop unused headers board_f: Move errno.h down to the bottom powerpc: Move setup_board_extra() into a PPC file board_f: Make init_helpers generic board_f: Make relocation functions generic board_f: powerpc: Drop unused headers arch/arc/include/asm/init_helpers.h| 12 -- arch/arc/include/asm/relocate.h| 16 -- arch/arm/cpu/arm926ejs/armada100/dram.c| 4 +- arch/arm/cpu/armv8/fsl-layerscape/cpu.c| 6 +- arch/arm/include/asm/u-boot-arm.h | 1 - arch/arm/mach-davinci/misc.c | 4 +- arch/arm/mach-meson/board.c| 4 +- arch/arm/mach-mvebu/arm64-common.c | 8 +- arch/arm/mach-mvebu/dram.c | 4 +- arch/arm/mach-omap2/am33xx/emif4.c | 4 +- arch/arm/mach-omap2/omap3/emif4.c | 4 +- arch/arm/mach-omap2/omap3/sdrc.c | 4 +- arch/arm/mach-orion5x/dram.c | 4 +- arch/arm/mach-tegra/board2.c | 4 +- arch/arm/mach-tegra/tegra186/nvtboot_mem.c | 4 +- arch/arm/mach-uniphier/dram_init.c | 4 +- arch/mips/mach-ath79/dram.c| 8 +- arch/mips/mach-pic32/cpu.c | 6 +- arch/mips/mach-pic32/include/mach/ddr.h| 2 +- arch/powerpc/cpu/mpc5xxx/spl_boot.c| 4 +- arch/powerpc/cpu/mpc85xx/cpu.c | 14 +- arch/powerpc/cpu/ppc4xx/44x_spd_ddr2.c | 18 ++- arch/powerpc/cpu/ppc4xx/denali_spd_ddr2.c | 10 +- arch/powerpc/cpu/ppc4xx/sdram.c| 18 ++- arch/powerpc/cpu/ppc4xx/spl_boot.c | 2 +- arch/powerpc/lib/Makefile | 1 + arch/powerpc/lib/setup.c | 32 arch/x86/cpu/broadwell/sdram.c | 4 +- arch/x86/cpu/coreboot/sdram.c | 4 +- arch/x86/cpu/efi/sdram.c | 4 +- arch/x86/cpu/ivybridge/sdram.c | 4 +- arch/x86/cpu/qemu/dram.c | 4 +- arch/x86/cpu/quark/dram.c | 4 +- arch/x86/include/asm/relocate.h| 17 --- arch/x86/include/asm/u-boot-x86.h | 1 - arch/x86/lib/efi/efi.c | 6 +- arch/x86/lib/fsp/fsp_dram.c| 4 +- arch/x86/lib/relocate.c| 2 +- arch/x86/lib/spl.c | 2 +- arch/xtensa/cpu/cpu.c | 5 + arch/xtensa/include/asm/relocate.h | 14 -- arch/xtensa/lib/relocate.c | 2 +- board/AndesTech/adp-ag101p/adp-ag101p.c| 4 +- board/Arcturus/ucp1020/spl.c | 2 +- board/BuS/eb_cpu5282/eb_cpu5282.c | 6 +- board/a3m071/a3m071.c | 6 +- board/a4m072/a4m072.c | 8 +- board/amcc/acadia/memory.c | 8 +- board/amcc/bamboo/bamboo.c | 8 +- board/amcc/bubinga/bubinga.c | 10 +- board/amcc/sequoia/sdram.c | 8 +- board/amcc/walnut/walnut.c | 10 +- board/amcc/yosemite/yosemite.c | 7 +- board/armadeus/apf27/apf27.c | 4 +- board/armltd/vexpress/vexpress_common.c| 4 +- board/armltd/vexpress64/vexpress64.c | 4 +- board/astro/mcf5373l/mcf5373l.c| 6 +- board/beckhoff/mx53cx9020/mx53cx9020.c | 4 +- board/broadcom/bcm23550_w1d/bcm23550_w1d.c | 4 +- board/broadcom/bcm28155_ap/bcm28155_ap.c | 4 +- board/broadcom/bcm_ep/board.c | 4 +- board/broadcom/bcmns2/northstar2.c | 4 +- board/cadence/xtfpga/xtfpga.c | 4 +- board/canmb/canmb.c| 8 +- board/cirrus/edb93xx/edb93xx.c | 4 +-
[U-Boot] [PATCH 2/4] board: advantech: dms-ba16: add the PMIC configuration support
Change the PMIC bulk configuration from auto mode to sync mode to avoid the voltage shutdown issue Signed-off-by: Ken Lin --- board/advantech/dms-ba16/dms-ba16.c | 51 + 1 file changed, 51 insertions(+) diff --git a/board/advantech/dms-ba16/dms-ba16.c b/board/advantech/dms-ba16/dms-ba16.c index a67752f1ca..8aa7ff1659 100644 --- a/board/advantech/dms-ba16/dms-ba16.c +++ b/board/advantech/dms-ba16/dms-ba16.c @@ -534,6 +534,54 @@ static const struct boot_mode board_boot_modes[] = { }; #endif +void pmic_init(void) +{ + +#define DA9063_ADDR 0x58 +#define BCORE2_CONF 0x9D +#define BCORE1_CONF 0x9E +#define BPRO_CONF 0x9F +#define BIO_CONF 0xA0 +#define BMEM_CONF 0xA1 +#define BPERI_CONF 0xA2 +#define MODE_BIT_H 7 +#define MODE_BIT_L 6 + +uchar val; +i2c_set_bus_num(2); + +i2c_read(DA9063_ADDR, BCORE2_CONF, 1, &val, 1); +val |= (1 << MODE_BIT_H); +val &= ~(1 << MODE_BIT_L); +i2c_write(DA9063_ADDR, BCORE2_CONF , 1, &val, 1); + +i2c_read(DA9063_ADDR, BCORE1_CONF, 1, &val, 1); +val |= (1 << MODE_BIT_H); +val &= ~(1 << MODE_BIT_L); +i2c_write(DA9063_ADDR, BCORE1_CONF , 1, &val, 1); + +i2c_read(DA9063_ADDR, BPRO_CONF, 1, &val, 1); +val |= (1 << MODE_BIT_H); +val &= ~(1 << MODE_BIT_L); +i2c_write(DA9063_ADDR, BPRO_CONF , 1, &val, 1); + +i2c_read(DA9063_ADDR, BIO_CONF, 1, &val, 1); +val |= (1 << MODE_BIT_H); +val &= ~(1 << MODE_BIT_L); +i2c_write(DA9063_ADDR, BIO_CONF , 1, &val, 1); + +i2c_read(DA9063_ADDR, BMEM_CONF, 1, &val, 1); +val |= (1 << MODE_BIT_H); +val &= ~(1 << MODE_BIT_L); +i2c_write(DA9063_ADDR, BMEM_CONF , 1, &val, 1); + +i2c_read(DA9063_ADDR, BPERI_CONF, 1, &val, 1); +val |= (1 << MODE_BIT_H); +val &= ~(1 << MODE_BIT_L); +i2c_write(DA9063_ADDR, BPERI_CONF , 1, &val, 1); + +} + int board_late_init(void) { #ifdef CONFIG_CMD_BMODE @@ -563,6 +611,9 @@ int board_late_init(void) setup_ba16_sata(); #endif +/* board specific pmic init */ +pmic_init(); + return 0; } -- 2.11.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 01/16] board_f: Drop board_type parameter from initdram()
On 31.03.2017 16:40, Simon Glass wrote: It looks like only cm5200 and tqm8xx use this feature, so we don't really need it in generic code. Drop it and have the users access gd->board_type directly. Signed-off-by: Simon Glass Reviewed-by: Stefan Roese Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] fatls returncode
2017-03-27 10:51 GMT+02:00 Wolfgang Denk : > Dear Mirza, > > In message > you > wrote: >> >> > Please update to a recent versionof the code. The return code >> > handling has probably been fixed by this commit: >> > >> > 0a04ed8 2015-09-11 17:15:21 -0400 FIX: fat: Provide correct return co= >> de from disk_{read|write} to upper layers >> >> I did an update (cherry-picked FAT related commits from upstream), but >> I still get the same result. > > I see. > >> Analyzing the code in fs/fat/fat.c:do_fat_read_at (which is called by >> the fatls command) one can see that "ret" is set in three locations. >> In my case I never reach any of these three, since my exit path is: >> >> fs/fat/fat.c: >> >> 1139 /* If end of rootdir reached */ >> 1140 if (rootdir_end) { >> 1141 if (dols == LS_ROOT) { >> 1142 printf("\n%d file(s), %d dir(s)\n\n", >> 1143files, dirs); >> 1144 *size = 0; >> 1145 } >> 1146 goto exit; >> 1147 } > > OK... Understood. > >> So either this exit path is actually an error and it is correct as-is, >> or this path should set "ret = 0". My knowledge of FAT is limited so I >> can not really tell which it should be but there is no indications in >> the code/comments that this exit path is an error. > > I think the exit is OK, as we have reached the end of the root > directory, but it should set "ret = 0;" before the goto. > > But then, I am not an expert on this code either, so I added Sergei > Shtylyov on cc: who added this line with > > commit ac4977719e157bcb3c45c70d9dd781164727530d > Author: Sergei Shtylyov > Date: Mon Aug 8 09:38:33 2011 + > > fat: fix crash with big sector size > > > Sergei, do you agree that ret = 0 should be set before the "goto > exit" here? I also found the commit that removed the "ret = 0" since it did indeed exist earlier. 1ad0b98a067a ("fat: Prepare API change for files greater than 2GB") Added author on CC. That commit also removed another occurrence of "ret = 0" which I question if that was correct as well. -- Med Vänliga Hälsningar / Best Regards *** Mirza Krak Host Mobility AB mirza.k...@hostmobility.com Anders Personsgatan 12, 416 64 Göteborg Sweden http://www.hostmobility.com Direct: +46 31 31 32 704 Phone: +46 31 31 32 700 Fax: +46 31 80 67 51 Mobile: +46 730 28 06 22 *** ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 14/18] sunxi: Pine64: defconfig: enable SPL FIT support
2017年3月29日 14:57于 Maxime Ripard 写道: > > On Tue, Mar 28, 2017 at 01:45:22AM +0100, Andre Przywara wrote: > > The Pine64 (and all other 64-bit Allwinner boards) need to load an > > ARM Trusted Firmware image beside the actual U-Boot proper. > > This can now be easily achieved by using the just extended SPL FIT > > loading support, so enable it in the Pine64 defconfig. > > Also add the FIT image as a build target to 64-bit sunxi board to > > trigger the respective Makefile rules. > > > > Signed-off-by: Andre Przywara > > --- > > configs/pine64_plus_defconfig | 6 ++ > > include/configs/sunxi-common.h | 4 > > 2 files changed, 10 insertions(+) > > > > diff --git a/configs/pine64_plus_defconfig b/configs/pine64_plus_defconfig > > index 92bda60..8a90579 100644 > > --- a/configs/pine64_plus_defconfig > > +++ b/configs/pine64_plus_defconfig > > @@ -3,9 +3,14 @@ CONFIG_ARCH_SUNXI=y > > CONFIG_MACH_SUN50I=y > > CONFIG_RESERVE_ALLWINNER_BOOT0_HEADER=y > > CONFIG_DEFAULT_DEVICE_TREE="sun50i-a64-pine64-plus" > > +CONFIG_OF_LIST="sun50i-a64-pine64 sun50i-a64-pine64-plus" > > # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set > > CONFIG_CONSOLE_MUX=y > > CONFIG_SPL=y > > +CONFIG_FIT=y > > +CONFIG_SPL_FIT=y > > +CONFIG_SPL_LOAD_FIT=y > > +CONFIG_SPL_OF_LIBFDT=y > > Again, this doesn't make any sense to enable it in *all* our > defconfigs. If this is something that should be enabled by default for > the A64 support, then do so in Kconfig directly. Here it's "strongly recommended" to use SPL FIT support, but not "must", as someone may use U-Boot to execute their own code that wants EL3. In that situation SPL FIT support shouldn't be present. U-Boot is not Linux Loader, so we should give people the permission to disable it; however, U-Boot is mostly used to load and execute Linux, so this should be defaultly enabled -- is this correctly the meaning of defconfig? > > Maxime > > -- > Maxime Ripard, Free Electrons > Embedded Linux and Kernel engineering > http://free-electrons.com ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 0/7] Enable MIPI dsi display for rk3399
From: "eric.gao" This serial patchs enable mipi dsi display for rk3399,and let the system log print to lcd. The function of each patch is decribe in the following.Thank you. Patch 1: Fix system halt when we enable bucks of PMIC rk808. Patch 2: Enable i2c for rk3399. Patch 3: Enable PMIC rk808 for display system using. Patch 4: Enable rkclk init,prepare aclk dclk for vop. Patch 5: Add mipi display,panel driver and so on. Patch 6: Enable print log to lcd. Patch 7: Fix crash when scrolling screen. eric.gao (7): system halt when we enable bucks of PMIC rk808 Enable i2c for rk3399 Enable RK808 for rk3399 evb Enable rkclk init function Add mipi display support for rk3399 && rk3288 Enable print log file to lcd crash when scroll screen arch/arm/dts/rk3399-evb.dts | 141 + arch/arm/dts/rk3399.dtsi | 88 ++ arch/arm/include/asm/arch-rockchip/cru_rk3399.h | 2 +- arch/arm/include/asm/arch-rockchip/mipi_rk3399.h | 203 + arch/arm/include/asm/arch-rockchip/vop_rk3288.h | 1 + arch/arm/mach-rockchip/rk3399/syscon_rk3399.c| 1 + configs/evb-rk3399_defconfig | 11 + drivers/clk/rockchip/clk_rk3399.c| 4 + drivers/i2c/rk_i2c.c | 1 + drivers/video/Kconfig| 2 + drivers/video/console_normal.c | 2 +- drivers/video/rockchip/Kconfig | 44 +++ drivers/video/rockchip/Makefile | 7 +- drivers/video/rockchip/panel.c | 81 + drivers/video/rockchip/rk_mipi.c | 371 +++ drivers/video/rockchip/rk_vop.c | 12 +- include/configs/rk3399_common.h | 5 +- 17 files changed, 969 insertions(+), 7 deletions(-) create mode 100644 arch/arm/include/asm/arch-rockchip/mipi_rk3399.h create mode 100644 drivers/video/rockchip/Kconfig create mode 100644 drivers/video/rockchip/panel.c create mode 100644 drivers/video/rockchip/rk_mipi.c -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 4/7] Enable rkclk init function
From: "eric.gao" Signed-off-by: eric.gao --- drivers/clk/rockchip/clk_rk3399.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/clk/rockchip/clk_rk3399.c b/drivers/clk/rockchip/clk_rk3399.c index 922ce7e..cfcd1e4 100644 --- a/drivers/clk/rockchip/clk_rk3399.c +++ b/drivers/clk/rockchip/clk_rk3399.c @@ -20,6 +20,10 @@ DECLARE_GLOBAL_DATA_PTR; +#ifndef CONFIG_SPL_BUILD +#define CONFIG_SPL_BUILD +#endif + #if CONFIG_IS_ENABLED(OF_PLATDATA) struct rk3399_clk_plat { struct dtd_rockchip_rk3399_cru dtd; -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 6/7] Enable print log file to lcd
From: "eric.gao" Signed-off-by: eric.gao --- configs/evb-rk3399_defconfig| 1 + include/configs/rk3399_common.h | 5 - 2 files changed, 5 insertions(+), 1 deletion(-) diff --git a/configs/evb-rk3399_defconfig b/configs/evb-rk3399_defconfig index b9cb0e8..89b2e17 100644 --- a/configs/evb-rk3399_defconfig +++ b/configs/evb-rk3399_defconfig @@ -68,3 +68,4 @@ CONFIG_DM_VIDEO=y CONFIG_DISPLAY=y CONFIG_VIDEO_ROCKCHIP=y CONFIG_DISPLAY_MIPI=y +CONFIG_VIDCONSOLE_AS_LCD=y diff --git a/include/configs/rk3399_common.h b/include/configs/rk3399_common.h index 4ba81ac..6183f4e 100644 --- a/include/configs/rk3399_common.h +++ b/include/configs/rk3399_common.h @@ -69,7 +69,10 @@ #define CONFIG_EXTRA_ENV_SETTINGS \ ENV_MEM_LAYOUT_SETTINGS \ "partitions=" PARTS_DEFAULT \ - BOOTENV + BOOTENV \ + "stdin=serial,cros-ec-keyb\0" \ + "stdout=serial,vidconsole\0" \ + "stderr=serial,vidconsole\0" #endif -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/7] Enable i2c for rk3399
From: "eric.gao" Signed-off-by: eric.gao --- arch/arm/dts/rk3399.dtsi | 16 configs/evb-rk3399_defconfig | 1 + drivers/i2c/rk_i2c.c | 1 + 3 files changed, 18 insertions(+) diff --git a/arch/arm/dts/rk3399.dtsi b/arch/arm/dts/rk3399.dtsi index 456fdb6..93e3bf4 100644 --- a/arch/arm/dts/rk3399.dtsi +++ b/arch/arm/dts/rk3399.dtsi @@ -26,6 +26,7 @@ serial4 = &uart4; mmc0 = &sdhci; mmc1 = &sdmmc; + i2c0 = &i2c0; }; cpus { @@ -651,6 +652,21 @@ status = "disabled"; }; + i2c0: i2c@ff3c { + compatible = "rockchip,rk3399-i2c"; + reg = <0x0 0xff3c 0x0 0x1000>; + assigned-clocks = <&pmucru SCLK_I2C0_PMU>; + assigned-clock-rates = <2>; + clocks = <&pmucru SCLK_I2C0_PMU>, <&pmucru PCLK_I2C0_PMU>; + clock-names = "i2c", "pclk"; + interrupts = ; + pinctrl-names = "default"; + pinctrl-0 = <&i2c0_xfer>; + #address-cells = <1>; + #size-cells = <0>; + status = "disabled"; + }; + pinctrl: pinctrl { u-boot,dm-pre-reloc; compatible = "rockchip,rk3399-pinctrl"; diff --git a/configs/evb-rk3399_defconfig b/configs/evb-rk3399_defconfig index bedc1fd..2e2f9a8 100644 --- a/configs/evb-rk3399_defconfig +++ b/configs/evb-rk3399_defconfig @@ -58,3 +58,4 @@ CONFIG_USB_EHCI_GENERIC=y CONFIG_USB_STORAGE=y CONFIG_USE_TINY_PRINTF=y CONFIG_ERRNO_STR=y +CONFIG_SYS_I2C_ROCKCHIP=y diff --git a/drivers/i2c/rk_i2c.c b/drivers/i2c/rk_i2c.c index 7c701cb..a4c8c2ba 100644 --- a/drivers/i2c/rk_i2c.c +++ b/drivers/i2c/rk_i2c.c @@ -381,6 +381,7 @@ static const struct dm_i2c_ops rockchip_i2c_ops = { static const struct udevice_id rockchip_i2c_ids[] = { { .compatible = "rockchip,rk3288-i2c" }, + { .compatible = "rockchip,rk3399-i2c" }, { } }; -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 0/2] Improve Raspberry Pi mmc writes
When experimenting with fastboot from U-Boot on the Raspberry Pi 3 we found that the writes to the sdcard are much more slow than when accessing it from the userspace. These two patches speed up the write and allow us to reliably write the sdcard from U-Boot. Alex Deymo (1): mmc: sdhci: Wait for SDHCI_INT_DATA_END when transferring. Jocelyn Bohr (1): mmc: bcm2835_sdhci: Speed up mmc writes. drivers/mmc/bcm2835_sdhci.c | 8 ++-- drivers/mmc/sdhci.c | 15 +++ 2 files changed, 17 insertions(+), 6 deletions(-) -- 2.12.2.564.g063fe858b8-goog ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH RESEND v6] usb: gadget: avoid variable name clipping in cb_getvar
From: Nicolas Le Bayon Instead of using a fixed-size array to store variable name, preferring a dynamic allocation treats correctly all variable name lengths. Variable names are growing through releases and features. By this way, name clipping is prevented. Signed-off-by: Nicolas Le Bayon Reviewed-by: Marek Vasut Acked-by: Lukasz Majewski --- Changes in v2: - instead of using a bigger fixed size, use malloc to fit with size needs Changes in v3: - v2 was an error (intermediate version), so propose a complete one Changes in v4: - be more explicit and detailed in label and description fields - remove intermediate variable only used one time - be more explicit in error message - fix indent issue Changes in v5: - drop an unuseful error() call Changes in v6: - add Marek review approval drivers/usb/gadget/f_fastboot.c | 12 ++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/drivers/usb/gadget/f_fastboot.c b/drivers/usb/gadget/f_fastboot.c index 2160b1c..7cd6d24 100644 --- a/drivers/usb/gadget/f_fastboot.c +++ b/drivers/usb/gadget/f_fastboot.c @@ -432,9 +432,15 @@ static void cb_getvar(struct usb_ep *ep, struct usb_request *req) else strcpy(response, "FAILValue not set"); } else { - char envstr[32]; + char *envstr; - snprintf(envstr, sizeof(envstr) - 1, "fastboot.%s", cmd); + envstr = malloc(strlen("fastboot.") + strlen(cmd) + 1); + if (!envstr) { + fastboot_tx_write_str("FAILmalloc error"); + return; + } + + sprintf(envstr, "fastboot.%s", cmd); s = getenv(envstr); if (s) { strncat(response, s, chars_left); @@ -442,6 +448,8 @@ static void cb_getvar(struct usb_ep *ep, struct usb_request *req) printf("WARNING: unknown variable: %s\n", cmd); strcpy(response, "FAILVariable not implemented"); } + + free(envstr); } fastboot_tx_write_str(response); } -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 12/14] fdt: eth_fixup: Add hook for board to override MAC
Hey Joe, On 26-03-17 16:10, Joe Hershberger wrote: Hi Oliver, On Sun, Dec 11, 2016 at 3:27 PM, Simon Glass wrote: Hi Oliver, On 9 December 2016 at 02:25, Olliver Schinagl wrote: Hey simon On December 8, 2016 11:21:32 PM CET, Simon Glass wrote: Hi Oliver, On 7 December 2016 at 02:26, Olliver Schinagl wrote: On December 7, 2016 4:47:23 AM CET, Simon Glass wrote: Hi Oliver, On 5 December 2016 at 03:28, Olliver Schinagl wrote: Hey Simon, On 05-12-16 07:24, Simon Glass wrote: Hi Oliver, On 2 December 2016 at 03:16, Olliver Schinagl wrote: Hey Joe, On 30-11-16 21:40, Joe Hershberger wrote: On Fri, Nov 25, 2016 at 9:30 AM, Olliver Schinagl wrote: This patch adds a method for the board to set the MAC address if the environment is not yet set. The environment based MAC addresses are not touched, but if the fdt has an alias set, it is parsed and put into the environment. E.g. The environment contains ethaddr and eth1addr, and the fdt contains an ethernet1 nothing happens. If the fdt contains ethernet2 however, it is parsed and inserted into the environment as eth2addr. Signed-off-by: Olliver Schinagl --- common/fdt_support.c | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/common/fdt_support.c b/common/fdt_support.c index c34a13c..f127392 100644 --- a/common/fdt_support.c +++ b/common/fdt_support.c @@ -465,6 +465,11 @@ int fdt_fixup_memory(void *blob, u64 start, u64 size) return fdt_fixup_memory_banks(blob, &start, &size, 1); } +__weak int board_get_enetaddr(const int i, unsigned char *mac_addr) Ugh. This collides with a function in board/v38b/ethaddr.c and in board/intercontrol/digsy_mtc/digsy_mtc.c Also, it's so generic, and only gets called by the fdt fixup stuff... This function should probably be named in such a way that its association with fdt is clear. I did not notice that, sorry! But naming suggestions are welcome :) Right now, I use it in two unrelated spots however. from the fdt as seen above and in a subclass driver (which will come up for review) as suggested by Simon. There I do: +static int sunxi_gmac_eth_read_rom_hwaddr(struct udevice *dev) +{ + struct eth_pdata *pdata = dev_get_platdata(dev); + + return board_get_enetaddr(dev->seq, pdata->enetaddr); +} + const struct eth_ops sunxi_gmac_eth_ops = { .start = designware_eth_start, .send = designware_eth_send, @@ -102,6 +110,7 @@ const struct eth_ops sunxi_gmac_eth_ops = { .free_pkt = designware_eth_free_pkt, .stop = designware_eth_stop, .write_hwaddr = designware_eth_write_hwaddr, + .read_rom_hwaddr= sunxi_gmac_eth_read_rom_hwaddr, }; which is completly unrelated to the fdt. So naming suggestion or overal suggestion how to handle this nice and generically? Based from the name however I would think that all board_get_enetaddr's work the same however so should have been interchangeable? Or was that silly thinking? Would it be possible to use a name without 'board' in it? I think this / hope is actually sunxi-specific code, not board-specific? You are actually correct, we take the serial number of the SoC (sunxi specific) and generate a serial/MAC from it. So nothing to do with the board. So I can just name it sunxi_gen_enetaddr(). Would that be then (much) better? The reason why I went to 'board' with my mind, is because a) the original mac gen code and b) the location was in board/sunxi/board.c. I think it is thus also sensible to move it out of board/sunxi/board.c as indeed, it has nothing to do with board(s). That sounds good to me - and you should be able to call it directly >from the driver and avoid any weak functions, right? The subclass driver can, the fdt fixup however still needs a weak fdt_get_enetaddr()? (Which in our case calls then sunxi_get_enetaddr() i think.) OK - I feel that the fdt fixups need a bit of thought. At the moment it is all pretty ad-hoc. Yeah i think i agree, but i guess thats a separate cleanup step generally, no? OK - are you able to take a look at this? Any update on this or any of the other patches in your series that I did not apply last release? I was expecting a v2 to address some things such as this patch. I have a few after rebasing u-boot-net/master and I just started yesterday to get back up to speed. I'll double check all review comments and send a v2 with the remaining patches. Sorry for taking so long here! Olliver Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/7] system halt when we enable bucks of PMIC rk808
From: "eric.gao" if we enable PMIC rk808,the system will halt at very early stage ,log is shown as bellow. INFO:plat_rockchip_pmu_init(1211): pd status 3e INFO:BL31: Initializing runtime services INFO:BL31: Preparing for EL3 exit to normal world INFO:Entry point address = 0x20 INFO:SPSR = 0x3c9 time 44561b, 0 (<compatible) { <<-- if (!strcmp(of_match->compatible, compat)) { *of_idp = of_match; return 0; } of_match++; } Signed-off-by: eric.gao --- arch/arm/mach-rockchip/rk3399/syscon_rk3399.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/mach-rockchip/rk3399/syscon_rk3399.c b/arch/arm/mach-rockchip/rk3399/syscon_rk3399.c index d32985b..74d4552 100644 --- a/arch/arm/mach-rockchip/rk3399/syscon_rk3399.c +++ b/arch/arm/mach-rockchip/rk3399/syscon_rk3399.c @@ -14,6 +14,7 @@ static const struct udevice_id rk3399_syscon_ids[] = { { .compatible = "rockchip,rk3399-pmugrf", .data = ROCKCHIP_SYSCON_PMUGRF }, { .compatible = "rockchip,rk3399-pmusgrf", .data = ROCKCHIP_SYSCON_PMUSGRF }, { .compatible = "rockchip,rk3399-cic", .data = ROCKCHIP_SYSCON_CIC }, + { } }; U_BOOT_DRIVER(syscon_rk3399) = { -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/2] mmc: bcm2835_sdhci: Speed up mmc writes.
From: Jocelyn Bohr The linux kernel driver for this module does not use a delay when writing to the SDHCI_BUFFER register. This patch mimics that behavior in order to speed up the mmc writes on the Raspberry Pi. Signed-off-by: Alex Deymo --- drivers/mmc/bcm2835_sdhci.c | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/mmc/bcm2835_sdhci.c b/drivers/mmc/bcm2835_sdhci.c index 29c2a85812..20079bce48 100644 --- a/drivers/mmc/bcm2835_sdhci.c +++ b/drivers/mmc/bcm2835_sdhci.c @@ -44,6 +44,7 @@ /* 400KHz is max freq for card ID etc. Use that as min */ #define MIN_FREQ 40 +#define SDHCI_BUFFER 0x20 struct bcm2835_sdhci_host { struct sdhci_host host; @@ -69,8 +70,11 @@ static inline void bcm2835_sdhci_raw_writel(struct sdhci_host *host, u32 val, * (Which is just as well - otherwise we'd have to nobble the DMA engine * too) */ - while (timer_get_us() - bcm_host->last_write < bcm_host->twoticks_delay) - ; + if (reg != SDHCI_BUFFER) { + while (timer_get_us() - bcm_host->last_write < + bcm_host->twoticks_delay) + ; + } writel(val, host->ioaddr + reg); bcm_host->last_write = timer_get_us(); -- 2.12.2.564.g063fe858b8-goog ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/2] mmc: sdhci: Wait for SDHCI_INT_DATA_END when transferring.
sdhci_transfer_data() function transfers the blocks passed up to the number of blocks defined in mmc_data, but returns immediately once all the blocks are transferred, even if the loop exit condition is not met (bit SDHCI_INT_DATA_END set in the STATUS word). When doing multiple writes to mmc, returning right after the last block is transferred can cause the write to fail when sending the MMC_CMD_STOP_TRANSMISSION command right after the MMC_CMD_WRITE_MULTIPLE_BLOCK command, leaving the mmc driver in an unconsistent state until reboot. This error was observed in the rpi3 board. This patch waits for the SDHCI_INT_DATA_END bit to be set even after sending all the blocks. Test: Reliably wrote 2GiB of data to mmc in a rpi3. Signed-off-by: Alex Deymo --- drivers/mmc/sdhci.c | 15 +++ 1 file changed, 11 insertions(+), 4 deletions(-) diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c index c94d58db65..b745977b3f 100644 --- a/drivers/mmc/sdhci.c +++ b/drivers/mmc/sdhci.c @@ -72,6 +72,7 @@ static int sdhci_transfer_data(struct sdhci_host *host, struct mmc_data *data, unsigned int start_addr) { unsigned int stat, rdy, mask, timeout, block = 0; + bool transfer_done = false; #ifdef CONFIG_MMC_SDHCI_SDMA unsigned char ctrl; ctrl = sdhci_readb(host, SDHCI_HOST_CONTROL); @@ -89,17 +90,23 @@ static int sdhci_transfer_data(struct sdhci_host *host, struct mmc_data *data, __func__, stat); return -EIO; } - if (stat & rdy) { + if (!transfer_done && (stat & rdy)) { if (!(sdhci_readl(host, SDHCI_PRESENT_STATE) & mask)) continue; sdhci_writel(host, rdy, SDHCI_INT_STATUS); sdhci_transfer_pio(host, data); data->dest += data->blocksize; - if (++block >= data->blocks) - break; + if (++block >= data->blocks) { + /* Keep looping until the SDHCI_INT_DATA_END is +* cleared, even if we finished sending all the +* blocks. +*/ + transfer_done = true; + continue; + } } #ifdef CONFIG_MMC_SDHCI_SDMA - if (stat & SDHCI_INT_DMA_END) { + if (!transfer_done && (stat & SDHCI_INT_DMA_END)) { sdhci_writel(host, SDHCI_INT_DMA_END, SDHCI_INT_STATUS); start_addr &= ~(SDHCI_DEFAULT_BOUNDARY_SIZE - 1); start_addr += SDHCI_DEFAULT_BOUNDARY_SIZE; -- 2.12.2.564.g063fe858b8-goog ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 6/6] cmd: Add "boot_android" command.
The new "boot_android" command simply executes the Android Bootloader flow. This receives the location (interface, dev, partition) of the Android "misc" partition which is then used to lookup and infer the kernel and system images that should be booted from the passed slot. Test: Booted a rpi3 build with Android Things. Signed-off-by: Alex Deymo --- README | 6 +++ cmd/Kconfig| 10 + cmd/Makefile | 1 + cmd/boot_android.c | 126 + 4 files changed, 143 insertions(+) create mode 100644 cmd/boot_android.c diff --git a/README b/README index 384cc6aabb..5f62e14d94 100644 --- a/README +++ b/README @@ -1484,6 +1484,12 @@ The following options need to be configured: sending again an USB request to the device. - Android Bootloader support: + CONFIG_CMD_BOOT_ANDROID + This enables the command "boot_android" which executes the + Android Bootloader flow. Enabling CONFIG_CMD_FASTBOOT is + recommended to support the Android Fastboot protocol as part + of the bootloader. + CONFIG_ANDROID_BOOTLOADER This enables support for the Android bootloader flow. Android devices can boot in normal mode, recovery mode or bootloader diff --git a/cmd/Kconfig b/cmd/Kconfig index 87a445d269..c4c22464b1 100644 --- a/cmd/Kconfig +++ b/cmd/Kconfig @@ -431,6 +431,16 @@ config CMD_LOAD_ANDROID define the size and kernel address on the header, which are used by this command. +config CMD_BOOT_ANDROID + bool "boot_android" + default n + depends on ANDROID_BOOTLOADER + help + Performs the Android Bootloader boot flow, loading the appropriate + Android image (normal kernel, recovery kernel or "bootloader" mode) + and booting it. The boot mode is determined by the contents of the + Android Bootloader Message. + config CMD_FLASH bool "flinfo, erase, protect" default y diff --git a/cmd/Makefile b/cmd/Makefile index 2f75dab040..348cf75386 100644 --- a/cmd/Makefile +++ b/cmd/Makefile @@ -22,6 +22,7 @@ obj-$(CONFIG_CMD_BDI) += bdinfo.o obj-$(CONFIG_CMD_BEDBUG) += bedbug.o obj-$(CONFIG_CMD_BLOCK_CACHE) += blkcache.o obj-$(CONFIG_CMD_BMP) += bmp.o +obj-$(CONFIG_CMD_BOOT_ANDROID) += boot_android.o obj-$(CONFIG_CMD_BOOTEFI) += bootefi.o obj-$(CONFIG_CMD_BOOTMENU) += bootmenu.o obj-$(CONFIG_CMD_BOOTLDR) += bootldr.o diff --git a/cmd/boot_android.c b/cmd/boot_android.c new file mode 100644 index 00..067d9c7637 --- /dev/null +++ b/cmd/boot_android.c @@ -0,0 +1,126 @@ +/* + * Copyright (C) 2016 The Android Open Source Project + * + * SPDX-License-Identifier: BSD-2-Clause + */ + +#include +#include +#include + +/** + * part_get_info_by_dev_and_name - Parse a device number and partition name + * string in the form of "device_num;partition_name", for example "0;misc". + * If the partition is found, sets dev_desc and part_info accordingly with the + * information of the partition with the given partition_name. + * + * @dev_iface: Device interface. + * @dev_part_str: Input string argument, like "0;misc". + * @dev_desc: Place to put the device description pointer. + * @part_info: Place to put the partition information. + * @return 0 on success, or -1 on error + */ +static int part_get_info_by_dev_and_name(const char *dev_iface, +const char *dev_part_str, +struct blk_desc **dev_desc, +disk_partition_t *part_info) +{ + char *ep; + const char *part_str; + int dev_num; + + part_str = strchr(dev_part_str, ';'); + if (!part_str) + return -1; + + dev_num = simple_strtoul(dev_part_str, &ep, 16); + if (ep != part_str) { + /* Not all the first part before the ; was parsed. */ + return -1; + } + part_str++; + + *dev_desc = blk_get_dev(dev_iface, dev_num); + if (!*dev_desc) { + printf("Could not find %s %d\n", dev_iface, dev_num); + return -1; + } + if (part_get_info_by_name(*dev_desc, part_str, part_info) < 0) { + printf("Could not find \"%s\" partition\n", part_str); + return -1; + } + return 0; +} + +static int do_boot_android(cmd_tbl_t *cmdtp, int flag, int argc, + char * const argv[]) +{ + unsigned long load_address; + int ret = CMD_RET_SUCCESS; + char *addr_arg_endp, *addr_str; + struct blk_desc *dev_desc; + disk_partition_t part_info; + const char *misc_part_iface; + const char *misc_part_desc; + + if (argc < 4) + return CMD_RET_USAGE; + if (argc > 5) + return CMD_RET_USAGE; + + if (argc >= 5) {
[U-Boot] [PATCH 5/7] Add mipi display support for rk3399 && rk3288
From: "eric.gao" Signed-off-by: eric.gao --- arch/arm/dts/rk3399-evb.dts | 33 ++ arch/arm/dts/rk3399.dtsi | 72 + arch/arm/include/asm/arch-rockchip/cru_rk3399.h | 2 +- arch/arm/include/asm/arch-rockchip/mipi_rk3399.h | 203 + arch/arm/include/asm/arch-rockchip/vop_rk3288.h | 1 + configs/evb-rk3399_defconfig | 4 + drivers/video/Kconfig| 2 + drivers/video/rockchip/Kconfig | 44 +++ drivers/video/rockchip/Makefile | 7 +- drivers/video/rockchip/panel.c | 81 + drivers/video/rockchip/rk_mipi.c | 371 +++ drivers/video/rockchip/rk_vop.c | 12 +- 12 files changed, 827 insertions(+), 5 deletions(-) create mode 100644 arch/arm/include/asm/arch-rockchip/mipi_rk3399.h create mode 100644 drivers/video/rockchip/Kconfig create mode 100644 drivers/video/rockchip/panel.c create mode 100644 drivers/video/rockchip/rk_mipi.c diff --git a/arch/arm/dts/rk3399-evb.dts b/arch/arm/dts/rk3399-evb.dts index 7a889c7..abb00e8 100644 --- a/arch/arm/dts/rk3399-evb.dts +++ b/arch/arm/dts/rk3399-evb.dts @@ -52,6 +52,10 @@ gpio = <&gpio4 25 GPIO_ACTIVE_HIGH>; }; + panel:panel { + compatible = "BOE,TV080WUM"; + status = "disabled"; + }; vccsys: vccsys { compatible = "regulator-fixed"; regulator-name = "vccsys"; @@ -218,6 +222,35 @@ }; }; +&panel { + backlight_en = <&gpio1 13 GPIO_ACTIVE_HIGH>; + backlight_pwm = <&gpio4 18 GPIO_ACTIVE_HIGH>; + power-supply = <&vcc33_lcd>; + status = "okay"; +}; + +&mipi_dsi { + status = "okay"; + display-timings { + timing0 { + bits-per-pixel = <24>; + clock-frequency = <16000>; + hfront-porch = <120>; + hsync-len = <20>; + hback-porch = <21>; + hactive = <1200>; + vfront-porch = <21>; + vsync-len = <3>; + vback-porch = <18>; + vactive = <1920>; + hsync-active = <0>; + vsync-active = <0>; + de-active = <1>; + pixelclk-active = <0>; + }; + }; +}; + &pinctrl { pmic { pmic_int_l: pmic-int-l { diff --git a/arch/arm/dts/rk3399.dtsi b/arch/arm/dts/rk3399.dtsi index 93e3bf4..c82e674 100644 --- a/arch/arm/dts/rk3399.dtsi +++ b/arch/arm/dts/rk3399.dtsi @@ -667,6 +667,78 @@ status = "disabled"; }; + vopl: vop@ff8f { + u-boot,dm-pre-reloc; + compatible = "rockchip,rk3399-vop-lit"; + reg = <0x0 0xff8f 0x0 0x3efc>; + interrupts = ; + clocks = <&cru ACLK_VOP1>, <&cru DCLK_VOP1>, <&cru HCLK_VOP1>; + clock-names = "aclk_vop", "dclk_vop", "hclk_vop"; + resets = <&cru SRST_A_VOP1>, <&cru SRST_H_VOP1>, <&cru SRST_D_VOP1>; + reset-names = "axi", "ahb", "dclk"; + status = "okay"; + vopl_out: port { + #address-cells = <1>; + #size-cells = <0>; + vopl_out_mipi: endpoint@0 { + reg = <3>; + remote-endpoint = <&mipi_in_vopl>; + }; + }; + }; + + vopb: vop@ff90 { + u-boot,dm-pre-reloc; + compatible = "rockchip,rk3399-vop-big"; + reg = <0x0 0xff90 0x0 0x3efc>; + interrupts = ; + clocks = <&cru ACLK_VOP0>, <&cru DCLK_VOP0>, <&cru HCLK_VOP0>; + #clock-cells = <0>; + clock-names = "aclk_vop", "dclk_vop", "hclk_vop"; + resets = <&cru SRST_A_VOP0>, <&cru SRST_H_VOP0>, <&cru SRST_D_VOP0>; + reset-names = "axi", "ahb", "dclk"; + /*power-domains = <&power RK3399_PD_VOPB>;*/ + status = "okay"; + vopb_out: port { + #address-cells = <1>; + #size-cells = <0>; + vopb_out_mipi: endpoint@0 { + reg = <3>; + remote-endpoint = <&mipi_in_vopb>; + }; + }; + }; + + mipi_dsi: mipi@ff96 { + compatible = "rockchip,rk3399_mipi_dsi"; + reg = <0x0 0xff96 0x0 0x8000>; + interrupts = ; + clocks = <&cru SCLK_MIPIDPHY_REF>, <&cru PCLK_MIPI_DSI0>, +<&cru SCLK_DPHY_TX0_CFG>; + clock-names = "ref", "pclk", "phy_cfg"; + rockchip,grf = <&grf>; + #address-cells = <1>; + #size-cells = <0
Re: [U-Boot] [PATCH 00/16] RFC: Board init using driver model
Hi York, On 22 March 2017 at 10:00, york sun wrote: > On 03/19/2017 11:59 AM, Simon Glass wrote: >> At present we have a lot of ad-hoc init functions related to boards, for >> example board_early_init_f(), board_misc_init_f() and dram_init(). >> >> There are used in different ways by different boards as useful hooks to >> do the required init and sequence it correctly. Some functions are always >> enabled but have a __weak default. Some are controlled by the existence >> of a CONFIG. >> >> There are two main init sequences: board_init_f() (f for running from >> read-only flash) which runs before relocation and board_init_r() (r for >> relocated) which runs afterwards. >> >> One problem with the current sequence is that it has a lot of >> arch-specific #ifdefs around various functions. There are also #ifdefs >> for various features. There has been quite a bit of discussion about how >> to tidy this up and at least one RFC series[1]. >> >> Now that we have driver model we can use this to deal with the init >> sequences. This approach has several advantages: >> >> - We have a path to remove the #ifdefs >> - It is easy for multiple parts of the code to implement the same hook >> - We can track what is called and what is not >> - We don't need weak functions >> - We can eventually adjust the sequence to improve naming or to add new >> init phases >> - It provides a model for how we might deal with ft_board_setup() and >> friends >> >> This series starts the process of replacing the pre-relocation init >> sequence with a driver-model solution. > > I like the idea to be able to use DM earlier. Well actually my series does not allow that. Here is the start of the init sequence with u-boot-dm/rmb-working applied: static const init_fnc_t init_sequence_f[] = { setup_mon_len, #ifdef CONFIG_OF_CONTROL fdtdec_setup, #endif #ifdef CONFIG_TRACE trace_early_init, #endif initf_malloc, initf_console_record, #if defined(CONFIG_HAVE_FSP) arch_fsp_init, #endif arch_cpu_init, /* basic arch cpu dependent setup */ mach_cpu_init, /* SoC/machine dependent CPU setup */ initf_dm, Of these: - Setting up device tree must happen before DM - trace could be moved later, but then you lose tracing of DM init - malloc() is needed - recording console could move, but as it is it records DM init console debug output, which could be useful - arch_fsp_init() and arch_cpu_init() and mach_cpu_init() could perhaps move later depending on how we define them Anyway I'm interested in your suggestions. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 7/7] crash when scroll screen
From: "eric.gao" After enable log printing to lcd,when the screen start scroll,the system crash.And the log is shown as bellow. "Synchronous Abort" handler, esr 0x9645 "Synchronous Abort" handler, esr 0x9645 Checking the source code, we found that the variate "pixels" get a wrong value. int pixels = VIDEO_FONT_HEIGHT * vid_priv->line_length; "pixels" here means the value of pixels for a character,rather than the byte for a character. so the variate "pixels" is 4 times bigger than it's exact value. which will cause the memory overflow when the cpu run the following code. for (i = 0; i < pixels; i++) *dst++ = clr; << Signed-off-by: eric.gao --- drivers/video/console_normal.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/video/console_normal.c b/drivers/video/console_normal.c index 89a55dd..b627d48 100644 --- a/drivers/video/console_normal.c +++ b/drivers/video/console_normal.c @@ -18,7 +18,7 @@ static int console_normal_set_row(struct udevice *dev, uint row, int clr) { struct video_priv *vid_priv = dev_get_uclass_priv(dev->parent); void *line; - int pixels = VIDEO_FONT_HEIGHT * vid_priv->line_length; + int pixels = VIDEO_FONT_HEIGHT * vid_priv->xsize; int i; line = vid_priv->fb + row * VIDEO_FONT_HEIGHT * vid_priv->line_length; -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] arm64: zynqmp: fail SPL build if no psu_init found
When doing the SPL build, not finding the psu_init files yields an unuseable spl binary. Time is wasted as the build is carried through dev ops all the way to trying to boot the DUD build. A failure immediately alerts developers that something is wrong in the configuration of the u-boot tree, thus allowing quicker recovery. Adding an extra test in this section made the logic a bit too clunky so the layout of the tests was refactored for the reader's benefit. Signed-off-by: Jean-Francois Dagenais --- board/xilinx/zynqmp/Makefile | 28 ++-- 1 file changed, 22 insertions(+), 6 deletions(-) diff --git a/board/xilinx/zynqmp/Makefile b/board/xilinx/zynqmp/Makefile index 2bf0375..78cb550 100644 --- a/board/xilinx/zynqmp/Makefile +++ b/board/xilinx/zynqmp/Makefile @@ -7,22 +7,38 @@ obj-y := zynqmp.o -hw-platform-y :=$(shell echo $(CONFIG_DEFAULT_DEVICE_TREE)) +ifeq ($(CONFIG_SPL_BUILD), y) +# use the devicetree name as a hint for the psu_init file dir name +hw-platform-y :=$(shell echo $(CONFIG_DEFAULT_DEVICE_TREE)) init-objs := $(if $(wildcard $(srctree)/$(src)/$(hw-platform-y)/psu_init_gpl.c),\ $(hw-platform-y)/psu_init_gpl.o) +# if couldn't find psu_init files where they *should*, be... ifeq ($(init-objs),) -ifneq ($(wildcard $(srctree)/$(src)/psu_init_gpl.c),) -init-objs := psu_init_gpl.o -$(if $(CONFIG_SPL_BUILD),\ -$(warning Put custom psu_init_gpl.c/h to board/xilinx/zynqmp/custom_hw_platform/)) +# then fallback to this current dir, if file exists +init-objs := $(if $(wildcard $(srctree)/$(src)/psu_init_gpl.c), psu_init_gpl.o) endif + +# if init-objs still empty, then abort +ifeq ($(init-objs),) +# define a \n equivalent: +define n + + +endef + +$(error Could not locate psu_init_gpl.c/h files, tried: $n\ + $(srctree)/$(src)/$(hw-platform-y)/psu_init_gpl.c and $n\ + $(srctree)/$(src)/psu_init_gpl.c) endif -obj-$(CONFIG_ZYNQ_SDHCI) += tap_delays.o obj-$(CONFIG_SPL_BUILD) += $(init-objs) +endif # if SPL_BUILD + +obj-$(CONFIG_ZYNQ_SDHCI) += tap_delays.o + # Suppress "warning: function declaration isn't a prototype" CFLAGS_REMOVE_psu_init_gpl.o := -Wstrict-prototypes -- 2.1.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] rpi: Support both UART interfaces.
The Raspberry Pi 3 has two UART interfaces that can be pinmuxed to the header pins. The PL011 is by default muxed to the Bluetooth chip and the mini-UART can be muxed to the pin headers passing "enabled_uart=1" in the config.txt file. Passing "enable_uart=1" has other implications, since the baudrate of the miniuart depends on the clock frequency of the main core, which is normally dynamic unless enable_uart=1 is set. If Bluetooth is not used or not required, it is possible to set the PL011 UART to the header pins passing either "dtoverlay=pi3-disable-bt" or "dtoverlay=pi3-miniuart-bt" to disable Bluetooth or use it via the miniuart respectively. This patch disables (for U-Boot) the UARTs modules not muxed to the header pins so the serial port is used only if available in the header pins, avoiding writing to the Bluetooth chip if needed. This allows to enable the PL01X driver for the Raspberry Pi 3, previously disabled for that board, which can be used for the U-Boot console if properly configured in the device tree. Note that in order to get the PL01X driver in the Raspberry Pi 3 to work with U-Boot the device tree must set "skip-init" in the uart0 block, for example this device tree fragment would do it: fragment@0 { target = <&uart0>; __overlay__ { skip-init; }; }; Test: Booted a rpi3 with either UART output. Signed-off-by: Alex Deymo --- board/raspberrypi/rpi/rpi.c | 78 +++-- drivers/serial/serial_pl01x.c | 3 ++ include/configs/rpi.h | 8 +++- include/dm/platform_data/serial_pl01x.h | 2 + 4 files changed, 66 insertions(+), 25 deletions(-) diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c index 2146534b36..58f07953f5 100644 --- a/board/raspberrypi/rpi/rpi.c +++ b/board/raspberrypi/rpi/rpi.c @@ -18,6 +18,7 @@ #include #include #include +#include #include #ifdef CONFIG_ARM64 #include @@ -442,8 +443,19 @@ static void get_board_rev(void) printf("RPI %s (0x%x)\n", model->name, revision); } -#ifndef CONFIG_PL01X_SERIAL -static bool rpi_is_serial_active(void) +/* An enum describing the pin muxing selection for the UART RX/TX pins. */ +enum rpi_uart_mux { + /* The pin is associated with the internal "miniuart" block. */ + RPI_UART_BCM283X_MU, + + /* The pin is associated with the PL01X uart driver. */ + RPI_UART_PL01X, + + /* The pin is associated with a different function. */ + RPI_UART_OTHER, +}; + +static enum rpi_uart_mux rpi_get_uart_mux_setting(void) { int serial_gpio = 15; struct udevice *dev; @@ -452,41 +464,61 @@ static bool rpi_is_serial_active(void) * The RPi3 disables the mini uart by default. The easiest way to find * out whether it is available is to check if the RX pin is muxed. */ - if (uclass_first_device(UCLASS_GPIO, &dev) || !dev) - return true; - - if (bcm2835_gpio_get_func_id(dev, serial_gpio) != BCM2835_GPIO_ALT5) - return false; + return RPI_UART_OTHER; - return true; + switch (bcm2835_gpio_get_func_id(dev, serial_gpio)) { + case BCM2835_GPIO_ALT5: + return RPI_UART_BCM283X_MU; + case BCM2835_GPIO_ALT0: + return RPI_UART_PL01X; + } + return RPI_UART_OTHER; } -/* Disable mini-UART I/O if it's not pinmuxed to our pins. - * The firmware only enables it if explicitly done in config.txt: enable_uart=1 +/* Disable UART I/O for the mini-UART and PL01X UART if they are not pinmuxed to + * the Raspberry Pi header. The mini-UART is only enabled in the header if + * explicitly done in config.txt: enable_uart=1, and the PL01X is only enabled + * if not used for Bluetooth and explicitly exposed in config.txt as either + * dtoverlay=pi3-disable-bt or dtoverlay=pi3-miniuart-bt. */ -static void rpi_disable_inactive_uart(void) +static void rpi_disable_inactive_uarts(void) { struct udevice *dev; - struct bcm283x_mu_serial_platdata *plat; + enum rpi_uart_mux mux; - if (uclass_get_device_by_driver(UCLASS_SERIAL, - DM_GET_DRIVER(serial_bcm283x_mu), - &dev) || !dev) - return; + mux = rpi_get_uart_mux_setting(); + +#ifdef CONFIG_BCM283X_MU_SERIAL + struct bcm283x_mu_serial_platdata *bcm283x_mu_plat; - if (!rpi_is_serial_active()) { - plat = dev_get_platdata(dev); - plat->disabled = true; + if (mux != RPI_UART_BCM283X_MU && + !uclass_get_device_by_driver(UCLASS_SERIAL, +DM_GET_DRIVER(serial_bcm283x_mu), +&dev) && + dev) { + bcm283x_mu_plat = dev_get_platdata(dev); + bcm283x_mu_plat->disabled = true;
Re: [U-Boot] [PATCH 09/16] board_f: Drop setup_dram_config() wrapper
On 31.03.2017 16:40, Simon Glass wrote: By making dram_init_banksize() return an error code we can drop the wrapper. Adjust this and clean up all implementations. Signed-off-by: Simon Glass Reviewed-by: Stefan Roese Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] Allow boards to initialize the DT at runtime.
In some boards like the Raspberry Pi the initial bootloader will pass a DT to the kernel. When using U-boot as such kernel, the board code in U-Boot should be able to provide U-boot with this, already assembled device tree blob. This patch introduces a new config option CONFIG_OF_BOARD to use instead of CONFIG_OF_EMBED or CONFIG_OF_SEPARATE which will initialize the DT from a board-specific funtion instead of bundling one with U-boot or as a separated file. This allows boards like the Raspberry Pi to reuse the device tree passed from the bootcode.bin and start.elf firmware files, included the run-time selected device tree overlays. Signed-off-by: Alex Deymo --- README | 8 +++- board/raspberrypi/rpi/rpi.c | 10 ++ doc/README.fdt-control | 4 dts/Kconfig | 8 include/fdtdec.h| 6 ++ lib/fdtdec.c| 3 +++ 6 files changed, 38 insertions(+), 1 deletion(-) diff --git a/README b/README index aa907ced8a..e658f02a7e 100644 --- a/README +++ b/README @@ -975,7 +975,7 @@ The following options need to be configured: tree is available in the global data as gd->fdt_blob. U-Boot needs to get its device tree from somewhere. This can - be done using one of the two options below: + be done using one of the three options below: CONFIG_OF_EMBED If this variable is defined, U-Boot will embed a device tree @@ -996,6 +996,12 @@ The following options need to be configured: still use the individual files if you need something more exotic. + CONFIG_OF_BOARD + If this variable is defined, U-Boot will use the device tree + provided by the board at runtime instead of embedding one with + the image. Only boards defining board_fdt_blob_setup() support + this option (see include/fdtdec.h file). + - Watchdog: CONFIG_WATCHDOG If this variable is defined, it enables watchdog diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c index 2146534b36..ef04d397d6 100644 --- a/board/raspberrypi/rpi/rpi.c +++ b/board/raspberrypi/rpi/rpi.c @@ -516,6 +516,16 @@ int board_mmc_init(bd_t *bis) msg_clk->get_clock_rate.body.resp.rate_hz); } +/* + * If the firmware passed a device tree use it for U-Boot. + */ +void *board_fdt_blob_setup(void) +{ + if (fdt_magic(fw_dtb_pointer) != FDT_MAGIC) + return NULL; + return (void *)fw_dtb_pointer; +} + int ft_board_setup(void *blob, bd_t *bd) { /* diff --git a/doc/README.fdt-control b/doc/README.fdt-control index c965629905..378b06b108 100644 --- a/doc/README.fdt-control +++ b/doc/README.fdt-control @@ -130,6 +130,10 @@ u-boot-dtb.bin which does the above step for you also. If you are using CONFIG_SPL_FRAMEWORK, then u-boot.img will be built to include the device tree binary. +If CONFIG_OF_BOARD is defined, a board-specific routine will provide the +device tree at runtime, for example if an earlier bootloader stage creates +it and passes it to U-Boot. + If CONFIG_OF_HOSTFILE is defined, then it will be read from a file on startup. This is only useful for sandbox. Use the -d flag to U-Boot to specify the file to read. diff --git a/dts/Kconfig b/dts/Kconfig index 3f64eda619..978b2d7f3d 100644 --- a/dts/Kconfig +++ b/dts/Kconfig @@ -51,6 +51,14 @@ config OF_EMBED and development only and is not recommended for production devices. Boards in the mainline U-Boot tree should not use it. +config OF_BOARD + bool "Provided by the board at runtime" + depends on !SANDBOX + help + If this option is enabled, the device tree will be provided by + the board at runtime if the board supports it, instead of being + bundled with the image. + config OF_HOSTFILE bool "Host filed DTB for DT control" depends on SANDBOX diff --git a/include/fdtdec.h b/include/fdtdec.h index d074478f14..5c54f71458 100644 --- a/include/fdtdec.h +++ b/include/fdtdec.h @@ -1015,4 +1015,10 @@ int fdtdec_setup_memory_banksize(void); */ int fdtdec_setup(void); +/** + * Board-specific FDT initialization. Returns the address to a device tree blob. + * Called when CONFIG_OF_BOARD is defined. + */ +void *board_fdt_blob_setup(void); + #endif diff --git a/lib/fdtdec.c b/lib/fdtdec.c index 81f47ef2c7..2e1beb545b 100644 --- a/lib/fdtdec.c +++ b/lib/fdtdec.c @@ -1247,6 +1247,9 @@ int fdtdec_setup(void) /* FDT is at end of image */ gd->fdt_blob = (ulong *)&_end; # endif +# elif defined(CONFIG_OF_BOARD) + /* Allow the board to override the fdt address. */ + gd->fdt_blob = board_fdt_blob_setup(); # elif defined(CONFIG_OF_HOSTFILE) if (sandbox_read_fdt_from_file()) { puts("Failed to read control FDT\n"); -
[U-Boot] [PATCH 4/6] disk: Return the partition number in part_get_info_by_name()
Similar to what blk_get_device_part_str() does, this patch makes part_get_info_by_name() return the partition number in case of a match. This is useful when the partition number is needed and not just the descriptor. Signed-off-by: Alex Deymo --- common/fb_mmc.c | 6 +++--- disk/part.c | 2 +- include/part.h | 3 ++- 3 files changed, 6 insertions(+), 5 deletions(-) diff --git a/common/fb_mmc.c b/common/fb_mmc.c index 6cc113d825..866982e41c 100644 --- a/common/fb_mmc.c +++ b/common/fb_mmc.c @@ -37,7 +37,7 @@ static int part_get_info_by_name_or_alias(struct blk_desc *dev_desc, int ret; ret = part_get_info_by_name(dev_desc, name, info); - if (ret) { + if (ret < 0) { /* strlen("fastboot_partition_alias_") + 32(part_name) + 1 */ char env_alias_name[25 + 32 + 1]; char *aliased_part_name; @@ -153,7 +153,7 @@ void fb_mmc_flash_write(const char *cmd, void *download_buffer, } #endif - if (part_get_info_by_name_or_alias(dev_desc, cmd, &info)) { + if (part_get_info_by_name_or_alias(dev_desc, cmd, &info) < 0) { error("cannot find partition: '%s'\n", cmd); fastboot_fail("cannot find partition"); return; @@ -205,7 +205,7 @@ void fb_mmc_erase(const char *cmd) } ret = part_get_info_by_name_or_alias(dev_desc, cmd, &info); - if (ret) { + if (ret < 0) { error("cannot find partition: '%s'", cmd); fastboot_fail("cannot find partition"); return; diff --git a/disk/part.c b/disk/part.c index cd447024c0..491b02dc9c 100644 --- a/disk/part.c +++ b/disk/part.c @@ -635,7 +635,7 @@ int part_get_info_by_name(struct blk_desc *dev_desc, const char *name, } if (strcmp(name, (const char *)info->name) == 0) { /* matched */ - return 0; + return i; } } } diff --git a/include/part.h b/include/part.h index b6d1b33167..83bce05a43 100644 --- a/include/part.h +++ b/include/part.h @@ -163,7 +163,8 @@ int blk_get_device_part_str(const char *ifname, const char *dev_part_str, * @param gpt_name - the specified table entry name * @param info - returns the disk partition info * - * @return - '0' on match, '-1' on no match, otherwise error + * @return - the partition number on match (starting on 1), -1 on no match, + * otherwise error */ int part_get_info_by_name(struct blk_desc *dev_desc, const char *name, disk_partition_t *info); -- 2.12.2.564.g063fe858b8-goog ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] mmc: zynq_sdhci: improve debug print
When debugging dual SDHCI controller setup, printing strings and bank info is very helpful. Signed-off-by: Jean-Francois Dagenais --- drivers/mmc/zynq_sdhci.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/mmc/zynq_sdhci.c b/drivers/mmc/zynq_sdhci.c index 089a424..f975165 100644 --- a/drivers/mmc/zynq_sdhci.c +++ b/drivers/mmc/zynq_sdhci.c @@ -160,8 +160,8 @@ static void arasan_sdhci_set_tapdelay(struct sdhci_host *host) else return; - debug("%s, %d:%d, mode:%d\n", __func__, priv->deviceid, priv->bank, - uhsmode); + debug("%s, host:%s devId:%d, bank:%d, mode:%d\n", __func__, host->name, + priv->deviceid, priv->bank, uhsmode); if ((uhsmode >= MMC_TIMING_UHS_SDR25) && (uhsmode <= MMC_TIMING_HS200)) arasan_zynqmp_set_tapdelay(priv->deviceid, uhsmode, -- 2.1.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/6] image: Implement a function to load Android Images.
This patch implements the logic needed to load an Android boot image from storage, since the size and kernel address in Android images is defined in its header. Signed-off-by: Alex Deymo --- common/image-android.c | 51 ++ include/image.h| 19 +++ 2 files changed, 70 insertions(+) diff --git a/common/image-android.c b/common/image-android.c index c668407817..f040f5b400 100644 --- a/common/image-android.c +++ b/common/image-android.c @@ -8,6 +8,7 @@ #include #include #include +#include #include #define ANDROID_IMAGE_DEFAULT_KERNEL_ADDR 0x10008000 @@ -146,6 +147,56 @@ int android_image_get_ramdisk(const struct andr_img_hdr *hdr, return 0; } +long android_image_load(struct blk_desc *dev_desc, + const disk_partition_t *part_info, + unsigned long load_address, + unsigned long max_size) { + void *buf; + long blk_cnt, blk_read = 0; + + if (max_size < part_info->blksz) + return -1; + + /* We don't know the size of the Android image before reading the header +* so we don't limit the size of the mapped memory. +*/ + buf = map_sysmem(load_address, 0 /* size */); + + /* Read the Android header first and then read the rest. */ + if (blk_dread(dev_desc, part_info->start, 1, buf) != 1) + blk_read = -1; + + if (!blk_read && android_image_check_header(buf) != 0) { + printf("** Invalid Android Image header **\n"); + blk_read = -1; + } + if (!blk_read) { + blk_cnt = (android_image_get_end(buf) - (ulong)buf + + part_info->blksz - 1) / part_info->blksz; + if (blk_cnt * part_info->blksz > max_size) { + debug("Android Image too big (%lu bytes, max %lu)\n", + android_image_get_end(buf) - (ulong)buf, + max_size); + blk_read = -1; + } else { + debug("Loading Android Image (%lu blocks) to 0x%lx... ", + blk_cnt, load_address); + blk_read = blk_dread(dev_desc, part_info->start, +blk_cnt, buf); + } + } + + unmap_sysmem(buf); + if (blk_read < 0) + return blk_read; + + debug("%lu blocks read: %s\n", + blk_read, (blk_read == blk_cnt) ? "OK" : "ERROR"); + if (blk_read != blk_cnt) + return -1; + return blk_read; +} + #if !defined(CONFIG_SPL_BUILD) /** * android_print_contents - prints out the contents of the Android format image diff --git a/include/image.h b/include/image.h index 2372518960..de448a9a01 100644 --- a/include/image.h +++ b/include/image.h @@ -1241,6 +1241,25 @@ ulong android_image_get_end(const struct andr_img_hdr *hdr); ulong android_image_get_kload(const struct andr_img_hdr *hdr); void android_print_contents(const struct andr_img_hdr *hdr); +/** android_image_load - Load an Android Image from storage. + * + * Load an Android Image based on the header size in the storage. Return the + * number of bytes read from storage, which could be bigger than the actual + * Android Image as described in the header size. In case of error reading the + * image or if the image size needed to be read from disk is bigger than the + * the passed |max_size| a negative number is returned. + * + * @dev_desc: The device where to read the image from + * @part_info: The partition in |dev_desc| where to read the image from + * @load_address: The address where the image will be loaded + * @max_size: The maximum loaded size, in bytes + * @return the number of bytes read or a negative number in case of error. + */ +long android_image_load(struct blk_desc *dev_desc, + const disk_partition_t *part_info, + unsigned long load_address, + unsigned long max_size); + #endif /* CONFIG_ANDROID_BOOT_IMAGE */ /** -- 2.12.2.564.g063fe858b8-goog ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] arm64: zynqmp: fail SPL build if no psu_init found
> On Apr 3, 2017, at 02:55, Michal Simek wrote: > > This is not only one way how to configure system. You can use > psu_init*.tcl and configure chip through jtag and then you don't need > this .c/.h files. > You should be able to see warning already about it if you miss that files. Mmh. I had thought of that, but it seemed like this scenario might have been a minority issue. I guess this is a very yocto-centric problem. Warnings emitted inside builds that bitbake spawns are only visible in a log file for each steps (configure, compile, etc.) inside each recipe's work dir and so they are completely invisible to the operator that invokes bitbake. Perhaps I should come up with a strategy to emerge this particular warning in the u-boot-xlnx_%.bb recipe? Thoughts? ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/6] image: Update include/android_image.h
Update the Android image header format to the latest version published in AOSP. The original code moved to a new repository, so this patch also updates the reference to that path. Signed-off-by: Alex Deymo --- common/image-android.c | 9 + include/android_image.h | 24 +++- 2 files changed, 28 insertions(+), 5 deletions(-) diff --git a/common/image-android.c b/common/image-android.c index ee03b96aaa..c668407817 100644 --- a/common/image-android.c +++ b/common/image-android.c @@ -161,6 +161,9 @@ int android_image_get_ramdisk(const struct andr_img_hdr *hdr, void android_print_contents(const struct andr_img_hdr *hdr) { const char * const p = IMAGE_INDENT_STRING; + /* os_version = ver << 11 | lvl */ + u32 os_ver = hdr->os_version >> 11; + u32 os_lvl = hdr->os_version & ((1U << 11) - 1); printf("%skernel size: %x\n", p, hdr->kernel_size); printf("%skernel address: %x\n", p, hdr->kernel_addr); @@ -170,6 +173,12 @@ void android_print_contents(const struct andr_img_hdr *hdr) printf("%ssecond address: %x\n", p, hdr->second_addr); printf("%stags address: %x\n", p, hdr->tags_addr); printf("%spage size:%x\n", p, hdr->page_size); + /* ver = A << 14 | B << 7 | C (7 bits for each of A, B, C) +* lvl = ((Y - 2000) & 127) << 4 | M (7 bits for Y, 4 bits for M) */ + printf("%sos_version: %x (ver: %u.%u.%u, level: %u.%u)\n", + p, hdr->os_version, + (os_ver >> 7) & 0x7F, (os_ver >> 14) & 0x7F, os_ver & 0x7F, + (os_lvl >> 4) + 2000, os_lvl & 0x0F); printf("%sname: %s\n", p, hdr->name); printf("%scmdline: %s\n", p, hdr->cmdline); } diff --git a/include/android_image.h b/include/android_image.h index 094d60afe8..dfd4d9d72c 100644 --- a/include/android_image.h +++ b/include/android_image.h @@ -1,8 +1,8 @@ /* * This is from the Android Project, - * Repository: https://android.googlesource.com/platform/bootable/bootloader/legacy - * File: include/boot/bootimg.h - * Commit: 4205b865141ff2e255fe1d3bd16de18e217ef06a + * Repository: https://android.googlesource.com/platform/system/core/ + * File: mkbootimg/bootimg.h + * Commit: d162828814b08ada310846a33205befb69ef5799 * * Copyright (C) 2008 The Android Open Source Project * @@ -12,10 +12,13 @@ #ifndef _ANDROID_IMAGE_H_ #define _ANDROID_IMAGE_H_ +typedef struct andr_img_hdr andr_img_hdr; + #define ANDR_BOOT_MAGIC "ANDROID!" #define ANDR_BOOT_MAGIC_SIZE 8 #define ANDR_BOOT_NAME_SIZE 16 #define ANDR_BOOT_ARGS_SIZE 512 +#define ANDR_BOOT_EXTRA_ARGS_SIZE 1024 struct andr_img_hdr { char magic[ANDR_BOOT_MAGIC_SIZE]; @@ -31,14 +34,25 @@ struct andr_img_hdr { u32 tags_addr; /* physical addr for kernel tags */ u32 page_size; /* flash page size we assume */ - u32 unused[2]; /* future expansion: should be 0 */ + u32 unused; /* reserved for future expansion: MUST be 0 */ + + /* operating system version and security patch level; for +* version "A.B.C" and patch level "Y-M-D": +* ver = A << 14 | B << 7 | C (7 bits for each of A, B, C) +* lvl = ((Y - 2000) & 127) << 4 | M (7 bits for Y, 4 bits for M) +* os_version = ver << 11 | lvl */ + u32 os_version; char name[ANDR_BOOT_NAME_SIZE]; /* asciiz product name */ char cmdline[ANDR_BOOT_ARGS_SIZE]; u32 id[8]; /* timestamp / checksum / sha1 / etc */ -}; + + /* Supplemental command line data; kept here to maintain +* binary compatibility with older versions of mkbootimg */ + char extra_cmdline[ANDR_BOOT_EXTRA_ARGS_SIZE]; +} __attribute__((packed)); /* * +-+ -- 2.12.2.564.g063fe858b8-goog ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: socfpga: boot0 hook: remove macro from boot0 header file
On Mar 31, 2017 7:13 PM, "Marek Vasut" wrote: On 03/30/2017 03:22 AM, chee skywind wrote: > On Wed, Mar 29, 2017 at 5:03 PM, Marek Vasut wrote: > >> On 03/29/2017 05:49 AM, tien.fong.c...@intel.com wrote: >>> From: "Chee, Tien Fong" >>> >>> Commit ce62e57fc571 ("ARM: boot0 hook: remove macro, include whole >>> header file") miss out cleaning macro in this header file, and this >>> has broken implementation of a boot header capability in socfpga >>> SPL. Remove the macro in this file, and recovering it back >>> to proper functioning. >>> >>> Fixes: ce62e57fc571 ("ARM: boot0 hook: remove macro, include whole >>> header file") >>> >>> Signed-off-by: Chee, Tien Fong >> >> Patch looks good, minor nit below. >> >>> --- >>> arch/arm/mach-socfpga/include/mach/boot0.h | 24 >> ++-- >>> 1 file changed, 10 insertions(+), 14 deletions(-) >>> >>> diff --git a/arch/arm/mach-socfpga/include/mach/boot0.h >> b/arch/arm/mach-socfpga/include/mach/boot0.h >>> index aaada31..22d9e7f 100644 >>> --- a/arch/arm/mach-socfpga/include/mach/boot0.h >>> +++ b/arch/arm/mach-socfpga/include/mach/boot0.h >>> @@ -8,21 +8,17 @@ >>> #define __BOOT0_H >>> >>> #ifdef CONFIG_SPL_BUILD >>> -#define ARM_SOC_BOOT0_HOOK \ >>> - .balignl 64,0xf33db33f; \ >>> - \ >>> - .word 0x1337c0d3; /* SoCFPGA preloader validation word */ \ >>> - .word 0xc01df00d; /* Version, flags, length */\ >>> - .word 0xcafec0d3; /* Checksum, zero-pad */\ >>> - nop;\ >>> - \ >>> - b reset;/* SoCFPGA jumps here */\ >>> - nop;\ >>> - nop;\ >>> + .balignl 64,0xf33db33f; >>> + >>> + .word 0x1337c0d3; /* SoCFPGA preloader validation word */ >>> + .word 0xc01df00d; /* Version, flags, length */ >>> + .word 0xcafec0d3; /* Checksum, zero-pad */ >>> nop; >>> -#else >>> -#define ARM_SOC_BOOT0_HOOK >>> -#endif >>> >>> + b reset;/* SoCFPGA jumps here */ >>> + nop; >>> + nop; >>> + nop; >> >> Correct me if I'm wrong, but did you add one more "nop" here ? >> >> no, i din't add extra "nop" here. There are 3 "nop" from original code > after "b reset". Ah sorry, I see, it's just the patch being generated in a funny way. Thanks for double-checking. Yeah, it is weird but the patch looks correct. Thanks. -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 0/6] Android A/B Bootloader support
An "Android Bootloader" has a lot of requirements about how it should behave which Android partners must implement. In particular, the new A/B updates [1] added more requirements and flows to the bootloader which are not common, on top of the existing flows. For example, a few uncommon requirements include: * Lookup in the BCB (boot control block) whether a "recovery" message is stored. This is used by the recovery environment when applying a multi-stage update in the legacy update model (recovery reboots to recovery again) and for interrumpted factory-reset (a reboot during the factory reset should continue to reboot into factory reset until it is done). * A new "repair" mode. In the A/B model, when none of the slots is bootable, the device would boot into repair mode, which is often the same as "bootloader" mode (fastboot). * Recovery as root: In newer version of AOSP, it is possible to mount the system image as / without an initramfs, which then frees up the initramfs in the "boot" partition to hold the "recovery" initramfs. This is the default for new devices and required for the A/B setup. This patchset updates the Android-related headers and introduces new commands to boot a recent Android build. This work is based on the bootloader used in the Raspberry Pi in Android Things and extensively tested there. [1] https://source.android.com/devices/tech/ota/ab_updates.html Alex Deymo (6): image: Update include/android_image.h image: Implement a function to load Android Images. cmd: Add 'load_android' command to load Android images. disk: Return the partition number in part_get_info_by_name() Initial support for the Android Bootloader flow cmd: Add "boot_android" command. README | 25 ++- cmd/Kconfig | 19 ++ cmd/Makefile | 2 + cmd/boot_android.c | 126 + cmd/load_android.c | 56 ++ common/Kconfig | 19 ++ common/Makefile | 1 + common/android_bootloader.c | 350 +++ common/fb_mmc.c | 6 +- common/image-android.c | 60 ++ disk/part.c | 2 +- include/android_bootloader.h | 48 + include/android_bootloader_message.h | 174 + include/android_image.h | 24 ++- include/image.h | 19 ++ include/part.h | 3 +- 16 files changed, 920 insertions(+), 14 deletions(-) create mode 100644 cmd/boot_android.c create mode 100644 cmd/load_android.c create mode 100644 common/android_bootloader.c create mode 100644 include/android_bootloader.h create mode 100644 include/android_bootloader_message.h -- 2.12.2.564.g063fe858b8-goog ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] build uboot.rom for minnow
Hi, I have followed steps in the readme.x86 to build Uboot.rom for minnowboard. but i got a error message as: CHK include/config/uboot.release CHK include/generated/version_autogenerated.h CHK include/generated/timestamp_autogenerated.h UPD include/generated/timestamp_autogenerated.h CHK include/generated/generic-asm-offsets.h CHK include/generated/asm-offsets.h HOSTCC tools/mkenvimage.o HOSTLD tools/mkenvimage HOSTCC tools/fit_image.o HOSTCC tools/image-host.o HOSTCC tools/dumpimage.o HOSTLD tools/dumpimage HOSTCC tools/mkimage.o HOSTLD tools/mkimage HOSTLD tools/fit_info HOSTLD tools/fit_check_sign CC cmd/version.o LD cmd/built-in.o CC common/main.o CC common/board_f.o LD common/built-in.o CC lib/efi_loader/helloworld.o LD lib/efi_loader/helloworld.so OBJCOPY lib/efi_loader/helloworld.efi CC lib/smbios.o CC lib/display_options.o LD lib/built-in.o LD u-boot OBJCOPY u-boot.srec OBJCOPY u-boot-nodtb.bin CAT u-boot-dtb.bin COPYu-boot.bin SYM u-boot.sym OBJCOPY u-boot-x86-16bit.bin BINMAN u-boot.rom fdtput: invalid option -- 'd' Usage: write a property value to a device tree fdtput [...] fdtput -c [...] The command line arguments are joined together into a single value. s=string, i=int, u=unsigned, x=hex Optional modifier prefix: hh or b=byte, h=2 byte, l=4 byte (default) Options: -[cpt:vhV] -c, --create Create nodes if they don't already exist -p, --auto-path Automatically create nodes as needed for the node path -t, --type Type of data -v, --verboseDisplay each value decoded from command line -h, --help Print this help and exit -V, --versionPrint version and exit Error: unknown option binman: Error running 'fdtput ./u-boot-dtb-with-ucode.dtb -d /microcode/update@0 data' make: *** [u-boot.rom] Error 1 Please do help. SASKEN BUSINESS DISCLAIMER: This message may contain confidential, proprietary or legally privileged information. In case you are not the original intended Recipient of the message, you must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message and you are requested to delete it and inform the sender. Any views expressed in this message are those of the individual sender unless otherwise stated. Nothing contained in this message shall be construed as an offer or acceptance of any offer by Sasken Technologies Limited ( formerly known as "Sasken Communication Technologies Limited" ) unless sent with that express intent and with due authority of Sasken. Sasken has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email. Read Disclaimer at http://www.sasken.com/mail-disclaimer/ ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] Python Version
Hello, I was trying to compile u-boot for an OrangePi zero (AllWinner H2+) on my up to date Arch Linux machine. In contrary to other distributions, the standard Python version on Arch is Python3. To get a successful build, I had to append the "2.7" to the "python" in line 123 of tools/Makefile. Even if it's just for one distribution, it would be nice to explicitly state the Python version an every Python call and script shebang. Kind regard, marble signature.asc Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 3/6] cmd: Add 'load_android' command to load Android images.
Android kernel images include a header that specifies addresses and kernel size. This patch adds a command to load these images from storage without specifying the size or address of them, and parsing them from the header instead. --- cmd/Kconfig| 9 + cmd/Makefile | 1 + cmd/load_android.c | 56 ++ 3 files changed, 66 insertions(+) create mode 100644 cmd/load_android.c diff --git a/cmd/Kconfig b/cmd/Kconfig index 25e3b783a8..87a445d269 100644 --- a/cmd/Kconfig +++ b/cmd/Kconfig @@ -422,6 +422,15 @@ config CMD_LOADS help Load an S-Record file over serial line +config CMD_LOAD_ANDROID + bool "load_android" + default n + depends on ANDROID_BOOT_IMAGE + help + Load an Android Boot image from storage. The Android Boot images + define the size and kernel address on the header, which are used by + this command. + config CMD_FLASH bool "flinfo, erase, protect" default y diff --git a/cmd/Makefile b/cmd/Makefile index f13bb8c11e..2f75dab040 100644 --- a/cmd/Makefile +++ b/cmd/Makefile @@ -82,6 +82,7 @@ obj-$(CONFIG_CMD_LDRINFO) += ldrinfo.o obj-$(CONFIG_LED_STATUS_CMD) += led.o obj-$(CONFIG_CMD_LICENSE) += license.o obj-y += load.o +obj-$(CONFIG_CMD_LOAD_ANDROID) += load_android.o obj-$(CONFIG_LOGBUFFER) += log.o obj-$(CONFIG_ID_EEPROM) += mac.o obj-$(CONFIG_CMD_MD5SUM) += md5sum.o diff --git a/cmd/load_android.c b/cmd/load_android.c new file mode 100644 index 00..b9f3b1b372 --- /dev/null +++ b/cmd/load_android.c @@ -0,0 +1,56 @@ +/* + * Copyright (C) 2016 The Android Open Source Project + * + * SPDX-License-Identifier: BSD-2-Clause + */ + +#include +#include + +static int do_load_android(cmd_tbl_t *cmdtp, int flag, int argc, + char * const argv[]) +{ + int boot_partition; + unsigned long load_address; + char *addr_arg_endp, *addr_str; + struct blk_desc *dev_desc; + disk_partition_t part_info; + + if (argc < 2) + return CMD_RET_USAGE; + if (argc > 4) + return CMD_RET_USAGE; + + if (argc >= 4) { + load_address = simple_strtoul(argv[3], &addr_arg_endp, 16); + if (addr_arg_endp == argv[3] || *addr_arg_endp != '\0') + return CMD_RET_USAGE; + } else { + addr_str = getenv("loadaddr"); + if (addr_str != NULL) + load_address = simple_strtoul(addr_str, NULL, 16); + else + load_address = CONFIG_SYS_LOAD_ADDR; + } + + boot_partition = blk_get_device_part_str(argv[1], +(argc >= 3) ? argv[2] : NULL, +&dev_desc, &part_info, 1); + if (boot_partition < 0) + return CMD_RET_FAILURE; + + if (android_image_load(dev_desc, &part_info, load_address, -1UL) < 0) { + printf("Error loading Android Image from %s %d:%d to 0x%lx.\n", + argv[1], dev_desc->devnum, boot_partition, load_address); + return CMD_RET_FAILURE; + } + return CMD_RET_SUCCESS; +} + +U_BOOT_CMD( + load_android, 4, 0, do_load_android, + "load Android Boot image from storage.", + " [ []]\n" + "- Load a binary Android Boot image from the partition 'part' on\n" + " device type 'interface' instance 'dev' to address 'addr'." +); -- 2.12.2.564.g063fe858b8-goog ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 03/16] board_f: Rename initdram() to dram_init()
On 31.03.2017 16:40, Simon Glass wrote: This allows us to use the same DRAM init function on all archs. Signed-off-by: Simon Glass Reviewed-by: Stefan Roese Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 02/16] board_f: Drop return value from initdram()
On 31.03.2017 16:40, Simon Glass wrote: At present we cannot use this function as an init sequence call without a wrapper, since it returns the RAM size. Adjust it to set the RAM size in global_data instead, and return 0 on success. Signed-off-by: Simon Glass Reviewed-by: Stefan Roese Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 5/6] Initial support for the Android Bootloader flow
An Android Bootloader must comply with certain boot modes and change the kernel command line accordingly. This patch introduces the Android boot mode concept which determines whether the device should boot to one of the following: * recovery: which should boot to the recovery image, * bootloader: which should boot to the "bootloader" (fastboot) and * normal: which should boot to the system image. The boot mode is determined in part by the Boot Control Block (BCB) which is stored at the beginning of the "misc" partition. The BCB is defined in the "bootloader_message.h" file in AOSP, now copied here as android_bootloader_message.h with minor modifications. This patch implements the basic boot flow that loads and boots an Android kernel image assuming an A/B device which implies that it uses boot as recovery (BOARD_USES_RECOVERY_AS_BOOT in the BoardConfig.mk). This means that the recovery image shares the same kernel with the normal boot system image, but stores the recovery image as a ramdisk which is not used in normal mode. Among the limitations, this patch doesn't implement the A/B slot selection, it only boots from the provided slot. Test: Booted a rpi3 with this flow. Signed-off-by: Alex Deymo --- README | 19 +- common/Kconfig | 19 ++ common/Makefile | 1 + common/android_bootloader.c | 350 +++ include/android_bootloader.h | 48 + include/android_bootloader_message.h | 174 + 6 files changed, 607 insertions(+), 4 deletions(-) create mode 100644 common/android_bootloader.c create mode 100644 include/android_bootloader.h create mode 100644 include/android_bootloader_message.h diff --git a/README b/README index aa907ced8a..384cc6aabb 100644 --- a/README +++ b/README @@ -1483,6 +1483,21 @@ The following options need to be configured: entering dfuMANIFEST state. Host waits this timeout, before sending again an USB request to the device. +- Android Bootloader support: + CONFIG_ANDROID_BOOTLOADER + This enables support for the Android bootloader flow. Android + devices can boot in normal mode, recovery mode or bootloader + mode. The normal mode is the most common boot mode, but + recovery mode is often used to perform factory reset and OTA + (over-the-air) updates in the legacy updater. Also it is + possible for an Android system to request a reboot to the + "bootloader", which often means reboot to fastboot but may also + include a UI with a menu. + + CONFIG_ANDROID_BOOT_IMAGE + This enables support for booting images which use the Android + image format header. + - USB Device Android Fastboot support: CONFIG_USB_FUNCTION_FASTBOOT This enables the USB part of the fastboot gadget @@ -1494,10 +1509,6 @@ The following options need to be configured: used on Android devices. See doc/README.android-fastboot for more information. - CONFIG_ANDROID_BOOT_IMAGE - This enables support for booting images which use the Android - image format header. - CONFIG_FASTBOOT_BUF_ADDR The fastboot protocol requires a large memory buffer for downloads. Define this to the starting RAM address to use for diff --git a/common/Kconfig b/common/Kconfig index 8f73c8f757..47e2ffa3d6 100644 --- a/common/Kconfig +++ b/common/Kconfig @@ -393,6 +393,25 @@ config DISPLAY_BOARDINFO when U-Boot starts up. The board function checkboard() is called to do this. +config ANDROID_BOOTLOADER + bool "Support for Android Bootloader boot flow" + default n + depends on ANDROID_BOOT_IMAGE + help + If enabled, adds support to boot an Android device following the + Android Bootloader boot flow. This flow requires an Android Bootloader + to handle the Android Bootloader Message stored in the Boot Control + Block (BCB), normally in the "misc" partition of an Android device. + The BCB is used to determine the boot mode of the device (normal mode, + recovery mode or bootloader mode) and, if enabled, the slot to boot + from in devices with multiple boot slots (A/B devices). + +config ANDROID_BOOT_IMAGE + bool "Enable support for Android Boot Images" + help + This enables support for booting images which use the Android + image format header. + menu "Start-up hooks" config ARCH_EARLY_INIT_R diff --git a/common/Makefile b/common/Makefile index 86225f1564..9de0a77063 100644 --- a/common/Makefile +++ b/common/Makefile @@ -147,6 +147,7 @@ endif obj-$(CONFIG_CMD_IDE) += ide.o obj-y += image.o obj-$(CONFIG_ANDROID_BOOT_IMAGE)
[U-Boot] [PATCHv2] net: zynq_gem: Do not return -ENOSYS on success
The .read_rom_hwaddr net_ops hook does not check the return value, which is why it was never caught that we are currently returning 0 if the read_rom_hwaddr function return -ENOSYS and -ENOSYS otherwise. In this case we can simplify this by just returning the result of the function. Signed-off-by: Olliver Schinagl --- Changes since v1: Check pdata for NULL before dereferencing. drivers/net/zynq_gem.c | 8 +++- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/drivers/net/zynq_gem.c b/drivers/net/zynq_gem.c index 86dd03feda..52beedfad0 100644 --- a/drivers/net/zynq_gem.c +++ b/drivers/net/zynq_gem.c @@ -589,14 +589,12 @@ __weak int zynq_board_read_rom_ethaddr(unsigned char *ethaddr) static int zynq_gem_read_rom_mac(struct udevice *dev) { - int retval; struct eth_pdata *pdata = dev_get_platdata(dev); - retval = zynq_board_read_rom_ethaddr(pdata->enetaddr); - if (retval == -ENOSYS) - retval = 0; + if (!pdata) + return -ENOSYS; - return retval; + return zynq_board_read_rom_ethaddr(pdata->enetaddr); } static int zynq_gem_miiphy_read(struct mii_dev *bus, int addr, -- 2.11.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot