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!
 
@zmatt I stumbled on a TI product support for another TI ARM SoC regarding the intricacies of configuration of 4GB RAM. I'm not sure if it would be any help though as it references an AM5728 instead of the OMAP5432. Both use dual A15 cores and 2-4 M4 cores, so maybe?

https://e2e.ti.com/support/arm/sitara_arm/f/791/p/464238/1670266

On the off chance that TI reuses anything from one ARM CPU to another, it might be worth a look? If not, I apologize in advance for taking your time on a wandering path.
[doublepost=1487901643,1487883341][/doublepost]
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.

Continuing my own off topic here a bit because I'm freekin' thrilled with my admittedly weak GNU/Linux hacking skills. It took me tens of hours, two server chassis & motherboard combinations, etc to figure this out. Many of you would have figured it out in minutes.

I fiddled with it some more. It seems that the Debian Stretch installer sees the USB stick as sda during the install. All partitioning menus then show the HDD (12TB hardware RAID 50 spanning eight 2TB drives in my case) as sdb. The grub installer then writes to grub to boot from sdb, in my case it listed sdb2 in the grub script. And that is where it gets weird. From intramfs I was able to see the partitions on the array, and it listed them all as sda1 through sda4. I edited the grub script and changed the boot partition from sdb2 (written by the Stretch installer) to sda2 and Bob's now my uncle.

Now if there were a way to report Debian Stretch (Testing RC2) bugs without disclosing my email address to the world wide spam distributors, I would submit this one.

Off topic topic [SOLVED].
 
I'm running off internal eMMC and SD card on this netbook at present, and I had a similar problem with sda and sdb swapping round depending on whether I booted from eMMC or from boot CD. This was under ArchLinux though, so modifying my fstab myself was part of the standard install process, and using mount-by-label instead of by-block-device solved any trouble I was having.

It does mean if I plug in a usb device with a partition named like my internal ones my system could fail to boot, or be compromised in a number of interesting ways, so I guess I should probably switch over to boot-by-uuid now I've got it all working to avoid that possibility, but I don't generally use this machine anywhere it could be tampered with so I'll take my time with that.
 
Back
Top