Re: [PATCH v2] usb: gadget: ether: split start/stop from init/halt

[Kevin Hilman]

Niel Fourie  writes:

> Split out _usb_eth_start() from _usb_eth_init() and
> usb_eth_stop() from _usb_eth_halt(). Now _usb_eth_init() only
> initialises and registers the gadget device, which _usb_eth_halt()
> reverses, and together are used for probing and removing the
> device. The _usb_eth_start() and _usb_eth_stop() functions connect
> and disconnect the gadget as expected by the start()/stop()
> callbacks.
>
> Previously the gadget device was probed on every start() and
> removed on every stop(), which is inconsistent with other DM_ETH
> drivers.

By suggestion from Marek, I was testing this patch and discovered that
it broke fastboot over USB support.  With this patch applied on top of
v2022.10, I'm seeing:

=> fastboot 0
couldn't find an available UDC
g_dnl_register: failed!, error: -19

Kevin

Re: [PATCH 4/4] board: amlogic: vim3: add support for dynamic PCIe enable

[Kevin Hilman]

Neil Armstrong  writes:

> The VIM3 on-board  MCU can mux the PCIe/USB3.0 shared differential
> lines using a FUSB340TMX USB 3.1 SuperSpeed Data Switch between
> an USB3.0 Type A connector and a M.2 Key M slot.
> The PHY driving these differential lines is shared between
> the USB3.0 controller and the PCIe Controller, thus only
> a single controller can use it.
>
> This adds this dynamic switching right before booting Linux.
>
> Signed-off-by: Neil Armstrong 
> ---
>  board/amlogic/vim3/vim3.c  | 116 +
>  configs/khadas-vim3_defconfig  |   3 +
>  configs/khadas-vim3l_defconfig |   3 +
>  3 files changed, 122 insertions(+)
>
> diff --git a/board/amlogic/vim3/vim3.c b/board/amlogic/vim3/vim3.c
> index 02d8cd0ce0..cf730fa0d1 100644
> --- a/board/amlogic/vim3/vim3.c
> +++ b/board/amlogic/vim3/vim3.c
> @@ -11,6 +11,122 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include "khadas-mcu.h"

This file doesn't exist in this series, so it doesn't compile.

Copying it from Linux, it compiles and works fine.

Kevin

Re: [PATCH 0/4] amlogic: vim3: add support for dynamic PCIe enable

[Kevin Hilman]

Neil Armstrong  writes:

> The VIM3 on-board  MCU can mux the PCIe/USB3.0 shared differential
> lines using a FUSB340TMX USB 3.1 SuperSpeed Data Switch between
> an USB3.0 Type A connector and a M.2 Key M slot.
> The PHY driving these differential lines is shared between
> the USB3.0 controller and the PCIe Controller, thus only
> a single controller can use it.
>
> This serie adds a VIM3 specific board support and adds this dynamic
> switching right before booting Linux.

Reviewed-by: Kevin Hilman 
Tested-by: Kevin Hilman 

Tested on khadas vim3

Kevin

Re: [PATCH 0/2] amlogic: add Khadas VIM3L support

[Kevin Hilman]

Christian Hewitt  writes:

> Khadas VIM3L is a new revision of the VIM3 board that swaps the premium
> A311D chip for Amlogic's mid-range S905D3 chip.

Tested-by: Kevin Hilman 

Re: [U-Boot] Using kernelCI infrastructure for firmware testing

[Kevin Hilman]

"Patrick Rudolph"  writes:

> Hi folks,
> this is an attempt to improve firmware testing by using the
> infrastructure and knowledge of the kernelci community. If you think
> this is not the right place, please point me in the right direction.
>
> I'm a coreboot[1] developer trying to make sure that the master
> branch[2] doesn't regress. Currently there's no public firmware
> testing, only internal validation suites used by some companies that
> lack direct and automated feedback before a commit is actually merged.
> As this isn't a coreboot only topic, but applies to all open source
> "bios vendors", I added the u-boot project in CC as well.
>
> For me firmware testing looks pretty similar to kernel testing:
> * flash firmware to test
> * boot a known good linux kernel
> * run tests in userspace and verify hardware/software works as expected
>
> On the hardware side we have boards in our lab that allow remote power
> cycling and firmware flashing. It is attached to self hosted stock
> LAVA2018. But as we are firmware engineers, we don't want to deal with
> the administration of servers.
>
> Here are a few questions for you:
> * Would it make sense to also cover open source firmware tests on kernelci?

Yes.  We've talked about this a few times over the years, and all the
infra and tooling we have built for kernelCI would be well suited for
firmware testing.

The catch is mostly in time/resources invested.  For now, we are
primarily focused on kernel testing, but if there are contributors that
want to extend this to firmware, we are an open-source project and
welcome the contributions.

I would say the primary challenge here is that each SoC family, and
sometimes even each board has unique challenges to (re)flashing the
firmware as well as the ability to recover from non-working firmware.

This presents a problem not necessariuly for KernelCI but for the lab
admins for that hardware, and especially those writing the LAVA
device-types for those platforms.

I've added the main LAVA developer Remi Durrafort to Cc since he's been
doing a lot of work in LAVA to make firmware updates and recovery mode
usable from LAVA.  Recent versions of LAVA seem to be growing better
support for this:
https://docs.lavasoftware.org/lava/bootloaders.html

> * Do you build the linux images yourself?

We build all the linux kernel images, but rely on the lab admins to have
build/flashed working firmware and bootloaders.

> * Would you accept firmware images generated by a third party?

As long as the source is available and can be (re)built, that's
typically fine.

> * Can anybody get an account for the LAVA server to run firmware test?

That's up to each LAVA lab administrator.  Today, KernelCI uses a
distributed set of (mostly LAVA) labs.  Each lab admin has given
priveleges to KernelCI to send jobs.

> * What communication channels do you recommend?

This mailing list is a good place to start, but to be completely
honest, firmware testing is relatively low on our current list of
priorites.  But as I said above, it's feature we will welcome with open
arms, even if it's not a feature that the current set of developers will
be very active on.

I would say your first step is probably to get some support for the
devices you care about into upstream LAVA.  Once that is working, we
would work on how KernelCI could start generating jobs for those devices.

> * Will there be meetings or conferences to get in contact with the
> community to talk about this?

We just had an automated-testing summit connected to Embedded Linux
Conference Europe last month, where many of us were gathered.

Remi even gave a talk on bootloader testing with LAVA, maybe he can
share the slides for that.

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

Re: [U-Boot] [PATCH v7 00/15] SiFive FU540 Support

[Kevin Hilman]

On Fri, Apr 19, 2019 at 1:38 PM Kevin Hilman  wrote:
>
> Atish Patra  writes:
>
> > On 4/18/19 4:16 PM, Kevin Hilman wrote:
> >> Atish Patra  writes:
> >>
> >>> On 4/18/19 12:15 PM, Kevin Hilman wrote:
> >>>> Palmer, Anup,
> >>>>
> >>>> On Tue, Mar 12, 2019 at 1:55 AM Palmer Dabbelt  wrote:
> >>>>>
> >>>>> On Mon, 11 Mar 2019 07:33:25 PDT (-0700), bmeng...@gmail.com wrote:
> >>>>>> On Thu, Feb 14, 2019 at 7:58 AM Kevin Hilman  
> >>>>>> wrote:
> >>>>>>>
> >>>>>>> Kevin Hilman  writes:
> >>>>>>>
> >>>>>>>> Hi Anup,
> >>>>>>>>
> >>>>>>>> Anup Patel  writes:
> >>>>>>>>
> >>>>>>>>> This patchset adds SiFive Freedom Unleashed (FU540) support
> >>>>>>>>> to RISC-V U-Boot.
> >>>>>>>>>
> >>>>>>>>> The patches are based upon latest U-Boot source tree
> >>>>>>>>> (git://git.denx.de/u-boot.git) at commit id
> >>>>>>>>> dbe70c7d4e3d5c705a98d82952e05a591efd0683
> >>>>>>>>>
> >>>>>>>>> All drivers namely: SiFive PRCI, SiFive Serial, and Cadance
> >>>>>>>>> MACB Ethernet work fine on actual SiFive Unleashed board and
> >>>>>>>>> QEMU sifive_u machine.
> >>>>>>>>
> >>>>>>>> I tested u-boot networking (DHCP, TFTP) on my desk with a gigE switch
> >>>>>>>> and it worked fine.  Then, I moved it to a lab with a 100Mb switch,
> >>>>>>>> and DHCP doesn't work anymore.
> >>>>>>>
> >>>>>>> And to be clear, neither does TFTP if setting static
> >>>>>>> ipaddr/netmask/gatewayip etc.
> >>>>>>
> >>>>>> Sound to me a bug of the GEM driver on SiFive FU540 board.
> >>>>>
> >>>>> It looks to me like u-boot is missing a driver for the GEM clockmux in 
> >>>>> the
> >>>>> FU540.  This is necessary to switch between the clock for 1G operation 
> >>>>> and 100M
> >>>>> operation.  Without this you'll just get whatever clock was set up by 
> >>>>> the
> >>>>> previous boot stage (or even worse, reset).
> >>>>
> >>>> Anyone know if this is fixed in u-boot yet?  I've yet to try the
> >>>> latest mainline u-boot, but will if if it's expected to work.
> >>>>
> >>>
> >>> I have not seen a GEM driver for FU540 board. So I guess it is not fixed
> >>> it. Is it a blocker for setting up kernelCI for RISC-V ?
> >>
> >> Not really, that's only one of the remaining issue. For now, I have
> >> connected it to a gigE switch, so u-boot networking is working.
> >>
> >> But, the bigger blocker for kernelCI right now is not having
> >> out-of-the-box mainline support.  Mainline is still missing a serial
> >> driver, and a handful of Kconfig options in the default defconfig to
> >> make things boot[1].
> >>
> >> If I use the 'v5.1-rc4_unleashed' from your github, along with my
> >> kconfig fragment[1], things are working well.
> >>
> >> But in order to automate this for kernelCI, we need all of that
> >> upstream.
> >>
> > Yeah. I agree. We need upstream drivers sooner than later.
> > I believe SiFive Team (Paul & co) are working on this.
> >
> > He recently sent updated version of driver patches to the linux-riscv
> > mailing list.
>
> Yes, I'm trying to test all of those (hence our other discussion on the
> DT thread)
>
> >> [1] This is the config fragment I'm adding to the default defconfig in
> >> mainline.  I'm not exactly sure which ones are absolutely need for basic
> >> boot.
> >>
> >> CONFIG_SERIAL_SIFIVE=y
> >> CONFIG_SERIAL_SIFIVE_CONSOLE=y
> >> CONFIG_SIFIVE_PLIC=y
> >> CONFIG_SPI=y
> >> CONFIG_SPI_SIFIVE=y
> >> CONFIG_GPIOLIB=y
> >> CONFIG_GPIO_SIFIVE=y
> >> CONFIG_PWM_SIFIVE=y
> >> CONFIG_CLK_U54_PRCI=y
> >> CONFIG_CLK_GEMGXL_MGMT=y
> >>
> >
> > My working config has enabled all of the above except CONFIG_PWM_SIFIVE.
> > I have not played around the config that much to find out absolute
> > minimum config. So this may not be the answer you are looking for :).
>
> At least for kernelCI, we'll need to figure that out and get it upstream
> if we want to boot test these.

Oh, and one other u-boot question.

Any reason you didn't enable `booti` support in riscv u-boot?  That
would allow you to boot the Image (or Image.gz) directly, instead of
the need to create a special image with u-boot header (uImage)

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

Re: [U-Boot] [PATCH v7 00/15] SiFive FU540 Support

[Kevin Hilman]

Atish Patra  writes:

> On 4/18/19 4:16 PM, Kevin Hilman wrote:
>> Atish Patra  writes:
>> 
>>> On 4/18/19 12:15 PM, Kevin Hilman wrote:
>>>> Palmer, Anup,
>>>>
>>>> On Tue, Mar 12, 2019 at 1:55 AM Palmer Dabbelt  wrote:
>>>>>
>>>>> On Mon, 11 Mar 2019 07:33:25 PDT (-0700), bmeng...@gmail.com wrote:
>>>>>> On Thu, Feb 14, 2019 at 7:58 AM Kevin Hilman  
>>>>>> wrote:
>>>>>>>
>>>>>>> Kevin Hilman  writes:
>>>>>>>
>>>>>>>> Hi Anup,
>>>>>>>>
>>>>>>>> Anup Patel  writes:
>>>>>>>>
>>>>>>>>> This patchset adds SiFive Freedom Unleashed (FU540) support
>>>>>>>>> to RISC-V U-Boot.
>>>>>>>>>
>>>>>>>>> The patches are based upon latest U-Boot source tree
>>>>>>>>> (git://git.denx.de/u-boot.git) at commit id
>>>>>>>>> dbe70c7d4e3d5c705a98d82952e05a591efd0683
>>>>>>>>>
>>>>>>>>> All drivers namely: SiFive PRCI, SiFive Serial, and Cadance
>>>>>>>>> MACB Ethernet work fine on actual SiFive Unleashed board and
>>>>>>>>> QEMU sifive_u machine.
>>>>>>>>
>>>>>>>> I tested u-boot networking (DHCP, TFTP) on my desk with a gigE switch
>>>>>>>> and it worked fine.  Then, I moved it to a lab with a 100Mb switch,
>>>>>>>> and DHCP doesn't work anymore.
>>>>>>>
>>>>>>> And to be clear, neither does TFTP if setting static
>>>>>>> ipaddr/netmask/gatewayip etc.
>>>>>>
>>>>>> Sound to me a bug of the GEM driver on SiFive FU540 board.
>>>>>
>>>>> It looks to me like u-boot is missing a driver for the GEM clockmux in the
>>>>> FU540.  This is necessary to switch between the clock for 1G operation 
>>>>> and 100M
>>>>> operation.  Without this you'll just get whatever clock was set up by the
>>>>> previous boot stage (or even worse, reset).
>>>>
>>>> Anyone know if this is fixed in u-boot yet?  I've yet to try the
>>>> latest mainline u-boot, but will if if it's expected to work.
>>>>
>>>
>>> I have not seen a GEM driver for FU540 board. So I guess it is not fixed
>>> it. Is it a blocker for setting up kernelCI for RISC-V ?
>> 
>> Not really, that's only one of the remaining issue. For now, I have
>> connected it to a gigE switch, so u-boot networking is working.
>> 
>> But, the bigger blocker for kernelCI right now is not having
>> out-of-the-box mainline support.  Mainline is still missing a serial
>> driver, and a handful of Kconfig options in the default defconfig to
>> make things boot[1].
>> 
>> If I use the 'v5.1-rc4_unleashed' from your github, along with my
>> kconfig fragment[1], things are working well.
>> 
>> But in order to automate this for kernelCI, we need all of that
>> upstream.
>> 
> Yeah. I agree. We need upstream drivers sooner than later.
> I believe SiFive Team (Paul & co) are working on this.
>
> He recently sent updated version of driver patches to the linux-riscv 
> mailing list.

Yes, I'm trying to test all of those (hence our other discussion on the
DT thread)

>> [1] This is the config fragment I'm adding to the default defconfig in
>> mainline.  I'm not exactly sure which ones are absolutely need for basic
>> boot.
>> 
>> CONFIG_SERIAL_SIFIVE=y
>> CONFIG_SERIAL_SIFIVE_CONSOLE=y
>> CONFIG_SIFIVE_PLIC=y
>> CONFIG_SPI=y
>> CONFIG_SPI_SIFIVE=y
>> CONFIG_GPIOLIB=y
>> CONFIG_GPIO_SIFIVE=y
>> CONFIG_PWM_SIFIVE=y
>> CONFIG_CLK_U54_PRCI=y
>> CONFIG_CLK_GEMGXL_MGMT=y
>> 
>
> My working config has enabled all of the above except CONFIG_PWM_SIFIVE.
> I have not played around the config that much to find out absolute 
> minimum config. So this may not be the answer you are looking for :).

At least for kernelCI, we'll need to figure that out and get it upstream
if we want to boot test these.

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

Re: [U-Boot] [PATCH v7 00/15] SiFive FU540 Support

[Kevin Hilman]

Atish Patra  writes:

> On 4/18/19 12:15 PM, Kevin Hilman wrote:
>> Palmer, Anup,
>> 
>> On Tue, Mar 12, 2019 at 1:55 AM Palmer Dabbelt  wrote:
>>>
>>> On Mon, 11 Mar 2019 07:33:25 PDT (-0700), bmeng...@gmail.com wrote:
>>>> On Thu, Feb 14, 2019 at 7:58 AM Kevin Hilman  wrote:
>>>>>
>>>>> Kevin Hilman  writes:
>>>>>
>>>>>> Hi Anup,
>>>>>>
>>>>>> Anup Patel  writes:
>>>>>>
>>>>>>> This patchset adds SiFive Freedom Unleashed (FU540) support
>>>>>>> to RISC-V U-Boot.
>>>>>>>
>>>>>>> The patches are based upon latest U-Boot source tree
>>>>>>> (git://git.denx.de/u-boot.git) at commit id
>>>>>>> dbe70c7d4e3d5c705a98d82952e05a591efd0683
>>>>>>>
>>>>>>> All drivers namely: SiFive PRCI, SiFive Serial, and Cadance
>>>>>>> MACB Ethernet work fine on actual SiFive Unleashed board and
>>>>>>> QEMU sifive_u machine.
>>>>>>
>>>>>> I tested u-boot networking (DHCP, TFTP) on my desk with a gigE switch
>>>>>> and it worked fine.  Then, I moved it to a lab with a 100Mb switch,
>>>>>> and DHCP doesn't work anymore.
>>>>>
>>>>> And to be clear, neither does TFTP if setting static
>>>>> ipaddr/netmask/gatewayip etc.
>>>>
>>>> Sound to me a bug of the GEM driver on SiFive FU540 board.
>>>
>>> It looks to me like u-boot is missing a driver for the GEM clockmux in the
>>> FU540.  This is necessary to switch between the clock for 1G operation and 
>>> 100M
>>> operation.  Without this you'll just get whatever clock was set up by the
>>> previous boot stage (or even worse, reset).
>> 
>> Anyone know if this is fixed in u-boot yet?  I've yet to try the
>> latest mainline u-boot, but will if if it's expected to work.
>> 
>
> I have not seen a GEM driver for FU540 board. So I guess it is not fixed 
> it. Is it a blocker for setting up kernelCI for RISC-V ?

Not really, that's only one of the remaining issue. For now, I have
connected it to a gigE switch, so u-boot networking is working.

But, the bigger blocker for kernelCI right now is not having
out-of-the-box mainline support.  Mainline is still missing a serial
driver, and a handful of Kconfig options in the default defconfig to
make things boot[1].

If I use the 'v5.1-rc4_unleashed' from your github, along with my
kconfig fragment[1], things are working well.

But in order to automate this for kernelCI, we need all of that
upstream.

Kevin

[1] This is the config fragment I'm adding to the default defconfig in
mainline.  I'm not exactly sure which ones are absolutely need for basic
boot.

CONFIG_SERIAL_SIFIVE=y
CONFIG_SERIAL_SIFIVE_CONSOLE=y
CONFIG_SIFIVE_PLIC=y
CONFIG_SPI=y
CONFIG_SPI_SIFIVE=y
CONFIG_GPIOLIB=y
CONFIG_GPIO_SIFIVE=y
CONFIG_PWM_SIFIVE=y
CONFIG_CLK_U54_PRCI=y
CONFIG_CLK_GEMGXL_MGMT=y
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v7 00/15] SiFive FU540 Support

[Kevin Hilman]

Palmer, Anup,

On Tue, Mar 12, 2019 at 1:55 AM Palmer Dabbelt  wrote:
>
> On Mon, 11 Mar 2019 07:33:25 PDT (-0700), bmeng...@gmail.com wrote:
> > On Thu, Feb 14, 2019 at 7:58 AM Kevin Hilman  wrote:
> >>
> >> Kevin Hilman  writes:
> >>
> >> > Hi Anup,
> >> >
> >> > Anup Patel  writes:
> >> >
> >> >> This patchset adds SiFive Freedom Unleashed (FU540) support
> >> >> to RISC-V U-Boot.
> >> >>
> >> >> The patches are based upon latest U-Boot source tree
> >> >> (git://git.denx.de/u-boot.git) at commit id
> >> >> dbe70c7d4e3d5c705a98d82952e05a591efd0683
> >> >>
> >> >> All drivers namely: SiFive PRCI, SiFive Serial, and Cadance
> >> >> MACB Ethernet work fine on actual SiFive Unleashed board and
> >> >> QEMU sifive_u machine.
> >> >
> >> > I tested u-boot networking (DHCP, TFTP) on my desk with a gigE switch
> >> > and it worked fine.  Then, I moved it to a lab with a 100Mb switch,
> >> > and DHCP doesn't work anymore.
> >>
> >> And to be clear, neither does TFTP if setting static
> >> ipaddr/netmask/gatewayip etc.
> >
> > Sound to me a bug of the GEM driver on SiFive FU540 board.
>
> It looks to me like u-boot is missing a driver for the GEM clockmux in the
> FU540.  This is necessary to switch between the clock for 1G operation and 
> 100M
> operation.  Without this you'll just get whatever clock was set up by the
> previous boot stage (or even worse, reset).

Anyone know if this is fixed in u-boot yet?  I've yet to try the
latest mainline u-boot, but will if if it's expected to work.

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

Re: [U-Boot] [PATCH v7 00/15] SiFive FU540 Support

[Kevin Hilman]

Kevin Hilman  writes:

> Hi Anup,
>
> Anup Patel  writes:
>
>> This patchset adds SiFive Freedom Unleashed (FU540) support
>> to RISC-V U-Boot.
>>
>> The patches are based upon latest U-Boot source tree
>> (git://git.denx.de/u-boot.git) at commit id
>> dbe70c7d4e3d5c705a98d82952e05a591efd0683
>>
>> All drivers namely: SiFive PRCI, SiFive Serial, and Cadance
>> MACB Ethernet work fine on actual SiFive Unleashed board and
>> QEMU sifive_u machine.
>
> I tested u-boot networking (DHCP, TFTP) on my desk with a gigE switch
> and it worked fine.  Then, I moved it to a lab with a 100Mb switch,
> and DHCP doesn't work anymore.

And to be clear, neither does TFTP if setting static
ipaddr/netmask/gatewayip etc.

Kevin


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

Re: [U-Boot] [PATCH v7 00/15] SiFive FU540 Support

[Kevin Hilman]

Hi Anup,

Anup Patel  writes:

> This patchset adds SiFive Freedom Unleashed (FU540) support
> to RISC-V U-Boot.
>
> The patches are based upon latest U-Boot source tree
> (git://git.denx.de/u-boot.git) at commit id
> dbe70c7d4e3d5c705a98d82952e05a591efd0683
>
> All drivers namely: SiFive PRCI, SiFive Serial, and Cadance
> MACB Ethernet work fine on actual SiFive Unleashed board and
> QEMU sifive_u machine.

I tested u-boot networking (DHCP, TFTP) on my desk with a gigE switch
and it worked fine.  Then, I moved it to a lab with a 100Mb switch,
and DHCP doesn't work anymore.

Can you do some sanity testing with a 100Mb switch?

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

Re: [U-Boot] [PATCH v7 14/15] doc: Add a readme guide for SiFive FU540

[Kevin Hilman]

Atish Patra  writes:

>> On Feb 12, 2019, at 4:18 PM, Kevin Hilman  wrote:
>> 
>> Anup Patel  writes:
>> 
>>> From: Atish Patra 
>>> 
>>> The readme guide describes the procedure to build, flash and boot Linux
>>> using U-Boot on HiFive Unleashed. It also explains the current state of
>>> U-boot support and future action items.
>>> 
>>> Signed-off-by: Atish Patra 
>>> Signed-off-by: Anup Patel 
>>> Reviewed-by: Lukas Auer 
>> 
>> I'm testing this with the mainline kernel (v5.0-rc6) and running into
>> some problems getting kernel output on the serial console.
>> 
>
> Unfortunately. 
>

[...]

>> First question: this doc doesn't explain how there is a DT at
>> 0x8220, and what it contains.
>> 
>
> DT is being passed from the previous stage boot loader to OpenSBI and OpenSBI 
> passed it to U-Boot
> after modifying few entries (hart masks and plic entries).
>
> There is a way to provide custom DT in OpenSBI as well.

And if u-boot were load (or TFTP) a custom DT, this should work too,
right?

>> Trying this with a freshly build u-boot payload with OpenSBI, bootm
>> seems to detect a DT there, but I don't understand how it got there, or
>> what it is in it.
>> 
>> Looking a little closer, it appears that this DT (and the address) is
>> hard-coded in the OpenSBI code.  This should proably be documented here
>> for clarity sake.
>> 
>
> I will update the document to add more clarity.

Thanks.

>>> +## Booting kernel from Legacy Image at 8020 ...
>>> +   Image Name:   Linux
>>> +   Image Type:   RISC-V Linux Kernel Image (uncompressed)
>>> +   Data Size:14939068 Bytes = 14.2 MiB
>>> +   Load Address: 8020
>>> +   Entry Point:  8020
>>> +   Verifying Checksum ... OK
>>> +## Flattened Device Tree blob at 8220
>>> +   Booting using the fdt blob at 0x8220
>>> +   Loading Kernel Image ... OK
>>> +   Using Device Tree in place at 8220, end 82205c69
>>> +
>>> +Starting kernel ...
>> 
>> Next, I'm able to DHCP and TFTP my uImage just like above, but I don't
>> see any output on the console after the "Starting kernel".
>> 
>> That suggests that whatever DT is present there doesn't have the right
>> settings for the serial console.
>> 
>> I tried setting the u-boot bootargs to "console=ttySIF0 earlyprintk",
>> but I'm still seeing nothing on the console.
>> 
>> Dumping the hard-coded OpenSBI DT from u-boot[1], it seem that the
>> chosen node has the right value (as documented in this patch):
>> 
>> Hmm, maybe I'm missing the obvious... is there even an upstream serial
>> driver for this UART in v5.0-rc6...  (/me goes searching for the
>> compatible)... hmm, doesn't look like it.
>> 
>
> Unfortunately, all the drivers for unleashed are not upstreamed yet. It is a 
> mess and hopefully it will be resolved soon.
>
>>> +[0.00] OF: fdt: Ignoring memory range 0x8000 - 0x8020
>>> +[0.00] Linux version 5.0.0-rc1-00020-g4b51f736 (atish@jedi-01) 
>>> (gcc version 7.2.0 (GCC)) #262 SMP Mon Jan 21 17:39:27 PST 2019
>> 
>> Looks like you're testing with a handful of out-of-tree kernel patches.
>> Can you give a pointer to where you're building your kernel from?
>> 
>
> Here is my branch based on 5.0-rc5 that should work.

Yes, building a kernel from there, using the config options you
mentioned works.  Thanks.

> https://github.com/atishp04/linux/  v5.0-rc5_unleashed_uboot
>
> 1-8 patches are mostly SMP fixes and currently under review. They should be 
> part of next merge window.
> --
> 1. 4a0edc9b RISC-V: Assign hwcap as per comman capabilities.
> 2. c29e4afa irqchip/irq-sifive-plic: Check and continue in case of an invalid 
> cpuid.
> 3. 6c191098 clocksource/drivers/riscv: Add required checks during clock 
> source init
> 4. d89bfcf6 RISC-V: Compare cpuid with NR_CPUS before mapping.
> 5. 474cb3e3 RISC-V: Allow hartid-to-cpuid function to fail.
> 6. 5e07a2f4 RISC-V: Remove NR_CPUs check during hartid search from DT
> 7. cf5f2ec6 RISC-V: Move cpuid to hartid mapping to SMP.
> 8. 7838fe36 RISC-V: Do not wait indefinitely in __cpu_up
> --
>
> The real mess is the following driver patches for unleashed board. 
>
> 9. d46dc16f spi: sifive: no dma hack
> 10. e8ea1346 spi: add driver for the SiFive

Re: [U-Boot] [PATCH v7 14/15] doc: Add a readme guide for SiFive FU540

[Kevin Hilman]

Anup Patel  writes:

> From: Atish Patra 
>
> The readme guide describes the procedure to build, flash and boot Linux
> using U-Boot on HiFive Unleashed. It also explains the current state of
> U-boot support and future action items.
>
> Signed-off-by: Atish Patra 
> Signed-off-by: Anup Patel 
> Reviewed-by: Lukas Auer 

I'm testing this with the mainline kernel (v5.0-rc6) and running into
some problems getting kernel output on the serial console.

[...]

> +=> setenv ethaddr 70:B3:D5:92:F0:C2
> +=> setenv ipaddr 10.196.157.189
> +=> setenv serverip 10.11.143.218
> +=> setenv gatewayip 10.196.156.1
> +=> setenv netmask 255.255.252.0
> +=> bdinfo
> +boot_params = 0x
> +DRAM bank   = 0x
> +-> start= 0x8000
> +-> size = 0x0002
> +relocaddr   = 0xfff9
> +reloc off   = 0x7fd9
> +ethaddr = 70:B3:D5:92:F0:C2
> +IP addr = 10.196.157.189
> +baudrate= 115200 bps
> +=> tftpboot uImage
> +ethernet@1009: PHY present at 0
> +ethernet@1009: Starting autonegotiation...
> +ethernet@1009: Autonegotiation complete
> +ethernet@1009: link up, 1000Mbps full-duplex (lpa: 0x3800)
> +Using ethernet@1009 device
> +TFTP from server 10.11.143.218; our IP address is 10.196.157.189; sending 
> through gateway 10.196.156.1
> +Filename 'uImage'.
> +Load address: 0x8020
> +Loading: #
> + #
> + #
> + #
> + #
> + #
> + #
> + #
> + #
> + #
> + #
> + #
> + #
> + #
> + #
> + #
> + #
> + #
> + #
> + #
> + #
> + #
> + #
> + #
> + #
> + #
> + #
> + #
> + #
> + #
> + #
> + #
> + #
> + #
> + #
> + #
> + #
> + #
> + #
> + #
> + #
> + #
> + #
> + #
> + ##
> + 2.5 MiB/s
> +done
> +Bytes transferred = 14939132 (e3f3fc hex)
> +=> bootm 0x8020 - 0x8220

Re: [U-Boot] [PATCH] pinctrl: meson: axg: Fix GPIO pin offsets

[Kevin Hilman]

Carlo Caione  writes:

> The pin number (first and last) in the bank definition is missing the
> pin base offset shifting. This is causing a miscalculation when
> retrieving the register and pin offsets in the GPIO driver causing the
> 'gpio' command to drive the wrong pins / GPIOs in the second GPIO chip
> (the AO bank is driven correctly because the shifting is already 0).
>
> Signed-off-by: Carlo Caione 

This looks like it could use a Fixes: tag for stable.

Kevin

> ---
>  drivers/pinctrl/meson/pinctrl-meson-axg.c | 22 +++---
>  1 file changed, 11 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/pinctrl/meson/pinctrl-meson-axg.c 
> b/drivers/pinctrl/meson/pinctrl-meson-axg.c
> index a54fbce910..3bbbe817b4 100644
> --- a/drivers/pinctrl/meson/pinctrl-meson-axg.c
> +++ b/drivers/pinctrl/meson/pinctrl-meson-axg.c
> @@ -14,7 +14,7 @@
>  
>  #include "pinctrl-meson-axg.h"
>  
> -#define EE_OFF   14
> +#define EE_OFF   15
>  
>  /* emmc */
>  static const unsigned int emmc_nand_d0_pins[] = {BOOT_0};
> @@ -893,17 +893,17 @@ static struct meson_pmx_func 
> meson_axg_aobus_functions[] = {
>  };
>  
>  static struct meson_bank meson_axg_periphs_banks[] = {
> - /*   namefirst  last  pullen  pulldir out in  */
> - BANK("Z",GPIOZ_0,   GPIOZ_10, 3,  0,  3,  0,  9,  0,  10, 0,  11, 
> 0),
> - BANK("BOOT", BOOT_0,BOOT_14,  4,  0,  4,  0,  12, 0,  13, 0,  14, 
> 0),
> - BANK("A",GPIOA_0,   GPIOA_20, 0,  0,  0,  0,  0,  0,  1,  0,  2,  
> 0),
> - BANK("X",GPIOX_0,   GPIOX_22, 2,  0,  2,  0,  6,  0,  7,  0,  8,  
> 0),
> - BANK("Y",GPIOY_0,   GPIOY_15, 1,  0,  1,  0,  3,  0,  4,  0,  5,  
> 0),
> + /*   namefirst  lastpullen  
> pulldir out in  */
> + BANK("Z",PIN(GPIOZ_0, EE_OFF),  PIN(GPIOZ_10, EE_OFF), 3,  0,  
> 3,  0,  9,  0,  10, 0,  11, 0),
> + BANK("BOOT", PIN(BOOT_0, EE_OFF),   PIN(BOOT_14, EE_OFF),  4,  0,  
> 4,  0,  12, 0,  13, 0,  14, 0),
> + BANK("A",PIN(GPIOA_0, EE_OFF),  PIN(GPIOA_20, EE_OFF), 0,  0,  
> 0,  0,  0,  0,  1,  0,  2,  0),
> + BANK("X",PIN(GPIOX_0, EE_OFF),  PIN(GPIOX_22, EE_OFF), 2,  0,  
> 2,  0,  6,  0,  7,  0,  8,  0),
> + BANK("Y",PIN(GPIOY_0, EE_OFF),  PIN(GPIOY_15, EE_OFF), 1,  0,  
> 1,  0,  3,  0,  4,  0,  5,  0),
>  };
>  
>  static struct meson_bank meson_axg_aobus_banks[] = {
> - /*   namefirst  last   pullen  pulldir out in  
> */
> - BANK("AO",   GPIOAO_0,  GPIOAO_13, 0,  16,  0, 0,  0,  0,  0, 16,  1,  
> 0),
> + /*   namefirst  last  pullen  pulldir   
>   out in  */
> + BANK("AO",   PIN(GPIOAO_0, 0),  PIN(GPIOAO_13, 0), 0,  16,  0, 0,  0,  
> 0,  0, 16,  1,  0),
>  };
>  
>  static struct meson_pmx_bank meson_axg_periphs_pmx_banks[] = {
> @@ -931,11 +931,11 @@ static struct meson_axg_pmx_data 
> meson_axg_aobus_pmx_banks_data = {
>  
>  struct meson_pinctrl_data meson_axg_periphs_pinctrl_data = {
>   .name   = "periphs-banks",
> - .pin_base   = 11,
> + .pin_base   = 15,
>   .groups = meson_axg_periphs_groups,
>   .funcs  = meson_axg_periphs_functions,
>   .banks  = meson_axg_periphs_banks,
> - .num_pins   = 100,
> + .num_pins   = 86,
>   .num_groups = ARRAY_SIZE(meson_axg_periphs_groups),
>   .num_funcs  = ARRAY_SIZE(meson_axg_periphs_functions),
>   .num_banks  = ARRAY_SIZE(meson_axg_periphs_banks),
> -- 
> 2.19.1
>
>
> ___
> linux-amlogic mailing list
> linux-amlo...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-amlogic
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] binman: Put our local modules ahead of system modules

[Kevin Hilman]

Simon Glass <s...@chromium.org> writes:

> If a system module is named the same as one of those used by binman we
> currently pick the system module. Adjust the ordering so that our modules
> are chosen instead.
>
> The module conflict reported was 'tools' from jira-python. I cannot access
> that package to test it.
>
> Signed-off-by: Simon Glass <s...@chromium.org>
> Reported-by: Kevin Hilman <khil...@baylibre.com>

While I removed the pip package that was causing me problems, this looks
basically like the workaround I had done locally.

Acked-by: Kevin Hilman <khil...@baylibre.com>

Thanks for fixing it up,

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

Re: [U-Boot] binman: 'module' object has no attribute 'FinaliseOutputDir'

[Kevin Hilman]

On Fri, Jun 2, 2017 at 11:00 AM, Simon Glass <s...@chromium.org> wrote:
> Hi Kevin,
>
> On 1 June 2017 at 17:08, Kevin Hilman <khil...@baylibre.com> wrote:
>>
>> On Thu, Jun 1, 2017 at 8:23 AM, Simon Glass <s...@chromium.org> wrote:
>> > Hi Kevin,
>> >
>> > On 1 June 2017 at 07:55, Kevin Hilman <khil...@baylibre.com> wrote:
>> >> On Wed, May 31, 2017 at 12:19 PM, Simon Glass <s...@chromium.org> wrote:
>> >>> Hi Kevin,
>> >>>
>> >>> On 31 May 2017 at 12:13, Kevin Hilman <khil...@baylibre.com> wrote:
>> >>>> While trying to build v2017.05 for sun5i-r8-chip (CHIP_defconfig), I get
>> >>>> the following build error.  I'm not familiar with binman, so not sure
>> >>>> what I should be looking for.
>> >>>>
>> >>>> $ CROSS_COMPILE=arm-linux-gnueabihf- make
>> >>>>
>> >>>> [...]
>> >>>>
>> >>>>  LD  spl/drivers/serial/built-in.o
>> >>>>  LD  spl/drivers/built-in.o
>> >>>>  LD  spl/common/built-in.o
>> >>>>  LD  spl/lib/built-in.o
>> >>>>  LD  spl/u-boot-spl
>> >>>>  OBJCOPY spl/u-boot-spl-nodtb.bin
>> >>>>  COPYspl/u-boot-spl.bin
>> >>>>  MKSUNXI spl/sunxi-spl.bin
>> >>>>  BINMAN  u-boot-sunxi-with-spl.bin
>> >>>>  binman: 'module' object has no attribute 'FinaliseOutputDir'
>> >>>>  Makefile:1107: recipe for target 'u-boot-sunxi-with-spl.bin' failed
>> >>>>  make: *** [u-boot-sunxi-with-spl.bin] Error 1
>> >>>>
>> >>>>
>> >>>> If it matters, compiler is: gcc version 5.3.1 20160412 (Linaro GCC 
>> >>>> 5.3-2016.05)
>> >>>
>> >>> Do you know what version of python you are using? I cannot imagine
>> >>> what is happening here.
>> >>
>> >> $ python
>> >> Python 2.7.12 (default, Nov 19 2016, 06:48:10)
>> >> [GCC 5.4.0 20160609] on linux2
>> >> Type "help", "copyright", "credits" or "license" for more information.
>> >>>>>
>> >>
>> >> and fwiw, this is on Ubuntu 16.04 LTS.
>> >
>> > That's what I am using too. This is really mystifying. Are you able to
>> > debug the python code?
>>
>> If you give me some pointers/suggestions, I'd be glad to, but I don't
>> currently have much time to go wandering too deep into the uboot
>> weeds.
>
> My guess is that you have a tools.py file somewhere in your Python
> site_packages. You should be able to test this with:
>
> python
>> import tools
>
> Perhaps 'dpkg -S tools.py' will tell you what package installed it.

$ python
Python 2.7.12 (default, Nov 19 2016, 06:48:10)
[GCC 5.4.0 20160609] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import os.path
>>> import tools
>>> print os.path.abspath(tools.__file__)
/usr/local/lib/python2.7/dist-packages/tools/__init__.pyc
>>>

So since this is in /usr/local, dpkg -S didn't help, so it was
something installed by pip.  Turns out that it was the jira-python
package, installed by pip that had installed this tools dir.

> If you don't get an error then it suggests you already have this
> package. That in turn would suggest that the fix is that the path
> should be prepended instead of appended at the top of binman.py.

"pip uninstall jira-python" also did the trick, but prepending worked
too.  I suppose having a name slightly less generic than "tools" would
also work.

Anyways, I got it building now, so I'll let you decide which is the
"right way" to fix.

Thanks,

Kevin

[1]
$ git diff tools/binman/
diff --git a/tools/binman/binman.py b/tools/binman/binman.py
index 857d698b4c24..535bcece274f 100755
--- a/tools/binman/binman.py
+++ b/tools/binman/binman.py
@@ -17,7 +17,7 @@ import unittest

 # Bring in the patman and dtoc libraries
 our_path = os.path.dirname(os.path.realpath(__file__))
-sys.path.append(os.path.join(our_path, '../patman'))
+sys.path.insert(1, os.path.join(our_path, '../patman'))
 sys.path.append(os.path.join(our_path, '../dtoc'))
 sys.path.append(os.path.join(our_path, '../'))
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] binman: 'module' object has no attribute 'FinaliseOutputDir'

[Kevin Hilman]

On Thu, Jun 1, 2017 at 8:23 AM, Simon Glass <s...@chromium.org> wrote:
> Hi Kevin,
>
> On 1 June 2017 at 07:55, Kevin Hilman <khil...@baylibre.com> wrote:
>> On Wed, May 31, 2017 at 12:19 PM, Simon Glass <s...@chromium.org> wrote:
>>> Hi Kevin,
>>>
>>> On 31 May 2017 at 12:13, Kevin Hilman <khil...@baylibre.com> wrote:
>>>> While trying to build v2017.05 for sun5i-r8-chip (CHIP_defconfig), I get
>>>> the following build error.  I'm not familiar with binman, so not sure
>>>> what I should be looking for.
>>>>
>>>> $ CROSS_COMPILE=arm-linux-gnueabihf- make
>>>>
>>>> [...]
>>>>
>>>>  LD  spl/drivers/serial/built-in.o
>>>>  LD  spl/drivers/built-in.o
>>>>  LD  spl/common/built-in.o
>>>>  LD  spl/lib/built-in.o
>>>>  LD  spl/u-boot-spl
>>>>  OBJCOPY spl/u-boot-spl-nodtb.bin
>>>>  COPYspl/u-boot-spl.bin
>>>>  MKSUNXI spl/sunxi-spl.bin
>>>>  BINMAN  u-boot-sunxi-with-spl.bin
>>>>  binman: 'module' object has no attribute 'FinaliseOutputDir'
>>>>  Makefile:1107: recipe for target 'u-boot-sunxi-with-spl.bin' failed
>>>>  make: *** [u-boot-sunxi-with-spl.bin] Error 1
>>>>
>>>>
>>>> If it matters, compiler is: gcc version 5.3.1 20160412 (Linaro GCC 
>>>> 5.3-2016.05)
>>>
>>> Do you know what version of python you are using? I cannot imagine
>>> what is happening here.
>>
>> $ python
>> Python 2.7.12 (default, Nov 19 2016, 06:48:10)
>> [GCC 5.4.0 20160609] on linux2
>> Type "help", "copyright", "credits" or "license" for more information.
>>>>>
>>
>> and fwiw, this is on Ubuntu 16.04 LTS.
>
> That's what I am using too. This is really mystifying. Are you able to
> debug the python code?

If you give me some pointers/suggestions, I'd be glad to, but I don't
currently have much time to go wandering too deep into the uboot
weeds.

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

Re: [U-Boot] binman: 'module' object has no attribute 'FinaliseOutputDir'

[Kevin Hilman]

On Wed, May 31, 2017 at 12:19 PM, Simon Glass <s...@chromium.org> wrote:
> Hi Kevin,
>
> On 31 May 2017 at 12:13, Kevin Hilman <khil...@baylibre.com> wrote:
>> While trying to build v2017.05 for sun5i-r8-chip (CHIP_defconfig), I get
>> the following build error.  I'm not familiar with binman, so not sure
>> what I should be looking for.
>>
>> $ CROSS_COMPILE=arm-linux-gnueabihf- make
>>
>> [...]
>>
>>  LD  spl/drivers/serial/built-in.o
>>  LD  spl/drivers/built-in.o
>>  LD  spl/common/built-in.o
>>  LD  spl/lib/built-in.o
>>  LD  spl/u-boot-spl
>>  OBJCOPY spl/u-boot-spl-nodtb.bin
>>  COPYspl/u-boot-spl.bin
>>  MKSUNXI spl/sunxi-spl.bin
>>  BINMAN  u-boot-sunxi-with-spl.bin
>>  binman: 'module' object has no attribute 'FinaliseOutputDir'
>>  Makefile:1107: recipe for target 'u-boot-sunxi-with-spl.bin' failed
>>  make: *** [u-boot-sunxi-with-spl.bin] Error 1
>>
>>
>> If it matters, compiler is: gcc version 5.3.1 20160412 (Linaro GCC 
>> 5.3-2016.05)
>
> Do you know what version of python you are using? I cannot imagine
> what is happening here.

$ python
Python 2.7.12 (default, Nov 19 2016, 06:48:10)
[GCC 5.4.0 20160609] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>>

and fwiw, this is on Ubuntu 16.04 LTS.

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

[U-Boot] binman: 'module' object has no attribute 'FinaliseOutputDir'

[Kevin Hilman]

While trying to build v2017.05 for sun5i-r8-chip (CHIP_defconfig), I get
the following build error.  I'm not familiar with binman, so not sure
what I should be looking for.

$ CROSS_COMPILE=arm-linux-gnueabihf- make

[...]

 LD  spl/drivers/serial/built-in.o
 LD  spl/drivers/built-in.o
 LD  spl/common/built-in.o
 LD  spl/lib/built-in.o
 LD  spl/u-boot-spl
 OBJCOPY spl/u-boot-spl-nodtb.bin
 COPYspl/u-boot-spl.bin
 MKSUNXI spl/sunxi-spl.bin
 BINMAN  u-boot-sunxi-with-spl.bin
 binman: 'module' object has no attribute 'FinaliseOutputDir'
 Makefile:1107: recipe for target 'u-boot-sunxi-with-spl.bin' failed
 make: *** [u-boot-sunxi-with-spl.bin] Error 1


If it matters, compiler is: gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05)

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

[U-Boot] [PATCH] ARM: imx7s-warp: enable USB gadget ethernet

[Kevin Hilman]

Enable USB gadget ethernet by default to have networking capabilities.

Tested using DHCP and TFTP to transfer kernel, DT, ramdisk.

Cc: Fabio Estevam <feste...@gmail.com>
Signed-off-by: Kevin Hilman <khil...@baylibre.com>
---
Applies to v2016.11

 board/warp7/warp7.c | 14 ++
 configs/warp7_defconfig |  5 +
 include/configs/warp7.h |  7 +++
 3 files changed, 26 insertions(+)

diff --git a/board/warp7/warp7.c b/board/warp7/warp7.c
index da9afb4ccd86..df8e9da6f919 100644
--- a/board/warp7/warp7.c
+++ b/board/warp7/warp7.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include "../freescale/common/pfuze.h"
@@ -138,6 +139,19 @@ int power_init_board(void)
 }
 #endif
 
+int board_eth_init(bd_t *bis)
+{
+   int ret = 0;
+
+#ifdef CONFIG_USB_ETHER
+   ret = usb_eth_initialize(bis);
+   if (ret < 0)
+   printf("Error %d registering USB ether.\n", ret);
+#endif
+
+   return ret;
+}
+
 int board_init(void)
 {
/* address of boot parameters */
diff --git a/configs/warp7_defconfig b/configs/warp7_defconfig
index 0f0ec99e50ca..81acd8ff15c8 100644
--- a/configs/warp7_defconfig
+++ b/configs/warp7_defconfig
@@ -35,3 +35,8 @@ CONFIG_G_DNL_MANUFACTURER="FSL"
 CONFIG_G_DNL_VENDOR_NUM=0x0525
 CONFIG_G_DNL_PRODUCT_NUM=0xa4a5
 CONFIG_OF_LIBFDT=y
+
+CONFIG_CMD_NET=y
+CONFIG_NET_RANDOM_ETHADDR=y
+CONFIG_CMD_DHCP=y
+
diff --git a/include/configs/warp7.h b/include/configs/warp7.h
index d3b0c5e0d62c..f4a92319ebad 100644
--- a/include/configs/warp7.h
+++ b/include/configs/warp7.h
@@ -38,6 +38,7 @@
"script=boot.scr\0" \
"image=zImage\0" \
"console=ttymxc0\0" \
+   "ethact=usb_ether\0" \
"fdt_high=0x\0" \
"initrd_high=0x\0" \
"fdt_file=imx7s-warp.dtb\0" \
@@ -145,4 +146,10 @@
 #define CONFIG_SYS_DFU_DATA_BUF_SIZE   SZ_16M
 #define DFU_DEFAULT_POLL_TIMEOUT   300
 
+#define CONFIG_USB_ETHER
+#define CONFIG_USB_ETH_CDC
+#define CONFIG_USB_ETH_RNDIS
+#define CONFIG_USBNET_HOST_ADDR"de:ad:be:af:00:00"
+#define CONFIG_USBNET_DEV_ADDR "de:ad:be:af:00:01"
+
 #endif
-- 
2.9.3

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

Re: [U-Boot] [PATCH] configs: da850evm: enable bootz command

[Kevin Hilman]

Sekhar Nori <nsek...@ti.com> writes:

> Enable bootz command on Texas Instruments DA850 EVM
> board. This helps it boot zImage with device-tree
> blob passed.
>
> Signed-off-by: Sekhar Nori <nsek...@ti.com>

Tested-by: Kevin Hilman <khil...@baylibre.com>

Thanks!  This was the only change I needed to use the latest mainline
u-boot on my da850evm.

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

Re: [U-Boot] [PATCH 1/2] mmc: Add Amlogic Meson driver

[Kevin Hilman]

Carlo Caione <ca...@caione.org> writes:

> On Fri, May 13, 2016 at 3:46 PM, Kevin Hilman <khil...@baylibre.com> wrote:
>> Carlo Caione <ca...@caione.org> writes:
>>
>>> From: Carlo Caione <ca...@endlessm.com>
>>>
>>> This is a port / rewrite of the Amlogic driver shipped whithin the
>>> Amlogic SDK for the Meson GXBaby (S905) SoC.
>>>
>>> Signed-off-by: Carlo Caione <ca...@endlessm.com>
>>
>> [...]
>>
>>> +static const struct udevice_id meson_mmc_match[] = {
>>> + { .compatible = "amlogic,meson-mmc" },
>>> + { /* sentinel */ }
>>
>> IIUC, this controller is different between meson8* and gxbb.  If that's
>> the case, this compatible should probably be more specific.
>
> Yes, this is a point I raised also on lkml when I submitted the MMC
> driver for the Meson8b.
> Since the registers mapping is different I assume that this is the
> case. Just to be sure, given that you are the only one with a
> datasheet for the GXBB, can you confirm that?

I took a quick look and just compared the register layouts between s805
and s905 and indeed they are quite different.

Kevin

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

Re: [U-Boot] [PATCH 1/2] mmc: Add Amlogic Meson driver

[Kevin Hilman]

Carlo Caione  writes:

> From: Carlo Caione 
>
> This is a port / rewrite of the Amlogic driver shipped whithin the
> Amlogic SDK for the Meson GXBaby (S905) SoC.
>
> Signed-off-by: Carlo Caione 

[...]

> +static const struct udevice_id meson_mmc_match[] = {
> + { .compatible = "amlogic,meson-mmc" },
> + { /* sentinel */ }

IIUC, this controller is different between meson8* and gxbb.  If that's
the case, this compatible should probably be more specific.

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

Re: [U-Boot] [PATCH v3 00/25] dm: Introduce Rockchip RK3288 support

[Kevin Hilman]

Simon Glass s...@chromium.org writes:

 The Rockchip RK3288 is based on a quad-core Cortex-A17 CPU and has a good
 set of peripherals. Various full-featured U-Boot ports are available and
 this is an attempt to bring those features into mainline. With this series
 the Firefly RK3288 can boot to a prompt from an SD card.

 Since much of the code is generic, this also supports the Radxa Rock Pro.
 Since there is no device tree available for that yet, it uses the same
 config and device tree as the Firefly. This works because not all
 peripherals are supported, so the differences don't matter.

 Support for booting from USB OTG is also provided, using the on-chip boot
 ROM and the rkflashtool utility. This can boot as far as SPL, but there is
 no support for reading U-Boot proper from USB as yet. This requires
 implementing a suitable protocol (perhaps DFU or Rockchip's proprietary
 one) in SPL.

 Support is also provided for the Haier Chromebook, which is based on the
 same SoC. In this case it boots from SPI rather than an SD card.

Any testing on the Hisense Chromebook with the same SoC?  I don't know
if there are significant differences with the Haier one that would
effect this.

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

Re: [U-Boot] [PATCH v4 03/10] Exynos542x: Add workaround for ARM errata 798870

[Kevin Hilman]

Akshay Saraswat aksha...@samsung.com writes:

[...]

 I don't think it hurts to have a generic function with ARM errata
 workaround implementation. Whoever wish to use it can call it in their
 boot path. And it's not even getting executed right now for any SoC
 other than Exynos542x, so those who don't want it need not bother
 about it. This was the intention. :)

What about exynos542x platforms which also have secure firmware?  Are
you testing this on any of those (e.g. exynos5422-odroid-xu3?)

Kevin



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

Re: [U-Boot] [PATCH v4 03/10] Exynos542x: Add workaround for ARM errata 798870

[Kevin Hilman]

Nishanth Menon n...@ti.com writes:

 On 13:27-20150220, Akshay Saraswat wrote:
 This patch adds workaround for ARM errata 798870 which says
 If back-to-back speculative cache line fills (fill A and fill B) are
 issued from the L1 data cache of a CPU to the L2 cache, the second
 request (fill B) is then cancelled, and the second request would have
 detected a hazard against a recent write or eviction (write B) to the
 same cache line as fill B then the L2 logic might deadlock.
 
 Signed-off-by: Kimoon Kim kimoon@samsung.com
 Signed-off-by: Akshay Saraswat aksha...@samsung.com
 Reviewed-by: Simon Glass s...@chromium.org
 Tested-by: Simon Glass s...@chromium.org
 ---
 Changes since v3:
  - Added errata number in comment.
  - Moved changes to arm generic armv7.h
 
 Changes since v2:
  - No change.
 
 Changes since v1:
  - Added Reviewed-by  Tested-by.
  - Added space before */ on line # 40.
 
  arch/arm/include/asm/armv7.h | 16 
  1 file changed, 16 insertions(+)
 
 diff --git a/arch/arm/include/asm/armv7.h b/arch/arm/include/asm/armv7.h
 index a13da23..a2040b7 100644
 --- a/arch/arm/include/asm/armv7.h
 +++ b/arch/arm/include/asm/armv7.h
 @@ -69,6 +69,22 @@
  #define CP15DSB asm volatile (mcr p15, 0, %0, c7, c10, 4 : : r 
 (0))
  #define CP15DMB asm volatile (mcr p15, 0, %0, c7, c10, 5 : : r 
 (0))
  
 +/*
 + * Workaround for ARM errata # 798870
 + * Set L2ACTLR[7] to reissue any memory transaction in the L2 that has been
 + * stalled for 1024 cycles to verify that its hazard condition still exists.
 + */
 +static inline void v7_enable_l2_hazard_detect(void)
 +{
 +uint32_t val;
 +
 +/* L2ACTLR[7]: Enable hazard detect timeout */
 +asm volatile (mrc p15, 1, %0, c15, c0, 0\n\t : =r(val));
 +val |= (1  7);
 +asm volatile (mcr p15, 1, %0, c15, c0, 0\n\t : : r(val));

 This wont work for us in DRA7/OMAP5 L2ACTLR cannot be modified by
 u-boot. has to go to secure world using smc call.


I believe the same may be true even on some exynos5 platforms with
secure firmware (e.g. exynos5422-odroid-xu3).

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

Re: [U-Boot] Odroid XU3 - exynos5422 - SPL - iRAM/sRAM address

[Kevin Hilman]

Hi Suriyan,

On Thu, Jan 22, 2015 at 5:46 PM, Suriyan Ramasami suriya...@gmail.com wrote:
 On Thu, Jan 22, 2015 at 9:51 AM, Kevin Hilman khil...@kernel.org wrote:
 Suriyan Ramasami suriya...@gmail.com writes:

 Hello Kevin,

 On Wed, Jan 21, 2015 at 4:54 PM, Kevin Hilman khil...@kernel.org wrote:
 Hi Surijan,

 Suriyan Ramasami suriya...@gmail.com writes:

 Hello Sjoerd Simons,
A signed BL2 which allows unsigned BL2 chain load is already
 available for experimentation. Refer this link:
 http://forum.odroid.com/viewtopic.php?f=98t=6147#p58984
 The suriyan.bl2-hkxu3.1212.5422.zip blob contains a signed BL2 which
 allows the same.

 The layout of SD card is as follows:

 BL1 (1 to 30) 15K
 BL2 (31 to 62) 16K
 indicator block (63 to 64) 1K
 uboot (65 to 2112) 1M
 tzsw (2113 to 2624) 256K
 unsigned BL2 (2625 to 2656) 16K

 A non zero in the first byte of the indicator block instructs the
 signed BL2 to load the unsigned BL2 @ offset 2625.

 I took the binaries from your .zip file above and put them on the SD
 card for my odroid-xu3 at the offsets above.  I'm using BL1 and TZSW
 from the u-boot-hardkernel release[1] and using u-boot-dtb.bin from
 my own mainline u-boot build which inclues the odroid-xu3 patches.

 If I leave the indicator block zero'd, everything works fine, and it
 boots my version of mainline u-boot without any problems.

 If I then write a non-zero value to the first byte of the indicator
 block and write your unsigned BL2 at the appropriate offset, it no
 longer boots.  Is the unsigned BL2 supposed to boot u-boot at offset 65
 when it's finished as well?


 The unsigned SPL from mainline used will be spl/u-boot-spl.bin (raw
 jump to offset 0 in that file will be pure code without headers)

 OK.

 Changes are needed in spl_boot.c to make it next load u-boot-dtb.bin.

 I shall try to list most of the changes here:
 1.arch/arm/cpu/armv7/exynos/spl_boot.c:
The Odroid-XU3's IROM function pointers does not have any code
 (AFAICT). I checked the locations that are listed in the array table
 and found all 0's there.
We need to replace function copy_uboot_to_ram() with something
 similar from HK's file, so that it uses exynos_smc() calls to load the
 bits from SD card, or we could enable MMC code in SPL (haven't tried
 it) and use those functions instead.
   For quick results,I just forced an SD card read.

 2. #define CONFIG_SEC_FW_SIZE (15  10) /* 15 KB */
  somewhere, so that the start offset for U-Boot is calculated correctly.

 3. for chain loading we define CONFIG_SPL_TEXT_BASE to be, say
 0x63E0 so that when its executed the static global pointers are
 accessed correctly - static struct spl_machine_param machine_param in
 file smdk5420_spl.c.

 4. mem_ctrl_init() hangs in while (val != FOUTBPLL);
   One workaround is to use HKs version of this function which again
 uses some smc calls.

 With all these changes, SPL chainloading works.

 Do you have a patch against mainline u-boot for all these changes?  I'd
 be happy to test.


 Give me some time and I shall iron out my notes and get back to
 creating a patch for this against mainline U-Boot.

Curious if you've had any time to prepare some patches against
mainline u-boot.  I'm very curious to try this on the odroid-xu3.

Thanks,

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

Re: [U-Boot] Odroid XU3 - exynos5422 - SPL - iRAM/sRAM address

[Kevin Hilman]

Suriyan Ramasami suriya...@gmail.com writes:

 Hello Kevin,

 On Wed, Jan 21, 2015 at 4:54 PM, Kevin Hilman khil...@kernel.org wrote:
 Hi Surijan,

 Suriyan Ramasami suriya...@gmail.com writes:

 Hello Sjoerd Simons,
A signed BL2 which allows unsigned BL2 chain load is already
 available for experimentation. Refer this link:
 http://forum.odroid.com/viewtopic.php?f=98t=6147#p58984
 The suriyan.bl2-hkxu3.1212.5422.zip blob contains a signed BL2 which
 allows the same.

 The layout of SD card is as follows:

 BL1 (1 to 30) 15K
 BL2 (31 to 62) 16K
 indicator block (63 to 64) 1K
 uboot (65 to 2112) 1M
 tzsw (2113 to 2624) 256K
 unsigned BL2 (2625 to 2656) 16K

 A non zero in the first byte of the indicator block instructs the
 signed BL2 to load the unsigned BL2 @ offset 2625.

 I took the binaries from your .zip file above and put them on the SD
 card for my odroid-xu3 at the offsets above.  I'm using BL1 and TZSW
 from the u-boot-hardkernel release[1] and using u-boot-dtb.bin from
 my own mainline u-boot build which inclues the odroid-xu3 patches.

 If I leave the indicator block zero'd, everything works fine, and it
 boots my version of mainline u-boot without any problems.

 If I then write a non-zero value to the first byte of the indicator
 block and write your unsigned BL2 at the appropriate offset, it no
 longer boots.  Is the unsigned BL2 supposed to boot u-boot at offset 65
 when it's finished as well?


 The unsigned SPL from mainline used will be spl/u-boot-spl.bin (raw
 jump to offset 0 in that file will be pure code without headers)

OK.

 Changes are needed in spl_boot.c to make it next load u-boot-dtb.bin.

 I shall try to list most of the changes here:
 1.arch/arm/cpu/armv7/exynos/spl_boot.c:
The Odroid-XU3's IROM function pointers does not have any code
 (AFAICT). I checked the locations that are listed in the array table
 and found all 0's there.
We need to replace function copy_uboot_to_ram() with something
 similar from HK's file, so that it uses exynos_smc() calls to load the
 bits from SD card, or we could enable MMC code in SPL (haven't tried
 it) and use those functions instead.
   For quick results,I just forced an SD card read.

 2. #define CONFIG_SEC_FW_SIZE (15  10) /* 15 KB */
  somewhere, so that the start offset for U-Boot is calculated correctly.

 3. for chain loading we define CONFIG_SPL_TEXT_BASE to be, say
 0x63E0 so that when its executed the static global pointers are
 accessed correctly - static struct spl_machine_param machine_param in
 file smdk5420_spl.c.

 4. mem_ctrl_init() hangs in while (val != FOUTBPLL);
   One workaround is to use HKs version of this function which again
 uses some smc calls.

 With all these changes, SPL chainloading works.

Do you have a patch against mainline u-boot for all these changes?  I'd
be happy to test.

 How are you debugging your SPL images?

 I tried adding CONFIG_SPL_SERIAL_SUPPORT so I could printf from SPL, but
 that doesn't compile because it seems that libfdt support is needed.


 I didn't enable SERIAL SUPPORT for debugging. I did study the HK SPL
 code vs mainline SPL code quite a bit and worked from there.
 I can try to see if there is an easy way to enable serial printfs.

Are there any GPIO LEDs to blink?

Thanks,

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

Re: [U-Boot] Odroid XU3 - exynos5422 - SPL - iRAM/sRAM address

[Kevin Hilman]

Suriyan Ramasami suriya...@gmail.com writes:

 Hello Kevin,

 On Tue, Jan 20, 2015 at 3:29 PM, Suriyan Ramasami suriya...@gmail.com wrote:
 Hello Kevin,

 On Tue, Jan 20, 2015 at 2:43 PM, Kevin Hilman khil...@kernel.org wrote:
 Suriyan Ramasami suriya...@gmail.com writes:

 Hello Kevin,
These are the changes that would be necessary in uboot mainline for SPL:

 arch/arm/cpu/armv7/exynos/Kconfig
 -   select OF_CONTROL
 +   select SUPPORT_SPL
 +   select OF_CONTROL if !SPL_BUILD

 configs/odroid-xu3_defconfig
 +CONFIG_SPL=y

 include/configs/odroid_xu3.h
 #undef CONFIG_SPL_TEXT_BASE
 #define CONFIG_SPL_TEXT_BASE   0x02027000

 #undef CONFIG_SEC_FW_SIZE
 #define CONFIG_SEC_FW_SIZE (15  10) /* 15 KB */

 Thanks.  With those changes, a build gives me:

 ./include/common.h:355:73: fatal error: asm/u-boot-sandbox.h: No such file 
 or directory

 Sorry for the dumb questions, but I'm not very familiar with u-boot.
 I'm more comofortable in the kernel.


 The above used to work (a month ago). I shall check with current
 mainline uboot and report back.


 Sorry for the snafu. I t was my mistake. The correct diff for the
 configs is as below:

 diff --git a/arch/arm/cpu/armv7/exynos/Kconfig
 b/arch/arm/cpu/armv7/exynos/Kconfig
 index 7fcb5d2..39953e4 100644
 --- a/arch/arm/cpu/armv7/exynos/Kconfig
 +++ b/arch/arm/cpu/armv7/exynos/Kconfig
 @@ -26,7 +26,8 @@ config TARGET_ODROID

  config TARGET_ODROID_XU3
 bool Exynos5422 Odroid board
 -   select OF_CONTROL
 +   select SUPPORT_SPL
 +   select OF_CONTROL if !SPL_BUILD

  config TARGET_ARNDALE
 bool Exynos5250 Arndale board
 diff --git a/configs/odroid-xu3_defconfig b/configs/odroid-xu3_defconfig
 index 74aa0cf..6000ec1 100644
 --- a/configs/odroid-xu3_defconfig
 +++ b/configs/odroid-xu3_defconfig
 @@ -1,4 +1,5 @@
 -CONFIG_ARM=y
 -CONFIG_ARCH_EXYNOS=y
 -CONFIG_TARGET_ODROID_XU3=y
 +CONFIG_SPL=y
 ++S:CONFIG_ARM=y
 ++S:CONFIG_ARCH_EXYNOS=y
 ++S:CONFIG_TARGET_ODROID_XU3=y
  CONFIG_DEFAULT_DEVICE_TREE=exynos5422-odroidxu3

Thanks, that gets things building.  Just to double-check, no additional
changes to include/configs/odroid_xu3.h?

Also, which image are you using as your unsigned BL2? spl/u-boot-spl.bin
or spl/smdk5420-spl.bin?  

The later seems to be generated from the former using tools/mkexynosspl,
but not sure exactly what it's doing, or if its needed on all boards or
just the smdk5420 (as the name implies).

Thanks,

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

Re: [U-Boot] Odroid XU3 - exynos5422 - SPL - iRAM/sRAM address

[Kevin Hilman]

Hi Surijan,

Suriyan Ramasami suriya...@gmail.com writes:

 Hello Sjoerd Simons,
A signed BL2 which allows unsigned BL2 chain load is already
 available for experimentation. Refer this link:
 http://forum.odroid.com/viewtopic.php?f=98t=6147#p58984
 The suriyan.bl2-hkxu3.1212.5422.zip blob contains a signed BL2 which
 allows the same.

 The layout of SD card is as follows:

 BL1 (1 to 30) 15K
 BL2 (31 to 62) 16K
 indicator block (63 to 64) 1K
 uboot (65 to 2112) 1M
 tzsw (2113 to 2624) 256K
 unsigned BL2 (2625 to 2656) 16K

 A non zero in the first byte of the indicator block instructs the
 signed BL2 to load the unsigned BL2 @ offset 2625.

I took the binaries from your .zip file above and put them on the SD
card for my odroid-xu3 at the offsets above.  I'm using BL1 and TZSW
from the u-boot-hardkernel release[1] and using u-boot-dtb.bin from
my own mainline u-boot build which inclues the odroid-xu3 patches.

If I leave the indicator block zero'd, everything works fine, and it
boots my version of mainline u-boot without any problems.

If I then write a non-zero value to the first byte of the indicator
block and write your unsigned BL2 at the appropriate offset, it no
longer boots.  Is the unsigned BL2 supposed to boot u-boot at offset 65
when it's finished as well?

How are you debugging your SPL images?

I tried adding CONFIG_SPL_SERIAL_SUPPORT so I could printf from SPL, but
that doesn't compile because it seems that libfdt support is needed.

Kevin

[1] branch odroidxu3-v2012.07 from https://github.com/hardkernel/u-boot.git
has pre-built binaries that support u-boot size up to 1M in the
sd_fuse/hardkernel_1mb_uboot  directory.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Odroid XU3 - exynos5422 - SPL - iRAM/sRAM address

[Kevin Hilman]

Suriyan Ramasami suriya...@gmail.com writes:

 Hello Kevin,
These are the changes that would be necessary in uboot mainline for SPL:

 arch/arm/cpu/armv7/exynos/Kconfig
 -   select OF_CONTROL
 +   select SUPPORT_SPL
 +   select OF_CONTROL if !SPL_BUILD

 configs/odroid-xu3_defconfig
 +CONFIG_SPL=y

 include/configs/odroid_xu3.h
 #undef CONFIG_SPL_TEXT_BASE
 #define CONFIG_SPL_TEXT_BASE   0x02027000

 #undef CONFIG_SEC_FW_SIZE
 #define CONFIG_SEC_FW_SIZE (15  10) /* 15 KB */

Thanks.  With those changes, a build gives me:

./include/common.h:355:73: fatal error: asm/u-boot-sandbox.h: No such file or 
directory

Sorry for the dumb questions, but I'm not very familiar with u-boot.
I'm more comofortable in the kernel.

  FWICT, mainline uboot does not have code to handle secure firmware.
 For instance when secure firmware is present the address to poke a
 jump address for the CPU is different (nsram +1c etc). This stems from
 lowlevel_init.S being moved over to the NS area. This is also missing
 in uboot mainline or so I think.

Hmm, it seems the XU3 has secure firmware so I guess this wont' be useful
for me yet?

Curious what platforms you're testing this on?  And are any of them
using secure firmware?

Also, I'm still a bit unsure where the switch from secure to NS world
happens.  Is that in BL1? or somewhere in BL2?  If it's in BL2, have you
tried switching secure mode off?

 I hope this helps you out.

Well, it's certainly a step in the right direction, but not sure yet if
I can use it on the odroid-xu3 as I'm still trying to understand the
boot sequence.

Kevin

 The ddr init functions seem to be not correct for the 5422 (or so I
 think). I do not have access to any of the Samsung docs, hence, one
 solution was to copy over HKs ddr init function, and then the mainline
 SPL runs.

 Regards
 - Suriyan


 On Tue, Jan 20, 2015 at 1:30 PM, Kevin Hilman khil...@kernel.org wrote:
 Hello Suriyan,

 Suriyan Ramasami suriya...@gmail.com writes:

 Hello Sjoerd Simons,
A signed BL2 which allows unsigned BL2 chain load is already
 available for experimentation. Refer this link:
 http://forum.odroid.com/viewtopic.php?f=98t=6147#p58984
 The suriyan.bl2-hkxu3.1212.5422.zip blob contains a signed BL2 which
 allows the same.
 The layout of SD card is as follows:

 BL1 (1 to 30) 15K
 BL2 (31 to 62) 16K
 indicator block (63 to 64) 1K
 uboot (65 to 2112) 1M
 tzsw (2113 to 2624) 256K
 unsigned BL2 (2625 to 2656) 16K

 A non zero in the first byte of the indicator block instructs the
 signed BL2 to load the unsigned BL2 @ offset 2625.

 I'm currently running mainline u-boot, and hoping to test the series
 that powers down secondary cores on the odroid-xu3.  That series applies
 and builds with mainline u-boot (v2015.01-rc3), but for it to work
 correctly, IIUC, I'll also need to build an SPL from mainline.

 Can you share your changes to mainline u-boot that enable the building
 of SPL?

 I'd like to try that using your BL2 that will load an unsigned BL2.

 Thanks,

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

Re: [U-Boot] [PATCH 00/11] Add support for booting multiple cores

[Kevin Hilman]

Akshay Saraswat aksha...@samsung.com writes:

 This patch series introduces changes for booting secondary CPUs
 on Exynos5420 and Exynos5800.

Thanks for this series.  I think this should help get the odroid-xu3
behave better with the mainline linux kernel (assuming I can get it 
working with mainline u-boot/SPL.)

Are you testing this on mainline u-boot?

Can you describe what platforms you've tested this on and whether or not
those platforms are using secure firmware?

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

Re: [U-Boot] Odroid XU3 - exynos5422 - SPL - iRAM/sRAM address

[Kevin Hilman]

Hello Suriyan,

Suriyan Ramasami suriya...@gmail.com writes:

 Hello Sjoerd Simons,
A signed BL2 which allows unsigned BL2 chain load is already
 available for experimentation. Refer this link:
 http://forum.odroid.com/viewtopic.php?f=98t=6147#p58984
 The suriyan.bl2-hkxu3.1212.5422.zip blob contains a signed BL2 which
 allows the same.
 The layout of SD card is as follows:

 BL1 (1 to 30) 15K
 BL2 (31 to 62) 16K
 indicator block (63 to 64) 1K
 uboot (65 to 2112) 1M
 tzsw (2113 to 2624) 256K
 unsigned BL2 (2625 to 2656) 16K

 A non zero in the first byte of the indicator block instructs the
 signed BL2 to load the unsigned BL2 @ offset 2625.

I'm currently running mainline u-boot, and hoping to test the series
that powers down secondary cores on the odroid-xu3.  That series applies
and builds with mainline u-boot (v2015.01-rc3), but for it to work
correctly, IIUC, I'll also need to build an SPL from mainline.

Can you share your changes to mainline u-boot that enable the building
of SPL?

I'd like to try that using your BL2 that will load an unsigned BL2.

Thanks,

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

[U-Boot] [PATCH v2] common/board_f.c: fix compile error when tracing disabled

[Kevin Hilman]

From: Kevin Hilman khil...@linaro.org

When CONFIG_TRACE is disabled, linking fails with:

common/built-in.o:(.data.init_sequence_f+0x8): undefined reference to 
`trace_early_init'

To fix, wrap the call to trace_early_init() with #ifdef CONFIG_TRACE.

Cc: Simon Glass s...@chromium.org
Cc: Tom Rini tr...@ti.com
Signed-off-by: Kevin Hilman khil...@linaro.org
---
Applies to v2015.01-rc3

v2: Also remove the static inline stuff from trace.h

 common/board_f.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/common/board_f.c b/common/board_f.c
index 98c9c728ce73..cfd77f865361 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -813,7 +813,9 @@ static init_fnc_t init_sequence_f[] = {
 #endif
setup_mon_len,
setup_fdt,
+#ifdef CONFIG_TRACE
trace_early_init,
+#endif
initf_malloc,
 #if defined(CONFIG_MPC85xx) || defined(CONFIG_MPC86xx)
/* TODO: can this go into arch_cpu_init()? */
-- 
2.1.3

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

[U-Boot] [PATCH v3] common/board_f.c: fix compile error when tracing disabled

[Kevin Hilman]

From: Kevin Hilman khil...@linaro.org

When CONFIG_TRACE is disabled, linking fails with:

common/built-in.o:(.data.init_sequence_f+0x8): undefined reference to 
`trace_early_init'

To fix, wrap trace init calls with #ifdef CONFIG_TRACE.

While at it, remove the static inline version of the init call from
trace.h as suggested by Simon Glass, since it doesnt work.

Cc: Simon Glass s...@chromium.org
Cc: Tom Rini tr...@ti.com
Signed-off-by: Kevin Hilman khil...@linaro.org
---
Applies to v2015.01-rc3

v3: Actually remove the static inlines this time. :/

 common/board_f.c | 2 ++
 include/trace.h  | 7 ---
 2 files changed, 2 insertions(+), 7 deletions(-)

diff --git a/common/board_f.c b/common/board_f.c
index 98c9c728ce73..cfd77f865361 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -813,7 +813,9 @@ static init_fnc_t init_sequence_f[] = {
 #endif
setup_mon_len,
setup_fdt,
+#ifdef CONFIG_TRACE
trace_early_init,
+#endif
initf_malloc,
 #if defined(CONFIG_MPC85xx) || defined(CONFIG_MPC86xx)
/* TODO: can this go into arch_cpu_init()? */
diff --git a/include/trace.h b/include/trace.h
index 871327fb358a..09a38d782fc0 100644
--- a/include/trace.h
+++ b/include/trace.h
@@ -89,14 +89,7 @@ int trace_list_calls(void *buff, int buff_size, unsigned int 
*needed);
  */
 void trace_set_enabled(int enabled);
 
-#ifdef CONFIG_TRACE_EARLY
 int trace_early_init(void);
-#else
-static inline int trace_early_init(void)
-{
-   return 0;
-}
-#endif
 
 /**
  * Init the trace system
-- 
2.1.3

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

Re: [U-Boot] [PATCH v9 2/2] Odroid-XU3: Add documentation for Odroid-XU3

[Kevin Hilman]

Simon Glass s...@chromium.org writes:

[...]

 OK, thanks.  Any pointers on how to get this building with mainline
 u-boot?  Just adding CONFIG_SPL to odroid_xu3.h doesn't seem to work
 (compile errors.)  I'm quite comfortable in the kernel, but I'm not very
 familiar with u-boot, especially SPL.


 It's normally automatic unless some special disabling was done - see
 spl/u-boot-spl.bin in the output. You need to sign it though :-(

Right, I'm used to finding it there, but there's nothing there when
buildling using odroid-xu3_config with $SUBJECT series.

Kevin

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

Re: [U-Boot] [PATCH v11 0/3] Adds support for Exynos5422 odroid xu3 board

[Kevin Hilman]

Hyungwon Hwang human.hw...@samsung.com writes:

 Dear Kevin,

 On Tue, 09 Dec 2014 15:36:00 -0800
 Kevin Hilman khil...@kernel.org wrote:

 Hyungwon Hwang human.hw...@samsung.com writes:
 
  This is v11 of the patchset adding support Odroud XU3 board.
 
 I finally got around to testing this on top of v2015.01-rc3 on my XU3.
 
 As I mentioned earlier, I had to enable the USB and networking options
 so I could dhcp/tftp but after that it works for me.
 
 Feel free to add:
 
 Tested-by: Kevin Hilman khil...@linaro.org

 Thanks for yout review. Sjoerd is waiting for his patch merged
 (title: Exynos: Move down common USB
 configuration). So the features related USB and networking will be
 enabled after this patchset and his patch are merged.

OK, good.

 
 [...]
 
  Note: If you use micro SD card for your test you have to apply the
  below patch additionally. This patch is needed, because micro sd
  card is recognized as MMC1 instead of MMC0. Additional work is
  needed to make it work regardless of device id.
 
 FYI, with or without your MMC ID patch, I wasn't able to save the
 environment to the SD card I'm booting from:
 
 ODROID-XU3 # saveenv
 Saving Environment to MMC...
 dwmci_send_cmd: Timeout.
 MMC init failed
 

 Actually I just tested it again. But it works for me.

 Saving Environment to MMC...
 Writing to MMC(1)... done

 I applied my patchset and MMC ID patch to commit
 38cd8c4253013ccdd4052ee021f6066fe9a52551 in
 http://git.denx.de/u-boot-samsung.git (branch: master).

 I don't know why it does't work for you. Please feel free to need my
 help for this, if you need.

Curious wh you're using u-boot-samsung.git and not mainline.  Can you
test this using mainline u-boot v2015.01-rc3?

Kevin

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

[U-Boot] [PATCH] common/board_f.c: fix compile error when tracing disabled

[Kevin Hilman]

From: Kevin Hilman khil...@linaro.org

When CONFIG_TRACE is disabled, linking fails with:

common/built-in.o:(.data.init_sequence_f+0x8): undefined reference to 
`trace_early_init'

To fix, wrap the call to trace_early_init() with #ifdef CONFIG_TRACE.

Cc: Simon Glass s...@chromium.org
Cc: Tom Rini tr...@ti.com
Signed-off-by: Kevin Hilman khil...@linaro.org
---
Applies to v2015.01-rc3

 common/board_f.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/common/board_f.c b/common/board_f.c
index 98c9c728ce73..cfd77f865361 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -813,7 +813,9 @@ static init_fnc_t init_sequence_f[] = {
 #endif
setup_mon_len,
setup_fdt,
+#ifdef CONFIG_TRACE
trace_early_init,
+#endif
initf_malloc,
 #if defined(CONFIG_MPC85xx) || defined(CONFIG_MPC86xx)
/* TODO: can this go into arch_cpu_init()? */
-- 
2.1.3

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

Re: [U-Boot] [PATCH v11 0/3] Adds support for Exynos5422 odroid xu3 board

[Kevin Hilman]

Hyungwon Hwang human.hw...@samsung.com writes:

 This is v11 of the patchset adding support Odroud XU3 board.

I finally got around to testing this on top of v2015.01-rc3 on my XU3.

As I mentioned earlier, I had to enable the USB and networking options
so I could dhcp/tftp but after that it works for me.

Feel free to add:

Tested-by: Kevin Hilman khil...@linaro.org

[...]

 Note: If you use micro SD card for your test you have to apply the below
 patch additionally. This patch is needed, because micro sd card is
 recognized as MMC1 instead of MMC0. Additional work is needed to make it
 work regardless of device id.

FYI, with or without your MMC ID patch, I wasn't able to save the
environment to the SD card I'm booting from:

ODROID-XU3 # saveenv
Saving Environment to MMC...
dwmci_send_cmd: Timeout.
MMC init failed

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

Re: [U-Boot] [PATCH v9 2/2] Odroid-XU3: Add documentation for Odroid-XU3

[Kevin Hilman]

Simon Glass s...@chromium.org writes:

 On 8 December 2014 at 18:27, Kevin Hilman khil...@kernel.org wrote:


[...]

 So is secure-mode enabled before BL2 is started?  Or do you mean BL2 is
 where secure-mode is enabled?  If it's done in BL2, and if the
 hardkernel folks are willing to sign BL2 images (which I gathered from
 discussions elsewhere in this series) then it seems possible to turn off
 secure-mode.

 Yes it is possible - and easy - to do in BL2 / U-Boot SPL. This is
 what the Chromebooks do.

OK, good.


 So I went to look in the u-boot-samsung repo and didn't see the code for
 the SPL there.  Is the BL2 source (which I understood to be u-boot SPL)
 in some other repo?


 It's in mainline U-Boot so no particular need to go to the Samsung
 tree. 

I went to the samsung tree since the cover letter for this series
pointed me there.  But I just tried the latest version of this series
(v11) using mainlin u-boot.  Thanks for the pointer.

 See arch/arm/cpu/armv7/exynos/spl_boot.c and tzpc.c for the
 TrustZone stuff.

OK, thanks.  Any pointers on how to get this building with mainline
u-boot?  Just adding CONFIG_SPL to odroid_xu3.h doesn't seem to work
(compile errors.)  I'm quite comfortable in the kernel, but I'm not very
familiar with u-boot, especially SPL.

  It takes us back to the 1960s where we sent off our code at night to
  run it :-)
 
  I think the best bet is the current effort to mainline the rest of the
  Chromebook code then try to build it for XU3.

 What's the status of that effort?

 Coming along but the big/little support is still not there. The
 display works and most core peripherals. Needs more SPL work.

OK, I'll be glad to be a beta tester if/when you get to that point.

Thanks,

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

Re: [U-Boot] [PATCH v9 2/2] Odroid-XU3: Add documentation for Odroid-XU3

[Kevin Hilman]

Lukasz Majewski l.majew...@majess.pl writes:

[...]

 On 28 November 2014 at 06:46, Lukasz Majewski l.majew...@majess.pl
 wrote:
  Hello Javier,
 
  Hello Lukasz,
 
  On Fri, Nov 28, 2014 at 9:39 AM, Lukasz Majewski
  l.majew...@majess.pl wrote:
   I have yet to take him up on that offer though, but it sounds
   like a good way forward. The current layout really isn't
   practical.
  
  
   It indeed isn't very practical, but this is what you received
   from HardKernel when you buy XU3 board.
  
   Of course you can grab their sources, modify the layout, prepare
   u-boot's SPL and send it to them to be signed.
   However, it is not the way the normal user do things.
  
   He or she would like to replace standard (and outdated)
   HardKernel u-boot on their SD card and go forward with booting
   kernel.
  
 
  I agree with Sjoed that normal users don't replace the low-level
  components that are provided by the board vendor.
 
  After all you can boot a mainline kernel using the vendor u-boot,
  just append the DTB and create a uImage. The practical reason why
  someone would want to replace the vendor u-boot is to have more
  features but is very hard to do if there is a constraint in the
  maximum u-boot image size (even harder if the maximum is such
  small like in the XU3).
 
  I agree that 328 KiB size for u-boot is a constraint. I don't know
  HardKernel's justification for this.
 
 
   For now we _must_ focus on supporting XU3 with default BL1/BL2
   and hence we are obliged to have u-boot size smaller than 328
   KiB.
  
   It is challenging but for sure doable.
  
 
  It is doable but I don't see why the default BL2 _must_ be used.
 
  For practical/pragmatic reasons:
 
  1. It is difficult to have signed BL2 - each time we need to ask
  HardKernel for signing it. It is impractical and hampers usage of
  mainline SPL (BL2) with XU3.
 
  2. All the documentation on the HardKernel wiki site refers to the
  default BL2.
 
  3. We will have new BL2, which source code is based on 2012.07
  mainline u-boot.
 
  4. Two BL2 binaries - IMHO will hurt (i.e. brick) some device sooner
  or latter.
 
 
  A user that wants to replace the kernel or u-boot is already
  tech-savy and can for sure replace the BL2 as well if it's
  publicly available.
 
  Sorry, but I'm a bit sceptical about updating such low level code.
  Bad things do happen.
 
  Maybe hardkernel folks can even make the modified BL2 available on
  their website and the link added in the comment explaining the
  layout?
 
  We would then require HardKernel to:
 
  1. Provide updated BL2.img
  2. Update their wiki to reflect the new BL2.
 
 
  Also, it is an artificial constraint after all and can be easily
  modified. In fact I think we should push hardkernel to change that
  layout by default and use a BL2/SPL that has more sensible size for
  the u-boot binary even if they don't need it for their vendor
  u-boot which seems to be quite small.
 
  I totally agree.
 
  I'd like to propose a following plan:
 
  1. Accept Hyungwon's patches to have XU3 u-boot  328 KiB (with
  link to default BL2) to have XU3 support in place (and treat it as
  a starting point)
 
  2. If u-boot's size less than 328 KiB is _really_ a problem to
  somebody then ask hardkernel to change BL2 or:
  - modify their sources to change the layout (I regard this
  as a quick hack solution)
  - with a lot of pain develop BL2/SPL (by whom?) which base
  on newest mainline (then for each test hardkernel must sign the
binary).
 
 My 2p worth...
 
 The current Hardkernel BL1 looks broken to me - it is just too old.

 +1


FWIW, the XU3 firmware is broken in other ways as well which have a
major impact on power management.  

First, with mainline kernels using MCPM, only 6 of 8 CPUs come
online.  However, even with that fixed[1], it turns out that the kernel
can't properly manage CCI due to secure firmware[2], which means that MCPM
(multi-cluster power management) can't work, and thus the low-power
cluster-idle states can't work, the big.LITTLE switcher cannot work, and
the ongoing work on energy-aware scheduling will not be useful on this
platform.

Anyone know what are the chances of getting a non-secure version of the
firmware for this platform.  The Samsung Chromebook2 with basically the
same SoC (5800 compared to the 5422 on the XU3) ships with non-secure
firmware so all of the above mentioned features are working just fine.

I'm working on getting these same features working on the XU3, but this
broken firmware as brought a halt to any real progress.

Kevin

[1] 
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-November/305790.html
[2] 
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-November/306480.html
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v9 2/2] Odroid-XU3: Add documentation for Odroid-XU3

[Kevin Hilman]

Hi Simon,

Simon Glass s...@chromium.org writes:

 On 8 December 2014 at 10:58, Kevin Hilman khil...@kernel.org wrote:

[...]

 FWIW, the XU3 firmware is broken in other ways as well which have a
 major impact on power management.

 First, with mainline kernels using MCPM, only 6 of 8 CPUs come
 online.  However, even with that fixed[1], it turns out that the kernel
 can't properly manage CCI due to secure firmware[2], which means that MCPM
 (multi-cluster power management) can't work, and thus the low-power
 cluster-idle states can't work, the big.LITTLE switcher cannot work, and
 the ongoing work on energy-aware scheduling will not be useful on this
 platform.

 Anyone know what are the chances of getting a non-secure version of the
 firmware for this platform.  The Samsung Chromebook2 with basically the
 same SoC (5800 compared to the 5422 on the XU3) ships with non-secure
 firmware so all of the above mentioned features are working just fine.

 I have pushed on this but apparently it is not possible - they need to
 sign every BL2. The only implementation I've seen sets up the chip in
 BL2 (U-Boot SPL) so I don't think we can work around it. 

Not quite sure I'm following...

So is secure-mode enabled before BL2 is started?  Or do you mean BL2 is
where secure-mode is enabled?  If it's done in BL2, and if the
hardkernel folks are willing to sign BL2 images (which I gathered from
discussions elsewhere in this series) then it seems possible to turn off
secure-mode.

So I went to look in the u-boot-samsung repo and didn't see the code for
the SPL there.  Is the BL2 source (which I understood to be u-boot SPL)
in some other repo?

 It takes us back to the 1960s where we sent off our code at night to
 run it :-)

 I think the best bet is the current effort to mainline the rest of the
 Chromebook code then try to build it for XU3.

What's the status of that effort?  


 I'm working on getting these same features working on the XU3, but this
 broken firmware as brought a halt to any real progress.

 Agreed, but I think this is feasible once U-Boot on XU3 is sorted out.

Let's hope so.

Kevin

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

Re: [U-Boot] [PATCH v2] odroid-XU3: Add entry for DTS EHCI GPIO

[Kevin Hilman]

Suriyan Ramasami suriya...@gmail.com writes:

 Hello Hyungwon Hwang,

 On Mon, Dec 8, 2014 at 7:01 PM, Hyungwon Hwang human.hw...@samsung.com 
 wrote:
 Dear Sjoerd,

 On Fri, 05 Dec 2014 21:26:10 +0100
 Sjoerd Simons sjoerd.sim...@collabora.co.uk wrote:

 Add samsung,vbus-gpio information for the XU3. This allows the usage
 of the EHCI controller on the XU3, which is connected to the SMSC
 LAN9514 chip (usb hub + network).

 Signed-off-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk
 ---
 Changes since v1:
   + Correct gpio number
   + Add USB configuration in the odroid XU3 default config

 Hyungwon could you add this one to your XU3 patchset if you send a
 next version (assuming it looks good)?


 Does it work only with this patch? I applied this patch on top of my
 patchset, and connected the ethernet cable to the device. But it
 seemed not working. Is there anything else that I should do for test?

 For usb storage/network support this patch should be combined
 with the exynos configuration tweaks patch i submited earlier to the
 list: Exynos: Move down common USB configuration

  arch/arm/dts/exynos5422-odroidxu3.dts | 4 
  include/configs/odroid_xu3.h  | 4 
  2 files changed, 8 insertions(+)

 diff --git a/arch/arm/dts/exynos5422-odroidxu3.dts
 b/arch/arm/dts/exynos5422-odroidxu3.dts index cff32a9..79a7acd 100644
 --- a/arch/arm/dts/exynos5422-odroidxu3.dts
 +++ b/arch/arm/dts/exynos5422-odroidxu3.dts
 @@ -31,6 +31,10 @@
   0xb000 0xea0;
   };

 + ehci@1211 {
 + samsung,vbus-gpio = gpio 0x66 0; /* X26 */
 + };
 +
   serial@12C2 {
   status=okay;
   };
 diff --git a/include/configs/odroid_xu3.h
 b/include/configs/odroid_xu3.h index 88bb98d..aa0c142 100644
 --- a/include/configs/odroid_xu3.h
 +++ b/include/configs/odroid_xu3.h
 @@ -47,6 +47,10 @@

  #define
 CONFIG_DEFAULT_CONSOLEconsole=ttySAC2,115200n8\0
 +/* USB */
 +#define CONFIG_USB_EHCI
 +#define CONFIG_USB_EHCI_EXYNOS
 +
  /* FIXME: MUST BE REMOVED AFTER TMU IS TURNED ON */
  #undef CONFIG_EXYNOS_TMU
  #undef CONFIG_TMU_CMD_DTT


 In odroid_xu3.h you might want to add the below as well (for LAN + USB 
 storage)

 +/* Enable USB */
 +#define CONFIG_CMD_USB
 +#define CONFIG_USB_EHCI
 +#define CONFIG_USB_EHCI_EXYNOS
 +#define CONFIG_USB_STORAGE
 +#define CONFIG_CMD_DHCP
 +#define CONFIG_USB_HOST_ETHER
 +#define CONFIG_USB_ETHER_SMSC95XX

+1

I enabled these locally on v10 so that I could DHCP and TFTP boot.

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

Re: [U-Boot] OMAP4/Panda: u-boot upgrade v2012.04.01 - v2012.10 breaks RTC wakeups

[Kevin Hilman]

Hi Sricharan,

R Sricharan r.sricha...@ti.com writes:

  In the latest, pad mux and clocks for all
  non-essential modules at U-BOOT were removed.

  This might also cause the problem.
  We can bring this back in u-boot by adding the following macros
  and check if it works fine again.

   include/configs/omap4_common.h
   --
   #define CONFIG_SYS_ENABLE_PADS_ALL
   #define CONFIG_SYS_CLOCKS_ENABLE_ALL

Thanks for the pointer, that got things working again.  It's actually
CONFIG_SYS_ENABLE_PADS_ALL alone which got things working again.

I'm glad to see u-boot going in this direction.  In the kernel, we've
also been trying to get rid of bootloader dependencies also, but it's
clear we haven't got all of them yet.

I'll keep digging to see what's missing in the kernel pads setup to get
RTC working again.

Kevin


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

[U-Boot] OMAP4/Panda: u-boot upgrade v2012.04.01 - v2012.10 breaks RTC wakeups

[Kevin Hilman]

Hello,

I just noticed that the kernel wakeup from suspend using RTC is broken
after I upgraded u-boot from v2012.04.01 to v2012.10 on my
OMAP4430/Panda and OMAP4460/Panda-ES.

I haven't isolated the cause yet, but am hoping someone might have a
pointer about where to start digging.

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