Re: [U-Boot] [PATCH 3/3][v3] [RESEND] arm: ls1046ardb: Add SD secure boot target

2017-04-04 Thread Ruchika Gupta
> -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

2017-04-04 Thread Michal Simek
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

2017-04-04 Thread Maxime Ripard
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 ?

2017-04-04 Thread Joakim Tjernlund
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

2017-04-04 Thread Lukasz Majewski
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

2017-04-04 Thread Lukasz Majewski
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

2017-04-04 Thread Lukasz Majewski
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

2017-04-04 Thread Stefano Babic
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

2017-04-04 Thread Jagan Teki

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 ?

2017-04-04 Thread Lukasz Majewski
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

2017-04-04 Thread Marek Vasut
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

2017-04-04 Thread 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

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()

2017-04-04 Thread Heiko Stübner
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

2017-04-04 Thread Maxime Ripard
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

2017-04-04 Thread Jagan Teki
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 ?

2017-04-04 Thread Joakim Tjernlund
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 ?

2017-04-04 Thread Wolfgang Denk
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 ?

2017-04-04 Thread Wolfgang Denk
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

2017-04-04 Thread Jean-Jacques Hiblot



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

2017-04-04 Thread Heiko Stuebner
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 ?

2017-04-04 Thread Joakim Tjernlund
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

2017-04-04 Thread Jean-Jacques Hiblot



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 ?

2017-04-04 Thread Wolfgang Denk
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

2017-04-04 Thread Maxime Ripard
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 ?

2017-04-04 Thread Joakim Tjernlund
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

2017-04-04 Thread Benjamin Herrenschmidt
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

2017-04-04 Thread York Sun
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

2017-04-04 Thread York Sun
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

2017-04-04 Thread York Sun
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

2017-04-04 Thread ah pco
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

2017-04-04 Thread Mingkai Hu

> -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()

2017-04-04 Thread york sun
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()

2017-04-04 Thread york sun
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()

2017-04-04 Thread york sun
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

2017-04-04 Thread Marcel Ziswiler
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

2017-04-04 Thread YUAN Linyu


> -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

2017-04-04 Thread techping . chan
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

2017-04-04 Thread Gerd Hoffmann
  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

2017-04-04 Thread Benjamin Herrenschmidt
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

2017-04-04 Thread techping . chan
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

2017-04-04 Thread Mirza Krak
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.

2017-04-04 Thread João M . S . Silva

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

2017-04-04 Thread Ken Lin
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

2017-04-04 Thread Ken Lin
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

2017-04-04 Thread Alison Wang

> 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

2017-04-04 Thread techping . chan
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

2017-04-04 Thread techping . chan
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

2017-04-04 Thread Olliver Schinagl

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

2017-04-04 Thread Mingkai Hu
> 
> -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

2017-04-04 Thread Dan Handley
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

2017-04-04 Thread Ken Lin
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

2017-04-04 Thread chee skywind
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

2017-04-04 Thread techping . chan
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-04-04 Thread Icenowy Zheng

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

2017-04-04 Thread techping . chan
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()

2017-04-04 Thread Simon Glass
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

2017-04-04 Thread Simon Glass
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

2017-04-04 Thread eric . gao
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

2017-04-04 Thread eric . gao
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

2017-04-04 Thread Simon Glass
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()

2017-04-04 Thread Simon Glass
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()

2017-04-04 Thread Simon Glass
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

2017-04-04 Thread eric . gao
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

2017-04-04 Thread Simon Glass
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

2017-04-04 Thread Ken Lin
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()

2017-04-04 Thread Stefan Roese

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-04-04 Thread Mirza Krak
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-04-04 Thread Icenowy Zheng

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

2017-04-04 Thread eric . gao
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

2017-04-04 Thread eric . gao
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

2017-04-04 Thread eric . gao
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

2017-04-04 Thread eric . gao
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

2017-04-04 Thread Alex Deymo
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

2017-04-04 Thread nicolas.le.bayon
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

2017-04-04 Thread Olliver Schinagl

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

2017-04-04 Thread eric . gao
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.

2017-04-04 Thread Alex Deymo
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.

2017-04-04 Thread Alex Deymo
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.

2017-04-04 Thread Alex Deymo
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

2017-04-04 Thread eric . gao
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

2017-04-04 Thread Simon Glass
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

2017-04-04 Thread eric . gao
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

2017-04-04 Thread Jean-Francois Dagenais
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.

2017-04-04 Thread Alex Deymo
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

2017-04-04 Thread Stefan Roese

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.

2017-04-04 Thread Alex Deymo
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()

2017-04-04 Thread Alex Deymo
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

2017-04-04 Thread Jean-Francois Dagenais
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.

2017-04-04 Thread Alex Deymo
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

2017-04-04 Thread Jean-Francois Dagenais

> 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

2017-04-04 Thread Alex Deymo
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

2017-04-04 Thread chee skywind
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

2017-04-04 Thread Alex Deymo
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

2017-04-04 Thread Hariharan A
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

2017-04-04 Thread marble
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.

2017-04-04 Thread Alex Deymo
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()

2017-04-04 Thread Stefan Roese

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()

2017-04-04 Thread Stefan Roese

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

2017-04-04 Thread Alex Deymo
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

2017-04-04 Thread Olliver Schinagl
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


  1   2   3   >