Contributing to PyraOS

hns · Sep 19, 2019

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 · Sep 19, 2019

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 · Sep 19, 2019

ToastBucket said:
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 · Sep 19, 2019

Ah so maybe extlinux is a good thing to keep and have the boot script be modified by PyraOS.

ToastBucket · Sep 22, 2019

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.

levi · Sep 22, 2019

Thus far, we've mostly been collating these kind of updates via the pyra-kernel mailing list. Are you subscribed to it yet?

ToastBucket · Sep 22, 2019

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 · Sep 22, 2019

levi · Sep 22, 2019

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.

NetBLOKS · Sep 22, 2019

I really like reading about it too, so I would appreciate it, if you could still post it here and the mailing list.
Thanks a lot!

ToastBucket · Sep 22, 2019

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 · Sep 27, 2019

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 )

ToastBucket · Sep 27, 2019

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 · Sep 27, 2019

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 · Sep 27, 2019

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 · Sep 27, 2019

ToastBucket said:
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 · Sep 27, 2019

Thanks aTc. I’ll look into this further this weekend.

pmprog said:
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.

hns · Oct 31, 2019

hns said:
wget -O sgx.tar.xz https://packages.pyra-handheld.com/images/extra/sgx.tar.xz

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?

ToastBucket · Nov 1, 2019

Perhaps here

kernel / omap5-sgx-ddk-linux · GitLab

DragonBox Pyra - GIT Repositories

dev.pyra-handheld.com

Or here

packages / omap5-sgx-ddk-um-linux · GitLab

DragonBox Pyra - GIT Repositories

dev.pyra-handheld.com

Perhaps we should work more closely with the AM57xx implementation if it differs. This SOC is very similar to the OMAP5, with the main differences being its DMA mechanism if I remember right.

hns · Nov 2, 2019

ToastBucket said:
Or here

packages / omap5-sgx-ddk-um-linux · GitLab

DragonBox Pyra - GIT Repositories

dev.pyra-handheld.com

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.

Contributing to PyraOS

Well-Known Member

Very Active Member

Advanced Member

Very Active Member

Very Active Member

Still fresh, damnit!

Very Active Member

tealifted

Still fresh, damnit!

Finally on-board

Very Active Member

Very Active Member

Very Active Member

DNF (Did Not Finish)

Still fresh, damnit!

Very Active Member

Very Active Member

Well-Known Member

Very Active Member

Well-Known Member

Similar threads