sbc_chrisb

Members
  • Content Count

    20
  • Joined

  • Last visited

  1. 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.
  2. 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.
  3. 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
  4. 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: R
  5. 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.
  6. 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.
  7. 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 fro
  8. 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 an
  9. 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.
  10. 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-81
  11. 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
  12. 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 u
  13. 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 b
  14. 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:
  15. 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