Contributing to PyraOS


uEnv.txt can only set variables while a boot.scr can run any u-boot command, e.g. load other files, test for presence of sd cards etc.
LetuxOS for Pyra uses uEnv.txt.
LetuxOS for Pandora uses boot.scr.
Most users don't notice the difference.
 
I am leaning towards continued use of uEnv.txt since it can be easily modified on the fly without needing to mkimage it. One thing I'm not very familiar with is using u-boot to detect and select the correct kernel/dtb/initrd given a few versions. I've never built an embedded Debian device before, so I've always just loaded the one zImage etc. However, with Debian, multiple kernels may be installed from multiple packages. I know aTc is currently using extlinux to select kernels, but this still appears to require manual modification. I believe what I see on Ubuntu machines is a set of kernels with a symlink to the desired one, though I'm not sure how the package manager (or whatever tool is used for this) handles switching between kernels. Anyone have any insight?
 
I believe what I see on Ubuntu machines is a set of kernels with a symlink to the desired one, though I'm not sure how the package manager (or whatever tool is used for this) handles switching between kernels.
Ubuntu just uses GRUB's scripts to handle the version management by regenerating the GRUB config each time a kernel is installed or removed, the symlink is not really used and probably just for backwards compatibility with alternative bootloaders.
 
Ok! So there are some updates here. I have mostly stabilized the bootloader. I have decided on a method of handling user configuration and customization of the bootloader. It consists of a two-phase environment update system. The bootloader first loads boot.txt which defines the paths for the kernel, device tree, and initramfs. boot.txt is mandatory and can be updated by a userspace tool or by the apt install phase of a kernel package. The bootloader then loads uEnv.txt which allows the user to redefine any boot variable they want (including bootcmd) to fully customize the boot environment. It is fine to modify uEnv.txt manually (at your own risk of course), however it is not recommended to modify boot.txt as this should be handled by automated processes. You can of course overwrite anything defined in boot.txt using uEnv.txt.

The recent changes to the bootloader have been pushed and included the following:
- bq24297 (battery charger) support
- 2GB and 4GB RAM support (Using old RAM timings, I haven't yet been able to get notaz's improvements working).
- New boot environment system

I've also started building a set of guides. I only just started 20 minutes ago, so they are relatively minimal at the moment but should help people get started using the new bootloader and flashing PyraOS in general.
https://dev.pyra-handheld.com/imagebuild/pyra-docker/wikis/home

Anyone out there with prototypes, I'd really appreciate help testing and bug reporting. I only have one version of the hardware and I know there are multiple out there. I'm pretty sure that everyone is getting the final hardware version at this point, and as such I'm not really focusing on supporting old versions. Someone please let me know if this is a problem though.
 
No I’m not subscribed to the mailing list. I should be I’ll get on that. Mostly I’m trying to bring the information to the general community and users rather than just developers. This is why I’m starting to build the wikis. They’re on gitlab for now since the current wiki access is broken at the moment. Once im able to access and update the normal wiki I’ll move everything there.
 
 
Last edited:
I don't disagree with stuff like this being posted here. But the mailing list has some good people on it who don't frequent these boards, whose input might be valuable, so I'm thinking more like post it to both.

The only question I have is whether bootloader stuff is considered interesting to users of a pyra *kernel* mailing list, but my feeling is yes.
 
Actually, digging in a bit more, it looks like the extlinux configurations are already being generated by the debian package. From what I can see, it has similar functionality allowing a user.cfg to overwrite the automatically generated configuration. Unfortunately, this doesn't seem to have as much configurability as using environment files, but the package manager may already be configured to use this method. If this is the case, continued use of extlinux is probably best. @aTc, can you fill in here? I think you set this up.
 
It's done mostly through https://dev.pyra-handheld.com/packages/pyra-kpkg , that runs the postinst scripts when a kernel package is installed, and puts everything in the right place for extlinux to work.
Default kernel options are set in /etc/default/pyra-extlinux, which are then used by /usr/sbin/pyra-extlinux-update to generate the config files in /boot/extlinux for all the kernels.
user.cfg isn't touched by any of those scripts, so that's a place to put your own weird custom configs.

extlinux is also a bit more flexible than the somewhat hardcoded uenv.txt config, since it will just scan through all available devices for a config file to boot from, and use the settings from that.

And dtbs are in the linux-image.deb , they're stored in /usr/lib/linux-image-$version by default , I copy them to /boot/dtb using the same postinst script ( https://dev.pyra-handheld.com/packages/pyra-kpkg/blob/master/kernel/postinst.d/zz_pyra-kernel )
 
Last edited:
Ok I’ll update my bootloader to use extlinux like the old one does. I want to keep some user configuration of uboot environment in there, so perhaps I’ll have it run a uEnv file if it finds one before running extlinux, since to my knowledge, extlinux doesn’t seem to support modification of any uboot environment variable, just bootargs and kernel locations. Being able to easily modify uboot environment is very powerful as it allows you do do essentially anything.

So do you create a separate package for dtbs? When I build the kernel the dtbs aren’t included in the package. See the linux target in my makefile to see how I’m doing it.

https://dev.pyra-handheld.com/imagebuild/pyra-tools/blob/master/build.mk
 
Quick question, whilst the battery bit is being worked on... If the Pyra is turned off, but plugged in to charge, will it run a minimal system to just control the battery charge, or will it force booting into the full OS like the Pandora did?
Doesn't matter if it's not available at launch, but i was wondering if it was possible with the hardware setup
 
At the very least it's been reported that a Pyra can charge the battery with the CPU board removed, so no minimal OS or anything, the circuitry is enough to control charging safely. I'm not sure what happens if you plug in a switched-off complete pyra though to be honest, and whether some kind of minimal OS would actually be of any use; maybe you'd need one to read the configuration if you'd set your battery to only charge to 80% or whatever.
 
So do you create a separate package for dtbs? When I build the kernel the dtbs aren’t included in the package. See the linux target in my makefile to see how I’m doing it.

https://dev.pyra-handheld.com/imagebuild/pyra-tools/blob/master/build.mk

No, I just use make deb-pkg , and all the dtb end up in /usr/lib/linux-image-4.19.75-letux-lpae-pyra/ .
I just tried it with make bindeb-pkg in case that made a difference, but that also puts the dtb in linux-image-4.19.75-letux-lpae-pyra_4.19.75-letux-lpae-pyra-1_armhf.deb
Maybe you're missing some tools and it skips the dtb compiling.

The exact command line to compile the package I use is "make -j 6 ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- KBUILD_DEBARCH=armhf bindeb-pkg" , which is running in a debian buster nspawn on an x64 machine.
 
Thanks aTc. I’ll look into this further this weekend.

Quick question, whilst the battery bit is being worked on... If the Pyra is turned off, but plugged in to charge, will it run a minimal system to just control the battery charge, or will it force booting into the full OS like the Pandora did?
Doesn't matter if it's not available at launch, but i was wondering if it was possible with the hardware setup
Pyra charging is fully handled in hardware. The charger chip will operate autonomously with some default settings until the bootloader runs and configures it for fast charging. The charger stays powered by either USB or battery at all times, so the only time you may be restricted to slow charging is when you plug in with no bootable SD/MMC or no CPU. There are known issues trying to charge with no bootable device, as the omap keeps trying to boot, finds nothing, and tries again. This just sits and sucks power and prevents charging.
 
Hi, it is a long time that we made this work on the Pyra and now I am trying to repeat it
with official TI sources loaded from git://git.ti.com/graphics/omap5-sgx-ddk-um-linux.git

Unfortunately I did not yet succeed on OMAP5 (AM335x / BeagleBone works).

And I tried to fetch all branches available on the TI git and compare the binaries.
But they all differ from the unpacked sgx.tar.xz

So my question: where can i find the original source of the sgx.tar.xz?
 
  • Like
Reactions: rSl
Or here
Yes, this source repo matches the binaries!
And now it clarifies my problem on locating it on the TI git server. It is there, but buried under newer patches which change some files I was looking for. So TI has newer versions than we use (which may break the magic omap5432 modification of https://dev.pyra-handheld.com/packa...mmit/543c0d0bc7f9472368e58d6e037a1cf35de27da3).
Anyways, the commit hash 3af51eb8 is available in several TI git branches so that we can use this as reference to an official source repository.
And I was able to make it work.
 
Back
Top