Finalizing the PCBs

[rygD]

great news ed!!!! I keep us posted.
And some vids on youtube would be nice to show us the PCB, or a video making the first preorder console

They will probably be figuring out the most efficient way to assemble them at first. It is probably best to wait to make the video until the 109th Pyra.

Are bright pink cases still on the table?

If I paint my clear case it is likely to include something resembling bright translucent pink around the logo plate area.

 

[ible]

or a fast-motion video of ED assembling the first 100. see him start out slow, then get faster...

then heavy breathing gets faster...

 

[erico]

By the way he recorded video with one hand and messed with the pyra parts with the other hand on the last video...I take assembling it should be lightning fast and easy.

 

[Tanasinn]

By the way he recorded video with one hand and messed with the pyra parts with the other hand on the last video...I take assembling it should be lightning fast and easy.

This. I really enjoyed the first assembly vid and the case build seems like a walk in the park.

As soon as I am able to order the transparent case, I am gonna try my hand at applying dye to it to see how well it can bind. If this goes well, I'll make a separate post on how to go about it. From what FA's materials suggest, it can't be a set and forget dyeing process. It'll have to be constantly monitored due to some of the chemicals used in initial prep. I can also make molds and pretty much be down to make custom cases on our end. I can't promise many on hand so its empty stock until someone comes forward and has an idea they want to make. if the thickness between certain parts are just right, we can encase stuff like flower pedals or vinyl stickers [so they would not be damaged on the surface area. I am too excited on the design aspect of this.

As for my order, I do plan on mixing a black case with transparent similar to how nintendo does the design on the 3DS [save for the LBW one] transparent outside with black inside for contrast.

 

[elwing]

Don't get yourself fooled, ED's expert at device assembly... He's like level 9000...

 

[hns]

So, I'm looking forward to someone creating a driver for this.

I have started to hack something:

http://git.goldelico.com/?p=gta04-k...b;hb=48068d5e712157490ca0647922ead9e90e20677f

Currently it is organised as an SDIO client driver (like for the WL1837 WiFi chip). But that seems not to be the right way to properly intercept all mmc block read/write commands. And it tries to match the client device's vendor id while the switch is transparent.

 

[Silent-Hunter]

I have started to hack something:

http://git.goldelico.com/?p=gta04-k...b;hb=48068d5e712157490ca0647922ead9e90e20677f

Currently it is organised as an SDIO client driver (like for the WL1837 WiFi chip). But that seems not to be the right way to properly intercept all mmc block read/write commands. And it tries to match the client device's vendor id while the switch is transparent.

If I have a MicroSD to boot Android from, will this interfere with that?

Also, nice to hear this is theoretically possible!

 

[hns]

If I have a MicroSD to boot Android from, will this interfere with that?

As long as such a driver is included in your Android kernel, it will work. And it must be included, since everyone who wants to provide an Android image (e.g. Replicant) for the Pyra will have to use the Pyra kernel... Not only for this switch but for a lot of other drivers: charger, display, keyboard, ...
It only would make trouble if you use a system that does not use the Linux kernel (e.g. FreeBSD).

 

[matzesu]

On the Topic: "Build your own Clear Pyra", i think its lots more easy to make this yourself than on the Pandora, as you ditnt have anything to solder (Speakers on the LCD Cable) and this Tiny Power Switch ditnt exist on Pyra,
there is only the Shoulderbuttons, the Nub Caps, and the Caple who is a bit more robust than on the Pandora, and the Headsink..
Somethimes ago, i openend the Bottom of my Pandora to fix one Shoulderbutton (the Pad was a bit out of position), and i swapped the under bottompart to create my Black/Silver Pandora, this wasnt that tought as long you take care on the screews
The toughes Part to disample on the Pandora is the lid,

You still needs some experience whit RC Modelling or at least "Kinder Surprise Eggs" or Lego to work on the Pyra, buts its lots easear..

I ditnt want to swap my Pyra Case to transparent as i said it would be cool but not that usefull, and i rather would like to have a pretty tought Pyra whit a Case from the new Company, even if this is Puke Green or Pink,

Or Black

 

[Silent-Hunter]

As long as such a driver is included in your Android kernel, it will work. And it must be included, since everyone who wants to provide an Android image (e.g. Replicant) for the Pyra will have to use the Pyra kernel... Not only for this switch but for a lot of other drivers: charger, display, keyboard, ...
It only would make trouble if you use a system that does not use the Linux kernel (e.g. FreeBSD).

If I was using Android I wouldn't want it to be able to see the internal storage, it might try to write to it.

 

[erico]

That will only depend on the keyboard layout...

 

[Grench]

I have started to hack something:

http://git.goldelico.com/?p=gta04-k...b;hb=48068d5e712157490ca0647922ead9e90e20677f

Currently it is organised as an SDIO client driver (like for the WL1837 WiFi chip). But that seems not to be the right way to properly intercept all mmc block read/write commands. And it tries to match the client device's vendor id while the switch is transparent.

That sounds like only one or the other will be available at boot. I.e. likely the eMMC would be the default position of the eMMC/SDXC switch. Would this preclude booting from the microSDXC? Or would booting from the eMMC be an option to the bootloader menu? But then it would have to be upstream of loading the kernel...

If we can't boot from the microSDXC, I'm OK with that. I plan to boot from the eMMC and then use the microSDXC as a data repository for stuff I want to keep on-hand regardless of what cards are inserted. (data files, music, etc...)

The longer it takes for the Pyra to come out, the cheaper those 256GB microSDXC cards become. Currently they're $129 - which is still a premium over the $77 200GB ones. Of course there are the 400GB cards for $250... Using the microSDXC for 'big' internal storage has become somewhat practical.

 

[mecksg1]

personally i would like to have the clear case inside while having a super Nintendo gray game case as the outer shell of it. i would love that
ED get on to making that right now!!!!

 

[txus]

As long as such a driver is included in your Android kernel, it will work. And it must be included, since everyone who wants to provide an Android image (e.g. Replicant) for the Pyra will have to use the Pyra kernel... Not only for this switch but for a lot of other drivers: charger, display, keyboard, ...
It only would make trouble if you use a system that does not use the Linux kernel (e.g. FreeBSD).

I thought the idea was to have most of the stuff mainline. Has this changed?

 

[mecksg1]

If I was using Android I wouldn't want it to be able to see the internal storage, it might try to write to it.

i though we would all be using IOS on the Pyra so apple can tell us what we can and cannot have

 

[hns]

I thought the idea was to have most of the stuff mainline. Has this changed?

Before getting anything mainline it has to be developed... And the mainlining process can take years, even if your development "just works". So it will not be in mainline first.
[doublepost=1512160670,1512160451][/doublepost]

That sounds like only one or the other will be available at boot.

Yes or no. Depends. If MLO (= SPL = Second Phase Loader) comes from eMMC it still can throw the switch to look for U-Boot on both. This is a similar driver as for Linux but much simpler. Doesn't need to provide both in parallel. But also has to be developed.
Now you may ask if MLO can come from either one? Yes, it can. You can choose by pressing a shoulder button while powering on. But there is no reason to have different variants on eMMC or µSD (unless you are developing or testing something) or eMMC is empty/defective).

 

[WizardStan]

Yeah, why waiting for a case when there is a 3D printer next to me that wants to print one with a wood filament

Oooo, I would run my Pyra at top speed just to get that warm-wood-filament smell all the time

 

[levi]

I wonder if there's a problem with unplanned power outages. Those should be less common on the Pyra than on the Pandora due to its battery measurements actually being incorporated into the design, but I've still had occasions where the only reasonable way to get out of a badly crashed fullscreen process that was hogging the CPU was to yank the battery on purpose. If it was multiplexed to the SD card at the moment power goes down, but that doesn't have a bootloader on it.

I guess that depends on how long the power's out for though. If the system goes cold, then the switch will have reset to pointing at the eMMC I assume, so if it doesn't come back straight away, just pull the power and leave it for a bit longer before putting it back on.

 

[Grench]

I wonder if there's a problem with unplanned power outages. Those should be less common on the Pyra than on the Pandora due to its battery measurements actually being incorporated into the design, but I've still had occasions where the only reasonable way to get out of a badly crashed fullscreen process that was hogging the CPU was to yank the battery on purpose. If it was multiplexed to the SD card at the moment power goes down, but that doesn't have a bootloader on it.

I guess that depends on how long the power's out for though. If the system goes cold, then the switch will have reset to pointing at the eMMC I assume, so if it doesn't come back straight away, just pull the power and leave it for a bit longer before putting it back on.

If I understand correctly, the switch acts as a ganged relay. When power is not applied, the eMMC is connected. When power is supplied to the switch, the uSD is connected. In a power failure scenario, it should default back to the eMMC.

 

[Pocak]

It's a bit more complicated. The mux chip (txs02612) is not just a set of on-off switches; for example, it's also capable of voltage shifting. Without power, it can't drive its outputs, so it's always powered when the Pyra is on.

The storage option is chosen by the logic level at its SEL pin (the mux chip doesn't have any memory element), which comes from a combination of two GPIOs and a shoulder button. I would think that even a short battery disconnection resets the OMAP, so those GPIOs take their default values, and the unit boots as normal from eMMC (or uSD if left-top shoulder is held).