sfx2000

Members
  • Content Count

    410
  • Joined

  • Last visited

1 Follower

About sfx2000

  • Rank
    Embedded member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. And to that end, the current sbc-bench is going to favor the big.LITTLE chips, and may not reflect performance in other use cases. Comparing Jetson Nano to other SBC's that might be doing AI oriented stuff - again, consider the ecosystem, and where nVidia is positioning this part, and that is consistency across their product stack - and this was related to me from a friend that does Jetson development - he was pretty happy that Jetson Nano was around, as this is business for him...
  2. nVidia doesn't expose the A53's directly, it's all under the hood - cluster migration is their strategy - and this in many ways makes sense, but one is dependent on nVidia's firmware/hardware to make the right choice to move load over... Pretty much similar to Pixel-C or Shield... It's an either/or, not an "and" where all cores, big or LITTLE are available. In many ways, TX1 isn't that much different than Broadcom's VC4 - it's a GPU with ARM's attached, not the other way around - and that's ok, and makes sense with the rest of the nVida platforms, where the Nano allows for small/medium/large (Nano, TX2, Xavier) and have scalable consistency in what they're trying to do. Which is obviously a different approach than the China chips...
  3. EspressoBIN seems to be a decent fit to your asks..
  4. If it's really a Gobi, then consider libqmi/libmbim and modemmanger - they're in the upstream repos... and there's a PPA as well... https://launchpad.net/~aleksander-m/+archive/ubuntu/modemmanager-bionic Might work out of the box there - modemmanager is pretty cool, abstracts out a lot of the lower level stuff... That should get Gobi working as a modem - for GNSS oriented stuff, better to go with a GPS module like the uBlox Neo-6/7/8 modules, they're great for navigation and timing stuff, and they typically will interface with UART rather than USB
  5. Different strokes maybe - I like it because they do tend to keep current within the platforms they support, and onboarding a new platform is fairly straight forward - and sometimes less work than going from metal to buildroot and then to yocto... Please don't throw stones at another distro, it's bad form - OpenWRT is as much of a "real linux" as any other distro, different focus perhaps, and one tightly focused towards networking and wireless (not just WiFi these days). Fair enough - but cross platform support for MIPS/ARM/x86 counts for a lot - and it is considered more of an embedded linux platform... QC-Atheros IPQ4019 is a Quad A7, similar to AllWinner H3, and does nicely in 128MB RAM/32MB SPI-NOR, and has a working dual-band WiFi5 (802.11ac AC1200 class) stack, and plenty of bandwidth - and a working VPN platform (including Wireguard) - I don't recall Armbian actually having a working UBI/UBIFS over MTD on NAND or NOR flash, and recent experience with EspressoBIN, OpenWRT seems to have a better solution with networking and system stability. I've spent the last 10 weeks on OpenWRT with a MIPS24Kc based platform on a fairly small footprint (64/16) - again, my image is about 7MB, give or take, and I use about 28MB of RAM (some of that is due to glib2, which is a real pig, but it offers a lot in exchange) - during that time, I've had to dive deep into the internals, including their toolchain, etc, and I've come to respect much of what the OpenWRT/LEDE team has accomplished. It's allowed me to focus on what's important with the project, and they've sorted out 90 percent of things that I don't need to worry about. Anyways - 64MB, with Embedded Linux, is more than enough space to get a decent performing platform... Something like an "Armbian Lite" - with Busybox, maybe a smaller C Library like MUSL, and a stripped down kernel - almost sounds like Alpine Linux, wouldn't you agree?
  6. Don't go there - OpenWRT can be very efficient, but it's not a full flavored desktop class linux... and MHz doesn't matter as much as one would think with MCU's in this class - start pushing packets through the platform, and there's where OpenWRT starts to show it's strength.
  7. Conversely - if one is running ntpd, systemd-timesyncd can cause a lot of trouble here... Above is a great post - and some things to add maybe... GPS without PPS is an ok time source for NTP, if nothing else is available via the network - but it's precision only goes so far, and if the GPS is over USB, this adds more jitter... NOHZ is perhaps one approach, esp. with a CPU that does DVFS, and setting the scheduler appropriately to get some timing stability overall - not withstanding the long jumps that A64 seems to do, which is another issue, as NTP assumes that the system timing is somewhat stable. hint - if one is looking for a stable Stratum 1 NTP - check out google Public NTP, as this is what's keeping their global cloud in sync, and there it pays to also use google DNS for the resolver. This is likely good enough for most folks, and if one uses GPS over gpsd on the shm, that should be the preferred, and then time1/time2/time3/time4.google.com, and maybe consider the local clock, should get to a stable NTP. To get really stable local time - one is not going to get stratum 0 on an SBC, period, even with GPS and PPS... most of these cheap SBC's use an XO with 30 to 50 PPM accuracy (this is a 50 cent chip) - this is good enough for ethernet and WIFi - I'm looking a part that is 50 ppb, which would normally be an OCXO (spendy), but this part is a MEMS device, and so far the data I've seen looks pretty good over time.
  8. I don't have a pinebook, so not sure if this is helpful... someone should give it a try... GETTING A VIRTUAL TERMINAL Linux provides six virtual consoles (text-based command-line interfaces). Simultaneously, pressing the Control (Ctrl) and Alternate (Alt) keys with any of the functions keys from F1 through F6. For example, press Ctrl-Alt-F1. Return to the graphics screen by pressing Ctrl-Alt-F7.
  9. FWIW - here's a write up I did a couple of years back - useful for getting full use of snmp/snmpd... ===== SNMP ===== SNMP is a server/agent architecture - the agent runs on the target machines, and the service is run on the server - so we do both. NOTE - this is optional - only needed if one wants to do cacti or other SNMP related apps - if you don't need this, you can skip it NOTE 2 - we're covering SNMP v1/v2 - SNMP v3 includes some auth options that are handy to have, but generally in a local area network, they're 'extra credit' as many clients do not support it, and we're keeping things simple in this series. Good overview here - https://en.wikipedia.org/wiki/Simple_Network_Management_Protocol The config files * **snmpd.conf** - configures the agent and servers * **snmp.conf** - configures the server only **Install SNMP** sudo apt install snmp go to /etc/snmp and comment out the following line like this - this allows you to import MIB's sudo nano /etc/snmp/snmp.conf # As the snmp packages come without MIB files due to license reasons, loading # of MIBs is disabled by default. If you added the MIBs you can reenable # loading them by commenting out the following line. mibs : comment out the mibs line like below #mibs : Now run the mibs-downloader sudo apt install snmp-mibs-downloader done for server-side - smpd is optional for the server, but if you want to collect stats on localhost you'll need a configured SNMP Agent **SNMP Agent** To install the agent on a debian/ubuntu based machine sudo apt install snmpd For other platforms, check their documentation - Windows does support SNMP, but it needs to be turned on, same with Macs, QNAP/Synology NAS boxes are good, HP OfficeJet tends to have it enabled with 'public' community (not all do), some consumer routers also have SNMP agents (AsusWRT-RMerlin, as least in the builds I checked in his github). Many managed switches (smart switches) also have SNMP agents On linux - The agent config as shipped is very thorough, however, we can make it really simple... sudo mv /etc/snmp/snmpd.conf /etc/snmp/snmpd.conf.orig Now create a new one sudo nano /etc/snmp/snmpd.conf Only one line needs to be there, but you can add a couple of informative ones as needed - what we're doing here on the agent side is create a read-only SNMP community, naming it "public" and limiting scope to the local area network (in CIDR notation) rocommunity public 192.168.1.0/24 # syslocation "testLab" # syscontact gmailuser@gmail.com One more file to change - comment out the export MIBS line and save sudo nano /etc/default/snmpd <code> # This file controls the activity of snmpd # Don't load any MIBs by default. # You might comment this lines once you have the MIBs downloaded. # export MIBS= # snmpd control (yes means start daemon). SNMPDRUN=yes # snmpd options (use syslog, close stdin/out/err). SNMPDOPTS='-Lsd -Lf /dev/null -u snmp -g snmp -I -smux,mteTrigger,mteTriggerConf -p /run/snmpd.pid' </code> save the file and start/restart snmpd sudo service snmpd restart to test, do an snmpwalk against the local ip sudo snmpwalk -c public -v1 192.168.1.6 You should get a lot of information back, or the connection will timeout (e.g. either wrong community, or the agent isn't running/answering up)
  10. I would agree - the MediaTek/Ralink drivers are ok for client (STA) operations, but even there, they're a bit spooky. Not just for Armbian, but Linux in general - great adapters for Windows perhaps. Realtek 11 b/g/n generally work, and I'm rather partial to the Atheros ath9K chipsets, as they're fairly open, and do a good job across all WiFi modes.
  11. That's a cute little board - and perhaps something useful considering the form-factor and utility - the ESP32 community is pretty strong, and I think this is perhaps needed. Getting back to more Linux oriented platforms - Linux on MIPS24k runs nicely in 64MB of DDR2, with 16MB of SPI-NOR - I've got a performant AR9331 build running on OpenWRT with full 4g-modem support in less than 8MB image size... sfx@blaster:~/builds/openwrt/bin/targets/ar71xx/generic$ ll total 28384 -rw-r--r-- 1 sfx sfx 2806 May 26 13:51 config.seed -rw-r--r-- 1 sfx sfx 4560 May 26 13:52 openwrt-ar71xx-generic-device-gl-ar150.manifest -rw-r--r-- 1 sfx sfx 7536644 May 26 13:52 openwrt-ar71xx-generic-gl-ar150-squashfs-sysupgrade.bin -rw-r--r-- 1 sfx sfx 6160384 May 26 13:52 openwrt-ar71xx-generic-root.squashfs -rw-r--r-- 1 sfx sfx 1621878 May 26 13:52 openwrt-ar71xx-generic-uImage-lzma.bin -rwxr-xr-x 1 sfx sfx 5219948 May 26 13:52 openwrt-ar71xx-generic-vmlinux.bin -rwxr-xr-x 1 sfx sfx 5225072 May 26 13:52 openwrt-ar71xx-generic-vmlinux.elf -rw-r--r-- 1 sfx sfx 1638400 May 26 13:52 openwrt-ar71xx-generic-vmlinux.lzma -rwxr-xr-x 1 sfx sfx 1632000 May 26 13:52 openwrt-ar71xx-generic-vmlinux-lzma.elf drwxr-xr-x 2 sfx sfx 4096 May 26 13:52 packages -rw-r--r-- 1 sfx sfx 932 May 26 13:52 sha256sums So it can be done... Armbian is a full-featured Linux, and that pulls in a lot of baggage - something more like Alpine where a small clib and busybox to replace things - this could fit nicely inside the resources for V3 or RK3308... Armbian-Lite - which might have additional utility as an image for Docker/VM's for higher power SBC's in a cloud scale kind of thing. The MIPS based dingleberry-pi will have to wait, or someone else will have to push it forward with AR9331 in a Pi/SBC form factor - long story there. sfx
  12. In some ways, I think Jetson is similar to the BCM20xx series on Pi - the GPU runs the house, not the ARM's, they're just the guests of the GPU... which makes sense, as the GPU is the driver for memory bandwidth. There's a Cortex-A7 on Jetson that runs power management, and it works alongside the HW PMIC, which is where J40 breaks out for things... Anyways - review the L4T docs, along with the Jetson TX1 developer documents. https://docs.nvidia.com/jetson/l4t/index.html#page/Tegra%20Linux%20Driver%20Package%20Development%20Guide%2Fintroduction.html%23
  13. Interesting question - what's the use case that is being handled here? With RPi - keep in mind that the ARM's and Linux run as a guest device to VC4 and Threadx, and VC4 controls the GPIO bus, not the ARM(s) - so what happens on RPi, might not be consistent with other boards that break out the 40-pin interface. Look at J40 on the Jetson carrier board... as indicated in the Jetson Nano User Guide Hope this helps... sfx
  14. It's not available in the Ubuntu AMD64 repos either... As suggested, you'll have to sync up to the git src and build it yourself (or find a local freelancer if needed) - as this project chases a moving bus with dependencies on the version of Chrome itself (which is constantly changing), this would be a bit maintenance intensive...