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 :) |
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. Quote:
Quote:
Quote:
Have you looked at the mini root? You can probably modify this to achieve your goal. Quote:
Once you're done - docs.slackware.com will welcome your project documentation. |
Quote:
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. |
Quote:
Quote:
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:
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:
BTW it did succeed to build, didn't have time to play with it any further. Yet. Quote:
|
@justwantin
I just coonfigured it in a separate directory than the extracted code: Code:
$ tar xf ${srcarchive} after a while it was done and I need more time to test any further some pictures will be posted then too :) |
Quote:
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:
Quote:
Quote:
|
5 Attachment(s)
Quote:
Quote:
Quote:
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 ... |
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:
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 |
one of the non obvious dependencies:
Code:
dtc |
Quote:
|
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:
|
Quote:
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? |
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 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 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/ |
Quote:
|
Quote:
I just finished doing the initial booting phase: boot.cmd file: Code:
setenv bootargs console=ttyS0,115200 root=/dev/mmcblk0p1 rootwait panic=10 ro 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 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 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. |