BBBlfs
BBBlfs copied to clipboard
ungureanuvladvictor
Porting to OS X?
I am trying to do that for a while but OS X has a different way of handling USB devices compared to Linux. I need to configure a codeless-kext for the AM335x USB interface https://github.com/libusb/libusb/wiki/FAQ#How_can_I_run_libusb_applications_under_Mac_OS_X_if_there_is_already_a_kernel_extension_installed_for_the_device. Tried a couple of examples but my lack of experience on OS X said it's word.
I've written codeless kexts before, and I can sign them (pain, since most of the time you need this it's with open-source software, and that rarely has someone able to sign them). Maybe I'll try to write one for this.
I'm open for pull-requests and tests if you need. Ping me if something.
I did some tests with the AM335x ROM in USB Boot mode on my MacBook Pro. By default the com.apple.driver.AppleUSBCDC kext takes over the device. I removed the kexts from /Library/System/Extensions/ and here is the log using USB Prober.app : https://gist.github.com/ungureanuvladvictor/ce96ef95a054fde6539d .
I wrote a basic app using libusb to claim the interface and receive some data from it but seems there is an error on the usb level: https://gist.github.com/ungureanuvladvictor/939f08fdd6171144c292 . Mainly AM335x USB (did not respond to inquiry - kIOUSBPipeStalled (0xe000404f)) ... I do not what really this means. Maybe you can give some hints @JetForMe.
A comment from the OS X USB list:
Does the device only present itself as a CDC device or does it have a number of interfaces one of which actually really is a CDC device but also contain other custom endpoints? That’s fairly common as the CDC device piece is usually hooked up to send serial data to and from the board, but there are other interfaces on there as well to do other things.
If so then the CDC driver will claim the CDC device endpoints only and present them as a normal serial device, but won’t claim any of the other endpoints which aren’t related to CDC, leaving other processes free to use them. This is usually what you want, you want the CDC device to be a supported serial device and the custom endpoints to be available for their custom purposes.
One common issue with this has nothing to do with the CDC drivers, but has to do with code which uses libusb, or libusb-derived code, to use the other endpoints, the non-CDC ones, on the same device. The libusb code tries to open the device and read it to find the other endpoints. That doesn’t work because the device itself has already been opened by the CDC driver, exclusively, so that code to re-open it fails. However you don’t need to open the actual device to find the endpoints on OSX, you can discover them with IOKit, and they are perfectly usable.
Is that the case here?
Yes it is a CDC device class. The BBB ROM presents itself as a RNDIS interface to OSX (section 26.1.8.6 in the TRM http://www.ti.com/lit/ug/spruh73k/spruh73k.pdf ).
I removed all the USB CDC kexts from my system and still got an erorr at receiving data (claiming the interface worked).
Maybe a codeless kext would be a cleaner way to ban the USB CDC kexts ? I tried putting one myself but got lost while reading documentation.
I'm a little fuzzy myself, but a codeless kext is used to prevent OS-provided drivers from capturing the device, so that they can be used from user-space code. I applied for and was granted the authority to sign kexts, so now I just need to figure out exactly what needs to go into the kext's plist file to properly match the BBB. That part is actually easy; there are a few other properties of which I'm unsure.
As I know it needs to match per interface. So basic properties are vid/pid then match each interface separately (control and bulk interfaces). I will follow-up with a lsusb -v with a BBB connected to get the full details.
FYI, BeagleBoard.org does have a signed public key from Godaddy.com. It was used to sign the Windows drivers (https://github.com/beagleboard/beaglebone-getting-started/blob/master/Drivers/Windows/src/make.bat). Not sure if we can use the same key to sign this.
No, it's a different kind of signature altogether. You have to request the ability from Apple and they have to grant it.
@JetForMe here is the lsusb for the BBB ROM in usb boot mode: https://gist.github.com/ungureanuvladvictor/ae34c3f1dfc9a72c5fe4
I tried to put one together but couldn't figure out exactly what needed to go into the .plist file. If you can put the file together, I'm happy to sign it. Sorry, I've been swamped with travel and other projects and haven't had the energy to look into this further.
On Apr 6, 2015, at 14:09 , Vlad Victor Ungureanu (vvu) [email protected] wrote:
@JetForMe any chance you can get a codeless kext ?
— Reply to this email directly or view it on GitHub.
Rick Mann [email protected]
You said you have an example somewhere ? I need a new version because I am running Yosemite here. Any hint ?
If you have a working one, it just needs to be signed.
On Apr 6, 2015, at 14:14 , Vlad Victor Ungureanu (vvu) [email protected] wrote:
You said you have an example somewhere ? I need a new version because I am running Yosemite here. Any hint ?
— Reply to this email directly or view it on GitHub.
Rick Mann [email protected]
@JetForMe i made it work without a codeless kext. removed all the CDC kexts from my osx used this branch https://github.com/ungureanuvladvictor/BBBlfs/tree/osx_partial . It needed some RNDIS init code to work. Will have a codeless kext in a few days if you can sign.
Sure thing. Sorry, I've been out of town every weekend for the past month, and when I'm here I'm swamped with other things.
@JetForMe I have some updates. I pushed to the osx branch some code. Can you test it ? On my OS X Yosemite everything works as expected (putting the BBB in a flash state mode).
Install the codeless kext from the codeless kext folder. I have an install script there. You need to modify the bootargs to allow unsigned kexts run (http://apple.stackexchange.com/questions/163059/how-can-i-disable-kext-signing-in-mac-os-x-10-10-yosemite). After installing reboot your machine.
Then run:
brew install libusb --without-runtime-logging
./autogen.sh
./configure
make
cd bin
./usb_flasher
If you already have libusb installed please uninstall and install with the --without-runtime-logging option. The library with logging hangs on my machine, but without any logs works perfectly. I suppose you have a serial cable to see the output on the BBB. It should end up loading a kernel and exposing the eMMC to the OS X host.
Thanks!
Hmm. I finally got a chance to try to sign this thing, and I realize I don't know how. I've got the necessary cert, but the sample code that allegedly contains a Readme explaining how to do it is not available. Still working on it. I really don't want to modify my boot args just yet.
Did you get the kext signing certificate specifically? I made a request but Apple in their eminent wisdom denied it and suggested to use developer mode.
I did. The portal was down yesterday when I tried to reissue my cert. I'm away this weekend, will have to wait to try again.
Sent from my iPhone
On May 27, 2015, at 21:02, moto-timo [email protected] wrote:
Did you get the kext signing certificate specifically? I made a request but Apple in their eminent wisdom denied it and suggested to use developer mode.
— Reply to this email directly or view it on GitHub.
I suggest for the time being to use dev mode. I am not done with all the naming conventions so we get all the binaries and kexts under the same org/dev names and so on. At the end of the summer I plan to try again and ask apple to sign it again.