Jump to content

PhracturedBlue

Members
  • Posts

    16
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. I don't think the usb_storage module is involved in libusb bulk transfers? I did try playing around with CPU affinity for the USB interrupts, but it didn't change anything.
  2. I have a ToupTek MU300 USB2 camera that I was trying to get working with my LePotato. The camera does not have native kernel support, but the manufacturer provides an SDK with a pre-compiled lib for x86/arm, and additionally I have a kernel module which works on X86/X64 with this camera as well as userspace libusb based code to access the camera. The camera is very sensitive to having buffers available during bulk transfer, otherwise the image will be corrupted. Generally synchronous bulk transfer is not fast enough, and requires multiple buffers supplied in asynchronous mode. On x86-64 and Rpi3/4, everything works as expected. I can grab images via the vendor supplied SDK as well as with my libusb based code (and on x86-64 the kernel module...which is untested on RPi). However on the amlogic boards I have, the exact same code results in corrupted image frames being returned. The camera responds properly to control messages, and I do get data via bulk transfer, but the packets are not uniformly sized as they should be, and data is missing (converting the raw data to an image shows broken line alignment, indicating missing data) What I've tried: Tested 5.9.14 and 4.19 kernels Tested armhf and aarch64 Tested LePotato and ODroid-C4 Tested Kernerl-module, libusb, binary SDK Tested synchronous and asynchronous bulk transfers Tested with powered USB hub as well as directly plugged into SBC Tested with conservative and performance governors In all the above cases the camera performs the same way, yet there are no issues on RPi3, RPi4 or X86-64. I'm not sure what other options I might have to debug. I'm guessing it is something related to the USB stack, but it must be subtle, since I've seen no issues with other USB devices. I have looked at the traces in wireshark, and there is nothing obvious (besides that the bulk transfers are not uniformly the correct size) Does anyone have any ideas for other ways I may continue debug?
  3. I am measuring current through the 5V input (not at the wall) and am nowhere near 0.125A
  4. I have a 5.2V 2.5A supply that I use (same one I use for my RPi). I hard-booted without an HDMI cable attached, and current dropped by 10mA to 0.206mA with no devices plugged in (except for ethernet). I'll probably live with what I have for now, but getting down to .125 at idle would be really impressive.
  5. @Da Xue Do you have an example configuration of how to disable HDMI? Those are pretty sizeable gains compared to what I'm currently seeing. Also, I'm trying to figure out if overlays are supported for the DTB? I can rebuild the DTB, but it means I need to maintain it long term, and I'd rather not need to rebuild the DTB every time I update the kernel if I can avoid it.
  6. I was curious if anyone had worked on power management for the S905X. My Le Potato was idling around 0.32A@5.1V = ~1.5W The LibreElec guys documented idle current ~2/3 of that here so I was curious what was going on. Of course I am running a 4.18 armbian kernel (I assume they were using a 3.14 kernel for their tests) so I was never going to match their numbers precisely, but 33% more power seemed like an awful lot. Then I realized I had a USB thumb-drive installed, so I did some experimentation... My numbers were generated using an inline USB power meter that measures pretty accurately compared to a bench meter. My initial findings: Idle with no USB connections: 0.215A Idle with 16GB USB3 stick in USB port 1: 0.291A Idle with 16GB USB3 stick in USB port 2-4: 0.323A Idle with USB2UART in USB port 1: 0.225A Idle with USB2UART in USB port 2-4: 0.257A Idle with 2 USB2UART adapters (ports are irrelevant)" 0.280A It should be noted that enabling autosuspend for USB: echo 'auto' > '/sys/bus/usb/devices/<...>/power/control'; Does drop the idle power back to 0.215 when USB is not in use. I don't need the thumb drive, but I do need 2 USB2UART adapters plugged in and running all he time, so autosuspend isn't very helpful for my use case. I may look into disabling the serial console and use that instead of one of the USB2UART adapters, which should be able to save me ~55mA. Does anyone else have any recommendations to lower the idle power? This box will sit at idle most of the time, and my goal is to be able to run it for 24hours from a ~100Wh battery. On the RPi, it is possible to disable LEDs and HDMI to save some power. Are there similar setting for the LePotato?
  7. Here is an alternative solution that doesn't require a UART...i didn't test these exact steps, but I believe they should work. Again, note that step (5) will make it impossible to boot back to Android OR to mount Balbes's images onto EMMC 1) install Balbes's 5.59 debian-stretch-default onto USB/SD( it is important to use a 4.xx kernel for this method!): https://yadi.sk/d/pHxaRAs-tZiei/5.59/20180829 2) Follow his instructions to setup multiboot: https://forum.armbian.com/topic/2419-armbian-for-amlogic-s905-and-s905x/ 3) Reboot into armbian 4) From armbian, download the official 'Le Potato image' ( You could also put this on a second USB drive and mount it in Armbian) 5) Copy the image onto EMMC: sudo dd if=<path to armbian.img> of=/dev/mmcblk0 bs=4096 status=progress 6) Fixup armbianEnv.txt: 6a) sudo mount /dev/mmcblk0p1 /mnt 6b) sudo sh -c 'echo "bloader=ext4load mmc 1:1" >> /boot/armbianEnv.txt' 7) remove USB/SD and reboot
  8. Thanks again @Tido. I ended up using that image to install multiboot, which was indeed very helpful. While the install.sh script included won't work as is (need to change some paths since it is setup to install on mmc1), and the install.sh from 3.14 won't work with this image because the /dev paths are completely different, this was really helpful to understand how the boot process and upgrade works. In the end, I didn't use Balbes's boot at all. His multboot isn't compatible with stock Armbian, and whle it is probably possible to write an aml_autoscript which would work, I didn't bother. Here is my process of installing a stock Armbian system on a Le Potato's EMMC. The nand-sata-install almost works properly, I'm not sure if the issue is in u-boot or armbian, but I'll try to file a bug when I figure out where. This process gives full access to the full EMMC (The legacy u-boot wastes ~3GB in random partitions). Note that because these steps erase all of the partitions, it would be challenging to go back to Android in the future. 1) put Armbian official 'le potato' image on sd card 2) install sd card into le-potato and remove emmc 3) install UART onto 'le potato' and connect to PC @ 115200 baud 4) power up le potato 5) press enter several times in serial terminal to enter u-boot 6) install emmc 7) type 'run distro_bootcmd' in serial terminal 8) boot into Armbian...setup root and user, etc 9) sudo cfdisk /dev/mmcblk0 9a) remove all partitions. 9b) create a single linux partition (type 83) that fills the whole disk 9c) write changes 10) ls -l /dev/mmcblk0* and ensure you do not see mmcblk0p2-p14 10a) if you see any partitions (/dev/mmcblk0p2-p14) you need to reboot and go through steps 4-8 again 11) sudo nand-sata-install 11a) select emmc 11b) select ext4 11c) let the installation complete 11d) complete but DO NOT REBOOT 12) sudo mount /dev/mmcblk0p1 /mnt 13) sudo sh -c 'echo "bloader=ext4load mmc 1:1" >> /boot/armbianEnv.txt' 14) shutdown, remove sd card and reboot steps 11d-13 are needed because u-boot 2018.05 sets 'bloader=ext4load mmc 0:1' which forces booting the sdcard. This should ideally be calculated in either armbian's boot.scr or in u-boot itself
  9. Thanks @Tido I did indeed miss that. Thta would probably be the easiest way to get this working. I, however, tend to prefer the hard way. Balbes appears to be working with the legacy uboot shipped by Amlogic. Armbian is using 2018.05 (probably soon to be 2018.07) which actually has mainline support for the le potato. I'd much prefer to use the more modern version (that also doesn't require all those partitions). I'm going to continue trying to figure out what that will take
  10. Here is my current progress... Note: I have not yet been able to boot directly from the emmc into Armbian. I was not able to get balbes150's images to boot with emmc installed. Not sure why, but it wasn't too interesting to me since I want to run a 4.17 kernel. I was able to boot into a current armbian (via SSD) with the emmc module enabled via: 1) install armbian to an sd-card, boot and configure without emmc installed 2) connect a serial UART connecton to the UART pins on the le potato (baud 115200) 3) boot or reboot le-potato (still without emmc) 4) press enter several times in serial-console to enter u-boot prompt 5) install emmc module (while in u-boot prompt) 6) type 'run distro_bootcmd' in serial console to load armbian from sd-card This at least gets me a current armbian env with the emmc available: Device Boot Start End Sectors Size Id Type /dev/mmcblk0p1 0 8191 8192 4M 83 Linux /dev/mmcblk0p2 73728 204799 131072 64M 83 Linux /dev/mmcblk0p3 221184 1269759 1048576 512M 83 Linux /dev/mmcblk0p4 1269760 25800703 24530944 11.7G 5 Extended /dev/mmcblk0p5 1286144 1302527 16384 8M 83 Linux /dev/mmcblk0p6 1318912 1384447 65536 32M 83 Linux /dev/mmcblk0p7 1400832 1466367 65536 32M 83 Linux /dev/mmcblk0p8 1482752 1499135 16384 8M 83 Linux /dev/mmcblk0p9 1515520 1531903 16384 8M 83 Linux /dev/mmcblk0p10 1548288 1613823 65536 32M 83 Linux /dev/mmcblk0p11 1630208 1695743 65536 32M 83 Linux /dev/mmcblk0p12 1712128 1777663 65536 32M 83 Linux /dev/mmcblk0p13 1794048 5988351 4194304 2G 83 Linux /dev/mmcblk0p14 6004736 30535679 24530944 11.7G 83 Linux Looking at the u-boot code from armbian, I am not sure it will be able to boot emmc without modification. It seems to only load from mmc or usb...I think we need to boot from emmc? I have to play with it some more. Alternatives are to try to use use the existing u-boot on the emmc, or to use balbes150's u-boot with a FAT fs... I am currently going through the nand-sata-install script to make sure it isn't likley to break anything before I try it. One thing I am happy to see...The EMMC is much faster than the fastest sd card I have. Comparison: EMMC: | | Read(MB/s)|Write(MB/s)| |------|-----------|-----------| |Seq1M | 75.438| 41.317| |Seq32M| 80.075| 43.023| | 512K | 72.856| 39.066| | 4K | 14.463| 15.634| SD (Samsung Extreme 16GB) | | Read(MB/s)|Write(MB/s)| |------|-----------|-----------| |Seq1M | 21.873| 14.821| |Seq32M| 21.917| 15.424| | 512K | 21.121| 12.297| | 4K | 7.578| 0.926| Same SD card (Sandisk Extreme 16GB) in PC on USB3 port: | | Read(MB/s)|Write(MB/s)| |------|-----------|-----------| |Seq1M | 72.737| 48.762| |Seq32M| 72.847| 49.757| | 512K | 67.712| 32.398| | 4K | 6.694| 0.750| So we can see that the emmc provides massively improved sequential and random-access performance on the le potato.
  11. @Tido, thanks. I was hoping there were instructions that would let me work directly with Armbian. I need to run a nightly kernel. I am unsure whether I can intsall @Balbes150's image and then install a kernel on top of it (from eMMC) since it won't have the right dtb. I don't suppose Balbes150 has instructions on builiding his kernel? or is it all in the dtb and if I copy that from one of his images, it will be enough? I'll give it a shot.
  12. Sorry to revive this topic after many months, but are there recent instructions to copy Armbian to the eMMC? When I boot with the eMMC installed, it boots into Android. If I look at the SD card, I have ls -ld /boot lrwxrwxrwx 1 root root 18 Aug 25 13:17 dtb -> dtb-4.18.5-meson64 drwxr-xr-x 3 root root 4096 Jul 24 12:06 dtb-4.14.57-meson64 drwxr-xr-x 3 root root 4096 Aug 25 13:17 dtb-4.18.5-meson64 lrwxrwxrwx 1 root root 19 Jul 24 12:06 dtb.old -> dtb-4.14.57-meson64 I don't see a dtb.img to remove. How can I boot into armbian with the eMMC module installed?
  13. Using kernel 4.14.65, I get a usb-driver crash when accessing the top left port (topmost, nearest the ethernet port) of the Le potato. Plugging any device into this port results in the following kernel message and prevents the use of usb until reboot. There is no kernel stacktrace. As long as I don't plug anything into that port, the other 3 ports on the board work fine. [ 292.242434] usb 1-2: new full-speed USB device number 7 using xhci-hcd [ 302.562341] xhci-hcd xhci-hcd.0.auto: xHCI host not responding to stop endpoint command. [ 302.583217] xhci-hcd xhci-hcd.0.auto: Host halt failed, -110 [ 302.583231] xhci-hcd xhci-hcd.0.auto: xHCI host controller not responding, assume dead [ 302.583287] xhci-hcd xhci-hcd.0.auto: HC died; cleaning up [ 302.583527] usb usb1-port2: couldn't allocate usb_device [ 302.583578] usb 1-1: USB disconnect, device number 2 Is this a known issue? I looked areound and didn't see any other reports like it. I switched to a 4.18.5 nightly, and all 4 ports work fine there. Interestingly the 'bad' port enumerates as '1-2', where the others enumerate as 1-1.1 - 1-1.3 (I was expectng either '1-1.0' or '1-1.4'), and the current port '1-1' appears to be: Bus 001 Device 002: ID 05e3:0610 Genesys Logic, Inc. 4-port hub So I it looks like the top-left USB port is not hooked up to the usb hub on the le-potato?
  14. So after rebuilding the kernel with: CONFIG_NETCONSOLE=m CONFIG_NETCONSOLE_DYNAMIC=y I can confirm that netconsole does indeed work properly on my 'le potato'. Is there a process to request that this config option be included in the default Armbian builds? It will be annoying to need to rebuild my kernel manually forever more. Edit: I opened a request since it seems kernel config changes are appropriate here: https://github.com/armbian/build/issues/1086
  15. Thanks. I see it here: drivers/net/ethernet/stmicro/stmmac/stmmac_main.c whch is the same directory that dwmac-meson8b.c and if I'm reading the Makefile right, it looks like that may be included in the meson8b driver. I guess that is enough for me to go ahead and try the build and see how it goes.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines