Skip to content

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Sign in
W
White Rabbit
  • Project
    • Project
    • Details
    • Activity
    • Cycle Analytics
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Charts
  • Issues 5
    • Issues 5
    • List
    • Board
    • Labels
    • Milestones
  • Merge Requests 0
    • Merge Requests 0
  • Wiki
    • Wiki
  • image/svg+xml
    Discourse
    • Discourse
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Charts
  • Create a new issue
  • Commits
  • Issue Boards
  • Projects
  • White Rabbit
  • Wiki
  • Mchmaincpu

Mchmaincpu

Last edited by Projects Jan 28, 2010
Page history

A quick description of the MCH Main CPU

It's an embedded Linux system based on an ARM9 processor. It boots off flash and responds to two Ethernet interfaces (each one with its own MAC address): a service Fast Ethernet with a copper RJ45 in the front panel of the MCH and an "internal NIC" which sits on the main FPGA and is connected to the WR network. The interface between the NIC and the main CPU has to be slightly modified to be able to reuse standard networking Linux kernel code.

The NIC sends packets to the main CPU if they:

  • Have the CPU MAC address as destination.
  • Have a multicast address as a destination and the CPU address is registered as part of that multicast group (broadcast can be thought as a limit case of multicast): this is the case for PTPv2 and RSTP.

Development in the main CPU can be divided into:

* Kernel code: We should try to merge this code upstream as soon as the hardware reaches a stable point, because out-of-tree development == pain

* White Rabbit Machine support in the ARM tree. - DONE

  • NIC driver. To be done:

** accommodate the upcoming hardware changes.

** TX timestamping: we'll need to come up with a sane interface for it

* User-space code

  • PTP daemon

  • Has to be reviewed

  • Tests: I'd like to run on our switch standard automated tests used in industry, i.e. RFC 2544. Ideally the tests should be ready before the switch's development finishes. We may need to buy/rent/lease specific hardware, e.g. IXIA products.

  • RSTP: It looks like we could get some code here: http://www.openflowswitch.org/. -- Main.JavierSerrano - 23 Nov 2009

For RSTP, I'd probably use rstpd, which surely suffers from bit rot but nonetheless seems to be a good starting point.

I've had a look at the "OpenFlow Switch" code, and what they do (for the "OpenFlow Switch 0") is to implement a full switch in either kernel or user-space. I see this more as an appetiser than something to base our code on.
-- EmilioGCota - 23 Nov 2009

Clone repository
  • Data delivery
  • Documents
  • Documents
    • Articles
    • Faq documents
    • Fpga transceivers propagation delay study
    • Figures
    • Greg's master thesis
    • Posters
    • Presentations
    • Sfp data
    • Temperature tests (aka torture report)
    • Tom's master thesis
    • Wr jobs
    • Wr switch debugging
  • Documents/WR-contribution-for-ITU-T-Q13
    • 15 meeting
More Pages

New Wiki Page

Tip: You can specify the full path for the new file. We will automatically create any missing directories.