Contributing to PyraOS

hns

Very Active Member
Joined
Dec 4, 2011
Messages
450
Location
Oberhaching
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.
 

ToastBucket

Very Active Member
Joined
Oct 12, 2010
Messages
242
Location
Seattle
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?
 

Letalis Sonus

Advanced Member
Joined
Mar 5, 2009
Messages
1,286
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.
 

ToastBucket

Very Active Member
Joined
Oct 12, 2010
Messages
242
Location
Seattle
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.
 

ToastBucket

Very Active Member
Joined
Oct 12, 2010
Messages
242
Location
Seattle
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.
 

rSl

i'm not tired. you're tired.
Joined
Nov 19, 2005
Messages
727
Location
homecomputer
 
Last edited:

levi

Still fresh, damnit!
Joined
Oct 6, 2008
Messages
11,348
Location
Somewhere off the coast of the EU
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.
 

ToastBucket

Very Active Member
Joined
Oct 12, 2010
Messages
242
Location
Seattle
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.
 

aTc

Very Active Member
Joined
Apr 25, 2009
Messages
171
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:

ToastBucket

Very Active Member
Joined
Oct 12, 2010
Messages
242
Location
Seattle
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
 

pmprog

Advanced Member
Joined
Apr 25, 2011
Messages
3,883
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
 

levi

Still fresh, damnit!
Joined
Oct 6, 2008
Messages
11,348
Location
Somewhere off the coast of the EU
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.
 

aTc

Very Active Member
Joined
Apr 25, 2009
Messages
171
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.
 

ToastBucket

Very Active Member
Joined
Oct 12, 2010
Messages
242
Location
Seattle
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.
 
Top