Hi, Sorry for the delay in responding, other things pulled me away from this topic during the end of the week.
On 4/25/2013 2:39 PM, Charles Steinkuehler wrote: > 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). <more snipping> > 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. Agreed. I didn't break down "OS boot" into more granular steps (e.g. UBoot etc. ). The dividing line I was interested in is essentially "before LCNC starts" and "after LCNC starts" as I was thinking about differences that will arise because the hdw LCNC will be using is initialized & configured prior to LCNC start up. Yes, it can be twiddled later (with some restrictions), it would seem nice if things were arranged so that the hdw was already in a usable state when LCNC first sees it. > 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). We're OK for BBW as 3.2+Xenomai exists. For the BBB one needs the missing combination of 3.8 kernel + xenomai. My impression is that the BBW combo (3.2+Xenomai) won't init a BBB. Fortunately, Michael said he thinks that there will be a 3.8+Xenomai in May and that's pretty soon as these things go. I can't personally do anything about it as kernel patching for Xenomai is above my Linux union card rating - so I'll assume a 3.8+X will come to be and go forward from that assumption. <snip> > 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. After the BB is up an running, and the Capes have been initialized, we get to LCNC start time.... Then when LCNC starts, loading some PRU code into a PRU is the same; which PRU (0 or 1) can be used and which PRU signals are available will be different. I'm thinking it would be nice to be using a PRU signal subset that is common to both BBW and BBB. Tentatively, I think that will be possible for simpler (3-4 axis) machines - it will depend on which hardware platform features one needs. (I've started working thru the possible signal mux combinations for P8 and P9 on the BBW vs BBB; it could take a while) Given my studies so far, I'll summarize the situation as: a) I think a BBB without eMMC is not very desirable; eMMC removes some PRU0 pins (compared to the BBW). b) The BBB video subsystem creates: HDMI XOR PRU0. c) BeBoPr and Replicape use PRU0. I don't think they will work on a BBB without a PCB revision. That tempers my desire to buy either one (with is OK since they are not available anyhow). Thus I'm concluding that my desire to run LCNC on a BBB implies that an appropriate BBB cape is needed. (Oh my, I seem to be talking myself into another project... :-\ ) <snip> > 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). <snip> >> 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. Yep, something along that line. I'd like to start playing with the current state of affairs for LCNC on Bones. I can use the BBWs I have and be better prepared for then my BBBs arrive. It would be interesting to me to learn more about what you've already accomplished on the BBW by trying it out. What's the current status of LCNC on BBW and what branch would you recommend I start with? Dave ------------------------------------------------------------------------------ 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
