+-- To do list for SA64 ------------------------+ Incoming (to sort) ================================================================================ Build infrastructure: ================================================================================ P1: native setup arm/aarch64: * aarch64: Add distcc support at boot Research sugests 1 x x86/64 box dedicated for ARM and the others for aarch64. Now x-toolchain needs building. P1: x-toolchain for aarch64 Refreshed myself of the workings of this script. It'll be reasonably straight forward to add A64 support. I was going to let the RockPro64 build entirely natively, but since it's easy to update the toolchain, I'll do that as it'll decrease the build time immensely! Todo: set up routing for distccd to enable ARMv7 & ARMv8 toolchain selection based on client request. I have some ideas about this - probably just hack something up based on ports. * Tune down logging of distccd because the build logs quickly reach a few GBs during world builds. P1: u-boot for RockPro64. This will consist of the bootable SD card The RockPro boot will be initialised from the MicroSD card, with installtion on to attached storage. Later I'll look at other options, but this is the standard route and (see my insights below on the life span of that type of storage) makes the most sense for the target use of Slackware (desktop/server). * Made progress. Existing tools can be re-used in the main. P1: k/ do-src-update -needs A64 for .config support kernel.SlackBuild & a/kernel-modules already support multi-arch from the ARMv5 days. I left it in for reference, in case I ever added another architecture! ./_clean_other_pkg_sh to support multi-arch Since all of the build is automated for the Kernels, all I really need is to get an initial generic ARMv8 Kernel that - at least initially - works on the RockPro64. Note: I may bootstrap this on ARMv7 with the x-compiler, to make use of the existing automation within the native Slackware environment. P1: r2b - needs to accommodate aarch64/arm during package checks pre-build. Currently it's working because the ARMv7 port is up to date in the main. Need to add --prehook and --posthook to r2b to add hacks during the bootstrap process. --helper-singlepass : add this, R2B_HELPERSINGLEPASS=Yes This is for KDE and X11 builds to perform a single build pass rather than the usual 3. For world OS rebuilds, we don't benefit from multiple passes here as no shared libraries are changing. Do this prior to KDE rebuild on ARM. * Extract version/build control from kde.SlackBuild into a Sud Helper. * Work to be done whilst other packages are building. * Copy r2b to the local system to run on zippy whilst these changes are tested on mojo. X11 needs doing too but it's less important. P1: r2b needs to log bath failures per arch - probably prepend $SLKPORTARCH to the notice, since it's only a manual check and none of the rest of the reporting tools consume it for status. P2: r2b - collect build errors from kde and x11 builds, report on them & use in the decision making process of whether a batch succeeded or not. Needs to happen during later stage bootstraps of SA64 (possibly pass 50 or 60). P3: Sud needs to accomodate ARM and aarch64 checks: Apart from KDE and X11 (deferred until AArch64 is built or I'm stirred into changing it), both archs should be in lockstep. However, some pkgs such as TB, SM won't exist on ARM so we can bypass the check using the .nobuild- files Other than that, a missing file on *one* arch doesn't constitute update failure. But mismatches between binary arch pkgs and arm/build scripts must be flagged. ... x86 package file info: version=20.3.2 build=1 [ file: mesa-20.3.2-x86_64-1 ] ... ARM package file info: version=20.3.1 build=2 [ file: mesa-20.3.1-arm-2 ] ... arm/build script info: version=20.3.1 build=2 P3: Ensure Slackware version within installation documentation macros works for a64. P4: Wire into beehive glimpse. P4: Add Mirror 'sync' Status for supported releases (inc. current) to web site/dowload area, or perhaps into beehive glimpse. LOE: 10 mins, maybe 20 if I type slow. P4: Switch ARM progenitor platform to SA64. The plan is to have SA64 take the lead, as it'll find failures more expediently. Upon the first successful completion of a change batch, it'll signal ARMv7 to kick-off its build. This proves that the build scripts and the order works. DEP: KDE and x11 r2b helpers need to signal r2b, and collate the failures ready for manual inspection. Target date: Post SlkARM15 release, pre SA64 release. P99: dbuild: Support package dependency bypasses to build packages manually (outside of r2b). Operating System Packages ================================================================================ P1: glibc, gcc, and kernel headers. For bootstrapping a kernel headers, a make defconfig for any aarch64 will suffice followed by the make headers install. k/: P2: Determine modules required for initrd on RockPRo64. Determine changes required to kernel.SlackBuild and the README's. x/x11.SlackBuild: Make build errors surface into r2b. kde/kde/kde.SlackBuild: Make build errors work per arch and package. Make build errors surface into r2b. Add deduplication support to handle multiple update batches. a/mkinitrd: README files - perhaps unify or separate per arch. Apart from the different arch *name*, the processes should remain consistent. Probably not much to do. a/aaa_elflibs: Modularise to blend into Sud and r2b so that it's automated. Make r2b handle removal of temporary support libraries upon successful build passes. a/aaa_base: Support aarch64. root's email messages may need changing. ap/slackpkg: Prior to release ensure doinst.sh contains the aarch64 support. It probably will by this point as the update is already upstream so I'll consume it in due course. note: mirrors.slackware.com: doesn't support ARM, exclude. ap,xap/vim: # If dynamic support for Ruby works with this $ARCH, then allow it: if [ "$ARCH" = "x86_64" ]; then RUBYDYNAMIC="=dynamic" fi mesa/ May want to remove these during bootstrap: + -Dvulkan-device-select-layer=true \ + -Dopengl=true \ + -Dglx=dri \ d/gcc: Status: bootstrapable SlackBuild is prepared and tested on ARMv7. Set up the gcc build options to build for the ARMv8-a base. I have a list of some of the build options I'll look into at a later stage. d/llvm: Update for 64bit, bootstrap with gcc. Update toolchain name a la : clang.toolchains.i586.triple.diff.gz source/readme: Can refer to the slackwarearm source as this is the master tree and sa64 tree isn't required for users to re-build ARM packages from ARM src tree. x11: Determine what video modules are required and build them. Presently the x11 tag files are unified with ARM. May want to split if there's zero sense including drivers for ARM SoCs if they aren't present for aarch64 machines. The r2b helper will need work to handle both arm and aarch64 packages, particularly if they will diverge. It's easier to build them for both architectures - TBD. idea: Perhaps have separate arch build lists for the supplemental pacages. $SLKPORTARCH-list, and have the x11 r2b helper consume it. The list will contain any duplicated packages. Existing bootstrap build script can probably be re-used (if really needed) with probably little work. x11-skel: Determine defaults. Add platform auto-select as for ARM with default as some generic driver like fb on ARM, or for RockPro64. ap/linuxdoc-tools Ironically slacktrack, my own packaging tool isn't yet compatible with the Slackware ARM build system and needs to be handled out-of-band. P4: Should probably fix that, although OTOT it's me that updates it anyway and therefore doesn't matter too much. Can be Sud'd to mark for handling by an r2b callout upon successful completion of the batch in the same way as builder for mini roots. tcl/tk,tix tk is picking /usr/lib. Needs some investigation. aaa_libraries and the finder script. there are only /lib and /lib64 in the package, so store the 64bit versions of libraries and filter it in slackbuild easiest is to do a pipe FILTER="| sed 's?lib64?lib/?g'" into a pipeline. eval $( echo tar tvvf ~/slackware64-current/slackware64/a/aaa_elflibs-15.0-x86_64-27.txz $FILTER ) xap/xine-lib has x8664 stuff - prolly needs more arch flags --enable-pic" l/cryptopp.SlackBuild some 64bit stuff in LDFLAGS prolly not needed Board support stuff ================================================================================ https://www.linuxquestions.org/questions/slackware-arm-108/modified-argon-one-case-fan-script-for-raspberry-pi-4-without-systemd-4175689926 Fan script. Installer ================================================================================ Write installation documentation for RockPro64. Base on the standard approach for ARM. Confirmed - looks like it'll work. Need to determine memory address ranges per object type. Add aarch64 support to arm wrapper. miniroots ================================================================================ These are no longer required, and having looked around recently I've seen that they're being used in place of the installer. This isn't what these miniroots were created for - they were for me to bootstrap new hardware support, for which installer support would follow. The only reason for these miniroots was back when there was no generic ARM kernel, but you don't need them now. These are my reasons for why I am opposed to supplying 'images': These OS images are typically written to the ARM board's onboard/'embedded' storage (eMMC) or a (micro) SD card. It works, but many years ago during the 2nd ARM port of Slackware, I was letting the build system build the environment hundreds of times over (which allows the packages to include the maximum feature set (static config options aside) that can be obtained from within the Slackware OS environment (with the exception of home-brewed packages (e.g. from slackbuilds.org)). After a couple of passes, the machine segfaulted and kernel paniced (which is up there in the list of things that's going to potentially be a time sink (particularly if the build log is lost or truncated)). Fortunately the problem was hardware: building the packages had caused the storage to be destroyed. This onboard stuff seems to be pretty poor quality and have a relatively short life span; and you'll never know at which point your data will be inaccessible or corrupt. I destroyed SD cards too. USB sticks. I have destroyed all forms of storage building Slackware. However, hard disks - my machines are _hammered_ all day, almost every day and I only just replaced one Seagate SATA drive on the lead Orange Pi as it developed some bad sectors a couple of days ago. This machine has been building using the same disk since the hard float port began in 2016 (and the disk had already been heavily used in an x86 box prior to that!). On ARMv7, in the domain of the GUI: a basic window manager is usable but the more recent/user friendly/easy window managers are too heavy. ARMv7 is fine for file/email/(small scale) web servers, NAT gateways: I've been running mine for years, and of course Slackware is completely stable: upon boot of the self-hosted environment (which I'm currently prepararing for AArch64), Slackware is entirely self-hosted; which in and of itself proves the stability within multiple domains. I'd like for the user base to have the same stability I enjoy. Still in the domain of the GUI, with AArch64, this so far looks to be a game changer where AArch64 can be taken seriously as a desktop and for server tasks that require more horse power than the ARMv7 architecture can cater for. Aligning with web technologies is also important: in the past Slackware ARM was locked out of much of the web due to closed source technologies such as 'flash'. There was a binary provided by Adobe which I did get working with some weird game about some nonsense with trees and balloons, but it was slow and didn't work with everything I tried. And who wants to include a binary in an Open Source project (even if the licencing permits, which would entail me spending my time reading some licence for some nasty-looking web technology which, for me weren't even used on any of the sites I ever visited, but I didn't know about the tastes of the ARM user base! -- and after that I'd probably need to seek permission to use it.). If you want people to use stuff, you need to put it there. My pholosophy is that if you can provide something that you happen to like doing, and it benefits others - why not? Eventually people realise the value of what they have. Anyhow, I digress: the message is that the timing seems to be right for AArch64 for it to be taken seriously in the desktop/laptop domain. Therefore, this author suggests that if you plan on using Slackware as a desktop or server (which is always and continues to be this author's goal for Slackware ARM), you'd do best to install Slackware onto standard hard disks (preferably SSDs, preferably attached via (e)SATA or USB at a minmum. However, if you plan to use Slackware ARM/SA64 as an embedded device (some sort of home automation, sensor type stuff) - the onboard storage will be more than sufficient for this and this author encourages you to use that because the machine will be more compact and discreet. This author also advises that if you go down this route, you disable swap and tune down logging down to a minimum. Additionally, Slackware is moving far faster than previously (in case anybody hadn't noticed ;-) ), so if you're following -current and your OS is on SD/eMMC, it'll become faulty more quickly. The message is: install Slackware using the regular installer, on to standard hard disks/SSD. Actions: * Remove miniroots from tree. * Remove support option from web site. If you used these in the community, instead get the installer working for your device. That's what I'm doing! Bootware ================================================================================ Update u-boot ARM build scripts to support RockPro64 et al. Probably just split these off into new A64 versions as I can't see a need to rebuild u-boot for ARM devices now. Future archs ================================================================================ QEMU: Community can own it this time, as per arm. I won't work on it this time around. Pinebook Pro. Website ================================================================================ Add aarch64 to arm. and www. www.slack website Changelog script needs updating Revise entry about arm/aarch64 options on LQ post. +-- Completed tasks ------------------------+ 12345678901234567890123456789012345678901234567890123456789012345678901234567890 handy | ruler | | | | | | | +--------------------------+ Tue Feb 9 21:00:22 GMT 2021 bootware: Researching modifications required to the ARM uboot build scripts. http://opensource.rock-chips.com/wiki_Boot_option k/: Initial integration support for building armv7 & armv8 kernels. Looking into x-toolchain and multi-compiler support for distcc. Fixed up for 64bit/bootstrapping: l/qt5 ap/at ap/squashfs-tools l/t1lib x/fontconfig l/icu4c d/clisp l/liboil l/lcms l/aalib l/libvisual-plugins l/slang1 l/pygobject xap/sane l/mozjs78 l/gjs l/libcddb l/libieee1284 l/libvisual l/libasyncns l/t1lib l/libmcrypt l/libnjb l/libid3tag l/startup-notification ap/dc3dd ap/cdparanoia ap/madplay l/id3lib ap/a2ps ap/moc ap/normalize ap/squashfs-tools ap/jed ap/at ap/radeontool n/pidentd n/libnetfilter_log n/metamail n/htdig n/net-snmp x/xcm x/libhangul x/anthy xap/electricsheep xap/pidgin xap/ddd xap/xmms xap/x3270 xap/gftp xap/rdesktop d/indent a/kbd a/mtx a/floppy d/llvm +--------------------------+ Fri Feb 5 12:34:06 GMT 2021 Fixed up for 64bit/bootstrapping: l/gtk+ l/gd ap/lxc +--------------------------+ Sat Jan 30 09:18:36 UTC 2021 Researched https://patchwork.ozlabs.org/project/gcc/patch/20101005050958.3841D401B2@magilla.sf.frob.com/ Fixed up for 64bit/bootstrapping: d/device-tree-compiler d/binutils d/python2 l/db48 l/liboggz l/mm l/pilot-link l/libatasmart l/chmlib l/libidl l/libwnck l/fuse l/gamin l/libtheora l/SDL2_gfx l/libglade (partly) l/libmad l/a52dec l/mhash l/glib2 l/gtk+ l/pcre2 l/jmtpfs tcl/tclx x/glew +--------------------------+ Thu Jan 28 21:12:01 GMT 2021 a/coreutils: Patched for A64. More x-toolchain updates and fixes for ARM. +--------------------------+ Wed Jan 27 19:30:52 GMT 2021 * Merged in changes from x86 into ARM tree. * l/glibc d/gcc SA64 test packages built. Getting there. +--------------------------+ Sun Jan 24 21:35:09 GMT 2021 * Updated x-toolchain for binutils-2.36 a/{lzip,xz,tar,pkgtools}: switched to gzip compression (.tgz) to remove a few barriers during bootstrap and world rebuilds. +--------------------------+ Sat Jan 23 09:35:09 GMT 2021 * Updated x-toolchain for glibc-2.32. Assessed effort to add A64 support: 30 mins + 10 for the compile. +--------------------------+ Fri Jan 22 19:32:15 EST 2021 More build system preparations: * Prepared Sud to rip out the autoconf --target build options from almost all SlackBuilds during the world rebuild. This is legacy from the original ARMv3 port and is no longer required, and in some cases becomes embedded within package binary names or paths. * 64bit fixes: n/openssl. * Tested 64bit-fixed package build scripts on ARM. * slackkit: Completed updates to align with revised ARM build scripts. * Replaced zippy's failing disk in preparation for world build. * Reinstalled all ARM builders to re-sync with build system. * Hacked slackkit on the 14.2 builder to support use of build scripts from -current when necessary. d/llvm: Added bootstrap hooks to enable initial build with gcc. Needs more work for 64bit, but it's lower priority since with but a few exceptions, Slackware packages are built with gcc. Some packages require llvm, but they are the minority and aren't required to create the initial self-hosted bootable Slackware minimal OS. Therefore llvm can be deprioritised until 15.0's released. +--------------------------+ Thu Jan 21 18:03:49 EST 2021 * 64bit fixes: d/gcc, l/{glibc,libsamplerate,l/libcap}, a/bzip2 * Research gcc build options for SA64. Will apply some patches from git for SA64 but not ARM as it's too late in the devel cycle (as 15.0 is within view!). We'll see if there is any fallout from the ARM world rebuild though! * Completed preparations on ARM src tree for world rebuild with slackkit-1.20. Thanks to Patrick for phasing the rebuild to help smooth the process on ARM! +--------------------------+ Tue Jan 19 21:18:10 GMT 2021 * Preparing to sidestep Slackware world re-build #1 for ARM, do upgrades (including glibc-2.32), then perform a single world rebuild post glibc-2.33 in Feb. SA64 will pick up the changes whilst it's in bootstrap mode, running circles around the ARMv7 machine, as it makes its way majestically through the sea. (mixed metaphors are the best, aren't they. They're like a dream that cuts to new contexts, yet unlike with a mixed metaphor where you recognise the juxtaposition of two similar yet contrasting contexts - in a dream you don't notice the (what one could describe as abrupt) context change; *until* you wake up and have a larger context in which to place the dream). Or is it just me that thinks that. Anyway, what is on the list: * P1: Need to update r2b to add logging of date stamp of new packages to fix the rare bug where packages are built successfully but detected as failed. Will test this branch on the SA64 platform. d/cmake: Update armv7 bootstrapping support for SA64 environment. Tue Jan 19 08:07:10 GMT 2021 * Merged all gcc-10 fixes in from Patrick & nobodino into ARM src tree. Perfect timing!! That saved me some work :-) * Launched SA64 stage 1 within Slackmaster ARM env. * Bootstrapping Stage 2 begins in earnest. +--------------------------+ Sun Jan 17 20:45:06 GMT 2021 * Updated slackpkg for AArch64 as it's in the queue for x86. https://git.rlworkman.net/slackpkg/commit/?id=89d4761f19fdef03ddecb122b5a1cfe90dd9417c Thanks to Robby Workman for committing those in. +--------------------------+ Sat Jan 16 21:12:06 GMT 2021 * Launched SA64 stage 1 platform build within Slackmaster env. +--------------------------+ Thu Jan 14 21:44:06 GMT 2021 https://forum.pine64.org/showthread.php?tid=11918 https://www.cnx-software.com/wp-content/uploads/2017/08/Rock64-Pi-2-Bus-Pinout.png Attached to U-Boot console on RockPro64. When connecting the USB serial adapter to my x86 laptop, there was mostly corruption but plugging the same adapter into the USB bus of an Orange Pi running Slackware ARM-current worked perfectly. [..] Trying to boot from BOOTROM Returning to boot ROM... SoC: Rockchip rk3399 Reset cause: POR Model: Pine64 RockPro64 v2.1 DRAM: 3.9 GiB PMIC: RK808 MMC: mmc@fe310000: 2, mmc@fe320000: 1, sdhci@fe330000: 0 [..] Fri Jan 8 08:08:08 GMT 2021 distroscripts/native.setup: Added post installation system integration tests. Added some A64 suppport but needs more. +--------------------------+ Sun Jan 3 23:36:11 GMT 2021 Created 'Slackware ARM' youtube channel to supplanting the 'SlackChat' podcast) where we'll document the progress of both 32-bit Slackware ARM and the new AArch64 port. https://www.youtube.com/channel/UCabC1NZDGA3FZXf2hQ-6uyA l/glibc: bootstrap notes Rebuilt on ARM - works with gcc-10 without patching. Pat says it also builds on x86_64 with --disable-werror which is why it already builds on ARM, as this was required in the early days. Probably no issue for A64. slackkit - PORTSRC for mostly unified (with exceptions) port. the host OS should be able to reference entirely the arm port's src tree and leave the distrotools to use the divergent slackwareaarch64-current/source to prepare the public tree's tags, signatures et al. Needs confirmation: CONFIRMED working. Platform bootstrap: * Reviewed my previous notes and scripts * Re-studied Eric Hameleers/alienBOB's Slackware platform bootstrap tools. * Began preparing the build environment for AArch64 within the Slackware lower build environments. +--------------------------+ Sat Jan 2 19:39:30 GMT 2021 l/glibc: bootstrap notes - note from SlackFromScratch thread on LQ. glibc won't build with gcc-10. Need to pick option on aarch64 depending on buildability, as it won't build on x86 without patching; however, the patch available breaks the build on ARM. Fix forward and upgrade where necessary (which works cause the entire distribution will be rebuilt 100s of times) or work-around. Pat says the glibc upgrade isn't on the list yet : Option to build glibc-2.32 with --enable-obsolete-nsl --enable-obsolete-rpc to re-enable macros that some of the existing packages require. Or it might just work. Which would be nice. +--------------------------+ Fri Jan 01 11:09:29 GMT 2021 * Announce on Slackware ARM web site. bhg: Fixed batch reporting status on failures. slackkit: Add -fPIC to default CFLAGS for aarch64. +--------------------------+ Tue Dec 29 19:28:52 GMT 2020 slackkit: Change aarch64 toolchain quadlet to "aarch64-slackware-linux-gnu" Sud,r2b: Support architecture independent build logs. Adjust arm/build scripts to prepend ${SLKPORTARCH}- to log file name. Build scripts will be updated as the ARM port progresses and aarch64 is built. r2b: Support masking of packages to prevent building on a specific arch. This allows masking out of thunderbird, seamonkey and possibly some ARM or aarch64-specific packages. dbuild: Support removal of old-style and new-style build log file names. Hack to bypass x-toolchain, exec arm/build directly. x/mesa Archived compiled src supports architecture independence. KDE and x11: add architecture to build log names and ensure they're handled by dbuild. Changed x11's arm/build to unpack the apropriate mesa compiled src. +--------------------------+ Mon Dec 28 10:48:12 GMT 2020 Welcome Slackware AArch64, the 4th official port of Slackware to the ARM architecture. A potted release history: 2004: 32bit armv3 'legacy' ABI 2009: 32bit armv5 soft float ABI 2016: 32bit armv7 hard float ABI 2020: 64bit armv8 AArch64 The initial targets are RockPro64 and Raspberry Pi (community support, but with more integrated support than the ARM port). Thanks to Pine64 for supplying the intial RockPro64 hardware! Note that presently there are no packages available. This initial push is to test part of the build system integration. Progress: ========= Updated OS distribution management suite. Set up directory structure for slackwareaarch64-current to contain the new OS. source/README.txt: Note that the source tree is unified with the master Slackware ARM tree, hence why the directory structure for AArch64 is mostly barebones, apart from a few support files (presently for the installer and the OS distribution management suite) where divergence between the two architectures is required. k/: Patch set prepared for Linux 5.10 and aarch64/arm. x/x11: Support separate arm and aarch64 builds. kde/: Support separate arm and aarch64 builds. Prepared bootstrap tool to supplement kde.SlackBuild. slackkit: Initial aarch64 support. Support skipping dependency checks to facilitate bootstrapping aarch64. r2b: Support skipping dependency checks to bootstrap aarch64. Most package build scripts should now be 64-bit ready, apart from any necessary compiler flag adjustments (-fPIC in particular).