tarkin000

Ah, that explains it then. I suppose the integer value is close enough, and it would be trivial to write a script that reads the value and pipes into bc for conversion into Farenheit.

When I booted my OPi Lite with Armbian, there was a delay before anything would print to the screen (hdmi). As the instructions advise, it will boot once, take care of some configuration, and reboot. The whole process for boot/reboot takes about three minutes with a fresh image. Patience is the key. Hope this helps.

Hello, My sunxi_tp_temp always reports the same value (429496576.0). After digging around, it seems like it's not reading the correct registers. According to the H3 datasheet(1), pp 255-258, the thermal sensor base is at 0x01C25000. The data register is at 0x01C25080. Using the mod_mmio.h and sunxi_tp_temp.c as a guide, I wrote a little utility to print the current SoC temp. #include <stdio.h> #include "mod_mmio.h" // improved temperature print utility // GPLv2 int main(int argc, char *argv[]) { float reading,celsius,farenheit; reading = (float)mmio_read(0x01c25080); //celsius = (reading - 2794.0) / -14.882; Allwinner H3 datasheet formula celsius = ((reading - 2794.0) / -14.882) - 51.0; // adjustment based on observation farenheit = celsius * 1.8 + 32; #ifdef CEL_ONLY printf("%0.3f°C\n",celsius); #elif defined FAR_ONLY printf("%0.3f°F\n",farenheit); #else printf("%0.3f°C / %0.3f°F\n",celsius,farenheit,reading); #endif if (argc > 1) printf("raw sensor data: %0.3f\n",reading); return 0; } You may have to change the value 51.0; I have no idea why the formula from the datasheet didn't work, I just printed the results of their formula, compared it to the value obtained from /sys/class/thermal/thermal_zone0/temp, and came up with this 'fudge factor'. You can grab mod_mmio.h from here: https://github.com/igorpecovnik/lib/tree/master/scripts/sunxi-temp I have left defines in for celsius only (#define CEL_ONLY), farenheit only (#define FAR_ONLY), and the default is to display both (to train my American mind to get used to SI units). I named my executable pitemp: gcc -o pitemp pitemp.c I copied it to /usr/local/bin, chowned it to root, and made it suid root so I don't have to type sudo everytime. (not recommended for security reasons). Hope this helps someone. (1): You can download the datasheet (pdf, ~7.5MB) from here: http://linux-sunxi.org/H3 (scroll down halfway, it's under "Documentation")

I sort of solved it. I switched from using readline to linenoise, and that killed my having to set up some sort of repository or chroot for Debian packages (more below). As linenoise, Duktape, and a single header are all my binary needs, it now builds with my crosstool-ng compiler and a simple Makefile. I created a handy shell wrapper called armbian-gcc that adjusts paths before invoking gcc. I was able to make some headway with the libreadline6-dev package: crosstool-ng creates a directory for every toolchain, usually in ~/x-tool This toolchain directory, and its sub-directories, are readonly; a quick chmod fixes this. I created a sub-directory named 'pkgs', and from there I used apt-get source libreadline6-dev, which handily works without being root, as it downloads to whatever directory you are in. Then, I invoked configure like this: CC=arm-unknown-linux-gnueabihf-gcc ./configure --prefix=/home/foo/x-tool/arm-unknown-linux-gnueabihf --build=i686-linux-gnu --host=arm-unknown-linux-gnueabihf Then, make, and make install as usual. By setting the prefix, the library gets installed to ~/x-tool/<toolchain>/lib, and headers in ~/x-tool/<toolchain>/include, which are accessed by default when compiling with the toolchain. At this point, I hit a snag with not having built termcap, which is when I decided to go with linenoise. Theoretically, as long as you calculate the dependencies yourself (with the help of the Debian Jessie package lists), you can build any Jessie package for Arm on any host with a working crosstool-ng. I imagine targeting Ubuntu is much the same- calculate the dependencies, fetch the sources matching your target version, configure with CC,--build,--host, and --prefix, make, install. Hope this helps someone else.

Hello every one, I have used crosstool-ng on my Jessie server (x86), and downloaded the linaro toolchain for my Ubuntu (x64 / 16.04) laptop, but ran into a wall both times: the cross-compilers won't (and now that I think about it, can't) link to the host libraries. Do I simply get all the sources for the libraries I want/need, and adjust their configure parameters to point to dedicated directory, and then build my target? Is there an easy way to manage the versions / dependencies to match Jessie (the version on my target OPi)? I am trying to compile Duktape with libreadline, if that matters. Thanks, Steve

Downloaded and tested on Orange Pi lite. -p Showed the usual info, used the -g option to turn off GPU, rebooted, -p showed it was off.