Clearfog[Pro] Possible change in temperature reporting between 4.14(next) and 4.19(dev)

[Heisath]

Armbianmonitor:

http://ix.io/1Hf0

Hello,

 

today I tried upgrading my ClearfogPro Kernel from 4.14.106 (next) to 4.19.20(dev). So far everything seems to be working (samba, dnsmasq, minidlna, network etc.), see also attached armbianmonitor link.  Great work @ armbian.

 

I also noticed that the reported temperature by "cat /sys/devices/virtual/thermal/thermal_zone0/temp" seems to be about 20°C lower than with the old kernel. I appreciate this, because it seems to be closer to the real value (measured with thermal probe at heatsink).  The old 4.14 kernel always reported some value around 65-70°C which seemed a bit high for idling (cpu running at 800Mhz like 80% of the time). The new value of 35°C is quite realistic I guess.

 

Does anyone know / have information about a change in temperature reading on the clearfog in the last kernel upgrades? 

 

EDIT:

Checked in the kernel diff between 4.14 and 4.19 and there are some changes to https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/thermal/armada_thermal.c?h=linux-4.19.y

They definitely  changed something regarding some trim values - though I don't understand enough to really say if that changes the temperature reading.

 

But if it did it might also be interesting for the Helios4 guys, I remember seeing some questions about high temperatures in their thread. @gprovost could this be related?

 

 

 

Can I somehow help getting the 4.19 Kernel to be next? Like specific things to test?

Or is your plan to skip 4.19 completely and go directly to 5.x?

 

 

Greetings,

count-doku

[gprovost]

Thanks for the info and pointer. Now I understand where this -20°C tweak we asked about here comes from

It means it wasn't so smart to remove already the tweak... well at least it will already be aligned when armbian mvebu next jump to 4.19 or 5.x

 

The kernel change you mention are from this commit and effectively it didn't made it to v4.14

https://github.com/torvalds/linux/commit/8c0b888f6610d0ebbc4bdfb52d2fef9f4a11adfc

I'm also not 100% sure how this bitwise tweak works :/

FYI The Marvell errata (#132698) mentioned in the commit is an internal errata, it wasn't even made public.

[Igor]

  On 4/26/2019 at 7:20 AM, count-doku said:

Can I somehow help getting the 4.19 Kernel to be next? Like specific things to test?

Or is your plan to skip 4.19 completely and go directly to 5.x?

Expand  

IIRC we postponed upgrade to 4.19.y (at the time others were bumped to it) because lack of time for testing and some problems (forgot the details). IMO moving to 4.19.y makes sense, but testing would needed. There is no need to wait for 5.x

What this means for Helios4 @gprovost?

[Heisath]

Okay then I will make a backup of my clearfog setup, update kernel via armbian-config and test it. If nothing breaks it stays on, and I will report here in a week or so.

 

For the Helios:

Don't think it matters alot - maybe just re-add the -20°C tweak...

[gprovost]

  On 4/26/2019 at 11:39 AM, Igor said:

What this means for Helios4 @gprovost?

Expand  

 

We need some times to look, it won't be straight forward... some patched would need to be rework most probably, some patched would also need to be remove since some of our stuff made it upstream but not all. With @aprayoga we will start to look and report in this thread or new one.

 

  On 4/26/2019 at 5:32 PM, count-doku said:

For the Helios:

Don't think it matters alot - maybe just re-add the -20°C tweak... 

Expand  

Igor is not talking about the -20c tweak which was anyway just a cosmetic thingy for all mvebu platform.

 

There is a lot of kernel patches for mvebu and we need to insure all apply well on 4.19... for Helios4 one or two might be a bit tricky. Anyway we will work on it.

 

[Igor]

  On 4/27/2019 at 6:02 AM, gprovost said:

There is a lot of kernel patches for mvebu and we need to insure all apply well on 4.19... for Helios4 one or two might be a bit tricky. Anyway we will work on it.

Expand  

Indeed. I tried to do some progress but stuck on u-boot - I am unable to build a working legacy u-boot ... not sure what's going on. It just stops this way:
 

  Reveal hidden contents

U-Boot 2013.01 (Apr 27 2019 - 20:32:55) Marvell version: 2015_T1.0p11

Board: A38x-Customer-Board-1
SoC:   MV88F6828 Rev A0
       running 2 CPUs
CPU:   ARM Cortex A9 MPCore (Rev 1) LE
       CPU 0
       CPU    @ 1600 [MHz]
       L2     @ 800 [MHz]
       TClock @ 250 [MHz]
       DDR3    @ 800 [MHz]
       DDR3 32 Bit Width,FastPath Memory Access, DLB Enabled, ECC Disabled
DRAM:  1 GiB
MMC:   mv_sdh: 0
*** Warning - bad CRC, using default environment

PCI-e 1 (IF 0 - bus 0) Root Complex Interface, Detected Link X1, GEN 1.1
PCI-e 1: Detected No Link.
USB2.0 0: Host Mode
USB3.0 0: Host Mode
USB3.0 1: Host Mode

Map:   Code:                    0x3fed6000:0x3ff98098
       BSS:                     0x3ffefd54
       Stack:                   0x3f9c5f20
       Heap:                    0x3f9c6000:0x3fed6000
       U-Boot Environment:      0x000f0000:0x00100000 (MMC)

Board configuration detected:
Net:
|  port  | Interface | PHY address  |
|--------|-----------|--------------|
| egiga0 |   RGMII   |     0x00     |
| egiga1 |   SGMII   |   In-Band    |
| egiga2 |   SGMII   |   In-Band    |
egiga0 [PRIME], egiga1, egiga2
Hit any key to stop autoboot:  0
Unknown command 'echo' - try 'help'
Unknown command 'run' - try 'help'
Unknown command 'echo' - try 'help'
Unknown command 'run' - try 'help'
Unknown command 'echo' - try 'help'
Unknown command 'tftpboot' - try 'help'
Unknown command 'tftpboot' - try 'help'
Unknown command 'setenv' - try 'help'
Unknown command 'bootz' - try 'help'

 

 

[gprovost]

@Igor If we move Next branch to kernel 4.19, then should we move Default branch to kernel 4.14 ?

 

I don't really see the point of letting Default branch pointing to a supposedly 'vendor provided' kernel stuck at 4.4.

[Igor]

  On 4/30/2019 at 4:59 AM, gprovost said:

@Igor If we move Next branch to kernel 4.19, then should we move Default branch to kernel 4.14 ?

 

I don't really see the point of letting Default branch pointing to a supposedly 'vendor provided' kernel stuck at 4.4.

Expand  

 

Yes. 4.4 seems to be dead anyway, but first we need to make sure future NEXT 4.19.y is working fine.

[gprovost]

  On 4/30/2019 at 5:33 AM, Igor said:

Yes. 4.4 seems to be dead anyway, but first we need to make sure future NEXT 4.19.y is working fine.

Expand  

 

Yes we are working on it, we just wanted to ask the question first of the intention for Default if we move the pointer for Next branch ;-)

[Igor]

  On 4/30/2019 at 5:37 AM, gprovost said:

Yes we are working on it, we just wanted to ask the question first of the intention for Default if we move the pointer for Next branch ;-)

Expand  

 

I can't recall if there is any feature that was not brought to 4.14.y and exists only in 4.4 ... which is IIRC not even fully stable.  Therefore I think it can be dumped. I hope to bump u-boot to 2019.04 as well.