Sorry Rick, I did not mean to Hijack your post, but it seems I’ve done exactly that . . .
So… what would you guys like me to do… rip out remoteproc_prus so uio_pruss works again, even thou all of ti’s pru tools/wiki are being updated for remoteproc_pruss… I currently don’t use the ‘pruss’ system, so someone will have to maintain it for v4.1.x-ti…
The other option, when remoteproc_pruss doesn’t exist just enable uio_pruss…
Regards,
Ideally, I’d like to understand the whole process better. Which has nothing to do with wanting you to do anything specific. I really do not know what you have to go through Robert, in order to make everyone happy. I was however imagining somehow creating a situation where we could have a ti kernel for TI, and a bone image to keep things like the PRU’s in a working state until we have that other option. From the outside looking in, this seems like something potentially as trivial as a config, and perhaps a different setup script ? I honestly do not know. You tell me.
So, in other words. This keeps people like me, and perhaps armhf.com from keeping our own Linux builds. Then sharing that with the public, having posts winding up here - With people wondering why x.y.z does not work - When things change yet again.
Honestly, I’d like to help if I could. But not sure I know enough yet to do exactly that.
heh, I guess since I’ve had no response. I’m asking for too much. No problem . . .
heh, I guess since I’ve had no response. I’m asking for too much. No problem . . .
So, in other words. This keeps people like me, and perhaps armhf.com from keeping our own Linux builds. Then sharing that with the public, having posts winding up here - With people wondering why x.y.z does not work - When things change yet again.
Honestly, I’d like to help if I could. But not sure I know enough yet to do exactly that.
Sorry Rick, I did not mean to Hijack your post, but it seems I’ve done exactly that . . .
So… what would you guys like me to do… rip out remoteproc_prus so uio_pruss works again, even thou all of ti’s pru tools/wiki are being updated for remoteproc_pruss… I currently don’t use the ‘pruss’ system, so someone will have to maintain it for v4.1.x-ti…
The other option, when remoteproc_pruss doesn’t exist just enable uio_pruss…
Regards,
Ideally, I’d like to understand the whole process better. Which has nothing to do with wanting you to do anything specific. I really do not know what you have to go through Robert, in order to make everyone happy. I was however imagining somehow creating a situation where we could have a ti kernel for TI, and a bone image to keep things like the PRU’s in a working state until we have that other option. From the outside looking in, this seems like something potentially as trivial as a config, and perhaps a different setup script ? I honestly do not know. You tell me.
As soon as I reenable uio-pruss n bone we’d have that… Right 
There is one thing I do like about the current TI 4.1.x kernel, and that’s PREEMPT rt. Well, it’s not a terrible kernel, just does not have the PRUs workable it seems.
Anyway, how does one enable PREEMPT rt ?
Well, there's the bone "v4.1.x" + "rt" option: (so pru should work, as
it' doesn't have the ti patchset.)
sudo apt-get update
sudo apt-get install linux-image-4.1.9-bone-rt-r16
it's a little funny, but i don't think you guys realize the number of
kernel branches i'm building right now. .
Regards,
I certainly do! Honestly, I wish it were fewer. I don't even have to deal with non-BBB! You must really have a lot going on.
But for me, audio is working better in 4.1.4-ti-r9 than in 4.1.4-bone15, so I'll be exploring those differences.
Oh, I have a good idea. Probably every board with a dtb in /boot/dtbs/${kernel version}/ and maybe a good bit more ?
Haven’t seen that page yet. will have to look it over later when I’m not using up all my bandwidth pulling in ~1.9G worth of sources, and when not otherwise busy outdoors . . .
grrr . . . accidentally exited out of menuconfig before enabling uio_pruss Which section is uio_pruss under Robert ? I did notice a lot of compiled in remote_proc stuff though . …
@Rick, did you build 4.3 ? I’m curious, if you did. What did you think of it ?
I've had no luck with 4.3, 4.2, 4.1, or anything not 4.1.4-ti-r9.
Helpful tip with menuconfig: type a slash at the top, then search for things (e.g. "pruss"). This will give you some semi-useful results that tell you where to find things. In this case, it's
-> Device Drivers
-> Userspace I/O drivers (UIO [=m])
You still have to then find each of these in the menus and navigate to it, and the items aren't in any sensible order, but it's much better than browsing for it.
Thanks Rick, that is helpful. So what is the problem for you ? Is it the sound codec or are other things a problem as well ? Mostly I only really care about no auto reboots, but also I want to remove USB gadgets from being compiled in statically( I’d rather have modules ), but can not for the life of me tell what I need to change to [M]. Most of the Gadget drivers I’ve found so far only allow [*]
, or completely unselected [ ]
Oh, and I’m about to kick this eeepc to the curb as far as compiling goes . . . it’s still at it . . . works great as an NFS root + samba system though.
Thanks Rick, that is helpful. So what is the problem for you ? Is it the sound codec or are other things a problem as well ? Mostly I only really care about no auto reboots, but also I want to remove USB gadgets from being compiled in statically( I'd rather have modules ), but can not for the life of me tell what I need to change to [M]. Most of the Gadget drivers I've found so far only allow [*]
, or completely unselected
Oh, you're stretching my knowledge. I think some drivers don't have module capability, but I don't know if that's the case with the USB gadgets. Someday I want to build Linux From Scratch for this thing to get the absolute minimum kernel I can (and do other stuff to get to a 1-second boot time).
My problem right now is getting the clock rate correct with mcasp0. It's creating an mclk of 24 MHz, but I'm asking for 12 MHz in the DTS.
I just now succeeded in putting in printk() statements in the TI audio driver code, and seeing them in dmesg, so I'll be able to do a lot more (painful) debugging.
Learning far more than I wanted to about this stuff.
Well, the USB gadget comments by me were pretty much just comment. USB Gadgets are supposed to be either loadable module, compiled in, or removed. Problem is, there is so much garbage in kernel config related to USB gadget with similar names. It’s hard to tell what’s what.
This 24Mhz clock is coming from the CPU ? Maybe time for an external oscillator ? I’ll leave the EE stuff to you EE types heh.
Yeah, the CPU is generating it. Because linux is misbehaving.
I've already made the board, not putting in an oscillator now (plus, no guarantee that'll fix things).