Re: [U-Boot] [PATCH 01/19] configs: Add FPGA loadfs config for Arria 10

[Chee, Tien Fong]

On Sel, 2017-08-29 at 13:51 +0200, Marek Vasut wrote:
> On 08/29/2017 12:45 PM, tien.fong.c...@intel.com wrote:
> > 
> > From: Tien Fong Chee 
> > 
> > This config allow FPGA design loaded from FAT fs to FPGA manager.
> > 
> > Signed-off-by: Tien Fong Chee 
> > ---
> >  configs/socfpga_arria10_defconfig |1 +
> >  1 files changed, 1 insertions(+), 0 deletions(-)
> > 
> > diff --git a/configs/socfpga_arria10_defconfig
> > b/configs/socfpga_arria10_defconfig
> > index 53ab66f..d555743 100644
> > --- a/configs/socfpga_arria10_defconfig
> > +++ b/configs/socfpga_arria10_defconfig
> > @@ -29,3 +29,4 @@ CONFIG_DWAPB_GPIO=y
> >  CONFIG_DM_MMC=y
> >  CONFIG_SYS_NS16550=y
> >  CONFIG_USE_TINY_PRINTF=y
> > +CONFIG_CMD_FPGA_LOADFS=y
> You should enable stuff only after you add the necessary support bits
> ...
> 
I enabled it as early as possible, because i would like to use
compiling for detecting any code errors while adding the neccesssary
support bits. I can rearrange the patches sequence.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v3 0/8] sf: improve support of (Q)SPI flash memories

[Yang, Wenyou]

On 2017/8/30 13:41, Bin Meng wrote:

On Wed, Aug 30, 2017 at 1:27 PM, Yang, Wenyou  wrote:


On 2017/8/30 11:43, Bin Meng wrote:

On Wed, Aug 30, 2017 at 11:25 AM, Yang, Wenyou
 wrote:


On 2017/8/26 14:34, Jagan Teki wrote:

Hi,

Thanks for the changes.

On Tue, Jul 25, 2017 at 12:30 PM, Wenyou Yang

wrote:

This series of patches are based and have been tested on the 'master'
branch of the u-boot.git tree.

Tests were passed with a sama5d2 xplained board which embeds both SPI
and
QSPI controllers.

The following tests have been passed:

- QSPI0 + Macronix MX25L25673G:
 + probe: OK
 + Fast Read 1-1-4 at offset 0x1 (u-boot env): OK
 + Page Program 1-1-4 at offset 0x1: OK
   The Macronix datasheet tells that only Page Program 1-4-4 is
   supported, not Page Program 1-1-4, however it worked, I don't
know
   why...

- QSPI0 + Microchip SST26
 + probe: OK
 + Fast Read 1-1-4 at offset 0x1 (u-boot env): OK
 + Page Program 1-1-1 at offset 0x1: OK
   SST26 memories support Page Program 1-4-4 but with the op code of
   Page Program 1-1-4, which is not standard so I don't use it.

- QSPI0 + Adesto AT25DF321A
 + probe: OK
 + Fast Read 1-1-1 at offset 0x1 (u-boot env): OK
 + Page Program 1-1-1 at offset 0x1: OK

- SPI0 + Adesto AT25DF321A
 + probe: OK
 + Fast Read 1-1-1 at offset 0x6000 (u-boot env): OK
 + Page Program 1-1-1 at offest 0x6000: OK

- SPI1 + Atmel AT45
 + probe: OK
 + Read at offset 0 and other than 0: OK
 + Write at offset 0 and other than 0: OK

During my tests, I used:
 - setenv/saveenv, reboot, printenv
 or
 - sf probe, sf read, sf write, sf erase and sf update.

Changes in v3:
- Add the include  to fix build error for corvus_defconfig.

Changes in v2:
- Rebase on the latest u-boot/master(2710d54f5).

Cyrille Pitchen (8):
 spi: add support of SPI flash commands
 sf: describe all SPI flash commands with 'struct spi_flash_command'
 sf: select the relevant SPI flash protocol for read and write
commands
 sf: differentiate Page Program 1-1-4 and 1-4-4
 sf: add 'addr_len' member to 'struct spi_flash'
 sf: add new option to support SPI flash above 16MiB
 sf: add support to Microchip SST26 QSPI memories
 sf: add driver for Atmel QSPI controller

Comments:
How about writing struct spi_flash_command in spi_flash area
(include/spi_flash.h)? and then write atmel_qspi with
UCLASS_SPI_FLASH?

Testing:
Basic testing works fine.

Issues:
- Build issue: with zynq_microzed_defconfig
drivers/mtd/spi/spi_flash.c: In function ‘spi_flash_scan’:
drivers/mtd/spi/spi_flash.c:1049:7: warning: variable ‘above_16MB’ set
but not used [-Wunused-but-set-variable]
 bool above_16MB;
  ^~
 CC  spl/lib/membuff.o

- issue with spi_flash_cmd_read_ops 4BAIS
Need to calculate bank length only if BAR is in use. Otherwise,
consider the given len as read_len.

Will send separate patch for this.

Will You send a separate patch? or I include it in this patch set?

This should not be a separate patch. Since every patch needs to pass
buildman testing.

But it is not introduced by this patch set. So should be a separate patch to
fix.

Do you mean the build warnings exist in current u-boot/master?
Here are two issue, one is the build warning, other is the issue with 
spi_flash_cmd_read_ops.
The build warning is related with this patch, I will fix it in the next 
version.
But  the issue with spi_flash_cmd_read_ops on bank length is not related 
with this patch.




If so, Jagan can you please explain why you mention this? This is
nothing related to this patch review.

Regards,
Bin


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

Re: [U-Boot] [PATCH v3 0/8] sf: improve support of (Q)SPI flash memories

[Bin Meng]

On Wed, Aug 30, 2017 at 1:27 PM, Yang, Wenyou  wrote:
>
>
> On 2017/8/30 11:43, Bin Meng wrote:
>>
>> On Wed, Aug 30, 2017 at 11:25 AM, Yang, Wenyou
>>  wrote:
>>>
>>>
>>> On 2017/8/26 14:34, Jagan Teki wrote:

 Hi,

 Thanks for the changes.

 On Tue, Jul 25, 2017 at 12:30 PM, Wenyou Yang
 
 wrote:
>
> This series of patches are based and have been tested on the 'master'
> branch of the u-boot.git tree.
>
> Tests were passed with a sama5d2 xplained board which embeds both SPI
> and
> QSPI controllers.
>
> The following tests have been passed:
>
> - QSPI0 + Macronix MX25L25673G:
> + probe: OK
> + Fast Read 1-1-4 at offset 0x1 (u-boot env): OK
> + Page Program 1-1-4 at offset 0x1: OK
>   The Macronix datasheet tells that only Page Program 1-4-4 is
>   supported, not Page Program 1-1-4, however it worked, I don't
> know
>   why...
>
> - QSPI0 + Microchip SST26
> + probe: OK
> + Fast Read 1-1-4 at offset 0x1 (u-boot env): OK
> + Page Program 1-1-1 at offset 0x1: OK
>   SST26 memories support Page Program 1-4-4 but with the op code of
>   Page Program 1-1-4, which is not standard so I don't use it.
>
> - QSPI0 + Adesto AT25DF321A
> + probe: OK
> + Fast Read 1-1-1 at offset 0x1 (u-boot env): OK
> + Page Program 1-1-1 at offset 0x1: OK
>
> - SPI0 + Adesto AT25DF321A
> + probe: OK
> + Fast Read 1-1-1 at offset 0x6000 (u-boot env): OK
> + Page Program 1-1-1 at offest 0x6000: OK
>
> - SPI1 + Atmel AT45
> + probe: OK
> + Read at offset 0 and other than 0: OK
> + Write at offset 0 and other than 0: OK
>
> During my tests, I used:
> - setenv/saveenv, reboot, printenv
> or
> - sf probe, sf read, sf write, sf erase and sf update.
>
> Changes in v3:
>- Add the include  to fix build error for corvus_defconfig.
>
> Changes in v2:
>- Rebase on the latest u-boot/master(2710d54f5).
>
> Cyrille Pitchen (8):
> spi: add support of SPI flash commands
> sf: describe all SPI flash commands with 'struct spi_flash_command'
> sf: select the relevant SPI flash protocol for read and write
> commands
> sf: differentiate Page Program 1-1-4 and 1-4-4
> sf: add 'addr_len' member to 'struct spi_flash'
> sf: add new option to support SPI flash above 16MiB
> sf: add support to Microchip SST26 QSPI memories
> sf: add driver for Atmel QSPI controller

 Comments:
 How about writing struct spi_flash_command in spi_flash area
 (include/spi_flash.h)? and then write atmel_qspi with
 UCLASS_SPI_FLASH?

 Testing:
 Basic testing works fine.

 Issues:
 - Build issue: with zynq_microzed_defconfig
 drivers/mtd/spi/spi_flash.c: In function ‘spi_flash_scan’:
 drivers/mtd/spi/spi_flash.c:1049:7: warning: variable ‘above_16MB’ set
 but not used [-Wunused-but-set-variable]
 bool above_16MB;
  ^~
 CC  spl/lib/membuff.o

 - issue with spi_flash_cmd_read_ops 4BAIS
 Need to calculate bank length only if BAR is in use. Otherwise,
 consider the given len as read_len.

 Will send separate patch for this.
>>>
>>> Will You send a separate patch? or I include it in this patch set?
>>
>> This should not be a separate patch. Since every patch needs to pass
>> buildman testing.
>
> But it is not introduced by this patch set. So should be a separate patch to
> fix.

Do you mean the build warnings exist in current u-boot/master?

If so, Jagan can you please explain why you mention this? This is
nothing related to this patch review.

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

Re: [U-Boot] DA850evm SPI Flash Partitions between Linux and U-boot are Inconsistent

[Sekhar Nori]

On Wednesday 30 August 2017 08:07 AM, Adam Ford wrote:
> On Tue, Aug 29, 2017 at 8:05 AM, Adam Ford  wrote:
>> On Tue, Aug 29, 2017 at 6:41 AM, Sekhar Nori  wrote:
>>> On Tuesday 29 August 2017 03:29 PM, Adam Ford wrote:
 On Tue, Aug 29, 2017 at 4:13 AM, Sekhar Nori  wrote:
> Hi Adam,
>
> On Sunday 27 August 2017 08:31 PM, Adam Ford wrote:
>> I was trying to enable MTD Partitions to make loading the Kernel and
>> FS easier from within U-Boot
>>
>> The da850evm spi-flash partitions in Linux show
>>
>> "U-Boot-SPL" @ offset 0, size 64K
>> "U-Boot"; @ offset 0x0001, size 512K
>> "U-Boot-Env"; @ offset 0x0009
>
> According to board/davinci/da8xxevm/README.da850, we support AIS image
> format for SPI boot. This is a single image containing SPL and U-Boot.
>
> Given this, I think having separate partitions for SPL and U-Boot does
> not make sense since thats not how its going to be used.

 That's what I was thinking too, but I wasn't sure if someone had split
 SPL somehow to make it possible to update U-Boot via Linux or U-Boot
 itself.
>
>>
>> However U-Boot shows the following:
>>
>> CONFIG_SYS_SPI_U_BOOT_OFFS 0x8000 which would make the SPL partition 32K.
>> CONFIG_SYS_SPI_U_BOOT_SIZE  0x4 and the size of U-boot 256K
>> instead of 512k.
>>
>> CONFIG_ENV_SIZE (64 << 10)
>> CONFIG_ENV_OFFSET   (512 << 10) which is 0x8 instead of
>> Linux's 0x9
>>
>> It seems to me like the U-Boot and Linux should try and synchronize
>> their partitions tables.
>
> Right.
>
>> For people who want to burn Linux into the SPI flash it seems there
>> there should be some consistency.  I tried making the U-boot settings
>> match the Linux ones, but it seems to hang between SPL and U-Boot, so
>> I think the U-Boot offset in Linux might need to match U-Boot.  Can
>> you guys make some recomendations as to which is correct?
>
> I have not tried it, but looks like the partitions we need are
>
> "SPL/U-Boot AIS" @ offset 0, size 512K
> "U-Boot Environment" @ offset 512K, size 64K

 I was thinking the same thing.

> "Kernel/Spare" @ offset 576K, size 7552K
> "Mac Address" @ offset 8128K, size 64K (read only)

 If U-Boot reads the MAC address from its environmental variables
 instead of using up an entire 64K for what conceivably is 6 bytes,
 could we free up this space to help grow the Kernel/Spare space?
>>>
>>> If environment sector is erased, the mac address needs to be restored
>>> from SPI flash. Thats why I think it needs to remain as a read-only
>>> partition. Also, its just 64K more space, not sure if it will make a big
>>> difference in the overall scheme of things.
>>>
> With an 8M flash, I think its futile to try to fit a modern filesystem
> on the flash.
>
> If you are using DT boot, we cannot really change the partitions in
> device-tree because of DT backward-compatibility requirements. But we
> can fix da850evm_spiflash_part[] table in
> arch/arm/mach-davinci/board-da850-evm.c.

 Wouldn't having two different partition tables between da850-evm.c and
 the DT cause confusion down the road?  With DT being the future, why
 would we not try to eliminate any custom board files with just a
 single common davinci board file + board specific DT?
>>>
>>> Thats ideal yes. But there is a lot of support in the da850-evm board
>>> file which does not have a DT equivalent yet. Thats why I have kept the
>>> board file around.
>>>
> To help DT boot, we can pass fixed up mtdparts through environment
> variables. Something like what is done in 3f18ff07c81b ("ARM: keystone:
> Pass SPI MTD partition table via kernel command line").

 This was ultimately was I was wanting to do.  For some of the OMAP3
 boards, removing the partition tree was accepted since the partition
 info was passed to the kernel.  If we did this for DA850, we could
 simply elimiate the partition info in the Kernel (like some of the
 omap3 boards) and let the partition maps be defined by U-Boot would
 would guarantee consistency between them.
>>>
>>> Actually, thinking a bit more, we cannot change the partition
>>> information in kernel at all since that means loss of data for anyone
>>> updating just the kernel.
>>>
>>> We can however, pass updated kernel command line arguments in U-Boot so
>>> anyone updating the bootloader and erasing the environment sector gets
>>> updated partition information. This is likely to be the case where
>>> entire flash is being re-written and loss of data is not a concern.
>>>
>> That makes sense to me.
>>
>> I'll send a U-Boot patch marked RFC later today with the MTD stuff
>> enabled in U-Boot and changes to the bootargs to pass 

Re: [U-Boot] [PATCH v3 0/8] sf: improve support of (Q)SPI flash memories

[Yang, Wenyou]

On 2017/8/30 11:43, Bin Meng wrote:

On Wed, Aug 30, 2017 at 11:25 AM, Yang, Wenyou
 wrote:


On 2017/8/26 14:34, Jagan Teki wrote:

Hi,

Thanks for the changes.

On Tue, Jul 25, 2017 at 12:30 PM, Wenyou Yang 
wrote:

This series of patches are based and have been tested on the 'master'
branch of the u-boot.git tree.

Tests were passed with a sama5d2 xplained board which embeds both SPI and
QSPI controllers.

The following tests have been passed:

- QSPI0 + Macronix MX25L25673G:
+ probe: OK
+ Fast Read 1-1-4 at offset 0x1 (u-boot env): OK
+ Page Program 1-1-4 at offset 0x1: OK
  The Macronix datasheet tells that only Page Program 1-4-4 is
  supported, not Page Program 1-1-4, however it worked, I don't know
  why...

- QSPI0 + Microchip SST26
+ probe: OK
+ Fast Read 1-1-4 at offset 0x1 (u-boot env): OK
+ Page Program 1-1-1 at offset 0x1: OK
  SST26 memories support Page Program 1-4-4 but with the op code of
  Page Program 1-1-4, which is not standard so I don't use it.

- QSPI0 + Adesto AT25DF321A
+ probe: OK
+ Fast Read 1-1-1 at offset 0x1 (u-boot env): OK
+ Page Program 1-1-1 at offset 0x1: OK

- SPI0 + Adesto AT25DF321A
+ probe: OK
+ Fast Read 1-1-1 at offset 0x6000 (u-boot env): OK
+ Page Program 1-1-1 at offest 0x6000: OK

- SPI1 + Atmel AT45
+ probe: OK
+ Read at offset 0 and other than 0: OK
+ Write at offset 0 and other than 0: OK

During my tests, I used:
- setenv/saveenv, reboot, printenv
or
- sf probe, sf read, sf write, sf erase and sf update.

Changes in v3:
   - Add the include  to fix build error for corvus_defconfig.

Changes in v2:
   - Rebase on the latest u-boot/master(2710d54f5).

Cyrille Pitchen (8):
spi: add support of SPI flash commands
sf: describe all SPI flash commands with 'struct spi_flash_command'
sf: select the relevant SPI flash protocol for read and write commands
sf: differentiate Page Program 1-1-4 and 1-4-4
sf: add 'addr_len' member to 'struct spi_flash'
sf: add new option to support SPI flash above 16MiB
sf: add support to Microchip SST26 QSPI memories
sf: add driver for Atmel QSPI controller

Comments:
How about writing struct spi_flash_command in spi_flash area
(include/spi_flash.h)? and then write atmel_qspi with
UCLASS_SPI_FLASH?

Testing:
Basic testing works fine.

Issues:
- Build issue: with zynq_microzed_defconfig
drivers/mtd/spi/spi_flash.c: In function ‘spi_flash_scan’:
drivers/mtd/spi/spi_flash.c:1049:7: warning: variable ‘above_16MB’ set
but not used [-Wunused-but-set-variable]
bool above_16MB;
 ^~
CC  spl/lib/membuff.o

- issue with spi_flash_cmd_read_ops 4BAIS
Need to calculate bank length only if BAR is in use. Otherwise,
consider the given len as read_len.

Will send separate patch for this.

Will You send a separate patch? or I include it in this patch set?

This should not be a separate patch. Since every patch needs to pass
buildman testing.
But it is not introduced by this patch set. So should be a separate 
patch to fix.



diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
index 89ceae2..b5d8ef3 100644
--- a/drivers/mtd/spi/spi_flash.c
+++ b/drivers/mtd/spi/spi_flash.c
@@ -558,13 +558,15 @@ int spi_flash_cmd_read_ops(struct spi_flash
*flash, u32 offset,
   if (ret < 0)
   return ret;
   bank_sel = flash->bank_curr;
-#endif
   remain_len = ((SPI_FLASH_16MB_BOUN << flash->shift) *
   (bank_sel + 1)) - offset;
   if (len < remain_len)
   read_len = len;
   else
   read_len = remain_len;
+#else
+read_len = len;
+#endif

   cmd.addr = read_addr;
   cmd.data_len = read_len;


Regards,
Bin


Best Regards,
Wenyou Yang

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

[U-Boot] [PATCH] libfdt: Initialize the stack variable

[tien . fong . chee]

From: Tien Fong Chee 

Report Coverity log:
The code uses a variable that has not
been initialized, leading to unpredictable
or unintended results.

Reported-by: Coverity (CID: 60519)
Signed-off-by: Tien Fong Chee 
---
 lib/libfdt/fdt_wip.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/lib/libfdt/fdt_wip.c b/lib/libfdt/fdt_wip.c
index 45fb964..01adad0 100644
--- a/lib/libfdt/fdt_wip.c
+++ b/lib/libfdt/fdt_wip.c
@@ -115,7 +115,7 @@ int fdt_find_regions(const void *fdt, char * const inc[], 
int inc_count,
 struct fdt_region region[], int max_regions,
 char *path, int path_len, int add_string_tab)
 {
-   int stack[FDT_MAX_DEPTH];
+   int stack[FDT_MAX_DEPTH] = { 0 };
char *end;
int nextoffset = 0;
uint32_t tag;
-- 
1.7.7.4

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

Re: [U-Boot] [PATCH] libfdt: Initialize the stack variable

[Chee, Tien Fong]

On Kha, 2017-08-24 at 21:04 -0400, Tom Rini wrote:
> On Thu, Aug 24, 2017 at 01:53:57PM +0800, tien.fong.c...@intel.com
> wrote:
> 
> > 
> > From: Tien Fong Chee 
> > 
> > Report Coverity log:
> > The code uses a variable that has not
> > been initialized, leading to unpredictable
> > or unintended results.
> > 
> > Signed-off-by: Tien Fong Chee 
> > ---
> >  lib/libfdt/fdt_wip.c |2 +-
> >  1 files changed, 1 insertions(+), 1 deletions(-)
> > 
> > diff --git a/lib/libfdt/fdt_wip.c b/lib/libfdt/fdt_wip.c
> > index 45fb964..01adad0 100644
> > --- a/lib/libfdt/fdt_wip.c
> > +++ b/lib/libfdt/fdt_wip.c
> > @@ -115,7 +115,7 @@ int fdt_find_regions(const void *fdt, char *
> > const inc[], int inc_count,
> >      struct fdt_region region[], int max_regions,
> >      char *path, int path_len, int add_string_tab)
> >  {
> > -   int stack[FDT_MAX_DEPTH];
> > +   int stack[FDT_MAX_DEPTH] = { 0 };
> >     char *end;
> >     int nextoffset = 0;
> >     uint32_t tag;
> Since this comes from libfdt, have you checked there as well?  And in
> general, we use a Reported-by: Coverity (CID: ) for issues.  BTW,
> if
> you would like access to the community version of Coverity, please
> sign
> up at https://scan.coverity.com/projects/das-u-boot?tab=overview
> thanks!
> 
Okay, i can add myself to Das U-boot coverity project finally. This
warning is reported by CID: 60519. I will send out another patch with
Reported-by in commit messages.
Thanks.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] ** Can't read Driver Desriptor Block **

[Heinrich Schuchardt]

On 08/30/2017 03:54 AM, Bin Meng wrote:
> Hi Heinrich,
> 
> On Wed, Aug 30, 2017 at 4:26 AM, Heinrich Schuchardt  
> wrote:
>> Hello Simon,
>>
>> U-Boot HEAD qemu-86_defconfig cannot discover an IDE disk with one FAT
>> partition in qemu-system-x86_64.
>>
>> By bisection I found this patch.
>>
>> b7c6baef2891ce8978cbfddb66e944943473ac21
>> x86: Convert MMC to driver model
>>
>> With this patch I get
>>
>> IDE:   Bus 0: OK Bus 1: OK
>>   Device 0: Model: QEMU HARDDISK  Firm: 2.5+ Ser#: QM1
>> Type: Hard Disk
>> Supports 48-bit addressing
>> Capacity: 128.0 MB = 0.1 GB (262144 x 512)
>> ** Can't read Driver Desriptor Block **
>>   Device 1: not available
>>   Device 2: Model: QEMU Firm: 2.5+ Ser#: QEMU DVD-ROM
>> Type: Removable CD ROM
>> Capacity: not available
>>   Device 3: not available
>>
>> => ide info
>> =>
>>
>> Without the patch I get=> ide info
>> Device 0: Model: QEMU HARDDISK  Firm: 2.5+ Ser#: QM1
>> Type: Hard Disk
>> Supports 48-bit addressing
>> Capacity: 128.0 MB = 0.1 GB (262144 x 512)
>> Device 2: Model: QEMU Firm: 2.5+ Ser#: QEMU DVD-ROM
>> Type: Removable CD ROM
>> Capacity: not available
>>
>> I think we observe two independent errors here:
>>
>> - The hard disk Device 0 is not read.
>> - The ide command stops at the first device that is not available.
>>
>> I guess only the first is caused by your patch.
> 
> Both logs look fine to me. The "Can't read Driver Desriptor Block"
> comes from part_mac.c. Did you verify the actual IDE read/write fails
> with current HEAD?
> 
> Regards,
> Bin
> 

Hello Bin,

I have not checked block level read but used the shell commands for testing.

Before the patch I can read the directory of the drive:

=> ide info
Device 0: Model: QEMU HARDDISK  Firm: 2.5+ Ser#: QM1
Type: Hard Disk
Supports 48-bit addressing
Capacity: 128.0 MB = 0.1 GB (262144 x 512)
Device 2: Model: QEMU Firm: 2.5+ Ser#: QEMU DVD-ROM
Type: Removable CD ROM
Capacity: not available
=> fat2ls ide 0:1
Unknown command 'fat2ls' - try 'help'
=> fatls ide 0:1
   164768   snp.efi
0   file1
0   file2


After the patch (including HEAD) I cannot read the directory and cannot
load the file snp.efi either:

=> ide info
=> fatls ide 0:1
** Bad device ide 0 **
=>
=> fatls mmc 0:1
** Bad device mmc 0 **


In both cases I have loaded the same image with:

export BUILD_ROM=y
make distclean && make qemu-x86_defconfig && make -j6

qemu-system-x86_64 -m 1G -bios u-boot.rom -nographic \
-netdev \
user,id=eth0,tftp=tftp,net=192.168.76.0/24,dhcpstart=192.168.76.9 \
-device e1000,netdev=eth0 -machine pc-i440fx-2.8 -hda img

Best regards

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

Re: [U-Boot] [PATCH v3 0/8] sf: improve support of (Q)SPI flash memories

[Bin Meng]

On Wed, Aug 30, 2017 at 11:25 AM, Yang, Wenyou
 wrote:
>
>
> On 2017/8/26 14:34, Jagan Teki wrote:
>>
>> Hi,
>>
>> Thanks for the changes.
>>
>> On Tue, Jul 25, 2017 at 12:30 PM, Wenyou Yang 
>> wrote:
>>>
>>> This series of patches are based and have been tested on the 'master'
>>> branch of the u-boot.git tree.
>>>
>>> Tests were passed with a sama5d2 xplained board which embeds both SPI and
>>> QSPI controllers.
>>>
>>> The following tests have been passed:
>>>
>>> - QSPI0 + Macronix MX25L25673G:
>>>+ probe: OK
>>>+ Fast Read 1-1-4 at offset 0x1 (u-boot env): OK
>>>+ Page Program 1-1-4 at offset 0x1: OK
>>>  The Macronix datasheet tells that only Page Program 1-4-4 is
>>>  supported, not Page Program 1-1-4, however it worked, I don't know
>>>  why...
>>>
>>> - QSPI0 + Microchip SST26
>>>+ probe: OK
>>>+ Fast Read 1-1-4 at offset 0x1 (u-boot env): OK
>>>+ Page Program 1-1-1 at offset 0x1: OK
>>>  SST26 memories support Page Program 1-4-4 but with the op code of
>>>  Page Program 1-1-4, which is not standard so I don't use it.
>>>
>>> - QSPI0 + Adesto AT25DF321A
>>>+ probe: OK
>>>+ Fast Read 1-1-1 at offset 0x1 (u-boot env): OK
>>>+ Page Program 1-1-1 at offset 0x1: OK
>>>
>>> - SPI0 + Adesto AT25DF321A
>>>+ probe: OK
>>>+ Fast Read 1-1-1 at offset 0x6000 (u-boot env): OK
>>>+ Page Program 1-1-1 at offest 0x6000: OK
>>>
>>> - SPI1 + Atmel AT45
>>>+ probe: OK
>>>+ Read at offset 0 and other than 0: OK
>>>+ Write at offset 0 and other than 0: OK
>>>
>>> During my tests, I used:
>>>- setenv/saveenv, reboot, printenv
>>>or
>>>- sf probe, sf read, sf write, sf erase and sf update.
>>>
>>> Changes in v3:
>>>   - Add the include  to fix build error for corvus_defconfig.
>>>
>>> Changes in v2:
>>>   - Rebase on the latest u-boot/master(2710d54f5).
>>>
>>> Cyrille Pitchen (8):
>>>spi: add support of SPI flash commands
>>>sf: describe all SPI flash commands with 'struct spi_flash_command'
>>>sf: select the relevant SPI flash protocol for read and write commands
>>>sf: differentiate Page Program 1-1-4 and 1-4-4
>>>sf: add 'addr_len' member to 'struct spi_flash'
>>>sf: add new option to support SPI flash above 16MiB
>>>sf: add support to Microchip SST26 QSPI memories
>>>sf: add driver for Atmel QSPI controller
>>
>> Comments:
>> How about writing struct spi_flash_command in spi_flash area
>> (include/spi_flash.h)? and then write atmel_qspi with
>> UCLASS_SPI_FLASH?
>>
>> Testing:
>> Basic testing works fine.
>>
>> Issues:
>> - Build issue: with zynq_microzed_defconfig
>> drivers/mtd/spi/spi_flash.c: In function ‘spi_flash_scan’:
>> drivers/mtd/spi/spi_flash.c:1049:7: warning: variable ‘above_16MB’ set
>> but not used [-Wunused-but-set-variable]
>>bool above_16MB;
>> ^~
>>CC  spl/lib/membuff.o
>>
>> - issue with spi_flash_cmd_read_ops 4BAIS
>> Need to calculate bank length only if BAR is in use. Otherwise,
>> consider the given len as read_len.
>>
>> Will send separate patch for this.
>
> Will You send a separate patch? or I include it in this patch set?
>>

This should not be a separate patch. Since every patch needs to pass
buildman testing.

>> diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
>> index 89ceae2..b5d8ef3 100644
>> --- a/drivers/mtd/spi/spi_flash.c
>> +++ b/drivers/mtd/spi/spi_flash.c
>> @@ -558,13 +558,15 @@ int spi_flash_cmd_read_ops(struct spi_flash
>> *flash, u32 offset,
>>   if (ret < 0)
>>   return ret;
>>   bank_sel = flash->bank_curr;
>> -#endif
>>   remain_len = ((SPI_FLASH_16MB_BOUN << flash->shift) *
>>   (bank_sel + 1)) - offset;
>>   if (len < remain_len)
>>   read_len = len;
>>   else
>>   read_len = remain_len;
>> +#else
>> +read_len = len;
>> +#endif
>>
>>   cmd.addr = read_addr;
>>   cmd.data_len = read_len;
>>

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

Re: [U-Boot] [PATCH v3 0/8] sf: improve support of (Q)SPI flash memories

[Yang, Wenyou]

On 2017/8/26 14:34, Jagan Teki wrote:

Hi,

Thanks for the changes.

On Tue, Jul 25, 2017 at 12:30 PM, Wenyou Yang  wrote:

This series of patches are based and have been tested on the 'master'
branch of the u-boot.git tree.

Tests were passed with a sama5d2 xplained board which embeds both SPI and
QSPI controllers.

The following tests have been passed:

- QSPI0 + Macronix MX25L25673G:
   + probe: OK
   + Fast Read 1-1-4 at offset 0x1 (u-boot env): OK
   + Page Program 1-1-4 at offset 0x1: OK
 The Macronix datasheet tells that only Page Program 1-4-4 is
 supported, not Page Program 1-1-4, however it worked, I don't know
 why...

- QSPI0 + Microchip SST26
   + probe: OK
   + Fast Read 1-1-4 at offset 0x1 (u-boot env): OK
   + Page Program 1-1-1 at offset 0x1: OK
 SST26 memories support Page Program 1-4-4 but with the op code of
 Page Program 1-1-4, which is not standard so I don't use it.

- QSPI0 + Adesto AT25DF321A
   + probe: OK
   + Fast Read 1-1-1 at offset 0x1 (u-boot env): OK
   + Page Program 1-1-1 at offset 0x1: OK

- SPI0 + Adesto AT25DF321A
   + probe: OK
   + Fast Read 1-1-1 at offset 0x6000 (u-boot env): OK
   + Page Program 1-1-1 at offest 0x6000: OK

- SPI1 + Atmel AT45
   + probe: OK
   + Read at offset 0 and other than 0: OK
   + Write at offset 0 and other than 0: OK

During my tests, I used:
   - setenv/saveenv, reboot, printenv
   or
   - sf probe, sf read, sf write, sf erase and sf update.

Changes in v3:
  - Add the include  to fix build error for corvus_defconfig.

Changes in v2:
  - Rebase on the latest u-boot/master(2710d54f5).

Cyrille Pitchen (8):
   spi: add support of SPI flash commands
   sf: describe all SPI flash commands with 'struct spi_flash_command'
   sf: select the relevant SPI flash protocol for read and write commands
   sf: differentiate Page Program 1-1-4 and 1-4-4
   sf: add 'addr_len' member to 'struct spi_flash'
   sf: add new option to support SPI flash above 16MiB
   sf: add support to Microchip SST26 QSPI memories
   sf: add driver for Atmel QSPI controller

Comments:
How about writing struct spi_flash_command in spi_flash area
(include/spi_flash.h)? and then write atmel_qspi with
UCLASS_SPI_FLASH?

Testing:
Basic testing works fine.

Issues:
- Build issue: with zynq_microzed_defconfig
drivers/mtd/spi/spi_flash.c: In function ‘spi_flash_scan’:
drivers/mtd/spi/spi_flash.c:1049:7: warning: variable ‘above_16MB’ set
but not used [-Wunused-but-set-variable]
   bool above_16MB;
^~
   CC  spl/lib/membuff.o

- issue with spi_flash_cmd_read_ops 4BAIS
Need to calculate bank length only if BAR is in use. Otherwise,
consider the given len as read_len.

Will send separate patch for this.

Will You send a separate patch? or I include it in this patch set?

diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
index 89ceae2..b5d8ef3 100644
--- a/drivers/mtd/spi/spi_flash.c
+++ b/drivers/mtd/spi/spi_flash.c
@@ -558,13 +558,15 @@ int spi_flash_cmd_read_ops(struct spi_flash
*flash, u32 offset,
  if (ret < 0)
  return ret;
  bank_sel = flash->bank_curr;
-#endif
  remain_len = ((SPI_FLASH_16MB_BOUN << flash->shift) *
  (bank_sel + 1)) - offset;
  if (len < remain_len)
  read_len = len;
  else
  read_len = remain_len;
+#else
+read_len = len;
+#endif

  cmd.addr = read_addr;
  cmd.data_len = read_len;

thanks!


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

Re: [U-Boot] DA850evm SPI Flash Partitions between Linux and U-boot are Inconsistent

[Adam Ford]

On Tue, Aug 29, 2017 at 8:05 AM, Adam Ford  wrote:
> On Tue, Aug 29, 2017 at 6:41 AM, Sekhar Nori  wrote:
>> On Tuesday 29 August 2017 03:29 PM, Adam Ford wrote:
>>> On Tue, Aug 29, 2017 at 4:13 AM, Sekhar Nori  wrote:
 Hi Adam,

 On Sunday 27 August 2017 08:31 PM, Adam Ford wrote:
> I was trying to enable MTD Partitions to make loading the Kernel and
> FS easier from within U-Boot
>
> The da850evm spi-flash partitions in Linux show
>
> "U-Boot-SPL" @ offset 0, size 64K
> "U-Boot"; @ offset 0x0001, size 512K
> "U-Boot-Env"; @ offset 0x0009

 According to board/davinci/da8xxevm/README.da850, we support AIS image
 format for SPI boot. This is a single image containing SPL and U-Boot.

 Given this, I think having separate partitions for SPL and U-Boot does
 not make sense since thats not how its going to be used.
>>>
>>> That's what I was thinking too, but I wasn't sure if someone had split
>>> SPL somehow to make it possible to update U-Boot via Linux or U-Boot
>>> itself.

>
> However U-Boot shows the following:
>
> CONFIG_SYS_SPI_U_BOOT_OFFS 0x8000 which would make the SPL partition 32K.
> CONFIG_SYS_SPI_U_BOOT_SIZE  0x4 and the size of U-boot 256K
> instead of 512k.
>
> CONFIG_ENV_SIZE (64 << 10)
> CONFIG_ENV_OFFSET   (512 << 10) which is 0x8 instead of
> Linux's 0x9
>
> It seems to me like the U-Boot and Linux should try and synchronize
> their partitions tables.

 Right.

> For people who want to burn Linux into the SPI flash it seems there
> there should be some consistency.  I tried making the U-boot settings
> match the Linux ones, but it seems to hang between SPL and U-Boot, so
> I think the U-Boot offset in Linux might need to match U-Boot.  Can
> you guys make some recomendations as to which is correct?

 I have not tried it, but looks like the partitions we need are

 "SPL/U-Boot AIS" @ offset 0, size 512K
 "U-Boot Environment" @ offset 512K, size 64K
>>>
>>> I was thinking the same thing.
>>>
 "Kernel/Spare" @ offset 576K, size 7552K
 "Mac Address" @ offset 8128K, size 64K (read only)
>>>
>>> If U-Boot reads the MAC address from its environmental variables
>>> instead of using up an entire 64K for what conceivably is 6 bytes,
>>> could we free up this space to help grow the Kernel/Spare space?
>>
>> If environment sector is erased, the mac address needs to be restored
>> from SPI flash. Thats why I think it needs to remain as a read-only
>> partition. Also, its just 64K more space, not sure if it will make a big
>> difference in the overall scheme of things.
>>
 With an 8M flash, I think its futile to try to fit a modern filesystem
 on the flash.

 If you are using DT boot, we cannot really change the partitions in
 device-tree because of DT backward-compatibility requirements. But we
 can fix da850evm_spiflash_part[] table in
 arch/arm/mach-davinci/board-da850-evm.c.
>>>
>>> Wouldn't having two different partition tables between da850-evm.c and
>>> the DT cause confusion down the road?  With DT being the future, why
>>> would we not try to eliminate any custom board files with just a
>>> single common davinci board file + board specific DT?
>>
>> Thats ideal yes. But there is a lot of support in the da850-evm board
>> file which does not have a DT equivalent yet. Thats why I have kept the
>> board file around.
>>
 To help DT boot, we can pass fixed up mtdparts through environment
 variables. Something like what is done in 3f18ff07c81b ("ARM: keystone:
 Pass SPI MTD partition table via kernel command line").
>>>
>>> This was ultimately was I was wanting to do.  For some of the OMAP3
>>> boards, removing the partition tree was accepted since the partition
>>> info was passed to the kernel.  If we did this for DA850, we could
>>> simply elimiate the partition info in the Kernel (like some of the
>>> omap3 boards) and let the partition maps be defined by U-Boot would
>>> would guarantee consistency between them.
>>
>> Actually, thinking a bit more, we cannot change the partition
>> information in kernel at all since that means loss of data for anyone
>> updating just the kernel.
>>
>> We can however, pass updated kernel command line arguments in U-Boot so
>> anyone updating the bootloader and erasing the environment sector gets
>> updated partition information. This is likely to be the case where
>> entire flash is being re-written and loss of data is not a concern.
>>
> That makes sense to me.
>
> I'll send a U-Boot patch marked RFC later today with the MTD stuff
> enabled in U-Boot and changes to the bootargs to pass the MTD
> information to Linux.
>

I have a patch ready for review for U-Boot, but I had to make a few
changes to the davinci_all_defconfig to get the MTD 

Re: [U-Boot] [PATCH v3 0/8] sf: improve support of (Q)SPI flash memories

[Yang, Wenyou]

Hi Jagan,

On 2017/8/26 14:34, Jagan Teki wrote:

Hi,

Thanks for the changes.

On Tue, Jul 25, 2017 at 12:30 PM, Wenyou Yang  wrote:

This series of patches are based and have been tested on the 'master'
branch of the u-boot.git tree.

Tests were passed with a sama5d2 xplained board which embeds both SPI and
QSPI controllers.

The following tests have been passed:

- QSPI0 + Macronix MX25L25673G:
   + probe: OK
   + Fast Read 1-1-4 at offset 0x1 (u-boot env): OK
   + Page Program 1-1-4 at offset 0x1: OK
 The Macronix datasheet tells that only Page Program 1-4-4 is
 supported, not Page Program 1-1-4, however it worked, I don't know
 why...

- QSPI0 + Microchip SST26
   + probe: OK
   + Fast Read 1-1-4 at offset 0x1 (u-boot env): OK
   + Page Program 1-1-1 at offset 0x1: OK
 SST26 memories support Page Program 1-4-4 but with the op code of
 Page Program 1-1-4, which is not standard so I don't use it.

- QSPI0 + Adesto AT25DF321A
   + probe: OK
   + Fast Read 1-1-1 at offset 0x1 (u-boot env): OK
   + Page Program 1-1-1 at offset 0x1: OK

- SPI0 + Adesto AT25DF321A
   + probe: OK
   + Fast Read 1-1-1 at offset 0x6000 (u-boot env): OK
   + Page Program 1-1-1 at offest 0x6000: OK

- SPI1 + Atmel AT45
   + probe: OK
   + Read at offset 0 and other than 0: OK
   + Write at offset 0 and other than 0: OK

During my tests, I used:
   - setenv/saveenv, reboot, printenv
   or
   - sf probe, sf read, sf write, sf erase and sf update.

Changes in v3:
  - Add the include  to fix build error for corvus_defconfig.

Changes in v2:
  - Rebase on the latest u-boot/master(2710d54f5).

Cyrille Pitchen (8):
   spi: add support of SPI flash commands
   sf: describe all SPI flash commands with 'struct spi_flash_command'
   sf: select the relevant SPI flash protocol for read and write commands
   sf: differentiate Page Program 1-1-4 and 1-4-4
   sf: add 'addr_len' member to 'struct spi_flash'
   sf: add new option to support SPI flash above 16MiB
   sf: add support to Microchip SST26 QSPI memories
   sf: add driver for Atmel QSPI controller

Comments:
How about writing struct spi_flash_command in spi_flash area
(include/spi_flash.h)? and then write atmel_qspi with
UCLASS_SPI_FLASH?
The spi_flash_command struct describes the relevant features of the spi 
controller, instead of the spi_flash device.
The purpose of patch set is used to supersede the spi_xfer() function to 
access the spi_flash device.
So putting it in include/spi.h is suitable, we should not move it in the 
spi_flash area.


Moreover, why do we write atmel_qspi with  UCLASS_SPI_FLASH?  It is not 
easy to understand.


Testing:
Basic testing works fine.

Issues:
- Build issue: with zynq_microzed_defconfig
drivers/mtd/spi/spi_flash.c: In function ‘spi_flash_scan’:
drivers/mtd/spi/spi_flash.c:1049:7: warning: variable ‘above_16MB’ set
but not used [-Wunused-but-set-variable]
   bool above_16MB;


Will send a new version to fix it.  Thanks a lot.


^~
   CC  spl/lib/membuff.o

- issue with spi_flash_cmd_read_ops 4BAIS
Need to calculate bank length only if BAR is in use. Otherwise,
consider the given len as read_len.

Will send separate patch for this.

diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
index 89ceae2..b5d8ef3 100644
--- a/drivers/mtd/spi/spi_flash.c
+++ b/drivers/mtd/spi/spi_flash.c
@@ -558,13 +558,15 @@ int spi_flash_cmd_read_ops(struct spi_flashmake
*flash, u32 offset,
  if (ret < 0)
  return ret;
  bank_sel = flash->bank_curr;
-#endif
  remain_len = ((SPI_FLASH_16MB_BOUN << flash->shift) *
  (bank_sel + 1)) - offset;
  if (len < remain_len)
  read_len = len;
  else
  read_len = remain_len;
+#else
+read_len = len;
+#endif

  cmd.addr = read_addr;
  cmd.data_len = read_len;
thanks!


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

Re: [U-Boot] ** Can't read Driver Desriptor Block **

[Bin Meng]

Hi Heinrich,

On Wed, Aug 30, 2017 at 4:26 AM, Heinrich Schuchardt  wrote:
> Hello Simon,
>
> U-Boot HEAD qemu-86_defconfig cannot discover an IDE disk with one FAT
> partition in qemu-system-x86_64.
>
> By bisection I found this patch.
>
> b7c6baef2891ce8978cbfddb66e944943473ac21
> x86: Convert MMC to driver model
>
> With this patch I get
>
> IDE:   Bus 0: OK Bus 1: OK
>   Device 0: Model: QEMU HARDDISK  Firm: 2.5+ Ser#: QM1
> Type: Hard Disk
> Supports 48-bit addressing
> Capacity: 128.0 MB = 0.1 GB (262144 x 512)
> ** Can't read Driver Desriptor Block **
>   Device 1: not available
>   Device 2: Model: QEMU Firm: 2.5+ Ser#: QEMU DVD-ROM
> Type: Removable CD ROM
> Capacity: not available
>   Device 3: not available
>
> => ide info
> =>
>
> Without the patch I get=> ide info
> Device 0: Model: QEMU HARDDISK  Firm: 2.5+ Ser#: QM1
> Type: Hard Disk
> Supports 48-bit addressing
> Capacity: 128.0 MB = 0.1 GB (262144 x 512)
> Device 2: Model: QEMU Firm: 2.5+ Ser#: QEMU DVD-ROM
> Type: Removable CD ROM
> Capacity: not available
>
> I think we observe two independent errors here:
>
> - The hard disk Device 0 is not read.
> - The ide command stops at the first device that is not available.
>
> I guess only the first is caused by your patch.

Both logs look fine to me. The "Can't read Driver Desriptor Block"
comes from part_mac.c. Did you verify the actual IDE read/write fails
with current HEAD?

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

Re: [U-Boot] undefined reference to `environment'

[Bin Meng]

On Wed, Aug 30, 2017 at 6:07 AM, Thomas Petazzoni
 wrote:
> Hello,
>
> On Tue, 29 Aug 2017 17:18:24 -0400, Tom Rini wrote:
>
>> So there's something extra funny going on in the linking.  See
>> https://patchwork.ozlabs.org/patch/806263/ which I have included, but
>> haven't been able to push out.
>
> At this point, I don't think it's the correct fix. I don't see why it
> should be the responsibility of the linker script to include
> env/embedded.o. Almost no other architecture has env/embedded.o
> referenced in its linker script. Only a few m68k platforms, with custom
> linker script in their include/configs/.h file include env/embedded.o
> in their linker script, plus one Freescale platform.
>
> Again, changing extra- to obj- in env/Makefile also fixes the issue.

Yep, looks to me obj- is the correct way to fix.

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

[U-Boot] [PATCH 4/4] sunxi: dts: added emac node for nanopi m1 plus

[Philipp Rossak]

From: Philipp Rossak 

The sun8i emac hardware is present on the Nanopi M1.
It uses an external PHY.

Signed-off-by: Philipp Rossak 
---
 arch/arm/dts/sun8i-h3-nanopi-m1-plus.dts | 30 ++
 1 file changed, 30 insertions(+)

diff --git a/arch/arm/dts/sun8i-h3-nanopi-m1-plus.dts 
b/arch/arm/dts/sun8i-h3-nanopi-m1-plus.dts
index 8ddd1b2..1cc9185 100644
--- a/arch/arm/dts/sun8i-h3-nanopi-m1-plus.dts
+++ b/arch/arm/dts/sun8i-h3-nanopi-m1-plus.dts
@@ -45,6 +45,18 @@
 / {
model = "FriendlyArm NanoPi M1 Plus";
compatible = "friendlyarm,nanopi-m1-plus", "allwinner,sun8i-h3";
+
+   reg_gmac_3v3: gmac-3v3 {
+   compatible = "regulator-fixed";
+   pinctrl-names = "default";
+   pinctrl-0 = <_power_pin_nanopi_m1_plus>;
+   regulator-name = "gmac-3v3";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   startup-delay-us = <10>;
+   enable-active-high;
+   gpio = < 3 6 GPIO_ACTIVE_HIGH>;
+   };
 };
 
  {
@@ -55,6 +67,15 @@
status = "okay";
 };
 
+ {
+   /* The Nanopi M1 Plus uses an external phy */
+   pinctrl-names = "default";
+   pinctrl-0 = <_rgmii_pins>;
+   phy-supply = <_gmac_3v3>;
+   phy-mode = "rgmii";
+   /delete-property/allwinner,use-internal-phy;
+};
+
  {
status = "okay";
 };
@@ -62,3 +83,12 @@
  {
status = "okay";
 };
+
+ {
+   gmac_power_pin_nanopi_m1_plus: gmac_power_pin@0 {
+   allwinner,pins = "PD6";
+   allwinner,function = "gpio_out";
+   allwinner,drive = ;
+   allwinner,pull = ;
+   };
+};
-- 
2.7.4

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

[U-Boot] [PATCH 1/4] sunxi: defconfig: enable sun8i emac on nanopi m1

[Philipp Rossak]

From: Philipp Rossak 

The sun8i emac hardware is present on the Nanopi M1.
It uses the internal PHY.

Signed-off-by: Philipp Rossak 
---
 configs/nanopi_m1_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/nanopi_m1_defconfig b/configs/nanopi_m1_defconfig
index 498496b..6ac8968 100644
--- a/configs/nanopi_m1_defconfig
+++ b/configs/nanopi_m1_defconfig
@@ -14,3 +14,4 @@ CONFIG_SPL=y
 # CONFIG_SPL_ISO_PARTITION is not set
 # CONFIG_SPL_EFI_PARTITION is not set
 CONFIG_USB_EHCI_HCD=y
+CONFIG_SUN8I_EMAC=y
-- 
2.7.4

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

[U-Boot] [PATCH 2/4] sunxi: defconfig: enable sun8i emac on nanopi m1 plus

[Philipp Rossak]

From: Philipp Rossak 

The sun8i emac hardware is present on the Nanopi M1.
It uses an external PHY. Pin PD6 is used to enable
the external PHY.

Signed-off-by: Philipp Rossak 
---
 configs/nanopi_m1_plus_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/configs/nanopi_m1_plus_defconfig b/configs/nanopi_m1_plus_defconfig
index d7a908d..e696ce3 100644
--- a/configs/nanopi_m1_plus_defconfig
+++ b/configs/nanopi_m1_plus_defconfig
@@ -4,6 +4,7 @@ CONFIG_MACH_SUN8I_H3=y
 CONFIG_DRAM_CLK=408
 CONFIG_DRAM_ZQ=3881979
 CONFIG_DRAM_ODT_EN=y
+CONFIG_MACPWR="PD6"
 CONFIG_MMC0_CD_PIN="PH13"
 CONFIG_MMC_SUNXI_SLOT_EXTRA=2
 CONFIG_DEFAULT_DEVICE_TREE="sun8i-h3-nanopi-m1-plus"
@@ -16,3 +17,4 @@ CONFIG_SPL=y
 # CONFIG_SPL_ISO_PARTITION is not set
 # CONFIG_SPL_EFI_PARTITION is not set
 CONFIG_USB_EHCI_HCD=y
+CONFIG_SUN8I_EMAC=y
-- 
2.7.4

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

[U-Boot] [PATCH 3/4] sunxi: dts: added emac node for nanopi m1

[Philipp Rossak]

From: Philipp Rossak 

The sun8i emac hardware is present on the Nanopi M1.
It uses the internal PHY.

Signed-off-by: Philipp Rossak 
---
 arch/arm/dts/sun8i-h3-nanopi-m1.dts | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm/dts/sun8i-h3-nanopi-m1.dts 
b/arch/arm/dts/sun8i-h3-nanopi-m1.dts
index ec63d10..9c1c380 100644
--- a/arch/arm/dts/sun8i-h3-nanopi-m1.dts
+++ b/arch/arm/dts/sun8i-h3-nanopi-m1.dts
@@ -55,6 +55,17 @@
status = "okay";
 };
 
+ {
+   phy = <>;
+   phy-mode = "mii";
+   allwinner,use-internal-phy;
+   allwinner,leds-active-low;
+   status = "okay";
+   phy1: ethernet-phy@1 {
+   reg = <1>;
+   };
+};
+
  {
status = "okay";
 };
-- 
2.7.4

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

[U-Boot] [PATCH 0/4] Enable ethernet on nanopi m1 and nanopi m1 plus

[Philipp Rossak]

From: Philipp Rossak 

This Patchseries enables the ethernet for the Friendlyarm Nanopi M1 and 
the Friendlyarm Nanopi M1 Plus.

Philipp Rossak (4):
  sunxi: defconfig: enable sun8i emac on nanopi m1
  sunxi: defconfig: enable sun8i emac on nanopi m1 plus
  sunxi: dts: added emac node for nanopi m1
  sunxi: dts: added emac node for nanopi m1 plus

 arch/arm/dts/sun8i-h3-nanopi-m1-plus.dts | 30 ++
 arch/arm/dts/sun8i-h3-nanopi-m1.dts  | 11 +++
 configs/nanopi_m1_defconfig  |  1 +
 configs/nanopi_m1_plus_defconfig |  2 ++
 4 files changed, 44 insertions(+)

-- 
2.7.4

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

[U-Boot] [GIT PULL] u-boot-uniphier/master

[Masahiro Yamada]

Hi Tom,

Here is a bit volume pull request, but changes
are SoC-specific except the ofnode patch and denali_dt.
The latter is reviewed by Simon.

- add {ofnode,dev}_read_resource_byname
- provide DT probe hook to Denali NAND driver
- update clk/reset driver
- update DT
- misc cleanups



The following changes since commit 8b3cec7da18645eda7f7cd0b65ee9f2dac573409:

  mtdparts: Fix uninitialized scalar usage (2017-08-26 16:59:24 -0400)

are available in the git repository at:

  git://git.denx.de/u-boot-uniphier.git master

for you to fetch changes up to 0cc0c544bc317548885721d2312c90185642f98c:

  ARM: uniphier: enable Denali NAND driver for 64bit SoCs (2017-08-30
09:07:04 +0900)


Dai Okamura (1):
  ARM: uniphier: fix DSPLL init code for LD20 SoC

Masahiro Yamada (16):
  ofnode: add {ofnode, dev}_read_resource_byname()
  mtd: nand: denali_dt: add a DT driver
  ARM: uniphier: replace  with  in pll settings
  ARM: uniphier: move PLLCTRL register macros to each SoC .c file
  ARM: uniphier: add PLL settings for PXs3
  ARM: uniphier: remove unneeded NAND config options
  ARM: uniphier: enable CONFIG_NAND_DENALI_DT
  ARM: uniphier: remove ad-hoc pin settings for NAND
  clk: uniphier: add System clock support
  reset: uniphier: fix compatible for SD reset node for LD11/LD20
  reset: uniphier: add PXs3 support
  ARM: dts: uniphier: sync with Linux
  ARM: dts: uniphier: update PXs3 SoC/board DT
  ARM: uniphier: move CONFIG_NAND to defconfig
  ARM: uniphier: set system bus pinmux for PXs3
  ARM: uniphier: enable Denali NAND driver for 64bit SoCs

 arch/arm/dts/uniphier-ld11-global.dts  |   6 +-
 arch/arm/dts/uniphier-ld11-ref.dts |   6 +-
 arch/arm/dts/uniphier-ld11.dtsi|  13 ++-
 arch/arm/dts/uniphier-ld20-global.dts  |   6 +-
 arch/arm/dts/uniphier-ld20-ref.dts |   6 +-
 arch/arm/dts/uniphier-ld20.dtsi|  15 ++-
 arch/arm/dts/uniphier-ld4-ref.dts  |   6 +-
 arch/arm/dts/uniphier-ld4.dtsi |  11 +-
 arch/arm/dts/uniphier-ld6b-ref.dts |   6 +-
 arch/arm/dts/uniphier-ld6b.dtsi|   2 +-
 arch/arm/dts/uniphier-pinctrl.dtsi |   5 +
 arch/arm/dts/uniphier-pro4-ace.dts |   2 +-
 arch/arm/dts/uniphier-pro4-ref.dts |   6 +-
 arch/arm/dts/uniphier-pro4-sanji.dts   |   2 +-
 arch/arm/dts/uniphier-pro4.dtsi|   9 +-
 arch/arm/dts/uniphier-pro5-4kbox.dts   |   4 +-
 arch/arm/dts/uniphier-pro5.dtsi|  13 ++-
 arch/arm/dts/uniphier-pxs2-gentil.dts  |   2 +-
 arch/arm/dts/uniphier-pxs2-vodka.dts   |   2 +-
 arch/arm/dts/uniphier-pxs2.dtsi|  13 ++-
 arch/arm/dts/uniphier-pxs3-ref.dts |  29 -
 arch/arm/dts/uniphier-pxs3.dtsi| 163 +++
 arch/arm/dts/uniphier-sld8-ref.dts |   6 +-
 arch/arm/dts/uniphier-sld8.dtsi|  11 +-
 arch/arm/mach-uniphier/Kconfig |   1 -
 arch/arm/mach-uniphier/board_init.c|  28 +
 arch/arm/mach-uniphier/clk/pll-base-ld20.c |   6 +-
 arch/arm/mach-uniphier/clk/pll-ld11.c  |  13 ++-
 arch/arm/mach-uniphier/clk/pll-ld20.c  |  21 +++-
 arch/arm/mach-uniphier/clk/pll-pxs3.c  |  55 +
 arch/arm/mach-uniphier/sbc/sbc-pxs2.c  |   2 +
 arch/arm/mach-uniphier/sc64-regs.h |  21 
 configs/uniphier_ld4_sld8_defconfig|   2 +
 configs/uniphier_pro4_defconfig|   2 +
 configs/uniphier_pxs2_ld6b_defconfig   |   2 +
 configs/uniphier_v8_defconfig  |   5 +
 drivers/clk/uniphier/Makefile  |   1 +
 drivers/clk/uniphier/clk-uniphier-core.c   |  30 +
 drivers/clk/uniphier/clk-uniphier-sys.c|  34 ++
 drivers/clk/uniphier/clk-uniphier.h|   2 +
 drivers/core/ofnode.c  |  12 ++
 drivers/core/read.c|   6 +
 drivers/mtd/nand/Kconfig   |   7 ++
 drivers/mtd/nand/Makefile  |   1 +
 drivers/mtd/nand/denali.c  |   4 +-
 drivers/mtd/nand/denali.h  |   2 +
 drivers/mtd/nand/denali_dt.c   |  68 +++
 drivers/reset/reset-uniphier.c |  29 -
 include/configs/uniphier.h |   3 -
 include/dm/ofnode.h|   2 +
 include/dm/read.h  |  20 +++-
 51 files changed, 554 insertions(+), 169 deletions(-)
 create mode 100644 drivers/clk/uniphier/clk-uniphier-sys.c
 create mode 100644 drivers/mtd/nand/denali_dt.c


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

Re: [U-Boot] [PATCH] ARM: uniphier: move CONFIG_NAND to defconfig

[Masahiro Yamada]

2017-08-29 15:41 GMT+09:00 Masahiro Yamada :
> This imply was added when the option was moved by the moveconfig tool,
> but the intention is not clear.  Move it to defconfig.
>
> Signed-off-by: Masahiro Yamada 
> ---

Applied to u-boot-uniphier.

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

Re: [U-Boot] [PATCH] ARM: uniphier: enable Denali NAND driver for 64bit SoCs

[Masahiro Yamada]

2017-08-30 1:04 GMT+09:00 Masahiro Yamada :
> Now the entry to the NAND driver init can be is controlled by DT;
> it should not hurt to compile the driver all the time.
>
> Signed-off-by: Masahiro Yamada 
> ---

Applied to u-boot-uniphier.

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

Re: [U-Boot] [PATCH] ARM: uniphier: set system bus pinmux for PXs3

[Masahiro Yamada]

2017-08-29 15:42 GMT+09:00 Masahiro Yamada :
> The system bus is not enabled by default for NAND, eMMC boot
> etc. of PXs3.
>
> Signed-off-by: Masahiro Yamada 

Series, applied to u-boot-uniphier.

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

Re: [U-Boot] [PATCH 1/4] reset: uniphier: fix compatible for SD reset node for LD11/LD20

[Masahiro Yamada]

2017-08-29 12:20 GMT+09:00 Masahiro Yamada :
> LD20 has SD ctrl instead of MIO ctrl.  LD11 has both of them.
>
> Signed-off-by: Masahiro Yamada 
> ---

Series, applied to u-boot-uniphier.


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

Re: [U-Boot] [PATCH 0/2] Add denali DT driver

[Masahiro Yamada]

2017-08-26 1:12 GMT+09:00 Masahiro Yamada :
> 1/2 is required for 2/2.
> Denali NAND controller has two reg regions named "nand_data" and "denali_reg"
> as described by Documentation/devicetree/bindings/mtd/denali-nand.txt
>
>
>
> Masahiro Yamada (2):
>   ofnode: add {ofnode,dev}_read_resource_byname()
>   mtd: nand: denali_dt: add a DT driver
>

Both applied to u-boot-uniphier.

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

Re: [U-Boot] [PATCH 0/6] ARM: uniphier: update PLL settings and clean-up NAND settings

[Masahiro Yamada]

2017-08-26 17:57 GMT+09:00 Masahiro Yamada :
>
> 1-3: update PLL init code
> 4-6: clean up NAND adhoc code (the last two are only applicable
>  after the Denali DT driver is applied.)
>  http://patchwork.ozlabs.org/patch/805959/
>

Series, applied.




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

Re: [U-Boot] undefined reference to `environment'

[Thomas Petazzoni]

Hello,

On Tue, 29 Aug 2017 17:18:24 -0400, Tom Rini wrote:

> So there's something extra funny going on in the linking.  See
> https://patchwork.ozlabs.org/patch/806263/ which I have included, but
> haven't been able to push out.

At this point, I don't think it's the correct fix. I don't see why it
should be the responsibility of the linker script to include
env/embedded.o. Almost no other architecture has env/embedded.o
referenced in its linker script. Only a few m68k platforms, with custom
linker script in their include/configs/.h file include env/embedded.o
in their linker script, plus one Freescale platform.

Again, changing extra- to obj- in env/Makefile also fixes the issue.

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 00/23] efi_loader implement missing functions

[Heinrich Schuchardt]

On 08/29/2017 10:38 PM, Alexander Graf wrote:
> 
> 
>> Am 29.08.2017 um 22:16 schrieb Simon Glass :
>>
>> Hi,
>>
>>> On 29 August 2017 at 22:16, Rob Clark  wrote:
 On Tue, Aug 29, 2017 at 8:57 AM, Leif Lindholm  
 wrote:
 On Tue, Aug 29, 2017 at 02:26:48PM +0200, Alexander Graf wrote:
 I would add command
 bootefi selftest.efi
 to run the tests and provide the python wrapper code to add it to the
 test suite.
>>>
>>> I think that's a great idea, yes.
>> I wonder how far we are from running UEFI tests (either the official
>> ones, or I seem to remember hearing about some other test suite which
>> didn't require UEFI shell)?
>
> Let's ask Leif, Ard and Dong.
>
> The official test suite definitely needs the UEFI Shell. Is the suite
> publicly available by now?

 In binary form, you can access it already from the links on
 http://uefi.org/testtools

 Yes, 2.5 is latest release. No this is not a restriction ... the SCT
 releases have been lagging the specification releases a fair bit.

 The 2.5a package contains AARCH64, IA32 and X64 support (not ARM).
 Not that it couldn't contain ARM, it just hasn't been packaged.

>> That seems more useful long term than re-inventing comprehensive UEFI
>> test suite.  (Also, beyond just running shim/fallback/grub, I don't
>> really have time to invent new tests for the stack of efi_loader
>> patches I have.)
>
> Yes and no - it depends on the availability of the official suite :/.

 UEFI SCT is not yet open source/free software. Obviously, this is
 something Linaro has been lobbying for since day one of our
 involvement. There used to be little understanding for this, but that
 attitude has shifted substantially.
>>>
>>> So, if/until UEFI SCT is not an option, what about:
>>>
>>>  https://01.org/linux-uefi-validation
>>>
>>> (thx to pjones for pointing that out to me)
>>
>> Well in any case I'm not looking for a large functional test suite at
>> this stage. It certainly could be useful, but not as a replacement for
>> unit tests. The latter is for fast verification (so that everyone can
>> run it as part of 'make tests') and easy identification of the
>> location of bugs.
> 
> I fail to see the point here to be honest. The thing we care most about in 
> the uefi implementation is abi compatibility with the spec. That's basically 
> what SCT is supposed to get you. Running it should be a matter of seconds 
> with kvm enabled, so 'make tests' should easily be able to run it if you have 
> the correct target compiled.
> 
>>
>> These new tests should be written in C, run very quickly (similar to
>> the existing tests) to verify that the code works. Then when each new
>> feature is added, the test are expanded to cover the new
>> functionality. Should the code be refactored, the tests should provide
>> comfort that nothing broke.
> 
> So far I've never seen that approach work well in (low level) open source 
> projects, as you start to heavily raise the barrier for participation. Most 
> people in this world do these tasks in their spare time and won't spend x2 
> the time to also write and update unit tests.
> 
> I really think having a working functional test suite that is easy to run is 
> the best way forward in this case. We can then start thinking of ways to test 
> hard to reach code sections to increase test coverage.
> 
> 
> Alex

Simon is right in that test code is needed to ensure that refactoring
does not break existing functionality. The current git HEAD cannot read
from an IDE disk anymore. This problem could have been caught by a
functional test four weeks ago.

Unit tests should be based on exposed APIs. Tests for lower level
functions would not survive refactoring.

We implement only part of the UEFI spec. If we do not want to blow up
binary size we may even want to keep it that way. So a test suite for
full UEFI compatibility will always fail partially if it runs at all.

I am able to provide a test application that will cover the API
functions that I have focused on (events, protocols, (dis)connect
controllers). To limit my effort I would like to write it for the HEAD
of my patch queue and not break it down into one test patch per
implementation patch. I hope that is ok for you. My effort estimate is
40h+ so, please, be patient.

I would be happy to receive some review for the queued patches in the
meanwhile.

Best regards

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

[U-Boot] [PATCH v2] patman: add support for omitting bouncing addresses

[Chris Packham]

Add support for reading a list of bouncing addresses from a in-tree file
(doc/bounces) and from the ~/.patman config file. These addresses are
stripped from the Cc list.

Signed-off-by: Chris Packham 
---
This version supports an in-tree doc/bounces file as well as a section
in the .patman config file. A slight annoyance is the config file parser
expects key: value pairs whereas the bounces file is just a flat list. I
started looking a modeling this after the aliases but then I actually
thought that if we do want to tag someone as a bouncing address we
probably want to be explicit about it.

Changes in v2:
- better integration with existing configuration
- documentation

 doc/bounces  |  3 +++
 tools/patman/README  | 12 
 tools/patman/series.py   |  2 ++
 tools/patman/settings.py | 18 ++
 4 files changed, 35 insertions(+)
 create mode 100644 doc/bounces

diff --git a/doc/bounces b/doc/bounces
new file mode 100644
index ..d1c5f0d246eb
--- /dev/null
+++ b/doc/bounces
@@ -0,0 +1,3 @@
+# List of addresses picked up by patman/get_maintainer.pl that are known to
+# bounce. Addresses are listed one per line and need to match the author
+# information recorded in git.
diff --git a/tools/patman/README b/tools/patman/README
index e36857dedea1..8582ed6ba12c 100644
--- a/tools/patman/README
+++ b/tools/patman/README
@@ -84,6 +84,18 @@ Aliases are recursive.
 The checkpatch.pl in the U-Boot tools/ subdirectory will be located and
 used. Failing that you can put it into your path or ~/bin/checkpatch.pl
 
+If you want to avoid sending patches to email addresses that are picked up
+by patman but are known to bounce you can add a [bounces] section to your
+.patman file. Unlike the [alias] section these are simple key: value pairs
+that are not recursive.
+
+>>>
+
+[bounces]
+gonefishing: Fred Bloggs 
+
+<<<
+
 
 If you want to change the defaults for patman's command-line arguments,
 you can add a [settings] section to your .patman file.  This can be used
diff --git a/tools/patman/series.py b/tools/patman/series.py
index d3947a7c2ac5..ddc0993d9eac 100644
--- a/tools/patman/series.py
+++ b/tools/patman/series.py
@@ -10,6 +10,7 @@ import os
 
 import get_maintainer
 import gitutil
+import settings
 import terminal
 
 # Series-xxx tags that we understand
@@ -233,6 +234,7 @@ class Series(dict):
 cc += add_maintainers
 elif add_maintainers:
 cc += get_maintainer.GetMaintainer(commit.patch)
+cc = set(cc) - set(settings.bounces)
 cc = [m.encode('utf-8') if type(m) != str else m for m in cc]
 all_ccs += cc
 print(commit.patch, ', '.join(set(cc)), file=fd)
diff --git a/tools/patman/settings.py b/tools/patman/settings.py
index 5f207f5ef1c4..d735ff9ba3c6 100644
--- a/tools/patman/settings.py
+++ b/tools/patman/settings.py
@@ -269,6 +269,19 @@ def _ReadAliasFile(fname):
 if bad_line:
 print(bad_line)
 
+def _ReadBouncesFile(fname):
+"""Read in the bounces file if it exists
+
+Args:
+fname: Filename to read.
+"""
+if os.path.exists(fname):
+with open(fname) as fd:
+for line in fd:
+if line.startswith('#'):
+continue
+bounces.add(line.strip())
+
 def Setup(parser, project_name, config_fname=''):
 """Set up the settings module by reading config files.
 
@@ -293,10 +306,15 @@ def Setup(parser, project_name, config_fname=''):
 for name, value in config.items('alias'):
 alias[name] = value.split(',')
 
+_ReadBouncesFile('doc/bounces')
+for name, value in config.items('bounces'):
+bounces.add(value)
+
 _UpdateDefaults(parser, config)
 
 # These are the aliases we understand, indexed by alias. Each member is a list.
 alias = {}
+bounces = set()
 
 if __name__ == "__main__":
 import doctest
-- 
2.14.1

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

Re: [U-Boot] undefined reference to `environment'

[Tom Rini]

On Tue, Aug 29, 2017 at 4:50 PM, Thomas Petazzoni
 wrote:
> Hello,
>
> On Wed, 30 Aug 2017 04:16:39 +0800, Simon Glass wrote:
>
>> A bisect shows this came in with:
>>
>> f40ad66f (refs/bisect/bad) arch/sh: don't bring common/env_embedded.o
>> into the link
>>
>> Thomas, could you please take a look?
>
> env/embedded.o is missing in the link. It is added to extra-y by:
>
> extra-$(CONFIG_ENV_IS_IN_FLASH) += embedded.o
>
> I dumped extra-y right after this line, and it does contain embedded.o.
> However, it does not get added to the link stage.
>
> Why is this an extra-$() rather than an obj-$() ?

So there's something extra funny going on in the linking.  See
https://patchwork.ozlabs.org/patch/806263/ which I have included, but
haven't been able to push out.

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

Re: [U-Boot] undefined reference to `environment'

[Thomas Petazzoni]

Hello,

On Wed, 30 Aug 2017 04:16:39 +0800, Simon Glass wrote:

> A bisect shows this came in with:
> 
> f40ad66f (refs/bisect/bad) arch/sh: don't bring common/env_embedded.o
> into the link
> 
> Thomas, could you please take a look?

env/embedded.o is missing in the link. It is added to extra-y by:

extra-$(CONFIG_ENV_IS_IN_FLASH) += embedded.o

I dumped extra-y right after this line, and it does contain embedded.o.
However, it does not get added to the link stage.

Why is this an extra-$() rather than an obj-$() ?

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 00/23] efi_loader implement missing functions

[Alexander Graf]

> Am 29.08.2017 um 22:16 schrieb Simon Glass :
> 
> Hi,
> 
>> On 29 August 2017 at 22:16, Rob Clark  wrote:
>>> On Tue, Aug 29, 2017 at 8:57 AM, Leif Lindholm  
>>> wrote:
>>> On Tue, Aug 29, 2017 at 02:26:48PM +0200, Alexander Graf wrote:
>>> I would add command
>>> bootefi selftest.efi
>>> to run the tests and provide the python wrapper code to add it to the
>>> test suite.
>> 
>> I think that's a great idea, yes.
> I wonder how far we are from running UEFI tests (either the official
> ones, or I seem to remember hearing about some other test suite which
> didn't require UEFI shell)?
 
 Let's ask Leif, Ard and Dong.
 
 The official test suite definitely needs the UEFI Shell. Is the suite
 publicly available by now?
>>> 
>>> In binary form, you can access it already from the links on
>>> http://uefi.org/testtools
>>> 
>>> Yes, 2.5 is latest release. No this is not a restriction ... the SCT
>>> releases have been lagging the specification releases a fair bit.
>>> 
>>> The 2.5a package contains AARCH64, IA32 and X64 support (not ARM).
>>> Not that it couldn't contain ARM, it just hasn't been packaged.
>>> 
> That seems more useful long term than re-inventing comprehensive UEFI
> test suite.  (Also, beyond just running shim/fallback/grub, I don't
> really have time to invent new tests for the stack of efi_loader
> patches I have.)
 
 Yes and no - it depends on the availability of the official suite :/.
>>> 
>>> UEFI SCT is not yet open source/free software. Obviously, this is
>>> something Linaro has been lobbying for since day one of our
>>> involvement. There used to be little understanding for this, but that
>>> attitude has shifted substantially.
>> 
>> So, if/until UEFI SCT is not an option, what about:
>> 
>>  https://01.org/linux-uefi-validation
>> 
>> (thx to pjones for pointing that out to me)
> 
> Well in any case I'm not looking for a large functional test suite at
> this stage. It certainly could be useful, but not as a replacement for
> unit tests. The latter is for fast verification (so that everyone can
> run it as part of 'make tests') and easy identification of the
> location of bugs.

I fail to see the point here to be honest. The thing we care most about in the 
uefi implementation is abi compatibility with the spec. That's basically what 
SCT is supposed to get you. Running it should be a matter of seconds with kvm 
enabled, so 'make tests' should easily be able to run it if you have the 
correct target compiled.

> 
> These new tests should be written in C, run very quickly (similar to
> the existing tests) to verify that the code works. Then when each new
> feature is added, the test are expanded to cover the new
> functionality. Should the code be refactored, the tests should provide
> comfort that nothing broke.

So far I've never seen that approach work well in (low level) open source 
projects, as you start to heavily raise the barrier for participation. Most 
people in this world do these tasks in their spare time and won't spend x2 the 
time to also write and update unit tests.

I really think having a working functional test suite that is easy to run is 
the best way forward in this case. We can then start thinking of ways to test 
hard to reach code sections to increase test coverage.


Alex


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

Re: [U-Boot] [PATCH v2 00/16] dtoc: Add support for 64-bit addresses

[Dr. Philipp Tomsich]

Simon,

I should be able to give this a test drive on the RK3368 by the end of the week.
For the RK3399 our board uses full OF_CONTROL, so I won’t really exercise
this there.

Given that the RK3399 can always fall back to OF_CONTROL for SPL (as is the
default on Puma) and this only blocks the RK3368 TPL (which is not enabled
for any other boards than Lion): should we try to get this merged for this 
release
cycle or let it slip into the new merge window? 

Regards,
Philipp.

> On 29 Aug 2017, at 22:15, Simon Glass  wrote:
> 
> This series updates dtoc to support 64-bit addresses automatically. These
> appear in C code as fdt64_t arrays:
> 
> struct dtd_test1 {
>   fdt64_t reg[2];
> 
> };
> 
> static struct dtd_test1 dtv_test1 = {
>   .reg= {0x1234, 0x5678},
> };
> 
> C code can then process these address and size parents easily. This
> feature is controlled by the #address-cells and #size-cells values of the
> parent.
> 
> The v2 series also enhances phandle support so that it is now possible to
> support phandles with different number of arguments. Several clean-up
> patches are included also.
> 
> Changes in v2:
> - Support 'reg' properties with a single cell (e.g. #size-cells = 0)
> - Introduce an fdt_val_t type which is either 32- or 64-bits long
> - Update rk3368 and rk3399 uses
> - Drop review tags since there are significant changes in this patch
> 
> Simon Glass (16):
>  fdt: Sync libfdt up to upstream
>  dtoc: Adjust Node to record its parent
>  dtoc: Add a 64-bit type and a way to convert cells into 64 bits
>  dtoc: Avoid very long lines in output
>  dtoc: Add support for 32 or 64-bit addresses
>  dtoc: Handle 'reg' properties with unusual sizes
>  dtoc: Update the Fdt class to record phandles
>  dtoc: Use the Fdt's class's phandle map
>  dtoc: Make is_phandle() a member function
>  dtoc: Rename is_phandle() and adjust it to return more detail
>  dtoc: Rename the phandle struct
>  dtoc: Put each phandle on a separate line
>  dtoc: Put phandle args in an array
>  dtoc: Support properties containing multiple phandle values
>  dtoc: Rename the auto-generated dt-structs.h file
>  dtoc: Add a header to the generated files
> 
> doc/driver-model/of-plat.txt   |   2 +-
> drivers/clk/clk-uclass.c   |   4 +-
> drivers/clk/rockchip/clk_rk3368.c  |   2 +-
> drivers/clk/rockchip/clk_rk3399.c  |   4 +-
> drivers/core/regmap.c  |   2 +-
> include/clk.h  |   4 +-
> include/dt-structs.h   |  16 ++-
> include/fdtdec.h   |   2 +
> include/regmap.h   |   2 +-
> include/syscon.h   |   6 +-
> lib/libfdt/fdt_rw.c|  20 ++-
> lib/libfdt/libfdt.h|  31 +
> lib/libfdt/pylibfdt/libfdt.i   |  58 
> scripts/Makefile.spl   |   5 +-
> tools/dtoc/dtb_platdata.py | 204 ++--
> tools/dtoc/dtoc_test_addr32.dts|  27 
> tools/dtoc/dtoc_test_addr32_64.dts |  33 +
> tools/dtoc/dtoc_test_addr64.dts|  33 +
> tools/dtoc/dtoc_test_addr64_32.dts |  33 +
> tools/dtoc/dtoc_test_phandle.dts   |  16 ++-
> tools/dtoc/dtoc_test_simple.dts|  14 ++
> tools/dtoc/fdt.py  |  19 ++-
> tools/dtoc/fdt_util.py |  16 +++
> tools/dtoc/test_dtoc.py| 270 -
> 24 files changed, 748 insertions(+), 75 deletions(-)
> create mode 100644 tools/dtoc/dtoc_test_addr32.dts
> create mode 100644 tools/dtoc/dtoc_test_addr32_64.dts
> create mode 100644 tools/dtoc/dtoc_test_addr64.dts
> create mode 100644 tools/dtoc/dtoc_test_addr64_32.dts
> 
> -- 
> 2.14.1.342.g6490525c54-goog
> 

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

[U-Boot] ** Can't read Driver Desriptor Block **

[Heinrich Schuchardt]

Hello Simon,

U-Boot HEAD qemu-86_defconfig cannot discover an IDE disk with one FAT
partition in qemu-system-x86_64.

By bisection I found this patch.

b7c6baef2891ce8978cbfddb66e944943473ac21
x86: Convert MMC to driver model

With this patch I get

IDE:   Bus 0: OK Bus 1: OK
  Device 0: Model: QEMU HARDDISK  Firm: 2.5+ Ser#: QM1
Type: Hard Disk
Supports 48-bit addressing
Capacity: 128.0 MB = 0.1 GB (262144 x 512)
** Can't read Driver Desriptor Block **
  Device 1: not available
  Device 2: Model: QEMU Firm: 2.5+ Ser#: QEMU DVD-ROM
Type: Removable CD ROM
Capacity: not available
  Device 3: not available

=> ide info
=>

Without the patch I get=> ide info
Device 0: Model: QEMU HARDDISK  Firm: 2.5+ Ser#: QM1
Type: Hard Disk
Supports 48-bit addressing
Capacity: 128.0 MB = 0.1 GB (262144 x 512)
Device 2: Model: QEMU Firm: 2.5+ Ser#: QEMU DVD-ROM
Type: Removable CD ROM
Capacity: not available

I think we observe two independent errors here:

- The hard disk Device 0 is not read.
- The ide command stops at the first device that is not available.

I guess only the first is caused by your patch.

Best regards

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

Re: [U-Boot] [PATCH v2 05/16] dtoc: Add support for 32 or 64-bit addresses

[Dr. Philipp Tomsich]

> On 29 Aug 2017, at 22:15, Simon Glass  wrote:
> 
> When using 32-bit addresses dtoc works correctly. For 64-bit addresses it
> does not since it ignores the #address-cells and #size-cells properties.
> 
> Update the tool to use fdt64_t as the element type for reg properties when
> either the address or size is larger than one cell. Use the correct value
> so that C code can obtain the information from the device tree easily.
> 
> Alos create a new type, fdt_val_t, which is defined to either fdt32_t or
> fdt64_t depending on the word size of the machine. This type corresponds
> to fdt_addr_t and fdt_size_t. Unfortunately we cannot just use those types
> since they are defined to phys_addr_t and phys_size_t which use
> 'unsigned long' in the 32-bit case, rather than 'unsigned int'.
> 
> Add tests for the four combinations of address and size values (32/32,
> 64/64, 32/64, 64/32). Also update existing uses for rk3399 and rk3368
> which now need to use the new fdt_val_t type.
> 
> Signed-off-by: Simon Glass 
> 
> Suggested-by: Heiko Stuebner 
> Reported-by: Kever Yang 

Reviewed-by: Philipp Tomsich 

See below.

> ---
> 
> Changes in v2:
> - Support 'reg' properties with a single cell (e.g. #size-cells = 0)
> - Introduce an fdt_val_t type which is either 32- or 64-bits long
> - Update rk3368 and rk3399 uses
> - Drop review tags since there are significant changes in this patch
> 
> drivers/clk/rockchip/clk_rk3368.c  |   2 +-
> drivers/clk/rockchip/clk_rk3399.c  |   4 +-
> drivers/core/regmap.c  |   2 +-
> include/fdtdec.h   |   2 +
> include/regmap.h   |   2 +-
> include/syscon.h   |   6 +-
> tools/dtoc/dtb_platdata.py |  61 +++
> tools/dtoc/dtoc_test_addr32.dts|  27 +
> tools/dtoc/dtoc_test_addr32_64.dts |  33 ++
> tools/dtoc/dtoc_test_addr64.dts|  33 ++
> tools/dtoc/dtoc_test_addr64_32.dts |  33 ++
> tools/dtoc/fdt_util.py |   2 +
> tools/dtoc/test_dtoc.py| 212 +
> 13 files changed, 413 insertions(+), 6 deletions(-)
> create mode 100644 tools/dtoc/dtoc_test_addr32.dts
> create mode 100644 tools/dtoc/dtoc_test_addr32_64.dts
> create mode 100644 tools/dtoc/dtoc_test_addr64.dts
> create mode 100644 tools/dtoc/dtoc_test_addr64_32.dts
> 
> diff --git a/drivers/clk/rockchip/clk_rk3368.c 
> b/drivers/clk/rockchip/clk_rk3368.c
> index 2be1f572d7..0160d50c03 100644
> --- a/drivers/clk/rockchip/clk_rk3368.c
> +++ b/drivers/clk/rockchip/clk_rk3368.c
> @@ -471,7 +471,7 @@ static int rk3368_clk_probe(struct udevice *dev)
> #if CONFIG_IS_ENABLED(OF_PLATDATA)
>   struct rk3368_clk_plat *plat = dev_get_platdata(dev);
> 
> - priv->cru = map_sysmem(plat->dtd.reg[1], plat->dtd.reg[3]);
> + priv->cru = map_sysmem(plat->dtd.reg[0], plat->dtd.reg[1]);
> #endif
> #if IS_ENABLED(CONFIG_SPL_BUILD) || IS_ENABLED(CONFIG_TPL_BUILD)
>   rkclk_init(priv->cru);
> diff --git a/drivers/clk/rockchip/clk_rk3399.c 
> b/drivers/clk/rockchip/clk_rk3399.c
> index 3edafea140..0de3db620d 100644
> --- a/drivers/clk/rockchip/clk_rk3399.c
> +++ b/drivers/clk/rockchip/clk_rk3399.c
> @@ -963,7 +963,7 @@ static int rk3399_clk_probe(struct udevice *dev)
> #if CONFIG_IS_ENABLED(OF_PLATDATA)
>   struct rk3399_clk_plat *plat = dev_get_platdata(dev);
> 
> - priv->cru = map_sysmem(plat->dtd.reg[1], plat->dtd.reg[3]);
> + priv->cru = map_sysmem(plat->dtd.reg[0], plat->dtd.reg[0]);

The second argument needs to be reg[1].

> #endif
>   rkclk_init(priv->cru);
> #endif
> @@ -1145,7 +1145,7 @@ static int rk3399_pmuclk_probe(struct udevice *dev)
> #if CONFIG_IS_ENABLED(OF_PLATDATA)
>   struct rk3399_pmuclk_plat *plat = dev_get_platdata(dev);
> 
> - priv->pmucru = map_sysmem(plat->dtd.reg[1], plat->dtd.reg[3]);
> + priv->pmucru = map_sysmem(plat->dtd.reg[0], plat->dtd.reg[1]);
> #endif
> 
> #ifndef CONFIG_SPL_BUILD
> diff --git a/drivers/core/regmap.c b/drivers/core/regmap.c
> index d4e16a27ef..0f1d30820c 100644
> --- a/drivers/core/regmap.c
> +++ b/drivers/core/regmap.c
> @@ -40,7 +40,7 @@ static struct regmap *regmap_alloc_count(int count)
> }
> 
> #if CONFIG_IS_ENABLED(OF_PLATDATA)
> -int regmap_init_mem_platdata(struct udevice *dev, u32 *reg, int count,
> +int regmap_init_mem_platdata(struct udevice *dev, fdt_val_t *reg, int count,
>struct regmap **mapp)
> {
>   struct regmap_range *range;
> diff --git a/include/fdtdec.h b/include/fdtdec.h
> index 4a0947c626..1ba02be8e1 100644
> --- a/include/fdtdec.h
> +++ b/include/fdtdec.h
> @@ -27,10 +27,12 @@ typedef phys_size_t fdt_size_t;
> #define FDT_ADDR_T_NONE (-1ULL)
> #define fdt_addr_to_cpu(reg) be64_to_cpu(reg)
> #define fdt_size_to_cpu(reg) be64_to_cpu(reg)
> +typedef fdt64_t fdt_val_t;
> #else
> #define FDT_ADDR_T_NONE (-1U)
> #define fdt_addr_to_cpu(reg) 

Re: [U-Boot] [PATCH 00/23] efi_loader implement missing functions

[Simon Glass]

Hi,

On 29 August 2017 at 22:16, Rob Clark  wrote:
> On Tue, Aug 29, 2017 at 8:57 AM, Leif Lindholm  
> wrote:
>> On Tue, Aug 29, 2017 at 02:26:48PM +0200, Alexander Graf wrote:
>>> > > > I would add command
>>> > > > bootefi selftest.efi
>>> > > > to run the tests and provide the python wrapper code to add it to the
>>> > > > test suite.
>>> > >
>>> > > I think that's a great idea, yes.
>>> > I wonder how far we are from running UEFI tests (either the official
>>> > ones, or I seem to remember hearing about some other test suite which
>>> > didn't require UEFI shell)?
>>>
>>> Let's ask Leif, Ard and Dong.
>>>
>>> The official test suite definitely needs the UEFI Shell. Is the suite
>>> publicly available by now?
>>
>> In binary form, you can access it already from the links on
>> http://uefi.org/testtools
>>
>> Yes, 2.5 is latest release. No this is not a restriction ... the SCT
>> releases have been lagging the specification releases a fair bit.
>>
>> The 2.5a package contains AARCH64, IA32 and X64 support (not ARM).
>> Not that it couldn't contain ARM, it just hasn't been packaged.
>>
>>> > That seems more useful long term than re-inventing comprehensive UEFI
>>> > test suite.  (Also, beyond just running shim/fallback/grub, I don't
>>> > really have time to invent new tests for the stack of efi_loader
>>> > patches I have.)
>>>
>>> Yes and no - it depends on the availability of the official suite :/.
>>
>> UEFI SCT is not yet open source/free software. Obviously, this is
>> something Linaro has been lobbying for since day one of our
>> involvement. There used to be little understanding for this, but that
>> attitude has shifted substantially.
>
> So, if/until UEFI SCT is not an option, what about:
>
>   https://01.org/linux-uefi-validation
>
> (thx to pjones for pointing that out to me)

Well in any case I'm not looking for a large functional test suite at
this stage. It certainly could be useful, but not as a replacement for
unit tests. The latter is for fast verification (so that everyone can
run it as part of 'make tests') and easy identification of the
location of bugs.

These new tests should be written in C, run very quickly (similar to
the existing tests) to verify that the code works. Then when each new
feature is added, the test are expanded to cover the new
functionality. Should the code be refactored, the tests should provide
comfort that nothing broke.

>
> BR,
> -R
>
>
>
>> I will let Dong fill in on what the current status actually get the
>> code into the open is.
>>
>> /
>> Leif

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

Re: [U-Boot] undefined reference to `environment'

[Simon Glass]

+Thomas

Hi Joe,

On 29 August 2017 at 06:59, Joe Hershberger  wrote:
> Hi Simon / Tom,
>
> It seems the SH4 build is failing with the current trunk. Or at least
> my test build is failing and the change seems to have nothing to do
> with the failure.
>
> https://travis-ci.org/jhershbe/u-boot/jobs/269330102

A bisect shows this came in with:

f40ad66f (refs/bisect/bad) arch/sh: don't bring common/env_embedded.o
into the link

Thomas, could you please take a look?

>
> Cheers,
> -Joe

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

[U-Boot] [PATCH v2 10/16] dtoc: Rename is_phandle() and adjust it to return more detail

[Simon Glass]

Update this function to return more detail about a property that contains
phandles. This will allow (in a future commit) more accurate handling of
these properties.

Signed-off-by: Simon Glass 
---

Changes in v2: None

 tools/dtoc/dtb_platdata.py   | 79 +---
 tools/dtoc/dtoc_test_phandle.dts |  1 +
 2 files changed, 58 insertions(+), 22 deletions(-)

diff --git a/tools/dtoc/dtb_platdata.py b/tools/dtoc/dtb_platdata.py
index a483d6c875..001bc4ea66 100644
--- a/tools/dtoc/dtb_platdata.py
+++ b/tools/dtoc/dtb_platdata.py
@@ -12,6 +12,7 @@ This supports converting device tree data to C structures 
definitions and
 static data.
 """
 
+import collections
 import copy
 import sys
 
@@ -44,6 +45,14 @@ TYPE_NAMES = {
 STRUCT_PREFIX = 'dtd_'
 VAL_PREFIX = 'dtv_'
 
+# This holds information about a property which includes phandles.
+#
+# max_args: integer: Maximum number or arguments that any phandle uses (int).
+# args: Number of args for each phandle in the property. The total number of
+# phandles is len(args). This is a list of integers.
+PhandleInfo = collections.namedtuple('PhandleInfo', ['max_args', 'args'])
+
+
 def conv_name_to_c(name):
 """Convert a device-tree name to a C identifier
 
@@ -181,20 +190,42 @@ class DtbPlatdata(object):
 self._lines = []
 return lines
 
-def is_phandle(self, prop):
-   """Check if a node contains phandles
+def get_phandle_argc(self, prop, node_name):
+"""Check if a node contains phandles
 
-   We have no reliable way of detecting whether a node uses a phandle
-   or not. As an interim measure, use a list of known property names.
+We have no reliable way of detecting whether a node uses a phandle
+or not. As an interim measure, use a list of known property names.
 
-   Args:
-   prop: Prop object to check
-   Return:
-   True if the object value contains phandles, else False
-   """
-   if prop.name in ['clocks']:
-   return True
-   return False
+Args:
+prop: Prop object to check
+Return:
+Number of argument cells is this is a phandle, else None
+"""
+if prop.name in ['clocks']:
+val = prop.value
+if not isinstance(val, list):
+val = [val]
+i = 0
+
+max_args = 0
+args = []
+while i < len(val):
+phandle = fdt_util.fdt32_to_cpu(val[i])
+target = self._fdt.phandle_to_node.get(phandle)
+if not target:
+raise ValueError("Cannot parse '%s' in node '%s'" %
+ (prop.name, node_name))
+prop_name = '#clock-cells'
+cells = target.props.get(prop_name)
+if not cells:
+raise ValueError("Node '%s' has no '%s' property" %
+(target.name, prop_name))
+num_args = fdt_util.fdt32_to_cpu(cells.value)
+max_args = max(max_args, num_args)
+args.append(num_args)
+i += 1 + num_args
+return PhandleInfo(max_args, args)
+return None
 
 def scan_dtb(self):
 """Scan the device tree to obtain a tree of nodes and properties
@@ -358,14 +389,16 @@ class DtbPlatdata(object):
 for pname, prop in node.props.items():
 if pname in PROP_IGNORE_LIST or pname[0] == '#':
 continue
-if isinstance(prop.value, list):
-if self.is_phandle(prop):
-# Process the list as pairs of (phandle, id)
-value_it = iter(prop.value)
-for phandle_cell, _ in zip(value_it, value_it):
-phandle = fdt_util.fdt32_to_cpu(phandle_cell)
-target_node = self._fdt.phandle_to_node[phandle]
-node.phandles.add(target_node)
+info = self.get_phandle_argc(prop, node.name)
+if info:
+if not isinstance(prop.value, list):
+prop.value = [prop.value]
+# Process the list as pairs of (phandle, id)
+value_it = iter(prop.value)
+for phandle_cell, _ in zip(value_it, value_it):
+phandle = fdt_util.fdt32_to_cpu(phandle_cell)
+target_node = self._fdt.phandle_to_node[phandle]
+node.phandles.add(target_node)
 
 
 def generate_structs(self, structs):
@@ -383,7 +416,8 @@ class DtbPlatdata(object):
 self.out('struct %s%s {\n' % (STRUCT_PREFIX, name))
 for pname in sorted(structs[name]):
 prop = structs[name][pname]
-if self.is_phandle(prop):
+info = 

Re: [U-Boot] undefined reference to `environment'

[Thomas Petazzoni]

Hello,

On Wed, 30 Aug 2017 04:16:39 +0800, Simon Glass wrote:

> Hi Joe,
> 
> On 29 August 2017 at 06:59, Joe Hershberger  wrote:
> > Hi Simon / Tom,
> >
> > It seems the SH4 build is failing with the current trunk. Or at least
> > my test build is failing and the change seems to have nothing to do
> > with the failure.
> >
> > https://travis-ci.org/jhershbe/u-boot/jobs/269330102  
> 
> A bisect shows this came in with:
> 
> f40ad66f (refs/bisect/bad) arch/sh: don't bring common/env_embedded.o
> into the link
> 
> Thomas, could you please take a look?

Sure, I'll have a look. I guess I should be able to reproduce by
building ms7722se_defconfig ?

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v2 08/16] dtoc: Use the Fdt's class's phandle map

[Simon Glass]

Now that the Fdt class can map phandles to the associated nodes, use that
instead of a separate implementation.

Signed-off-by: Simon Glass 
---

Changes in v2: None

 tools/dtoc/dtb_platdata.py | 16 +++-
 1 file changed, 3 insertions(+), 13 deletions(-)

diff --git a/tools/dtoc/dtb_platdata.py b/tools/dtoc/dtb_platdata.py
index 0c719310b1..705ab27c86 100644
--- a/tools/dtoc/dtb_platdata.py
+++ b/tools/dtoc/dtb_platdata.py
@@ -144,17 +144,14 @@ class DtbPlatdata(object):
 _dtb_fname: Filename of the input device tree binary file
 _valid_nodes: A list of Node object with compatible strings
 _include_disabled: true to include nodes marked status = "disabled"
-_phandle_nodes: A dict of nodes indexed by phandle number (1, 2...)
 _outfile: The current output file (sys.stdout or a real file)
 _lines: Stashed list of output lines for outputting in the future
-_phandle_nodes: A dict of Nodes indexed by phandle (an integer)
 """
 def __init__(self, dtb_fname, include_disabled):
 self._fdt = None
 self._dtb_fname = dtb_fname
 self._valid_nodes = None
 self._include_disabled = include_disabled
-self._phandle_nodes = {}
 self._outfile = None
 self._lines = []
 self._aliases = {}
@@ -210,8 +207,7 @@ class DtbPlatdata(object):
 def scan_node(self, root):
 """Scan a node and subnodes to build a tree of node and phandle info
 
-This adds each node to self._valid_nodes and each phandle to
-self._phandle_nodes.
+This adds each node to self._valid_nodes.
 
 Args:
 root: Root node for scan
@@ -222,10 +218,6 @@ class DtbPlatdata(object):
 if (not self._include_disabled and not status or
 status.value != 'disabled'):
 self._valid_nodes.append(node)
-phandle_prop = node.props.get('phandle')
-if phandle_prop:
-phandle = phandle_prop.GetPhandle()
-self._phandle_nodes[phandle] = node
 
 # recurse to handle any subnodes
 self.scan_node(node)
@@ -234,11 +226,9 @@ class DtbPlatdata(object):
 """Scan the device tree for useful information
 
 This fills in the following properties:
-_phandle_nodes: A dict of Nodes indexed by phandle (an integer)
 _valid_nodes: A list of nodes we wish to consider include in the
 platform data
 """
-self._phandle_nodes = {}
 self._valid_nodes = []
 return self.scan_node(self._fdt.GetRoot())
 
@@ -374,7 +364,7 @@ class DtbPlatdata(object):
 value_it = iter(prop.value)
 for phandle_cell, _ in zip(value_it, value_it):
 phandle = fdt_util.fdt32_to_cpu(phandle_cell)
-target_node = self._phandle_nodes[phandle]
+target_node = self._fdt.phandle_to_node[phandle]
 node.phandles.add(target_node)
 
 
@@ -439,7 +429,7 @@ class DtbPlatdata(object):
 for phandle_cell, id_cell in zip(value_it, value_it):
 phandle = fdt_util.fdt32_to_cpu(phandle_cell)
 id_num = fdt_util.fdt32_to_cpu(id_cell)
-target_node = self._phandle_nodes[phandle]
+target_node = self._fdt.phandle_to_node[phandle]
 name = conv_name_to_c(target_node.name)
 vals.append('{&%s%s, %d}' % (VAL_PREFIX, name, id_num))
 else:
-- 
2.14.1.342.g6490525c54-goog

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

[U-Boot] [PATCH v2 11/16] dtoc: Rename the phandle struct

[Simon Glass]

Rather than naming the phandle struct according to the number of cells it
uses (e.g. struct phandle_2_cell) name it according to the number of
arguments it has (e.g. struct phandle_1_arg). This is a more intuitive
naming.

Signed-off-by: Simon Glass 
---

Changes in v2: None

 doc/driver-model/of-plat.txt | 2 +-
 drivers/clk/clk-uclass.c | 2 +-
 include/clk.h| 4 ++--
 include/dt-structs.h | 7 ++-
 tools/dtoc/dtb_platdata.py   | 3 ++-
 tools/dtoc/test_dtoc.py  | 2 +-
 6 files changed, 13 insertions(+), 7 deletions(-)

diff --git a/doc/driver-model/of-plat.txt b/doc/driver-model/of-plat.txt
index 3ed8c759d6..732bc34f06 100644
--- a/doc/driver-model/of-plat.txt
+++ b/doc/driver-model/of-plat.txt
@@ -111,7 +111,7 @@ struct dtd_rockchip_rk3288_dw_mshc {
 boolcap_sd_highspeed;
 fdt32_t card_detect_delay;
 fdt32_t clock_freq_min_max[2];
-struct phandle_2_cell clocks[4];
+struct phandle_1_arg clocks[4];
 booldisable_wp;
 fdt32_t fifo_depth;
 fdt32_t interrupts[3];
diff --git a/drivers/clk/clk-uclass.c b/drivers/clk/clk-uclass.c
index e68d9279b9..8b40326efa 100644
--- a/drivers/clk/clk-uclass.c
+++ b/drivers/clk/clk-uclass.c
@@ -23,7 +23,7 @@ static inline struct clk_ops *clk_dev_ops(struct udevice *dev)
 #if CONFIG_IS_ENABLED(OF_CONTROL)
 # if CONFIG_IS_ENABLED(OF_PLATDATA)
 int clk_get_by_index_platdata(struct udevice *dev, int index,
- struct phandle_2_cell *cells, struct clk *clk)
+ struct phandle_1_arg *cells, struct clk *clk)
 {
int ret;
 
diff --git a/include/clk.h b/include/clk.h
index c5988f78a8..e7ce3e8576 100644
--- a/include/clk.h
+++ b/include/clk.h
@@ -61,9 +61,9 @@ struct clk {
 };
 
 #if CONFIG_IS_ENABLED(OF_CONTROL) && CONFIG_IS_ENABLED(CLK)
-struct phandle_2_cell;
+struct phandle_1_arg;
 int clk_get_by_index_platdata(struct udevice *dev, int index,
- struct phandle_2_cell *cells, struct clk *clk);
+ struct phandle_1_arg *cells, struct clk *clk);
 
 /**
  * clock_get_by_index - Get/request a clock by integer index.
diff --git a/include/dt-structs.h b/include/dt-structs.h
index 0732c442ff..2ed997115a 100644
--- a/include/dt-structs.h
+++ b/include/dt-structs.h
@@ -9,7 +9,12 @@
 
 /* These structures may only be used in SPL */
 #if CONFIG_IS_ENABLED(OF_PLATDATA)
-struct phandle_2_cell {
+struct phandle_0_arg {
+   const void *node;
+   int id[0];
+};
+
+struct phandle_1_arg {
const void *node;
int id;
 };
diff --git a/tools/dtoc/dtb_platdata.py b/tools/dtoc/dtb_platdata.py
index 001bc4ea66..0234f71b76 100644
--- a/tools/dtoc/dtb_platdata.py
+++ b/tools/dtoc/dtb_platdata.py
@@ -419,7 +419,8 @@ class DtbPlatdata(object):
 info = self.get_phandle_argc(prop, structs[name])
 if info:
 # For phandles, include a reference to the target
-self.out('\t%s%s[%d]' % (tab_to(2, 'struct 
phandle_2_cell'),
+struct_name = 'struct phandle_%d_arg' % info.max_args
+self.out('\t%s%s[%d]' % (tab_to(2, struct_name),
  conv_name_to_c(prop.name),
  len(prop.value) / 2))
 else:
diff --git a/tools/dtoc/test_dtoc.py b/tools/dtoc/test_dtoc.py
index 62460acb7c..23c4439ed9 100644
--- a/tools/dtoc/test_dtoc.py
+++ b/tools/dtoc/test_dtoc.py
@@ -228,7 +228,7 @@ U_BOOT_DEVICE(pmic_at_9) = {
 self.assertEqual('''#include 
 #include 
 struct dtd_source {
-\tstruct phandle_2_cell clocks[1];
+\tstruct phandle_1_arg clocks[1];
 };
 struct dtd_target {
 \tfdt32_t\t\tintval;
-- 
2.14.1.342.g6490525c54-goog

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

[U-Boot] [PATCH v2 07/16] dtoc: Update the Fdt class to record phandles

[Simon Glass]

Add a map from phandles to nodes. This can be used by clients of the the
class instead of maintaining this themselves.

Signed-off-by: Simon Glass 
---

Changes in v2: None

 tools/dtoc/fdt.py | 5 +
 1 file changed, 5 insertions(+)

diff --git a/tools/dtoc/fdt.py b/tools/dtoc/fdt.py
index ffd42ce541..dbc338653b 100644
--- a/tools/dtoc/fdt.py
+++ b/tools/dtoc/fdt.py
@@ -212,6 +212,10 @@ class Node:
 searching into subnodes so that the entire tree is built.
 """
 self.props = self._fdt.GetProps(self)
+phandle = self.props.get('phandle')
+if phandle:
+val = fdt_util.fdt32_to_cpu(phandle.value)
+self._fdt.phandle_to_node[val] = self
 
 offset = libfdt.fdt_first_subnode(self._fdt.GetFdt(), self.Offset())
 while offset >= 0:
@@ -263,6 +267,7 @@ class Fdt:
 def __init__(self, fname):
 self._fname = fname
 self._cached_offsets = False
+self.phandle_to_node = {}
 if self._fname:
 self._fname = fdt_util.EnsureCompiled(self._fname)
 
-- 
2.14.1.342.g6490525c54-goog

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

[U-Boot] [PATCH v2 09/16] dtoc: Make is_phandle() a member function

[Simon Glass]

This function will need to have access to class members once we enhance it
to support multiple phandle values. In preparation for that, move it into
the class.

Signed-off-by: Simon Glass 
---

Changes in v2: None

 tools/dtoc/dtb_platdata.py | 36 ++--
 1 file changed, 18 insertions(+), 18 deletions(-)

diff --git a/tools/dtoc/dtb_platdata.py b/tools/dtoc/dtb_platdata.py
index 705ab27c86..a483d6c875 100644
--- a/tools/dtoc/dtb_platdata.py
+++ b/tools/dtoc/dtb_platdata.py
@@ -116,21 +116,6 @@ def get_compat_name(node):
 compat, aliases = compat[0], compat[1:]
 return conv_name_to_c(compat), [conv_name_to_c(a) for a in aliases]
 
-def is_phandle(prop):
-"""Check if a node contains phandles
-
-We have no reliable way of detecting whether a node uses a phandle
-or not. As an interim measure, use a list of known property names.
-
-Args:
-prop: Prop object to check
-Return:
-True if the object value contains phandles, else False
-"""
-if prop.name in ['clocks']:
-return True
-return False
-
 
 class DtbPlatdata(object):
 """Provide a means to convert device tree binary data to platform data
@@ -196,6 +181,21 @@ class DtbPlatdata(object):
 self._lines = []
 return lines
 
+def is_phandle(self, prop):
+   """Check if a node contains phandles
+
+   We have no reliable way of detecting whether a node uses a phandle
+   or not. As an interim measure, use a list of known property names.
+
+   Args:
+   prop: Prop object to check
+   Return:
+   True if the object value contains phandles, else False
+   """
+   if prop.name in ['clocks']:
+   return True
+   return False
+
 def scan_dtb(self):
 """Scan the device tree to obtain a tree of nodes and properties
 
@@ -359,7 +359,7 @@ class DtbPlatdata(object):
 if pname in PROP_IGNORE_LIST or pname[0] == '#':
 continue
 if isinstance(prop.value, list):
-if is_phandle(prop):
+if self.is_phandle(prop):
 # Process the list as pairs of (phandle, id)
 value_it = iter(prop.value)
 for phandle_cell, _ in zip(value_it, value_it):
@@ -383,7 +383,7 @@ class DtbPlatdata(object):
 self.out('struct %s%s {\n' % (STRUCT_PREFIX, name))
 for pname in sorted(structs[name]):
 prop = structs[name][pname]
-if is_phandle(prop):
+if self.is_phandle(prop):
 # For phandles, include a reference to the target
 self.out('\t%s%s[%d]' % (tab_to(2, 'struct 
phandle_2_cell'),
  conv_name_to_c(prop.name),
@@ -423,7 +423,7 @@ class DtbPlatdata(object):
 vals = []
 # For phandles, output a reference to the platform data
 # of the target node.
-if is_phandle(prop):
+if self.is_phandle(prop):
 # Process the list as pairs of (phandle, id)
 value_it = iter(prop.value)
 for phandle_cell, id_cell in zip(value_it, value_it):
-- 
2.14.1.342.g6490525c54-goog

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

Re: [U-Boot] [PATCH] env: Fix operation of 'make environ'

[Simon Glass]

Hi Joe,

On 30 August 2017 at 04:02, Joe Hershberger  wrote:
> Hi Simon,
>
> On Tue, Aug 29, 2017 at 2:53 PM, Simon Glass  wrote:
>> This was broken by the recent environment refactoring. Specifically:
>>
>> $  make environ
>> scripts/Makefile.build:59: tools/environ/Makefile: No such file or directory
>> make[1]: *** No rule to make target 'tools/environ/Makefile'.  Stop.
>> make: *** [Makefile:1469: environ] Error 2
>>
>> Fix this by updating the Makefile and adjusting the #include filesnames in
>> two C files.
>>
>> Fixes: ec74f5f (Makefile: Rename 'env' target to 'environ')
>> Reported-by: Måns Rullgård 
>> Signed-off-by: Simon Glass 
>
> I assume this was an accident. There is nothing different about this
> since the last time.

Sorry, yes, please ignore.

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

[U-Boot] [PATCH v2 16/16] dtoc: Add a header to the generated files

[Simon Glass]

Add a header that indicates that the files generated by dtoc should not be
modified.

Signed-off-by: Simon Glass 
---

Changes in v2: None

 tools/dtoc/dtb_platdata.py | 12 
 1 file changed, 12 insertions(+)

diff --git a/tools/dtoc/dtb_platdata.py b/tools/dtoc/dtb_platdata.py
index cfca45b0ac..dc9c0d9f45 100644
--- a/tools/dtoc/dtb_platdata.py
+++ b/tools/dtoc/dtb_platdata.py
@@ -190,6 +190,16 @@ class DtbPlatdata(object):
 self._lines = []
 return lines
 
+def out_header(self):
+"""Output a message indicating that this is an auto-generated file"""
+self.out('''/*
+ * DO NOT MODIFY
+ *
+ * This file was generated by dtoc from a .dtb (device tree binary) file.
+ */
+
+''')
+
 def get_phandle_argc(self, prop, node_name):
 """Check if a node contains phandles
 
@@ -410,6 +420,7 @@ class DtbPlatdata(object):
 definitions for node in self._valid_nodes. See the documentation in
 README.of-plat for more information.
 """
+self.out_header()
 self.out('#include \n')
 self.out('#include \n')
 
@@ -512,6 +523,7 @@ class DtbPlatdata(object):
 See the documentation in doc/driver-model/of-plat.txt for more
 information.
 """
+self.out_header()
 self.out('#include \n')
 self.out('#include \n')
 self.out('#include \n')
-- 
2.14.1.342.g6490525c54-goog

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

[U-Boot] [PATCH v2 14/16] dtoc: Support properties containing multiple phandle values

[Simon Glass]

At present dtoc has a very simplistic view of phandles. It assumes that
a property has only a single phandle with a single argument (i.e. two
cells per property).

This is not true in many cases. Enhance the implementation to scan all
phandles in a property and to use the correct number of arguments (which
can be 0, 1, 2 or more) when generating the C code. For the struct
definitions, use a struct which can hold the maximum number of arguments
used by the property.

Signed-off-by: Simon Glass 
---

Changes in v2: None

 include/dt-structs.h |  5 +
 tools/dtoc/dtb_platdata.py   | 21 ++---
 tools/dtoc/dtoc_test_phandle.dts | 17 +++--
 tools/dtoc/test_dtoc.py  | 27 ---
 4 files changed, 58 insertions(+), 12 deletions(-)

diff --git a/include/dt-structs.h b/include/dt-structs.h
index 9ab4e2524d..76979e73e1 100644
--- a/include/dt-structs.h
+++ b/include/dt-structs.h
@@ -18,6 +18,11 @@ struct phandle_1_arg {
const void *node;
int arg[1];
 };
+
+struct phandle_2_arg {
+   const void *node;
+   int arg[2];
+};
 #include 
 #endif
 
diff --git a/tools/dtoc/dtb_platdata.py b/tools/dtoc/dtb_platdata.py
index 1920a59f82..cfca45b0ac 100644
--- a/tools/dtoc/dtb_platdata.py
+++ b/tools/dtoc/dtb_platdata.py
@@ -394,11 +394,13 @@ class DtbPlatdata(object):
 if not isinstance(prop.value, list):
 prop.value = [prop.value]
 # Process the list as pairs of (phandle, id)
-value_it = iter(prop.value)
-for phandle_cell, _ in zip(value_it, value_it):
+pos = 0
+for args in info.args:
+phandle_cell = prop.value[pos]
 phandle = fdt_util.fdt32_to_cpu(phandle_cell)
 target_node = self._fdt.phandle_to_node[phandle]
 node.phandles.add(target_node)
+pos += 1 + args
 
 
 def generate_structs(self, structs):
@@ -422,7 +424,7 @@ class DtbPlatdata(object):
 struct_name = 'struct phandle_%d_arg' % info.max_args
 self.out('\t%s%s[%d]' % (tab_to(2, struct_name),
  conv_name_to_c(prop.name),
- len(prop.value) / 2))
+ len(info.args)))
 else:
 ptype = TYPE_NAMES[prop.type]
 self.out('\t%s%s' % (tab_to(2, ptype),
@@ -461,13 +463,18 @@ class DtbPlatdata(object):
 info = self.get_phandle_argc(prop, node.name)
 if info:
 # Process the list as pairs of (phandle, id)
-value_it = iter(prop.value)
-for phandle_cell, id_cell in zip(value_it, value_it):
+pos = 0
+for args in info.args:
+phandle_cell = prop.value[pos]
 phandle = fdt_util.fdt32_to_cpu(phandle_cell)
-id_num = fdt_util.fdt32_to_cpu(id_cell)
 target_node = self._fdt.phandle_to_node[phandle]
 name = conv_name_to_c(target_node.name)
-vals.append('{&%s%s, {%d}}' % (VAL_PREFIX, name, 
id_num))
+arg_values = []
+for i in range(args):
+
arg_values.append(str(fdt_util.fdt32_to_cpu(prop.value[pos + 1 + i])))
+pos += 1 + args
+vals.append('\t{&%s%s, {%s}}' % (VAL_PREFIX, name,
+ ', '.join(arg_values)))
 for val in vals:
 self.buf('\n\t\t%s,' % val)
 else:
diff --git a/tools/dtoc/dtoc_test_phandle.dts b/tools/dtoc/dtoc_test_phandle.dts
index c0a602f296..ba12b0fe65 100644
--- a/tools/dtoc/dtoc_test_phandle.dts
+++ b/tools/dtoc/dtoc_test_phandle.dts
@@ -10,15 +10,28 @@
 
 / {
phandle: phandle-target {
+   u-boot,dm-pre-reloc;
+   compatible = "target";
+   intval = <0>;
+#clock-cells = <0>;
+   };
+
+   phandle_1: phandle2-target {
u-boot,dm-pre-reloc;
compatible = "target";
intval = <1>;
-#clock-cells = <1>;
+   #clock-cells = <1>;
+   };
+   phandle_2: phandle3-target {
+   u-boot,dm-pre-reloc;
+   compatible = "target";
+   intval = <2>;
+   #clock-cells = <2>;
};
 
phandle-source {
u-boot,dm-pre-reloc;
compatible = "source";
-   clocks = < 1>;
+   clocks = < _1 11 _2 12 13 >;
};
 };
diff --git a/tools/dtoc/test_dtoc.py 

Re: [U-Boot] [U-Boot, 5/5] boot: fdt: fixup the memory dt nodes falcon boot

[York Sun]

On 08/29/2017 12:30 PM, Jagan Teki wrote:
> On Mon, Aug 28, 2017 at 10:17 PM, York Sun  wrote:
>> On 08/26/2017 04:50 AM, Jagan Teki wrote:
>>> On Thu, Aug 3, 2017 at 1:02 AM, Tom Rini  wrote:
 On Wed, Aug 02, 2017 at 07:10:51PM +, York Sun wrote:
> On 04/18/2017 04:57 AM, B, Ravi wrote:
>> In single stage bootmode or falcon boot mode,
>> the SPL shall update the memory dt nodes
>> spl_fixup_fdt() based on DDR configuration for
>> specific platform.
>>
>> Signed-off-by: Ravi Babu 
>> ---
>> common/spl/spl.c | 40 
>> 1 file changed, 40 insertions(+)
>
> Clearly I am late for this thread. I only notice this change when I try
> to merge my FIT improvement for falcon boot.
>
> Why do we need to fixup the device tree for falcon boot at all? The
> device tree is static, saved as argument when exporting it, isn't it? As
> far as the normal boot fixes up the device tree, the exported device
> tree is correct.

 So, the further argument here is that if you have to edit the dts to
 include a valid amount of memory so that the dtb the kernel spits out is
 useful in falcon mode, it's not at all useful in development.
>>>
>>> Anyone noticed! this change is breaking falcon mode (tried in i.MX6
>>> and rk3288) even if we forcibly disable CONFIG_SPL_OF_LIBFDT the SPL
>>> need to revert back to use SPL_OF_PLATDATA.
>>>
>>
>> It broke falcon boot for ls1043ardb and ls1043ardb (and probably all my
>> ARMv8 platforms) due to the way we reserve secure memory. I have added a
>> patch (not upstreamed yet) to prevent dram_init_banksize() to run twice
>> for my boards.
> 
> In-fact I too send patches for dram_init_banksize addition on i.MX6
> and rk3288 for fixing falcon, wonder why we need to add explicit
> function here just to prevent DDR re-config or something similar. I
> think this spl_fixup_fdt should have board or soc specific routine.?

I would prefer to call board/soc routine.

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

[U-Boot] [PATCH v2 13/16] dtoc: Put phandle args in an array

[Simon Glass]

We want to support more than one phandle argument. It makes sense to use
an array for this rather than discrete struct members. Adjust the code to
support this. Rename the member to 'arg' instead of 'id'.

Signed-off-by: Simon Glass 
---

Changes in v2: None

 drivers/clk/clk-uclass.c   | 2 +-
 include/dt-structs.h   | 4 ++--
 tools/dtoc/dtb_platdata.py | 2 +-
 tools/dtoc/test_dtoc.py| 2 +-
 4 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/clk/clk-uclass.c b/drivers/clk/clk-uclass.c
index 8b40326efa..83ba13374c 100644
--- a/drivers/clk/clk-uclass.c
+++ b/drivers/clk/clk-uclass.c
@@ -32,7 +32,7 @@ int clk_get_by_index_platdata(struct udevice *dev, int index,
ret = uclass_get_device(UCLASS_CLK, 0, >dev);
if (ret)
return ret;
-   clk->id = cells[0].id;
+   clk->id = cells[0].arg[0];
 
return 0;
 }
diff --git a/include/dt-structs.h b/include/dt-structs.h
index 2ed997115a..9ab4e2524d 100644
--- a/include/dt-structs.h
+++ b/include/dt-structs.h
@@ -11,12 +11,12 @@
 #if CONFIG_IS_ENABLED(OF_PLATDATA)
 struct phandle_0_arg {
const void *node;
-   int id[0];
+   int arg[0];
 };
 
 struct phandle_1_arg {
const void *node;
-   int id;
+   int arg[1];
 };
 #include 
 #endif
diff --git a/tools/dtoc/dtb_platdata.py b/tools/dtoc/dtb_platdata.py
index c0a3ae692b..1920a59f82 100644
--- a/tools/dtoc/dtb_platdata.py
+++ b/tools/dtoc/dtb_platdata.py
@@ -467,7 +467,7 @@ class DtbPlatdata(object):
 id_num = fdt_util.fdt32_to_cpu(id_cell)
 target_node = self._fdt.phandle_to_node[phandle]
 name = conv_name_to_c(target_node.name)
-vals.append('{&%s%s, %d}' % (VAL_PREFIX, name, id_num))
+vals.append('{&%s%s, {%d}}' % (VAL_PREFIX, name, 
id_num))
 for val in vals:
 self.buf('\n\t\t%s,' % val)
 else:
diff --git a/tools/dtoc/test_dtoc.py b/tools/dtoc/test_dtoc.py
index aa617a649c..fbae927cf8 100644
--- a/tools/dtoc/test_dtoc.py
+++ b/tools/dtoc/test_dtoc.py
@@ -253,7 +253,7 @@ U_BOOT_DEVICE(phandle_target) = {
 
 static struct dtd_source dtv_phandle_source = {
 \t.clocks\t\t\t= {
-\t\t{_phandle_target, 1},},
+\t\t{_phandle_target, {1}},},
 };
 U_BOOT_DEVICE(phandle_source) = {
 \t.name\t\t= "source",
-- 
2.14.1.342.g6490525c54-goog

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

[U-Boot] [PATCH v2 12/16] dtoc: Put each phandle on a separate line

[Simon Glass]

When writing values from properties which contain phandles, dtoc currently
writes 8 phandles per line. Change this to write one phandle per line.
This helps reduce line length, since phandles are generally longer and may
have arguments.

Signed-off-by: Simon Glass 
---

Changes in v2: None

 tools/dtoc/dtb_platdata.py | 12 +++-
 tools/dtoc/test_dtoc.py|  3 ++-
 2 files changed, 9 insertions(+), 6 deletions(-)

diff --git a/tools/dtoc/dtb_platdata.py b/tools/dtoc/dtb_platdata.py
index 0234f71b76..c0a3ae692b 100644
--- a/tools/dtoc/dtb_platdata.py
+++ b/tools/dtoc/dtb_platdata.py
@@ -468,15 +468,17 @@ class DtbPlatdata(object):
 target_node = self._fdt.phandle_to_node[phandle]
 name = conv_name_to_c(target_node.name)
 vals.append('{&%s%s, %d}' % (VAL_PREFIX, name, id_num))
+for val in vals:
+self.buf('\n\t\t%s,' % val)
 else:
 for val in prop.value:
 vals.append(get_value(prop.type, val))
 
-# Put 8 values per line to avoid very long lines.
-for i in xrange(0, len(vals), 8):
-if i:
-self.buf(',\n\t\t')
-self.buf(', '.join(vals[i:i + 8]))
+# Put 8 values per line to avoid very long lines.
+for i in xrange(0, len(vals), 8):
+if i:
+self.buf(',\n\t\t')
+self.buf(', '.join(vals[i:i + 8]))
 self.buf('}')
 else:
 self.buf(get_value(prop.type, prop.value))
diff --git a/tools/dtoc/test_dtoc.py b/tools/dtoc/test_dtoc.py
index 23c4439ed9..aa617a649c 100644
--- a/tools/dtoc/test_dtoc.py
+++ b/tools/dtoc/test_dtoc.py
@@ -252,7 +252,8 @@ U_BOOT_DEVICE(phandle_target) = {
 };
 
 static struct dtd_source dtv_phandle_source = {
-\t.clocks\t\t\t= {{_phandle_target, 1}},
+\t.clocks\t\t\t= {
+\t\t{_phandle_target, 1},},
 };
 U_BOOT_DEVICE(phandle_source) = {
 \t.name\t\t= "source",
-- 
2.14.1.342.g6490525c54-goog

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

[U-Boot] [PATCH v2 03/16] dtoc: Add a 64-bit type and a way to convert cells into 64 bits

[Simon Glass]

When dealing with multi-cell values we need a type that can hold this
value. Add this and a function to process it from a list of cell values.

Signed-off-by: Simon Glass 
Reviewed-by: Philipp Tomsich 
Tested-by: Philipp Tomsich 
---

Changes in v2: None

 tools/dtoc/dtb_platdata.py |  3 +++
 tools/dtoc/fdt.py  |  2 +-
 tools/dtoc/fdt_util.py | 14 ++
 3 files changed, 18 insertions(+), 1 deletion(-)

diff --git a/tools/dtoc/dtb_platdata.py b/tools/dtoc/dtb_platdata.py
index 041a33188f..4a1162a9fa 100644
--- a/tools/dtoc/dtb_platdata.py
+++ b/tools/dtoc/dtb_platdata.py
@@ -38,6 +38,7 @@ TYPE_NAMES = {
 fdt.TYPE_BYTE: 'unsigned char',
 fdt.TYPE_STRING: 'const char *',
 fdt.TYPE_BOOL: 'bool',
+fdt.TYPE_INT64: 'fdt64_t',
 }
 
 STRUCT_PREFIX = 'dtd_'
@@ -95,6 +96,8 @@ def get_value(ftype, value):
 return '"%s"' % value
 elif ftype == fdt.TYPE_BOOL:
 return 'true'
+elif ftype == fdt.TYPE_INT64:
+return '%#x' % value
 
 def get_compat_name(node):
 """Get a node's first compatible string as a C identifier
diff --git a/tools/dtoc/fdt.py b/tools/dtoc/fdt.py
index 49409a62ec..ffd42ce541 100644
--- a/tools/dtoc/fdt.py
+++ b/tools/dtoc/fdt.py
@@ -21,7 +21,7 @@ import libfdt
 # so it is fairly efficient.
 
 # A list of types we support
-(TYPE_BYTE, TYPE_INT, TYPE_STRING, TYPE_BOOL) = range(4)
+(TYPE_BYTE, TYPE_INT, TYPE_STRING, TYPE_BOOL, TYPE_INT64) = range(5)
 
 def CheckErr(errnum, msg):
 if errnum:
diff --git a/tools/dtoc/fdt_util.py b/tools/dtoc/fdt_util.py
index b9dfae8d0e..bec6ee947a 100644
--- a/tools/dtoc/fdt_util.py
+++ b/tools/dtoc/fdt_util.py
@@ -29,6 +29,20 @@ def fdt32_to_cpu(val):
 val = val.encode('raw_unicode_escape')
 return struct.unpack('>I', val)[0]
 
+def fdt_cells_to_cpu(val, cells):
+"""Convert one or two cells to a long integer
+
+Args:
+Value to convert (array of one or more 4-character strings)
+
+Return:
+A native-endian long value
+"""
+out = long(fdt32_to_cpu(val[0]))
+if cells == 2:
+out = out << 32 | fdt32_to_cpu(val[1])
+return out
+
 def EnsureCompiled(fname):
 """Compile an fdt .dts source file into a .dtb binary blob if needed.
 
-- 
2.14.1.342.g6490525c54-goog

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

[U-Boot] [PATCH v2 15/16] dtoc: Rename the auto-generated dt-structs.h file

[Simon Glass]

The filename of the auto-generated file is the same as the file that
includes it. Even though the form is in the generated/ subdirectory, this
could be confused.

Rename the generated file to something that makes it clear it is
auto-generated.

Signed-off-by: Simon Glass 
---

Changes in v2: None

 include/dt-structs.h | 2 +-
 scripts/Makefile.spl | 5 +++--
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/include/dt-structs.h b/include/dt-structs.h
index 76979e73e1..c0f56951b5 100644
--- a/include/dt-structs.h
+++ b/include/dt-structs.h
@@ -23,7 +23,7 @@ struct phandle_2_arg {
const void *node;
int arg[2];
 };
-#include 
+#include 
 #endif
 
 #endif
diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl
index dd8065d87d..b86ea76bab 100644
--- a/scripts/Makefile.spl
+++ b/scripts/Makefile.spl
@@ -257,14 +257,15 @@ cmd_dtoch = $(pythonpath) $(srctree)/tools/dtoc/dtoc -d 
$(obj)/$(SPL_BIN).dtb -o
 quiet_cmd_plat = PLAT$@
 cmd_plat = $(CC) $(c_flags) -c $< -o $@
 
-$(obj)/dts/dt-platdata.o: $(obj)/dts/dt-platdata.c 
include/generated/dt-structs.h
+$(obj)/dts/dt-platdata.o: $(obj)/dts/dt-platdata.c \
+   include/generated/dt-structs-gen.h
$(call if_changed,plat)
 
 PHONY += dts_dir
 dts_dir:
$(shell [ -d $(obj)/dts ] || mkdir -p $(obj)/dts)
 
-include/generated/dt-structs.h: $(obj)/$(SPL_BIN).dtb dts_dir checkdtoc
+include/generated/dt-structs-gen.h: $(obj)/$(SPL_BIN).dtb dts_dir checkdtoc
$(call if_changed,dtoch)
 
 $(obj)/dts/dt-platdata.c: $(obj)/$(SPL_BIN).dtb dts_dir checkdtoc
-- 
2.14.1.342.g6490525c54-goog

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

[U-Boot] [PATCH v2 06/16] dtoc: Handle 'reg' properties with unusual sizes

[Simon Glass]

At present dtoc assumes that all 'reg' properties have both an address and
a size. For I2C devices we do not have this. Adjust dtoc to cope.

Reported-by: Philipp Tomsich 
Signed-off-by: Simon Glass 
---

Changes in v2: None

 tools/dtoc/dtoc_test_simple.dts | 14 ++
 tools/dtoc/test_dtoc.py | 24 
 2 files changed, 38 insertions(+)

diff --git a/tools/dtoc/dtoc_test_simple.dts b/tools/dtoc/dtoc_test_simple.dts
index c736686263..6afe674b1f 100644
--- a/tools/dtoc/dtoc_test_simple.dts
+++ b/tools/dtoc/dtoc_test_simple.dts
@@ -9,6 +9,8 @@
  /dts-v1/;
 
 / {
+   #address-cells = <1>;
+   #size-cells = <1>;
spl-test {
u-boot,dm-pre-reloc;
compatible = "sandbox,spl-test";
@@ -45,4 +47,16 @@
compatible = "sandbox,spl-test.2";
};
 
+   i2c@0 {
+   compatible = "sandbox,i2c-test";
+   u-boot,dm-pre-reloc;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   pmic@9 {
+   compatible = "sandbox,pmic-test";
+   u-boot,dm-pre-reloc;
+   reg = <9>;
+   low-power;
+   };
+   };
 };
diff --git a/tools/dtoc/test_dtoc.py b/tools/dtoc/test_dtoc.py
index 09cfdd..62460acb7c 100644
--- a/tools/dtoc/test_dtoc.py
+++ b/tools/dtoc/test_dtoc.py
@@ -121,6 +121,12 @@ class TestDtoc(unittest.TestCase):
 data = infile.read()
 self.assertEqual('''#include 
 #include 
+struct dtd_sandbox_i2c_test {
+};
+struct dtd_sandbox_pmic_test {
+\tbool\t\tlow_power;
+\tfdt64_t\t\treg[2];
+};
 struct dtd_sandbox_spl_test {
 \tbool\t\tboolval;
 \tunsigned char\tbytearray[3];
@@ -192,6 +198,24 @@ U_BOOT_DEVICE(spl_test4) = {
 \t.platdata_size\t= sizeof(dtv_spl_test4),
 };
 
+static struct dtd_sandbox_i2c_test dtv_i2c_at_0 = {
+};
+U_BOOT_DEVICE(i2c_at_0) = {
+\t.name\t\t= "sandbox_i2c_test",
+\t.platdata\t= _i2c_at_0,
+\t.platdata_size\t= sizeof(dtv_i2c_at_0),
+};
+
+static struct dtd_sandbox_pmic_test dtv_pmic_at_9 = {
+\t.low_power\t\t= true,
+\t.reg\t\t\t= {0x9, 0x0},
+};
+U_BOOT_DEVICE(pmic_at_9) = {
+\t.name\t\t= "sandbox_pmic_test",
+\t.platdata\t= _pmic_at_9,
+\t.platdata_size\t= sizeof(dtv_pmic_at_9),
+};
+
 ''', data)
 
 def test_phandle(self):
-- 
2.14.1.342.g6490525c54-goog

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

[U-Boot] [PATCH v2 04/16] dtoc: Avoid very long lines in output

[Simon Glass]

Large arrays can result in lines with hundreds or thousands of characters
which is not very editor-friendly. To avoid this, addjust the tool to
group values 8 per line.

Signed-off-by: Simon Glass 
---

Changes in v2: None

 tools/dtoc/dtb_platdata.py | 7 ++-
 tools/dtoc/test_dtoc.py| 6 --
 2 files changed, 10 insertions(+), 3 deletions(-)

diff --git a/tools/dtoc/dtb_platdata.py b/tools/dtoc/dtb_platdata.py
index 4a1162a9fa..3243bccfe8 100644
--- a/tools/dtoc/dtb_platdata.py
+++ b/tools/dtoc/dtb_platdata.py
@@ -385,7 +385,12 @@ class DtbPlatdata(object):
 else:
 for val in prop.value:
 vals.append(get_value(prop.type, val))
-self.buf(', '.join(vals))
+
+# Put 8 values per line to avoid very long lines.
+for i in xrange(0, len(vals), 8):
+if i:
+self.buf(',\n\t\t')
+self.buf(', '.join(vals[i:i + 8]))
 self.buf('}')
 else:
 self.buf(get_value(prop.type, prop.value))
diff --git a/tools/dtoc/test_dtoc.py b/tools/dtoc/test_dtoc.py
index 8b95c4124f..5040f23325 100644
--- a/tools/dtoc/test_dtoc.py
+++ b/tools/dtoc/test_dtoc.py
@@ -146,7 +146,8 @@ static struct dtd_sandbox_spl_test dtv_spl_test = {
 \t.bytearray\t\t= {0x6, 0x0, 0x0},
 \t.byteval\t\t= 0x5,
 \t.intval\t\t\t= 0x1,
-\t.longbytearray\t\t= {0x9, 0xa, 0xb, 0xc, 0xd, 0xe, 0xf, 0x10, 0x11},
+\t.longbytearray\t\t= {0x9, 0xa, 0xb, 0xc, 0xd, 0xe, 0xf, 0x10,
+\t\t0x11},
 \t.stringval\t\t= "message",
 \t.boolval\t\t= true,
 \t.intarray\t\t= {0x2, 0x3, 0x4, 0x0},
@@ -162,7 +163,8 @@ static struct dtd_sandbox_spl_test dtv_spl_test2 = {
 \t.bytearray\t\t= {0x1, 0x23, 0x34},
 \t.byteval\t\t= 0x8,
 \t.intval\t\t\t= 0x3,
-\t.longbytearray\t\t= {0x9, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0},
+\t.longbytearray\t\t= {0x9, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
+\t\t0x0},
 \t.stringval\t\t= "message2",
 \t.intarray\t\t= {0x5, 0x0, 0x0, 0x0},
 \t.stringarray\t\t= {"another", "multi-word", "message"},
-- 
2.14.1.342.g6490525c54-goog

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

[U-Boot] [PATCH v2 02/16] dtoc: Adjust Node to record its parent

[Simon Glass]

We need to be able to search back up the tree for #address-cells and
 #size-cells. Record the parent of each node to make this easier.

Signed-off-by: Simon Glass 
Reviewed-by: Philipp Tomsich 
Tested-by: Philipp Tomsich 
---

Changes in v2: None

 tools/dtoc/fdt.py | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/tools/dtoc/fdt.py b/tools/dtoc/fdt.py
index 63a32ea2d7..49409a62ec 100644
--- a/tools/dtoc/fdt.py
+++ b/tools/dtoc/fdt.py
@@ -174,8 +174,9 @@ class Node:
 props: A dict of properties for this node, each a Prop object.
 Keyed by property name
 """
-def __init__(self, fdt, offset, name, path):
+def __init__(self, fdt, parent, offset, name, path):
 self._fdt = fdt
+self.parent = parent
 self._offset = offset
 self.name = name
 self.path = path
@@ -217,7 +218,7 @@ class Node:
 sep = '' if self.path[-1] == '/' else '/'
 name = self._fdt._fdt_obj.get_name(offset)
 path = self.path + sep + name
-node = Node(self._fdt, offset, name, path)
+node = Node(self._fdt, self, offset, name, path)
 self.subnodes.append(node)
 
 node.Scan()
@@ -279,7 +280,7 @@ class Fdt:
 
 TODO(s...@chromium.org): Implement the 'root' parameter
 """
-self._root = self.Node(self, 0, '/', '/')
+self._root = self.Node(self, None, 0, '/', '/')
 self._root.Scan()
 
 def GetRoot(self):
@@ -386,7 +387,7 @@ class Fdt:
 return libfdt.fdt_off_dt_struct(self._fdt) + offset
 
 @classmethod
-def Node(self, fdt, offset, name, path):
+def Node(self, fdt, parent, offset, name, path):
 """Create a new node
 
 This is used by Fdt.Scan() to create a new node using the correct
@@ -394,11 +395,12 @@ class Fdt:
 
 Args:
 fdt: Fdt object
+parent: Parent node, or None if this is the root node
 offset: Offset of node
 name: Node name
 path: Full path to node
 """
-node = Node(fdt, offset, name, path)
+node = Node(fdt, parent, offset, name, path)
 return node
 
 def FdtScan(fname):
-- 
2.14.1.342.g6490525c54-goog

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

[U-Boot] [PATCH v2 05/16] dtoc: Add support for 32 or 64-bit addresses

[Simon Glass]

When using 32-bit addresses dtoc works correctly. For 64-bit addresses it
does not since it ignores the #address-cells and #size-cells properties.

Update the tool to use fdt64_t as the element type for reg properties when
either the address or size is larger than one cell. Use the correct value
so that C code can obtain the information from the device tree easily.

Alos create a new type, fdt_val_t, which is defined to either fdt32_t or
fdt64_t depending on the word size of the machine. This type corresponds
to fdt_addr_t and fdt_size_t. Unfortunately we cannot just use those types
since they are defined to phys_addr_t and phys_size_t which use
'unsigned long' in the 32-bit case, rather than 'unsigned int'.

Add tests for the four combinations of address and size values (32/32,
64/64, 32/64, 64/32). Also update existing uses for rk3399 and rk3368
which now need to use the new fdt_val_t type.

Signed-off-by: Simon Glass 

Suggested-by: Heiko Stuebner 
Reported-by: Kever Yang 
---

Changes in v2:
- Support 'reg' properties with a single cell (e.g. #size-cells = 0)
- Introduce an fdt_val_t type which is either 32- or 64-bits long
- Update rk3368 and rk3399 uses
- Drop review tags since there are significant changes in this patch

 drivers/clk/rockchip/clk_rk3368.c  |   2 +-
 drivers/clk/rockchip/clk_rk3399.c  |   4 +-
 drivers/core/regmap.c  |   2 +-
 include/fdtdec.h   |   2 +
 include/regmap.h   |   2 +-
 include/syscon.h   |   6 +-
 tools/dtoc/dtb_platdata.py |  61 +++
 tools/dtoc/dtoc_test_addr32.dts|  27 +
 tools/dtoc/dtoc_test_addr32_64.dts |  33 ++
 tools/dtoc/dtoc_test_addr64.dts|  33 ++
 tools/dtoc/dtoc_test_addr64_32.dts |  33 ++
 tools/dtoc/fdt_util.py |   2 +
 tools/dtoc/test_dtoc.py| 212 +
 13 files changed, 413 insertions(+), 6 deletions(-)
 create mode 100644 tools/dtoc/dtoc_test_addr32.dts
 create mode 100644 tools/dtoc/dtoc_test_addr32_64.dts
 create mode 100644 tools/dtoc/dtoc_test_addr64.dts
 create mode 100644 tools/dtoc/dtoc_test_addr64_32.dts

diff --git a/drivers/clk/rockchip/clk_rk3368.c 
b/drivers/clk/rockchip/clk_rk3368.c
index 2be1f572d7..0160d50c03 100644
--- a/drivers/clk/rockchip/clk_rk3368.c
+++ b/drivers/clk/rockchip/clk_rk3368.c
@@ -471,7 +471,7 @@ static int rk3368_clk_probe(struct udevice *dev)
 #if CONFIG_IS_ENABLED(OF_PLATDATA)
struct rk3368_clk_plat *plat = dev_get_platdata(dev);
 
-   priv->cru = map_sysmem(plat->dtd.reg[1], plat->dtd.reg[3]);
+   priv->cru = map_sysmem(plat->dtd.reg[0], plat->dtd.reg[1]);
 #endif
 #if IS_ENABLED(CONFIG_SPL_BUILD) || IS_ENABLED(CONFIG_TPL_BUILD)
rkclk_init(priv->cru);
diff --git a/drivers/clk/rockchip/clk_rk3399.c 
b/drivers/clk/rockchip/clk_rk3399.c
index 3edafea140..0de3db620d 100644
--- a/drivers/clk/rockchip/clk_rk3399.c
+++ b/drivers/clk/rockchip/clk_rk3399.c
@@ -963,7 +963,7 @@ static int rk3399_clk_probe(struct udevice *dev)
 #if CONFIG_IS_ENABLED(OF_PLATDATA)
struct rk3399_clk_plat *plat = dev_get_platdata(dev);
 
-   priv->cru = map_sysmem(plat->dtd.reg[1], plat->dtd.reg[3]);
+   priv->cru = map_sysmem(plat->dtd.reg[0], plat->dtd.reg[0]);
 #endif
rkclk_init(priv->cru);
 #endif
@@ -1145,7 +1145,7 @@ static int rk3399_pmuclk_probe(struct udevice *dev)
 #if CONFIG_IS_ENABLED(OF_PLATDATA)
struct rk3399_pmuclk_plat *plat = dev_get_platdata(dev);
 
-   priv->pmucru = map_sysmem(plat->dtd.reg[1], plat->dtd.reg[3]);
+   priv->pmucru = map_sysmem(plat->dtd.reg[0], plat->dtd.reg[1]);
 #endif
 
 #ifndef CONFIG_SPL_BUILD
diff --git a/drivers/core/regmap.c b/drivers/core/regmap.c
index d4e16a27ef..0f1d30820c 100644
--- a/drivers/core/regmap.c
+++ b/drivers/core/regmap.c
@@ -40,7 +40,7 @@ static struct regmap *regmap_alloc_count(int count)
 }
 
 #if CONFIG_IS_ENABLED(OF_PLATDATA)
-int regmap_init_mem_platdata(struct udevice *dev, u32 *reg, int count,
+int regmap_init_mem_platdata(struct udevice *dev, fdt_val_t *reg, int count,
 struct regmap **mapp)
 {
struct regmap_range *range;
diff --git a/include/fdtdec.h b/include/fdtdec.h
index 4a0947c626..1ba02be8e1 100644
--- a/include/fdtdec.h
+++ b/include/fdtdec.h
@@ -27,10 +27,12 @@ typedef phys_size_t fdt_size_t;
 #define FDT_ADDR_T_NONE (-1ULL)
 #define fdt_addr_to_cpu(reg) be64_to_cpu(reg)
 #define fdt_size_to_cpu(reg) be64_to_cpu(reg)
+typedef fdt64_t fdt_val_t;
 #else
 #define FDT_ADDR_T_NONE (-1U)
 #define fdt_addr_to_cpu(reg) be32_to_cpu(reg)
 #define fdt_size_to_cpu(reg) be32_to_cpu(reg)
+typedef fdt32_t fdt_val_t;
 #endif
 
 /* Information obtained about memory from the FDT */
diff --git a/include/regmap.h b/include/regmap.h
index 1eed94e47a..493a5d8eff 100644
--- a/include/regmap.h
+++ b/include/regmap.h
@@ -69,7 +69,7 @@ int regmap_init_mem(struct udevice *dev, struct 

[U-Boot] [PATCH v2 01/16] fdt: Sync libfdt up to upstream

[Simon Glass]

Add upstream changes to U-Boot:

- new pylibfdt functions
- fdt_setprop_placeholder()

Signed-off-by: Simon Glass 
---

Changes in v2: None

 lib/libfdt/fdt_rw.c  | 20 ---
 lib/libfdt/libfdt.h  | 31 +++
 lib/libfdt/pylibfdt/libfdt.i | 58 
 3 files changed, 106 insertions(+), 3 deletions(-)

diff --git a/lib/libfdt/fdt_rw.c b/lib/libfdt/fdt_rw.c
index 80a3212141..3dc775261f 100644
--- a/lib/libfdt/fdt_rw.c
+++ b/lib/libfdt/fdt_rw.c
@@ -228,8 +228,8 @@ int fdt_set_name(void *fdt, int nodeoffset, const char 
*name)
return 0;
 }
 
-int fdt_setprop(void *fdt, int nodeoffset, const char *name,
-   const void *val, int len)
+int fdt_setprop_placeholder(void *fdt, int nodeoffset, const char *name,
+   int len, void **prop_data)
 {
struct fdt_property *prop;
int err;
@@ -242,8 +242,22 @@ int fdt_setprop(void *fdt, int nodeoffset, const char 
*name,
if (err)
return err;
 
+   *prop_data = prop->data;
+   return 0;
+}
+
+int fdt_setprop(void *fdt, int nodeoffset, const char *name,
+   const void *val, int len)
+{
+   void *prop_data;
+   int err;
+
+   err = fdt_setprop_placeholder(fdt, nodeoffset, name, len, _data);
+   if (err)
+   return err;
+
if (len)
-   memcpy(prop->data, val, len);
+   memcpy(prop_data, val, len);
return 0;
 }
 
diff --git a/lib/libfdt/libfdt.h b/lib/libfdt/libfdt.h
index f3f9cad184..6af94cb3f7 100644
--- a/lib/libfdt/libfdt.h
+++ b/lib/libfdt/libfdt.h
@@ -1404,6 +1404,37 @@ int fdt_set_name(void *fdt, int nodeoffset, const char 
*name);
 int fdt_setprop(void *fdt, int nodeoffset, const char *name,
const void *val, int len);
 
+/**
+ * fdt_setprop _placeholder - allocate space for a property
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose property to change
+ * @name: name of the property to change
+ * @len: length of the property value
+ * @prop_data: return pointer to property data
+ *
+ * fdt_setprop_placeholer() allocates the named property in the given node.
+ * If the property exists it is resized. In either case a pointer to the
+ * property data is returned.
+ *
+ * This function may insert or delete data from the blob, and will
+ * therefore change the offsets of some existing nodes.
+ *
+ * returns:
+ * 0, on success
+ * -FDT_ERR_NOSPACE, there is insufficient free space in the blob to
+ * contain the new property value
+ * -FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
+ * -FDT_ERR_BADLAYOUT,
+ * -FDT_ERR_BADMAGIC,
+ * -FDT_ERR_BADVERSION,
+ * -FDT_ERR_BADSTATE,
+ * -FDT_ERR_BADSTRUCTURE,
+ * -FDT_ERR_BADLAYOUT,
+ * -FDT_ERR_TRUNCATED, standard meanings
+ */
+int fdt_setprop_placeholder(void *fdt, int nodeoffset, const char *name,
+   int len, void **prop_data);
+
 /**
  * fdt_setprop_u32 - set a property to a 32-bit integer
  * @fdt: pointer to the device tree blob
diff --git a/lib/libfdt/pylibfdt/libfdt.i b/lib/libfdt/pylibfdt/libfdt.i
index 3b11bb0c95..6c44996c31 100644
--- a/lib/libfdt/pylibfdt/libfdt.i
+++ b/lib/libfdt/pylibfdt/libfdt.i
@@ -128,6 +128,23 @@ class Fdt:
 self._fdt = bytearray(data)
 check_err(fdt_check_header(self._fdt));
 
+def subnode_offset(self, parentoffset, name, quiet=()):
+"""Get the offset of a named subnode
+
+Args:
+parentoffset: Offset of the parent node to check
+name: Name of the required subnode, e.g. 'subnode@1'
+quiet: Errors to ignore (empty to raise on all errors)
+
+Returns:
+The node offset of the found node, if any
+
+Raises
+FdtException if there is no node with that name, or other error
+"""
+return check_err(fdt_subnode_offset(self._fdt, parentoffset, name),
+ quiet)
+
 def path_offset(self, path, quiet=()):
 """Get the offset for a given path
 
@@ -302,6 +319,47 @@ class Fdt:
 return pdata
 return bytearray(pdata[0])
 
+def get_phandle(self, nodeoffset):
+"""Get the phandle of a node
+
+Args:
+nodeoffset: Node offset to check
+
+Returns:
+phandle of node, or 0 if the node has no phandle or another error
+occurs
+"""
+return fdt_get_phandle(self._fdt, nodeoffset)
+
+def parent_offset(self, nodeoffset, quiet=()):
+"""Get the offset of a node's parent
+
+Args:
+nodeoffset: Node offset to check
+quiet: Errors to ignore (empty to raise on all errors)
+
+Returns:
+The offset of the parent node, if any
+
+Raises:
+FdtException if no parent found or other error occurs
+

[U-Boot] [PATCH v2 00/16] dtoc: Add support for 64-bit addresses

[Simon Glass]

This series updates dtoc to support 64-bit addresses automatically. These
appear in C code as fdt64_t arrays:

struct dtd_test1 {
fdt64_t reg[2];

};

static struct dtd_test1 dtv_test1 = {
.reg= {0x1234, 0x5678},
};

C code can then process these address and size parents easily. This
feature is controlled by the #address-cells and #size-cells values of the
parent.

The v2 series also enhances phandle support so that it is now possible to
support phandles with different number of arguments. Several clean-up
patches are included also.

Changes in v2:
- Support 'reg' properties with a single cell (e.g. #size-cells = 0)
- Introduce an fdt_val_t type which is either 32- or 64-bits long
- Update rk3368 and rk3399 uses
- Drop review tags since there are significant changes in this patch

Simon Glass (16):
  fdt: Sync libfdt up to upstream
  dtoc: Adjust Node to record its parent
  dtoc: Add a 64-bit type and a way to convert cells into 64 bits
  dtoc: Avoid very long lines in output
  dtoc: Add support for 32 or 64-bit addresses
  dtoc: Handle 'reg' properties with unusual sizes
  dtoc: Update the Fdt class to record phandles
  dtoc: Use the Fdt's class's phandle map
  dtoc: Make is_phandle() a member function
  dtoc: Rename is_phandle() and adjust it to return more detail
  dtoc: Rename the phandle struct
  dtoc: Put each phandle on a separate line
  dtoc: Put phandle args in an array
  dtoc: Support properties containing multiple phandle values
  dtoc: Rename the auto-generated dt-structs.h file
  dtoc: Add a header to the generated files

 doc/driver-model/of-plat.txt   |   2 +-
 drivers/clk/clk-uclass.c   |   4 +-
 drivers/clk/rockchip/clk_rk3368.c  |   2 +-
 drivers/clk/rockchip/clk_rk3399.c  |   4 +-
 drivers/core/regmap.c  |   2 +-
 include/clk.h  |   4 +-
 include/dt-structs.h   |  16 ++-
 include/fdtdec.h   |   2 +
 include/regmap.h   |   2 +-
 include/syscon.h   |   6 +-
 lib/libfdt/fdt_rw.c|  20 ++-
 lib/libfdt/libfdt.h|  31 +
 lib/libfdt/pylibfdt/libfdt.i   |  58 
 scripts/Makefile.spl   |   5 +-
 tools/dtoc/dtb_platdata.py | 204 ++--
 tools/dtoc/dtoc_test_addr32.dts|  27 
 tools/dtoc/dtoc_test_addr32_64.dts |  33 +
 tools/dtoc/dtoc_test_addr64.dts|  33 +
 tools/dtoc/dtoc_test_addr64_32.dts |  33 +
 tools/dtoc/dtoc_test_phandle.dts   |  16 ++-
 tools/dtoc/dtoc_test_simple.dts|  14 ++
 tools/dtoc/fdt.py  |  19 ++-
 tools/dtoc/fdt_util.py |  16 +++
 tools/dtoc/test_dtoc.py| 270 -
 24 files changed, 748 insertions(+), 75 deletions(-)
 create mode 100644 tools/dtoc/dtoc_test_addr32.dts
 create mode 100644 tools/dtoc/dtoc_test_addr32_64.dts
 create mode 100644 tools/dtoc/dtoc_test_addr64.dts
 create mode 100644 tools/dtoc/dtoc_test_addr64_32.dts

-- 
2.14.1.342.g6490525c54-goog

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

Re: [U-Boot] [PATCH] env: Fix operation of 'make environ'

[Joe Hershberger]

Hi Simon,

On Tue, Aug 29, 2017 at 2:53 PM, Simon Glass  wrote:
> This was broken by the recent environment refactoring. Specifically:
>
> $  make environ
> scripts/Makefile.build:59: tools/environ/Makefile: No such file or directory
> make[1]: *** No rule to make target 'tools/environ/Makefile'.  Stop.
> make: *** [Makefile:1469: environ] Error 2
>
> Fix this by updating the Makefile and adjusting the #include filesnames in
> two C files.
>
> Fixes: ec74f5f (Makefile: Rename 'env' target to 'environ')
> Reported-by: Måns Rullgård 
> Signed-off-by: Simon Glass 

I assume this was an accident. There is nothing different about this
since the last time.

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

[U-Boot] [PATCH] env: Fix operation of 'make environ'

[Simon Glass]

This was broken by the recent environment refactoring. Specifically:

$  make environ
scripts/Makefile.build:59: tools/environ/Makefile: No such file or directory
make[1]: *** No rule to make target 'tools/environ/Makefile'.  Stop.
make: *** [Makefile:1469: environ] Error 2

Fix this by updating the Makefile and adjusting the #include filesnames in
two C files.

Fixes: ec74f5f (Makefile: Rename 'env' target to 'environ')
Reported-by: Måns Rullgård 
Signed-off-by: Simon Glass 
---

 Makefile  | 2 +-
 tools/env/env_attr.c  | 2 +-
 tools/env/env_flags.c | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/Makefile b/Makefile
index a0f3bfd2a5..dd9d567811 100644
--- a/Makefile
+++ b/Makefile
@@ -1466,7 +1466,7 @@ checkarmreloc: u-boot
fi
 
 environ: scripts_basic
-   $(Q)$(MAKE) $(build)=tools/$@
+   $(Q)$(MAKE) $(build)=tools/env
 
 tools-only: scripts_basic $(version_h) $(timestamp_h)
$(Q)$(MAKE) $(build)=tools
diff --git a/tools/env/env_attr.c b/tools/env/env_attr.c
index 502d4c900b..4d8536335c 100644
--- a/tools/env/env_attr.c
+++ b/tools/env/env_attr.c
@@ -1 +1 @@
-#include "../../common/env_attr.c"
+#include "../../env/attr.c"
diff --git a/tools/env/env_flags.c b/tools/env/env_flags.c
index b261cb8e39..71e13e2021 100644
--- a/tools/env/env_flags.c
+++ b/tools/env/env_flags.c
@@ -1 +1 @@
-#include "../../common/env_flags.c"
+#include "../../env/flags.c"
-- 
2.14.1.342.g6490525c54-goog

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

Re: [U-Boot] [U-Boot, 5/5] boot: fdt: fixup the memory dt nodes falcon boot

[Jagan Teki]

On Mon, Aug 28, 2017 at 10:17 PM, York Sun  wrote:
> On 08/26/2017 04:50 AM, Jagan Teki wrote:
>> On Thu, Aug 3, 2017 at 1:02 AM, Tom Rini  wrote:
>>> On Wed, Aug 02, 2017 at 07:10:51PM +, York Sun wrote:
 On 04/18/2017 04:57 AM, B, Ravi wrote:
> In single stage bootmode or falcon boot mode,
> the SPL shall update the memory dt nodes
> spl_fixup_fdt() based on DDR configuration for
> specific platform.
>
> Signed-off-by: Ravi Babu 
> ---
>common/spl/spl.c | 40 
>1 file changed, 40 insertions(+)

 Clearly I am late for this thread. I only notice this change when I try
 to merge my FIT improvement for falcon boot.

 Why do we need to fixup the device tree for falcon boot at all? The
 device tree is static, saved as argument when exporting it, isn't it? As
 far as the normal boot fixes up the device tree, the exported device
 tree is correct.
>>>
>>> So, the further argument here is that if you have to edit the dts to
>>> include a valid amount of memory so that the dtb the kernel spits out is
>>> useful in falcon mode, it's not at all useful in development.
>>
>> Anyone noticed! this change is breaking falcon mode (tried in i.MX6
>> and rk3288) even if we forcibly disable CONFIG_SPL_OF_LIBFDT the SPL
>> need to revert back to use SPL_OF_PLATDATA.
>>
>
> It broke falcon boot for ls1043ardb and ls1043ardb (and probably all my
> ARMv8 platforms) due to the way we reserve secure memory. I have added a
> patch (not upstreamed yet) to prevent dram_init_banksize() to run twice
> for my boards.

In-fact I too send patches for dram_init_banksize addition on i.MX6
and rk3288 for fixing falcon, wonder why we need to add explicit
function here just to prevent DDR re-config or something similar. I
think this spl_fixup_fdt should have board or soc specific routine.?

thanks!
-- 
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] imx: mx7: Add support for USB boot mode

[Troy Kisky]

On 8/29/2017 7:37 AM, Eric Nelson wrote:
> Hi Troy,
> 
> On 08/28/2017 09:42 AM, Troy Kisky wrote:
>> On 8/27/2017 3:04 PM, Eric Nelson wrote:
>>> This adds support for USB boot mode on the i.MX7D SoC, which
>>> is most useful when doing U-Boot development on this chip.
>>>
>>> i.e., it enables you to enter the ROM boot loader's serial
>>> download protocol using the command:
>>>
>>> => bmode usb
>>>
>>> Signed-off-by: Eric Nelson 
>>> ---
>>>   arch/arm/mach-imx/mx7/soc.c | 2 ++
>>>   1 file changed, 2 insertions(+)
>>>
>>> diff --git a/arch/arm/mach-imx/mx7/soc.c b/arch/arm/mach-imx/mx7/soc.c
>>> index 87bf105..63ee59f 100644
>>> --- a/arch/arm/mach-imx/mx7/soc.c
>>> +++ b/arch/arm/mach-imx/mx7/soc.c
>>> @@ -372,6 +372,8 @@ void set_wdog_reset(struct wdog_regs *wdog)
>>>    * to SBMR1, which will determine the boot device.
>>>    */
>>>   const struct boot_mode soc_boot_modes[] = {
>>
>> You might want to add
>>
>> +   {"normal",  MAKE_CFGVAL(0x00, 0x00, 0x00, 0x00)},
>>
>>
>> while you're at it, to undo with "bmode normal"
>>
> 
> Normal, meaning "don't override"?
> 
> Why would you want to do this?
> 
> Please advise,

Hi Eric!


If you do "bmode usb" and then use "imx_usb" to load a new u-boot.
You may want to do "bmode normal", so that a watchdog reset from
the linux kernel or from u-boot will work as expected, instead of
starting the ROM USB downloader again.

BR

Troy

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

Re: [U-Boot] [PATCH 2/2] net: nfs: Correct type of rpc_t->u.reply->data

[Joe Hershberger]

On Sun, Aug 20, 2017 at 9:40 PM, Tom Rini  wrote:
> In rpc_t we declare data to be a uint8_t of size 2048, for a final size
> of 2048.  We also however declare the reply part of the union to have a
> uint32_t data field of NFS_READ_SIZE (1024) for a final size of
> 4096+24=4120 and an overrun.  Expand the comment above the struct to
> note that if NFS_READ_SIZE is increased then the data buf must also be
> increased and correct the declaration to be uint8_t.
>
> Reported-by: Coverity (CID: 152888)
> Cc: Joe Hershberger 
> Signed-off-by: Tom Rini 
> ---
>  net/nfs.h | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/net/nfs.h b/net/nfs.h
> index 1aa06e8fb90f..b23b4088d825 100644
> --- a/net/nfs.h
> +++ b/net/nfs.h
> @@ -39,8 +39,9 @@
>  /*
>   * Block size used for NFS read accesses.  A RPC reply packet (including  all
>   * headers) must fit within a single Ethernet frame to avoid fragmentation.
> - * However, if CONFIG_IP_DEFRAG is set, a bigger value could be used.  In any
> - * case, most NFS servers are optimized for a power of 2.
> + * However, if CONFIG_IP_DEFRAG is set, a bigger value could be used, so long
> + * as rpc_t->u->data is incrased to match. In any case, most NFS servers are
> + * optimized for a power of 2.
>   */
>  #define NFS_READ_SIZE  1024/* biggest power of two that fits Ether frame 
> */
>
> @@ -73,7 +74,7 @@ struct rpc_t {
> uint32_t verifier;
> uint32_t v2;
> uint32_t astatus;
> -   uint32_t data[NFS_READ_SIZE];
> +   uint8_t data[NFS_READ_SIZE];

All of the pointer math would also need to be updated. Didn't notice
that at first so,

Nacked-by: Joe Hershberger 

> } reply;
> } u;
>  } __attribute__((packed));
> --
> 1.9.1
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [u-boot-release] [PATCH 2/3] armv8: ls1088a: SPL size reduction

[York Sun]

On 08/29/2017 10:36 AM, Sumit Garg wrote:
>> -Original Message-
>> From: York Sun
>> Sent: Tuesday, August 29, 2017 9:25 PM
>> To: Sumit Garg ; u-boot@lists.denx.de
>> Cc: Prabhakar Kushwaha ; Ruchika Gupta
>> 
>> Subject: Re: [u-boot-release] [PATCH 2/3] armv8: ls1088a: SPL size reduction
>>
>> On 08/29/2017 12:02 AM, Sumit Garg wrote:
>>> Using changes in this patch we were able to reduce approx 8k size of
>>> u-boot-spl.bin image. Following is breif description of changes to
>>> reduce SPL size:
>>> 1. Changes in board/freescale/ls1088a/Makefile to remove
>>>  compilation of eth.c and cpld.c in case of SPL build.
>>> 2. Changes in board/freescale/ls1088a/ls1088a.c to keep
>>>  board_early_init_f funcations in case of SPL build.
>>> 3. Changes in ls1088a_common.h & ls1088ardb.h to remove driver
>>>  specific macros due to which static data was being compiled in
>>>  case of SPL build.
>>> 4. Enable CONFIG_SYS_DCACHE_OFF in case of SPL build as DCACHE is
>>>  not being enabled in case of SPL image but was compiled in to
>>>  add redundant code.
>>>
>>> Signed-off-by: Sumit Garg 
>>> ---
>>>
>>> Dependent on ls1088 base SD boot target. Also dependent on ls1088 QPSI
>>> secure boot target.
>>>
>>>board/freescale/ls1088a/Makefile  |  4 +++-
>>>board/freescale/ls1088a/ls1088a.c | 14 --
>>>include/configs/ls1088a_common.h  | 20 
>>>include/configs/ls1088ardb.h  | 20 
>>>4 files changed, 51 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/board/freescale/ls1088a/Makefile
>>> b/board/freescale/ls1088a/Makefile
>>> index bdcce9e..0e15031 100644
>>> --- a/board/freescale/ls1088a/Makefile
>>> +++ b/board/freescale/ls1088a/Makefile
>>> @@ -5,6 +5,8 @@
>>>#
>>>
>>>obj-y += ls1088a.o
>>> +obj-y += ddr.o
>>> +ifndef CONFIG_SPL_BUILD
>>>obj-$(CONFIG_TARGET_LS1088ARDB) += eth_ls1088ardb.o
>>>obj-$(CONFIG_TARGET_LS1088AQDS) += eth_ls1088aqds.o -obj-y += ddr.o
>>> +endif
>>> diff --git a/board/freescale/ls1088a/ls1088a.c
>>> b/board/freescale/ls1088a/ls1088a.c
>>> index 1860f9c..1c28ab4 100644
>>> --- a/board/freescale/ls1088a/ls1088a.c
>>> +++ b/board/freescale/ls1088a/ls1088a.c
>>> @@ -24,6 +24,13 @@
>>>
>>>DECLARE_GLOBAL_DATA_PTR;
>>>
>>> +int board_early_init_f(void)
>>> +{
>>> +   fsl_lsch3_early_init_f();
>>> +   return 0;
>>> +}
>>> +
>>> +#if !defined(CONFIG_SPL_BUILD)
>>>unsigned long long get_qixis_addr(void)
>>>{
>>> unsigned long long addr;
>>> @@ -324,12 +331,6 @@ int board_init(void)
>>> return 0;
>>>}
>>>
>>> -int board_early_init_f(void)
>>> -{
>>> -   fsl_lsch3_early_init_f();
>>> -   return 0;
>>> -}
>>> -
>>>void detail_board_ddr_info(void)
>>>{
>>> puts("\nDDR");
>>> @@ -404,3 +405,4 @@ int ft_board_setup(void *blob, bd_t *bd)
>>> return 0;
>>>}
>>>#endif
>>> +#endif /* defined(CONFIG_SPL_BUILD) */
>>> diff --git a/include/configs/ls1088a_common.h
>>> b/include/configs/ls1088a_common.h
>>> index 63b69f8..fb4c852 100644
>>> --- a/include/configs/ls1088a_common.h
>>> +++ b/include/configs/ls1088a_common.h
>>> @@ -7,6 +7,20 @@
>>>#ifndef __LS1088_COMMON_H
>>>#define __LS1088_COMMON_H
>>>
>>> +/* SPL build */
>>> +#ifdef CONFIG_SPL_BUILD
>>> +#define SPL_NO_BOARDINFO
>>> +#define SPL_NO_QIXIS
>>> +#define SPL_NO_PCI
>>> +#define SPL_NO_ENV
>>> +#define SPL_NO_RTC
>>> +#define SPL_NO_USB
>>> +#define SPL_NO_SATA
>>> +#define SPL_NO_QSPI
>>> +#define SPL_NO_IFC
>>> +#define CONFIG_SYS_DCACHE_OFF
>>
>> How much space can you save with data cache off? I prefer to leave the cache
>> on. Cache is used if PPA is loaded in SPL stage for boost booting speed.
>>
>> York
>   
> As we discussed earlier too, dcache was not enabled in SPL for our layerscape 
> platforms. 

That was a mistake when SPL targets were added. It should be enabled.
As I said, if you load PPA in SPL, cache will be enabled for EL2. You 
didn't do it because booting performance is not a concern. If you enable 
falcon boot, this is required.

> 
> Also we do need more space (approx.. 6KB) on OCRAM for header. As currently 
> we are only supporting
> single key in header (Max Size: 4KB) for validation. But actual use-case 
> requires SRK table (8 keys) in
> header (Size: 10KB).
> 
> Total Available OCRAM for SPL image and header:   88KB
> 
> Current SPL image size with GCC 5.4.1 tool-chain: 84KB
> Current SPL header size with GCC 5.4.1 tool-chain:4KB
> 
> Required SPL header size with GCC 5.4.1 tool-chain:   10KB
> 
> So we need to reduce SPL image size by 6KB more.
> 

I understand the difficulty to fit secure boot into OCRAM. Please try 
GCC 6. It has better optimization.

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

Re: [U-Boot] [PATCH v2] spi: fsl_qspi: Add controller busy check before new spi operation

[Jagan Teki]

On Tue, Aug 29, 2017 at 6:55 PM, Suresh Gupta  wrote:
> It is recommended to check either controller is free to take
> new spi action. The IP_ACC and AHB_ACC bits indicates that
> the controller is busy in IP or AHB mode respectively.
> And the BUSY bit indicates that controller is currently
> busy handling a transaction to an external flash device
>
> Signed-off-by: Suresh Gupta 
> ---
> Changes in v2:
>
> - Add wait_for_bit instead of while
> - move the busy check code to fsl_qspi_claim_bus form qspi_xfer
>
>  drivers/spi/fsl_qspi.c | 28 +++-
>  drivers/spi/fsl_qspi.h |  4 
>  2 files changed, 31 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/spi/fsl_qspi.c b/drivers/spi/fsl_qspi.c
> index 1dfa89a..ed23aac 100644
> --- a/drivers/spi/fsl_qspi.c
> +++ b/drivers/spi/fsl_qspi.c
> @@ -14,6 +14,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include "fsl_qspi.h"
>
>  DECLARE_GLOBAL_DATA_PTR;
> @@ -991,7 +992,7 @@ static int fsl_qspi_probe(struct udevice *bus)
> struct fsl_qspi_platdata *plat = dev_get_platdata(bus);
> struct fsl_qspi_priv *priv = dev_get_priv(bus);
> struct dm_spi_bus *dm_spi_bus;
> -   int i;
> +   int i, ret;
>
> dm_spi_bus = bus->uclass_priv;
>
> @@ -1011,6 +1012,18 @@ static int fsl_qspi_probe(struct udevice *bus)
> priv->flash_num = plat->flash_num;
> priv->num_chipselect = plat->num_chipselect;
>

I think in previous version, this code not added in probe is it? is
this because probe doing mcr and other reg operations?

> +   /* make sure controller is not busy anywhere */
> +   ret = wait_for_bit(__func__, >regs->sr,
> +  QSPI_SR_BUSY_MASK |
> +  QSPI_SR_AHB_ACC_MASK |
> +  QSPI_SR_IP_ACC_MASK,
> +  false, 1000, false);
> +
> +   if (ret) {
> +   printf("ERROR : The controller is busy\n");
> +   return -EBUSY;
> +   }

Better to drop printf or use debug and wait_for_bit usually return
-ETIMEDOUT or -EINTR on failure so just return ret.

thanks!
-- 
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [u-boot-release] [PATCH 2/3] armv8: ls1088a: SPL size reduction

[Sumit Garg]

> -Original Message-
> From: York Sun
> Sent: Tuesday, August 29, 2017 9:25 PM
> To: Sumit Garg ; u-boot@lists.denx.de
> Cc: Prabhakar Kushwaha ; Ruchika Gupta
> 
> Subject: Re: [u-boot-release] [PATCH 2/3] armv8: ls1088a: SPL size reduction
> 
> On 08/29/2017 12:02 AM, Sumit Garg wrote:
> > Using changes in this patch we were able to reduce approx 8k size of
> > u-boot-spl.bin image. Following is breif description of changes to
> > reduce SPL size:
> > 1. Changes in board/freescale/ls1088a/Makefile to remove
> > compilation of eth.c and cpld.c in case of SPL build.
> > 2. Changes in board/freescale/ls1088a/ls1088a.c to keep
> > board_early_init_f funcations in case of SPL build.
> > 3. Changes in ls1088a_common.h & ls1088ardb.h to remove driver
> > specific macros due to which static data was being compiled in
> > case of SPL build.
> > 4. Enable CONFIG_SYS_DCACHE_OFF in case of SPL build as DCACHE is
> > not being enabled in case of SPL image but was compiled in to
> > add redundant code.
> >
> > Signed-off-by: Sumit Garg 
> > ---
> >
> > Dependent on ls1088 base SD boot target. Also dependent on ls1088 QPSI
> > secure boot target.
> >
> >   board/freescale/ls1088a/Makefile  |  4 +++-
> >   board/freescale/ls1088a/ls1088a.c | 14 --
> >   include/configs/ls1088a_common.h  | 20 
> >   include/configs/ls1088ardb.h  | 20 
> >   4 files changed, 51 insertions(+), 7 deletions(-)
> >
> > diff --git a/board/freescale/ls1088a/Makefile
> > b/board/freescale/ls1088a/Makefile
> > index bdcce9e..0e15031 100644
> > --- a/board/freescale/ls1088a/Makefile
> > +++ b/board/freescale/ls1088a/Makefile
> > @@ -5,6 +5,8 @@
> >   #
> >
> >   obj-y += ls1088a.o
> > +obj-y += ddr.o
> > +ifndef CONFIG_SPL_BUILD
> >   obj-$(CONFIG_TARGET_LS1088ARDB) += eth_ls1088ardb.o
> >   obj-$(CONFIG_TARGET_LS1088AQDS) += eth_ls1088aqds.o -obj-y += ddr.o
> > +endif
> > diff --git a/board/freescale/ls1088a/ls1088a.c
> > b/board/freescale/ls1088a/ls1088a.c
> > index 1860f9c..1c28ab4 100644
> > --- a/board/freescale/ls1088a/ls1088a.c
> > +++ b/board/freescale/ls1088a/ls1088a.c
> > @@ -24,6 +24,13 @@
> >
> >   DECLARE_GLOBAL_DATA_PTR;
> >
> > +int board_early_init_f(void)
> > +{
> > +   fsl_lsch3_early_init_f();
> > +   return 0;
> > +}
> > +
> > +#if !defined(CONFIG_SPL_BUILD)
> >   unsigned long long get_qixis_addr(void)
> >   {
> > unsigned long long addr;
> > @@ -324,12 +331,6 @@ int board_init(void)
> > return 0;
> >   }
> >
> > -int board_early_init_f(void)
> > -{
> > -   fsl_lsch3_early_init_f();
> > -   return 0;
> > -}
> > -
> >   void detail_board_ddr_info(void)
> >   {
> > puts("\nDDR");
> > @@ -404,3 +405,4 @@ int ft_board_setup(void *blob, bd_t *bd)
> > return 0;
> >   }
> >   #endif
> > +#endif /* defined(CONFIG_SPL_BUILD) */
> > diff --git a/include/configs/ls1088a_common.h
> > b/include/configs/ls1088a_common.h
> > index 63b69f8..fb4c852 100644
> > --- a/include/configs/ls1088a_common.h
> > +++ b/include/configs/ls1088a_common.h
> > @@ -7,6 +7,20 @@
> >   #ifndef __LS1088_COMMON_H
> >   #define __LS1088_COMMON_H
> >
> > +/* SPL build */
> > +#ifdef CONFIG_SPL_BUILD
> > +#define SPL_NO_BOARDINFO
> > +#define SPL_NO_QIXIS
> > +#define SPL_NO_PCI
> > +#define SPL_NO_ENV
> > +#define SPL_NO_RTC
> > +#define SPL_NO_USB
> > +#define SPL_NO_SATA
> > +#define SPL_NO_QSPI
> > +#define SPL_NO_IFC
> > +#define CONFIG_SYS_DCACHE_OFF
> 
> How much space can you save with data cache off? I prefer to leave the cache
> on. Cache is used if PPA is loaded in SPL stage for boost booting speed.
> 
> York
 
As we discussed earlier too, dcache was not enabled in SPL for our layerscape 
platforms. I have just
removed redundant dcache specific code from SPL. I do save 2KB memory by 
removing redundant
dcache specific code.

Also we do need more space (approx.. 6KB) on OCRAM for header. As currently we 
are only supporting
single key in header (Max Size: 4KB) for validation. But actual use-case 
requires SRK table (8 keys) in
header (Size: 10KB).

Total Available OCRAM for SPL image and header: 88KB

Current SPL image size with GCC 5.4.1 tool-chain:   84KB
Current SPL header size with GCC 5.4.1 tool-chain:  4KB

Required SPL header size with GCC 5.4.1 tool-chain: 10KB

So we need to reduce SPL image size by 6KB more.

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

Re: [U-Boot] setup of PEX_GCLK_RATIO in E500 CPUs(P2010) missing ?

[York Sun]

+Roy Zang to comment on PCIe clock source

On 08/29/2017 10:06 AM, Joakim Tjernlund wrote:
> On Tue, 2017-08-29 at 15:43 +, York Sun wrote:
>> On 08/29/2017 06:21 AM, Joakim Tjernlund wrote:
>>> On Tue, 2017-08-29 at 12:47 +0200, Joakim Tjernlund wrote:
 As we are looking at PCI stuff ATM I would like to ask
 about PEX_GCLK_RATIO in E500 CPUs. I cannot find this is setup
 at all for E500 but I THINK this is required.

 In 83xx one do:
 get_clocks();
 /* Configure the PCIE controller core clock ratio */
 out_le32(hose_cfg_base + PEX_GCLK_RATIO,
>>>
>>> A bit strange with out_le32 instead of out_be32 ?
>>>
 (((bus ? gd->arch.pciexp2_clk : gd->arch.pciexp1_clk)
 / 100) * 16) / 333);
 udelay(100);

 Any clues?

Jocke
>>>
>>> Seems like only 83xx is setting this parameter.
>>>
>>> Anyhow, I put together this patch:
>>>
>>> --- a/drivers/pci/fsl_pci_init.c
>>> +++ b/drivers/pci/fsl_pci_init.c
>>> @@ -322,6 +322,10 @@ void fsl_pci_init(struct pci_controller *hose, struct 
>>> fsl_pci_info *pci_info)
>>>
>>>   pci_setup_indirect(hose, cfg_addr, cfg_data);
>>>
>>> +   /* Configure the PCIE controller core clock ratio */
>>> +   pci_hose_write_config_dword(hose, dev, 0x440, (gd->bus_clk / 
>>> 3) * 16);
>>> +   /* udelay(100) needed here ?*/
>>> +
>>>   block_rev = in_be32(>block_rev1);
>>>   if (PEX_IP_BLK_REV_2_2 <= block_rev) {
>>>   pi = >pit[2];  /* 0xDC0 */
>>>
>>> Any chance this will work for all supported FSL PCIe controllers?
>>>
>>
>> Jocke,
>>
>> You don't need to program this register if the actual PCIe clock is the
>> same as default. Since SerDes reference clock has to be 100MHz for PCIe
>> protocol, my guess is the PCIe clock is always correct. The bus_clk you
>> are referring is not the PCIe clock. Again, I am not a PCIe expert, I
>> could be wrong. Since PCIe (SerDes) has been working on multiple
>> platforms, I guess the clock is correct.
> 
> I don't think so. Here is what T1042 says about this:
> 
> The PCI Express controller clock frequency is one-half the platform clock 
> frequency.
> 
> The PCI Express controller core clock ratio register is used to program the 
> ratio of the
> actual PCI Express controller clock frequency to the default controller core 
> frequency
> ( 333 MHz ). This is required only when a PCI Express controller clock 
> frequency other
> than the default 333 MHz has to be used.
> As an example of programming PEX_GCLK_RATIO, consider the case where the 
> actual
> PCI Express controller clock is 250 MHz, the ratio of the actual clock to the 
> default clock
> ( 333 MHz) is 3:4. that is, the default core clock has to be multiplied by 
> the ratio (3/4,
> which is equivalent to 12/16). So the register has to be programmed with the 
> decimal
> numerator value 12 or 0x_000C.
> 
> Our CCB is 250 MHz so this should be set to 0xc.
> 
> I found this on Google too:
> The PEX controller hardware requires for timing tuning in order to operate 
> properly at given CCB/2 clock
> frequency. PEX_GCLK_RATIO register controls this tuning with 333MHz/16 
> granularities. So for given CCB
> frequency Fccb [MHz] we must write to PEX_GCLK_RATIO nearest integer of 
> ((Fccb/2)/(333/16)). So for Fccb=375
> we have to write 18.

Jocke,

Basically I agree with you, if the clock is different from default, you 
need to set the ratio. T104x indeed uses 1/2 platform clock as PCIe 
clock. I am not sure if P2010 uses the same way. Let me add Roy to this 
thread.

Roy, how do we get PCIe clock for P1/T1 (and other mpc85xx) SoCs? Don't 
we need to set PEX_GCLK_RATIO register? It is not even in the header file.

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

Re: [U-Boot] [PATCH] mtd/spi: Add MT35XU512ABA1G12 NOR flash support

[Jagan Teki]

On Tue, Aug 29, 2017 at 9:42 PM, Yogesh Narayan Gaur
 wrote:
>
>
>> -Original Message-
>> From: Jagan Teki [mailto:jagannadh.t...@gmail.com]
>> Sent: Friday, August 11, 2017 4:03 PM
>> To: Yogesh Narayan Gaur 
>> Cc: u-boot@lists.denx.de; York Sun 
>> Subject: Re: [PATCH] mtd/spi: Add MT35XU512ABA1G12 NOR flash support
>>
>> On Fri, Aug 11, 2017 at 3:38 PM, Yogesh Narayan Gaur
>>  wrote:
>> >
>> >
>> >> -Original Message-
>> >> From: Jagan Teki [mailto:jagannadh.t...@gmail.com]
>> >> Sent: Friday, August 11, 2017 3:32 PM
>> >> To: Yogesh Narayan Gaur 
>> >> Cc: u-boot@lists.denx.de; York Sun 
>> >> Subject: Re: [PATCH] mtd/spi: Add MT35XU512ABA1G12 NOR flash support
>> >>
>> >> On Fri, Aug 11, 2017 at 3:30 PM, Yogesh Narayan Gaur
>> >>  wrote:
>> >> >
>> >> >
>> >> >> -Original Message-
>> >> >> From: Jagan Teki [mailto:jagannadh.t...@gmail.com]
>> >> >> Sent: Friday, August 11, 2017 3:25 PM
>> >> >> To: Yogesh Narayan Gaur 
>> >> >> Cc: u-boot@lists.denx.de; York Sun 
>> >> >> Subject: Re: [PATCH] mtd/spi: Add MT35XU512ABA1G12 NOR flash
>> >> >> support
>> >> >>
>> >> >> On Tue, Aug 1, 2017 at 9:43 AM, Yogesh Gaur
>> >> >> 
>> >> >> wrote:
>> >> >> > Add MT35XU512ABA1G12 parameters to NOR flash parameters array.
>> >> >> > Since the manufactory ID is changed to 0x2C, add it for micron
>> >> >> > and using it for relevant settings.
>> >> >> >
>> >> >> > The MT35XU512ABA1G12 only supports 1 bit mode and 8 bits. It
>> >> >> > can't support dual and quad. Supports subsector erase with 4KB
>> >> >> > granularity, have support of FSR(flag status register) and flash 
>> >> >> > size is
>> 64MB.
>> >> >> > ---
>> >> >> >  drivers/mtd/spi/sf_internal.h   | 1 +
>> >> >> >  drivers/mtd/spi/spi_flash.c | 2 ++
>> >> >> >  drivers/mtd/spi/spi_flash_ids.c | 1 +
>> >> >> >  3 files changed, 4 insertions(+)
>> >> >> >
>> >> >> > diff --git a/drivers/mtd/spi/sf_internal.h
>> >> >> > b/drivers/mtd/spi/sf_internal.h index 839cdbe..f46cb3a 100644
>> >> >> > --- a/drivers/mtd/spi/sf_internal.h
>> >> >> > +++ b/drivers/mtd/spi/sf_internal.h
>> >> >> > @@ -33,6 +33,7 @@ enum spi_nor_option_flags {
>> >> >> >  /* CFI Manufacture ID's */
>> >> >> >  #define SPI_FLASH_CFI_MFR_SPANSION 0x01
>> >> >> >  #define SPI_FLASH_CFI_MFR_STMICRO  0x20
>> >> >> > +#define SPI_FLASH_CFI_MFR_MICRON   0x2C
>> >> >>
>> >> >> Does this new mfr id from micro? so 0x20 still exists?
>> >> >>
>> >> > On older Micron flash like MT25QU512ABB mfr id still is 0x20 but in
>> >> > newer
>> >> flash, MT35X, it's been changed to 0x2c.
>> >>
>> >> OK, so the flash features like quad ennoblements, opcodes remains same?
>> >> except the mfr?
>> >>
>> > This flash support single bit and octal bit cmds no dual or quad support.
>> > Opcode for read/write/erase and other register operation related cmds are
>> similar to already supported flashes like MT25QU512ABB(n25q512a in existing
>> table).
>> > Only mfr id has been modified.
>>
>> OK.
>
> Did this patch needs to be modified further or can be upstreamed?

Yes, ie what I commented in previous thread.

thanks!
-- 
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v1] imx: remove SATA boot mode for i.MX 6UL and 6ULL

[Jagan Teki]

On Tue, Aug 29, 2017 at 10:16 PM, Stefano Babic  wrote:
> Hi Stefan,
>
> On 29/08/2017 18:10, Stefan Agner wrote:
>> From: Stefan Agner 
>>
>> The NXP i.MX 6UL and 6ULL do not support SATA and have no SATA
>> boot mode, hence remove it from the boot device detecion. This
>> fixes a build error introduced with 3bd1642d4d50 ("imx: fix USB
>> boot mode detection for i.MX 6UL and 6ULL")
>>
>> Fixes: 3bd1642d4d50 ("imx: fix USB boot mode detection for i.MX 6UL and 
>> 6ULL")
>> Signed-off-by: Stefan Agner 
>> ---
>>
>>  arch/arm/mach-imx/spl.c | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/arch/arm/mach-imx/spl.c b/arch/arm/mach-imx/spl.c
>> index bcd1033fdb..3853e7739d 100644
>> --- a/arch/arm/mach-imx/spl.c
>> +++ b/arch/arm/mach-imx/spl.c
>> @@ -45,8 +45,10 @@ u32 spl_boot_device(void)
>>   case IMX6_BMODE_RESERVED:
>>   return BOOT_DEVICE_BOARD;
>>   /* SATA: See 8.5.4, Table 8-20 */
>> +#if !defined(CONFIG_MX6UL) && !defined(CONFIG_MX6ULL)
>>   case IMX6_BMODE_SATA:
>>   return BOOT_DEVICE_SATA;
>> +#endif
>>   /* Serial ROM: See 8.5.5.1, Table 8-22 */
>>   case IMX6_BMODE_SERIAL_ROM:
>>   /* BOOT_CFG4[2:0] */
>>
>
> Reviewed-by: Stefano Babic 

Reviewed-by: Jagan Teki 

thanks!
-- 
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 00/23] efi_loader implement missing functions

[Heinrich Schuchardt]

On 08/29/2017 04:16 PM, Rob Clark wrote:
> On Tue, Aug 29, 2017 at 8:57 AM, Leif Lindholm  
> wrote:
>> On Tue, Aug 29, 2017 at 02:26:48PM +0200, Alexander Graf wrote:
>> I would add command
>> bootefi selftest.efi
>> to run the tests and provide the python wrapper code to add it to the
>> test suite.
>
> I think that's a great idea, yes.
 I wonder how far we are from running UEFI tests (either the official
 ones, or I seem to remember hearing about some other test suite which
 didn't require UEFI shell)?
>>>
>>> Let's ask Leif, Ard and Dong.
>>>
>>> The official test suite definitely needs the UEFI Shell. Is the suite
>>> publicly available by now?
>>
>> In binary form, you can access it already from the links on
>> http://uefi.org/testtools
>>
>> Yes, 2.5 is latest release. No this is not a restriction ... the SCT
>> releases have been lagging the specification releases a fair bit.
>>
>> The 2.5a package contains AARCH64, IA32 and X64 support (not ARM).
>> Not that it couldn't contain ARM, it just hasn't been packaged.
>>
 That seems more useful long term than re-inventing comprehensive UEFI
 test suite.  (Also, beyond just running shim/fallback/grub, I don't
 really have time to invent new tests for the stack of efi_loader
 patches I have.)
>>>
>>> Yes and no - it depends on the availability of the official suite :/.
>>
>> UEFI SCT is not yet open source/free software. Obviously, this is
>> something Linaro has been lobbying for since day one of our
>> involvement. There used to be little understanding for this, but that
>> attitude has shifted substantially.
> 
> So, if/until UEFI SCT is not an option, what about:
> 
>   https://01.org/linux-uefi-validation
> 
> (thx to pjones for pointing that out to me)
> 
> BR,
> -R



Unfortunately I do not get the image extracted from
https://01.org/linux-uefi-validation/downloads/luv-live-image-23
loaded:

qemu-system-x86_64 -m 1G -bios denx/u-boot.rom -nographic \
-netdev \
user,id=eth0,tftp=tftp,net=192.168.76.0/24,dhcpstart=192.168.76.9 \
-device e1000,netdev=eth0 -machine pc-i440fx-2.8
luv-v2.1_diskboot_mbr_i386_.img

-Boot 2017.09-rc2-P001-00255-g50e25c18b3 (Aug 29 2017 - 00:49:18 +0200)

CPU: x86_64, vendor AMD, device 663h
DRAM:  1 GiB
Using default environment

Video: 640x480x16
Model: QEMU x86 (I440FX)
Net:   e1000: 52:54:00:12:34:56

Warning: e1000#0 using MAC address from ROM
eth0: e1000#0
IDE:   Bus 0: OK Bus 1: OK
  Device 0: Model: QEMU HARDDISK  Firm: 2.5+ Ser#: QM1
Type: Hard Disk
Supports 48-bit addressing
Capacity: 118.0 MB = 0.1 GB (241664 x 512)
** Can't read Driver Desriptor Block **

Hopefully Petr knows what is wrong in the partition reading logic.

Heinrich

> 
> 
> 
>> I will let Dong fill in on what the current status actually get the
>> code into the open is.
>>
>> /
>> Leif
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] setup of PEX_GCLK_RATIO in E500 CPUs(P2010) missing ?

[Joakim Tjernlund]

On Tue, 2017-08-29 at 15:43 +, York Sun wrote:
> On 08/29/2017 06:21 AM, Joakim Tjernlund wrote:
> > On Tue, 2017-08-29 at 12:47 +0200, Joakim Tjernlund wrote:
> > > As we are looking at PCI stuff ATM I would like to ask
> > > about PEX_GCLK_RATIO in E500 CPUs. I cannot find this is setup
> > > at all for E500 but I THINK this is required.
> > > 
> > > In 83xx one do:
> > > get_clocks();
> > > /* Configure the PCIE controller core clock ratio */
> > > out_le32(hose_cfg_base + PEX_GCLK_RATIO,
> > 
> > A bit strange with out_le32 instead of out_be32 ?
> > 
> > > (((bus ? gd->arch.pciexp2_clk : gd->arch.pciexp1_clk)
> > > / 100) * 16) / 333);
> > > udelay(100);
> > > 
> > > Any clues?
> > > 
> > >   Jocke
> > 
> > Seems like only 83xx is setting this parameter.
> > 
> > Anyhow, I put together this patch:
> > 
> > --- a/drivers/pci/fsl_pci_init.c
> > +++ b/drivers/pci/fsl_pci_init.c
> > @@ -322,6 +322,10 @@ void fsl_pci_init(struct pci_controller *hose, struct 
> > fsl_pci_info *pci_info)
> >   
> >  pci_setup_indirect(hose, cfg_addr, cfg_data);
> >   
> > +   /* Configure the PCIE controller core clock ratio */
> > +   pci_hose_write_config_dword(hose, dev, 0x440, (gd->bus_clk / 
> > 3) * 16);
> > +   /* udelay(100) needed here ?*/
> > +
> >  block_rev = in_be32(>block_rev1);
> >  if (PEX_IP_BLK_REV_2_2 <= block_rev) {
> >  pi = >pit[2];  /* 0xDC0 */
> > 
> > Any chance this will work for all supported FSL PCIe controllers?
> > 
> 
> Jocke,
> 
> You don't need to program this register if the actual PCIe clock is the 
> same as default. Since SerDes reference clock has to be 100MHz for PCIe 
> protocol, my guess is the PCIe clock is always correct. The bus_clk you 
> are referring is not the PCIe clock. Again, I am not a PCIe expert, I 
> could be wrong. Since PCIe (SerDes) has been working on multiple 
> platforms, I guess the clock is correct.

I don't think so. Here is what T1042 says about this:

The PCI Express controller clock frequency is one-half the platform clock 
frequency.

The PCI Express controller core clock ratio register is used to program the 
ratio of the
actual PCI Express controller clock frequency to the default controller core 
frequency
( 333 MHz ). This is required only when a PCI Express controller clock 
frequency other
than the default 333 MHz has to be used.
As an example of programming PEX_GCLK_RATIO, consider the case where the actual
PCI Express controller clock is 250 MHz, the ratio of the actual clock to the 
default clock
( 333 MHz) is 3:4. that is, the default core clock has to be multiplied by the 
ratio (3/4,
which is equivalent to 12/16). So the register has to be programmed with the 
decimal
numerator value 12 or 0x_000C.

Our CCB is 250 MHz so this should be set to 0xc.

I found this on Google too:
The PEX controller hardware requires for timing tuning in order to operate 
properly at given CCB/2 clock
frequency. PEX_GCLK_RATIO register controls this tuning with 333MHz/16 
granularities. So for given CCB
frequency Fccb [MHz] we must write to PEX_GCLK_RATIO nearest integer of 
((Fccb/2)/(333/16)). So for Fccb=375
we have to write 18.

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

Re: [U-Boot] [PATCH 1/1] net: fix typos

[Joe Hershberger]

On Tue, Aug 29, 2017 at 11:44 AM, Heinrich Schuchardt
 wrote:
> %s/Desriptor/Descriptor/g
>
> Signed-off-by: Heinrich Schuchardt 

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

[U-Boot] [PATCH] pico-imx7d: Add "how to boot with NXP 4.1 Kernel"

[Vanessa Maegima]

The NXP 4.1 kernel needs to boot with secure boot.

Add information on how to enable secure boot mode.

Signed-off-by: Vanessa Maegima 
---
 board/technexion/pico-imx7d/README | 17 +
 1 file changed, 17 insertions(+)

diff --git a/board/technexion/pico-imx7d/README 
b/board/technexion/pico-imx7d/README
index a2805ee..8af4eff 100644
--- a/board/technexion/pico-imx7d/README
+++ b/board/technexion/pico-imx7d/README
@@ -47,3 +47,20 @@ Remove power from the pico board.
 Put pico board into normal boot mode.
 
 Power up the board and the new updated U-Boot should boot from eMMC.
+
+Building U-Boot to boot with NXP 4.1 kernel:
+
+The NXP 4.1 kernel boots only in secure boot mode on mx7.
+
+Follow the next steps to enable secure boot:
+
+$ make mrproper
+$ make pico-imx7d_defconfig
+$ make menuconfig
+   -> ARM architecture
+   -> [*] Enable support for booting in non-secure mode
+   -> [*]   Boot in secure mode by default
+   -> Exit
+$ make
+
+Flash u-boot.imx using the imx_usb_loader tool.
-- 
2.7.4

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

[U-Boot] [PATCH 1/1] net: fix typos

[Heinrich Schuchardt]

%s/Desriptor/Descriptor/g

Signed-off-by: Heinrich Schuchardt 
---
 drivers/net/fsl_mcdmafec.c | 2 +-
 drivers/net/mcffec.c   | 2 +-
 drivers/net/mvneta.c   | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/net/fsl_mcdmafec.c b/drivers/net/fsl_mcdmafec.c
index 26c714cc04..2d89cea4a3 100644
--- a/drivers/net/fsl_mcdmafec.c
+++ b/drivers/net/fsl_mcdmafec.c
@@ -391,7 +391,7 @@ static int fec_init(struct eth_device *dev, bd_t * bd)
/* Set Opcode/Pause Duration Register */
fecp->opd = 0x00010020;
 
-   /* Setup Buffers and Buffer Desriptors */
+   /* Setup Buffers and Buffer Descriptors */
info->rxIdx = 0;
info->txIdx = 0;
 
diff --git a/drivers/net/mcffec.c b/drivers/net/mcffec.c
index 39a6747320..ebcbed941a 100644
--- a/drivers/net/mcffec.c
+++ b/drivers/net/mcffec.c
@@ -465,7 +465,7 @@ int fec_init(struct eth_device *dev, bd_t * bd)
fecp->emrbr = PKT_MAXBLR_SIZE;
 
/*
-* Setup Buffers and Buffer Desriptors
+* Setup Buffers and Buffer Descriptors
 */
info->rxIdx = 0;
info->txIdx = 0;
diff --git a/drivers/net/mvneta.c b/drivers/net/mvneta.c
index 50577d7f07..f1be9521a9 100644
--- a/drivers/net/mvneta.c
+++ b/drivers/net/mvneta.c
@@ -540,7 +540,7 @@ static void mvneta_txq_pend_desc_add(struct mvneta_port *pp,
u32 val;
 
/* Only 255 descriptors can be added at once ; Assume caller
-* process TX desriptors in quanta less than 256
+* process TX descriptors in quanta less than 256
 */
val = pend_desc;
mvreg_write(pp, MVNETA_TXQ_UPDATE_REG(txq->id), val);
-- 
2.11.0

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

Re: [U-Boot] [PATCH v1] imx: remove SATA boot mode for i.MX 6UL and 6ULL

[Stefano Babic]

Hi Stefan,

On 29/08/2017 18:10, Stefan Agner wrote:
> From: Stefan Agner 
> 
> The NXP i.MX 6UL and 6ULL do not support SATA and have no SATA
> boot mode, hence remove it from the boot device detecion. This
> fixes a build error introduced with 3bd1642d4d50 ("imx: fix USB
> boot mode detection for i.MX 6UL and 6ULL")
> 
> Fixes: 3bd1642d4d50 ("imx: fix USB boot mode detection for i.MX 6UL and 6ULL")
> Signed-off-by: Stefan Agner 
> ---
> 
>  arch/arm/mach-imx/spl.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/arch/arm/mach-imx/spl.c b/arch/arm/mach-imx/spl.c
> index bcd1033fdb..3853e7739d 100644
> --- a/arch/arm/mach-imx/spl.c
> +++ b/arch/arm/mach-imx/spl.c
> @@ -45,8 +45,10 @@ u32 spl_boot_device(void)
>   case IMX6_BMODE_RESERVED:
>   return BOOT_DEVICE_BOARD;
>   /* SATA: See 8.5.4, Table 8-20 */
> +#if !defined(CONFIG_MX6UL) && !defined(CONFIG_MX6ULL)
>   case IMX6_BMODE_SATA:
>   return BOOT_DEVICE_SATA;
> +#endif
>   /* Serial ROM: See 8.5.5.1, Table 8-22 */
>   case IMX6_BMODE_SERIAL_ROM:
>   /* BOOT_CFG4[2:0] */
> 

Reviewed-by: Stefano Babic 

Best regards,
Stefano Babic

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

[U-Boot] [PATCH 1/1] disk: part: fix typo

[Heinrich Schuchardt]

%s/Desriptor/Descriptor/g

Fix lines over 80 characters with said typo.

Signed-off-by: Heinrich Schuchardt 
---
 disk/part_mac.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/disk/part_mac.c b/disk/part_mac.c
index b6c082e7e1..d597dcf00a 100644
--- a/disk/part_mac.c
+++ b/disk/part_mac.c
@@ -47,7 +47,10 @@ static int part_test_mac(struct blk_desc *dev_desc)
ulong i, n;
 
if (part_mac_read_ddb (dev_desc, ddesc)) {
-   /* error reading Driver Desriptor Block, or no valid Signature 
*/
+   /*
+* error reading Driver Descriptor Block,
+* or no valid Signature
+*/
return (-1);
}
 
@@ -71,7 +74,10 @@ static void part_print_mac(struct blk_desc *dev_desc)
ldiv_t mb, gb;
 
if (part_mac_read_ddb (dev_desc, ddesc)) {
-   /* error reading Driver Desriptor Block, or no valid Signature 
*/
+   /*
+* error reading Driver Descriptor Block,
+* or no valid Signature
+*/
return;
}
 
@@ -153,7 +159,7 @@ static int part_mac_read_ddb(struct blk_desc *dev_desc,
 mac_driver_desc_t *ddb_p)
 {
if (blk_dread(dev_desc, 0, 1, (ulong *)ddb_p) != 1) {
-   printf ("** Can't read Driver Desriptor Block **\n");
+   printf("** Can't read Driver Descriptor Block **\n");
return (-1);
}
 
-- 
2.11.0

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

Re: [U-Boot] [PATCH 00/23] efi_loader implement missing functions

[Leif Lindholm]

On Tue, Aug 29, 2017 at 05:59:41PM +0200, Heinrich Schuchardt wrote:
> On 08/29/2017 02:57 PM, Leif Lindholm wrote:
> > UEFI SCT is not yet open source/free software. Obviously, this is
> > something Linaro has been lobbying for since day one of our
> > involvement. There used to be little understanding for this, but that
> > attitude has shifted substantially.
> > 
> > I will let Dong fill in on what the current status actually get the
> > code into the open is.
> > 
> According to the accompanying information UEFI SCT requires a working
> UEFI shell. This rules out this test suite.

Hey, I was only replying to:

> > On Tue, Aug 29, 2017 at 02:26:48PM +0200, Alexander Graf wrote:
> >> The official test suite definitely needs the UEFI Shell. Is the suite
> >> publicly available by now?

But also, why does requiring a working UEFI Shell rule it out?
I mean, are there any reasons beyond UEFI Shell not currently being
functional under U-Boot?

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

Re: [U-Boot] setup of PEX_GCLK_RATIO in E500 CPUs(P2010) missing ?

[York Sun]

On 08/29/2017 06:21 AM, Joakim Tjernlund wrote:
> On Tue, 2017-08-29 at 12:47 +0200, Joakim Tjernlund wrote:
>> As we are looking at PCI stuff ATM I would like to ask
>> about PEX_GCLK_RATIO in E500 CPUs. I cannot find this is setup
>> at all for E500 but I THINK this is required.
>>
>> In 83xx one do:
>> get_clocks();
>> /* Configure the PCIE controller core clock ratio */
>> out_le32(hose_cfg_base + PEX_GCLK_RATIO,
> 
> A bit strange with out_le32 instead of out_be32 ?
> 
>> (((bus ? gd->arch.pciexp2_clk : gd->arch.pciexp1_clk)
>> / 100) * 16) / 333);
>> udelay(100);
>>
>> Any clues?
>>
>>   Jocke
> Seems like only 83xx is setting this parameter.
> 
> Anyhow, I put together this patch:
> 
> --- a/drivers/pci/fsl_pci_init.c
> +++ b/drivers/pci/fsl_pci_init.c
> @@ -322,6 +322,10 @@ void fsl_pci_init(struct pci_controller *hose, struct 
> fsl_pci_info *pci_info)
>   
>  pci_setup_indirect(hose, cfg_addr, cfg_data);
>   
> +   /* Configure the PCIE controller core clock ratio */
> +   pci_hose_write_config_dword(hose, dev, 0x440, (gd->bus_clk / 
> 3) * 16);
> +   /* udelay(100) needed here ?*/
> +
>  block_rev = in_be32(>block_rev1);
>  if (PEX_IP_BLK_REV_2_2 <= block_rev) {
>  pi = >pit[2];  /* 0xDC0 */
> 
> Any chance this will work for all supported FSL PCIe controllers?
> 

Jocke,

You don't need to program this register if the actual PCIe clock is the 
same as default. Since SerDes reference clock has to be 100MHz for PCIe 
protocol, my guess is the PCIe clock is always correct. The bus_clk you 
are referring is not the PCIe clock. Again, I am not a PCIe expert, I 
could be wrong. Since PCIe (SerDes) has been working on multiple 
platforms, I guess the clock is correct.

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

Re: [U-Boot] [PATCH 00/23] efi_loader implement missing functions

[Heinrich Schuchardt]

On 08/29/2017 02:57 PM, Leif Lindholm wrote:
> On Tue, Aug 29, 2017 at 02:26:48PM +0200, Alexander Graf wrote:
> I would add command
> bootefi selftest.efi
> to run the tests and provide the python wrapper code to add it to the
> test suite.

 I think that's a great idea, yes.
>>> I wonder how far we are from running UEFI tests (either the official
>>> ones, or I seem to remember hearing about some other test suite which
>>> didn't require UEFI shell)?
>>
>> Let's ask Leif, Ard and Dong.
>>
>> The official test suite definitely needs the UEFI Shell. Is the suite
>> publicly available by now?
> 
> In binary form, you can access it already from the links on
> http://uefi.org/testtools 
> 
> Yes, 2.5 is latest release. No this is not a restriction ... the SCT
> releases have been lagging the specification releases a fair bit.
> 
> The 2.5a package contains AARCH64, IA32 and X64 support (not ARM).
> Not that it couldn't contain ARM, it just hasn't been packaged.
> 
>>> That seems more useful long term than re-inventing comprehensive UEFI
>>> test suite.  (Also, beyond just running shim/fallback/grub, I don't
>>> really have time to invent new tests for the stack of efi_loader
>>> patches I have.)
>>
>> Yes and no - it depends on the availability of the official suite :/.
> 
> UEFI SCT is not yet open source/free software. Obviously, this is
> something Linaro has been lobbying for since day one of our
> involvement. There used to be little understanding for this, but that
> attitude has shifted substantially.
> 
> I will let Dong fill in on what the current status actually get the
> code into the open is.
> 
> /
> Leif
> 
According to the accompanying information UEFI SCT requires a working
UEFI shell. This rules out this test suite.

Regards

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

Re: [U-Boot] [PATCH 00/23] efi_loader implement missing functions

[Alexander Graf]

On 08/29/2017 06:06 PM, Leif Lindholm wrote:

On Tue, Aug 29, 2017 at 05:59:41PM +0200, Heinrich Schuchardt wrote:

On 08/29/2017 02:57 PM, Leif Lindholm wrote:

UEFI SCT is not yet open source/free software. Obviously, this is
something Linaro has been lobbying for since day one of our
involvement. There used to be little understanding for this, but that
attitude has shifted substantially.

I will let Dong fill in on what the current status actually get the
code into the open is.


According to the accompanying information UEFI SCT requires a working
UEFI shell. This rules out this test suite.

Hey, I was only replying to:


On Tue, Aug 29, 2017 at 02:26:48PM +0200, Alexander Graf wrote:

The official test suite definitely needs the UEFI Shell. Is the suite
publicly available by now?

But also, why does requiring a working UEFI Shell rule it out?


I don't think it rules it out, it just means it won't easily work today.


I mean, are there any reasons beyond UEFI Shell not currently being
functional under U-Boot?


No :). Someone just needs to sit down and debug why it doesn't work step 
by step.



Alex

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

Re: [U-Boot] [PATCH] mtd/spi: Add MT35XU512ABA1G12 NOR flash support

[Yogesh Narayan Gaur]

> -Original Message-
> From: Jagan Teki [mailto:jagannadh.t...@gmail.com]
> Sent: Friday, August 11, 2017 4:03 PM
> To: Yogesh Narayan Gaur 
> Cc: u-boot@lists.denx.de; York Sun 
> Subject: Re: [PATCH] mtd/spi: Add MT35XU512ABA1G12 NOR flash support
> 
> On Fri, Aug 11, 2017 at 3:38 PM, Yogesh Narayan Gaur
>  wrote:
> >
> >
> >> -Original Message-
> >> From: Jagan Teki [mailto:jagannadh.t...@gmail.com]
> >> Sent: Friday, August 11, 2017 3:32 PM
> >> To: Yogesh Narayan Gaur 
> >> Cc: u-boot@lists.denx.de; York Sun 
> >> Subject: Re: [PATCH] mtd/spi: Add MT35XU512ABA1G12 NOR flash support
> >>
> >> On Fri, Aug 11, 2017 at 3:30 PM, Yogesh Narayan Gaur
> >>  wrote:
> >> >
> >> >
> >> >> -Original Message-
> >> >> From: Jagan Teki [mailto:jagannadh.t...@gmail.com]
> >> >> Sent: Friday, August 11, 2017 3:25 PM
> >> >> To: Yogesh Narayan Gaur 
> >> >> Cc: u-boot@lists.denx.de; York Sun 
> >> >> Subject: Re: [PATCH] mtd/spi: Add MT35XU512ABA1G12 NOR flash
> >> >> support
> >> >>
> >> >> On Tue, Aug 1, 2017 at 9:43 AM, Yogesh Gaur
> >> >> 
> >> >> wrote:
> >> >> > Add MT35XU512ABA1G12 parameters to NOR flash parameters array.
> >> >> > Since the manufactory ID is changed to 0x2C, add it for micron
> >> >> > and using it for relevant settings.
> >> >> >
> >> >> > The MT35XU512ABA1G12 only supports 1 bit mode and 8 bits. It
> >> >> > can't support dual and quad. Supports subsector erase with 4KB
> >> >> > granularity, have support of FSR(flag status register) and flash size 
> >> >> > is
> 64MB.
> >> >> > ---
> >> >> >  drivers/mtd/spi/sf_internal.h   | 1 +
> >> >> >  drivers/mtd/spi/spi_flash.c | 2 ++
> >> >> >  drivers/mtd/spi/spi_flash_ids.c | 1 +
> >> >> >  3 files changed, 4 insertions(+)
> >> >> >
> >> >> > diff --git a/drivers/mtd/spi/sf_internal.h
> >> >> > b/drivers/mtd/spi/sf_internal.h index 839cdbe..f46cb3a 100644
> >> >> > --- a/drivers/mtd/spi/sf_internal.h
> >> >> > +++ b/drivers/mtd/spi/sf_internal.h
> >> >> > @@ -33,6 +33,7 @@ enum spi_nor_option_flags {
> >> >> >  /* CFI Manufacture ID's */
> >> >> >  #define SPI_FLASH_CFI_MFR_SPANSION 0x01
> >> >> >  #define SPI_FLASH_CFI_MFR_STMICRO  0x20
> >> >> > +#define SPI_FLASH_CFI_MFR_MICRON   0x2C
> >> >>
> >> >> Does this new mfr id from micro? so 0x20 still exists?
> >> >>
> >> > On older Micron flash like MT25QU512ABB mfr id still is 0x20 but in
> >> > newer
> >> flash, MT35X, it's been changed to 0x2c.
> >>
> >> OK, so the flash features like quad ennoblements, opcodes remains same?
> >> except the mfr?
> >>
> > This flash support single bit and octal bit cmds no dual or quad support.
> > Opcode for read/write/erase and other register operation related cmds are
> similar to already supported flashes like MT25QU512ABB(n25q512a in existing
> table).
> > Only mfr id has been modified.
> 
> OK.

Did this patch needs to be modified further or can be upstreamed?

> 
> And better remove the new CONFIG_ macro since the both chips have equal
> functionalities and anyway changes should managed by id table.
> the chip you defined under STMICRO ifdef :)
> 
> thanks!
> --
> Jagan Teki
> Free Software Engineer | www.openedev.com U-Boot, Linux | Upstream
> Maintainer Hyderabad, India.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] ARM: uniphier: enable Denali NAND driver for 64bit SoCs

[Masahiro Yamada]

Now the entry to the NAND driver init can be is controlled by DT;
it should not hurt to compile the driver all the time.

Signed-off-by: Masahiro Yamada 
---

 configs/uniphier_v8_defconfig | 5 +
 1 file changed, 5 insertions(+)

diff --git a/configs/uniphier_v8_defconfig b/configs/uniphier_v8_defconfig
index 066685f7b002..f4e183574580 100644
--- a/configs/uniphier_v8_defconfig
+++ b/configs/uniphier_v8_defconfig
@@ -31,6 +31,11 @@ CONFIG_I2C_EEPROM=y
 CONFIG_MMC_UNIPHIER=y
 CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_CADENCE=y
+CONFIG_NAND=y
+CONFIG_NAND_DENALI=y
+CONFIG_NAND_DENALI_DT=y
+CONFIG_SYS_NAND_DENALI_64BIT=y
+CONFIG_NAND_DENALI_SPARE_AREA_SKIP_BYTES=8
 CONFIG_SYSRESET=y
 CONFIG_SYSRESET_PSCI=y
 CONFIG_USB=y
-- 
2.7.4

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

Re: [U-Boot] [u-boot-release] [PATCH 2/3] armv8: ls1088a: SPL size reduction

[York Sun]

On 08/29/2017 12:02 AM, Sumit Garg wrote:
> Using changes in this patch we were able to reduce approx 8k
> size of u-boot-spl.bin image. Following is breif description of
> changes to reduce SPL size:
> 1. Changes in board/freescale/ls1088a/Makefile to remove
> compilation of eth.c and cpld.c in case of SPL build.
> 2. Changes in board/freescale/ls1088a/ls1088a.c to keep
> board_early_init_f funcations in case of SPL build.
> 3. Changes in ls1088a_common.h & ls1088ardb.h to remove driver
> specific macros due to which static data was being compiled in
> case of SPL build.
> 4. Enable CONFIG_SYS_DCACHE_OFF in case of SPL build as DCACHE is
> not being enabled in case of SPL image but was compiled in to
> add redundant code.
> 
> Signed-off-by: Sumit Garg 
> ---
> 
> Dependent on ls1088 base SD boot target. Also dependent on ls1088
> QPSI secure boot target.
> 
>   board/freescale/ls1088a/Makefile  |  4 +++-
>   board/freescale/ls1088a/ls1088a.c | 14 --
>   include/configs/ls1088a_common.h  | 20 
>   include/configs/ls1088ardb.h  | 20 
>   4 files changed, 51 insertions(+), 7 deletions(-)
> 
> diff --git a/board/freescale/ls1088a/Makefile 
> b/board/freescale/ls1088a/Makefile
> index bdcce9e..0e15031 100644
> --- a/board/freescale/ls1088a/Makefile
> +++ b/board/freescale/ls1088a/Makefile
> @@ -5,6 +5,8 @@
>   #
>   
>   obj-y += ls1088a.o
> +obj-y += ddr.o
> +ifndef CONFIG_SPL_BUILD
>   obj-$(CONFIG_TARGET_LS1088ARDB) += eth_ls1088ardb.o
>   obj-$(CONFIG_TARGET_LS1088AQDS) += eth_ls1088aqds.o
> -obj-y += ddr.o
> +endif
> diff --git a/board/freescale/ls1088a/ls1088a.c 
> b/board/freescale/ls1088a/ls1088a.c
> index 1860f9c..1c28ab4 100644
> --- a/board/freescale/ls1088a/ls1088a.c
> +++ b/board/freescale/ls1088a/ls1088a.c
> @@ -24,6 +24,13 @@
>   
>   DECLARE_GLOBAL_DATA_PTR;
>   
> +int board_early_init_f(void)
> +{
> + fsl_lsch3_early_init_f();
> + return 0;
> +}
> +
> +#if !defined(CONFIG_SPL_BUILD)
>   unsigned long long get_qixis_addr(void)
>   {
>   unsigned long long addr;
> @@ -324,12 +331,6 @@ int board_init(void)
>   return 0;
>   }
>   
> -int board_early_init_f(void)
> -{
> - fsl_lsch3_early_init_f();
> - return 0;
> -}
> -
>   void detail_board_ddr_info(void)
>   {
>   puts("\nDDR");
> @@ -404,3 +405,4 @@ int ft_board_setup(void *blob, bd_t *bd)
>   return 0;
>   }
>   #endif
> +#endif /* defined(CONFIG_SPL_BUILD) */
> diff --git a/include/configs/ls1088a_common.h 
> b/include/configs/ls1088a_common.h
> index 63b69f8..fb4c852 100644
> --- a/include/configs/ls1088a_common.h
> +++ b/include/configs/ls1088a_common.h
> @@ -7,6 +7,20 @@
>   #ifndef __LS1088_COMMON_H
>   #define __LS1088_COMMON_H
>   
> +/* SPL build */
> +#ifdef CONFIG_SPL_BUILD
> +#define SPL_NO_BOARDINFO
> +#define SPL_NO_QIXIS
> +#define SPL_NO_PCI
> +#define SPL_NO_ENV
> +#define SPL_NO_RTC
> +#define SPL_NO_USB
> +#define SPL_NO_SATA
> +#define SPL_NO_QSPI
> +#define SPL_NO_IFC
> +#define CONFIG_SYS_DCACHE_OFF

How much space can you save with data cache off? I prefer to leave the 
cache on. Cache is used if PPA is loaded in SPL stage for boost booting 
speed.

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

[U-Boot] [PATCH v1] imx: remove SATA boot mode for i.MX 6UL and 6ULL

[Stefan Agner]

From: Stefan Agner 

The NXP i.MX 6UL and 6ULL do not support SATA and have no SATA
boot mode, hence remove it from the boot device detecion. This
fixes a build error introduced with 3bd1642d4d50 ("imx: fix USB
boot mode detection for i.MX 6UL and 6ULL")

Fixes: 3bd1642d4d50 ("imx: fix USB boot mode detection for i.MX 6UL and 6ULL")
Signed-off-by: Stefan Agner 
---

 arch/arm/mach-imx/spl.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/mach-imx/spl.c b/arch/arm/mach-imx/spl.c
index bcd1033fdb..3853e7739d 100644
--- a/arch/arm/mach-imx/spl.c
+++ b/arch/arm/mach-imx/spl.c
@@ -45,8 +45,10 @@ u32 spl_boot_device(void)
case IMX6_BMODE_RESERVED:
return BOOT_DEVICE_BOARD;
/* SATA: See 8.5.4, Table 8-20 */
+#if !defined(CONFIG_MX6UL) && !defined(CONFIG_MX6ULL)
case IMX6_BMODE_SATA:
return BOOT_DEVICE_SATA;
+#endif
/* Serial ROM: See 8.5.5.1, Table 8-22 */
case IMX6_BMODE_SERIAL_ROM:
/* BOOT_CFG4[2:0] */
-- 
2.14.1

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

Re: [U-Boot] [PATCH 2/2] net: nfs: Correct type of rpc_t->u.reply->data

[Joe Hershberger]

Hi Tom,

On Sun, Aug 20, 2017 at 9:40 PM, Tom Rini  wrote:
> In rpc_t we declare data to be a uint8_t of size 2048, for a final size
> of 2048.  We also however declare the reply part of the union to have a
> uint32_t data field of NFS_READ_SIZE (1024) for a final size of
> 4096+24=4120 and an overrun.  Expand the comment above the struct to
> note that if NFS_READ_SIZE is increased then the data buf must also be
> increased and correct the declaration to be uint8_t.
>
> Reported-by: Coverity (CID: 152888)
> Cc: Joe Hershberger 
> Signed-off-by: Tom Rini 

This seems to be breaking one of the targets...
https://travis-ci.org/jhershbe/u-boot/jobs/269330530

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

Re: [U-Boot] [PATCH] imx: mx7: Add support for USB boot mode

[Eric Nelson]

Hi Troy,

On 08/28/2017 09:42 AM, Troy Kisky wrote:

On 8/27/2017 3:04 PM, Eric Nelson wrote:

This adds support for USB boot mode on the i.MX7D SoC, which
is most useful when doing U-Boot development on this chip.

i.e., it enables you to enter the ROM boot loader's serial
download protocol using the command:

=> bmode usb

Signed-off-by: Eric Nelson 
---
  arch/arm/mach-imx/mx7/soc.c | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/arch/arm/mach-imx/mx7/soc.c b/arch/arm/mach-imx/mx7/soc.c
index 87bf105..63ee59f 100644
--- a/arch/arm/mach-imx/mx7/soc.c
+++ b/arch/arm/mach-imx/mx7/soc.c
@@ -372,6 +372,8 @@ void set_wdog_reset(struct wdog_regs *wdog)
   * to SBMR1, which will determine the boot device.
   */
  const struct boot_mode soc_boot_modes[] = {


You might want to add

+   {"normal",  MAKE_CFGVAL(0x00, 0x00, 0x00, 0x00)},


while you're at it, to undo with "bmode normal"



Normal, meaning "don't override"?

Why would you want to do this?

Please advise,


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

Re: [U-Boot] setup of PEX_GCLK_RATIO in E500 CPUs(P2010) missing ?

[York Sun]

On 08/29/2017 03:47 AM, Joakim Tjernlund wrote:
> As we are looking at PCI stuff ATM I would like to ask
> about PEX_GCLK_RATIO in E500 CPUs. I cannot find this is setup
> at all for E500 but I THINK this is required.
> 
> In 83xx one do:
> get_clocks();
> /* Configure the PCIE controller core clock ratio */
> out_le32(hose_cfg_base + PEX_GCLK_RATIO,
> (((bus ? gd->arch.pciexp2_clk : gd->arch.pciexp1_clk)
> / 100) * 16) / 333);
> udelay(100);
> 
> Any clues?
> 

Jocke,

P2010 has SerDes. With PCIe, SerDes uses 100MHz reference clock. Please 
see reference manual "SerDes reference clock configuration".

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

Re: [U-Boot] [PATCH 00/23] efi_loader implement missing functions

[Rob Clark]

On Tue, Aug 29, 2017 at 8:57 AM, Leif Lindholm  wrote:
> On Tue, Aug 29, 2017 at 02:26:48PM +0200, Alexander Graf wrote:
>> > > > I would add command
>> > > > bootefi selftest.efi
>> > > > to run the tests and provide the python wrapper code to add it to the
>> > > > test suite.
>> > >
>> > > I think that's a great idea, yes.
>> > I wonder how far we are from running UEFI tests (either the official
>> > ones, or I seem to remember hearing about some other test suite which
>> > didn't require UEFI shell)?
>>
>> Let's ask Leif, Ard and Dong.
>>
>> The official test suite definitely needs the UEFI Shell. Is the suite
>> publicly available by now?
>
> In binary form, you can access it already from the links on
> http://uefi.org/testtools
>
> Yes, 2.5 is latest release. No this is not a restriction ... the SCT
> releases have been lagging the specification releases a fair bit.
>
> The 2.5a package contains AARCH64, IA32 and X64 support (not ARM).
> Not that it couldn't contain ARM, it just hasn't been packaged.
>
>> > That seems more useful long term than re-inventing comprehensive UEFI
>> > test suite.  (Also, beyond just running shim/fallback/grub, I don't
>> > really have time to invent new tests for the stack of efi_loader
>> > patches I have.)
>>
>> Yes and no - it depends on the availability of the official suite :/.
>
> UEFI SCT is not yet open source/free software. Obviously, this is
> something Linaro has been lobbying for since day one of our
> involvement. There used to be little understanding for this, but that
> attitude has shifted substantially.

So, if/until UEFI SCT is not an option, what about:

  https://01.org/linux-uefi-validation

(thx to pjones for pointing that out to me)

BR,
-R



> I will let Dong fill in on what the current status actually get the
> code into the open is.
>
> /
> Leif
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] ARM: uniphier: fix DSPLL init code for LD20 SoC

[Masahiro Yamada]

2017-08-28 21:57 GMT+09:00 Masahiro Yamada :
> From: Dai Okamura 
>
> Signed-off-by: Dai Okamura 
> Signed-off-by: Masahiro Yamada 
> ---

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

Re: [U-Boot] [PATCH] clk: uniphier: add System clock support

[Masahiro Yamada]

2017-08-29 1:06 GMT+09:00 Masahiro Yamada :
> Support system clocks for LD4, Pro4, sLD8, Pro5, PXs2/LD6b, LD11, LD20.
>
> Signed-off-by: Masahiro Yamada 
> ---

Applied to u-boot-uniphier.

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

Re: [U-Boot] setup of PEX_GCLK_RATIO in E500 CPUs(P2010) missing ?

[Joakim Tjernlund]

On Tue, 2017-08-29 at 12:47 +0200, Joakim Tjernlund wrote:
> As we are looking at PCI stuff ATM I would like to ask
> about PEX_GCLK_RATIO in E500 CPUs. I cannot find this is setup
> at all for E500 but I THINK this is required.
> 
> In 83xx one do:
> get_clocks();
> /* Configure the PCIE controller core clock ratio */
> out_le32(hose_cfg_base + PEX_GCLK_RATIO,

A bit strange with out_le32 instead of out_be32 ?

> (((bus ? gd->arch.pciexp2_clk : gd->arch.pciexp1_clk)
> / 100) * 16) / 333);
> udelay(100);
> 
> Any clues?
> 
>  Jocke
Seems like only 83xx is setting this parameter.

Anyhow, I put together this patch:

--- a/drivers/pci/fsl_pci_init.c
+++ b/drivers/pci/fsl_pci_init.c
@@ -322,6 +322,10 @@ void fsl_pci_init(struct pci_controller *hose, struct 
fsl_pci_info *pci_info)
 
pci_setup_indirect(hose, cfg_addr, cfg_data);
 
+   /* Configure the PCIE controller core clock ratio */
+   pci_hose_write_config_dword(hose, dev, 0x440, (gd->bus_clk / 3) 
* 16);
+   /* udelay(100) needed here ?*/
+
block_rev = in_be32(>block_rev1);
if (PEX_IP_BLK_REV_2_2 <= block_rev) {
pi = >pit[2];  /* 0xDC0 */

Any chance this will work for all supported FSL PCIe controllers?

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

[U-Boot] [PATCH] armv8: fsl-layerscape: Fix final MMU table for QSPI and IFC

[Suresh Gupta]

For QSPI and IFC addresses execution shouldn't be allowed
when u-boot running from DDR. Revise the MMU final table
to enforce execute-never bits.

Signed-off-by: Suresh Gupta 
---
 arch/arm/include/asm/arch-fsl-layerscape/cpu.h | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/arm/include/asm/arch-fsl-layerscape/cpu.h 
b/arch/arm/include/asm/arch-fsl-layerscape/cpu.h
index c4e5ecc..3d564d6 100644
--- a/arch/arm/include/asm/arch-fsl-layerscape/cpu.h
+++ b/arch/arm/include/asm/arch-fsl-layerscape/cpu.h
@@ -199,7 +199,8 @@ static struct mm_region final_map[] = {
},
{ CONFIG_SYS_FSL_QSPI_BASE1, CONFIG_SYS_FSL_QSPI_BASE1,
  CONFIG_SYS_FSL_QSPI_SIZE1,
- PTE_BLOCK_MEMTYPE(MT_NORMAL) | PTE_BLOCK_NON_SHARE
+ PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
+ PTE_BLOCK_NON_SHARE | PTE_BLOCK_PXN | PTE_BLOCK_UXN
},
{ CONFIG_SYS_FSL_QSPI_BASE2, CONFIG_SYS_FSL_QSPI_BASE2,
  CONFIG_SYS_FSL_QSPI_SIZE2,
@@ -208,7 +209,8 @@ static struct mm_region final_map[] = {
},
{ CONFIG_SYS_FSL_IFC_BASE2, CONFIG_SYS_FSL_IFC_BASE2,
  CONFIG_SYS_FSL_IFC_SIZE2,
- PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) | PTE_BLOCK_NON_SHARE
+ PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
+ PTE_BLOCK_NON_SHARE | PTE_BLOCK_PXN | PTE_BLOCK_UXN
},
{ CONFIG_SYS_FSL_DCSR_BASE, CONFIG_SYS_FSL_DCSR_BASE,
  CONFIG_SYS_FSL_DCSR_SIZE,
-- 
1.9.3

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

Re: [U-Boot] DA850evm SPI Flash Partitions between Linux and U-boot are Inconsistent

[Adam Ford]

On Tue, Aug 29, 2017 at 6:41 AM, Sekhar Nori  wrote:
> On Tuesday 29 August 2017 03:29 PM, Adam Ford wrote:
>> On Tue, Aug 29, 2017 at 4:13 AM, Sekhar Nori  wrote:
>>> Hi Adam,
>>>
>>> On Sunday 27 August 2017 08:31 PM, Adam Ford wrote:
 I was trying to enable MTD Partitions to make loading the Kernel and
 FS easier from within U-Boot

 The da850evm spi-flash partitions in Linux show

 "U-Boot-SPL" @ offset 0, size 64K
 "U-Boot"; @ offset 0x0001, size 512K
 "U-Boot-Env"; @ offset 0x0009
>>>
>>> According to board/davinci/da8xxevm/README.da850, we support AIS image
>>> format for SPI boot. This is a single image containing SPL and U-Boot.
>>>
>>> Given this, I think having separate partitions for SPL and U-Boot does
>>> not make sense since thats not how its going to be used.
>>
>> That's what I was thinking too, but I wasn't sure if someone had split
>> SPL somehow to make it possible to update U-Boot via Linux or U-Boot
>> itself.
>>>

 However U-Boot shows the following:

 CONFIG_SYS_SPI_U_BOOT_OFFS 0x8000 which would make the SPL partition 32K.
 CONFIG_SYS_SPI_U_BOOT_SIZE  0x4 and the size of U-boot 256K
 instead of 512k.

 CONFIG_ENV_SIZE (64 << 10)
 CONFIG_ENV_OFFSET   (512 << 10) which is 0x8 instead of
 Linux's 0x9

 It seems to me like the U-Boot and Linux should try and synchronize
 their partitions tables.
>>>
>>> Right.
>>>
 For people who want to burn Linux into the SPI flash it seems there
 there should be some consistency.  I tried making the U-boot settings
 match the Linux ones, but it seems to hang between SPL and U-Boot, so
 I think the U-Boot offset in Linux might need to match U-Boot.  Can
 you guys make some recomendations as to which is correct?
>>>
>>> I have not tried it, but looks like the partitions we need are
>>>
>>> "SPL/U-Boot AIS" @ offset 0, size 512K
>>> "U-Boot Environment" @ offset 512K, size 64K
>>
>> I was thinking the same thing.
>>
>>> "Kernel/Spare" @ offset 576K, size 7552K
>>> "Mac Address" @ offset 8128K, size 64K (read only)
>>
>> If U-Boot reads the MAC address from its environmental variables
>> instead of using up an entire 64K for what conceivably is 6 bytes,
>> could we free up this space to help grow the Kernel/Spare space?
>
> If environment sector is erased, the mac address needs to be restored
> from SPI flash. Thats why I think it needs to remain as a read-only
> partition. Also, its just 64K more space, not sure if it will make a big
> difference in the overall scheme of things.
>
>>> With an 8M flash, I think its futile to try to fit a modern filesystem
>>> on the flash.
>>>
>>> If you are using DT boot, we cannot really change the partitions in
>>> device-tree because of DT backward-compatibility requirements. But we
>>> can fix da850evm_spiflash_part[] table in
>>> arch/arm/mach-davinci/board-da850-evm.c.
>>
>> Wouldn't having two different partition tables between da850-evm.c and
>> the DT cause confusion down the road?  With DT being the future, why
>> would we not try to eliminate any custom board files with just a
>> single common davinci board file + board specific DT?
>
> Thats ideal yes. But there is a lot of support in the da850-evm board
> file which does not have a DT equivalent yet. Thats why I have kept the
> board file around.
>
>>> To help DT boot, we can pass fixed up mtdparts through environment
>>> variables. Something like what is done in 3f18ff07c81b ("ARM: keystone:
>>> Pass SPI MTD partition table via kernel command line").
>>
>> This was ultimately was I was wanting to do.  For some of the OMAP3
>> boards, removing the partition tree was accepted since the partition
>> info was passed to the kernel.  If we did this for DA850, we could
>> simply elimiate the partition info in the Kernel (like some of the
>> omap3 boards) and let the partition maps be defined by U-Boot would
>> would guarantee consistency between them.
>
> Actually, thinking a bit more, we cannot change the partition
> information in kernel at all since that means loss of data for anyone
> updating just the kernel.
>
> We can however, pass updated kernel command line arguments in U-Boot so
> anyone updating the bootloader and erasing the environment sector gets
> updated partition information. This is likely to be the case where
> entire flash is being re-written and loss of data is not a concern.
>
That makes sense to me.

I'll send a U-Boot patch marked RFC later today with the MTD stuff
enabled in U-Boot and changes to the bootargs to pass the MTD
information to Linux.


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

Re: [U-Boot] [PATCH] imx6: drop duplicated bss memset and board_init_r() call

[Fabio Estevam]

On Mon, Aug 28, 2017 at 3:58 PM, Anatolij Gustschin  wrote:
> bss section is cleared in crt0.S. board_init_r() is also
> entered from crt0 code.
>
> Signed-off-by: Anatolij Gustschin 

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

Re: [U-Boot] [PATCH 00/23] efi_loader implement missing functions

[Leif Lindholm]

On Tue, Aug 29, 2017 at 02:26:48PM +0200, Alexander Graf wrote:
> > > > I would add command
> > > > bootefi selftest.efi
> > > > to run the tests and provide the python wrapper code to add it to the
> > > > test suite.
> > > 
> > > I think that's a great idea, yes.
> > I wonder how far we are from running UEFI tests (either the official
> > ones, or I seem to remember hearing about some other test suite which
> > didn't require UEFI shell)?
> 
> Let's ask Leif, Ard and Dong.
> 
> The official test suite definitely needs the UEFI Shell. Is the suite
> publicly available by now?

In binary form, you can access it already from the links on
http://uefi.org/testtools 

Yes, 2.5 is latest release. No this is not a restriction ... the SCT
releases have been lagging the specification releases a fair bit.

The 2.5a package contains AARCH64, IA32 and X64 support (not ARM).
Not that it couldn't contain ARM, it just hasn't been packaged.

> > That seems more useful long term than re-inventing comprehensive UEFI
> > test suite.  (Also, beyond just running shim/fallback/grub, I don't
> > really have time to invent new tests for the stack of efi_loader
> > patches I have.)
> 
> Yes and no - it depends on the availability of the official suite :/.

UEFI SCT is not yet open source/free software. Obviously, this is
something Linaro has been lobbying for since day one of our
involvement. There used to be little understanding for this, but that
attitude has shifted substantially.

I will let Dong fill in on what the current status actually get the
code into the open is.

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

[U-Boot] [PATCH v2] spi: fsl_qspi: Add controller busy check before new spi operation

[Suresh Gupta]

It is recommended to check either controller is free to take
new spi action. The IP_ACC and AHB_ACC bits indicates that
the controller is busy in IP or AHB mode respectively.
And the BUSY bit indicates that controller is currently
busy handling a transaction to an external flash device

Signed-off-by: Suresh Gupta 
---
Changes in v2:

- Add wait_for_bit instead of while
- move the busy check code to fsl_qspi_claim_bus form qspi_xfer

 drivers/spi/fsl_qspi.c | 28 +++-
 drivers/spi/fsl_qspi.h |  4 
 2 files changed, 31 insertions(+), 1 deletion(-)

diff --git a/drivers/spi/fsl_qspi.c b/drivers/spi/fsl_qspi.c
index 1dfa89a..ed23aac 100644
--- a/drivers/spi/fsl_qspi.c
+++ b/drivers/spi/fsl_qspi.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "fsl_qspi.h"
 
 DECLARE_GLOBAL_DATA_PTR;
@@ -991,7 +992,7 @@ static int fsl_qspi_probe(struct udevice *bus)
struct fsl_qspi_platdata *plat = dev_get_platdata(bus);
struct fsl_qspi_priv *priv = dev_get_priv(bus);
struct dm_spi_bus *dm_spi_bus;
-   int i;
+   int i, ret;
 
dm_spi_bus = bus->uclass_priv;
 
@@ -1011,6 +1012,18 @@ static int fsl_qspi_probe(struct udevice *bus)
priv->flash_num = plat->flash_num;
priv->num_chipselect = plat->num_chipselect;
 
+   /* make sure controller is not busy anywhere */
+   ret = wait_for_bit(__func__, >regs->sr,
+  QSPI_SR_BUSY_MASK |
+  QSPI_SR_AHB_ACC_MASK |
+  QSPI_SR_IP_ACC_MASK,
+  false, 1000, false);
+
+   if (ret) {
+   printf("ERROR : The controller is busy\n");
+   return -EBUSY;
+   }
+
mcr_val = qspi_read32(priv->flags, >regs->mcr);
qspi_write32(priv->flags, >regs->mcr,
 QSPI_MCR_RESERVED_MASK | QSPI_MCR_MDIS_MASK |
@@ -1156,10 +1169,23 @@ static int fsl_qspi_claim_bus(struct udevice *dev)
struct fsl_qspi_priv *priv;
struct udevice *bus;
struct dm_spi_slave_platdata *slave_plat = dev_get_parent_platdata(dev);
+   int ret;
 
bus = dev->parent;
priv = dev_get_priv(bus);
 
+   /* make sure controller is not busy anywhere */
+   ret = wait_for_bit(__func__, >regs->sr,
+  QSPI_SR_BUSY_MASK |
+  QSPI_SR_AHB_ACC_MASK |
+  QSPI_SR_IP_ACC_MASK,
+  false, 1000, false);
+
+   if (ret) {
+   printf("ERROR : The controller is busy\n");
+   return -EBUSY;
+   }
+
priv->cur_amba_base = priv->amba_base[slave_plat->cs];
 
qspi_module_disable(priv, 0);
diff --git a/drivers/spi/fsl_qspi.h b/drivers/spi/fsl_qspi.h
index 6cb3610..e468eb2 100644
--- a/drivers/spi/fsl_qspi.h
+++ b/drivers/spi/fsl_qspi.h
@@ -105,6 +105,10 @@ struct fsl_qspi_regs {
 #define QSPI_RBCT_RXBRD_SHIFT  8
 #define QSPI_RBCT_RXBRD_USEIPS (1 << QSPI_RBCT_RXBRD_SHIFT)
 
+#define QSPI_SR_AHB_ACC_SHIFT  2
+#define QSPI_SR_AHB_ACC_MASK   (1 << QSPI_SR_AHB_ACC_SHIFT)
+#define QSPI_SR_IP_ACC_SHIFT   1
+#define QSPI_SR_IP_ACC_MASK(1 << QSPI_SR_IP_ACC_SHIFT)
 #define QSPI_SR_BUSY_SHIFT 0
 #define QSPI_SR_BUSY_MASK  (1 << QSPI_SR_BUSY_SHIFT)
 
-- 
1.9.3

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

Re: [U-Boot] [PATCH 05/19] arm: socfpga: Enhance FPGA program support with at least 4 byte data

[Marek Vasut]

On 08/29/2017 12:45 PM, tien.fong.c...@intel.com wrote:
> From: Tien Fong Chee 
> 
> This patch enables FPGA program with minimum 4 byte data size.

What does that mean ? Expand the description, it's inobvious

> Signed-off-by: Tien Fong Chee 
> ---
>  drivers/fpga/socfpga.c |   14 --
>  1 files changed, 8 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/fpga/socfpga.c b/drivers/fpga/socfpga.c
> index 28fa16b..6e14ebd 100644
> --- a/drivers/fpga/socfpga.c
> +++ b/drivers/fpga/socfpga.c
> @@ -1,5 +1,5 @@
>  /*
> - * Copyright (C) 2012 Altera Corporation 
> + * Copyright (C) 2012-2017 Altera Corporation 
>   * All rights reserved.
>   *
>   * SPDX-License-Identifier:  BSD-3-Clause
> @@ -55,18 +55,20 @@ void fpgamgr_program_write(const void *rbf_data, size_t 
> rbf_size)
>   uint32_t loops4 = DIV_ROUND_UP(rbf_size % 32, 4);
>  
>   asm volatile(
> + "   cmp %2, #0\n"
> + "   beq 2f\n"
>   "1: ldmia   %0!,{r0-r7}\n"
>   "   stmia   %1!,{r0-r7}\n"
>   "   sub %1, #32\n"
>   "   subs%2, #1\n"
>   "   bne 1b\n"
> - "   cmp %3, #0\n"
> - "   beq 3f\n"
> - "2: ldr %2, [%0],   #4\n"
> + "2: cmp %3, #0\n"
> + "   beq 4f\n"
> + "3: ldr %2, [%0],   #4\n"
>   "   str %2, [%1]\n"
>   "   subs%3, #1\n"
> - "   bne 2b\n"
> - "3: nop\n"
> + "   bne 3b\n"
> + "4: nop\n"
>   : "+r"(src), "+r"(dst), "+r"(loops32), "+r"(loops4) :
>   : "r0", "r1", "r2", "r3", "r4", "r5", "r6", "r7", "cc");
>  }
> 


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

Re: [U-Boot] [PATCH 00/23] efi_loader implement missing functions

[Alexander Graf]

On 08/29/2017 12:52 PM, Heinrich Schuchardt wrote:

On 08/27/2017 10:10 PM, Simon Glass wrote:

Hi Heinrich,

On 26 August 2017 at 16:51, Heinrich Schuchardt  wrote:

This patch sequence contains all patches needed to load
iPXE and use it for downloading and executing images
via https or http or to mount iSCSI volumes.

Network speed on an Odroid C2 reached 30 MB/s which should be
enough for most use cases.

I have tested the following iPXE commands successfully
* dhcp
* route
* ntp
* sanhook iSCSI-target
* chain http-target
* kernel http-target
* boot (after calling kernel)
* exit
* reboot

The only adjustment in iPXE was adding file src/config/local/nap.h with
   #undef NAP_EFIX86
   #undef NAP_EFIARM
   #define NAP_NULL
and src/config/local/myscript.ipxe with
   #!ipxe
   shell
before building iPXE with
   make bin-arm64-efi/snp.efi EMBED=config/local/myscript.ipxe

The next task will be to put iXPE binaries on a server
and to create Travis CI test cases.

Some general comments on the series as a whole:

1. It really needs to have tests. This is a lot of new code in U-Boot,
and relying on travis CI test cases (which takes forever to run) is
not a good option. We have a 'make tests' target which you should hook
into, via the pytests framework. This runs in a minute or so. There is
quite a bit of documentation in test/py for this. It should be easy
enough to build up the data structures in sandbox and then test that
each function does what is expected.

2. Exported functions should be commented to describe their purpose,
arguments and return value. Non-trivial static functions should be
commented too.

Regards,
Simon


Hello Alex,


I think you meant to say Hello Simon?



testing the EFI API is only possible from an EFI program.

I suggest to build an EFI app selftest.efi like the helloworld.efi have.
I would add command
bootefi selftest.efi
to run the tests and provide the python wrapper code to add it to the
test suite.


I think that's a great idea, yes.



There are some very simple patches which you may decide to cherry pick,
notably

[PATCH 02/23] efi_loader: notify when ExitBootServices is invoked
[PATCH 03/23] efi_loader: support 16 protocols per efi_object
[PATCH 17/23] efi_loader: efi_net: hwaddr_size = 6
[PATCH 18/23] efi_net: return EFI_UNSUPPORTED where appropriate


How important are those? I would ideally like to see the unit test thing 
first, then add new functionality :)



Alex

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

Re: [U-Boot] [PATCH 00/23] efi_loader implement missing functions

[Alexander Graf]

On 08/29/2017 02:17 PM, Rob Clark wrote:

On Tue, Aug 29, 2017 at 7:45 AM, Alexander Graf  wrote:

On 08/29/2017 12:52 PM, Heinrich Schuchardt wrote:

On 08/27/2017 10:10 PM, Simon Glass wrote:

Hi Heinrich,

On 26 August 2017 at 16:51, Heinrich Schuchardt 
wrote:

This patch sequence contains all patches needed to load
iPXE and use it for downloading and executing images
via https or http or to mount iSCSI volumes.

Network speed on an Odroid C2 reached 30 MB/s which should be
enough for most use cases.

I have tested the following iPXE commands successfully
* dhcp
* route
* ntp
* sanhook iSCSI-target
* chain http-target
* kernel http-target
* boot (after calling kernel)
* exit
* reboot

The only adjustment in iPXE was adding file src/config/local/nap.h with
#undef NAP_EFIX86
#undef NAP_EFIARM
#define NAP_NULL
and src/config/local/myscript.ipxe with
#!ipxe
shell
before building iPXE with
make bin-arm64-efi/snp.efi EMBED=config/local/myscript.ipxe

The next task will be to put iXPE binaries on a server
and to create Travis CI test cases.

Some general comments on the series as a whole:

1. It really needs to have tests. This is a lot of new code in U-Boot,
and relying on travis CI test cases (which takes forever to run) is
not a good option. We have a 'make tests' target which you should hook
into, via the pytests framework. This runs in a minute or so. There is
quite a bit of documentation in test/py for this. It should be easy
enough to build up the data structures in sandbox and then test that
each function does what is expected.

2. Exported functions should be commented to describe their purpose,
arguments and return value. Non-trivial static functions should be
commented too.

Regards,
Simon


Hello Alex,


I think you meant to say Hello Simon?


testing the EFI API is only possible from an EFI program.

I suggest to build an EFI app selftest.efi like the helloworld.efi have.
I would add command
bootefi selftest.efi
to run the tests and provide the python wrapper code to add it to the
test suite.


I think that's a great idea, yes.

I wonder how far we are from running UEFI tests (either the official
ones, or I seem to remember hearing about some other test suite which
didn't require UEFI shell)?


Let's ask Leif, Ard and Dong.

The official test suite definitely needs the UEFI Shell. Is the suite 
publicly available by now?



That seems more useful long term than re-inventing comprehensive UEFI
test suite.  (Also, beyond just running shim/fallback/grub, I don't
really have time to invent new tests for the stack of efi_loader
patches I have.)


Yes and no - it depends on the availability of the official suite :/.



If there is a TODO list of what is required to get to the point where
we can run existing UEFI tests, I can try and pick off bits and pieces
here and there as I have time.


Let's ask the others :)


Alex

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

Re: [U-Boot] [PATCH 04/19] arm: socfpga: Add FPGA loadfs command support

[Marek Vasut]

On 08/29/2017 12:45 PM, tien.fong.c...@intel.com wrote:
> From: Tien Fong Chee 
> 
> This patch enables FPGA loadfs command support to U-boot console.
> 
> Signed-off-by: Tien Fong Chee 

But you enabled support for this in patch 1/19 ... ordering issue ?
Patch changelog doesn't match what the patch does ...

> ---
>  cmd/fpga.c|2 +-
>  drivers/fpga/altera.c |   38 ++
>  drivers/fpga/fpga.c   |8 
>  include/fpga.h|2 ++
>  4 files changed, 41 insertions(+), 9 deletions(-)
> 
> diff --git a/cmd/fpga.c b/cmd/fpga.c
> index 016349f..28e6628 100644
> --- a/cmd/fpga.c
> +++ b/cmd/fpga.c
> @@ -363,7 +363,7 @@ U_BOOT_CMD(fpga, 6, 1, do_fpga,
>  "(Xilinx only)\n"
>  #endif
>  #if defined(CONFIG_CMD_FPGA_LOADFS)
> -"Load device from filesystem (FAT by default) (Xilinx only)\n"
> +"Load device from filesystem (FAT by default)\n"
>  "  loadfs [dev] [address] [image size] [blocksize] \n"
>  "[] \n"
>  #endif
> diff --git a/drivers/fpga/altera.c b/drivers/fpga/altera.c
> index 135a357..8b60bd5 100644
> --- a/drivers/fpga/altera.c
> +++ b/drivers/fpga/altera.c
> @@ -23,25 +23,30 @@ static const struct altera_fpga {
>   enum altera_family  family;
>   const char  *name;
>   int (*load)(Altera_desc *, const void *, size_t);
> + int (*loadfs)(Altera_desc *, const void *, size_t,
> +  fpga_fs_info *);
>   int (*dump)(Altera_desc *, const void *, size_t);
>   int (*info)(Altera_desc *);
>  } altera_fpga[] = {
>  #if defined(CONFIG_FPGA_ACEX1K)
> - { Altera_ACEX1K, "ACEX1K", ACEX1K_load, ACEX1K_dump, ACEX1K_info },
> - { Altera_CYC2,   "ACEX1K", ACEX1K_load, ACEX1K_dump, ACEX1K_info },
> + { Altera_ACEX1K, "ACEX1K", ACEX1K_load, NULL, ACEX1K_dump, ACEX1K_info 
> },
> + { Altera_CYC2,   "ACEX1K", ACEX1K_load, NULL, ACEX1K_dump, ACEX1K_info 
> },
>  #elif defined(CONFIG_FPGA_CYCLON2)
> - { Altera_ACEX1K, "CycloneII", CYC2_load, CYC2_dump, CYC2_info },
> - { Altera_CYC2,   "CycloneII", CYC2_load, CYC2_dump, CYC2_info },
> + { Altera_ACEX1K, "CycloneII", CYC2_load, NULL, CYC2_dump, CYC2_info },
> + { Altera_CYC2,   "CycloneII", CYC2_load, NULL, CYC2_dump, CYC2_info },
>  #endif
>  #if defined(CONFIG_FPGA_STRATIX_II)
> - { Altera_StratixII, "StratixII", StratixII_load,
> + { Altera_StratixII, "StratixII", StratixII_load, NULL,
> StratixII_dump, StratixII_info },
>  #endif
>  #if defined(CONFIG_FPGA_STRATIX_V)
> - { Altera_StratixV, "StratixV", stratixv_load, NULL, NULL },
> + { Altera_StratixV, "StratixV", stratixv_load, NULL, NULL, NULL },
>  #endif
> -#if defined(CONFIG_FPGA_SOCFPGA)
> - { Altera_SoCFPGA, "SoC FPGA", socfpga_load, NULL, NULL },
> +#if defined(CONFIG_FPGA_SOCFPGA) && !defined(CONFIG_CMD_FPGA_LOADFS)
> + { Altera_SoCFPGA, "SoC FPGA", socfpga_load, NULL, NULL, NULL },
> +#endif
> +#if defined(CONFIG_FPGA_SOCFPGA) && defined(CONFIG_CMD_FPGA_LOADFS)
> + { Altera_SoCFPGA, "SoC FPGA", socfpga_load, socfpga_loadfs, NULL, NULL 
> },
>  #endif
>  };
>  
> @@ -174,3 +179,20 @@ int altera_info(Altera_desc *desc)
>  
>   return FPGA_SUCCESS;
>  }
> +
> +#if defined(CONFIG_CMD_FPGA_LOADFS)
> +int altera_loadfs(Altera_desc *desc, const void *buf, size_t bsize,
> +fpga_fs_info *fpga_fsinfo)
> +{
> + const struct altera_fpga *fpga = altera_desc_to_fpga(desc, __func__);
> +
> + if (!fpga)
> + return FPGA_FAIL;
> +
> + debug_cond(FPGA_DEBUG, "%s: Launching the %s FS Loader...\n",
> +__func__, fpga->name);
> + if (fpga->loadfs)
> + return fpga->loadfs(desc, buf, bsize, fpga_fsinfo);
> + return 0;
> +}
> +#endif
> diff --git a/drivers/fpga/fpga.c b/drivers/fpga/fpga.c
> index e0fb1b4..42e901e 100644
> --- a/drivers/fpga/fpga.c
> +++ b/drivers/fpga/fpga.c
> @@ -198,6 +198,14 @@ int fpga_fsload(int devnum, const void *buf, size_t size,
>   fpga_no_sup((char *)__func__, "Xilinx devices");
>  #endif
>   break;
> +#if defined(CONFIG_FPGA_ALTERA)
> + case fpga_altera:
> + ret_val = altera_loadfs(desc->devdesc, buf, size,
> + fpga_fsinfo);

Why is this not a generic code ? Load stuff from FS and program it into
the FPGA directly, should be pretty generic operation IMO.

> +#else
> + fpga_no_sup((char *)__func__, "Altera devices");
> +#endif
> + break;
>   default:
>   printf("%s: Invalid or unsupported device type %d\n",
>  __func__, desc->devtype);
> diff --git a/include/fpga.h b/include/fpga.h
> index d768fb1..8920016 100644
> --- 

Re: [U-Boot] [PATCH 00/23] efi_loader implement missing functions

[Rob Clark]

On Tue, Aug 29, 2017 at 7:45 AM, Alexander Graf  wrote:
> On 08/29/2017 12:52 PM, Heinrich Schuchardt wrote:
>>
>> On 08/27/2017 10:10 PM, Simon Glass wrote:
>>>
>>> Hi Heinrich,
>>>
>>> On 26 August 2017 at 16:51, Heinrich Schuchardt 
>>> wrote:

 This patch sequence contains all patches needed to load
 iPXE and use it for downloading and executing images
 via https or http or to mount iSCSI volumes.

 Network speed on an Odroid C2 reached 30 MB/s which should be
 enough for most use cases.

 I have tested the following iPXE commands successfully
 * dhcp
 * route
 * ntp
 * sanhook iSCSI-target
 * chain http-target
 * kernel http-target
 * boot (after calling kernel)
 * exit
 * reboot

 The only adjustment in iPXE was adding file src/config/local/nap.h with
#undef NAP_EFIX86
#undef NAP_EFIARM
#define NAP_NULL
 and src/config/local/myscript.ipxe with
#!ipxe
shell
 before building iPXE with
make bin-arm64-efi/snp.efi EMBED=config/local/myscript.ipxe

 The next task will be to put iXPE binaries on a server
 and to create Travis CI test cases.
>>>
>>> Some general comments on the series as a whole:
>>>
>>> 1. It really needs to have tests. This is a lot of new code in U-Boot,
>>> and relying on travis CI test cases (which takes forever to run) is
>>> not a good option. We have a 'make tests' target which you should hook
>>> into, via the pytests framework. This runs in a minute or so. There is
>>> quite a bit of documentation in test/py for this. It should be easy
>>> enough to build up the data structures in sandbox and then test that
>>> each function does what is expected.
>>>
>>> 2. Exported functions should be commented to describe their purpose,
>>> arguments and return value. Non-trivial static functions should be
>>> commented too.
>>>
>>> Regards,
>>> Simon
>>>
>> Hello Alex,
>
>
> I think you meant to say Hello Simon?
>
>>
>> testing the EFI API is only possible from an EFI program.
>>
>> I suggest to build an EFI app selftest.efi like the helloworld.efi have.
>> I would add command
>> bootefi selftest.efi
>> to run the tests and provide the python wrapper code to add it to the
>> test suite.
>
>
> I think that's a great idea, yes.

I wonder how far we are from running UEFI tests (either the official
ones, or I seem to remember hearing about some other test suite which
didn't require UEFI shell)?

That seems more useful long term than re-inventing comprehensive UEFI
test suite.  (Also, beyond just running shim/fallback/grub, I don't
really have time to invent new tests for the stack of efi_loader
patches I have.)

If there is a TODO list of what is required to get to the point where
we can run existing UEFI tests, I can try and pick off bits and pieces
here and there as I have time.

BR,
-R

>>
>> There are some very simple patches which you may decide to cherry pick,
>> notably
>>
>> [PATCH 02/23] efi_loader: notify when ExitBootServices is invoked
>> [PATCH 03/23] efi_loader: support 16 protocols per efi_object
>> [PATCH 17/23] efi_loader: efi_net: hwaddr_size = 6
>> [PATCH 18/23] efi_net: return EFI_UNSUPPORTED where appropriate
>
>
> How important are those? I would ideally like to see the unit test thing
> first, then add new functionality :)
>
>
> Alex
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot