OK, lots to comment on here. I may not hit everything, but further details in-line (along with some major snippage to keep the overall length reasonable).
> Here's an outline of the BB boot sequence: > > (The following is what I think I currently understand -- details could > still be incorrect. I'm iteratively looking at multiple topics to figure > this out - if someone spots an error, or a silly assumption, please > educate me further. ) You've got a different perspective on this than I do. To me it's more: * Power On * Rom bootstrap code * UBoot executed from uSD card (BBW) or mmc Flash (BBB) * Linux kernel * Normal Linux startup sequence We have the ability to twiddle or setup I/O pins from UBoot on. > 1)power up > > 2)OS boot process > > a.Hardware init > > i.BBB specific OS code looks for Capes (& Cape EPROMs) > > (this is where the kernel version seems to matter as BBB requires device > tree support, that BBW doesn't). > > 1.OS Configures pins according to EPROM data on cape > > a.Theory: BeBoPr and Replicape implicitly assume default BBW pin setup > (I've not verified this yet as I haven't found cape EPROM contents for > the boards) > > b.Implication: these capes won't work on BBB w/o changes (pin conflicts). > > c.Frankly the tech details of this are a bit moot when you can't buy the > capes... > d. ... and we need some physical connection ability from the BBs to the > rest of the world. The device tree support and a kernel with BeagleBone specific support is required to do things like use standard drivers for the PWM outputs and GPIO pins, and is not specific to BBB or BBW. There are 3.2 and 3.8 kernels available with BBW support, and at least 3.8 kernels for BBB. The bigger issue for LinuxCNC is the kernel must have Xenomai support or there is no hope of running LinuxCNC well enough to actually move motors. So, Xenomai is required, device-tree is desired but not absolutely critical (you can talk directly to the raw hardware, it's just not as elegant or portable as using the kernel drivers). > 3)LCNC started > > a.LCNC Init - Current sequence: > > i.LCNC loads PRU code etc > > 1.LCNC software on BBW is assuming a default BBW pin > config (established during OS boot process). > > ii.Assertion: We need a different assumption for BBB... > > 1.Treating BBB as BBW by "not using HDMI" does not seem > to be an easy option > > a.(disabling HDMI appears to be a sftw+hdw job -- not a pure > software one; some hdw signals have tobe held in certain states during > POR etc.). This is *EXACTLY* the same on the BBB and the BBW. The pins involved are used to configure the ROM boot code internal to the CPU and determine if the CPU tries to boot from MMC flash, SD card, USB, serial, ethernet, JTAG, or lord knows what else (I haven't crawled through the applicable sections of the TRM and Data Sheet yet). There are warnings about these I/O pins in the BBW manual, but the warnings are a lot more pronounced in the BBB manual. > b.That implies a cape is needed to convert a BBB pin out > into a BBW pin out. It seems a bit silly to build a cape just to do that. There is no requirement for any hardware to make a BBB act like a BBW. At worst, you need a bit of software to disable the new BBB hardware (ie: hold the MMC flash in reset and put the HDMI chip into a low-power mode). This is discussed in the BBB manual. > 2. Issue: what assumptions to use re BBB pin out? > > 3.Enabler: Some consensus on a BBB Pin config that could > be used to jump start further BBB work and allow more folks to > participate in LCNC on BB development. > > a.We're are kind of stuck when no interface capes are easily > available. > > b.Future enhancement: Hal could learn more about BBB platform and > dynamically rearrange pin mappings and mux modes. > > i.More complexity -- would have to consider interactions with multiple > capes etc. > > ii. It seems preferable not to make this a LCNC on BBB prerequisite. I plan on making HAL components unique to each cape (currently BeBoPr and Replicape, others to come?) that would be responsible for setting up any required pin muxing, clock routing, or whatever. This cape specific code would also configure the lower-level PRU code properly so it 'twiddles' the correct I/O pins. > Idea: > > I'd like to see a simple BBB cape that would > > A)Implement a simple, assumable, BBB pin mapping that could be used by > LCNC Hal for BBB. > > B)Sets up the BBB pins at OS boot time (via Cape EPROM info). > > C)Lets us simply connect a BBB to readily available external hardware > (e.g. Break out boards). > > This would enable the creation of a low cost BBB cape that could be used > for LCNC on BB (BBW or BBB) development.I'm thinking the goal should be > to keep it as simple and low cost as possible. This would enable > creation of a BBB cape that enables more people to play with LCNC on a > BBB (it would also work fine in a BBW). I specifically think of this as > a "LCNC proto cape", simpler than a BeBoPr or Replicape as it would NOT > include motor drivers etc. > > If there is interest in this approach, I'll follow up with a minimal > signal support proposal in the form of a straw man for people to comment > on.As a first cut, I'd try to see what we can do using a BBB pin mapping > that still allows use of the eMMC and HDMI features of the BBB. Hmm...sounds like maybe a BeagleBone 25-pin LPT port cape (or maybe dual LPT port) is needed? This should be pretty easy to wire up with a couple connectors and some line drivers...then you could hook your 'Bone to anything LinuxCNC that hooked to a standard LPT. -- Charles Steinkuehler [email protected] ------------------------------------------------------------------------------ Try New Relic Now & We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
