Re: [U-Boot] [PATCH V2 5/6] ARM: dts: k2g: Add support for PMMC

[Nishanth Menon]

Tom,


On Fri, Feb 26, 2016 at 6:27 PM, Tom Rini  wrote:
> On Fri, Feb 26, 2016 at 06:18:30PM -0600, Nishanth Menon wrote:
>> On Fri, Feb 26, 2016 at 12:18 PM, Tom Rini  wrote:
>> > On Thu, Feb 25, 2016 at 12:53:46PM -0600, Nishanth Menon wrote:
[...]
>> >
>> > ... and this will match whatever is in the kernel, right?
>>
>> The Linux kernel will not need to access PMMC similar to how bootloader has 
>> to.
>>
>> Bootloader looks to load up the peripheral - so, it's view of the
>> hardware is as a programmable core (similar to how we'd look at a
>> DSP/other remote proc), however, linux kernel only cares about the
>> communication link (which is the message manager) and the protocol on
>> top to communicate and does not need to access PMMC directly (it is
>> only done once by bootloader).
>>
>> So the the current u-boot dt binding will not even need to be send
>> upstream kernel, instead a protocol level definition (similar to SCPI)
>> will be exposed to linux kernel.
>
> So is the kernel community going to be unhappy about getting what it
> might consider extraneous information in the device tree?  The goal here
> is to be able to just copy in the DT files from $upstream and really
> really not have local changes without a good reason (and yes, we need to
> revisit u-boot,dm-pre-reloc at some point).  Maybe a question for one of
> the higher level DT lists...
>

Hmmm... I can switch to platform data if maintenance is an concern. I
dont think PMMC will be an unique experience for DT view of the
hardware where every  piece of software looks at things differently.
For example: if we move DDR configuration to device tree (which dt is
pretty capable of doing), then we are stuck with the same issue yet
again. DDR configuration is not necessary for kernel device tree since
it has nothing to do there - and we dont provide that information
(since it becomes a maintenance pain in kernel world as well), but
u-boot SPL will need to have that information.

Device tree is a representation of hardware is exactly what we do,
except that view depends on what we need to expose to each software
solution. Even in Linux, in a hypervisor world, a guest OS may only
have access to certain peripherals of the SoC - we dont expose all the
peripherals to the OS via dt, instead a custom guest OS dt view of the
world is created. This is one problem we all have with DT -> the
extent to which we "describe hardware" - there is no objective rules
for the same that can get blindly applied..

Do let me know if I need to bring this device outside of dt into
platform data world. It wont be my first preference, but if it does
create a severe maintenance burden, then maybe that is what needs to
happen -> only resources that are shared between kernel and bootloader
can reside in dt... just my 2 cents..

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

Re: [U-Boot] [PATCH V2 5/6] ARM: dts: k2g: Add support for PMMC

[Tom Rini]

On Fri, Feb 26, 2016 at 06:18:30PM -0600, Nishanth Menon wrote:
> On Fri, Feb 26, 2016 at 12:18 PM, Tom Rini  wrote:
> > On Thu, Feb 25, 2016 at 12:53:46PM -0600, Nishanth Menon wrote:
> >
> >> Enable support for PMMC the TI power processor on K2G. This processor
> >> manages all power management related activities on the SoC and and
> >> allows the Operating Systems on compute processors such as ARM, DSP to
> >> offload the power logic away into the power processor. U-boot just has a
> >> load responsibility, hence the view of the hardware from a bootloader
> >> perspective is different from the view of hardware from a Operating
> >> System perspective. While bootloader just loads up the firmware,
> >> Operating Systems look at the resultant system as "hardware".
> >>
> >> Signed-off-by: Nishanth Menon 
> >
> > Reviewed-by: Tom Rini 
> >
> > ... and this will match whatever is in the kernel, right?
> 
> The Linux kernel will not need to access PMMC similar to how bootloader has 
> to.
> 
> Bootloader looks to load up the peripheral - so, it's view of the
> hardware is as a programmable core (similar to how we'd look at a
> DSP/other remote proc), however, linux kernel only cares about the
> communication link (which is the message manager) and the protocol on
> top to communicate and does not need to access PMMC directly (it is
> only done once by bootloader).
> 
> So the the current u-boot dt binding will not even need to be send
> upstream kernel, instead a protocol level definition (similar to SCPI)
> will be exposed to linux kernel.

So is the kernel community going to be unhappy about getting what it
might consider extraneous information in the device tree?  The goal here
is to be able to just copy in the DT files from $upstream and really
really not have local changes without a good reason (and yes, we need to
revisit u-boot,dm-pre-reloc at some point).  Maybe a question for one of
the higher level DT lists...

-- 
Tom


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

Re: [U-Boot] [PATCH V2 5/6] ARM: dts: k2g: Add support for PMMC

[Nishanth Menon]

On Fri, Feb 26, 2016 at 12:18 PM, Tom Rini  wrote:
> On Thu, Feb 25, 2016 at 12:53:46PM -0600, Nishanth Menon wrote:
>
>> Enable support for PMMC the TI power processor on K2G. This processor
>> manages all power management related activities on the SoC and and
>> allows the Operating Systems on compute processors such as ARM, DSP to
>> offload the power logic away into the power processor. U-boot just has a
>> load responsibility, hence the view of the hardware from a bootloader
>> perspective is different from the view of hardware from a Operating
>> System perspective. While bootloader just loads up the firmware,
>> Operating Systems look at the resultant system as "hardware".
>>
>> Signed-off-by: Nishanth Menon 
>
> Reviewed-by: Tom Rini 
>
> ... and this will match whatever is in the kernel, right?

The Linux kernel will not need to access PMMC similar to how bootloader has to.

Bootloader looks to load up the peripheral - so, it's view of the
hardware is as a programmable core (similar to how we'd look at a
DSP/other remote proc), however, linux kernel only cares about the
communication link (which is the message manager) and the protocol on
top to communicate and does not need to access PMMC directly (it is
only done once by bootloader).

So the the current u-boot dt binding will not even need to be send
upstream kernel, instead a protocol level definition (similar to SCPI)
will be exposed to linux kernel.

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

Re: [U-Boot] [PATCH V2 2/6] ARM: keystone2: psc-defs: use adequate () for macros

[Nishanth Menon]

On Fri, Feb 26, 2016 at 12:17 PM, Tom Rini  wrote:
> On Thu, Feb 25, 2016 at 12:53:43PM -0600, Nishanth Menon wrote:
>
>> '#define X a | b' is better defined as '#define X (a | b)' for obvious
>> reasons.
>>
>> Signed-off-by: Nishanth Menon 
>
> Reviewed-by: Tom Rini 
>
> But this makes my head hurt.  Can we somehow do any of that with less
> parenthesis?  Like, is this really something we must macro? Or can we
> re-factor it?  I had to highlight every open/close to be happy it was
> correct, which is not a good sign.

I will try and give it a shot and repost - yeah - it was pretty
convoluted in the first place might be changing it to a static inline
might be a simpler approach..


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

Re: [U-Boot] [PATCH 5/6] ARM: keystone2: use SPD info to configure K2HK and K2E DDR3

[Nishanth Menon]

On Fri, Feb 26, 2016 at 12:16 PM, Tom Rini  wrote:
> On Thu, Feb 25, 2016 at 09:52:14AM -0600, Nishanth Menon wrote:
>
>> From: Vitaly Andrianov 
>>
>> This commit replaces hard-coded EMIF and PHY DDR3 configurations for
>> predefined SODIMMs to a calculated configuration. The SODIMM parameters
>> are read from SODIMM's SPD and used to calculated the configuration.
>>
>> The current commit supports calculation for DDR3 with 1600MHz and 1333MHz
>> only.
>>
>> Signed-off-by: Vitaly Andrianov 
>> Signed-off-by: Lokesh Vutla 
>> Signed-off-by: Nishanth Menon 
> [snip]
>> +#ifdef DUMP_DDR_CONFIG
>> +static void dump_phy_config(struct ddr3_phy_config *ptr)
>
> Please figure out how to do this with debug() instead.
>
> [snip]
>> + puts("DDR3A Speed will be configured for 1333 Operation.\n");
>
> Just printf, always, it's fine, really.
>
Thank you for the review. Will try to do that and repost.


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

Re: [U-Boot] [PULL] u-boot-usb/master

[Marek Vasut]

On 02/25/2016 04:23 PM, Tom Rini wrote:
> On Wed, Feb 24, 2016 at 07:13:47PM +0100, Marek Vasut wrote:
> 
>> The following changes since commit 52dd704bf8eda7ca039cdb398ec0b6895c3ef939:
>>
>>   Merge branch 'master' of http://git.denx.de/u-boot-sunxi (2016-02-23
>> 15:35:47 -0500)
>>
>> are available in the git repository at:
>>
>>   git://git.denx.de/u-boot-usb.git master
>>
>> for you to fetch changes up to d7d8c00575c8ae766d387c763395470410427b69:
>>
>>   implement Fastboot via USB OTG on bcm28155_ap boards (2016-02-24
>> 19:12:33 +0100)
>>
> 
> Applied to u-boot/master, thanks!
> 
> But note and please fix ASAP:
> Building current source for 1 boards (1 thread, 6 jobs per thread)
>aarch64:  +   p2571
> +(p2571) In file included from arch/arm/include/asm/byteorder.h:29:0,
> +(p2571)  from include/compiler.h:125,
> +(p2571)  from include/image.h:19,
> +(p2571)  from include/common.h:88,
> +(p2571)  from drivers/usb/host/ehci-hcd.c:10:
> +(p2571)td->qt_buffer[idx] = cpu_to_hc32(virt_to_phys((void *)addr));
> +(p2571)  ^
> +(p2571) include/linux/byteorder/little_endian.h:34:51: note: in definition 
> of macro ‘__cpu_to_le32’
> +(p2571)  #define __cpu_to_le32(x) ((__force __le32)(__u32)(x))
> +(p2571)^
> +(p2571) drivers/usb/host/ehci-hcd.c:250:24: note: in expansion of macro 
> ‘cpu_to_hc32’
> +(p2571) ^
> w+(p2571) drivers/usb/host/ehci-hcd.c: In function ‘ehci_td_buffer’:
> w+(p2571) drivers/usb/host/ehci-hcd.c:250:49: warning: cast to pointer from 
> integer of different size [-Wint-to-pointer-cast]
> 
> Also seen on p2371-2180 and p2371-

Should be fixed nowish. Sorry for the mess.

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

Re: [U-Boot] [PATCH] usb: ehci: Fix warning on aarch64

[Marek Vasut]

On 02/26/2016 11:17 PM, Tom Rini wrote:
> On Fri, Feb 26, 2016 at 11:00:02PM +0100, Marek Vasut wrote:
> 
>> Fix the following warning on aarch64 introduced by using p2v/v2p
>> functions in the code:
>>
>> In file included from ./arch/arm/include/asm/byteorder.h:29:0,
>>  from include/compiler.h:125,
>>  from include/image.h:19,
>>  from include/common.h:88,
>>  from drivers/usb/host/ehci-hcd.c:10:
>> drivers/usb/host/ehci-hcd.c: In function ‘ehci_td_buffer’:
>> drivers/usb/host/ehci-hcd.c:250:49: warning: cast to pointer from integer of 
>> different size [-Wint-to-pointer-cast]
>>td->qt_buffer[idx] = cpu_to_hc32(virt_to_phys((void *)addr));
>>  ^
>> include/linux/byteorder/little_endian.h:34:51: note: in definition of macro 
>> ‘__cpu_to_le32’
>>  #define __cpu_to_le32(x) ((__force __le32)(__u32)(x))
>>^
>> drivers/usb/host/ehci-hcd.c:250:24: note: in expansion of macro ‘cpu_to_hc32’
>>td->qt_buffer[idx] = cpu_to_hc32(virt_to_phys((void *)addr));
>>
>> Signed-off-by: Marek Vasut 
>> Cc: Stephen Warren 
>> Cc: Tom Rini 
> 
> Reviewed-by: Tom Rini 

In that case, applied, thanks!

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

Re: [U-Boot] [PATCH v6 00/76] mtd: Add SPI-NOR core support

[Simon Glass]

Hi Jagan,

On 26 February 2016 at 13:44, york sun  wrote:
> On 02/22/2016 10:18 AM, Jagan Teki wrote:
>> Hi York,
>>
>> On 15 February 2016 at 02:16, Jagan Teki  wrote:
>>> Compared to previous patch series this series adds spi-nor
>>> core with spi-nor controller drivers are of "mtd uclass"
>>>
>>> This is whole series for all spi-nor related changes, and while
>>> series tested on spansion spi-nor chip.
>>>
>>> Know issue:
>>> - arch/x86/lib/mrccache.c uses dm_spi_flash_ops, this need to fix.
>>>
>>> Why this framework:
>>>
>>> Some of the SPI device drivers at drivers/spi not a real
>>> spi controllers, Unlike normal/generic SPI controllers they
>>> operates only with SPI-NOR flash devices. these were technically
>>> termed as SPI-NOR controllers, Ex: drivers/spi/fsl_qspi.c
>>>
>>> The problem with these were resides at drivers/spi is entire
>>> SPI layer becomes SPI-NOR flash oriented which is absolutely
>>> a wrong indication where SPI layer getting effected more with
>>> flash operations - So this SPI-NOR core will resolve this issue
>>> by separating all SPI-NOR flash operations from spi layer and
>>> creats a generic layer called SPI-NOR core which can be used to
>>> interact SPI-NOR to SPI driver interface layer and the SPI-NOR
>>> controller driver. The idea is taken from Linux spi-nor framework.
>>>
>>> Before SPI-NOR:
>>>
>>> ---
>>> cmd/sf.c
>>> ---
>>> spi_flash.c
>>> ---
>>> sf_probe.c
>>> ---
>>> spi-uclass
>>> ---
>>> spi drivers
>>> ---
>>> SPI NOR chip
>>> ---
>>>
>>> After SPI-NOR:
>>>
>>> --
>>> cmd/sf.c
>>> --
>>> spi-nor.c
>>> ---
>>> m25p80.cspi nor drivers
>>> ---
>>> spi-uclass  SPI NOR chip
>>> ---
>>> spi drivers
>>> ---
>>> SPI NOR chip
>>> ---
>>>
>>> SPI-NOR with MTD:
>>>
>>> --
>>> cmd/sf.c
>>> --
>>> MTD core
>>> --
>>> spi-nor.c
>>> ---
>>> m25p80.cspi nor drivers
>>> ---
>>> spi-uclass  SPI NOR chip
>>> ---
>>> spi drivers
>>> ---
>>> SPI NOR chip
>>> ---
>>>
>>> drivers/mtd/spi-nor/spi-nor.c: spi-nor core
>>> drivers/mtd/spi-nor/m25p80.c: mtd uclass driver
>>> which is an interface layer b/w spi-nor core drivers/spi
>>> drivers/mtd/spi-nor/fsl_qspi.c: spi-nor controller driver(mtd uclass)
>>>
>>> Changes for v6:
>>> - Fixed git bisectable issues, with buildman.
>>> - Fixed spi-nor compilation issues
>>> - newly designed changes.
>>>
>>> Changes for v5:
>>> - newly designed changes
>>>
>>> Testing:
>>> $ git clone git://git.denx.de/u-boot-spi.git
>>> $ cd u-boot-spi
>>> $ git checkout -b spi-nor origin/spi-nor
>>>
>>> Jagan Teki (76):
>>>   mtd: Add m25p80 driver
>>>   mtd: Add Kconfig entry for MTD_M25P80
>>>   mtd: Add SPI-NOR core support
>>>   doc: device-tree-bindings: jedec,spi-nor
>>>   mtd: spi-nor: Add Kconfig entry for MTD_SPI_NOR
>>>   mtd: spi-nor: Add kconfig for MTD_SPI_NOR_USE_4K_SECTORS
>>>   mtd: spi-nor: Add MTD support
>>>   mtd: spi-nor: Add spi_nor support in m25p80
>>>   mtd: spi-nor: Add dm spi-nor probing
>>>   mtd: spi-nor: Add spi_flash_probe for mtd-dm-spi-nor
>>>   mtd: spi-nor: Add spi_flash_free for mtd-dm-spi-nor
>>>   mtd: spi-nor: m25p80: Add spi_nor support for non-dm
>>>   sf: Rename erase_size to erasesize
>>>   sf: Use erasesize instead of sector_size
>>>   sf: Use uint64_t for flash->size
>>>   spi_flash: Use mtd_info operation for SPI-NOR
>>>   spi_flash: Use spi_flash_t instead of struct spi_flash
>>>   mtd: spi-nor: Move spi_read_then_write to spi layer
>>>   spi: Rename spi_read_then_write to spi_write_then_read
>>>   mtd: spi-nor: Rename SPI_FLASH_BAR to SPI_NOR_BAR
>>>   mtd: spi-nor: Add Kconfig entry for SPI_NOR_BAR
>>>   mtd: spi-nor: Copy spl files from drivers/mtd/spi
>>>   mtd: spi-nor: spl: Follow ascending order of include headers
>>>   mtd: spi-nor: fsl_espi_spl: Use mtd_info
>>>   mtd: spi-nor: spi_spl_load: Use mtd_info
>>>   mtd: spi-nor: Add flash vendor Kconfig entries
>>>   arm: zynq: Kconfig: Select MTD uclass
>>>   arm: zynq: Kconfig: Drop DM_SPI_FLASH
>>>   defconfigs: zynq_microzed: Drop CONFIG_SPI_FLASH
>>>   defconfig: zynq_microzed: Enable CONFIG_MTD_M25P80
>>>   defconfig: zynq_microzed: Enable CONFIG_MTD_SPI_NOR
>>>   spl: Add CONFIG_SPL_SPI_NOR_SUPPORT
>>>   configs: zynq: Use CONFIG_SPL_SPI_NOR_SUPPORT
>>>   configs: zynq: Use CONFIG_SPL_MTD_SUPPORT
>>>   mtd: spi-nor: Copy sf_dataflash
>>>   mtd: 

Re: [U-Boot] [PATCH] usb: ehci: Fix warning on aarch64

[Tom Rini]

On Fri, Feb 26, 2016 at 11:00:02PM +0100, Marek Vasut wrote:

> Fix the following warning on aarch64 introduced by using p2v/v2p
> functions in the code:
> 
> In file included from ./arch/arm/include/asm/byteorder.h:29:0,
>  from include/compiler.h:125,
>  from include/image.h:19,
>  from include/common.h:88,
>  from drivers/usb/host/ehci-hcd.c:10:
> drivers/usb/host/ehci-hcd.c: In function ‘ehci_td_buffer’:
> drivers/usb/host/ehci-hcd.c:250:49: warning: cast to pointer from integer of 
> different size [-Wint-to-pointer-cast]
>td->qt_buffer[idx] = cpu_to_hc32(virt_to_phys((void *)addr));
>  ^
> include/linux/byteorder/little_endian.h:34:51: note: in definition of macro 
> ‘__cpu_to_le32’
>  #define __cpu_to_le32(x) ((__force __le32)(__u32)(x))
>^
> drivers/usb/host/ehci-hcd.c:250:24: note: in expansion of macro ‘cpu_to_hc32’
>td->qt_buffer[idx] = cpu_to_hc32(virt_to_phys((void *)addr));
> 
> Signed-off-by: Marek Vasut 
> Cc: Stephen Warren 
> Cc: Tom Rini 

Reviewed-by: Tom Rini 

-- 
Tom


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

[U-Boot] [PATCH] usb: ehci: Fix warning on aarch64

[Marek Vasut]

Fix the following warning on aarch64 introduced by using p2v/v2p
functions in the code:

In file included from ./arch/arm/include/asm/byteorder.h:29:0,
 from include/compiler.h:125,
 from include/image.h:19,
 from include/common.h:88,
 from drivers/usb/host/ehci-hcd.c:10:
drivers/usb/host/ehci-hcd.c: In function ‘ehci_td_buffer’:
drivers/usb/host/ehci-hcd.c:250:49: warning: cast to pointer from integer of 
different size [-Wint-to-pointer-cast]
   td->qt_buffer[idx] = cpu_to_hc32(virt_to_phys((void *)addr));
 ^
include/linux/byteorder/little_endian.h:34:51: note: in definition of macro 
‘__cpu_to_le32’
 #define __cpu_to_le32(x) ((__force __le32)(__u32)(x))
   ^
drivers/usb/host/ehci-hcd.c:250:24: note: in expansion of macro ‘cpu_to_hc32’
   td->qt_buffer[idx] = cpu_to_hc32(virt_to_phys((void *)addr));

Signed-off-by: Marek Vasut 
Cc: Stephen Warren 
Cc: Tom Rini 
---
 drivers/usb/host/ehci-hcd.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index 8f259be..0113c6c 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -237,7 +237,7 @@ static int ehci_shutdown(struct ehci_ctrl *ctrl)
 static int ehci_td_buffer(struct qTD *td, void *buf, size_t sz)
 {
uint32_t delta, next;
-   uint32_t addr = (unsigned long)buf;
+   unsigned long addr = (unsigned long)buf;
int idx;
 
if (addr != ALIGN(addr, ARCH_DMA_MINALIGN))
-- 
2.7.0

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

Re: [U-Boot] [PATCH v6 00/76] mtd: Add SPI-NOR core support

[york sun]

On 02/22/2016 10:18 AM, Jagan Teki wrote:
> Hi York,
> 
> On 15 February 2016 at 02:16, Jagan Teki  wrote:
>> Compared to previous patch series this series adds spi-nor
>> core with spi-nor controller drivers are of "mtd uclass"
>>
>> This is whole series for all spi-nor related changes, and while
>> series tested on spansion spi-nor chip.
>>
>> Know issue:
>> - arch/x86/lib/mrccache.c uses dm_spi_flash_ops, this need to fix.
>>
>> Why this framework:
>>
>> Some of the SPI device drivers at drivers/spi not a real
>> spi controllers, Unlike normal/generic SPI controllers they
>> operates only with SPI-NOR flash devices. these were technically
>> termed as SPI-NOR controllers, Ex: drivers/spi/fsl_qspi.c
>>
>> The problem with these were resides at drivers/spi is entire
>> SPI layer becomes SPI-NOR flash oriented which is absolutely
>> a wrong indication where SPI layer getting effected more with
>> flash operations - So this SPI-NOR core will resolve this issue
>> by separating all SPI-NOR flash operations from spi layer and
>> creats a generic layer called SPI-NOR core which can be used to
>> interact SPI-NOR to SPI driver interface layer and the SPI-NOR
>> controller driver. The idea is taken from Linux spi-nor framework.
>>
>> Before SPI-NOR:
>>
>> ---
>> cmd/sf.c
>> ---
>> spi_flash.c
>> ---
>> sf_probe.c
>> ---
>> spi-uclass
>> ---
>> spi drivers
>> ---
>> SPI NOR chip
>> ---
>>
>> After SPI-NOR:
>>
>> --
>> cmd/sf.c
>> --
>> spi-nor.c
>> ---
>> m25p80.cspi nor drivers
>> ---
>> spi-uclass  SPI NOR chip
>> ---
>> spi drivers
>> ---
>> SPI NOR chip
>> ---
>>
>> SPI-NOR with MTD:
>>
>> --
>> cmd/sf.c
>> --
>> MTD core
>> --
>> spi-nor.c
>> ---
>> m25p80.cspi nor drivers
>> ---
>> spi-uclass  SPI NOR chip
>> ---
>> spi drivers
>> ---
>> SPI NOR chip
>> ---
>>
>> drivers/mtd/spi-nor/spi-nor.c: spi-nor core
>> drivers/mtd/spi-nor/m25p80.c: mtd uclass driver
>> which is an interface layer b/w spi-nor core drivers/spi
>> drivers/mtd/spi-nor/fsl_qspi.c: spi-nor controller driver(mtd uclass)
>>
>> Changes for v6:
>> - Fixed git bisectable issues, with buildman.
>> - Fixed spi-nor compilation issues
>> - newly designed changes.
>>
>> Changes for v5:
>> - newly designed changes
>>
>> Testing:
>> $ git clone git://git.denx.de/u-boot-spi.git
>> $ cd u-boot-spi
>> $ git checkout -b spi-nor origin/spi-nor
>>
>> Jagan Teki (76):
>>   mtd: Add m25p80 driver
>>   mtd: Add Kconfig entry for MTD_M25P80
>>   mtd: Add SPI-NOR core support
>>   doc: device-tree-bindings: jedec,spi-nor
>>   mtd: spi-nor: Add Kconfig entry for MTD_SPI_NOR
>>   mtd: spi-nor: Add kconfig for MTD_SPI_NOR_USE_4K_SECTORS
>>   mtd: spi-nor: Add MTD support
>>   mtd: spi-nor: Add spi_nor support in m25p80
>>   mtd: spi-nor: Add dm spi-nor probing
>>   mtd: spi-nor: Add spi_flash_probe for mtd-dm-spi-nor
>>   mtd: spi-nor: Add spi_flash_free for mtd-dm-spi-nor
>>   mtd: spi-nor: m25p80: Add spi_nor support for non-dm
>>   sf: Rename erase_size to erasesize
>>   sf: Use erasesize instead of sector_size
>>   sf: Use uint64_t for flash->size
>>   spi_flash: Use mtd_info operation for SPI-NOR
>>   spi_flash: Use spi_flash_t instead of struct spi_flash
>>   mtd: spi-nor: Move spi_read_then_write to spi layer
>>   spi: Rename spi_read_then_write to spi_write_then_read
>>   mtd: spi-nor: Rename SPI_FLASH_BAR to SPI_NOR_BAR
>>   mtd: spi-nor: Add Kconfig entry for SPI_NOR_BAR
>>   mtd: spi-nor: Copy spl files from drivers/mtd/spi
>>   mtd: spi-nor: spl: Follow ascending order of include headers
>>   mtd: spi-nor: fsl_espi_spl: Use mtd_info
>>   mtd: spi-nor: spi_spl_load: Use mtd_info
>>   mtd: spi-nor: Add flash vendor Kconfig entries
>>   arm: zynq: Kconfig: Select MTD uclass
>>   arm: zynq: Kconfig: Drop DM_SPI_FLASH
>>   defconfigs: zynq_microzed: Drop CONFIG_SPI_FLASH
>>   defconfig: zynq_microzed: Enable CONFIG_MTD_M25P80
>>   defconfig: zynq_microzed: Enable CONFIG_MTD_SPI_NOR
>>   spl: Add CONFIG_SPL_SPI_NOR_SUPPORT
>>   configs: zynq: Use CONFIG_SPL_SPI_NOR_SUPPORT
>>   configs: zynq: Use CONFIG_SPL_MTD_SUPPORT
>>   mtd: spi-nor: Copy sf_dataflash
>>   mtd: dataflash: Remove unneeded spi data
>>   mtd: dataflash: Move flash id detection into jedec_probe
>>   mtd: dataflash: Fix add_dataflash return logic
>>   mtd: dataflash: Add UCLASS_MTD support
>>   mtd: dataflash: Use 

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

[Simon Glass]

Hi Tom,

Here is the series that fixes various tests.


The following changes since commit 24862c640ea50ac88be343161eb681bea5dbfeef:

  test/py: skip tests that require large CONFIG_SYS_MAXARGS
(2016-02-26 08:42:12 -0500)

are available in the git repository at:

  git://git.denx.de/u-boot-dm.git

for you to fetch changes up to 6796704b0dfb4f98cb4a026988e9739884812b5c:

  pci: Fix compiler warnings in dm_pciauto_setup_device() (2016-02-26
08:53:10 -0700)


Bin Meng (1):
  pci: Fix compiler warnings in dm_pciauto_setup_device()

Simon Glass (16):
  image: Correct the OS location code to work on sandbox
  Revert "image-fit: Fix signature checking"
  image: Fix FIT and vboot tests to exit sandbox correctly
  trace: Fix compiler warnings in trace
  lib: Don't instrument the div64 function
  trace: Improve the trace test number recognition
  timer: Support tracing fully
  timer: Provide an early timer
  timer: Set up the real timer after driver model is available
  sandbox: timer: Support the early timer
  sandbox: Correct ordering of defconfig
  sandbox: Enable the early timer
  sandbox: spi: Add more debugging to SPI emulation
  sandbox: spi: Remove an incorrect free()
  spi: Correct two error return values
  spi: Re-enable the SPI flash tests

 cmd/trace.c   |  4 ++--
 common/board_f.c  |  6 ++
 common/board_r.c  | 14 --
 common/bootm.c|  2 +-
 common/image-fit.c| 16 +---
 configs/sandbox_defconfig | 11 ++-
 drivers/mtd/spi/sandbox.c | 14 ++
 drivers/mtd/spi/sf_probe.c|  4 +---
 drivers/mtd/spi/spi_flash.c   |  2 +-
 drivers/pci/pci_auto.c|  2 +-
 drivers/timer/Kconfig | 10 ++
 drivers/timer/sandbox_timer.c | 18 +++---
 drivers/timer/timer-uclass.c  |  6 +++---
 include/image.h   |  5 +
 include/timer.h   | 21 +
 lib/div64.c   |  3 ++-
 lib/time.c| 28 +---
 test/dm/Makefile  |  4 ++--
 test/image/test-fit.py|  4 
 test/trace/test-trace.sh  |  4 +++-
 test/vboot/sandbox-u-boot.dts |  3 +++
 21 files changed, 138 insertions(+), 43 deletions(-)

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

[U-Boot] [PATCH] ARM: DRA7xx: Enable NFS boot command

[Andrew F. Davis]

NFS loading works on DRA7 variants, remove the undefinition.

Signed-off-by: Andrew F. Davis 
---
 configs/dra72_evm_defconfig   | 1 -
 configs/dra7xx_evm_defconfig  | 1 -
 configs/dra7xx_evm_qspiboot_defconfig | 1 -
 configs/dra7xx_evm_uart3_defconfig| 1 -
 4 files changed, 4 deletions(-)

diff --git a/configs/dra72_evm_defconfig b/configs/dra72_evm_defconfig
index b5bd798..a8a2b65 100644
--- a/configs/dra72_evm_defconfig
+++ b/configs/dra72_evm_defconfig
@@ -9,7 +9,6 @@ CONFIG_SPL_STACK_R_ADDR=0x8200
 # CONFIG_CMD_IMLS is not set
 # CONFIG_CMD_FLASH is not set
 # CONFIG_CMD_SETEXPR is not set
-# CONFIG_CMD_NFS is not set
 CONFIG_OF_CONTROL=y
 CONFIG_DM=y
 CONFIG_SPI_FLASH=y
diff --git a/configs/dra7xx_evm_defconfig b/configs/dra7xx_evm_defconfig
index f98e7b7..b69dc53 100644
--- a/configs/dra7xx_evm_defconfig
+++ b/configs/dra7xx_evm_defconfig
@@ -7,6 +7,5 @@ CONFIG_SPL_STACK_R_ADDR=0x8200
 # CONFIG_CMD_IMLS is not set
 # CONFIG_CMD_FLASH is not set
 # CONFIG_CMD_SETEXPR is not set
-# CONFIG_CMD_NFS is not set
 CONFIG_SPI_FLASH=y
 CONFIG_SPI_FLASH_BAR=y
diff --git a/configs/dra7xx_evm_qspiboot_defconfig 
b/configs/dra7xx_evm_qspiboot_defconfig
index f14fa62..c823fe6 100644
--- a/configs/dra7xx_evm_qspiboot_defconfig
+++ b/configs/dra7xx_evm_qspiboot_defconfig
@@ -8,5 +8,4 @@ CONFIG_SYS_EXTRA_OPTIONS="QSPI_BOOT"
 # CONFIG_CMD_IMLS is not set
 # CONFIG_CMD_FLASH is not set
 # CONFIG_CMD_SETEXPR is not set
-# CONFIG_CMD_NFS is not set
 CONFIG_SPI_FLASH=y
diff --git a/configs/dra7xx_evm_uart3_defconfig 
b/configs/dra7xx_evm_uart3_defconfig
index 8882260..4c6aeb6 100644
--- a/configs/dra7xx_evm_uart3_defconfig
+++ b/configs/dra7xx_evm_uart3_defconfig
@@ -9,5 +9,4 @@ CONFIG_SYS_EXTRA_OPTIONS="SPL_YMODEM_SUPPORT"
 # CONFIG_CMD_IMLS is not set
 # CONFIG_CMD_FLASH is not set
 # CONFIG_CMD_SETEXPR is not set
-# CONFIG_CMD_NFS is not set
 CONFIG_SPI_FLASH=y
-- 
2.7.2

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

Re: [U-Boot] [PATCH] usb: gadget: composite: Correct recovery path for register

[Marek Vasut]

On 02/26/2016 08:43 PM, Sam Protsenko wrote:
> On Fri, Feb 19, 2016 at 9:34 PM, Sam Protsenko
>  wrote:
>> + Praneeth Bajjuri
>> + Tom Rini
>> + Rob Herring
>>
>> On Tue, Feb 16, 2016 at 7:59 PM, Semen Protsenko
>>  wrote:
>>> From: Sam Protsenko 
>>>
>>> In case when usb_composite_register() failed once (for whatever reason),
>>> it will fail further even if all conditions are correct. Example:
>>>
>>> => fastboot 2
>>> Invalid Controller Index
>>> couldn't find an available UDC
>>> g_dnl_register: failed!, error: -19
>>> exit not allowed from main input shell.
>>>
>>> => fastboot 0
>>> g_dnl_register: failed!, error: -22
>>> exit not allowed from main input shell.
>>>
>>> Despite that 0 is correct index for USB controller, "fastboot 0" command
>>> will fail, because "composite" structure wasn't cleared properly on
>>> previous fail (on "fastboot 2" command).
>>>
>>> This patch fixes that erroneous behavior, allowing us to use composite
>>> even after previous failure.
>>>
>>> Signed-off-by: Sam Protsenko 
>>> ---
>>>  drivers/usb/gadget/composite.c | 8 +++-
>>>  1 file changed, 7 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/usb/gadget/composite.c b/drivers/usb/gadget/composite.c
>>> index 60f9272..d0ee784 100644
>>> --- a/drivers/usb/gadget/composite.c
>>> +++ b/drivers/usb/gadget/composite.c
>>> @@ -1077,6 +1077,8 @@ static struct usb_gadget_driver composite_driver = {
>>>   */
>>>  int usb_composite_register(struct usb_composite_driver *driver)
>>>  {
>>> +   int res;
>>> +
>>> if (!driver || !driver->dev || !driver->bind || composite)
>>> return -EINVAL;
>>>
>>> @@ -1084,7 +1086,11 @@ int usb_composite_register(struct 
>>> usb_composite_driver *driver)
>>> driver->name = "composite";
>>> composite = driver;
>>>
>>> -   return usb_gadget_register_driver(_driver);
>>> +   res = usb_gadget_register_driver(_driver);
>>> +   if (res != 0)
>>> +   composite = NULL;
>>> +
>>> +   return res;
>>>  }
>>>
>>>  /**
>>> --
>>> 2.7.0
>>>
> 
> bump
> 

Looks fine. Lukasz, shall I pick this myself ?

btw if this isn't applied in a week, please ping me and I will pick it
nonetheless.

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

Re: [U-Boot] [PATCH 1/3] omap5: Kconfig: Add option to select Android boot

[Sam Protsenko]

On Fri, Feb 19, 2016 at 9:25 PM, Semen Protsenko
 wrote:
> From: Sam Protsenko 
>
> We need to differentiate somehow if u-boot build is intended for Android
> or regular Linux boot. Android requires some specific details from
> bootloader, such as enabled fastboot and specific partition table.
> Using this option we can check if user chose Android boot and configure
> those details properly.
>
> Signed-off-by: Sam Protsenko 
> ---
>  arch/arm/cpu/armv7/omap5/Kconfig | 8 
>  1 file changed, 8 insertions(+)
>
> diff --git a/arch/arm/cpu/armv7/omap5/Kconfig 
> b/arch/arm/cpu/armv7/omap5/Kconfig
> index bfa264e..e03daff 100644
> --- a/arch/arm/cpu/armv7/omap5/Kconfig
> +++ b/arch/arm/cpu/armv7/omap5/Kconfig
> @@ -21,6 +21,14 @@ endchoice
>  config SYS_SOC
> default "omap5"
>
> +config ANDROID_BOOT
> +   bool "Android boot"
> +   default n
> +   help
> + This option enables Android build. Different boards can rely on this
> + option to provide Android partition list, enable fastboot capability
> + and so on.
> +
>  source "board/compulab/cm_t54/Kconfig"
>  source "board/ti/omap5_uevm/Kconfig"
>  source "board/ti/dra7xx/Kconfig"
> --
> 2.7.0
>

Consider this patch abandoned as new version was sent aside from this patchset:
http://lists.denx.de/pipermail/u-boot/2016-February/246744.html
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 3/3] defconfig: Add dra7xx_evm_android_defconfig

[Sam Protsenko]

On Fri, Feb 19, 2016 at 9:25 PM, Semen Protsenko
 wrote:
> From: Sam Protsenko 
>
> Add defconfig for DRA7XX EVM board intended for Android build.
> This defconfig was derived from configs/dra7xx_evm_defconfig. The only
> difference for now is that this new config exports Android partition
> table via $partitions variable.
>
> Signed-off-by: Sam Protsenko 
> ---
>  configs/dra7xx_evm_android_defconfig | 17 +
>  1 file changed, 17 insertions(+)
>  create mode 100644 configs/dra7xx_evm_android_defconfig
>
> diff --git a/configs/dra7xx_evm_android_defconfig 
> b/configs/dra7xx_evm_android_defconfig
> new file mode 100644
> index 000..1e5960b
> --- /dev/null
> +++ b/configs/dra7xx_evm_android_defconfig
> @@ -0,0 +1,17 @@
> +CONFIG_ARM=y
> +CONFIG_OMAP54XX=y
> +CONFIG_TARGET_DRA7XX_EVM=y
> +CONFIG_SPL_STACK_R_ADDR=0x8200
> +CONFIG_SPL=y
> +CONFIG_SPL_STACK_R=y
> +# CONFIG_CMD_IMLS is not set
> +# CONFIG_CMD_FLASH is not set
> +CONFIG_CMD_GPIO=y
> +# CONFIG_CMD_SETEXPR is not set
> +# CONFIG_CMD_NFS is not set
> +CONFIG_SPI_FLASH=y
> +CONFIG_SPI_FLASH_BAR=y
> +CONFIG_SPI_FLASH_SPANSION=y
> +CONFIG_SYS_NS16550=y
> +CONFIG_TI_QSPI=y
> +CONFIG_ANDROID_BOOT=y
> --
> 2.7.0
>

Consider this patch abandoned as new version was sent aside from this patchset:
http://lists.denx.de/pipermail/u-boot/2016-February/246744.html
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] usb: gadget: composite: Correct recovery path for register

[Sam Protsenko]

On Fri, Feb 19, 2016 at 9:34 PM, Sam Protsenko
 wrote:
> + Praneeth Bajjuri
> + Tom Rini
> + Rob Herring
>
> On Tue, Feb 16, 2016 at 7:59 PM, Semen Protsenko
>  wrote:
>> From: Sam Protsenko 
>>
>> In case when usb_composite_register() failed once (for whatever reason),
>> it will fail further even if all conditions are correct. Example:
>>
>> => fastboot 2
>> Invalid Controller Index
>> couldn't find an available UDC
>> g_dnl_register: failed!, error: -19
>> exit not allowed from main input shell.
>>
>> => fastboot 0
>> g_dnl_register: failed!, error: -22
>> exit not allowed from main input shell.
>>
>> Despite that 0 is correct index for USB controller, "fastboot 0" command
>> will fail, because "composite" structure wasn't cleared properly on
>> previous fail (on "fastboot 2" command).
>>
>> This patch fixes that erroneous behavior, allowing us to use composite
>> even after previous failure.
>>
>> Signed-off-by: Sam Protsenko 
>> ---
>>  drivers/usb/gadget/composite.c | 8 +++-
>>  1 file changed, 7 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/usb/gadget/composite.c b/drivers/usb/gadget/composite.c
>> index 60f9272..d0ee784 100644
>> --- a/drivers/usb/gadget/composite.c
>> +++ b/drivers/usb/gadget/composite.c
>> @@ -1077,6 +1077,8 @@ static struct usb_gadget_driver composite_driver = {
>>   */
>>  int usb_composite_register(struct usb_composite_driver *driver)
>>  {
>> +   int res;
>> +
>> if (!driver || !driver->dev || !driver->bind || composite)
>> return -EINVAL;
>>
>> @@ -1084,7 +1086,11 @@ int usb_composite_register(struct 
>> usb_composite_driver *driver)
>> driver->name = "composite";
>> composite = driver;
>>
>> -   return usb_gadget_register_driver(_driver);
>> +   res = usb_gadget_register_driver(_driver);
>> +   if (res != 0)
>> +   composite = NULL;
>> +
>> +   return res;
>>  }
>>
>>  /**
>> --
>> 2.7.0
>>

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

Re: [U-Boot] net: phy: atheros: Fix problem with phy_reset() clearing BMCR

[Joe Hershberger]

Hi Alison,

https://patchwork.ozlabs.org/patch/585059/ was applied to u-boot-net.git.

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

Re: [U-Boot] net: bootp: Add environment variable for timeout period

[Joe Hershberger]

Hi amessier.t...@gmail.com,

https://patchwork.ozlabs.org/patch/576715/ was applied to u-boot-net.git.

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

Re: [U-Boot] [PATCH 2/3] arm: dra7xx: Define Android partition table

[Sam Protsenko]

On Fri, Feb 26, 2016 at 5:37 PM, Tom Rini  wrote:
> On Fri, Feb 19, 2016 at 09:25:32PM +0200, Semen Protsenko wrote:
>
>> From: Sam Protsenko 
>>
>> "fastboot oem format" command reuses "gpt write" command, which in turn
>> requires correct partitions defined in $partitions variable. This patch
>> adds such definition of Android partitions for DRA7XX EVM board.
>>
>> While at it, enable CONFIG_RANDOM_UUID to spare user from providing
>> UUIDs for each partition manually.
>>
>> Signed-off-by: Sam Protsenko 
>> ---
>>  include/configs/dra7xx_evm.h | 20 
>>  1 file changed, 20 insertions(+)
>>
>> diff --git a/include/configs/dra7xx_evm.h b/include/configs/dra7xx_evm.h
>> index 4658283..e7e074d 100644
>> --- a/include/configs/dra7xx_evm.h
>> +++ b/include/configs/dra7xx_evm.h
>> @@ -42,10 +42,29 @@
>>  #define CONFIG_SYS_OMAP_ABE_SYSCK
>>
>>  #ifndef CONFIG_SPL_BUILD
>> +
>>  /* Define the default GPT table for eMMC */
>> +#ifndef CONFIG_ANDROID_BOOT
>>  #define PARTS_DEFAULT \
>>   "uuid_disk=${uuid_gpt_disk};" \
>>   "name=rootfs,start=2MiB,size=-,uuid=${uuid_gpt_rootfs}"
>> +#else
>> +#define PARTS_DEFAULT \
>> + "uuid_disk=${uuid_gpt_disk};" \
>> + "name=xloader,start=128K,size=128K,uuid=${uuid_gpt_xloader};" \
>> + "name=bootloader,size=384K,uuid=${uuid_gpt_bootloader};" \
>> + "name=environment,size=128K,uuid=${uuid_gpt_environment};" \
>> + "name=misc,size=128K,uuid=${uuid_gpt_misc};" \
>> + "name=efs,start=1280K,size=16M,uuid=${uuid_gpt_efs};" \
>> + "name=crypto,size=16K,uuid=${uuid_gpt_crypto};" \
>> + "name=recovery,size=10M,uuid=${uuid_gpt_recovery};" \
>> + "name=boot,size=10M,uuid=${uuid_gpt_boot};" \
>> + "name=system,size=768M,uuid=${uuid_gpt_system};" \
>> + "name=cache,size=256M,uuid=${uuid_gpt_cache};" \
>> + "name=ipu1,size=1M,uuid=${uuid_gpt_ipu1};" \
>> + "name=ipu2,size=1M,uuid=${uuid_gpt_ipu2};" \
>> + "name=userdata,size=-,uuid=${uuid_gpt_userdata}"
>> +#endif
>>
>>  #define DFU_ALT_INFO_MMC \
>>   "dfu_alt_info_mmc=" \
>> @@ -116,6 +135,7 @@
>>  /* Enhance our eMMC support / experience. */
>>  #define CONFIG_CMD_GPT
>>  #define CONFIG_EFI_PARTITION
>> +#define CONFIG_RANDOM_UUID
>>  #define CONFIG_HSMMC2_8BIT
>>
>>  /* CPSW Ethernet */
>
> I'm OK with the concept here.  But I think what I'd rather see instead
> of a 3 part series here is just changing the defaults to be what Android
> requires here.  No one else currently relies on the default layout we
> offer so lets just change it for what's required here, it's still
> functional enough for other possible uses.
>
> --
> Tom

Consider this patch abandoned as new version was sent aside from this patchset:
http://lists.denx.de/pipermail/u-boot/2016-February/246744.html
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] Pull request: u-boot-net.git master

[Joe Hershberger]

The following changes since commit 24862c640ea50ac88be343161eb681bea5dbfeef:

  test/py: skip tests that require large CONFIG_SYS_MAXARGS
(2016-02-26 08:42:12 -0500)

are available in the git repository at:

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

for you to fetch changes up to 50768f5b06e7704cf2bc209f89e250130c3fff5b:

  net: bootp: Add environment variable for timeout period (2016-02-26
13:37:38 -0600)


Alexandre Messier (1):
  net: bootp: Add environment variable for timeout period

Alison Wang (1):
  net: phy: atheros: Fix problem with phy_reset() clearing BMCR

 README|  6 ++
 drivers/net/phy/atheros.c |  3 +++
 net/bootp.c   | 11 ++-
 3 files changed, 19 insertions(+), 1 deletion(-)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] arm: dra7xx: Define Android partition table

[Semen Protsenko]

From: Sam Protsenko 

"fastboot oem format" command reuses "gpt write" command, which in turn
requires correct partitions defined in $partitions variable. This patch
adds such definition of Android partitions for DRA7XX EVM board.

By default $partitions variable contains Linux partition table. In order
to prepare Android environment one can run next commands from U-Boot
shell:

=> env set partitions $partitions_android
=> env save

After those operations one can go to fastboot mode and perform
"fastboot oem format" to create Android partition table.

While at it, enable CONFIG_RANDOM_UUID to spare user from providing
UUIDs for each partition manually.

Signed-off-by: Sam Protsenko 
---
 include/configs/dra7xx_evm.h | 20 +++-
 1 file changed, 19 insertions(+), 1 deletion(-)

diff --git a/include/configs/dra7xx_evm.h b/include/configs/dra7xx_evm.h
index 4658283..0196280 100644
--- a/include/configs/dra7xx_evm.h
+++ b/include/configs/dra7xx_evm.h
@@ -44,8 +44,25 @@
 #ifndef CONFIG_SPL_BUILD
 /* Define the default GPT table for eMMC */
 #define PARTS_DEFAULT \
+   /* Linux partitions */ \
"uuid_disk=${uuid_gpt_disk};" \
-   "name=rootfs,start=2MiB,size=-,uuid=${uuid_gpt_rootfs}"
+   "name=rootfs,start=2MiB,size=-,uuid=${uuid_gpt_rootfs}\0" \
+   /* Android partitions */ \
+   "partitions_android=" \
+   "uuid_disk=${uuid_gpt_disk};" \
+   "name=xloader,start=128K,size=128K,uuid=${uuid_gpt_xloader};" \
+   "name=bootloader,size=384K,uuid=${uuid_gpt_bootloader};" \
+   "name=environment,size=128K,uuid=${uuid_gpt_environment};" \
+   "name=misc,size=128K,uuid=${uuid_gpt_misc};" \
+   "name=efs,start=1280K,size=16M,uuid=${uuid_gpt_efs};" \
+   "name=crypto,size=16K,uuid=${uuid_gpt_crypto};" \
+   "name=recovery,size=10M,uuid=${uuid_gpt_recovery};" \
+   "name=boot,size=10M,uuid=${uuid_gpt_boot};" \
+   "name=system,size=768M,uuid=${uuid_gpt_system};" \
+   "name=cache,size=256M,uuid=${uuid_gpt_cache};" \
+   "name=ipu1,size=1M,uuid=${uuid_gpt_ipu1};" \
+   "name=ipu2,size=1M,uuid=${uuid_gpt_ipu2};" \
+   "name=userdata,size=-,uuid=${uuid_gpt_userdata}"
 
 #define DFU_ALT_INFO_MMC \
"dfu_alt_info_mmc=" \
@@ -116,6 +133,7 @@
 /* Enhance our eMMC support / experience. */
 #define CONFIG_CMD_GPT
 #define CONFIG_EFI_PARTITION
+#define CONFIG_RANDOM_UUID
 #define CONFIG_HSMMC2_8BIT
 
 /* CPSW Ethernet */
-- 
2.7.0

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

Re: [U-Boot] [PATCH 02/10] arm64: Make full va map code more dynamic

[Stephen Warren]

On 02/25/2016 09:36 AM, Alexander Graf wrote:



On 24.02.16 19:14, Stephen Warren wrote:

On 02/24/2016 05:11 AM, Alexander Graf wrote:

The idea to generate our pages tables from an array of memory ranges
is very sound. However, instead of hard coding the code to create up
to 2 levels of 64k granule page tables, we really should just create
normal 4k page tables that allow us to set caching attributes on 2M
or 4k level later on.

So this patch moves the full_va mapping code to 4k page size and
makes it fully flexible to dynamically create as many levels as
necessary for a map (including dynamic 1G/2M pages). It also adds
support to dynamically split a large map into smaller ones when
some code wants to set dcache attributes.

With all this in place, there is very little reason to create your
own page tables in board specific files.

Signed-off-by: Alexander Graf 



+/*
+ * This is a recursively called function to count the number of
+ * page tables we need to cover a particular PTE range. If you
+ * call this with level = -1 you basically get the full 48 bit
+ * coverage.
+ */
+static int count_required_pts(u64 addr, int level, u64 maxaddr)


I think this looks correct now. Nits below if a respin is needed for
other reasons.


+{
+int levelshift = level2shift(level);
+u64 levelsize = 1ULL << levelshift;
+u64 levelmask = levelsize - 1;
+u64 levelend = addr + levelsize;
+int r = 0;
+int i;
+bool is_level = false;


I might suggest renaming that is_level_needed. It's not obvious to me
exactly what the name "is_level" is intended to represent; the name
seems to represent whether something (unspecified) is a level or not.


We're basically asking the function whether a PTE for address  at
level  would be an inval/block/level PTE. is_level marks it as a
level pte.

I could maybe rename this into pte_type and create an enum that is
either PTE_INVAL, PTE_BLOCK or PTE_LEVEL.




+
+for (i = 0; i < ARRAY_SIZE(mem_map); i++) {
+struct mm_region *map = _map[i];
+u64 start = map->base;
+u64 end = start + map->size;
+
+/* Check if the PTE would overlap with the map */
+if (max(addr, start) <= min(levelend, end)) {
+start = max(addr, start);
+end = min(levelend, end);
+
+/* We need a sub-pt for this level */
+if ((start & levelmask) || (end & levelmask)) {
+is_level = true;
+break;
+}
+
+/* Lv0 can not do block PTEs, so do levels here too */
+if (level <= 0) {
+is_level = true;
+break;
+}
+}
+}
+
+/*
+ * Block PTEs at this level are already covered by the parent page
+ * table, so we only need to count sub page tables.
+ */
+if (is_level) {
+int sublevel = level + 1;
+u64 sublevelsize = 1ULL << level2shift(sublevel);
+
+/* Account for the new sub page table ... */
+r = 1;


"Account for the page table at /this/ level"? This may represent the
top-level (0/1) page table, not just sub page tables. The sub-level
accounting is via the recursive call to count_required_pts() I believe.


I think the easiest way to visualize what's going on is if we start with
level -1.

We basically ask the function at level -1 whether a PTE at level -1 (48
bits) would fit into a block PTE at level -1 (so the PTE spans all 48
bits) or whether we need to create a new level entry plus page table for it.


Hmm, I had overlooked that the call to count_required_pts() passed 
"start_level - 1" not "start_level". Now that I see that, your 
explanation makes more sense to me.


It'd be nice if some/all of this explanation were comments in the code 
to aid readers.


That said, I would have expected a slightly more direct calculation; why 
not:


int start_level = 0; // or 1 if small VA space
total_pts = count_required_pts(start_level);
total_pts += 4; // "random" number to account for later splits

int count_required_pts(int level, ...) {
int npts = 1; // the table at this level
for each pte slot at this level:
if a mem_map entry starts/stops within the pte slot:
npts += count_required_pts(level + 1, ...);
else:
// nothing; pte is either a block or inval at this level
return npts;
}

Still, the current code appears to work find, and can be ammended later 
if we want.



Obviously for all entries this resolves into a "yes, create a level PTE
entry and a new page table to point to". So at level=-1 we account for
the root page table which really is a "sub page table" here.

Then we recursively go through the address space that we cover, checking
whether a page fits into inval/block PTEs or we need to create page
tables for it as well.

So at level=0, we really are checking for PTEs that you'd have at
level=0 (38 bits). If the  combination at level=0 results
in "level", we need to 

Re: [U-Boot] [PATCH 3/5] usb: ehci: Implement V2P mapping

[Marek Vasut]

On 02/26/2016 08:12 PM, Stephen Warren wrote:
> On 02/26/2016 11:44 AM, Marek Vasut wrote:
>> On 02/26/2016 07:16 PM, Stephen Warren wrote:
>>
>> Hi!
>>
>> [...]
>>
 Tom reported this to me too, sorry :-(

 Do you have an idea how to fix this too? I am now installing arm64
   toolchain.
>>>
>>> I haven't looked at it yet. I've seen similar problems in the bast
>>> handled by casting between integer types before casting to pointers
>>> e.g. something like the following guess:
>>>
>>> uint32_t pa; void *p = (void *)(uintptr_t)pa;
>>
>> I just tried this, it should do the trick. Can you give it a spin ?
> 
> That does the trick, thanks.

Thanks! I'll finish buildman builds (I set it up, finally, yay!) and
submit a proper patch.

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

Re: [U-Boot] [PATCH 3/5] usb: ehci: Implement V2P mapping

[Stephen Warren]

On 02/26/2016 11:44 AM, Marek Vasut wrote:

On 02/26/2016 07:16 PM, Stephen Warren wrote:

Hi!

[...]


Tom reported this to me too, sorry :-(

Do you have an idea how to fix this too? I am now installing arm64
  toolchain.


I haven't looked at it yet. I've seen similar problems in the bast
handled by casting between integer types before casting to pointers
e.g. something like the following guess:

uint32_t pa; void *p = (void *)(uintptr_t)pa;


I just tried this, it should do the trick. Can you give it a spin ?


That does the trick, thanks.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Please pull u-boot-mpc85xx master

[Tom Rini]

On Fri, Feb 26, 2016 at 06:51:52PM +, york sun wrote:

> Tom,
> 
> The following changes since commit 24862c640ea50ac88be343161eb681bea5dbfeef:
> 
>   test/py: skip tests that require large CONFIG_SYS_MAXARGS (2016-02-26 
> 08:42:12
> -0500)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-mpc85xx.git master
> 
> for you to fetch changes up to cf23b4da624f32639d5cb9de6e3c9069ffd26ae5:
> 
>   powerpc/t208xqds: fix esdhc peripheral clock support (2016-02-26 10:48:07 
> -0800)
> 

Applied to u-boot/master, thanks!

-- 
Tom


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

[U-Boot] Please pull u-boot-mpc85xx master

[york sun]

Tom,

The following changes since commit 24862c640ea50ac88be343161eb681bea5dbfeef:

  test/py: skip tests that require large CONFIG_SYS_MAXARGS (2016-02-26 08:42:12
-0500)

are available in the git repository at:

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

for you to fetch changes up to cf23b4da624f32639d5cb9de6e3c9069ffd26ae5:

  powerpc/t208xqds: fix esdhc peripheral clock support (2016-02-26 10:48:07 
-0800)


Yangbo Lu (1):
  powerpc/t208xqds: fix esdhc peripheral clock support

 include/configs/T208xQDS.h |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Thanks.

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

Re: [U-Boot] [PATCH] powerpc/t208xqds: fix esdhc peripheral clock support

[york sun]

On 01/28/2016 12:41 AM, Yangbo Lu wrote:
> The patch that enabled eSDHC peripheral clock support had an
> obvious error as below. This patch is used to fix it.
> 
> +#define define CONFIG_FSL_ESDHC_USE_PERIPHERAL_CLK
> 
> Fixes: 3285e6cbcc1b ("powerpc/t2080qds: enable eSDHC peripheral clock 
> support")
> Signed-off-by: Yangbo Lu 
> ---
>  include/configs/T208xQDS.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Applied to u-boot-mpc85xx master. Awaiting upstream.

York

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

Re: [U-Boot] [PATCH 3/5] usb: ehci: Implement V2P mapping

[Marek Vasut]

On 02/26/2016 07:16 PM, Stephen Warren wrote:

Hi!

[...]

>> Tom reported this to me too, sorry :-(
>> 
>> Do you have an idea how to fix this too? I am now installing arm64
>>  toolchain.
> 
> I haven't looked at it yet. I've seen similar problems in the bast 
> handled by casting between integer types before casting to pointers 
> e.g. something like the following guess:
> 
> uint32_t pa; void *p = (void *)(uintptr_t)pa;

I just tried this, it should do the trick. Can you give it a spin ?

diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index 8f259be..0113c6c 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -237,7 +237,7 @@ static int ehci_shutdown(struct ehci_ctrl *ctrl)
 static int ehci_td_buffer(struct qTD *td, void *buf, size_t sz)
 {
uint32_t delta, next;
-   uint32_t addr = (unsigned long)buf;
+   unsigned long addr = (unsigned long)buf;
int idx;

if (addr != ALIGN(addr, ARCH_DMA_MINALIGN))

I am a bit worried about the u32 values all around the place. If the
buffer would be above 4GiB, we might have a problem.

>> Do you know about some nice arm64 board with USB for testing?
> 
> There's always the Jetson TX1; it is the p2371-2180 that I was 
> building above:
> 
> http://www.nvidia.com/object/jetson-tx1-dev-kit.html

If you have one you don't need ... ;-)

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

Re: [U-Boot] [PATCH v4 00/11] arm64: Unify MMU code v3

[Stephen Warren]

On 02/25/2016 05:49 PM, Alexander Graf wrote:

Howdy,

Currently on arm64 there is a big pile of mess when it comes to MMU
support and page tables. Each board does its own little thing and the
generic code is pretty dumb and nobody actually uses it.

This patch set tries to clean that up. After this series is applied,
all boards except for the FSL Layerscape ones are converted to the
new generic page table logic and have icache+dcache enabled.

The new code always uses 4k page size. It dynamically allocates 1G or
2M pages for ranges that fit. When a dcache attribute request comes in
that requires a smaller granularity than our previous allocation could
fulfill, pages get automatically split.

I have tested and verified the code works on HiKey (bare metal),
vexpress64 (Foundation Model) and zynqmp (QEMU). The TX1 target is
untested, but given the simplicity of the maps I doubt it'll break.
ThunderX in theory should also work, but I haven't tested it. I would
be very happy if people with access to those system could give the patch
set a try.

With this we're a big step closer to a good base line for EFI payload
support, since we can now just require that all boards always have dcache
enabled.

I would also be incredibly happy if some Freescale people could look
at their MMU code and try to unify it into the now cleaned up generic
code. I don't think we're far off here.


Tested-by: Stephen Warren 
(On p2371- and p2371-2180)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V2 6/6] configs: k2g_evm: Add TI power processor support

[Tom Rini]

On Thu, Feb 25, 2016 at 12:53:47PM -0600, Nishanth Menon wrote:

> Enable support for PMMC the TI power processor on K2G. This processor
> manages all power management related activities on the SoC and and
> allows the Operating Systems on compute processors such as ARM, DSP to
> offload the power logic away into the power processor.
> 
> Signed-off-by: Nishanth Menon 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH V2 4/6] remoteproc: Add support for TI power processor

[Tom Rini]

On Thu, Feb 25, 2016 at 12:53:45PM -0600, Nishanth Menon wrote:

> Many TI System on Chip (SoC) solutions do have a dedicated
> microcontroller for doing power management functionality. These include
> the AM335x, AM437x, Keystone K2G SoCs. The functionality provided by
> these microcontrollers and the communication mechanisms vary very
> widely. However, we are able to consolidate some basic functionality to
> be generic enough starting with K2G SoC family. Introduce a basic remote
> proc driver to support these microcontrollers. In fact, on SoCs starting
> with K2G, basic power management functions are primarily accessible for
> the High Level Operating Systems(HLOS) via these microcontroller solutions.
> 
> Hence, having these started at a bootloader level is pretty much
> mandatory.
> 
> Signed-off-by: Nishanth Menon 

Reviewed-by: Tom Rini 

-- 
Tom


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

[U-Boot] [PATCH] arm: socfpga: Fix SR1500 env position

[Marek Vasut]

Move the inclusion of the common socfpga configuration file further
down in the sr1500 configuration, so that the socfpga_common.h can
check if environment is in SPI NOR and it's location is defined and
if it is not, define default location.

This fixes "arm: socfpga: Enabling U-Boot environment support in QSPI"
which introduced a minor warning.

Signed-off-by: Marek Vasut 
Cc: Chin Liang See 
Cc: Dinh Nguyen 
Cc: Dinh Nguyen 
Cc: Pavel Machek 
Cc: Marek Vasut 
Cc: Stefan Roese 
---
 include/configs/socfpga_sr1500.h | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/include/configs/socfpga_sr1500.h b/include/configs/socfpga_sr1500.h
index fdf67ca..e4aafaa 100644
--- a/include/configs/socfpga_sr1500.h
+++ b/include/configs/socfpga_sr1500.h
@@ -92,13 +92,6 @@
 #define CONFIG_SYS_BOOTCOUNT_ADDR  0xfff8
 #define CONFIG_SYS_BOOTCOUNT_BE
 
-/* The rest of the configuration is shared */
-#include 
-
-/* U-Boot payload is stored at offset 0x6 */
-#undef CONFIG_SYS_SPI_U_BOOT_OFFS
-#define CONFIG_SYS_SPI_U_BOOT_OFFS 0x6
-
 /* Environment setting for SPI flash */
 #undef CONFIG_ENV_SIZE
 #define CONFIG_SYS_REDUNDAND_ENVIRONMENT
@@ -111,4 +104,11 @@
 #define CONFIG_ENV_SPI_MODESPI_MODE_3
 #define CONFIG_ENV_SPI_MAX_HZ  CONFIG_SF_DEFAULT_SPEED
 
+/* The rest of the configuration is shared */
+#include 
+
+/* U-Boot payload is stored at offset 0x6 */
+#undef CONFIG_SYS_SPI_U_BOOT_OFFS
+#define CONFIG_SYS_SPI_U_BOOT_OFFS 0x6
+
 #endif /* __CONFIG_SOCFPGA_SR1500_H__ */
-- 
2.7.0

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

Re: [U-Boot] [PATCH V2 5/6] ARM: dts: k2g: Add support for PMMC

[Tom Rini]

On Thu, Feb 25, 2016 at 12:53:46PM -0600, Nishanth Menon wrote:

> Enable support for PMMC the TI power processor on K2G. This processor
> manages all power management related activities on the SoC and and
> allows the Operating Systems on compute processors such as ARM, DSP to
> offload the power logic away into the power processor. U-boot just has a
> load responsibility, hence the view of the hardware from a bootloader
> perspective is different from the view of hardware from a Operating
> System perspective. While bootloader just loads up the firmware,
> Operating Systems look at the resultant system as "hardware".
> 
> Signed-off-by: Nishanth Menon 

Reviewed-by: Tom Rini 

... and this will match whatever is in the kernel, right?

-- 
Tom


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

Re: [U-Boot] [PATCH V2 2/6] ARM: keystone2: psc-defs: use adequate () for macros

[Tom Rini]

On Thu, Feb 25, 2016 at 12:53:43PM -0600, Nishanth Menon wrote:

> '#define X a | b' is better defined as '#define X (a | b)' for obvious
> reasons.
> 
> Signed-off-by: Nishanth Menon 

Reviewed-by: Tom Rini 

But this makes my head hurt.  Can we somehow do any of that with less
parenthesis?  Like, is this really something we must macro? Or can we
re-factor it?  I had to highlight every open/close to be happy it was
correct, which is not a good sign.

-- 
Tom


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

Re: [U-Boot] [PATCH V2 3/6] ARM: keystone2: psc: introduce function to hold and release module in reset.

[Tom Rini]

On Thu, Feb 25, 2016 at 12:53:44PM -0600, Nishanth Menon wrote:

> These are useful for modules that need to be held in reset and are
> enabled for data to be loaded on to them. Typically these are
> microcontrollers or other processing entities in the system.
> 
> Signed-off-by: Nishanth Menon 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH V5 7/7] board: ti: AM57xx: Add detection logic for AM57xx-evm

[Tom Rini]

On Wed, Feb 24, 2016 at 12:30:58PM -0600, Steve Kipisz wrote:

> Current AM57xx evm supports both BeagleBoard-X15
> (http://beagleboard.org/x15) and AM57xx EVM
> (http://www.ti.com/tool/tmdxevm5728).
> 
> The AM572x EValuation Module(EVM) provides an affordable platform to
> quickly start evaluation of Sitara. ARM Cortex-A15 AM57x Processors
> (AM5728, AM5726, AM5718, AM5716) and accelerate development for HMI,
> machine vision, networking, medical imaging and many other industrial
> applications. This EVM is based on the same BeagleBoard-X15 Chassis
> and adds mPCIe, mSATA, LCD, touchscreen, Camera, push button and TI's
> wlink8 offering.
> 
> Since the EEPROM contents are compatible between the BeagleBoard-X15 and
> the AM57xx-evm, we add support for the detection logic to enable
> support for various user programmable scripting capability.
> 
> NOTE: U-boot configuration is currently a superset of AM57xx evm and
> BeagleBoard-X15 and no additional configuration tweaking is needed.
> 
> This change also sets up the stage for future support of TI AM57xx EVMs
> to the same base bootloader build.
> 
> Signed-off-by: Steve Kipisz 
> Signed-off-by: Lokesh Vutla 
> Signed-off-by: Nishanth Menon 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH V5 0/7] ARM: omap-common: Add board detection support for TI EVMs

[Tom Rini]

On Wed, Feb 24, 2016 at 12:30:51PM -0600, Steve Kipisz wrote:

> Several TI EVMs have onboard EEPROM that contain board description
> information. The onboard EEPROM on Beaglebone, Beaglebone Black, AM335x
> EVM, AM43x EVM, AM57xx EVM, Beagleboard-x15 all share the same format.
> 
> This series of patches introduces code which is generic among these
> platforms. The boards can use the data for any operations they might
> choose.
> 
> V5 of the series now updates the v4 series to ensure that latest u-boot
> platform support including BBG is supported as well.
> This also setsup easier introduction of DRA7-evm variant of eeproms as well.
> 
> Testing:
> AM335x:
>   BeagleBone-Green: http://pastebin.ubuntu.com/15183845/
>   BeagleBone-Black: http://pastebin.ubuntu.com/15183885/
>   AM335x-SK: http://pastebin.ubuntu.com/15188966/
> 
> AM437x:
>   AM437x-GPEVM: http://pastebin.ubuntu.com/15188896/
>   AM437x-SK: http://pastebin.ubuntu.com/15188940/
> 
> Am57xx:
>   AM57xx-gpevm: http://pastebin.ubuntu.com/15188997/
> 
> baseline:
>   master 595af9db2422 Merge branch 'master' of 
> git://www.denx.de/git/u-boot-imx

I like this, it all looks good.  But it's too late to take in for this
release given the number of different boards that get changed in the
end.  I'll pick this up after the v2016.03 release, thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH V2 1/6] ARM: keystone2: psc: redo doc in kernel-doc format

[Tom Rini]

On Thu, Feb 25, 2016 at 12:53:42PM -0600, Nishanth Menon wrote:

> u-boot coding style guidance in
> http://www.denx.de/wiki/U-Boot/CodingStyle clearly mentions that the
> kernel doc style shall be followed for documentation in u-boot.
> 
> Current PSC documentation standard does not, so fix that.
> 
> Signed-off-by: Nishanth Menon 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH V5 6/7] ARM: OMAP4/5: Add generic board detection hook

[Tom Rini]

On Wed, Feb 24, 2016 at 12:30:57PM -0600, Steve Kipisz wrote:

> Many TI EVMs have capability to store relevant board information
> such as DDR description in EEPROM. Further many pad configuration
> variations can occur as part of revision changes in the platform.
> In-order to support these at runtime, we for a board detection hook
> which is available for override from board files that may desire to do
> so.
> 
> NOTE: All TI EVMs are capable of detecting board information based on
> early clocks that are configured. However, in case of additional needs
> this can be achieved within the override logic from within the board
> file.
> 
> Signed-off-by: Steve Kipisz 
> Reviewed-by: Tom Rini 
> Reviewed-by: Lokesh Vutla 

Reviewed-by: Tom Rini 

-- 
Tom


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

[U-Boot] [PATCH 2/2] warp7: Add initial support

[Fabio Estevam]

From: Fabio Estevam 

Add the basic support for Warp7 board.

For more information about this reference design, please visit:

https://www.element14.com/community/docs/DOC-79058/l/warp-7-the-next-generation-wearable-reference-platform

Signed-off-by: Fabio Estevam 
---
 arch/arm/cpu/armv7/mx7/Kconfig |   6 ++
 board/warp7/Kconfig|   9 +++
 board/warp7/MAINTAINERS|   6 ++
 board/warp7/Makefile   |   6 ++
 board/warp7/imximage.cfg   |  95 ++
 board/warp7/warp7.c| 102 
 configs/warp7_defconfig|  12 
 include/configs/warp7.h| 149 +
 8 files changed, 385 insertions(+)
 create mode 100644 board/warp7/Kconfig
 create mode 100644 board/warp7/MAINTAINERS
 create mode 100644 board/warp7/Makefile
 create mode 100644 board/warp7/imximage.cfg
 create mode 100644 board/warp7/warp7.c
 create mode 100644 configs/warp7_defconfig
 create mode 100644 include/configs/warp7.h

diff --git a/arch/arm/cpu/armv7/mx7/Kconfig b/arch/arm/cpu/armv7/mx7/Kconfig
index 97d6238..58d9bbf 100644
--- a/arch/arm/cpu/armv7/mx7/Kconfig
+++ b/arch/arm/cpu/armv7/mx7/Kconfig
@@ -18,11 +18,17 @@ config TARGET_MX7DSABRESD
select DM
select DM_THERMAL
 
+config TARGET_WARP7
+   bool "warp7"
+   select DM
+   select DM_THERMAL
+
 endchoice
 
 config SYS_SOC
default "mx7"
 
 source "board/freescale/mx7dsabresd/Kconfig"
+source "board/warp7/Kconfig"
 
 endif
diff --git a/board/warp7/Kconfig b/board/warp7/Kconfig
new file mode 100644
index 000..61c33fb
--- /dev/null
+++ b/board/warp7/Kconfig
@@ -0,0 +1,9 @@
+if TARGET_WARP7
+
+config SYS_BOARD
+   default "warp7"
+
+config SYS_CONFIG_NAME
+   default "warp7"
+
+endif
diff --git a/board/warp7/MAINTAINERS b/board/warp7/MAINTAINERS
new file mode 100644
index 000..1d3ee29
--- /dev/null
+++ b/board/warp7/MAINTAINERS
@@ -0,0 +1,6 @@
+WARP7 BOARD
+M: Fabio Estevam 
+S: Maintained
+F: board/warp7/
+F: include/configs/warp7.h
+F: configs/warp7_defconfig
diff --git a/board/warp7/Makefile b/board/warp7/Makefile
new file mode 100644
index 000..f39d1d8
--- /dev/null
+++ b/board/warp7/Makefile
@@ -0,0 +1,6 @@
+# (C) Copyright 2016 NXP Semiconductors
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+obj-y  := warp7.o
diff --git a/board/warp7/imximage.cfg b/board/warp7/imximage.cfg
new file mode 100644
index 000..e7b6d30
--- /dev/null
+++ b/board/warp7/imximage.cfg
@@ -0,0 +1,95 @@
+/*
+ * Copyright (C) 2016 NXP Semiconductors
+ *
+ * SPDX-License-Identifier:GPL-2.0
+ *
+ * Refer docs/README.imxmage for more details about how-to configure
+ * and create imximage boot image
+ *
+ * The syntax is taken as close as possible with the kwbimage
+ */
+
+#define __ASSEMBLY__
+#include 
+
+IMAGE_VERSION  2
+BOOT_FROM  sd
+
+/*
+ * Device Configuration Data (DCD)
+ *
+ * Each entry must have the format:
+ * Addr-type   AddressValue
+ *
+ * where:
+ * Addr-type register length (1,2 or 4 bytes)
+ * Address   absolute address of the register
+ * value value to be stored in the register
+ */
+
+DATA 4 0x30340004 0x4F45
+
+DATA 4 0x30391000 0x0002
+DATA 4 0x307a 0x03040008
+DATA 4 0x307a0064 0x00200038
+DATA 4 0x307a0490 0x0001
+DATA 4 0x307a00d0 0x00350001
+DATA 4 0x307a00dc 0x00c3000a
+DATA 4 0x307a00e0 0x0001
+DATA 4 0x307a00e4 0x00110006
+DATA 4 0x307a00f4 0x033f
+DATA 4 0x307a0100 0x0a0e110b
+DATA 4 0x307a0104 0x00020211
+DATA 4 0x307a0108 0x03060708
+DATA 4 0x307a010c 0x00a0500c
+DATA 4 0x307a0110 0x05020307
+DATA 4 0x307a0114 0x02020404
+DATA 4 0x307a0118 0x02020003
+DATA 4 0x307a011c 0x0202
+DATA 4 0x307a0120 0x0202
+
+DATA 4 0x307a0180 0x00600018
+DATA 4 0x307a0184 0x00e00100
+DATA 4 0x307a0190 0x02098205
+DATA 4 0x307a0194 0x00060303
+DATA 4 0x307a01a0 0x8043
+DATA 4 0x307a01a4 0x00100020
+DATA 4 0x307a01a8 0x8014
+
+DATA 4 0x307a0200 0x0015
+DATA 4 0x307a0204 0x00161616
+DATA 4 0x307a0210 0x0f0f
+DATA 4 0x307a0214 0x04040404
+DATA 4 0x307a0218 0x0f0f0404
+
+DATA 4 0x307a0240 0x06000600
+DATA 4 0x307a0244 0x
+DATA 4 0x30391000 0x
+DATA 4 0x3079 0x17421e40
+DATA 4 0x30790004 0x10210100
+DATA 4 0x30790008 0x0001
+DATA 4 0x30790010 0x0007080c
+DATA 4 0x307900b0 0x1010007e
+
+DATA 4 0x3079001C 0x0101
+DATA 4 0x3079009c 0x0d6e
+
+DATA 4 0x30790030 0x06060606
+DATA 4 0x30790020 0x0a0a0a0a
+DATA 4 0x30790050 0x0108
+DATA 4 0x30790050 0x0008
+DATA 4 0x30790018 0x000f
+DATA 4 0x307900c0 0x0e487304
+DATA 4 0x307900c0 0x0e4c7304
+DATA 4 0x307900c0 0x0e4c7306
+DATA 4 0x307900c0 0x0e4c7304
+
+CHECK_BITS_SET 4 0x307900c4 0x1
+
+DATA 4 0x307900c0 0x0e487304
+
+DATA 4 0x30384130 0x
+DATA 4 0x30340020 0x0178
+DATA 4 0x30384130 0x0002
+
+CHECK_BITS_SET 4 0x307a0004 0x1
diff --git 

[U-Boot] [PATCH 1/2] mx7_common: Put early/late init configs into board file

[Fabio Estevam]

From: Fabio Estevam 

CONFIG_BOARD_EARLY_INIT_F and CONFIG_BOARD_LATE_INIT should not be
placed into mx7_common because not all boards need these options.

Move them to the board file instead.

Signed-off-by: Fabio Estevam 
---
 include/configs/mx7_common.h  | 3 ---
 include/configs/mx7dsabresd.h | 3 +++
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/include/configs/mx7_common.h b/include/configs/mx7_common.h
index fac7c3f..a78fc7c 100644
--- a/include/configs/mx7_common.h
+++ b/include/configs/mx7_common.h
@@ -32,9 +32,6 @@
 /* Size of malloc() pool */
 #define CONFIG_SYS_MALLOC_LEN   (32 * SZ_1M)
 
-#define CONFIG_BOARD_EARLY_INIT_F
-#define CONFIG_BOARD_LATE_INIT
-
 #define CONFIG_DISPLAY_CPUINFO
 #define CONFIG_DISPLAY_BOARDINFO
 
diff --git a/include/configs/mx7dsabresd.h b/include/configs/mx7dsabresd.h
index 2c981e0..d233572 100644
--- a/include/configs/mx7dsabresd.h
+++ b/include/configs/mx7dsabresd.h
@@ -14,6 +14,9 @@
 #define CONFIG_DBG_MONITOR
 #define PHYS_SDRAM_SIZESZ_1G
 
+#define CONFIG_BOARD_EARLY_INIT_F
+#define CONFIG_BOARD_LATE_INIT
+
 /* Uncomment to enable secure boot support */
 /* #define CONFIG_SECURE_BOOT */
 #define CONFIG_CSF_SIZE0x4000
-- 
1.9.1

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

Re: [U-Boot] [PATCH 3/5] usb: ehci: Implement V2P mapping

[Stephen Warren]

On 02/26/2016 09:55 AM, Marek Vasut wrote:

On 02/26/2016 05:48 PM, Stephen Warren wrote:

On 01/26/2016 07:14 PM, Marek Vasut wrote:

Certain processor architectures, like MIPS, require that the USB
structures and transfer buffers are passed with their PA to the
USB controller. If VA is passed, the USB will not work. Add the
necessary virt_to_phys() calls into the USB EHCI code to make it
work.


FYI, this causes some cast size warnings, e.g.:


+make
O=/home/swarren/shared/git_wa/tegra-uboot-flasher/u-boot/build-p2371-2180
-s p2371-2180_defconfig
+make
O=/home/swarren/shared/git_wa/tegra-uboot-flasher/u-boot/build-p2371-2180
-s -j8
In file included from ../arch/arm/include/asm/byteorder.h:29:0,
  from ../include/compiler.h:125,
  from ../include/image.h:19,
  from ../include/common.h:88,
  from ../drivers/usb/host/ehci-hcd.c:10:
../drivers/usb/host/ehci-hcd.c: In function ‘ehci_td_buffer’:
../drivers/usb/host/ehci-hcd.c:248:49: warning: cast to pointer from
integer of different size [-Wint-to-pointer-cast]
td->qt_buffer[idx] = cpu_to_hc32(virt_to_phys((void *)addr));
  ^
../include/linux/byteorder/little_endian.h:34:51: note: in definition
of macro ‘__cpu_to_le32’
  #define __cpu_to_le32(x) ((__force __le32)(__u32)(x))
^
../drivers/usb/host/ehci-hcd.c:248:24: note: in expansion of macro
‘cpu_to_hc32’
td->qt_buffer[idx] = cpu_to_hc32(virt_to_phys((void *)addr));
 ^


(This is a 64-bit ARM platform, so I had CROSS_COMPILE=aarch64-linux-gnu-)


Tom reported this to me too, sorry :-(

Do you have an idea how to fix this too? I am now installing arm64
toolchain.


I haven't looked at it yet. I've seen similar problems in the bast 
handled by casting between integer types before casting to pointers e.g. 
something like the following guess:


uint32_t pa;
void *p = (void *)(uintptr_t)pa;


Do you know about some nice arm64 board with USB for testing?


There's always the Jetson TX1; it is the p2371-2180 that I was building 
above:


http://www.nvidia.com/object/jetson-tx1-dev-kit.html

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

Re: [U-Boot] [PATCH V5 5/7] ti: AM437x: Use generic EEPROM detection logic

[Tom Rini]

On Wed, Feb 24, 2016 at 12:30:56PM -0600, Steve Kipisz wrote:

> From: Nishanth Menon 
> 
> Now that we have a generic TI eeprom logic which can be reused across
> platforms, reuse the same.
> 
> This revision also includes fixes identified by Dave Gerlach
> 
> 
> Cc: Dave Gerlach 
> Signed-off-by: Nishanth Menon 
> Signed-off-by: Steven Kipisz 
> Signed-off-by: Lokesh Vutla 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH V5 4/7] ti: AM335x: Use generic EEPROM detection logic

[Tom Rini]

On Wed, Feb 24, 2016 at 12:30:55PM -0600, Steve Kipisz wrote:

> From: Nishanth Menon 
> 
> Use the generic EEPROM detection logic instead of duplicating the AM
> eeprom logic.
> 
> Signed-off-by: Nishanth Menon 
> Signed-off-by: Steven Kipisz 
> Signed-off-by: Lokesh Vutla 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH V5 3/7] ARM: omap-common: Add standard access for board description EEPROM

[Tom Rini]

On Wed, Feb 24, 2016 at 12:30:54PM -0600, Steve Kipisz wrote:

> From: Lokesh Vutla 
> 
> Several TI EVMs have EEPROM that can contain board description information
> such as revision, DDR definition, serial number, etc. In just about all
> cases, these EEPROM are on the I2C bus and provides us the opportunity
> to centralize the generic operations involved.
> 
> The on-board EEPROM on the BeagleBone Black, BeagleBone, AM335x EVM,
> AM43x GP EVM, AM57xx-evm, BeagleBoard-X15 share the same format.
> However, DRA-7* EVMs, OMAP4SDP use a modified format.
> 
> We hence introduce logic which is generic between these platforms
> without enforcing any specific format. This allows the boards to use the
> relevant format for operations that they might choose.
> 
> This module will compile for all TI SoC based boards when
> CONFIG_TI_I2C_BOARD_DETECT is enabled to have optimal build times for
> platforms that require this support.
> 
> It is important to note that this logic is fundamental to the board
> configuration process such as DDR configuration which is needed in
> SPL, hence cannot be part of the standard u-boot driver model (which
> is available later in the process). Hence, to aid efficiency, the
> eeprom contents are copied over to SRAM scratchpad memory area at the
> first invocation to retrieve data.
> 
> To prevent churn with cases such as DRA7, where eeprom format maybe
> incompatible, we introduce a generic common format in eeprom which
> is made available over accessor functions for usage.
> 
> Special handling for BBG1 EEPROM had to be introduced thanks to the
> weird eeprom rev contents used.
> 
> The follow on patches introduce the use of this library for AM335x,
> AM437x, and AM57xx.
> 
> Signed-off-by: Lokesh Vutla 
> Signed-off-by: Steve Kipisz 
> Signed-off-by: Roger Quadros 
> Signed-off-by: Nishanth Menon 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH V5 2/7] ARM: OMAP4/5: Centralize gpi2c_init

[Tom Rini]

On Wed, Feb 24, 2016 at 12:30:53PM -0600, Steve Kipisz wrote:

> Centralize gpi2c_init into omap_common from the sys_proto header so
> that the information can be reused across SoCs.
> 
> Signed-off-by: Steve Kipisz 
> Reviewed-by: Tom Rini 
> Reviewed-by: Lokesh Vutla 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH V5 1/7] ARM: OMAP4/5: Centralize early clock initialization

[Tom Rini]

On Wed, Feb 24, 2016 at 12:30:52PM -0600, Steve Kipisz wrote:

> Early clock initialization is currently done in two stages for OMAP4/5
> SoCs. The first stage is the initialization of console clocks and
> then we initialize basic clocks for functionality necessary for SoC
> initialization and basic board functionality.
> 
> By splitting up prcm_init and centralizing this clock initialization,
> we setup the code for follow on patches that can do board specific
> initialization such as board detection which will depend on these
> basic clocks.
> 
> As part of this change, since the early clock initialization
> is centralized, we no longer need to expose the console clock
> initialization.
> 
> NOTE: we change the sequence slightly by initializing console clocks
> timer after the io settings are complete, but this is not expected
> to have any functioanlity impact since we setup the basic IO drive
> strength initialization as part of do_io_settings.
> 
> Signed-off-by: Steve Kipisz 
> Reviewed-by: Tom Rini 
> Reviewed-by: Lokesh Vutla 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH 6/6] ARM: keystone2: use detected ddr3a size

[Tom Rini]

On Thu, Feb 25, 2016 at 09:52:15AM -0600, Nishanth Menon wrote:

> From: Vitaly Andrianov 
> 
> Because KS2 u-boot works in 32 bit address space the existing ram_size
> global data field cannot be used. The maximum, which the get_ram_size()
> can detect is 2GB only. The ft_board_setup() needs the actual ddr3 size
> to fix up dtb.
> 
> This commit introduces the ddr3_get_size() which uses SPD data to
> calculate the ddr3 size. This function replaces the "ddr3_size"
> environment variable, which was used to get the SODIMM size.
> 
> For platforms, which don't have SODIMM with SPD and ddr3 is populated to
> a board a simple ddr3_get_size function that returns ddr3 size has to be
> implemented. See hardware-k2l.h
> 
> Signed-off-by: Vitaly Andrianov 
> Signed-off-by: Nishanth Menon 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH 5/6] ARM: keystone2: use SPD info to configure K2HK and K2E DDR3

[Tom Rini]

On Thu, Feb 25, 2016 at 09:52:14AM -0600, Nishanth Menon wrote:

> From: Vitaly Andrianov 
> 
> This commit replaces hard-coded EMIF and PHY DDR3 configurations for
> predefined SODIMMs to a calculated configuration. The SODIMM parameters
> are read from SODIMM's SPD and used to calculated the configuration.
> 
> The current commit supports calculation for DDR3 with 1600MHz and 1333MHz
> only.
> 
> Signed-off-by: Vitaly Andrianov 
> Signed-off-by: Lokesh Vutla 
> Signed-off-by: Nishanth Menon 
[snip]
> +#ifdef DUMP_DDR_CONFIG
> +static void dump_phy_config(struct ddr3_phy_config *ptr)

Please figure out how to do this with debug() instead.

[snip]
> + puts("DDR3A Speed will be configured for 1333 Operation.\n");

Just printf, always, it's fine, really.

-- 
Tom


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

Re: [U-Boot] [PATCH 4/6] ARM: keystone2: K2G: Add support for different arm/device speeds

[Tom Rini]

On Thu, Feb 25, 2016 at 09:52:13AM -0600, Nishanth Menon wrote:

> From: Lokesh Vutla 
> 
> The maximum device and arm speeds can be determined by reading
> EFUSE_BOOTROM register. As there is already a framework for reading this
> register, adding support for all possible speeds on k2g devices.
> 
> Signed-off-by: Lokesh Vutla 
> Signed-off-by: Nishanth Menon 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH 3/6] ARM: keystone2: Allow for board specific speed definitions

[Tom Rini]

On Thu, Feb 25, 2016 at 09:52:12AM -0600, Nishanth Menon wrote:

> From: Lokesh Vutla 
> 
> Its not compulsory that speed definition should be same on EFUSE_BOOTROM
> register for all keystone 2 devices. So, allow for board specific
> speed definitions.
> 
> Signed-off-by: Lokesh Vutla 
> Signed-off-by: Nishanth Menon 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH 2/6] ARM: keystone2: K2G: power-off DSP during boot

[Tom Rini]

On Thu, Feb 25, 2016 at 09:52:11AM -0600, Nishanth Menon wrote:

> From: Suman Anna 
> 
> The DSPs are powered on by default upon a Power ON reset, and
> they are powered off on current Keystone 2 SoCs - K2HK, K2L, K2E
> during the boot in u-boot. This is not functional on K2G though.
> Extend the existing DSP power-off support to the only DSP present
> on K2G. Do note that the PSC clock domain module id for DSP on K2G
> differs from that of previous Keystone2 SoCs.
> 
> Signed-off-by: Suman Anna 
> Signed-off-by: Nishanth Menon 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH 1/6] ARM: keystone2: Use macro for DSP GEM power domain

[Tom Rini]

On Thu, Feb 25, 2016 at 09:52:10AM -0600, Nishanth Menon wrote:

> From: Suman Anna 
> 
> Define a macro for the DSP GEM power domain id number and
> use it instead of a hard-coded number in the code that
> disables all the DSPs on various Keystone2 SoCs.
> 
> Signed-off-by: Suman Anna 
> Signed-off-by: Nishanth Menon 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [RFC PATCH v5 1/4] common: Convert ulong to phys_addr_t for image addresses

[york sun]

On 02/26/2016 10:05 AM, Simon Glass wrote:



>
> All these double casts look somewhat wrong to me.  Why are they
> needed?

 Dear Wolfgang,

 I can use some serious help here. What I am really trying to achieve is 
 the last
 two patches in this set. I didn't want to use replace ulong with 
 phys_addr_t. I
 am not proud with the change I proposed, but I didn't come up with a 
 smarter
 solution. My specific trouble is to build ARMv8 targets on 32-bit Ubuntu 
 host.
 Some code is shared between the target and host tool (mkimage). I started 
 from
 small changes, but it gets wider and wider when I tried to get rid of the
 compiling warnings.

 York

>>>
>>> I suggest just documenting it better with comments and in the commit
>>> message. It's mostly the same comment I made.
>>>
>>> One concern is that if you cast to uintptr_t on a 32-bit host machine,
>>> won't you end up dropping the top 32 bits?
>>>
>>
>> Simon,
>>
>> Some code is shared between targets and hosts, but not all. The ugly casting 
>> is
>> used by targets only. Maybe I should take another look at the issue and back
>> away from converting ulong to phys_addr_t totally. It is only broken on 
>> 32-bit
>> host tool and seems nobody really cares. Sandbox is also broken on 32-bit 
>> host
>> (compiling warnings), and yet no one complains. Am I the only one living in 
>> old
>> age? I can upgrade to 64-bit Ubuntu and we all can forget about this mess I
>> created. (Getting exhausted here...)
> 
> Well maybe. You could instead just print an error and quit when trying
> to use 64-bit images on a 32-bit host machine. I think that would be
> acceptable these days.
> 

Sounds good to me. Let me try to rework the patch set.

York


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

Re: [U-Boot] [RFC PATCH v5 1/4] common: Convert ulong to phys_addr_t for image addresses

[Simon Glass]

Hi York,

On 26 February 2016 at 10:47, york sun  wrote:
> On 02/26/2016 09:31 AM, Simon Glass wrote:
>> Hi York,
>>
>> On 26 February 2016 at 10:22, york sun  wrote:
>>> On 02/25/2016 03:05 PM, Wolfgang Denk wrote:
 Dear York Sun,

 In message <1456439779-4792-2-git-send-email-york@nxp.com> you wrote:
> When dealing with image addresses, ulong has been used. Some files
> are used by both host and target. It is OK for the target, but not
> always enough for host tools including mkimage. This patch replaces
> "ulong" with "phys_addr_t" to make sure addresses are correct for
> both the target and the host.

 You talk here about using "phys_addr_t"...

> -   ulong, ulong, ulong))images->ep;
> +   ulong, ulong, ulong))(uintptr_t)images->ep;

 ...but here you use  uintptr_t  , hich is something different?

> -ulong, ulong, ulong))images->ep)(images->ft_addr,
> +ulong, ulong, ulong))(uintptr_t)images->ep)(images->ft_addr,

 Ditto.

> +phys_addr_t os_data;
> +ulong os_len;
>  void *data = NULL;
>  size_t len;
>  int ret;
> @@ -87,11 +89,10 @@ static int boot_prep_linux(bootm_headers_t *images)
>  if (images->legacy_hdr_valid) {
>  hdr = images->legacy_hdr_os;
>  if (image_check_type(hdr, IH_TYPE_MULTI)) {
> -ulong os_data, os_len;

 Why do you moe the declarations out of this block?  The variables are
 only used within this block so there is no need for a wider scope?

> -data = (void *)os_data;
> +data = (void *)(uintptr_t)os_data;

 This double cast looks scary to me, and you don;t explain it in the
 commit message.  Why exactly is this needed?

> -cmd_line_dest = (void *)images->ep + COMMAND_LINE_OFFSET;
> +cmd_line_dest = (void *)(uintptr_t)images->ep +
> +COMMAND_LINE_OFFSET;

 Ditto.

> -printf("Setup at %#08lx\n", images->ep);
> -ret = setup_zimage((void *)images->ep, cmd_line_dest,
> +printf("Setup at %#08" PRIpa "\n", images->ep);

 This is really ugly...

> +ret = setup_zimage((void *)(uintptr_t)images->ep, cmd_line_dest,

 See before.

> -debug("## Transferring control to Linux (at address %08lx, kernel 
> %08lx) ...\n",
> +debug("## Transferring control to Linux (at address %#08" PRIpa
> +  ", kernel %#08" PRIpa ") ...\n",

 See before...

> -debug("*  kernel: cmdline image address = 0x%08lx\n",
> -images->ep);
> +debug("*  kernel: cmdline image address = %#08" PRIpa "\n",
> +  images->ep);

 Ditto.  etc. etc.

> +/*
> + * In this function, data is decalred as phys_addr_t type.

 s/decalred/declared/

> + * On some systems (eg. ARM, PowerPC) phys_addr_t can be
> + * "unsigned long", or "unsigned long long", depending on
> + * CONFIG_PHYS_64BIT.  It is safe to cast 64-bit phys_addr_t
> + * to 32-bit pointer for image handling because the actual
> + * address the image is loaded is within 32-bit space.

 Who guarantees that?

> -data = (ulong)fit_data;
> +data = (phys_addr_t)(uintptr_t)fit_data;

 This double cast looks strange to me.  Why is it needed?

> -void *from = (void *)data;
> +void *from = (void *)(uintptr_t)data;

 Ditto.

> -memmove((char *) dest, (char *)data, len);
> +memmove((char *)dest, (char *)(uintptr_t)data, len);

 Ditto. etc. etc.


 All these double casts look somewhat wrong to me.  Why are they
 needed?
>>>
>>> Dear Wolfgang,
>>>
>>> I can use some serious help here. What I am really trying to achieve is the 
>>> last
>>> two patches in this set. I didn't want to use replace ulong with 
>>> phys_addr_t. I
>>> am not proud with the change I proposed, but I didn't come up with a smarter
>>> solution. My specific trouble is to build ARMv8 targets on 32-bit Ubuntu 
>>> host.
>>> Some code is shared between the target and host tool (mkimage). I started 
>>> from
>>> small changes, but it gets wider and wider when I tried to get rid of the
>>> compiling warnings.
>>>
>>> York
>>>
>>
>> I suggest just documenting it better with comments and in the commit
>> message. It's mostly the same comment I made.
>>
>> One concern is that if you cast to uintptr_t on a 32-bit host machine,
>> won't you end up dropping the top 32 bits?
>>
>
> Simon,
>
> Some code is shared between targets and hosts, but 

Re: [U-Boot] [PATCH] arm: socfpga: Enabling U-Boot environment support in QSPI

[Marek Vasut]

On 02/26/2016 02:06 PM, Chin Liang See wrote:
> On Wed, 2016-02-24 at 18:44 +0100, Marek Vasut wrote:
>> On 02/24/2016 09:50 AM, Chin Liang See wrote:
>>> Enabling the support of storing U-Boot environment
>>> within serial NOR flash. By default, its still
>>> store into SDMMC
>>>
>>> Signed-off-by: Chin Liang See 
>>> Cc: Dinh Nguyen 
>>> Cc: Dinh Nguyen 
>>> Cc: Pavel Machek 
>>> Cc: Marek Vasut 
>>> Cc: Stefan Roese 
>>
>> I am fine with the patch, but why did I receive it thrice ? ;-)
>>
> 
> Sorry about this as I thought IT blocked the email sending. I noticed
> the U-Boot mailing didn't show the patch after 10 mins. I was surprised
> to see 3 and guess it took longer time to go through IT servers
> screening :)

Gotcha!

btw I started screening the patches a bit more. socfpga_sr1500 produces
a warning with this patch.

Please use buildman to build your patches, something like:

./tools/buildman/buildman -b u-boot/master..HEAD -defsS "socfpga"

will do the trick.

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

Re: [U-Boot] [RFC PATCH v5 1/4] common: Convert ulong to phys_addr_t for image addresses

[york sun]

On 02/26/2016 09:31 AM, Simon Glass wrote:
> Hi York,
> 
> On 26 February 2016 at 10:22, york sun  wrote:
>> On 02/25/2016 03:05 PM, Wolfgang Denk wrote:
>>> Dear York Sun,
>>>
>>> In message <1456439779-4792-2-git-send-email-york@nxp.com> you wrote:
 When dealing with image addresses, ulong has been used. Some files
 are used by both host and target. It is OK for the target, but not
 always enough for host tools including mkimage. This patch replaces
 "ulong" with "phys_addr_t" to make sure addresses are correct for
 both the target and the host.
>>>
>>> You talk here about using "phys_addr_t"...
>>>
 -   ulong, ulong, ulong))images->ep;
 +   ulong, ulong, ulong))(uintptr_t)images->ep;
>>>
>>> ...but here you use  uintptr_t  , hich is something different?
>>>
 -ulong, ulong, ulong))images->ep)(images->ft_addr,
 +ulong, ulong, ulong))(uintptr_t)images->ep)(images->ft_addr,
>>>
>>> Ditto.
>>>
 +phys_addr_t os_data;
 +ulong os_len;
  void *data = NULL;
  size_t len;
  int ret;
 @@ -87,11 +89,10 @@ static int boot_prep_linux(bootm_headers_t *images)
  if (images->legacy_hdr_valid) {
  hdr = images->legacy_hdr_os;
  if (image_check_type(hdr, IH_TYPE_MULTI)) {
 -ulong os_data, os_len;
>>>
>>> Why do you moe the declarations out of this block?  The variables are
>>> only used within this block so there is no need for a wider scope?
>>>
 -data = (void *)os_data;
 +data = (void *)(uintptr_t)os_data;
>>>
>>> This double cast looks scary to me, and you don;t explain it in the
>>> commit message.  Why exactly is this needed?
>>>
 -cmd_line_dest = (void *)images->ep + COMMAND_LINE_OFFSET;
 +cmd_line_dest = (void *)(uintptr_t)images->ep +
 +COMMAND_LINE_OFFSET;
>>>
>>> Ditto.
>>>
 -printf("Setup at %#08lx\n", images->ep);
 -ret = setup_zimage((void *)images->ep, cmd_line_dest,
 +printf("Setup at %#08" PRIpa "\n", images->ep);
>>>
>>> This is really ugly...
>>>
 +ret = setup_zimage((void *)(uintptr_t)images->ep, cmd_line_dest,
>>>
>>> See before.
>>>
 -debug("## Transferring control to Linux (at address %08lx, kernel 
 %08lx) ...\n",
 +debug("## Transferring control to Linux (at address %#08" PRIpa
 +  ", kernel %#08" PRIpa ") ...\n",
>>>
>>> See before...
>>>
 -debug("*  kernel: cmdline image address = 0x%08lx\n",
 -images->ep);
 +debug("*  kernel: cmdline image address = %#08" PRIpa "\n",
 +  images->ep);
>>>
>>> Ditto.  etc. etc.
>>>
 +/*
 + * In this function, data is decalred as phys_addr_t type.
>>>
>>> s/decalred/declared/
>>>
 + * On some systems (eg. ARM, PowerPC) phys_addr_t can be
 + * "unsigned long", or "unsigned long long", depending on
 + * CONFIG_PHYS_64BIT.  It is safe to cast 64-bit phys_addr_t
 + * to 32-bit pointer for image handling because the actual
 + * address the image is loaded is within 32-bit space.
>>>
>>> Who guarantees that?
>>>
 -data = (ulong)fit_data;
 +data = (phys_addr_t)(uintptr_t)fit_data;
>>>
>>> This double cast looks strange to me.  Why is it needed?
>>>
 -void *from = (void *)data;
 +void *from = (void *)(uintptr_t)data;
>>>
>>> Ditto.
>>>
 -memmove((char *) dest, (char *)data, len);
 +memmove((char *)dest, (char *)(uintptr_t)data, len);
>>>
>>> Ditto. etc. etc.
>>>
>>>
>>> All these double casts look somewhat wrong to me.  Why are they
>>> needed?
>>
>> Dear Wolfgang,
>>
>> I can use some serious help here. What I am really trying to achieve is the 
>> last
>> two patches in this set. I didn't want to use replace ulong with 
>> phys_addr_t. I
>> am not proud with the change I proposed, but I didn't come up with a smarter
>> solution. My specific trouble is to build ARMv8 targets on 32-bit Ubuntu 
>> host.
>> Some code is shared between the target and host tool (mkimage). I started 
>> from
>> small changes, but it gets wider and wider when I tried to get rid of the
>> compiling warnings.
>>
>> York
>>
> 
> I suggest just documenting it better with comments and in the commit
> message. It's mostly the same comment I made.
> 
> One concern is that if you cast to uintptr_t on a 32-bit host machine,
> won't you end up dropping the top 32 bits?
> 

Simon,

Some code is shared between targets and hosts, but not all. The ugly casting is
used by targets only. Maybe I should take another look at the issue and back
away from converting ulong to phys_addr_t totally. It is only broken on 32-bit
host tool and seems 

Re: [U-Boot] [PATCH 6/9] Hang when no command line processing can be performed

[Tom Rini]

On Fri, Feb 26, 2016 at 10:31:36AM -0700, Simon Glass wrote:
> Hi Tom,
> 
> On 26 February 2016 at 10:17, Tom Rini  wrote:
> > On Thu, Feb 25, 2016 at 09:00:53PM -0700, Simon Glass wrote:
> >
> >> Normally board_run_command() will handle command processed. But if for some
> >> reason it returns then we should hang to avoid further processing.
> >>
> >> Signed-off-by: Simon Glass 
> >
> > Reviewed-by: Tom Rini 
> >
> > ... but can we maybe try and force this to happen as an experiment and
> > see if panic here?
> 
> Yes this comes up with sandbox when the option is enabled.

Sorry, I mean that instead of hang() we call panic("..something") ?

-- 
Tom


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

Re: [U-Boot] [RFC PATCH v5 1/4] common: Convert ulong to phys_addr_t for image addresses

[Simon Glass]

Hi York,

On 26 February 2016 at 10:22, york sun  wrote:
> On 02/25/2016 03:05 PM, Wolfgang Denk wrote:
>> Dear York Sun,
>>
>> In message <1456439779-4792-2-git-send-email-york@nxp.com> you wrote:
>>> When dealing with image addresses, ulong has been used. Some files
>>> are used by both host and target. It is OK for the target, but not
>>> always enough for host tools including mkimage. This patch replaces
>>> "ulong" with "phys_addr_t" to make sure addresses are correct for
>>> both the target and the host.
>>
>> You talk here about using "phys_addr_t"...
>>
>>> -   ulong, ulong, ulong))images->ep;
>>> +   ulong, ulong, ulong))(uintptr_t)images->ep;
>>
>> ...but here you use  uintptr_t  , hich is something different?
>>
>>> -ulong, ulong, ulong))images->ep)(images->ft_addr,
>>> +ulong, ulong, ulong))(uintptr_t)images->ep)(images->ft_addr,
>>
>> Ditto.
>>
>>> +phys_addr_t os_data;
>>> +ulong os_len;
>>>  void *data = NULL;
>>>  size_t len;
>>>  int ret;
>>> @@ -87,11 +89,10 @@ static int boot_prep_linux(bootm_headers_t *images)
>>>  if (images->legacy_hdr_valid) {
>>>  hdr = images->legacy_hdr_os;
>>>  if (image_check_type(hdr, IH_TYPE_MULTI)) {
>>> -ulong os_data, os_len;
>>
>> Why do you moe the declarations out of this block?  The variables are
>> only used within this block so there is no need for a wider scope?
>>
>>> -data = (void *)os_data;
>>> +data = (void *)(uintptr_t)os_data;
>>
>> This double cast looks scary to me, and you don;t explain it in the
>> commit message.  Why exactly is this needed?
>>
>>> -cmd_line_dest = (void *)images->ep + COMMAND_LINE_OFFSET;
>>> +cmd_line_dest = (void *)(uintptr_t)images->ep +
>>> +COMMAND_LINE_OFFSET;
>>
>> Ditto.
>>
>>> -printf("Setup at %#08lx\n", images->ep);
>>> -ret = setup_zimage((void *)images->ep, cmd_line_dest,
>>> +printf("Setup at %#08" PRIpa "\n", images->ep);
>>
>> This is really ugly...
>>
>>> +ret = setup_zimage((void *)(uintptr_t)images->ep, cmd_line_dest,
>>
>> See before.
>>
>>> -debug("## Transferring control to Linux (at address %08lx, kernel 
>>> %08lx) ...\n",
>>> +debug("## Transferring control to Linux (at address %#08" PRIpa
>>> +  ", kernel %#08" PRIpa ") ...\n",
>>
>> See before...
>>
>>> -debug("*  kernel: cmdline image address = 0x%08lx\n",
>>> -images->ep);
>>> +debug("*  kernel: cmdline image address = %#08" PRIpa "\n",
>>> +  images->ep);
>>
>> Ditto.  etc. etc.
>>
>>> +/*
>>> + * In this function, data is decalred as phys_addr_t type.
>>
>> s/decalred/declared/
>>
>>> + * On some systems (eg. ARM, PowerPC) phys_addr_t can be
>>> + * "unsigned long", or "unsigned long long", depending on
>>> + * CONFIG_PHYS_64BIT.  It is safe to cast 64-bit phys_addr_t
>>> + * to 32-bit pointer for image handling because the actual
>>> + * address the image is loaded is within 32-bit space.
>>
>> Who guarantees that?
>>
>>> -data = (ulong)fit_data;
>>> +data = (phys_addr_t)(uintptr_t)fit_data;
>>
>> This double cast looks strange to me.  Why is it needed?
>>
>>> -void *from = (void *)data;
>>> +void *from = (void *)(uintptr_t)data;
>>
>> Ditto.
>>
>>> -memmove((char *) dest, (char *)data, len);
>>> +memmove((char *)dest, (char *)(uintptr_t)data, len);
>>
>> Ditto. etc. etc.
>>
>>
>> All these double casts look somewhat wrong to me.  Why are they
>> needed?
>
> Dear Wolfgang,
>
> I can use some serious help here. What I am really trying to achieve is the 
> last
> two patches in this set. I didn't want to use replace ulong with phys_addr_t. 
> I
> am not proud with the change I proposed, but I didn't come up with a smarter
> solution. My specific trouble is to build ARMv8 targets on 32-bit Ubuntu host.
> Some code is shared between the target and host tool (mkimage). I started from
> small changes, but it gets wider and wider when I tried to get rid of the
> compiling warnings.
>
> York
>

I suggest just documenting it better with comments and in the commit
message. It's mostly the same comment I made.

One concern is that if you cast to uintptr_t on a 32-bit host machine,
won't you end up dropping the top 32 bits?

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

Re: [U-Boot] [RFC PATCH v5 1/4] common: Convert ulong to phys_addr_t for image addresses

[york sun]

On 02/25/2016 03:05 PM, Wolfgang Denk wrote:
> Dear York Sun,
> 
> In message <1456439779-4792-2-git-send-email-york@nxp.com> you wrote:
>> When dealing with image addresses, ulong has been used. Some files
>> are used by both host and target. It is OK for the target, but not
>> always enough for host tools including mkimage. This patch replaces
>> "ulong" with "phys_addr_t" to make sure addresses are correct for
>> both the target and the host.
> 
> You talk here about using "phys_addr_t"...
> 
>> -   ulong, ulong, ulong))images->ep;
>> +   ulong, ulong, ulong))(uintptr_t)images->ep;
> 
> ...but here you use  uintptr_t  , hich is something different?
> 
>> -ulong, ulong, ulong))images->ep)(images->ft_addr,
>> +ulong, ulong, ulong))(uintptr_t)images->ep)(images->ft_addr,
> 
> Ditto.
> 
>> +phys_addr_t os_data;
>> +ulong os_len;
>>  void *data = NULL;
>>  size_t len;
>>  int ret;
>> @@ -87,11 +89,10 @@ static int boot_prep_linux(bootm_headers_t *images)
>>  if (images->legacy_hdr_valid) {
>>  hdr = images->legacy_hdr_os;
>>  if (image_check_type(hdr, IH_TYPE_MULTI)) {
>> -ulong os_data, os_len;
> 
> Why do you moe the declarations out of this block?  The variables are
> only used within this block so there is no need for a wider scope?
> 
>> -data = (void *)os_data;
>> +data = (void *)(uintptr_t)os_data;
> 
> This double cast looks scary to me, and you don;t explain it in the
> commit message.  Why exactly is this needed?
> 
>> -cmd_line_dest = (void *)images->ep + COMMAND_LINE_OFFSET;
>> +cmd_line_dest = (void *)(uintptr_t)images->ep +
>> +COMMAND_LINE_OFFSET;
> 
> Ditto.
> 
>> -printf("Setup at %#08lx\n", images->ep);
>> -ret = setup_zimage((void *)images->ep, cmd_line_dest,
>> +printf("Setup at %#08" PRIpa "\n", images->ep);
> 
> This is really ugly...
> 
>> +ret = setup_zimage((void *)(uintptr_t)images->ep, cmd_line_dest,
> 
> See before.
> 
>> -debug("## Transferring control to Linux (at address %08lx, kernel 
>> %08lx) ...\n",
>> +debug("## Transferring control to Linux (at address %#08" PRIpa
>> +  ", kernel %#08" PRIpa ") ...\n",
> 
> See before...
> 
>> -debug("*  kernel: cmdline image address = 0x%08lx\n",
>> -images->ep);
>> +debug("*  kernel: cmdline image address = %#08" PRIpa "\n",
>> +  images->ep);
> 
> Ditto.  etc. etc.
> 
>> +/*
>> + * In this function, data is decalred as phys_addr_t type.
> 
> s/decalred/declared/
> 
>> + * On some systems (eg. ARM, PowerPC) phys_addr_t can be
>> + * "unsigned long", or "unsigned long long", depending on
>> + * CONFIG_PHYS_64BIT.  It is safe to cast 64-bit phys_addr_t
>> + * to 32-bit pointer for image handling because the actual
>> + * address the image is loaded is within 32-bit space.
> 
> Who guarantees that?
> 
>> -data = (ulong)fit_data;
>> +data = (phys_addr_t)(uintptr_t)fit_data;
> 
> This double cast looks strange to me.  Why is it needed?
> 
>> -void *from = (void *)data;
>> +void *from = (void *)(uintptr_t)data;
> 
> Ditto.
> 
>> -memmove((char *) dest, (char *)data, len);
>> +memmove((char *)dest, (char *)(uintptr_t)data, len);
> 
> Ditto. etc. etc.
> 
> 
> All these double casts look somewhat wrong to me.  Why are they
> needed?

Dear Wolfgang,

I can use some serious help here. What I am really trying to achieve is the last
two patches in this set. I didn't want to use replace ulong with phys_addr_t. I
am not proud with the change I proposed, but I didn't come up with a smarter
solution. My specific trouble is to build ARMv8 targets on 32-bit Ubuntu host.
Some code is shared between the target and host tool (mkimage). I started from
small changes, but it gets wider and wider when I tried to get rid of the
compiling warnings.

York

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

Re: [U-Boot] [PATCH 8/9] Allow command-line files to be dropped

[Simon Glass]

Hi Tom,

On 26 February 2016 at 10:17, Tom Rini  wrote:
> On Thu, Feb 25, 2016 at 09:00:55PM -0700, Simon Glass wrote:
>
>> These files do not need to be compiled when CONFIG_CMDLINE is disabled.
>> Update the Makefile to reflect this.
>>
>> Signed-off-by: Simon Glass 
>
> Reviewed-by: Tom Rini 
>
> ... but did you buildman the world here?  iirc, we have some cases that
> fake running a command to make something important happen here.

Not on this commit, but for the series. I will though.

It is definitely possible that enabling the option will create build
errors. For one, you need a board_run_command() function to be
present. I've tested it for sandbox and am actually thinking of adding
a sandbox board without commands.

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

Re: [U-Boot] [PATCH 6/9] Hang when no command line processing can be performed

[Simon Glass]

Hi Tom,

On 26 February 2016 at 10:17, Tom Rini  wrote:
> On Thu, Feb 25, 2016 at 09:00:53PM -0700, Simon Glass wrote:
>
>> Normally board_run_command() will handle command processed. But if for some
>> reason it returns then we should hang to avoid further processing.
>>
>> Signed-off-by: Simon Glass 
>
> Reviewed-by: Tom Rini 
>
> ... but can we maybe try and force this to happen as an experiment and
> see if panic here?

Yes this comes up with sandbox when the option is enabled.

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

Re: [U-Boot] [PATCH 5/9] Drop command-processing code when CONFIG_CMDLINE is disabled

[Tom Rini]

On Thu, Feb 25, 2016 at 09:00:52PM -0700, Simon Glass wrote:

> Command parsing and processing code is not needed when the command line is
> disabled. Remove this code in that case.
> 
> Signed-off-by: Simon Glass 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH 8/9] Allow command-line files to be dropped

[Tom Rini]

On Thu, Feb 25, 2016 at 09:00:55PM -0700, Simon Glass wrote:

> These files do not need to be compiled when CONFIG_CMDLINE is disabled.
> Update the Makefile to reflect this.
> 
> Signed-off-by: Simon Glass 

Reviewed-by: Tom Rini 

... but did you buildman the world here?  iirc, we have some cases that
fake running a command to make something important happen here.

-- 
Tom


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

Re: [U-Boot] [PATCH 7/9] Allow command code to compile to nothing

[Tom Rini]

On Thu, Feb 25, 2016 at 09:00:54PM -0700, Simon Glass wrote:

> When CONFIG_CMDLINE is disabled we need to remove all the command-line
> code. Most can be removed by dropping the appropriate linker lists from the
> images, but sub-commands must be dealt with specially.
> 
> A simple mechanism is used to avoid 'unused static function' errors.
> 
> Signed-off-by: Simon Glass 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH 6/9] Hang when no command line processing can be performed

[Tom Rini]

On Thu, Feb 25, 2016 at 09:00:53PM -0700, Simon Glass wrote:

> Normally board_run_command() will handle command processed. But if for some
> reason it returns then we should hang to avoid further processing.
> 
> Signed-off-by: Simon Glass 

Reviewed-by: Tom Rini 

... but can we maybe try and force this to happen as an experiment and
see if panic here?

-- 
Tom


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

Re: [U-Boot] [PATCH 4/9] sandbox: Avoid calling commands when not available

[Tom Rini]

On Thu, Feb 25, 2016 at 09:00:51PM -0700, Simon Glass wrote:

> Don't try to run commands when not supported.
> 
> Signed-off-by: Simon Glass 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH 2/9] Add an option to enable the command line

[Tom Rini]

On Thu, Feb 25, 2016 at 09:00:49PM -0700, Simon Glass wrote:

> Add a new Kconfig option for the command line. This is enabled by default,
> but when disabled it will remove the command line.
> 
> Signed-off-by: Simon Glass 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH 1/9] cbfs: Update a function to be static

[Tom Rini]

On Thu, Feb 25, 2016 at 09:00:48PM -0700, Simon Glass wrote:

> All command functions should be static. Update the CBFS functions to follow
> this rule.
> 
> Signed-off-by: Simon Glass 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH 3/9] arm: x86: Drop command-line code when CONFIG_CMDLINE is disabled

[Tom Rini]

On Thu, Feb 25, 2016 at 09:00:50PM -0700, Simon Glass wrote:

> Update the link script to drop this code when not needed. This is only done
> for two architectures at present.
> 
> Signed-off-by: Simon Glass 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH v2 16/16] spi: Re-enable the SPI flash tests

[Simon Glass]

On 24 February 2016 at 09:14, Simon Glass  wrote:
> These are working correctly again, so re-enable them.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Jagan Teki 
> Tested-by: Jagan Teki 
> ---
>
> Changes in v2: None
>
>  test/dm/Makefile | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

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

Re: [U-Boot] [PATCH v2 15/16] spi: Correct two error return values

[Simon Glass]

On 24 February 2016 at 09:14, Simon Glass  wrote:
> When an error number is provided we should use it, not change it. This fixes
> the SPI and SPI flash tests.
>
> One of these is long-standing. The other seems to have been introduced by
> commit 1e90d9fd (sf: Move read_id code to sf_ops).
>
> Signed-off-by: Simon Glass 
> Fixes: 1e90d9fd (sf: Move read_id code to sf_ops)
> Reviewed-by: Jagan Teki 
> Tested-by: Jagan Teki 
> ---
>
> Changes in v2: None
>
>  drivers/mtd/spi/sf_probe.c  | 4 +---
>  drivers/mtd/spi/spi_flash.c | 2 +-
>  2 files changed, 2 insertions(+), 4 deletions(-)

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

Re: [U-Boot] [PATCH v2 14/16] sandbox: spi: Remove an incorrect free()

[Simon Glass]

On 24 February 2016 at 09:14, Simon Glass  wrote:
> We must not free data that is managed by driver mode. Remove this line,
> which is a hangover from the pre-driver-model code.
>
> This fixes a problem where 'sf probe' crashes U-Boot if the backing file
> for the SPI flash cannot be found.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Jagan Teki 
> Tested-by: Jagan Teki 
> Reviewed-by: Tom Rini 
> ---
>
> Changes in v2: None
>
>  drivers/mtd/spi/sandbox.c | 1 -
>  1 file changed, 1 deletion(-)

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

Re: [U-Boot] [PATCH v2 13/16] sandbox: spi: Add more debugging to SPI emulation

[Simon Glass]

On 24 February 2016 at 09:14, Simon Glass  wrote:
> Add a little more debugging to help when things go wrong.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Jagan Teki 
> Tested-by: Jagan Teki 
> ---
>
> Changes in v2: None
>
>  drivers/mtd/spi/sandbox.c | 13 ++---
>  1 file changed, 10 insertions(+), 3 deletions(-)

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

Re: [U-Boot] [PATCH v2 12/16] sandbox: Enable the early timer

[Simon Glass]

On 24 February 2016 at 09:14, Simon Glass  wrote:
> Enable this so that tracing works with sandbox.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v2: None
>
>  configs/sandbox_defconfig | 1 +
>  1 file changed, 1 insertion(+)

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

Re: [U-Boot] [PATCH v2 11/16] sandbox: Correct ordering of defconfig

[Simon Glass]

On 24 February 2016 at 09:14, Simon Glass  wrote:
> This has got out of order: fix it.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v2: None
>
>  configs/sandbox_defconfig | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)

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

Re: [U-Boot] [PATCH v2 09/16] timer: Set up the real timer after driver model is available

[Simon Glass]

On 24 February 2016 at 09:14, Simon Glass  wrote:
> When using the early timer, we need to manually trigger setting up the
> real timer. This will not happen automatically. Do this immediately after
> starting driver model.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v2: None
>
>  common/board_f.c |  6 ++
>  common/board_r.c | 14 --
>  2 files changed, 18 insertions(+), 2 deletions(-)

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

Re: [U-Boot] [PATCH v2 10/16] sandbox: timer: Support the early timer

[Simon Glass]

On 24 February 2016 at 09:14, Simon Glass  wrote:
> Add support for the early timer so we can use tracing with sandbox again.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v2:
> - Use SANDBOX_TIMER_RATE instead of an open-coded value
>
>  drivers/timer/sandbox_timer.c | 18 +++---
>  1 file changed, 15 insertions(+), 3 deletions(-)

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

Re: [U-Boot] [PATCH v2 08/16] timer: Provide an early timer

[Simon Glass]

On 24 February 2016 at 09:14, Simon Glass  wrote:
> In some cases the timer must be accessible before driver model is active.
> Examples include when using CONFIG_TRACE to trace U-Boot's execution before
> driver model is set up. Enable this option to use an early timer. These
> functions must be supported by your timer driver: timer_early_get_count()
> and timer_early_get_rate().
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v2:
> - Fix double space in comment
>
>  drivers/timer/Kconfig | 10 ++
>  include/timer.h   | 21 +
>  lib/time.c| 28 +---
>  3 files changed, 52 insertions(+), 7 deletions(-)

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

Re: [U-Boot] [PATCH v2 07/16] timer: Support tracing fully

[Simon Glass]

On 24 February 2016 at 09:14, Simon Glass  wrote:
> A few of the functions in the timer uclass are not marked with 'notrace'. Fix
> this so that tracing can be used with CONFIG_TRACE.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v2: None
>
>  drivers/timer/timer-uclass.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)

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

Re: [U-Boot] [PATCH v2 05/16] lib: Don't instrument the div64 function

[Simon Glass]

On 24 February 2016 at 09:14, Simon Glass  wrote:
> This function can be called from the timer code on instrumented functions.
> Mark it as 'notrace' so that it doesn't cause infinite recursion.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v2: None
>
>  lib/div64.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)

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

Re: [U-Boot] [PATCH v2 06/16] trace: Improve the trace test number recognition

[Simon Glass]

On 24 February 2016 at 09:14, Simon Glass  wrote:
> The awk tool can be confused by return character (ASCII 13) in its input
> since it thinks there is a separate field. These can appear if the terminal
> is in raw mode, perhaps due to a previous U-Boot crash with sandbox. This
> is very confusing. Remove these so that the trace test passes.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v2: None
>
>  test/trace/test-trace.sh | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)

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

Re: [U-Boot] [PATCH v2 04/16] trace: Fix compiler warnings in trace

[Simon Glass]

On 24 February 2016 at 09:14, Simon Glass  wrote:
> With min() we must use the same type for each parameter. Fix two problems
> in trace.c which produce compiler warnings.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v2: None
>
>  cmd/trace.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

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

Re: [U-Boot] [PATCH v2 01/16] image: Correct the OS location code to work on sandbox

[Simon Glass]

On 24 February 2016 at 09:14, Simon Glass  wrote:
> A recent change broke the 'bootm' command on sandbox. The root cause is
> using a pointer as an address. Conversion from pointer to address needs to
> use map_to_sysmem() so that sandbox can do the right thing. The problem was
> pre-existing but uncovered by a recent commit.
>
> Fix this. Also move fit_get_end() to the C file to avoid needing to include
> mapmem.h (and thus asm/io.h) everywhere.
>
> Fixes: 1fec3c5d (common/image.c: Make boot_get_ramdisk() perform a check for 
> Android images)
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v2: None
>
>  common/bootm.c | 2 +-
>  common/image-fit.c | 5 +
>  include/image.h| 5 +
>  3 files changed, 7 insertions(+), 5 deletions(-)

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

Re: [U-Boot] [PATCH] pci: Fix compiler warnings in dm_pciauto_setup_device()

[Simon Glass]

On 19 February 2016 at 13:55, Simon Glass  wrote:
> On 18 February 2016 at 00:14, Bin Meng  wrote:
>> Fix the following compiler warnings when DEBUG is on.
>>
>> warning: 'bar_res' may be used uninitialized in this function.
>> drivers/pci/pci_auto.c:101:21:
>>if (!enum_only && pciauto_region_allocate(bar_res, bar_size,
>> ^
>>
>> Signed-off-by: Bin Meng 
>> ---
>>
>>  drivers/pci/pci_auto.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> Reviewed-by: Simon Glass 

Applied to u-boot-dm, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 02/16] Revert "image-fit: Fix signature checking"

[Simon Glass]

On 24 February 2016 at 09:14, Simon Glass  wrote:
> This reverts commit 84ca65aa4bd0d03867e9e49805201d0564d3ffb0.
>
> On signature verification failures fit_image_verify() should NOT exit with
> error. Only keys marked 'required' can cause image verification failure.
> This logic is already there and works correctly.
>
> Add a comment to make this clear.
>
> Fixes: 84ca65aa (image-fit: Fix signature checking)
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v2: None
>
>  common/image-fit.c | 11 ---
>  1 file changed, 8 insertions(+), 3 deletions(-)

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

Re: [U-Boot] [PATCH v2 03/16] image: Fix FIT and vboot tests to exit sandbox correctly

[Simon Glass]

On 24 February 2016 at 09:14, Simon Glass  wrote:
> When used with a device tree, sandbox now requires a 'reset' controller. Add
> this to the device trees so that reset works and the tests can complete.
>
> Signed-off-by: Simon Glass 
> Fixes: 5010d98f (sandbox: Use the reset driver to handle reset)
> ---
>
> Changes in v2: None
>
>  test/image/test-fit.py| 4 
>  test/vboot/sandbox-u-boot.dts | 3 +++
>  2 files changed, 7 insertions(+)

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

Re: [U-Boot] [PATCH v2 2/2] board:freescale:usb: Add device-tree fixup support for xhci controller

[Sriram Dash]

Please find my reply inline

-Original Message-
From: Marek Vasut [mailto:ma...@denx.de] 
Sent: Thursday, February 25, 2016 11:31 PM
To: Sriram Dash ; u-boot@lists.denx.de
Cc: york sun ; Ramneek Mehresh ; 
Rajesh Bhagat 
Subject: Re: [PATCH v2 2/2] board:freescale:usb: Add device-tree fixup support 
for xhci controller

On 02/24/2016 05:44 AM, Sriram Dash wrote:
> Enables usb device-tree fixup code to incorporate xhci controller
> 
> Signed-off-by: Ramneek Mehresh 
> Signed-off-by: Sriram Dash 
> ---
>  board/freescale/common/Makefile |  4 +++-
>  board/freescale/common/usb.c| 11 +--
>  include/fdt_support.h   |  4 ++--
>  3 files changed, 14 insertions(+), 5 deletions(-)
> 
> diff --git a/board/freescale/common/Makefile 
> b/board/freescale/common/Makefile index 62de45c..8388f47 100644
> --- a/board/freescale/common/Makefile
> +++ b/board/freescale/common/Makefile
> @@ -13,7 +13,9 @@ MINIMAL=y
>  endif
>  endif
>  
> -obj-$(CONFIG_USB_EHCI_FSL) += usb.o
> +ifneq ($(filter y,$(CONFIG_USB_EHCI_FSL) $(CONFIG_USB_XHCI_FSL)),) 
> +obj-y += usb.o endif

Please just add:

obj-$(CONFIG_USB_XHCI_FSL) += usb.o

here. Kbuild takes care of duplicities.

[Sriram] 
Accepted, Will change in v3 of patch

>  ifdef MINIMAL
>  # necessary to create built-in.o
> diff --git a/board/freescale/common/usb.c 
> b/board/freescale/common/usb.c index 7a35e92..b06daa0 100644
> --- a/board/freescale/common/usb.c
> +++ b/board/freescale/common/usb.c
> @@ -23,6 +23,7 @@ static const char *fdt_usb_get_node_type(void *blob, 
> int start_offset,  {
>   const char *compat_dr = "fsl-usb2-dr";
>   const char *compat_mph = "fsl-usb2-mph";
> + const char *compat_snps = "snps,dwc3";

Will you add more random variables here once you add another DT compat string 
for another controller? You might want to learn about C arrays :)

[Sriram] Accepted, Will change in v3 of patch


>   const char *node_type = NULL;
>  
>   *node_offset = fdt_node_offset_by_compatible(blob, start_offset, @@ 
> -32,8 +33,14 @@ static const char *fdt_usb_get_node_type(void *blob, int 
> start_offset,
>start_offset,
>compat_dr);
>   if (*node_offset < 0) {
> - printf("ERROR: could not find compatible node: %s\n",
> -fdt_strerror(*node_offset));
> + *node_offset = fdt_node_offset_by_compatible
> +(blob, start_offset, compat_snps);
> + if (*node_offset < 0) {
> + printf("ERROR:could not find node:%s",
> +fdt_strerror(*node_offset));
> + } else {
> + node_type = compat_snps;
> + }
>   } else {
>   node_type = compat_dr;
>   }
> diff --git a/include/fdt_support.h b/include/fdt_support.h index 
> 296add0..d34e959 100644
> --- a/include/fdt_support.h
> +++ b/include/fdt_support.h
> @@ -113,11 +113,11 @@ void fdt_fixup_qe_firmware(void *fdt);
>   */
>  int fdt_fixup_display(void *blob, const char *path, const char 
> *display);
>  
> -#if defined(CONFIG_HAS_FSL_DR_USB) || defined(CONFIG_HAS_FSL_MPH_USB)
> +#if defined(CONFIG_USB_EHCI_FSL) || defined(CONFIG_USB_XHCI_FSL)

This change looks unrelated.

[Sriram] fdt_fixup_dr_usb is currently for fixing device tree for EHCI. We are 
planning to use this 
for XHCI also. 

>  void fdt_fixup_dr_usb(void *blob, bd_t *bd);  #else  static inline 
> void fdt_fixup_dr_usb(void *blob, bd_t *bd) {} -#endif /* 
> defined(CONFIG_HAS_FSL_DR_USB) || defined(CONFIG_HAS_FSL_MPH_USB) */
> +#endif /* defined(CONFIG_USB_EHCI_FSL) || 
> +defined(CONFIG_USB_XHCI_FSL) */
>  
>  #if defined(CONFIG_SYS_FSL_SEC_COMPAT)
>  void fdt_fixup_crypto_node(void *blob, int sec_rev);
> 

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

Re: [U-Boot] [PATCH v2 1/2] board:freescale:common: Move device-tree fixup framework to common file

[Sriram Dash]

Please find my reply inline

-Original Message-
From: Marek Vasut [mailto:ma...@denx.de] 
Sent: Thursday, February 25, 2016 11:28 PM
To: Sriram Dash ; u-boot@lists.denx.de
Cc: york sun ; Ramneek Mehresh ; 
Rajesh Bhagat 
Subject: Re: [PATCH v2 1/2] board:freescale:common: Move device-tree fixup 
framework to common file

On 02/24/2016 05:44 AM, Sriram Dash wrote:
> Move usb device-tree fixup framework from ehci-fsl.c to common place 
> so that it can be used by other drivers as well (xhci-fsl.c).
> Also, call fdt_usb_get_node_type() from fdt_fixup_usb_mode_phy_type() 
> to avoid code duplication.
> 
> Signed-off-by: Ramneek Mehresh 
> Signed-off-by: Sriram Dash 

Is this just moving the code ? If so, please resubmit and use git format-patch 
-M -C to generate the patches for the submission. It makes it much easier to 
detect moved files.

[Sriram] No, this patch is performing two actions: 

1. Move usb device-tree fixup framework from ehci-fsl.c to common place 
so that it can be used by other drivers as well (xhci-fsl.c).

2. Call fdt_usb_get_node_type() from fdt_fixup_usb_mode_phy_type() 
to avoid code duplication.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] arm: Add support for LEGO MINDSTORMS EV3

[David Lechner]

This is based on the davinci da850evm. It can boot from either the
on-board 16MB flash or from a microSD card. It also reads board
information from an I2C EEPROM.

The EV3 itself initally boots from write-protected EEPROM, so no
u-boot SPL is needed.

Signed-off-by: David Lechner 
---
 arch/arm/mach-davinci/Kconfig |   4 +
 arch/arm/mach-davinci/da850_pinmux.c  |  10 +
 arch/arm/mach-davinci/include/mach/hardware.h |   1 +
 board/lego/ev3/Kconfig|  12 ++
 board/lego/ev3/MAINTAINERS|   6 +
 board/lego/ev3/Makefile   |  10 +
 board/lego/ev3/README |  32 
 board/lego/ev3/legoev3.c  | 176 ++
 configs/legoev3_defconfig |  12 ++
 include/configs/legoev3.h | 255 ++
 10 files changed, 518 insertions(+)
 create mode 100644 board/lego/ev3/Kconfig
 create mode 100644 board/lego/ev3/MAINTAINERS
 create mode 100644 board/lego/ev3/Makefile
 create mode 100644 board/lego/ev3/README
 create mode 100644 board/lego/ev3/legoev3.c
 create mode 100644 configs/legoev3_defconfig
 create mode 100644 include/configs/legoev3.h

diff --git a/arch/arm/mach-davinci/Kconfig b/arch/arm/mach-davinci/Kconfig
index a8d3e2f..5d1c5c5 100644
--- a/arch/arm/mach-davinci/Kconfig
+++ b/arch/arm/mach-davinci/Kconfig
@@ -22,6 +22,9 @@ config TARGET_OMAPL138_LCDK
 config TARGET_CALIMAIN
bool "Calimain board"
 
+config TARGET_LEGOEV3
+   bool "LEGO MINDSTORMS EV3"
+
 endchoice
 
 config SYS_SOC
@@ -31,5 +34,6 @@ source "board/Barix/ipam390/Kconfig"
 source "board/davinci/da8xxevm/Kconfig"
 source "board/davinci/ea20/Kconfig"
 source "board/omicron/calimain/Kconfig"
+source "board/lego/ev3/Kconfig"
 
 endif
diff --git a/arch/arm/mach-davinci/da850_pinmux.c 
b/arch/arm/mach-davinci/da850_pinmux.c
index 6105f63..758109e 100644
--- a/arch/arm/mach-davinci/da850_pinmux.c
+++ b/arch/arm/mach-davinci/da850_pinmux.c
@@ -12,6 +12,16 @@
 #include 
 
 /* SPI pin muxer settings */
+const struct pinmux_config spi0_pins_base[] = {
+   { pinmux(3), 1, 0 }, /* SPI0_CLK */
+   { pinmux(3), 1, 2 }, /* SPI0_SOMI */
+   { pinmux(3), 1, 3 }, /* SPI0_SIMO */
+};
+
+const struct pinmux_config spi0_pins_scs0[] = {
+   { pinmux(4), 1, 1 }, /* SPI0_SCS[0] */
+};
+
 const struct pinmux_config spi1_pins_base[] = {
{ pinmux(5), 1, 2 }, /* SPI1_CLK */
{ pinmux(5), 1, 4 }, /* SPI1_SOMI */
diff --git a/arch/arm/mach-davinci/include/mach/hardware.h 
b/arch/arm/mach-davinci/include/mach/hardware.h
index a4eb0bd..2a0360a 100644
--- a/arch/arm/mach-davinci/include/mach/hardware.h
+++ b/arch/arm/mach-davinci/include/mach/hardware.h
@@ -503,6 +503,7 @@ struct davinci_syscfg_regs {
 #define DAVINCI_SYSCFG_SUSPSRC_SPI0(1 << 21)
 #define DAVINCI_SYSCFG_SUSPSRC_SPI1(1 << 22)
 #define DAVINCI_SYSCFG_SUSPSRC_UART0   (1 << 18)
+#define DAVINCI_SYSCFG_SUSPSRC_UART1   (1 << 19)
 #define DAVINCI_SYSCFG_SUSPSRC_UART2   (1 << 20)
 #define DAVINCI_SYSCFG_SUSPSRC_TIMER0  (1 << 27)
 
diff --git a/board/lego/ev3/Kconfig b/board/lego/ev3/Kconfig
new file mode 100644
index 000..14b3f0c
--- /dev/null
+++ b/board/lego/ev3/Kconfig
@@ -0,0 +1,12 @@
+if TARGET_LEGOEV3
+
+config SYS_BOARD
+   default "ev3"
+
+config SYS_VENDOR
+   default "lego"
+
+config SYS_CONFIG_NAME
+   default "legoev3"
+
+endif
diff --git a/board/lego/ev3/MAINTAINERS b/board/lego/ev3/MAINTAINERS
new file mode 100644
index 000..11b3261
--- /dev/null
+++ b/board/lego/ev3/MAINTAINERS
@@ -0,0 +1,6 @@
+LEGOEV3 BOARD
+M: David Lechner 
+S: Maintained
+F: board/lego/ev3/
+F: include/configs/legoev3.h
+F: configs/legoev3_defconfig
diff --git a/board/lego/ev3/Makefile b/board/lego/ev3/Makefile
new file mode 100644
index 000..f3e717a
--- /dev/null
+++ b/board/lego/ev3/Makefile
@@ -0,0 +1,10 @@
+#
+# (C) Copyright 2000, 2001, 2002
+# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+#
+# Copyright (C) 2007 Sergey Kubushyn 
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+obj-y  += legoev3.o
diff --git a/board/lego/ev3/README b/board/lego/ev3/README
new file mode 100644
index 000..1a50ca9
--- /dev/null
+++ b/board/lego/ev3/README
@@ -0,0 +1,32 @@
+Summary
+===
+
+LEGO MINDSTORMS EV3 is a toy robot produced by the LEGO Group. It is based
+on the davinci da850 evm. The EV3 has a 16MB spi flash and a SDHC microSD card
+reader.
+
+Booting
+===
+
+The EV3 contains a bootloader in EEPROM that loads u-boot.bin from address 0x0
+of the spi flash memory. Using the default configuration, u-boot will check to
+see if there is a boot.scr file on the first FAT partition of the mmc. If there
+is, it will run the script and boot the kernel from the uImage file also in
+the FAT partition. Otherwise, it will load a kernel and rootfs 

Re: [U-Boot] [PATCH 3/5] usb: ehci: Implement V2P mapping

[Marek Vasut]

On 02/26/2016 05:48 PM, Stephen Warren wrote:
> On 01/26/2016 07:14 PM, Marek Vasut wrote:
>> Certain processor architectures, like MIPS, require that the USB
>> structures and transfer buffers are passed with their PA to the
>> USB controller. If VA is passed, the USB will not work. Add the
>> necessary virt_to_phys() calls into the USB EHCI code to make it
>> work.
> 
> FYI, this causes some cast size warnings, e.g.:
> 
>> +make
>> O=/home/swarren/shared/git_wa/tegra-uboot-flasher/u-boot/build-p2371-2180
>> -s p2371-2180_defconfig
>> +make
>> O=/home/swarren/shared/git_wa/tegra-uboot-flasher/u-boot/build-p2371-2180
>> -s -j8
>> In file included from ../arch/arm/include/asm/byteorder.h:29:0,
>>  from ../include/compiler.h:125,
>>  from ../include/image.h:19,
>>  from ../include/common.h:88,
>>  from ../drivers/usb/host/ehci-hcd.c:10:
>> ../drivers/usb/host/ehci-hcd.c: In function ‘ehci_td_buffer’:
>> ../drivers/usb/host/ehci-hcd.c:248:49: warning: cast to pointer from
>> integer of different size [-Wint-to-pointer-cast]
>>td->qt_buffer[idx] = cpu_to_hc32(virt_to_phys((void *)addr));
>>  ^
>> ../include/linux/byteorder/little_endian.h:34:51: note: in definition
>> of macro ‘__cpu_to_le32’
>>  #define __cpu_to_le32(x) ((__force __le32)(__u32)(x))
>>^
>> ../drivers/usb/host/ehci-hcd.c:248:24: note: in expansion of macro
>> ‘cpu_to_hc32’
>>td->qt_buffer[idx] = cpu_to_hc32(virt_to_phys((void *)addr));
>> ^
> 
> (This is a 64-bit ARM platform, so I had CROSS_COMPILE=aarch64-linux-gnu-)

Tom reported this to me too, sorry :-(

Do you have an idea how to fix this too? I am now installing arm64
toolchain.

Do you know about some nice arm64 board with USB for testing?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 4/7 v3] pci/layerscape: add support for LUT

[Stuart Yoder]

From: Stuart Yoder 

The per-PCI controller LUT (Look-Up-Table) is a 32-entry table
that maps PCI requester IDs (bus/dev/fun) to a stream ID.

This patch implements infrastructure to enable LUT initialization:
  -define registers offsets
  -add an index to 'struct ls_pcie' to track next available slot in LUT
  -add function to allocate the next available entry index
  -add function to program a LUT entry

Signed-off-by: Stuart Yoder 
---
-v3
   -moved LUT #defines to immap_lsch3.h, made index
allocator return an int

 .../include/asm/arch-fsl-layerscape/immap_lsch3.h  |4 +++
 drivers/pci/pcie_layerscape.c  |   29 
 2 files changed, 33 insertions(+)

diff --git a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h 
b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
index 91f3ce8..d04e336 100644
--- a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
+++ b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
@@ -86,6 +86,10 @@
 #define PCIE_LUT_BASE  0x8
 #define PCIE_LUT_LCTRL00x7F8
 #define PCIE_LUT_DBG   0x7FC
+#define PCIE_LUT_UDR(n) (0x800 + (n) * 8)
+#define PCIE_LUT_LDR(n) (0x804 + (n) * 8)
+#define PCIE_LUT_ENABLE (1 << 31)
+#define PCIE_LUT_ENTRY_COUNT32
 
 /* Device Configuration */
 #define DCFG_BASE  0x01e0
diff --git a/drivers/pci/pcie_layerscape.c b/drivers/pci/pcie_layerscape.c
index bb29222..8b1e6fb 100644
--- a/drivers/pci/pcie_layerscape.c
+++ b/drivers/pci/pcie_layerscape.c
@@ -93,6 +93,7 @@ struct ls_pcie {
void __iomem *dbi;
void __iomem *va_cfg0;
void __iomem *va_cfg1;
+   int next_lut_index;
struct pci_controller hose;
 };
 
@@ -482,6 +483,33 @@ static void ls_pcie_setup_ep(struct ls_pcie *pcie, struct 
ls_pcie_info *info)
}
 }
 
+
+/*
+ * Return next available LUT index.
+ */
+static int ls_pcie_next_lut_index(struct ls_pcie *pcie)
+{
+   if (pcie->next_lut_index < PCIE_LUT_ENTRY_COUNT)
+   return pcie->next_lut_index++;
+   else
+   return -1;  /* LUT is full */
+}
+
+/*
+ * Program a single LUT entry
+ */
+static void ls_pcie_lut_set_mapping(struct ls_pcie *pcie, int index, u32 devid,
+u32 streamid)
+{
+   void __iomem *lut;
+
+   lut = pcie->dbi + PCIE_LUT_BASE;
+
+   /* leave mask as all zeroes, want to match all bits */
+   writel((devid << 16), lut + PCIE_LUT_UDR(index));
+   writel(streamid | PCIE_LUT_ENABLE, lut + PCIE_LUT_LDR(index));
+}
+
 int ls_pcie_init_ctrl(int busno, enum srds_prtcl dev, struct ls_pcie_info 
*info)
 {
struct ls_pcie *pcie;
@@ -513,6 +541,7 @@ int ls_pcie_init_ctrl(int busno, enum srds_prtcl dev, 
struct ls_pcie_info *info)
pcie->va_cfg1 = map_physmem(info->cfg1_phys,
info->cfg1_size,
MAP_NOCACHE);
+   pcie->next_lut_index = 0;
 
/* outbound memory */
pci_set_region(>regions[0],
-- 
1.7.9.5

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

[U-Boot] [PATCH 6/7 v3] pci/layerscape: fdt: function to set msi-map entries

[Stuart Yoder]

From: Stuart Yoder 

msi-map properties are used to tell an OS how PCI requester
IDs are mapped to ARM SMMU stream IDs.  This patch defines a
function to append a single msi-map entry to a given PCI controller
device tree node.

Signed-off-by: Stuart Yoder 
---
-v3
   -no changes

 drivers/pci/pcie_layerscape.c |   43 -
 1 file changed, 42 insertions(+), 1 deletion(-)

diff --git a/drivers/pci/pcie_layerscape.c b/drivers/pci/pcie_layerscape.c
index 230aec4..f6ed900 100644
--- a/drivers/pci/pcie_layerscape.c
+++ b/drivers/pci/pcie_layerscape.c
@@ -483,7 +483,6 @@ static void ls_pcie_setup_ep(struct ls_pcie *pcie, struct 
ls_pcie_info *info)
}
 }
 
-
 /*
  * Return next available LUT index.
  */
@@ -521,6 +520,48 @@ static u32 ls_pcie_next_streamid(void)
return next_stream_id++;
 }
 
+/*
+ * An msi-map is a property to be added to the pci controller
+ * node.  It is a table, where each entry consists of 4 fields
+ * e.g.:
+ *
+ *  msi-map = <[devid] [phandle-to-msi-ctrl] [stream-id] [count]
+ * [devid] [phandle-to-msi-ctrl] [stream-id] [count]>;
+ */
+static void fdt_pcie_set_msi_map_entry(void *blob, struct ls_pcie *pcie,
+  u32 devid, u32 streamid)
+{
+   char pcie_path[19];
+   u32 *prop;
+   u32 phandle;
+   int nodeoffset;
+
+   /* find pci controller node */
+   snprintf(pcie_path, sizeof(pcie_path), "/soc/pcie@%llx",
+(u64)pcie->dbi);
+   nodeoffset = fdt_path_offset(blob, pcie_path);
+   if (nodeoffset < 0) {
+   printf("\n%s: ERROR: unable to update PCIe node: %s\n",
+  __func__, pcie_path);
+   return;
+   }
+
+   /* get phandle to MSI controller */
+   prop = (u32 *)fdt_getprop(blob, nodeoffset, "msi-parent", 0);
+   if (prop == NULL) {
+   printf("\n%s: ERROR: missing msi-parent: %s\n", __func__,
+  pcie_path);
+   return;
+   }
+   phandle = be32_to_cpu(*prop);
+
+   /* set one msi-map row */
+   fdt_appendprop_u32(blob, nodeoffset, "msi-map", devid);
+   fdt_appendprop_u32(blob, nodeoffset, "msi-map", phandle);
+   fdt_appendprop_u32(blob, nodeoffset, "msi-map", streamid);
+   fdt_appendprop_u32(blob, nodeoffset, "msi-map", 1);
+}
+
 int ls_pcie_init_ctrl(int busno, enum srds_prtcl dev, struct ls_pcie_info 
*info)
 {
struct ls_pcie *pcie;
-- 
1.7.9.5

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

[U-Boot] [PATCH 1/7 v3] armv8: ls2080a: remove obsolete stream ID partitioning support

[Stuart Yoder]

From: Stuart Yoder 

Remove stream ID partitioning support that has been made
obsolete by upstream device tree bindings that specify how
representing how PCI requester IDs are mapped to MSI specifiers
and SMMU stream IDs.

Signed-off-by: Stuart Yoder 
---
-v3
  -no changes

 arch/arm/cpu/armv8/fsl-layerscape/fdt.c |  113 ---
 drivers/pci/pcie_layerscape.c   |   70 ---
 2 files changed, 183 deletions(-)

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c 
b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
index 4e4861d..7a64f41 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
@@ -70,115 +70,6 @@ void ft_fixup_cpu(void *blob)
 }
 #endif
 
-/*
- * the burden is on the the caller to not request a count
- * exceeding the bounds of the stream_ids[] array
- */
-void alloc_stream_ids(int start_id, int count, u32 *stream_ids, int max_cnt)
-{
-   int i;
-
-   if (count > max_cnt) {
-   printf("\n%s: ERROR: max per-device stream ID count exceed\n",
-  __func__);
-   return;
-   }
-
-   for (i = 0; i < count; i++)
-   stream_ids[i] = start_id++;
-}
-
-/*
- * This function updates the mmu-masters property on the SMMU
- * node as per the SMMU binding-- phandle and list of stream IDs
- * for each MMU master.
- */
-void append_mmu_masters(void *blob, const char *smmu_path,
-   const char *master_name, u32 *stream_ids, int count)
-{
-   u32 phandle;
-   int smmu_nodeoffset;
-   int master_nodeoffset;
-   int i;
-
-   /* get phandle of mmu master device */
-   master_nodeoffset = fdt_path_offset(blob, master_name);
-   if (master_nodeoffset < 0) {
-   printf("\n%s: ERROR: master not found\n", __func__);
-   return;
-   }
-   phandle = fdt_get_phandle(blob, master_nodeoffset);
-   if (!phandle) { /* if master has no phandle, create one */
-   phandle = fdt_create_phandle(blob, master_nodeoffset);
-   if (!phandle) {
-   printf("\n%s: ERROR: unable to create phandle\n",
-  __func__);
-   return;
-   }
-   }
-
-   /* append it to mmu-masters */
-   smmu_nodeoffset = fdt_path_offset(blob, smmu_path);
-   if (fdt_appendprop_u32(blob, smmu_nodeoffset, "mmu-masters",
-  phandle) < 0) {
-   printf("\n%s: ERROR: unable to update SMMU node\n", __func__);
-   return;
-   }
-
-   /* for each stream ID, append to mmu-masters */
-   for (i = 0; i < count; i++) {
-   fdt_appendprop_u32(blob, smmu_nodeoffset, "mmu-masters",
-  stream_ids[i]);
-   }
-
-   /* fix up #stream-id-cells with stream ID count */
-   if (fdt_setprop_u32(blob, master_nodeoffset, "#stream-id-cells",
-   count) < 0)
-   printf("\n%s: ERROR: unable to update #stream-id-cells\n",
-  __func__);
-}
-
-
-/*
- * The info below summarizes how streamID partitioning works
- * for ls2080a and how it is conveyed to the OS via the device tree.
- *
- *  -non-PCI legacy, platform devices (USB, SD/MMC, SATA, DMA)
- * -all legacy devices get a unique ICID assigned and programmed in
- *  their AMQR registers by u-boot
- * -u-boot updates the hardware device tree with streamID properties
- *  for each platform/legacy device (smmu-masters property)
- *
- *  -PCIe
- * -for each PCI controller that is active (as per RCW settings),
- *  u-boot will allocate a range of ICID and convey that to Linux via
- *  the device tree (smmu-masters property)
- *
- *  -DPAA2
- * -u-boot will allocate a range of ICIDs to be used by the Management
- *  Complex for containers and will set these values in the MC DPC image.
- * -the MC is responsible for allocating and setting up ICIDs
- *  for all DPAA2 devices.
- *
- */
-#ifdef CONFIG_FSL_LSCH3
-static void fdt_fixup_smmu(void *blob)
-{
-   int nodeoffset;
-
-   nodeoffset = fdt_path_offset(blob, "/iommu@500");
-   if (nodeoffset < 0) {
-   printf("\n%s: WARNING: no SMMU node found\n", __func__);
-   return;
-   }
-
-   /* fixup for all PCI controllers */
-#ifdef CONFIG_PCI
-   fdt_fixup_smmu_pcie(blob);
-#endif
-}
-#endif
-
 void ft_cpu_setup(void *blob, bd_t *bd)
 {
 #ifdef CONFIG_MP
@@ -200,8 +91,4 @@ void ft_cpu_setup(void *blob, bd_t *bd)
 #ifdef CONFIG_FSL_ESDHC
fdt_fixup_esdhc(blob, bd);
 #endif
-
-#ifdef CONFIG_FSL_LSCH3
-   fdt_fixup_smmu(blob);
-#endif
 }
diff --git a/drivers/pci/pcie_layerscape.c b/drivers/pci/pcie_layerscape.c
index 99f9c83..bb29222 100644
--- a/drivers/pci/pcie_layerscape.c
+++ b/drivers/pci/pcie_layerscape.c
@@ -664,73 +664,3 @@ void 

[U-Boot] [PATCH 0/7 v3] support mapping PCI device ids to stream ids for MSIs

[Stuart Yoder]

From: Stuart Yoder 

A binding for PCI nodes has been finalized specifying how PCI
device IDs can be mapped to MSI specifiers.  See
Documentation/devicetree/bindings/pci/pci-msi.txt in the kernel.

For ls2080a and similar Layerscape SoCs, the MSI specifier is the stream
id.  A programmable table (LUT) in the PCI controller defines the hardware
mapping of PCI requester IDs to stream IDs.

This patch series implements support for this mapping.

Patch 1 removes the obsolete available-stream-id support.
Patch 2 updates stream ID partitioning info to be current
Patch 3 updates pci.h so pci_get_hose_head() is available
Patch 4 implements support for programming the LUT
Patch 5 implements a simple stream ID allocator for PCI
Patch 6 implements a function to set msi-map properties
Patch 7 implements a function to iterate over all PCI buses
and set up a LUT entry and msi-map for all discovered
devices

This patch series enables MSIs on ls2080a on v4.5-rc5 and later
kernels.  The obsolete support removed was unused in any
upstream kernels.

-v2 changes
   -in patch 7 removed skip of the host bridge when scanning the
bus
-v3 changes
   -patch 4: moved LUT #defines to immap_lsch3.h, made index
 allocator return an int
   -patch 5: return 0x on error
   -patch 7: fixed return value checks

Stuart Yoder (7):
  armv8: ls2080a: remove obsolete stream ID partitioning support
  armv8: ls2080a: update stream ID partitioning info
  pci: make pci_get_hose_head() available to external users
  pci/layerscape: add support for LUT
  pci/layerscape: add stream ID allocator
  pci/layerscape: fdt: function to set msi-map entries
  pci/layerscape: set LUT and msi-map for discovered PCI devices

 arch/arm/cpu/armv8/fsl-layerscape/fdt.c|  113 --
 .../include/asm/arch-fsl-layerscape/immap_lsch3.h  |4 +
 .../asm/arch-fsl-layerscape/ls2080a_stream_id.h|   55 +++--
 drivers/pci/pcie_layerscape.c  |  215 +---
 include/pci.h  |1 +
 5 files changed, 184 insertions(+), 204 deletions(-)

-- 
1.7.9.5

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

[U-Boot] [PATCH 7/7 v3] pci/layerscape: set LUT and msi-map for discovered PCI devices

[Stuart Yoder]

From: Stuart Yoder 

for all PCI devices discovered in a system:
  -allocate a LUT (look-up-table) entry in that PCI controller
  -allocate a stream ID for the device
  -program and enable a LUT entry (maps PCI requester id to stream ID)
  -set the msi-map property on the controller reflecting the
   LUT mapping

basic bus scanning loop/logic was taken from drivers/pci/pci.c
pci_hose_scan_bus().

Signed-off-by: Stuart Yoder 
---
-v3
   -fixed return value check-- look for u32 value not int

 drivers/pci/pcie_layerscape.c |   64 +
 1 file changed, 64 insertions(+)

diff --git a/drivers/pci/pcie_layerscape.c b/drivers/pci/pcie_layerscape.c
index f6ed900..200f0f0 100644
--- a/drivers/pci/pcie_layerscape.c
+++ b/drivers/pci/pcie_layerscape.c
@@ -562,6 +562,66 @@ static void fdt_pcie_set_msi_map_entry(void *blob, struct 
ls_pcie *pcie,
fdt_appendprop_u32(blob, nodeoffset, "msi-map", 1);
 }
 
+static void fdt_fixup_pcie(void *blob)
+{
+   unsigned int found_multi = 0;
+   unsigned char header_type;
+   int index;
+   u32 streamid;
+   pci_dev_t dev;
+   int bus;
+   unsigned short id;
+   struct pci_controller *hose;
+   struct ls_pcie *pcie;
+   int i;
+
+   for (i = 0, hose = pci_get_hose_head(); hose; hose = hose->next, i++) {
+   pcie = hose->priv_data;
+   for (bus = hose->first_busno; bus <= hose->last_busno; bus++) {
+
+   for (dev =  PCI_BDF(bus, 0, 0);
+dev <  PCI_BDF(bus, PCI_MAX_PCI_DEVICES - 1,
+   PCI_MAX_PCI_FUNCTIONS - 1);
+dev += PCI_BDF(0, 0, 1)) {
+
+   if (PCI_FUNC(dev) && !found_multi)
+   continue;
+
+   pci_read_config_word(dev, PCI_VENDOR_ID, );
+
+   pci_read_config_byte(dev, PCI_HEADER_TYPE,
+_type);
+
+   if ((id == 0x) || (id == 0x))
+   continue;
+
+   if (!PCI_FUNC(dev))
+   found_multi = header_type & 0x80;
+
+   streamid = ls_pcie_next_streamid();
+   if (streamid == 0x) {
+   printf("ERROR: no stream ids free\n");
+   continue;
+   }
+
+   index = ls_pcie_next_lut_index(pcie);
+   if (index < 0) {
+   printf("ERROR: no LUT indexes free\n");
+   continue;
+   }
+
+   /* map PCI b.d.f to streamID in LUT */
+   ls_pcie_lut_set_mapping(pcie, index, dev >> 8,
+   streamid);
+
+   /* update msi-map in device tree */
+   fdt_pcie_set_msi_map_entry(blob, pcie, dev >> 8,
+  streamid);
+   }
+   }
+   }
+}
+
 int ls_pcie_init_ctrl(int busno, enum srds_prtcl dev, struct ls_pcie_info 
*info)
 {
struct ls_pcie *pcie;
@@ -738,6 +798,10 @@ void ft_pci_setup(void *blob, bd_t *bd)
#ifdef CONFIG_PCIE4
ft_pcie_ls_setup(blob, FSL_PCIE_COMPAT, CONFIG_SYS_PCIE4_ADDR, PCIE4);
#endif
+
+   #if defined(CONFIG_LS2080A) || defined(CONFIG_LS2085A)
+   fdt_fixup_pcie(blob);
+   #endif
 }
 
 #else
-- 
1.7.9.5

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

[U-Boot] [PATCH 3/7 v3] pci: make pci_get_hose_head() available to external users

[Stuart Yoder]

From: Stuart Yoder 

put pci_get_hose_head() prototype in header so it is available to
external users-- allowing them to find and iterate over all pci controllers

Signed-off-by: Stuart Yoder 
---
-v3
  -no changes

 include/pci.h |1 +
 1 file changed, 1 insertion(+)

diff --git a/include/pci.h b/include/pci.h
index 68548b0..8698056 100644
--- a/include/pci.h
+++ b/include/pci.h
@@ -700,6 +700,7 @@ extern void *pci_map_bar(pci_dev_t pdev, int bar, int 
flags);
 extern void pci_register_hose(struct pci_controller* hose);
 extern struct pci_controller* pci_bus_to_hose(int bus);
 extern struct pci_controller *find_hose_by_cfg_addr(void *cfg_addr);
+extern struct pci_controller *pci_get_hose_head(void);
 
 extern int pci_skip_dev(struct pci_controller *hose, pci_dev_t dev);
 extern int pci_hose_scan(struct pci_controller *hose);
-- 
1.7.9.5

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

Re: [U-Boot] [PATCH 3/5] usb: ehci: Implement V2P mapping

[Stephen Warren]

On 01/26/2016 07:14 PM, Marek Vasut wrote:

Certain processor architectures, like MIPS, require that the USB
structures and transfer buffers are passed with their PA to the
USB controller. If VA is passed, the USB will not work. Add the
necessary virt_to_phys() calls into the USB EHCI code to make it
work.


FYI, this causes some cast size warnings, e.g.:


+make O=/home/swarren/shared/git_wa/tegra-uboot-flasher/u-boot/build-p2371-2180 
-s p2371-2180_defconfig
+make O=/home/swarren/shared/git_wa/tegra-uboot-flasher/u-boot/build-p2371-2180 
-s -j8
In file included from ../arch/arm/include/asm/byteorder.h:29:0,
 from ../include/compiler.h:125,
 from ../include/image.h:19,
 from ../include/common.h:88,
 from ../drivers/usb/host/ehci-hcd.c:10:
../drivers/usb/host/ehci-hcd.c: In function ‘ehci_td_buffer’:
../drivers/usb/host/ehci-hcd.c:248:49: warning: cast to pointer from integer of 
different size [-Wint-to-pointer-cast]
   td->qt_buffer[idx] = cpu_to_hc32(virt_to_phys((void *)addr));
 ^
../include/linux/byteorder/little_endian.h:34:51: note: in definition of macro 
‘__cpu_to_le32’
 #define __cpu_to_le32(x) ((__force __le32)(__u32)(x))
   ^
../drivers/usb/host/ehci-hcd.c:248:24: note: in expansion of macro ‘cpu_to_hc32’
   td->qt_buffer[idx] = cpu_to_hc32(virt_to_phys((void *)addr));
^


(This is a 64-bit ARM platform, so I had CROSS_COMPILE=aarch64-linux-gnu-)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 1/2] board:freescale:common: Move device-tree fixup framework to common file

[Marek Vasut]

On 02/26/2016 05:07 PM, Sriram Dash wrote:
> Please find my reply inline

Please stop top-posting.

Also please fix your mailer so it quotes correctly with '>'

> -Original Message- From: Marek Vasut [mailto:ma...@denx.de] 
> Sent: Thursday, February 25, 2016 11:28 PM To: Sriram Dash
> ; u-boot@lists.denx.de Cc: york sun
> ; Ramneek Mehresh ; Rajesh
> Bhagat  Subject: Re: [PATCH v2 1/2]
> board:freescale:common: Move device-tree fixup framework to common
> file
> 
> On 02/24/2016 05:44 AM, Sriram Dash wrote:
>> Move usb device-tree fixup framework from ehci-fsl.c to common
>> place so that it can be used by other drivers as well
>> (xhci-fsl.c). Also, call fdt_usb_get_node_type() from
>> fdt_fixup_usb_mode_phy_type() to avoid code duplication.
>> 
>> Signed-off-by: Ramneek Mehresh  
>> Signed-off-by: Sriram Dash 
> 
> Is this just moving the code ? If so, please resubmit and use git
> format-patch -M -C to generate the patches for the submission. It
> makes it much easier to detect moved files.
> 
> [Sriram] No, this patch is performing two actions:
> 
> 1. Move usb device-tree fixup framework from ehci-fsl.c to common
> place so that it can be used by other drivers as well (xhci-fsl.c).
> 
> 2. Call fdt_usb_get_node_type() from fdt_fixup_usb_mode_phy_type() to
> avoid code duplication.

Then it should be two patches.


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