I just started working with a Beagle Bone Blue and I have installed the necessary drivers however when I go to http://192.168.7.2/, it say the site cannot be reached because it took too long to respond. I would really appreciate it if someone would help be. Thanks!
I think the kernel image you are using in BeagleBone Blue must be properly booted in the board or if you are using eMMC0 for booting the board,
Check the kernel logs of booting using minicom in Linux or putty/Terraterm in Windows.
Also, check if there is one folder creating as BeagleBone(Getting Started) in Windows after proper booting done.
If you are using Linux, check the same type of folder and verify the internet connectivity.
Try to use new kernel image available from https://beagleboard.org/latest-images
Boot it using sd Card and flash it on the board.
Then, try 192.168.7.2 in the browser.
It will be working if you follow the proper steps.
I hope it helps.
Related
I have built an image for the TQ Systems STKa8x Evaluation board with an i.MX8 QuadMax using the yocto project. The resulting image does not boot on the device. Can anyone help me interpret the warnings and errors occuring in the serial console output when trying to boot?
I think the the machine configuration might be wrong? The device hardware is ok, becaus the device boots using the included sd card.
Did you flash your Yocto image in your emmc or SDcard ? Here it seams that there is no partition table in your emmc which is normally embedded inside Linux image. It is more likely that the flash did not succeed.
Plus you can see warning from u-boot that he cannot load the device tree. Check your repository build/tmp/deploy/image/machine/*.dtb
You should also check if your linux image and device tree is flashed in the correct address.
Solved: The problem was caused by the SD card. I have used this SD card https://de.transcend-info.com/embedded/product/embedded-memory-cards/usd230i. Using another one solved my problem.
Since I cannot get the manifold 2 in my region, I created a cable according to https://forum.dji.com/forum.php?mod=viewthread&tid=219723.
The cable is connected via FTDI converter directly to the drone's OSDK port.
when connected to a serial terminal application I get data from the drone
Terminal
When I try to debug the flightcontrol-sample in Linux, I get the following:
LinuxOutput
Data is also received in Linux using 'screen' command.
testing the cable for 'loopback' works fine.
I have changed the port baud rate to several options (230400 & 921600) to no avail.
the ACM cable is connected through an additional USB port to the drone's port directly.
Am I missing some HW components in my setup?
I have entered all the relevant Linux commands to get the required permissions as advised in
https://developer.dji.com/onboard-sdk/documentation/quickstart/development-environment.html
&
https://developer.dji.com/onboard-sdk/documentation/quickstart/run-the-sample.html
Am I missing something in that department?
The final goal is to use STM32 as FC, but testing is easier using the Linux environment.
Any additional things I can test?
Are there other working setup designs I can try?
Thanks for your help.
i got M300 osdk connection up at Apr 2020.
So far not many issues. There are many tricks and rules that you need to follows e.g osdk adapter board usb type C seam side face inside. make sure osdk adapter board is powered up by checking the output supply voltage. 3.3V FTDI. and make sure it is pull up properly by checking voltage as well
After you check through the hardware.
the software has many tricks as well. for M300 only osdk/osdkros 4.0 and above can drive. The new userconfig.txt format changed and you have to change accordingly. and you can go through my checklist which I posted on DJI forum https://forum.dji.com/forum.php?mod=viewthread&tid=216529
If you really still have a problem. do provide photos on your connection, the terminal output for the error message.
As Dr. Yuan suggested, have a look at the UserConfig.txt file. Depending on which OSDK version you are using, it has a different format.
In my case, using osdk 3.9 configuring it this way solved my issues:
app_id : xxx (number)
app_key : xxx (number)
device : /dev/ttyUSB0
baudrate : 230400
Also check your FTDI cable, it once burned out for me and it was the reason for this error too. You should try a new one just in case.
I use the OSDK with a raspberry pi, in case you are using this kind of linux environment, I suggest you check the configuration files (cmdline.txt and config.txt) doing sudo nano /boot/cmdline.txt and same for config.txt.
my configuration for cmdline.txt is:
dwc_otg.lpm_enable=0 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait
And for config.txt just add this at the end:
enable_uart=1
init_uart_clock=64000000
start_x=1
I hope these can help and that I am not too late.
I'm fighting strongly against a problem that is making me crazy.
I’m extensively using QEMU over a Win7 64bits machine for running different Linux VMs (Debian, Raspbian).
In the past I configured the network following the QEMU instructions using the OpenVPN TAP device and network bridge in Win7 : it ran perfectly and the Linux machine was able to connect the “real world” networks, internet and so on.
In the last few days, on the contrary, this nice behavior stops working. The Windows situation is unmodified (the OpenVPN TAP driver settings are the same, the bridge is still there, when the bridge is active Windows still see the network, the TAP driver becomes “busy” when the QEMU VM starts as usual, the QEMU startup scripts are still the same…), but the emulated Linux system (whatever image I use) is unable to connect the network.
The “eth0” interface is active but unable to get the IP address from the DHCP and also using fixed IP address doesn’t solve the problem, since the IP address is not seen by the “real” network.
I have tried to uninstall and reinstall again the OpenVPN TAP driver, to downgrade Win QEMU to the previous version, but no way !
The only change that I made in the HOST configuration has been to install GNS3 (with its own TAP driver), but without including the QEMU VM in any GNS3 network.
Does anybody have suggestions regarding what kind of checks I have to do on QEMU in order to solve the problem ?
Any help will be appreciated
Regards
Ugo Poddine
I was finally able to get out.
I was forced to restore a previous system image : all attempts to uninstall and reinstall the OpenVPN TAP driver were useless.
The problem is probably due to the update of the OpenVPN TAP driver : with the v.9.0.0.9 no problem, but updating to the 9.21.1 seems to have generated the problem.
I'm now able to use again QEMU and GNS3 in network.
But what a strange case !
The host part will be a PC program made from c# in which I will use LibUSBdotnet to do the communication.
My problem is how do I make the Linux side pickup and respond. I don't really know where to start.
Whenever I try to search for it, all result show are "how linux communicates with a device attached to it".
Or it does not matter if a device is host or client, because they utilize the same pipes/bus?
Can I use something in "/dev/usb***"?
I have seen "libusb" which I believe is the linux cousin of libusbdotnet.
Can I somehow use this library? If anyone can show me the right direction, I would really appreciate it.
AFAIK libusb is the library for usb-host side, not for usb-device side. So you cannot use it in your case. I suggest the same as myninjaname said - to analyse one of the Linux usb gadget drivers as a start point.
I have a USB-to-Serial Adapter that is being recognized on my Mac in the System Information as being connected to the USB Hub but when I run ls /dev in Terminal the usbserial is not showing up. It was working up until this morning but now it is not. I have tried rebooting, changing USB slots and the lot. Any suggestions?
So after doing some research I have found that the Prolific driver that is designed for the USB-to-Serial adapter is a little unstable. Therefore I used a third party driver that seems to have fixed the problem 100%. You can find it here, http://xbsd.nl/2011/07/pl2303-serial-usb-on-osx-lion.html, I recommend it even if the Prolific driver seems to be working okay.
This problem is arising almost every time in windows. and as a solution we go to devise manager->other device->right click on that->update driver software->browse my computer for driver software->Let me pick from a list of device drivers on my computer-> USB controller-> next.
Here my suggestion is to delete the driver from is the place and try to reboot you pc once and then check for the results. hope you get ride of this, best of luck.