headers
Andy Fleming | 1 Feb 2012 01:29
Picon

Re: [PATCH 2/4] net: fec_mxc: add PHYLIB support

On Mon, Jan 30, 2012 at 8:13 PM, Troy Kisky
<troy.kisky <at> boundarydevices.com> wrote:
> On 1/29/2012 7:04 PM, Andy Fleming wrote:
>>
>> On Thu, Jan 26, 2012 at 4:21 PM, Troy Kisky
>> <troy.kisky <at> boundarydevices.com>  wrote:
>>>
>>> Signed-off-by: Troy Kisky<troy.kisky <at> boundarydevices.com>
>>> ---
>>>  drivers/net/fec_mxc.c |   35 ++++++++++++++++++++++++++++++-----
>>>  drivers/net/fec_mxc.h |    1 +
>>>  2 files changed, 31 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/drivers/net/fec_mxc.c b/drivers/net/fec_mxc.c
>>> index 3fffe79..4d7a38d 100644
>>> --- a/drivers/net/fec_mxc.c
>>> +++ b/drivers/net/fec_mxc.c
>>>  <at>  <at>  -371,6 +371,20  <at>  <at>  static int fec_set_hwaddr(struct eth_device *dev)
>>>        return 0;
>>>  }
>>>
>>> +static void fec_eth_phy_config(struct eth_device *dev)
>>> +{
>>> +#ifdef CONFIG_PHYLIB
>>> +       struct fec_priv *fec = (struct fec_priv *)dev->priv;
>>> +       struct phy_device *phydev;
>>> +
>>> +       phydev = phy_connect(miiphy_get_dev_by_name(dev->name),
>>> +                       fec->phy_id, dev, PHY_INTERFACE_MODE_RGMII);
>>> +       fec->phydev = phydev;
(Continue reading)

Permalink | Reply | 1 comment |
headers
Troy Kisky | 1 Feb 2012 03:00
Favicon

Re: [PATCH 2/4] net: fec_mxc: add PHYLIB support

On 1/31/2012 5:29 PM, Andy Fleming wrote:
> On Mon, Jan 30, 2012 at 8:13 PM, Troy Kisky
> <troy.kisky <at> boundarydevices.com>  wrote:
>> On 1/29/2012 7:04 PM, Andy Fleming wrote:
>>> On Thu, Jan 26, 2012 at 4:21 PM, Troy Kisky
>>> <troy.kisky <at> boundarydevices.com>    wrote:
>>>> Signed-off-by: Troy Kisky<troy.kisky <at> boundarydevices.com>
>>>> ---
>>>>   drivers/net/fec_mxc.c |   35 ++++++++++++++++++++++++++++++-----
>>>>   drivers/net/fec_mxc.h |    1 +
>>>>   2 files changed, 31 insertions(+), 5 deletions(-)
>>>>
>>>> diff --git a/drivers/net/fec_mxc.c b/drivers/net/fec_mxc.c
>>>> index 3fffe79..4d7a38d 100644
>>>> --- a/drivers/net/fec_mxc.c
>>>> +++ b/drivers/net/fec_mxc.c
>>>>  <at>  <at>  -371,6 +371,20  <at>  <at>  static int fec_set_hwaddr(struct eth_device *dev)
>>>>         return 0;
>>>>   }
>>>>
>>>> +static void fec_eth_phy_config(struct eth_device *dev)
>>>> +{
>>>> +#ifdef CONFIG_PHYLIB
>>>> +       struct fec_priv *fec = (struct fec_priv *)dev->priv;
>>>> +       struct phy_device *phydev;
>>>> +
>>>> +       phydev = phy_connect(miiphy_get_dev_by_name(dev->name),
>>>> +                       fec->phy_id, dev, PHY_INTERFACE_MODE_RGMII);
>>>> +       fec->phydev = phydev;
>>>> +       if (phydev)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Charles Manning | 1 Feb 2012 03:11
Picon

Re: Can u-Boot Ran from RAM?

On Tuesday 31 January 2012 17:07:05 Bud Miljkovic wrote:
> Hi there,
>
>
>
> While getting acquainted with possible u-Boot development issues, I read
> FAQ "14.2.1.  Can U-Boot be configured such that it can be started in
> RAM?" and was puzzled to learn that u-Boot cannot run from RAM.

This is clearly not true.

The omap devices and davinci devices both use rom boot loaders to load uboot 
into ram for further execution.

In the case of omaps it is often even more complex using a rom boot loader to 
load x-load (or cut down u-boot) to load the real uboot which then loads 
Linux.

-- Charles
Permalink | Reply | 0 comments |
headers
Jason Hui | 1 Feb 2012 05:49
Favicon

Re: [PATCH 0/3] mxc_spi refactoring (for mx6q and mx6qsabrelite)

Eric,

On Tue, Jan 31, 2012 at 9:39 PM, Eric Nelson
<eric.nelson <at> boundarydevices.com> wrote:
> On 01/30/2012 11:51 PM, Jason Liu wrote:
>>
>> Eric,
>>
>> 2012/1/31 Eric Nelson<eric.nelson <at> boundarydevices.com>:
>>>
>>> This patch set refactors mxc_spi as described in
>>>    http://lists.denx.de/pipermail/u-boot/2010-March/068791.html
>>> and requested in
>>>    http://lists.denx.de/pipermail/u-boot/2012-January/116023.html
>>> in order to add support for the MX6Q in general and the mx6qsabrelite
>>> specifically.
>>
>>
>> If this patch-set is re-send, please specify version Vx and change-log.
>> Thanks,
>>
> Hi Jason,
>
> I wasn't quite sure how to handle that, since I split up a 7-patch
> series into independent parts.
>
> Any guidance?

IMHO,
if the patches is resent with changes you need specify Vx and change-log.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Christian Riesch | 1 Feb 2012 07:40
Picon
Favicon

[PATCH 1/2] SPL: Add YMODEM over UART load support

Hi Tom, Hi Matt,

On Tuesday, January 31, 2012, Tom Rini <trini <at> ti.com> wrote:
> From: Matt Porter <mporter <at> ti.com>
>
> Adds support for loading U-Boot from UART using YMODEM protocol.
> If YMODEM support is enabled in SPL and the romcode indicates
> that SPL loaded via UART then SPL will wait for start of a
> YMODEM transfer via the console port.

:-) I like this feature!

I tried something similar a few month ago for the da850evm and my own
board, it worked but I never had time to finished it and submit it, it was
just a hack.

For my tests I used the UART loader utility from TI to load the SPL and
then minicom for loading u-boot. Do you have an automated solution for
this? Would be nice to have something like this in tools/.

> Signed-off-by: Matt Porter <mporter <at> ti.com>
> Signed-off-by: Tom Rini <trini <at> ti.com>
> ---
>  arch/arm/cpu/armv7/omap-common/Makefile     |    3 +
>  arch/arm/cpu/armv7/omap-common/spl.c        |    5 ++
>  arch/arm/cpu/armv7/omap-common/spl_ymodem.c |   76
+++++++++++++++++++++++++++
>  arch/arm/include/asm/omap_common.h          |    3 +
>  common/Makefile                             |    3 +
>  lib/Makefile                                |    3 +
(Continue reading)

Permalink | Reply | 1 comment |
headers
Heiko Schocher | 1 Feb 2012 08:33
Picon
Picon
Favicon

Re: [PATCH v5 4/7] arm, arm926ejs: Do not clear the V bit on DA850 SoCs

Hello Sughosh,

Sughosh Ganu wrote:
> hi Christian,
> 
> On Tue, Jan 31, 2012 at 7:26 PM, Christian Riesch <
> christian.riesch <at> omicron.at> wrote:
> 
>> The V bit of the c1 register of CP15 should not be cleared
>> since the SoC has no valid memory at 0x00000000.
>>
>> Signed-off-by: Christian Riesch <christian.riesch <at> omicron.at>
>> Reported-by: Sughosh Ganu <urwithsughosh <at> gmail.com>
>> Cc: Albert Aribaud <albert.u.boot <at> aribaud.net>
>> Cc: Tom Rini <trini <at> ti.com>
>> ---
>>  arch/arm/cpu/arm926ejs/start.S |    5 ++++-
>>  1 files changed, 4 insertions(+), 1 deletions(-)
>>
>> diff --git a/arch/arm/cpu/arm926ejs/start.S
>> b/arch/arm/cpu/arm926ejs/start.S
>> index b39ed8a..b350480 100644
>> --- a/arch/arm/cpu/arm926ejs/start.S
>> +++ b/arch/arm/cpu/arm926ejs/start.S
>>  <at>  <at>  -372,7 +372,10  <at>  <at>  flush_dcache:
>>         * disable MMU and D cache, and enable I cache
>>         */
>>        mrc     p15, 0, r0, c1, c0, 0
>> -       bic     r0, r0, #0x00002300     /* clear bits 13, 9:8 (--V- --RS)
>> */
(Continue reading)

Permalink | Reply | 2 comments |
headers
Shengzhou Liu | 1 Feb 2012 09:31
Favicon

[PATCH] powerpc/usb: fix bug of CPU halt when missing USB PHY clock

when missing USB PHY clock and issuing "usb start" at u-boot prompt, writing to
or_portsc register will cause CPU halt. We should check USBGP[PHY_CLK_VALID] bit
at the first time in ehci_hcd_init() to avoid CPU hang in this case.

Signed-off-by: Shengzhou Liu <Shengzhou.Liu <at> freescale.com>
---
 drivers/usb/host/ehci-fsl.c |   22 +++++++++++++++++++---
 1 files changed, 19 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/host/ehci-fsl.c b/drivers/usb/host/ehci-fsl.c
index b2d294e..cc29375 100644
--- a/drivers/usb/host/ehci-fsl.c
+++ b/drivers/usb/host/ehci-fsl.c
 <at>  <at>  -31,6 +31,18  <at>  <at> 
 #include "ehci.h"
 #include "ehci-core.h"

+/* Check USB PHY clock valid */
+static int usb_phy_clk_valid(struct usb_ehci *ehci)
+{
+	if ((!(in_be32(&ehci->control) & PHY_CLK_VALID)) &&
+			(!in_be32(&ehci->prictrl))) {
+		printf("WARNING: USB PHY clock invalid\n");
+		return 0;
+	} else {
+		return 1;
+	}
+}
+
 /*
(Continue reading)

Permalink | Reply | 8 comments |
headers
Marek Vasut | 1 Feb 2012 11:11
Picon

Re: Can u-Boot Ran from RAM?

> On Monday 30 January 2012 23:07:05 Bud Miljkovic wrote:
> > While getting acquainted with possible u-Boot development issues, I read
> > FAQ "14.2.1.  Can U-Boot be configured such that it can be started in
> > RAM?" and was puzzled to learn that u-Boot cannot run from RAM.
> 
> you misread it.  the question is for people who have loaded u-boot, and
> then want to load another copy of u-boot into ram and then execute that
> directly.
> 
> so the question is "can u-boot be *started in ram*" and the answer is "no".

The answer is "yes if you know how to do it" ;-)

> normally u-boot is bootstrapped from non-ram storage (via a bootrom, or
> some bit of code being latched in at a hardcoded address, or some other
> cpu-specific magic).
> -mike
Permalink | Reply | 8 comments |
headers
Marek Vasut | 1 Feb 2012 11:12
Picon

Re: Can u-Boot Ran from RAM?

> On 01/30/2012 09:07 PM, Bud Miljkovic wrote:
> > Hi there,
> > 
> > 
> > 
> > While getting acquainted with possible u-Boot development issues, I read
> > FAQ "14.2.1.  Can U-Boot be configured such that it can be started in
> > RAM?" and was puzzled to learn that u-Boot cannot run from RAM.
> > 
> > 
> > 
> > Considering a custom platform, using i.MX536, I understand that the
> > i.MX53x processor has its own ROM-based code that performs boot time
> > essential devices initialisation, etc.  In the case when NAND flash is
> > the program-image medium at the boot stage, first, the ROM-based code
> > checks for Discovered Bad Blocks Table (DBBT) presence and searches for
> > valid Firmware Configuration Block (FCB) on external NAND Flash.
> > 
> > 
> > 
> > If FCB is found that points to the NAND Flash page(s) that contain the
> > first 4K of initial firmware to be loaded from NAND Flash. Then, it
> > loads the 4K of data, pointed by FCB, into the NFC RAM buffer. These
> > data contain a valid Image Vector Table (IVT).  Then, the ROM-based code
> > processes IVT, executes the Device Configuration Data (DCD) sequences to
> > initialize boot-related integrated peripherals (typically, these are
> > IOMUX, SDRAM controller and boot memory controller), then copies the
> > application code, also contained in IVT, to target memory (typically,
> > SDRAM) and jumps to it. Typically, this application code is the custom
> > primary bootloader that completes loading the application code (e.g.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Wolfgang Denk | 1 Feb 2012 11:24
Picon
Picon
Favicon

Re: [PATCH 1/2] SPL: Add YMODEM over UART load support

Dear Tom Rini,

In message <1328047438-26294-1-git-send-email-trini <at> ti.com> you wrote:
> From: Matt Porter <mporter <at> ti.com>
> 
> Adds support for loading U-Boot from UART using YMODEM protocol.
> If YMODEM support is enabled in SPL and the romcode indicates
> that SPL loaded via UART then SPL will wait for start of a
> YMODEM transfer via the console port.

Does it really make sense to add all kind of bloat to the SPL?

What originally has been designed to be minimal code now start to pull
in all kinds of other crap, that has never been designed to run before
relocation.

Best regards,

Wolfgang Denk

--

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd <at> denx.de
To be a winner, all you need to give is all you have.
Permalink | Reply | 10 comments |

Gmane