Build for ARM64 ChromeOS?

[dpreed]

I've moved to using a Chromebook for my tinkering computer, now that Linux(debian) is supported in ChromeOS (in beta) and it supports USB devices. But the issue I'm encountering is that my Chromebook is an ARM64 machine, and I can't build the Labrador Desktop_interface project.

The main issue seems to be that the Labrador.pro file doesn't seem to find a 64 bit libdfup properly. (a minor issue is that qt isn't properly set up if one just apt-get install's qt5-default, but I worked around that).

Any hope? Anyone tried this?

[EspoTek]

That sounds awesome, David.

In regards to the .pro file, all of the arch-specific stuff for unix is handled in a single location. Search the .pro file for contains(QT_ARCH, arm).

If you already have am arm64 libdfuprog build, you should be able to just duplicate the contains(QT_ARCH, arm) section for arm64, changing the paths to point to your arm64 lib.

If you don't have a build of libdfuprog for arm64, you can get the source here: https://github.com/EspoTek/libdfuprog

To build, it should just be:

./bootstrap.sh
./libdfuprog_make_linux

The build lib appears somewhere in the source tree, I think it's src/libdfuprog-0.9.so Apologies for the oddness of the process, I knew nothing about bash, Linux or software eng when first setting it up!

What did you need to do to get qt5-default working, by the way? Another customer has had issues building on Raspberry Pi.

[dpreed]

OK, got it compiled, built libdfuprog for arm64 and got everything installed. It only needed me to fix Labrador.pro and add the libdfuprog.so for arm64.

The result is that the labrador app comes up, but can't connect to the labrador device.

Now this is sort of to-be-expected. The way the linux environment runs in ChromeOS is as an LXC container, isolated from the rest of ChromeOS, but with the ability to use the Wayland compositor to put windows on the desktop, and with its own network addresses, etc. Passing USB devices through to the container is a brand new feature just being released as Google developers release it into the bleeding edge testing environment (ChromeOS 75 versions that you can get by going to the right update channel). So it's all brand new. When you plug in the Labrador, you have to enable it to be passed through to the Linux container, and it gets passed through. (lsusb lists it, and dmesg shows it has been attached).

However, getting the udev rules executed seems to be not working quite right. I think this is because udev executes outside the LXC container, so it doesn't see the rules in the container.

I can put together what you might want to pull (the Labrador.pro changes I made), but since I had to manually build libdfuprog separately, maybe you would want to figure out how to add that as well. Do you have a way to build one of those for arm64?

Regarding qt5-default, it just worked after I installed it. Now it is the case that some Raspberry Pi's are ARM64, noy ARM. So maybe the other user just needs to use these changes. The clue is that when you type 'qmake' it says it is building for x64, rather than for raspberry pi. Obviously the x86_64 linux world is not the right one to build for. But I haven't tried with my RPi model 3 A+, which is next on my project list, as it happens - I'm exploring the idea of using it as the center of a test bench.

[EspoTek]

Ahh, that's a pain. Running as sudo should get the board to connect, but of course that involves running as sudo...

Where would be the best place to file a bug report to Google about this? It seems like a feature that would be pretty well in demand.

Regarding a pull request, if you're able to include the arm64 binary of libdfuprog, that would be greatly appreciated. I'm sure I'd be able to build it, but that would involve modifying build scripts and getting a cross compiler set up. No point duplicating work if the binary already exists (plus I won't be able to test it).

[dpreed]

Thanks... The USB support for Linux in ChromeOS is brand new and experimental. I will post a report about there not being a uevent when a USB device is passed into the container. Running as root is not so easy because QT doesn't work at root level (it's missing the DISPLAY environment variable, as often happens). But I persist ... When I've convinced myself that the arm64 libdfuprog library actually works, I'll put together a pullable version and share with you.

One other thing: the layout and spacing of the text in the gui looks terrible on ChromeOS, compared to the other platforms. Any hints as to what might be the problem? fonts missing?

[EspoTek]

I couldn't tell you what the issue would be without seeing a screenshot, but wouldn't be surprised if it was a font DPI issue.

[dpreed]

Here's how it is working on my Chromebook under the latest dev channel release of ChromeOS.

1. Notice the layout issues (font issues).
2. The udev rules are not triggered, so I had to create the symlinks and do a chmod myself for now. Reported this to ChromeOS developers - I expect it will be fixed in the dev channel as they do new releases. USB device support in ChromeOS is not declared complete, but it seems pretty good.
3. I tried out the firmware update menu command, which uses libdfuprog. This didn't seem to be working, despite my building that library for arm64 and installing it. So I'm not quite sure how to diagnose the problem - the system seemed to hang and require rebooting when it tried to do the reprogramming. Debugging clues?

Looks promising.

[EspoTek]

I was able to reproduce (1) on my home PC (Kubuntu 18.04) with the resolution forced to 1366x768. The minimum width for low-res displays was 800px, it should have been 1280. Just put a patch out to fix that.

Thanks for telling the ChromeOS guys about (2).

(3) is not expected. Does the dfu-programmer executable show the same issues? https://dfu-programmer.github.io/

The equivalent command sequence should be:

dfu-programmer atxmega32a4u erase --force
dfu-programmer atxmega32a4u flash firmware/labrafirm_0006_02.hex
dfu-programmer atxmega32a4u launch
sleep 5
dfu-programmer atxmega32a4u launch

[dpreed]

I will try the dfu programmer equivalent...

[EspoTek]

Hi David. Did you end up having any luck with this one?

[maks]

@EspoTek sorry I've been away from the Larador for quite a while. I've now had a chance to go back to trying to use it and tried also with the linux container support on ChoromeOS as I'm also trying to switch to using Chromebooks as my primary dev machine. I got the labrador being detected and ChromeOS showing me the prompt to pass it through to the LInux container and the labrador qt gui app running in the conatiner seems to detect it, prompting me to do a calibration, but no data from the board seems to be getting to the app, though I don't seem to see any error messages either. Is there a way to enable more verbose debug log output when running the app? I suspect there may be some restriction on isochronous mode for pass through devices into the LXC container that the linux distro (eg Debian) runs in on ChromeOS, though I havn't been able to find anything that actually says that in the documentation from Google about the usb support for linux contianers on ChromeOS...

[maks]

@EspoTek I grabbed the logs while running the current AppImage build and I can't seem to spot anything obviously wrong, but posting them here in case you do.

Also here is a screenshot of the app running in the ChromeOS linux container:

As you can see it says the device is connected, but I dont see the expected noisy scope trace (its just on a bread board with some basic hookup wires).

I also tried compiling latest src from this repo and unfort same result :-(

Just to be sure there was nothing wrong with the board, I tried it with a win10 laptop and it worked fine, I coudl see the oscilloscope trace in the UI, see it showing waveforms when I hooked up the sig generator, etc.

---

Initial Log:

EVICE NOT FOUND
Connected
deviceConnectedDisplay::connectedStatusChanged running!
CHECKING CONNECTION!
Entering unixUsbDriver::usbInit
DEVICE NOT FOUND
Connected
libusb: error [udev_hotplug_event] ignoring udev action bind
deviceConnectedDisplay::connectedStatusChanged running!
CHECKING CONNECTION!
Entering unixUsbDriver::usbInit
Device found!!
KERNEL DRIVER INACTIVE
Interface claimed!
Connected
BOARD IS RUNNING FIRMWARE VERSION 0x0004
EXPECTING FIRMWARE VERSION 0x0004
FIRMWARE VARIANT = 0x02
EXPECTED VARIANT = 0x02
Connecting now!
deviceConnectedDisplay::connectedStatusChanged running!
newDig
isoCtx submitted successfully!
[n, k] =  0 0
t =  1598856293333
Delay =  0
Setup successful!
MAIN THREAD ID 0x7dd025753fc0
Iso Stack initialised!
New voltage = 4.5
Going to send value  31
newDig
SUB THREAD ID 0x7dd00ac0e700
Changed to mode 0
newGain = 8.000000
gainMask = c0c
Multiplying by  0.0625
Buffer shifted by -4
unified debug is of size 27
unified debug is of size 27
unified debug is of size 27
unified debug is of size 27

And Log after starting Labrador app again with the board still connected:

./EspoTek_Labrador--x86_64.AppImage 
QObject::connect: No such slot bufferControl::signalGenIn(bool)
QObject::connect:  (sender name:   'signalGenGroup_CH2')
QObject::connect:  (receiver name: 'bufferDisplay')
QObject::connect: No such slot timedTickBox::resetTimer(bool)
QObject::connect:  (sender name:   'lockPsuCheckBox')
QObject::connect:  (receiver name: 'lockPsuCheckBox')
QMetaObject::connectSlotsByName: No matching signal for on_actionRecord_triggered(bool)
QMetaObject::connectSlotsByName: No matching signal for on_actionTake_Snapshot_triggered()
Attempting to open "/tmp/.mount_EspoTeXU113B/usr/bin/waveforms/_list.wfl"
nameBuffer =  Sin

nameBuffer =  Square

nameBuffer =  Triangle

nameBuffer =  Sawtooth

nameBuffer =  DC
newName =  "Sin"
opening /tmp/.mount_EspoTeXU113B/usr/bin/waveforms/Sin.tlw
128

Length =  128
Divisibility =  4
List loaded!!
Attempting to open "/tmp/.mount_EspoTeXU113B/usr/bin/waveforms/_list.wfl"
nameBuffer =  Sin

nameBuffer =  Square

nameBuffer =  Triangle

nameBuffer =  Sawtooth

nameBuffer =  DC
newName =  "Sin"
opening /tmp/.mount_EspoTeXU113B/usr/bin/waveforms/Sin.tlw
Length =  128
Divisibility =  4
List loaded!!
Making USB Driver invisible!!
pipeID 0 = 129
Generic Usb Driver setup complete
unixUsbDriver created!
driver =  unixUsbDriver(0x11d2120)
axes =  QCustomPlot(0x10869c0, name="scopeAxes")
CHECKING CONNECTION!
Entering unixUsbDriver::usbInit
Libusb context initialised
Device found!!
KERNEL DRIVER INACTIVE
Interface claimed!
Connected
BOARD IS RUNNING FIRMWARE VERSION 0x0004
EXPECTING FIRMWARE VERSION 0x0004
FIRMWARE VARIANT = 0x02
EXPECTED VARIANT = 0x02
Connecting now!
newDig
isoCtx submitted successfully!
[n, k] =  0 0
t =  1598856553365
Delay =  0
Setup successful!
MAIN THREAD ID 0x7c0056a82fc0
Iso Stack initialised!
SUB THREAD ID 0x7c003cd2f700
PSU DUTY CYCLE of dutyTemp = 16 OUT OF RANGE (could underflow on SOF)!!!  ABORTING!!!
PSU DUTY CYCLE of dutyTemp = 11 OUT OF RANGE (could underflow on SOF)!!!  ABORTING!!!
PSU DUTY CYCLE of dutyTemp = 6 OUT OF RANGE (could underflow on SOF)!!!  ABORTING!!!
PSU DUTY CYCLE of dutyTemp = 1 OUT OF RANGE (could underflow on SOF)!!!  ABORTING!!!
PSU DUTY CYCLE of dutyTemp = 0 OUT OF RANGE (could underflow on SOF)!!!  ABORTING!!!
unified debug is of size 27
unified debug is of size 27
unified debug is of size 27
unified debug is of size 27
dt_userWantsToCalibrate 65536
ReinitUsb Stage 1 complete
Cancelled 2 0
Total Cancelled = 1
libusb_cancel_transfer FAILED
ERROR LIBUSB_ERROR_NOT_FOUND
Cancelled 3 0
Total Cancelled = 2
libusb_cancel_transfer FAILED
ERROR LIBUSB_ERROR_NOT_FOUND
Cancelled 0 0
Total Cancelled = 3
libusb_cancel_transfer FAILED
ERROR LIBUSB_ERROR_NOT_FOUND
Cancelled 1 0
Total Cancelled = 4
libusb_cancel_transfer FAILED
ERROR LIBUSB_ERROR_NOT_FOUND
Cleaning... #3 phases remain.

Cleaning... #2 phases remain.

Cleaning... #1 phases remain.

Cleaning... #0 phases remain.

Cleanup complete
ReinitUsb entering stage 2

unixUsbDriver destructor ran!
isRunning? false
THREAD Gone!
Transfers freed.
Interface released
Device Closed
Libusb exited
unixUsbDriver destructor completed!

genericUsbDriver dectructor entering
genericUsbDriver dectructor completed
Reinitialising USB driver!
Making USB Driver invisible!!
pipeID 0 = 129
Generic Usb Driver setup complete
unixUsbDriver created!
ReinitUsbStage2 is returning
deviceConnectedDisplay::connectedStatusChanged running!
CHECKING CONNECTION!
Entering unixUsbDriver::usbInit
Libusb context initialised
Device found!!
KERNEL DRIVER INACTIVE
Interface claimed!
Connected
BOARD IS RUNNING FIRMWARE VERSION 0x0004
EXPECTING FIRMWARE VERSION 0x0004
FIRMWARE VARIANT = 0x02
EXPECTED VARIANT = 0x02
Connecting now!
deviceConnectedDisplay::connectedStatusChanged running!
newDig
isoCtx submitted successfully!
[n, k] =  0 0
t =  1598856559535
Delay =  0
Setup successful!
MAIN THREAD ID 0x7c0056a82fc0
Iso Stack initialised!
New voltage = 4.5
Going to send value  31
newDig
SUB THREAD ID 0x7c003cd2f700
Changed to mode 0
newGain = 8.000000
gainMask = c0c
Multiplying by  0.0625
Buffer shifted by -4
unified debug is of size 27
unified debug is of size 27

[EspoTek]

Oh wow, Maksim Lin. That's a blast from the past! G'day, and hope you're doing well. :) Your diagnosis is definitely correct - there is something going wrong that is preventing the isochronous transfers from being submitted (or cancelled?). Specifically, it seems that they're being submitted to libusb but later when attempting to cancel the transfers, they don't exist?

The first thing I'd check is whether or not there is any data being sent to the Isochronous endpoint (0x83) at all - is Wireshark available to you under ChromeOS?

The simplest way to get more verbose debugging output would be by changing the libusb_set_debug(ctx, 3) in unixusbdriver.cpp to libusb_set_debug(ctx, 4).

[maks]

Thanks Chris! Yes sorry its been so long, but I'm back now and really keen to get my Labrador going again. Thanks for those tips, I didn't even know you could use Wireshark to look at USB - I'd only ever used it for network traffic! I'll give it a go and see if I can get it going. And thanks, I'll bump up the debug logging as well and see if that helps too.

One thing though: is the current Linux build known to be working? Why I ask is: I tried it on a desktop running Ubuntu 20.04.1 and I got an error dialog message from the Labrador app saying it couldn't isochronous connection setup. Note I don't get that error dialog on ChromeOS.

Admittedly the x99 asrock motherboard my desktop has a really crap uefi firmware (aka "bios") and usb controller, so I'm forced to run it with usb3 disabled, but I have a webcam working on it fine, so I would have thought the Labrador should be able to? I have tried as recommended in your docs and put it on its own usb port and via a usb hub on its own, but that didn't help 😞 I've got a new pci usb3 card on order for the desktop, so hopefully I can test out with it once I get it in few days.

[phr0gger]

Labrador works with the current Raspberry Pi OS which is 4.19.115

Please excuse typos, sent from my phone.

On Sep 2, 2020, at 12:57 AM, Maksim Lin notifications@github.com wrote:

 Thanks Chris! Yes sorry its been so long, but I'm back now and really keen to get my Labrador going again. Thanks for those tips, I didn't even know you could use Wireshark to look at USB - I'd only ever used it for network traffic! I'll give it a go and see if I can get it going. And thanks, I'll bump up the debug logging as well and see if that helps too.

One thing though: is the current Linux build known to be working? Why I ask is: I tried it on a desktop running Ubuntu 20.04.1 and I got an error dialog message from the Labrador app saying it couldn't isochronous connection setup. Note I don't get that error dialog on ChromeOS.

Admittedly the x99 asrock motherboard my desktop has a really crap uefi firmware (aka "bios") and usb controller, so I'm forced to run it with usb3 disabled, but I have a webcam working on it fine, so I would have thought the Labrador should be able to? I have tried as recommended in your docs and put it on its own usb port and via a usb hub on its own, but that didn't help 😞 I've got a new pci usb3 card on order for the desktop, so hopefully I can test out with it once I get it in few days.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[dpreed]

FYI - I gave up on Labrador for my Chromebook, since it seemed unstable. I actually got it to work once, but then it stopped working. I think ChromeOS USB-linux is not properly maintained, yet. No idea how to even get attention from the developers - they just release new code in the Dev channel, and sometimes it breaks things. The default channel seems not to test USB related stuff, so whatever is broken just gets moved into the default channel. Dev is slightly better about that.

I would love it to work, though. I use the Raspberry Pi the occasional times I use Labrador, but I have to say that ties up a screen, as most of my RPi's are headless in my lab work.

If the problem is isochronous usb, maybe that is easy. Chromebook USB support for unusual devices (not storage) is still rocky, they do support serial OK, so I can run arduino stuff through the chromebook.

I would be happy to see Chromebook supported for Labrador.

On Wednesday, September 2, 2020 8:44am, "phr0gger" notifications@github.com said:

Labrador works with the current Raspberry Pi OS which is 4.19.115

Please excuse typos, sent from my phone.

On Sep 2, 2020, at 12:57 AM, Maksim Lin notifications@github.com wrote:

Thanks Chris! Yes sorry its been so long, but I'm back now and really keen to get my Labrador going again. Thanks for those tips, I didn't even know you could use Wireshark to look at USB - I'd only ever used it for network traffic! I'll give it a go and see if I can get it going. And thanks, I'll bump up the debug logging as well and see if that helps too.

One thing though: is the current Linux build known to be working? Why I ask is: I tried it on a desktop running Ubuntu 20.04.1 and I got an error dialog message from the Labrador app saying it couldn't isochronous connection setup. Note I don't get that error dialog on ChromeOS.

Admittedly the x99 asrock motherboard my desktop has a really crap uefi firmware (aka "bios") and usb controller, so I'm forced to run it with usb3 disabled, but I have a webcam working on it fine, so I would have thought the Labrador should be able to? I have tried as recommended in your docs and put it on its own usb port and via a usb hub on its own, but that didn't help 😞 I've got a new pci usb3 card on order for the desktop, so hopefully I can test out with it once I get it in few days.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub , or unsubscribe .

[maks]

@dpreed I think submitting issues to the Chromium bug tracker is a good way to get things in front of the ChromeOS devs, also there is the google group too.

@EspoTek unfortunately I'm still not having much luck with the labrador on linux in general. I received my new PCI 5 port USB card, but trying to use it with the labrador I get:

Not enough bandwidth for new device state.
can't set config #1, error -28

And the above error happens even when I literally have no other USB devices plugged in! I'm beginning to think this could actually be an issue with the labrador on newer linux kernels, as I'm on 5.4 on the desktop and thats also the guest kernel of the VM that the linux container on ChromeOS runs on (the host ChromeOS kernel is 4.19).

Searching around on the net find plenty of places where people are having problems with the above, one of the more useful posts was a reply from Greg Kroh-Harman, one of the most senior kernel devs, which seems to point to usb2 devices asking for too much bandwidth.

I spotted in the wiki here that you have:

the Labrador reserves the entire bandwidth of a USB hub in order to ensure it gets a solid connection.

so I wonder if this something I could tweak in the labrador firmware by having it ask for a lower amount of bandwidth, as I think this may be the cause of the issue on my desktop at least, as newer linux kernels may be more strict in how they check for the bandwidth being requested by usb2 devices? If you could give me pointer to the spot in the firmware where that usb bandwidth allocation request is set, I could have a go with trying out different values and I think it should be fairly easy to do soem trial and error as it seems the labrador app actualyl uploads new firmware each time the device connects?

[maks]

Hmm, just followed through reading the rest of that linux mailling list thread and it seems that its actually the xhci controller thats responsible for the error around not enough bandwidth, so perhaps this is why it works for others but not for me, even with the same VL805 controller, its perhaps differences in the VL805 firmware on the Rpi4's vs the PCI card that I have.

Either way, perhaps some fiddling with labrador firmwares usb code could get me to a working solution...

[EspoTek]

Oh, if you're running a device with a VL085 controller then you're going to have a bad time with high-bandwidth isochronous devices (not just Labrador).

https://github.com/EspoTek/Labrador/issues/93