date:20181210

Re: [U-Boot] [PATCH v4 12/25] mtd: ensure MTD and NOR drivers are compiled with ENV_IS_IN_FLASH

2018-12-10 Thread Miquel Raynal

Hi Tom,

Tom Rini  wrote on Mon, 10 Dec 2018 13:10:11 -0500:

> On Mon, Dec 10, 2018 at 07:02:45PM +0100, Miquel Raynal wrote:
> > Hello,
> > 
> > Miquel Raynal  wrote on Sun,  9 Dec 2018
> > 19:07:34 +0100:
> >   
> > > MTD and NOR flash support must be enabled when the environment is in
> > > NOR.
> > > 
> > > Signed-off-by: Miquel Raynal 
> > > ---
> > >  configs/armadillo-800eva_defconfig | 2 ++
> > >  1 file changed, 2 insertions(+)
> > > 
> > > diff --git a/configs/armadillo-800eva_defconfig 
> > > b/configs/armadillo-800eva_defconfig
> > > index b1d923c069..72758884b4 100644
> > > --- a/configs/armadillo-800eva_defconfig
> > > +++ b/configs/armadillo-800eva_defconfig
> > > @@ -32,6 +32,8 @@ CONFIG_CMD_PING=y
> > >  # CONFIG_CMD_MISC is not set
> > >  CONFIG_ENV_IS_IN_FLASH=y
> > >  # CONFIG_MMC is not set
> > > +CONFIG_MTD=y
> > > +CONFIG_MTD_NOR_FLASH=y
> > >  CONFIG_SH_ETHER=y
> > >  CONFIG_SCIF_CONSOLE=y
> > >  CONFIG_OF_LIBFDT=y  
> > 
> > This change triggered a build failure. This is because, despite
> > declaring an in-flash environment, there was absolutely no MTD driver
> > compiled-in. No driver named after 'flash' or 'nor' or 'mtd' was
> > compiled.
> > 
> > The fix for this issue (the only one reported by Travis for this
> > version of the series) is to just drop this patch. As it has absolutely
> > no dependency and only impacts a single defconfig, I would rather
> > prefer not re-send 24 identical patches in a v5 unless there are
> > comments that I must address.  
> 
> Thanks.  Do you have a patchwork account?  If so you should be able to
> manage the status of your own at least and marking it as "Rejected" or
> "Not Applicable" or anything like that will mean it won't be picked up
> by accident.  If not, I'll get to it soon.
> 

I do have an account on ozlabs' patchwork. I went there to discard this
patch but I saw that someone (probably you) already did it.


Thanks,
Miquèl
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 06/20] riscv: ax25: Hide the ax25-specific Kconfig option

2018-12-10 Thread Bin Meng

Hi Rick,

On Tue, Dec 11, 2018 at 3:06 PM Rick Chen  wrote:
>
> > > Subject: [PATCH v2 06/20] riscv: ax25: Hide the ax25-specific Kconfig 
> > > option
> > >
> > > There is no need to expose RISCV_NDS to the Kconfig menu as it is an
> > > ax25-specific option.
> > >
>
> Hi Bin
>
> Can you explain why there is no need to expose RISCV_NDS here ?
>

This is specific to AX25, and there is no need to appear in the
Kconfig menu when people are building U-Boot for some other RISC-V
platforms. Also even if you select Y in the Kconfig menu for this
option for platforms other than AX25, it just does not help since all
its logic is within arch/riscv/cpu/ax25.

Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 06/20] riscv: ax25: Hide the ax25-specific Kconfig option

2018-12-10 Thread Rick Chen

> > Subject: [PATCH v2 06/20] riscv: ax25: Hide the ax25-specific Kconfig option
> >
> > There is no need to expose RISCV_NDS to the Kconfig menu as it is an
> > ax25-specific option.
> >

Hi Bin

Can you explain why there is no need to expose RISCV_NDS here ?

Rick

> > Signed-off-by: Bin Meng 
> > ---
> >
> > Changes in v2: None
> >
> >  arch/riscv/cpu/ax25/Kconfig | 8 +++-
> >  1 file changed, 3 insertions(+), 5 deletions(-)
> >
> > diff --git a/arch/riscv/cpu/ax25/Kconfig b/arch/riscv/cpu/ax25/Kconfig index
> > 6c7022f..5ff9e5c 100644
> > --- a/arch/riscv/cpu/ax25/Kconfig
> > +++ b/arch/riscv/cpu/ax25/Kconfig
> > @@ -1,7 +1,5 @@
> >  config RISCV_NDS
> > - bool "AndeStar V5 ISA support"
> > - default n
> > + bool
> >   help
> > - Say Y here if you plan to run U-Boot on AndeStar v5
> > - platforms and use some specific features which are
> > - provided by Andes Technology AndeStar V5 Families.
> > +   Run U-Boot on AndeStar v5 platforms and use some specific features
> > +   which are provided by Andes Technology AndeStar V5 Families.
> > --
> > 2.7.4
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] ARM: rockchip: rv1108: Fix booting with initramfs

2018-12-10 Thread Heiko Stuebner

Hi Philipp,

Am Dienstag, 11. Dezember 2018, 00:12:40 CET schrieb Philipp Tomsich:
> + Heiko
> 
> > On 10.12.2018, at 01:56, Tom Rini  wrote:
> > 
> > On Mon, Dec 10, 2018 at 01:38:36AM +0100, Philipp Tomsich wrote:
> >> Tom,
> >> 
> >> On 10.12.2018, at 01:28, Tom Rini  wrote:
> >>> 
> >>> On Mon, Dec 10, 2018 at 01:01:52AM +0100, Philipp Tomsich wrote:
> > We move the ramdisk_addr_r to 0x6800 and disable the initrd and
> > fdt relocation, so the initramfs works out of box.
> > 
> > Signed-off-by: Otavio Salvador 
> > Reviewed-by: Philipp Tomsich 
> > ---
> > 
> > include/configs/rv1108_common.h | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> > 
>  
>  Applied to u-boot-rockchip, thanks!
> >>> 
> >>> Ugh, sorry for not spotting this sooner.  Please don't disable
> >>> fdt/initrd relocation and instead use bootm_size.
> >> 
> >> Thanks for spotting this (just in time).
> >> I’ll drop it and rerun Travis for tomorrow’s PR.
> > 
> > Thanks.  And you might want to audit the rest of rockchip (and no, my
> > own house isn't 100% in order) as it looks like in general at least
> > you're using fdt_high to (good) set an upper bound but I think
> > bootm_size is more robust as we can set that and it covers fdt and
> > initrd if present (which not all rk3xxx_common.h are setting).
> 
> We may have a problem on rk3188 and rk3288 configurations. While I can
> convert these to bootm_size, I would have to do so blindly, as I don’t have
> any boards.
> 
> @Heiko: you have added the fdt_high and initrd_high in rk3188_common.h,
> do you have more info and would you have able to test this changed to
> bootm_size instead?

I think I more or less only copied that from rk3288 (adjusted for actual
ram-location) and I'm of course able to test changes you want to do on
rk3188 [Though only starting from thursday].

Heiko



___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [Fwd: [PATCH] mpc83xx: Add support for -msingle-pic-base]

2018-12-10 Thread Mario Six

On Wed, Dec 5, 2018 at 12:56 PM Mario Six  wrote:
>
> Hi Joakim,
> On Wed, Dec 5, 2018 at 11:03 AM Joakim Tjernlund
>  wrote:
> >
> > Ping ?
> >
> > On Thu, 2018-11-29 at 14:09 +0100, Joakim Tjernlund wrote:
> > > OOPS, I forgot to include you in this patch so I do that now :)
> > >
> > >
> > > --- Forwarded Message 
> > > From: Joakim Tjernlund 
> > > To: u-boot@lists.denx.de
> > > Cc: Joakim Tjernlund 
> > > Subject: [PATCH] mpc83xx: Add support for -msingle-pic-base
> > > Date: Wed, 28 Nov 2018 10:59:55 +0100
> > >
> > > -msingle-pic-base is a new gcc(from 4.6) option for ppc and
> > > it reduces the size of my u-boot with about 4 KB.
> > > While at it, add -fno-jump-tables too to save a
> > > few more bytes.
> > >
> > > Signed-off-by: Joakim Tjernlund 
> > > ---
> > >
> > >  I think all PowerPC's can use this but I have only tested
> > >  83xx so just enable for this cpu for now.
> > >
> > >  arch/powerpc/cpu/mpc83xx/config.mk | 1 +
> > >  arch/powerpc/cpu/mpc83xx/start.S   | 3 +++
> > >  2 files changed, 4 insertions(+)
> > >
> > > diff --git a/arch/powerpc/cpu/mpc83xx/config.mk 
> > > b/arch/powerpc/cpu/mpc83xx/config.mk
> > > index 14870eec4d..a07df4d389 100644
> > > --- a/arch/powerpc/cpu/mpc83xx/config.mk
> > > +++ b/arch/powerpc/cpu/mpc83xx/config.mk
> > > @@ -3,3 +3,4 @@
> > >  # Copyright 2004 Freescale Semiconductor, Inc.
> > >
> > >  PLATFORM_CPPFLAGS += -DCONFIG_E300 -msoft-float
> > > +PLATFORM_RELFLAGS += -msingle-pic-base -fno-jump-tables
> > > diff --git a/arch/powerpc/cpu/mpc83xx/start.S 
> > > b/arch/powerpc/cpu/mpc83xx/start.S
> > > index a3bacf138c..c00bb31363 100644
> > > --- a/arch/powerpc/cpu/mpc83xx/start.S
> > > +++ b/arch/powerpc/cpu/mpc83xx/start.S
> > > @@ -288,6 +288,9 @@ in_flash:
> > >   /*--*/
> > >
> > >   GET_GOT /* initialize GOT access*/
> > > + /* Needed for -msingle-pic-base */
> > > + bl  _GLOBAL_OFFSET_TABLE_@local-4
> > > + mflrr30
> > >
> > >   /* r3: IMMR */
> > >   lis r3, CONFIG_SYS_IMMR@h
> >
> Don't worry, I was aware of the patch; just had to find some time for
> testing :-)
>
> Reviewed-by: Mario Six 
> Tested-by: Mario Six  (on MPC8308)
>
> Best regards,
> Mario

Applied to u-boot-mpc83xx/master.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] ARM: at91: Fix 'boot.bin' generation when CONFIG_SD_BOOT is enabled

2018-12-10 Thread Derald D. Woods

On Mon, Dec 10, 2018 at 03:14:05PM +, eugen.hris...@microchip.com wrote:
> 
> 
> On 10.12.2018 16:54, Derald Woods wrote:
> > 
> > 
> > On Mon, Dec 10, 2018 at 8:03 AM  > > wrote:
> > 
> > 
> > 
> > On 10.12.2018 15:01, Derald D. Woods wrote:
> >  > On Mon, Dec 10, 2018 at 08:32:33AM +,
> > eugen.hris...@microchip.com  wrote:
> >  >>
> >  >>
> >  >> On 08.12.2018 21:49, Derald D. Woods wrote:
> >  >>> On AT91 platforms configured for SD_BOOT, this commit avoids the
> >  >>> generation of the PMECC header used for booting from NAND
> > flash. This
> >  >>> issue was found by attempting to boot the SAMA5D3-XPLD board
> > with the
> >  >>> 'sama5d3_xplained_mmc_defconfig'.
> >  >>>
> >  >>> [PMECC Reference]
> >  >>> http://www.at91.com/linux4sam/bin/view/Linux4SAM/AT91Bootstrap
> >  >>>
> >  >>> [Mailing List Thread]
> >  >>> https://lists.denx.de/pipermail/u-boot/2018-December/350666.html
> >  >>>
> >  >>> Fixes: 5541543f ("configs: at91: Remove
> > CONFIG_SYS_EXTRA_OPTIONS assignment")
> >  >>> Reported-by: Daniel Evans  > >
> >  >>> Cc: Robert Nelson  > >
> >  >>> Cc: Eugen Hristev  > >
> >  >>> Cc: Wenyou Yang  > >
> >  >>> Signed-off-by: Derald D. Woods  > >
> >  >>> ---
> >  >>>    scripts/Makefile.spl | 2 ++
> >  >>>    1 file changed, 2 insertions(+)
> >  >>>
> >  >>> diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl
> >  >>> index 22bd8f7c27..e727cb610f 100644
> >  >>> --- a/scripts/Makefile.spl
> >  >>> +++ b/scripts/Makefile.spl
> >  >>> @@ -166,10 +166,12 @@ ifeq ($(CONFIG_SYS_SOC),"at91")
> >  >>>    MKIMAGEFLAGS_boot.bin = -T atmelimage
> >  >>>
> >  >>>    ifeq ($(CONFIG_SPL_GENERATE_ATMEL_PMECC_HEADER),y)
> >  >>> +ifneq ($(CONFIG_SD_BOOT),y)
> >  >>
> >  >> Hi Derald,
> >  >>
> >  >> Thanks for your patch, however, I don't like that we do not use the
> >  >> CONFIG_SPL_GENERATE_ATMEL_PMECC_HEADER anymore... isn't this config
> >  >> supposed to say whether we are going to generate the header or not ?
> >  >>
> >  >
> >  > That is not what is happening with this patch.
> > SPL_GENERATE_ATMEL_PMECC_HEADER
> >  > is not removed. The config still serves its orignal intent. If
> > SD_BOOT
> >  > is configured, then NAND is not being used. In this non-NAND
> > case, the
> >  > header is not needed.
> >  >
> >  >> Checking if "not sd-boot" doesn't look like a good option... we
> > may use
> >  >> SPI boot or QSPI or some other type at some point and the issue will
> >  >> still be there.
> >  >>
> >  >
> >  > This location and method would work for those nod-NAND cases
> > also. See
> >  > below.
> >  >
> >  >> I would rather fix the original patch by Wenyou, namely move the
> > #ifdef
> >  >> below to not have the GENERATE_ATMEL_PMECC enabled for SDBOOT.
> >  >>
> >  >> Does this sound good for you?
> >  >>
> >  >
> >  > If this SPL_GENERATE_ATMEL_PMECC_HEADER only needs to be there
> > for NAND,
> >  > why not guard the 'ifdef ($(CONFIG_NAND_BOOT,y))'? Would this be
> > better?
> >  > Basically we could replace the 'ifneq ($(CONFIG_SD_BOOT),y)' with the
> >  > more appropriate 'ifeq ($(CONFIG_NAND_BOOT),y)'. This would actually
> >  > allow the future use-cases to be added as they become available
> > and can
> >  > be shown to actually boot with the header applied.
> >  >
> >  > I will put together a proper version 2 of my patch later today.
> >  >
> >  > [patch v2]
> >  >
> > 
> > 
> >  > diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl
> >  > index 22bd8f7..e727cb6 100644
> >  > --- a/scripts/Makefile.spl
> >  > +++ b/scripts/Makefile.spl
> >  > @@ -166,10 +166,12 @@ ifeq ($(CONFIG_SYS_SOC),"at91")
> >  >   MKIMAGEFLAGS_boot.bin = -T atmelimage
> >  >
> >  >   ifeq ($(CONFIG_SPL_GENERATE_ATMEL_PMECC_HEADER),y)
> >  > +ifeq ($(CONFIG_NAND_BOOT),y)
> >  >   MKIMAGEFLAGS_boot.bin += -n $(shell
> > $(obj)/../tools/atmel_pmecc_params)
> >  >
> >  >   boot.bin: $(obj)/../tools/atmel_pmecc_params
> >  >   endif
> >  > +endif
> >  >
> >  >   boot.bin: $(obj)/u-boot-spl.bin FORCE
> >  >       $(call if_changed,mkimage)
> >  >
> > 
> > 
> >  >
> >  > This would allow other configurations to 'opt-in' to applying the
> >  > header. Which I think is the

Re: [U-Boot] Regression: dm: i2c: Make i2c_get_chip_for_busnum() fail if the chip is not detected

2018-12-10 Thread Heiko Schocher

Hello Stephen,

Am 10.12.2018 um 19:23 schrieb Stephen Warren:

The following commit:

dm: i2c: Make i2c_get_chip_for_busnum() fail if the chip is not detected
i2c_get_chip_for_busnum() really should check the presence of the chip on
the bus. Most of the users of this function assume that this is done.

... causes a boot failure on NVIDIA Jetson TX2:

:-(

Thanks for detecting so fast!

U-Boot 2019.01-rc1-00220-g7ff485c68b7e (Dec 10 2018 - 11:20:41 -0700)

TEGRA186
Model: NVIDIA P2771--500
DRAM: 7.8 GiB
tegra_ivc_read_get_next_frame() timed out (-12)
tegra_board_init: Cannot find MAX77620 I2C chip
initcall sequence fffa95a8 failed at call 80083480 (err=-110)
### ERROR ### Please RESET the board ###

This may be due to the fact the bus in question is implemented by RPC to a separate CPU, and that
mechanism hasn't been used with probing before. In general though, there's not guarantee that
probing will work even on a local/native I2C bus, since different chips don't support all probe
methods (see i2c-detect in Linux, which supports various different probing methods due to this), so
I'm rather surprised this change was implemented. Is it really necessary? I believe we should revert
it.

Hmm... yes, you are right.

Ah, Jean-Jacques first had another approach, see:

https://lists.denx.de/pipermail/u-boot/2018-October/343230.html

May it is possible to switch back to this approach ?

bye,
Heiko
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [RESEND PATCH v3 00/19] DM_I2C_COMPAT removal for all ti platforms

2018-12-10 Thread Heiko Schocher


Hello Simon,

Am 11.12.2018 um 02:05 schrieb Simon Glass:

Hi Tom,

On Fri, 7 Dec 2018 at 07:23, Tom Rini  wrote:


On Fri, Dec 07, 2018 at 02:50:36PM +0100, Jean-Jacques Hiblot wrote:


This series remove the usage of the DM_I2C_COMPAT option for all the ti
platforms. It also takes this opportunity to not disable DM_I2C in the SPL.

There are a couples of issues to fix:
- CMD_EEPROM does not support the DM API. Fixed by removing this option
   when DM_I2C is used without DM_I2C_COMPAT
- i2c_get_chip_for_busnum() does not work when OF_CONTROL is not used
   (as is the case with am33xx SPL).
- The I2C driver do not support DM_I2C without OF_CONTROL.
- Most of the PMIC drivers do not support the I2C DM API.
- Board detection is done prior DM initialization. Fixed by moving it after
   DM is initialized. That move breaks the DRA7 platforms (The fixes for
   that are at the last 5 patches this series)

When all this is taken care of DM_I2C_COMPAT can be removed and DM_I2C
enabled in the SPL.

This has been tested with the following boards:
- am437x SK
- am335x SK
- am335x beaglebone (both DM and non-DM config)
- dra76 evm
- am572 evm
- k2g evm

The following targets may be impacted by the changes related to
SPL_OF_CONTROL and SPL_OF_PLATDATA:
- am3517_evm_defconfig
- omap3_logic_defconfig
- chromebit_mickey_defconfig
- chromebook_jerry_defconfig
- chromebook_minnie_defconfig
- evb-rk3399_defconfig
- rock_defconfig

It would be nice it some of you could try to boot them.


So I've just reviewed-by all of the TI parts.  Heiko, do you want this
via the I2C tree?  Simon, do you want this via the DM tree?  Do both of
you just want me to grab it instead?  The window on applying this for
this release is closing quickly but this has been around for long enough
that I'd like to see it go in.  Thanks!


Agreed. I am happy to take it, or you can. Please let me know.


I just tooked them and send a pull request to Tom, see:

https://lists.denx.de/pipermail/u-boot/2018-December/351388.html

and Tom apllied it already:

https://lists.denx.de/pipermail/u-boot/2018-December/351431.html

Stephen found a regression, see:
https://lists.denx.de/pipermail/u-boot/2018-December/351480.html

I am not in front of my PC today, so I have to look, may Jean-Jacques
has time to look into?

bye,
Heiko
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: h...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

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

2018-12-10 Thread Keerthy



On Tuesday 11 December 2018 06:34 AM, Simon Glass wrote:
> Hi,
> 
> On Tue, 4 Dec 2018 at 21:10, Keerthy  wrote:
>>
>>
>>
>> On Friday 30 November 2018 08:25 PM, Tom Rini wrote:
>>> On Thu, Nov 29, 2018 at 01:55:14PM -0700, Simon Glass wrote:
>>>
 Hi Tom,

 The following changes since commit 
 e16c888fab5014b022d5781dc534f204460a073b:

   Merge branch '2018-11-28-master-imports' (2018-11-28 23:04:58 -0500)

 are available in the Git repository at:

   git://git.denx.de/u-boot-dm.git tags/pull-29nov18

 for you to fetch changes up to 5ca3927deff30458f5d5b384f6699f70b9509315:

   core: ofnode: Add ofnode_get_addr_size_index (2018-11-29 09:30:06 -0700)

 Results here:

 https://travis-ci.org/sglass68/u-boot/builds/461363284
>>>
>>> NAK.  I don't know _why_ but I can confirm that both within travis:
>>> https://travis-ci.org/trini/u-boot/jobs/461494951
>>> and then locally when I installed clang-7.0 from https://apt.llvm.org/ I
>>> see that:
>>> 5ca3927deff30458f5d5b384f6699f70b9509315 is the first bad commit
>>> commit 5ca3927deff30458f5d5b384f6699f70b9509315
>>> Author: Keerthy 
>>> Date:   Mon Nov 19 11:44:48 2018 +0530
>>>
>>> core: ofnode: Add ofnode_get_addr_size_index
>>>
>>> is totally breaking test.py on sandbox.  It still starts and I don't see
>>> the obvious whats wrong, but I've bisected twice to this same commit.
>>>
>>
>> Okay i am not sure either what is going wrong there. I will take a look at 
>> this.
> 
> I am worried that this might be a unicode problem.
> 
> - build outputs error messages with backquotes, UTF-8, etc.
> - pipe from builder thread to buildman breaks things into 4KB chunks
> - sometimes a UTF-8 char break across a 4KB boundary
> - I/O error results
> 
> I suspect this because buildman's unicode handling is actually a bit
> broken - see how quotes come through in messages on some machines.
> 
> But it might be something else entirely.

Adding Lokesh

Hey Lokesh,

I am yet to dig into this. Seems my patch is breaking test.py on sandbox and
hence it was not pulled.

Regards,
Keerthy
> 
> Regards,
> Simon
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/4] scsi: ceva: add ls1046a soc support

2018-12-10 Thread Peng Ma

Hi York,

got it, thanks.

Best Regards,
Peng
>-Original Message-
>From: York Sun
>Sent: 2018年12月11日 5:10
>To: Peng Ma ; u-boot@lists.denx.de
>Cc: albert.u.b...@aribaud.net; Mingkai Hu ;
>sumit.g...@nxp.com; Pankaj Bansal ; Fabio
>Estevam ; Yinbo Zhu ;
>michal.si...@xilinx.com; s...@chromium.org; Andy Tang
>
>Subject: Re: [PATCH 1/4] scsi: ceva: add ls1046a soc support
>
>On 10/11/18 3:38 AM, Peng Ma wrote:
>> Add ahci compatible support for ls1046a soc.
>>
>> Signed-off-by: Peng Ma 
>> ---
>
>Please remember to sort defconfig using moveconfig.py in the future.
>This set is applied to fsl-qoriq master, awaiting upstream. Thanks.
>
>York
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 16/20] riscv: Do some basic architecture level cpu initialization

2018-12-10 Thread Bin Meng

Hi Lukas,

On Tue, Dec 11, 2018 at 8:01 AM Auer, Lukas
 wrote:
>
> Hi Bin,
>
> On Fri, 2018-12-07 at 06:14 -0800, Bin Meng wrote:
> > Implement arch_cpu_init() to do some basic architecture level cpu
> > initialization, like FPU enable, etc.
> >
> > Signed-off-by: Bin Meng 
> >
> > ---
> >
> > Changes in v2:
> > - use csr_set() to set MSTATUS_FS
> > - only enabling the cycle, time, and instret counters
> > - change to use satp
> >
> >  arch/riscv/cpu/cpu.c | 19 +++
> >  1 file changed, 19 insertions(+)
> >
> > diff --git a/arch/riscv/cpu/cpu.c b/arch/riscv/cpu/cpu.c
> > index 3858e51..194799c 100644
> > --- a/arch/riscv/cpu/cpu.c
> > +++ b/arch/riscv/cpu/cpu.c
> > @@ -7,6 +7,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >
> >  /*
> >   * prior_stage_fdt_address must be stored in the data section since
> > it is used
> > @@ -67,3 +68,21 @@ int arch_early_init_r(void)
> >
> >   return 0;
> >  }
> > +
> > +int arch_cpu_init(void)
> > +{
> > + /* Enable FPU */
> > + if (supports_extension('d') || supports_extension('f')) {
>
> supports_extension does not work when running in supervisor mode
> (unless BBL is patched). Can we maybe use the CPU driver here?
>

Yes, I think so. Will change to use info provided by the CPU driver in v3.

> > + csr_set(MODE_PREFIX(status), MSTATUS_FS);
> > + csr_write(fcsr, 0);
> > + }
> > +
> > + /* Enable perf counters for cycle, time, and instret counters
> > only */
> > + csr_write(MODE_PREFIX(counteren), GENMASK(2, 0));
>
> I would tend to only enable this in mcounteren, so for the supervisor-
> mode. Linux can still enable the counters for user-mode if required.
>

OK.

> > +
> > + /* Disable paging */
> > + if (supports_extension('s'))
> > + csr_write(satp, 0);
>
> This should only be done, when running in machine mode. In supervisor
> mode this would cause issues if we have something other than an
> identity-mapping or paging disabled.
>

I doubt we want to enable paging for S-mode U-Boot, but I am OK to do
such in M-mode only.

Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 05/20] timer: Add generic driver for RISC-V privileged architecture defined timer

2018-12-10 Thread Bin Meng

Hi Lukas,

On Tue, Dec 11, 2018 at 7:17 AM Auer, Lukas
 wrote:
>
> Hi Bin,
>
> On Fri, 2018-12-07 at 06:14 -0800, Bin Meng wrote:
> > RISC-V privileged architecture v1.10 defines a real-time counter,
> > exposed as a memory-mapped machine-mode register - mtime. mtime must
> > run at constant frequency, and the platform must provide a mechanism
> > for determining the timebase of mtime. The mtime register has a
> > 64-bit precision on all RV32, RV64, and RV128 systems.
> >
> > Different platform may have different implementation of the mtime
> > block hence an API riscv_get_time() is required by this driver for
> > platform codes to hide such implementation details. For example,
> > on some platforms mtime is provided by the CLINT module, while on
> > some other platforms a simple 'rdtime' can be used to get the timer
> > counter.
> >
> > With this timer driver the U-Boot timer functionalities like delay
> > works correctly now.
> >
> > Signed-off-by: Bin Meng 
> >
> > ---
> >
> > Changes in v2:
> > - remove the probe to syscon driver in the timer probe, to make the
> >   driver generic, and rely on platform codes to provide the API
> >   riscv_get_time().
> >
> >  drivers/timer/Kconfig   |  8 +++
> >  drivers/timer/Makefile  |  1 +
> >  drivers/timer/riscv_timer.c | 57
> > +
> >  3 files changed, 66 insertions(+)
> >  create mode 100644 drivers/timer/riscv_timer.c
> >
> > diff --git a/drivers/timer/Kconfig b/drivers/timer/Kconfig
> > index b0e6f32..8995979 100644
> > --- a/drivers/timer/Kconfig
> > +++ b/drivers/timer/Kconfig
> > @@ -126,6 +126,14 @@ config OMAP_TIMER
> >   help
> > Select this to enable an timer for Omap devices.
> >
> > +config RISCV_TIMER
> > + bool "RISC-V timer support"
> > + depends on RISCV && TIMER
> > + select RISCV_CLINT
>
> Since we have one generic timer for RISC-V now, I don't think it makes
> sense to specifically select the CLINT here.
>

Ah, yes!

> > + help
> > +   Select this to enable support for the timer as defined
> > +   by the RISC-V privileged architecture spec v1.10.
>
> nit: should we explicitly mention the version here? v1.11 will also
> include the mtime CSR, for example. This is not really important, just
> noticed it now.
>

OK, will remove it in v3.

> Looks good otherwise.
>
> Reviewed-by: Lukas Auer 
>

Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] Please pull fsl-qoriq master

2018-12-10 Thread Tom Rini

On Mon, Dec 10, 2018 at 09:22:52PM +, York Sun wrote:

> Tom,
> 
> The following changes since commit d452f27b3ea806fd99aee4b73a723318032c1d5c:
> 
>   Prepare v2019.01-rc1 (2018-12-03 23:50:13 -0500)
> 
> are available in the Git repository at:
> 
>   git://git.denx.de/u-boot-fsl-qoriq.git tags/fsl-qoriq-for-v2019.01-rc2
> 
> for you to fetch changes up to 4909b89ec763f0c7030fa8474f9b6c5df866b01f:
> 
>   armv8: lx2160a: Add LX2160A SoC Support (2018-12-06 14:37:19 -0800)
> 

Note there were a lot of new defconfigs that I added to existing
MAINTAINER entries as best I could figure.  I've added my travis test to
make this fatal, after this PR.

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] travis: Add check for configs without MAINTAINERS entries

2018-12-10 Thread Tom Rini

On Thu, Dec 06, 2018 at 04:39:43PM -0500, Tom Rini wrote:

> The genboardscfg.py script will emit a WARNING message if we have new
> defconfig files that are not listed in a MAINTAINERS file.  Make new
> cases of this a failure we catch in Travis-CI.
> 
> Signed-off-by: Tom Rini 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] Please pull u-boot-rockchip/master (for-master-20181210)

2018-12-10 Thread Tom Rini

On Mon, Dec 10, 2018 at 02:34:42PM +0100, Philipp Tomsich wrote:

> Tom,
> 
> Here’s another pull-request for rc2.
> I expect a few more bug-fixes and DTS-changes later this week after having 
> talked to
> some of the stakeholders and also having seen internal review requests.
> 
> Build-test result for this one is at 
> https://travis-ci.org/ptomsich/u-boot-rockchip/builds/465884207
> 
> Thanks,
> Philipp.
> 
> 
> 
> The following changes since commit cde578ff36b15ec9c2033f03b94ecf809af7cc64:
> 
>   ARM: mvebu: restore license information in mv_ddr_plat.{c,h} (2018-12-09 
> 17:10:13 -0500)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-rockchip.git tags/for-master-20181210
> 
> for you to fetch changes up to eff43904b7f0c05ed316755e83b5474792059a5c:
> 
>   rockchip: rk3399-puma: enable fan53555 regulators in DTS (2018-12-10 
> 10:04:45 +0100)
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [GIT PULL] u-boot-mips

2018-12-10 Thread Tom Rini

On Mon, Dec 10, 2018 at 07:04:32PM +0100, Daniel Schwierzeck wrote:

> Hi Tom,
> 
> please pull some fixes for MIPS BCM platforms.
> 
> Would you accept another pull request from u-boot-mips/next with the BMIPS 
> part
> of the original series "dma: add channels support"? The changes are isolated 
> to
> BMIPS platform and it would add a user for the new DMA channel support.

So long as it's isolated, yes.

> The following changes since commit cde578ff36b15ec9c2033f03b94ecf809af7cc64:
> 
>   ARM: mvebu: restore license information in mv_ddr_plat.{c,h} (2018-12-09 
> 17:10:13 -0500)
> 
> are available in the Git repository at:
> 
>   git://git.denx.de/u-boot-mips.git tags/mips-fixes-for-2019.01
> 
> for you to fetch changes up to 1410708eeb310e74af23dbee53a7774038cb3918:
> 
>   bmips: bcm6838: fix device tree warning (2018-12-10 18:47:13 +0100)
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

1 2 3 >

1 - 100 of 209 matches

Mail list logo