I am writing to you to ask you about the following: I am working on a custom embedded Linux distro for a Zynq700 based board. One of the features to be added is support for USB in host mode, which I have achieved.
This way, with rootfs I have a combination of udev rules & fstab entries that allow a given USB stick to be automounted with a certain conditions. However, if we change the filesystem to initramfs, the flash drive not only does not automount, it is not recognised.
I looked at the output of dmesg, lsusb & lsmod to make sure of this & confirmed that no driver function is called. In addition, I also notice that the USB stick is not receiving any power (the HW is correct because with the same hdf and roofs I have it functional).
Is there some peculiarity of initramfs compared to rootfs that I'm missing that has this effect?
Thanks in advance
Related
I tried to run PyUSB under Windows and in a first test simply wanted to read out all my USB devices with usb.core.find(find_all = True). But that failed with backends iibusb0 and libusb1. Meanwhile I read several times that I need to change the driver of the device I want to talk to through PyUSB eg using Zadig.
As I want to use the devices with different programs I can't change drivers.
So my questions are:
is changing the driver the only way to use PyUSB?
what other options are there for USB under Python and Windows
I downloaded USBTreeView and that runs fine - without changing any drivers. How does it do it? (I know its not Python)
Thanks for any help
Martin
I am trying to set up Tinker Board headlessly as I don't have access to a wired keyboard and mouse.
One method I know that works for Raspi is by creating an SSH file while setting it up and a wpa_supplicant.conf file to provide wifi details. I have flashed the latest Tinker OS v2.2.9 onto the eMMC present on the board as per the instructions. But, in this case I am not able to access the drive once flashed (Contrary to raspi setup).
Is there a way to set it up headlessly?
Thank you for taking out time to read this and helping out.
I have recently bought a USB, which is initially formatted using exFAT. Then I tried wiping it off and format it with ext4. But then, Linux Mint 20 doesn't seem to be able to mount it. When I checked the "disks" utility, the USB appeared, but it just displayed the loading loop. I tried to cancel the mount job, no luck either. Then I tried a live Linux Mint 19, also can't open the USB, so this is clearly not a problem with my existing computer.
Then I booted up my Windows copy (dual boot with Mint 20), plugged the USB in, formatted it to exFAT, and Windows can then open it. Then I boot up Mint 20 and live Mint 19 and both can open it. So my question is, do USB manufacturers restrict the type of filesystems a USB can have? I have never heard of this phenomenon, and can you give me some source to read more?
So I have dug into this a whole lot for the past few days and I think I know what's wrong. I tried to create an ext4 partition, didn't work. I then tried to fix it using fsck, also no dice. Then I tried to create an ext4 partition with less size (60GB), and then it works, with no corruption. It turns out that I just got scammed by the manufacturer.
I was running Linux in an ARM-based detailed CPU model in FS mode, and I was doing the checkpoint after the first time I launched the CPU. However, I needed to frequently transfer files to the ARM Linux, so I am wondering if there is any way to do so without re-launching the CPU model again (e.g., directly transfer files to linux through sftp, or mounting the host file system)? Great thanks!
Currently, I just added the files to the Linux disk image, and relaunched the CPU model from scratch (which takes more than 1.5 hours).
Here are the possibilities that I'm aware of:
use 9P. Semi outdated patch at: http://gem5.org/WA-gem5 but easy to get working again.
9P is designed explicitly to mount host directories on guest, and is therefore the nicest solution.
See also: https://github.com/cirosantilli2/gem5-issues/issues/24
QEMU example.
use a second disk image, normally squashfs which is easy to generate quickly and conveniently.
unmount, make changes to image, remount. So a bit annoying, but doable, and possibly the easiest to get working.
Not currently exposed on fs.py, patch mentioned at: How to attach multiple disk images in a simulation with gem5 fs.py?
m5 readfile + zip.
OK, this is likely going to be slow, just mentioning it ;-)
guest to host networking: as you mentioned, if that were possible, you could mount FTPs around
However I don't think it is supported, see: How to do port forwarding from guest to host and vice versa in gem5?
Also it would require messing with NFS setups on host / guest, which is always a bad thing.
With QEMU, as usual, it is possible.
The current situation is a mess. The main reason is that it is a bit hard to nicely integrate 9P / multidisk into fs.py. But I'm certain it is possible, we just need a brave soul.
Related thread about how to expand an existing disk image if space is your concern: https://www.mail-archive.com/gem5-users#gem5.org/msg16494.html
Mailing list thread: https://www.mail-archive.com/gem5-users#gem5.org/msg16477.html
This question is related to Upload Arduino code on virtual serial port through Arduino IDE. The main problem is being able to upload code onto virtual COM port instead of using Arduino so I could take the binary code output and use it in some other application. The problem with that is that the process of uploading is also related to the bootloader on the Arduino and that's why the upload process never reaches 100%. The suggested solution was either to implement a bootloader in my application or use something that is already out there.
My question now is can I make use of the different programmer modes in the Arduino IDE to sort of by-pass the bootloader so the upload process can reach 100% and the code would actually reach the virtual COM port?
Any help would be highly appreciated. Thanks
Sounds like your Virtual Serial Port driver is getting stuck on some timeouts or buffers. The IDE calls avrdude with a specific protocol to match with what is built into the Arduino's bootloader, loaded on the AVR. There are other bootloader (in fact many, too many to mention), some of which may have different timing and such, but to use them would basically no longer be Arduino. to see the possibilities .\avrdude.exe -c.
If you are just trying to get a dump of what is going over the Serial port. I have used Virtual Serial Ports Emulator . It is very versatile in that its modular, allowing you to build up what you want.
Also, as mentioned from the other threads about this, note the data over the serial port is formated ontop of the STK500 protocol. You also mention in other thread that you don't want to use another tool to get the data. Whereas in order to use another protocol you would need to change the source compiler.java and rebuild the project as to call avrdude with the new protocol. So you might as well just get it with another tool. see below this will tie back in.
you can get the raw binary, from what is being fed to avrdude. Where as it may not be initially obvious. As avrdude get ELF not BIN. The Arduino IDE contains all of avr-gcc and its tools. Where avr-objcopy located in .\Arduino\hardware\tools\avr\bin can convert the IDE's output that is funneled into avrdude, to the binary you likely desire. No need for scoping the serial port stream.
To do this by hand, You need to locate IDE's temp working directory, by enabling the IDE's verbose compile prints. And also likely put avr-objcopy in your path. then simply call it as in the below example, substituting your sketch's filename, in place of mine.
C:\Users\mflaga\AppData\Local\Temp\build6135656488044319492.tmp>avr-objcopy -I ihex FilePlayer.cpp.hex -O binary FilePlayer.cpp.bin
Where as you could replace avrdude.exe with a batchfile that calls both avrdude and avr-objcopy to automat