Slackaware (-current) on H3: step by step

drmozes · 01-13-2017, 06:43 AM

So looking at your photos, you also have an Orange Pi PC v1.3 - mine's v1.2 and has no SATA.

My goodness, this is ridiculous. I might put version numbers back into the documentation.
I'm not entirely sure which DTB files go with which device now..

My Orange Pi PC has no SATA so I've written about how to install on to a USB drive.

I foresee some number of revisions to the new INSTALL_ORANGEPI.TXT file in the upcoming weeks ;-)

SCerovec · 01-13-2017, 06:36 PM

@Penthux
I sure look forward to be of any help, thanks for the heads-up

.
@drmozes,
I see no better way than publishing photos of the devices?

The key point of picking OPI-PC is price in the first line.

for raw SATA throughput the BPI seems to be "it" with it's GLan IMO.

for both SATA and CPU, I'm not sure, would have to check?

re:install
I have to check yet if we can craft an alone booting USB (SPL-->USB). That way we could make "clean install" images?
If not, we still could clean install but have to "prime" the MMC first to boot the setup off any install media:
-lan
-USB
-MMC

off(?) topic:
how about making an Slackware live port?

drmozes · 01-14-2017, 05:40 AM

Quote:

Originally Posted by SCerovec

@drmozes,
I see no better way than publishing photos of the devices?

The version numbers are printed on the board below the GPIO pins, so my documentation refers to those
http://armed.slackware.com/tmp/INSTALL_ORANGEPI.TXT is the mostly finished work in progress.
The URLs for the U-Boot SD card images aren't yet up to date.

Quote:

Originally Posted by SCerovec

for raw SATA throughput the BPI seems to be "it" with it's GLan IMO.

for both SATA and CPU, I'm not sure, would have to check?

I don't know. I didn't time it properly yet but it seemed like the Orange Pi H3 Plus v1.1 with eSATA (over the USB bridge) compiled the Kernel significantly faster than the Banana Pi with eSATA.

Quote:

Originally Posted by SCerovec

re:install
I have to check yet if we can craft an alone booting USB (SPL-->USB). That way we could make "clean install" images?
If not, we still could clean install but have to "prime" the MMC first to boot the setup off any install media:
-lan
-USB
-MMC

Do you mean a 'live/installed' USB image that you can dd to a USB stick and boot from?
I don't know if the Orange Pi supports booting U-Boot from USB - normally they support booting U-Boot from the SD card, followed by the internal MMC. You could put U-Boot on the SD card (as I do) then boot from a USB stick -- my instructions for the Orange Pi PC have the OS installed to a USB hard drive, which equally could be a USB stick.

Quote:

Originally Posted by SCerovec

off(?) topic:
how about making an Slackware live port?

I love off topic :-)

I don't do pre-installed images of any kind as I don't think that's really the "Slackware way" (and they're effort to maintain and test - particularly when people hack them up and then email me about problems that I didn't create, taking time away from the core OS development and maintenance!), but you can do it as a community project for example, and I think it'd be a great idea.

My main concern with such things (for all reading who have and would like to contribute in any way) is that such projects are correctly perceived by the audience/fan base as being associated with, but not created by the Slackware developers.
The work I do under the banner of Slackware came from years of contribution and having created 'ARMedslack'. Presumably Pat was comfortable that my approaches and the quality of my work (under what was 'ARMedslack') more or less aligned with his own, so that 'ARMedslack' could be an official port of 'Slackware' x86 going forwards.

That doesn't mean that nobody else can produce work that's to the same standards, but it does mean that whatever _I_ put out needs to be respectful of Pat's "Slackware" brand. In turn, this means that people producing their own work that's linked to mine in some way must clearly state that it's theirs, since I am never going to have time to respectfully and carefully consider, examine and provide feedback about people's personal interest projects (I'm not talking of patches here and there, I am talking about entirely separate projects such as the RPi stuff) to make sure that I think they meet the standards.

This attitude/approach might be taken as being dictatorial but the issue is that people generally don't spend time to examine and read anything properly, so they take things at face value. If someone puts out an image of "Slackware ARM for the XYZ" (as has happened), yet it's a highly personalised OS install with packages that aren't even in Slackware ARM, let alone x86, and that work is buggy then it reflects badly on the origin project.

Slackware isn't set up to accommodate group development where individuals can submit changes and manage packages (such as Debian is) and Slackware ARM is no exception. I think that the "Slackware ARM Community" is probably the best way to accomplish and link personal interest projects with the core project.

Anyway, I say that because whilst I am not a pre-installed images guy, the idea to bring more people to use Slackware on these devices is great and if it's documented properly (including how to update the OS install) then it's an asset to the project.

SCerovec · 01-16-2017, 07:36 AM

re:install
I mean having an USB stick, eventually, able to perform an clean install, like nowadays the x86 Slackware has?

The step from enthusiasts install (connecting UART, RTFMing, troubleshooting steps ...)

to

"power user" install (make it have SPI; poke the USB in and make it installed in the first attempt (hopefully?))

Where I understand the step from "power user" to enthusiasts is -when one takes not only the screwdriver but an welding iron and a file to it's computer shop?

a HOWTOLESS install, so to say?

drmozes · 01-16-2017, 09:06 AM

Quote:

Originally Posted by SCerovec

re:install
I mean having an USB stick, eventually, able to perform an clean install, like nowadays the x86 Slackware has?

This should be easy to achieve: Just make an installer image (with a single partition with the kernel and installer image) that can be dd'd to a USB stick, and make u-boot boot from USB.

I might have a look at providing that method of installation actually, since it'd cut down having to set up a tftp server and stuff like that; and all of the ARM devices I've come across recently have USB ports.

SCerovec · 01-17-2017, 09:08 AM

Found so far:
1. USB cant provide SPL to H3
2. TF card is providing SPL no problem
3. If no TF card and/or no MMC device detected, the H# goes into FEL mode

in FEL mode the OPi-PC accepts an fel-uploader provided firmware

It uploads no problem.

Stuck at:
the instant I put the control to the setup image it fails with syntax error?

Code:

-->done USB reset, loading FDT
11357 bytes read in 2663 ms (3.9 KiB/s)
-->loading kernel
4212880 bytes read in 374 ms (10.7 MiB/s)
-->loading ramdisk
45967289 bytes read in 60214 ms (745.1 KiB/s)
-->loaded setup image
syntax error
Unknown command '�' - try 'help'
SCRIPT FAILED: continuing...

so I'm on to happy hacking

SCerovec · 01-17-2017, 09:40 AM

Got it!
file: boot.cmd (version for serial UART output)

Code:

echo 'for SlackwareARM FEL boot v0.2...'
setenv fdtfile '/boot/dtb/sun8i-h3-orangepi-pc.dtb'
setenv kernelfile '/boot/zImage-armv7'
setenv setupfs '/boot/initrd-armv7.img'
setenv fdt_addr_r 0x43000000
setenv kernel_addr_r 0x46000000
setenv ramdisk_addr_r 0x47000000
usb reset; usb scan
echo "-->done USB reset, loading FDT"
load usb 0:1 ${fdt_addr_r} ${fdtfile}
echo "-->loading kernel"
load usb 0:1 ${kernel_addr_r} ${kernelfile}
echo "-->loading ramdisk"
load usb 0:1 ${ramdisk_addr_r} ${setupfs}
echo "-->loaded setup image"
fdt addr ${fdt_addr_r} 0x40000
setenv bootcmd_generic ' debug earlyprintk sunxi_g2d_mem_reserve=0 sunxi_ve_mem_reserve=0'
setenv slkconsole ' console=ttyS0,115200'
setenv osargs " TERM=screen-256color nodhcp root=/dev/ram rw"
setenv bootargs ${slkconsole} ${bootcmd_generic} ${osargs}
echo "-->passing control to kernel now:"
bootz ${kernel_addr_r} ${ramdisk_addr_r}:${filesize} ${fdt_addr_r}

converted by:

Code:

mkimage -C none -A arm -T script -d boot.cmd boot.scr

the mkimage is found in tools/ directory of the u-boot build (and copied somewhere into $PATH)

the procedure (currently):
1. build the u-boot (spl image)
2. dd zeros to first few MB of the media (just in case)
3. in fdsik (or whatever) make a fresh empty "DOS" label
4. dd the image to 8k (8x1024 bytes) behind of the TF card volume begin

Code:

---+------------------------------------+--------------------------->lots of blocks there
   |  SPL U-boot and config             | rest of the volume
---+------------------------------------+--------------------------->lots of blocks there
   | non partition space                | 1st partition to be (/dev/mmcblk0p1)
   ^ 8k mark (block #16 of 512 byte blocks)
                                        ^ 1024k mark (block 2048 of 512 byte blocks)
^ partition table (#0 block)

so after dd-ing the SPL image one can proceed to partition the media in any preferred partition editor.
5. I recommend making an single ext4 partition for the rest of the volume for least kernel overhead?

6. populate the USB installer volume:

Code:

├── boot/
│   ├── boot.cmd
│   ├── boot.scr
│   ├── dtb/
│   ├── initrd-armv7.img
│   ├── u-boot-sunxi-with-spl.bin
│   ├── uImage-armv7
│   ├── uinitrd-armv7.img
│   └── zImage-armv7
├── lost+found/
└── slackwarearm-current/
    ├── CHECKSUMS.md5
    ├── CHECKSUMS.md5.asc
    ├── COPYING
    ├── COPYING3
    ├── COPYRIGHT.TXT
    ├── CRYPTO_NOTICE.TXT
    ├── CURRENT.WARNING
    ├── ChangeLog.txt
    ├── Changes_todo.txt
    ├── FILELIST.TXT
    ├── GPG-KEY
    ├── INSTALL_BANANAPI.TXT
    ├── INSTALL_QEMU.TXT
    ├── INSTALL_RASPBERRYPI.TXT
    ├── INSTALL_TRIMSLICE.TXT
    ├── PACKAGES.TXT
    ├── README_REMOVED_PACKAGES.TXT
    ├── UPGRADE.TXT
    ├── extra/
    ├── isolinux/
    ├── kernels/
    ├── pasture/
    ├── patches/
    ├── slackware/
    ├── source/
    └── testing/

I wanted to have the u-boot-sunxi-with-spl.bin just in case in the boot (not needed), maybe i should have the mkimage too?

file: boot.cmd (alternate version for HDMI output)

Quote:

echo 'for SlackwareARM FEL boot v0.2...'
setenv fdtfile '/boot/dtb/sun8i-h3-orangepi-pc.dtb'
setenv kernelfile '/boot/zImage-armv7'
setenv setupfs '/boot/initrd-armv7.img'
setenv fdt_addr_r 0x43000000
setenv kernel_addr_r 0x46000000
setenv ramdisk_addr_r 0x47000000
usb reset; usb scan
echo "-->done USB reset, loading FDT"
load usb 0:1 ${fdt_addr_r} ${fdtfile}
echo "-->loading kernel"
load usb 0:1 ${kernel_addr_r} ${kernelfile}
echo "-->loading ramdisk"
load usb 0:1 ${ramdisk_addr_r} ${setupfs}
echo "-->loaded setup image"
fdt addr ${fdt_addr_r} 0x40000
setenv bootcmd_generic ' debug earlyprintk sunxi_g2d_mem_reserve=0 sunxi_ve_mem_reserve=0 disp.screen0_output_mode=EDID:1280x720p50 hdmi.audio=EDID:0'
setenv slkconsole ' console=tty1'
setenv osargs " TERM=screen-256color nodhcp root=/dev/ram rw"
setenv bootargs ${slkconsole} ${bootcmd_generic} ${osargs}
echo "-->passing controll to kernel now:"
bootz ${kernel_addr_r} ${ramdisk_addr_r}:${filesize} ${fdt_addr_r}

plug all in and be ready for setup

to be continued ...

SCerovec · 01-17-2017, 01:15 PM

Setup fails silently?
then when i type:

Code:

# dialog
dialog: error while loading shared libraries: libncursesw.so.5: cannot open shared object file: No such file or directory

i get this error?

the present libncursesw.so is libncursesw.so.6.

so i guess dialog didn't know

?
the setup image needs updating... (I'll wait for it)
FWIW cfdisk also won't work (depends on ncurses too)

Penthux · 01-18-2017, 01:33 AM

Quote:

Originally Posted by SCerovec

Setup fails silently?
then when i type:

Code:

# dialog
dialog: error while loading shared libraries: libncursesw.so.5: cannot open shared object file: No such file or directory

i get this error?

the present libncursesw.so is libncursesw.so.6.

so i guess dialog didn't know

?
the setup image needs updating... (I'll wait for it)
FWIW cfdisk also won't work (depends on ncurses too)

Try this...

Code:

ln -s libncurses.so.6.0 libncurses.so.5
ln -s libncursesw.so.6.0 libncursesw.so.5

SCerovec · 01-18-2017, 04:47 AM

Code:

root@slackware:/# ln -vs /lib/libncurses.so.6.0 /lib/libncurses.so.5
'/lib/libncurses.so.5' -> '/lib/libncurses.so.6.0'
root@slackware:/# ln -vs /lib/libncursesw.so.6.0 /lib/libncursesw.so.5
'/lib/libncursesw.so.5' -> '/lib/libncursesw.so.6.0'

check:

Code:

root@slackware:/# ls -lah /lib/libncurses*.so*
lrwxrwxrwx 1 root root   22 Jan  1 00:05 /lib/libncurses.so.5 -> /lib/libncurses.so.6.0*
lrwxrwxrwx 1 root root   17 Dec 29  2016 /lib/libncurses.so.6 -> libncurses.so.6.0*
-rwxr-xr-x 1 root root 123K Dec 29  2016 /lib/libncurses.so.6.0*
lrwxrwxrwx 1 root root   23 Jan  1 00:05 /lib/libncursesw.so.5 -> /lib/libncursesw.so.6.0*
lrwxrwxrwx 1 root root   18 Dec 29  2016 /lib/libncursesw.so.6 -> libncursesw.so.6.0*
-rwxr-xr-x 1 root root 177K Dec 29  2016 /lib/libncursesw.so.6.0*

works!

SCerovec · 01-18-2017, 05:53 AM

the file needed to boot from MMC:
file:boot.cmd

Code:

echo 'for SlackwareARM FEL boot v0.2...'
setenv fdtfile '/boot/dtb/sun8i-h3-orangepi-pc.dtb'
setenv kernelfile '/boot/zImage-armv7'
setenv initrdfile '/boot/initrd-armv7'
setenv fdt_addr_r 0x43000000
setenv kernel_addr_r 0x46000000
setenv ramdisk_addr_r 0x47000000
echo "-->loading FDT:"
ext4load mmc 0:1 ${fdt_addr_r} ${fdtfile}
echo "-->loading kernel:"
ext4load mmc 0:1 ${kernel_addr_r} ${kernelfile}
echo "-->loading initial ramdisk:"
ext4load mmc 0:1 ${ramdisk_addr_r} ${initrdfile}
fdt addr ${fdt_addr_r} 0x40000
setenv bootcmd_generic ' debug earlyprintk sunxi_g2d_mem_reserve=0 sunxi_ve_mem_reserve=0'
setenv slkconsole ' console=ttyS0,115200'
setenv osargs " resumedev=/dev/mmcblk0p2 root=/dev/mmcblk0p1 rootfstype=ext4 ro"
setenv bootargs ${slkconsole} ${bootcmd_generic} ${osargs}
echo "-->passing controll to kernel now:"
bootz ${kernel_addr_r} ${ramdisk_addr_r}:${filesize} ${fdt_addr_r}

converted with:

Code:

mkimage -C none -A arm -T script -d boot.cmd boot.scr

SCerovec · 01-18-2017, 06:02 AM

there apparently is no need to alter the default u_boot environment.

So far I've been able to pull an successful install on both Banana and Orange -PI SBC without ever touching the u-boot environment.

It sees a "BAD" crc and loads its default which works in an apparently preferable order of boot:

MMC
USB
LAN

I have yet to check where the SATA/eSATA goes in that order?

Setup left me "stranded" on reboot and i landed right back into it.
I mounted the USB and the MMC somewhere

...
I cp-ed the boot.scr from the USB's /boot to MMC's /boot and made it look like the above posted one.
after converting it to boot.scr on the MMC's, the Opi-PC booted happily away!

the setup was without E,X,XAP.XFCE,KDE and KDEi
and it took 4.8G of the 8GB MMC

to be continued...

SCerovec · 01-18-2017, 06:48 AM

can't get the HDMI port to throw an picture?

What's the current status of the H3's mali GPU in the kernel?

could there be a tweak to cheat it to work?

SCerovec · 01-24-2017, 12:23 PM

I took a look at the Raspbian OPi image:
kernel 3.4.34

So i wonder:
How wise would it be to run two kernels for our ARM port:
1. This no doubt would add certain overhead to the maintainer, hands down.
2. There where historical moments when Slackware did so for x86 architecture
3. All the bells and whistles on ARM seem to come to 3.x branches first?

Then again, if any, which ("old") kernel is best to be shipped?

Hannes Worst · 01-25-2017, 12:39 AM

Did you have a look at the Armbian kernel? They are at 3.4.112 for h3 with a lot more features I believe.