Re: [U-Boot] [PATCH v3 3/4] net: phy: Force master mode A20-OLinuXino-Lime2

[Michael Haas]

On 03/26/2016 12:46 AM, Iain Paton wrote:
> On 24/03/16 06:46, Michael Haas wrote:
>> Force master mode on the A20-OLinuXino-Lime2. This change is required
>> to get a reliable link at gigabit speeds.
>>
>> Signed-off-by: Michael Haas 
> Acked-by: Iain Paton 
>
> Glad to see someone finally got to the bottom of this. On the boards I have 
> I only see the problem intermittantly, perhaps 2% of boots so virtually 
> impossible to know if anything fixed it. 
>
> Is something needed in the kernel as well, or is it sufficient to do it in 
> u-boot?
>
> Iain

I have not verified this extensively. In my experience, fixing u-boot is
enough to get a stable link in the kernel.

Michael

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

Re: [U-Boot] [RFC PATCH 2/2] mmc: add support for block device cache

[Eric Nelson]

Hi all,

On 03/21/2016 11:31 AM, Eric Nelson wrote:
> On 03/20/2016 03:54 PM, Eric Nelson wrote:
>> On 03/20/2016 03:13 PM, Tom Rini wrote:
>>> On Sun, Mar 20, 2016 at 12:35:53PM -0700, Eric Nelson wrote:
 On 03/17/2016 02:23 PM, Stephen Warren wrote:
> On 03/16/2016 03:40 PM, Eric Nelson wrote:
>> Signed-off-by: Eric Nelson 
>
...

>> I'm seeing some build breakage on master surrounding the use
>> of DM though.
>>

Peng's patch made it clear that DM wasn't supported by fsl_esdhc.

>> If I select DM and BLK on top of nitrogen6q_defconfig, I get
>> lots of build errors.
>>

It's CONFIG_BLK that produces lots of issues, and from what
I can tell, it's only currently supported for sandbox.

Out of ignorance, I was conflating the two.

>> I want to get a V2 RFC patch out before digging through the
>> details of that.
>>
> 
> I'm obviously not up to speed on the state of DM and I hadn't
> seen Simon's patch adding blk.h.
> 
> The new blk_dread/write/erase functions do provide a convenient
> spot for checking cache, though they're not universally used yet.
> 
> In particular, hooking up the cache there will lose visibility
> into things like the "mmc write" command.
> 
> I'm also not sure of the current state of DM with respect to
> block drivers and wonder if a block cache should wait a cycle
> or two.
> 
> Simon, I'd appreciate some feedback when you have a chance.
> 

I think I have a better handle on this now.

I'm still a bit confused on what needs to be done in order
for CONFIG_BLK to work against real hardware.

>From what I can tell, the some modules in cmd/ need to be
updated to use blk_dread/blk_dwrite/blk_derase and some kind
of re-structuring needs to occur in drivers/mmc to support
the "blk" uclass.

Does that sound about right?

Is somebody currently working on this?

Please advise,


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

Re: [U-Boot] [PATCH v3 3/4] net: phy: Force master mode A20-OLinuXino-Lime2

[Iain Paton]

On 24/03/16 06:46, Michael Haas wrote:
> Force master mode on the A20-OLinuXino-Lime2. This change is required
> to get a reliable link at gigabit speeds.
> 
> Signed-off-by: Michael Haas 

Acked-by: Iain Paton 

Glad to see someone finally got to the bottom of this. On the boards I have 
I only see the problem intermittantly, perhaps 2% of boots so virtually 
impossible to know if anything fixed it. 

Is something needed in the kernel as well, or is it sufficient to do it in 
u-boot?

Iain

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

[U-Boot] Ethernet via USB on Sinlinx SinA33

[Quentin Schulz]

Hi,

I am trying to get Ethernet to work through the USB port of the Sinlinx
SinA33 on U-Boot to use TFTP to get the kernel and dtb files.

However, I am getting 'data abort' when using dhcp or tftp after adding:
#define CONFIG_USB_HOST_ETHER
#define CONFIG_USB_ETHER_ASIX

to include/configs/sunxi-common.h and checking CONFIG_USB_EHCI_HCD as
told in the documentation [1]

I tested this configuration with the C.H.I.P. and it is working well.

Steps to reproduce:

1) Add the following lines to include/configs/sunxi-common.h:

#define CONFIG_USB_HOST_ETHER
#define CONFIG_USB_ETHER_ASIX

2) make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- Sinlinx_SinA33_defconfig
3) make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- menuconfig
4) Check CONFIG_USB_EHCI_HC and save configuration
5) make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- -j$(nproc)
6) Prepare SDCard:
sudo dd if=u-boot-sunxi-with-spl.bin of=/dev/sdX bs=1024 seek=8
7) Boot the board and run dhcp or tftp
8) Get 'data abort' and board gets reset (ethact is also not defined)

The log file is attached.

Thank you,

Quentin

[1] https://github.com/lentinj/u-boot/blob/master/doc/README.usb#L132
U-Boot SPL 2016.01-dirty (Mar 25 2016 - 17:54:10)
DRAM: 1024 MiB
Trying to boot from MMC


U-Boot 2016.01-dirty (Mar 25 2016 - 17:54:10 +0100) Allwinner Technology

CPU:   Allwinner A33 (SUN8I)
DRAM:  1 GiB
MMC:   SUNXI SD/MMC: 0
*** Warning - bad CRC, using default environment

In:serial
Out:   serial
Err:   serial
Net:   No ethernet found.
starting USB...
USB0:   USB EHCI 1.00
USB1:   USB OHCI 1.0
scanning bus 0 for devices... 
Warning: asix_eth MAC addresses don't match:
Address in SROM is 00:80:8e:8a:95:1b
Address in environment is  02:44:08:0d:8d:1a
2 USB Device(s) found
Hit any key to stop autoboot:  0 
=> print ipaddr
## Error: "ipaddr" not defined
=> dhcp
BOOTP broadcast 1
DHCP client bound to address 192.168.1.43 (217 ms)
*** Warning: no boot file name; using 'C0A8012B.img'
Using asix_eth device
TFTP from server 0.0.0.0; our IP address is 192.168.1.43; sending through 
gateway 192.168.1.1
Filename 'C0A8012B.img'.
Load address: 0x4200
Loading: *
TFTP error: 'File not found' (1)
Not retrying...
data abort
pc : [<7ef7be3c>]  lr : [<7efb107c>]
reloc pc : [<4a015e3c>]lr : [<4a04b07c>]
sp : 7af41150  ip : 0d084402 fp : 7af4aa70
r10:   r9 : 7af45ee8 r8 : 000a
r7 :   r6 : 7af57040 r5 : 7af56ff8  r4 : 7efb1084
r3 : 7af56f88  r2 :  r1 : 00b8  r0 : ffc2003d
Flags: NzCv  IRQs off  FIQs off  Mode SVC_32
Resetting CPU ...

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

Re: [U-Boot] [PATCH v2] usb: gadget: Move CONFIG_USB_GADGET to Kconfig

[Tom Rini]

On Fri, Mar 25, 2016 at 04:39:47PM +0200, Semen Protsenko wrote:

> From: Sam Protsenko 
> 
> The description was borrowed from kernel. "tristate" type was changed
> to "bool" (I believe we don't support modules for u-boot yet, right?).
> CONFIG_USB_GADGET requires CONFIG_USB to be defined too, so add it along
> as well.
> 
> Definitions were added to defconfig files in a way that
> "make savedefconfig" generates exactly the same file as used defconfig.
> 
> Signed-off-by: Sam Protsenko 

Applied to u-boot/master, thanks!

Note that I had to fixup zynq_zc702 and I also see:
   arm: (for 510/510 boards)  all +0.1  bss -0.0  rodata +0.1  
spl/u-boot-spl:all +0.1  spl/u-boot-spl:rodata +0.1 
socfpga_sr1500 :  all +27  bss -16  rodata +43  spl/u-boot-spl:all 
+43  spl/u-boot-spl:rodata +43 

But that's it over my whole usual build scheme.

-- 
Tom


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

[U-Boot] Issue with ALLOC_CACHE_ALIGN_BUFFER in env_relocate_spec and

[Vincent]

Hi,
I am having some issue with several instances of
ALLOC_CACHE_ALIGN_BUFFER in (at least):
- common/env_mmc: env_relocate_spec
- disk/part_dos: test_part_dos

U-boot (ls1021atwr) is build in SPL mode, SPL part is in Secure World,
u-boot is in Normal World.
In the SPL part, there is no problem, MMC access are fine. In the
normal world, I experience what I think is stack corruption:

At these locations, calls to the MMC to read partition info mostly
read 0 or garbages. Garbage looks like stack overflow/corruption. For
example, in the first function, checking the CRC of u-boot's env
stored in the MMC fails because the buffer is correct until the last
kb where there is values instead of zeroes, which looks like RAM
addresses and data.

I tried several fix, but I still don't understand what's happening:
- I tried to allocate the buffer where MMC data is read into the head
-> it works fine
- I tried to allocate more room to these buffer on the stack ->
sometimes it works, but not always.

Maybe it's my compiler (NXP's SDK 1.9, based on yocto) which is buggy,
I don't know.
I can provide some custom dump of memory if necessary, but the buffers
at these locations are quite huge I'm afraid.

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

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

[Tom Rini]

On Wed, Mar 23, 2016 at 11:13:55PM +0100, Hans de Goede wrote:

> Hi Tom,
> 
> Here is the first sunxi pull-req for v2016.05, it
> contains:
> 
> -A sync of the sunxi dts files with the kernel
> -Addition of support for 10 new boards
> -Various fixes
> 
> The following changes since commit 0764f24ae6bc937e358990c357f7452b4d5351e3:
> 
>   net: Move CONFIG_RTL8169 to Kconfig (2016-03-22 12:19:53 -0400)
> 
> are available in the git repository at:
> 
>   http://git.denx.de/u-boot-sunxi.git master
> 
> for you to fetch changes up to e449e840c5adf728ddd308501af3115656aa9a60:
> 
>   sunxi: A83T: fix 32bit overflow warning (2016-03-23 22:04:13 +0100)
> 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH] ARM: asm: types: Introduce DMA_ADDR_T_64BIT

[Tom Rini]

On Thu, Mar 24, 2016 at 04:02:00PM +0530, Lokesh Vutla wrote:

> dma_addr_t holds any valid DMA address. If the DMA API only uses 32-bit
> addresses, dma_addr_t need only be 32 bits wide.  Bus addresses, e.g., PCI 
> BARs,
> may be wider than 32 bits, but drivers do memory-mapped I/O to ioremapped
> kernel virtual addresses, so they don't care about the size of the actual
> bus addresses.
> Also 32 bit ARM systems with LPAE enabled can use 64bit address space, but
> DMA still use 32bit address like in case of DRA7 and Keystone platforms.
> 
> This is inspired from the Linux kernel types implementation[1]
> 
> [1] 
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/include/linux/types.h#n142
> 
> Acked-by: Lukasz Majewski 
> Signed-off-by: Lokesh Vutla 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH 2/2] ARM: keystone2: Add missing privilege ID settings

[Tom Rini]

On Wed, Mar 23, 2016 at 10:14:19AM -0500, Nishanth Menon wrote:

> Add missing Privilege ID settings for KS2 SoCs.
> 
> Based on:
> K2H/K: Table 6-7. Privilege ID Settings from SPRS866E (Nov 2013)
>   http://www.ti.com/lit/ds/symlink/66ak2h14.pdf (page 99)
> K2L: Table 7-7. Privilege ID Settings from SPRS930 (April 2015)
>   http://www.ti.com/lit/ds/symlink/66ak2l06.pdf (page 71)
> K2E: Table 7-7. Privilege ID Settings from SPRS865D (Mar 2015)
>   http://www.ti.com/lit/ds/symlink/66ak2e05.pdf (page 75)
> K2G: Table 3-16. PrivIDs from SPRUHY8 (Jan 2016)
>   http://www.ti.com/lit/ug/spruhy8/spruhy8.pdf (page 238)
> 
> Overall mapping:

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH 1/2] ARM: keystone2: Refactor MSMC macros to avoid #ifdeffery

[Tom Rini]

On Wed, Mar 23, 2016 at 10:14:18AM -0500, Nishanth Menon wrote:

> MSMC segment Privilege ID is not consistent accross the keystone2 SoCs.
> As the first step to ensure complete SoC wide coherency setup, lets
> refactor the macros to remove the #if-deffery around the code which
> obfuscates which IDs are actually enabled for which SoC.
> 
> As a result of this change the PCIe configuration is moved after the
> msmc configuration is complete, but that should ideally have no
> functional impact.
> 
> Signed-off-by: Nishanth Menon 

Reviewed-by: Tom Rini 

-- 
Tom


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

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

[Tom Rini]

On Thu, Mar 24, 2016 at 11:09:19AM +0100, Stefan Roese wrote:

> Hi Tom,
> 
> please pull the following patches from the marvell git
> repository. I plan to send some other patches still under
> review a bit later - perhaps in a week or. As I'm off in
> Easter vacation starting tomorrow.
> 
> Thanks,
> Stefan
> 
> The following changes since commit d085ecd61b9956cda0d37b89b5c538f54440fe58:
> 
>   ARM: uniphier: switch to raw U-Boot image (2016-03-24 01:45:41 +0900)
> 
> are available in the git repository at:
> 
>   git://www.denx.de/git/u-boot-marvell.git 
> 
> for you to fetch changes up to 7497a6a1f13eb86d68a936edecfd682bbad5752d:
> 
>   tools: kwboot: Add xmodem timeout option (2016-03-24 10:08:49 +0100)
> 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH V2 3/5] rpi: add Raspberry Pi 3 board ID

[Tom Rini]

On Thu, Mar 24, 2016 at 10:15:18PM -0600, Stephen Warren wrote:

> This allows U-Boot to known the name of the board.
> 
> The existing rpi_2_defconfig can operate correctly on the Raspberry Pi 3
> in 32-bit mode /if/ you have configured the firmware to use the PL011 UART
> as the console UART (the default is the mini UART). This requires two
> things:
> a) config.txt should contain dtoverlay=pi3-miniuart-bt
> b) You should run the following to tell the VC FW to process DT when
> booting, and copy u-boot.bin.img (rather than u-boot.bin) to the SD card
> as the kernel image:
> 
>path/to/kernel/scripts/mkknlimg --dtok u-boot.bin u-boot.bin.img
> 
> This works as of firmware.git commit 046effa13ebc "firmware: arm_loader:
> emmc clock depends on core clock See:
> https://github.com/raspberrypi/firmware/issues/572;.
> 
> Signed-off-by: Stephen Warren 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH V2 5/5] rpi: BCM2837 and Raspberry Pi 3 32-bit support

[Tom Rini]

On Thu, Mar 24, 2016 at 10:15:20PM -0600, Stephen Warren wrote:

> The Raspberry Pi 3 contains a BCM2837 SoC. The BCM2837 is a BCM2836 with
> the CPU complex swapped out for a quad-core ARMv8. This can operate in 32-
> or 64-bit mode. 32-bit mode is the current default selected by the
> VideoCore firmware on the Raspberry Pi 3. This patch adds a 32-bit port of
> U-Boot for the Raspberry Pi 3.
> 
> From U-Boot's perspective, the only delta between the RPi 2 and RPi 3 is a
> change in usage of the SoC UARTs. On all previous Pis, the PL011 was the
> only UART in use. The Raspberry Pi 3 adds a Bluetooth module which uses a
> UART to connect to the SoC. By default, the PL011 is used for this purpose
> since it has larger FIFOs than the other "mini" UART. However, this can
> be configured via the VideoCore firmware's config.txt file. This patch
> hard-codes use of the mini UART in the RPi 3 port. If your system uses the
> PL011 UART for the console even on the RPi 3, please use the RPi 2 U-Boot
> port instead. A future change might determine which UART to use at
> run-time, thus allowing the RPi 2 and RPi 3 (32-bit) ports to be squashed
> together.
> 
> The mini UART has some limitations. One externally visible issue in the
> BCM2837 integration is that the UART divides the SoC's "core clock" to
> generate the baud rate. The core clock is typically variable, and under
> control of the VideoCore firmware for thermal management reasons. If the
> VC FW does modify the core clock rate, UART communication will be
> corrupted since the baud rate will vary from the expected value. This was
> not an issue for the PL011 UART, since it is fed by a fixed 3MHz clock. To
> work around this, the VideoCore firmware can be told not to modify the SoC
> core clock. However, the only way this can happen and be thermally safe is
> to limit the core clock to a low/minimum frequency. This leaves
> performance on the table for use-cases that don't care about a UART
> console. Consequently, use of the mini UART console must be explicitly
> requested by entering the following line into config.txt:
> 
> enable_uart=1
> 
> A recent version of the VC firmware is required to ensure that the mini
> UART is fully and correctly initialized by the VC FW; at least
> firmware.git 046effa13ebc "firmware: arm_loader: emmc clock depends on
> core clock See: https://github.com/raspberrypi/firmware/issues/572;.
> 
> Signed-off-by: Stephen Warren 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH V2 4/5] ARM: bcm2835: expand Kconfig target descriptions

[Tom Rini]

On Thu, Mar 24, 2016 at 10:15:19PM -0600, Stephen Warren wrote:

> This adds an explanation of which Raspberry Pi models each target option
> supports.
> 
> Signed-off-by: Stephen Warren 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH V2 2/5] rpi: use constant "unknown board" DT filename

[Tom Rini]

On Thu, Mar 24, 2016 at 10:15:17PM -0600, Stephen Warren wrote:

> To simplify support for new SoCs, just use a constant filename
> for the unknown case. In practice this case shouldn't be hit anyway, so
> the filename isn't relevant, and certainly doesn't need to differentiate
> between SoCs. If a user has an as-yet-unknown board, they can override
> this value in the environment anyway.
> 
> Signed-off-by: Stephen Warren 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH V2 1/5] ARM: bcm2835: move CONFIG_BCM283* to Kconfig

[Tom Rini]

On Thu, Mar 24, 2016 at 10:15:16PM -0600, Stephen Warren wrote:

> Signed-off-by: Stephen Warren 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH] powerpc: t1040qds: Use generic ethsw commands

[Joe Hershberger]

On Mon, Mar 14, 2016 at 6:46 AM, Codrin Ciubotariu
 wrote:
> The commands for the VSC9953 l2 switch from T1040 became generic in
> patch https://patchwork.ozlabs.org/patch/499748/ and the define
> was renamed.
>
> Signed-off-by: Codrin Ciubotariu 

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

Re: [U-Boot] [PATCH] drivers: net: vsc9953: Do not configure disabled ports

[Joe Hershberger]

On Mon, Mar 14, 2016 at 6:46 AM, Codrin Ciubotariu
 wrote:
> Some SerDes protocols might not enable all l2switch ports. In this case,
> these ports should not be configured to perform Rx/Tx operations.
> This also fixes an issue when flooded frames were also switched to
> disabled ports and frames start to accumulate, consuming memory
> and eventually causing head-of-line blocking for other frames.
>
> Signed-off-by: Codrin Ciubotariu 

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

Re: [U-Boot] [PATCH v3 09/21] eth: asix88179: Print packet length properly

[Joe Hershberger]

On Sun, Mar 13, 2016 at 4:36 PM, Mateusz Kulikowski
 wrote:
> Debug printf used '%u' to print size_t variable.
> This caused warnings on 64-bit machines.
>
> Signed-off-by: Mateusz Kulikowski 

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

Re: [U-Boot] [PATCH] drivers: net: vsc9953: Fix bug when PVID is shown for disabled ports only

[Joe Hershberger]

On Mon, Mar 14, 2016 at 6:46 AM, Codrin Ciubotariu
 wrote:
> Signed-off-by: Codrin Ciubotariu 

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

Re: [U-Boot] [PATCH] net: rtl8169: Fix build error when DEBUG is on

[Joe Hershberger]

On Fri, Mar 18, 2016 at 1:27 AM, Bin Meng  wrote:
> When DEBUG_RTL8169 is on, a build error occurs in function
> 'rtl_init': error: 'dev' undeclared. Fix this.
>
> Signed-off-by: Bin Meng 

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

Re: [U-Boot] [PATCH 2/4] driver: net: fsl-mc: Check NULL before pointer dereference

[Joe Hershberger]

On Fri, Mar 18, 2016 at 5:45 AM, Prabhakar Kushwaha
 wrote:
> NULL pointer should be checked before any dereference.  This patch
> move memest after the NULL pointer check.
>
> Signed-off-by: Prabhakar Kushwaha 
> Reported-by: Jose Rivera 

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

Re: [U-Boot] [PATCH] driver: net: fsl-mc: Free dflt_dpio pointer after its usage

[Joe Hershberger]

On Fri, Mar 18, 2016 at 5:45 AM, Prabhakar Kushwaha
 wrote:
> Free dflt_dpio pointer after its usage during error handling
>
> Signed-off-by: Prabhakar Kushwaha 
> Reported-by: Jose Rivera 

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

Re: [U-Boot] [PATCH v3 3/4] net: phy: Force master mode A20-OLinuXino-Lime2

[Joe Hershberger]

On Thu, Mar 24, 2016 at 1:46 AM, Michael Haas  wrote:
> Force master mode on the A20-OLinuXino-Lime2. This change is required
> to get a reliable link at gigabit speeds.
>
> Signed-off-by: Michael Haas 

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

Re: [U-Boot] [PATCH v3 2/4] net: phy: Force master mode for A20-Olimex-SOM-EVB

[Joe Hershberger]

On Thu, Mar 24, 2016 at 1:46 AM, Michael Haas  wrote:
> Force master mode for 1000BASE-T operation on the
> A20-Olimex-SOM-EVB.
>
> Karsten Merker reports that this change is necessary to get a reliable
> link at gigabit speeds.
>
> Signed-off-by: Michael Haas 

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

Re: [U-Boot] [PATCH v5 1/3] net: phy: Optionally force master mode for RTL PHY

[Joe Hershberger]

On Fri, Mar 25, 2016 at 12:22 PM, Michael Haas
 wrote:
> This patch introduces CONFIG_RTL8211X_PHY_FORCE_MASTER. If this
> define is set, RTL8211x PHYs (except for the RTL8211F) will have their
> 1000BASE-T master/slave autonegotiation disabled and forced to master
> mode.
>
> This is helpful for PHYs like the RTL8211C which produce unstable links
> in slave mode. Such problems have been found on the A20-Olimex-SOM-EVB
> and A20-OLinuXino-Lime2.
>
> There is no proper way to identify affected PHYs in software as the
> RTL8211C shares its UID with the RTL8211B. Thus, this fix requires
> the introduction of an #ifdef.
>
> CC: fra...@gmail.com
> CC: mer...@debian.org
> CC: hdego...@redhat.com
> CC: i...@hellion.org.uk
> CC: joe.hershber...@ni.com
>
> Signed-off-by: Michael Haas 
> Tested-by: Karsten Merker 

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

Re: [U-Boot] [PATCH 2/6 v3] net: mvpp2.c: Add Marvell mvpp2 network driver for Armada 375

[Joe Hershberger]

Hi Stefan,

On Wed, Mar 23, 2016 at 2:21 AM, Stefan Roese  wrote:
> This patch adds support for the mvpp2 ethernet controller which is integrated
> in the Marvell Armada 375 SoC. This port is based on the Linux driver (v4.4),
> which has been stripped of the in U-Boot unused portions.
>
> Tested on the Marvell Armada 375 eval board db-88f6720.
>
> Signed-off-by: Stefan Roese 
> Cc: Luka Perkov 
> Cc: Joe Hershberger 

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

Re: [U-Boot] [PATCH 2/6] net: mvpp2.c: Add Marvell mvpp2 network driver for Armada 375

[Joe Hershberger]

Hi Stefan,

On Wed, Mar 23, 2016 at 1:39 AM, Stefan Roese  wrote:
> Hi Joe,
>
> On 22.03.2016 20:10, Joe Hershberger wrote:
>>
>> Sorry for the delay.
>
>
> No problem. Thanks for the review.
>
>
>> On Tue, Mar 15, 2016 at 11:35 AM, Stefan Roese  wrote:
>>>
>>> This patch adds support for the mvpp2 ethernet controller which is
>>> integrated
>>> in the Marvell Armada 375 SoC. This port is based on the Linux driver
>>> (v4.4),
>>> which has been stripped of the in U-Boot unused portions.
>>>
>>> Tested on the Marvell Armada 375 eval board db-88f6720.
>>>
>>> Signed-off-by: Stefan Roese 
>>> Cc: Luka Perkov 
>>> Cc: Joe Hershberger 
>>> ---
>>>   drivers/net/Kconfig  |8 +
>>>   drivers/net/Makefile |1 +
>>>   drivers/net/mvpp2.c  | 4222
>>> ++
>>>   3 files changed, 4231 insertions(+)
>>>   create mode 100644 drivers/net/mvpp2.c
>>>
>>> diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
>>> index bc2f51d..bcb4c96 100644
>>> --- a/drivers/net/Kconfig
>>> +++ b/drivers/net/Kconfig
>>> @@ -94,6 +94,14 @@ config ETH_DESIGNWARE
>>>100Mbit and 1 Gbit operation. You must enable CONFIG_PHYLIB to
>>>provide the PHY (physical media interface).
>>>
>>> +config MVPP2
>>> +   bool "Marvell Armada 375 network interface support"
>>> +   depends on ARMADA_375
>>> +   select PHYLIB
>>> +   help
>>> + This driver supports the network interface units in the
>>> + Marvell ARMADA 375 SoC.
>>> +
>>>   config PCH_GBE
>>>  bool "Intel Platform Controller Hub EG20T GMAC driver"
>>>  depends on DM_ETH && DM_PCI
>>> diff --git a/drivers/net/Makefile b/drivers/net/Makefile
>>> index 33a81ee..fbedd04 100644
>>> --- a/drivers/net/Makefile
>>> +++ b/drivers/net/Makefile
>>> @@ -42,6 +42,7 @@ obj-$(CONFIG_MPC5xxx_FEC) += mpc5xxx_fec.o
>>>   obj-$(CONFIG_MPC512x_FEC) += mpc512x_fec.o
>>>   obj-$(CONFIG_MVGBE) += mvgbe.o
>>>   obj-$(CONFIG_MVNETA) += mvneta.o
>>> +obj-$(CONFIG_MVPP2) += mvpp2.o
>>>   obj-$(CONFIG_NATSEMI) += natsemi.o
>>>   obj-$(CONFIG_DRIVER_NE2000) += ne2000.o ne2000_base.o
>>>   obj-$(CONFIG_DRIVER_AX88796L) += ax88796.o ne2000_base.o
>>> diff --git a/drivers/net/mvpp2.c b/drivers/net/mvpp2.c
>>> new file mode 100644
>>> index 000..09dfc7e
>>> --- /dev/null
>>> +++ b/drivers/net/mvpp2.c
>>> @@ -0,0 +1,4222 @@
>>> +/*
>>> + * Driver for Marvell PPv2 network controller for Armada 375 SoC.
>>> + *
>>> + * Copyright (C) 2014 Marvell
>>> + *
>>> + * Marcin Wojtas 
>>> + *
>>> + * U-Boot version:
>>> + * Copyright (C) 2016 Stefan Roese 
>>> + *
>>> + * This file is licensed under the terms of the GNU General Public
>>> + * License version 2. This program is licensed "as is" without any
>>> + * warranty of any kind, whether express or implied.
>>> + */
>>> +
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +
>>> +DECLARE_GLOBAL_DATA_PTR;
>>> +
>>> +#if !defined(CONFIG_PHYLIB)
>>> +# error Marvell mvpp2 requires PHYLIB
>>> +#endif
>>
>>
>> This isn't needed since you "select" PHYLIB in the Kconfig.
>
>
> Good catch. Removed in v2.
>
>>> +
>>> +/* Some linux -> U-Boot compatibility stuff */
>>> +#define netdev_err(dev, fmt, args...)  \
>>> +   printf(fmt, ##args)
>>> +#define netdev_warn(dev, fmt, args...) \
>>> +   printf(fmt, ##args)
>>> +#define netdev_info(dev, fmt, args...) \
>>> +   printf(fmt, ##args)
>>> +#define netdev_dbg(dev, fmt, args...)  \
>>> +   printf(fmt, ##args)
>>> +
>>> +#define ETH_ALEN   6   /* Octets in one ethernet addr
>>> */
>>> +
>>> +#define ETH_P_IP   0x0800  /* Internet Protocol packet
>>> */
>>
>>
>> Already available in include/net.h as PROT_IP
>>
>>> +#define ETH_P_PPP_SES  0x8864  /* PPPoE session messages
>>> */
>>
>>
>> Add this to include/net.h as PROT_PPP_SES
>>
>>> +#define ETH_P_ARP  0x0806  /* Address Resolution packet
>>> */
>>
>>
>> Already available in include/net.h as PROT_ARP
>>
>>> +#define ETH_P_IPV6 0x86DD  /* IPv6 over bluebook
>>> */
>>
>>
>> Add this to include/net.h as PROT_IPV6
>
>
> Changed to use these U-Boot defines instead. Thanks.
>
> Does it perhaps make sense to globally change all those U-Boot defines
> to the Linux ones instead?

That sounds like a good idea to me.

>>> +
>>> +#define __verify_pcpu_ptr(ptr) \
>>> +do {   \
>>> +   const void __percpu *__vpp_verify = (typeof((ptr) + 0))NULL;\
>>> +   (void)__vpp_verify; \
>>> +} while (0)

Re: [U-Boot] [PATCH V3] fsl: esdhc: support driver model

[Eric Nelson]

Hi Peng,

On 03/24/2016 11:16 PM, Peng Fan wrote:
> Support Driver Model for fsl esdhc driver.
> 
> 1. Introduce a new structure struct fsl_esdhc_priv
> 2. Refactor fsl_esdhc_initialize which is originally used by board code.
>- Introduce fsl_esdhc_init to be common usage for DM and non-DM
>- Introduce fsl_esdhc_cfg_to_priv to build the bridge for non-DM part.
>- The original API for board code is still there, but we use
>  'fsl_esdhc_cfg_to_priv' and 'fsl_esdhc_init' to serve it.
> 3. All the functions are changed to use 'struct fsl_esdhc_priv', except
>fsl_esdhc_initialize.
> 4. Since clk driver is not implemented, use mxc_get_clock to geth
>the clk and fill 'priv->sdhc_clk'.
> 
> Has been tested on i.MX6UL 14X14 EVK board:
> "
> =>dm tree
> 
>  simple_bus  [ + ]|   `-- aips-bus@0210
>   mmc[ + ]|   |-- usdhc@0219
>   mmc[ + ]|   |-- usdhc@02194000
> 
> => mmc list
> FSL_SDHC: 0 (SD) 
> FSL_SDHC: 1 (SD)
> "
> 

After pulling in device tree files from the mainline kernel, I was able
to test this on a SABRE Lite, so you can add my:

Tested-By: Eric Nelson 

Is somebody prepping patches to pull in support for i.MX6DQ?

Please advise,


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

[U-Boot] [PATCH] dm: gpio: handle GPIO_ACTIVE_LOW flag in DT

[Eric Nelson]

Device tree parsing of GPIO nodes is currently ignoring flags.

Add support for GPIO_ACTIVE_LOW by checking for the presence
of the flag and setting the desc->flags field to the driver
model constant GPIOD_ACTIVE_LOW.

Signed-off-by: Eric Nelson 
---
 drivers/gpio/gpio-uclass.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/gpio/gpio-uclass.c b/drivers/gpio/gpio-uclass.c
index b58d4e6..6d30612 100644
--- a/drivers/gpio/gpio-uclass.c
+++ b/drivers/gpio/gpio-uclass.c
@@ -6,6 +6,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -118,12 +119,16 @@ static int gpio_find_and_xlate(struct gpio_desc *desc,
 {
struct dm_gpio_ops *ops = gpio_get_ops(desc->dev);
 
+   desc->flags = 0;
/* Use the first argument as the offset by default */
-   if (args->args_count > 0)
+   if (args->args_count > 0) {
desc->offset = args->args[0];
+   if ((args->args_count > 1) &&
+   (args->args[1] & GPIO_ACTIVE_LOW))
+   desc->flags = GPIOD_ACTIVE_LOW;
+   }
else
desc->offset = -1;
-   desc->flags = 0;
 
return ops->xlate ? ops->xlate(desc->dev, desc, args) : 0;
 }
-- 
2.6.2

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

[U-Boot] [PATCH v5 2/3] sunxi: A20-Olimex-SOM-EVB: Force 8211CL to master

[Michael Haas]

Force master mode for 1000BASE-T operation on the
A20-Olimex-SOM-EVB.

Karsten Merker reports that this change is necessary to get a reliable
link at gigabit speeds.

Signed-off-by: Michael Haas 

---

Changes in v5:
 - Fix order of defconfig entry (suggested by Karsten Marker)
Series-changes: 4
 - Changed commit summary according to Chen-Yu Tsai's suggestion,
   modified to fit the 70 character limit

Changes in v4: None
Changes in v3: None
Changes in v2: None

 configs/A20-Olimex-SOM-EVB_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/A20-Olimex-SOM-EVB_defconfig 
b/configs/A20-Olimex-SOM-EVB_defconfig
index 66d8f98..bcfbf9c 100644
--- a/configs/A20-Olimex-SOM-EVB_defconfig
+++ b/configs/A20-Olimex-SOM-EVB_defconfig
@@ -17,5 +17,6 @@ 
CONFIG_SYS_EXTRA_OPTIONS="SUNXI_GMAC,RGMII,AHCI,SATAPWR=SUNXI_GPC(3)"
 # CONFIG_CMD_FLASH is not set
 # CONFIG_CMD_FPGA is not set
 CONFIG_CMD_GPIO=y
+CONFIG_RTL8211X_PHY_FORCE_MASTER=y
 CONFIG_ETH_DESIGNWARE=y
 CONFIG_USB_EHCI_HCD=y
-- 
2.7.2

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

[U-Boot] [PATCH v5 1/3] net: phy: Optionally force master mode for RTL PHY

[Michael Haas]

This patch introduces CONFIG_RTL8211X_PHY_FORCE_MASTER. If this
define is set, RTL8211x PHYs (except for the RTL8211F) will have their
1000BASE-T master/slave autonegotiation disabled and forced to master
mode.

This is helpful for PHYs like the RTL8211C which produce unstable links
in slave mode. Such problems have been found on the A20-Olimex-SOM-EVB
and A20-OLinuXino-Lime2.

There is no proper way to identify affected PHYs in software as the
RTL8211C shares its UID with the RTL8211B. Thus, this fix requires
the introduction of an #ifdef.

CC: fra...@gmail.com
CC: mer...@debian.org
CC: hdego...@redhat.com
CC: i...@hellion.org.uk
CC: joe.hershber...@ni.com

Signed-off-by: Michael Haas 
Tested-by: Karsten Merker 

---

Changes in v5:
 - Improve formatting of Kconfig help text. No content change. Change
   suggested by Karsten Merker.

Changes in v4:
 - Squashed previously separate commit introducing KCONFIG variable
   into commit containing main code change (Hans de Goede's suggestion)
 - Changed KCONFIG description according to Karsten Merker's suggestions
   plus some clarification of my own
 - Changed commit message according to Karsten Merker's suggestions

Changes in v3:
 - Remove incorrect detection of RTL8211CL and use #ifdef instead
   (thanks to Karsten Merker)
 - Introduced constants for register bits

Changes in v2:
 - Removed accidental inclusion of Karsten's patch in my first submission of 
this series.
 - Fix a typo in the code: 6 -> &

 drivers/net/Kconfig   | 21 +
 drivers/net/phy/realtek.c | 13 -
 2 files changed, 33 insertions(+), 1 deletion(-)

diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 2a229b8..e0008fd 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -13,6 +13,27 @@ config PHYLIB
help
  Enable Ethernet PHY (physical media interface) support.
 
+config RTL8211X_PHY_FORCE_MASTER
+   bool "Ethernet PHY RTL8211x: force 1000BASE-T master mode"
+   depends on PHYLIB
+   help
+ Force master mode for 1000BASE-T on RTl8211x PHYs (except for 
RTL8211F).
+ This can work around link stability and data corruption issues on 
gigabit
+ links which can occur in slave mode on certain PHYs, e.g. on the
+ RTL8211C(L).
+
+ Please note that two directly connected devices (i.e. via crossover 
cable)
+ will not be able to establish a link between each other if they both 
force
+ master mode. Multiple devices forcing master mode when connected by a
+ network switch do not pose a problem as the switch configures its 
affected
+ ports into slave mode.
+
+ This option only affects gigabit links. If you must establish a direct
+ connection between two devices which both force master mode, try 
forcing
+ the link speed to 100MBit/s.
+
+ If unsure, say N.
+
 menuconfig NETDEVICES
bool "Network device support"
depends on NET
diff --git a/drivers/net/phy/realtek.c b/drivers/net/phy/realtek.c
index 259a87f..359ec50 100644
--- a/drivers/net/phy/realtek.c
+++ b/drivers/net/phy/realtek.c
@@ -12,6 +12,10 @@
 
 #define PHY_AUTONEGOTIATE_TIMEOUT 5000
 
+/* RTL8211x 1000BASE-T Control Register */
+#define MIIM_RTL8211x_CTRL1000T_MSCE (1 << 12);
+#define MIIM_RTL8211X_CTRL1000T_MASTER (1 << 11);
+
 /* RTL8211x PHY Status Register */
 #define MIIM_RTL8211x_PHY_STATUS   0x11
 #define MIIM_RTL8211x_PHYSTAT_SPEED0xc000
@@ -53,7 +57,14 @@ static int rtl8211x_config(struct phy_device *phydev)
 */
phy_write(phydev, MDIO_DEVAD_NONE, MIIM_RTL8211x_PHY_INER,
  MIIM_RTL8211x_PHY_INTR_DIS);
-
+#ifdef CONFIG_RTL8211X_PHY_FORCE_MASTER
+   unsigned int reg = phy_read(phydev, MDIO_DEVAD_NONE, MII_CTRL1000);
+   /* force manual master/slave configuration */
+   reg |= MIIM_RTL8211x_CTRL1000T_MSCE;
+   /* force master mode */
+   reg |= MIIM_RTL8211X_CTRL1000T_MASTER;
+   phy_write(phydev, MDIO_DEVAD_NONE, MII_CTRL1000, reg);
+#endif
/* read interrupt status just to clear it */
phy_read(phydev, MDIO_DEVAD_NONE, MIIM_RTL8211x_PHY_INER);
 
-- 
2.7.2

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

[U-Boot] [PATCH v5 3/3] sunxi: A20-OLinuXino-Lime2: Force 8211CL to master

[Michael Haas]

Force master mode on the A20-OLinuXino-Lime2. This change is required
to get a reliable link at gigabit speeds.

Signed-off-by: Michael Haas 

---

Changes in v5:
 - Fix order of defconfig entry (suggested by Karsten Marker)

Changes in v4:
 - Changed commit summary according to Chen-Yu Tsai's suggestion,
   modified to fit the 70 character limit

Changes in v3: None
Changes in v2: None

 configs/A20-OLinuXino-Lime2_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/A20-OLinuXino-Lime2_defconfig 
b/configs/A20-OLinuXino-Lime2_defconfig
index 95c67d6..1de503a 100644
--- a/configs/A20-OLinuXino-Lime2_defconfig
+++ b/configs/A20-OLinuXino-Lime2_defconfig
@@ -14,5 +14,6 @@ 
CONFIG_SYS_EXTRA_OPTIONS="SUNXI_GMAC,RGMII,AHCI,SATAPWR=SUNXI_GPC(3)"
 # CONFIG_CMD_FLASH is not set
 # CONFIG_CMD_FPGA is not set
 CONFIG_CMD_GPIO=y
+CONFIG_RTL8211X_PHY_FORCE_MASTER=y
 CONFIG_ETH_DESIGNWARE=y
 CONFIG_USB_EHCI_HCD=y
-- 
2.7.2

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

[U-Boot] [PATCH v5 0/3] net: phy: Force master mode for RTL8211C on some boards

[Michael Haas]

This patch is required to get reliable 1000BASE-T operation on some
boards using the RTL8211C(L) PHY.

Following discussions on v2 of this patch, I have removed the incorrect
check for the RTL8211C(L). Affected boards now have to define
CONFIG_RTL8211X_PHY_FORCE_MASTER to benefit from the fix.

Note that this patch requires Karsten Merkers '[PATCH] net: phy: Realtek
RTL8211B/C PHY ID fix' as well as Hans de Goede's recent u-boot-sunxi
pull request, specifically 1eae8f66ff749409eb96e2f3f3387c56232d0b8a and
fc8991c61c393ce6a9d3dfc97cb56dbbd9e8cbba.

Michael


Changes in v5:
 - Improve formatting of Kconfig help text. No content change. Change
   suggested by Karsten Merker.
 - Fix order of defconfig entry (suggested by Karsten Marker)
Series-changes: 4
 - Changed commit summary according to Chen-Yu Tsai's suggestion,
   modified to fit the 70 character limit
 - Fix order of defconfig entry (suggested by Karsten Marker)

Changes in v4:
 - Squashed previously separate commit introducing KCONFIG variable
   into commit containing main code change (Hans de Goede's suggestion)
 - Changed KCONFIG description according to Karsten Merker's suggestions
   plus some clarification of my own
 - Changed commit message according to Karsten Merker's suggestions
 - Changed commit summary according to Chen-Yu Tsai's suggestion,
   modified to fit the 70 character limit

Changes in v3:
 - Remove incorrect detection of RTL8211CL and use #ifdef instead
   (thanks to Karsten Merker)
 - Introduced constants for register bits

Changes in v2:
 - Removed accidental inclusion of Karsten's patch in my first submission of 
this series.
 - Fix a typo in the code: 6 -> &

Michael Haas (3):
  net: phy: Optionally force master mode for RTL PHY
  sunxi: A20-Olimex-SOM-EVB: Force 8211CL to master
  sunxi: A20-OLinuXino-Lime2: Force 8211CL to master

 configs/A20-OLinuXino-Lime2_defconfig |  1 +
 configs/A20-Olimex-SOM-EVB_defconfig  |  1 +
 drivers/net/Kconfig   | 21 +
 drivers/net/phy/realtek.c | 13 -
 4 files changed, 35 insertions(+), 1 deletion(-)

-- 
2.7.2

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

Re: [U-Boot] Variable content dump to memory

[James Chargin]

Dear Nicolae,

On 03/25/2016 02:12 AM, Nicolae Rosia wrote:

On Thu, Mar 24, 2016 at 7:51 PM, James Chargin  wrote:
[...]

You weren't completely specific about your needs, but assuming you are wanting 
to write a U-Boot environment variable to memory, try something like


You're right.
I'm trying to do the following:
U-Boot# setenv mytext 'This is a long text'
U-Boot# printenv mytext
mytext=This is a long text
and somehow write it to a memory address so I can use it with ext4write.


I don't have a solution to your needs, unfortunately. I thought my 
solution might be for a problem more simple than you were asking about.


Perhaps someone else on the mailing list has an idea.

Jim



Best regards,
Nicolae



--
Jim Chargin
AJA Video Systems   j...@aja.com
(530) 271-3334  http://www.aja.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2] usb: gadget: Move CONFIG_USB_GADGET to Kconfig

[Semen Protsenko]

From: Sam Protsenko 

The description was borrowed from kernel. "tristate" type was changed
to "bool" (I believe we don't support modules for u-boot yet, right?).
CONFIG_USB_GADGET requires CONFIG_USB to be defined too, so add it along
as well.

Definitions were added to defconfig files in a way that
"make savedefconfig" generates exactly the same file as used defconfig.

Signed-off-by: Sam Protsenko 
---
 configs/A13-OLinuXino_defconfig  |  1 +
 configs/CHIP_defconfig   |  1 +
 configs/Cubietruck_defconfig |  1 +
 configs/am335x_baltos_defconfig  |  2 ++
 configs/am335x_boneblack_defconfig   |  2 ++
 configs/am335x_boneblack_vboot_defconfig |  2 ++
 configs/am335x_evm_defconfig |  2 ++
 configs/am335x_evm_nor_defconfig |  2 ++
 configs/am335x_evm_norboot_defconfig |  2 ++
 configs/am335x_evm_spiboot_defconfig |  2 ++
 configs/am335x_evm_usbspl_defconfig  |  2 ++
 configs/am335x_gp_evm_defconfig  |  2 ++
 configs/am437x_gp_evm_defconfig  |  2 ++
 configs/am437x_sk_evm_defconfig  |  2 ++
 configs/am43xx_evm_defconfig |  2 ++
 configs/am43xx_evm_ethboot_defconfig |  2 ++
 configs/am43xx_evm_qspiboot_defconfig|  2 ++
 configs/am43xx_evm_usbhost_boot_defconfig|  2 ++
 configs/apalis_t30_defconfig |  1 +
 configs/bcm11130_defconfig   |  2 ++
 configs/bcm11130_nand_defconfig  |  2 ++
 configs/bcm28155_ap_defconfig|  2 ++
 configs/bcm28155_w1d_defconfig   |  2 ++
 configs/beaver_defconfig |  1 +
 configs/birdland_bav335a_defconfig   |  2 ++
 configs/birdland_bav335b_defconfig   |  2 ++
 configs/cgtqmx6eval_defconfig|  2 ++
 configs/colibri_t20_defconfig|  1 +
 configs/colibri_t30_defconfig|  1 +
 configs/colibri_vf_defconfig |  2 ++
 configs/corvus_defconfig |  2 ++
 configs/dalmore_defconfig|  1 +
 configs/dra72_evm_defconfig  |  2 ++
 configs/dra74_evm_defconfig  |  2 ++
 configs/dra7xx_evm_defconfig |  2 ++
 configs/dra7xx_evm_qspiboot_defconfig|  2 ++
 configs/dra7xx_evm_uart3_defconfig   |  2 ++
 configs/draco_defconfig  |  2 ++
 configs/e2220-1170_defconfig |  1 +
 configs/gwventana_defconfig  |  2 ++
 configs/jetson-tk1_defconfig |  1 +
 configs/kc1_defconfig|  1 +
 configs/ma5d4evk_defconfig   |  2 ++
 configs/mx6dlsabreauto_defconfig |  2 ++
 configs/mx6dlsabresd_defconfig   |  2 ++
 configs/mx6qpsabreauto_defconfig |  2 ++
 configs/mx6qsabreauto_defconfig  |  2 ++
 configs/mx6qsabrelite_defconfig  |  2 ++
 configs/mx6qsabresd_defconfig|  2 ++
 configs/mx6sabresd_spl_defconfig |  2 ++
 configs/mx7dsabresd_defconfig|  2 ++
 configs/nitrogen6dl2g_defconfig  |  2 ++
 configs/nitrogen6dl_defconfig|  2 ++
 configs/nitrogen6q2g_defconfig   |  2 ++
 configs/nitrogen6q_defconfig |  2 ++
 configs/nitrogen6s1g_defconfig   |  2 ++
 configs/nitrogen6s_defconfig |  2 ++
 configs/nyan-big_defconfig   |  1 +
 configs/odroid-xu3_defconfig |  1 +
 configs/odroid_defconfig |  1 +
 configs/omap3_beagle_defconfig   |  2 ++
 configs/omap3_logic_defconfig|  2 ++
 configs/omap5_uevm_defconfig |  2 ++
 configs/origen_defconfig |  1 +
 configs/p2371-_defconfig |  1 +
 configs/p2371-2180_defconfig |  1 +
 configs/p2571_defconfig  |  1 +
 configs/pengwyn_defconfig|  2 ++
 configs/pxm2_defconfig   |  2 ++
 configs/rastaban_defconfig   |  2 ++
 configs/rut_defconfig|  2 ++
 configs/s5p_goni_defconfig   |  2 ++
 configs/s5pc210_universal_defconfig  |  1 +
 configs/sama5d2_xplained_mmc_defconfig   |  2 ++
 configs/sama5d2_xplained_spiflash_defconfig  |  2 ++
 configs/sama5d3xek_mmc_defconfig |  2 ++
 configs/sama5d3xek_nandflash_defconfig   |  2 ++
 configs/sama5d3xek_spiflash_defconfig|  2 ++
 configs/sama5d4_xplained_mmc_defconfig   |  2 ++
 configs/sama5d4_xplained_nandflash_defconfig |  2 ++
 configs/sama5d4_xplained_spiflash_defconfig  |  2 ++
 configs/sama5d4ek_mmc_defconfig  |  2 ++
 configs/sama5d4ek_nandflash_defconfig|  2 ++
 configs/sama5d4ek_spiflash_defconfig |  2 ++
 

Re: [U-Boot] ENV library broken with setenv/printenv argument structs

[Andreas Fenkart]

HI Stefano,

I was not aware of the use case. I have sent out a simple patch that
moves the definition of the structs from fw_main_env.c to fw_env.c,
which should avoid the linking problem. Do you have test application
you could send me. I without doing the option parsing as done in
fw_env_main, you probably use only use a very limited subset of the
library.

/Andi

2016-03-25 10:31 GMT+01:00 Stefano Babic :
> Hi Andreas,
>
> your series for the U-Boot environment tools does not let to use anymore
> the tools as library to be linked to custom program.
>
> In fact, tools/env/Makefile generates a library too:
>
> lib-y += fw_env.o \
> crc32.o ctype.o linux_string.o \
> env_attr.o env_flags.o aes.o
>
> that means that fw_main should not maintain any structure that is
> referenced by the library.
> In fact, linking with the library (renamed as ibubootenv.a), gives the
> errors:
>
> undefined reference to `printenv_args'
> undefined reference to `common_args'
>
> The two functions fw_printenv() and fw_setenv() are then supposed to be
> called by a custom program, what it does not work anymore.
>
> Can you take a look at it ?
>
> Thanks,
> Stefano Babic
>
> --
> =
> DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
> =
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] mx6sabresd: Remove unneeded enable_lvds() function

[Fabio Estevam]

From: Fabio Estevam 

enable_lvds() function only set bits IOMUXC_GPR2_DATA_WIDTH_CH0_18BIT and
IOMUXC_GPR2_DATA_WIDTH_CH1_18BIT, but these bits were already set
previously inside setup_display().

We can safely remove enable_lvds() then.

Signed-off-by: Fabio Estevam 
---
 board/freescale/mx6sabresd/mx6sabresd.c | 12 +---
 1 file changed, 1 insertion(+), 11 deletions(-)

diff --git a/board/freescale/mx6sabresd/mx6sabresd.c 
b/board/freescale/mx6sabresd/mx6sabresd.c
index 727334a..2319354 100644
--- a/board/freescale/mx6sabresd/mx6sabresd.c
+++ b/board/freescale/mx6sabresd/mx6sabresd.c
@@ -365,22 +365,12 @@ static void do_enable_hdmi(struct display_info_t const 
*dev)
imx_enable_hdmi_phy();
 }
 
-static void enable_lvds(struct display_info_t const *dev)
-{
-   struct iomuxc *iomux = (struct iomuxc *)
-   IOMUXC_BASE_ADDR;
-   u32 reg = readl(>gpr[2]);
-   reg |= IOMUXC_GPR2_DATA_WIDTH_CH0_18BIT |
-  IOMUXC_GPR2_DATA_WIDTH_CH1_18BIT;
-   writel(reg, >gpr[2]);
-}
-
 struct display_info_t const displays[] = {{
.bus= -1,
.addr   = 0,
.pixfmt = IPU_PIX_FMT_RGB666,
.detect = NULL,
-   .enable = enable_lvds,
+   .enable = NULL,
.mode   = {
.name   = "Hannstar-XGA",
.refresh= 60,
-- 
1.9.1

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

[U-Boot] [PATCH] tools: env: bug: config structs must be defined in tools library

[Andreas Fenkart]

fw_senten/fw_printenv can be compiled as a tools library,
excluding the fw_env_main object.

Reported-by: Stefano Babic 
Signed-off-by: Andreas Fenkart 
---
 tools/env/fw_env.c  | 4 
 tools/env/fw_env_main.c | 4 
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/tools/env/fw_env.c b/tools/env/fw_env.c
index ee17a69..2533dc4 100644
--- a/tools/env/fw_env.c
+++ b/tools/env/fw_env.c
@@ -34,6 +34,10 @@
 
 #include "fw_env.h"
 
+struct common_args common_args;
+struct printenv_args printenv_args;
+struct setenv_args setenv_args;
+
 #define DIV_ROUND_UP(n, d) (((n) + (d) - 1) / (d))
 
 #define WHITESPACE(c) ((c == '\t') || (c == ' '))
diff --git a/tools/env/fw_env_main.c b/tools/env/fw_env_main.c
index 4bd4216..3065de9 100644
--- a/tools/env/fw_env_main.c
+++ b/tools/env/fw_env_main.c
@@ -49,10 +49,6 @@ static struct option long_options[] = {
{NULL, 0, NULL, 0}
 };
 
-struct common_args common_args;
-struct printenv_args printenv_args;
-struct setenv_args setenv_args;
-
 void usage_printenv(void)
 {
 
-- 
2.8.0.rc3

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

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

[Fabio Estevam]

Hi Stefano,

On Fri, Mar 11, 2016 at 9:22 AM, Stefano Babic  wrote:

>> Could this series go into your -next tree then? I would like to submit
>> other patches for warp7.
>
> Yes, I pick them up.

I see the warp7 commit in your -next branch, but not in u-boot-imx master.

Do you plan to apply it to u-boot.imx master?

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

Re: [U-Boot] [PATCH] Common: SPL: spl_nand: Fixed debug correct NAND ECC type.

[Tom Rini]

On Fri, Mar 25, 2016 at 01:13:17PM +0100, Ahmed Samir Khalil wrote:

> In case of #define DEBUG 1 (fordebugging SPL). A bug in
> spl_nand_load_image() will be triggered, because it prints
> using hw ecc regardless of soft ecc configurations and
> initializations.
> 
> Signed-off-by: Ahmed Samir 

Reviewed-by: Tom Rini 

-- 
Tom


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

[U-Boot] [PATCH] Common: SPL: spl_nand: Fixed debug correct NAND ECC type.

[Ahmed Samir Khalil]

In case of #define DEBUG 1 (fordebugging SPL). A bug in
spl_nand_load_image() will be triggered, because it prints
using hw ecc regardless of soft ecc configurations and
initializations.

Signed-off-by: Ahmed Samir 
---
 common/spl/spl_nand.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/common/spl/spl_nand.c b/common/spl/spl_nand.c
index 3e2c074..79388ff 100644
--- a/common/spl/spl_nand.c
+++ b/common/spl/spl_nand.c
@@ -44,7 +44,11 @@ int spl_nand_load_image(void)
int *src __attribute__((unused));
int *dst __attribute__((unused));
 
+#ifdef CONFIG_SPL_NAND_SOFTECC
+   debug("spl: nand - using sw ecc\n");
+#else
debug("spl: nand - using hw ecc\n");
+#endif
nand_init();
 
/*use CONFIG_SYS_TEXT_BASE as temporary storage area */
-- 
2.5.0

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

[U-Boot] [PATCH] armv8: ls1043aqds: make sure fixed-link property is big endian

[shh.xie]

From: Shaohui Xie 

When setting fixed-link property to DTS, the values should be converted
with using cpu_to_fdt32 so that to have correct value on little endian
Soc.

Signed-off-by: Shaohui Xie 
---
 board/freescale/ls1043aqds/eth.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/board/freescale/ls1043aqds/eth.c b/board/freescale/ls1043aqds/eth.c
index 67b4afe..bf26376 100644
--- a/board/freescale/ls1043aqds/eth.c
+++ b/board/freescale/ls1043aqds/eth.c
@@ -176,9 +176,9 @@ void board_ft_fman_fixup_port(void *fdt, char *compat, 
phys_addr_t addr,
} else if (fm_info_get_enet_if(port) ==
   PHY_INTERFACE_MODE_SGMII_2500) {
/* 2.5G SGMII interface */
-   f_link.phy_id = port;
-   f_link.duplex = 1;
-   f_link.link_speed = 1000;
+   f_link.phy_id = cpu_to_fdt32(port);
+   f_link.duplex = cpu_to_fdt32(1);
+   f_link.link_speed = cpu_to_fdt32(1000);
f_link.pause = 0;
f_link.asym_pause = 0;
/* no PHY for 2.5G SGMII */
@@ -241,9 +241,9 @@ void board_ft_fman_fixup_port(void *fdt, char *compat, 
phys_addr_t addr,
} else if (fm_info_get_enet_if(port) == PHY_INTERFACE_MODE_XGMII &&
   port == FM1_10GEC1) {
/* XFI interface */
-   f_link.phy_id = port;
-   f_link.duplex = 1;
-   f_link.link_speed = 1;
+   f_link.phy_id = cpu_to_fdt32(port);
+   f_link.duplex = cpu_to_fdt32(1);
+   f_link.link_speed = cpu_to_fdt32(1);
f_link.pause = 0;
f_link.asym_pause = 0;
/* no PHY for XFI */
-- 
2.1.0.27.g96db324

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

[U-Boot] [PATCH v3] arm: socfpga: migration of CONFIG_SPI_FLASH_BAR

[Denis Bakhvalov]

CONFIG_SPI_FLASH_BAR was deleted from socfpga_common.h
and placed in socfpga_*_defconfig because it is Kconfig symbol.

Signed-off-by: Denis Bakhvalov 
Reported-by: Denis Bakhvalov 
Cc: Marek Vasut 
Acked-by: Marek Vasut 
---
Changes for v2:
   - Diff was generated from u-boot-socfpga
Changes for v3:
   - Fixed description of changes

 configs/socfpga_arria5_defconfig   | 1 +
 configs/socfpga_cyclone5_defconfig | 1 +
 configs/socfpga_de0_nano_soc_defconfig | 1 +
 configs/socfpga_mcvevk_defconfig   | 1 +
 configs/socfpga_sockit_defconfig   | 1 +
 configs/socfpga_socrates_defconfig | 1 +
 configs/socfpga_sr1500_defconfig   | 1 +
 include/configs/socfpga_common.h   | 2 --
 8 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/configs/socfpga_arria5_defconfig b/configs/socfpga_arria5_defconfig
index 7b60d95..505a68d 100644
--- a/configs/socfpga_arria5_defconfig
+++ b/configs/socfpga_arria5_defconfig
@@ -19,6 +19,7 @@ CONFIG_SPI_FLASH=y
 CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_SPI_FLASH_STMICRO=y
 # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set
+CONFIG_SPI_FLASH_BAR=y
 CONFIG_DM_ETH=y
 CONFIG_ETH_DESIGNWARE=y
 CONFIG_SYS_NS16550=y
diff --git a/configs/socfpga_cyclone5_defconfig 
b/configs/socfpga_cyclone5_defconfig
index 6a487f4..df19a95 100644
--- a/configs/socfpga_cyclone5_defconfig
+++ b/configs/socfpga_cyclone5_defconfig
@@ -19,6 +19,7 @@ CONFIG_SPI_FLASH=y
 CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_SPI_FLASH_STMICRO=y
 # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set
+CONFIG_SPI_FLASH_BAR=y
 CONFIG_DM_ETH=y
 CONFIG_ETH_DESIGNWARE=y
 CONFIG_SYS_NS16550=y
diff --git a/configs/socfpga_de0_nano_soc_defconfig 
b/configs/socfpga_de0_nano_soc_defconfig
index cfcae5d..bb37825 100644
--- a/configs/socfpga_de0_nano_soc_defconfig
+++ b/configs/socfpga_de0_nano_soc_defconfig
@@ -19,5 +19,6 @@ CONFIG_ETH_DESIGNWARE=y
 CONFIG_SYS_NS16550=y
 CONFIG_CADENCE_QSPI=y
 CONFIG_DESIGNWARE_SPI=y
+CONFIG_SPI_FLASH_BAR=y
 CONFIG_USB=y
 CONFIG_DM_USB=y
diff --git a/configs/socfpga_mcvevk_defconfig b/configs/socfpga_mcvevk_defconfig
index b6f6a65..8a76aa1 100644
--- a/configs/socfpga_mcvevk_defconfig
+++ b/configs/socfpga_mcvevk_defconfig
@@ -19,5 +19,6 @@ CONFIG_ETH_DESIGNWARE=y
 CONFIG_SYS_NS16550=y
 CONFIG_CADENCE_QSPI=y
 CONFIG_DESIGNWARE_SPI=y
+CONFIG_SPI_FLASH_BAR=y
 CONFIG_USB=y
 CONFIG_DM_USB=y
diff --git a/configs/socfpga_sockit_defconfig b/configs/socfpga_sockit_defconfig
index f45c3ed..36bb1e1 100644
--- a/configs/socfpga_sockit_defconfig
+++ b/configs/socfpga_sockit_defconfig
@@ -19,6 +19,7 @@ CONFIG_SPI_FLASH=y
 CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_SPI_FLASH_STMICRO=y
 # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set
+CONFIG_SPI_FLASH_BAR=y
 CONFIG_DM_ETH=y
 CONFIG_ETH_DESIGNWARE=y
 CONFIG_SYS_NS16550=y
diff --git a/configs/socfpga_socrates_defconfig 
b/configs/socfpga_socrates_defconfig
index e25d09b..937f14f 100644
--- a/configs/socfpga_socrates_defconfig
+++ b/configs/socfpga_socrates_defconfig
@@ -23,5 +23,6 @@ CONFIG_ETH_DESIGNWARE=y
 CONFIG_SYS_NS16550=y
 CONFIG_CADENCE_QSPI=y
 CONFIG_DESIGNWARE_SPI=y
+CONFIG_SPI_FLASH_BAR=y
 CONFIG_USB=y
 CONFIG_DM_USB=y
diff --git a/configs/socfpga_sr1500_defconfig b/configs/socfpga_sr1500_defconfig
index d499a14..83eada3 100644
--- a/configs/socfpga_sr1500_defconfig
+++ b/configs/socfpga_sr1500_defconfig
@@ -17,6 +17,7 @@ CONFIG_DM_MMC=y
 CONFIG_SPI_FLASH=y
 CONFIG_SPI_FLASH_STMICRO=y
 # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set
+CONFIG_SPI_FLASH_BAR=y
 CONFIG_DM_ETH=y
 CONFIG_ETH_DESIGNWARE=y
 CONFIG_SYS_NS16550=y
diff --git a/include/configs/socfpga_common.h b/include/configs/socfpga_common.h
index 56d32e6..2ad0287 100644
--- a/include/configs/socfpga_common.h
+++ b/include/configs/socfpga_common.h
@@ -93,7 +93,6 @@
 #define CONFIG_CMD_SPI
 #define CONFIG_CMD_SF
 #define CONFIG_SF_DEFAULT_SPEED3000
-#define CONFIG_SPI_FLASH_BAR
 /*
  * The base address is configurable in QSys, each board must specify the
  * base address based on it's particular FPGA configuration. Please note
@@ -219,7 +218,6 @@ unsigned int cm_get_qspi_controller_clk_hz(void);
 #endif
 #define CONFIG_CQSPI_DECODER   0
 #define CONFIG_CMD_SF
-#define CONFIG_SPI_FLASH_BAR
 
 /*
  * Designware SPI support
-- 
1.9.1

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

Re: [U-Boot] [PATCH v2] mx6sabresd: Use VESA 1024x768 timings

[Stefano Babic]

On 16/03/2016 16:55, Fabio Estevam wrote:
> VESA 1024x768 results in much more accurate timings.
> 
> Based on the patch from Soeren Moch for the tbs2910 board.
> 
> Signed-off-by: Fabio Estevam 
> ---
> Changes since v1:
> - Fix Soeren's name
> 
>  board/freescale/mx6sabresd/mx6sabresd.c | 28 ++--
>  1 file changed, 14 insertions(+), 14 deletions(-)
> 
> diff --git a/board/freescale/mx6sabresd/mx6sabresd.c 
> b/board/freescale/mx6sabresd/mx6sabresd.c
> index e9d9664..727334a 100644
> --- a/board/freescale/mx6sabresd/mx6sabresd.c
> +++ b/board/freescale/mx6sabresd/mx6sabresd.c
> @@ -386,13 +386,13 @@ struct display_info_t const displays[] = {{
>   .refresh= 60,
>   .xres   = 1024,
>   .yres   = 768,
> - .pixclock   = 15385,
> - .left_margin= 220,
> - .right_margin   = 40,
> - .upper_margin   = 21,
> - .lower_margin   = 7,
> - .hsync_len  = 60,
> - .vsync_len  = 10,
> + .pixclock   = 15384,
> + .left_margin= 160,
> + .right_margin   = 24,
> + .upper_margin   = 29,
> + .lower_margin   = 3,
> + .hsync_len  = 136,
> + .vsync_len  = 6,
>   .sync   = FB_SYNC_EXT,
>   .vmode  = FB_VMODE_NONINTERLACED
>  } }, {
> @@ -406,13 +406,13 @@ struct display_info_t const displays[] = {{
>   .refresh= 60,
>   .xres   = 1024,
>   .yres   = 768,
> - .pixclock   = 15385,
> - .left_margin= 220,
> - .right_margin   = 40,
> - .upper_margin   = 21,
> - .lower_margin   = 7,
> - .hsync_len  = 60,
> - .vsync_len  = 10,
> + .pixclock   = 15384,
> + .left_margin= 160,
> + .right_margin   = 24,
> + .upper_margin   = 29,
> + .lower_margin   = 3,
> + .hsync_len  = 136,
> + .vsync_len  = 6,
>   .sync   = FB_SYNC_EXT,
>   .vmode  = FB_VMODE_NONINTERLACED
>  } }, {
> 
Applied to u-boot-imx, thanks !

Best regards,
Stefano Babic


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

Re: [U-Boot] [PATCH] mx27: 16-bit wide watchdog registers

[Stefano Babic]

On 20/03/2016 14:10, Leonid Iziumtsev wrote:
> From: Leonid Iziumtsev 
> 
> Make the watchdog registers 16-bit wide, as they are according to TRM.
> 
> Signed-off-by: Leonid Iziumtsev 
> ---
>  arch/arm/cpu/arm926ejs/mx27/reset.c   | 8 
>  arch/arm/include/asm/arch-mx27/imx-regs.h | 6 +++---
>  2 files changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/arch/arm/cpu/arm926ejs/mx27/reset.c 
> b/arch/arm/cpu/arm926ejs/mx27/reset.c
> index f7b4a1c..e764986 100644
> --- a/arch/arm/cpu/arm926ejs/mx27/reset.c
> +++ b/arch/arm/cpu/arm926ejs/mx27/reset.c
> @@ -27,14 +27,14 @@ void reset_cpu(ulong ignored)
>  {
>   struct wdog_regs *regs = (struct wdog_regs *)IMX_WDT_BASE;
>   /* Disable watchdog and set Time-Out field to 0 */
> - writel(0x, >wcr);
> + writew(0x, >wcr);
>  
>   /* Write Service Sequence */
> - writel(0x, >wsr);
> - writel(0x, >wsr);
> + writew(0x, >wsr);
> + writew(0x, >wsr);
>  
>   /* Enable watchdog */
> - writel(WCR_WDE, >wcr);
> + writew(WCR_WDE, >wcr);
>  
>   while (1);
>   /*NOTREACHED*/
> diff --git a/arch/arm/include/asm/arch-mx27/imx-regs.h 
> b/arch/arm/include/asm/arch-mx27/imx-regs.h
> index baf1d29..40b76d2 100644
> --- a/arch/arm/include/asm/arch-mx27/imx-regs.h
> +++ b/arch/arm/include/asm/arch-mx27/imx-regs.h
> @@ -106,9 +106,9 @@ struct esdramc_regs {
>  
>  /* Watchdog Registers*/
>  struct wdog_regs {
> - u32 wcr;
> - u32 wsr;
> - u32 wstr;
> + u16 wcr;
> + u16 wsr;
> + u16 wstr;
>  };
>  
>  /* PLL registers */
> 

Applied to u-boot-imx, thanks !

Best regards,
Stefano Babic

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

Re: [U-Boot] [PATCH 1/3] imx: mx6ul: skip setting ahb rate

[Stefano Babic]

On 25/03/2016 10:16, Peng Fan wrote:
> Hi Stefano,
> 
> Gentle Ping on the three patches.
> 
> Thanks,
> Peng.
> On Wed, Mar 09, 2016 at 04:44:36PM +0800, Peng Fan wrote:
>> To i.MX6UL, default ARM rate and AHB rate is 396M and 198M,
>> no need to set them.
>>
>> Signed-off-by: Peng Fan 
>> Cc: Stefano Babic 
>> ---
>> arch/arm/cpu/armv7/mx6/soc.c | 19 ---
>> 1 file changed, 12 insertions(+), 7 deletions(-)
>>
>> diff --git a/arch/arm/cpu/armv7/mx6/soc.c b/arch/arm/cpu/armv7/mx6/soc.c
>> index bdd41b0..f29901f 100644
>> --- a/arch/arm/cpu/armv7/mx6/soc.c
>> +++ b/arch/arm/cpu/armv7/mx6/soc.c
>> @@ -328,13 +328,18 @@ int arch_cpu_init(void)
>>   */
>>  init_bandgap();
>>
>> -/*
>> - * When low freq boot is enabled, ROM will not set AHB
>> - * freq, so we need to ensure AHB freq is 132MHz in such
>> - * scenario.
>> - */
>> -if (mxc_get_clock(MXC_ARM_CLK) == 39600)
>> -set_ahb_rate(13200);
>> +if (!IS_ENABLED(CONFIG_MX6UL)) {
>> +/*
>> + * When low freq boot is enabled, ROM will not set AHB
>> + * freq, so we need to ensure AHB freq is 132MHz in such
>> + * scenario.
>> + *
>> + * To i.MX6UL, when power up, default ARM core and
>> + * AHB rate is 396M and 132M.
>> + */
>> +if (mxc_get_clock(MXC_ARM_CLK) == 39600)
>> +set_ahb_rate(13200);
>> +}
>>
>>  /* Set perclk to source from OSC 24MHz */
>> #if defined(CONFIG_MX6SL)
>> -- 
>> 2.6.2
>>

Appplied (whole series) to u-boot-imx, thanks !

Best regards,
Stefano Babic

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

[U-Boot] A problem about 'sf probe' using DM_SPI

[Qianyu Gong]

Hi Simon,

I think I'm not very clear with this code in common/cmd_sf.c:
"
# ifdef CONFIG_DM_SPI_FLASH
   /* Remove the old device, otherwise probe will just be a nop */
   ret = spi_find_bus_and_cs(bus, cs, _dev, );
   if (!ret) {
  device_remove(new);
 device_unbind(new);
 }
"
I may understand the remove but why need to unbind the device?
The unbind would cause a series of free operations on the device list, correct?

Then if I probe a flash twice, at the second time the driver model will create
a new flash named 'spi_flash@xx:xx' using default settings because it doesn't
find such a device in the device list and never probes it from the board's fdt 
again.

=> dm tree
Class   Probed   Name

root[ + ]root_driver
simple_bus  [ + ]`-- soc
spi [ + ]   |-- dspi@210
spi_flash   [   ]||-- n25q128a
spi_flash   [ + ]|   |-- spi_flash@1:1
spi_flash   [ + ]|   `-- spi_flash@1:2

Fortunately the default SPI mode set by U-Boot is SPI_MODE_3 so it doesn't cause
issues on our boards. But if an SPI flash which only supports SPI_MODE_0 is 
used,
I think it wouldn't work properly from the second probe.


Sorry if there is something wrong with my understandings.
Just because I found my flash's name was changed to spi-flash@xx:xx in dm tree
after several probes, I began to read something about driver model.:)


Regards,
Qianyu

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

Re: [U-Boot] [PATCH] dm: i2c: mxc_i2c: implement i2c_idle_bus

[Peng Fan]

Hi Heiko,

On Mon, Mar 21, 2016 at 05:10:45PM +0800, Peng Fan wrote:
>Hi Heiko,
>
>On Mon, Mar 21, 2016 at 07:50:32AM +0100, Heiko Schocher wrote:
>>Hello Peng Fan,
>>
>>Sorry for the late reply ...
>>
>>Am 11.03.2016 um 09:47 schrieb Peng Fan:
>>>Implement i2c_idle_bus in driver, then setup_i2c can
>>>be dropped for boards which enable DM_I2C/DM_GPIO/PINCTRL.
>>>The i2c_idle_bus force bus idle flow follows setup_i2c in
>>>arch/arm/imx-common/i2c-mxv7.c
>>>
>>>This patch is an implementation following linux kernel patch:
>>>"
>>>commit 1c4b6c3bcf30d0804db0d0647d8ebeb862c6f7e5
>>>Author: Gao Pan 
>>>Date:   Fri Oct 23 20:28:54 2015 +0800
>>>
>>> i2c: imx: implement bus recovery
>>>
>>> Implement bus recovery methods for i2c-imx so we can recover from
>>> situations where SCL/SDA are stuck low.
>>>
>>> Once i2c bus SCL/SDA are stuck low during transfer, config the i2c
>>> pinctrl to gpio mode by calling pinctrl sleep set function, and then
>>> use GPIO to emulate the i2c protocol to send nine dummy clock to recover
>>> i2c device. After recovery, set i2c pinctrl to default group setting.
>>>"
>>>
>>>See Documentation/devicetree/bindings/i2c/i2c-imx.txt for detailed
>>>description.
>>>1. Introuduce scl_gpio/sda_gpio/bus in mxc_i2c_bus.
>>>2. Discard the __weak attribute for i2c_idle_bus and implement it,
>>>since we have pinctrl driver/driver model gpio driver. We can
>>>use device tree, but not let board code to do this.
>>>3. gpio state for mxc_i2c is not a must, but it is recommended. If
>>>there is no gpio state, driver will give tips, but not fail.
>>>4. The i2c controller was first probed, default pinctrl state will
>>>be used, so when need to use gpio function, need to do
>>>"pinctrl_select_state(dev, "gpio")" and after force bus idle,
>>>need to switch back "pinctrl_select_state(dev, "default")".
>>>
>>>This is example about how to use the gpio force bus
>>>idle function:
>>>"
>>>   {
>>> clock-frequency = <10>;
>>> pinctrl-names = "default", "gpio";
>>> pinctrl-0 = <_i2c1>;
>>> pinctrl-1 = <_i2c1_gpio>;
>>> scl-gpios = < 28 GPIO_ACTIVE_HIGH>;
>>> sda-gpios = < 29 GPIO_ACTIVE_HIGH>;
>>> status = "okay";
>>> []
>>>  };
>>>
>>>[.]
>>>
>>> pinctrl_i2c1_gpio: i2c1grp_gpio {
>>> fsl,pins = <
>>> MX6UL_PAD_UART4_TX_DATA__GPIO1_IO28 0x1b8b0
>>> MX6UL_PAD_UART4_RX_DATA__GPIO1_IO29 0x1b8b0
>>> >;
>>> };
>>>"
>>>
>>>Signed-off-by: Peng Fan 
>>>Cc: Albert Aribaud 
>>>Cc: Stefano Babic 
>>>Cc: Heiko Schocher 
>>>Cc: Simon Glass 
>>>Cc: York Sun 
>>>---
>>>  arch/arm/include/asm/imx-common/mxc_i2c.h |  10 +++
>>>  drivers/i2c/mxc_i2c.c | 101 
>>> +++---
>>>  2 files changed, 102 insertions(+), 9 deletions(-)
>>
>>Thanks for this patch. In principle it looks very good ... I
>>have only a "nitpick" ... Couldn;t we split this patch into a
>>common piece, which does the deblocking of the bus, and a
>>"board/driver" specific part, where we do the pinmux changes?
>>
>>There is nothing "imx" special in the deblocking of the i2c
>>bus, beside switching the pinmux ... and as you use DM and DT
>>there is not even in your patch a imx special part ...
>>
>>So I tend to say, we can move this piece of code into a more
>>common place (drivers/i2c/i2c_core.c or into a new file i2c_deblock.c)
>>instead having it in the imx i2c driver ...
>>
>>Can you rework this?
>
>The idea of this patch is from Linux I2C patch for IMX:
>"
>commit 1c4b6c3bcf30d0804db0d0647d8ebeb862c6f7e5
>Author: Gao Pan 
>Date:   Fri Oct 23 20:28:54 2015 +0800
>
> i2c: imx: implement bus recovery
>
> Implement bus recovery methods for i2c-imx so we can recover from
> situations where SCL/SDA are stuck low.
>"
>
>so I would like to keep it in mxc i2c driver for now. When other i2c drivers
>have such requirement to force bus idle, then we can think of a new common
>way to support them.

Will you reject this patch or pick up this patch?

Thanks,
Peng.

>
>Thanks,
>Peng.
>
>>
>>Thanks a lot!
>>
>>bye,
>>Heiko
>>>
>
>[.]
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] imx: mx6: Fix incorrect clear mmdc_ch0 handshake mask

[Stefano Babic]

On 25/03/2016 10:14, Peng Fan wrote:
> Hi Stefano,
> 
> On Wed, Mar 09, 2016 at 05:37:28PM +0800, Peng Fan wrote:
>> Hi Stefano,
>>
>> On Wed, Mar 09, 2016 at 10:47:38AM +0100, Stefano Babic wrote:
>>> Hi Peng, Ye,
>>>
>>> On 09/03/2016 09:13, Peng Fan wrote:
 From: Ye Li 

 Since the MX6UL/SL/SX only has one DDR channel, in CCM_CCDR register
 the bit[17] for mmdc_ch0 is reserved and its proper state should be 1.
 When clear this bit, the periph_clk_sel cannot be set and that
 CDHIPR[periph_clk_sel_busy] handshake never clears.

 Signed-off-by: Ye Li 
 Signed-off-by: Peng Fan 
 ---
  arch/arm/cpu/armv7/mx6/soc.c | 5 -
  1 file changed, 4 insertions(+), 1 deletion(-)

 diff --git a/arch/arm/cpu/armv7/mx6/soc.c b/arch/arm/cpu/armv7/mx6/soc.c
 index 91a3deb..bdd41b0 100644
 --- a/arch/arm/cpu/armv7/mx6/soc.c
 +++ b/arch/arm/cpu/armv7/mx6/soc.c
 @@ -278,7 +278,10 @@ static void clear_mmdc_ch_mask(void)
reg = readl(_ccm->ccdr);
  
/* Clear MMDC channel mask */
 -  reg &= ~(MXC_CCM_CCDR_MMDC_CH1_HS_MASK | MXC_CCM_CCDR_MMDC_CH0_HS_MASK);
 +  if (is_cpu_type(MXC_CPU_MX6SX) || is_cpu_type(MXC_CPU_MX6UL) || 
 is_cpu_type(MXC_CPU_MX6SL))
 +  reg &= ~(MXC_CCM_CCDR_MMDC_CH1_HS_MASK);
 +  else
 +  reg &= ~(MXC_CCM_CCDR_MMDC_CH1_HS_MASK | 
 MXC_CCM_CCDR_MMDC_CH0_HS_MASK);
writel(reg, _ccm->ccdr);
  }
  
>>>
>>> Acked-by: Stefano Babic 
>>>
>>> This is a fix, and my question to you both: is it enough to merge it
>>> after 2016.03 ? I have not read about big issues due to periph_clk_sel,
>>> and maybe we can postponed it (or I merge directly into -next as several
>>> of you have already proposed).
>>
>> Yeah. It's okay to merge after 2016.03.


I do it

Stefano

> 
> Will you pick up this patch?
> 
> Regards,
> Peng.
> 
>>
>> Regards,
>> Peng.
>>
>>>
>>> Best regards,
>>> Stefano Babic
>>>
>>>
>>>
>>> -- 
>>> =
>>> DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
>>> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
>>> Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
>>> =


-- 
=
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
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] ENV library broken with setenv/printenv argument structs

[Stefano Babic]

Hi Andreas,

your series for the U-Boot environment tools does not let to use anymore
the tools as library to be linked to custom program.

In fact, tools/env/Makefile generates a library too:

lib-y += fw_env.o \
crc32.o ctype.o linux_string.o \
env_attr.o env_flags.o aes.o

that means that fw_main should not maintain any structure that is
referenced by the library.
In fact, linking with the library (renamed as ibubootenv.a), gives the
errors:

undefined reference to `printenv_args'
undefined reference to `common_args'

The two functions fw_printenv() and fw_setenv() are then supposed to be
called by a custom program, what it does not work anymore.

Can you take a look at it ?

Thanks,
Stefano Babic

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

Re: [U-Boot] [PATCH 1/3] imx: mx6ul: skip setting ahb rate

[Peng Fan]

Hi Stefano,

Gentle Ping on the three patches.

Thanks,
Peng.
On Wed, Mar 09, 2016 at 04:44:36PM +0800, Peng Fan wrote:
>To i.MX6UL, default ARM rate and AHB rate is 396M and 198M,
>no need to set them.
>
>Signed-off-by: Peng Fan 
>Cc: Stefano Babic 
>---
> arch/arm/cpu/armv7/mx6/soc.c | 19 ---
> 1 file changed, 12 insertions(+), 7 deletions(-)
>
>diff --git a/arch/arm/cpu/armv7/mx6/soc.c b/arch/arm/cpu/armv7/mx6/soc.c
>index bdd41b0..f29901f 100644
>--- a/arch/arm/cpu/armv7/mx6/soc.c
>+++ b/arch/arm/cpu/armv7/mx6/soc.c
>@@ -328,13 +328,18 @@ int arch_cpu_init(void)
>*/
>   init_bandgap();
> 
>-  /*
>-   * When low freq boot is enabled, ROM will not set AHB
>-   * freq, so we need to ensure AHB freq is 132MHz in such
>-   * scenario.
>-   */
>-  if (mxc_get_clock(MXC_ARM_CLK) == 39600)
>-  set_ahb_rate(13200);
>+  if (!IS_ENABLED(CONFIG_MX6UL)) {
>+  /*
>+   * When low freq boot is enabled, ROM will not set AHB
>+   * freq, so we need to ensure AHB freq is 132MHz in such
>+   * scenario.
>+   *
>+   * To i.MX6UL, when power up, default ARM core and
>+   * AHB rate is 396M and 132M.
>+   */
>+  if (mxc_get_clock(MXC_ARM_CLK) == 39600)
>+  set_ahb_rate(13200);
>+  }
> 
>   /* Set perclk to source from OSC 24MHz */
> #if defined(CONFIG_MX6SL)
>-- 
>2.6.2
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] imx: mx6: Fix incorrect clear mmdc_ch0 handshake mask

[Peng Fan]

Hi Stefano,

On Wed, Mar 09, 2016 at 05:37:28PM +0800, Peng Fan wrote:
>Hi Stefano,
>
>On Wed, Mar 09, 2016 at 10:47:38AM +0100, Stefano Babic wrote:
>>Hi Peng, Ye,
>>
>>On 09/03/2016 09:13, Peng Fan wrote:
>>> From: Ye Li 
>>> 
>>> Since the MX6UL/SL/SX only has one DDR channel, in CCM_CCDR register
>>> the bit[17] for mmdc_ch0 is reserved and its proper state should be 1.
>>> When clear this bit, the periph_clk_sel cannot be set and that
>>> CDHIPR[periph_clk_sel_busy] handshake never clears.
>>> 
>>> Signed-off-by: Ye Li 
>>> Signed-off-by: Peng Fan 
>>> ---
>>>  arch/arm/cpu/armv7/mx6/soc.c | 5 -
>>>  1 file changed, 4 insertions(+), 1 deletion(-)
>>> 
>>> diff --git a/arch/arm/cpu/armv7/mx6/soc.c b/arch/arm/cpu/armv7/mx6/soc.c
>>> index 91a3deb..bdd41b0 100644
>>> --- a/arch/arm/cpu/armv7/mx6/soc.c
>>> +++ b/arch/arm/cpu/armv7/mx6/soc.c
>>> @@ -278,7 +278,10 @@ static void clear_mmdc_ch_mask(void)
>>> reg = readl(_ccm->ccdr);
>>>  
>>> /* Clear MMDC channel mask */
>>> -   reg &= ~(MXC_CCM_CCDR_MMDC_CH1_HS_MASK | MXC_CCM_CCDR_MMDC_CH0_HS_MASK);
>>> +   if (is_cpu_type(MXC_CPU_MX6SX) || is_cpu_type(MXC_CPU_MX6UL) || 
>>> is_cpu_type(MXC_CPU_MX6SL))
>>> +   reg &= ~(MXC_CCM_CCDR_MMDC_CH1_HS_MASK);
>>> +   else
>>> +   reg &= ~(MXC_CCM_CCDR_MMDC_CH1_HS_MASK | 
>>> MXC_CCM_CCDR_MMDC_CH0_HS_MASK);
>>> writel(reg, _ccm->ccdr);
>>>  }
>>>  
>>
>>Acked-by: Stefano Babic 
>>
>>This is a fix, and my question to you both: is it enough to merge it
>>after 2016.03 ? I have not read about big issues due to periph_clk_sel,
>>and maybe we can postponed it (or I merge directly into -next as several
>>of you have already proposed).
>
>Yeah. It's okay to merge after 2016.03.

Will you pick up this patch?

Regards,
Peng.

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

Re: [U-Boot] Variable content dump to memory

[Nicolae Rosia]

On Thu, Mar 24, 2016 at 7:51 PM, James Chargin  wrote:
[...]
> You weren't completely specific about your needs, but assuming you are 
> wanting to write a U-Boot environment variable to memory, try something like
>
You're right.
I'm trying to do the following:
U-Boot# setenv mytext 'This is a long text'
U-Boot# printenv mytext
mytext=This is a long text
and somehow write it to a memory address so I can use it with ext4write.

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

Re: [U-Boot] Linux hangs due to commit v2015.10-15-g02cc27c on loading i2c-mv64xx

[Michael Haas]

On 03/20/2016 08:15 PM, Hans de Goede wrote:
> > I'm running Debian Jessie with Linux 4.3.0-0.bpo.1-armmp-lpae on my
> > a20-olinuxino-lime2.
> > I have noticed that my board hangs with my recent u-boot versions
> when I
> > load the i2c module.
> >
> > git-bisect narrowed the problem down to the following commit:
> >
> > 02cc27c74f9b884b538bcd1b93342a4c05b5d608 is the first bad commit
> > commit 02cc27c74f9b884b538bcd1b93342a4c05b5d608
> > Author: Hans de Goede 
> > Date:   Sat Oct 3 15:29:24 2015 +0200
> >
> >sunxi: power: Change axp209 LDO3 and LDO4 default to disabled
>
> 
>
> > The axp209 is attached to the i2c bus, so that is likely the real
> > culprit. In my setup, the axp209 drivers are loaded before I insert
> > i2c-mv64xxx.
> >
> > What would be the best course of action here?
> >
> > * Revert the commit
> > * Enable LDO3 and LDO4 for the a20-olinuxino-lime2 only?
> > * Fix linux
>
> I would go for option 3: "Fix linux", looking at the lime2 dts I see:
>
> vcc_csi0: ldo3 {
> regulator-min-microvolt = <70>;
> regulator-max-microvolt = <350>;
> regulator-always-on;
> };
>
> vcc_csi1: ldo4 {
> regulator-min-microvolt = <125>;
> regulator-max-microvolt = <330>;
> regulator-always-on;
> };
>
> The regulator-always-on will cause both regulators to get turned on,
> but the min / max constraints match the datasheet constrains / the
> absolute min / max values these ldo-s can deliver, not the constraints
> which the board design puts on these.
>
> So now these ldo-s end up getting turned on at whatever voltage
> is the default (which according to the datasheet is unknown),
> where as the schematic says that if these get turned on (which
> is not necessary) they should be run at 2.8V.
>
> This dts file is the only axp209 using dts file which:
>
> 1) Does not have proper constraints for LDO3 / LDO4
> 2) Uses regulator-always-on; for these
>
> I would suggest fixing both, first you can try making min = max =
> 280. And if that fixes things, which I expect it will, I would
> also drop the regulator-always-on from the dts, since we really
> only need to turn these on when using the csi interface in which
> case it would be up to the csi driver to explicitly turn them on.
>

Setting the voltage to 2.8V does not seem to fix things. Dropping the
'regulator-always-on' stance does allow me to
load and use i2c-mv64xx and axp20x-i2c.

Is that something I should submit upstream or is there further
investigation needed why simply setting a proper voltage
does not work?

Thanks!

Michael

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

[U-Boot] [PATCH v4 1/3] net: phy: Optionally force master mode for RTL PHY

[Michael Haas]

This patch introduces CONFIG_RTL8211X_PHY_FORCE_MASTER. If this
define is set, RTL8211x PHYs (except for the RTL8211F) will have their
1000BASE-T master/slave autonegotiation disabled and forced to master
mode.

This is helpful for PHYs like the RTL8211C which produce unstable links
in slave mode. Such problems have been found on the A20-Olimex-SOM-EVB
and A20-OLinuXino-Lime2.

There is no proper way to identify affected PHYs in software as the
RTL8211C shares its UID with the RTL8211B. Thus, this fix requires
the introduction of an #ifdef.

CC: fra...@gmail.com
CC: mer...@debian.org
CC: hdego...@redhat.com
CC: i...@hellion.org.uk
CC: joe.hershber...@ni.com

Signed-off-by: Michael Haas 
Tested-by: Karsten Merker 

---

Changes in v4:
 - Squashed previously separate commit introducing KCONFIG variable
   into commit containing main code change (Hans de Goede's suggestion)
 - Changed KCONFIG description according to Karsten Merker's suggestions
   plus some clarification of my own
 - Changed commit message according to Karsten Merker's suggestions

Changes in v3:
 - Remove incorrect detection of RTL8211CL and use #ifdef instead
   (thanks to Karsten Merker)
 - Introduced constants for register bits

Changes in v2:
 - Removed accidental inclusion of Karsten's patch in my first submission of 
this series.
 - Fix a typo in the code: 6 -> &

 drivers/net/Kconfig   | 21 +
 drivers/net/phy/realtek.c | 13 -
 2 files changed, 33 insertions(+), 1 deletion(-)

diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 2a229b8..8a95fbd 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -13,6 +13,27 @@ config PHYLIB
help
  Enable Ethernet PHY (physical media interface) support.
 
+config RTL8211X_PHY_FORCE_MASTER
+   bool "Ethernet PHY RTL8211x: force 1000BASE-T master mode"
+   depends on PHYLIB
+   help
+ Force master mode for 1000BASE-T on RTl8211x PHYs (except for 
RTL8211F).
+ This can work around link stability and data
+ corruption issues on gigabit links which can occur in slave mode on
+ certain PHYs, e.g. on the RTL8211C(L).
+
+ Please note that two directly connected devices (i.e. via
+ crossover cable) will not be able to establish a link between each 
other
+ if they both force master mode. Multiple devices forcing
+ master mode when connected by a network switch do not pose a
+ problem as the switch configures its affected ports into slave
+ mode.
+ This option only affects gigabit links. If you must establish a direct
+ connection between two devices which both force master mode, try 
forcing
+ the link speed to 100MBit/s.
+
+ If unsure, say N.
+
 menuconfig NETDEVICES
bool "Network device support"
depends on NET
diff --git a/drivers/net/phy/realtek.c b/drivers/net/phy/realtek.c
index 259a87f..359ec50 100644
--- a/drivers/net/phy/realtek.c
+++ b/drivers/net/phy/realtek.c
@@ -12,6 +12,10 @@
 
 #define PHY_AUTONEGOTIATE_TIMEOUT 5000
 
+/* RTL8211x 1000BASE-T Control Register */
+#define MIIM_RTL8211x_CTRL1000T_MSCE (1 << 12);
+#define MIIM_RTL8211X_CTRL1000T_MASTER (1 << 11);
+
 /* RTL8211x PHY Status Register */
 #define MIIM_RTL8211x_PHY_STATUS   0x11
 #define MIIM_RTL8211x_PHYSTAT_SPEED0xc000
@@ -53,7 +57,14 @@ static int rtl8211x_config(struct phy_device *phydev)
 */
phy_write(phydev, MDIO_DEVAD_NONE, MIIM_RTL8211x_PHY_INER,
  MIIM_RTL8211x_PHY_INTR_DIS);
-
+#ifdef CONFIG_RTL8211X_PHY_FORCE_MASTER
+   unsigned int reg = phy_read(phydev, MDIO_DEVAD_NONE, MII_CTRL1000);
+   /* force manual master/slave configuration */
+   reg |= MIIM_RTL8211x_CTRL1000T_MSCE;
+   /* force master mode */
+   reg |= MIIM_RTL8211X_CTRL1000T_MASTER;
+   phy_write(phydev, MDIO_DEVAD_NONE, MII_CTRL1000, reg);
+#endif
/* read interrupt status just to clear it */
phy_read(phydev, MDIO_DEVAD_NONE, MIIM_RTL8211x_PHY_INER);
 
-- 
2.7.2

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

[U-Boot] [PATCH v4 2/3] sunxi: A20-Olimex-SOM-EVB: Force 8211CL to master

[Michael Haas]

Force master mode for 1000BASE-T operation on the
A20-Olimex-SOM-EVB.

Karsten Merker reports that this change is necessary to get a reliable
link at gigabit speeds.

Signed-off-by: Michael Haas 
---

Changes in v4:
 - Changed commit summary according to Chen-Yu Tsai's suggestion,
   modified to fit the 70 character limit

Changes in v3: None
Changes in v2: None

 configs/A20-Olimex-SOM-EVB_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/A20-Olimex-SOM-EVB_defconfig 
b/configs/A20-Olimex-SOM-EVB_defconfig
index 66d8f98..68de5f2 100644
--- a/configs/A20-Olimex-SOM-EVB_defconfig
+++ b/configs/A20-Olimex-SOM-EVB_defconfig
@@ -19,3 +19,4 @@ 
CONFIG_SYS_EXTRA_OPTIONS="SUNXI_GMAC,RGMII,AHCI,SATAPWR=SUNXI_GPC(3)"
 CONFIG_CMD_GPIO=y
 CONFIG_ETH_DESIGNWARE=y
 CONFIG_USB_EHCI_HCD=y
+CONFIG_RTL8211X_PHY_FORCE_MASTER=y
-- 
2.7.2

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

[U-Boot] [PATCH v4 0/3] net: phy: Force master mode for RTL8211C on some boards

[Michael Haas]

This patch is required to get reliable 1000BASE-T operation on some
boards using the RTL8211C(L) PHY.

Following discussions on v2 of this patch, I have removed the incorrect
check for the RTL8211C(L). Affected boards now have to define
CONFIG_RTL8211X_PHY_FORCE_MASTER to benefit from the fix.

Note that this patch requires Karsten Merkers '[PATCH] net: phy: Realtek
RTL8211B/C PHY ID fix' as well as Hans de Goede's recent u-boot-sunxi
pull request, specifically 1eae8f66ff749409eb96e2f3f3387c56232d0b8a and
fc8991c61c393ce6a9d3dfc97cb56dbbd9e8cbba.

Michael


Changes in v4:
 - Squashed previously separate commit introducing KCONFIG variable
   into commit containing main code change (Hans de Goede's suggestion)
 - Changed KCONFIG description according to Karsten Merker's suggestions
   plus some clarification of my own
 - Changed commit message according to Karsten Merker's suggestions
 - Changed commit summary according to Chen-Yu Tsai's suggestion,
   modified to fit the 70 character limit
 - Changed commit summary according to Chen-Yu Tsai's suggestion,
   modified to fit the 70 character limit

Changes in v3:
 - Remove incorrect detection of RTL8211CL and use #ifdef instead
   (thanks to Karsten Merker)
 - Introduced constants for register bits

Changes in v2:
 - Removed accidental inclusion of Karsten's patch in my first submission of 
this series.
 - Fix a typo in the code: 6 -> &

Michael Haas (3):
  net: phy: Optionally force master mode for RTL PHY
  sunxi: A20-Olimex-SOM-EVB: Force 8211CL to master
  sunxi: A20-OLinuXino-Lime2: Force 8211CL to master

 configs/A20-OLinuXino-Lime2_defconfig |  1 +
 configs/A20-Olimex-SOM-EVB_defconfig  |  1 +
 drivers/net/Kconfig   | 21 +
 drivers/net/phy/realtek.c | 13 -
 4 files changed, 35 insertions(+), 1 deletion(-)

-- 
2.7.2

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

[U-Boot] [PATCH v4 3/3] sunxi: A20-OLinuXino-Lime2: Force 8211CL to master

[Michael Haas]

Force master mode on the A20-OLinuXino-Lime2. This change is required
to get a reliable link at gigabit speeds.

Signed-off-by: Michael Haas 
---

Changes in v4:
 - Changed commit summary according to Chen-Yu Tsai's suggestion,
   modified to fit the 70 character limit

Changes in v3: None
Changes in v2: None

 configs/A20-OLinuXino-Lime2_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/A20-OLinuXino-Lime2_defconfig 
b/configs/A20-OLinuXino-Lime2_defconfig
index 95c67d6..3bd4fa7 100644
--- a/configs/A20-OLinuXino-Lime2_defconfig
+++ b/configs/A20-OLinuXino-Lime2_defconfig
@@ -16,3 +16,4 @@ 
CONFIG_SYS_EXTRA_OPTIONS="SUNXI_GMAC,RGMII,AHCI,SATAPWR=SUNXI_GPC(3)"
 CONFIG_CMD_GPIO=y
 CONFIG_ETH_DESIGNWARE=y
 CONFIG_USB_EHCI_HCD=y
+CONFIG_RTL8211X_PHY_FORCE_MASTER=y
-- 
2.7.2

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

Re: [U-Boot] [PATCH 1/2] sunxi: Add conditional magic sram poke for A33

[Ian Campbell]

On Fri, 2016-03-25 at 01:10 +0100, Karsten Merker wrote: 
> > -   if ((version & 0x) == 0x1650)
> > +   /*
> > +    * Ideally this would be a switch case, bit we do not know exactly
> 
> s/bit/but/

Other than that, both patches:
Acked-by: Ian Campbell 

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

Re: [U-Boot] [PATCH 5/5] lib: Enable private libgcc by default

[Albert ARIBAUD]

On Fri, 25 Mar 2016 07:37:25 +0100, Albert ARIBAUD
 wrote:
> Hello Tom,

> That way,
> 
> 0) U-Boot gets the stable and controlled AEABI support you want;
> 
> 1) GCC keeps its somewhat stable but uncontrolled internal "generated
>code / libgcc" interface;
> 
> 2) U-Boot won't interfere with non-aeabi-related stuff in GCC+libgcc,
>i.e. whatever ibgcc-related but non-AEABI-related changes occur in
>a GCC release, we won't break them changes in non-AEABI ;
> 
> 3) GCC+libgcc won't interfere with AEABI any more, i.e. whatever AEABI
>breakages happen in a given GCC toolchain will not break U-Boot.
> 
> 4) This design works with any ARM toolchain -- which is kind of evident
>since it separates generic ARM EABI support from specific toolchain
>support.

Addition: this does not mean we should get rid of the private libgcc
support: it can be useful in case of an issue with the non-aeabi part
of libgcc.

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

Re: [U-Boot] [PATCH 5/5] lib: Enable private libgcc by default

[Albert ARIBAUD]

Hello Sergey,

On Thu, 24 Mar 2016 18:37:52 -0700 (PDT), Sergey Kubushyn
 wrote:
> On Thu, 24 Mar 2016, Tom Rini wrote:

> U-Boot is a standalone program not supposed to coexist with any external
> applications i.e. it is totally self-sufficient, not living in some kind of
> system environment so it makes perfect sense for it not to use _ANY_
> external parts in the final binary.

Granted U-Boot is standalone as a binary system component, but this
binary, as the produce of GCC, is dependent on libgcc for more than
simply AEABI support, hence my proposal.

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

Re: [U-Boot] [PATCH 5/5] lib: Enable private libgcc by default

[Albert ARIBAUD]

Hello Tom,

On Thu, 24 Mar 2016 20:49:42 -0400, Tom Rini  wrote:
> On Thu, Mar 24, 2016 at 08:50:03AM +0100, Albert ARIBAUD wrote:
> > Hello Tom,
> > 
> > On Wed, 23 Mar 2016 17:36:17 -0400, Tom Rini  wrote:
> > > On Wed, Mar 23, 2016 at 06:08:45PM +0100, Albert ARIBAUD wrote:
> > > > Hello Tom,
> > > > 
> > > > On Wed, 23 Mar 2016 09:22:38 -0400, Tom Rini  wrote:
> > > > > On Wed, Mar 23, 2016 at 01:53:35PM +0100, Albert ARIBAUD wrote:
> > > > > > Hello Marek,
> > > > > > 
> > > > > > On Sun, 20 Mar 2016 17:15:34 +0100, Marek Vasut  
> > > > > > wrote:
> > > > > > > This patch decouples U-Boot binary from the toolchain on systems 
> > > > > > > where
> > > > > > > private libgcc is available. Instead of pulling in functions 
> > > > > > > provided
> > > > > > > by the libgcc from the toolchain, U-Boot will use it's own set of 
> > > > > > > libgcc
> > > > > > > functions. These functions are usually imported from Linux 
> > > > > > > kernel, which
> > > > > > > also uses it's own libgcc functions instead of the ones provided 
> > > > > > > by the
> > > > > > > toolchain.
> > > > > > > 
> > > > > > > This patch solves a rather common problem. The toolchain can 
> > > > > > > usually
> > > > > > > generate code for many variants of target architecture and often 
> > > > > > > even
> > > > > > > different endianness. The libgcc on the other hand is usually 
> > > > > > > compiled
> > > > > > > for one particular configuration and the functions provided by it 
> > > > > > > may
> > > > > > > or may not be suited for use in U-Boot. This can manifest in two 
> > > > > > > ways,
> > > > > > > either the U-Boot fails to compile altogether and linker will 
> > > > > > > complain
> > > > > > > or, in the much worse case, the resulting U-Boot will build, but 
> > > > > > > will
> > > > > > > misbehave in very subtle and hard to debug ways.
> > > > > > 
> > > > > > I don't think using private libgcc by default is a good idea.
> > > > > > 
> > > > > > U-Boot's private libgcc is not a feature of U-Boot, but a fix for 
> > > > > > some
> > > > > > cases where a target cannot properly link with the libgcc provided 
> > > > > > by
> > > > > > the (specific release of the) GCC toolchain in use. Using private 
> > > > > > libgcc
> > > > > > to other cases than these does not fix or improve anything; those
> > > > > > other cases were working and did not require any fix in this 
> > > > > > respect. 
> > > > > 
> > > > > This isn't true, exactly.  If using clang for example everyone needs 
> > > > > to
> > > > > enable this code.  We're also using -fno-builtin -ffreestanding which
> > > > > should limit the amount of interference from the toolchain.  And we 
> > > > > get
> > > > > that.
> > > > 
> > > > You mean clang does not produce self-sustained binaries?
> > > 
> > > clang does not provide "libgcc", so there's no -lgcc providing all of
> > > the functions that are (today) in:
> > > _ashldi3.S _ashrdi3.S _divsi3.S  _lshrdi3.S _modsi3.S _udivsi3.S
> > > _umodsi3.S div0.S  _uldivmod.S
> > > which aside from __modsi3 and __umodsi3 are all __aeabi_xxx
> > 
> > (ok, that explains what you mean by AEABI functions -- those are
> > actually not functions defined by the AEABI, but functions that the GCC
> > folks prefixed with __aeabi.)
> 
> No.  For reference,
> http://infocenter.arm.com/help/topic/com.arm.doc.ihi0043d/IHI0043D_rtabi.pdf
> and chapter 4 is all about the support library.  We are entirely in our
> right to do either of (a) use the compiler-provided library (b) provide
> our own implementation of what we need.  The kernel opts for (b) and I
> would like us to follow that as well, consistently, rather than ad-hoc.

Kk, so you did not mean "whatever happens to be aeabi in libgcc, you
meant AEABI itself.

But then what you seek is is not a custom libgcc; it is controlled
AEABI support library.

I'm fine with that, since, contrary to libgcc, it has an external,
stable, definition.

But that is *unrelated* to libgcc, which is not described nor intended
as "AEABI support" -- libgcc exists in all architectures, even non-ARM,
and provides AEABI in the ARM case by accident -- or, more to the point,
by sub-optimal design IMO.

The right design for solving the problems raised by Marek is therefore
to rename U-Boot's "custom libgcc" as U-Boot's "AEABI support library"
and link U-Boot *first* against this AEABI support library, *then*
against GCC's libgcc.

Essentially, this 'hijacks' whatever is AEABI from libgcc while not
interfering with what is not AEABI (i.e. what is purely GCC/libgcc
internals).

That way,

0) U-Boot gets the stable and controlled AEABI support you want;

1) GCC keeps its somewhat stable but uncontrolled internal "generated
   code / libgcc" interface;

2) U-Boot won't interfere with non-aeabi-related stuff in GCC+libgcc,
   i.e. whatever ibgcc-related but non-AEABI-related changes occur in
   a GCC release, we won't break them 

[U-Boot] [PATCH V3] fsl: esdhc: support driver model

[Peng Fan]

Support Driver Model for fsl esdhc driver.

1. Introduce a new structure struct fsl_esdhc_priv
2. Refactor fsl_esdhc_initialize which is originally used by board code.
   - Introduce fsl_esdhc_init to be common usage for DM and non-DM
   - Introduce fsl_esdhc_cfg_to_priv to build the bridge for non-DM part.
   - The original API for board code is still there, but we use
 'fsl_esdhc_cfg_to_priv' and 'fsl_esdhc_init' to serve it.
3. All the functions are changed to use 'struct fsl_esdhc_priv', except
   fsl_esdhc_initialize.
4. Since clk driver is not implemented, use mxc_get_clock to geth
   the clk and fill 'priv->sdhc_clk'.

Has been tested on i.MX6UL 14X14 EVK board:
"
=>dm tree

 simple_bus  [ + ]|   `-- aips-bus@0210
  mmc[ + ]|   |-- usdhc@0219
  mmc[ + ]|   |-- usdhc@02194000

=> mmc list
FSL_SDHC: 0 (SD)
FSL_SDHC: 1 (SD)
"

Signed-off-by: Peng Fan 
Cc: York Sun 
Cc: Yangbo Lu 
Cc: Hector Palacios 
Cc: Eric Nelson 
Cc: Stefano Babic 
Cc: Fabio Estevam 
Cc: Pantelis Antoniou 
Cc: Simon Glass 
---

V3:
 Fix build error reported by York for PPC.

V2:
 restructure the V1 patch.
 Introduce fsl_esdhc_priv structure.
 Introduce code to handle cd-gpios and non-removable.

 drivers/mmc/fsl_esdhc.c | 253 
 1 file changed, 213 insertions(+), 40 deletions(-)

diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c
index ea5f4bf..3acf9e8 100644
--- a/drivers/mmc/fsl_esdhc.c
+++ b/drivers/mmc/fsl_esdhc.c
@@ -20,6 +20,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -72,6 +74,30 @@ struct fsl_esdhc {
uintscr;/* eSDHC control register */
 };
 
+/**
+ * struct fsl_esdhc_priv
+ *
+ * @esdhc_regs: registers of the sdhc controller
+ * @sdhc_clk: Current clk of the sdhc controller
+ * @bus_width: bus width, 1bit, 4bit or 8bit
+ * @cfg: mmc config
+ * @mmc: mmc
+ * Following is used when Driver Model is enabled for MMC
+ * @dev: pointer for the device
+ * @non_removable: 0: removable; 1: non-removable
+ * @cd_gpio: gpio for card detection
+ */
+struct fsl_esdhc_priv {
+   struct fsl_esdhc *esdhc_regs;
+   unsigned int sdhc_clk;
+   unsigned int bus_width;
+   struct mmc_config cfg;
+   struct mmc *mmc;
+   struct udevice *dev;
+   int non_removable;
+   struct gpio_desc cd_gpio;
+};
+
 /* Return the XFERTYP flags for a given command and data packet */
 static uint esdhc_xfertyp(struct mmc_cmd *cmd, struct mmc_data *data)
 {
@@ -118,8 +144,8 @@ static uint esdhc_xfertyp(struct mmc_cmd *cmd, struct 
mmc_data *data)
 static void
 esdhc_pio_read_write(struct mmc *mmc, struct mmc_data *data)
 {
-   struct fsl_esdhc_cfg *cfg = mmc->priv;
-   struct fsl_esdhc *regs = (struct fsl_esdhc *)cfg->esdhc_base;
+   struct fsl_esdhc_priv *priv = mmc->priv;
+   struct fsl_esdhc *regs = priv->esdhc_regs;
uint blocks;
char *buffer;
uint databuf;
@@ -180,8 +206,8 @@ esdhc_pio_read_write(struct mmc *mmc, struct mmc_data *data)
 static int esdhc_setup_data(struct mmc *mmc, struct mmc_data *data)
 {
int timeout;
-   struct fsl_esdhc_cfg *cfg = mmc->priv;
-   struct fsl_esdhc *regs = (struct fsl_esdhc *)cfg->esdhc_base;
+   struct fsl_esdhc_priv *priv = mmc->priv;
+   struct fsl_esdhc *regs = priv->esdhc_regs;
 #ifdef CONFIG_FSL_LAYERSCAPE
dma_addr_t addr;
 #endif
@@ -312,8 +338,8 @@ esdhc_send_cmd(struct mmc *mmc, struct mmc_cmd *cmd, struct 
mmc_data *data)
int err = 0;
uintxfertyp;
uintirqstat;
-   struct fsl_esdhc_cfg *cfg = mmc->priv;
-   volatile struct fsl_esdhc *regs = (struct fsl_esdhc *)cfg->esdhc_base;
+   struct fsl_esdhc_priv *priv = mmc->priv;
+   struct fsl_esdhc *regs = priv->esdhc_regs;
 
 #ifdef CONFIG_SYS_FSL_ERRATUM_ESDHC111
if (cmd->cmdidx == MMC_CMD_STOP_TRANSMISSION)
@@ -482,9 +508,9 @@ out:
 static void set_sysctl(struct mmc *mmc, uint clock)
 {
int div, pre_div;
-   struct fsl_esdhc_cfg *cfg = mmc->priv;
-   volatile struct fsl_esdhc *regs = (struct fsl_esdhc *)cfg->esdhc_base;
-   int sdhc_clk = cfg->sdhc_clk;
+   struct fsl_esdhc_priv *priv = mmc->priv;
+   struct fsl_esdhc *regs = priv->esdhc_regs;
+   int sdhc_clk = priv->sdhc_clk;
uint clk;
 
if (clock < mmc->cfg->f_min)
@@ -527,8 +553,8 @@ static void set_sysctl(struct mmc *mmc, uint clock)
 #ifdef CONFIG_FSL_ESDHC_USE_PERIPHERAL_CLK
 static void esdhc_clock_control(struct mmc *mmc, bool enable)
 {
-   struct fsl_esdhc_cfg *cfg = mmc->priv;
-   struct fsl_esdhc *regs = (struct fsl_esdhc *)cfg->esdhc_base;
+   struct fsl_esdhc_priv *priv = mmc->priv;
+   struct fsl_esdhc *regs