What you see is our improved REV.B of A64-OLinuXino. What’s new:
- Gigabit PHY is now KSZ9031 from MICROCHIP/MICREL which allow board to be produced in both commercial and industrial grade!
- DDR3 is now DDR3L for lower power
- we add SPI flash footprint U12
- Audio input now is jumper selectable between LINE-IN and MIC-IN
- eMMC now can work on software selectable voltage 3.3V or 1.8V which would allow faster speeds
- status LED is attached to port PE17
- size 90×60 mm
Now we do final software tests and if everything is OK we will run production.
olimex 
Sep 01, 2016 @ 11:36:06
Great!
Any plans for a version without eMMC?
Expected price range?
Sep 01, 2016 @ 13:26:03
Since Olimex listened to linux-sunxi community (thanks!) and added SPI flash on the bottom of the PCB to boot from a cost-down variant without eMMC could be the only reason. Netbooting sunxi boards without SD card, NAND or eMMC becomes reality 🙂
Sep 01, 2016 @ 14:31:32
thomas e-mail me as your domain seems down and my e-mail bounce back 🙂
Sep 01, 2016 @ 15:51:21
We put the SPI Flash just to proof the concept, I doubt many people would use this board to boot remotely, but it’s just additional option.
I think where this board will shine among other A64 boards is the possibility for indstrial -40+85C operating temperatures (this is why we use Micrel PHY which cost x3 times the Realtek) and the possibility to use the eMMC with the dual voltage at much higher speeds, so removing the eMMC will just cripple it. Who needs low cost has plenty of toy alternatives 🙂
Sep 01, 2016 @ 16:26:10
Yes, the dedicated eMMC boot partition is expected to cover the same functionality as the SPI flash, but some software support is needed to make the firmware easily upgradable from the FEL mode via the sunxi-fel tool. Still, unlike EEPROM, the SPI flash can be safely probed from the bootloader in a generic way (because the boot ROM does the same) and be used as a generic device-independent data storage. This storage can be potentially used for the MAC address, the device tree blob and other things. But nothing is certain and this still needs to be investigated.
If a cost reduced board variant without eMMC ever comes out (targeting the same price range as the Pine64), the SPI flash can be used to boot from network or from a USB hard drive without any need to use a bootable SD card.
Sep 07, 2016 @ 05:13:23
Does it brings any advantages? These days SD cards are fairly cheap and have a decent capacity. Not to mention MMC card could do everything SPI NOR could do like just launching boot loader and doing net boot.
On side note I also failed to get point of mumblings about “security” crap of SPI flashes on Sunxi wiki. Why the hell these guys can’t wire-strap WP# pin to disable writes and filling wiki with some oddball crap about “security”? No software could fiddle with WP# but user could easily change its state using e.g. switch. So boot loader could be locked read-only once tested and could enforce e.g. secureboot-like schemes if desired, where only true machine owner could decide what to boot, etc.
Sep 07, 2016 @ 06:05:03
> Does it brings any advantages? These days SD cards are fairly cheap and have a decent capacity. Not to mention MMC card could do everything SPI NOR could do like just launching boot loader and doing net boot.
Have you actually read the wiki page? The advantages are explained in the very beginning. A certain fraction of users are not very smart. Some of them will try to run the board without any SD card inserted at all and complain that the board is defective because “there is nothing on the monitor”. Some of them will just format the SD card using FAT file system and simply copy the SD card image file on it, then complain that the board is defective. Some of them will download the SD card image for a wrong board model and get a non-bootable system… Well, you should get the idea. And these are only a few example. Real users tend to be very creative with with finding new ways to shoot themselves in the foot 🙂
But if the board has a factory installed firmware already available in the SPI NOR flash, then users get PC BIOS alike functionality out of the box. The firmware can warn the user about a missing SD card and/or about missing a usable OS on the SD card. And maybe even help the user to automatically format an empty SD card and go to the Internet to download something like a Debian distro. It is possible to implement something that even a grandma can use!
Regarding the cost. If I understand it correctly, an SPI NOR flash chip is less expensive than an SD card. And the size does not matter as long as it is large enough to store the firmware. Also some people don’t quite like SD cards because the contacts in the slot may become oxidized or contaminated with dust/grease (I remember having seen comments about it in this olimex blog). One may also sometimes want to use the SD card slot as a card reader and insert/remove SD cards at runtime. There are plenty of different use cases. Of course I understand that many people got used to and are perfectly happy running their OS and their bootloader from a permanently inserted SD card. And it’s fine, as long as they are not too aggressive when advocating their way of using devboards.
If you think that the https://linux-sunxi.org/Bootable_SPI_flash wiki page is not very clear and is difficult to understand, feel free to help by editing it.
Sep 07, 2016 @ 06:23:00
> Why the hell these guys can’t wire-strap WP# pin to disable writes and filling wiki with some oddball crap about “security”? No software could fiddle with WP# but user could easily change its state using e.g. switch.
Again, we have a very different interpretation of what is “easy”. The wiki page explains that there is a possible use case when somebody might want to upgrade the firmware from a running system without resorting to a somewhat more cumbersome recovery procedure. I’m reminding you that one needs a PC/laptop (or another devboard) and a USB cable, then switch the board into FEL mode and run the sunxi-fel tool (ok, we may want to make a nice GUI frontend for it later). Can a grandma easily do this? With your suggestion, there will be always a non-negligible fraction of users running an old version of the firmware. And now imagine that there is an important firmware bugfix, which needs to be rolled out…
And by the way, the wiki page does not forbid you to have an extra write protection hardware switch. Everything is up to the devboard designers.
Sep 14, 2016 @ 09:28:02
> Have you actually read the wiki page? The advantages are explained in the very beginning.
IMHO, this part of sunxi wiki looks like personal opinions/preferences. I do not consider it trustworthy. Justifications why it is a “problem” is IMHO quite weak. Someone have to write SD? Someone have to write SPI/eMMC/NAND as well. I really do not get how they’re different.
> A certain fraction of users are not very smart.
These aren’t Olimex target audience I guess. Furthermore, they could just buy laptop/tablet with preinstalled OS. It gives best user experience. At cost of being unsuitable for custom applications. Unlike SBCs and modules.
Btw, Olimex sells pre-flashed cards ;). I could also swear I’ve seen some sunxi boards with onboard NAND coming with pre-flashed adnroid, etc. IMHO full android or linux pre-flashed is far more meaningful for dummies anyway.
> then users get PC BIOS alike functionality out of the box.
IMHO, PC bios is worst thing about PCs. PCs only provide good UX when you buy it with OS preinstalled and only use it as desktop. If you want to install non-default OS, it could be bumpy ride, esp. with “secure” boot crap (which proven to be not secure at all), all these UEFI bugs and so on. This foul road gone as far as mere OS reinstall could perma-brick some laptops. Twice as bad in embedded.
Sunxi uboot isn’t much better. I have to patch it to use in my embedded systems. It outsmarts itself. Its boot time is awful, uboot accounts ~30% of boot time of my devices! It fiddles with usb/sata. This introduces dozens of stupid failure modes where it lockups or misdetects boot target. Watchdog never kicks in either. Great. And there is nobody on site to reboot device or press a key in fuk’ng uboot prompt. I failed to find civilized ways like menuconfig to make it non-interactive and pike off. I’ve got my hands dirty and patched sunxi support code. Sorry if this sounds harsh but I had some misbooted devices where WD never fired, so there were unhappy customers. So I had two days of grinding through uboot code understanding how could I adjust boot env. Eventually figuring I have to actually patch sunxi support code/headers. Btw, Sunxi is the only freakin’ arch which dares to enforce usb support with no means to disable it via menuconfig. Fortunately uboot is GPLed, so I could at least patch this myself. On PCs with blob-only BIOS stuff like this going to be 100% showstopper for embedded applications and somesuch. Those trying to use PCs for embedded/automations eventually find their crap hanging in some prompt asking for something. While there could be no even keyboard to press that damn key in first place. Ever seen kbd on, say, some kiosk? Or some networked appliance? Some telemetry gateway? It not to be taken as granted there is serial or LCD attached either. Unfortunately sunxi ppl seems to ignore this.
> Regarding the cost. If I understand it correctly, an SPI NOR flash chip is less expensive than an SD card.
OTOH when it comes to UX, SD card, NAND or eMMC allows one to (pre)flash whole system. It gives far more meaningful UX for newbies, isn’t it?
As for card reader: valid point! Though Sunxi usually supports more than 1 MMC, best option is probably to have e.g. 2 slots. Or boot eMMC + “data” SD, etc. Since firmware is dumb, it is unlikely ppl would use it as OS. OS would be booted most of time. Once OS booted, removing card is fatal unless OS image built special, all-in-RAM way. While it is possible to do all-RAM-based OS, it brings plenty of drawbacks. So I do not get how firmware could fully address card removal woes. SPI NOR is too small to contain full OS (except something like OpenWRT). So at best it solves only some corner cases.
> feel free to help by editing it.
Valid point. But I’m not sure it is good idea to rush into some article and challenge half of statements. It probably subject for discussion or so?
Sep 14, 2016 @ 09:49:11
As for security:
– Either SW could change “root of trust” part (e.g. boot loader with root signing key).
– Or HW enforces R/O and there is no way to do that. So SW is out of luck.
My point is: if software could do something on user request, there is always change it would do that on its own. If hacker hijacks system and gets root, he could assume e.g. full control over spi controller and rest of SoC. Doing anything SoC & surrounding HW technically capable of. External HW could partially help, e.g. I’ve seen some “smart” (parallel) NOR flashes capable of demanding “password” to unlock write to certain sectors and password was changeable, so it possible to lock-out writes to boot most of time and still update it but attackers could potentially steal that password and it is hard to do that. Not sure if SPI NOR flashes implement tricks like this.
Still, SW can’t flip HW switch, preventing write on HW layer. WP# is WP#, it protects device from writes. Malicious/unintentional write would fail. Furthermore, once boot is operational and tested, it is unwise to fiddle with it. Especially for “not so smart” users. So I think actually setting switch to R/O by default would save users from plenty of woes regarding “erased boot loader” situations :). While those who knows what they’re doing would have no issues to flip the switch.
And by even then, sunxi ROM prefers SD card over SPI. So if user dares to use SD card in boot slot, attacker could always inject own boot image to that card, it would take precedence over readonly SPI thing. Reboot. Boo-hoo, root of trust takeover complete. IIRC some SD and esp. eMMC cards could be set R/O as well, but its one-time thing. Once card is RO, it would stay RO forever. Since it done by commands, rather than by HW switch and no command could undo permanent readonly (it would jeopardize whole idea anyway) – there is no way to flip switch at all. Security is tricky bitch. Uhm, yeah, “true” mmc host gives a bit more fun. And a bit more hazards. Attackers could have quite some lulz feeding cards with fairly destructive/irreversible commands.
What is even more worrysome: eFuses. These are poorly documented but I suspect clueless blowing of fuses could cause ROM-level secure boot to activate. Ironically, only attacker would know secure boot key. Or even nobody. Nice way to sabotage someone’s else HW, isn’t it? IIRC eFuses cell got own programming voltage supply, and I think safest option either not to connect that at all to prevent programming eFuses or connect it via jumper and place it to R/O position by default. I guess this way it is possible to perma-brick boards by kicking in ROMed secure boot. Though I never seen any Sunxi device with secure boot activated and datasheet is really brief on this topic. So I do not know how exactly Sunxi implemends secure boot (things like A10/A20 probably unable to do it, but more recent parts got larger roms, new sets of fuses so it suggest they maybe could do ROM-level secureboot based on what fuses contain, like some other ICs do that).a
Sep 22, 2016 @ 12:24:17
To LinuxUser:
> IMHO, this part of sunxi wiki looks like personal opinions/preferences. I do not consider it trustworthy.
I can say exactly the same about your comments 😉 However the linux-sunxi wiki page is strictly focused on practical aspects and provides a usable solution, which works here and now (well, if you have a board with SPI flash). At least the core functionality is already there. The bells and whistles can be added later.
> Someone have to write SPI/eMMC/NAND as well. I really do not get how they’re different.
SPI/eMMC/NAND are generally non-removable. But the SD card is. It makes a huge difference in reducing the chance of a user error. Also please have a look at https://patchwork.ozlabs.org/patch/629172/
> Btw, Olimex sells pre-flashed cards😉.
I have already explained this in my previous comment. The user just may buy a wrong SD card from the Olimex web shop (ex. an A10-LIME card instead of an A20-LIME) and run into exactly the same problem as downloading a wrong SD card image.
> I could also swear I’ve seen some sunxi boards with onboard NAND coming with pre-flashed adnroid, etc. IMHO full android or linux pre-flashed is far more meaningful for dummies anyway.
How is the firmware asking the user “Hey, please provide me with some Internet connectivity (plug an Ethernet cable) and I will download the latest *upstream* Debian ARM distribution and write it to your SD card” less meaningful? Moreover, when (not if) the user finally messes up the pre-installed Android or Linux, being able to *easily* reinstall the system may be useful.
> Once OS booted, removing card is fatal unless OS image built special, all-in-RAM way. While it is possible to do all-RAM-based OS, it brings plenty of drawbacks. So I do not get how firmware could fully address card removal woes. SPI NOR is too small to contain full OS (except something like OpenWRT). So at best it solves only some corner cases.
Yeah, the corner cases such as booting the OS from a USB stick. Or booting it from a SATA hard drive, if we are talking about other SoCs too. I agree that booting over Ethernet has only a somewhat niche use, but it may be useful in some configurations too.
And you apparently have totally missed the point about eventually having a *generic* ARM Linux distribution on your SD card. Which you can move between different board models and it still works. This is something that you have on desktop PCs (in the form of LiveCDs), but not on ARM development boards. We are not quite there yet, but isolating all the board-specific bits into a firmware and putting it into a small non-removable on-board storage can solve the problem.
Sep 22, 2016 @ 15:36:01
For much of this conversation, I must repeat my earlier suggestion. If anyone in the ARM community wishes their board to “take off” and become an industry standard, I reiterate that each unique board will have to have a simple, failsafe boot loader which is familiar with all the built-in-on-board hardware and provides a standard way to address it, In other words, a BIOS, and those BIOSes should have a user-friendly look and feel. Even for those who are building embedded systems the advantages are huge. It means you don’t have to reinvent YOUR wheel each time the board is updated or modified in production. Building the actual operating system on, as an example, the old HP-1000 A-series real-time boxes was trivial, and in the case of the DEC Alphastation and Aphaservers, the SRM console could address and boot from literally any storage media that you could hang on the system.
And the initial firmware (read BIOS/bootloader) in each case was tiny. You must remember that these systems were designed 30 years ago when ALL memory cost like solid gold. You guys are spoiled! In 1990 or 91 I won the door prize at the HP Interex convention in Boston, a 3.3 MB RAM board for my HP-1000 A990. The list price for the board was $13,000 US!
Sep 22, 2016 @ 12:30:35
To LinuxUser:
> And by even then, sunxi ROM prefers SD card over SPI. So if user dares to use SD card in boot slot, attacker could always inject own boot image to that card, it would take precedence over readonly SPI thing. Reboot. Boo-hoo, root of trust takeover complete.
Yeah, I’m happy that you learned this information from the linux-sunxi wiki page. But there was no point also re-posting it to the Olimex blog 😉 And you forgot to mention the suggested workaround. So the other blog readers may get a wrong idea.
Sep 22, 2016 @ 12:48:37
To LinuxUser:
> Sunxi uboot isn’t much better. I have to patch it to use in my embedded systems. It outsmarts itself. Its boot time is awful, uboot accounts ~30% of boot time of my devices! It fiddles with usb/sata.
Yes, U-Boot is able to boot from USB and SATA hard drives, and this functionality is enabled by default. Just because any average inexperienced user expects the system to be bootable from this kind of storage media too.
But if you have a special use case, then the defaults might be not optimal for you.
> This introduces dozens of stupid failure modes where it lockups or misdetects boot target. Watchdog never kicks in either. Great.
Can you provide a link to your great bugreport in the U-Boot mailing list? Has this problem been addressed by now?
> And there is nobody on site to reboot device or press a key in fuk’ng uboot prompt. I failed to find civilized ways like menuconfig to make it non-interactive and pike off. I’ve got my hands dirty and patched sunxi support code. Sorry if this sounds harsh but I had some misbooted devices where WD never fired, so there were unhappy customers.
It just sounds like you are representing a commercial entity and want a paid support. I think that this can be arranged if you are interested. If not, then good luck. It’s open source and you can do everything yourself.
> Those trying to use PCs for embedded/automations eventually find their crap hanging in some prompt asking for something. While there could be no even keyboard to press that damn key in first place. Ever seen kbd on, say, some kiosk? Or some networked appliance? Some telemetry gateway? It not to be taken as granted there is serial or LCD attached either. Unfortunately sunxi ppl seems to ignore this.
Considering that “sunxi ppl” == “anyone with Allwinner hardware”, obviously you are also included in the group. So it is *you*, who has failed to provide some decent support for these use cases and document them is the linux-sunxi wiki. Despite apparently having done some work on it. Please do a better job.
And again. If you want paid support, then we can discuss it.
Sep 01, 2016 @ 15:45:36
I’m not sure eMMC-less version will be interested for our type of customers, this board is designed to be reliable industrial 24/7 solution for customers who use now our A20 boards but need more computing power and/or 4K video.
Sep 01, 2016 @ 12:57:38
I’m excited about this, but other than eMMC, what options does this have for storage? Does it have USB3 or any SATA connectors?
Sep 01, 2016 @ 15:55:23
A64 has no USB3 neither SATA
Sep 01, 2016 @ 14:30:02
Do you have armbian running on there with a mainline kernel?
Sep 01, 2016 @ 14:48:02
I tested both Armbian images for Pine64 yesterday. Both images legacy and vanilla boot fine on A64-OLinuXino, but most of peripherals don’t work properly, of course, due to the hardware differences between the A64-OLinuXino and Pine64 boards (different USB port controller, different GbE controller, etc). I believe that it shouldn’t be very hard to add a build for our board.
Sep 01, 2016 @ 16:31:57
I suspect most of the differences can be solved by editing the DTS file. But I might be wrong.
Sep 01, 2016 @ 15:56:32
and Armbian images has way better optimized power consumption! these guys do great job 🙂
Sep 01, 2016 @ 15:05:26
This is wonderful! I am watching and waiting to get my hands on onr.
Sep 01, 2016 @ 15:17:10
Good news,
1. Price info plase?
2. Ram 1 org 2gb ?
3. Nand 8 or 16gb?
4. Eth is giga or 100?
Date?
Thanks….
Sep 01, 2016 @ 15:42:43
1. I would love to answer but do not know the answer yet 🙂 Let’s wait until production?
2. can be 1GB or 2GB but price for 2GB will not be attractive
3. 4GB of course, if you find industrial grade eMMC 8GB or 16GB under $50 tell me
4. read above “Gigabit PHY is now KSZ9031 from MICROCHIP/MICREL”
Date? Soon 🙂
Sep 01, 2016 @ 18:06:31
There are few IO on this board. One of the reasons I like the A20 lime is the number of IO it has, for my applications there is always a lot of external hardware. Maybe there are plans for this board in a Lime/micro format someday?
Sep 01, 2016 @ 22:02:21
Cooling. Does the board need a fansink? Or is it possible to avoid a fan, and just use a heatsink? Are there any mounting holes you can use for a heatsink?
Sep 02, 2016 @ 08:31:15
The answer is easy. A64 does neither _need_ a fan nor heatsink when throttling settings are defined sane. But if you plan to run heavy workloads over longer periods of time (read as: longer than a few seconds) then performance will be affected since throttling happens.
I don’t know how efficient the SBC design helps with heat dissipation but with Pine64 (also using the ground plane as heatsink) we tried to develop sane dvfs / throttling settings already back in March and with these settings we managed at least to avoid a) shutting down CPU cores as a measure of overheating protection which is something that will happen for sure when you use Allwinner’s default settings b) powering off the whole board since it overheats to fast.
When running Armbian on the board even after heavy workloads where throttling down to 480 MHz did not help any more and CPU cores had to be killed, the cores come back when temperature allows it (in-kernel corekeeper as patch) and you can be assured that if modifications to the thermal trip points are necessary on A64-OLinuXino since the board behaves differently to address b) we will implement it ASAP and send every stuff we find back to longsleep (would be a smart move from Olimex to send him and apritzel developer samples). Those maintain more or less the two Linux kernel branches for A64 now and I hope it remains so.
If you’re really interested in this stuff (thermal, dvfs / cpufreq scaling, reliability and so on) take a few hours and read through https://github.com/longsleep/build-pine64-image/pull/3
Sep 02, 2016 @ 09:18:06
Almost forgot: In case you send out dev samples, please consider Jared McNeill too. The FreeBSD folks would love to support a 64-bit board that is not toy-grade hardware: https://www.freebsd.org/doc/en/articles/contributors/staff-committers.html
Sep 02, 2016 @ 09:32:49
noted, thanks
Sep 02, 2016 @ 14:30:30
As a user and not a developer, I second the suggestion that BSD be included and encouraged in development for the A64 board. I have used BSD when I was after absolute reliability; there is a major difference in attitude between the Linux and BSD communities and it shows in reliability.
Sep 02, 2016 @ 08:43:01
We still run test on this board but what we noticed yesterday is that with Armbian image the power consumption is about twice low as if Allwinner SDK kernel is used.
We ran stress test for many hours yesterday and sure CPU is getting hot during this operation, but the good news for us is that not only the CPU gets hot, but also whole board get hot as the CPU! This means we made great heat dissipation and distribution i.e. the temperature of the board is almost same as CPU temperature i.e. good heat transmission to PCB power and GND planes which act like two 90×50 mm copper heat sinks attached to the CPU 🙂 (at least while we were fighting with H3 we learned new PCB routing tricks)
Sep 02, 2016 @ 09:13:05
I hope, you do not compare Armbian vanilla image with Allwinner SDK kernel since vanilla uses mainline kernel and there we still have no access to PMIC therefor no dvfs, no cpufreq scaling and a fixed clockspeed of pretty conservative 408 MHz. And please also stop using stress and use stuff for real men: https://github.com/ssvb/cpuburn-arm 🙂
On the other hand Allwinner’s default settings are known to kill CPU cores way too early (and with their kernel they never come back until a reboot) so if the board showed higher consumption with Allwinner’s settings than any Armbian image then this is really promising regarding heat dissipation.
BTW: Lucky guys having professionals as customers. The average SBC tinkerer starts already to whine when the SD card slot on a board feels slightly warm 😉
Sep 02, 2016 @ 13:49:50
More specifically, for Allwinner A64 that would be https://raw.githubusercontent.com/ssvb/cpuburn-arm/master/cpuburn-a53.S
Yeah, I still need to convert this set of separate test programs into a single utility with built-in runtime CPU type detection. So that it automatically picks the best cooking strategy for the target CPU 🙂
Sep 06, 2016 @ 23:40:21
Whoa, it seems you’ve made PCB quite a decent heatsink, which sounds like a really nice idea.
Sep 05, 2016 @ 16:26:15
Thanks for keeping SPI in mind. I prefer it over I2C. Most MEMs sensors only support I2C and SPI, and SPI connection is usually at least 10mhz sometimes 20mhz, I2C is at most 3.2mhz. SPI has so many uses besides flash.
Sep 06, 2016 @ 23:36:18
Cool. I wonder if there’re chances some early devices could be accessible to e.g. Linux-Sunxi devs and somesuch? Or some few “advanced” users, just to give it early evaluation, with full understanding it is WIP and could expose quirks and backfire on both SW and HW levels, etc.
I also really wonder if there going to be cheap version. E.g. with no wi-fi, commercial grade and without e.g. eMMC, etc. I have some scenario where I only care about gigabit and 64 bit.
Sep 07, 2016 @ 11:22:53
SPI flash option would be interesting on a20 boards without nand/emmc for storing u-boot instead of a microsd. It can be used for network boot, for example.
Sep 13, 2016 @ 20:07:56
A20 is a bit old now. But eventually having the A20 successor (R40?) board manufactured by Olimex would be very nice. I’m particularly interested in having the bootloader in the SPI flash and booting the system from SATA.
Sep 07, 2016 @ 16:52:55
The idea of a locked, read-only bootloader seems to make a lot of sense to me. Even better, because it’s less complicated would be a physical write-protection switch of some sort, most likely a simple jumper on the motherboard. Remove the plug to modify the bootloader! Or for that matter, to update any firmware. Simple, and it makes sense.
Sep 13, 2016 @ 20:23:05
Except that the firmware upgrade process becomes neither simple nor user friendly this way. And in the early days (the first half a year of the board life time) we might want to be able to do a somewhat active firmware development. In my opinion, the hardware protected bootloder model can only work reasonably well if we keep this SPI flash firmware extremely simple (do only the digital signature verification and loading of the next stage) but have the actual digitally signed board-specific firmware (which implements the secure monitor, PSCI, SCPI and other stuff) on a removable media together with the rest of the OS (maybe stored in a dedicated GPT partition with a unique Allwiner-specific GUID).
Yes, it’s one of the possibilities. But this kinda defeats the purpose to some extent, because we can’t have a generic “ARM Linux” distribution (which is free of any board specific pieces) this way. And as I already suggested to LinuxUser, feel free to contribute by editing the linux-sunxi wiki and adding your ideas. The linux-sunxi bootable SPI flash page is currently more like a draft which needs to be fleshed out.
In any case, thanks for your feedback! It is surely appreciated.
Sep 13, 2016 @ 20:30:22
I mean, some devices, such as chromebooks, already have a firmware write protect screw: https://www.chromium.org/chromium-os/developer-information-for-chrome-os-devices/samsung-arm-chromebook
And as you may guess, not every average user is perfectly comfortable with this particular procedure. The vast majority of users will just keep using the original pre-installed factory firmware.
Sep 13, 2016 @ 20:52:57
My point about the boot loader being protected by a shorting pin was intended to simplify things and not complicate them. In the original IBM PC BIOS, the boot loader merely points to a physical address in memory in effect telling the CPU “Go here and do this.” If the boot loader is intentionally kept simple, containing only information about the addresses of stuff on the A64 motherboard (Basic Input Output System) then that address your internal memory/SD Card becomes the equivalent of Track 0 Sector 0. Personally, were it up to me, I’d suggest reverse engineering the old DEC Alpha’s SRM console, the best and most flexible system I ever saw. I’d be happy to try it but truth be told, I’m not good enough to attempt it and even when I was working with those systems every day I didn’t have enough skills. But think about this; regardless of the ARM manufacturer, writing a simple pointing program for the particular chip means in essence that you can stop worrying about how to load or update since you’e made every target pretty much the same, just like an ancient PC.
Sep 13, 2016 @ 21:01:14
Sorry, all. I spoke about SRM and there probably are a lot of you who have neer seen it. A good HOWTO can be found here:
http://www.tldp.org/HOWTO/SRM-HOWTO/x11.html
Sep 08, 2016 @ 12:59:35
I *love* it that you added the line-in option! You rock!
Here, take my money! Where do I throw it!? Can I have it NOW!? 😉
Sep 27, 2016 @ 14:03:10
Thank you, for adding the SPI option, let it be put to good use.