lanefu

Aha! the console wasn't in /etc/securetty (/dev/ttyMV0) victory! I'll kick off a WIP thread soon--once I get things a little more dialed in... armbian monitor seemed to work out of the box too

making progress... I can get the board's u-boot to boot armbian now.. I have some quirk where i'm not sure the root password is getting set during install_common().. when I try to login from the console it doesn't prompt for a password when i try to login as root. ...but i think it's my image.. gonna switch to a better build host in AWS instead of my Docker on top of NFS host

sweet the patch for mvebu you all linked to worked fine on mvebu64.... Image FS wasn't showing as valid. so gonna clean image caches etc. I'm building u-boot,but it's really a placebo for now. the espressobin comes with it's own u-boot fork installed on NOR

thanks Zador, Tkaiser.. that's a big help..... Will probably take me a bit to digest what the patches are doing, but that's part of the fun.

I don't think so..... telll me more please

I'm sooooo close to sharing a WIP for building armbiain for espressobin , but I'm having trouble getting armbian builder to use the file name for the kernel package deb. │ dpkg-deb: building package 'linux-headers-4.4.8-mvebu64' in '../linux-headers-4.4.8-mvebu64_5.27_arm64.deb'. │ │ dpkg-deb: building package 'linux-libc-dev' in '../linux-libc-dev_5.27_arm64.deb'. │ │ dpkg-deb: building package 'linux-image-4.4.8-mvebu64' in '../linux-image-4.4.8-mvebu64_5.27_arm64.deb'. │ │ dpkg-deb: building package 'linux-image-4.4.8-mvebu64-dbg' in '../linux-image-4.4.8-mvebu64-dbg_5.27_arm64.deb'. │ │ dpkg-genchanges: binary-only upload (no source code included) │ └──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘ dpkg-deb: error: failed to read archive '/root/output/debs/linux-image-mvebu64_5.27_arm64.deb': No such file or directory What's the cleanest way to have the resulting deb and armbianbuilder line up? Stuff I've done: made esspressobin.wip board config Made mvebu64 sources config Made mvebu64 Kernel config Made kernel patch to elminate the localversion file assured VERSION_AUTO is disabled in kernel config Files n stuff esspressobin.wip mvebu64.conf

Did you build the image with a VM or a container?

It's a quirk with systemd... I had the same problem... _netdev doesn't work either.. Switch to systemd automounter and it'll magically work when you access it.. diskstation:/volume6/linuxmirror /mnt/linuxmirror nfs defaults,x-systemd.automount 0 0

I use mainline on several boards and run them 24/7. Unless you're planning on using software raid for several drives and really hammering all the cores for long period of time you have nothing to worry about--- If you are worried plop a 5 volt fan on the headers and rock n roll.

that'll work too!

I'm tinkering with image building via docker again.. I was curious if you have made any improvements to the process..and was curious about your app building

Might need to create a new index or indexes (maybe just drop and recreate existing?) on armcore_sessions containing id, running_time, login_type, member_id, running_time. What indexes exist currently?

Try building the appropriate python lib linked in the resources section at the top of this post.. then read the official pya20 dox and see if you win. https://pypi.python.org/pypi/pyA20 I *think* they're just bitbanging spi on that lib but not sure.

ill have to dig through my notes to show you.... at this point im uninspired to persue wiringOP because it just has so much junk in it. I see why werecat threw a fit on the orangepi forums a while back. so ill slowly start chasing the python route. someone forked pya20 specifally for the zero.... i updated the first post of this thread and added it as a resource. i did a quick test with onboard led and it seemed to work anyway i think pursuing an autodetecting pya20.gpio fork is the most straightforward path. Tapatalk thinks its important to tell you im using tapatalk from a phone.

Holy cow.. I had no idea how ugly the wiringpi C library really is... it's really ugly.. not that I know what I'm doing--but It's ugly.

Follow the build process. If you aren't able to do it, you may not be ready to work with mainline and docker.

hi. the appropriate way is to use the armbian build tools and build your own opi 2e image with the mainline kernel. the armbian tools make it pretty easy, but still a bit of effort. i highly recommend using ubuntu xenial over jessie... the docker version is much more current. ive been running docker on my 2e from an imade i made months ago and its been pretty stable. my reverse proxy is running as a container on a 2e full time. i even built x264 zoneminder as a container with success Tapatalk thinks its important to tell you im using tapatalk from a phone.

Forreal...You don't have a zero yet? What a bummer... So definitions n stuff are usually in .h files for the .c files to use.. so may wanna poke there

I'm gonna make you help me....Fork my repo and see if you can identify the Pin Mapping code and we'll try to get this going

okay so focus on WiringOP..... thanks....

sorry I kinda fell off the face of the earth and dropped the ball. I'm still torn about what's more desirable.. a robust wiringpi port or just a healthy pyA20

Well for the sake of time i ended up doing a GPIO project on a Pi A+ with rpi.gpio.... it was pretty easy to use. so uhm lets see what the thoughts are for scope. try to get this to support h2 and h3 boards by using some autodection for https://github.com/duxingkei33/orangepi_PC_gpio_pyH3/tree/master/pyA20/gpio ?

So what replaces the suxi-gpio module? the generic gpio sysfs stuff?

Hmm I'm so torn now.... the python minimum viable solution is appealing for most mortals and I would figure C nerds are just going to do what they're going to do regardless--but these guys have interrupt support working now for the C stuff, so I guess there is a bit of polish going on Especially now that I've realized Zhaolei's WiringOP is more maintained that I originally thought.... https://github.com/zhaolei/WiringOP/commits/h3

I traced through the Pi Zero Schematics and mapped the 26 pins to their AllWinner ID/function 1 - 3.3v 3 - PA12 (TWI0_SDA/DI_RX/PA_EINT12) 5 - PA11 (TWI0_SCK/DI_TX/PA_EINT11) 7 - PA6 (SIM_PWREN/PWM1/PA_EINT6) 9 - GND 11 - PA1 (UART2_RX/JTAG_CK0/PA_EINT1) [IO-0] 13 - PA0 (UART2_TX/JTAG_MS0/PA_EINT0) [IO-2] 15 - PA3 (UART2_CTS/JTAG_DI0/PA_EINT3) [IO-3] 17 - 3.3v 19 - PA15 (SPI1_MOSI/UART3_RTS/PA_EINT15) 21 - PA16 (SPI1_MISO/UART3_CTS/PA_EINT16) 23 - PA14 (SPI1_CLK/UART3_RX/PA_EINT14) 25 - GND 2 - 5v 4 - 5v 6 - GND 8 - PG6 (UART1_TX/PG_EINT6) 10 - PG7 (UART1_RX/PG_EINT7) 12 - PA7 (SIM_CLK/PA_EINT7) [IO-1] 14 - GND 16 - PA19 (PCM0_CLK/TWI1_SDA/PA_EINT19) [IO-4] 18 - PA18 (PCM0_SYNC/TWI1_SCK/PA_EINT18) [IO-5] 20 - GND 22 - PA2 (UART2_RTS/JTAG_DO0/PA_EINT2) [IO-6] 24 - PA13 (SPI1_CS/UART3_TX/PA_EINT13) 26 - PA10 (SIM_DET/PA_EINT10) So according to the FEX there's like 2 GPIO Pins enabled by default? Pin12(PA7) and Pin26(PA10)? [gpio_para] gpio_used = 0 gpio_num = 2 gpio_pin_1 = port:PA07<1><default><default><0> gpio_pin_2 = port:PA10<1><default><default><0>