Slackaware (-current) on H3: step by step

SCerovec · 01-25-2017, 01:10 AM

I have no doubt!

Ramifications:

kernels of the 3.x branch require the old u_boot (fex one)

This is a deal breaker for me: I like all supported boards to be bootable via the same u_boot?

further, how does the 3.4.x kernel (non dtb) fare with the Slackware system?

Any caveats there?

Hannes Worst · 01-25-2017, 02:36 PM

Most linux operatingsystems (debian, ubuntu, Arch) on H3-boards make use of script.bin that must be patched to adjust kernelsettings. Armbian developers made several scripts to achieve this, like h3disp: https://forum.armbian.com/index.php/...on-h3-devices/, to change resolution and fix-thermal.sh https://forum.armbian.com/index.php/...lity-problems/ to prevent overheating on some boards. Linux-sunxi developed some sunxi-tools like bin2fex and fex2bin to patch script.bin. I don know if it is usable within slackware though, I never tried it.

drmozes · 01-26-2017, 07:32 AM

Regarding using a vendor kernel in Slackware ARM: no.

Raspbian et al all exist in support *of* a particular device, where as Slackware ARM exists because I want it to- independently from any device. Slackware ARM has support *for* a piece of hardware if it makes it in to the upstream kernel (and mostly) X.org support (but I mainly care only about Kernel support), not "this product is brought to market with an OS we've hacked up just so people can switch it on and use it for <something>"

Using an old vendor kernel:
1. Security? where do the patches come from
2. Support for hardware: e.g. the current sun8i emac driver (network on H3 plus a couple others) is no longer developed. The support is being merged into the stmmac driver. I'm not going to invest my time in something that's already legacy, just to support a particular device. If the support is upstream in an main stream release candidate or "linux next", then that's progressive not regressive.
3. Supporting an older kernel causes problems for long term maintenance and even maintenance of "-current". it'd need special support just to avoid applying the handful of patches currently required for 4.x, for example.

Anyway, I already have 4.10rc5 out in -current now which supports H3. The only problem is that the sun8i emac driver crashes under load (e.g. when installing Slackware) - where as it did not with rc2; so I've contacted the developer of it who replied today with some help.
Once I have it working I'll make the notice in the change log.

SCerovec · 01-27-2017, 04:20 AM

So, there is no mainline kernel in the 3.4.x series?

And the various *bian-s are patchworks for particular devices (no same kernel across the various devices)?

Then it makes no sense whatsoever to go back

OTOH, our good host drmozes

already brew us an upcoming 4.x kernel supporting the H3.

Dear chef, when can we try the stew too

?
(I know,I know, but I had to ask ?)

Meanwhile the updated (yet to be tested) stript for U-boot (one script that does it all (hopefully)) with the ISC license ('this okay?)

file boot.cmd

Code:

###
#
#  v0.4-beta (C) ISC cest73@ya.ru 2016 and onwards for Slackware ARM and U-BOOT
#
#  filename: boot.cmd
#
#  Generic (hopefully) Uboot script with templates for many scenarios
#  typical on-disk layout:
#  /boot/          for kernel and initrd
#  /boot/dtb/      for device tree files
#  /boot.scr       configuration for u_boot
#                  the last one generated from 
#  /boot.cmd       by
#
#  /usr/sbin/bootedit
#
###

###
#
# declaring the system layout for boot...
#
###

# uncomment only one of the two
#setenv mode 'setup'
setenv mode 'regular'

# set the appropriate boot target(CASE sensitive!):
# 'tftp' for booting over LAN, please refer to HOWTOS on install media
# 'usb' for booting from a USB storage (stick or disk)
# 'sata' to harness the speedy SATA interface for boot
# 'fel' if You deliver this file and the boot items by means of an OTG micro USB cable
# 'mmc' for the most usual setup - the files residing on a SD or MMC card
setenv media 'mmc'

#'serial' for the UART0
#'hdmi' for the HDMI port
#TODO 'composite'
#TODO 'ssh'
setenv interface 'hdmi'

#'auto' dhcp
#'172.32.16.0' our local address, then also set host below
#'none' no net during boot
setenv net 'none'
#setenv net '192.168.168.128'
# the IP of the tftp serving host
#setenv host '192.168.168.102'

# One has to read and search for the correct value here
# look in /boot/dtb/ for Yours
# for Banana PI:sun7i-a20-bananapi.dtb
setenv dtbfile 'sun7i-a20-bananapi.dtb'

# the custom commandline parameters go here 
# (4 for X on boot, 3 for default, etc)
# plus board specific hacks and tweaks
setenv bootcmd_generic ' debug earlyprintk sunxi_g2d_mem_reserve=0 sunxi_ve_mem_reserve=0 TERM=screen-256color 3'


# below this line WHERE THERE BE DRAGONS! (dont go!)

echo '-->SlackwareARM U-boot helper script V0.4...'

###
#
# defining the host specific parameters
#
###

# One has to read and search for the correct value here
# for Banana PI:
setenv fdtfile "/boot/dtb/${dtbfile}"

# kernel is (mostly) always te same
setenv kernelfile '/boot/zImage-armv7'
if test $mode = 'setup'; then
   # for setup
   setenv setupfs '/boot/initrd-armv7.img'
else
   # for everyday
   setenv initrdfile '/boot/initrd-armv7'
fi

if test $media = 'tftp'; then
  # here again, read thorougly the correct DTB file for the
  # actual comupter booting:
  setenv tftpfdtfile "slackwarearm-current/dtb/${dtbfile}"

  setenv tftpkernelfile 'slackwarearm-current/zImage-armv7'

  if test $mode = 'setup'; then
     # for setup
     setenv tftpsetupfs 'slackwarearm-current/initrd-armv7.img'
  else
     # for everyday
     setenv tftpinitrdfile 'slackwarearm-current/initrd-armv7'
  fi
fi

###
#
# defining the load addresses
#
###

# we change only for fel, otherwise we falback to tftp address
if test $media = 'fel' ; then
   # derived from UBOOT-FEL load address
   setenv fdt_addr_r 0x43000000
   setenv kernel_addr_r 0x42000000
   setenv ramdisk_addr_r 0x43300000
else
   # use this for tftfp setup
   setenv fdt_addr_r 0x43000000
   setenv kernel_addr_r 0x46000000
   setenv ramdisk_addr_r 0x47000000
fi

###
#
# crafting the file source commands
#
###

if test $media = 'tftp'; then
   echo "-->TFTP init:"
   # by tftpboot ..........refer how to setup in the install on Banana PI HOWTO
   # adjust to own TFTP server/host
   if test $net != 'auto'; then
      setenv serverip ${host}
      setenv ipaddr ${net}
   else
      # this is rather an parachute option ;)
      dhcpcd
   fi
   echo "-->Loading FDT"
   tftp ${fdt_addr} ${tftpfdtfile}
   echo "-->Loading kernel"
   tftp ${kernel_addr_r} $tftpkernelfile
   if test $mode = 'setup'; then
      echo "-->Loading setup ramdisk"
      # for setup
      tftp ${ramdisk_addr_r} $tftpsetupfs
   else
      echo "-->Loading initial ramdisk"
      # for everyday
      tftp ${ramdisk_addr_r} $tftpinitrdfile
   fi
else
   if test $media = 'fel'; then
      #for FEL we load via the cable O.o
      echo "-->FEL initiating"
   else
      if test $media = 'sata'; then
         echo "-->SATA/SCSI initiating"
         scsi reset
         scsi scan
      elif test $media = 'usb'; then
         echo "-->USB initiating"
         usb reset
         usb scan
      fi
      # except for fel, we load for mmc, usb and scsi/sata
      echo "-->Loading files from ${media} 0:1"
      load ${media} 0:1 ${fdt_addr_r} ${fdtfile}
      load ${media} 0:1 ${kernel_addr_r} ${kernelfile}
      if test $mode = 'setup'; then
         echo "-->Loading setup ramdisk"
         # for setup
         load ${media} 0:1 ${ramdisk_addr_r} ${setupfs}
      else
         echo "-->Loading initial ramdisk"
         # for every day
         load ${media} 0:1 ${ramdisk_addr_r} ${initrdfile}
      fi
   fi
   fdt addr ${fdt_addr_r} 0x40000
fi
###
#
# crafting the boot arguments
#
###

### initial output for OS

if test $interface = 'serial'; then
   # for serial console
   setenv slkconsole ' console=ttyS0,115200'
else
   # we asumeotherwise always or for HDMI
   setenv slkconsole ' console=tty1 disp.screen0_output_mode=EDID:1680x105060 hdmi.audio=EDID:0'
fi

### OS related parameters

if test $mode = 'setup'; then
   if test $net = 'auto'; then
      # setup with automatic network parameters
      setenv osargs " nic=auto:eth0:dhcp root=/dev/ram rw"
   else
      # setup with manual or special network setup
      setenv osargs " nodhcp root=/dev/ram rw"
   fi
else
   if test $media = 'mmc' ; then
      # everyday parameters for MMC/SD card
      setenv osargs " resumedev=/dev/mmcblk0p2 root=/dev/mmcblk0p1 rootfstype=ext4 ro"
   else
      if test $media = 'scsi' ; then 
        # everyday parameters for SCSI with the 2 second delay
        setenv osargs " resumedev=/dev/sda2 root=/dev/sda1 waitforroot=2 rootfstype=ext4 ro"
      else
        # everyday parameters for USB
        setenv osargs " resumedev=/dev/sda2 root=/dev/sda1 rootfstype=ext4 ro"
      fi
   fi
fi

### finally, gluing it all together

# kernel command line
echo "--> kernel commandline:"
echo "--> ${slkconsole} ${bootcmd_generic} ${osargs} ${usrargs} <--"
setenv bootargs ${slkconsole} ${bootcmd_generic} ${osargs}

# passing control to kernel
echo "--> Passing controll to kernel:"
bootz ${kernel_addr_r} ${ramdisk_addr_r}:${filesize} ${fdt_addr_r}

# here from You should be with Slackware setup or system

and the a bit more current & updated
bootedit:

Code:

#!/bin/sh

#wrapper for editing /boot.src
# ISC apply - support on Linuxquestions.org for Slackware ARM
# author: cest73@ya.ru
# version V1.1
# file /usr/sbin/bootedit
#

Editor='/usr/bin/mcedit'
Converter='/usr/bin/mkimage'
pars='-C none -A arm -T script'
tgt='/boot.scr'
src='/boot.cmd'


if [[ -x ${Editor} ]] ; then
if [[ -x ${Converter} ]] ; then
$Editor ${src} && $Converter ${pars} -d ${src} ${tgt}
else
echo "converter [${Converter}] not found! aborting."
exit 2
fi
else
echo "editor [${Editor}] not found! aborting."
exit 2
fi
echo "done."

drmozes · 01-27-2017, 05:39 AM

Quote:

Originally Posted by SCerovec

So, there is no mainline kernel in the 3.4.x series?

That's not how it works. The vendor kernels are usually a fork of a particular mainline version with tonnes of patches against it.
You take the entire kernel, not a small patch set. You could probably extricate the patches and apply them against a similar major version number, but it's not something I'd ever consider.
This sort of thing is something an individual would do, not something you'd include in the forward looking OS.

Quote:

And the various *bian-s are patchworks for particular devices (no same kernel across the various devices)?

Yep. Everyone's got their own fork on git hub and eventually they might get their changes mainlined.

SCerovec · 02-11-2017, 09:00 AM

Last time on H3 install series (short recap):
1. we primed the MMC/TF/SD card with SPL (i used a Class10 8GB) and a single partition
2. we prepared the USB volume (flash, thumb, 2.5" vith USB converter...) with Slackware-arm install media
3. we connected via the UART to the OPi-PC
4. plugged the MMC
5. Plugged the USB
6. Powered on and got to boot right into the Slackware setup - the same one used on x86.

7. I selected all but KDE/KDEi and after it begun i left for an hour (or so...)

TODO:
HDMI
quirks

P.S.
feedback: The ETH0 seems to register fine with OPi_PC v1.3 here

SCerovec · 02-11-2017, 10:49 AM

The actual tested file that worked the boot for me:

file:/boot/boot.cmd

Code:

###
#
#  v0.5-beta (C) ISC cest73@ya.ru 2016 and onwards for Slackware ARM and U-BOOT
#
#  filename: boot.cmd
#
#  Generic (hopefully) Uboot script with templates for many scenarios
#  typical on-disk layout:
#  /boot/          for kernel and initrd
#  /boot/dtb/      for device tree files
#  /boot.scr       configuration for u_boot
#                  the last one generated from 
#  /boot.cmd       by
#
#  /usr/sbin/bootedit
#
###

echo '-->SlackwareARM U-boot helper script V0.5...'

###
#
# declaring the system layout for boot...
#
###

# uncomment only one of the two
#setenv mode 'setup'
setenv mode 'regular'

# enter for media :
# 'tftp'
# 'usb'
# 'sata'
# 'fel'
# 'mmc'
setenv media 'mmc'

#'serial' for the UART0
#'hdmi' for the HDMI port
#TODO 'composite'
#TODO 'ssh'
setenv interface 'serial'

#'auto' dhcp
#'172.32.16.0' our local address, then also set host below
#'none' no net during boot
setenv net 'none'
#setenv net '192.168.168.128'
# the IP of the tftp serving host
#setenv host '192.168.168.102'

# look in /boot/dtb/ for Yours
# for Banana PI:sun7i-a20-bananapi.dtb
# for Orange PI:sun8i-h3-orangepi-pc.dtb
setenv dtbfile 'sun8i-h3-orangepi-pc.dtb'

# for Banana PI add "sunxi_g2d_mem_reserve=0 sunxi_ve_mem_reserve=0"
setenv bootcmd_generic ' debug earlyprintk TERM=screen-256color 3'

# below this line WHERE THERE BE DRAGONS! (dont go!)

###
#
# defining the host specific parameters
#
###

setenv fdtfile "/boot/dtb/${dtbfile}"

# kernel is (mostly) always te same
setenv kernelfile '/boot/zImage-armv7'
if test $mode = 'setup'; then
   # for setup
   setenv setupfs '/boot/initrd-armv7.img'
else
   # for everyday
   setenv initrdfile '/boot/initrd-armv7'
fi

if test $media = 'tftp'; then
  setenv tftpfdtfile "slackwarearm-current/dtb/${dtbfile}"

  setenv tftpkernelfile 'slackwarearm-current/zImage-armv7'

  if test $mode = 'setup'; then
     # for setup
     setenv tftpsetupfs 'slackwarearm-current/initrd-armv7.img'
  else
     # for everyday
     setenv tftpinitrdfile 'slackwarearm-current/initrd-armv7'
  fi
fi

###
#
# defining the load addresses
#
###

# we change only for fel, otherwise we falback to tftp address
if test $media = 'fel' ; then
   # derived from UBOOT-FEL load address
   setenv fdt_addr_r 0x43000000
   setenv kernel_addr_r 0x42000000
   setenv ramdisk_addr_r 0x43300000
else
   # use this for tftfp setup
   setenv fdt_addr_r 0x43000000
   setenv kernel_addr_r 0x46000000
   setenv ramdisk_addr_r 0x47000000
fi

###
#
# crafting the file source commands
#
###

if test $media = 'tftp'; then
   echo "-->TFTP init:"
   # by tftpboot ..........refer how to setup in the install on Banana PI HOWTO
   # adjust to own TFTP server/host
   if test $net != 'auto'; then
      setenv serverip ${host}
      setenv ipaddr ${net}
   else
      # this is rather an parachute option ;)
      dhcpcd
   fi
   echo "-->Loading FDT"
   tftp ${fdt_addr} ${tftpfdtfile}
   echo "-->Loading kernel"
   tftp ${kernel_addr_r} $tftpkernelfile
   if test $mode = 'setup'; then
      echo "-->Loading setup ramdisk"
      # for setup
      tftp ${ramdisk_addr_r} $tftpsetupfs
   else
      echo "-->Loading initial ramdisk"
      # for everyday
      tftp ${ramdisk_addr_r} $tftpinitrdfile
   fi
else
   if test $media = 'fel'; then
      #for FEL we load via the cable O.o
      echo "-->FEL initiating"
   else
      if test $media = 'sata'; then
         echo "-->SATA/SCSI initiating"
         scsi reset
         scsi scan
      elif test $media = 'usb'; then
         echo "-->USB initiating"
         usb reset
         usb scan
      fi
      # except for fel, we load for mmc, usb and scsi/sata
      echo "-->Loading files from ${media} 0:1"
      load ${media} 0:1 ${fdt_addr_r} ${fdtfile}
      load ${media} 0:1 ${kernel_addr_r} ${kernelfile}
      if test $mode = 'setup'; then
         echo "-->Loading setup ramdisk"
         # for setup
         load ${media} 0:1 ${ramdisk_addr_r} ${setupfs}
      else
         echo "-->Loading initial ramdisk"
         # for every day
         load ${media} 0:1 ${ramdisk_addr_r} ${initrdfile}
      fi
   fi
   fdt addr ${fdt_addr_r} 0x40000
fi
###
#
# crafting the boot arguments
#
###

### initial output for OS

if test $interface = 'serial'; then
   # for serial console
   setenv slkconsole ' console=ttyS0,115200'
else
   # we asumeotherwise always or for HDMI
   setenv slkconsole ' console=tty1 disp.screen0_output_mode=EDID:1680x105060 hdmi.audio=EDID:0'
fi

### OS related parameters

if test $mode = 'setup'; then
   if test $net = 'auto'; then
      # setup with automatic network parameters
      setenv osargs " nic=auto:eth0:dhcp root=/dev/ram rw"
   else
      # setup with manual or special network setup
      setenv osargs " nodhcp root=/dev/ram rw"
   fi
else
   if test $media = 'mmc' ; then
      # everyday parameters for MMC/SD card
      setenv osargs " resumedev=/dev/mmcblk0p2 root=/dev/mmcblk0p1 rootfstype=ext4 ro"
   else
      if test $media = 'scsi' ; then 
        # everyday parameters for SCSI with the 2 second delay
        setenv osargs " resumedev=/dev/sda2 root=/dev/sda1 waitforroot=2 rootfstype=ext4 ro"
      else
        # everyday parameters for USB
        setenv osargs " resumedev=/dev/sda2 root=/dev/sda1 rootfstype=ext4 ro"
      fi
   fi
fi

### finally, gluing it all together

# kernel command line
echo "--> kernel commandline:"
echo "-->${slkconsole} ${bootcmd_generic} ${osargs} ${usrargs}<--"
setenv bootargs "${slkconsole} ${bootcmd_generic} ${osargs}"

# passing control to kernel
echo "--> Passing controll to kernel:"
bootz ${kernel_addr_r} ${ramdisk_addr_r}:${filesize} ${fdt_addr_r}

# here from You should be with Slackware setup or system

I can try it with OPi_PC and Bpi (as i did).

@drmozes:
could we craft one general SPL+u_boot for all (or at least many) SBC to boot?

SCerovec · 02-11-2017, 04:03 PM

Heads-up:
I'm testing a boot-install script this weekend, will report back after few more tries.

SCerovec · 02-12-2017, 04:30 AM

I know the initrd is "bloaty" at ~45MB already, but couldn't we squeeze screen or tmux too?

Last evening i had installed the system (nth time in a row) and I really wanted to be able to "zap" back and forth, but being connected over an UART, i was not able to.

But had the installer's initrd included the screen/tmux

...

no?

drmozes · 02-12-2017, 11:27 AM

Quote:

Originally Posted by SCerovec

I know the initrd is "bloaty" at ~45MB already, but couldn't we squeeze screen or tmux too?

Last evening i had installed the system (nth time in a row) and I really wanted to be able to "zap" back and forth, but being connected over an UART, i was not able to.

But had the installer's initrd included the screen/tmux

...

no?

I don't see the point. If you follow the documents I have written, you'll see that you use screen on the x86 connecting to the UART which is presented via a USB adapter: so you run screen on there instead.

ftp://ftp.arm.slackware.com/slackwar...L_ORANGEPI.TXT is mostly complete - I just want to make a USB version of the installer for all armv7 devices, rather than have to set up an environment with a tftp server.
The only problems are that the sun8i emac (NIC) driver is unstable and causes kernel panics under load. I've contacted the developer of the driver though.

SCerovec · 02-13-2017, 09:30 AM

I'm glad there will be an unified USB way

, could I help anyhow?

The point of having screen/tmux on board the install:

while letting install chew away it's ~5-6GB of /, one could fire up a new session and let top run for performance feedback?
Or, in case of network based install media, let netwatch if iftop track performance?

But since we running through the UART, the only way to "zap" terminals back and forth, is to have screen or tmux on the installer.

No matter what I have on the x86 (or whatever) the only way to have more than a single session on the installing machine, if using the UART method, is a multiplexer, screen being the older and better known, tmux being the newer, looking forward one?

Just a matter of performance tracking, I happen to miss?

On regular desktop ("KVM" type) installs I "zap" quite often and track performance or check logs etc...

SCerovec · 02-16-2017, 10:01 AM

regarding the HDMI frame-buffer, /dev/fb0 and the desktop role of out H3 devices:
mailinglists

anyone familiar how to get that patch?
EDIT: got it! Now to test it...
see the 23k FAUX LOG

attachment.

download, prune the .log and untar it for testing.

Warning: keep backups!

SCerovec · 06-27-2017, 07:12 AM

First: don't hold Your breath:
We aren't there yet

but here a short "TL;DR" for the impatient

current kernel 4.11.7

not a sing of /dev/fb, no TV out, no HDMI

so i peeked the mailing lists:
- it seems that the DE2 (display engine 2.0) driver is about to be tested (~alpha phase Jernej Skrabec (jernejsk))
- other than that, there seems to be options in the registers of our SoC that has stalled the process a bit
- all other infrastructure seems to be in place already one way or the other...

So it is about time the patch hits mainline any time soon (keep Your eyes peeled

for the changelogs !)

we are getting there (like in weeks, not in months IMHO)