[offtopic]Some cheap and tiny ARM devices.

[caseih]

You're right. I should have quoted the relevant posts I was responding to. It was greenink who said they " they have entrapped victims," which I heartily disagree with; it's simply not true. I also continued to disagree with your assertion that it's reasonable to require MS to continually modify the kernel and drivers of a non-shipping OS in maintenance mode to support new CPUs. It's quite likely that Windows 7 would run unmodified on the new chips, but only to a point, and maybe not so well (power management, for example). Windows requires chipset drivers (and the chipset is tied closely to the CPU) to function properly. I think rather than deal with the fallout from Windows not running well on the new CPUs, it's far easier and better (from their POV) to just only support the newest CPUs and chipsets from Windows 10. Sure it's a marketing decision, but there is a large tech component to the decision, and it's not really that unreasonable, nor is it really that bad for customers. As I maintain, very few people use the retail box license and would be in a position to transfer their license to a new machine anyway. I wouldn't be surprised if it was less than 1%

Anyway, that's all I meant.

[D.J.Peters]

BBC mcro bit MC for kids 32-Bit-ARM Cortex M0 CPU http://microbit.org

Joshy

[srvaldez]

In case anybody can run a aarch64 debian on some device; here's a FreeBasic build for it:
http://users.freebasic-portal.de/stw/bu ... -03-07.tgz
I'd really like to test it at some point in the future when arm64 is available for common devices like the rpi.

hello St_W
I have a pine64 with debian64 and freebasic is running ok, having problems executing the compiled program from geany but they run ok if launched from the terminal.
are there any parameters that need to be passed to the FreeBasic makefile in case I want to build the latest git version ?

thank you St_W

[srvaldez]

just tried to compile FreeBasic and ran into trouble, missing <sys/io.h> in src/rtlib/unix/hinit.c
I changed <sys/io.h> to <libio.h> and compiled ok but when a try to compile a basic program I get

unknown value aarch64 for -march
typedef signed char Int8

[St_W]

I have a pine64 with debian64 and freebasic is running ok [...]
are there any parameters that need to be passed to the FreeBasic makefile in case I want to build the latest git version ?

Hi srvaldez, really nice to hear that there's finally a 64-bit ARM board out there that also runs a 64-bit OS and 64-bit software including FreeBasic - so the effort to create a fbc build wasn't useless back then.

I built the binary about a year ago so I can't really remember how I did it. I searched for notes and found the following, which doesn't doesn't mention any build commands, however. So I guess there were no special arguments needed (or I forgot to write them down; or I there are additional notes I couldn't find right now; ... :-) ).

Additionally note that I did cross compile from x86_64 Debian as I did not have a native aarch64 system available.

Here are my raw notes:

CC src/rtlib/obj/linux-aarch64/hinit.o
src/rtlib/unix/hinit.c:12:20: fatal error: sys/io.h: No such file or directory
#include <sys/io.h>

--> use sys/uio.h (copy/symlink as sys/io.h)
/home/stw/gcc-linaro-4.8-2015.06-x86_64_aarch64-linux-gnu/aarch64-linux-gnu/libc/usr/include/sys/uio.h


src/rtlib/unix/hinit.c

#ifdef __aarch64__
#include <sys/uio.h>
#else
#include <sys/io.h>
#endif



These packages did not make it into Jessie so you need to install them from the Debian Cross-toolchains repository. Create /etc/apt/sources.list.d/crosstools.list containing:
deb http://emdebian.org/tools/debian/ jessie main
You will need the archive key installed.
curl http://emdebian.org/tools/debian/emdebi ... rchive.key | sudo apt-key add -
The key fingerprint is: 084C 6C6F 3915 9EDB 6796 9AA8 7DE0 8967 1804 772E (you will need to install curl in a bare chroot)
crossbuild-essential-<arch> packages exist to aid in installing the correct cross-packages. For instance to install the armhf cross-toolchain, first enable the foreign architecture (and update), then install crossbuild-essential-armhf :
sudo dpkg --add-architecture arm64
sudo apt-get update
sudo apt-get install crossbuild-essential-arm64
This will pull in the required packages to cross-build for the target architecture, namely libc6-dev:<arch>, gcc-<triplet>, g++-<triplet> and dpkg-cross. (Note that dpkg-cross was removed from jessie, but remains in the Debian Cross-toolchains repository).
Note that if you also have debian unstable enabled in your apt sources you are likely to hit dependency issues. Either disable it or add an apt-preference to prefer jessie:
echo "APT::Default-Release \"jessie\";" > /etc/apt/apt.conf.d/20defaultrelease

From <https://wiki.debian.org/CrossToolchains ... ebian_8.29>




apt-get install libncurses5-dev:arm64
apt-get install libgpm-dev:arm64
apt-get install libx11-dev:arm64
apt-get install mesa-common-dev:arm64
apt-get install libxpm-dev:arm64
apt-get install libxext-dev:arm64
apt-get install libxrandr-dev:arm64

X86_64
libffi-dev

//edit: found the compile command (cross-compilation); nothing special:

Code: Select all

make rtlib gfxlib2 TARGET=aarch64-linux-gnu
make TARGET=aarch64-linux-gnu FBC='bin/fbc_linux -i inc'

[srvaldez]

thank you St_W for the help, but for some reason my FB build won't compile any programs, but that's no problem as your version is quite recent.

[srvaldez]

ok I need your compiling experts advice, with St_W fbc build fbc -w all -v test.bas gives

compiling C: gcc -S -nostdlib -nostdinc -Wall -Wno-unused-label -Wno-unused-function -Wno-unused-variable -Wno-unused-but-set-variable -Wno-main -Werror-implicit-function-declaration -O0 -fno-strict-aliasing -frounding-math -fno-math-errno -fno-exceptions -fno-unwind-tables -fno-asynchronous-unwind-tables "test.c" -o "test.asm"

my fb build

compiling C: gcc -march=aarch64 -S -nostdlib -nostdinc -Wall -Wno-unused-label -Wno-unused-function -Wno-unused-variable -Wno-unused-but-set-variable -Wno-main -Werror-implicit-function-declaration -O0 -fno-strict-aliasing -frounding-math -fno-math-errno -fwrapv -fno-exceptions -fno-unwind-tables -fno-asynchronous-unwind-tables "test.c" -o "test.asm"

my fb emits -march=aarch64 -fwrapv extra, how can I build fb so that it will not pass those extra parameters to gcc?

[St_W]

[...] but when a try to compile a basic program I get

unknown value aarch64 for -march
typedef signed char Int8

I found the VM with the build and it seems that I also ran into that issue and just patched the source (without writing it down ..). Here's the diff:

Code: Select all

From c97920558b5821ec9d810785d6ffac0ecf90b86d Mon Sep 17 00:00:00 2001
From: stw
Date: Mon, 27 Mar 2017 01:55:19 +0200
Subject: [PATCH] aarch64 fixes

---
 src/compiler/fbc.bas   | 4 +++-
 src/rtlib/unix/hinit.c | 4 ++++
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/src/compiler/fbc.bas b/src/compiler/fbc.bas
index c759533df..19050863b 100644
--- a/src/compiler/fbc.bas
+++ b/src/compiler/fbc.bas
@@ -2753,7 +2753,9 @@ private function hCompileStage2Module( byval module as FBCIOFILE ptr ) as intege
 		if( fbc.cputype_is_native ) then
 			ln += "-march=native "
 		else
-			ln += "-march=" + *fbGetGccArch( ) + " "
+			if( fbGetCpuFamily( ) <> FB_CPUFAMILY_AARCH64 ) then
+				ln += "-march=" + *fbGetGccArch( ) + " "
+			end if
 		end if
 
 		if( fbGetOption( FB_COMPOPT_PIC ) ) then
diff --git a/src/rtlib/unix/hinit.c b/src/rtlib/unix/hinit.c
index d5bf27ca9..3a0fb0047 100644
--- a/src/rtlib/unix/hinit.c
+++ b/src/rtlib/unix/hinit.c
@@ -9,8 +9,12 @@
 #include <signal.h>
 #include <termcap.h>
 #ifdef HOST_LINUX
+#ifdef __aarch64__
+#include <sys/uio.h>
+#else
 #include <sys/io.h>
 #endif
+#endif
 #include <sys/ioctl.h>
 #include <fcntl.h>
 
-- 
2.11.1.windows.1

The change in "src/compiler/fbc.bas" is the relevant part in this case and should fix the problem. Maybe dkl or other compiler experts can give more information and/or a cleaner solution.

[srvaldez]

thank you very much St_W :=)

[St_W]

Maybe I can create a build job for aarch64 (ARMv8-A 64-bit) on my CI machine (Jenkins) next weekend to provide nightly git-builds for that platform too. May be useful to ensure that the code can be at least built for aarch64, but that's probably it.

Side benefit: I've to implement the build process as a script and thus generate some documentation :-)

[D.J.Peters]

A new tiny PocketBeagle with Octavo Systems OSD3358 1GHz ARM® Cortex-A8.




AM335x


Joshy

[D.J.Peters]

Is this pocket beagle 3.3V or 5V :-)

[srvaldez]

LOL, nice picture

[marcov]

Is this pocket beagle 3.3V or 5V :-)

If you smell something burning, the voltage is too high :-)

[D.J.Peters]

If you smell something burning, the voltage is too high :-)

No A=ampere makes a hot dog not the V=voltage ;-)

With other words you can touch 100,000 V with 0.1 A without any problems but never touch 0.1V with 100,000 A !

Joshy