Rob this is what I have so far. It's possible that in the back and forth I'm doing I've either missed noting a change or done unnecessary steps etc. Builds and compiles are still a thing that I'm not understanding to my satisfaction.
I will at some point recreate the original file and do a diff between it and what I'm running.
My build has been for a while stalling the box during the build of kstars so I'm still working away.
kstars seemed to be failing earlier on because of the dependency of stellarsolver on the qt5 pieces. I tried installing stellarsolver and later added the qt installs, kstars seems to get further but then began hitting the lock up issue.
zram service is failing but I've not looked into that yet.
I was seeing errors at one point when I reran the script with a permission error
I'm kicking off setupDebianSBC.sh from a wrapper script and think I'm capturing all the output to a log (happy to take advice if there is a better way of doing that).
sudo ./setupDebianSBC.sh 2>&1 | tee setupDebianSBC.log
I've added the following into my local copy at about line 60 to install items that appear to have shown up as missing (and included notes where changes have been made elsewhere). Some may have been optional but I'm trying to be able to build as much as possible.
BTW I also added an " @ $(date)" into the display routine to help me identify when things have really locked up.
############# My Addons
display "Running Bob Stephens add ons."
# libwxgtk3.0-dev has been renamed to libwxgtk3.0-gtk3-dev (PHD2 install)
# Changed the call from git to https at git clone anongit.kde.org/kstars
# installs that didn't look like they needed to be done in place.
sudo apt -y install libkf5doctools-dev libkf5texteditor-dev libkf5kdelibs4support-dev
sudo apt -y install kdoctools5
sudo apt -y install libgtest-dev
sudo apt -y install libgmock-dev
sudo apt -y install oggfwd
sudo apt -y install libtheora-dev
# qt is used by the stellarsolver install and had issues in this build
sudo apt install qtbase5-dev qtchooser qt5-qmake qtbase5-dev-tools
I have a mostly configured controller using a mix of Rob's script and some manual work. It's hooked up to my mount, focuser and two ZWO cameras and being accessed via realVNC Viewer from inside the house. I used the X11VNC Server which Rob's script sets up nicely. Weather is still mostly cloudy here at the moment so no actual Astrophotography work has been done yet.
My attempts to build both Kstars and phd2 were locking up the box for some reason once I got past some prerequisite installs.
I did a "sudo apt install kstars" and that appeared to get me to the point of having a functional Observatory control box. I wasn't able to install phd2 as it wanted a newer version of a library than was readily available. I use the built in guider so PHD2 was just to see what worked. I may revisit that at some point for the learning exercise.
The Uitilty scripts are not available for some reason, I was looking forward to some automation on the fixing of names for USB serial devices.
So far the T95 max boxes look like they could do the job in a pinch but have been difficult to get the install setup on and other's have pointed to some more powerful alternatives which may be better suited as an alternative to Raspberry Pi's.
I think my lockup issues were memory related. I used the steps in Rob's file to add swap space and am running the System Monitoring Center (chewing extra resources but it's interesting). The build has run a lot further than previous attempts. I think this is a case of letting it run and see what tomorrow brings.
I was just looking at that board last night. Looks nice. The CPU isn't quite as fast or have as many cores as the ODroid-N2+, but it has native m.2 and twice as much RAM, so that makes up for it.
Keep in mind I don't think it has built-in WiFi, so you'll need to get a USB WiFi dongle. HardKernel (the makers of ODroid) sell one that is known to work without needing to do anything special with drivers, so I just ordered that at the same time I ordered the ODroid.
I liked the Sata port as well. I may not use it but having it there might be useful in the future. I skipped the WiFi dongle as I'm expecting to be wired for observatory (and away from home) use. I may regret that but by the time I paid shipping and dealt with the exchange rate it was adding up. Threw some extra on 64GB eMMc storage though.
Rob as an FYI I've used your setupUbuntuSBC.sh script to do the setup on the ODROID M1. It seemed to run pretty well. I'm having an issue with a package upgrade but that is not related to your stuff. No real life observatory control as yet but solves ran nicely. I don't seem to have icons in the Ekos control buttons (I've seen that often but have not quite worked out what it is caused by).
Thanks again for your work in setting those scripts up.
Kevin it looks like you have done a bit with the ODROID GPIO's I've found the pinout for mine and am having a look at making an expansion board to incorporate Dew Heater Control (my old arduino version is documented at www.iceinspace.com.au/63-597-0-0-1-0.html ) and possibly a couple of stepper controllers for Focuser and longer term a rotator. I'm not happy that I understand the limitations (if any) on the GPIO's. I got a surprise as I dug into the GPIO's on the ESP32's and realized how many of them were not really usable for my purposes due to special requirements at boot. So afr I've not found anything for the ODROID that has me convinced that I understand limitations.
I'm thinking of starting a discussion on GPIO usage/resources but trying to workout where it would fit. I found your earlier Waveshare topic but I'm not thinking of just Focusers and Filter Wheels. Thoughts?
Yeah as you can see in my 3D model I'm using a Waveshare stepper motor HAT, using the driver I wrote. The hardware pinouts are compatible with the Raspberry Pi 40-pin header, even though addressing the GPIOs are different (different numbering scheme).
So far the only GPIOs I've used are the ones used by the Waveshare HAT for the two motors, in digital output mode.
On the Rock Pi (which also has a compatible 40-pin header, but also with different numbering scheme), I had to disable an i2s kernel module, because it was conflicting with the GPIO. I've had no such problems on my ODroid N2+ though.
My V1 of a HAT for the M1. I'm expecting some revisions will be required (especially tweaking trace widths) but am away soon for a bit so figured I'd get some boards made and test the basics with it.
Slightly wider than the M1 board which is not ideal. It has a 4 channel dew heater control and stepper drivers for a focuser and rotator on board. I could easily remove 2 dew heater channels for my use and retrieve some width in the board but for now it's mostly a learning exercise rather than an attempt to get the final board. I'd not opto isolated the FET circuits in the original Android version of this but have added it this time.
Not tried with this version but I have pondered putting some components upside down to see if a simplified version would fit in the official case with access via the back.
I have not done PCP mounted sockets for the 12V supply or I2C bus at this stage. I2C to talk to a Temp/Humidity sensor to measure ambient conditions. Headers on the board for both currently but version 2 will probably do that differently. I hope there are no I2C or 1-wire conflicts with the M1, I use both, Dallas 1-wire temp sensors under the heater straps to try and track heating.