Contributing to PyraOS

[EvilDragon]

The charge circuit should support up to 2A. Right now it looks like the configuration is a little funky. The battery does not appear to charge fully and I haven’t been able to make measurements and fully characterize this yet. More to come once I’m able to do this.



Ok that sounds good. I see in the TRM that there is an option to boot from SD and fall back to eMMC, then to USB if no bootloader is found. This may be a good way to configure the boot pins if it’s not already configured this way. This way it will fall back to eMMC unless there’s a bootable SD loaded.

Is there currently a method in place for flashing the eMMC? I remember ED saying this was not yet implemented yet but I could be mistaken. If not, a flashing SD image may be a simple solution. Basic bootloader and kernel that automatically starts up, partitions eMMC, and flashes when booted with this SD card in.

Flashing via a USB/serial boot option would probably be best, but I haven’t found any good information about the OMAP5s serial boot process. If you have any documents describing this that would be awesome

Just a quick reminder: The MicroSD / eMMC is special.
The OMAP5 only supports three MMC-Devices - and these are the two big SD Card slots and the eMMC/MicroSD.

The eMMC/MicroSD have a switch where you can either connect the eMMC or MicroSD to the third OMAP5 input.

Right now, you can only switch to either one, but if someone codes a driver, it would be possible to make Linux see both devices at once and the driver flips the switch and sends the according data to the proper device.

 

[ToastBucket]

Just a quick reminder: The MicroSD / eMMC is special.
The OMAP5 only supports three MMC-Devices - and these are the two big SD Card slots and the eMMC/MicroSD.

The eMMC/MicroSD have a switch where you can either connect the eMMC or MicroSD to the third OMAP5 input.

Right now, you can only switch to either one, but if someone codes a driver, it would be possible to make Linux see both devices at once and the driver flips the switch and sends the according data to the proper device.

Oh that’s interesting. I didn’t know that. That sounds like it would be a relatively complicated driver as it may have to handle mounting and unmounting the devices for the switch. I’ll check out the schematic.

 

[levi]

I don't immediately see a problem related to mounting and unmounting with this switch. As with any removable media on linux, it's the responsibility of the userspace to mount and unmount drives, and if we ever get to the situation where it'll flick between one and the other rapidly it should be fast enough that as far as even the kernel is concerned they're both connected at once.

Maybe it doesn't work like that though, and it'll connect things up as and when required only, so if you saturate either reading or writing from either for long enough, it can look like an unscheduled disconnect of the other. I'm not sure how the kernel works out a device has been removed though, perhaps the driver has to notify the kernel of that fact so if you just don't do that unless you try to read from a device and it doesn't respond, that'd be okay too.

But we have time to study this and work it out. As far as I know that's always been something we could try down the line, and unless someone's really keen to work it out, it'll likely happen after mass production.

 

[ToastBucket]

I see a few issues here. The first is if power is removed from the device. If power is removed randomly, it depends on the eMMC part itself to determine what happens in this situation. This may or may not be what’s happening, I have to take a look at the schematics. Entirely depends on how this switch works.

The second is caching. Linux caches writes to non-volatile storage. When writing to flash, the write does not necessarily happen right away. If the device is not present when Linux decides to write through the cache, I am not entirely sure what happens. I don’t believe that simply doing a sync before detaching is a way around this as a write could happen after syncing and before detaching. This may work but it doesn’t seem to be a sure thing.

The third is rootfs location. It seems unlikely to me that the rootfs will be stored on an SD card (in the external slot) if the eMMC is being used. The most likely use case it seems is that the OS (+rootfs) will be on the eMMC while extra data will be stored on the other SD cards. If the rootfs is on either the microSD or the eMMC, we can’t reliably disconnect them from the SOC. The kernel driver would need to be pretty clever to be able to know when it needs the rootfs present and when it doesn’t.

Based on these, I don’t think the switch driver is particularly viable, or at least worth the effort. We’ll see though, maybe someone else has some good ideas on how to make this work.

Another note is if the bootloader is to be loaded from the eMMC, it needs to be properly connected before boot so that the bootROM can appropriately find the bootloader.

 

[hns]

There is a script that ejects one and mounts the other one:
http://git.goldelico.com/?p=letux-k...2;hb=df2f370eb2449d06df8825eda109f5a76a2fb12a

The really good solution should be to make the kernel present two mmc interfaces to user-space, capture mmc read/write requests from either one and multiplex them into the single mmc interface provided by the omap5 (there are similar drivers in the kernel for i2c multiplexers). This needs a lock/mutex to serialize requests arriving in parellel. Insert/Eject and buffering (sync) etc. should not be a problem since it is not possible to remove the eMMC and very difficult to remove the µSD while the Pyra is running. And the "sync" and umount during power-off makes this driver idle before shut-down.

A non-working sketch for such a driver is here: http://git.goldelico.com/?p=letux-kernel.git;a=shortlog;h=refs/heads/letux/txs02612
It registers two new mmc interfaces but AFAIR it has problems locating the omap5 mmc port to be used. Therefore (and due to low priority of this task) I have not invested time to fully implement the read/write request serialization. Another issue is that we might have different interface speeds and capabilites for eMMC and µSD and have to tell that the omap5 port each time we switch between both. A minor issue may be that the mmc interface names (/dev/mmcblk[0-9]p[0-9]) are not guaranteed to be stable since they depend on asynchronous probing sequence. Maybe udev rules help.

For boot, there is hardware that you can control the switch by a shoulder button until SPL or the kernel takes over active control. This is only required for the rare case that you want to force the BootROM to load the SPL from µSD instead of eMMC. Also note that if a SPL is on the left SD card it will take priority over eMMC and/or µSD by BootROM search order. So you can always insert a bootable SD card for "unbricking" the Pyra if both eMMC and/or µSD SPL/U-Boot contents are damaged.

Regarding boot system I'd assume that SPL and U-Boot are usually only in eMMC and a kernel + basic rootfs are also in eMMC. Each rootfs on µSD or SD can (optionally) come with their own kernel. And U-Boot with some bootscr or initrd+kexec scans for kernels through all known devices, being eMMC, µSD or SD or USB stick in a predetermined sequence (or user-configurable). AFAIR the Pandora does it the same way with SPL(MLO) and U-Boot in NAND.

 

[Askarus]

It's not very well tested.
ED seems to have an issue where it takes 45 minutes to install, while on my pyra it does it in 3 minutes.
(Haven't looked into it, but i think it's to do with the date on the pyra not being set properly, and it giving a warning for the date being in the future for each file extracted.)
I did try having it just dd the image directly to emmc, but that was actually slower than extracting the .tgz to it

I manually flashed the Pyra OS to the emmc right now.
It took about 5 minutes from a SanDisk Ultra micro SD.

 

[docbroke]

A minor issue may be that the mmc interface names (/dev/mmcblk[0-9]p[0-9]) are not guaranteed to be stable since they depend on asynchronous probing sequence. Maybe udev rules help.

Can we use UUID instead of /dev/mmc*. Mount command supports that with "mount -uuid". For unmounting we may use directory instead of device, "umount /mnt/<sda?>". Although we have to find out UUID first, which shall be different in all the pyras.


As ToastBucket has already said, I too feel that unmount rootfs everytime while using microSD card doesn't feel very stable, especially considering that microSD card itself will mount somewhere on rootfs. Like we unmount "/" to mount "/home" assuming emmc mounted at / and microSD at /home.

 

[matzesu]

Quite Interessting to read about the Progress on Pyra Software Development, but its a bit sad that i only understand half of the things..
Mybe thats the Reason why i am only a Consumer and dotnt be a Developer.. ^^

 

[ToastBucket]

As ToastBucket has already said, I too feel that unmount rootfs everytime while using microSD card doesn't feel very stable, especially considering that microSD card itself will mount somewhere on rootfs. Like we unmount "/" to mount "/home" assuming emmc mounted at / and microSD at /home.

After reading what hns wrote, I’m not convinced that a mount/unmount will be necessary. It will be managed at an even lower level than that (we can’t unmount the rootfs anyway). But it will still need to be managed such that the right device is attached at the right time and the kernel knows that the microSD is actually there, but temporarily unattached, or not there at all. So for this we may need to intercept the MMC drivers card detect interrupt system or polling routine to trick it into thinking the card is there when it’s not.

We also run into an issue with context switching. Worst case scenario we have two contexts switching back and forth where one needs access to microSD and one needs access to eMMC. Now the mux needs to be flipped for each context switch to be complete reducing performance (once again depends on hardware how bad this will be). We also have two cores, so there may be two kthreads running simultaneously, one in each core, where one needs eMMC and one needs microSD. In this scenario we completely lose multi core performance as each core will be blocked until the other core gives up the bus.

In my opinion, it seems most efficient to drop the microSD support for now and focus on the rest of the essential items left for development. Then once the kernel is in pretty good shape start looking at this. The viability of getting this working seems like a solid maybe to me, and the difficulty development level of this seems very high. Others may disagree though, in which case great! The driver skeleton is already there so they’re able to start playing with it

 

[Eight Bit]

It would already be nice if a 2nd OS could be booted from the mSD. It can be selected as a boot device apart from the eMMC I presume?

 

[docbroke]

I think booting 2nd OS from microSD is possible, but in that case rootfs will be on microSD and eMMC will be unavailable for use, similarly when booting main OS from eMMC microSD will not be usable. This is probably most efficient way to use both eMMC and microSD card. Using both at the same time or copying from eMMC to microSD or vice versa is too complicated unless someone is able to write some driver that can fool the kernel in thinking that both devices are available and when kernel attempts to read or write to one of the device driver changes the switch appropriately.

 

[levi]

Yes, either eMMC or the microSD (if you put the OS on there) should be available, so that if the emmc ever dies you can replace it with a MicroSD card. The idea to be able to access both at the same time was a back of the beermat kind of idea, and hopefully nobody's expecting it for when they get their Pyra first. It was always later on kind of stuff, that said, I have nothing against trying to work out how it might work here if you have the bandwidth to cover it.

 

[God Ginrai]

The original reason for the internal microSD slot was so that we could boot our main OS from there if we didn't want to stress the NAND, so it should definitely be possible to boot from it. I'm not saying this should be top priority, (as things like getting the basic hardware and windowing system working take priority) but this is definitely something that shouldn't just be dropped as @ToastBucket is suggesting...

-God Ginrai

 

[levi]

ISTR we've already had confirmation that the Pyra as is can boot from MicroSD or indeed any of the other SD slots, and perhaps a USB device inserted into the appropriate port at the back. I can't remember off the top of my head where I read that though, so I don't know if it's just a deduction from the facts all lines have been tested and uboot allows booting from anything it can see, or if anyone's actually tried it out yet.

 

[ToastBucket]

ISTR we've already had confirmation that the Pyra as is can boot from MicroSD or indeed any of the other SD slots, and perhaps a USB device inserted into the appropriate port at the back. I can't remember off the top of my head where I read that though, so I don't know if it's just a deduction from the facts all lines have been tested and uboot allows booting from anything it can see, or if anyone's actually tried it out yet.

Yep, as long as there’s a driver in U-Boot, it can boot from it. Any of the devices are bootable (not positive about USB but I’m pretty sure), it’s just a matter of configuration. Sounds like U-Boots already configured to check in a couple spots by default. If you want to do something specific, you’ll need to configure it yourself. But hey that’s why the source is available

It’s definitely possible to boot from either eMMC or microSD. According to HNS, there is already a hardware configuration to do this by holding a shoulder button, though this could also be configured by U-Boot as well. Switching between them at runtime to use both at the same time, however, is not trivial. Particularly if the rootfs is mounted from one of those devices.

 

[EvilDragon]

It’s definitely possible to boot from either eMMC or microSD. According to HNS, there is already a hardware configuration to do this by holding a shoulder button, though this could also be configured by U-Boot as well. Switching between them at runtime to use both at the same time, however, is not trivial. Particularly if the rootfs is mounted from one of those devices.

Quick note: When you force boot from MicroSD via hardware button, it needs to have an MLO and U-Boot on the MicroSD card, of course.

 

[ToastBucket]

Quick note: When you force boot from MicroSD via hardware button, it needs to have an MLO and U-Boot on the MicroSD card, of course.

Yes of course. I’ll be compiling as much of this information as I can into a hacking/customization guide on the Wiki that explains boot process, how to modify it, how to modify the OS, how to contribute, etc. I’m currently populating a README in the build system repository as I don’t seem to have access to the wiki when logging in with my forum credentials. Can you help with this @EvilDragon?

 

[Farox]

@hns
Is goldelico site down? i can't reach the page (mailing list) to look at latest kernel development http://lists.goldelico.com/pipermail/letux-kernel/

 

[rSl]

i can't reach the page (mailing list) to look at

same here

 

[Grench]

I'm glad that the eMMC & microSDXC are being given consideration.

The initial use cases for having the two were:
1. eMMC wear fear. I know there are people who hardly ever booted from eMMC on the Pandora because of fear that it would wear out. I don't know of any actual cases where Pandora eMMC actually wore out - but OK.
2. eMMC size constraint worries. If I recall, the original size for this eMMC was slated to be 4GB to match to the dev board eMMC. Other higher density options were found and 32GB was seen as the right price/capacity point. That makes this concern a bit lessened.

Back then, it was seen as a 'boot from one or the other and the other is invisible for the duration'. The concept of having them dynamically switch was thought up - and we all thought it was a splendid idea if it could work. I don't see this as a critical need at launch though.

My plan: Have the OS exist on both the eMMC and the microSDXC and choose at power-up which one to boot from via the shoulder button. I suspect that boot times will be within a few seconds of each other either way with the eMMC booting a touch faster. Hypothetically I'll be able to boot from either - and if one goes sideways, I should be able to not worry about it in the moment - something to fix at convenience rather than being 'down'. I have a 64gb microSDXC card that migrated out of a cell phone that went to 400GB that will be idea for this initial use - if I fry a 64GB card from the pile, oh well. Some day when we're all confident in stability of the ports I'll upgrade the card.

So - which shoulder button tells the Pyra to boot from eMMC on power-on?

Will the same disk image used to boot from the left SDXC slot work from either if dd copied to it (triggered active) or will there need to be edits post copy?

If booted from the left SDXC card, is there an OS command string we can use to selectively activate one or the other (flip the multiplexer)?

If I have an SDXC card with a working OS image on it in the left SDXC slot, is it still possible to force it to boot from the eMMC or microSDXC? If not, that third copy of the OS might just live on a card stored in the non-booting right SDXC slot (assuming I have the boot on left noboot on right correct...)

An exciting time...