LinuxQuestions.org - Slackaware (-current) on H3: step by step

- Slackware - ARM (https://www.linuxquestions.org/questions/slackware-arm-108/)

- - Slackaware (-current) on H3: step by step (https://www.linuxquestions.org/questions/slackware-arm-108/slackaware-current-on-h3-step-by-step-4175597078/)

Slackaware (-current) on H3: step by step

1. I use an Orange Pi PC for my H3 host (@$16 hardly any beats it's bang for buck)
2. H3 is Allwinner so any inquiry begins here at sunxsi (kudos to sunxi).

it seem it's supported by mainline uboot (excellent) and apparently mainline kernel supports booting it since 4.9

Why Orange PI PC?:
1. it's "en par" with R-Pi3 raw performance
2. Bang for buck - it's second to none
3. It's "old enough" for mainline

my goals:
-document all needed to make it 7/24 station for server or PC.

Further info as I progress.

Quote:

Originally Posted by SCerovec (Post 5652341)

I've got the Orange Pi H3 Plus v1.1 working but unfortunately I haven't been able to get the Ethernet working (I took the sun8i emac patch from Fedora's Kernel SRPM -- you can pull the patch from the Kernel repo but it's easier to pull it from Fedora, and I'm assuming someone using Fedora on an OPi might have tested it) - the NIC is found but it never gets a link/carrier; yet it works fine in U-Boot.

Code:

root@melonia:~# uname -a

Linux melonia 4.9.1-armv7 #2 SMP Sat Jan 7 14:20:52 GMT 2017 armv7l Allwinner sun8i Family GNU/Linux

root@melonia:~# cat /proc/device-tree/model

Xunlong Orange Pi Plus / Plus 2

I've written the installation documents for it and it'll be uploaded when the next batch of packages goes out.

If you get your eth0 working I'd like to know, although you've got a different model to me.

Also does the Orange Pi PC have mmc? My install docs assume eSATA but I will expand it to MMC since the Orange Pi Plus has it.
Working out which Orange Pi you have is quite difficult -I had to look at the wording next to the GPIO pins -- the web site does not help much particularly since there are multiple models under the same name!

Hey drmozes, kudos for the valuable work there :D!

I got my an O-PI_PC it seems to be v1.3?

I will, of course, spam few photos in the process? ;)

Maybe some code too?

Quote:

Originally Posted by drmozes (Post 5652355)

The Orange Pi Plus has 8GB eMMC and the Orange Pi Plus 2 has 16GB eMMC... *reportedly*. As you know the official Orange Pi website makes a dogs dinner out of listing the spec's of each board model/version and revisions, plus that entire website confuses the hell out of me!

You can install an OS on the eMMC and the Orange Pi will boot with it if there's no microSD card detected at boot. The microSD is the primary boot device so it will always try to boot from that first. Not sure what will happen if the microSD card has no bootable partition or boot files on it but the eMMC does. I think you can also configure the Orange Pi to boot from eSATA but don't quote me on that. I've yet to put mine through the rigours of testing.

might I chime in?

The "bare metal" really seeks for the uboot or a like initial loader, rather than an actual OS.

It does, however, make sense to use an present eMMC of 8GB for something more than mere "BIOS" (in x86 lingo).

Yes, all non Raspberry companies reflect a culture of inflated enthusiasm (Asia(TM)?)

The OPI-PC has an MMC slot (TF size) and apparently no "flash chips" (eMMC) elsewhere. Photos still due. (my (lame) Excuse: -15 C on day time and the shop (=shed) is outside of the house:rolleyes:)

As it turns out, I was sent an Orange Pi Plus *and* an Orange Pi PC, so once I'm done with some other stuff I'll add documentation support for the Orange Pi PC as well.

Please lookup the attached pictures:
Yes the price was such :rolleyes: I couldn't resist to get an non DIY-ed case and the USB power cord.

The PSU is an all powerful twin 2.4A 5.1V monster from e-bay :eek:

more images below...

I mainly pick to post what I would like to lookup on any device.

That's why the abundance of views :hattip:

next we prepare the TF-card for a boot, and connect the UART and power to the SBC (stay tuned)...

Hello fellow slackers, here we continue the process...
This stage is apparently referred to as installing the SPL by sunxsi:

1. We need to obtain an u_boot - it's source code and it's maintained here. I got 2017.01
2. To be able to build it we either have to be native (build it on ARM host) or use a toolchain (in next post in more detail), i used the last time's linaro 5.3.1, links apparently obsolete quickly, so please use a search engine and the site structure, to locate the current one?
3. the build result is the file named

Code:

u-boot-sunxi-with-spl.bin

note the spl it stands for secondary program loader, we used to call BIOS on x86.
We need put this to where the SBC can find it - an MMC and on the spacial location:

Code:

start        size        usage

0        8KB        Unused, available for partition table etc.

8        24KB        Initial SPL loader

32        512KB        U-Boot

544        128KB        environment

672        352KB        reserved

1024        -        Free for partitions

according to sunxi.org.
This apparently populates the "track zero" of our "flash-disk"
The partition usually begins at 2048...
drmozes has us covered with the preparation of most orange_pi SBCs. And while he prepares all for us, I used his scripts and the "empty image" as following:

Code:

dd if=u_boot-build/u-boot-sunxi-with-spl.bin of=empty_image.img bs=1k seek=8

so I got my SPL in place where it belongs on a real "drive".
then I just applied it over an dedicated MMC:

Code:

# dd if=empty_image.img of=/dev/sdc

NOTE:
this is the first step one has to make as root,
i used /dev/sdc as it's the correct device for me - use most caution when finding out the proper device - or loose data at You own risk!

and my SPL was in place for me to try boot the OPI-PC:
MMC --> slot
2A (or better) 5V PSU (led driver comes to mind)
UART converter (or anything talking serial) to the OPI_PC header (care to "X" the TX and RX - TX-->RX RX-->TX GND-->GND)
open a terminal:

Code:

# screen -T screen-256color /dev/ttyUSB0 115200,-crtscts

(it becomes blank) (i use root for convenience- otherwise check user is in the right group (dialout?))
power on the OPI_PC
and it happily spews away:

Code:

U-Boot SPL 2017.01 (Jan 12 2017 - 19:48:33)

DRAM: 1024 MiB

Trying to boot from MMC1



U-Boot 2017.01 (Jan 12 2017 - 19:48:33 +0100) Allwinner Technology



CPU:  Allwinner H3 (SUN8I 1680)

Model: Xunlong Orange Pi PC

I2C:  ready

DRAM:  1 GiB

MMC:  SUNXI SD/MMC: 0

*** Warning - bad CRC, using default environment



In:    serial

Out:  serial

Err:  serial

Net:  phy interface0

eth0: ethernet@1c30000

starting USB...

USB0:  USB EHCI 1.00

USB1:  USB OHCI 1.0

USB2:  USB EHCI 1.00

USB3:  USB OHCI 1.0

USB4:  USB EHCI 1.00

USB5:  USB OHCI 1.0

scanning bus 0 for devices... 1 USB Device(s) found

scanning bus 2 for devices... 1 USB Device(s) found

scanning bus 4 for devices... 1 USB Device(s) found

Hit any key to stop autoboot:  0 

=> <INTERRUPT>

I might note the SPL got (DHCPd's) IP, so Ethernet seems supported by the mainline u_boot.

Using an toolchain: pros and cons.
I wanted to point out here, that our beloved Slackware apparently endorses the way of natively building ARM packages.
And by a good reason so.
It is better to have packages tested in native environment (that they work as intended) than to vaste time troubleshooting an non native build requirement.

But i just so happen that I don't have an native host running at hand, and have an new (fresh?) SBC in dire need of an OS.

So I found my self more easy to produce an toolchain-built u-boot on Slackware, than to try build it native on non-Slackware OS.

So it seems merely a matter of preference, and in my case of convenience (I happen more easy hack on Slackware than on other distros :o)

here my buildscript that makes the u-boot:

Code:

#!/bin/sh

# blah blah for Slackware-current 2017.

#

#



our_target="orangepi_pc_defconfig"

image="u-boot-sunxi-with-spl.bin"

export KBUILD_OUTPUT=`pwd`/u_boot-build



export CC=`pwd`/gcc-linaro-5.3.1-2016.05-x86_64_arm-linux-gnueabihf/bin/arm-linux-gnueabihf-





${CC}gcc --version



echo "we are building here:"

echo ${KBUILD_OUTPUT}

mkdir -vp ${KBUILD_OUTPUT}

rm -vrf ${KBUILD_OUTPUT}/*



echo "entering source tree"



cd u-boot

make ARCH=arm CROSS_COMPILE=${CC} distclean



make ARCH=arm CROSS_COMPILE=${CC} ${our_target}



# make ARCH=arm CROSS_COMPILE=${CC} xconfig



make -j4 ARCH=arm CROSS_COMPILE=${CC} all



echo "if all went well, here we have the image ready"





file=${KBUILD_OUTPUT}/${image}

if [ -a $file ]; then

  echo "image found :"

  ls -h $file

else

  echo "error, no valid output"

  exit 1

fi



echo "partition the device, and issue as root:"

echo "dd if=$file of=\"/dev/<yourMMC>\" bs=1k seek=8"

NOTE:
alpha quality, just works as is (ISC license okay?)
for it to work: symlink Your U_boot sources to u-boot:

Code:

ln -vs u-boot-2017.01 u-boot

for me, as I downloaded 2017.01 version.

Where do we go now?
well, since we have the option to boot from a u_boot, which equates "full featured bios boot", why not make an USB stick of current-ARM and try make it booted and then install? ;)

I will report back as soon as I find the available carrier for this (spare USB).

goal:
get series:
a,l,d,app and n installed at least - therefrom one can continue en vivo with slackpkg.

stay tuned
;)

Quote:

Originally Posted by SCerovec (Post 5654256)

Where do we go now?

Hi SCerovec,

It wouldn't be a bad idea to document and publish all your hard work on Slack Docs. I'm sure many users would benefit from your experience and efforts. :)

Quote:

Originally Posted by Penthux (Post 5654259)

Hi SCerovec,

It wouldn't be a bad idea to document and publish all your hard work on Slack Docs. I'm sure many users would benefit from your experience and efforts. :)

Why not hold off on that for now since the H3 installation support is already documented, but not pushed out until the latest packages finish building.

Once it's out, you might want to write additional documentation to cover more complex installation methods -- which I can provide a link to in the OrangePI installation docs.