Creating an "empty" OS for the pyra

[ljones]

Hello all!

Now that I have my pyra I'm now starting to consider an idea although I do not quite know how doable it is or not. The idea is to create an "empty" debian install for the pyra that runs off an sd card; by empty I mean that it is just a basic command line (the pyra just runs off the sd and has the basic command line prompt) and a few tools with no gui; instead of having a normal pre-created gui and OS you build it up piece by piece by installing .deb packages. Pretty much on my x86 debian machine this is what I do to get a complete desktop.

One idea might be to simply take the pyra os and just uninstall xfce. But that dosen't seem like a very clean way to go about things really plus I would have to work out exactly what needs to be uninstalled (and what needs to stay).

Fortunatly debian does at least have some sort of tool to create a basic OS called debootstrap. Haven't used it in a little while though!

But I can immediately think of 3 problems. Firstly what about the kernel? Presumably I'd have to take the "normal" pyra OS, pinch its kernel and modules and insert it into the debootstrap image although I'm really not sure how exactly to do that. Secondly there is the thorny issue of xorg acceleration (I don't know what the pyra uses but there are many arm devices which either have to use propietary xorg drivers or don't have anything at all).

After that there are other driver issues: bluetooth, wifi, audio and soforth. And then finally there's booting to take care of; does pyra just use uboot? And (again some armdevices need this) does the pyra need a file to be written to a specific place on the microsd card to enable boot? I can remember from long ago many allwinner based devices needed this.

Really at this point just trying to see if it is even at all possible. Any thoughts or comments?

ljones

 

[hns]

download makesd: https://projects.goldelico.com/p/gta04-makesd/

run

DEV=/dev/$your_SD_reader makesd pyra -r minimal

or if your have a 4GB RAM Pyra use

DEV=/dev/$your_SD_reader makesd pyra-4g -r minimal

This creates a bootable SD card which you can access through the USB-FTDI console. It is Debian Jessie and a v5.4 kernel by default but if you do

DEV=/dev/$your_SD_reader makesd -v latest pyra -r minimal

it will use Debian Bullseye with a v5.14 kernel.

Good starting points to play around. And easy to restart from scratch without touching the installed image...

Edit: I should add that you can use the USB3 port for Ethernet over USB (RNDIS) to get external access or use the /root/wlan-on script to enable WiFi. Then the apt-get world becomes available.

 

[ljones]

I've honestly never even seen that before and I have no idea what a letux is (I've heard of a (night of the) lepus but that isn't quite the same thing hehe!

How well it will work or if it is too specific to one thing only time will tell I guess.

Instead of running it (the makesd script) directly on the pyra I used my normal debian x86 box instead although I did have to add a "./";

$ DEV=/dev/sdc ./makesd -v latest pyra-4gb -r minimal

The good news is that created a new debian bullseye image (11) and I even got a command line login prompt on the pyra's screen

Many thanks for that info there. Next up will be to try to see how far I get with xorg I guess.

ljones

 

[TrashyMG]

I have no idea what a letux is

The Pyra is currently running the Letux linux kernel, hns consistently compiling updated versions of it, where the PyraOS will likely keep a more stable branch of the Letux kernel and update it on Major releases.

 

[ljones]

Ok, ran into a couple of issues. Firstly I cannot connect to the internet (to install more .deb files) at all using this method. The system dosen't seem to want to connect via either a usb ethernet adapter or wifi. Speaking of wifi I noticed this;

root@letux:~# systemctl status networking.service
* networking.service - Raise network interfaces
Loaded: loaded (/lib/systemd/system/networking.service; enabled; vendor pr>
Active: failed (Result: exit-code) since Sun 2021-07-18 15:37:20 UTC; 19s >
       Docs: man:interfaces(5)
Process: 3548 ExecStart=/sbin/ifup -a --read-environment (code=exited, stat>
   Main PID: 3548 (code=exited, status=1/FAILURE)
        CPU: 28.129s

Jul 18 15:37:20 letux dhclient[3728]: bugs on either our web page at www.isc.or>
Jul 18 15:37:20 letux dhclient[3728]: before submitting a bug.  These pages exp>
Jul 18 15:37:20 letux dhclient[3728]: process and the information we find helpf>
Jul 18 15:37:20 letux dhclient[3728]:
Jul 18 15:37:20 letux dhclient[3728]: exiting.
Jul 18 15:37:20 letux ifup[3548]: ifup: failed to bring up wwan0
Jul 18 15:37:20 letux systemd[1]: networking.service: Main process exited, code>
Jul 18 15:37:20 letux systemd[1]: networking.service: Failed with result 'exit->
Jul 18 15:37:20 letux systemd[1]: Failed to start Raise network interfaces.
Jul 18 15:37:20 letux systemd[1]: networking.service: Consumed 28.129s CPU time.

More seriously though the pyra dosen't seem to be always able to boot from sd card correctly (I did try more than one card, and the cards are ok). Sometimes the pyra booting from sd card would try to power on, but immediately power off again. A look through the serial port messages reveals something not quite right at uboot;

U-Boot SPL 2016.11-00301-gfd188cb (Feb 16 2019 - 14:57:57)
OMAP5432-GP ES2.0
ram code 0x0
version code 0xa
Found LC15 V5.3 with 4GB RAM
SDRAM: identified size not same as expected size identified: 0 expected: 40000000
>>spl:board_init_r()
spl_init()
Trying to boot from MMC1
FATAL: DDR RAM is not working! (80a00000: 1234f278)

This goes away if I try to boot from internal storage.

It looks like something isn't getting detected correctly from that "SDRAM" message there. (Update: after leaving the pyra powered off and with the sd card out for a while I can get back to booting from the sd card too).

ljones

 

[hns]

1. Letux is: www.letux.org and https://pyra-handheld.com/boards/threads/letux-os.81518/
2. the U-Boot/DDR message may be that your board needs slightly different DDR timings setup. ED mentioned a while ago that there is a patch in PyraOS and I am not sure if it is missing in the LetuxOS U-Boot.
3. for getting WiFi, please try the /root/wlan-on script. Alternatively connecting a PC with RNDIS through USB to the usb3 port (usb2 cable works as well) should bring up an interface usb0 with 192.168.0.202/200 address pair.
4. if you have external acces: to get some X11 installation: apt-get install letux-xorg

 

[ljones]

No luck there with any of that unfortunatly. :-(

I did have a usb0 created on the pyra but I am not sure if it would work - the pyra although it is conneced to my PC is only via usb-serial. Not sure if rndis would work - wouldn't that need some sort of ethernet over usb?

The script file also dosen't seem to install wpasupplicant so wlan-on dosen't work. I did find an easier solution though that was to take the card out of the pyra and use a chroot on another computer.

I managed to install letux-xorg but it did not get very far. All it said on the screen was "270 -> 8" and that is as far as it got!

Update: A couple of problems with xorg: Firstly letux appears to be using /etc/X11/xorg.conf which makes reference to something called "void". Digging a bit deeper there's a debian package called xserver-xorg-input-void although this seems to be not in letux.

I deleted those lines and got slightly further as it wasn't finding any xorg video driver. I then tried installing xserver-xorg-video-omap and that almost works, but not quite -- the driver can almost find screens but not quite as at gives up with a "could not read chipset" error.

I did try getting rid of xorg.conf (it appeared to be linked to a different file); that did something different it just gave a blank screen. This did try to use the xserver-xorg-video-omap driver but for some reason it then "forgot" it and is trying to use fbdev.

ljones

 

[ljones]

Ok, well after a *lot* of poking around and a lot of work I managed to get xorg going. Not much works for example the nubs don't move the mouse or anything but after trying to figure out how to compile this I eventually got xorg showing something. Took a lot of work though mind you to work out what I needed.

The xorg.conf config on that page I linked too is needed as well.

 

[ljones]

Ok I had a bit more of a go at all of this. Haven't done anything for the last day or two as it has been sweltering in the UK. Too hot to do anything much.

I tried installing the tde desktop and also the KDE plasma desktop. Bad news and good news to report though.

The good news? They both run; tde (I only did the most basic install) runs fairly quickly. KDE plasma is somewhat slower.

The bad news? For some reason although I managed to compile the xorg driver in my above post for some reason it dosen't seem to be working 100%. For example in the tde desktop, resizing a window works well enough but moving a window around is a bit slow and stuttery. I do have xorg.conf set up as well so maybe either I don't have the driver quite right or maybe I'm missing something? No idea on that one; answers on a postcard please

Also created a video here though it dosen't show it up so well.

Update: I did notice this error in Xorg.0.log

[   287.648] (EE) OMAP5(0): ERROR: Viv2DEXA: Failed to create gpu
[   287.712] (II) Initializing extension MIT-SCREEN-SAVER
[   287.717] (EE) AIGLX error: dlopen of /usr/lib/arm-linux-gnueabihf/dri/armsoc_dri.so failed (/usr/lib/arm-linux-gnueabih
f/dri/armsoc_dri.so: cannot open shared object file: No such file or directory)
[   287.717] (EE) AIGLX error: unable to load driver armsoc

Though weather or not that is the problem or not I'm not sure; I am thinking that these errors are to do with a missing 3d driver?

ljones

 

[levi]

I'm guessing by the timestamp that those are errors generated at the start of your x session. The CPU presumably at it's most basic level can be useful for blitting random rectangles around the screen, so it might still be used in moving windows around.

Presumably you don't have a file in /usr/lib/arm-linux-gnueabihf/dri/armsoc_dri.so, at the very least that's what the second and third errors are saying. Any ideas how to generate that?

 

[ljones]

I had a look and that file is definately missing. I don't know how to generate it though :-( .

The website the driver is on mentions about compiling a 3d driver; from the website ---> ("This driver only use GC320 2D capabilities to provide X11 acceleration, it does not give any 3D acceleration. For 3D acceleration, you could use https://github.com/TexasInstruments/dri3wsegl which is a DRI3 plugin for PVR SGX 544MP 3D chip available in AM57x.")

....though I wouldn't have thought this would affect 2d (xorg accel)?

Will also leave a copy of xorg.0.log here . I looked through it and noticed this:

[   287.648] (II) EXA(0): Driver allocated offscreen pixmaps
[   287.648] (II) EXA(0): Driver registered support for the following operations:
[   287.648] (II)         Solid
[   287.648] (II)         Copy
[   287.648] (II)         Composite (RENDER acceleration)

That "Composite (RENDER acceleration)" is intresting - it didn't seem to work very well (I did try display compositing, but it was not acceleated - very slooooow!).

ljones

 

[levi]

I had a look and that file is definately missing. I don't know how to generate it though :-( .

Yeah, not surprising. I only really mentioned it in case you knew about it. I wouldn't know more than a quick internet search of the filename to be honest.

FWIW: I don't really consider an xorg installation to be any part of an 'empty' OS install. But if I can help you get that working, I will.

 

[docbroke]

have you installed mesa ? I guess something_dri.so belongs to mesa package.

Also someone with default pyra os can look at the source of armsoc_dri.so using "dpkg-query -S /usr/lib/arm-linux-gnueabihf/dri/armsoc_dri.so".

 

[ljones]

>FWIW: I don't really consider an xorg installation to be any part of an 'empty' OS install. But if I can help you get that working, I will.

Thanks I think I probably named this thread wrong. I wouldn't consider an xorg install part of an empty install either but I guess I thought that it would've been a *lot* harder even to get to this point let alone xorg. My idea all along was to create the empty OS but then build on top of it, type it all up and put it here so if someone else wanted to try it, (maybe its time for another thread) . Its the way I set up my debian x86 box by "building it up".

>Also someone with default pyra os can look at the source of armsoc_dri.so using "dpkg-query -S /usr/lib/arm-linux-gnueabihf/dri/armsoc_dri.so".
It didn't seem to exist on the default pyra install either! Not only is it not present on the default pyra install the Xorg.0.log on the deafult install never references it.

But I looked through the default install file log (Xorg.0.log, default pyra os install) and it really dosen't seem to reference that file. But I did find something intresting.

Default pyra OS:

[    21.925] (II) OMAP5(0): Viv2DEXA: Etnaviv driver found
[    21.925] (II) OMAP5(0): Viv2DEXA: Vivante GC320 GPU revision 5301 found !

The "empty" OS I made:

[   287.648] (II) OMAP5(0): Viv2DEXA: Etnaviv driver found
[   287.648] (EE) OMAP5(0): ERROR: Viv2DEXA: Failed to create gpu

Might something be missing from the driver? I did look into installing mesa although not sure what to install at the moment. Prehaps it isn't even needed or maybe there's a way to compile the driver without it but with that GC320 support?

ljones

 

[ljones]

Still guessing maybe there's a problem somehow with the driver itself. I tried recompiling but it made no diference, but I did see:

src/Makefile.am:54: warning: source file 'viv2d/queue.c' is in a subdirectory,
src/Makefile.am:54: but option 'subdir-objects' is disabled
automake: warning: possible forward-incompatibility.
automake: At least a source file is in a subdirectory, but the 'subdir-objects'
automake: automake option hasn't been enabled.

Going into src/viv2d and building manually with make then make install dosen't change anything.

Maybe there's a newer version of this driver its a driver bug?

ljones

 

[ljones]

Not getting anywhere with this in the end unfortunatly. I have no idea at all on what to do with this driver. :-( . At best I think I might need to compile something like etnaviv for that xorg driver but I am not sure; this is what I found or least that is as close as I can get.

Though something dosen't seem to be right with letux itself. The letux image creator installed a 5.14.0-rc.1-letux-lpae+ kernel on the microsd card but yet there are no kernel source packages (headers) for it in letux. All I see is images and headers for kernel 5.10-0.8-rt. There's something called "linux-image-armmp" but that seems to be kernel 5.10.46-2.

Ok, I'm really confused at this point. Nothing seems to tie up here. ?

ljones

 

[ible]

but_why.gif

it's pretty easy to customize and switch out different display/desktop managers from the normal PyraOS

 

[hns]

Though something dosen't seem to be right with letux itself. The letux image creator installed a 5.14.0-rc.1-letux-lpae+ kernel on the microsd card but yet there are no kernel source packages (headers) for it in letux. All I see is images and headers for kernel 5.10-0.8-rt. There's something called "linux-image-armmp" but that seems to be kernel 5.10.46-2.

I am not sure where you did fid -rt or -armmp? If there is something it is a glitch from transitioning the build scripts.
It is all here: https://download.goldelico.com/letux-kernel/letux-5.14-rc1-lpae/
You can find a debian header package, but preferred is to use the git source tree.
There you can go to src and https://download.goldelico.com/letux-kernel/letux-5.14-rc1-lpae/src/kernel-source.html to move to the git repo/branch/tag
Anyways, there is now 5.14-rc3: https://git.goldelico.com/?p=letux-kernel.git;a=shortlog;h=refs/heads/letux-5.14-rc3
Hope this helps.

 

[EvilDragon]

On the more recent kernels, both the SGX and Etnaviv driver is broken. That's why we stick with a older kernel version for the time being.

 

[hns]

On the more recent kernels, both the SGX and Etnaviv driver is broken. That's why we stick with a older kernel version for the time being.

Is there also a bounty for this?
I may have fixed SGX - at least I can now load the firmware again. Without timeout error reports. On the letux-5.10.y or letux-5.14-rc3 kernels (plus the not yet published fix).
But I have no user-space for really testing more (I did have some kmscube test but it turned out to use software rendering because it works even without SGX driver installed).
What I don't know is if etnaviv is fixed by this as well but it is unlikely.