Headless setup of NixOS on raspberry pi3 - raspberry-pi3

Having followed Zupo's execellent post which was mentioned in a NixOs Weekly, I wondered if it might be possible to setup a rasberry pi3 without the need for a monitor and use wifi rather than an ethernet cable.
There are all ready several blogs that set up raspbian headlessly by the addition of an ssh file in the boot directory and wpa_supplicant.conf in the /etc/wpa_supplicant directory, but I am unsure how to achieve this in the NixOS way.
Any help appreciated.

Related

modprobe: FATAL: Module lirc_rpi not found in directory /lib/modules/5.10.92-v7+

I am trying to Configure Lirc for my Rpi 3b+ for a personal project. I am using this guide. When running sudo modprobe lirc_rpiI get the error of modprobe: FATAL: Module lirc_rpi not found in directory /lib/modules/5.10.92-v7+ Can anyone help me solve this?
That LIRC should not work on Rpi is a misunderstanding. LIRC works on all linux systems, RPi included, but certainly not on Arduino (Arduino don't run Linux).
The basic problem is that the guide you refer to is severely outdated. In particular, the hardware.conf file is not used on modern LIRC installations.
As for the possible need for a lirc_rpi kernel moduled this depends on the actual use case. In most cases, LIRC uses either the serial ports or the lirc0 device, neither of which needing any specific kernel module.
The complete upstream docs are available at https://www.lirc.org/html/configuration-guide.html. It might be possible to give some more feedback if you describe your use case in more detail.
Lirc is not meant to work on raspberry pi, only other computers. You should use something else like an ardino. Good luck

M300 OSDK - drone version not obtained

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.

NodeMCU version unknown

I'm new with NodeMCU firmware use. I have a Amica ESP-12E (v2?) dev kit connected to a DHT22 which I program using the Arduino IDE. All is setup and working fine.
My problem came when I wanted to update NodeMCU firmware. Since I don't really know what came pre installed from China, I downloaded ESPlorer to try to determine NodeMCU version. I get the following "error" when I reset the dev board:
Communication with MCU..Got answer! Communication with MCU established.
AutoDetect firmware...
Can't autodetect firmware, because proper answer not received (may be unknown firmware).
Please, reset module or continue.
{{a long string of weird characters that I can't copy and paste appear here}}
At this point I'm totally clueless about what version of firmware I have. Is there a way to obtain NodeMCU firmware version by software via Arduino IDE code, ESPlorer GUI or something similar?
On the other hand, is there a really easy way to compile/download latest NodeMCU firmware BIN file? Even one with all the modules active will be fine for me now, I'm just trying to understand and test things.
You seem to be confusing two very different platforms. I leave out some details as not to confuse you any further.
Arduino: you use Arduino programming in the Arduino IDE then build and install a binary to your device whenever the application changes. No NodeMCU firmware needed!
NodeMCU: you flash the NodeMCU firmware once (e.g. using esptool.py) and then upload Lua code (e.g. using ESPlorer) whenever the application changes. This is more lightweight than the Arduino platform.
On the other hand, is there a really easy way to compile/download
latest NodeMCU firmware BIN file?
Yes, have a look at the NodeMCU documentation at http://nodemcu.readthedocs.io/en/latest/en/build/. The easiest is to use the cloud builder at https://nodemcu-build.com/. I currently suggest to build from the dev branch because flashing is easier with it.
As pointed out you have several options for firmware and you'll need to make a choice as to which suits you going forward. If you are going to stick with the Nodemcu LUA firmware you can determine the version by typing:
print(node.info())
at the command line prompt.
There are alternatives to using ESPlorer e.g. Putty or Coolterm that will give you the raw output from the device with no interpretation. So if you have the correct serial port settings and the device plugged into the USB port it will show the banner when you reset giving an indication of the origin and version of the installed firmware.
In ESPlorer, there is an option under settings which if unchecked will stop looking checking for the version of the code.
For whatever reason, ESPlorer is not designed to read nodemcu version.
The error message throws you off, could lead you to think, there is an error.
At best, the above error can be ignored. It has no impact at all. In background, init.lua is up and running.

QEMU for Win7 hosting Debian : no more able to connect to the network

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 !

controlling hub power from linux shell

I am using a buildroot image (3.12 kernel) running on my raspberry Pi with a USB LED light connected to it and I want to control on/off through the CLI.
I went through this. However, there is no control or level file in the power folder.
Is there any kernel configuration that I have to enable to get this ?
Found the answer to this. I have to enable PM_SUSPEND in the kernel configuration to get the class files. But then, as mentioned in the comments, RaspberryPi has the power lines directly connected to the power rails

Resources