sfx2000

This was a bit of a buzz back in late Dec 2018, and things got kind of quiet after that... Rumour was that the SoC was the SocioNext SC2A11, which is a Japanese chipset (and from experience, Japanese chip vendors are very particular about who they work with)...

If you're thinking about the Raspberry Pi family of boards - no, Armbian's attention is focused elsewhere... There's a lot of reasons for this - but the takeaway is that Raspberry Pi has a vibrant ecosystem in their sandbox - and they've done a good job, and they don't need our help. If you have some other fruity-Pi board, there's a good chance that somebody might be working on it.

I always worry about Android kernels in any event - looking at AOSP vs the Android OEM closed stuff, drivers can be a real pain - so I basically discount it - nice for study perhaps, but Android is about as open as my closed fist. Android is heavily based on Linux (as is ChromeOS), but it's not Linux, except in the very narrow case - so it makes it a real challenge. (apologies to the AOSP and ChromiumOS teams, the work they do is good - sometimes just not useful) Anyways - with SoC vendors in general - I'd like to see mainline first, not as a second thought - when I get a BSP for an SoC, and it's likely old, so to bring it up to current - even simple things like UART can be abstracted into a vendor specific thing, and with many SoC's, it's not just the primary Application Processor (that might be open), but there is the underlying stuff that just is not cleanly documented... I've seen projects where you think you're running clean on a Cortex-something or other, but underneath, there is an ARM11 running all the IO, with a shim looking up into what the ARM11 things is an application - so one has to deal with abstracts - this is not good... If one is trying to get close to the metal - these Android based BSP's are very, very difficult to work with. Just my two cents.

There was something else in systemd that was stepping on ntpd (and likely chrony), ran into this actually on amd64 - look at journalctl....

Locks the filesystem, but it doesn't lock the board down - depends on what OP wants to do and how paranoid they might be. Come to think of it, for their case, could use both as belt and suspenders - doesn't do the code signing part however... I've seen platforms that lock things down so tight that they even require code-signing for binaries, bootloaders, and file systems.

yep - this board does seem to be similar to the Sunvell board - straight NAND there, so need to build a flash filesystem on it... One might hope -- http://linux-sunxi.org/FEL/USBBoot On the board - one would want to sort out the UART headers - seems there is a socket, so one should use a scope to sort them - then console output there would be quite helpful...

See above - yes, you can... Be mindful of systemd-timesyncd - you might want to disable that one if one is running chrony, ntpd, or ntpsec.

Might consider looking at SecureBoot That would be the first place to look - lock your board down there... And then start moving up the stack... sfx

Spent some time to sort out things... not a kernel issue... ended up being that systemctl rc.local.service was exiting based on a bad entry in rc.local that was calling dnsmasq as a systemd resource, and it failed. Since the rc.local.service fails, oled-start doesn't run Don't ask me how dnsmasq service ever got into my rc.local, along with an iptables-restore entry - as I don't recall... Might have been when I was trying to help one of our forum members out with AP mode stuff... I've never been the biggest fan of systemd - it is things like this where one can get nested items that make it hard to troubleshoot.

<snip for brevity>

4.19.63 - http://ix.io/1T68 If I recall, it broke on the 4.19 bump...

Could be - as once one gets into secure boot - one of the ARM chips I'm working on right now - it has a separate boot processor that is underneath the application space (e.g. Linux) - in my case, it's another core - ARM11 vs the ARMv7A that the OS runs on. There are OTP's and/or eFuses that are popped depending on the SoC, along with the stored keys. That's all I can say right now (forrest gump voice)

Should be in the upstream repo's... So use apt to purge ntp, and install chrony... chrony is a good solution. Folks might also want to look at ntpsec packages... sfx

In my experience with ARM - this is an undefined instruction exception Which means either a context issues - executing THUMB as ARM, or that Data is read as an instruction at a very low level. This is usually application code, and sometimes compiler option if over optimizing for the wrong CPU arch/model - which is usually fixed by a makefile option if using GCC... sfx

I think with Crypto - leave it to Pro's - people smarter than you or me - and I'm smart enough not to go into a tizzy over an academic exercise without a CVE attached to it. ChaCha might faster in SW than AES - but with most platforms, AES isn't really an issue - AMD64/aarch64 - not withstanding the mitigations resulting from things like Meltdown/Spectre, etc... And that's implementation - even there - it's arch differences across generations of cores and vendors, along with supporting compilers, source code... Playing around with Crypto is always a risk on the leading edge - and God does not roll dice on pseudorandom devices like CPU's and Software.