cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
icosmos72
Visitor
Visitor
4,000 Views
Registered: ‎01-04-2010

ML507 gets up to "eth0: XLlTemac: Options: 0x3fa"

Jump to solution

Hello all ---

 

I have a fresh-from-the-box ML507, didn't change any DIP switches, didn't give it any new programs on the CF card.  Turn it on and it gives me the happy "Choose demo:" prompt on the LCD.  Looks good.

 

Compiled the current linux version 2.6.31 from the git tree, both with and without the downloaded ramdisk.image.gz.  Nothing changed, nothing tweaked, just make 44x/virtex_defconfig and make zImage (ARCH is set to powerpc).  Downloaded via XMD, and everything seems to go swimmingly until the world suddenly ends at "eth0: XLlTemac: Options: 0x3fa".  I see in everyone else's output on these forums --- /and I even saw this once, just once/ --- that the next line of output should report the allocation of an interrupt, and indeed, if I tell XMD to stop the processor and compare the address to the .elf file dump, it is generally in some function that seems to have to do with allocating interrupts.  The processor isn't wedged or halted, but it cetainly isn't getting anywhere.

 

I've tried this, as noted, with and without the RAMdisk; with and without an Ethernet cable attached; with a variety of different cables and hubs.  Always halts at the same spot, except for that one random time (out of maybe two dozen attempts) when it got down to "Freeing unused kernel memory: 164k init".

 

My next thought was to go diving through driver code, but then I realized: everything I'm doing is vanilla; nothing changed from the downloaded, known-good code and fresh-from-the-factory board.  So I'm probably just misunderstanding something (like, "You dope, you need to set the DIP switches like *this*...").  Any suggestions from those whose ML507s are working well?

 

Thanks so much for everyone's time.  Full output from the Linux bootup serial output follows.

 

--Scott

 

 

zImage starting: loaded at 0x00400000 (sp: 0x00720eb0)
 Allocating 0x38b824 bytes for kernel ...
 gunzipping (0x00000000 <- 0x0040e000:0x005afc4b)...done 0x36a04c bytes
 Attached initrd image at 0x005b0000-0x0071ff20
 initrd head: 0x1f8b0808
 
 Linux/PowerPC load: console=ttyS0 ip=on root=/dev/ram
 Finalizing device tree... flat tree at 0x72d300
 Using Xilinx Virtex440 machine description
Linux version 2.6.31 (user@user-laptop) (gcc version 4.2.2) #1 PREEMPT Thu Dec 31 20:59:46 EST 2009
Found initrd at 0xc05b0000:0xc071ff20
Zone PFN ranges:
  DMA      0x00000000 -> 0x00010000
  Normal   0x00010000 -> 0x00010000
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
    0: 0x00000000 -> 0x00010000
MMU: Allocated 1088 bytes of context maps for 255 contexts
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 65024
Kernel command line: console=ttyS0 ip=on root=/dev/ram
PID hash table entries: 1024 (order: 10, 4096 bytes)
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Memory: 254592k/262144k available (3332k kernel code, 7396k reserved, 140k data, 130k bss, 164k init)
Kernel virtual memory layout:
  * 0xffffe000..0xfffff000  : fixmap
  * 0xfde00000..0xfe000000  : consistent mem
  * 0xfde00000..0xfde00000  : early ioremap
  * 0xd1000000..0xfde00000  : vmalloc & ioremap
NR_IRQS:512
clocksource: timebase mult[a00000] shift[22] registered
Console: colour dummy device 80x25
Mount-cache hash table entries: 512
NET: Registered protocol family 16
PCI: Probing PCI hardware
bio: create slab <bio-0> at 0
XGpio: /plb@0/gpio@81460000: registered
XGpio: /plb@0/gpio@81400000: registered
XGpio: /plb@0/gpio@81420000: registered
XGpio: /plb@0/gpio@81440000: registered
NET: Registered protocol family 2
IP route cache hash table entries: 2048 (order: 1, 8192 bytes)
TCP established hash table entries: 8192 (order: 4, 65536 bytes)
TCP bind hash table entries: 8192 (order: 3, 32768 bytes)
TCP: Hash tables configured (established 8192 bind 8192)
TCP reno registered
NET: Registered protocol family 1
Trying to unpack rootfs image as initramfs...
rootfs image is not initramfs (no cpio magic); looks like an initrd
Freeing initrd memory: 1471k freed
ROMFS MTD (C) 2007 Red Hat, Inc.
msgmni has been set to 500
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered (default)
Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
83e00000.serial: ttyS0 at MMIO 0x83e01003 (irq = 16) is a 16550
console [ttyS0] enabled
brd: module loaded
loop: module loaded
Device Tree Probing 'ethernet'
xilinx_lltemac 81c00000.ethernet: MAC address is now  2: 0: 0: 0: 0: 0
xilinx_lltemac 81c00000.ethernet: XLlTemac: using DMA mode.
XLlTemac: DCR address: 0x80
XLlTemac: buffer descriptor size: 32768 (0x8000)
XLlTemac: Allocating DMA descriptors with kmalloc
XLlTemac: (buffer_descriptor_init) phy: 0xf8b0000, virt: 0xcf8b0000, size: 0x8000
XTemac: PHY detected at address 7.
xilinx_lltemac 81c00000.ethernet: eth0: Xilinx TEMAC at 0x81C00000 mapped to 0xD1036000, irq=17
mice: PS/2 mouse device common for all mice
TCP cubic registered
NET: Registered protocol family 17
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
eth0: XLlTemac: Options: 0x3fa
 

 

 

 

0 Kudos
Reply
1 Solution

Accepted Solutions
icosmos72
Visitor
Visitor
4,819 Views
Registered: ‎01-04-2010

Totally does help!  Thanks, and my apologies for misunderstanding the language in the Wiki --- I thought it was about laying one's hands on the bitstream that went into the newest boards-as-delivered, in case people had older vintage boards; not that the boards-as-delivered had an incompatible bitstream.  Now that you point it out, the language makes a whole lot more sense than the way I was parsing it.  Thanks again!

 

View solution in original post

0 Kudos
Reply
2 Replies
linnj
Xilinx Employee
Xilinx Employee
3,985 Views
Registered: ‎09-10-2008

Ah.... I see that you are not downloading any bitstream and assuming you can use the bitstream that is on the board, unless I'm just missing it somewhere.

 

I'm assuming that you really meant 44x/virtex5_defconfig and it was typo without the "5".

 

The wiki page is a little confusing in that respect (too much history that's too old now) and I should clean it up to be simpler and less error prone.  Here's what it says at the end of the message.  I realize it's a pain, but the reference designs that come on the board are not always what we want/need for Linux. We are trying to do a better job of aligning them in the future across groups (apps that provides the designs on the board vs engineering with Linux). 

 

Major Changes

  • For the ML507 board, a new bitstream is needed for the device tree, virtex440-ml507.dts, that is in the GIT tree. The Virtex 5 FXT Development Kit was released by Xilinx and this system is the new reference design for Open Source Linux and u-boot. This system is not available on this wiki site, but is available as a standard reference design from Xilinx at https://secure.xilinx.com/webreg/clickthrough.do?cid=111799. Users are required to have or create a Xilinx user account, but the system is available for free.

 

Hope that helps.

 

 

 

icosmos72
Visitor
Visitor
4,820 Views
Registered: ‎01-04-2010

Totally does help!  Thanks, and my apologies for misunderstanding the language in the Wiki --- I thought it was about laying one's hands on the bitstream that went into the newest boards-as-delivered, in case people had older vintage boards; not that the boards-as-delivered had an incompatible bitstream.  Now that you point it out, the language makes a whole lot more sense than the way I was parsing it.  Thanks again!

 

View solution in original post

0 Kudos
Reply