We've started to order things!


quickcharge functionality (like from qualcomm)

Qualcomm's 'Quick Charge' was a brand name for a method of pulling more power through a USB port than then USB spec allows. They did this with a higher voltage, I believe.

The USB type c effectively supersedes this, allowing significantly higher currents to be drawn to provide the equivalent extra power.

For the charging, the components that must support it are the charger itself, the PMIC (and other power circuitry) and the battery, along with all the traces on the board and the socket coping with the higher load. The SoC itself isn't really involved. I believe that most of this is on the 'main' board?
 
  • Like
Reactions: Gon
If I understand this properly, I think he is just saying the cases he is receiving right now aren't going to be transparent, but that doesn't necessarily mean that the cases for the final order won't be transparent, because wasn't there going to be a small variety of colors? Or is that no longer the case?
 
It would be neat if ED made case kits available later on his shop so we can easily change the color of our Pyras once we get bored. With maybe polls or massdrops for the next batch color. More generally speaking, will all of the parts for the Pyra be available in the store like FairPhone does? Since the community is full of tinkerers, it would be nice to enable people to repair their Pyras themselves.
 
Last edited:
So the troublesome material was a Grammar Nazi joke? I am just trying to figure out what offends people.

There are some very strict laws and rules in Germany regarding the events and symbols used by the nazis. A lot of people still feel guilty/ashamed for what happened even though they had nothing to do with it.. Having been on holiday in Germany many times I noticed that people rather not be reminded of that time and if you see what they do to help foreigners it's obvious they learned from it. Even the wolfenstein games are released without nazi iconography in germany.
 
I wish more of my countrymen learned from and felt ashamed of similar past events, rather than continuing with them or trying to bring them back. I guess if there is no middle ground it is better to react harshly to jokes rather than allow such thing to happen again.
 
Hi, I've been lurking for quite some time, your post got me curious enough to register!
Welcome to the forum!

I assume you are aware that igepv5 works with LPAE and 4GB
Actually I was, yet I had managed to completely forget about that one! It has also been ported to a newer u-boot by rcn:
https://github.com/RobertCNelson/Bo.../0001-IGEPv5-Added-IGEPv5-board-support.patch

I see absolutely nothing noteworthy in it with regard to memory setup. They configure 2 ranks in the geometry, enable impedance calibration for both of them, make some unnecessary changes to LISA section mapping, and inform the kernel. I guess I should just have faith and configure it. :D I got a bit side-tracked by trying to understand the phy init better, trying to get the u-boot equivalent of earlycon working (sigh), etc.

Oh, fun fact: while exploring the ram init code I realized that u-boot-2016.11 on omap5/dra7 entirely neglects to enable ram-side impedance calibration! Whoops :p I'm referring to zq_config bits 30-31 (for rank 0-1), which must be set to make EMIF send commands to the RAM chips to make them calibrate their drivers and ODT. Maybe it accidently got restructured out at some point, haven't checked yet.

mem=2032M@0x80000000 mem=2048M@0x300000000
Via kernel parameters instead of DT... not very pretty, but hey if it works...

I'm guessing they did it this way because they didn't have 98cc4544d65c? ("ARM: dts: Add support for more than 2GB of memory for omap5")

And I think there's the second cpu startup loop and whatever other boot rom stuff is at the 2032-2048
No, I'm pretty sure second cpu goes straight from ROM to linux. My first guess would be that the 16M@0xff000000 is intended for use by the multimedia firmware running on various subsystems. Or maybe it just gets cargo-culted around with the original reason lost in time ;-)

Also n-tuple-check the pin muxing for cke1 and ncs1..
All DDR3 signals have dedicated pins, no pinmux. There's a bit of I/O config for them, but the control signals (cas, ras, reset, we, cs0, cs1, ck0, cke1, odt0, odt1) are all grouped together and use the same settings (in byte at 0x4a002e37).
 
I see absolutely nothing noteworthy in it with regard to memory setup. They configure 2 ranks in the geometry, enable impedance calibration for both of them, make some unnecessary changes to LISA section mapping, and inform the kernel. I guess I should just have faith and configure it. :D I got a bit side-tracked by trying to understand the phy init better, trying to get the u-boot equivalent of earlycon working (sigh), etc.

OK so it should be close to working then :) For the u-boot SPL debugging you need to be careful it still fits into SRAM for the size.

Oh, fun fact: while exploring the ram init code I realized that u-boot-2016.11 on omap5/dra7 entirely neglects to enable ram-side impedance calibration! Whoops :p I'm referring to zq_config bits 30-31 (for rank 0-1), which must be set to make EMIF send commands to the RAM chips to make them calibrate their drivers and ODT. Maybe it accidently got restructured out at some point, haven't checked yet.

Hmmm OK

No, I'm pretty sure second cpu goes straight from ROM to linux. My first guess would be that the 16M@0xff000000 is intended for use by the multimedia firmware running on various subsystems. Or maybe it just gets cargo-culted around with the original reason lost in time ;-)

I think there's also something that then gets copied to DDR. I noticed this looking at the CPU1 startup address. But having code for DDR in DDR would be silly unless there's something that needs to be saved and restored for the second bank separately.
 
I hope she's open-source and DRM free.

Edit: this makes no sense, move along, nothing to see here.
 
Last edited:
I would not recommend trying to make a modern linux system free of DRM (the Direct Rendering Manager), except for displayless systems of course.

I've been trying to Debian Stretch command line only on a server and it's driving me nuts. The install works fine but GRUB won't boot from the hardware RAID unless I include the desktop environment for which Stretch overrides and installs XFCE (and components) even if deselected. Gotta love Debian testing releases. I'll have to drop back to Jessie for now I guess. Yes - topic strayed.
 

Then back onto tech topics from above then?

@EvilDragon If the opportunity arises as parts arrive, pictures of said box/pile of parts are always welcome.

@zmatt Even if I don't understand 90% of what you're talking about, the 10% I follow helps to educate me, and likely others, around the process itself. Any updates you have the opportunity to provide - even if they're discussing paths taken in error - are always welcome. Also, since you have in your possession one of the very few Pyra prototype handhelds in existence, we would all love to hear any thoughts you have around it. Frankly, your work would merit it's own blog in the Pyra OS discussions area if you chose to do so.

Thank you to everyone working the project!
 
Back
Top