ODROID-HC4 extras (LED control, DDR/CPU thermal in hwmon, PWM control)

[rpardini]

Some patches for the ODROID-HC4.

• make the red led accessible in /sys/class/leds/ (so it can be eg turned off, just like the blue led)

  • this is just added to the device tree, very simple, low risk, my own patch

• add thermal support for cpu/ddr, in the hopes of getting the fan in HC4 going according to temps

  • this is for all meson64, @tobetter's patch - seems useful for all meson, low risk

• another @tobetter patch for changing the manual/auto control of pwm1 via pwm1_enable in hwmon

  • I'd rather a cooling map in the DTS, but this works for now
  • totally HC4-specific, but patch affects pwm everywhere, so I used separate board-folder patch
  • upstream does not seem super-happy about it (see commit, there's links)

• still missing / much wanted:

  • SATA power control (GPIO?) -- so we can reset the SATA drives when things go wrong
  • MTD-style SPI flash, so we can write u-boot to SPI (16mb) and be done with SD cards

[igorpecovnik]

MTD-style SPI flash, so we can write u-boot to SPI (16mb) and be done with SD cards

Worse case we can implement SPI boot loader in a binary form - but I guess this should probably be a separate project / PR. And possible without Petitboot?

upstream does not seem super-happy about it (see commit, there's links)

Like many hacks that resist in our patch areas :) Guenter looks like he knows what he is talking about ... "In-kernel thermal control would in general be preferred" which I do agree with.

Perhaps break this whole thing to - "yes we merge at once" and "other things". Doing fan the correct way will probably take some time? SPI boot too.

[rpardini]

MTD-style SPI flash, so we can write u-boot to SPI (16mb) and be done with SD cards
Worse case we can implement SPI boot loader in a binary form - but I guess this should probably be a separate project / PR. And possible without Petitboot?

The HC4 has no eMMC. That means the juggle needed to write to SPI on the C4 (shorten the eMMC band to 4bits, use the freed pins to talk via SPI to NOR) should not be needed. That way we could have a single DTB for the HC4 with the NOR permanently enabled/writable, and just write our own u-boot there (during nand-sata-install; u-boot will need SATA support at least) and overwrite Petitboot. It's better than telling users to flash_eraseall ...

This PR at this point contains no changes in this aspect.

Like many hacks that resist in our patch areas :) Guenter looks like he knows what he is talking about ... "In-kernel thermal control would in general be preferred" which I do agree with.

Yes. In this aspect the DTS for the HC4 is severely lacking. There are versions around with the trip points etc, I could hunt around and try to cobble one together, but would take time, and end nowhere. It's a new SBC so vendor should supply it eventually. I think N2+ has it already.

This PR at this point using that hacky patch at least lets me run the box via fancontrol, which is far from ideal, but does work. pwmconfig creates pretty gnuplot graphics. etc. See @tobetter's http://docs.linuxfactory.or.kr/guides/sensors.html#fanspeed-control

Perhaps break this whole thing to - "yes we merge at once" and "other things". Doing fan the correct way will probably take some time? SPI boot too.

See above. I proposed this as a "merge now" while I work on the other stuff.

[igorpecovnik]

totally HC4-specific, but patch affects pwm everywhere, so I used separate board-folder patch

This is not going to work, since kernel binary is common. We can have per board patches only for u-boot. This patch has to be a part of meson64 family. If it won't break others, namely N2+, we can merge.

[rpardini]

totally HC4-specific, but patch affects pwm everywhere, so I used separate board-folder patch
This is not going to work, since kernel binary is common. We can have per board patches only for u-boot. This patch has to be a part of meson64 family. If it won't break others, namely N2+, we can merge.

You mean that the official release builds a single kernel per-family? And board-xxx specific patch folders are ignored (or always included?) -- wondering how to handle this...

[igorpecovnik]

You mean that the official release builds a single kernel per-family? And board-xxx specific patch folders are ignored (or always included?) -- wondering how to handle this...

Without looking into the code ... patch per board is supported since this works and make sense on u-boot. But kernel is identical per family. Its anomaly ... if you build image for some other board, patch per this board will not be include.

I think we should only check if it affects Odroid N2+ (fan function) and merge.

[rpardini]

Yes, I never considered the official builds vs board-patches. I will split this into 3 PRs

• one for the red led, HC4 DTS only
• second for hwmon support in all of meson64 (should be safe)
• a third for pwm control, so we can test separately against n2+ (I just got one...)

[rpardini]

Done, #2585 #2586 #2587