LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Slackware - ARM (https://www.linuxquestions.org/questions/slackware-arm-108/)
-   -   Banana PI Slackware and alternate partition layout (https://www.linuxquestions.org/questions/slackware-arm-108/banana-pi-slackware-and-alternate-partition-layout-4175590789/)

SCerovec 10-05-2016 02:29 AM

Banana PI Slackware and alternate partition layout
 
hi,
I've got an Banana Pi M1 for the role of an dedicated NAS.

Being able to get it to boot Slackware-current I can report that it works.

However there are wishes open and I try use this thread to address some of my concerns and solutions I found and still seek.

Also I hope this thread to be the reference for users to wishing to get the Banana PI doing other than bare a storage for the LAN.

So far i got:
- Install it with the serial converter and provided howto (kind thanks!)
tips: make sure You have an quality MMC/SD card with good quality contacts ;)

- Booting to OS and running services over network

Didn't check yet:
- SATA (waiting for cables to arrive)

Checked but didn't work:
- USB - one can't just plug a USB device to the B_Pi and have it working. While i have no doubt the hardware woks, there are B_Pi specific issues I'm gonna have to delve in yet and I will report back.


What I want to further investigate and share here:

Booting from a offline editable partition, as R_pi has currently and making a HOWTO
why: To be able to prepare a MMC/SD card and just plug it to serve; To be able to tweak the various boot options (boot sources, OS locations etc, hardware settings)

So far I stuck in building the Linaro tool chain around GCC 4.9 (quite a pile of things?) and then try to make the boot as accessible to editing as practical - with no additional hardware required (in the sense of serial converters or USB cables) besides an Card reader.

I would optionally try to explore the OTG option for building an boot-able partition by the means of only a USB cable - to whatever destination is possible (MMC/USB/SATA) and report the limitations and requirements for each.

P.S.
this will take quite some time and I'm on a tight schedule, so don't hold your breath :)

drmozes 10-05-2016 02:49 AM

Quote:

Originally Posted by SCerovec (Post 5614089)
So far i got:
- Install it with the serial converter and provided howto (kind thanks!)

You can also install it using the HDMI port if you change the boot parameters, but I prefer using the serial port because I can paste in the boot parameters in to a terminal easily.

I was wondering whether I could tftp a u-boot script and call it but didn't find out how to do that yet.

Quote:

Checked but didn't work:
- USB - one can't just plug a USB device to the B_Pi and have it working. While i have no doubt the hardware woks, there are B_Pi specific issues I'm gonna have to delve in yet and I will report back.
I have a USB keyboard, ethernet and SD card reader on mine. Is there a particular USB device that doesn't work? Perhaps there is no Kernel module for it.

Quote:

Booting from a offline editable partition, as R_pi has currently and making a HOWTO
I don't know what you mean by offline - if it's plugged into the device then it's online. Do you mean it's inaccessible to Linux once booted? I'm not sure why anybody would want to do this unless you wanted to hide the location of the Kernel and initrd, but then it makes Kernel upgrades a pain.

Quote:

why: To be able to prepare a MMC/SD card and just plug it to serve; To be able to tweak the various boot options (boot sources, OS locations etc, hardware settings)
As I see it you could do this and still have the ready to serve SD card fully visible to the running OS.
Have you looked at the mini root? You can probably modify this to achieve your goal.


Quote:

So far I stuck in building the Linaro tool chain around GCC 4.9 (quite a pile of things?)
Why gcc 4.9 and why the Linaro tool chain?

Once you're done - docs.slackware.com will welcome your project documentation.

justwantin 10-07-2016 03:40 PM

Quote:

So far I stuck in building the Linaro tool chain around GCC 4.9 (quite a pile of things?)
Have you tried http://crosstool-ng.org? It's a fully automated build that worked for me in Slack 14.1 and in current before 14.2. Didn't use it for much beyond building u-boot. If your bpi m1 is up and running, perhaps you could try x-toolchain

The Bpi M1 is sold by Sinovoip while Banana Pi is sold by Lemaker. I wonder if they are exactly the same now as they were supposedly in first production runs.

SCerovec 10-09-2016 06:45 AM

Quote:

Originally Posted by drmozes (Post 5614092)
You can also install it using the HDMI port if you change the boot parameters, but I prefer using the serial port because I can paste in the boot parameters in to a terminal easily.

Thank You for the excellent HOWTO, it helped a lot!
Quote:

I was wondering whether I could tftp a u-boot script and call it but didn't find out how to do that yet.



I have a USB keyboard, ethernet and SD card reader on mine. Is there a particular USB device that doesn't work? Perhaps there is no Kernel module for it.

I just so happen to have an RPi B, the one with the 7805 type of voltage regulator, and anything i tried on B_Pi was off the R_Pi.
It's an desktop USB keyboard i had at hand.
further an USB stick failed to be accessed, so I figured to check for latest u_boot upstream?
Quote:


I don't know what you mean by offline - if it's plugged into the device then it's online. Do you mean it's inaccessible to Linux once booted? I'm not sure why anybody would want to do this unless you wanted to hide the location of the Kernel and initrd, but then it makes Kernel upgrades a pain.



As I see it you could do this and still have the ready to serve SD card fully visible to the running OS.
Have you looked at the mini root? You can probably modify this to achieve your goal.

:)
Nothing as exotic as that, offline simply means off the device:
I always have an alternative PC at hand, and want be able to do "fiddly" stuff wile the OS is offline. Even better yet, to access the boot parameters online while the OS runs and apply them via reboot.
So far, to interact with boot parameters i need be in boot shell? and on a terminal, be it serial or virtual?
Quote:


Why gcc 4.9 and why the Linaro tool chain?
I supposedly need this to build latest u_boot?
BTW it did succeed to build, didn't have time to play with it any further.
Yet.
Quote:

Once you're done - docs.slackware.com will welcome your project documentation.
May I count on Your generous help sir, :D for final redaction?

SCerovec 10-09-2016 06:56 AM

@justwantin
I just coonfigured it in a separate directory than the extracted code:
Code:

$ tar xf ${srcarchive}
$ mkdir ${builddir}
$ cd ${builddir}
$ ../${srcdir}/configure
$ make -j4

for I have a quadcore CPU.
after a while it was done and I need more time to test any further

some pictures will be posted then too :)

drmozes 10-10-2016 04:54 AM

Quote:

Originally Posted by SCerovec (Post 5615706)
I always have an alternative PC at hand, and want be able to do "fiddly" stuff wile the OS is offline. Even better yet, to access the boot parameters online while the OS runs and apply them via reboot.

Yes that'd be cool. I think the easiest option is to replace the hard coded u-boot config (as my docs suggest) with a command to load a script from the file system instead -similar to LILO.
That'd be an interesting project to do, but it'd need a fair bit of work I think. Debian has something similar already.

I might have a look into that, although I'd rather someone else works on it as I have no time to commit to it.

Quote:

So far, to interact with boot parameters i need be in boot shell? and on a terminal, be it serial or virtual?
You just need to get access to the u-boot command prompt which is either by serial cable or with a USB keyboard and HDMI.

Quote:

I supposedly need this to build latest u_boot?
You don't need the Linaro toolchain to build u-boot - just any recent gcc.

Quote:

May I count on Your generous help sir, :D for final redaction?
Depends what it's about and whether I'd have any valuable input, but you can post it here.

SCerovec 10-10-2016 05:06 AM

5 Attachment(s)
Quote:

Originally Posted by drmozes (Post 5616028)
Yes that'd be cool. I think the easiest option is to replace the hard coded u-boot config (as my docs suggest) with a command to load a script from the file system instead -similar to LILO.
That'd be an interesting project to do, but it'd need a fair bit of work I think. Debian has something similar already.

I might have a look into that, although I'd rather someone else works on it as I have no time to commit to it.

That's what I was after here :)
Quote:

You just need to get access to the u-boot command prompt which is either by serial cable or with a USB keyboard and HDMI.

You don't need the Linaro toolchain to build u-boot - just any recent gcc.

mine u_boot somehow failed to build, i will investigate and report back
Quote:


Depends what it's about and whether I'd have any valuable input, but you can post it here.
Excellent :D
This was exactly what i was hoping for! on to business :D :
below find the attached first few photos:
The B_Pi front n back
The Keyboard that failed to register
Illustration of an "headless setup" for an NAS (Network Accessible Storage)
Current installation setup - exotic HW requirements.
next post more photos to come...
.. stay tuned ...

SCerovec 10-10-2016 05:18 AM

5 Attachment(s)
... last time on armed kitchen (the series :D )...

my best case scenario:

I get to install the u_boot SPL "behind" the partition sectors (track zero)
this loads the script from an filesystem (preferably ext4)
this script handles loading the:
  1. kernel
  2. intrd
  3. commandline parameters
and that script resides on the root partition

compromises:
- I can accept a small boot partition as Debian uses ATM
- I can accept multi stage boot as long as i end up having said script in userspace and runtime.

TBD:
if there are any and which differences of my B_pi and Lemaker's Banana-pro and Banana-pi?

Those who can, please post photos of involved devices?

more photos:
The fel-key (USB boot enable key) etc
SATA connectors and USB-power plug
yet another top view
an cordless input pad planned for use
reference: R_pi model B

SCerovec 10-10-2016 06:24 AM

one of the non obvious dependencies:
Code:

dtc
device-tree-compiler

to be installed by sbotools or any other preferred method

drmozes 10-10-2016 07:57 AM

Quote:

Originally Posted by SCerovec (Post 5616048)
one of the non obvious dependencies:
Code:

dtc
device-tree-compiler

to be installed by sbotools or any other preferred method

This is the same thing, and it's in the 'd' series on ARM (d/device-tree-compiler) but I don't include a build script for x86/64.

SCerovec 10-10-2016 08:26 AM

dtc (see above) and the Linaro toolchain are needed to build a custom (more recent?) banana pi u_boot image.
I build it on my x86 host, so I must cross compile it, so I happen to need Linaro's toolchain?
Allthough this time i use the pre-built one, and this way i harness the Slackware's legendary binary compatibility :), but note it's a 64bit package!

further:
Note: "SPL" stands for "Secondary Program Loader"
(from the u_boot README)

...getting there :) here some of the path passed already:
Quote:

Toolchain HOWTOs:
https://eewiki.net/display/linuxonar...ssCompiler:GCC
(note: ~180Mb download)

URIs:
http://www.linaro.org/downloads/
Code:

wget -c https://releases.linaro.org/components/toolchain/binaries/5.3-2016.05/arm-linux-gnueabihf/gcc-linaro-5.3.1-2016.05-x86_64_arm-linux-gnueabihf.tar.xz
tar xf gcc-linaro-5.3.1-2016.05-x86_64_arm-linux-gnueabihf.tar.xz
export CC=`pwd`/gcc-linaro-5.3.1-2016.05-x86_64_arm-linux-gnueabihf/bin/arm-linux-gnueabihf-
${CC}gcc --version #<== note it's 5.3.1 and not shipped 5.3.0 of Slackware!
make ARCH=arm CROSS_COMPILE=${CC} distclean
make ARCH=arm CROSS_COMPILE=${CC} Bananapi_defconfig
make ARCH=arm CROSS_COMPILE=${CC} xconfig # <== note: here i tweak the config a bit ;)
make ARCH=arm CROSS_COMPILE=${CC}

...
  COPY    spl/u-boot-spl.bin
  CFG    spl/u-boot-spl.cfg
  MKSUNXI spl/sunxi-spl.bin
  OBJCOPY u-boot-nodtb.bin
  CAT    u-boot-dtb.bin
  COPY    u-boot.bin
  MKIMAGE u-boot.img
  CAT    u-boot-sunxi-with-spl.bin
  OBJCOPY u-boot.srec
  SYM    u-boot.sym
  CFG    u-boot.cfg
  COPY    u-boot.dtb
  MKIMAGE u-boot-dtb.img


... stay tuned :) ...

SCerovec 10-10-2016 08:29 AM

Quote:

Originally Posted by drmozes (Post 5616062)
This is the same thing, and it's in the 'd' series on ARM (d/device-tree-compiler) but I don't include a build script for x86/64.

But i didn't know about this, this is why I choose to mention it, as it's not a common knowledge thing among x86 dwellers :hattip:

the device three is altogether a fresh thing for me too...

Cross compiling the more even :D, but i manage somehow...

Kind thanks for the support, hope i don't spam anyone?

SCerovec 10-10-2016 09:49 AM

1 Attachment(s)
so, having built all the files needed, it's time we prepare our SD card to carry the OS.
I recommend Gparted, as there is a separate live CD as well as a package for Slackware.
BEWARE:
with Gparted one can easily destroy mountains of data; Use with extreme caution and mandatory backup!
- note to self: warning issued - conscience clear.

attached please find images of proposed partition layout
after tayloring Your space, navigate to the build dir of the u-boot and execute as root:
Code:

# dd if=u-boot-sunxi-with-spl.bin of=/dev/sdb bs=1024 seek=8
where /dev/sdb is Your future MMC card and not Yout host OS disk!

now it's time to sync and perform an eject just to be sure.

next time we work on boot.cmd and the
Code:

/boot
directory.

If You accidentally have erased Your hard drive now is a good time to panic, otherwise have a nice time.

P.S.
only reason to use an FAT primary boot partition is to have the boot editable by an non GNU OS, which I find by itself ridiculous, as usually we want to provide an vmlinuz/zImage and probably a proper initrd? Am i wrong? Would they be downloaded anyway, and I just am sawing the branch I'm sitting on by this choice? I mean even Androids read ext4 by now?
this:https://www.paragon-software.com/home/extfs-windows/

drmozes 10-10-2016 12:27 PM

Quote:

Originally Posted by SCerovec (Post 5616100)
only reason to use an FAT primary boot partition is to have the boot editable by an non GNU OS, which I find by itself ridiculous, as usually we want to provide an vmlinuz/zImage and probably a proper initrd? Am i wrong? Would they be downloaded anyway, and I just am sawing the branch I'm sitting on by this choice? I mean even Androids read ext4 by now?
this:https://www.paragon-software.com/home/extfs-windows/

Just bare in mind that the Slackware packaging for the Kernels use symlinks and expect /boot to have a file system compatible with them, and for this u-boot only supports ext2/3/4 (as far as I know).

SCerovec 10-10-2016 01:01 PM

Quote:

Originally Posted by drmozes (Post 5616164)
Just bare in mind that the Slackware packaging for the Kernels use symlinks and expect /boot to have a file system compatible with them, and for this u-boot only supports ext2/3/4 (as far as I know).

One more reason we go for ext4, so ext4 it is:

I just finished doing the initial booting phase:
boot.cmd file:
Code:

setenv bootargs console=ttyS0,115200 root=/dev/mmcblk0p1 rootwait panic=10 ro
setenv fdt_addr 0x43000000
setenv kernel_addr_r 0x47000000
setenv ramdisk_addr_r 0x48000000

load mmc 0:1 ${fdt_addr} boot/dtb/${fdtfile}
load mmc 0:1 ${kernel_addr_r} boot/zImage-armv7
load mmc 0:1 ${ramdisk_addr_r} boot/initrd-armv7

fdt addr ${fdt_addr} 0x40000
bootz ${kernel_addr_r} ${ramdisk_addr_r}:${filesize} ${fdt_addr}

here is obvious that I used the values from the excellent HOWTO:hattip:

next it has to be converted to boot.scr by means of the following command:
Code:

mkimage -C none -A arm -T script -d boot.cmd boot.scr
the mkimage is built in the tools directory of the u-boot tree.

if not converted it won't boot.

before partitioning the MMC card, it is strongly advised to zero out the beginning of the medium:
Code:

dd if=/dev/zero of=/dev/sdb count=4k
and start from scratch, as the environment of the SPL is maintained "in between" any managed storage space - only manual zeroing "takes care".

further I intend to check and document the method of LAN based installation:

best case:

1. zero out the beginning
2. make "empty dos label"
3. tailor MMC/SSD card partitions
4. put setup to boot from "ROOT" partition into RAM (pre-built /boot.scr file ;) )
5. upload "our stuff" to "HOME"/ftp/pub/slackwarearm for installation
6. boot to online ssh server
7. accept a login to setup

therefrom it would be straight forward?

and to end setup with copying the (canonic?) /boot.scr file over the one belonging to setup?

note: the boot.scr seems to need be in the root directory of an partition?
...to be continued...


All times are GMT -5. The time now is 10:52 PM.