4 ms·

I evaluated an EMAG at work several months ago. It didn't end up making sense for us compared to x86, but it provided a good opportunity to port our server sta

I evaluated an EMAG at work several months ago. It didn't end up making sense for us compared to x86, but it provided a good opportunity to port our server stack to arm64 and it was a great learning experience. Regarding the boot times: If you watch the serial console when the machine is booting, you see that its running a native arm boot loader (uboot?), and then that boot loader boots the EFI firmware. So I think the "double bootloader" is a large part of the long boot times.

a012 6y ago
But even loading up Ubuntu looks painful, it took 2 more minutes to complete.
- drewg123 6y ago
  Its hard to tell whats going on with the OS boot from their video of the glass console because of the endemic information hiding prevalent in OSes these days. God forbid that you have some kind of progress indicator, or even text (the horror! we might confuse users!) In my case, I was booting FreeBSD, and I don't remember having boot much slower on this box than it does on Intel Xeon or AMD Rome once the EFI bios finally handed off to the FreeBSD efi boot loader.
  - qubex 6y ago
    I commiserate with you. For the past fifteen years or so I’ve set my macs to verbose boot because I want to see what’s going on and where they seize up (if indeed that happens). Doesn’t happen often but in the few occasions it has it’s really saved my bacon.
- rbanffy 6y ago
  Boot times are a funny thing - we don't boot our computers as often as we did our 386 PCs. I often boot my computers only when there is a kernel upgrade that requires the OS to be reloaded. My main laptop hasn't booted in 28 days (but got suspended numerous times). The corporate issue Mac did it last week (and also suspends every time it's moved). The Xeon under my desk says it's 52 days - I remember it had a kernel update. The VMs may have longer uptimes, since they were suspended and restarted - the OpenSolaris one must think it's up for years. Last time I booted a serious server, the OS came up in about a minute or so. The application took something close to two hours to be fully primed and within performance guidelines. Years ago a RabbitMQ decided to take 9 hours to fully restart. We had to add queue server redundancy to the application more quickly than I would advise anyone to try.
rcxdude 6y ago
That's not super uncommon: ARM systems usually have a chain of bootloaders from the one burned into ROM to the actual OS (one I used went 1st stage in ROM: 2nd stage in a sector in flash, 3rd stage from filesystem, boot OS from filesystem). But in general this process was very fast: the layering is essentially due to managing complexity: the earlier stages are smaller and less capable (and a key limit is the limit on where they can read the next stage from and where they can place it, which limits the size of the stage), and the whole process is generally really fast (limited either by a boot selection menu with a timeout or by the storage speed of the medium containing the bootloader). I suspect there is similar or more complexity in the boot process of a modern x86 system.
- floatboth 6y ago
  All (complex enough) systems ever have a chain of loader stages like that. The process is fast on desktop machines. Big servers spend minutes training and testing all the damn RAM.

a012 6y ago

But even loading up Ubuntu looks painful, it took 2 more minutes to complete.

drewg123 6y ago
Its hard to tell whats going on with the OS boot from their video of the glass console because of the endemic information hiding prevalent in OSes these days. God forbid that you have some kind of progress indicator, or even text (the horror! we might confuse users!) In my case, I was booting FreeBSD, and I don't remember having boot much slower on this box than it does on Intel Xeon or AMD Rome once the EFI bios finally handed off to the FreeBSD efi boot loader.
- qubex 6y ago
  I commiserate with you. For the past fifteen years or so I’ve set my macs to verbose boot because I want to see what’s going on and where they seize up (if indeed that happens). Doesn’t happen often but in the few occasions it has it’s really saved my bacon.
rbanffy 6y ago
Boot times are a funny thing - we don't boot our computers as often as we did our 386 PCs. I often boot my computers only when there is a kernel upgrade that requires the OS to be reloaded. My main laptop hasn't booted in 28 days (but got suspended numerous times). The corporate issue Mac did it last week (and also suspends every time it's moved). The Xeon under my desk says it's 52 days - I remember it had a kernel update. The VMs may have longer uptimes, since they were suspended and restarted - the OpenSolaris one must think it's up for years. Last time I booted a serious server, the OS came up in about a minute or so. The application took something close to two hours to be fully primed and within performance guidelines. Years ago a RabbitMQ decided to take 9 hours to fully restart. We had to add queue server redundancy to the application more quickly than I would advise anyone to try.

rcxdude 6y ago

That's not super uncommon: ARM systems usually have a chain of bootloaders from the one burned into ROM to the actual OS (one I used went 1st stage in ROM: 2nd stage in a sector in flash, 3rd stage from filesystem, boot OS from filesystem). But in general this process was very fast: the layering is essentially due to managing complexity: the earlier stages are smaller and less capable (and a key limit is the limit on where they can read the next stage from and where they can place it, which limits the size of the stage), and the whole process is generally really fast (limited either by a boot selection menu with a timeout or by the storage speed of the medium containing the bootloader). I suspect there is similar or more complexity in the boot process of a modern x86 system.

floatboth 6y ago
All (complex enough) systems ever have a chain of loader stages like that. The process is fast on desktop machines. Big servers spend minutes training and testing all the damn RAM.