[U-Boot] EMAC failure and SPI support for TI DaVinci DM365

[U-Boot] EMAC failure and SPI support for TI DaVinci DM365

[Ian Jeffray]

Hi guys,

This question may be mostly directed to Sandeep Paulraj, the TI
tree maintainer, but is also observed in the mainline...

I've had great success with U-Boot on many ADI BF5xx devices, but I'm
having considerably less fun with the TI DM365.

I've a DM365EVM board - the stock U-Boot binary from the PSP 3.10
distribution from TI works ok, but has no SPI ('sf') support, so I
need to build that in for starters (ultimately we're designing a
custom board with only SPI flash - no NAND).

My problem is that even building the 2009.11 release, the current
mainline revision (ie 2010.02 prerelease), or the u-boot-ti mainline,
the EMAC fails and instantly reboots the board... with no mods made
to U-Boot... just a build out of the box fails this way:

git clone git://git.denx.de/u-boot-ti.git
cd u-boot-ti
make davinci_dm365evm_config
make

...then flash on to my board using the sfh_DM36x.exe utility with the
UBL from the PSP 3.10 distribution... and boot up...

  > DM36x initialization passed!
  > TI UBL Version: 1.50
  > Booting Catalog Boot Loader
  > BootMode = NAND
  > Starting NAND Copy...
  > Valid magicnum, 0xA1ACED66, found in block 0x0000001A.
  >    DONE
  > Jumping to entry point at 0x81080000.
  >
  > U-Boot 2009.11-00988-g2a6e256 (Feb 23 2010 - 13:50:13)
  >
  > I2C:   ready
  > DRAM:  128 MB
  > NAND:  2048 MiB
  > (snipped out lots of nand BBT details here from this email)
  > *** Warning - bad CRC or NAND, using default environment
  >
  > Net:
  > Hit any key to stop autoboot:  0
  > DM365 EVM # dhcp
  > DM36x initialization passed!
  > TI UBL Version: 1.50
  > Booting Catalog Boot Loader

As you can see, as soon as I "dhcp", the board is rebooting.  The same
happens if I set "ipaddr" and "netmask" then attempt a tftp or ping.

My expectation was that this stuff would work fine out of the box and
clearly isn't for me -- I hope this is just something I'm doing wrong
here and that someone is able to confirm that the code's kosher and
maybe pointers as to what I could have done wrong?

I do notice that the "Net: " line above has no further detail, wheras
the TI PSP binary version says "Ethernet PHY: GENERIC @ 0x00"
(I've not managed to get a 2009.03 build of my own to run on DM365
to compare yet... that's the version TI supplied as binary somehow)


My second question is about the DaVinci SPI flash support in U-Boot.
I've replaced the 64K SPI flash on the DM365EVM with a larger part,
which works just fine from my self-build Linux kernel, so I know the
device itself is fine.   All attempts to utilise this from U-Boot
are failing.   I realise the SPI DaVinci SPI flash driver is rather
new - wondering what the expectations of this driver are in terms of
stability and testing?


Many thanks for all the great work by everyone on the U-Boot project;
It's certainly been an invaluable asset for us on Blackfin and I hope
we'll be able to get it playing nicely on DaVinci too!

Thanks,
Ian.

[U-Boot] EMAC failure and SPI support for TI DaVinci DM365

[Paulraj, Sandeep]

> Subject: [U-Boot] EMAC failure and SPI support for TI DaVinci DM365
> 
> Hi guys,
> 
> This question may be mostly directed to Sandeep Paulraj, the TI
> tree maintainer, but is also observed in the mainline...
> 
> I've had great success with U-Boot on many ADI BF5xx devices, but I'm
> having considerably less fun with the TI DM365.
> 
> I've a DM365EVM board - the stock U-Boot binary from the PSP 3.10
> distribution from TI works ok, but has no SPI ('sf') support, so I
> need to build that in for starters (ultimately we're designing a
> custom board with only SPI flash - no NAND).
> 
> My problem is that even building the 2009.11 release, the current
> mainline revision (ie 2010.02 prerelease), or the u-boot-ti mainline,
> the EMAC fails and instantly reboots the board... with no mods made
> to U-Boot... just a build out of the box fails this way:
> 
> git clone git://git.denx.de/u-boot-ti.git
> cd u-boot-ti
> make davinci_dm365evm_config
> make
> 
> ...then flash on to my board using the sfh_DM36x.exe utility with the
> UBL from the PSP 3.10 distribution... and boot up...
> 
>   > DM36x initialization passed!
>   > TI UBL Version: 1.50
>   > Booting Catalog Boot Loader
>   > BootMode = NAND
>   > Starting NAND Copy...
>   > Valid magicnum, 0xA1ACED66, found in block 0x0000001A.
>   >    DONE
>   > Jumping to entry point at 0x81080000.
>   >
>   > U-Boot 2009.11-00988-g2a6e256 (Feb 23 2010 - 13:50:13)
>   >
>   > I2C:   ready
>   > DRAM:  128 MB
>   > NAND:  2048 MiB
>   > (snipped out lots of nand BBT details here from this email)
>   > *** Warning - bad CRC or NAND, using default environment
>   >
>   > Net:
>   > Hit any key to stop autoboot:  0
>   > DM365 EVM # dhcp
>   > DM36x initialization passed!
>   > TI UBL Version: 1.50
>   > Booting Catalog Boot Loader
> 
> As you can see, as soon as I "dhcp", the board is rebooting.  The same
> happens if I set "ipaddr" and "netmask" then attempt a tftp or ping.


I checked this feature some days back after I rebased with Wolfgang. 

And this is the dump
DM36x initialization passed!
TI UBL Version: 1.50
Booting Catalog Boot Loader
BootMode = NAND
Starting NAND Copy...
Valid magicnum, 0xA1ACED66, found in block 0x00000019.
   DONE
Jumping to entry point at 0x81080000.


U-Boot 2009.11-00406-ga85c80c-dirty (Feb 17 2010 - 20:42:42)

I2C:   ready
DRAM:  128 MB
NAND:  2048 MiB
Bad block table found at page 524224, version 0x01
Bad block table found at page 1048512, version 0x01
Bad block table found at page 524160, version 0x01
Bad block table found at page 1048448, version 0x01
nand_read_bbt: Bad block at 0x000000100000
nand_read_bbt: Bad block at 0x000000360000

many more of these I just removed them.. . BTW there is nothing wrong with these messages.

Net:   Ethernet PHY: GENERIC @ 0x01

Hit any key to stop autoboot:  0
BOOTP broadcast 1
*** Unhandled DHCP Option in OFFER/ACK: 44
*** Unhandled DHCP Option in OFFER/ACK: 46
*** Unhandled DHCP Option in OFFER/ACK: 150
*** Unhandled DHCP Option in OFFER/ACK: 44
*** Unhandled DHCP Option in OFFER/ACK: 46
*** Unhandled DHCP Option in OFFER/ACK: 150
DHCP client bound to address 158.218.100.176
Using  device
TFTP from server 158.218.100.23; our IP address is 158.218.100.176
Filename 'uImage-git-dm365'.
Load address: 0x80700000
Loading: #################################################################
         #######################################
done
Bytes transferred = 1523356 (173e9c hex)
## Booting kernel from Legacy Image at 80700000 ...
   Image Name:   Linux-2.6.33-rc4-06989-g887f8d1-
   Created:      2010-01-27  21:11:35 UTC
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    1523292 Bytes =  1.5 MB
   Load Address: 80008000
   Entry Point:  80008000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.
Linux version 2.6.33-rc4-06989-g887f8d1-dirty (a0866907 at gt5d9d821.telogy.design.
ti.com) (gcc version 4.3.3 (Sourcery G++ Lite 2009q1-203) ) #7 PREEMPT Wed Jan 2
7 16:11:26 EST 2010
CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177
CPU: VIVT data cache, VIVT instruction cache
Machine: DaVinci DM365 EVM
Memory policy: ECC disabled, Data cache writeback
DaVinci dm365_rev1.2 variant 0x8

And then I get to the kernel prompt

> 
> My expectation was that this stuff would work fine out of the box and
> clearly isn't for me -- I hope this is just something I'm doing wrong
> here and that someone is able to confirm that the code's kosher and
> maybe pointers as to what I could have done wrong?
This is your custom board correct. I am using the Spectrum Digital DM365 EVM
> 
> I do notice that the "Net: " line above has no further detail, wheras
> the TI PSP binary version says "Ethernet PHY: GENERIC @ 0x00"
> (I've not managed to get a 2009.03 build of my own to run on DM365
> to compare yet... that's the version TI supplied as binary somehow)
The other issue might be the updates tot eh EMAC driver. The version that finally was accepted by Ben was submitted by Nick Thompson. It worked fine for me but I'm not sure if something small was missed.

Maybe you can compare the driver that TI release as part of PSP 3.01 and what is there in u-boot at the moment.
I'll do so myself as soon as I get some free cycles.

> 
> 
> My second question is about the DaVinci SPI flash support in U-Boot.
> I've replaced the 64K SPI flash on the DM365EVM with a larger part,
The default EVM comes with an EEPROM 
> which works just fine from my self-build Linux kernel, so I know the
> device itself is fine.   All attempts to utilise this from U-Boot
> are failing.   I realise the SPI DaVinci SPI flash driver is rather
> new - wondering what the expectations of this driver are in terms of
> stability and testing?

I have not tried SPI FLASH from U-boot myself. I have tried SPI with flash in the kernel.

Did you do all the necessary PINMUX?

The TI engineer who did the SPI driver for U-boot must have only tested on OMAP L chips. The SPI IP is similar but not same. 

> 
> 
> Many thanks for all the great work by everyone on the U-Boot project;
> It's certainly been an invaluable asset for us on Blackfin and I hope
> we'll be able to get it playing nicely on DaVinci too!

BTW I've moved into a new project where I will be working on adding Linux support for TI DSPs so I am not as involved with ARM SOC's as I used to be. It might take me some time before I get to the issues you mention above.

> 
> Thanks,
> Ian.

[U-Boot] EMAC failure and SPI support for TI DaVinci DM365

[Ian Jeffray]

Hi Sandeep,

You wrote:
> I checked this feature some days back after I rebased with Wolfgang.
[snip]
> Net:   Ethernet PHY: GENERIC @ 0x01

Well it's good to know that it must be something wrong with my
tools or my board :-)

>> My expectation was that this stuff would work fine out of the box and
>> clearly isn't for me -- I hope this is just something I'm doing wrong
>> here and that someone is able to confirm that the code's kosher and
>> maybe pointers as to what I could have done wrong?
> This is your custom board correct. I am using the Spectrum Digital DM365 EVM

No; I don't have a custom board (yet) - I'm also using the DM365EVM...
which was why I was hoping things would "just work" out of the box.

I guess I'll have to try and debug around the network code directly...
to find out why the "Ethernet PHY:" part isn't being displayed.

Thanks for the dump - it's always really useful to compare output
against a working system!


>> I do notice that the "Net: " line above has no further detail, wheras
>> the TI PSP binary version says "Ethernet PHY: GENERIC @ 0x00"
>> (I've not managed to get a 2009.03 build of my own to run on DM365
>> to compare yet... that's the version TI supplied as binary somehow)
> The other issue might be the updates tot eh EMAC driver. The version that finally was accepted by Ben was submitted by Nick Thompson. It worked fine for me but I'm not sure if something small was missed.
>
> Maybe you can compare the driver that TI release as part of PSP 3.01 and what is there in u-boot at the moment.
> I'll do so myself as soon as I get some free cycles.

That's what I want to do but I guess I must be myopic... I can't
see or find the U-Boot sources in the PSP.   I'll look again.


(Re SPI flash)
> I have not tried SPI FLASH from U-boot myself. I have tried SPI with flash in the kernel.
>
> Did you do all the necessary PINMUX?

Aha! No. I didn't realise I would need to do that myself.  My fault
there then.  I'll investigate this.  Thanks for the pointer!

 > The TI engineer who did the SPI driver for U-boot must have only
 > tested on OMAP L chips. The SPI IP is similar but not same.

A little worrysome ;)   Maybe Davinci SPI support in U-Boot isn't
very well fledged and tested just now - something for me to work on.


Regards,

Ian.

[U-Boot] EMAC failure and SPI support for TI DaVinci DM365

[Nick Thompson]

On 23/02/10 20:14, Paulraj, Sandeep wrote:
> Ian Jeffray wrote:
>> I do notice that the "Net: " line above has no further detail, wheras
>> the TI PSP binary version says "Ethernet PHY: GENERIC @ 0x00"
>> (I've not managed to get a 2009.03 build of my own to run on DM365
>> to compare yet... that's the version TI supplied as binary somehow)
> The other issue might be the updates tot eh EMAC driver. The version that finally was accepted by Ben was submitted by Nick Thompson. It worked fine for me but I'm not sure if something small was missed.
> 

I tested on da830evm, but only in my private tree. The changes needed
by da830 are still filtering up to main (currently in the arm tree).

Once it hits main, I will be retesting. In the mean time, I will be
following this thread in case there is an issue.

Nick.