Contributing to PyraOS
- Thread starter ToastBucket
- Start date
That's because we have more MMC devices than the OMAP5 supports.
Most SoCs support 1 or 2 MMC devices, the OMAP5 supports 3.
However, we have four: the eMMC, the MicroSD and both SD Card slots.
That's why we need to share one of the MMCs with two devices.
In our case, the eMMC and the MicroSD slot.
We're doing that using a MUXer, so with a clever drive that switches between the two devices, it's possible to use both at once.
At the moment however, we can only manually switch between the two, as no driver exists.
Flashing is not an issue, as only the MicroSD slot isn't enabled when the eMMC is active.
I don't have a BeagleBone Black, but I doubt it uses more than 3 MMC devices.
Most SoCs support 1 or 2 MMC devices, the OMAP5 supports 3.
However, we have four: the eMMC, the MicroSD and both SD Card slots.
That's why we need to share one of the MMCs with two devices.
In our case, the eMMC and the MicroSD slot.
We're doing that using a MUXer, so with a clever drive that switches between the two devices, it's possible to use both at once.
At the moment however, we can only manually switch between the two, as no driver exists.
Flashing is not an issue, as only the MicroSD slot isn't enabled when the eMMC is active.
I don't have a BeagleBone Black, but I doubt it uses more than 3 MMC devices.
ToastBucket
Very Active Member
The eMMC can be flashed a variety of ways. A simple way is to load uboot and a kernel into ram and flash it this way. Often this process will be handled over USB, but I believe the Pyra will load from a tester OS booted from SD. The OS will boot from an SD, run a script to test the hardware, and then flash the device if it passes.
levi
Still fresh, damnit!
Indeed, assuming it works how I understand it that is. If it's booted from a full size SD card or a USB device or anything else, it can flip the MUXer to access the eMMC and write to it that way. You only can't flash it using a microSD card inserted under the battery, but in reality, who was going to do that?
ToastBucket
Very Active Member
This should be doable also, there’s hardware logic to boot from the microSD by holding one of the shoulder buttons.
levi
Still fresh, damnit!
Yes, but in that instance the os disappears once you hit the switch. Maybe the OS stub on the SD card could preload the eMMC filesystem into RAM before switching to that filesystem, but it feels to me like such a solution would require a lot of in situ testing before I'd trust it at least.
ToastBucket
Very Active Member
Yes, but in this case we wouldn’t use a full file system. Just an initramfs which is small enough to be loaded into RAM. The initramfs is only loaded with the necessary tools.
This is a pretty standard way to flash via USB/serial. Load the bootloader into RAM via USB/serial and send over a kernel, initramfs, and device tree. Load these into the appropriate spots in RAM and boot the kernel. Then use the standard tools (which have been built into the initramfs) to partition the MMC, create filesystems, and dd in the images. If the bootloader has fastboot support, then all of this can be done without booting a kernel at all.
[doublepost=1567139348,1567117053][/doublepost]Talking about this made me change my mind about the way the build system is building images. I've now updated it so that it generates a 256MB boot.img formatted as ext4 containing the kernel and device tree. It also creates a 3GB rootfs.img formatted as f2fs (contents are 2.4GB). This makes it much easier for flashing to already partitioned media, such as the eMMC, especially if using fastboot (I plan to implement this because its incredibly convenient). It also makes it easier to create a custom partition map on your boot media, or simply have the kernel on the eMMC and the rootfs on external media (this will require some minor customization to the bootloader and fstab). The image is 3GB so you will have to resize the filesystem to fit the partition, though this is fairly straightforward and adds a lot of flexibility.
Check it out here
https://dev.pyra-handheld.com/imagebuild/pyra-tools/commit/3911b0056b424bbcbe179376e943e62534c83fa4
Last edited:
pmprog
DNF (Did Not Finish)
- Joined
- Apr 25, 2011
- Messages
- 4,150
That link 404's here
Grench
Forum Addict!
- Joined
- Oct 3, 2008
- Messages
- 6,629
An ask... might be too early, but something to consider?
Step by step instructions to get from a raw or botched OS Pyra without working OS to a working Pyra with the OS installed to either the eMMC or microSDXC using whatever is the then current PyraOS.
Step by step instructions to get from a raw or botched OS Pyra without working OS to a working Pyra with the OS installed to either the eMMC or microSDXC using whatever is the then current PyraOS.
ToastBucket
Very Active Member
Yep I plan on creating a good amount of documentation. I really want all of these processes to be easy and available to encourage development by those less experienced. Pyra is a perfect platform to learn. I can make quicker progress on this once I get hardware to test with, and my hardware is currently in the mail so this will happen soon.
Oops fixed.
levi
Still fresh, damnit!
Flash a reflash to an SD card, insert it in one of the SD slots and boot it up. Job done.
ToastBucket
Very Active Member
Yes after my research into the OMAP5 this seems to be the simplest option. What’s important is the exact documentation for how to do this. It’s not exactly obvious for someone unaware, especially because each SOC expects different offsets, programs headers, etc. aTc currently has a script on our GitLab (Pyra-install) though it may be a bit confusing to look at if you don’t have a good amount of experience with this.
My current plan however is load an SD with Uboot and partition/flash the media using fastboot. As far as I know, our uboot doesn’t currently support fastboot but implementing this will be one of my tasks.
Creating an image file that can be put onto an SD card with dd, Win32Imager or similar tools which reflashes the Pyra in whatever status it is shouldn't be a big deal.
codenomad
Automation Replicant
I'm still getting a 404 when trying to access the above link.
ToastBucket
Very Active Member
That’s weird I’m not. The repo is public so should be ok. I’ve changed the link to just point at the repo not the commit maybe that will be better I guess.
codenomad
Automation Replicant
That link works, thank you!
levi
Still fresh, damnit!
I checked it after you said you'd fixed it, and your post wasn't actually marked as being edited at all. I guess you omitted to hit submit after changing it?
ToastBucket
Very Active Member
That’s likely!
ToastBucket
Very Active Member
Alright, so I finally have hardware and have made some pretty solid headway on the bootloader. Currently the bootloader is using boot.scr files to guide the boot process. Personally I think it would be a bit easier to use a uEnv.txt for loading the environment. Its a lot more friendly to hacking. What would you guys prefer?
levi
Still fresh, damnit!
I think we used boot.scr files on the Pandora. I never understood what they were, so if uEnv.txt can do the same thing but be readable to someone at least, then that'd be better I guess.
