(This is not a topic about the choice of x86_64 vs ARM for the SoC of the Pyra -- I would mildly favour an x86_64 SoC, if possible, for the extra compatibility with my GNU/Linux PC system but, since I expect the form factor of the Pyra to be rather awkward for a significant number of the relevant programs (first-person shooters, real-time strategy, grand strategy (I cannot see there being a good experience with Crusader Kings 2 or Hearts of Iron 4 on such a small screen) or anything both fast-paced and mouse-based) I have no particular preference.) [/LISP]
Having read through the threads about the SoC choices & availability, I came across an argument, in favour of ARM rather than x86_64, that my Computer Science degree has not adequately prepared me for. That is the argument that x86_64 should be avoided, as one would have to write a BIOS for the processor to function, whereas for ARM one would not. I read this and I thought: "That is interesting, but why is it so?". I know almost nothing about ARM (other than that it is RISC and "cleaner than x86", allegedly) as I have never (until the Pandora, at least) had a non-x86(/_64) device for which I cared one jot, while I have been an enthusiastic (personal/home) computer user since childhood (no consoles, only DOS/Windows & GNU/Linux).
My understanding is that, for a GNU/Linux PC, the BIOS/(U)EFI is a program, loaded from flash memory on the motherboard, that checks a specific place (Master boot record for BIOS) for a pointer to another program to load. This other program is either an operating system kernel image or a bootloader that can further point to other images, typically operating system kernels. An operating system kernel then grabs data from a preconfigured position on a storage medium of some kind (in my setup, an SSD) that it treats as a filesystem and runs an init system (PID 1 in Unix-parlance) that runs other programs to build-up the user environment, including a login system, window manager, desktop environment etc.. The kernel also has access to/responsibility for restricted x86(_64) commands, virtual memory tables (needed by the CPU), process/thread CPU/core allocation tables (also needed by the CPU) and some other tasks. It is obvious how the x86(_64) system is dependent on the existence of an OS (but what about PC-booters?), but it is not so clear to me why the BIOS is required. It seems to me conceivable that there would be an x86(_64) machine that loaded an OS directly without going via BIOS.
Questions:
1. (For the above, please correct me if & where I am wrong/incomplete)
2. What is the ARM/Pandora/Pyra bootstrapping process? Why is it simpler -- why is the x86_64 one more difficult (and is that related to the PC hardware specification being relatively "open", with freely installable OSes etc.; alternately, is this why ARM devices tend to be so locked-down/crippled?)?
3. I am led to believe that there is a free(?) BIOS implementation called Coreboot/Libreboot. Is this relevant?
4. I have been fiddling with the programming language FORTH, recently (LISP/Scheme/Clojure is next!). It appears that there is some kind of bootloader/BIOS/firmware program based on this language, called Open Firmware. It was developed by Mitch Bradley for Sun Microsystems and used for the servers they sold (with, I believe, a variety of CPUs and Instruction Set Architectures in use: at least PowerPC and SPARC) and was more recently used by the One Laptop Per Child project (using an x86, I believe), with supposed advantages being interactive debugging with the Forth interpreter and mass-firmware-deployment. http://wiki.laptop.org/go/Open_Firmware http://wiki.laptop.org/go/OFW_FAQ https://en.wikipedia.org/wiki/Open_Firmware . Is this in any way relevant to the Pandora or the Pyra?
5. There is some terminology around the Pandora, the Pyra and the Nokia N900 that confuses me. Text describes "flashing the firmware" in terms that seem to me like installing an OS. Why is this? Is the OS truly on a normally-inaccessible storage medium? If so, why? Is there no way to insert a USB-storage device and boot from it with a menu like on a PC?
Thanks in advance.
Having read through the threads about the SoC choices & availability, I came across an argument, in favour of ARM rather than x86_64, that my Computer Science degree has not adequately prepared me for. That is the argument that x86_64 should be avoided, as one would have to write a BIOS for the processor to function, whereas for ARM one would not. I read this and I thought: "That is interesting, but why is it so?". I know almost nothing about ARM (other than that it is RISC and "cleaner than x86", allegedly) as I have never (until the Pandora, at least) had a non-x86(/_64) device for which I cared one jot, while I have been an enthusiastic (personal/home) computer user since childhood (no consoles, only DOS/Windows & GNU/Linux).
My understanding is that, for a GNU/Linux PC, the BIOS/(U)EFI is a program, loaded from flash memory on the motherboard, that checks a specific place (Master boot record for BIOS) for a pointer to another program to load. This other program is either an operating system kernel image or a bootloader that can further point to other images, typically operating system kernels. An operating system kernel then grabs data from a preconfigured position on a storage medium of some kind (in my setup, an SSD) that it treats as a filesystem and runs an init system (PID 1 in Unix-parlance) that runs other programs to build-up the user environment, including a login system, window manager, desktop environment etc.. The kernel also has access to/responsibility for restricted x86(_64) commands, virtual memory tables (needed by the CPU), process/thread CPU/core allocation tables (also needed by the CPU) and some other tasks. It is obvious how the x86(_64) system is dependent on the existence of an OS (but what about PC-booters?), but it is not so clear to me why the BIOS is required. It seems to me conceivable that there would be an x86(_64) machine that loaded an OS directly without going via BIOS.
Questions:
1. (For the above, please correct me if & where I am wrong/incomplete)
2. What is the ARM/Pandora/Pyra bootstrapping process? Why is it simpler -- why is the x86_64 one more difficult (and is that related to the PC hardware specification being relatively "open", with freely installable OSes etc.; alternately, is this why ARM devices tend to be so locked-down/crippled?)?
3. I am led to believe that there is a free(?) BIOS implementation called Coreboot/Libreboot. Is this relevant?
4. I have been fiddling with the programming language FORTH, recently (LISP/Scheme/Clojure is next!). It appears that there is some kind of bootloader/BIOS/firmware program based on this language, called Open Firmware. It was developed by Mitch Bradley for Sun Microsystems and used for the servers they sold (with, I believe, a variety of CPUs and Instruction Set Architectures in use: at least PowerPC and SPARC) and was more recently used by the One Laptop Per Child project (using an x86, I believe), with supposed advantages being interactive debugging with the Forth interpreter and mass-firmware-deployment. http://wiki.laptop.org/go/Open_Firmware http://wiki.laptop.org/go/OFW_FAQ https://en.wikipedia.org/wiki/Open_Firmware . Is this in any way relevant to the Pandora or the Pyra?
5. There is some terminology around the Pandora, the Pyra and the Nokia N900 that confuses me. Text describes "flashing the firmware" in terms that seem to me like installing an OS. Why is this? Is the OS truly on a normally-inaccessible storage medium? If so, why? Is there no way to insert a USB-storage device and boot from it with a menu like on a PC?
Thanks in advance.