Information about OS / Kernel / Prototypes


Does anyone know whether it will be possible to deploy LetuxOS (and eventually other OSes) on the Pyra from a IODD 2541 device, or from an Easy2Boot/Ventoy-enabled USB drive?
 
Last edited:
TrashyMG said:
Had to seriously google all that... if it's supported in mainline debian armhf likely yes?
Click to expand...
Haha just a couple of multiboot options I came across through some YouTube channels.
Right, I need to check whether they are actually supported in mainline...
 
  • Like
Reactions: rSl
TrashyMG said:
Had to seriously google all that... if it's supported in mainline debian armhf likely yes?
Click to expand...
The response I’ve had so far was actually in regard to using the IODD 2541 with Raspberry Pi but I assume it still holds true for any other armhf-based device?

The Q. I posed beneath a video about the IODD 2541 was:
“Question from a NOOB: Clearly IODD provide support for Linux OSes but does that also mean support for mainline Debian armhf?”

The reply I got was:
“It should work as long as your Pi is setup to boot from USB. By default they aren’t setup this way.”

Perhaps, being a NOOB, I didn’t ask the right Q. or didn’t phrase it correctly?
 
If they just appear as a USB hard/DVD drive with all the user interface on the drive itself, then there should be no problems using it with the standard Linux drivers.

Booting from USB might be more of an issue, some U-boot tweaks may be needed to get that to work as I don't know if it has been tried yet. Worst case, in theory you could have the kernel, ramdisk and dtb on eMMC/SD and rootfs on the USB drive.
 
daveshah said:
If they just appear as a USB hard/DVD drive with all the user interface on the drive itself, then there should be no problems using it with the standard Linux drivers.

Booting from USB might be more of an issue, some U-boot tweaks may be needed to get that to work as I don't know if it has been tried yet. Worst case, in theory you could have the kernel, ramdisk and dtb on eMMC/SD and rootfs on the USB drive.
Click to expand...
Cool, sounds good!
 
daveshah said:
If they just appear as a USB hard/DVD drive with all the user interface on the drive itself, then there should be no problems using it with the standard Linux drivers.

Booting from USB might be more of an issue, some U-boot tweaks may be needed to get that to work as I don't know if it has been tried yet. Worst case, in theory you could have the kernel, ramdisk and dtb on eMMC/SD and rootfs on the USB drive.
Click to expand...
Directly booting from USB or SATA is theoretically possible, but AFAIK nobody has tried. And at least for the USB2 host ports there is no driver in U-Boot (would have to enable power and implement the HSIC hub protocol). The OTG-USB3 port may potentially work (but U-Boot also has no code for powering up for OTG) and SATA maybe. So to be safe, U-Boot must come from eMMC/µSD (or SD).

A working scheme could be:
* SPL boot loader, U-Boot, kernel with simple rootfs in initrd are booted from eMMC (or µSD or left SD slot).
* that initrd scans all available devices for a rootfs (incl. kernel, DTB and modules) and boots what it finds.
* then, all peripherals where a Linux driver exists would be available: SD, µSD, rootfs partition of eMMC, USB, SATA drive and maybe even over network.

Boot sequence would then be:
BootROM loads MLO (from SD, µSD, eMMC) -> loads U-Boot (from SD, µSD, eMMC) -> loads Kernel with initrd (from SD, µSD, eMMC) -> loads final Kernel (from any source supported by Kernel with initrd) -> mounts real rootfs (from any source)

So there is no need to change U-Boot code. To make this work only the initrd is missing. Or it may already be available in PyraOS (and I am not aware since I do not have the time to follow PyraOS; LetuxOS doesn't have it).

So yes, it is possible to boot the final OS from USB hard disk, memory stick, DVD drive, Floppy drive, ...
Also note that the final kernel needs not necessarily be a Linux kernel. Only the initrd would have to know how to start (kexec) a different kernel binary and tell it about the boot device.
 
hns said:
Directly booting from USB or SATA is theoretically possible, but AFAIK nobody has tried. And at least for the USB2 host ports there is no driver in U-Boot (would have to enable power and implement the HSIC hub protocol). The OTG-USB3 port may potentially work (but U-Boot also has no code for powering up for OTG) and SATA maybe. So to be safe, U-Boot must come from eMMC/µSD (or SD).

A working scheme could be:
* SPL boot loader, U-Boot, kernel with simple rootfs in initrd are booted from eMMC (or µSD or left SD slot).
* that initrd scans all available devices for a rootfs (incl. kernel, DTB and modules) and boots what it finds.
* then, all peripherals where a Linux driver exists would be available: SD, µSD, rootfs partition of eMMC, USB, SATA drive and maybe even over network.

Boot sequence would then be:
BootROM loads MLO (from SD, µSD, eMMC) -> loads U-Boot (from SD, µSD, eMMC) -> loads Kernel with initrd (from SD, µSD, eMMC) -> loads final Kernel (from any source supported by Kernel with initrd) -> mounts real rootfs (from any source)

So there is no need to change U-Boot code. To make this work only the initrd is missing. Or it may already be available in PyraOS (and I am not aware since I do not have the time to follow PyraOS; LetuxOS doesn't have it).

So yes, it is possible to boot the final OS from USB hard disk, memory stick, DVD drive, Floppy drive, ...
Also note that the final kernel needs not necessarily be a Linux kernel. Only the initrd would have to know how to start (kexec) a different kernel binary and tell it about the boot device.
Click to expand...
Good to know and my bad, I’d managed to get the idea that LetuxOS and PyraOS were one and the same :$
 
Phlyra said:
Good to know and my bad, I’d managed to get the idea that LetuxOS and PyraOS were one and the same :$
Click to expand...
Well, LetuxOS and PyraOS are two different OS distributions but sharing a lot behind the screen. They share the code base for boot loader and kernel (although there may be different configs and additional patches). They also share standard Debian (but different releases). They mainly differ in the complete setup for user-space, i.e. what you can see and operate.
This is because both projects have a lot in common but partially different goals. LetuxOS wants to make stable kernels and get code upstream and support many devices (GTA04, OpenPandora, Udoo neo, PandaBoard, RasPi, PinePhone, CI20, Kobo/Tolino eInk reader etc.). But has no specific focus on GUI, although there are QuantumSTEP and Replicant images available.
PyraOS focusses on the Pyra to get a fast and robust to operate gaming platform out of the Pyra hardware (and no other). Therefore there is a bigger focus on user space polishing and optimization, sometimes even going into reconfiguring and recompiling Debian packages.
In summary you may see LetuxOS vs. PyraOS as equivalent or different as Debian vs. Ubuntu or Debian vs. Raspbian.
 
hns said:
Well, LetuxOS and PyraOS are two different OS distributions but sharing a lot behind the screen. They share the code base for boot loader and kernel (although there may be different configs and additional patches). They also share standard Debian (but different releases). They mainly differ in the complete setup for user-space, i.e. what you can see and operate.
This is because both projects have a lot in common but partially different goals. LetuxOS wants to make stable kernels and get code upstream and support many devices (GTA04, OpenPandora, Udoo neo, PandaBoard, RasPi, PinePhone, CI20, Kobo/Tolino eInk reader etc.). But has no specific focus on GUI, although there are QuantumSTEP and Replicant images available.
PyraOS focusses on the Pyra to get a fast and robust to operate gaming platform out of the Pyra hardware (and no other). Therefore there is a bigger focus on user space polishing and optimization, sometimes even going into reconfiguring and recompiling Debian packages.
In summary you may see LetuxOS vs. PyraOS as equivalent or different as Debian vs. Ubuntu or Debian vs. Raspbian.
Click to expand...
Ahhh ok, that makes sense - thanks for the clarification! :)
@hns So is there a separate mailing list for reading about PyraOS update work?
 

Attachments

  • 99E7F119-0F3C-4A7A-A0EE-70B4E4A24DAF.jpeg
    99E7F119-0F3C-4A7A-A0EE-70B4E4A24DAF.jpeg
    100.5 KB · Views: 547
  • 2C963538-8C7A-4D4A-9CBB-10BF1A9F0DDF.jpeg
    2C963538-8C7A-4D4A-9CBB-10BF1A9F0DDF.jpeg
    98 KB · Views: 522
Phlyra said:
Thanks for the links! Unfortunately for both of them I get this:
:mad:
Click to expand...
Yeah it resolves to a regular http site and throws a flag up, I know it works in chrome is you bypass the warning, I'm not sure how you would do that in Safari.
 
TrashyMG said:
Yeah it resolves to a regular http site and throws a flag up, I know it works in chrome is you bypass the warning, I'm not sure how you would do that in Safari.
Click to expand...
Ah. I’ll try again later on my laptop but d’you know whether it works alright in Firefox?
 
I don't think that much has changed since my previous posts. I am still working on improving the 3D and X11 combination, fixing some resize related bugs and a bug when a program closes its window and then opens another.

The last main issue is that the etnaviv driver for the 2D core, used for that Xorg driver for blitting, does not play well with extended physical addresses (its pattern of buffer allocation causes the swiotlb to run out), so to work with 4GB RAM it needs to be modified to only allocate DMA buffers in the lowest 2GB of RAM. There is a patch for this already in Linux 5.7 that might be backportable to the 5.6 we are using but this needs investigation still.

I believe @hns has been looking into some DSI panel issues with kernels beyond 5.6 that might need that driver to be updated.

@aTc has been creating Debian packages for all this stuff and testing it on an actual Pyra.
 
Last edited:
daveshah said:
I don't think that much has changed since my previous posts. I am still working on improving the 3D and X11 combination, fixing some resize related bugs and a bug when a program closes its window and then opens another.

The last main issue is that the etnaviv driver for the 2D core, used for that Xorg driver for blitting, does not play well with extended physical addresses (its pattern of buffer allocation causes the swiotlb to run out), so to work with 4GB RAM it needs to be modified to only allocate DMA buffers in the lowest 2GB of RAM. There is a patch for this already in Linux 5.7 that might be backportable to the 5.6 we are using but this needs investigation still.

I believe @hns has been looking into some DSI panel issues with kernels beyond 5.6 that might need that driver to be updated.

@aTc has been creating Debian packages for all this stuff and testing it on an actual Pyra.
Click to expand...
DSI, hdmi bug fixed, too ! (source: mailing list)
At this rate when I get my second batch (hopefully) pyra, os will be bugfree xD
 
You must log in or register to reply here.

Similar threads

jedi23
New Kernel for Buster released
Replies
3
Views
2K
matzesu
matzesu
johnicboom
LeTux OS
2
Replies
27
Views
5K
Askarus
Askarus
Linux-SWAT
Booting the Pyra : unifying the efforts.
Replies
14
Views
5K
aTc
aTc
A
Are general pyra users allowed accounts on dev.pyra-handheld.com ?
Replies
5
Views
4K
HamburgerBun
HamburgerBun
Linux-SWAT
Slackware inside Pyra
3 4 5
Replies
81
Views
14K
Linux-SWAT
Linux-SWAT
Back
Top