[root@noyb devuan]# mkdir raspi2 raspi3
[root@noyb devuan]# mount -o loop,offset=$((512*8192)) devuan_ascii_2.0.0_armhf_raspi2.img raspi2
[root@noyb devuan]# mount -o loop,offset=$((512*2048)) devuan_ascii_2.0.0_arm64_raspi3.img raspi3
^^^
Differing partitioning, doesn't matter
[root@noyb devuan]# diff raspi2 raspi3
Binary files raspi2/bcm2708-rpi-0-w.dtb and raspi3/bcm2708-rpi-0-w.dtb differ
Binary files raspi2/bcm2708-rpi-b.dtb and raspi3/bcm2708-rpi-b.dtb differ
Binary files raspi2/bcm2708-rpi-b-plus.dtb and raspi3/bcm2708-rpi-b-plus.dtb differ
Binary files raspi2/bcm2708-rpi-cm.dtb and raspi3/bcm2708-rpi-cm.dtb differ
Binary files raspi2/bcm2709-rpi-2-b.dtb and raspi3/bcm2709-rpi-2-b.dtb differ
Binary files raspi2/bcm2710-rpi-3-b.dtb and raspi3/bcm2710-rpi-3-b.dtb differ
Binary files raspi2/bcm2710-rpi-3-b-plus.dtb and raspi3/bcm2710-rpi-3-b-plus.dtb differ
Binary files raspi2/bcm2710-rpi-cm3.dtb and raspi3/bcm2710-rpi-cm3.dtb differ
Differing Device Tree Blobs can matter
Only in raspi2: bcm2835-rpi-a.dtb
Only in raspi2: bcm2835-rpi-a-plus.dtb
Only in raspi2: bcm2835-rpi-b.dtb
Only in raspi2: bcm2835-rpi-b-plus.dtb
Only in raspi2: bcm2835-rpi-b-rev2.dtb
Only in raspi2: bcm2835-rpi-zero.dtb
Only in raspi2: bcm2835-rpi-zero-w.dtb
Only in raspi2: bcm2836-rpi-2-b.dtb
Binary files raspi2/bcm2837-rpi-3-b.dtb and raspi3/bcm2837-rpi-3-b.dtb differ
Definitely matters, Broadcom code in your case will cause bcm2837-rpi-3-b.dtb to be pulled in
regardless of which image you use (assuming you have a 3B not a 3B+).
diff raspi2/config.txt raspi3/config.txt
11a12,14
>
> ## kernel
> kernel=kernel8.img
Binary files raspi2/kernel7.img and raspi3/kernel7.img differ
Only in raspi3: kernel8.img
Common subdirectories: raspi2/overlays and raspi3/overlays
Suggest you copy the Broadcom binaries from a working image (stretch) and overwrite the devuan
ones (or just try with bcm2837-rpi-3-b.dtb copied over first).
Please report back the results if you try this.
As an aside VLC media player has just been ported to work with the Raspberry Pi accelerated
hardware.
On 05/12/2018 09:56, Joril wrote:
> On 05/12/2018 10:41, KatolaZ wrote:
>
>>> I see, but the Raspbian Stretch image (armhf) DOES work on this RPI3B,
>>> shouldn't the Devuan armhf image work too?
>>
>> According to which principle should the Devuan rpi2 image work as
>> well, again? ;) There is an rpi3 image in the same place you have
>> found the rpi2.
>
> Yes, but according to devuan_ascii/embedded/README.txt, section "Currently supported images"
> this bullet point:
>
> * Raspberry Pi 2 and 3 (raspi2)
>
> led me to believe there was a chance that the raspi2 image would work on a RPI3 as well :)
>
>
>> The choice made by raspbian is sub-optimal: they basically provide an
>> image for the least common config that works on as many different rpi
>> models as possible. If you have an armv8, why should you run it as if
>> it were an armv7 or an armv6? o_O
>
> I'd agree with you but what I'm trying to run on this rpi is omxplayer, a Raspberry-tailored
> media player that's only provided as a 32bit binary :/ [1]
> I know I could try to compile it manually but there is evidence [2] that it would not be a
> speedy task, so I thought that if I could get Devuan armhf to run, I'd get the job done more
> quickly.
>
> 1: https://omxplayer.sconde.net
> 2: https://unix.stackexchange.com/questions/235844/does-omxplayer-run-on-normal-64bit
> _______________________________________________
> Dng mailing list
> Dng@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng