BOOTP on EVM board and Beagle Bone

I have the same problem. No packets on the wire while in ethernet boot mode.

From the processor errata (http://www.ti.com/lit/pdf/sprz360):

Advisory 1.0.7: Boot: Ethernet Boot ROM Code PHY Link Speed Detection

Advisory 1.0.8: Boot: Ethernet Boot ROM Code Sends an Incorrect Vendor Class Identifier in BOOTP
Packet

Advisory 1.0.18: ROM: Ethernet Boot Code Does Not Change Default Direction of RMII1 Reference
Clock When Booting from Ethernet Using RMII

I'm not sure yet how to navigate around these issues (or if its even possible with the am335x-evm board).

Advisory 1.0.7 will not be an issue if you connect the EVM to a 100Mbps network.  The EVM will not boot when connected to a 1000Mbps network because the AM335x MAC will be incorrectly configured for 100Mbps.

Advisory  1.0.8 does not prevent booting.

Advisory 1.0.18 does not apply to the EVM or BeagleBone because neither of these boards use RMII.

Note: All three of these Advisories apply to silicon revision 1.0  and we are expecting them to be resolved in silicon revision 2.0.

Regards,
Paul

Thanks. I hooked this up to a 100Mbps switch and started receiving bootp packets.

After configuring a bootp/dhcp server, the EVM board boots over ethernet.

I now have a am335x-evm-sk (starter kit) board (for the dual ethernet capability), and don't see any BOOTP messages when I configured the SYSBOOT pull-ups/downs to do so (EMAC1, MMC0, XIPmux2, NANDI2C). 

An interesting thing is if I boot from an SD card, either the bootstrap loader (MLO), or u-boot will send out a BOOTP message (which my server responds to)...but it doesn't do anything with the response...and that defeats the purpose of ethernet booting if you have to plug a card in.

Is it possible to get this board to boot over ethernet straight from ROM? What am I missing here?

Hi Sean and others

I'vve reached the point where my Starter Kit sends out BOOT packets and

completes the TFTP transfer of the MLO file from the BOOTP/TFPT server.

But the boot sequence does not continue from there, nothing is seen on the debug port.

A similar project, booting from sd card works file.

I think something must be wrong with either my makeimg.inc or xldr.bib in the emac project.

Could you possibly inform me about the contents of these files (or even better the whole xldr\emac project.)

I think my problem has to do with tne constants 0x402f0000 and 402f0400 and would like to verify

that I'm building the MLO.emac file right

Best regards Jens

Hi Jens,

Are you building uboot in your development environment. It looks like MLO is a file formatted to run out of flash memory. If you're booting over ethernet, you'll want to send u-boot-spl.bin and then u-boot.img to get a working bootloader.

Hi Sean

Thank you for your reply.

Unfortunately I forgot to mention that we use Windows CE 7, not Linux for our development. That explains my mentioning of .bib etc.

Anyway, we have solved the problem! This will probably not be of much use to Linux developers, only to CE70 developers:

We had 2 problems:

1) TI AM335x Technical Reference Manual spruh73g.pdf chapter 26.1.8 "Perifiral Booting" states:

"The boot image is downloaded directly into internal RAM at the location 0x402F0000 on GP devices."

"Transfer control to 0x402F0400 (GP)"

This seems to wrong! Both constants should be 0x402F0400

2) We coundn't make the Microsoft tool used for building such binary images build usable code for any other address than 0x402F1000, which is used for

building images for for instance SD boot. (No problem in that case, because an 8-byte header defining size and entry is appended in front of the image)

Based on 1) and 2) we decided to build the code for 0x402F1000 and append an empty block of 0x0c00 bytes to the image. When the resulting file is loaded into

0x402F0400, the image will end up exactly where it is bulid: at  0x402F0400 + 0xc00 =  0x402F1000

Finally a relative jump to  0x402F1000 was placed at location 0 of the file (i.e. at location  0x402F0400) seen from the CPU.

When this file is transferred by TFTP it will start up and announce itself on the debug port.

Now remains the work of implementing a simple TFTP client for transfering the next level of boot code, in CE known as EBOOT

Probably we will be able to find a Linux version of that code somewhere and port it to CE.

Best regards Jens