4 ms·

We had similar ideas, but the bootloaders were always problematic. These Atom chips are still probably limited to 32bit boot loaders.

geokon 7y ago
This is discussed in the comment section. It shouldn't be a problem any longer. Tom Cubie is from Radxa
DCKing 7y ago
IIRC this was a major problem with the Bay Trail generation (32 bit EFI, 64 bit CPU). These are Cherry Trail generation chips (one generation newer) which did get 64 bit EFIs. That's not to say this board has a 64 bit EFI, but the vendor could avoid problems if they're smart.
- notyourday 7y ago
  I have 4 different BayTrails (manufacturers/etc) running in my apartment. There is zero issue with them in Linux but they have a funky requirement: - they must be booted into legacy i.e. on EFI mode. EFI mode boot does not work reliably. - the boot disk must have MBR and not GPT disk label.
  - userbinator 7y ago
    I'm not surprised, EFI is a mess in general. Good old BIOS has worked for 30+ years, and is simple enough that it's not hard to get right (yet there are/were some that still did...) --- load the first sector of the boot device at 7C00 and jump to it.
    - beagle3 7y ago
      And then spend then next 400,000,000 cycles progressively switching from 40 year old 8086 real mode to the present, reading some newer firmware configuration tables from that same BIOS (which are often buggy), compensating for those bugs, etc. That's still less than a quarter of a second, granted. But the complexity goes to the OS instead of a reasonable separation of concerns. Granted, the mess that [U]EFI is, it might still be the better option. But the old BIOS is only "good" because of the crazy (sunk and continuing) cost to effectively implement "good new bios" within the operating systems.
      - notyourday 7y ago
        > That's still less than a quarter of a second, granted. But the complexity goes to the OS instead of a reasonable separation of concerns. So? The OS already does it.
      - drudru11 7y ago
        I have found the [U]EFI mess to be really unbearable. It is too hard to debug. I mean, they learned nothing from the workstation or minicomputer era wrt. boot diagnostics.
      - userbinator 7y ago
        BIOSes have been executing mostly in "unreal"/flat-real mode since at least the 486 days, and I recall one of the later ones switching into that mode only a dozen instructions after FFFF:FFF0. EFI is ridiculous complexity, more than that of early OSs, mostly just to do things which the OS would again do when it boots up.
- Fr0styMatt88 7y ago
  The device I allude to in my other comment here is a Cherry Trail device. I did query the supplier as to why the EFI was not 64-bit and was told essentially that "The 2 GB version of the device comes with 32-bit UEFI because it doesn't support 64-bit OS". Another variant of the device with more RAM does come with a 64-bit UEFI, apparently. I can _kind of_ see the logic -- when you have only 2 GB of RAM, you aren't really going to want to put a 64-bit OS on it. Part of the issue there as well is, as I understand it, UEFI can only load EFI applications (of which the bootloader is) of the same bitness as the UEFI implementation -- 64-bit UEFI can _only_ load 64-bit bootloaders.

geokon 7y ago

This is discussed in the comment section. It shouldn't be a problem any longer. Tom Cubie is from Radxa

DCKing 7y ago

IIRC this was a major problem with the Bay Trail generation (32 bit EFI, 64 bit CPU). These are Cherry Trail generation chips (one generation newer) which did get 64 bit EFIs. That's not to say this board has a 64 bit EFI, but the vendor could avoid problems if they're smart.

notyourday 7y ago
I have 4 different BayTrails (manufacturers/etc) running in my apartment. There is zero issue with them in Linux but they have a funky requirement: - they must be booted into legacy i.e. on EFI mode. EFI mode boot does not work reliably. - the boot disk must have MBR and not GPT disk label.
- userbinator 7y ago
  I'm not surprised, EFI is a mess in general. Good old BIOS has worked for 30+ years, and is simple enough that it's not hard to get right (yet there are/were some that still did...) --- load the first sector of the boot device at 7C00 and jump to it.
  - beagle3 7y ago
    And then spend then next 400,000,000 cycles progressively switching from 40 year old 8086 real mode to the present, reading some newer firmware configuration tables from that same BIOS (which are often buggy), compensating for those bugs, etc. That's still less than a quarter of a second, granted. But the complexity goes to the OS instead of a reasonable separation of concerns. Granted, the mess that [U]EFI is, it might still be the better option. But the old BIOS is only "good" because of the crazy (sunk and continuing) cost to effectively implement "good new bios" within the operating systems.
    - notyourday 7y ago
      > That's still less than a quarter of a second, granted. But the complexity goes to the OS instead of a reasonable separation of concerns. So? The OS already does it.
    - drudru11 7y ago
      I have found the [U]EFI mess to be really unbearable. It is too hard to debug. I mean, they learned nothing from the workstation or minicomputer era wrt. boot diagnostics.
    - userbinator 7y ago
      BIOSes have been executing mostly in "unreal"/flat-real mode since at least the 486 days, and I recall one of the later ones switching into that mode only a dozen instructions after FFFF:FFF0. EFI is ridiculous complexity, more than that of early OSs, mostly just to do things which the OS would again do when it boots up.
Fr0styMatt88 7y ago
The device I allude to in my other comment here is a Cherry Trail device. I did query the supplier as to why the EFI was not 64-bit and was told essentially that "The 2 GB version of the device comes with 32-bit UEFI because it doesn't support 64-bit OS". Another variant of the device with more RAM does come with a 64-bit UEFI, apparently. I can _kind of_ see the logic -- when you have only 2 GB of RAM, you aren't really going to want to put a 64-bit OS on it. Part of the issue there as well is, as I understand it, UEFI can only load EFI applications (of which the bootloader is) of the same bitness as the UEFI implementation -- 64-bit UEFI can _only_ load 64-bit bootloaders.