now I have the following issue:
sudo pip3 install paho-mqtt gives following message:
Could not find a version that satisfies the requirement paho-mqtt( from version: ) No matching distribution found for paho-mqtt. Some advice?
MQTT & EV3DEV with Edimax EW-7811Un V2
- download http://rubirobot.ru/files/img/ev3dev-S-rubirobot.img.xz
- Flash onto drive with balenaEtcher
Network registration over SSH did not work
setup Connection over display for Edimax
Upgrade EV3DEV
- sudo apt update
- sudo apt upgrade
- sudo reboot (sudo shutdown now)
May take upto 15 min.
Think about batteries
Install MQTT Broker over SSH on EV
- sudo apt-get install mosquitto
- systemctl status mosquitto -> not active!
- sudo systemctl restart mosquitto
- systemctl status mosquitto -> active
Install paho-mqtt
- sudo apt update
- sudo apt install python3-paho-mqtt
Hello, how does the EV3 decide whether the SD card is bootable or not? I'm trying to make an SD card that I can use both in a Raspberry Pi (with a RPi OS install) and ev3dev. What I've tried is copying the files from the ev3dev boot partition to the raspberry pi boot partition, then shrinking the rpi rootfs and creating a new partition for the ev3dev rootfs. With this, the Raspberry Pi 3 boots up to the system just fine, but the EV3 loads the stock firmware so I assume it does not count the card as bootable.
https://github.com/ev3dev/u-boot/blob/5f439eafe235f7db922cf846b7e7e5dce568c821/include/configs/legoev3.h#L81-L103 would be a good place to start
Looking around that file, I think I should change
distro_bootpart from 2 to 3 in CONFIG_EXTRA_ENV_SETTINGS
I have replaced that value, compiled u-boot, put it in place, but it still skips to the builtin firmware
if it is loading the stock firmware, then there is probably something wrong with boot.scr
does it work if you flash the official ev3dev image to the SD card?
There is a different copy of u-boot in the EV3 flash memory. https://github.com/mindboards/ev3sources/blob/master/extra/uboot-03.20.00.13/include/configs/da850evm.h#L242-L258
This is what runs first. so it looks for boot.scr, if it finds that, it runs it, if that fails, it tries booting Linux from a uImage file in the FAT partition, if that fails, it boots from the flash memory.
Maybe the RPi SD card used exFAT instead of FAT32 or something like that?
if you have a way to get a serial console, that could help debug
I'll probably get one soon though, it's useful for many purposes
There is a few megabytes of free space at the start of the partition table, is it possible that it might cause problems?
Nevermind, official image also has that and it works
Partition type is set to
W95 FAT32 (LBA) and not W95 FAT32
I'll try to change that
Did not work
IT BOOTS IF I REMOVE THE RASPBERRY PI BOOT FILES
??
Android/ bcm2710-rpi-2-b.dtb fixup4.dat overlays/
COPYING.linux bcm2710-rpi-3-b-plus.dtb fixup4cd.dat start.elf
LICENCE.broadcom bcm2710-rpi-3-b.dtb fixup4db.dat start4.elf
LOST.DIR/ bcm2710-rpi-cm3.dtb fixup4x.dat start4cd.elf
System Volume Information/ bcm2711-rpi-4-b.dtb fixup_cd.dat start4db.elf
bcm2708-rpi-b-plus.dtb bcm2711-rpi-400.dtb fixup_db.dat start4x.elf
bcm2708-rpi-b-rev1.dtb bcm2711-rpi-cm4.dtb fixup_x.dat start_cd.elf
bcm2708-rpi-b.dtb issue.txt start_db.elf
bcm2708-rpi-cm.dtb bootcode.bin kernel.img start_x.elf
bcm2708-rpi-zero-w.dtb cmdline.txt kernel7.img
bcm2708-rpi-zero.dtb config.txt kernel7l.img
bcm2709-rpi-2-b.dtb fixup.dat kernel8.img
(with boot.scr, uEnv.txt and u-boot.bin removed)
maybe u-boot does not like too much files on a FAT filesystem
Or it has problems with long filenames
Update: It still boots up with an intentionally long filename
I think I'll debug this further tomorrow
Thank you @dlech so much for the help