For changes to take effect it would be necessary that you're using an image utilising script.bin and therefore you would've to use bin2fex/fex2bin to alter the contents. But please don't do this if you're not experienced and do a backup of your whole SD-card before. When editing/exchanging this stuff goes wrong then your board won't boot any longer.

Altering scaling_max_freq currently might not make a difference based on the assumption that only the 2 operating points in the fex file are used. But I had a look into the H3's SDK sources before and maybe the stuff in the dfvs table provided in the fex file only overwrites parts of the default table (that seems to use 1.2V for all frequencies). At the moment these are just wild assumptions and unfortunately I can not check myself since my H3 devices just left Shenzen.

That's why I started another thread and posted a preliminary RPi-Monitor template suitable to visualize relationships. According to Olimex reducing the DRAM bandwidth helps much with reducing the heat the H3 produces. Then it would be an easy one to try this out (and that's why I wrote the H3 template for RPi-Monitor). Adjust DRAM frequency by eg.

and have a look how temperatures change in different situations (while being idle, while running sysbench an all 4 or just 2 cores). That's the stuff I want to do when my Orange Pi arrives. But my main focus is underclocking to the limits. I had the fear the H3 would be broken by design and would consume many times as much as the A20 for example. But fortunately this is not the case :-)

Yes, that would be possible. I played recently with another board (LeMaker guitar, unfortunately not worth a look) that uses Actions Semi's S500 SoC. This beast and its PMU get really hot, exceeding easily 100°C. But there it was possible to define operating points in the sources to be able to clock the board up to 1.3 GHz (somewhat insane since then thermal throttling jumped in and the board became slower) and define a default of 1.1 GHz unless the user adjusted the value to his needs.

So it's possible to provide a dvfs table that starts at 480 MHz @ 1.04V (maybe even lower) and ends at 1536 MHz @ 1.5V (VDD_CPUX -- this is solely for 'extremity frequency when run benckmark or demo apk' not for normal use -- there the maximum rating is 1.4V and I really doubt that you can then run the SoC with 1.53 GHz).

The problem is to define the operating points in a sane way and test all these intensively. Since normally you try to define every operating point with lowest voltage possible to reduce both heat and consumption since even slight increases in voltage lead to a huge increase in both consumption/temperature. At least that's my goal with the OPi PC. Fortunately you can run all this stuff unattended, so I will set up a test environment to walk through a few hundred settings (with reboots in between -- did that already to test some u-boot settings to optimise network throughput on A20 boards)

Thanks.  I didn't know how all that worked.  I've built the sunxi-tools and created a new script.bin with such a table.  Operating at 1296 instead of 1536 (presumably 1.34v, according to the table i built) has already a noticeable effect on my temperatures.  Mostly I'm trying to find where I want to run at this point.  I just want to run all 4 cores at 100% reliably without resorting to active cooling.  I suspect I've alread achieved that (using a 1.5" heatsink), but I'll do more testing.

Using RPi-Monitor (or something similar you would've to adjust for H3 first) really helps with stuff like that. Please keep in mind that some of the stuff you try to have an eye on works in a very dynamic fashion (cpufrequency scaling, throttling and even CPU cores being shut down for thermal reasons).
Couldn't believe it before using RPi-Monitor the first time on a Banana Pi... but you get so many relationships that normally stay invisible or would be hard to check by just looking at graphs. And I would have an eye on DRAM frequency whether reducing the frequency there further helps.

And if you also double check with a small set of benchmarks then you also get the idea what you trade in for what (peak performance against chip temperatures)

My box is going to run a chess engine 24/7.  I get a good idea of the trade just looking at the nodes per second (nps) achieved.  It actually runs fine with 1 core at 100% on the default (overclocked @ 1.536) settings.  With 2 cores at 1536, temps start to get troublesome, approaching 70C.  This is all with a heatsink-- without one, even 1 core at default OrangePi settings causes CPU shutdowns.

I'm not sure what to do wrt heatsinks though.  I have a few lying around from old computers.  They are designed for northbridge or video card cooling maybe 10 years ago.  The one I'm using isn't perfect.   It is all copper, but it doesn't contact the H3 perfectly because it's larger than the H3 and other stuff interferes.  Basically the RAM chips aren't at exactly the same height, so the heatsink isn't contacting snugly on that side of the H3 chip.  I know this only because in messing with it a few times, the residual grease left on the heatsink isn't a square like you'd expect.  It's most prominent on the side away from the RAM chips.  Anyway, I've ordered other heatsinks, and I won't fully decide how to run until I can test them.