sbc_chrisb

Is this the thread were we make requests for config changes for the kernel build? I am going back to rebuild a custom kernel due to missing hidraw and logitech unifying receiver modules. As far as I'm concerned I'm cool with rolling a custom kernel, but I would think I ain't the only dude wanting to use Logitech wireless devices with my board. It would be cool to have these built in as modules.

Agreed, I was pulling my hair out trying to install to mmc with any image as it would not flush the partitions, until I finally just tried dd'ing an armbian image directly to the mmc module, which flushed out the Android stuff, and then from there I did the stuff I mentioned in my posts. I could not get any installation to work while the Android stuff was present. Even with balbes' instructions, none of it worked until I used dd.

No worries, I just wanted to confirm what you asked. I have it working with the tweak so I'm happy at this point. I'm also working on restoring an old TRS-80 Color 1 right now so I understand the distraction

Okay, so I reverted boot.cmd to your version, ie put the rootdev back to /dev/mmcblk1p1, then created armbianEnv.txt with the following line: setenv rootdev "/dev/mmcblk0p1" Rebuilt the scr. Rebooted. Fails to boot, this is the captured output: Begin: Running /scripts/local-block ... done. done. Gave up waiting for suspend/resume device done. Begin: Will now check root file system ... fsck from util-linux 2.29.2 [/sbin/fsck.ext4 (1) -- /dev/mmcblk1p1] fsck.ext4 -a -C0 /dev/mmcblk1p1 LPotato_SD: clean, 13/1954064 files, 166731/7814912 blocks done. done. Begin: Running /scripts/local-bottom ... done. Begin: Running /scripts/init-bottom ... mount: No such file or directory mount: invalid option -- done. mount: No such file or directory run-init: opening console: No such file or directory Target filesystem doesn't have requested /sbin/init. run-init: opening console: No such file or directory run-init: opening console: No such file or directory run-init: opening console: No such file or directory run-init: opening console: No such file or directory run-init: opening console: No such file or directory No init found. Try passing init= bootarg. (initramfs) So, while on a fresh Armbian image the boot.cmd you posted works completely 100% as is, when using an older image that was updated via apt and etc seems to require me to directly change the cmd and rebuild scr. Unless I'm doing something wrong with the ArmbianEnv.txt, which is entirely possible. I'm not really familiar with that file.

Yes, sorry that statement is correct, it would still boot from SD which allowed me to go back in and fix it. I don't have the exact logs of that point but I believe that was when it was hanging at trying to remount the rootfs and failing, so it just sat there hung until I inserted the SD card.

Okay, I might have goofed on something here. I'll fire it back up in a bit, revert my boot.cmd modification, and retest. I can confirm, with both an older armbian image that was upgraded via apt, and with a brand new image downloaded from the main site, that nand-sata-install does not work. The only way I got past that was rebuilding a newer 4.18.19 kernel, and uboot. After that, I required the use of Tony's updated boot.cmd in order to boot from it, it would not boot by default at all.

Follow up post, in case anyone ends up here in searches on this topic. Once i had this working, I then repeated it using my original SD card install with what started out as an older version of Armbian, upgraded via apt. I had a few minor bumps I'm going to explain here. 1. The new kernel is a must. The stock kernel did not work, I had to reuse the 4.18.19 kernel packages I built before. 2. The updated boot script I keep mentioning has to be tweaked. It will try to use mmcblk1p1 for the root device, but on my board the mmc is mmcblk0. The device would not boot from mmc until I modified the boot.cmd to set the rootdev and rebuilt the scr. I'm not sure if this is expected behaviour or not.

Whew. Okay, so that was a fun ride. My suspicions about the kernel were correct. I followed the docs to do a new kernel build for armbian, 4.18.19. I hadn't built a kernel or anything large like that in a while, really stress tested my AMD 8350. Either way, I got the new packages over onto the Potato, installed them (with a --force-all to get uboot to update, since it refuses initially). Then after another reboot, nand-sata-install completed successfully. First boot without an SD card failed hard. Went back in with the SD card, mounted the emmc and mv'd the boot.cmd and scr files out of the way and put in the one Tony provided me above. Rebuilt the scr with mkimage. That did the trick, I'm now running on emmc now. Thanks for the help, Tony. To recap, the stock image is fine to install to emmc *if* you: 1. build a new 4.18 kernel, hopefully the next armbian release will be fine 2. run nand-sata-install 3. mount the emmc and modify the boot.cmd command *in the emmc boot dir* with the updated file linked above, then rebuild the scr with mkimage. NOTE: don't use the command in the bottom of the file directly, as it gives absolute paths for the files and since you're on the SD card the path is different. Use the following while in the boot dir of the emmc: mkimage -C none -A arm -T script -d boot.cmd boot.scr

Okay, so I left it running for a while, almost 4 hours. It was stuck in the same "checking for open files" spot. I think at this point I'm going to look up some docs and build a newer kernel for this before I proceed any further, that was one factor that seemed to have success at least with this. Also, my USB wifi dongle is an ath9k_htc device and there doesn't appear to be a driver pre-built with these images (I enabled non-free and installed the firmware-atheros package and there's still no kernel module for the device), so I'm going to try building that as a module as well. Side note, these emmc modules appear to have two extra 4MB devices glued on, showing in lsblk. I copied them off with DD to inspect with a hex editor to try to figure out what they are, but does anyone happen to know? I didn't see that in any docs.

I found a log in /var/log/nand-sata-install.log, it looks like it was looking for open files still when I aborted? I'm not sure what files might be missing. Tue Sep 18 17:28:10 UTC 2018: Start nand-sata-install. Old UUID: UUID=763b6c65-4dfe-4e7b-8180-426b7298fddf SD UUID: UUID=dc031793-8691-4641-96a0-9520084fe3b0 UUID=763b6c65-4dfe-4e7b-8180-426b7298fddf SATA UUID: UUID=dc031793-8691-4641-96a0-9520084fe3b0 eMMC UUID: UUID=dc031793-8691-4641-96a0-9520084fe3b0 ext4 Boot: $1 /dev/mmcblk0p1 ext4 Root: $2 /dev/mmcblk0p1 Usage: 1007 Dest: 6781 /etc/fstab: UUID=763b6c65-4dfe-4e7b-8180-426b7298fddf / ext4 defaults,noatime,nodiratime,commit=600,errors=remount-ro 0 1 tmpfs /tmp tmpfs defaults,nosuid 0 0 /etc/mtab: /dev/mmcblk0p1 /mnt/nand-sata-install.jY1gTX/bootfs ext4 rw,relatime,data=ordered 0 0 /dev/mmcblk0p1 /mnt/nand-sata-install.jY1gTX/rootfs ext4 rw,relatime,data=ordered 0 0 /dev/mmcblk1p1 / ext4 rw,noatime,nodiratime,errors=remount-ro,commit=600 0 0 /dev/mmcblk1p1 /var/log.hdd ext4 rw,noatime,nodiratime,errors=remount-ro,commit=600 0 0 /dev/zram0 /var/log ext4 rw,relatime,block_validity,discard,delalloc,nojournal_checksum,barrier,user_xattr,acl 0 0 Files currently open for writing: Trying to stop running services to minimize open files: Checking again for open files: Copying 37009 files to /dev/mmcblk0p1. Finishing full install to eMMC. Checking again for open files: Tue Sep 18 18:34:28 UTC 2018: Finished This stock image appears to be using kernel 4.14, that was one difference with the balbes images in that they used the 4.19rc kernel. I'm not finding any man page nor any options calling the nand-sata-install command via -h, so I don't know if there's any way to turn up the debugging on it. I'm going to try getting internet to the device and doing apt upgrades on the sd card that I'm installing with, then re-running the nand-sata-install command, and seeing if that helps.

Yep, thanks for the reminder. I'm familiar with creating those scr files. I've been waiting for a loooooong time for the nand-sata-install command on the stock download you mentioned, I think it's stuck or something. Just sitting at "Counting files.....few seconds" for, oh maybe two hours now. I'm pretty sure it's not supposed to take that long. About to abort and see what command line options that command has to see if I can get a log file or something. I was originally using an older armbian image and had a similar experience with it, which was why I had tried balbes images, which worked great for that command. Not really sure what's going on with the stock Armbian command. Doing more investigating.

Thanks for the update. I copied the file linked and pasted it into my emmc boot as boot.cmd, then ran mkimage to generate the scr. Unfortunately, I'm still getting the previous results. I then re-ran the nand-sata-install command to clear the emmc back to a default state before any of my tinkering, and tried again. Still stops at remounting root fs. Is there a direct link to an image for the version of armbian you are using here that I can plop onto my SD card to try booting from? I am currently using the images from balbes, and I don't know if that's configured differently. I'd like to just use whatever image you're reporting success with here.

So, I've been fighting with getting a working Armbian install on my eMMC for almost a week now. I should also mention I have a serial console hooked up, so I am working strictly over the serial debug console. I've ruled out power issues, and here's the problem I'm at now. I used balbes' latest image to create a bootable SD card. I can boot with that card. I ended up only having success by using the nand-sata-install command once I had gotten booted into that version of armbian. I mounted the eMMC and verified the boot files, and then reboot without the SD card present in order to boot straight from eMMC. The kernel gets to remounting the root filesystem and just hangs. The last message is: [ 4.062163] [drm] Cannot find any crtc or sizes It just sits there. If, at this point, I insert the SD card, the system sees it, and mounts that card as root and boot. So, my system is then running only on the SD card, again. I've tried a few things with changing the fstab on the emmc to use the /dev/mmcblk1p2 for root instead of LABEL= as well as for /boot, figuring it was that old bug that prevented mounting with labels. It's not that. I also tried changing the boot/uEnv.ini file to use the /dev/ device rather than the label, still no luck. It just will not mount the mmc as the root file system. Not sure what info is needed to proceed. I also gave the above bloader line a spin in armbianEnv.txt but it didn't help anything. Any one have any ideas here? Is there another file I need to modify to boot solely from the eMMC?

So, I still need to verify some of the later pins, going to work on that tomorrow with a bash walker loop while I swap wires on the header to an LED. This is yet another table that maps the 40 pins to libgpio, for reference. Maybe someone will find it useful. GC0 is gpiochip0 and GC1 is gpiochip1 in libgpio. Quick bash variable list for importing into scripts, so you can just think in terms of header pins rather than the mappings. P01=NA P02=NA P03=0:5 P04=NA P05=0:4 P06=NA P07=1:98 P08=1:91 P09=NA P10=1:92 P11=0:8 P12=0:6 P13=0:9 P14=NA P15=1:100 P16=1:93 P17=NA P18=1:94 P19=1:87 P20=NA P21=1:88 P22=1:79 P23=1:90 P24=1:89 P25=NA P26=1:80 P27=1:75 P28=1:76 P29=1:96 P30=NA P31=1:97 P32=1:95 P33=1:85 P34=NA P35=1:86 P36=1:81 P37=1:84 P38=1:82 P39=NA P40=1:83 Example bash script: #!/bin/bash . pinheaders #This is the above variable list as a separate file print() { for i in {01..40}; do var=P${i} printf "Pin $i: ${!var}\n"; done } walk() { for i in {01..40}; do var=P${i} if [[ ! ${!var} = "NA" ]]; then chip=gpiochip$(echo ${!var} | cut -f1 -d:) pin=$(echo ${!var} | cut -f2 -d:) gpioset $chip ${pin}=1 sleep .5 gpioset $chip ${pin}=0 fi done } You get the idea. If you're working with just pins 27 and 28 you can source the pinheader file, then use $P27 and $P28 to get the chip and pin from that variable. Hopefully this info is useful to someone searching the forum like I was.

So, I did some more testing and crashed my board. I hooked up wire to what I'm calling pin 3. Honestly I'm completely confused how to number these pins now. I was referencing this page http://wiki.loverpi.com/sbc-brand:libre-computer and the pinout link there: http://wiki.loverpi.com/pinouts which has two pins labelled 2: the pin right next to 3v3, and also first 5v. Anyway I wired up the pin next to 3v3 to an LED, and also ground. I then ran a bash loop to use gpioset gpiochip1 like so: chris@lepotato:~/Projects/libgpiod$ for i in {1..25}; do echo $i; sudo gpioset gpiochip1 $i'=1'; read; sudo gpioset gpiochip1 $i'=0'; done 1 gpioset: error setting the GPIO line values: Invalid argument gpioset: error setting the GPIO line values: Invalid argument 2 gpioset: error setting the GPIO line values: Invalid argument gpioset: error setting the GPIO line values: Invalid argument 3 gpioset: error setting the GPIO line values: Invalid argument gpioset: error setting the GPIO line values: Invalid argument 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 gpioset: error setting the GPIO line values: Device or resource busy gpioset: error setting the GPIO line values: Device or resource busy 20 21 22 23 24 25 And yeah, the LED never lit up. From that spreadsheet linked above, it should have been lighting up at 5, but it wasn't. When I tried doing the above loop all the way to 100, it eventually completely crashed my board and I had to hard reset it. Is libgpio just busted or something? I confirmed the LED works by connecting it to the ground pin and 5v, then 3v3, then the second 5v, and it lights up fine on those three. I hooked it to "pin 3" and while it gives a very slight dim light by default (not sure it's supposed to do that or what), and then never changes when I run the above loop to send it to 1 or 0. I must be doing something wrong here... EDIT: Okay, so I can't get this to actually change any values anyway. l_chip=gpiochip1 chris@lepotato:~$ sudo gpioget $l_chip 5 1 chris@lepotato:~$ sudo gpioset $l_chip 5=0 chris@lepotato:~$ sudo gpioget $l_chip 5 1 I think these tools are broken. EDIT2: Okay, I think I figured this out thanks to Neil's spreadsheet up there. I noticed pin 3 is GPIOAO_5 and gpiochip0 is called AOBUS in /sys/class/gpio: chris@lepotato:~$ ls -l /sys/class/gpio/ total 0 --w------- 1 root root 4096 Jan 1 1970 export lrwxrwxrwx 1 root root 0 Jan 1 1970 gpiochip0 -> ../../devices/platform/soc/c8100000.aobus/c8100000.aobus:pinctrl@14/gpio/gpiochip0 lrwxrwxrwx 1 root root 0 Jan 1 1970 gpiochip10 -> ../../devices/platform/soc/c8834000.periphs/c8834000.periphs:pinctrl@4b0/gpio/gpiochip10 --w------- 1 root root 4096 Jan 1 1970 unexport So I tried switching my gpioset to use gpiochip0 and turning pin 5 off turned this off. I think I can work with this now. Thanks to Neil for providing that spreadsheet, that info seems good. Now trying to figure out how to control the pins on GPIOX on that spreadsheet. They don't map to the other chip from what I can tell. EDIT3: Just going to keep updating this post for my notes in case it's helpful to anyone, and if anyone has any suggestions they can chime in. I might have found my crash. I was doing a read loop on the pins of chip1, and apparently reading pin 53 triggers the filesystem to go read-only and everything goes bonkers with I/O errors after that, requiring pulling the power. chris@lepotato:~$ for i in {30..60}; do printf "$i: "; sudo gpioget $l_chip2 $i; done 30: 0 31: 0 32: 0 33: 0 34: 0 35: gpioget: error reading GPIO values: Device or resource busy 36: 0 37: 0 38: 0 39: 0 40: 0 41: 0 42: 1 43: 1 44: 0 45: 1 46: 1 47: 1 48: gpioget: error reading GPIO values: Device or resource busy 49: 1 50: 1 51: 1 52: 1 53: sudo: unable to write to /var/lib/sudo/ts/chris: Read-only file system 1 54: sudo: unable to open /var/lib/sudo/ts/chris: Read-only file system Eh, maybe not. I don't think the reads triggered it specifically, I tried reading those pins again after reboot and it was fine. This time, I triggered some kind of I/O issue up near pin 80? It finished the loop up to 80 and then wouldn't take any more input from my ssh session. Network completely shut off at that point, another hard reboot and I can't trigger the condition again manually. Weird. EDIT: Merging the info from Tido and Neil, I think I have it now. I'll try to make a new spreadsheet (yeah I know, another?) mapping the pins to libgpiod commands. Basically, I realized Tido's info was shifted by 10 from what was in gpioinfo. IE, 7J1 Pin8 is listed as gpio-101, but in gpioinfo it's 91. Thanks to both of y'all for this info. This is what I was looking for. And sorry for the super long multi-edits. I don't know what this forum's etiquette for that kind of thing is.