Banana PI Slackware and alternate partition layout
Slackware - ARMThis forum is for the discussion of Slackware ARM.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
I'm using the one I synced from slackware-arm-current as per the HOWTO?
Code:
$ uname -a
Linux banarm 4.7.5-armv7 #2 SMP Mon Sep 26 22:52:36 BST 2016 armv7l Allwinner sun7i (A20) Family GNU/Linux
the other two questions:
No, I use the Banana Pi M1, so i use the bananapi blobs ?
And my best guess is they have some issues here?
is there an easy way i can check which blob is used?
for
Code:
printenv ${fdtfile}
on the boot loader shell prompt
For some reason I thought that you had a Banana Pi Pro. If you've followed the How to exactly then it should be fine.
You can tell which blob is in use by looking at the config as you have done.
I have 3 Banana Pi's here all installed using the Howto and they all work fine.
strange thing:
while in u-boot bot shell i can access and operate the USB devices:
Code:
=> usb reset
=> usb part
=> usb list
all work and evaluate the devices.
Moreover the USB keyboard (called keykoard??) also works - excep the leds don't show CAPS/num no any light?
but after I booted the kernel, any usb device is obscured from me?
Code:
# lsusb -v
yields nothing?
however i have this strange sequence in my dmesg:
Code:
[ 0.066981] Serial: AMBA PL011 UART driver
[ 0.082155] reg-fixed-voltage usb0-vbus: could not find pctldev for node /soc
@01c00000/pinctrl@01c20800/usb0_vbus_pin@0, deferring probe
[ 0.082210] reg-fixed-voltage usb1-vbus: could not find pctldev for node /soc
@01c00000/pinctrl@01c20800/usb1_vbus_pin@0, deferring probe
[ 0.082243] reg-fixed-voltage usb2-vbus: could not find pctldev for node /soc
@01c00000/pinctrl@01c20800/usb2_vbus_pin@0, deferring probe
[ 0.083081] reg-fixed-voltage gmac-3v3: could not find pctldev for node /soc@
01c00000/pinctrl@01c20800/gmac_power_pin@0, deferring probe
[ 0.084177] vgaarb: loaded
what is pctldev and what those errors mean?
Quote:
Originally Posted by drmozes
For some reason I thought that you had a Banana Pi Pro. If you've followed the How to exactly then it should be fine.
You can tell which blob is in use by looking at the config as you have done.
I have 3 Banana Pi's here all installed using the Howto and they all work fine.
I don't know what your issue is I'm afraid!
up there in red
could You please run
Code:
lsusb -v
for me?
apparently the device tree is the culprit?
I did measure all test points and they are all within few percent (1.5 test point yields 1.48V, 5v0 yields 5.23V, USB input is 4.8V)
the plugged device has ~3V on one data lead, all other are 0V.
As the USB devices all resolve on u-boot i assume the dtb/* holds the key?
this is for another thread, I focus for now on headless install.
Will report back
I have just upgraded to Linux 4.8.1 and testing it has found that USB keyboard no longer works in U-Boot (yet it was previously since I was using it as the desktop test machine!)
I have upgraded to the latest build on the SD Card here, which has restored keyboard access in the u-boot console.
I've also found now after upgrading to Linux 4.8.1 that I get nothing on USB either. I'm checking the Kernel configs - it might be that some how the machine I'm using got a botched package upgrade and some how continued to work; and that the Kernel currently shipped doesn't work with USB on the Pi -- which explains your problem!
I've found that a config merge has managed to remove the power module required to make USB work.
I can only assume that some how I botched the package upgrades on my desktop -current Banana Pi which is why I didn't notice before now. The primary build machine for -current gets reinstalled regularly, but the desktop test one just gets upgraded.
I'm rebuilding Linux 4.8.1 with the new config and will reinstall both, and probably push out the new packages tomorrow once I've tested them.
You'll have working USB in Linux soon!
thats great news!
I'm been busy also
here the "magic" script that needs be tested thoroughly.
first prerequisites: serial connection for debug tftp setup for testing MMC card/setup USB drive/setup SATA drive/setup microUSB cable for the OTG port
file boot.cmd
Code:
###
#
# v0.1-alpha (C) GPL cest73@ya.ru 2016 for Slackware ARM and U-BOOT
#
# 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 /boot.scr.uimg out filename and format:
# generated by
# ./mkimage -C none -A arm -T script -d boot.cmd boot.scr
#
# filename: boot.cmd
###
echo 'for SlackwareARM FEL boot v0.1...'
###
#
# defining the host specific parameters
#
###
# for Banana PI:
setenv fdtfile '/boot/dtb/sun7i-a20-bananapi.dtb'
setenv kernelfile '/boot/zImage-armv7'
# for setup
setenv setupfs '/boot/initrd-armv7.img'
# for everyday
setenv initrdfile '/boot/initrd-armv7'
setenv tftpfdtfile 'slackwarearm-current/dtb/sun7i-a20-bananapi.dtb'
setenv tftpkernelfile 'slackwarearm-current/zImage-armv7'
# for setup
setenv tftpsetupfs 'slackwarearm-current/initrd-armv7.img'
# for everyday
setenv tftpinitrdfile 'slackwarearm-current/initrd-armv7'
###
#
# defining the load addresses
#
###
# derived from UBOOT-FEL load address
#setenv fdt_addr_r 0x43000000
#setenv kernel_addr_r 0x42000000
#setenv ramdisk_addr_r 0x43300000
# use this for tftfp setup
setenv fdt_addr_r 0x43000000
setenv kernel_addr_r 0x46000000
setenv ramdisk_addr_r 0x47000000
###
#
# crafting the file source commands
#
###
# by ftfpboot .......... setup in the install on Banana PI HOWTO
# adjust to own TFTP server/host
setenv serverip 192.168.168.102
setenv ipaddr 192.168.168.128
tftp ${fdt_addr} ${tftpfdtfile}
tftp ${kernel_addr_r} $tftpkernelfile
# for setup
tftp ${ramdisk_addr_r} $tftpsetupfs
# for everyday
#tftp ${ramdisk_addr_r} $tftpinitrdfile
# from SCSI/SATA
#scsi reset; scsi scan
#ext4load scsi 0:1 ${fdt_addr_r} ${fdtfile}
#ext4load scsi 0:1 ${kernel_addr_r} ${kernelfile}
# for setup
#ext4load scsi 0:1 ${ramdisk_addr_r} ${setupfs}
# for every day
#ext4load scsi 0:1 ${ramdisk_addr_r} ${initrdfile}
# from MMC (tested so far)
#ext4load mmc 0:1 ${fdt_addr_r} ${fdtfile}
#ext4load mmc 0:1 ${kernel_addr_r} ${kernelfile}
# for setup
#ext4load mmc 0:1 ${ramdisk_addr_r} ${setupfs}
# for every day
#ext4load mmc 0:1 ${ramdisk_addr_r} ${initrdfile}
# from USB media
#usb reset; usb scan
#load usb 0:1 ${fdt_addr_r} ${fdtfile}
#load usb 0:1 ${kernel_addr_r} ${kernelfile}
# for setup
#load usb 0:1 ${ramdisk_addr_r} ${setupfs}
# for every day
#load usb 0:1 ${ramdisk_addr_r} ${initrdfile}
#for FEL just comment all above out - we load via the cable O.o
fdt addr ${fdt_addr_r} 0x40000
###
#
# crafting the boot arguments
#
###
### common boot arguments
#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 bootcmd_generic ' sunxi_g2d_mem_reserve=0 sunxi_ve_mem_reserve=0'
#setenv bootcmd_generic ' debug earlyprintk'
### initial output
# for serial console
setenv slkconsole ' console=ttyS0,115200'
# or for HDMI
#setenv slkconsole ' console=tty1'
### OS related parameters
# setup with automatic network parameters
#setenv osargs " TERM=screen-256color nic=auto:eth0:dhcp root=/dev/ram rw"
# setup without LAN network
setenv osargs " TERM=screen-256color nodhcp root=/dev/ram rw"
# everyday parameters for MMC/SD card
#setenv osargs " resumedev=/dev/mmcblk0p2 root=/dev/mmcblk0p1 rootfstype=ext4 ro"
# everyday parameters for SCSI or USB
#setenv osargs " resumedev=/dev/sda2 root=/dev/sda1 waitforroot=2 rootfstype=ext4 ro"
### gluing it all together
# kernel command line
setenv bootargs ${slkconsole} ${bootcmd_generic} ${osargs}
###
#
# initial output
#
###
# passing control to kernel
bootz ${kernel_addr_r} ${ramdisk_addr_r}:${filesize} ${fdt_addr_r}
# here from You should be with Slackware setup or system
this file alone is *magic* , where ever You put it on root (/) it pulls the belonging /boot/* residing files into operation - if edited correctly (by means of toggling the many #)
then the "wizard" script doing all the "brain muscle" in our stead:
file fel-setup.sh
Code:
#!/bin/bash
####
#
# (c) GPL v3 for Slackware for ARM and Banana PI
# by cest73@yandex.ru (support on linuxquestions.org)
#
###
#init:
prog=$(which sunxi-fel)
conv=$(which mkimage)
string="AWUSBFEX soc=00001651(A20) 00000001 ver=0001 44 08 scratchpad=00007e00 00000000 00000000"
spl="u-boot-sunxi-with-spl.bin"
bootcmd="boot.cmd"
bootscr="boot.scr"
echo "checking for ${conv}"
if [ -x ${conv} ] ; then
echo "converting:"
$conv -C none -A arm -T script -d ${bootcmd} ${bootscr}
else
echo "can't convert the ${bootcmd} file."
if [ -a ${bootscr} ] ; then
echo "WARNING: present [${bootscr}] will be used!"
else
echo "we have nothing to fall back to, aborting."
exit 2
fi
fi
echo "checking for ${prog}"
if [ -x ${prog} ] ; then
echo "detecting:"
device=$(lsusb -d 1f3a:efe8 | awk '{print $2"-"$4}' | sed -e "s/://" -e "s/-/:/")
if [ -z $device ]; then
echo -ne "Did You plug the USB to DC or OTG port?\n Also the board needs to be in FEL mode.\n"
exit 2
fi
echo "device detected: ["${device}"],"
echo "checking:"
extract=$($prog -d ${device} ver)
echo "got response:["${extract}"]"
if [ "X${extract}"=="X${string}" ]; then
echo "*** it's a match! ***"
else
echo "it's not a match."
exit 2
fi
else
echo "no executable found: sunxi-fel is part of sunxi tools from sunxi u-boot package"
exit 2
fi
echo "locating the SPI file:["$spl"]:"
#spl_file=$(slocate -n1 ${spl} | grep "\/${file}")
spl_file=${spl}
echo "checking for ["$spl_file"]"
if [ -a "${spl_file}" ] ; then
echo "found ["${spl_file}"]"
else
echo "no spi file found"
exit 2
fi
echo "uploading to device:"
# this is for "zero playload" cases as tftp boot etc...
# $prog -p -v uboot ${spl_file} \
# write 0x43100000 boot.scr
#exit 1
$prog -p -v uboot ${spl_file} \
write 0x43100000 boot.scr \
write 0x43000000 sun7i-a20-bananapi.dtb \
write 0x46000000 zImage-armv7 \
write 0x47000000 initrd-armv7.img #<-- setup
WARNING: ALPHA CODE - it will break things, errors are only marginally handled! patches only are welcome insufficiently commented patches will be > /dev/null
tested so far:
OTG works
boot.scr works via OTG ("fel-boot")
fel-boot works - reset while holding K3 key
USB works in u-boot (latest stable 2016 here)
auto detection in U-boot works (mostly)
MMC boot works (this script boots my MMC setup)
tftp boot works (only way setup wants to mount /dev/ram is tftp - why?)
fel-boot works for MMC (i boot the USB supplied kernel and run the MMC residing OS)
fel-boot can't mount "root" fs from setup's initrd? yet it mounts from tftp - the same exact files
also i provided a downloadable tarbal with my binary files I tested all with: fel-setup-01tar.gz ~56Mb
Last edited by SCerovec; 10-14-2016 at 12:48 AM.
Reason: re stated welcome inputs
I've found that a config merge has managed to remove the power module required to make USB work.
I can only assume that some how I botched the package upgrades on my desktop -current Banana Pi which is why I didn't notice before now. The primary build machine for -current gets reinstalled regularly, but the desktop test one just gets upgraded.
I'm rebuilding Linux 4.8.1 with the new config and will reinstall both, and probably push out the new packages tomorrow once I've tested them.
You'll have working USB in Linux soon!
In no way am I to be considered an authority on kernel builds, but so far I found that doing a cross-release config merge is fastest accomplished by hand:
1. run a diff on .configs and examine only changes that might be enabled
2. any changes made that make the "menuconfig" menu structure look odd will probably result in a compile break
3. Probably You'll end up doing something in between oldconfig and newconfig so take the time
4. enabling as few at a time and test-compile is a good idea
Last time i tried to merge a config (4.8 -> 4.7.?) i ended up in abandoning the try all together?
Also it's understood that moving a config is only reasonable on a vanilla kernel
I noticed PCI support on "our" kernel, are there ARM based PCI boards too?
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
?
files to be tested
*magic* 
