Yeah 3.8.x will do the trick, but the only problem there is do nto expect hotplug for ethernet or USB to work. In fact, the kernel will ooops after about a minute if you do.
This stuff I'm doing for myself as well since the future path seems to be 3.14.x, and possible 3.19.x after that. My own "production" image is actually still 3.8.13-bone47 though. At least this is where I do all my heavy code writing for my own projects. But since I have an NFS server, with 147GB spare disk space just for beaglebone development. it does not hurt to have a few spare images laying around. I've done some testing on newer test images ( later than *bone47 ), and so far I have not liked what I've seen. This is not to say that their bad, its just not what I want in my production images *YET*. On Thu, Dec 11, 2014 at 5:06 PM, Rick Mann <[email protected]> wrote: > > > On Dec 11, 2014, at 15:59 , William Hermans <[email protected]> wrote: > > > > Do you think libpruio will be able to work with your changes? > > > > I am not really changing anything, just piecing together a bunch of > information spread out all over the web, and adjusting things as needed to > make it work for me( us ). > > > > Mostly, I'm exploring / experimenting. Generally I'm pretty good at > troubleshooting, so if there are any pitfalls along the way, I may / may > not convey that in my notes / blog, but I will put the working stuff that i > find out there for others to read. > > > > As far as libpruio goes, it should just be a copy / paste replacement > for whatever device tree files I use during my findings. But, I can not > guarantee that of course, as I have no idea *YET* how much universal io is > integrated into the boneblack images. > > > > Everything I've read seems to indicate that dtb=<filename> in uEnv.txt > should work. But since i've been posting about / talking on thiese point in > the groups here, I figured I had better go see for myself. As technically I > have been just been going by what I've been reading on these groups. Albiet > form reliable people, but . . .You never know. > > > > BTW, this may take me a few days as I have real life obligations over > the next month or so, and I'll be traveling next week so it could take some > time. But if you're in no hurry, I'll have some information out soon-ish, I > hope > > Since I found a working solution in downgrading to 3.8, I can certainly > wait a while. Eventually I'd like to get it all working with the latest and > greatest. At some point, I'm going to build my own kernel with the bare > minimum needed to let my app work, and with an eye toward very fast > (subsecond) boot. > > Thank you! > > > > > On Thu, Dec 11, 2014 at 4:48 PM, William Hermans <[email protected]> > wrote: > > Technically anything that is accessible from sysfs should be accessible > via Nodejs. I dont know what all Jason does with bonescript, I shy away > from it as its just another abstraction layer I personally do not need. I > use "stock" Nodejs, and have not done much with it yet, but am able to > execute a binary that queries a USB thermometer, and spit that information > out to a local network webpage via socket.io. > > > > On Thu, Dec 11, 2014 at 4:25 PM, Rick Mann <[email protected]> > wrote: > > > > > On Dec 11, 2014, at 15:08 , William Hermans <[email protected]> wrote: > > > > > > what I am not sure of is exactly what all is enabled as this point in > time cape wise. ADC, I2C, UARTs, PWM, etc. > > > > Is it possible to test these things from bonescript? It seems like it's > able to enable these things, but I don't really understand how it all fits > together. I know of at least one reference online that uses the bonescript > repo as the authoritative source for device descriptions. > > -- > > Rick Mann > > [email protected] > > > > > > -- > > For more options, visit http://beagleboard.org/discuss > > --- > > You received this message because you are subscribed to the Google > Groups "BeagleBoard" group. > > To unsubscribe from this group and stop receiving emails from it, send > an email to [email protected]. > > For more options, visit https://groups.google.com/d/optout. > > > > > > > > -- > > For more options, visit http://beagleboard.org/discuss > > --- > > You received this message because you are subscribed to the Google > Groups "BeagleBoard" group. > > To unsubscribe from this group and stop receiving emails from it, send > an email to [email protected]. > > For more options, visit https://groups.google.com/d/optout. > > > -- > Rick Mann > [email protected] > > > -- > For more options, visit http://beagleboard.org/discuss > --- > You received this message because you are subscribed to the Google Groups > "BeagleBoard" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
