Re: [U-Boot] Problem with mounting a jffs2 partition on flash.

[Bakhvalov, Denis (Nokia - PL/Wroclaw)]

Hi Wolfgang,

Thank you for your quick reply.

> 1) Is there any specific reason for using JFFS2?  We consider this
>   pretty much deprecated today and usually tend to prefer UBI/UBIFS.

Yes, I'm aware that jffs2 is quite old and ubifs is a successor of jffs2, but 
the reason is that current Linux Kernel has no support for UBI.
It means that if will use UBI in U-boot we can't see the contents in Lunix env 
after it starts.
I understand that it should have solution, but it requires recompiling Linux 
kernel which is also time consuming.

So, for a proof of concept I decided to make it work with jffs2.

> 2) Especially with SoCFPGA it is highly recommended to use current
>   mainline code.

> As mentioned, it is highly recommended to use current mainline
> instead.

> OK - I understand this is with the OLD version of U-Boot, right?
Yes, current logs are from OLD U-boot version.

> What exactly are these "other problems" ?

U-Boot launches, but after that it is hanging.
U-Boot 2016.01 (Feb 05 2016 - 14:15:47 +0100)

CPU:   Altera SoCFPGA Platform
FPGA:  Altera Arria V, D5, version 0x0
BOOT:  QSPI Flash (3.0V)
   Watchdog enabled
I2C:   ready
DRAM:

I will try to tackle this problem also.
However, I must say that I don't have much experience with U-Boot, so maybe I'm 
missing something obvious?

Can you please share some examples of correct configuration for such use case 
(jffs2 partition on NOR flash with SPI)?
I spent some time digging into the code, enabling different defines, so now it 
is complete mess in my sources.

Best regards,
Denis Bakhvalov

MBB Radio Platforms, RFSW
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] u-boot legacy/FIT/FIT+signature compatability

[Troy Benjegerdes]

so I'm tracing through stuff on an am3517-evm board, and finding that with  
  
a FIT image file that works without signature checking compiled in, when
  
I turn on sig checking, if it doesn't find a signature I just get a data
  
abort, *and* the resulting u-boot doesn't recognize old 'legacy' boot   
  
images anymore either. 


I get the point that if you have signatures on, you may not want to hand
over keys to decrypt secure filesystems if you try to boot an unsigned
image, but I think the fallbacks and backwards compatability could be
developed a little better, especially since why now that I have CONFIG_FIT
I now can't seem to load a legacy image.


-- 

Troy Benjegerdes 'da hozer'  ho...@hozed.org
7 elements  earth::water::air::fire::mind::spirit::soulgrid.coop

  Never pick a fight with someone who buys ink by the barrel,
 nor try buy a hacker who makes money by the megahash

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

Re: [U-Boot] [PATCH 2/2] fastboot: sparse: remove unnecessary logging

[Maxime Ripard]

Hi Steve,

On Thu, Feb 04, 2016 at 10:51:00AM -0800, Steve Rae wrote:
> Hi Maxime,
> 
> On Thu, Feb 4, 2016 at 4:20 AM, Maxime Ripard <
> maxime.rip...@free-electrons.com> wrote:
> 
> > Hi Steve,
> >
> > On Wed, Feb 03, 2016 at 12:46:02PM -0800, Steve Rae wrote:
> > > remove logging of the 'skipped' blocks
> > >
> > > Signed-off-by: Steve Rae 
> > > ---
> > >
> > >  common/image-sparse.c | 6 ++
> > >  1 file changed, 2 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/common/image-sparse.c b/common/image-sparse.c
> > > index f02aee4..594bf4e 100644
> > > --- a/common/image-sparse.c
> > > +++ b/common/image-sparse.c
> > > @@ -275,7 +275,6 @@ int store_sparse_image(sparse_storage_t *storage,
> > void *storage_priv,
> > >   sparse_buffer_t *buffer;
> > >   uint32_t start;
> > >   uint32_t total_blocks = 0;
> > > - uint32_t skipped = 0;
> > >   int i;
> > >
> > >   debug("=== Storage ===\n");
> > > @@ -334,7 +333,6 @@ int store_sparse_image(sparse_storage_t *storage,
> > void *storage_priv,
> > > storage,
> > >
> >  sparse_header);
> > >   total_blocks += blkcnt;
> >
> 
> This change (in the first patch), updates the "total_blocks" value, so that
> the "next" chunk has the proper "starting block" address
> (see these line 363...)
> 362 ret = storage->write(storage, storage_priv,
> 363  start + total_blocks,
> 364  buffer_blk_cnt,
> 365  buffer->data);
> Without this change, all the blocks written to the partition after the
> CHUNK_TYPE_DONT_CARE blocks are corrupted (they are not in the correct
> location).
> So, even though we are not actually writing any blocks to this space, the
> space must be maintained!

Ah, yeah, understood.

I'm guessing it was working in my case since I had no DONT_CARE chunks
in the first sparse image sent, and then only DONT_CARE chunks for the
space you already wrote, we got that covered by last_offset... :/

So, yeah, it's broken...

> (Recently, I am now understanding that with NAND, there may be more
> complications; probably cannot just increment the "total_blocks" -- I
> suspect that it is required to actually determine if there are bad blocks
> in this space, and update the "total_blocks" value accordingly)

Yes, if you try to write to a bad block on NAND, you're actually going
to write to the next block, which will introduce some offset, or
you'll going to write to a block that's already been written.

Maxime

> > - skipped += blkcnt;
> > >   continue;
> > >   }
> > >
> > > @@ -375,8 +373,8 @@ int store_sparse_image(sparse_storage_t *storage,
> > void *storage_priv,
> > >   sparse_put_data_buffer(buffer);
> > >   }
> > >
> > > - debug("Wrote %d blocks, skipped %d, expected to write %d blocks\n",
> > > -   total_blocks, skipped,
> > > + debug("Wrote %d blocks, expected to write %d blocks\n",
> > > +   total_blocks,
> >
> > What's the rationale between those two patches?
> >
> 
> see inline comment above
> 
> 
> >
> > Do we really want to treat the DONT_CARE chunks as if they were
> > written?
> >
> 
> I suspect that we do, and "sparse_header->total_blks" actually includes
> them in the count too...
> This "total_blocks" count is actually the number of blocks "processed"
> (which may or may not include actually writing to the partition).
> IMO - I think counting the "skipped blocks is unnecessary.

Ok, sounds good.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Problem with mounting a jffs2 partition on flash.

[Marek Vasut]

On Monday, February 08, 2016 at 01:22:33 PM, Wolfgang Denk wrote:
> Dear Denis,

Hi,

> In message  
you wrote:
> > Yes, I'm aware that jffs2 is quite old and ubifs is a successor of
> > jffs2, but the reason is that current Linux Kernel has no support for
> > UBI.
> 
> What do you mean by "current" here?  UBI/UBIFS support in U-Boot was
> actually adapted from the Linux kernel, so Linux support for UBI/UBIFS
> predates the U-Boot code by a long, long time.
> 
> Do you mean you are using a prehistoric Linux kernel version?
> 
> > I understand that it should have solution, but it requires
> > recompiling Linux kernel which is also time consuming.
> 
> Hm... just recompiling is only a matter of seconds (or, on a very slow
> system, minutes max).  I understand there are other concerns that you
> don't want to update?  Please be aware that there it is likely that
> there other incompatibilities / bugs in such an ancient kernel...
> 
> > > What exactly are these "other problems" ?
> > 
> > U-Boot launches, but after that it is hanging.
> > U-Boot 2016.01 (Feb 05 2016 - 14:15:47 +0100)
> > 
> > CPU:   Altera SoCFPGA Platform
> > FPGA:  Altera Arria V, D5, version 0x0
> > BOOT:  QSPI Flash (3.0V)
> > 
> >Watchdog enabled
> > 
> > I2C:   ready
> > DRAM:
> > 
> > I will try to tackle this problem also.
> > However, I must say that I don't have much experience with U-Boot,
> > so maybe I'm missing something obvious?
> 
> It appears it is hanging in the DRAM initialization phase.  This is a
> very common issue.  Please make sure your memory configuration is
> correct.

It would be very helpful to see the whole boot output, not just U-Boot output.
For example SPL output is missing. Are you using mainline U-Boot SPL or not ?
How did you install the U-Boot on your board ?

> > Can you please share some examples of correct configuration for
> > such use case (jffs2 partition on NOR flash with SPI)?
> 
> You can deal with this later; first you need to have the system
> running at all.  You should focus on this first.
> 
> 
> Best regards,
> 
> Wolfgang Denk

Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 06/18] Migrate CONFIG_ULPI* to Kconfig

[Marek Vasut]

On Sunday, February 07, 2016 at 09:57:26 PM, Mateusz Kulikowski wrote:
> Move CONFIG_USB_ULPI* from headers to defconfigs for boards that use it.
> Also - add CONFIG_USB where necesarry - all boards use it,
> but some are not defining it explicitly.
> 
> Affected boards:
> colibri_t20, harmony, mcx, mt_ventoux, twister,
> zynq_(picozed, zc702, zc706, zed, zybo)
> 
> Signed-off-by: Mateusz Kulikowski 
> Reviewed-by: Simon Glass 

Acked-by: Marek Vasut 

Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Maintainers' email address not valid

[Tom Rini]

On Sat, Feb 06, 2016 at 11:30:12AM +0800, Bin Meng wrote:

> Hi Tom,
> 
> The following U-Boot maintainers' email address seem no longer valid.
> 
> vipin.ku...@st.com
> martin.kra...@tq-systems.de
> kim.phill...@freescale.com
> 
> I believe we should remove them and update the MAINTAINTERS.

Please do, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Problem with mounting a jffs2 partition on flash.

[Wolfgang Denk]

Dear Denis,

In message  
you wrote:
> 
> That's why we want to mount a jffs2 partition on flash at U-boot stage. 
> Unfortunately we've faced some problems and we need help from your side.
> We have Altera SOCFPGA Arria V Board. We use U-boot from SOC Embedded Design 
> Suite.  We have NOR flash with SPI interface (S25FL512S).

1) Is there any specific reason for using JFFS2?  We consider this
   pretty much deprecated today and usually tend to prefer UBI/UBIFS.

2) Especially with SoCFPGA it is highly recommended to use current
   mainline code.

> I prepared Jffs2 partition from Linux env using flash_eraseall -j
> command. It is perfectly mountable from Linux env, I can put files on
> it etc.
> 
> 1.  Currently we are using U-boot 2013:
> U-Boot 2013.01.01 (Jan 26 2016 - 11:50:12)

As mentioned, it is highly recommended to use current mainline
instead.

> # ls
> 
> --- jffs2_part_info: partition number 3 for device nor0 (snor0)
> rescan: First time in use
> raise: Signal # 8 caught
> Scanning JFFS2 FS:  done.
> 
> **The directory Entries**
> 
> **The fragment Entries**
> 
> As you can see ls command fails.

OK - I understand this is with the OLD version of U-Boot, right?


You wrote:

> We are ok to upgrade our U-boot to a fresh one, however we faced
> other problems with it.

What exactly are these "other problems" ?

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
"It ain't so much the things we don't know that get  us  in  trouble.
It's  the  things  we know that ain't so." - Artemus Ward aka Charles
Farrar Brown
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] Problem with mounting a jffs2 partition on flash.

[Bakhvalov, Denis (Nokia - PL/Wroclaw)]

Dear U-boot Support,

My name is Denis and I'm representing Nokia.

We want to have flexibility in choosing which Linux kernel image to load for 
different HW configurations.
But we don't want to define several partitions and use hardcoded addresses on 
the flash to fetch the needed
Linux kernel image. We want to keep them in a one big partition and choose 
between them using their filenames.

That's why we want to mount a jffs2 partition on flash at U-boot stage. 
Unfortunately we've faced some problems and we need help from your side.
We have Altera SOCFPGA Arria V Board. We use U-boot from SOC Embedded Design 
Suite.  We have NOR flash with SPI interface (S25FL512S).

I prepared Jffs2 partition from Linux env using flash_eraseall -j command. It 
is perfectly mountable from Linux env, I can put files on it etc.
1.  Currently we are using U-boot 2013:
U-Boot 2013.01.01 (Jan 26 2016 - 11:50:12)
VERSION : 00.02.04.00

We are ok to upgrade our U-boot to a fresh one, however we faced other problems 
with it.

Here is the actual problem:

# mtdparts
...
---list_partitions---

device nor0 , # parts = 4
#: namesizeoffset  mask_flags
0: boot0x0010  0x  0
1: bootenv 0x0008  0x0010  0
2: SomeInfo0x0198  0x0018  0
3: jffs2spart  0x0250  0x01b0  0

--- mtd_part_info: partition number 0 for device nor0 (snor0)

active partition: nor0,0 - (boot) 0x0010 @ 0x

# chpart nor0,3
...
=> mtddevnum 3,
=> mtddevname jffs2spart
partition changed to nor0,3

# ls

--- jffs2_part_info: partition number 3 for device nor0 (snor0)
rescan: First time in use
raise: Signal # 8 caught
Scanning JFFS2 FS:  done.

**The directory Entries**

**The fragment Entries**

As you can see ls command fails.

I tried to change U-boot configuration several times, with no success.
I can paste my configuration if needed.

But first I would like to hear major hints. Because it could happen so, that 
I'm doing something wrong.

Your support would be greatly appreciated!


Best regards,
Denis Bakhvalov

MBB Radio Platforms, RFSW



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

Re: [U-Boot] Issue with USB mass storage (thumb drives)

[Hannes Schmelzer]

On 04.02.2016 12:28, Marek Vasut wrote:

On Thursday, February 04, 2016 at 09:21:08 AM, Schrempf Frieder wrote:

On 03.02.2016 20:16, Sergei Temerkhanov wrote:

On Wed, Feb 3, 2016 at 8:40 AM, Marek Vasut  wrote:

On Wednesday, February 03, 2016 at 12:49:20 PM, Schrempf Frieder wrote:

On 03.02.2016 12:12, Marek Vasut wrote:

On Wednesday, February 03, 2016 at 11:15:00 AM, Schrempf Frieder wrote:

On 03.02.2016 10:55, Fabio Estevam wrote:

On Wed, Feb 3, 2016 at 7:40 AM, Marek Vasut  wrote:

In that case, debug time.

Usual problems are bad routing of the tracks on the board , so try
with USB 1.1 hub and if that works, that's your problem.

Another suggestion would be to try the 100MB transfer in Linux and
see if this works or not.

That would help us to narrow down whether this is a hardware or
software problem.

Another thing to try may be limiting the value of USB_MAX_XFER_BLK in
common/usb_storage.c

This was a really helpful hint! Thank you Sergei!

I just tried to limit USB_MAX_XFER_BLK to 1/8 of the original value
(65535 -> 8191) and this time the transfer works without timeouts.

As we have a customer who needs this working as soon as possible my
question now is how to properly solve this.
Should I generally limit USB_MAX_XFER_BLK in my u-boot to avoid these
errors? Which value to choose?

Nice! Can you share which sticks are those, ideally brand/type and USB IDs ?

Hi,
that tip works also on my ZYNQ board.

There is some comment around this 'magic-define':

/*
 * The U-Boot EHCI driver can handle any transfer length as long as 
there is
 * enough free heap space left, but the SCSI READ(10) and WRITE(10) 
commands are

 * limited to 65535 blocks.
 */

Can i assume that 16MiB free heap space is enough if i want read a 16MiB 
file ?



Best regards,
Marek Vasut

best regards,
Hannes

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

Re: [U-Boot] [PATCH 2/2] include:configs: Add usb device-tree fixup for all fsl platforms

[Ramneek Mehresh]

> -Original Message-
> From: Ramneek Mehresh
> Sent: Thursday, January 28, 2016 5:45 PM
> To: 'Marek Vasut' 
> Cc: Ramneek Mehresh ; u-
> b...@lists.denx.de; Simon Glass 
> Subject: RE: [PATCH 2/2] include:configs: Add usb device-tree fixup for all 
> fsl
> platforms
> 
> 
> 
> > -Original Message-
> > From: Marek Vasut [mailto:ma...@denx.de]
> > Sent: Thursday, January 28, 2016 5:04 PM
> > To: Ramneek Mehresh 
> > Cc: Ramneek Mehresh ; u-
> > b...@lists.denx.de; Simon Glass 
> > Subject: Re: [PATCH 2/2] include:configs: Add usb device-tree fixup
> > for all fsl platforms
> >
> > On Thursday, January 28, 2016 at 12:05:29 PM, Ramneek Mehresh wrote:
> > > > -Original Message-
> > > > From: Marek Vasut [mailto:ma...@denx.de]
> > > > Sent: Wednesday, January 27, 2016 5:13 PM
> > > > To: Ramneek Mehresh 
> > > > Cc: Ramneek Mehresh ; u-
> > > > b...@lists.denx.de; Simon Glass 
> > > > Subject: Re: [PATCH 2/2] include:configs: Add usb device-tree
> > > > fixup for all fsl platforms
> > > >
> > > > On Wednesday, January 27, 2016 at 12:33:04 PM, Ramneek Mehresh
> > wrote:
> > > > > > -Original Message-
> > > > > > From: Marek Vasut [mailto:ma...@denx.de]
> > > > > > Sent: Wednesday, January 27, 2016 1:57 PM
> > > > > > To: Ramneek Mehresh 
> > > > > > Cc: Ramneek Mehresh ; u-
> > > > > > b...@lists.denx.de; Simon Glass 
> > > > > > Subject: Re: [PATCH 2/2] include:configs: Add usb device-tree
> > > > > > fixup for all fsl platforms
> > > > > >
> > > > > > On Wednesday, January 27, 2016 at 09:26:08 AM, Ramneek
> Mehresh
> > > >
> > > > wrote:
> > > > > > > > -Original Message-
> > > > > > > > From: Marek Vasut [mailto:ma...@denx.de]
> > > > > > > > Sent: Wednesday, January 27, 2016 1:05 PM
> > > > > > > > To: Ramneek Mehresh 
> > > > > > > > Cc: Ramneek Mehresh ; u-
> > > > > > > > b...@lists.denx.de; Simon Glass 
> > > > > > > > Subject: Re: [PATCH 2/2] include:configs: Add usb
> > > > > > > > device-tree fixup for all fsl platforms
> > > > > > > >
> > > > > > > > On Wednesday, January 27, 2016 at 05:30:51 AM, Ramneek
> > > > > > > > Mehresh
> > > > > >
> > > > > > wrote:
> > > > > > > > > > -Original Message-
> > > > > > > > > > From: Marek Vasut [mailto:ma...@denx.de]
> > > > > > > > > > Sent: Wednesday, January 27, 2016 9:57 AM
> > > > > > > > > > To: Ramneek Mehresh 
> > > > > > > > > > Cc: Ramneek Mehresh
> ;
> > u-
> > > > > > > > > > b...@lists.denx.de; Simon Glass 
> > > > > > > > > > Subject: Re: [PATCH 2/2] include:configs: Add usb
> > > > > > > > > > device-tree fixup for all fsl platforms
> > > > > > > > > >
> > > > > > > > > > On Wednesday, January 27, 2016 at 05:14:00 AM, Ramneek
> > > >
> > > > Mehresh
> > > >
> > > > > > > > wrote:
> > > > > > > > > > > > -Original Message-
> > > > > > > > > > > > From: Marek Vasut [mailto:ma...@denx.de]
> > > > > > > > > > > > Sent: Tuesday, January 26, 2016 4:58 PM
> > > > > > > > > > > > To: Ramneek Mehresh
> > 
> > > > > > > > > > > > Cc: u-boot@lists.denx.de
> > > > > > > > > > > > Subject: Re: [PATCH 2/2] include:configs: Add usb
> > > > > > > > > > > > device-tree fixup for all fsl platforms
> > > > > > > > > > > >
> > > > > > > > > > > > On Tuesday, January 26, 2016 at 12:36:58 PM,
> > > > > > > > > > > > Ramneek
> > > >
> > > > Mehresh
> > > >
> > > > > > > > wrote:
> > > > > > > > > > > > > Add usb device-tree fixup for all relevant fsl
> > > > > > > > > > > > > ppc and arm platforms
> > > > > > > > > > > > >
> > > > > > > > > > > > > Signed-off-by: Ramneek Mehresh
> > > > > > > > > >
> > > > > > > > > > 
> > > > > > > > > >
> > > > > > > > > > > > > ---
> > > > > > > > > > > > >
> > > > > > > > > > > > >  board/freescale/b4860qds/b4860qds.c | 2 +-
> > > > > > > > > > > > >  board/freescale/bsc9131rdb/bsc9131rdb.c | 2 ++
> > > > > > > > > > > > >  board/freescale/bsc9132qds/bsc9132qds.c | 2 ++
> > > > > > > > > > > > >  board/freescale/corenet_ds/corenet_ds.c | 4 
> > > > > > > > > > > > >  board/freescale/ls2080aqds/ls2080aqds.c | 4 
> > > > > > > > > > > > >  board/freescale/ls2080ardb/ls2080ardb.c | 4 
> > > > > > > > > > > > >  board/freescale/mpc8308rdb/mpc8308rdb.c | 4
> 
> > > > > > > > > > > > >  board/freescale/mpc8315erdb/mpc8315erdb.c   | 2 ++
> > > > > > > > > > > > >  board/freescale/mpc837xemds/mpc837xemds.c   | 2
> ++
> > > > > > > > > > > > >  board/freescale/mpc837xerdb/mpc837xerdb.c   | 2 ++
> > > > > > > > > > > > >  

[U-Boot] [PATCH] OMAP3: am3517_evm: SD/MMC boot with uEnv.txt, zImage, and FDT

[Derald D. Woods]

Boot with the Linux zImage and am3517-evm.dtb pair, when SD/MMC media
is present. This behavior can be overridden by creating a 'uEnv.txt'
file with 'uenvcmd' defined.

To boot an existing 'uImage', create the following 'uEnv.txt':

[start]-

loaduimage=fatload mmc 0:1 ${loadaddr} ${bootfile}
uenvcmd=run loaduimage; run mmcargs; bootm ${loadaddr}

[end]---

Inspired by similar patches, for other OMAP3 boards, from EEWiki
- https://github.com/eewiki/u-boot-patches/tree/master/v2016.01

Signed-off-by: Derald D. Woods 
---
 include/configs/am3517_evm.h | 48 ++--
 1 file changed, 37 insertions(+), 11 deletions(-)

diff --git a/include/configs/am3517_evm.h b/include/configs/am3517_evm.h
index 4547d7f..4d662ad 100644
--- a/include/configs/am3517_evm.h
+++ b/include/configs/am3517_evm.h
@@ -132,6 +132,10 @@
 #define CONFIG_CMD_EXT2/* EXT2 Support */
 #define CONFIG_CMD_FAT /* FAT support  */
 #define CONFIG_CMD_JFFS2   /* JFFS2 Support*/
+#define CONFIG_CMD_EXT4
+#define CONFIG_CMD_EXT4_WRITE
+
+#define CONFIG_CMD_BOOTZ
 
 #define CONFIG_CMD_I2C /* I2C serial bus support   */
 #define CONFIG_CMD_MMC /* MMC support  */
@@ -184,19 +188,34 @@
 #define CONFIG_EXTRA_ENV_SETTINGS \
"loadaddr=0x8200\0" \
"console=ttyO2,115200n8\0" \
+   "fdtfile=am3517-evm.dtb\0" \
+   "fdtaddr=0x82C0\0" \
+   "vram=16M\0" \
+   "bootenv=uEnv.txt\0" \
+   "cmdline=\0" \
+   "optargs=\0" \
"mmcdev=0\0" \
+   "mmcpart=1\0" \
+   "mmcroot=/dev/mmcblk0p2 rw\0" \
+   "mmcrootfstype=ext4 rootwait fixrtc\0" \
"mmcargs=setenv bootargs console=${console} " \
-   "root=/dev/mmcblk0p2 rw rootwait\0" \
+   "${optargs} " \
+   "root=${mmcroot} " \
+   "rootfstype=${mmcrootfstype} " \
+   "${cmdline}\0" \
"nandargs=setenv bootargs console=${console} " \
"root=/dev/mtdblock4 rw " \
"rootfstype=jffs2\0" \
-   "loadbootscript=fatload mmc ${mmcdev} ${loadaddr} boot.scr\0" \
+   "loadbootenv=fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${bootenv}\0"\
+   "importbootenv=echo Importing environment from mmc ...; " \
+   "env import -t ${loadaddr} ${filesize}\0" \
"bootscript=echo Running bootscript from mmc ...; " \
"source ${loadaddr}\0" \
-   "loaduimage=fatload mmc ${mmcdev} ${loadaddr} uImage\0" \
+   "loadimage=fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${bootfile}\0" \
+   "loadfdt=fatload mmc ${mmcdev}:${mmcpart} ${fdtaddr} ${fdtfile}\0" \
"mmcboot=echo Booting from mmc ...; " \
"run mmcargs; " \
-   "bootm ${loadaddr}\0" \
+   "bootz ${loadaddr} - ${fdtaddr}\0" \
"nandboot=echo Booting from nand ...; " \
"run nandargs; " \
"nand read ${loadaddr} 28 40; " \
@@ -204,13 +223,20 @@
 
 #define CONFIG_BOOTCOMMAND \
"mmc dev ${mmcdev}; if mmc rescan; then " \
-   "if run loadbootscript; then " \
-   "run bootscript; " \
-   "else " \
-   "if run loaduimage; then " \
-   "run mmcboot; " \
-   "else run nandboot; " \
-   "fi; " \
+   "echo SD/MMC found on device $mmcdev; " \
+   "if run loadbootenv; then " \
+   "run importbootenv; " \
+   "fi; " \
+   "echo Checking if uenvcmd is set ...; " \
+   "if test -n $uenvcmd; then " \
+   "echo Running uenvcmd ...; " \
+   "run uenvcmd; " \
+   "fi; " \
+   "echo Running default loadimage ...; " \
+   "setenv bootfile zImage; " \
+   "if run loadimage; then " \
+   "run loadfdt; " \
+   "run mmcboot; " \
"fi; " \
"else run nandboot; fi"
 
-- 
2.7.1

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

Re: [U-Boot] Problem with mounting a jffs2 partition on flash.

[Wolfgang Denk]

Dear Denis,

In message  
you wrote:
> 

> Yes, I'm aware that jffs2 is quite old and ubifs is a successor of
> jffs2, but the reason is that current Linux Kernel has no support for
> UBI.

What do you mean by "current" here?  UBI/UBIFS support in U-Boot was
actually adapted from the Linux kernel, so Linux support for UBI/UBIFS
predates the U-Boot code by a long, long time.

Do you mean you are using a prehistoric Linux kernel version?

> I understand that it should have solution, but it requires
> recompiling Linux kernel which is also time consuming.

Hm... just recompiling is only a matter of seconds (or, on a very slow
system, minutes max).  I understand there are other concerns that you
don't want to update?  Please be aware that there it is likely that
there other incompatibilities / bugs in such an ancient kernel...

> > What exactly are these "other problems" ?
> 
> U-Boot launches, but after that it is hanging.
> U-Boot 2016.01 (Feb 05 2016 - 14:15:47 +0100)
> 
> CPU:   Altera SoCFPGA Platform
> FPGA:  Altera Arria V, D5, version 0x0
> BOOT:  QSPI Flash (3.0V)
>Watchdog enabled
> I2C:   ready
> DRAM:
> 
> I will try to tackle this problem also.
> However, I must say that I don't have much experience with U-Boot,
> so maybe I'm missing something obvious?

It appears it is hanging in the DRAM initialization phase.  This is a
very common issue.  Please make sure your memory configuration is
correct.

> Can you please share some examples of correct configuration for
> such use case (jffs2 partition on NOR flash with SPI)?

You can deal with this later; first you need to have the system
running at all.  You should focus on this first.


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
Far back in the mists of ancient time, in the great and glorious days
of the former Galactic Empire, life was wild, rich  and  largely  tax
free. - Douglas Adams, _The Hitchhiker's Guide to the Galaxy_
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v4] armv7: ls102xa: Enable snooping on transactions from CAAM

[Aneesh Bansal]

CAAM IP lies behind SMMU in the system. Configure SMMU to do the following:
a) Program SCR to bypass transactions with stream ID other than that of CAAM
b) Program S2CR to change memroy attributes of transactions with CAAM's stream
ID (0x10) to cacheable.

CC: Alison Wang 
Signed-off-by: Ruchika Gupta 
Signed-off-by: Nitesh Narayan Lal 
Signed-off-by: Aneesh Bansal 
---
Changes in v4:
- Modified the Commit message
- Functionality moved to SoC Specific file

The patch is dependent on 
http://patchwork.ozlabs.org/patch/579377/

 arch/arm/cpu/armv7/ls102xa/soc.c   |  5 +++
 arch/arm/include/asm/arch-ls102xa/config.h |  2 ++
 arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h  | 35 
 .../include/asm/arch-ls102xa/ls102xa_stream_id.h   |  1 +
 board/freescale/common/ls102xa_stream_id.c | 37 +-
 5 files changed, 79 insertions(+), 1 deletion(-)

diff --git a/arch/arm/cpu/armv7/ls102xa/soc.c b/arch/arm/cpu/armv7/ls102xa/soc.c
index b1b0c71..42cd31a 100644
--- a/arch/arm/cpu/armv7/ls102xa/soc.c
+++ b/arch/arm/cpu/armv7/ls102xa/soc.c
@@ -134,5 +134,10 @@ int ls102xa_smmu_stream_id_init(void)
ls102xa_config_smmu_stream_id(dev_stream_id,
  ARRAY_SIZE(dev_stream_id));
 
+   /* Configure SMMU to make transactions with CAAM stream ID
+* as cacheable
+*/
+   ls1021x_config_smmu_caam_cacheable(0x10);
+
return 0;
 }
diff --git a/arch/arm/include/asm/arch-ls102xa/config.h 
b/arch/arm/include/asm/arch-ls102xa/config.h
index 424fe87..f189ea8 100644
--- a/arch/arm/include/asm/arch-ls102xa/config.h
+++ b/arch/arm/include/asm/arch-ls102xa/config.h
@@ -62,6 +62,8 @@
 
 #define LPUART_BASE(CONFIG_SYS_IMMR + 0x0195)
 
+#define SMMU_BASE  (CONFIG_SYS_IMMR + 0x30)
+
 #define CONFIG_SYS_PCIE1_ADDR  (CONFIG_SYS_IMMR + 0x240)
 #define CONFIG_SYS_PCIE2_ADDR  (CONFIG_SYS_IMMR + 0x250)
 
diff --git a/arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h 
b/arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h
index 0a80772..61da884 100644
--- a/arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h
+++ b/arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h
@@ -435,4 +435,39 @@ struct ccsr_ahci {
 
 uint get_svr(void);
 
+/* MMU 400 */
+#define SMMU_NSCR  (SMMU_BASE + 0x400)
+#define SMMU_SMR   (SMMU_BASE + 0x800)
+#define SMMU_S2CR  (SMMU_BASE + 0xc00)
+
+#define SMMU_NSCR_CLIENTPD_SHIFT   0
+#define SMMU_NSCR_MTCFG_SHIFT  20
+
+#define SMR_SMR_VALID_SHIFT31
+#define SMR_ID_MASK0x7fff
+#define SMR_MASK_SHIFT 16
+
+#define S2CR_WACFG_SHIFT   22
+#define S2CR_WACFG_MASK0x3
+#define S2CR_WACFG_WRITE_ALLOCATE  0x2
+
+#define S2CR_RACFG_SHIFT   20
+#define S2CR_RACFG_MASK0x3
+#define S2CR_RACFG_READ_ALLOCATE   0x2
+
+#define S2CR_TYPE_SHIFT16
+#define S2CR_TYPE_MASK 0x3
+#define S2CR_TYPE_BYPASS   0x01
+
+#define S2CR_MEM_ATTR_SHIFT12
+#define S2CR_MEM_ATTR_MASK 0xf
+#define S2CR_MEM_ATTR_CACHEABLE0xa
+
+#define S2CR_MTCFG 0x0800
+
+#define S2CR_SHCFG_SHIFT   8
+#define S2CR_SHCFG_MASK0x3
+#define S2CR_SHCFG_OUTER_CACHEABLE 0x1
+#define S2CR_SHCFG_INNER_CACHEABLE 0x2
+
 #endif /* __ASM_ARCH_LS102XA_IMMAP_H_ */
diff --git a/arch/arm/include/asm/arch-ls102xa/ls102xa_stream_id.h 
b/arch/arm/include/asm/arch-ls102xa/ls102xa_stream_id.h
index fa571b3..c1d22bf 100644
--- a/arch/arm/include/asm/arch-ls102xa/ls102xa_stream_id.h
+++ b/arch/arm/include/asm/arch-ls102xa/ls102xa_stream_id.h
@@ -71,4 +71,5 @@ struct smmu_stream_id {
 
 void ls1021x_config_caam_stream_id(struct liodn_id_table *tbl, int size);
 void ls102xa_config_smmu_stream_id(struct smmu_stream_id *id, uint32_t num);
+void ls1021x_config_smmu_caam_cacheable(uint32_t liodn);
 #endif
diff --git a/board/freescale/common/ls102xa_stream_id.c 
b/board/freescale/common/ls102xa_stream_id.c
index f434269..8e28d64 100644
--- a/board/freescale/common/ls102xa_stream_id.c
+++ b/board/freescale/common/ls102xa_stream_id.c
@@ -7,6 +7,7 @@
 #include 
 #include 
 #include 
+#include 
 
 void ls102xa_config_smmu_stream_id(struct smmu_stream_id *id, uint32_t num)
 {
@@ -20,7 +21,7 @@ void ls102xa_config_smmu_stream_id(struct smmu_stream_id *id, 
uint32_t num)
 void ls1021x_config_caam_stream_id(struct liodn_id_table *tbl, int size)
 {
int i;
-   u32 liodn;
+   uint32_t liodn;
 
for (i = 0; i < size; i++) {
if (tbl[i].num_ids == 2)
@@ -31,3 +32,37 @@ void ls1021x_config_caam_stream_id(struct 

Re: [U-Boot] [PATCH v2 3/7] drivers: block: disk-uclass: implement scsi_init()

[Mugunthan V N]

On Sunday 07 February 2016 01:59 AM, Simon Glass wrote:
> Hi Bin,
> 
> On 3 February 2016 at 04:59, Mugunthan V N  wrote:
>>
>> Implement scsi_init() api to probe driver model based sata
>> devices.
>>
>> Signed-off-by: Mugunthan V N 
>> ---
>>  drivers/block/disk-uclass.c | 39 +++
>>  1 file changed, 39 insertions(+)
> 
> This patch seems odd to me. I would hope that scsi_init() would go
> away with driver model and it would happen as part of the controller
> probe. But of course we cannot probe SCSI from UCLASS_DISK. I think
> the uclass 'disk' is too broad to be useful.
> 
> So I am wondering whether the decision to use UCLASS_DISK instead of
> UCLASS_AHCI was a mistake.
> 
> Perhaps instead we should have:
> 
> UCLASS_AHCI
> UCLASS_SCSI
> UCLASS_MMC
> etc...
> 
> and each of these devices can have a UCLASS_BLK under them (the block device).
> 
> Possibly we could even have a dummy UCLASS_DISK device under each of
> the above, but I'm not sure that is useful.
> 
> What do you think?
> 

Hmmm, this sounds a better approach to me also. So that we can abstract
all bulk related activities to UCLASS_BLK. I can do an RFC if you are okay?

Regards
Mugunthan V N

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

[U-Boot] [PATCH] Fix variable documented in README.distro for PXE address.

[Vagrant Cascadian]

Fixes typo of pxe_addr_r with pxefile_addr_r.

Signed-off-by: Vagrant Cascadian 
---

 doc/README.distro | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/README.distro b/doc/README.distro
index 3715c8c..e1b7216 100644
--- a/doc/README.distro
+++ b/doc/README.distro
@@ -243,7 +243,7 @@ kernel_addr_r:
 
   A size of 16MB for the kernel is likely adequate.
 
-pxe_addr_r:
+pxefile_addr_r:
 
   Mandatory. The location in RAM where extlinux.conf will be loaded to prior
   to processing.
-- 
2.1.4

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

[U-Boot] [PATCH v4 14/14] SECURE BOOT: Change fsl_secboot_validate function to output image addr

[Saksham Jain]

Currently, fsl_secboot_validate function used to set env variable "img_addr"
to contain address of image being validated.

The function has been changed to output image addr via argument
img_addr_ptr. The command esbc_validate sets the env variable
"img_addr".

This change helps when fsl_secboot_validate function is called from within
UBOOT (because now instead of calling function "getenv("img_addr")"
we can directly get the image address.)

Signed-off-by: Aneesh Bansal 
Signed-off-by: Saksham Jain 
---
Changes for v2:
- No changes
Changes for v3:
- No changes
Changes for v4:
- Cleaned up commit message
 board/freescale/common/cmd_esbc_validate.c | 12 +++-
 board/freescale/common/fsl_validate.c  | 26 +++---
 include/fsl_validate.h |  4 ++--
 3 files changed, 28 insertions(+), 14 deletions(-)

diff --git a/board/freescale/common/cmd_esbc_validate.c 
b/board/freescale/common/cmd_esbc_validate.c
index 375bc24..cefe3cc 100644
--- a/board/freescale/common/cmd_esbc_validate.c
+++ b/board/freescale/common/cmd_esbc_validate.c
@@ -29,6 +29,8 @@ static int do_esbc_validate(cmd_tbl_t *cmdtp, int flag, int 
argc,
char *hash_str = NULL;
uintptr_t haddr;
int ret;
+   uintptr_t img_addr = 0;
+   char buf[20];
 
if (argc < 2)
return cmd_usage(cmdtp);
@@ -43,7 +45,15 @@ static int do_esbc_validate(cmd_tbl_t *cmdtp, int flag, int 
argc,
 * part of header. So, the function is called
 * by passing this argument as 0.
 */
-   ret = fsl_secboot_validate(haddr, hash_str, 0);
+   ret = fsl_secboot_validate(haddr, hash_str, _addr);
+
+   /* Need to set "img_addr" even if validation failure.
+* Required when SB_EN in RCW set and non-fatal error
+* to continue U-Boot
+*/
+   sprintf(buf, "%lx", img_addr);
+   setenv("img_addr", buf);
+
if (ret)
return 1;
 
diff --git a/board/freescale/common/fsl_validate.c 
b/board/freescale/common/fsl_validate.c
index 95059c7..64e4e30 100644
--- a/board/freescale/common/fsl_validate.c
+++ b/board/freescale/common/fsl_validate.c
@@ -570,7 +570,7 @@ static int calc_esbchdr_esbc_hash(struct 
fsl_secboot_img_priv *img)
 
/* Update hash for actual Image */
ret = algo->hash_update(algo, ctx,
-   (u8 *)img->img_addr, img->img_size, 1);
+   (u8 *)(*(img->img_addr_ptr)), img->img_size, 1);
if (ret)
return ret;
 
@@ -646,7 +646,6 @@ static void construct_img_encoded_hash_second(struct 
fsl_secboot_img_priv *img)
  */
 static int read_validate_esbc_client_header(struct fsl_secboot_img_priv *img)
 {
-   char buf[20];
struct fsl_secboot_img_hdr *hdr = >hdr;
void *esbc = (u8 *)(uintptr_t)img->ehdrloc;
u8 *k, *s;
@@ -661,17 +660,14 @@ static int read_validate_esbc_client_header(struct 
fsl_secboot_img_priv *img)
/* If Image Address is not passed as argument to function,
 * then Address and Size must be read from the Header.
 */
-   if (img->img_addr == 0) {
+   if (*(img->img_addr_ptr) == 0) {
#ifdef CONFIG_ESBC_ADDR_64BIT
-   img->img_addr = hdr->pimg64;
+   *(img->img_addr_ptr) = hdr->pimg64;
#else
-   img->img_addr = hdr->pimg;
+   *(img->img_addr_ptr) = hdr->pimg;
#endif
}
 
-   sprintf(buf, "%lx", img->img_addr);
-   setenv("img_addr", buf);
-
if (!hdr->img_size)
return ERROR_ESBC_CLIENT_HEADER_IMG_SIZE;
 
@@ -814,9 +810,17 @@ static int calculate_cmp_img_sig(struct 
fsl_secboot_img_priv *img)
 
return 0;
 }
-
+/* haddr - Address of the header of image to be validated.
+ * arg_hash_str - Option hash string. If provided, this
+ * overides the key hash in the SFP fuses.
+ * img_addr_ptr - Optional pointer to address of image to be validated.
+ * If non zero addr, this overides the addr of image in header,
+ * otherwise updated to image addr in header.
+ * Acts as both input and output of function.
+ * This pointer shouldn't be NULL.
+ */
 int fsl_secboot_validate(uintptr_t haddr, char *arg_hash_str,
-   uintptr_t img_addr)
+   uintptr_t *img_addr_ptr)
 {
struct ccsr_sfp_regs *sfp_regs = (void *)(CONFIG_SYS_SFP_ADDR);
ulong hash[SHA256_BYTES/sizeof(ulong)];
@@ -869,7 +873,7 @@ int fsl_secboot_validate(uintptr_t haddr, char 
*arg_hash_str,
/* Update the information in Private Struct */
hdr = >hdr;
img->ehdrloc = haddr;
-   img->img_addr = img_addr;
+   img->img_addr_ptr = img_addr_ptr;
esbc = (u8 *)img->ehdrloc;
 
memcpy(hdr, esbc, sizeof(struct fsl_secboot_img_hdr));
diff --git a/include/fsl_validate.h b/include/fsl_validate.h
index ff6f6b7..a71e1ce 100644
--- a/include/fsl_validate.h
+++ 

[U-Boot] [PATCH v4 10/14] crypto/fsl: Correct 64bit Write when MMU disabled

[Saksham Jain]

When MMU is disabled, 64bit Write must be at a memory aligned at
64bit Boundary. So, this commit splits the 64bit write into 2 -32bit
writes as the memory location is not guaranteed to be 64bit aligned.
The alignment exception only occurs when MMU is disabled.

Signed-off-by: Aneesh Bansal 
Signed-off-by: Saksham Jain 
---
Changes for v2:
- No changes
Changes for v3:
- No changes
Changes for v4:
- No changes

 drivers/crypto/fsl/desc_constr.h | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/crypto/fsl/desc_constr.h b/drivers/crypto/fsl/desc_constr.h
index 2559ccd..db6ddee 100644
--- a/drivers/crypto/fsl/desc_constr.h
+++ b/drivers/crypto/fsl/desc_constr.h
@@ -85,10 +85,9 @@ static inline void append_ptr(u32 *desc, dma_addr_t ptr)
 #ifdef CONFIG_PHYS_64BIT
/* The Position of low and high part of 64 bit address
 * will depend on the endianness of CAAM Block */
-   union ptr_addr_t ptr_addr;
-   ptr_addr.m_halfs.high = (u32)(ptr >> 32);
-   ptr_addr.m_halfs.low = (u32)ptr;
-   *offset = ptr_addr.m_whole;
+   union ptr_addr_t *ptr_addr = (union ptr_addr_t *)offset;
+   ptr_addr->m_halfs.high = (u32)(ptr >> 32);
+   ptr_addr->m_halfs.low = (u32)ptr;
 #else
*offset = ptr;
 #endif
-- 
1.8.1.4

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

[U-Boot] [PATCH v4 13/14] SECURE BOOT: Halt execution when secure boot fail after reset request

[Saksham Jain]

In case of fatal failure during secure boot execution (e.g. header not found)
it is needed that the execution stops.
Earlier, we were asserting reset request in case in case of failure. But if
the RESET_REQ is not tied off to HRESET, this allows the execution to continue.

This can either be taken care in bootscript (Execute esbc_halt command in case 
of
image verification process) or it can be taken care in Uboot Code.

Doing the latter via a esbc_halt.

Signed-off-by: Aneesh Bansal 
Signed-off-by: Saksham Jain 
---
Changes for v2:
- No changes
Changes for v3:
- No changes
Chnages for v4:
- Cleaned up commit message

 board/freescale/common/cmd_esbc_validate.c | 2 +-
 board/freescale/common/fsl_validate.c  | 5 +
 include/fsl_validate.h | 3 +++
 3 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/board/freescale/common/cmd_esbc_validate.c 
b/board/freescale/common/cmd_esbc_validate.c
index dfa3e21..375bc24 100644
--- a/board/freescale/common/cmd_esbc_validate.c
+++ b/board/freescale/common/cmd_esbc_validate.c
@@ -8,7 +8,7 @@
 #include 
 #include 
 
-static int do_esbc_halt(cmd_tbl_t *cmdtp, int flag, int argc,
+int do_esbc_halt(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
 {
if (fsl_check_boot_mode_secure() == 0) {
diff --git a/board/freescale/common/fsl_validate.c 
b/board/freescale/common/fsl_validate.c
index c12b9c9..95059c7 100644
--- a/board/freescale/common/fsl_validate.c
+++ b/board/freescale/common/fsl_validate.c
@@ -325,6 +325,8 @@ static void fsl_secboot_header_verification_failure(void)
 
printf("Generating reset request\n");
do_reset(NULL, 0, 0, NULL);
+   /* If reset doesn't coocur, halt execution */
+   do_esbc_halt(NULL, 0, 0, NULL);
 }
 
 /*
@@ -355,6 +357,9 @@ static void fsl_secboot_image_verification_failure(void)
 
printf("Generating reset request\n");
do_reset(NULL, 0, 0, NULL);
+   /* If reset doesn't coocur, halt execution */
+   do_esbc_halt(NULL, 0, 0, NULL);
+
} else {
change_sec_mon_state(HPSR_SSM_ST_TRUST,
 HPSR_SSM_ST_NON_SECURE);
diff --git a/include/fsl_validate.h b/include/fsl_validate.h
index f812c1a..ff6f6b7 100644
--- a/include/fsl_validate.h
+++ b/include/fsl_validate.h
@@ -242,6 +242,9 @@ struct fsl_secboot_img_priv {
uint32_t img_size;  /* ESBC Image Size */
 };
 
+int do_esbc_halt(cmd_tbl_t *cmdtp, int flag, int argc,
+   char * const argv[]);
+
 int fsl_secboot_validate(uintptr_t haddr, char *arg_hash_str,
uintptr_t img_loc);
 int fsl_secboot_blob_encap(cmd_tbl_t *cmdtp, int flag, int argc,
-- 
1.8.1.4

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

[U-Boot] [PATCH v4 12/14] SECURE_BOOT: Use default bootargs during Secure Boot

[Saksham Jain]

For secure boot, currently we were using fixed bootargs for
all SoCs. This is not needed and we can use the bootargs
which are used in non-secure boot.
Incase bootargs are not defined for non-secure boot of any
platform, we use default bootargs.

Signed-off-by: Aneesh Bansal 
Signed-off-by: Saksham Jain 
---
Changes for v2:
- No changes
Changes for v3:
- No changes
Changes for v4:
- Cleaned up commit message

 include/config_fsl_chain_trust.h | 14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/include/config_fsl_chain_trust.h b/include/config_fsl_chain_trust.h
index aa222bb..566fd80 100644
--- a/include/config_fsl_chain_trust.h
+++ b/include/config_fsl_chain_trust.h
@@ -44,11 +44,18 @@
  *  "41066b564c6ffcef40ccbc1e0a5d0d519604000c785d97bbefd25e4d288d1c8b"
  */
 
+#ifdef CONFIG_BOOTARGS
+#define CONFIG_SET_BOOTARGS"setenv bootargs \'" CONFIG_BOOTARGS" \';"
+#else
+#define CONFIG_SET_BOOTARGS"setenv bootargs \'root=/dev/ram "  \
+   "rw console=ttyS0,115200 ramdisk_size=60\';"
+#endif
+
+
 #ifdef CONFIG_BOOTSCRIPT_KEY_HASH
 #define CONFIG_SECBOOT \
"setenv bs_hdraddr " __stringify(CONFIG_BOOTSCRIPT_HDR_ADDR)";" \
-   "setenv bootargs \'root=/dev/ram rw console=ttyS0,115200 "  \
-   "ramdisk_size=60\';"\
+   CONFIG_SET_BOOTARGS \
CONFIG_EXTRA_ENV\
"esbc_validate $bs_hdraddr " \
  __stringify(CONFIG_BOOTSCRIPT_KEY_HASH)";" \
@@ -57,8 +64,7 @@
 #else
 #define CONFIG_SECBOOT \
"setenv bs_hdraddr " __stringify(CONFIG_BOOTSCRIPT_HDR_ADDR)";" \
-   "setenv bootargs \'root=/dev/ram rw console=ttyS0,115200 "  \
-   "ramdisk_size=60\';"\
+   CONFIG_SET_BOOTARGS \
CONFIG_EXTRA_ENV\
"esbc_validate $bs_hdraddr;" \
"source $img_addr;" \
-- 
1.8.1.4

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

[U-Boot] [PATCH v4 04/14] SECURE BOOT: Add Secure Boot support on ls2080aqds/rdb

[Saksham Jain]

Following changes have been made to enable secure boot:
1) Sec_init has been called in starting to initialize SEC Block (CAAM)
which will be used for Secure Boot validation later for both ls2080a qds
and rdb
2) 64Bit address in ESBC Header has been enabled as this SoC is based on
armv8
3) Secure Boot defconfigs created for boards (NOR Boot).

Signed-off-by: Aneesh Bansal 
Signed-off-by: Saksham Jain 
---
Changes for v2:
- No changes
Changes for v3:
- No changes
Changes for v4:
- Cleaned up commit message

 arch/arm/include/asm/fsl_secure_boot.h   |  9 +++--
 board/freescale/ls2080aqds/ls2080aqds.c  |  5 -
 board/freescale/ls2080ardb/ls2080ardb.c  |  5 -
 configs/ls2080aqds_SECURE_BOOT_defconfig | 15 +++
 configs/ls2080ardb_SECURE_BOOT_defconfig | 15 +++
 configs/ls2085aqds_SECURE_BOOT_defconfig | 15 +++
 configs/ls2085ardb_SECURE_BOOT_defconfig | 15 +++
 include/configs/ls2080aqds.h |  2 ++
 include/configs/ls2080ardb.h |  2 ++
 9 files changed, 79 insertions(+), 4 deletions(-)
 create mode 100644 configs/ls2080aqds_SECURE_BOOT_defconfig
 create mode 100644 configs/ls2080ardb_SECURE_BOOT_defconfig
 create mode 100644 configs/ls2085aqds_SECURE_BOOT_defconfig
 create mode 100644 configs/ls2085ardb_SECURE_BOOT_defconfig

diff --git a/arch/arm/include/asm/fsl_secure_boot.h 
b/arch/arm/include/asm/fsl_secure_boot.h
index 3e46c63..e65caed 100644
--- a/arch/arm/include/asm/fsl_secure_boot.h
+++ b/arch/arm/include/asm/fsl_secure_boot.h
@@ -18,7 +18,9 @@
 #ifdef CONFIG_CHAIN_OF_TRUST
 #define CONFIG_CMD_ESBC_VALIDATE
 #define CONFIG_CMD_BLOB
+#define CONFIG_CMD_HASH
 #define CONFIG_FSL_SEC_MON
+#define CONFIG_SHA_HW_ACCEL
 #define CONFIG_SHA_PROG_HW_ACCEL
 #define CONFIG_RSA
 #define CONFIG_RSA_FREESCALE_EXP
@@ -47,8 +49,11 @@
 
 #endif
 
-#ifdef CONFIG_LS1043A
-/* For LS1043 (ARMv8), ESBC image Address in Header is 64 bit */
+#if defined(CONFIG_LS1043A) || defined(CONFIG_LS2080A) ||\
+   defined(CONFIG_LS2085A)
+/* For LS1043 (ARMv8), ESBC image Address in Header is 64 bit
+ * Similiarly for LS2080 and LS2085
+ */
 #define CONFIG_ESBC_ADDR_64BIT
 #endif
 
diff --git a/board/freescale/ls2080aqds/ls2080aqds.c 
b/board/freescale/ls2080aqds/ls2080aqds.c
index aa256a2..ab101a4 100644
--- a/board/freescale/ls2080aqds/ls2080aqds.c
+++ b/board/freescale/ls2080aqds/ls2080aqds.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "../common/qixis.h"
 #include "ls2080aqds_qixis.h"
@@ -248,7 +249,9 @@ int arch_misc_init(void)
 #ifdef CONFIG_FSL_DEBUG_SERVER
debug_server_init();
 #endif
-
+#ifdef CONFIG_FSL_CAAM
+   sec_init();
+#endif
return 0;
 }
 #endif
diff --git a/board/freescale/ls2080ardb/ls2080ardb.c 
b/board/freescale/ls2080ardb/ls2080ardb.c
index c63b639..0c78a41 100644
--- a/board/freescale/ls2080ardb/ls2080ardb.c
+++ b/board/freescale/ls2080ardb/ls2080ardb.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "../common/qixis.h"
 #include "ls2080ardb_qixis.h"
@@ -214,7 +215,9 @@ int arch_misc_init(void)
 #ifdef CONFIG_FSL_DEBUG_SERVER
debug_server_init();
 #endif
-
+#ifdef CONFIG_FSL_CAAM
+   sec_init();
+#endif
return 0;
 }
 #endif
diff --git a/configs/ls2080aqds_SECURE_BOOT_defconfig 
b/configs/ls2080aqds_SECURE_BOOT_defconfig
new file mode 100644
index 000..5c50894
--- /dev/null
+++ b/configs/ls2080aqds_SECURE_BOOT_defconfig
@@ -0,0 +1,15 @@
+CONFIG_ARM=y
+CONFIG_TARGET_LS2080AQDS=y
+# CONFIG_SYS_MALLOC_F is not set
+CONFIG_DM_SPI=y
+CONFIG_DM_SPI_FLASH=y
+CONFIG_DEFAULT_DEVICE_TREE="fsl-ls2080a-qds"
+CONFIG_SYS_EXTRA_OPTIONS="SYS_FSL_DDR4, LS2080A, SECURE_BOOT"
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_OF_CONTROL=y
+CONFIG_NET_RANDOM_ETHADDR=y
+CONFIG_DM=y
+CONFIG_NETDEVICES=y
+CONFIG_E1000=y
+CONFIG_SYS_NS16550=y
+CONFIG_FSL_DSPI=y
diff --git a/configs/ls2080ardb_SECURE_BOOT_defconfig 
b/configs/ls2080ardb_SECURE_BOOT_defconfig
new file mode 100644
index 000..9456e04
--- /dev/null
+++ b/configs/ls2080ardb_SECURE_BOOT_defconfig
@@ -0,0 +1,15 @@
+CONFIG_ARM=y
+CONFIG_TARGET_LS2080ARDB=y
+# CONFIG_SYS_MALLOC_F is not set
+CONFIG_DM_SPI=y
+CONFIG_DM_SPI_FLASH=y
+CONFIG_DEFAULT_DEVICE_TREE="fsl-ls2080a-rdb"
+CONFIG_SYS_EXTRA_OPTIONS="SYS_FSL_DDR4, LS2080A, SECURE_BOOT"
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_OF_CONTROL=y
+CONFIG_NET_RANDOM_ETHADDR=y
+CONFIG_DM=y
+CONFIG_NETDEVICES=y
+CONFIG_E1000=y
+CONFIG_SYS_NS16550=y
+CONFIG_FSL_DSPI=y
diff --git a/configs/ls2085aqds_SECURE_BOOT_defconfig 
b/configs/ls2085aqds_SECURE_BOOT_defconfig
new file mode 100644
index 000..8f96fc0
--- /dev/null
+++ b/configs/ls2085aqds_SECURE_BOOT_defconfig
@@ -0,0 +1,15 @@
+CONFIG_ARM=y
+CONFIG_TARGET_LS2080AQDS=y
+# CONFIG_SYS_MALLOC_F is not set
+CONFIG_DM_SPI=y
+CONFIG_DM_SPI_FLASH=y
+CONFIG_DEFAULT_DEVICE_TREE="fsl-ls2080a-qds"
+CONFIG_SYS_EXTRA_OPTIONS="SYS_FSL_DDR4, LS2085A, 

[U-Boot] [PATCH v4 03/14] SECURE BOOT: Add new ESBC header for ls-ch3 Secure Boot

[Saksham Jain]

For Secure Boot, a header is used to identify key table, signature
and image address. For LS-CH3, there is a new header structure being used.

The following changes are there in the new header:
1) Currently IE Table (Key extension) feature is not supported
2) Single Key feature is not supported. Keys must be in table format.
3) Hence, SRK (Key table) is by default currently always present.
4) Max Key number has increase from 4 to 8. 8th Key is unrevockable.
5) New Barker Code is being used.

Signed-off-by: Aneesh Bansal 
Signed-off-by: Saksham Jain 
---
Changes for v2:
- No changes
Changes for v3:
- No changes
Changes for v4:
- Cleaned up commit message

 arch/arm/include/asm/arch-fsl-layerscape/config.h |  3 +-
 arch/arm/include/asm/fsl_secure_boot.h|  4 ++
 board/freescale/common/fsl_validate.c | 35 +++--
 include/fsl_secboot_err.h |  3 ++
 include/fsl_validate.h| 60 ---
 5 files changed, 91 insertions(+), 14 deletions(-)

diff --git a/arch/arm/include/asm/arch-fsl-layerscape/config.h 
b/arch/arm/include/asm/arch-fsl-layerscape/config.h
index d2d54b7..e975e25 100644
--- a/arch/arm/include/asm/arch-fsl-layerscape/config.h
+++ b/arch/arm/include/asm/arch-fsl-layerscape/config.h
@@ -79,7 +79,8 @@
 /* Security Monitor */
 #define CONFIG_SYS_FSL_SEC_MON_LE
 
-
+/* Secure Boot */
+#define CONFIG_ESBC_HDR_LS
 
 /* Cache Coherent Interconnect */
 #define CCI_MN_BASE0x0400
diff --git a/arch/arm/include/asm/fsl_secure_boot.h 
b/arch/arm/include/asm/fsl_secure_boot.h
index 0da0599..3e46c63 100644
--- a/arch/arm/include/asm/fsl_secure_boot.h
+++ b/arch/arm/include/asm/fsl_secure_boot.h
@@ -40,9 +40,13 @@
  * The feature is only applicable in case of NOR boot and is
  * not applicable in case of RAMBOOT (NAND, SD, SPI).
  */
+#ifndef CONFIG_ESBC_HDR_LS
+/* Current Key EXT feature not available in LS ESBC Header */
 #define CONFIG_FSL_ISBC_KEY_EXT
 #endif
 
+#endif
+
 #ifdef CONFIG_LS1043A
 /* For LS1043 (ARMv8), ESBC image Address in Header is 64 bit */
 #define CONFIG_ESBC_ADDR_64BIT
diff --git a/board/freescale/common/fsl_validate.c 
b/board/freescale/common/fsl_validate.c
index 8fd6dd6..c12b9c9 100644
--- a/board/freescale/common/fsl_validate.c
+++ b/board/freescale/common/fsl_validate.c
@@ -35,7 +35,13 @@ static const u8 hash_identifier[] = { 0x30, 0x31, 0x30, 
0x0d, 0x06, 0x09, 0x60,
};
 
 static u8 hash_val[SHA256_BYTES];
+
+#ifdef CONFIG_ESBC_HDR_LS
+/* New Barker Code for LS ESBC Header */
+static const u8 barker_code[ESBC_BARKER_LEN] = { 0x12, 0x19, 0x20, 0x01 };
+#else
 static const u8 barker_code[ESBC_BARKER_LEN] = { 0x68, 0x39, 0x27, 0x81 };
+#endif
 
 void branch_to_self(void) __attribute__ ((noreturn));
 
@@ -157,10 +163,15 @@ static int get_ie_info_addr(u32 *ie_addr)
 /* This function checks srk_table_flag in header and set/reset srk_flag.*/
 static u32 check_srk(struct fsl_secboot_img_priv *img)
 {
+#ifdef CONFIG_ESBC_HDR_LS
+   /* In LS, No SRK Flag as SRK is always present*/
+   return 1;
+#else
if (img->hdr.len_kr.srk_table_flag & SRK_FLAG)
return 1;
 
return 0;
+#endif
 }
 
 /* This function returns ospr's key_revoc values.*/
@@ -223,6 +234,7 @@ static u32 read_validate_srk_tbl(struct 
fsl_secboot_img_priv *img)
 }
 #endif
 
+#ifndef CONFIG_ESBC_HDR_LS
 static u32 read_validate_single_key(struct fsl_secboot_img_priv *img)
 {
struct fsl_secboot_img_hdr *hdr = >hdr;
@@ -238,6 +250,7 @@ static u32 read_validate_single_key(struct 
fsl_secboot_img_priv *img)
 
return 0;
 }
+#endif /* CONFIG_ESBC_HDR_LS */
 
 #if defined(CONFIG_FSL_ISBC_KEY_EXT)
 static u32 read_validate_ie_tbl(struct fsl_secboot_img_priv *img)
@@ -388,6 +401,7 @@ void fsl_secboot_handle_error(int error)
case ERROR_ESBC_CLIENT_HEADER_SIG_KEY_MOD:
case ERROR_ESBC_CLIENT_HEADER_SG_ESBC_EP:
case ERROR_ESBC_CLIENT_HEADER_SG_ENTIRES_BAD:
+   case ERROR_KEY_TABLE_NOT_FOUND:
 #ifdef CONFIG_KEY_REVOCATION
case ERROR_ESBC_CLIENT_HEADER_KEY_REVOKED:
case ERROR_ESBC_CLIENT_HEADER_INVALID_SRK_NUM_ENTRY:
@@ -536,11 +550,18 @@ static int calc_esbchdr_esbc_hash(struct 
fsl_secboot_img_priv *img)
if (!key_hash && check_ie(img))
key_hash = 1;
 #endif
-   if (!key_hash)
+#ifndef CONFIG_ESBC_HDR_LS
+/* No single key support in LS ESBC header */
+   if (!key_hash) {
ret = algo->hash_update(algo, ctx,
img->img_key, img->hdr.key_len, 0);
+   key_hash = 1;
+   }
+#endif
if (ret)
return ret;
+   if (!key_hash)
+   return ERROR_KEY_TABLE_NOT_FOUND;
 
/* Update hash for actual Image */
ret = algo->hash_update(algo, ctx,
@@ -626,8 +647,6 @@ static int read_validate_esbc_client_header(struct 
fsl_secboot_img_priv 

[U-Boot] [PATCH v4 06/14] SECURE BOOT: Copy Bootscript and header from NOR to DDR for LS2080/5

[Saksham Jain]

During Secure Boot, a bootscript is validated using its header.
This patch copies both these images to DDR from NOR and then validates and
executed them from DDR. (If NOR is the boot source for LS2080 and LS2085).

This copy step is done to make this step common across booting sources.
Because in case of non-xip memories (e.g. NAND, SD) it is neccessary to copy
both these images to DDR.

For other ARM Platforms (ls1043 and ls1020), header is not copied from NOR
to DDR (otherwise customers will need to modify the existing headers).

Signed-off-by: Aneesh Bansal 
Signed-off-by: Saksham Jain 
---
Changes for v2:
- for platform such as ls1043 and ls1021, boot header in NOR.
Not copied to NOR. For them, fixed CONFIG_BOOTSCRIPT_HDR_ADDR
to CONFIG_BS_HDR_ADDR_FLASH.
Changes for v3:
- No change
Changes for v4:
-Cleaned up commit message


 arch/arm/include/asm/fsl_secure_boot.h | 28 +---
 include/config_fsl_chain_trust.h   | 11 +++
 2 files changed, 32 insertions(+), 7 deletions(-)

diff --git a/arch/arm/include/asm/fsl_secure_boot.h 
b/arch/arm/include/asm/fsl_secure_boot.h
index 7c55ea1..7ab9623 100644
--- a/arch/arm/include/asm/fsl_secure_boot.h
+++ b/arch/arm/include/asm/fsl_secure_boot.h
@@ -62,11 +62,33 @@
"setenv initrd_high 0xcfff;"\
"setenv hwconfig \'fsl_ddr:ctlr_intlv=null,bank_intlv=null\';"
 
-/* The address needs to be modified according to NOR memory map */
+/* Copying Bootscript and Header to DDR from NOR for LS2 and for rest, from
+ * Non-XIP Memory (Nand/SD)*/
+#if defined(CONFIG_SYS_RAMBOOT) || defined(CONFIG_LS2080A) ||\
+   defined(CONFIG_LS2085A)
+#define CONFIG_BOOTSCRIPT_COPY_RAM
+#endif
+/* The address needs to be modified according to NOR and DDR memory map */
 #if defined(CONFIG_LS2080A) || defined(CONFIG_LS2085A)
-#define CONFIG_BOOTSCRIPT_HDR_ADDR 0x58392
+#define CONFIG_BS_HDR_ADDR_FLASH   0x58392
+#define CONFIG_BS_ADDR_FLASH   0x58390
+#define CONFIG_BS_HDR_ADDR_RAM 0xa392
+#define CONFIG_BS_ADDR_RAM 0xa390
+#else
+#define CONFIG_BS_HDR_ADDR_FLASH   0x600a
+#define CONFIG_BS_ADDR_FLASH   0x6006
+#define CONFIG_BS_HDR_ADDR_RAM 0xa006
+#define CONFIG_BS_ADDR_RAM 0xa006
+#endif
+
+#ifdef CONFIG_BOOTSCRIPT_COPY_RAM
+#define CONFIG_BOOTSCRIPT_HDR_ADDR CONFIG_BS_HDR_ADDR_RAM
+#define CONFIG_BS_HDR_SIZE 0x2000
+#define CONFIG_BOOTSCRIPT_ADDR CONFIG_BS_ADDR_RAM
+#define CONFIG_BS_SIZE 0x1000
 #else
-#define CONFIG_BOOTSCRIPT_HDR_ADDR 0x600a
+#define CONFIG_BOOTSCRIPT_HDR_ADDR CONFIG_BS_HDR_ADDR_FLASH
+/* BS_HDR_SIZE, BOOTSCRIPT_ADDR and BS_SIZE are not required */
 #endif
 
 #include 
diff --git a/include/config_fsl_chain_trust.h b/include/config_fsl_chain_trust.h
index 45dda56..aa222bb 100644
--- a/include/config_fsl_chain_trust.h
+++ b/include/config_fsl_chain_trust.h
@@ -65,8 +65,6 @@
"esbc_halt\0"
 #endif
 
-/* For secure boot flow, default environment used will be used */
-#if defined(CONFIG_SYS_RAMBOOT)
 #ifdef CONFIG_BOOTSCRIPT_COPY_RAM
 #define CONFIG_BS_COPY_ENV \
"setenv bs_hdr_ram " __stringify(CONFIG_BS_HDR_ADDR_RAM)";" \
@@ -76,14 +74,19 @@
"setenv bs_flash " __stringify(CONFIG_BS_ADDR_FLASH)";" \
"setenv bs_size " __stringify(CONFIG_BS_SIZE)";"
 
+/* For secure boot flow, default environment used will be used */
+#if defined(CONFIG_SYS_RAMBOOT)
 #if defined(CONFIG_RAMBOOT_NAND)
 #define CONFIG_BS_COPY_CMD \
"nand read $bs_hdr_ram $bs_hdr_flash $bs_hdr_size ;" \
"nand read $bs_ram $bs_flash $bs_size ;"
 #endif /* CONFIG_RAMBOOT_NAND */
-#endif /* CONFIG_BOOTSCRIPT_COPY_RAM */
-
+#else
+#define CONFIG_BS_COPY_CMD \
+   "cp.b $bs_hdr_flash $bs_hdr_ram  $bs_hdr_size ;" \
+   "cp.b $bs_flash $bs_ram  $bs_size ;"
 #endif
+#endif /* CONFIG_BOOTSCRIPT_COPY_RAM */
 
 #ifndef CONFIG_BS_COPY_ENV
 #define CONFIG_BS_COPY_ENV
-- 
1.8.1.4

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

[U-Boot] [PATCH v4 09/14] armv8: fsl-lsch3: Disable SMMU during Secure Boot

[Saksham Jain]

During secure boot, SMMU is enabled on POR by SP bootrom.
SMMU needs to be put in Bypass mode in uboot to
enable CAAM transcations to pass through.

During Nonsecure Boot, SP BootROM doesn't enable SMMU and
at reset SMMU is in bypass mode.

Signed-off-by: Aneesh Bansal 
Signed-off-by: Saksham Jain 
---
Changes for v2:
- No changes
Changes for v3:
- No changes
Changes for v4:
- No changes

 arch/arm/cpu/armv8/fsl-layerscape/soc.c| 18 +-
 arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h | 15 +++
 2 files changed, 32 insertions(+), 1 deletion(-)

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/soc.c 
b/arch/arm/cpu/armv8/fsl-layerscape/soc.c
index 7ff0148..0043523 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/soc.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/soc.c
@@ -151,7 +151,14 @@ static void erratum_a009203(void)
 #endif
 #endif
 }
-
+void bypass_smmu(void)
+{
+   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);
+}
 void fsl_lsch3_early_init_f(void)
 {
erratum_a008751();
@@ -160,6 +167,15 @@ void fsl_lsch3_early_init_f(void)
erratum_a009203();
erratum_a008514();
erratum_a008336();
+#ifdef CONFIG_CHAIN_OF_TRUST
+   /* 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
+   */
+   if (fsl_check_boot_mode_secure() == 1)
+   bypass_smmu();
+#endif
 }
 
 #ifdef CONFIG_SCSI_AHCI_PLAT
diff --git a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h 
b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
index 1fc51e0..06d4856 100644
--- a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
+++ b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
@@ -83,6 +83,21 @@
 /* Security Monitor */
 #define CONFIG_SYS_SEC_MON_ADDR(CONFIG_SYS_IMMR + 0x00e9)
 
+/* MMU 500 */
+#define SMMU_SCR0  (SMMU_BASE + 0x0)
+#define SMMU_SCR1  (SMMU_BASE + 0x4)
+#define SMMU_SCR2  (SMMU_BASE + 0x8)
+#define SMMU_SACR  (SMMU_BASE + 0x10)
+#define SMMU_IDR0  (SMMU_BASE + 0x20)
+#define SMMU_IDR1  (SMMU_BASE + 0x24)
+
+#define SMMU_NSCR0 (SMMU_BASE + 0x400)
+#define SMMU_NSCR2 (SMMU_BASE + 0x408)
+#define SMMU_NSACR (SMMU_BASE + 0x410)
+
+#define SCR0_CLIENTPD_MASK 0x0001
+#define SCR0_USFCFG_MASK   0x0400
+
 
 /* PCIe */
 #define CONFIG_SYS_PCIE1_ADDR  (CONFIG_SYS_IMMR + 0x240)
-- 
1.8.1.4

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

Re: [U-Boot] [U-Boot, PATCHv2] common/memsize.c: Simplify RAM size detection

[Eddy Petrișor]

2016-02-08 22:49 GMT+02:00 Tom Rini :
> On Tue, Feb 02, 2016 at 10:15:28PM +0200, Eddy Petrișor wrote:
>
>> The case of memory of size 0 is not that different from a memory of any other
>> size, so we remove the duplicate code and treat the small differences when it
>> is the case.
>>
>> Signed-off-by: Eddy Petrișor 
>
> Applied to u-boot/master, thanks!

Thank you!

-- 
Eddy Petrișor
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v4 08/14] armv8 : ls2080: Add config for endianess of CCSR GUR

[Saksham Jain]

The GUR (DCFG) registers in CCSR space are in LE format
for ls2080/ls2085. Defined a config CONFIG_SYS_FSL_CCSR_GUR_LE in
arch/arm/include/asm/arch-fsl-layerscape/config.h

Signed-off-by: Aneesh Bansal 
Signed-off-by: Saksham Jain 
---
Changes for v2:
- No changes
Changes for v3:
- No changes
Changes for v4:
- No changes

 arch/arm/include/asm/arch-fsl-layerscape/config.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/include/asm/arch-fsl-layerscape/config.h 
b/arch/arm/include/asm/arch-fsl-layerscape/config.h
index e975e25..7f95191 100644
--- a/arch/arm/include/asm/arch-fsl-layerscape/config.h
+++ b/arch/arm/include/asm/arch-fsl-layerscape/config.h
@@ -82,6 +82,9 @@
 /* Secure Boot */
 #define CONFIG_ESBC_HDR_LS
 
+/* DCFG - GUR */
+#define CONFIG_SYS_FSL_CCSR_GUR_LE
+
 /* Cache Coherent Interconnect */
 #define CCI_MN_BASE0x0400
 #define CCI_MN_RNF_NODEID_LIST 0x180
-- 
1.8.1.4

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

[U-Boot] [PATCH v4 11/14] crypto/fsl: Make CAAM transactions cacheable

[Saksham Jain]

To solve CAAM coherency issue on ls2080a and ls2085a.
When Caches are enabled and CAAM's DMA's AXI transcations are not
made cacheable, Core reads/write data from/to Caches and CAAM does from
Main Memory. This forces data flushes to synchronize various data structures
But even if any data in proximity of these structures is read by core,
these structures again are fetched in caches.

To avoid this problem, either all the data that CAAM accesses can be made
cache line aligned or CAAM transcations can be made cacheable.

So, this commit makes CAAM transcations as Write Back with Write and Read
Allocate.

Signed-off-by: Aneesh Bansal 
Signed-off-by: Saksham Jain 
---
Changes for v2:
- No changes
Changes for v3:
- No changes
Changes for v4:
- Cleaned up commit message

 drivers/crypto/fsl/jr.c | 13 +
 drivers/crypto/fsl/jr.h |  3 +++
 2 files changed, 16 insertions(+)

diff --git a/drivers/crypto/fsl/jr.c b/drivers/crypto/fsl/jr.c
index b553e3c..987d946 100644
--- a/drivers/crypto/fsl/jr.c
+++ b/drivers/crypto/fsl/jr.c
@@ -530,7 +530,20 @@ int sec_init(void)
uint32_t mcr = sec_in32(>mcfgr);
int ret = 0;
 
+   /*
+* Modifying CAAM Read/Write Attributes
+* For LS2080A and LS2085A
+* For AXI Write - Cacheable, Write Back, Write allocate
+* For AXI Read - Cacheable, Read allocate
+* Only For LS2080a and LS2085a, to solve CAAM coherency issues
+*/
+#if defined(CONFIG_LS2080A) || defined(CONFIG_LS2085A)
+   mcr = (mcr & ~MCFGR_AWCACHE_MASK) | (0xb << MCFGR_AWCACHE_SHIFT);
+   mcr = (mcr & ~MCFGR_ARCACHE_MASK) | (0x6 << MCFGR_ARCACHE_SHIFT);
+#else
mcr = (mcr & ~MCFGR_AWCACHE_MASK) | (0x2 << MCFGR_AWCACHE_SHIFT);
+#endif
+
 #ifdef CONFIG_PHYS_64BIT
mcr |= (1 << MCFGR_PS_SHIFT);
 #endif
diff --git a/drivers/crypto/fsl/jr.h b/drivers/crypto/fsl/jr.h
index 5899696..1f2e324 100644
--- a/drivers/crypto/fsl/jr.h
+++ b/drivers/crypto/fsl/jr.h
@@ -23,6 +23,9 @@
 #define MCFGR_PS_SHIFT  16
 #define MCFGR_AWCACHE_SHIFT8
 #define MCFGR_AWCACHE_MASK (0xf << MCFGR_AWCACHE_SHIFT)
+#define MCFGR_ARCACHE_SHIFT12
+#define MCFGR_ARCACHE_MASK (0xf << MCFGR_ARCACHE_SHIFT)
+
 #define JR_INTMASK   0x0001
 #define JRCR_RESET  0x01
 #define JRINT_ERR_HALT_INPROGRESS   0x4
-- 
1.8.1.4

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

[U-Boot] [PATCH v4 07/14] SECURE BOOT: Change env variable "fdt_high" for LS2080a and LS2085a

[Saksham Jain]

"fdt_high" env variable has been changed to 0xa000 for ls2080a
and ls2085a during Secure Boot. This env_varible is used to specify
the upper limit to be used for copying flat device tree.
This address must be visible to kernel.

The "fdt_high" value has been set during Secure Boot to same value
as it's default value during non-secure boot.

Signed-off-by: Aneesh Bansal 
Signed-off-by: Saksham Jain 
---
Changes for v2:
- No changes
Changes for v3:
- No changes
Changes for v4:
- No changes

 arch/arm/include/asm/fsl_secure_boot.h | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/include/asm/fsl_secure_boot.h 
b/arch/arm/include/asm/fsl_secure_boot.h
index 7ab9623..eafdc0b 100644
--- a/arch/arm/include/asm/fsl_secure_boot.h
+++ b/arch/arm/include/asm/fsl_secure_boot.h
@@ -57,10 +57,17 @@
 #define CONFIG_ESBC_ADDR_64BIT
 #endif
 
+#if defined(CONFIG_LS2080A) || defined(CONFIG_LS2085A)
+#define CONFIG_EXTRA_ENV \
+   "setenv fdt_high 0xa000;"   \
+   "setenv initrd_high 0xcfff;"\
+   "setenv hwconfig \'fsl_ddr:ctlr_intlv=null,bank_intlv=null\';"
+#else
 #define CONFIG_EXTRA_ENV \
"setenv fdt_high 0xcfff;"   \
"setenv initrd_high 0xcfff;"\
"setenv hwconfig \'fsl_ddr:ctlr_intlv=null,bank_intlv=null\';"
+#endif
 
 /* Copying Bootscript and Header to DDR from NOR for LS2 and for rest, from
  * Non-XIP Memory (Nand/SD)*/
-- 
1.8.1.4

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

Re: [U-Boot] [PATCH] Fix variable documented in README.distro for PXE address.

[Stephen Warren]

On 02/08/2016 08:55 PM, Vagrant Cascadian wrote:
> Fixes typo of pxe_addr_r with pxefile_addr_r.

Reviewed-by: Stephen Warren 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] Makefile: remove BUILD_TAG from KBUILD_CFLAGS

[Stephen Warren]

From: Stephen Warren 

If BUILD_TAG is part of KBUILD_CFLAGS, then any time the value changes,
all files get rebuilt. In a continuous integration environment, the value
will change every build. This wastes time assuming that incremental
builds would otherwise occur.

To solve this, remove BUILD_TAG from KBUILD_FLAGS and add it to the end of
"local version".

This has other advantages too:
- The special case for BUILD_TAG in display_options.c can be removed.
- The version printed by the "version" command exactly matches what is
  printed at boot.

Old sign-on message:
U-Boot 2016.03-rc1-00044-g4085db5e767b (Feb ...), Build: bar-bas

New sign-on message:
U-Boot 2016.03-rc1-00044-g4085db5e767b-bar-baz (Feb ...)

Signed-off-by: Stephen Warren 
---
 Makefile| 4 
 lib/display_options.c   | 4 
 scripts/setlocalversion | 4 
 3 files changed, 4 insertions(+), 8 deletions(-)

diff --git a/Makefile b/Makefile
index 42fad45afee1..2265b8995a7b 100644
--- a/Makefile
+++ b/Makefile
@@ -562,10 +562,6 @@ else
 KBUILD_CFLAGS  += -O2
 endif
 
-ifdef BUILD_TAG
-KBUILD_CFLAGS += -DBUILD_TAG='"$(BUILD_TAG)"'
-endif
-
 KBUILD_CFLAGS += $(call cc-option,-fno-stack-protector)
 KBUILD_CFLAGS += $(call cc-option,-fno-delete-null-pointer-checks)
 
diff --git a/lib/display_options.c b/lib/display_options.c
index 29343fc00e3f..5dcdf4e429af 100644
--- a/lib/display_options.c
+++ b/lib/display_options.c
@@ -15,11 +15,7 @@
 
 int display_options (void)
 {
-#if defined(BUILD_TAG)
-   printf ("\n\n%s, Build: %s\n\n", version_string, BUILD_TAG);
-#else
printf ("\n\n%s\n\n", version_string);
-#endif
return 0;
 }
 
diff --git a/scripts/setlocalversion b/scripts/setlocalversion
index 63d91e22ed7c..4ef6603b5c27 100755
--- a/scripts/setlocalversion
+++ b/scripts/setlocalversion
@@ -171,4 +171,8 @@ else
fi
 fi
 
+if test -n "${BUILD_TAG}"; then
+   res="$res-${BUILD_TAG}"
+fi
+
 echo "$res"
-- 
2.7.0

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

[U-Boot] [PATCH v4 02/14] armv8: ls2080: Add Secure Boot configs: SEC, Security Monitor, SRK and RCW

[Saksham Jain]

For ls2080, Added configs for various IPs used during secure boot

Added address and endianness for SEC and Security Monitor.

SRK - Fuses in SFP (Fused for public keys hash)
These are stored in LE format.

Signed-off-by: Aneesh Bansal 
Signed-off-by: Saksham Jain 
---
Changes for v2:
- No changes
Changes for v3:
- No changes
Changes for v4:
-Cleaned up commit message

 arch/arm/include/asm/arch-fsl-layerscape/config.h  | 10 ++
 arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h | 10 ++
 2 files changed, 20 insertions(+)

diff --git a/arch/arm/include/asm/arch-fsl-layerscape/config.h 
b/arch/arm/include/asm/arch-fsl-layerscape/config.h
index 997ff00a..d2d54b7 100644
--- a/arch/arm/include/asm/arch-fsl-layerscape/config.h
+++ b/arch/arm/include/asm/arch-fsl-layerscape/config.h
@@ -70,6 +70,16 @@
 /* SFP */
 #define CONFIG_SYS_FSL_SFP_VER_3_4
 #define CONFIG_SYS_FSL_SFP_LE
+#define CONFIG_SYS_FSL_SRK_LE
+
+/* SEC */
+#define CONFIG_SYS_FSL_SEC_LE
+#define CONFIG_SYS_FSL_SEC_COMPAT  5
+
+/* Security Monitor */
+#define CONFIG_SYS_FSL_SEC_MON_LE
+
+
 
 /* Cache Coherent Interconnect */
 #define CCI_MN_BASE0x0400
diff --git a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h 
b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
index f1b021f..1fc51e0 100644
--- a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
+++ b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
@@ -76,6 +76,14 @@
 /* SFP */
 #define CONFIG_SYS_SFP_ADDR(CONFIG_SYS_IMMR + 0x00e80200)
 
+/* SEC */
+#define CONFIG_SYS_FSL_SEC_ADDR(CONFIG_SYS_IMMR + 0x0700)
+#define CONFIG_SYS_FSL_JR0_ADDR(CONFIG_SYS_IMMR + 0x0701)
+
+/* Security Monitor */
+#define CONFIG_SYS_SEC_MON_ADDR(CONFIG_SYS_IMMR + 0x00e9)
+
+
 /* PCIe */
 #define CONFIG_SYS_PCIE1_ADDR  (CONFIG_SYS_IMMR + 0x240)
 #define CONFIG_SYS_PCIE2_ADDR  (CONFIG_SYS_IMMR + 0x250)
@@ -204,6 +212,8 @@ struct ccsr_gur {
 #defineFSL_CHASSIS3_RCWSR28_SRDS1_PRTCL_SHIFT  16
 #defineFSL_CHASSIS3_RCWSR28_SRDS2_PRTCL_MASK   0xFF00
 #defineFSL_CHASSIS3_RCWSR28_SRDS2_PRTCL_SHIFT  24
+#define RCW_SB_EN_REG_INDEX9
+#define RCW_SB_EN_MASK 0x0400
 
u8  res_180[0x200-0x180];
u32 scratchrw[32];  /* Scratch Read/Write */
-- 
1.8.1.4

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

[U-Boot] [PATCH v4 00/14] Add Support for Secure Boot on LS208x

[Saksham Jain]

Secure Boot ESBC has been enabled on FSL LS208x platforms.

Changes for v2:
- changed function fsl_secboot_validate to return address of image
- corrected Bootscript header for ls1043 and ls1021
Changes for v3:
- minor changes to remove compilation warnings
Changes ofr v4:
- removed IE Key extenstion support. Methodology not fixed yet.
- minor changes in commit messages (clean up)


Saksham Jain (14):
  armv8: ls2080: Add SFP Configs for LS2080/LS2085
  armv8: ls2080: Add Secure Boot configs: SEC, Security Monitor, SRK and
RCW
  SECURE BOOT: Add new ESBC header for ls-ch3 Secure Boot
  SECURE BOOT: Add Secure Boot support on ls2080aqds/rdb
  armv8: fsl-lsch3: Add bootscript header address for Secure Boot
  SECURE BOOT: Copy Bootscript and header from NOR to DDR for LS2080/5
  SECURE BOOT: Change env variable "fdt_high" for LS2080a and LS2085a
  armv8 : ls2080: Add config for endianess of CCSR GUR
  armv8: fsl-lsch3: Disable SMMU during Secure Boot
  crypto/fsl: Correct 64bit Write when MMU disabled
  crypto/fsl: Make CAAM transactions cacheable
  SECURE_BOOT: Use default bootargs during Secure Boot
  SECURE BOOT: Halt execution when secure boot fail after reset request
  SECURE BOOT: Change fsl_secboot_validate function to output image addr

 arch/arm/cpu/armv8/fsl-layerscape/soc.c| 18 +-
 arch/arm/include/asm/arch-fsl-layerscape/config.h  | 18 ++
 .../include/asm/arch-fsl-layerscape/immap_lsch3.h  | 28 +
 arch/arm/include/asm/fsl_secure_boot.h | 50 ++--
 board/freescale/common/cmd_esbc_validate.c | 14 -
 board/freescale/common/fsl_validate.c  | 66 +++--
 board/freescale/ls2080aqds/ls2080aqds.c|  5 +-
 board/freescale/ls2080ardb/ls2080ardb.c|  5 +-
 configs/ls2080aqds_SECURE_BOOT_defconfig   | 15 +
 configs/ls2080ardb_SECURE_BOOT_defconfig   | 15 +
 configs/ls2085aqds_SECURE_BOOT_defconfig   | 15 +
 configs/ls2085ardb_SECURE_BOOT_defconfig   | 15 +
 drivers/crypto/fsl/desc_constr.h   |  7 +--
 drivers/crypto/fsl/jr.c| 13 +
 drivers/crypto/fsl/jr.h|  3 +
 include/config_fsl_chain_trust.h   | 25 +---
 include/configs/ls2080aqds.h   |  2 +
 include/configs/ls2080ardb.h   |  2 +
 include/fsl_secboot_err.h  |  3 +
 include/fsl_sfp.h  |  3 +-
 include/fsl_validate.h | 67 ++
 21 files changed, 341 insertions(+), 48 deletions(-)
 create mode 100644 configs/ls2080aqds_SECURE_BOOT_defconfig
 create mode 100644 configs/ls2080ardb_SECURE_BOOT_defconfig
 create mode 100644 configs/ls2085aqds_SECURE_BOOT_defconfig
 create mode 100644 configs/ls2085ardb_SECURE_BOOT_defconfig

-- 
1.8.1.4

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

[U-Boot] [PATCH v4 01/14] armv8: ls2080: Add SFP Configs for LS2080/LS2085

[Saksham Jain]

In LS2080/LS2085, SFP is LE and Ver is 3.4
The base address is 0x01e80200
SFP will be used in Secure Boot to read fuses.

Signed-off-by: Aneesh Bansal 
Signed-off-by: Saksham Jain 
---
Changes for v2:
- No changes
Changes for v3:
- No changes
Changes for v4:
- Cleaned up commit message

 arch/arm/include/asm/arch-fsl-layerscape/config.h  | 4 
 arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h | 3 +++
 include/fsl_sfp.h  | 3 ++-
 3 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/arch-fsl-layerscape/config.h 
b/arch/arm/include/asm/arch-fsl-layerscape/config.h
index ff3b1be..997ff00a 100644
--- a/arch/arm/include/asm/arch-fsl-layerscape/config.h
+++ b/arch/arm/include/asm/arch-fsl-layerscape/config.h
@@ -67,6 +67,10 @@
 /* SMMU Defintions */
 #define SMMU_BASE  0x0500 /* GR0 Base */
 
+/* SFP */
+#define CONFIG_SYS_FSL_SFP_VER_3_4
+#define CONFIG_SYS_FSL_SFP_LE
+
 /* Cache Coherent Interconnect */
 #define CCI_MN_BASE0x0400
 #define CCI_MN_RNF_NODEID_LIST 0x180
diff --git a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h 
b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
index 91f3ce8..f1b021f 100644
--- a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
+++ b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
@@ -73,6 +73,9 @@
 #define AHCI_BASE_ADDR1(CONFIG_SYS_IMMR + 
0x0220)
 #define AHCI_BASE_ADDR2(CONFIG_SYS_IMMR + 
0x0221)
 
+/* SFP */
+#define CONFIG_SYS_SFP_ADDR(CONFIG_SYS_IMMR + 0x00e80200)
+
 /* PCIe */
 #define CONFIG_SYS_PCIE1_ADDR  (CONFIG_SYS_IMMR + 0x240)
 #define CONFIG_SYS_PCIE2_ADDR  (CONFIG_SYS_IMMR + 0x250)
diff --git a/include/fsl_sfp.h b/include/fsl_sfp.h
index 353a123..2976a2c 100644
--- a/include/fsl_sfp.h
+++ b/include/fsl_sfp.h
@@ -32,7 +32,8 @@
 /* Number of SRKH registers */
 #define NUM_SRKH_REGS  8
 
-#ifdef CONFIG_SYS_FSL_SFP_VER_3_2
+#ifdefined(CONFIG_SYS_FSL_SFP_VER_3_2) ||  \
+   defined(CONFIG_SYS_FSL_SFP_VER_3_4)
 struct ccsr_sfp_regs {
u32 ospr;   /* 0x200 */
u32 ospr1;  /* 0x204 */
-- 
1.8.1.4

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

[U-Boot] [PATCH v4 05/14] armv8: fsl-lsch3: Add bootscript header address for Secure Boot

[Saksham Jain]

During secure boot, Linux image along with other images are validated
using bootscript. This bootscript also needs to be validated before
it is executed. This requires a header for bootscript.

When secure boot is enabled, default bootcmd is changed to first validate
bootscript using the header and then execute the script.

For ls2080/5, NOR memory map is different from earlier arm SoCs.
So a new address on NOR is used for this bootscript header.
(0x58392). The Bootscript address is mentioned in this header along
with addresses of other images.

Signed-off-by: Aneesh Bansal 
Signed-off-by: Saksham Jain 
---
Changes for v2:
- No changes
Changes for v3:
- No changes
Changes for v4:
-Cleaned up commit message

 arch/arm/include/asm/fsl_secure_boot.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/include/asm/fsl_secure_boot.h 
b/arch/arm/include/asm/fsl_secure_boot.h
index e65caed..7c55ea1 100644
--- a/arch/arm/include/asm/fsl_secure_boot.h
+++ b/arch/arm/include/asm/fsl_secure_boot.h
@@ -63,7 +63,11 @@
"setenv hwconfig \'fsl_ddr:ctlr_intlv=null,bank_intlv=null\';"
 
 /* The address needs to be modified according to NOR memory map */
+#if defined(CONFIG_LS2080A) || defined(CONFIG_LS2085A)
+#define CONFIG_BOOTSCRIPT_HDR_ADDR 0x58392
+#else
 #define CONFIG_BOOTSCRIPT_HDR_ADDR 0x600a
+#endif
 
 #include 
 #endif /* #ifdef CONFIG_CHAIN_OF_TRUST */
-- 
1.8.1.4

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

[U-Boot] [PATCH] OMAP3LOGIC: Update maintainer

[Adam Ford]

I will take this over from Peter Barada, since I work with it daily
at Logic PD.

Signed-off-by: Adam Ford 
---
 board/logicpd/omap3som/MAINTAINERS | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/board/logicpd/omap3som/MAINTAINERS 
b/board/logicpd/omap3som/MAINTAINERS
index ffe2201..68ad3a5 100644
--- a/board/logicpd/omap3som/MAINTAINERS
+++ b/board/logicpd/omap3som/MAINTAINERS
@@ -1,5 +1,5 @@
 OMAP3SOM BOARD
-M: Peter Barada 
+M: Adam Ford 
 S: Maintained
 F: board/logicpd/omap3som/
 F: include/configs/omap3_logic.h
-- 
1.9.1

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

Re: [U-Boot] [PATCH] image: fix getenv_bootm_size() function

[Matthias Weißer]

Hi Hannes

I had the same problem. http://patchwork.ozlabs.org/patch/579391/ fixed it.

Regards,
Matthias


2016-02-08 15:01 GMT+01:00 Hannes Schmelzer :
>
>
> On 18.12.2015 06:17, Masahiro Yamada wrote:
>>
>> Currently, this function returns wrong size if "bootm_low" is defined,
>> but "bootm_size" is not.
>>
>> Signed-off-by: Masahiro Yamada 
>> ---
>>
>>   common/image.c | 4 ++--
>>   1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/common/image.c b/common/image.c
>> index d63d9e0..f4a1dc8 100644
>> --- a/common/image.c
>> +++ b/common/image.c
>> @@ -472,9 +472,9 @@ phys_size_t getenv_bootm_size(void)
>>   #if defined(CONFIG_ARM) && defined(CONFIG_NR_DRAM_BANKS)
>> -   return gd->bd->bi_dram[0].size - tmp;
>> +   return gd->bd->bi_dram[0].size - (tmp - gd->bd->bi_dram[0].start);
>>   #else
>> -   return gd->bd->bi_memsize - tmp;
>> +   return gd->bd->bi_memsize - (tmp - gd->bd->bi_memstart);
>>   #endif
>>   }
>
> Hi Masahiro,
>
> your commit has been merged on 19.1. this year.
> Today i ran a test on my tseries board with most current u-boot/master.
>
> I ran into trouble booting my linux kernel:
>
> ---
> Kernel image @ 0x8020 [ 0x00 - 0x222720 ]
> ## Loading init Ramdisk from Legacy Image at 80a0 ...
>Image Name:
>Image Type:   ARM Linux RAMDisk Image (uncompressed)
>Data Size:12452646 Bytes = 11.9 MiB
>Load Address: 
>Entry Point:  
> ## Flattened Device Tree blob at 8010
>Booting using the fdt blob at 0x8010
> ERROR: Failed to allocate 0xbe0326 bytes below 0x1000.
> ramdisk - allocation error
> FDT creation failed! hanging...### ERROR ### Please RESET the board ###
> ---
>
> I debugged  bit am came to the conclusio, that the line
>
> +   return gd->bd->bi_dram[0].size - (tmp - gd->bd->bi_dram[0].start);
>
> brings me into trouble.
>
> On my board DRAM is configured as follows:
> U-Boot (BuR V2.0)# bdinfo
> arch_number = 0x
> boot_params = 0x8100
> DRAM bank   = 0x
> *-> start= 0x8000**
> **-> size = 0x1000**
> *
> so size minus start would give a negative number.
> I tried local revert of this commit and everything works as before.
>
> more correct would be
>
> +   return gd->bd->bi_dram[0].start - (tmp - gd->bd->bi_dram[0].size);
>
>
> whats your thinking about?
>
> best regards,
> Hannes
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] how to change my name in patchwork?

[Hannes Schmelzer]

hi folks,

i've got married now one year ago.
Before marriage my surname was 'Petermaier', after 'Schmelzer'.

Patchwork still calls me 'Hannes Petermaier'.
Is there any chance to change this ?

many thanks and best regards,
Hannes

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

Re: [U-Boot] [PATCH v2 05/18] usb: ulpi: Add Kconfig options for ULPI

[Marek Vasut]

On Sunday, February 07, 2016 at 09:57:25 PM, Mateusz Kulikowski wrote:
> The following options can be now enabled via defconfig:
> - CONFIG_USB_ULPI
> - CONFIG_USB_ULPI_VIEWPORT
> - CONFIG_USB_ULPI_VIEWPORT_OMAP
> 
> Signed-off-by: Mateusz Kulikowski 
> Reviewed-by: Simon Glass 

Acked-by: Marek Vasut 

Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Problem with mounting a jffs2 partition on flash.

[Calvin Johnson]

Hi Denis,


> -Original Message-
> From: U-Boot [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Wolfgang
> Denk
> Sent: Monday, February 08, 2016 5:53 PM
> To: Bakhvalov, Denis (Nokia - PL/Wroclaw) 
> Cc: u-boot@lists.denx.de
> Subject: Re: [U-Boot] Problem with mounting a jffs2 partition on flash.
> 
> Dear Denis,
> 
> In message
> 
> you wrote:
> >
> 
> > Yes, I'm aware that jffs2 is quite old and ubifs is a successor of
> > jffs2, but the reason is that current Linux Kernel has no support for
> > UBI.
> 
> What do you mean by "current" here?  UBI/UBIFS support in U-Boot was
> actually adapted from the Linux kernel, so Linux support for UBI/UBIFS
> predates the U-Boot code by a long, long time.
> 
> Do you mean you are using a prehistoric Linux kernel version?
> 
> > I understand that it should have solution, but it requires recompiling
> > Linux kernel which is also time consuming.
> 
> Hm... just recompiling is only a matter of seconds (or, on a very slow system,
> minutes max).  I understand there are other concerns that you don't want to
> update?  Please be aware that there it is likely that there other 
> incompatibilities
> / bugs in such an ancient kernel...
> 
> > > What exactly are these "other problems" ?
> >
> > U-Boot launches, but after that it is hanging.
> > U-Boot 2016.01 (Feb 05 2016 - 14:15:47 +0100)
> >
> > CPU:   Altera SoCFPGA Platform
> > FPGA:  Altera Arria V, D5, version 0x0
> > BOOT:  QSPI Flash (3.0V)
> >Watchdog enabled
> > I2C:   ready
> > DRAM:
> >
> > I will try to tackle this problem also.
> > However, I must say that I don't have much experience with U-Boot, so
> > maybe I'm missing something obvious?
> 
> It appears it is hanging in the DRAM initialization phase.  This is a very 
> common
> issue.  Please make sure your memory configuration is correct.

I would also suggest you to enable DEBUG flag to get more information that 
helps debug your issues.

> 
> > Can you please share some examples of correct configuration for such
> > use case (jffs2 partition on NOR flash with SPI)?
> 
> You can deal with this later; first you need to have the system running at 
> all.
> You should focus on this first.
> 
> 
> 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 Far
> back in the mists of ancient time, in the great and glorious days of the 
> former
> Galactic Empire, life was wild, rich  and  largely  tax
> free. - Douglas Adams, _The Hitchhiker's Guide to the Galaxy_
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot

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

Re: [U-Boot] [PATCH] image: fix getenv_bootm_size() function

[Hannes Schmelzer]

On 08.02.2016 15:11, Matthias Weißer wrote:

Hi Hannes

I had the same problem. http://patchwork.ozlabs.org/patch/579391/ fixed it.

Regards,
Matthias


2016-02-08 15:01 GMT+01:00 Hannes Schmelzer :


On 18.12.2015 06:17, Masahiro Yamada wrote:

Currently, this function returns wrong size if "bootm_low" is defined,
but "bootm_size" is not.

Signed-off-by: Masahiro Yamada 
---

   common/image.c | 4 ++--
   1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/common/image.c b/common/image.c
index d63d9e0..f4a1dc8 100644
--- a/common/image.c
+++ b/common/image.c
@@ -472,9 +472,9 @@ phys_size_t getenv_bootm_size(void)
   #if defined(CONFIG_ARM) && defined(CONFIG_NR_DRAM_BANKS)
-   return gd->bd->bi_dram[0].size - tmp;
+   return gd->bd->bi_dram[0].size - (tmp - gd->bd->bi_dram[0].start);
   #else
-   return gd->bd->bi_memsize - tmp;
+   return gd->bd->bi_memsize - (tmp - gd->bd->bi_memstart);
   #endif
   }

Hi Masahiro,

your commit has been merged on 19.1. this year.
Today i ran a test on my tseries board with most current u-boot/master.

I ran into trouble booting my linux kernel:

---
Kernel image @ 0x8020 [ 0x00 - 0x222720 ]
## Loading init Ramdisk from Legacy Image at 80a0 ...
Image Name:
Image Type:   ARM Linux RAMDisk Image (uncompressed)
Data Size:12452646 Bytes = 11.9 MiB
Load Address: 
Entry Point:  
## Flattened Device Tree blob at 8010
Booting using the fdt blob at 0x8010
ERROR: Failed to allocate 0xbe0326 bytes below 0x1000.
ramdisk - allocation error
FDT creation failed! hanging...### ERROR ### Please RESET the board ###
---

I debugged  bit am came to the conclusio, that the line

+   return gd->bd->bi_dram[0].size - (tmp - gd->bd->bi_dram[0].start);

brings me into trouble.

On my board DRAM is configured as follows:
U-Boot (BuR V2.0)# bdinfo
arch_number = 0x
boot_params = 0x8100
DRAM bank   = 0x
*-> start= 0x8000**
**-> size = 0x1000**
*
so size minus start would give a negative number.
I tried local revert of this commit and everything works as before.

more correct would be

+   return gd->bd->bi_dram[0].start - (tmp - gd->bd->bi_dram[0].size);


whats your thinking about?

best regards,
Hannes

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

Hi Matthias,

this also fixes my problem.

many thanks!

best regards,
Hannes

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

Re: [U-Boot] [PATCH 2/2] include:configs: Add usb device-tree fixup for all fsl platforms

[Marek Vasut]

On Monday, February 08, 2016 at 12:07:29 PM, Ramneek Mehresh wrote:
> > -Original Message-
> > From: Ramneek Mehresh
> > Sent: Thursday, January 28, 2016 5:45 PM
> > To: 'Marek Vasut' 
> > Cc: Ramneek Mehresh ; u-
> > b...@lists.denx.de; Simon Glass 
> > Subject: RE: [PATCH 2/2] include:configs: Add usb device-tree fixup for
> > all fsl platforms
> > 
> > > -Original Message-
> > > From: Marek Vasut [mailto:ma...@denx.de]
> > > Sent: Thursday, January 28, 2016 5:04 PM
> > > To: Ramneek Mehresh 
> > > Cc: Ramneek Mehresh ; u-
> > > b...@lists.denx.de; Simon Glass 
> > > Subject: Re: [PATCH 2/2] include:configs: Add usb device-tree fixup
> > > for all fsl platforms
> > > 
> > > On Thursday, January 28, 2016 at 12:05:29 PM, Ramneek Mehresh wrote:
> > > > > -Original Message-
> > > > > From: Marek Vasut [mailto:ma...@denx.de]
> > > > > Sent: Wednesday, January 27, 2016 5:13 PM
> > > > > To: Ramneek Mehresh 
> > > > > Cc: Ramneek Mehresh ; u-
> > > > > b...@lists.denx.de; Simon Glass 
> > > > > Subject: Re: [PATCH 2/2] include:configs: Add usb device-tree
> > > > > fixup for all fsl platforms
> > > > > 
> > > > > On Wednesday, January 27, 2016 at 12:33:04 PM, Ramneek Mehresh
> > > 
> > > wrote:
> > > > > > > -Original Message-
> > > > > > > From: Marek Vasut [mailto:ma...@denx.de]
> > > > > > > Sent: Wednesday, January 27, 2016 1:57 PM
> > > > > > > To: Ramneek Mehresh 
> > > > > > > Cc: Ramneek Mehresh ; u-
> > > > > > > b...@lists.denx.de; Simon Glass 
> > > > > > > Subject: Re: [PATCH 2/2] include:configs: Add usb device-tree
> > > > > > > fixup for all fsl platforms
> > > > > > > 
> > > > > > > On Wednesday, January 27, 2016 at 09:26:08 AM, Ramneek
> > 
> > Mehresh
> > 
> > > > > wrote:
> > > > > > > > > -Original Message-
> > > > > > > > > From: Marek Vasut [mailto:ma...@denx.de]
> > > > > > > > > Sent: Wednesday, January 27, 2016 1:05 PM
> > > > > > > > > To: Ramneek Mehresh 
> > > > > > > > > Cc: Ramneek Mehresh ; u-
> > > > > > > > > b...@lists.denx.de; Simon Glass 
> > > > > > > > > Subject: Re: [PATCH 2/2] include:configs: Add usb
> > > > > > > > > device-tree fixup for all fsl platforms
> > > > > > > > > 
> > > > > > > > > On Wednesday, January 27, 2016 at 05:30:51 AM, Ramneek
> > > > > > > > > Mehresh
> > > > > > > 
> > > > > > > wrote:
> > > > > > > > > > > -Original Message-
> > > > > > > > > > > From: Marek Vasut [mailto:ma...@denx.de]
> > > > > > > > > > > Sent: Wednesday, January 27, 2016 9:57 AM
> > > > > > > > > > > To: Ramneek Mehresh 
> > > > > > > > > > > Cc: Ramneek Mehresh
> > 
> > ;
> > 
> > > u-
> > > 
> > > > > > > > > > > b...@lists.denx.de; Simon Glass 
> > > > > > > > > > > Subject: Re: [PATCH 2/2] include:configs: Add usb
> > > > > > > > > > > device-tree fixup for all fsl platforms
> > > > > > > > > > > 
> > > > > > > > > > > On Wednesday, January 27, 2016 at 05:14:00 AM, Ramneek
> > > > > 
> > > > > Mehresh
> > > > > 
> > > > > > > > > wrote:
> > > > > > > > > > > > > -Original Message-
> > > > > > > > > > > > > From: Marek Vasut [mailto:ma...@denx.de]
> > > > > > > > > > > > > Sent: Tuesday, January 26, 2016 4:58 PM
> > > > > > > > > > > > > To: Ramneek Mehresh
> > > 
> > > 
> > > 
> > > > > > > > > > > > > Cc: u-boot@lists.denx.de
> > > > > > > > > > > > > Subject: Re: [PATCH 2/2] include:configs: Add usb
> > > > > > > > > > > > > device-tree fixup for all fsl platforms
> > > > > > > > > > > > > 
> > > > > > > > > > > > > On Tuesday, January 26, 2016 at 12:36:58 PM,
> > > > > > > > > > > > > Ramneek
> > > > > 
> > > > > Mehresh
> > > > > 
> > > > > > > > > wrote:
> > > > > > > > > > > > > > Add usb device-tree fixup for all relevant fsl
> > > > > > > > > > > > > > ppc and arm platforms
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > Signed-off-by: Ramneek Mehresh
> > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > > > > ---
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > >  board/freescale/b4860qds/b4860qds.c | 2
> > > > > > > > > > > > > >  +- board/freescale/bsc9131rdb/bsc9131rdb.c
> > > > > > > > > > > > > >  | 2 ++ board/freescale/bsc9132qds/bsc9132qds.c 
> > > > > > > > > > > > > > | 2 ++
> > > > > > > > > > > > > >  board/freescale/corenet_ds/corenet_ds.c | 4
> > > > > > > > > > > > > >   board/freescale/ls2080aqds/ls2080aqds.c   
> > > > > > > > > > > > > >   | 4 
> > > > > > > > > > > > > >  board/freescale/ls2080ardb/ls2080ardb.c | 4

Re: [U-Boot] Issue with USB mass storage (thumb drives)

[Marek Vasut]

On Monday, February 08, 2016 at 09:41:09 AM, Hannes Schmelzer wrote:
> On 04.02.2016 12:28, Marek Vasut wrote:
> > On Thursday, February 04, 2016 at 09:21:08 AM, Schrempf Frieder wrote:
> >> On 03.02.2016 20:16, Sergei Temerkhanov wrote:
> >>> On Wed, Feb 3, 2016 at 8:40 AM, Marek Vasut  wrote:
>  On Wednesday, February 03, 2016 at 12:49:20 PM, Schrempf Frieder wrote:
> > On 03.02.2016 12:12, Marek Vasut wrote:
> >> On Wednesday, February 03, 2016 at 11:15:00 AM, Schrempf Frieder wrote:
> >>> On 03.02.2016 10:55, Fabio Estevam wrote:
>  On Wed, Feb 3, 2016 at 7:40 AM, Marek Vasut  wrote:
> > In that case, debug time.
> > 
> > Usual problems are bad routing of the tracks on the board , so
> > try with USB 1.1 hub and if that works, that's your problem.
>  
>  Another suggestion would be to try the 100MB transfer in Linux and
>  see if this works or not.
>  
>  That would help us to narrow down whether this is a hardware or
>  software problem.
> >>> 
> >>> Another thing to try may be limiting the value of USB_MAX_XFER_BLK in
> >>> common/usb_storage.c
> >> 
> >> This was a really helpful hint! Thank you Sergei!
> >> 
> >> I just tried to limit USB_MAX_XFER_BLK to 1/8 of the original value
> >> (65535 -> 8191) and this time the transfer works without timeouts.
> >> 
> >> As we have a customer who needs this working as soon as possible my
> >> question now is how to properly solve this.
> >> Should I generally limit USB_MAX_XFER_BLK in my u-boot to avoid these
> >> errors? Which value to choose?
> > 
> > Nice! Can you share which sticks are those, ideally brand/type and USB
> > IDs ?
> 
> Hi,
> that tip works also on my ZYNQ board.
> 
> There is some comment around this 'magic-define':
> 
> /*
>   * The U-Boot EHCI driver can handle any transfer length as long as
> there is
>   * enough free heap space left, but the SCSI READ(10) and WRITE(10)
> commands are
>   * limited to 65535 blocks.
>   */
> 
> Can i assume that 16MiB free heap space is enough if i want read a 16MiB
> file ?

The file is actually not read into a buffer on a heap iirc, but directly to
the target location if that's in RAM.

Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH][v2] armv8/ls2080ardb: Enable VID support

[Rai Harninder]

This patch enable VID support for ls2080ardb platform.
It uses the common VID driver

Signed-off-by: Rai Harninder 
---
Changes in v2
- Use CONFIG_FSL_LSCH3 instead of CONFIG_LAYERSCAPE
  since the latter is defined for other platforms
  as well
- Modify patch description

 .../include/asm/arch-fsl-layerscape/immap_lsch3.h  |4 
 board/freescale/common/vid.c   |   15 ++-
 board/freescale/ls2080ardb/ls2080ardb.c|5 +
 include/configs/ls2080ardb.h   |   16 
 4 files changed, 39 insertions(+), 1 deletions(-)

diff --git a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h 
b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
index 91f3ce8..4fd58ee 100644
--- a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
+++ b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
@@ -146,6 +146,10 @@ struct ccsr_gur {
u8  res_008[0x20-0x8];
u32 gpporcr1;   /* General-purpose POR configuration */
u32 gpporcr2;   /* General-purpose POR configuration 2 */
+#define FSL_CHASSIS3_DCFG_FUSESR_VID_SHIFT 25
+#define FSL_CHASSIS3_DCFG_FUSESR_VID_MASK  0x1F
+#define FSL_CHASSIS3_DCFG_FUSESR_ALTVID_SHIFT  20
+#define FSL_CHASSIS3_DCFG_FUSESR_ALTVID_MASK   0x1F
u32 dcfg_fusesr;/* Fuse status register */
u32 gpporcr3;
u32 gpporcr4;
diff --git a/board/freescale/common/vid.c b/board/freescale/common/vid.c
index 1bd65a8..b037643 100644
--- a/board/freescale/common/vid.c
+++ b/board/freescale/common/vid.c
@@ -10,6 +10,8 @@
 #include 
 #ifdef CONFIG_LS1043A
 #include 
+#elif defined(CONFIG_FSL_LSCH3)
+#include 
 #else
 #include 
 #endif
@@ -285,7 +287,7 @@ static int set_voltage(int i2caddress, int vdd)
 int adjust_vdd(ulong vdd_override)
 {
int re_enable = disable_interrupts();
-#ifdef CONFIG_LS1043A
+#if defined(CONFIG_LS1043A) || defined(CONFIG_FSL_LSCH3)
struct ccsr_gur *gur = (void *)(CONFIG_SYS_FSL_GUTS_ADDR);
 #else
ccsr_gur_t __iomem *gur =
@@ -362,7 +364,11 @@ int adjust_vdd(ulong vdd_override)
}
 
/* get the voltage ID from fuse status register */
+#ifdef CONFIG_FSL_LSCH3
+   fusesr = in_le32(>dcfg_fusesr);
+#else
fusesr = in_be32(>dcfg_fusesr);
+#endif
/*
 * VID is used according to the table below
 *---
@@ -387,6 +393,13 @@ int adjust_vdd(ulong vdd_override)
vid = (fusesr >> FSL_CHASSIS2_DCFG_FUSESR_VID_SHIFT) &
FSL_CHASSIS2_DCFG_FUSESR_VID_MASK;
}
+#elif defined(CONFIG_FSL_LSCH3)
+   vid = (fusesr >> FSL_CHASSIS3_DCFG_FUSESR_ALTVID_SHIFT) &
+   FSL_CHASSIS3_DCFG_FUSESR_ALTVID_MASK;
+   if ((vid == 0) || (vid == FSL_CHASSIS3_DCFG_FUSESR_ALTVID_MASK)) {
+   vid = (fusesr >> FSL_CHASSIS3_DCFG_FUSESR_VID_SHIFT) &
+   FSL_CHASSIS3_DCFG_FUSESR_VID_MASK;
+   }
 #else
vid = (fusesr >> FSL_CORENET_DCFG_FUSESR_ALTVID_SHIFT) &
FSL_CORENET_DCFG_FUSESR_ALTVID_MASK;
diff --git a/board/freescale/ls2080ardb/ls2080ardb.c 
b/board/freescale/ls2080ardb/ls2080ardb.c
index c63b639..9515b25 100644
--- a/board/freescale/ls2080ardb/ls2080ardb.c
+++ b/board/freescale/ls2080ardb/ls2080ardb.c
@@ -122,6 +122,11 @@ int select_i2c_ch_pca9547(u8 ch)
return 0;
 }
 
+int i2c_multiplexer_select_vid_channel(u8 channel)
+{
+   return select_i2c_ch_pca9547(channel);
+}
+
 int config_board_mux(int ctrl_type)
 {
u8 reg5;
diff --git a/include/configs/ls2080ardb.h b/include/configs/ls2080ardb.h
index 116dbcd..9a95f31 100644
--- a/include/configs/ls2080ardb.h
+++ b/include/configs/ls2080ardb.h
@@ -14,6 +14,22 @@
 
 #define CONFIG_DISPLAY_BOARDINFO
 
+#define I2C_MUX_CH_VOL_MONITOR 0xa
+#define I2C_VOL_MONITOR_ADDR   0x38
+#define CONFIG_VOL_MONITOR_IR36021_READ
+#define CONFIG_VOL_MONITOR_IR36021_SET
+
+#define CONFIG_VID_FLS_ENV "ls2080ardb_vdd_mv"
+#ifndef CONFIG_SPL_BUILD
+#define CONFIG_VID
+#endif
+/* step the IR regulator in 5mV increments */
+#define IR_VDD_STEP_DOWN   5
+#define IR_VDD_STEP_UP 5
+/* The lowest and highest voltage allowed for LS2080ARDB */
+#define VDD_MV_MIN 819
+#define VDD_MV_MAX 1212
+
 #ifndef __ASSEMBLY__
 unsigned long get_board_sys_clk(void);
 #endif
-- 
1.7.6.GIT

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

Re: [U-Boot] [PATCH] image: fix getenv_bootm_size() function

[Hannes Schmelzer]

On 18.12.2015 06:17, Masahiro Yamada wrote:

Currently, this function returns wrong size if "bootm_low" is defined,
but "bootm_size" is not.

Signed-off-by: Masahiro Yamada 
---

  common/image.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/common/image.c b/common/image.c
index d63d9e0..f4a1dc8 100644
--- a/common/image.c
+++ b/common/image.c
@@ -472,9 +472,9 @@ phys_size_t getenv_bootm_size(void)
  
  
  #if defined(CONFIG_ARM) && defined(CONFIG_NR_DRAM_BANKS)

-   return gd->bd->bi_dram[0].size - tmp;
+   return gd->bd->bi_dram[0].size - (tmp - gd->bd->bi_dram[0].start);
  #else
-   return gd->bd->bi_memsize - tmp;
+   return gd->bd->bi_memsize - (tmp - gd->bd->bi_memstart);
  #endif
  }

Hi Masahiro,

your commit has been merged on 19.1. this year.
Today i ran a test on my tseries board with most current u-boot/master.

I ran into trouble booting my linux kernel:

---
Kernel image @ 0x8020 [ 0x00 - 0x222720 ]
## Loading init Ramdisk from Legacy Image at 80a0 ...
   Image Name:
   Image Type:   ARM Linux RAMDisk Image (uncompressed)
   Data Size:12452646 Bytes = 11.9 MiB
   Load Address: 
   Entry Point:  
## Flattened Device Tree blob at 8010
   Booting using the fdt blob at 0x8010
ERROR: Failed to allocate 0xbe0326 bytes below 0x1000.
ramdisk - allocation error
FDT creation failed! hanging...### ERROR ### Please RESET the board ###
---

I debugged  bit am came to the conclusio, that the line

+   return gd->bd->bi_dram[0].size - (tmp - gd->bd->bi_dram[0].start);

brings me into trouble.

On my board DRAM is configured as follows:
U-Boot (BuR V2.0)# bdinfo
arch_number = 0x
boot_params = 0x8100
DRAM bank   = 0x
*-> start= 0x8000**
**-> size = 0x1000**
*
so size minus start would give a negative number.
I tried local revert of this commit and everything works as before.

more correct would be

+   return gd->bd->bi_dram[0].start - (tmp - gd->bd->bi_dram[0].size);


whats your thinking about?

best regards,
Hannes
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] image: fix getenv_bootm_size() function again

[Hannes Schmelzer]

On 05.02.2016 08:12, Masahiro Yamada wrote:

Commit 9c11135ce053 ("image: fix getenv_bootm_size() function") fixed
the case where "bootm_low" is defined, but "bootm_size" is not.
Instead, it broke the case where neither "bootm_low" nor "bootm_size"
is defined.  Fix this function again.

Fixes: 9c11135ce053 ("image: fix getenv_bootm_size() function")
Signed-off-by: Masahiro Yamada 
---

  common/image.c | 21 +
  1 file changed, 13 insertions(+), 8 deletions(-)

diff --git a/common/image.c b/common/image.c
index f4a1dc8..82ace38 100644
--- a/common/image.c
+++ b/common/image.c
@@ -458,24 +458,29 @@ ulong getenv_bootm_low(void)
  
  phys_size_t getenv_bootm_size(void)

  {
-   phys_size_t tmp;
+   phys_size_t tmp, size;
+   phys_addr_t start;
char *s = getenv("bootm_size");
if (s) {
tmp = (phys_size_t)simple_strtoull(s, NULL, 16);
return tmp;
}
+
+#if defined(CONFIG_ARM) && defined(CONFIG_NR_DRAM_BANKS)
+   start = gd->bd->bi_dram[0].start;
+   size = gd->bd->bi_dram[0].size;
+#else
+   start = gd->bd->bi_memstart;
+   size = gd->bd->bi_memsize;
+#endif
+
s = getenv("bootm_low");
if (s)
tmp = (phys_size_t)simple_strtoull(s, NULL, 16);
else
-   tmp = 0;
-
+   tmp = start;
  
-#if defined(CONFIG_ARM) && defined(CONFIG_NR_DRAM_BANKS)

-   return gd->bd->bi_dram[0].size - (tmp - gd->bd->bi_dram[0].start);
-#else
-   return gd->bd->bi_memsize - (tmp - gd->bd->bi_memstart);
-#endif
+   return size - (tmp - start);
  }
  
  phys_size_t getenv_bootm_mapsize(void)

Tested-by: Hannes Schmelzer 

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

Re: [U-Boot] [PATCH 2/2] fastboot: sparse: remove unnecessary logging

[Steve Rae]

Hi Maxime,

On Mon, Feb 8, 2016 at 12:19 AM, Maxime Ripard <
maxime.rip...@free-electrons.com> wrote:

> Hi Steve,
>
> On Thu, Feb 04, 2016 at 10:51:00AM -0800, Steve Rae wrote:
> > Hi Maxime,
> >
> > On Thu, Feb 4, 2016 at 4:20 AM, Maxime Ripard <
> > maxime.rip...@free-electrons.com> wrote:
> >
> > > Hi Steve,
> > >
> > > On Wed, Feb 03, 2016 at 12:46:02PM -0800, Steve Rae wrote:
> > > > remove logging of the 'skipped' blocks
> > > >
> > > > Signed-off-by: Steve Rae 
> > > > ---
> > > >
> > > >  common/image-sparse.c | 6 ++
> > > >  1 file changed, 2 insertions(+), 4 deletions(-)
> > > >
> > > > diff --git a/common/image-sparse.c b/common/image-sparse.c
> > > > index f02aee4..594bf4e 100644
> > > > --- a/common/image-sparse.c
> > > > +++ b/common/image-sparse.c
> > > > @@ -275,7 +275,6 @@ int store_sparse_image(sparse_storage_t *storage,
> > > void *storage_priv,
> > > >   sparse_buffer_t *buffer;
> > > >   uint32_t start;
> > > >   uint32_t total_blocks = 0;
> > > > - uint32_t skipped = 0;
> > > >   int i;
> > > >
> > > >   debug("=== Storage ===\n");
> > > > @@ -334,7 +333,6 @@ int store_sparse_image(sparse_storage_t *storage,
> > > void *storage_priv,
> > > > storage,
> > > >
> > >  sparse_header);
> > > >   total_blocks += blkcnt;
> > >
> >
> > This change (in the first patch), updates the "total_blocks" value, so
> that
> > the "next" chunk has the proper "starting block" address
> > (see these line 363...)
> > 362 ret = storage->write(storage, storage_priv,
> > 363  start + total_blocks,
> > 364  buffer_blk_cnt,
> > 365  buffer->data);
> > Without this change, all the blocks written to the partition after the
> > CHUNK_TYPE_DONT_CARE blocks are corrupted (they are not in the correct
> > location).
> > So, even though we are not actually writing any blocks to this space, the
> > space must be maintained!
>
> Ah, yeah, understood.
>
> I'm guessing it was working in my case since I had no DONT_CARE chunks
> in the first sparse image sent, and then only DONT_CARE chunks for the
> space you already wrote, we got that covered by last_offset... :/
>
> So, yeah, it's broken...
>
> > (Recently, I am now understanding that with NAND, there may be more
> > complications; probably cannot just increment the "total_blocks" -- I
> > suspect that it is required to actually determine if there are bad blocks
> > in this space, and update the "total_blocks" value accordingly)
>
> Yes, if you try to write to a bad block on NAND, you're actually going
> to write to the next block, which will introduce some offset, or
> you'll going to write to a block that's already been written.
>
> Maxime
>
>
So, to handle MMC versus NAND, I propose that we follow the same method
used throughout 'fastboot':

+#ifdef CONFIG_FASTBOOT_FLASH_MMC_DEV
total_blocks += blkcnt;
+#endif
+#ifdef CONFIG_FASTBOOT_FLASH_NAND_DEV
+   /* TBD */
+#endif

What do you think?
I can submit a "v2" -- Could you create a patch for the the NAND part?

Thanks in advance, Steve


> > > - skipped += blkcnt;
> > > >   continue;
> > > >   }
> > > >
> > > > @@ -375,8 +373,8 @@ int store_sparse_image(sparse_storage_t *storage,
> > > void *storage_priv,
> > > >   sparse_put_data_buffer(buffer);
> > > >   }
> > > >
> > > > - debug("Wrote %d blocks, skipped %d, expected to write %d
> blocks\n",
> > > > -   total_blocks, skipped,
> > > > + debug("Wrote %d blocks, expected to write %d blocks\n",
> > > > +   total_blocks,
> > >
> > > What's the rationale between those two patches?
> > >
> >
> > see inline comment above
> >
> >
> > >
> > > Do we really want to treat the DONT_CARE chunks as if they were
> > > written?
> > >
> >
> > I suspect that we do, and "sparse_header->total_blks" actually includes
> > them in the count too...
> > This "total_blocks" count is actually the number of blocks "processed"
> > (which may or may not include actually writing to the partition).
> > IMO - I think counting the "skipped blocks is unnecessary.
>
> Ok, sounds good.
>
> Thanks!
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] test/py: support running sandbox under gdbserver

[Stephen Warren]

On 02/06/2016 01:39 PM, Simon Glass wrote:

Hi Stephen,

On 6 February 2016 at 13:34, Stephen Warren  wrote:

On 02/06/2016 01:30 PM, Simon Glass wrote:

On 4 February 2016 at 16:11, Stephen Warren  wrote:

Implement command--line option --gdbserver COMM, which does two things:

a) Run the sandbox process under gdbserver, using COMM as gdbserver's
communication channel.

b) Disables all timeouts, so that if U-Boot is halted under the debugger,
tests don't fail. If the user gives up in the middle of a debugging
session, they can simply CTRL-C the test script to abort it.

This allows easy debugging of test failures without having to manually
re-create the failure conditions. Usage is:

Window 1:
./test/py/test.py --bd sandbox --gdbserver localhost:1234

Window 2:
gdb ./build-sandbox/u-boot -ex 'target remote localhost:1234'

When using this option, it likely makes sense to use pytest's -k option
to limit the set of tests that are executed.

Simply running U-Boot directly under gdb (rather than gdbserver) was
also considered. However, this was rejected because:

a) gdb's output would then be processed by the test script, and likely
confuse it causing false failures.

b) pytest by default hides stdout from tests, which would prevent the
user from interacting with gdb.

While gdb can be told to redirect the debugee's stdio to a separate
PTY, this would appear to leave gdb's stdio directed at the test
scripts and the debugee's stdio directed elsewhere, which is the
opposite of the desired effect. Perhaps some complicated PTY muxing
and process hierarchy could invert this. However, the current scheme
is simple to implement and use, so it doesn't seem worth complicating
matters.

c) Using gdbserver allows arbitrary debuggers to be used, even those with
a GUI. If the test scripts invoked the debugger themselves, they'd have
to know how to execute arbitary applications. While the user could hide
this all in a wrapper script, this feels like extra complication.

An interesting future idea might be a --gdb-screen option, which could
spawn both U-Boot and gdb separately, and spawn the screen into a newly
created window under screen. Similar options could be envisaged for
creating a new xterm/... too.

--gdbserver  currently only supports sandbox, and not real hardware.
That's primarily because the test hooks are responsible for all aspects of
hardware control, so there's nothing for the test scripts themselves can
do to enable gdbserver on real hardware. We might consider introducing a
separate --disable-timeouts option to support use of debuggers on real
hardware, and having --gdbserver imply that option.

Signed-off-by: Stephen Warren 
---
  test/py/conftest.py   |  8 
  test/py/tests/test_sleep.py   |  7 ---
  test/py/u_boot_console_base.py|  3 ++-
  test/py/u_boot_console_sandbox.py |  5 -
  test/py/u_boot_spawn.py   | 12 
  5 files changed, 26 insertions(+), 9 deletions(-)


Can you please add info about this to the docs?

Also for me this worked up to the point where it ran the
test_sandbox_exit.py test. Then the gdb process said that U-Boot
exited normally. Is that test not compatible with this feature?


The sandbox_exit test deliberately causes the sandbox process to exit,
to make sure that the "reset" command and "typing" Ctrl-C work. To
continue the test, simply re-run gdb to re-attach to the new gdbserver
and U-Boot process.


That's a bit annoying. Perhaps we should have a flag that disabled
such tests? Or perhaps a way to specify what tests are run?


I would expect the user to only run the specific test that needed 
debugging in order to speed up the whole process. So, unless someone was 
debugging the reset tests, they wouldn't notice this.


There's already a standard pytest option to select which tests to run; -k.


Anyway, can you add this to the docs too?


Sure.


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

Re: [U-Boot] [PATCH v2 3/7] drivers: block: disk-uclass: implement scsi_init()

[Simon Glass]

Hi Muganthan,

On 8 February 2016 at 04:23, Mugunthan V N  wrote:
> On Sunday 07 February 2016 01:59 AM, Simon Glass wrote:
>> Hi Bin,
>>
>> On 3 February 2016 at 04:59, Mugunthan V N  wrote:
>>>
>>> Implement scsi_init() api to probe driver model based sata
>>> devices.
>>>
>>> Signed-off-by: Mugunthan V N 
>>> ---
>>>  drivers/block/disk-uclass.c | 39 +++
>>>  1 file changed, 39 insertions(+)
>>
>> This patch seems odd to me. I would hope that scsi_init() would go
>> away with driver model and it would happen as part of the controller
>> probe. But of course we cannot probe SCSI from UCLASS_DISK. I think
>> the uclass 'disk' is too broad to be useful.
>>
>> So I am wondering whether the decision to use UCLASS_DISK instead of
>> UCLASS_AHCI was a mistake.
>>
>> Perhaps instead we should have:
>>
>> UCLASS_AHCI
>> UCLASS_SCSI
>> UCLASS_MMC
>> etc...
>>
>> and each of these devices can have a UCLASS_BLK under them (the block 
>> device).
>>
>> Possibly we could even have a dummy UCLASS_DISK device under each of
>> the above, but I'm not sure that is useful.
>>
>> What do you think?
>>
>
> Hmmm, this sounds a better approach to me also. So that we can abstract
> all bulk related activities to UCLASS_BLK. I can do an RFC if you are okay?

I have been working on a block uclass and tidying up the partition
stuff. I'll see if I can get patches out next week. In the meantime
I'd like to get comments from Bin and others about this too.

I suspect we will end up apply what you have (or similar) for this
release, but I'd like to figure out the best approach here.

Thinking about it more I suggest this:

UCLASS_AHCI / SCSI / MMC etc. for the controllers
each with a UCLASS_DISK child device for each disk attached to the controller
each with a (single) UCLASS_BLK child device

>
> Regards
> Mugunthan V N
>

Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 3/7] drivers: block: disk-uclass: implement scsi_init()

[Tom Rini]

On Mon, Feb 08, 2016 at 10:45:34AM -0700, Simon Glass wrote:
> Hi Muganthan,
> 
> On 8 February 2016 at 04:23, Mugunthan V N  wrote:
> > On Sunday 07 February 2016 01:59 AM, Simon Glass wrote:
> >> Hi Bin,
> >>
> >> On 3 February 2016 at 04:59, Mugunthan V N  wrote:
> >>>
> >>> Implement scsi_init() api to probe driver model based sata
> >>> devices.
> >>>
> >>> Signed-off-by: Mugunthan V N 
> >>> ---
> >>>  drivers/block/disk-uclass.c | 39 +++
> >>>  1 file changed, 39 insertions(+)
> >>
> >> This patch seems odd to me. I would hope that scsi_init() would go
> >> away with driver model and it would happen as part of the controller
> >> probe. But of course we cannot probe SCSI from UCLASS_DISK. I think
> >> the uclass 'disk' is too broad to be useful.
> >>
> >> So I am wondering whether the decision to use UCLASS_DISK instead of
> >> UCLASS_AHCI was a mistake.
> >>
> >> Perhaps instead we should have:
> >>
> >> UCLASS_AHCI
> >> UCLASS_SCSI
> >> UCLASS_MMC
> >> etc...
> >>
> >> and each of these devices can have a UCLASS_BLK under them (the block 
> >> device).
> >>
> >> Possibly we could even have a dummy UCLASS_DISK device under each of
> >> the above, but I'm not sure that is useful.
> >>
> >> What do you think?
> >>
> >
> > Hmmm, this sounds a better approach to me also. So that we can abstract
> > all bulk related activities to UCLASS_BLK. I can do an RFC if you are okay?
> 
> I have been working on a block uclass and tidying up the partition
> stuff. I'll see if I can get patches out next week. In the meantime
> I'd like to get comments from Bin and others about this too.
> 
> I suspect we will end up apply what you have (or similar) for this
> release, but I'd like to figure out the best approach here.

OK.  I had marked the series deferred this morning, and moved it back to
new now.  Given the caveat of needing  higher level rework after can you
review/ack/nack 3 and 5 as much as you feel comfortable with?  Thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 3/4] spi: omap3: Convert to DM

[Tom Rini]

On Sat, Feb 06, 2016 at 11:27:21PM +0100, Christophe Ricard wrote:
> Hi Simon, Tom,
> 
> I assume the approach you are taking is also valuable for the i2c:
> omap24xx patch serie:
> http://lists.denx.de/pipermail/u-boot/2016-January/241676.html
> 
> What are your recommendation about the pending patches ?
> Should i send back only the one not taking care of the DM conversion
> and send another serie later ?
> 
> I have seen some work ongoing on this topic on the u-boot-fdt tree
> on the spl-working branch.
> Is there a more accurate place to follow this work ?

For i2c, aside from needing to defer removing the non-DM code for a
while yet, there were some review comments to address in a v2 or answer
as intentional.  For SPI, it's all looking good and I'm assuming Jagan
will have a SPI PR soon.  Thanks!

> 
> Best Regards
> Christophe
> 
> On 26/01/2016 02:55, Peng Fan wrote:
> >Hi Simon,
> >
> >On Mon, Jan 25, 2016 at 06:11:24PM -0700, Simon Glass wrote:
> >>+Hans
> >>
> >>Hi Tom,
> >>
> >>On 21 January 2016 at 05:24, Tom Rini  wrote:
> >>>On Wed, Jan 20, 2016 at 07:46:15PM -0700, Simon Glass wrote:
> +Mugunthan, Tom
> 
> On 17 January 2016 at 03:56, Christophe Ricard
>  wrote:
> >Convert omap3_spi driver to DM and keep compatibility with previous
> >mode.
> >
> >Signed-off-by: Christophe Ricard 
> >---
> >
> >  drivers/spi/Kconfig |   6 +
> >  drivers/spi/omap3_spi.c | 439 
> > ++--
> >  drivers/spi/omap3_spi.h |  14 +-
> >  3 files changed, 402 insertions(+), 57 deletions(-)
> This is a pretty painful conversion, with lots of #ifdefs. I think it
> would be possible to use a common pointer type and reduce this.
> 
> But perhaps it does not matter - how long must we be in the state of
> supporting legacy SPI? Can we convert all TI boards to driver model?
> >>>We _really_ need some way to support more than one board per binary
> >>>before we can move everything to DM only.
> >>>
> >>>I think we can kind of do this today if we stick to using platform data
> >>>for everything that's board-specific rather than SoC-defined.  What we
> >>>talked about at ELCE was auto-generating the pdata from the device tree,
> >>>I think.
> >>We discussed this on IRC but since that doesn't exist as far as the
> >>mailing list is concerned...
> >>
> >>The current plan is:
> >>
> >>- Adjust build system to optionally build a u-boot.img in FIT format
> >>that includes the U-Boot binary and >1 device tree files
> >>- Adjust SPL to load this
> >>- Add a way for SPL to determine which device tree to select (by
> >>calling a board-specific function)
> >>- Have SPL pass this selected device tree to U-Boot when it starts
> >Can dtb be sperated from the final u-boot.img, if using SPL?
> >I mean let SPL load the u-boot.img and the dtb to correct DRAM address.
> >And the dtb is shared with linux kernel.
> >
> >Regards,
> >Peng.
> >>Thus we should be able to support more than one board with a single
> >>U-Boot image. Of course this is not a perfect solution (e.g. it is
> >>inefficient since the DTs are likely to be largely the same) but it
> >>should be a good first step.
> >>
> >>I'm going to try this out with sunxi initially and plan to get some
> >>patches out by the end of the week.
> >>
> >>Regards,
> >>Simon
> >>___
> >>U-Boot mailing list
> >>U-Boot@lists.denx.de
> >>http://lists.denx.de/mailman/listinfo/u-boot
> 

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 3/4] spi: omap3: Convert to DM

[Jagan Teki]

On 8 February 2016 at 23:10, Tom Rini  wrote:
> On Sat, Feb 06, 2016 at 11:27:21PM +0100, Christophe Ricard wrote:
>> Hi Simon, Tom,
>>
>> I assume the approach you are taking is also valuable for the i2c:
>> omap24xx patch serie:
>> http://lists.denx.de/pipermail/u-boot/2016-January/241676.html
>>
>> What are your recommendation about the pending patches ?
>> Should i send back only the one not taking care of the DM conversion
>> and send another serie later ?
>>
>> I have seen some work ongoing on this topic on the u-boot-fdt tree
>> on the spl-working branch.
>> Is there a more accurate place to follow this work ?
>
> For i2c, aside from needing to defer removing the non-DM code for a
> while yet, there were some review comments to address in a v2 or answer
> as intentional.  For SPI, it's all looking good and I'm assuming Jagan
> will have a SPI PR soon.  Thanks!

Yes, by this week-end.

>>
>> On 26/01/2016 02:55, Peng Fan wrote:
>> >Hi Simon,
>> >
>> >On Mon, Jan 25, 2016 at 06:11:24PM -0700, Simon Glass wrote:
>> >>+Hans
>> >>
>> >>Hi Tom,
>> >>
>> >>On 21 January 2016 at 05:24, Tom Rini  wrote:
>> >>>On Wed, Jan 20, 2016 at 07:46:15PM -0700, Simon Glass wrote:
>> +Mugunthan, Tom
>> 
>> On 17 January 2016 at 03:56, Christophe Ricard
>>  wrote:
>> >Convert omap3_spi driver to DM and keep compatibility with previous
>> >mode.
>> >
>> >Signed-off-by: Christophe Ricard 
>> >---
>> >
>> >  drivers/spi/Kconfig |   6 +
>> >  drivers/spi/omap3_spi.c | 439 
>> > ++--
>> >  drivers/spi/omap3_spi.h |  14 +-
>> >  3 files changed, 402 insertions(+), 57 deletions(-)
>> This is a pretty painful conversion, with lots of #ifdefs. I think it
>> would be possible to use a common pointer type and reduce this.
>> 
>> But perhaps it does not matter - how long must we be in the state of
>> supporting legacy SPI? Can we convert all TI boards to driver model?
>> >>>We _really_ need some way to support more than one board per binary
>> >>>before we can move everything to DM only.
>> >>>
>> >>>I think we can kind of do this today if we stick to using platform data
>> >>>for everything that's board-specific rather than SoC-defined.  What we
>> >>>talked about at ELCE was auto-generating the pdata from the device tree,
>> >>>I think.
>> >>We discussed this on IRC but since that doesn't exist as far as the
>> >>mailing list is concerned...
>> >>
>> >>The current plan is:
>> >>
>> >>- Adjust build system to optionally build a u-boot.img in FIT format
>> >>that includes the U-Boot binary and >1 device tree files
>> >>- Adjust SPL to load this
>> >>- Add a way for SPL to determine which device tree to select (by
>> >>calling a board-specific function)
>> >>- Have SPL pass this selected device tree to U-Boot when it starts
>> >Can dtb be sperated from the final u-boot.img, if using SPL?
>> >I mean let SPL load the u-boot.img and the dtb to correct DRAM address.
>> >And the dtb is shared with linux kernel.
>> >
>> >Regards,
>> >Peng.
>> >>Thus we should be able to support more than one board with a single
>> >>U-Boot image. Of course this is not a perfect solution (e.g. it is
>> >>inefficient since the DTs are likely to be largely the same) but it
>> >>should be a good first step.
>> >>
>> >>I'm going to try this out with sunxi initially and plan to get some
>> >>patches out by the end of the week.

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

Re: [U-Boot] rpi: link to another model number info source

[Tom Rini]

On Thu, Jan 28, 2016 at 10:24:44PM -0700, Stephen Warren wrote:

> This source has been blessed by Dom Cobley at the RPi Foundation, so seems
> like the best source to refer to. It's a superset of and consistent with
> the other sources.
> 
> Cc: Lubomir Rintel 
> Cc: Eric Anholt 
> Signed-off-by: Stephen Warren 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot,41/41,v2] ARM: omap3_logic: Fix pin muxing

[Tom Rini]

On Thu, Jan 21, 2016 at 07:50:07PM -0600, Adam Ford wrote:

> Enhance pin muxing to enable more board features and reduce power
> based on Tony's device tree work.
> 
> Signed-off-by: Adam Ford 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] serial: serial_stm32: move clock config from driver to board

[Tom Rini]

On Tue, Jan 26, 2016 at 06:12:20PM -0800, Vikas Manocha wrote:

> This patch removes the uart clock enable from serial driver & move it in the
> board code.
> 
> Signed-off-by: Vikas Manocha 
> Reviewed-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] test, tools: introduce tbot README

[Tom Rini]

On Tue, Jan 26, 2016 at 08:42:48AM +0100, Heiko Schocher wrote:

> introduce a README how to use tbot for testing U-Boot
> and/or linux kernels.
> 
> Signed-off-by: Heiko Schocher 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot, v3, 1/8] board: ti: ks2_evm: remove board_eth_init when CONFIG_DM_ETH is defined

[Tom Rini]

On Tue, Feb 02, 2016 at 03:51:31PM +0530, Mugunthan V N wrote:

> remove board_eth_init when CONFIG_DM_ETH is defined
> 
> Signed-off-by: Mugunthan V N 
> Reviewed-by: Tom Rini 
> Acked-by: Joe Hershberger 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot,V2] OMAP3: omap3_logic: Remove YAFFS support.

[Tom Rini]

On Mon, Feb 01, 2016 at 06:27:21AM -0600, Adam Ford wrote:

> UBIFS is the preferred FS, and YAFFS isn't officially included in
> Linux.  Removing this feature reduces the code size.
> 
> Signed-off-by: Adam Ford 
> Reviewed-by: Tom Rini 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot, 6/6] dm: Update on current serial driver status

[Tom Rini]

On Sun, Jan 31, 2016 at 09:16:17AM -0700, Simon Glass wrote:

> Update the README to reflect the current status.
> 
> Signed-off-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] OMAP3: omap3_logic: Enable CONFIG_SMC911X_32_BIT

[Tom Rini]

On Sun, Jan 31, 2016 at 05:13:33PM -0600, Adam Ford wrote:

> The interface automatically converts one 32-bit word into two 16 words.
> The README said it is permissible to use this flag in that scenario.
> 
> Signed-off-by: Adam Ford 
> Reviewed-by: Tom Rini 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot, 3/6] dm: freescale: serial: Drop serial_imx serial driver

[Tom Rini]

On Sun, Jan 31, 2016 at 09:16:14AM -0700, Simon Glass wrote:

> This does not appear to be used, and has not been converted to driver model
> by the deadline (doc/driver-model/serial-howto.txt).
> 
> Signed-off-by: Simon Glass 
> Reviewed-by: Tom Rini 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot, 1/6] dm: freescale: Drop mxs_auart serial driver

[Tom Rini]

On Sun, Jan 31, 2016 at 09:16:12AM -0700, Simon Glass wrote:

> This does not appear to be used, and has not been converted to driver model
> by the deadline (doc/driver-model/serial-howto.txt).
> 
> Signed-off-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot, 5/6] dm: pxa: serial: Drop serial_sa1100 serial driver

[Tom Rini]

On Sun, Jan 31, 2016 at 09:16:16AM -0700, Simon Glass wrote:

> This does not appear to be used, and has not been converted to driver model
> by the deadline (doc/driver-model/serial-howto.txt).
> 
> Signed-off-by: Simon Glass 
> Reviewed-by: Tom Rini 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] sniper: Drop references to P970

[Tom Rini]

On Sun, Feb 07, 2016 at 04:50:50PM +0100, Paul Kocialkowski wrote:

> There are various different boards with the same hardware sold as LG Optimus
> Black, such as P970, P970g and KU5900. Since this port is functional for all
> variants, it doesn't make sense to keep references to P970.
> 
> Signed-off-by: Paul Kocialkowski 
> Reviewed-by: Tom Rini 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] test/py: support running sandbox under gdbserver

[Stephen Warren]

On 02/08/2016 01:49 PM, Tom Rini wrote:

On Thu, Feb 04, 2016 at 04:11:50PM -0700, Stephen Warren wrote:


From: Stephen Warren 

Implement command--line option --gdbserver COMM, which does two things:

a) Run the sandbox process under gdbserver, using COMM as gdbserver's
communication channel.

b) Disables all timeouts, so that if U-Boot is halted under the debugger,
tests don't fail. If the user gives up in the middle of a debugging
session, they can simply CTRL-C the test script to abort it.

This allows easy debugging of test failures without having to manually
re-create the failure conditions. Usage is:

Window 1:
./test/py/test.py --bd sandbox --gdbserver localhost:1234

Window 2:
gdb ./build-sandbox/u-boot -ex 'target remote localhost:1234'

When using this option, it likely makes sense to use pytest's -k option
to limit the set of tests that are executed.

Simply running U-Boot directly under gdb (rather than gdbserver) was
also considered. However, this was rejected because:

a) gdb's output would then be processed by the test script, and likely
confuse it causing false failures.

b) pytest by default hides stdout from tests, which would prevent the
user from interacting with gdb.

While gdb can be told to redirect the debugee's stdio to a separate
PTY, this would appear to leave gdb's stdio directed at the test
scripts and the debugee's stdio directed elsewhere, which is the
opposite of the desired effect. Perhaps some complicated PTY muxing
and process hierarchy could invert this. However, the current scheme
is simple to implement and use, so it doesn't seem worth complicating
matters.

c) Using gdbserver allows arbitrary debuggers to be used, even those with
a GUI. If the test scripts invoked the debugger themselves, they'd have
to know how to execute arbitary applications. While the user could hide
this all in a wrapper script, this feels like extra complication.

An interesting future idea might be a --gdb-screen option, which could
spawn both U-Boot and gdb separately, and spawn the screen into a newly
created window under screen. Similar options could be envisaged for
creating a new xterm/... too.

--gdbserver  currently only supports sandbox, and not real hardware.
That's primarily because the test hooks are responsible for all aspects of
hardware control, so there's nothing for the test scripts themselves can
do to enable gdbserver on real hardware. We might consider introducing a
separate --disable-timeouts option to support use of debuggers on real
hardware, and having --gdbserver imply that option.

Signed-off-by: Stephen Warren 


Applied to u-boot/master, thanks!


Oh. I was just about to send V2 to address some of Simon's comments...
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot,5/5] s3c24xx: serial: Remove dead code

[Tom Rini]

On Sat, Feb 06, 2016 at 07:57:29AM +0100, David Müller (ELSOFT AG) wrote:

> Signed-off-by: David Müller 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2] dm: video: Add a temporary work-around for old stdout var

[Stephen Warren]

On 02/06/2016 02:31 PM, Simon Glass wrote:

Boards with a saved environment may use 'lcd' in their stdout environment
variable, expecting that this will enable output to the LCD. When the board
moves to use driver model for video, this will no-longer work. Add a
work-around to fix this. A warning messages is printed, and we will remove
the work-around at the end of 2016.


I tested u-boot-dm/tegra-working which I assume is the same as these 
patches, so the series,


Tested-by: Stephen Warren 

But...


diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig



+config VIDCONSOLE_AS_LCD
+   bool "Use 'vidconsole' when 'lcd' is seen in stdout"
+   depends on DM_VIDEO
+   help
+ This is a work-around for boards which have 'lcd' in their stdout
+ environment variable, but have moved to use driver model for video.
+ In this case the console will no-longer work. While it is possible
+ to update the environment, the breakage may be confusing for users.
+ This option will be removed around the end of 2016.


Removing this option at the end of 2016 is simply going to cause the 
exact same problem then. Is there any harm in simply not deprecating 
this feature? I suppose at least there's a warning that people should 
convert over, so perhaps they will and so the chances of people getting 
bitten by this well be less by then.

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

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

[Tom Rini]

On Fri, Feb 05, 2016 at 12:52:49PM +0800, Bin Meng wrote:

> Hi Tom,
> 
> This includes changes to move all x86 codes to use DM PCI APIs
> completely. Now DM_PCI_COMPAT is disabled in the x86 build.
> 
> The following changes since commit 94985cc9d3d7ed991ca8b2627d5894df5ea68f49:
> 
>   Merge branch 'master' of git://git.denx.de/u-boot-usb (2016-02-04
> 06:56:23 -0500)
> 
> are available in the git repository at:
> 
> 
>   git://git.denx.de/u-boot-x86.git master
> 
> for you to fetch changes up to 5c884420a5752163ce738701701ae1874d8f466d:
> 
>   x86: Drop pci_type1.c and DEFINE_PCI_DEVICE_TABLE (2016-02-05 12:47:24 
> +0800)
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Pull request: u-boot-staging

[Tom Rini]

On Sat, Feb 06, 2016 at 07:18:06PM +0100, Anatolij Gustschin wrote:

> Hi Tom,
> 
> The following changes since commit 94985cc9d3d7ed991ca8b2627d5894df5ea68f49:
> 
>   Merge branch 'master' of git://git.denx.de/u-boot-usb (2016-02-04 06:56:23 
> -0500)
> 
> are available in the git repository at:
> 
> 
>   git://git.denx.de/u-boot-staging.git ag...@denx.de
> 
> for you to fetch changes up to 2300184f702656b72394e458bf15f7aaba8af892:
> 
>   net: davinci_emac: fix NULL check after pointer dereference (2016-02-06 
> 16:39:31 +0100)
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] OMAP3: am3517_evm: SD/MMC boot with uEnv.txt, zImage, and FDT

[Tom Rini]

On Sun, Feb 07, 2016 at 08:54:47PM -0600, Derald D. Woods wrote:

> Boot with the Linux zImage and am3517-evm.dtb pair, when SD/MMC media
> is present. This behavior can be overridden by creating a 'uEnv.txt'
> file with 'uenvcmd' defined.
> 
> To boot an existing 'uImage', create the following 'uEnv.txt':
> 
> [start]-
> 
> loaduimage=fatload mmc 0:1 ${loadaddr} ${bootfile}
> uenvcmd=run loaduimage; run mmcargs; bootm ${loadaddr}
> 
> [end]---
> 
> Inspired by similar patches, for other OMAP3 boards, from EEWiki
> - https://github.com/eewiki/u-boot-patches/tree/master/v2016.01
> 
> Signed-off-by: Derald D. Woods 

Reviewed-by: Tom Rini 

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PULL] Please pull u-boot-nios/master

[Tom Rini]

On Sat, Feb 06, 2016 at 03:17:04PM +0800, Thomas Chou wrote:

> The following changes since commit 94985cc9d3d7ed991ca8b2627d5894df5ea68f49:
> 
>   Merge branch 'master' of git://git.denx.de/u-boot-usb (2016-02-04 06:56:23 
> -0500)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-nios.git master
> 
> for you to fetch changes up to e4f348ba6f070789e6505cc65cf6683421674637:
> 
>   nios2: set up the debug UART early (2016-02-06 15:14:25 +0800)
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot, v3, 2/7] tools: env: make parse_aes_key stateless

[Tom Rini]

On Wed, Dec 09, 2015 at 01:13:22PM +0100, Andreas Fenkart wrote:

> Signed-off-by: Andreas Fenkart 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot, v3, 1/7] tools: env validate: pass values as 0-based array

[Tom Rini]

On Wed, Dec 09, 2015 at 01:13:21PM +0100, Andreas Fenkart wrote:

> passing argv/argc can produce off-by-one errors
> 
> Signed-off-by: Andreas Fenkart 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] image: fix getenv_bootm_size() function again

[Tom Rini]

On Fri, Feb 05, 2016 at 04:12:50PM +0900, Masahiro Yamada wrote:

> Commit 9c11135ce053 ("image: fix getenv_bootm_size() function") fixed
> the case where "bootm_low" is defined, but "bootm_size" is not.
> Instead, it broke the case where neither "bootm_low" nor "bootm_size"
> is defined.  Fix this function again.
> 
> Fixes: 9c11135ce053 ("image: fix getenv_bootm_size() function")
> Signed-off-by: Masahiro Yamada 
> Tested-by: Matthias Weisser 
> Tested-by: Hannes Schmelzer 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] api: Add FreeBSD API support for MIPS platforms

[Tom Rini]

On Thu, Feb 04, 2016 at 12:13:44PM +0200, Stanislav Galabov wrote:

> This patch adds U-Boot API support (used by FreeBSD loader) for MIPS 
> platforms.
> 
> Signed-off-by: Stanislav Galabov 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot, v3, 1/3] kbuild: remove unneeded ifdef conditionals around build rules

[Tom Rini]

On Fri, Feb 05, 2016 at 05:55:12PM +0900, Masahiro Yamada wrote:

> These rules are only used for SOCFPGA, SUNXI, but no need to hide
> them from other SoCs.
> 
> Signed-off-by: Masahiro Yamada 
> Reviewed-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot, v3, 2/3] kbuild: add missing FORCE where $(call if_changed, ) is used

[Tom Rini]

On Fri, Feb 05, 2016 at 05:55:13PM +0900, Masahiro Yamada wrote:

> FORCE is needed for $(call if_changed,...) to be evaluated every time.
> Otherwise, the command is not executed when the command line has
> changed but any prerequisite has not been updated.
> 
> Signed-off-by: Masahiro Yamada 
> Reviewed-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] test/py: support running sandbox under gdbserver

[Tom Rini]

On Thu, Feb 04, 2016 at 04:11:50PM -0700, Stephen Warren wrote:

> From: Stephen Warren 
> 
> Implement command--line option --gdbserver COMM, which does two things:
> 
> a) Run the sandbox process under gdbserver, using COMM as gdbserver's
>communication channel.
> 
> b) Disables all timeouts, so that if U-Boot is halted under the debugger,
>tests don't fail. If the user gives up in the middle of a debugging
>session, they can simply CTRL-C the test script to abort it.
> 
> This allows easy debugging of test failures without having to manually
> re-create the failure conditions. Usage is:
> 
> Window 1:
> ./test/py/test.py --bd sandbox --gdbserver localhost:1234
> 
> Window 2:
> gdb ./build-sandbox/u-boot -ex 'target remote localhost:1234'
> 
> When using this option, it likely makes sense to use pytest's -k option
> to limit the set of tests that are executed.
> 
> Simply running U-Boot directly under gdb (rather than gdbserver) was
> also considered. However, this was rejected because:
> 
> a) gdb's output would then be processed by the test script, and likely
>confuse it causing false failures.
> 
> b) pytest by default hides stdout from tests, which would prevent the
>user from interacting with gdb.
> 
>While gdb can be told to redirect the debugee's stdio to a separate
>PTY, this would appear to leave gdb's stdio directed at the test
>scripts and the debugee's stdio directed elsewhere, which is the
>opposite of the desired effect. Perhaps some complicated PTY muxing
>and process hierarchy could invert this. However, the current scheme
>is simple to implement and use, so it doesn't seem worth complicating
>matters.
> 
> c) Using gdbserver allows arbitrary debuggers to be used, even those with
>a GUI. If the test scripts invoked the debugger themselves, they'd have
>to know how to execute arbitary applications. While the user could hide
>this all in a wrapper script, this feels like extra complication.
> 
> An interesting future idea might be a --gdb-screen option, which could
> spawn both U-Boot and gdb separately, and spawn the screen into a newly
> created window under screen. Similar options could be envisaged for
> creating a new xterm/... too.
> 
> --gdbserver  currently only supports sandbox, and not real hardware.
> That's primarily because the test hooks are responsible for all aspects of
> hardware control, so there's nothing for the test scripts themselves can
> do to enable gdbserver on real hardware. We might consider introducing a
> separate --disable-timeouts option to support use of debuggers on real
> hardware, and having --gdbserver imply that option.
> 
> Signed-off-by: Stephen Warren 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] .travis.yml: explicitly request sudo

[Tom Rini]

On Wed, Feb 03, 2016 at 10:41:34AM -0700, Stephen Warren wrote:

> From: Stephen Warren 
> 
> Without this, builds default to using new Travis CI infra-structure which
> does no allow sudo. The builds need sudo in order to install the ELDK
> compilers. Consequently, almost all builds fail without this.
> 
> I suspect that existing Travis CI users have not noticed this because
> their accounts or builds have been grand-fathered into backwards-
> compatible default settings, whereas I just set up a new build from
> scratch and received new default settings.
> 
> Cc: Wolfgang Denk 
> Cc: Heiko Schocher 
> Cc: Tom Rini 
> Cc: Daniel Schwierzeck 
> Cc: Andreas Färber 
> Signed-off-by: Stephen Warren 
> Acked-by: Heiko Schocher 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot, PATCHv2] common/memsize.c: Simplify RAM size detection

[Tom Rini]

On Tue, Feb 02, 2016 at 10:15:28PM +0200, Eddy Petrișor wrote:

> The case of memory of size 0 is not that different from a memory of any other
> size, so we remove the duplicate code and treat the small differences when it
> is the case.
> 
> Signed-off-by: Eddy Petrișor 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] malloc: solve dead code issue in memalign()

[Tom Rini]

On Thu, Feb 04, 2016 at 11:54:20AM -0700, Stephen Warren wrote:

> From: Stephen Warren 
> 
> The recent change to memalign() caused the allocation failure detection
> code to be dead code; the "retry" logic is always activated under the same
> condition that the original failure detection code is, and also fully
> handles any possible failures. This patch solves the presence of dead
> code.
> 
> Two alternatives are possible:
> 
> a) Delete the now-dead test, and rely on the "retry" path to handle any
> allocation problems, as it does.
> 
> b) Make the "retry" path fall through to the existing (currently dead)
> failure detection code, thus making it not-dead.
> 
> (b) was chosen since it reduces the diff between U-Boot's and the upstream
> dlmalloc. This should make it marginally easier to import a new version of
> dlmalloc in the future.
> 
> Reported by: Coverity Scan
> Fixes: 4f144a416469 ("malloc: work around some memalign fragmentation issues")
> Signed-off-by: Stephen Warren 
> Reviewed-by: Tom Rini 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] test/py: support running sandbox under gdbserver

[Tom Rini]

On Mon, Feb 08, 2016 at 01:55:10PM -0700, Stephen Warren wrote:
> On 02/08/2016 01:49 PM, Tom Rini wrote:
> >On Thu, Feb 04, 2016 at 04:11:50PM -0700, Stephen Warren wrote:
> >
> >>From: Stephen Warren 
> >>
> >>Implement command--line option --gdbserver COMM, which does two things:
> >>
> >>a) Run the sandbox process under gdbserver, using COMM as gdbserver's
> >>communication channel.
> >>
> >>b) Disables all timeouts, so that if U-Boot is halted under the debugger,
> >>tests don't fail. If the user gives up in the middle of a debugging
> >>session, they can simply CTRL-C the test script to abort it.
> >>
> >>This allows easy debugging of test failures without having to manually
> >>re-create the failure conditions. Usage is:
> >>
> >>Window 1:
> >>./test/py/test.py --bd sandbox --gdbserver localhost:1234
> >>
> >>Window 2:
> >>gdb ./build-sandbox/u-boot -ex 'target remote localhost:1234'
> >>
> >>When using this option, it likely makes sense to use pytest's -k option
> >>to limit the set of tests that are executed.
> >>
> >>Simply running U-Boot directly under gdb (rather than gdbserver) was
> >>also considered. However, this was rejected because:
> >>
> >>a) gdb's output would then be processed by the test script, and likely
> >>confuse it causing false failures.
> >>
> >>b) pytest by default hides stdout from tests, which would prevent the
> >>user from interacting with gdb.
> >>
> >>While gdb can be told to redirect the debugee's stdio to a separate
> >>PTY, this would appear to leave gdb's stdio directed at the test
> >>scripts and the debugee's stdio directed elsewhere, which is the
> >>opposite of the desired effect. Perhaps some complicated PTY muxing
> >>and process hierarchy could invert this. However, the current scheme
> >>is simple to implement and use, so it doesn't seem worth complicating
> >>matters.
> >>
> >>c) Using gdbserver allows arbitrary debuggers to be used, even those with
> >>a GUI. If the test scripts invoked the debugger themselves, they'd have
> >>to know how to execute arbitary applications. While the user could hide
> >>this all in a wrapper script, this feels like extra complication.
> >>
> >>An interesting future idea might be a --gdb-screen option, which could
> >>spawn both U-Boot and gdb separately, and spawn the screen into a newly
> >>created window under screen. Similar options could be envisaged for
> >>creating a new xterm/... too.
> >>
> >>--gdbserver  currently only supports sandbox, and not real hardware.
> >>That's primarily because the test hooks are responsible for all aspects of
> >>hardware control, so there's nothing for the test scripts themselves can
> >>do to enable gdbserver on real hardware. We might consider introducing a
> >>separate --disable-timeouts option to support use of debuggers on real
> >>hardware, and having --gdbserver imply that option.
> >>
> >>Signed-off-by: Stephen Warren 
> >
> >Applied to u-boot/master, thanks!
> 
> Oh. I was just about to send V2 to address some of Simon's comments...

Feh.  Please send 'em as an iterative patch then :)

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [Patch V3 2/3] fm: fdt: Move fman ucode fixup to Fman driver code

[york sun]

On 02/08/2016 11:18 AM, Scott Wood wrote:
> On Mon, 2016-02-08 at 19:03 +, york sun wrote:
>> On 02/01/2016 09:06 AM, york sun wrote:
>>> On 01/25/2016 09:40 PM, Qianyu Gong wrote:

> -Original Message-
> From: Scott Wood [mailto:o...@buserror.net]
> Sent: Tuesday, January 26, 2016 1:17 AM
> To: Qianyu Gong ; u-boot@lists.denx.de
> Cc: b07...@freescale.com; Shaohui Xie 
> Subject: Re: [U-Boot] [Patch V3 2/3] fm: fdt: Move fman ucode fixup to
> Fman
> driver code
>
> On Mon, 2016-01-25 at 19:37 +0800, Gong Qianyu wrote:
>> Both Freescale Layerscape and powerpc/mpc85xx platforms are using
>> fdt_fixup_fman_firmware() to insert Fman ucode blob into the device
>> tree. So move the function to driver code.
>>
>> Signed-off-by: Gong Qianyu 
>> ---
>> V3:
>>  - Remove file changes about "qe.h".
>>(Should be put in the first patch of this patchset)
>> V2:
>>  - New patch.
>>
>>  arch/powerpc/cpu/mpc85xx/fdt.c | 125
>> ++
>> -
>>  drivers/net/fm/Makefile|   1 +
>>  drivers/net/fm/fdt.c   | 129
>> +
>>  include/fsl_fman.h |   1 +
>>  4 files changed, 136 insertions(+), 120 deletions(-)
>
> Again, pass -M -C to git format-patch.
>
> -Scott

 I don't understand but I've already used "git format-patch -M -C --stat
 ...".

>>>
>>> Scott means using -M and -C, git should detect the moving instead of
>>> adding and
>>> deleting the same code. Try to add --find-copies-harder to see if it
>>> generates a
>>> smaller patch.
>>>
>>
>> Qianyu,
>>
>> Since you are on holiday, I tried it for you. Adjusting "-M -C" doesn't
>> work.
>> Even you are moving the function from one file to another, "git format
>> -patch"
>> cannot detect the moving because both files exist before and after this
>> change,
>> and the change set is not significant enough to be detected.
> 
> It looks like the patch is creating drivers/net/fm/fdt.c...
> 

I was fooled and tried to adjust -M with numbers. I only noticed when I compared
these two files before and after this patch.

Even it is moving a chunk of code from file A to file B, git cannot generate a
patch saying so.

York

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

Re: [U-Boot] [U-Boot, v3, 4/7] tools: env: parse aes key / suppress flag into argument struct

[Tom Rini]

On Wed, Dec 09, 2015 at 01:13:24PM +0100, Andreas Fenkart wrote:

> disabled original parsing, but not yet removed since the
> argument indexing needs to be fixed
> 
> Signed-off-by: Andreas Fenkart 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot, v3, 6/7] tools: env: factor out parse_common_args

[Tom Rini]

On Wed, Dec 09, 2015 at 01:13:26PM +0100, Andreas Fenkart wrote:

> Signed-off-by: Andreas Fenkart 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot,v3,7/7] tools: env: update usage strings

[Tom Rini]

On Wed, Dec 09, 2015 at 01:13:27PM +0100, Andreas Fenkart wrote:

> Signed-off-by: Andreas Fenkart 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot, v3, 3/7] tools: env: introduce setenv/printenv argument structs

[Tom Rini]

On Wed, Dec 09, 2015 at 01:13:23PM +0100, Andreas Fenkart wrote:

> goal is to use getopt for all argument parsing instead of adhoc
> parsing in fw_getenv/fw_setenv functions
> 
> Signed-off-by: Andreas Fenkart 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot, v3, 5/7] tools: env: shift optind arguments and fix argument indices

[Tom Rini]

On Wed, Dec 09, 2015 at 01:13:25PM +0100, Andreas Fenkart wrote:

> Signed-off-by: Andreas Fenkart 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot, 2/6] dm: opencores: Drop opencores_yanu serial driver

[Tom Rini]

On Sun, Jan 31, 2016 at 09:16:13AM -0700, Simon Glass wrote:

> This does not appear to be used, and has not been converted to driver model
> by the deadline (doc/driver-model/serial-howto.txt).
> 
> Signed-off-by: Simon Glass 
> Reviewed-by: Tom Rini 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot, 4/6] dm: serial: Drop serial_max3100 serial driver

[Tom Rini]

On Sun, Jan 31, 2016 at 09:16:15AM -0700, Simon Glass wrote:

> This does not appear to be used, and has not been converted to driver model
> by the deadline (doc/driver-model/serial-howto.txt).
> 
> Signed-off-by: Simon Glass 
> Reviewed-by: Tom Rini 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] rpi: link to another model number info source

[Tom Rini]

On Thu, Jan 28, 2016 at 10:24:44PM -0700, Stephen Warren wrote:

> This source has been blessed by Dom Cobley at the RPi Foundation, so seems
> like the best source to refer to. It's a superset of and consistent with
> the other sources.
> 
> Cc: Lubomir Rintel 
> Cc: Eric Anholt 
> Signed-off-by: Stephen Warren 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] OMAP3: Enable SPL on omap3_logic

[Tom Rini]

On Fri, Jan 29, 2016 at 08:12:34PM -0600, Adam Ford wrote:

> Previously, Omap3_logic assumed X-loader was present.  With this
> patch, we can finally replace X-loader with an MLO generated by
> U-Boot.  This requires ECC to be setup to match the Linux Kernel
> and the PBIAS confgured for the SD card.
> 
> Signed-off-by: Derald D. Woods 
> Signed-off-by: Adam Ford 
> Reviewed-by: Tom Rini 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot, v3, 7/8] ARM: dts: k2g: Add keystone net dts files

[Tom Rini]

On Tue, Feb 02, 2016 at 03:51:37PM +0530, Mugunthan V N wrote:

> Add keystone net DT support for k2g evm.
> 
> Signed-off-by: Mugunthan V N 
> Reviewed-by: Tom Rini 
> Acked-by: Joe Hershberger 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot, v3, 8/8] defconfig: k2g_evm_defconfig: enable net driver model

[Tom Rini]

On Tue, Feb 02, 2016 at 03:51:38PM +0530, Mugunthan V N wrote:

> enable net driver model for k2g evm as keystone_net supports
> driver model
> 
> Signed-off-by: Mugunthan V N 
> Reviewed-by: Tom Rini 
> Acked-by: Joe Hershberger 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot, v3, 6/8] defconfig: k2e_evm_defconfig: enable net driver model

[Tom Rini]

On Tue, Feb 02, 2016 at 03:51:36PM +0530, Mugunthan V N wrote:

> enable net driver model for k2e evm as keystone_net supports
> driver model
> 
> Signed-off-by: Mugunthan V N 
> Reviewed-by: Tom Rini 
> Acked-by: Joe Hershberger 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] rpi: set ethaddr as well

[Tom Rini]

On Wed, Feb 03, 2016 at 04:08:09PM +0100, Lubomir Rintel wrote:

> Let's set "ethaddr" when we get the ethernet address too, so that
> fdt_fixup_ethernet() sets the address in the device tree and the Linux
> driver can pick it up.
> 
> Signed-off-by: Lubomir Rintel 
> Tested-by: Stephen Warren 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot, v3, 3/3] kbuild: fix build rule of u-boot-spl.dtb

[Tom Rini]

On Fri, Feb 05, 2016 at 05:55:14PM +0900, Masahiro Yamada wrote:

> The build command of u-boot-spl.dtb is not constant, but dependent
> on CONFIG_OF_SPL_REMOVE_PROPS.  Use $(call if_changed,...) so that
> the change of CONFIG_OF_SPL_REMOVE_PROPS is detected.
> 
> Also, add tools/fdtgrep to the dependency to make sure u-boot-spl.dtb
> is generated by the up-to-date fdtgrep in case the tool is modified.
> 
> Signed-off-by: Masahiro Yamada 
> Reviewed-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] board_r: fix a typo in comment block

[Tom Rini]

On Fri, Feb 05, 2016 at 08:49:39PM +0900, Masahiro Yamada wrote:

> Signed-off-by: Masahiro Yamada 
> Reviewed-by: Bin Meng 
> Reviewed-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot, 2/2] ARM: rpi: set fdt_high in the default environment

[Tom Rini]

On Fri, Feb 05, 2016 at 10:45:47PM -0700, Stephen Warren wrote:

> The ARM Linux kernel requires the DT to be in memory accessible early
> during the boot process. This always happens naturally on the RPi 1,
> since the maximum memory size of 512MiB, and additionally some of that
> is reserved for use by the GPU. The RPi 2 has 1GiB of RAM (minus some
> GPU usage), and so if the DT is relocated to the top of RAM, Linux cannot
> access it. Prevent this from happening by setting fdt_high.
> 
> Cc: Daniel Stone 
> Signed-off-by: Stephen Warren 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot, 1/2] ARM: rpi: update memory layout env. var. documentation

[Tom Rini]

On Fri, Feb 05, 2016 at 10:45:46PM -0700, Stephen Warren wrote:

> Update rpi-common.h's documentation that describes the rationale for
> choosing various addresses for standardized variables used by boot
> scripts. This comment was correct when written, but not updated when some
> of the values were changed.
> 
> Fixes: 14006a567105 ("rpi: set fdt_addr_r to 0x0100 to match default
> ...device_tree_address")
> Cc: Jonathan Liu 
> Cc: Daniel Stone 
> Signed-off-by: Stephen Warren 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot, 4/5] doc: Remove any reference to CONFIG_MODEM_SUPPORT, CONFIG_CMD_HWFLOW, CONFIG_HWFLOW and friends from the documentation.

[Tom Rini]

On Sat, Feb 06, 2016 at 07:57:28AM +0100, David Müller (ELSOFT AG) wrote:

> Signed-off-by: David Müller 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot, 3/5] Remove unused CONFIG_HWFLOW option and associated dead code.

[Tom Rini]

On Sat, Feb 06, 2016 at 07:57:27AM +0100, David Müller (ELSOFT AG) wrote:

> Signed-off-by: David Müller 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot