Re: [U-Boot] [PATCH v2 1/2] core: add uclass_get_device_by_phandle_id() api

[Kever Yang]

Hi Simon,


On 02/12/2018 10:35 PM, Simon Glass wrote:
> Hi Kever,
>
> On 8 February 2018 at 19:56, Kever Yang  wrote:
>> Add api for who can not get phandle from a device property.
> Can you please add a motivation to the commit message? It is not
> obvious to me when this function would be used.
Here is the example why I need this, see the dts node here:
lvds@ff2e {
...
rockchip,grf = <>;
port {
port@0 {
endpoint@0 {
remote-endpoint = <_out_lvds>;
}
}
}
}

We can only get 'grf' udevice by uclass_get_device_by_phandle(),
but we not able to get udevice 'vopl_out_lvds', other driver like
rockchip pinctrl
also need to get udevice by a phandle which is not one of direct property of
another device node.

Thanks,
- Kever
>> Signed-off-by: Kever Yang 
>> ---
>>
>> Changes in v2:
>> - use uint instead of int for phandle
>> - address comment from Philipp
>>
>>  drivers/core/uclass.c | 26 ++
>>  include/dm/uclass.h   | 16 
>>  2 files changed, 42 insertions(+)
>>
> Regards,
> Simon
>


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

Re: [U-Boot] [PATCH 1/2] mtd: nand: tegra: convert to driver model and live tree

[Masahiro Yamada]

2018-02-24 1:40 GMT+09:00 Stefan Agner :
> On 21.02.2018 16:16, Marcel Ziswiler wrote:
>> From: Marcel Ziswiler 
>>
>> The Tegra NAND driver recently got broken by ongoing driver model resp.
>> live tree migration work:
>>
>> NAND:  Could not decode nand-flash in device tree
>> Tegra NAND init failed
>> 0 MiB
>>
>> A patch for NAND uclass support was proposed about a year ago:
>> https://patchwork.ozlabs.org/patch/722282/
>>
>> It was not merged and I do not see on-going work for this.
>>
>> This commit just provides a driver model probe hook to retrieve further
>> configuration from the live device tree. As there is no NAND ulass as of
>> yet (ab)using UCLASS_MISC. Once UCLASS_NAND is supported, it would be
>> possible to migrate to it.
>>
>> Signed-off-by: Marcel Ziswiler 
>>
>> ---



>>
>> +U_BOOT_DRIVER(tegra_nand) = {
>> + .name = "tegra-nand",
>> + .id = UCLASS_MISC,
>
> There is also UCLASS_MTD, which I was going to use in a upcoming
> patchset for mxs_nand.c.
>
> I see that drivers/mtd/nand/denali_dt.c is currently using UCLASS_MISC,
> Masahiro, any reason for that?


I do not remember why.
Maybe, I just missed UCLASS_MTD.

The denali_dt only uses .probe(), so any uclass would be fine.
I guess I chose something that sounded generic, so "MISC".




> Commit d85879938d ("dm: implement a MTD uclass") seems to suggest that
> it should be fine for NAND flash drivers too...
>
> --
> Stefan
>



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

Re: [U-Boot] config_whitelist: remove false-positive CONFIG options

[Tom Rini]

On Sat, Jan 06, 2018 at 03:17:06AM +0900, Masahiro Yamada wrote:

> U-Boot pulled in several core makefiles from Linux.  The following
> are not used in U-Boot:
> 
>   - CONFIG_DEBUG_SECTION_MISMATCH
>   - CONFIG_FTRACE_MCOUNT_RECORD
>   - CONFIG_GCOV_KERNEL
>   - CONFIG_GCOV_PROFILE_ALL
>   - CONFIG_KASAN
>   - CONFIG_MODVERSIONS
> 
> We can remove the unused code if we like. (although it will get the
> scripts out of sync)
> 
> CONFIG_BOOM and CONFIG_HIS_DRIVER are just mentioned in the comment
> block of scripts/basic/fixdep.c
> 
> CONFIG_SHELL is not configuration, but a variable for internal-use.
> It is just a historical misnomer in Kbuild.
> 
> Signed-off-by: Masahiro Yamada 
> Reviewed-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


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

[U-Boot] [PULL] u-boot-sh/master

[Marek Vasut]

The following changes since commit f0f6917188ad660cf002c10095f46ecf748b8f58:

  Prepare v2018.03-rc3 (2018-02-20 16:51:56 -0500)

are available in the Git repository at:

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

for you to fetch changes up to 0b75cc3f1303a5558115918b4aed760d0d68a797:

  mmc: uniphier-sd: Add compatible strings for RCar Gen2 (2018-02-23
00:06:05 +0100)


Marek Vasut (1):
  mmc: uniphier-sd: Add compatible strings for RCar Gen2

Tom Rini (2):
  sh: Use -m2a-nofpu only
  sh: Do not provide strncmp

 arch/sh/cpu/sh2/config.mk|  2 +-
 arch/sh/include/asm/string.h | 33 ++---
 drivers/mmc/uniphier-sd.c|  5 +
 3 files changed, 8 insertions(+), 32 deletions(-)
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [RFC v3 03/15] dma: add bcm6348-iudma support

[Grygorii Strashko]

Hi

thanks for your comments.

On 02/22/2018 02:48 PM, Álvaro Fernández Rojas wrote:
> El 22/02/2018 a las 20:50, Grygorii Strashko escribió:
>> On 02/21/2018 10:10 AM, Álvaro Fernández Rojas wrote:
>>> BCM6348 IUDMA controller is present on multiple BMIPS (BCM63xx) SoCs.
>>>
>>> Signed-off-by: Álvaro Fernández Rojas 
>>> ---
>>>    v3: no changes
>>>    v2: Fix dma rx burst config and select DMA_CHANNELS.
>>>
>>>    drivers/dma/Kconfig |   9 +
>>>    drivers/dma/Makefile    |   1 +
>>>    drivers/dma/bcm6348-iudma.c | 505 
>>> 
>>>    3 files changed, 515 insertions(+)
>>>    create mode 100644 drivers/dma/bcm6348-iudma.c
>>>
>> [...]
>>> +static int bcm6348_iudma_enable(struct dma *dma)
>>> +{
>>> +    struct bcm6348_iudma_priv *priv = dev_get_priv(dma->dev);
>>> +    struct bcm6348_chan_priv *ch_priv = priv->ch_priv[dma->id];
>>> +    struct bcm6348_dma_desc *dma_desc;
>>> +    uint8_t i;
>>> +
>>> +    /* init dma rings */
>>> +    dma_desc = ch_priv->dma_ring;
>>> +    for (i = 0; i < ch_priv->dma_ring_size; i++) {
>>> +    if (bcm6348_iudma_chan_is_rx(dma->id)) {
>>> +    dma_desc->status = DMAD_ST_OWN_MASK;
>>> +    dma_desc->length = PKTSIZE_ALIGN;
>>> +    dma_desc->address = virt_to_phys(net_rx_packets[i]);
>> You are filling RX queue/ring with buffers defined in Net core.
>> Does it mean that this DMA driver will not be usable for other 
>> purposes, as
>> Net can be compiled out?
> As far as I know, and depending on the specific SoC, BCM63xx IUDMA is 
> used for Ethernet, USB (device only) and xDSL.
> So yes, in u-boot it will be used for ethernet only.
> BTW, my first attempt didn't use net_rx_packets, but I saw that in 
> pic32_eth implementation and dropped the dma specific buffers. I will 
> add them again ;).

it is really net specific :)

>>
>> Wouldn't it be reasonable to have some sort of .receive_prepare() 
>> callback in
>> DMA dma_ops, so DMA user can control which buffers to push in RX DMA 
>> channel?
>> And it also can be used in eth_ops.free_pkt() callback (see below).
> Yes, probably, but maybe we can achieve that without adding another call.
>>

I'm looking at this patch set from our HW point of view. In my case,
DMA channel can be used with different IPs (not only networking), so
it would be really great if DMA user can pass RX buffers in DMA driver -
network driver can use net_rx_packets, other drivers might use own buffers.
So hard-codding RX buffers in DMA driver looks like not a good choice.

>>> +
>>> +    /* flush cache */
>>> +    flush_dcache_range((ulong)dma_desc,
>>> +    ALIGN_END_ADDR(struct bcm6348_dma_desc, dma_desc, 1));
>> Could you clarify pls, if you do return dma_desc to RX ring here or not?
> Yes.
>>
>> if yes, wouldn't it cause potential problem on Net RX path
>>     ret = eth_get_ops(current)->recv(current, flags, );
>> ^^ (1) here buffer will be received from DMA ( and pushed back to RX 
>> ring ?? )
>>
>>     flags = 0;
>>     if (ret > 0)
>>     net_process_received_packet(packet, ret);
>> ^^ (2) here it will be passed in Net stack
>>
>>     if (ret >= 0 && eth_get_ops(current)->free_pkt)
>>     eth_get_ops(current)->free_pkt(current, packet, ret);
>> ^^ at this point it should be safe to return buffer in DMA RX ring.
>>
>>     if (ret <= 0)
>>     break;
>>
>> Can DMA overwrite packet after point (1) while packet is still 
>> processed (2)?
> I don't think so, because as far as I know u-boot is not processing more 
> than one packet at once, is it?

u-boot can't process more than one packet, but dma does. if buffer returned
to DMA and there are some traffic on the line - DMA can potentially refill 
all buffers in its RX ring while u-boot still processing one packet.


> But yeah, I see your point and if it does process more than one packet 
> at once this is not the proper way to do that.
> I will use free_pkt in next version and lock the packet until it's 
> processed.


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

Re: [U-Boot] configs: Re-sync with CONFIG_DISTRO_DEFAULTS

[Tom Rini]

On Sat, Feb 10, 2018 at 04:54:38PM -0500, Tom Rini wrote:

> A number of platforms include config_distro_defaults.h but do not enable
> CONFIG_DISTRO_DEFAULTS.  As they plainly intended to, set that flag and
> re-sync config files.
> 
> Signed-off-by: Tom Rini 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH v2 0/9] rockchip: rk3288-vyasa: dts fixes/additions

[Dr. Philipp Tomsich]

> On 23 Feb 2018, at 16:29, Jagan Teki  wrote:
> 
> 
> 
> On 23-Feb-2018 8:53 PM, "Dr. Philipp Tomsich" 
>  > wrote:
> 
>> On 23 Feb 2018, at 16:17, Jagan Teki > > wrote:
>> 
>> Philipp,
>> 
>> On Wed, Feb 14, 2018 at 9:26 PM, Jagan Teki > > wrote:
>>> Series add new dts nodes like gmac, usb, io_domains and fixed existing
>>> regulator, pmic stuff as per schematic.
>>> 
>>> Changes for v2:
>>> - Collect Acked-by and Reviewed-by tags from Philipp
>>> - Add eMMC boot support
>>> - Add missing commit message
>>> - Remove RK_GPIO8 macro to sync with Linux
>>> 
>>> Jagan Teki (9):
>>>  ARM: dts: rockchip: Sync rk3288-vyasa dts from Linux
>>>  ARM: dts: rockchip: rk3288-vyasa: Remove vdd_log from rk808, DCDC_REG1
>>>  ARM: dts: rockchip: rk3288-vyasa: Use vmmc-supply from PMIC
>>>  ARM: dts: rockchip: Add regulators for rk3288-vyasa
>>>  ARM: dts: rockchip: Add gmac support for rk3288-vyasa board
>>>  rockchip: rk3288-vyasa: defconfig: Enable gmac support
>>>  ARM: dts: rockchip: Add usb host for rk3288-vyasa
>>>  ARM: dts: rockchip: Add usb otg for rk3288-vyasa
>>>  rk3288: vyasa: Add eMMC boot support
>> 
>> Can you pick this series, it's been there in ML from few releases.
> 
> 
> These have been sent only after rc2 was tagged and are on my todo-list
> for next (so they should go at the start of the merge window, when I send
> out the pull-request to get our next merged back onto master).
> 
> This this V2 initial version been from 11/17, ie reason for ping.

Just for future reference: I usually start processing a series once I have a 
final
version.  I’ve burned my fingers on merging vendor patches in the past after
rc1 had been out.

So my modus operandi now is: once v1 has its status in ‘changes requested’
I won’t track this until I get a newer version that can be merged. And if such a
version comes in after rc2, I’ll try to err on the safe side…
… OTOH, if you just barely miss a merge window and need it in rc2, you should
ping me right away.

Hope this helps,
Phil.

P.S.: I have you TPL fix on Travis right now...

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

Re: [U-Boot] Support of kernels > 16 MiB on Raspberry Pi

[Tuomas Tynkkynen]

+ agraf

On Fri, 23 Feb 2018 09:57:30 -0500
Tom Rini  wrote:

> On Fri, Feb 23, 2018 at 04:47:06PM +0900, Jaehoon Chung wrote:
> > On 02/23/2018 04:58 AM, Alexander Kurtz wrote:  
> > > Hi!
> > > 
> > > I am using U-Boot to boot Debian Buster arm64 (standard kernel with a
> > > dracut-based initramfs) via an extlinux.conf on my Raspberry Pi 3. 
> > > 
> > > Recently, the Debian kernel grew beyond 16 MiB:
> > > 
> > > 4.13: /boot/vmlinuz-4.13.0-1-arm64 == 16448000 bytes (< 16 MiB) [0]
> > > 4.14: /boot/vmlinuz-4.14.0-3-arm64 == 17539584 bytes (> 16 MiB) [1]
> > > 4.15: /boot/vmlinuz-4.15.0-1-arm64 == 17867264 bytes (> 16 MiB) [2]
> > > 
> > > https://github.com/u-boot/u-boot/blob/master/include/configs/rpi.h#L129 
> > > says:
> > > 
> > > #define ENV_MEM_LAYOUT_SETTINGS \
> > > "fdt_high=\0" \
> > > "initrd_high=\0" \
> > > "fdt_addr_r=0x0100\0" \
> > > "pxefile_addr_r=0x0010\0" \
> > > "kernel_addr_r=0x0100\0" \
> > > "scriptaddr=0x0200\0" \
> > > "ramdisk_addr_r=0x0210\0" \
> > > 
> > > Am I correct in assuming that this default configuration will break
> > > with kernels > 16 MiB? The Readme [3] seems to confirm this, but I
> > > wanted to ask for explicit confirmation here.  
> > 
> > Especially, this is occurred about arm64 kernel.
> > Because it wil be overlapped with other image address, if kernel image is 
> > over than 16MB.
> > 
> > In my case, i'm using the private boot.scr.img for booting script.
> > I had just added the kernel_addr_r=0x02d00.
> > 
> > Just Refer to below:
> > https://review.tizen.org/git/?p=platform/kernel/u-boot.git;a=commit;h=8fdfbbeb8a4b2f8c8e66824709e48d9abdb23534
> >   
> 
> I would strongly recommend setting the values here based on what
> linux/Documentation/arm/Booting and linux/Documentation/arm64/boot.txt
> describe as the maximum limits for each of these locations.  And take a
> peek at include/configs/ti_armv7_common.h in U-Boot on how I set these
> for the various TI platforms.
> 

I sent a patch for the load addresses a while ago, for which I never got
around to writing a follow-up it seems:

https://lists.denx.de/pipermail/u-boot/2017-June/295889.html

FWIW, I have my doubts of the relocation mechanism used for DTs and initrds
because on ARM, the size of the lowmem mapping in Linux (which dictates the
highest permitted address) depends on not only build-time options like
CONFIG_VMSPLIT_* but also on boot-time options like vmalloc=xxxM.

Also, at least when using the extlinux.conf boot method, because the files
(kernel, DTB, initrd) are first loaded to RAM to the addresses specified
in the environment and only then relocated, the files can still smash each
other in memory during load time. So enabling relocation doesn't actually
help, tweaking the load addresses is still required.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] Support of kernels > 16 MiB on Raspberry Pi

[Stephen Warren]

On 02/22/2018 12:58 PM, Alexander Kurtz wrote:

Hi!

I am using U-Boot to boot Debian Buster arm64 (standard kernel with a
dracut-based initramfs) via an extlinux.conf on my Raspberry Pi 3.

Recently, the Debian kernel grew beyond 16 MiB:

 4.13: /boot/vmlinuz-4.13.0-1-arm64 == 16448000 bytes (< 16 MiB) [0]
 4.14: /boot/vmlinuz-4.14.0-3-arm64 == 17539584 bytes (> 16 MiB) [1]
 4.15: /boot/vmlinuz-4.15.0-1-arm64 == 17867264 bytes (> 16 MiB) [2]

https://github.com/u-boot/u-boot/blob/master/include/configs/rpi.h#L129 says:

 #define ENV_MEM_LAYOUT_SETTINGS \
 "fdt_high=\0" \
 "initrd_high=\0" \
 "fdt_addr_r=0x0100\0" \
 "pxefile_addr_r=0x0010\0" \
 "kernel_addr_r=0x0100\0" \
 "scriptaddr=0x0200\0" \
 "ramdisk_addr_r=0x0210\0" \

Am I correct in assuming that this default configuration will break
with kernels > 16 MiB? The Readme [3] seems to confirm this, but I
wanted to ask for explicit confirmation here.


Yes, I expect those values are broken for kernels over 16MiB (and 
perhaps even smaller ones too, which may use memory after the compressed 
image for BSS during boot, which could overlap the ramdisk).

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

Re: [U-Boot] [PATCH v2 0/9] rockchip: rk3288-vyasa: dts fixes/additions

[Jagan Teki]

On 23-Feb-2018 8:53 PM, "Dr. Philipp Tomsich" <
philipp.toms...@theobroma-systems.com> wrote:


On 23 Feb 2018, at 16:17, Jagan Teki  wrote:

Philipp,

On Wed, Feb 14, 2018 at 9:26 PM, Jagan Teki 
wrote:

Series add new dts nodes like gmac, usb, io_domains and fixed existing
regulator, pmic stuff as per schematic.

Changes for v2:
- Collect Acked-by and Reviewed-by tags from Philipp
- Add eMMC boot support
- Add missing commit message
- Remove RK_GPIO8 macro to sync with Linux

Jagan Teki (9):
 ARM: dts: rockchip: Sync rk3288-vyasa dts from Linux
 ARM: dts: rockchip: rk3288-vyasa: Remove vdd_log from rk808, DCDC_REG1
 ARM: dts: rockchip: rk3288-vyasa: Use vmmc-supply from PMIC
 ARM: dts: rockchip: Add regulators for rk3288-vyasa
 ARM: dts: rockchip: Add gmac support for rk3288-vyasa board
 rockchip: rk3288-vyasa: defconfig: Enable gmac support
 ARM: dts: rockchip: Add usb host for rk3288-vyasa
 ARM: dts: rockchip: Add usb otg for rk3288-vyasa
 rk3288: vyasa: Add eMMC boot support


Can you pick this series, it's been there in ML from few releases.


These have been sent only after rc2 was tagged and are on my todo-list
for next (so they should go at the start of the merge window, when I send
out the pull-request to get our next merged back onto master).


This this V2 initial version been from 11/17, ie reason for ping.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot, v2, 1/1] fs: fat: avoid superfluous conversion calling set_cluster

[Tom Rini]

On Wed, Feb 14, 2018 at 07:14:43PM +0100, Heinrich Schuchardt wrote:

> Parameter size of function set_cluster is of type unsigned long. It makes
> no sense to convert actsize to int before passing it to set_cluster as
> size. Let's use loff_t as type of parameter size to avoid any conversion.
> 
> Signed-off-by: Heinrich Schuchardt 
> ---
> v2
>   change type of parameter size
> ---
>  fs/fat/fat_write.c | 7 +++
>  1 file changed, 3 insertions(+), 4 deletions(-)
> 
> diff --git a/fs/fat/fat_write.c b/fs/fat/fat_write.c
> index 2b753df2820..270b2908acd 100644
> --- a/fs/fat/fat_write.c
> +++ b/fs/fat/fat_write.c
> @@ -494,8 +494,7 @@ static __u32 determine_fatent(fsdata *mydata, __u32 entry)
>   * Return 0 on success, -1 otherwise.
>   */
>  static int
> -set_cluster(fsdata *mydata, __u32 clustnum, __u8 *buffer,
> -  unsigned long size)
> +set_cluster(fsdata *mydata, __u32 clustnum, __u8 *buffer, loff_t size)
>  {
>   __u32 idx = 0;
>   __u32 startsect;
> @@ -679,7 +678,7 @@ set_contents(fsdata *mydata, dir_entry *dentptr, __u8 
> *buffer,
>  
>   /* set remaining bytes */
>   actsize = filesize;
> - if (set_cluster(mydata, curclust, buffer, (int)actsize) != 0) {
> + if (set_cluster(mydata, curclust, buffer, actsize) != 0) {
>   debug("error: writing cluster\n");
>   return -1;
>   }
> @@ -696,7 +695,7 @@ set_contents(fsdata *mydata, dir_entry *dentptr, __u8 
> *buffer,
>  
>   return 0;
>  getit:
> - if (set_cluster(mydata, curclust, buffer, (int)actsize) != 0) {
> + if (set_cluster(mydata, curclust, buffer, actsize) != 0) {
>   debug("error: writing cluster\n");
>   return -1;
>   }

So, this introduces a bunch of build issues when using certain
toolchains (such as Debian's arm-linux-gnueabihf):
arm:  +   display5
+(display5) fs/built-in.o: In function `get_cluster':
+(display5) build/../fs/fat/fat.c:278: undefined reference to `__aeabi_ldivmod'
+(display5) arm-linux-gnueabihf-ld.bfd: BFD (GNU Binutils for Debian) 2.28 
assertion fail ../../bfd/elf32-arm.c:9514
+(display5) make[1]: *** [u-boot] Error 1
+(display5) make: *** [sub-make] Error 2

-- 
Tom


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

Re: [U-Boot] [PATCH v2 0/9] rockchip: rk3288-vyasa: dts fixes/additions

[Dr. Philipp Tomsich]

> On 23 Feb 2018, at 16:17, Jagan Teki  wrote:
> 
> Philipp,
> 
> On Wed, Feb 14, 2018 at 9:26 PM, Jagan Teki  > wrote:
>> Series add new dts nodes like gmac, usb, io_domains and fixed existing
>> regulator, pmic stuff as per schematic.
>> 
>> Changes for v2:
>> - Collect Acked-by and Reviewed-by tags from Philipp
>> - Add eMMC boot support
>> - Add missing commit message
>> - Remove RK_GPIO8 macro to sync with Linux
>> 
>> Jagan Teki (9):
>>  ARM: dts: rockchip: Sync rk3288-vyasa dts from Linux
>>  ARM: dts: rockchip: rk3288-vyasa: Remove vdd_log from rk808, DCDC_REG1
>>  ARM: dts: rockchip: rk3288-vyasa: Use vmmc-supply from PMIC
>>  ARM: dts: rockchip: Add regulators for rk3288-vyasa
>>  ARM: dts: rockchip: Add gmac support for rk3288-vyasa board
>>  rockchip: rk3288-vyasa: defconfig: Enable gmac support
>>  ARM: dts: rockchip: Add usb host for rk3288-vyasa
>>  ARM: dts: rockchip: Add usb otg for rk3288-vyasa
>>  rk3288: vyasa: Add eMMC boot support
> 
> Can you pick this series, it's been there in ML from few releases.


These have been sent only after rc2 was tagged and are on my todo-list
for next (so they should go at the start of the merge window, when I send
out the pull-request to get our next merged back onto master).

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

[U-Boot] [PATCH] rockchip: clk: rk3399: handle set_rate/get_rate for PLL_PPLL

[Philipp Tomsich]

The device-tree node for the PMU clk controller assigns to its parent
(i.e. PLL_PPLL) even though this clock currently is set up statically
by an init-function.

In order to avoid unexpected failures, a simple implementation of
set_rate (which accepts requests, but notifies the caller of the
preset frequency in its return value) and get_rate (which always
returns the preset frequency) are added.

Note that this is required for the RK808 PMIC to probe successfully on
the RK3399-Q7, following the support for the assigned-clocks property.

References: commit f4fcba5c5baa ("clk: implement clk_set_defaults()")
Signed-off-by: Philipp Tomsich 
Tested-by: Klaus Goger 
---

 drivers/clk/rockchip/clk_rk3399.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/clk/rockchip/clk_rk3399.c 
b/drivers/clk/rockchip/clk_rk3399.c
index 42926ba..37237e3 100644
--- a/drivers/clk/rockchip/clk_rk3399.c
+++ b/drivers/clk/rockchip/clk_rk3399.c
@@ -1236,6 +1236,8 @@ static ulong rk3399_pmuclk_get_rate(struct clk *clk)
ulong rate = 0;
 
switch (clk->id) {
+   case PLL_PPLL:
+   return PPLL_HZ;
case PCLK_RKPWM_PMU:
rate = rk3399_pwm_get_clk(priv->pmucru);
break;
@@ -1257,7 +1259,13 @@ static ulong rk3399_pmuclk_set_rate(struct clk *clk, 
ulong rate)
ulong ret = 0;
 
switch (clk->id) {
+   case PLL_PPLL:
+   /*
+* This has already been set up and we don't want/need
+* to change it here.  Accept the request though, as the
+* device-tree has this in an 'assigned-clocks' list.
+*/
+   return PPLL_HZ;
case SCLK_I2C0_PMU:
case SCLK_I2C4_PMU:
case SCLK_I2C8_PMU:
-- 
2.1.4

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

Re: [U-Boot] [PATCH 1/2] mtd: nand: tegra: convert to driver model and live tree

[Stefan Agner]

On 21.02.2018 16:16, Marcel Ziswiler wrote:
> From: Marcel Ziswiler 
> 
> The Tegra NAND driver recently got broken by ongoing driver model resp.
> live tree migration work:
> 
> NAND:  Could not decode nand-flash in device tree
> Tegra NAND init failed
> 0 MiB
> 
> A patch for NAND uclass support was proposed about a year ago:
> https://patchwork.ozlabs.org/patch/722282/
> 
> It was not merged and I do not see on-going work for this.
> 
> This commit just provides a driver model probe hook to retrieve further
> configuration from the live device tree. As there is no NAND ulass as of
> yet (ab)using UCLASS_MISC. Once UCLASS_NAND is supported, it would be
> possible to migrate to it.
> 
> Signed-off-by: Marcel Ziswiler 
> 
> ---
> 
>  drivers/mtd/nand/tegra_nand.c | 98 
> ---
>  1 file changed, 55 insertions(+), 43 deletions(-)
> 
> diff --git a/drivers/mtd/nand/tegra_nand.c b/drivers/mtd/nand/tegra_nand.c
> index c03c9cb178..405018018c 100644
> --- a/drivers/mtd/nand/tegra_nand.c
> +++ b/drivers/mtd/nand/tegra_nand.c
> @@ -18,6 +18,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include "tegra_nand.h"
>  
>  DECLARE_GLOBAL_DATA_PTR;
> @@ -29,6 +30,13 @@ DECLARE_GLOBAL_DATA_PTR;
>  /* ECC bytes to be generated for tag data */
>  #define TAG_ECC_BYTES4
>  
> +static const struct udevice_id tegra_nand_dt_ids[] = {
> + {
> + .compatible = "nvidia,tegra20-nand",
> + },
> + { /* sentinel */ }
> +};
> +
>  /* 64 byte oob block info for large page (== 2KB) device
>   *
>   * OOB flash layout for Tegra with Reed-Solomon 4 symbol correct ECC:
> @@ -91,9 +99,11 @@ struct nand_drv {
>   struct fdt_nand config;
>  };
>  
> -static struct nand_drv nand_ctrl;
> -static struct mtd_info *our_mtd;
> -static struct nand_chip nand_chip[CONFIG_SYS_MAX_NAND_DEVICE];
> +struct tegra_nand_info {
> + struct udevice *dev;
> + struct nand_drv nand_ctrl;
> + struct nand_chip nand_chip;
> +};
>  
>  /**
>   * Wait for command completion
> @@ -453,8 +463,8 @@ static void stop_command(struct nand_ctlr *reg)
>   * @param *reg_val   address of reg_val
>   * @return 0 if ok, -1 on error
>   */
> -static int set_bus_width_page_size(struct fdt_nand *config,
> - u32 *reg_val)
> +static int set_bus_width_page_size(struct mtd_info *our_mtd,
> +struct fdt_nand *config, u32 *reg_val)
>  {
>   if (config->width == 8)
>   *reg_val = CFG_BUS_WIDTH_8BIT;
> @@ -514,7 +524,7 @@ static int nand_rw_page(struct mtd_info *mtd,
> struct nand_chip *chip,
>  
>   info = (struct nand_drv *)nand_get_controller_data(chip);
>   config = >config;
> - if (set_bus_width_page_size(config, _val))
> + if (set_bus_width_page_size(mtd, config, _val))
>   return -EINVAL;
>  
>   /* Need to be 4-byte aligned */
> @@ -722,7 +732,7 @@ static int nand_rw_oob(struct mtd_info *mtd,
> struct nand_chip *chip,
>   if (((int)chip->oob_poi) & 0x03)
>   return -EINVAL;
>   info = (struct nand_drv *)nand_get_controller_data(chip);
> - if (set_bus_width_page_size(>config, _val))
> + if (set_bus_width_page_size(mtd, >config, _val))
>   return -EINVAL;
>  
>   stop_command(info->reg);
> @@ -883,51 +893,39 @@ static void setup_timing(unsigned
> timing[FDT_NAND_TIMING_COUNT],
>  /**
>   * Decode NAND parameters from the device tree
>   *
> - * @param blob   Device tree blob
> - * @param node   Node containing "nand-flash" compatible node
> + * @param devDriver model device
> + * @param config Device tree NAND configuration
>   * @return 0 if ok, -ve on error (FDT_ERR_...)
>   */
> -static int fdt_decode_nand(const void *blob, int node, struct fdt_nand 
> *config)
> +static int fdt_decode_nand(struct udevice *dev, struct fdt_nand *config)
>  {
>   int err;
>  
> - config->reg = (struct nand_ctlr *)fdtdec_get_addr(blob, node, "reg");
> - config->enabled = fdtdec_get_is_enabled(blob, node);
> - config->width = fdtdec_get_int(blob, node, "nvidia,nand-width", 8);
> - err = gpio_request_by_name_nodev(offset_to_ofnode(node),
> - "nvidia,wp-gpios", 0, >wp_gpio, GPIOD_IS_OUT);
> + config->reg = (struct nand_ctlr *)dev_read_addr(dev);
> + config->enabled = dev_read_enabled(dev);
> + config->width = dev_read_u32_default(dev, "nvidia,nand-width", 8);
> + err = gpio_request_by_name(dev, "nvidia,wp-gpios", 0, >wp_gpio,
> +GPIOD_IS_OUT);
>   if (err)
>   return err;
> - err = fdtdec_get_int_array(blob, node, "nvidia,timing",
> - config->timing, FDT_NAND_TIMING_COUNT);
> + err = dev_read_u32_array(dev, "nvidia,timing", config->timing,
> +  FDT_NAND_TIMING_COUNT);
>   if (err < 0)
>   return err;
>  
> - 

[U-Boot] [PATCH 0/5] rockchip: video: migrate RK3399 w/ HDMI to livetree

[Philipp Tomsich]

This series fixes the regression on the RK3399 (since some boards have
moved to live tree) for HDMI output.  This fix requires some new
functionality in the ofnode family (i.e. finding an ofnode's parent
node and finding an ofnode from a phandle), but these are all add-on
functionality and thus should not interfere with any other boards or
drivers (as it's only us using them so far).

To have working HDMI again, the fix for our PMU clk driver (so
PLL_PPLL, which is listed in the 'assigned-clocks', is handled
correctly during probing).


Kever Yang (1):
  core: add ofnode_get_by_phandle() api

Philipp Tomsich (4):
  core: ofnode: add ofnode_get_parent function
  rockchip: video: rk_hdmi: migrate to livetree
  rockchip: video: rk_vop: migrate to livetree
  rockchip: video: update MAINTAINERS

 MAINTAINERS  |  1 +
 drivers/core/ofnode.c| 27 +
 drivers/video/rockchip/rk_hdmi.c |  2 +-
 drivers/video/rockchip/rk_vop.c  | 85 +++-
 include/dm/ofnode.h  | 16 
 5 files changed, 102 insertions(+), 29 deletions(-)

-- 
2.1.4

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

Re: [U-Boot] [PATCH v2 0/9] rockchip: rk3288-vyasa: dts fixes/additions

[Jagan Teki]

Philipp,

On Wed, Feb 14, 2018 at 9:26 PM, Jagan Teki  wrote:
> Series add new dts nodes like gmac, usb, io_domains and fixed existing
> regulator, pmic stuff as per schematic.
>
> Changes for v2:
> - Collect Acked-by and Reviewed-by tags from Philipp
> - Add eMMC boot support
> - Add missing commit message
> - Remove RK_GPIO8 macro to sync with Linux
>
> Jagan Teki (9):
>   ARM: dts: rockchip: Sync rk3288-vyasa dts from Linux
>   ARM: dts: rockchip: rk3288-vyasa: Remove vdd_log from rk808, DCDC_REG1
>   ARM: dts: rockchip: rk3288-vyasa: Use vmmc-supply from PMIC
>   ARM: dts: rockchip: Add regulators for rk3288-vyasa
>   ARM: dts: rockchip: Add gmac support for rk3288-vyasa board
>   rockchip: rk3288-vyasa: defconfig: Enable gmac support
>   ARM: dts: rockchip: Add usb host for rk3288-vyasa
>   ARM: dts: rockchip: Add usb otg for rk3288-vyasa
>   rk3288: vyasa: Add eMMC boot support

Can you pick this series, it's been there in ML from few releases.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot, v2, 1/1] fs: fat: avoid useless conversion when calling get_cluster

[Tom Rini]

On Wed, Feb 14, 2018 at 07:17:28PM +0100, Heinrich Schuchardt wrote:

> Parameter size of function get_cluster() is of type unsigned long. It makes
> no sense to convert actsize to int before passing it to get_cluster as
> size. Let't use t_off as type of parameter to avoid any type conversion.
> 
> Signed-off-by: Heinrich Schuchardt 
> ---
> v2
>   change type of parameter size
> ---
>  fs/fat/fat.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/fs/fat/fat.c b/fs/fat/fat.c
> index dd7888cd6d4..cf4580b63df 100644
> --- a/fs/fat/fat.c
> +++ b/fs/fat/fat.c
> @@ -244,7 +244,7 @@ static __u32 get_fatent(fsdata *mydata, __u32 entry)
>   * Return 0 on success, -1 otherwise.
>   */
>  static int
> -get_cluster(fsdata *mydata, __u32 clustnum, __u8 *buffer, unsigned long size)
> +get_cluster(fsdata *mydata, __u32 clustnum, __u8 *buffer, loff_t size)
>  {
>   __u32 idx = 0;
>   __u32 startsect;
> @@ -353,7 +353,7 @@ static int get_contents(fsdata *mydata, dir_entry 
> *dentptr, loff_t pos,
>   if (pos) {
>   actsize = min(filesize, (loff_t)bytesperclust);
>   if (get_cluster(mydata, curclust, get_contents_vfatname_block,
> - (int)actsize) != 0) {
> + actsize) != 0) {
>   printf("Error reading cluster\n");
>   return -1;
>   }
> @@ -393,14 +393,14 @@ static int get_contents(fsdata *mydata, dir_entry 
> *dentptr, loff_t pos,
>  
>   /* get remaining bytes */
>   actsize = filesize;
> - if (get_cluster(mydata, curclust, buffer, (int)actsize) != 0) {
> + if (get_cluster(mydata, curclust, buffer, actsize) != 0) {
>   printf("Error reading cluster\n");
>   return -1;
>   }
>   *gotsize += actsize;
>   return 0;
>  getit:
> - if (get_cluster(mydata, curclust, buffer, (int)actsize) != 0) {
> + if (get_cluster(mydata, curclust, buffer, actsize) != 0) {
>   printf("Error reading cluster\n");
>   return -1;
>   }

And similar to my last message, this also causes problems on for example
socfpga_sr1500.

-- 
Tom


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

[U-Boot] [PATCH 4/5] rockchip: video: rk_vop: migrate to livetree

[Philipp Tomsich]

This migrates rk_vop (the shared functions used by multiple VOP
mini-drivers) to be compatible with a live tree.

Unfortunately, there's
(i)  a lot of tree traversal needed for a VOP (as each active VOP
 vnode references back to the endpoints in the encoders and vice
 versa) to configure the connection between VOPs and encoders;
(ii) the DTS binding is not too sane and one needs to walk a node's
 parents (the original code just assumed that the device would
 live 3 levels above the property linked through a phandle) until
 a UCLASS_DISPLAY device can be found.

As part of the migration, the code for finding the enclosing display
device has been changed to not assume a specific depth of nesting
(i.e. we walk until we reach the root or find a matching device) and
to use the newly introduced (in the same series) ofnode_get_parent()
function.

Signed-off-by: Philipp Tomsich 
Tested-by: Klaus Goger 
---

 drivers/video/rockchip/rk_vop.c | 85 +++--
 1 file changed, 57 insertions(+), 28 deletions(-)

diff --git a/drivers/video/rockchip/rk_vop.c b/drivers/video/rockchip/rk_vop.c
index c979049..1288608 100644
--- a/drivers/video/rockchip/rk_vop.c
+++ b/drivers/video/rockchip/rk_vop.c
@@ -218,41 +218,67 @@ static void rkvop_mode_set(struct udevice *dev,
  * node within the VOP's 'port' list.
  * @return 0 if OK, -ve if something went wrong
  */
-static int rk_display_init(struct udevice *dev, ulong fbbase, int ep_node)
+static int rk_display_init(struct udevice *dev, ulong fbbase, ofnode ep_node)
 {
struct video_priv *uc_priv = dev_get_uclass_priv(dev);
-   const void *blob = gd->fdt_blob;
struct rk_vop_priv *priv = dev_get_priv(dev);
int vop_id, remote_vop_id;
struct rk3288_vop *regs = priv->regs;
struct display_timing timing;
struct udevice *disp;
-   int ret, remote, i, offset;
+   int ret;
+   u32 remote_phandle;
struct display_plat *disp_uc_plat;
struct clk clk;
enum video_log2_bpp l2bpp;
+   ofnode remote;
 
-   vop_id = fdtdec_get_int(blob, ep_node, "reg", -1);
+   debug("%s(%s, %lu, %s)\n", __func__,
+ dev_read_name(dev), fbbase, ofnode_get_name(ep_node));
+
+   vop_id = ofnode_read_s32_default(ep_node, "reg", -1);
debug("vop_id=%d\n", vop_id);
-   remote = fdtdec_lookup_phandle(blob, ep_node, "remote-endpoint");
-   if (remote < 0)
-   return -EINVAL;
-   remote_vop_id = fdtdec_get_int(blob, remote, "reg", -1);
-   debug("remote vop_id=%d\n", remote_vop_id);
+   ret = ofnode_read_u32(ep_node, "remote-endpoint", _phandle);
+   if (ret)
+   return ret;
 
-   for (i = 0, offset = remote; i < 3 && offset > 0; i++)
-   offset = fdt_parent_offset(blob, offset);
-   if (offset < 0) {
-   debug("%s: Invalid remote-endpoint position\n", dev->name);
+   remote = ofnode_get_by_phandle(remote_phandle);
+   if (!ofnode_valid(remote))
return -EINVAL;
-   }
+   remote_vop_id = ofnode_read_u32_default(remote, "reg", -1);
+   debug("remote vop_id=%d\n", remote_vop_id);
 
-   ret = uclass_find_device_by_of_offset(UCLASS_DISPLAY, offset, );
-   if (ret) {
-   debug("%s: device '%s' display not found (ret=%d)\n", __func__,
- dev->name, ret);
-   return ret;
-   }
+   /*
+* The remote-endpoint references into a subnode of the encoder
+* (i.e. HDMI, MIPI, etc.) with the DTS looking something like
+* the following (assume 'hdmi_in_vopl' to be referenced):
+*
+* hdmi: hdmi@ff94 {
+*   ports {
+* hdmi_in: port {
+*   hdmi_in_vopb: endpoint@0 { ... };
+*   hdmi_in_vopl: endpoint@1 { ... };
+* }
+*   }
+* }
+*
+* The original code had 3 steps of "walking the parent", but
+* a much better (as in: less likely to break if the DTS
+* changes) way of doing this is to "find the enclosing device
+* of UCLASS_DISPLAY".
+*/
+   while (ofnode_valid(remote)) {
+   remote = ofnode_get_parent(remote);
+   if (!ofnode_valid(remote)) {
+   debug("%s(%s): no UCLASS_DISPLAY for remote-endpoint\n",
+ __func__, dev_read_name(dev));
+   return -EINVAL;
+   }
+
+   uclass_find_device_by_ofnode(UCLASS_DISPLAY, remote, );
+   if (disp)
+   break;
+   };
 
disp_uc_plat = dev_get_uclass_platdata(disp);
debug("Found device '%s', disp_uc_priv=%p\n", disp->name, disp_uc_plat);
@@ -334,16 +360,15 @@ void rk_vop_probe_regulators(struct udevice *dev,
 int rk_vop_probe(struct udevice *dev)
 {

Re: [U-Boot] [PATCH 0/5] rockchip: video: migrate RK3399 w/ HDMI to livetree

[Dr. Philipp Tomsich]

Tom et al.,

I’d like to see this bug fix included in 2018.03, but don’t want to take the 
decision
on my own:
-   some of this should have come via Anatolij’s tree
-   if touches ofnode.h/c and also needs a change by Kever that Simon
reviewed (and noted that test cases should also be added) and that
should normally come through the DM tree
-   it only affects our company's BSP and we can just keep a branch of
2018.03 alive in our public GIT until 2018.05 comes out...

Please let me know if I can process this through the Rockchip tree for
2018.03 or whether this has to wait until the new merge window.

Thanks,
Philipp.

> On 23 Feb 2018, at 17:38, Philipp Tomsich 
>  wrote:
> 
> 
> This series fixes the regression on the RK3399 (since some boards have
> moved to live tree) for HDMI output.  This fix requires some new
> functionality in the ofnode family (i.e. finding an ofnode's parent
> node and finding an ofnode from a phandle), but these are all add-on
> functionality and thus should not interfere with any other boards or
> drivers (as it's only us using them so far).
> 
> To have working HDMI again, the fix for our PMU clk driver (so
> PLL_PPLL, which is listed in the 'assigned-clocks', is handled
> correctly during probing).
> 
> 
> Kever Yang (1):
>  core: add ofnode_get_by_phandle() api
> 
> Philipp Tomsich (4):
>  core: ofnode: add ofnode_get_parent function
>  rockchip: video: rk_hdmi: migrate to livetree
>  rockchip: video: rk_vop: migrate to livetree
>  rockchip: video: update MAINTAINERS
> 
> MAINTAINERS  |  1 +
> drivers/core/ofnode.c| 27 +
> drivers/video/rockchip/rk_hdmi.c |  2 +-
> drivers/video/rockchip/rk_vop.c  | 85 +++-
> include/dm/ofnode.h  | 16 
> 5 files changed, 102 insertions(+), 29 deletions(-)
> 
> -- 
> 2.1.4
> 

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

Re: [U-Boot] [PATCH] rockchip: i2c: enable I2C inside GRF for rk3066 and rk3188

[Dr. Philipp Tomsich]

> On 20 Feb 2018, at 09:43, Alexander Kochetkov  wrote:
> 
> In order to make I2C work on rk3066 and rk3188 boards GFR
> must be updated.

The commit message does not really tell me what the change is… 
…see below for a couple questions.

> 
> Signed-off-by: Alexander Kochetkov 

Acked-by: Philipp Tomsich 

> ---
> drivers/i2c/rk_i2c.c |   85 +++---
> 1 file changed, 80 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/i2c/rk_i2c.c b/drivers/i2c/rk_i2c.c
> index 332280c..3ec5474 100644
> --- a/drivers/i2c/rk_i2c.c
> +++ b/drivers/i2c/rk_i2c.c
> @@ -12,6 +12,7 @@
> #include 
> #include 
> #include 
> +#include 
> #include 
> #include 
> #include 
> @@ -34,6 +35,13 @@ struct rk_i2c {
>   unsigned int speed;
> };
> 
> +/**
> + * @grf_offset: offset inside the grf regmap for setting the i2c type
> + */
> +struct rk_i2c_soc_data {
> + int grf_offset;
> +};
> +
> static inline void rk_i2c_get_div(int div, int *divh, int *divl)
> {
>   *divl = div / 2;
> @@ -381,9 +389,37 @@ static int rockchip_i2c_ofdata_to_platdata(struct 
> udevice *bus)
> static int rockchip_i2c_probe(struct udevice *bus)
> {
>   struct rk_i2c *priv = dev_get_priv(bus);
> + struct rk_i2c_soc_data *soc_data;
> + uint32_t value;
> + int bus_nr;
> + void *grf;
> + int ret;
> 
>   priv->regs = dev_read_addr_ptr(bus);
> 
> + soc_data = (struct rk_i2c_soc_data*)dev_get_driver_data(bus);
> +
> + if (soc_data->grf_offset >= 0) {
> + grf = syscon_get_first_range(ROCKCHIP_SYSCON_GRF);
> + if (IS_ERR(grf)) {
> + ret = PTR_ERR(grf);
> + debug("%s: Could not get syscon for %s: %d\n",
> +  __func__, bus->name, ret);
> + return ret;
> + }
> +
> + ret = dev_read_alias_seq(bus, _nr);
> + if (ret < 0) {
> + debug("%s: Could not get alias for %s: %d\n",
> +  __func__, bus->name, ret);
> + return ret;
> + }
> +
> + /* 27+i: write mask, 11+i: value */
> + value = BIT(27 + bus_nr) | BIT(11 + bus_nr);

What exactly are you trying to configure here?

Do you need to bring these out of reset, is this some IO config or
are these clock gates?  Note that if it’s any of these, then the 
respective drivers (i.e. reset, pinctrl, clock) should be modified
instead of putting this here. 

> + writel(value, grf + soc_data->grf_offset);

This should be a rk_setreg(…) call.

> + }
> +
>   return 0;
> }
> 
> @@ -392,12 +428,51 @@ static const struct dm_i2c_ops rockchip_i2c_ops = {
>   .set_bus_speed  = rockchip_i2c_set_bus_speed,
> };
> 
> +static const struct rk_i2c_soc_data rk3066_soc_data = {
> + .grf_offset = 0x154,

Please don’t use open-coded constants for something like this.

> +};
> +
> +static const struct rk_i2c_soc_data rk3188_soc_data = {
> + .grf_offset = 0x0a4,
> +};
> +
> +static const struct rk_i2c_soc_data rk3228_soc_data = {
> + .grf_offset = -1,
> +};
> +
> +static const struct rk_i2c_soc_data rk3288_soc_data = {
> + .grf_offset = -1,
> +};
> +
> +static const struct rk_i2c_soc_data rk3328_soc_data = {
> + .grf_offset = -1,
> +};
> +
> +static const struct rk_i2c_soc_data rk3399_soc_data = {
> + .grf_offset = -1,
> +};
> +
> static const struct udevice_id rockchip_i2c_ids[] = {
> - { .compatible = "rockchip,rk3066-i2c" },
> - { .compatible = "rockchip,rk3188-i2c" },
> - { .compatible = "rockchip,rk3288-i2c" },
> - { .compatible = "rockchip,rk3328-i2c" },
> - { .compatible = "rockchip,rk3399-i2c" },
> + {
> + .compatible = "rockchip,rk3066-i2c",
> + .data = (ulong)_soc_data,
> + },
> + {
> + .compatible = "rockchip,rk3188-i2c",
> + .data = (ulong)_soc_data,
> + },
> + {
> + .compatible = "rockchip,rk3288-i2c",
> + .data = (ulong)_soc_data,
> + },
> + {
> + .compatible = "rockchip,rk3328-i2c",
> + .data = (ulong)_soc_data,
> + },
> + {
> + .compatible = "rockchip,rk3399-i2c",
> + .data = (ulong)_soc_data,
> + },
>   { }
> };
> 
> -- 
> 1.7.9.5
> 
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot

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

[U-Boot] [PATCH 3/5] rockchip: video: rk_hdmi: migrate to livetree

[Philipp Tomsich]

The rk_hdmi (shared functions for multiple HDMI mini-drivers) has been
using devfdt_get_addr() to read the HDMI controller's IO base address.
This will cause a failure with a live tree.

This changes the driver to use dev_read_addr() which is safe both for
flat trees and live trees.

Signed-off-by: Philipp Tomsich 
Tested-by: Klaus Goger 

---

 drivers/video/rockchip/rk_hdmi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/video/rockchip/rk_hdmi.c b/drivers/video/rockchip/rk_hdmi.c
index a9c8fba..b55b397 100644
--- a/drivers/video/rockchip/rk_hdmi.c
+++ b/drivers/video/rockchip/rk_hdmi.c
@@ -84,7 +84,7 @@ int rk_hdmi_ofdata_to_platdata(struct udevice *dev)
struct rk_hdmi_priv *priv = dev_get_priv(dev);
struct dw_hdmi *hdmi = >hdmi;
 
-   hdmi->ioaddr = (ulong)devfdt_get_addr(dev);
+   hdmi->ioaddr = (ulong)dev_read_addr(dev);
hdmi->mpll_cfg = rockchip_mpll_cfg;
hdmi->phy_cfg = rockchip_phy_config;
 
-- 
2.1.4

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

[U-Boot] [PATCH 2/5] core: add ofnode_get_by_phandle() api

[Philipp Tomsich]

From: Kever Yang 

We need to get ofnode from a phandle, add interface to support
both live dt and fdt.

Signed-off-by: Kever Yang 
Reviewed-by: Simon Glass 
Reviewed-by: Philipp Tomsich 
Tested-by: Klaus Goger 
Signed-off-by: Philipp Tomsich 
---

 drivers/core/ofnode.c | 13 +
 include/dm/ofnode.h   |  8 
 2 files changed, 21 insertions(+)

diff --git a/drivers/core/ofnode.c b/drivers/core/ofnode.c
index dd6d57c..d0bdea0 100644
--- a/drivers/core/ofnode.c
+++ b/drivers/core/ofnode.c
@@ -188,6 +188,19 @@ const char *ofnode_get_name(ofnode node)
return fdt_get_name(gd->fdt_blob, ofnode_to_offset(node), NULL);
 }
 
+ofnode ofnode_get_by_phandle(uint phandle)
+{
+   ofnode node;
+
+   if (of_live_active())
+   node = np_to_ofnode(of_find_node_by_phandle(phandle));
+   else
+   node.of_offset = fdt_node_offset_by_phandle(gd->fdt_blob,
+   phandle);
+
+   return node;
+}
+
 int ofnode_read_size(ofnode node, const char *propname)
 {
int len;
diff --git a/include/dm/ofnode.h b/include/dm/ofnode.h
index 6938e62..0d00840 100644
--- a/include/dm/ofnode.h
+++ b/include/dm/ofnode.h
@@ -318,6 +318,14 @@ ofnode ofnode_get_parent(ofnode node);
 const char *ofnode_get_name(ofnode node);
 
 /**
+ * ofnode_get_by_phandle() - get ofnode from phandle
+ *
+ * @phandle:   phandle to look up
+ * @return ofnode reference to the phandle
+ */
+ofnode ofnode_get_by_phandle(uint phandle);
+
+/**
  * ofnode_read_size() - read the size of a property
  *
  * @node: node to check
-- 
2.1.4

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

Re: [U-Boot] pci: Fix decode regions for memory banks

[Tom Rini]

On Thu, Feb 15, 2018 at 08:59:53AM +0100, Bernhard Messerklinger wrote:

> Since memory banks may not be located behind each other we need to add
> them separately.
> 
> Signed-off-by: Bernhard Messerklinger 
> 
> Reviewed-by: Hannes Schmelzer 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot,v2] net: Remove Xilinx ll_temac driver

[Tom Rini]

On Tue, Feb 20, 2018 at 10:19:00AM +0100, Michal Simek wrote:

> ll_temac driver was used by Xilinx Microblaze big endian and
> Xilinx ppc405/ppc440 SoCs.
> 
> ppc support was removed by: "powerpc: remove 4xx support"
> (sha1: 98f705c9cefdfdba62c069821bbba10273a0a8ed)
> and Microblaze BE is not tested for a long time that's why this driver
> can be removed because none is going to updated it to DM anyway.
> 
> Signed-off-by: Michal Simek 
> Acked-by: Joe Hershberger 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] configs: am335x_evm_usbspl: Add CONFIG_SPL_NET_VCI_STRING

[Tom Rini]

On Fri, Feb 16, 2018 at 01:41:23PM +0530, Faiz Abbas wrote:

> Add CONFIG_SPL_NET_VCI_STRING to enable USB-Ethernet boot mode
> support.
> 
> Signed-off-by: Faiz Abbas 
> Reviewed-by: Tom Rini 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] omap3_logic: Fix Environmental location

[Tom Rini]

On Thu, Feb 22, 2018 at 05:15:12PM -0600, Adam Ford wrote:

> For the omap3_logic boards, the environment is always in NAND.
> This removes the ENV_IS_IN_FAT flag to eliminate the extra chatter.
> 
> Signed-off-by: Adam Ford 
> 
> diff --git a/configs/omap3_logic_defconfig b/configs/omap3_logic_defconfig
> index 02eb2cf..0a60319 100644

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] arm64: show_regs: Dump the LRs HW values

[Tom Rini]

On Tue, Feb 20, 2018 at 11:30:08PM +, Karl Beldan wrote:

> These were dropped in [1], after relocation, for their values offset by
> reloc_off.
> Unconditionally show the HW values and add a '(reloc)' hint for the
> offset values showed after relocation.
> Also, the LRs' dumps are now formatted the same way the other regs' are.
> 
> [1] Commit 082693f4 ("arm64 :show_regs: show the address before relocation")
> 
> Signed-off-by: Karl Beldan 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot,v2] fdt: Fixup only valid memory banks

[Tom Rini]

On Thu, Feb 15, 2018 at 07:05:59PM +0100, Thierry Reding wrote:

> From: Thierry Reding 
> 
> Memory banks with address 0 and size 0 are empty and should not be
> passed to the OS via device tree.
> 
> Acked-by: Stephen Warren 
> Signed-off-by: Thierry Reding 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] Makefile: Don't mess with .text section location for selected arches

[Tom Rini]

On Wed, Feb 21, 2018 at 01:06:26PM +0300, Alexey Brodkin wrote:

> Most of architectures have .text section situated in the very beginning
> of U-Boot binary and thus it is very logical that CONFIG_SYS_TEXT_BASE
> is used on final linkage step to specify where U-Boot gets linked to.
> 
> For that we pass the following construction to the LD:

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [RFC] ns16550: Add support for AUX regs usage on some ARC SoCs

[Alexey Brodkin]

Hi Simon,

On Thu, 2018-02-22 at 10:29 -0700, Simon Glass wrote:
> Hi Alexey,
> 
> On 22 February 2018 at 09:23, Alexey Brodkin
>  wrote:
> > Hi Simon,
> > 
> > On Thu, 2018-02-22 at 09:17 -0700, Simon Glass wrote:
> > > Hi,
> > > 
> > > On 21 February 2018 at 05:26, Alexey Brodkin
> > >  wrote:

[snip]

> > > > ---
> > > >  drivers/serial/ns16550.c | 11 +--
> > > >  1 file changed, 9 insertions(+), 2 deletions(-)
> > > 
> > > I think a separate driver might be better, unless we want to make the
> > > read/write interface go through regmap or similar?
> > 
> > But in case of ARC's AUX regs portmap won't help because those AUX regs are
> > couldn't be mapped - that a completely different address space and we may
> > only access them via dedicated instructions (LR vs LD and SR vs ST).
> 
> Well...
> 
> 1. With a separate driver, you can do whatever you want :-) I know it
> introduces code duplication though...
> 
> 2. With regmap you can add your own regmap driver, and again do
> whatever you want. I can help with that if it sounds attractive

That sounds definitely interesting!
Are there any pointers on how that usually done?

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

Re: [U-Boot] [uboot-snps-arc] [PATCH 1/2] SPI Flash: add support of sst26wf* flash series

[Eugeniy Paltsev]

Hi Jagan,

Maybe you have any comments or remarks about this patch? And if you don't could 
you please apply it. Thanks!


On Tue, 2018-02-06 at 18:15 +0300, Eugeniy Paltsev wrote:
> sst26wf flash series block protection implementation differs
> from other SST series, so add implementation for sst26wf
> lock/unlock/is_locked functions.
> 
> Signed-off-by: Eugeniy Paltsev 
> ---
>  drivers/mtd/spi/spi_flash.c | 188 
> 
>  1 file changed, 188 insertions(+)
> 
> diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
> index 294d9f9..ec3f5bc 100644
> --- a/drivers/mtd/spi/spi_flash.c
> +++ b/drivers/mtd/spi/spi_flash.c
> @@ -842,6 +842,184 @@ int stm_unlock(struct spi_flash *flash, u32 ofs, size_t 
> len)
>  }
>  #endif
>  
> +#if defined(CONFIG_SPI_FLASH_SST)
> +#define SST26_CMD_READ_BPR   0x72
> +#define SST26_CMD_WRITE_BPR  0x42
> +
> +#define BLOCK_64K_SZ 0x1
> +#define MAX_BPR_REG_LEN  (18 + 1)
> +#define SST26WF_BOUND_REG_SIZE   ((32 + 4 * 8) * 1024)
> +
> +bool sst26_check_bpr(u32 bpr_size, u8 *cmd, u32 bit)
> +{
> + return !!(cmd[bpr_size - (bit / 8) - 1] & BIT(bit % 8));
> +}
> +
> +bool sst26_clear_bpr(u32 bpr_size, u8 *cmd, u32 bit)
> +{
> + cmd[bpr_size - (bit / 8) - 1] &= ~BIT(bit % 8);
> + return false;
> +}
> +
> +bool sst26_set_bpr(u32 bpr_size, u8 *cmd, u32 bit)
> +{
> + cmd[bpr_size - (bit / 8) - 1] |= BIT(bit % 8);
> + return false;
> +}
> +
> +enum lock_ctl {
> + CTL_LOCK,
> + CTL_UNLOCK,
> + CTL_CHECK
> +};
> +
> +/*
> + * sst26wf016/sst26wf032/sst26wf064 have next block protection:
> + * 4x   - 8  KByte blocks - read & write protection bits - upper addresses
> + * 1x   - 32 KByte blocks - write protection bits
> + * rest - 64 KByte blocks - write protection bits
> + * 1x   - 32 KByte blocks - write protection bits
> + * 4x   - 8  KByte blocks - read & write protection bits - lower addresses
> + *
> + * We'll support only per 64k lock/unlock so lower and upper 64 KByte region
> + * will be treated as single block.
> + */
> +
> +/*
> + * Lock, unlock or check lock status of the flash region of the flash 
> (depending
> + * on the lock_ctl value)
> + */
> +int sst26_lock_ctl(struct spi_flash *flash, u32 ofs, size_t len, enum 
> lock_ctl ctl)
> +{
> + u32 i, bpr_ptr, rptr_64k, lptr_64k, bpr_size;
> + bool lower_64k = false, upper_64k = false;
> + u8 cmd, bpr_buff[MAX_BPR_REG_LEN] = {};
> + int ret;
> +
> + bool (* bpr_bit_process) (u32 bpr_size, u8 *, u32);
> +
> + /* Check length and offset for 64k alignment */
> + if ((ofs & 0x) || (len & 0x))
> + return -EINVAL;
> +
> + if (ofs + len > flash->size)
> + return -EINVAL;
> +
> + /* SST26 family has only 16 Mbit, 32 Mbit and 64 Mbit IC */
> + if (flash->size != 0x20 &&
> + flash->size != 0x40 &&
> + flash->size != 0x80)
> + return -EINVAL;
> +
> + bpr_size = 2 + (flash->size / BLOCK_64K_SZ / 8);
> +
> + cmd = SST26_CMD_READ_BPR;
> + ret = spi_flash_read_common(flash, , 1, bpr_buff, bpr_size);
> + if (ret < 0) {
> + printf("SF: fail to read block-protection register\n");
> + return ret;
> + }
> +
> + if (ctl == CTL_LOCK)
> + bpr_bit_process = sst26_set_bpr;
> + else if (ctl == CTL_UNLOCK)
> + bpr_bit_process = sst26_clear_bpr;
> + else
> + bpr_bit_process = sst26_check_bpr;
> +
> + rptr_64k = min_t(u32, ofs + len , flash->size - SST26WF_BOUND_REG_SIZE);
> + lptr_64k = max_t(u32, ofs, SST26WF_BOUND_REG_SIZE);
> +
> + upper_64k = ((ofs + len) > (flash->size - SST26WF_BOUND_REG_SIZE));
> + lower_64k = (ofs < SST26WF_BOUND_REG_SIZE);
> +
> + /* Lower bits in block-protection register are about 64k region */
> + bpr_ptr = lptr_64k / BLOCK_64K_SZ - 1;
> +
> + /* Process 64K blocks region */
> + while (lptr_64k < rptr_64k) {
> + if (bpr_bit_process(bpr_size, bpr_buff, bpr_ptr))
> + return 1;
> +
> + bpr_ptr++;
> + lptr_64k += BLOCK_64K_SZ;
> + }
> +
> + /* 32K and 8K region bits in BPR are after 64k region bits */
> + bpr_ptr = (flash->size - 2 * SST26WF_BOUND_REG_SIZE) / BLOCK_64K_SZ;
> +
> + /* Process lower 32K block region */
> + if (lower_64k)
> + if (bpr_bit_process(bpr_size, bpr_buff, bpr_ptr))
> + return 1;
> +
> + bpr_ptr++;
> +
> + /* Process upper 32K block region */
> + if (upper_64k)
> + if (bpr_bit_process(bpr_size, bpr_buff, bpr_ptr))
> + return 1;
> +
> + bpr_ptr++;
> +
> + /* Process lower 8K block region */
> + for (i = 0; i < 4; i++) {
> + if (lower_64k)
> + if (bpr_bit_process(bpr_size, bpr_buff, bpr_ptr))
> +   

Re: [U-Boot] [U-Boot,2/2] xtensa: clean up CONFIG_SYS_TEXT_ADDR

[Tom Rini]

On Mon, Feb 12, 2018 at 03:39:19PM -0800, Max Filippov wrote:

> Drop CONFIG_SYS_MEMORY_TOP. Rename CONFIG_SYS_TEXT_ADDR to
> XTENSA_SYS_TEXT_ADDR.
> 
> Signed-off-by: Max Filippov 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot, 1/3] ARM: Kconfig: Move TI_SECURE_DEVICE to a common area

[Tom Rini]

On Wed, Feb 14, 2018 at 11:53:37AM -0600, Andrew F. Davis wrote:

> TI_SECURE_DEVICE is used by both OMAP2+ and Keystone2 family devices,
> and so when ARCH_OMAP2PLUS was used to gate off the OMAP2+ Kconfig
> Keystone2 family devices lost this config option.
> 
> Move this option out of mach-omap2 Kconfig to a spot accessible by both
> families. We picked arch/arm/Kconfig over the TI specific board/ti/
> location as this option is not specific to our boards but rather our
> architecture.
> 
> Plus at some point this option can be changed to just
> SECURE_DEVICE, as having secure parts is not exclusive to TI and
> so other vendors can interpret this option as needed by their device
> configurations.
> 
> Fixes: a93fbf4a7892 ("ARM: omap2+: rename config to ARCH_OMAP2PLUS and 
> consolidate Kconfig")
> Signed-off-by: Andrew F. Davis 
> Reviewed-by: Lokesh Vutla 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] ns16550: Fix mem mapped endian check

[Tom Rini]

On Thu, Feb 15, 2018 at 09:02:26AM +0100, Bernhard Messerklinger wrote:

> Do a explicit check for CONFIG_SYS_BIG_ENDIAN and
> CONFIG_SYS_LITTLE_ENDIAN to avoid errors on platforms where both
> are undefined (x86).
> 
> Signed-off-by: Bernhard Messerklinger 
> 
> Reviewed-by: Hannes Schmelzer 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot, 2/3] env: Fix missed getenv_ulong to env_get_ulong conversion

[Tom Rini]

On Wed, Feb 14, 2018 at 11:53:38AM -0600, Andrew F. Davis wrote:

> This seems to have been missed, possibly due to the inability to
> enable TI_SECURE_DEVICE on Keystone2 devices previously.
> 
> Fixes: bfebc8c965e4 ("env: Rename getenv_hex(), getenv_yesno(), 
> getenv_ulong()")
> Signed-off-by: Andrew F. Davis 
> Reviewed-by: Lokesh Vutla 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot, 3/3] defconfig: k2x_hs_evm: Re-enable TI_SECURE_DEVICE in HS K2x parts

[Tom Rini]

On Wed, Feb 14, 2018 at 11:53:39AM -0600, Andrew F. Davis wrote:

> These got removed in config re-syncs due to a Kconfig bug. Add these
> back here.
> 
> Signed-off-by: Andrew F. Davis 
> Reviewed-by: Lokesh Vutla 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] tools/kwbimage: fix LibreSSL build

[Tom Rini]

On Wed, Feb 21, 2018 at 02:59:01AM +1100, Jonathan Gray wrote:

> Fix build after addition of RSA_get0_key() to LibreSSL.
> Patch from Theo Buehler and Stuart Henderson.
> 
> Signed-off-by: Theo Buehler 
> Signed-off-by: Stuart Henderson 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] sf: Add ISSI IS25LP256 entry

[Tom Rini]

On Wed, Feb 21, 2018 at 09:12:02PM +0100, Marek Vasut wrote:

> Add entry for ISSI IS25LP256 part.
> 
> Signed-off-by: Marek Vasut 
> Cc: Jagan Teki 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH 1/5] core: ofnode: add ofnode_get_parent function

[Anatolij Gustschin]

On Fri, 23 Feb 2018 17:38:49 +0100
Philipp Tomsich philipp.toms...@theobroma-systems.com wrote:

> The Rockchip video drivers need to walk the ofnode-parrents to find
> an enclosing device that has a UCLASS_DISPLAY driver bound.  This
> adds a ofnode_get_parent()-function that returns the parent-node.
> 
> Signed-off-by: Philipp Tomsich 
> Tested-by: Klaus Goger 

Reviewed-by: Anatolij Gustschin 

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

Re: [U-Boot] [PATCH 3/5] rockchip: video: rk_hdmi: migrate to livetree

[Anatolij Gustschin]

On Fri, 23 Feb 2018 17:38:51 +0100
Philipp Tomsich philipp.toms...@theobroma-systems.com wrote:

> The rk_hdmi (shared functions for multiple HDMI mini-drivers) has been
> using devfdt_get_addr() to read the HDMI controller's IO base address.
> This will cause a failure with a live tree.
> 
> This changes the driver to use dev_read_addr() which is safe both for
> flat trees and live trees.
> 
> Signed-off-by: Philipp Tomsich 
> Tested-by: Klaus Goger 

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

Re: [U-Boot] Support of kernels > 16 MiB on Raspberry Pi

[Tom Rini]

On Fri, Feb 23, 2018 at 08:00:19PM +0200, Tuomas Tynkkynen wrote:
> + agraf
> 
> On Fri, 23 Feb 2018 09:57:30 -0500
> Tom Rini  wrote:
> 
> > On Fri, Feb 23, 2018 at 04:47:06PM +0900, Jaehoon Chung wrote:
> > > On 02/23/2018 04:58 AM, Alexander Kurtz wrote:  
> > > > Hi!
> > > > 
> > > > I am using U-Boot to boot Debian Buster arm64 (standard kernel with a
> > > > dracut-based initramfs) via an extlinux.conf on my Raspberry Pi 3. 
> > > > 
> > > > Recently, the Debian kernel grew beyond 16 MiB:
> > > > 
> > > > 4.13: /boot/vmlinuz-4.13.0-1-arm64 == 16448000 bytes (< 16 MiB) [0]
> > > > 4.14: /boot/vmlinuz-4.14.0-3-arm64 == 17539584 bytes (> 16 MiB) [1]
> > > > 4.15: /boot/vmlinuz-4.15.0-1-arm64 == 17867264 bytes (> 16 MiB) [2]
> > > > 
> > > > https://github.com/u-boot/u-boot/blob/master/include/configs/rpi.h#L129 
> > > > says:
> > > > 
> > > > #define ENV_MEM_LAYOUT_SETTINGS \
> > > > "fdt_high=\0" \
> > > > "initrd_high=\0" \
> > > > "fdt_addr_r=0x0100\0" \
> > > > "pxefile_addr_r=0x0010\0" \
> > > > "kernel_addr_r=0x0100\0" \
> > > > "scriptaddr=0x0200\0" \
> > > > "ramdisk_addr_r=0x0210\0" \
> > > > 
> > > > Am I correct in assuming that this default configuration will break
> > > > with kernels > 16 MiB? The Readme [3] seems to confirm this, but I
> > > > wanted to ask for explicit confirmation here.  
> > > 
> > > Especially, this is occurred about arm64 kernel.
> > > Because it wil be overlapped with other image address, if kernel image is 
> > > over than 16MB.
> > > 
> > > In my case, i'm using the private boot.scr.img for booting script.
> > > I had just added the kernel_addr_r=0x02d00.
> > > 
> > > Just Refer to below:
> > > https://review.tizen.org/git/?p=platform/kernel/u-boot.git;a=commit;h=8fdfbbeb8a4b2f8c8e66824709e48d9abdb23534
> > >   
> > 
> > I would strongly recommend setting the values here based on what
> > linux/Documentation/arm/Booting and linux/Documentation/arm64/boot.txt
> > describe as the maximum limits for each of these locations.  And take a
> > peek at include/configs/ti_armv7_common.h in U-Boot on how I set these
> > for the various TI platforms.
> > 
> 
> I sent a patch for the load addresses a while ago, for which I never got
> around to writing a follow-up it seems:
> 
> https://lists.denx.de/pipermail/u-boot/2017-June/295889.html
> 
> FWIW, I have my doubts of the relocation mechanism used for DTs and initrds
> because on ARM, the size of the lowmem mapping in Linux (which dictates the
> highest permitted address) depends on not only build-time options like
> CONFIG_VMSPLIT_* but also on boot-time options like vmalloc=xxxM.
> 
> Also, at least when using the extlinux.conf boot method, because the files
> (kernel, DTB, initrd) are first loaded to RAM to the addresses specified
> in the environment and only then relocated, the files can still smash each
> other in memory during load time. So enabling relocation doesn't actually
> help, tweaking the load addresses is still required.

It's true that on ARM you can have different splits, but at least when I
wrote the limits for TI, I either picked the smallest possible, or said
"if you have less than 256MB on your system, you need to make these
manually".  I honestly don't recall which atm.

-- 
Tom


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

Re: [U-Boot] [PATCH 5/5] rockchip: video: update MAINTAINERS

[Anatolij Gustschin]

On Fri, 23 Feb 2018 17:38:53 +0100
Philipp Tomsich philipp.toms...@theobroma-systems.com wrote:

> The video drivers (VOP, HDMI encoder, LVDS encoder, MIPI encoder) for
> Rockchip SOCs are self-contained and are mainly impacted by other
> changes in the architecture support (e.g. pinctrl, clocking, etc).
> 
> Let's add these to the list of files maintained as part of the
> Rockchip port.
> 
> Signed-off-by: Philipp Tomsich 

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

Re: [U-Boot] [PATCH 4/5] rockchip: video: rk_vop: migrate to livetree

[Anatolij Gustschin]

On Fri, 23 Feb 2018 17:38:52 +0100
Philipp Tomsich philipp.toms...@theobroma-systems.com wrote:

> This migrates rk_vop (the shared functions used by multiple VOP
> mini-drivers) to be compatible with a live tree.
> 
> Unfortunately, there's
> (i)  a lot of tree traversal needed for a VOP (as each active VOP
>  vnode references back to the endpoints in the encoders and vice
>  versa) to configure the connection between VOPs and encoders;
> (ii) the DTS binding is not too sane and one needs to walk a node's
>  parents (the original code just assumed that the device would
>  live 3 levels above the property linked through a phandle) until
>  a UCLASS_DISPLAY device can be found.
> 
> As part of the migration, the code for finding the enclosing display
> device has been changed to not assume a specific depth of nesting
> (i.e. we walk until we reach the root or find a matching device) and
> to use the newly introduced (in the same series) ofnode_get_parent()
> function.
> 
> Signed-off-by: Philipp Tomsich 
> Tested-by: Klaus Goger 

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

Re: [U-Boot] [PATCH 0/5] rockchip: video: migrate RK3399 w/ HDMI to livetree

[Anatolij Gustschin]

On Fri, 23 Feb 2018 17:38:48 +0100
Philipp Tomsich philipp.toms...@theobroma-systems.com wrote:
...
> To have working HDMI again, the fix for our PMU clk driver (so
> PLL_PPLL, which is listed in the 'assigned-clocks', is handled
> correctly during probing).

Series applied to u-boot-video/master, thanks!

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

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

[Tom Rini]

On Fri, Feb 23, 2018 at 05:58:37PM +0100, Marek Vasut wrote:

> The following changes since commit f0f6917188ad660cf002c10095f46ecf748b8f58:
> 
>   Prepare v2018.03-rc3 (2018-02-20 16:51:56 -0500)
> 
> are available in the Git repository at:
> 
>   git://git.denx.de/u-boot-sh.git master
> 
> for you to fetch changes up to 0b75cc3f1303a5558115918b4aed760d0d68a797:
> 
>   mmc: uniphier-sd: Add compatible strings for RCar Gen2 (2018-02-23
> 00:06:05 +0100)
> 

Applied to u-boot/master, thanks!

-- 
Tom


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

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

[Tom Rini]

On Fri, Feb 23, 2018 at 12:06:59AM +0100, Marek Vasut wrote:

> The following changes since commit f0f6917188ad660cf002c10095f46ecf748b8f58:
> 
>   Prepare v2018.03-rc3 (2018-02-20 16:51:56 -0500)
> 
> are available in the Git repository at:
> 
>   git://git.denx.de/u-boot-usb.git master
> 
> for you to fetch changes up to b0cce3f90f546da0c1e0dda5abcaf05d81078b0d:
> 
>   cmd: fastboot: Kconfig: solve config issue (2018-02-21 20:28:15 +0100)
> 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH 1/5] core: ofnode: add ofnode_get_parent function

[Simon Glass]

On 23 February 2018 at 09:38, Philipp Tomsich
 wrote:
>
> The Rockchip video drivers need to walk the ofnode-parrents to find
> an enclosing device that has a UCLASS_DISPLAY driver bound.  This
> adds a ofnode_get_parent()-function that returns the parent-node.
>
> Signed-off-by: Philipp Tomsich 
> Tested-by: Klaus Goger 
> ---
>
>  drivers/core/ofnode.c | 14 ++
>  include/dm/ofnode.h   |  8 
>  2 files changed, 22 insertions(+)
>

Reviewed-by: Simon Glass 

Do you think we could have a simple ofnode test in test/dm to call
this new function?
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v1 1/4] mmc: omap_hsmmc: do not embed struct mmc in struct omap_hsmmc_plat

[Simon Glass]

Hi Jean-Jacques,

On 22 February 2018 at 03:25, Jean-Jacques Hiblot  wrote:
> The area for struct mmc can be allocated dynamically. It greatly reduces
> the size of struct omap_hsmmc_plat. This is useful in cases where the board
> level code declares one or two struct omap_hsmmc_plat because it doesn't
> use the Driver Model.
>
> This saves around 740 bytes for the am335x_evm SPL.
>
> Signed-off-by: Jean-Jacques Hiblot 
> ---
>
>  arch/arm/include/asm/omap_mmc.h | 2 +-
>  drivers/mmc/omap_hsmmc.c| 6 +++---
>  2 files changed, 4 insertions(+), 4 deletions(-)
>

Reviewed-by: Simon Glass 

I would like to understand why this saves memory though. Presumably
the pointer has to point to a real struct anyway, which uses memory.
So how does this help?

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

Re: [U-Boot] [PATCH 2/2] usb: kbd: implement special keys

[Simon Glass]

Hi Heinrich,

On 22 February 2018 at 05:04, Heinrich Schuchardt  wrote:
> Correct support for arrow keys: use the standard xterm escape sequences.
>
> Provide support for F1-F12, Insert, Delete, Home, End, Page Up, Page Down.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  common/usb_kbd.c | 121 
> +--
>  1 file changed, 90 insertions(+), 31 deletions(-)
>

Is there any way this code could be shared with input.c? It has
translation tables.

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

Re: [U-Boot] [RFC] ns16550: Add support for AUX regs usage on some ARC SoCs

[Simon Glass]

Hi Alexey,

On 23 February 2018 at 11:08, Alexey Brodkin
 wrote:
> Hi Simon,
>
> On Thu, 2018-02-22 at 10:29 -0700, Simon Glass wrote:
>> Hi Alexey,
>>
>> On 22 February 2018 at 09:23, Alexey Brodkin
>>  wrote:
>> > Hi Simon,
>> >
>> > On Thu, 2018-02-22 at 09:17 -0700, Simon Glass wrote:
>> > > Hi,
>> > >
>> > > On 21 February 2018 at 05:26, Alexey Brodkin
>> > >  wrote:
>
> [snip]
>
>> > > > ---
>> > > >  drivers/serial/ns16550.c | 11 +--
>> > > >  1 file changed, 9 insertions(+), 2 deletions(-)
>> > >
>> > > I think a separate driver might be better, unless we want to make the
>> > > read/write interface go through regmap or similar?
>> >
>> > But in case of ARC's AUX regs portmap won't help because those AUX regs are
>> > couldn't be mapped - that a completely different address space and we may
>> > only access them via dedicated instructions (LR vs LD and SR vs ST).
>>
>> Well...
>>
>> 1. With a separate driver, you can do whatever you want :-) I know it
>> introduces code duplication though...
>>
>> 2. With regmap you can add your own regmap driver, and again do
>> whatever you want. I can help with that if it sounds attractive
>
> That sounds definitely interesting!
> Are there any pointers on how that usually done?

Not yet. My ideas:

- Add a new regmap_init_xxx() function
- Adjust the regmap structure to allow read()/write() function
pointers to be provided
- Adjust the regmap code to call them, instead of the hard-coded
memory-mapped ones
- Adjust ns16550 to call regmap instead of readl/writel

This should clean up the mess in ns16550 a bit. But it will require a
bit of investigation / thinking.

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

Re: [U-Boot] [PATCH v2 4/4] mmc: omap_hsmmc: use a default 52MHz max clock rate if none is specified

[Tom Rini]

On Fri, Feb 23, 2018 at 10:40:19AM +0100, Jean-Jacques Hiblot wrote:

> mmc_of_parse() doesn't set a default value if none is available in DT.
> In that case, use a default 52MHz clock rate.
> 
> Signed-off-by: Alex Kiernan 
> Signed-off-by: Jean-Jacques Hiblot 
> 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH v2 2/4] mmc: omap_hsmmc: compile out write support if not needed

[Tom Rini]

On Fri, Feb 23, 2018 at 10:40:17AM +0100, Jean-Jacques Hiblot wrote:

> This reduces the size of the binary by about 196 bytes.
> 
> Signed-off-by: Jean-Jacques Hiblot 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH v2 3/4] mmc: omap_hsmmc: make it possible to compile out ADMA support

[Tom Rini]

On Fri, Feb 23, 2018 at 10:40:18AM +0100, Jean-Jacques Hiblot wrote:
> Some platforms don't have ADMA controllers. For those platforms, compiling
> it out reduces the size of the binary by about 600 bytes.
> Leaving the support in doesn't break things as the driver checks at runtime
> if the ADMA2 controller is present.
> 
> Signed-off-by: Jean-Jacques Hiblot 
> 
> ---
> 
> Changes in v2:
> - Use a Kconfig option to compile out the ADMA support instead of relying
>   on the platform architecture
> 
>  drivers/mmc/Kconfig  |  9 +
>  drivers/mmc/omap_hsmmc.c | 12 ++--
>  2 files changed, 15 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
> index f2d8256..88a1359 100644
> --- a/drivers/mmc/Kconfig
> +++ b/drivers/mmc/Kconfig
> @@ -239,6 +239,15 @@ config MMC_OMAP_HS
>  
> If unsure, say N.
>  
> +config MMC_OMAP_HS_ADMA
> + bool "ADMA support for OMAP HS MMC"
> + depends on MMC_OMAP_HS && !OMAP34XX
> + default y if !AM33XX

Is this logic really the right restrictions?  Does it work on some
AM33XX platforms (AM43xx?) and just never OMAP34XX?  Thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH v2 1/4] mmc: omap_hsmmc: do not embed struct mmc in struct omap_hsmmc_plat

[Tom Rini]

On Fri, Feb 23, 2018 at 10:40:16AM +0100, Jean-Jacques Hiblot wrote:

> The area for struct mmc can be allocated dynamically. It greatly reduces
> the size of struct omap_hsmmc_plat. This is useful in cases where the board
> level code declares one or two struct omap_hsmmc_plat because it doesn't
> use the Driver Model.
> 
> This saves around 740 bytes for the am335x_evm SPL.
> 
> Signed-off-by: Jean-Jacques Hiblot 

Reviewed-by: Tom Rini 

-- 
Tom


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

[U-Boot] [PATCH v2 1/4] mmc: omap_hsmmc: do not embed struct mmc in struct omap_hsmmc_plat

[Jean-Jacques Hiblot]

The area for struct mmc can be allocated dynamically. It greatly reduces
the size of struct omap_hsmmc_plat. This is useful in cases where the board
level code declares one or two struct omap_hsmmc_plat because it doesn't
use the Driver Model.

This saves around 740 bytes for the am335x_evm SPL.

Signed-off-by: Jean-Jacques Hiblot 
---

Changes in v2: None

 arch/arm/include/asm/omap_mmc.h | 2 +-
 drivers/mmc/omap_hsmmc.c| 6 +++---
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/include/asm/omap_mmc.h b/arch/arm/include/asm/omap_mmc.h
index 3d70148..42ce8dc 100644
--- a/arch/arm/include/asm/omap_mmc.h
+++ b/arch/arm/include/asm/omap_mmc.h
@@ -67,7 +67,7 @@ struct hsmmc {
 struct omap_hsmmc_plat {
struct mmc_config cfg;
struct hsmmc *base_addr;
-   struct mmc mmc;
+   struct mmc *mmc;
bool cd_inverted;
u32 controller_flags;
const char *hw_rev;
diff --git a/drivers/mmc/omap_hsmmc.c b/drivers/mmc/omap_hsmmc.c
index 02970f2..e0b679a 100644
--- a/drivers/mmc/omap_hsmmc.c
+++ b/drivers/mmc/omap_hsmmc.c
@@ -1858,8 +1858,8 @@ static int omap_hsmmc_ofdata_to_platdata(struct udevice 
*dev)
 static int omap_hsmmc_bind(struct udevice *dev)
 {
struct omap_hsmmc_plat *plat = dev_get_platdata(dev);
-
-   return mmc_bind(dev, >mmc, >cfg);
+   plat->mmc = calloc(1, sizeof(struct mmc));
+   return mmc_bind(dev, plat->mmc, >cfg);
 }
 #endif
 static int omap_hsmmc_probe(struct udevice *dev)
@@ -1882,7 +1882,7 @@ static int omap_hsmmc_probe(struct udevice *dev)
 #endif
 
 #ifdef CONFIG_BLK
-   mmc = >mmc;
+   mmc = plat->mmc;
 #else
mmc = mmc_create(cfg, priv);
if (mmc == NULL)
-- 
1.9.1

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

Re: [U-Boot] [PATCH v2 0/4] mmc: omap_hsmmc: Reduce the footprint of the driver and fix am335x clock

[Adam Ford]

On Fri, Feb 23, 2018 at 3:40 AM, Jean-Jacques Hiblot 
wrote:

>
> This series aims at reducing the footprint of the omap_hsmmc driver in
> the SPL (1.5 kB gain in the case of the SPL for the am335x evm).
> It also fixes an issue with the am335x_evm by setting a default maximum
> frequency if none is defined in the dts.
>
> tested on am335x_evm, bbb, bbb (vboot), and dra7 evm
>
>
I tested this version as well.

This series fixes 2d7482cf793f ("mmc: omap_hsmmc: use mmc_of_parse to
populate mmc_config") which made my DM3730 unable to probe the MMC.

Tested-by: Adam Ford  #omap3_logic


> Changes in v2:
> - Use a Kconfig option to compile out the ADMA support instead of relying
>   on the platform architecture
>
> Jean-Jacques Hiblot (4):
>   mmc: omap_hsmmc: do not embed struct mmc in struct omap_hsmmc_plat
>   mmc: omap_hsmmc: compile out write support if not needed
>   mmc: omap_hsmmc: make it possible to compile out ADMA support
>   mmc: omap_hsmmc: use a default 52MHz max clock rate if none is
> specified
>
>  arch/arm/include/asm/omap_mmc.h |  2 +-
>  drivers/mmc/Kconfig |  9 +
>  drivers/mmc/omap_hsmmc.c| 31 ---
>  3 files changed, 30 insertions(+), 12 deletions(-)
>
> --
> 1.9.1
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v2 2/4] mmc: omap_hsmmc: compile out write support if not needed

[Jean-Jacques Hiblot]

This reduces the size of the binary by about 196 bytes.

Signed-off-by: Jean-Jacques Hiblot 
---

Changes in v2: None

 drivers/mmc/omap_hsmmc.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/omap_hsmmc.c b/drivers/mmc/omap_hsmmc.c
index e0b679a..8b57edc 100644
--- a/drivers/mmc/omap_hsmmc.c
+++ b/drivers/mmc/omap_hsmmc.c
@@ -1181,8 +1181,9 @@ static int mmc_read_data(struct hsmmc *mmc_base, char 
*buf, unsigned int size)
return 0;
 }
 
+#if CONFIG_IS_ENABLED(MMC_WRITE)
 static int mmc_write_data(struct hsmmc *mmc_base, const char *buf,
-   unsigned int size)
+ unsigned int size)
 {
unsigned int *input_buf = (unsigned int *)buf;
unsigned int mmc_stat;
@@ -1235,7 +1236,13 @@ static int mmc_write_data(struct hsmmc *mmc_base, const 
char *buf,
}
return 0;
 }
-
+#else
+static int mmc_write_data(struct hsmmc *mmc_base, const char *buf,
+ unsigned int size)
+{
+   return -ENOTSUPP;
+}
+#endif
 static void omap_hsmmc_stop_clock(struct hsmmc *mmc_base)
 {
writel(readl(_base->sysctl) & ~CEN_ENABLE, _base->sysctl);
-- 
1.9.1

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

[U-Boot] [PATCH v2 3/4] mmc: omap_hsmmc: make it possible to compile out ADMA support

[Jean-Jacques Hiblot]

Some platforms don't have ADMA controllers. For those platforms, compiling
it out reduces the size of the binary by about 600 bytes.
Leaving the support in doesn't break things as the driver checks at runtime
if the ADMA2 controller is present.

Signed-off-by: Jean-Jacques Hiblot 

---

Changes in v2:
- Use a Kconfig option to compile out the ADMA support instead of relying
  on the platform architecture

 drivers/mmc/Kconfig  |  9 +
 drivers/mmc/omap_hsmmc.c | 12 ++--
 2 files changed, 15 insertions(+), 6 deletions(-)

diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
index f2d8256..88a1359 100644
--- a/drivers/mmc/Kconfig
+++ b/drivers/mmc/Kconfig
@@ -239,6 +239,15 @@ config MMC_OMAP_HS
 
  If unsure, say N.
 
+config MMC_OMAP_HS_ADMA
+   bool "ADMA support for OMAP HS MMC"
+   depends on MMC_OMAP_HS && !OMAP34XX
+   default y if !AM33XX
+   help
+ This enables support for the ADMA2 controller (SDA3.00 Part A2 DMA
+ controller). If supported by the hardware, selecting this option will
+ increase performances.
+
 config MMC_OMAP36XX_PINS
bool "Enable MMC1 on OMAP36xx/37xx"
depends on OMAP34XX && MMC_OMAP_HS
diff --git a/drivers/mmc/omap_hsmmc.c b/drivers/mmc/omap_hsmmc.c
index 8b57edc..3d2836d 100644
--- a/drivers/mmc/omap_hsmmc.c
+++ b/drivers/mmc/omap_hsmmc.c
@@ -93,7 +93,7 @@ struct omap_hsmmc_data {
enum bus_mode mode;
 #endif
u8 controller_flags;
-#ifndef CONFIG_OMAP34XX
+#ifdef CONFIG_MMC_OMAP_HS_ADMA
struct omap_hsmmc_adma_desc *adma_desc_table;
uint desc_slot;
 #endif
@@ -117,7 +117,7 @@ struct omap_mmc_of_data {
u8 controller_flags;
 };
 
-#ifndef CONFIG_OMAP34XX
+#ifdef CONFIG_MMC_OMAP_HS_ADMA
 struct omap_hsmmc_adma_desc {
u8 attr;
u8 reserved;
@@ -741,7 +741,7 @@ static int omap_hsmmc_init_setup(struct mmc *mmc)
return -ETIMEDOUT;
}
}
-#ifndef CONFIG_OMAP34XX
+#ifdef CONFIG_MMC_OMAP_HS_ADMA
reg_val = readl(_base->hl_hwinfo);
if (reg_val & MADMA_EN)
priv->controller_flags |= OMAP_HSMMC_USE_ADMA;
@@ -834,7 +834,7 @@ static void mmc_reset_controller_fsm(struct hsmmc 
*mmc_base, u32 bit)
}
 }
 
-#ifndef CONFIG_OMAP34XX
+#ifdef CONFIG_MMC_OMAP_HS_ADMA
 static void omap_hsmmc_adma_desc(struct mmc *mmc, char *buf, u16 len, bool end)
 {
struct omap_hsmmc_data *priv = omap_hsmmc_get_data(mmc);
@@ -1037,7 +1037,7 @@ static int omap_hsmmc_send_cmd(struct udevice *dev, 
struct mmc_cmd *cmd,
else
flags |= (DP_DATA | DDIR_WRITE);
 
-#ifndef CONFIG_OMAP34XX
+#ifdef CONFIG_MMC_OMAP_HS_ADMA
if ((priv->controller_flags & OMAP_HSMMC_USE_ADMA) &&
!mmc_is_tuning_cmd(cmd->cmdidx)) {
omap_hsmmc_prepare_data(mmc, data);
@@ -1082,7 +1082,7 @@ static int omap_hsmmc_send_cmd(struct udevice *dev, 
struct mmc_cmd *cmd,
}
}
 
-#ifndef CONFIG_OMAP34XX
+#ifdef CONFIG_MMC_OMAP_HS_ADMA
if ((priv->controller_flags & OMAP_HSMMC_USE_ADMA) && data &&
!mmc_is_tuning_cmd(cmd->cmdidx)) {
u32 sz_mb, timeout;
-- 
1.9.1

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

Re: [U-Boot] [PATCH v2 0/4] mmc: omap_hsmmc: Reduce the footprint of the driver and fix am335x clock

[Jaehoon Chung]

On 02/23/2018 07:24 PM, Adam Ford wrote:
> On Fri, Feb 23, 2018 at 3:40 AM, Jean-Jacques Hiblot 
> wrote:
> 
>>
>> This series aims at reducing the footprint of the omap_hsmmc driver in
>> the SPL (1.5 kB gain in the case of the SPL for the am335x evm).
>> It also fixes an issue with the am335x_evm by setting a default maximum
>> frequency if none is defined in the dts.
>>
>> tested on am335x_evm, bbb, bbb (vboot), and dra7 evm
>>
>>
> I tested this version as well.
> 
> This series fixes 2d7482cf793f ("mmc: omap_hsmmc: use mmc_of_parse to
> populate mmc_config") which made my DM3730 unable to probe the MMC.
> 
> Tested-by: Adam Ford  #omap3_logic

After testing, I will apply these patches with your tag.

Best Regards,
Jaehoon Chung

> 
> 
>> Changes in v2:
>> - Use a Kconfig option to compile out the ADMA support instead of relying
>>   on the platform architecture
>>
>> Jean-Jacques Hiblot (4):
>>   mmc: omap_hsmmc: do not embed struct mmc in struct omap_hsmmc_plat
>>   mmc: omap_hsmmc: compile out write support if not needed
>>   mmc: omap_hsmmc: make it possible to compile out ADMA support
>>   mmc: omap_hsmmc: use a default 52MHz max clock rate if none is
>> specified
>>
>>  arch/arm/include/asm/omap_mmc.h |  2 +-
>>  drivers/mmc/Kconfig |  9 +
>>  drivers/mmc/omap_hsmmc.c| 31 ---
>>  3 files changed, 30 insertions(+), 12 deletions(-)
>>
>> --
>> 1.9.1
>>
>>
> 

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

Re: [U-Boot] [UBOOT PATCH 2/2] mmc: Added Kconfig support for CONFIG_ZYNQ_SDHCI_MIN_FREQ

[Jaehoon Chung]

Hi,

On 02/22/2018 09:17 PM, Vipul Kumar wrote:
> This patch added Kconfig support for CONFIG_ZYNQ_SDHCI_MIN_FREQ
> and enabled it in respective defconfig.
> 
> Signed-off-by: Vipul Kumar 
> Signed-off-by: Siva Durga Prasad Paladugu 
> ---
>  configs/xilinx_zynqmp_ep_defconfig | 1 +
>  drivers/mmc/Kconfig| 7 +++
>  drivers/mmc/zynq_sdhci.c   | 4 
>  include/configs/xilinx_zynqmp_ep.h | 1 -
>  4 files changed, 8 insertions(+), 5 deletions(-)
> 
> diff --git a/configs/xilinx_zynqmp_ep_defconfig 
> b/configs/xilinx_zynqmp_ep_defconfig
> index 00db5e3..4de1ac1 100644
> --- a/configs/xilinx_zynqmp_ep_defconfig
> +++ b/configs/xilinx_zynqmp_ep_defconfig
> @@ -62,6 +62,7 @@ CONFIG_MISC=y
>  CONFIG_DM_MMC=y
>  CONFIG_MMC_SDHCI=y
>  CONFIG_MMC_SDHCI_ZYNQ=y
> +CONFIG_ZYNQ_SDHCI_MIN_FREQ=101562

It seems that 101562 is the shifted value.
If ZYNQ_SDHCI_MIN_REQ is set to 100KHz, what happen?

Best Regards,
Jaehoon Chung

>  CONFIG_NAND=y
>  CONFIG_NAND_ARASAN=y
>  CONFIG_SPI_FLASH=y
> diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
> index 42b7d21..4f2993c 100644
> --- a/drivers/mmc/Kconfig
> +++ b/drivers/mmc/Kconfig
> @@ -478,6 +478,13 @@ config ZYNQ_SDHCI_MAX_FREQ
> help
>   Set the maximum frequency for the SDHCI controller.
> 
> +config ZYNQ_SDHCI_MIN_FREQ
> +   int "Set the minimum frequencyof the controller"
> +   depends on MMC_SDHCI_ZYNQ
> +   default 0
> +   help
> + Set the minimum frequencyof the controller.
> +
>  config MMC_SUNXI
> bool "Allwinner sunxi SD/MMC Host Controller support"
> depends on ARCH_SUNXI && !UART0_PORT_F
> diff --git a/drivers/mmc/zynq_sdhci.c b/drivers/mmc/zynq_sdhci.c
> index 0fddb42..414778c 100644
> --- a/drivers/mmc/zynq_sdhci.c
> +++ b/drivers/mmc/zynq_sdhci.c
> @@ -16,10 +16,6 @@
> 
>  DECLARE_GLOBAL_DATA_PTR;
> 
> -#ifndef CONFIG_ZYNQ_SDHCI_MIN_FREQ
> -# define CONFIG_ZYNQ_SDHCI_MIN_FREQ0
> -#endif
> -
>  struct arasan_sdhci_plat {
> struct mmc_config cfg;
> struct mmc mmc;
> diff --git a/include/configs/xilinx_zynqmp_ep.h 
> b/include/configs/xilinx_zynqmp_ep.h
> index a77eeea..a26377a 100644
> --- a/include/configs/xilinx_zynqmp_ep.h
> +++ b/include/configs/xilinx_zynqmp_ep.h
> @@ -13,7 +13,6 @@
>  #ifndef __CONFIG_ZYNQMP_EP_H
>  #define __CONFIG_ZYNQMP_EP_H
> 
> -#define CONFIG_ZYNQ_SDHCI_MIN_FREQ (CONFIG_ZYNQ_SDHCI_MAX_FREQ >> 9)
>  #define CONFIG_ZYNQ_EEPROM
>  #define CONFIG_ZYNQMP_XHCI_LIST {ZYNQMP_USB0_XHCI_BASEADDR, \
>  ZYNQMP_USB1_XHCI_BASEADDR}
> --
> 2.7.4
> 
> This email and any attachments are intended for the sole use of the named 
> recipient(s) and contain(s) confidential information that may be proprietary, 
> privileged or copyrighted under applicable law. If you are not the intended 
> recipient, do not read, copy, or forward this email message or any 
> attachments. Delete this email message and any attachments immediately.
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
> 

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

Re: [U-Boot] [PATCH] bootcount: flush after storing the bootcounter

[Lukasz Majewski]

Hi Heiko,

> Hello Lukasz,
> 
> Am 22.02.2018 um 14:03 schrieb Lukasz Majewski:
> > Hi Stefano,
> >   
> >> Hi Lukasz,
> >>
> >> On 22/02/2018 12:52, Lukasz Majewski wrote:  
> >>> Hi Stefano,
> >>>  
>  If the bootcounter address is in a cached memory,
>  a flush of dcache must occur after updateing the bootcounter.
> 
>  Issue found on i.MX6 where bootcounter is put into the internal
>  (cached) IRAM.
> 
>  Signed-off-by: Stefano Babic 
>  ---
>    drivers/bootcount/bootcount.c | 3 +++
>    1 file changed, 3 insertions(+)
> 
>  diff --git a/drivers/bootcount/bootcount.c
>  b/drivers/bootcount/bootcount.c index d5ce450..48594a6 100644
>  --- a/drivers/bootcount/bootcount.c
>  +++ b/drivers/bootcount/bootcount.c
>  @@ -59,6 +59,9 @@ __weak void bootcount_store(ulong a)
>   raw_bootcount_store(reg, a);
>   raw_bootcount_store(reg + 4, BOOTCOUNT_MAGIC);
>    #endif /* defined(CONFIG_SYS_BOOTCOUNT_SINGLEWORD */
>  +flush_dcache_range(CONFIG_SYS_BOOTCOUNT_ADDR,
>  +CONFIG_SYS_BOOTCOUNT_ADDR +
>  +CONFIG_SYS_CACHELINE_SIZE);  
> >>>
> >>> Is it safe to flush the whole cache line?  
> >>
> >> Is there is some drawbacks ?  
> > 
> > I think not - as we are now in u-boot.
> > 
> > (I do have patches, which add also support for bootcount in SPL - I
> > will send them when Kconfig prerequisities go into mainline).
> >   
> >>
> >> flush_dcache_range() requires that addresses are aligned with
> >> CONFIG_SYS_CACHELINE_SIZE. I cannot flush a single word.  
> > 
> > Yes. Correct.
> >   
> >>  
> >>>
> >>> For iMX6Q I do use SNVS_LPGR register (0x020CC068).  
> >>
> >> It is a long story...  
> > 
> > :-)
> >   
> >>  
> >>> It will preserve
> >>> its content after reset caused by WDT (also reset command in
> >>> u-boot). I also do use the SINGLEWORD to store "magic" and boot
> >>> count in a single 32 bit number.
> >>>  
> >>
> >> I used it in the past - Heiko found issues with recent kernel
> >> versions because kernel is using it. That means, after a rebootwe
> >> get what the kernel has written in it, not the bootcounter
> >> anymore.  
> > 
> > You mean the SRC_GPRx registers?
> >   
> >>
> >> It looks like, too, that SNVS behavior changes between i.MX6
> >> variants. Even in manual, there are discordances (on i.MX6Q seems
> >> can be used, on DL seems to be reserved,...).  
> > 
> > What I can say :/
> >   
> >>
> >> Due to recent issues, I searched for a suitable place in IRAM.  
> > 
> > Ok.
> >   
> >>
> >> Anyway, this has nothing to do with the issue. If the storage with
> >> the bootcounter is cached, it must be flushed.  
> > 
> > Yes. Of course.
> >   
> >>
> >>  
> >>> You may also want to consider using SRC_GPRx registers:
> >>> https://community.nxp.com/message/985790?commentID=985790=watches.email.thread#comment-985790
> >>>   
> >>
> >> See above, waiting for Heiko's comment,too.  
> > 
> > Ok. Maybe the reply from the NXP community is not complete...  
> 
> Hmm.. I have here an imx6dl based board:
> 
> CPU:   Freescale i.MX6DL rev1.3 at 792 MHz
> 
> and I tried to put the bootcounter into the iram, but found no addr,
> which is stable over a reboot from linux into U-Boot ... I must
> admit, that I use the GPU may it use iram? Nevertheless, unsure place.
> 
> Tried SRC_GPRx registers, but also not stable after a "boot linux -
> reboot to U-Boot" cycle.
> 
> imx6 D/QL UML says
> SRC_GPRx with x = 5-8 for quad only -> so not usable for me
> 
> and x=(1-8):
> 
> "Holds argument of entry function for coreX. The SRC ensures that the
> register value will persist across  system resets."
> 
> with (X=0-3)
> 
> So, the core may uses them ...
> 
> The S/DL manual says to this registers:
> "Read/write general purpose bits used to store an arbitrary value.
> This register is used by the ROM code and should not be used by
> application software."
> 
> So also on S/DL no chance to use this registers without risk ...

This was also my concern. Hence I've asked NXP community (support)
explicitly:

https://community.nxp.com/message/985790?commentID=985790=watches.email.thread#comment-985790

Maybe the BootROM is different for different SoC versions? (My iMX6Q is
rev. 1.5, yours iMX6DL is 1.3)?

Maybe it would be good to ask your case on the NXP community site as
well?

Similar symptomps I had with some Samsung SoCs. In their case the FBL
(not BootROM) from Samsung was using those registers to check if we go
out from "sleep" mode.

However, what I've understood from iMX6 User Manual, the BootROM on iMX6
needs values from SRC_GPRx - and it shall restore the LInux without the
need for bootloader intervention.

> 
> I have on my hw a pfuze100 and I stored the bootcounter in the 4 8bit
> registers MEMA - MEMD ... as we have no battery attached to the pfuze
> this works fine... as you said "Development by luck" :-D

:-)

[U-Boot] [PATCH v2 4/4] mmc: omap_hsmmc: use a default 52MHz max clock rate if none is specified

[Jean-Jacques Hiblot]

mmc_of_parse() doesn't set a default value if none is available in DT.
In that case, use a default 52MHz clock rate.

Signed-off-by: Alex Kiernan 
Signed-off-by: Jean-Jacques Hiblot 

---

Changes in v2: None

 drivers/mmc/omap_hsmmc.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/mmc/omap_hsmmc.c b/drivers/mmc/omap_hsmmc.c
index 3d2836d..caaa914 100644
--- a/drivers/mmc/omap_hsmmc.c
+++ b/drivers/mmc/omap_hsmmc.c
@@ -1832,6 +1832,8 @@ static int omap_hsmmc_ofdata_to_platdata(struct udevice 
*dev)
if (ret < 0)
return ret;
 
+   if (!cfg->f_max)
+   cfg->f_max = 5200;
cfg->host_caps |= MMC_MODE_HS_52MHz | MMC_MODE_HS;
cfg->f_min = 40;
cfg->voltages = MMC_VDD_32_33 | MMC_VDD_33_34 | MMC_VDD_165_195;
-- 
1.9.1

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

[U-Boot] [PATCH v2 0/4] mmc: omap_hsmmc: Reduce the footprint of the driver and fix am335x clock

[Jean-Jacques Hiblot]

This series aims at reducing the footprint of the omap_hsmmc driver in
the SPL (1.5 kB gain in the case of the SPL for the am335x evm).
It also fixes an issue with the am335x_evm by setting a default maximum
frequency if none is defined in the dts.

tested on am335x_evm, bbb, bbb (vboot), and dra7 evm

Changes in v2:
- Use a Kconfig option to compile out the ADMA support instead of relying
  on the platform architecture

Jean-Jacques Hiblot (4):
  mmc: omap_hsmmc: do not embed struct mmc in struct omap_hsmmc_plat
  mmc: omap_hsmmc: compile out write support if not needed
  mmc: omap_hsmmc: make it possible to compile out ADMA support
  mmc: omap_hsmmc: use a default 52MHz max clock rate if none is
specified

 arch/arm/include/asm/omap_mmc.h |  2 +-
 drivers/mmc/Kconfig |  9 +
 drivers/mmc/omap_hsmmc.c| 31 ---
 3 files changed, 30 insertions(+), 12 deletions(-)

-- 
1.9.1

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

Re: [U-Boot] [PATCH V5 31/31] imx: add i.MX8MQ EVK support

[Stefano Babic]

Hi Fabio,

On 22/02/2018 17:40, Fabio Estevam wrote:
> Hi Peng,
> 
> On Sun, Feb 4, 2018 at 7:42 AM, Stefano Babic  wrote:
> 
>> I have merged most of the series, Patch 2 up to patch 30, leaving out
>> just the last one for the EVK. Building mx8evk is fine, I have just
>> noted a couple of checkpatch warnings in mx8mq_evk.h
>> (CONFIG_EXTRA_SETTINGS, line too long). You could fix as well in next
>> post. The rest of patches is fine and will part of my next PR.
> 
> Do you plan to post a new version for the patch that adds the mx8mq evk 
> support?

Do you mean to get it in 2018.03 ? The merge window is already closed, I
am checking patches for fixes (if you see I missed something, raise a
hand as usual...), but without adding new stuff. I do not want to put
Peng under pressure while I am sure that MX8MQ EVK will be postponed in
next release.

Stefano

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

[U-Boot] [PATCH v2] mmc: uniphier-sd: Fix a compile error relevant to unused-function

[Jaehoon Chung]

During disabled MMC_HS200_SUPPORT, some functions don't use anywhere.

Signed-off-by: Jaehoon Chung 
---
Chnagelog on V2
- Remove functions in uniphier-sd.h

 drivers/mmc/uniphier-sd-rcar.c | 4 
 drivers/mmc/uniphier-sd.h  | 9 -
 2 files changed, 4 insertions(+), 9 deletions(-)

diff --git a/drivers/mmc/uniphier-sd-rcar.c b/drivers/mmc/uniphier-sd-rcar.c
index 8baa2a9b46..894decd04d 100644
--- a/drivers/mmc/uniphier-sd-rcar.c
+++ b/drivers/mmc/uniphier-sd-rcar.c
@@ -80,6 +80,7 @@ static unsigned int uniphier_sd_init_tuning(struct 
uniphier_sd_priv *priv)
SH_MOBILE_SDHI_SCC_DTCNTL_TAPNUM_MASK;
 }
 
+#if CONFIG_IS_ENABLED(MMC_HS200_SUPPORT)
 void rcar_gen3_sd_reset_tuning(struct uniphier_sd_priv *priv)
 {
u32 reg;
@@ -105,6 +106,7 @@ void rcar_gen3_sd_reset_tuning(struct uniphier_sd_priv 
*priv)
reg &= ~SH_MOBILE_SDHI_SCC_RVSCNTL_RVSEN;
uniphier_sd_writel(priv, reg, SH_MOBILE_SDHI_SCC_RVSCNTL);
 }
+#endif
 
 static void uniphier_sd_prepare_tuning(struct uniphier_sd_priv *priv,
   unsigned long tap)
@@ -223,6 +225,7 @@ static int uniphier_sd_select_tuning(struct 
uniphier_sd_priv *priv,
return 0;
 }
 
+#if CONFIG_IS_ENABLED(MMC_HS200_SUPPORT)
 int rcar_gen3_sd_execute_tuning(struct udevice *dev, uint opcode)
 {
struct uniphier_sd_priv *priv = dev_get_priv(dev);
@@ -286,3 +289,4 @@ out:
 
return ret;
 }
+#endif
diff --git a/drivers/mmc/uniphier-sd.h b/drivers/mmc/uniphier-sd.h
index 38d104296f..6192e5973c 100644
--- a/drivers/mmc/uniphier-sd.h
+++ b/drivers/mmc/uniphier-sd.h
@@ -141,15 +141,6 @@ void uniphier_sd_writel(struct uniphier_sd_priv *priv,
 #if CONFIG_IS_ENABLED(MMC_RENESAS_TUNING)
 void rcar_gen3_sd_reset_tuning(struct uniphier_sd_priv *priv);
 int rcar_gen3_sd_execute_tuning(struct udevice *dev, uint opcode);
-#else
-static void rcar_gen3_sd_reset_tuning(struct uniphier_sd_priv *priv)
-{
-}
-
-static int rcar_gen3_sd_execute_tuning(struct udevice *dev, uint opcode)
-{
-   return -EINVAL;
-}
 #endif
 
 #endif /* __MMC_UNIPHIER_SD_H__ */
-- 
2.16.1

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

Re: [U-Boot] [PATCH V5 31/31] imx: add i.MX8MQ EVK support

[Fabio Estevam]

Hi Peng,

On Fri, Feb 23, 2018 at 3:02 AM, Peng Fan  wrote:

>>Do you plan to post a new version for the patch that adds the mx8mq evk 
>>support?
>
> I was a bit busy on other things. Regarding the board support, I still
> do not have a good idea about the DDR things. I am thinking moving
> the ddr code out into a dedicated bin file and pad to the end of SPL.
>
> What do you think?

Let's wait for some feedback from Stefano.

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

Re: [U-Boot] [PATCH v2 3/4] mmc: omap_hsmmc: make it possible to compile out ADMA support

[Jean-Jacques Hiblot]

On 23/02/2018 13:21, Tom Rini wrote:

On Fri, Feb 23, 2018 at 10:40:18AM +0100, Jean-Jacques Hiblot wrote:

Some platforms don't have ADMA controllers. For those platforms, compiling
it out reduces the size of the binary by about 600 bytes.
Leaving the support in doesn't break things as the driver checks at runtime
if the ADMA2 controller is present.

Signed-off-by: Jean-Jacques Hiblot 

---

Changes in v2:
- Use a Kconfig option to compile out the ADMA support instead of relying
   on the platform architecture

  drivers/mmc/Kconfig  |  9 +
  drivers/mmc/omap_hsmmc.c | 12 ++--
  2 files changed, 15 insertions(+), 6 deletions(-)

diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
index f2d8256..88a1359 100644
--- a/drivers/mmc/Kconfig
+++ b/drivers/mmc/Kconfig
@@ -239,6 +239,15 @@ config MMC_OMAP_HS
  
  	  If unsure, say N.
  
+config MMC_OMAP_HS_ADMA

+   bool "ADMA support for OMAP HS MMC"
+   depends on MMC_OMAP_HS && !OMAP34XX
+   default y if !AM33XX

Is this logic really the right restrictions?  Does it work on some
AM33XX platforms (AM43xx?) and just never OMAP34XX?  Thanks!
Starting with platform am33xx there is a way to check if the ADMA 
controller is present or not by reading a register. This register is not 
available in OMAP34XX.
That being said I don't think that ADMA is available on any variant of 
am33xx.


JJ




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

Re: [U-Boot] [PATCH v2 3/4] mmc: omap_hsmmc: make it possible to compile out ADMA support

[Tom Rini]

On Fri, Feb 23, 2018 at 01:47:36PM +0100, Jean-Jacques Hiblot wrote:
> 
> 
> On 23/02/2018 13:21, Tom Rini wrote:
> >On Fri, Feb 23, 2018 at 10:40:18AM +0100, Jean-Jacques Hiblot wrote:
> >>Some platforms don't have ADMA controllers. For those platforms, compiling
> >>it out reduces the size of the binary by about 600 bytes.
> >>Leaving the support in doesn't break things as the driver checks at runtime
> >>if the ADMA2 controller is present.
> >>
> >>Signed-off-by: Jean-Jacques Hiblot 
> >>
> >>---
> >>
> >>Changes in v2:
> >>- Use a Kconfig option to compile out the ADMA support instead of relying
> >>   on the platform architecture
> >>
> >>  drivers/mmc/Kconfig  |  9 +
> >>  drivers/mmc/omap_hsmmc.c | 12 ++--
> >>  2 files changed, 15 insertions(+), 6 deletions(-)
> >>
> >>diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
> >>index f2d8256..88a1359 100644
> >>--- a/drivers/mmc/Kconfig
> >>+++ b/drivers/mmc/Kconfig
> >>@@ -239,6 +239,15 @@ config MMC_OMAP_HS
> >>  If unsure, say N.
> >>+config MMC_OMAP_HS_ADMA
> >>+   bool "ADMA support for OMAP HS MMC"
> >>+   depends on MMC_OMAP_HS && !OMAP34XX
> >>+   default y if !AM33XX
> >Is this logic really the right restrictions?  Does it work on some
> >AM33XX platforms (AM43xx?) and just never OMAP34XX?  Thanks!
> Starting with platform am33xx there is a way to check if the ADMA controller
> is present or not by reading a register. This register is not available in
> OMAP34XX.
> That being said I don't think that ADMA is available on any variant of
> am33xx.

OK, thanks!

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH V5 31/31] imx: add i.MX8MQ EVK support

[Fabio Estevam]

Hi Stefano,

On Fri, Feb 23, 2018 at 6:46 AM, Stefano Babic  wrote:

>> Do you plan to post a new version for the patch that adds the mx8mq evk 
>> support?
>
> Do you mean to get it in 2018.03 ? The merge window is already closed, I
> am checking patches for fixes (if you see I missed something, raise a
> hand as usual...), but without adding new stuff. I do not want to put
> Peng under pressure while I am sure that MX8MQ EVK will be postponed in
> next release.

I was thinking about getting the mx8mq evk support into 2018.05. I
understand we are very close to the release now.

If you have some suggestions on how we can improve the DDR
configuration mechanism for mx8mq, please let us know.

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

Re: [U-Boot] Support of kernels > 16 MiB on Raspberry Pi

[Tom Rini]

On Fri, Feb 23, 2018 at 04:47:06PM +0900, Jaehoon Chung wrote:
> On 02/23/2018 04:58 AM, Alexander Kurtz wrote:
> > Hi!
> > 
> > I am using U-Boot to boot Debian Buster arm64 (standard kernel with a
> > dracut-based initramfs) via an extlinux.conf on my Raspberry Pi 3. 
> > 
> > Recently, the Debian kernel grew beyond 16 MiB:
> > 
> > 4.13: /boot/vmlinuz-4.13.0-1-arm64 == 16448000 bytes (< 16 MiB) [0]
> > 4.14: /boot/vmlinuz-4.14.0-3-arm64 == 17539584 bytes (> 16 MiB) [1]
> > 4.15: /boot/vmlinuz-4.15.0-1-arm64 == 17867264 bytes (> 16 MiB) [2]
> > 
> > https://github.com/u-boot/u-boot/blob/master/include/configs/rpi.h#L129 
> > says:
> > 
> > #define ENV_MEM_LAYOUT_SETTINGS \
> > "fdt_high=\0" \
> > "initrd_high=\0" \
> > "fdt_addr_r=0x0100\0" \
> > "pxefile_addr_r=0x0010\0" \
> > "kernel_addr_r=0x0100\0" \
> > "scriptaddr=0x0200\0" \
> > "ramdisk_addr_r=0x0210\0" \
> > 
> > Am I correct in assuming that this default configuration will break
> > with kernels > 16 MiB? The Readme [3] seems to confirm this, but I
> > wanted to ask for explicit confirmation here.
> 
> Especially, this is occurred about arm64 kernel.
> Because it wil be overlapped with other image address, if kernel image is 
> over than 16MB.
> 
> In my case, i'm using the private boot.scr.img for booting script.
> I had just added the kernel_addr_r=0x02d00.
> 
> Just Refer to below:
> https://review.tizen.org/git/?p=platform/kernel/u-boot.git;a=commit;h=8fdfbbeb8a4b2f8c8e66824709e48d9abdb23534

I would strongly recommend setting the values here based on what
linux/Documentation/arm/Booting and linux/Documentation/arm64/boot.txt
describe as the maximum limits for each of these locations.  And take a
peek at include/configs/ti_armv7_common.h in U-Boot on how I set these
for the various TI platforms.

-- 
Tom


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