Support Raspberry Pi 2 with MoOde 9

[Sander]

Couldn't find a discussion on this, so I thought I'd just ask.

I have a Raspberry Pi 2B with an IQaudIO Pi-DAC+ running 8.3.9.
Seeing that MoOde 9 does not have an image for the 2B yet, I would appreciate it if this could be made available. The hardware itself is not scrap yet and an upgrade to a RPi 3 is still around € 40.

Is there any chance that MoOde 9 could be made available for the RPi 2B?

[Tim Curtis]

Not possible due to lack of project manpower. Generating a 32-bit image requires that all the packages in our CS repo are built and maintained for both 32b and 64b architectures. Just maintaining 64b architecture packages takes a significant amount of time and effort, so basically double that.

But who knows, maybe a dev somewhere will join the project and volunteer to to take on the 32-bit builds. I'll be happy to help out. :-)

[Sander]

Not possible due to lack of project manpower.

I purchased a RPi 3B and moved the HAT to the new device.
After 2 attempts the config restore worked (the first one never finished but I hadn't enabled SSH so could not get to the logfile). I still had to set the correct default audio advice afterwards, but the other settings have been transferred fine!

[Prince]

Hi,

I run the Pi1B with 512 MB exclusively for nostalgic reasons (I own a Pi4B also). I used the last moOde9 builder with 32bit support to upgrade to Bookworm. It's a dirty image where builders step3 had been skipped and the package dependencies had to be solved by hand afterwards (changing between moOde8 and moOde9 sources). I haven't checked all moOde's functions, but internetradio and upnp-stuff have been running well here for ~6 months. Very dirty but works rocksolid. 
(I can see your eyes rollin'  , but I love my 1B)

For cosmetic reasons, I checked for the incorrect memory size displayed (256MB instead of 512MB). The 1B has the old revision code. 

Code:

cat /proc/cpuinfo | awk -F': ' '/Revision/ {print $2}'
000e

My question is: Why is the revision-code 'and'-combined in the pirev.py-script with 0x17?

Code:

old_rev = OLD_REVISION_CODES[code&0x17]

In my case the code-variable has '14' ('0xe') stored in it. That is right and points to the right pi-model.
After the 'and'-combined with '0x17' the old_rev becomes to '6' and points to the wrong model.

# code  mod   rev    mem      manufacturer
    0x002: ["B", "1.0", "256MB", "Egoman"],
    0x003: ["B", "1.0", "256MB", "Egoman"],
    0x004: ["B", "2.0", "256MB", "Sony UK"],
    0x005: ["B", "2.0", "256MB", "Qisda"],
    0x006: ["B", "2.0", "256MB", "Egoman"],         <- Wrong model shown in moOde
    0x007: ["A", "2.0", "256MB", "Egoman"],
    0x008: ["A", "2.0", "256MB", "Sony UK"],
    0x009: ["A", "2.0", "256MB", "Qisda"],
    0x00d: ["B", "2.0", "512MB", "Egoman"],
    0x00e: ["B", "2.0", "512MB", "Sony UK"],    <- my model
    0x00f: ["B", "2.0", "512MB", "Egoman"],
    0x010: ["B+", "1.2", "512MB", "Sony UK"],
    0x011: ["CM1", "1.0", "512MB", "Sony UK"],
    0x012: ["A+", "1.1", "256MB", "Sony UK"],
    0x013: ["B+", "1.2", "512MB", "Embest"],
    0x014: ["CM1", "1.0", "512MB", "Embest"],
    0x015: ["A+", "1.1", "256MB/512MB", "Embest"]

 


Thanks

[Tim Curtis]

That's a good question. I don't recall why that was done.

Your best bet is prolly to just edit the code and remove it.

[TheOldPresbyope]

Probably should have masked with 0x1F instead of 0x17?

[Prince]

Of course 0x1F will do the trick. Thank you both, now I can sleep well tonight. 

[Tim Curtis]

Looking at the code I don't think &0x17 may be a bug and is not actually needed.

[TheOldPresbyope]

Looking at the code I don't think &0x17 may be a bug and is not actually needed.

Having now had a chance to read both the code and the RPF documentation, I agree. The bit masking should be unnecessary...but it's up to @Prince to confirm. I have no early models to test with 

Regards,
Kent

[Tim Curtis]

Looking at the code I don't think &0x17 may be a bug and is not actually needed.

Having now had a chance to read both the code and the RPF documentation, I agree. The bit masking should be unnecessary...but it's up to @Prince to confirm. I have no early models to test with 

Regards,
Kent

You can simulate the codes using the python cli but I actually tested earlier today using my Pi-1B and no issues :-)

Code:

pi@moode32bit:~ $ cat /proc/cpuinfo
processor       : 0
model name      : ARMv6-compatible processor rev 7 (v6l)
BogoMIPS        : 697.95
Features        : half thumb fastmult vfp edsp java tls
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x0
CPU part        : 0xb76
CPU revision    : 7

Hardware        : BCM2835
Revision        : 000e
Serial          : 00000000fcf9f81d
Model           : Raspberry Pi Model B Rev 2

# As-is with 0x17 mask
pi@moode32bit:~ $ /var/www/util/pirev.py 
0xe     B       2.0     256MB   Egoman  ?

# Actual RAM
pi@moode32bit:~ $ vcgencmd get_mem arm
arm=448M
pi@moode32bit:~ $ vcgencmd get_mem gpu
gpu=64M

# Samsung DRAM chip part number on this Pi-1B
K4P4G324EB-AGC1
https://www.datasheets.com/part-details/k4p4g324eb-agc1-samsung-electronics-53733965

# Without 0x17 mask
pi@moode32bit:~ $ /var/www/util/pirev.py
0xe     B       2.0     512MB   Sony UK ?