Finalizing everything!

[EvilDragon]

1. Is it possible to charge the battery with two USBs and power the pyra with last one?

That depends on what the charger chip can do, which we're still checking.

There is one huge difference to Pandoras power circuit though:
On the Pandora, when a battery is inserted, the power ALWAYS goes through the battery (that's why the Pandora doesn't boot if the battery if flat even with an AC adaptor connected).

On the Pyra, the charger circuit powers the unit and uses the rest to charge the battery.
If the new charging chip can handle two USB ports at the same time, it could charge the battery faster.

One way to reduce cost is to add spacers to the pandora batteries and ship with those.
It uses existing stock, and offers a lightweight option for people who don't go (star-) trekking.

Not really. We already own 3000 Pyra batteries and only have about 300 - 400 Pandora batteries left.
And that plastic part would need an extra mold which costs more than it's worth it.

I think it's better if we just create the design and everyone who wants to use it can print it himself.

BTW: We already checked: Pandoras battery can power up the Pyra when it's aligned properly, so that plastic frame would work.

There's more than memory in the physical address space. All embedded hardware periphials like GPU, SPI/I²C controller, GPIO etc. etc. is mapped into the physical address space. This is the reason why 32-bit x86 systems can't address more than 3-3.5 GB of RAM without PAE, there's other shit in the way.

I thought the limit for 32bit systems (even x86) WAS 4GB?
Windows only could use 2GB, with some boot parameter it could use 3GB, but Linux always could use the full 4GB on a 32bit system, AFAIR.

 

[TrashyMG]

One question. Would it be possible to create a solution that deactivates one half of the 4GB RAM for Power saving purposes ? Maybe with a switch on the CPU- Board. So that you can choose between full and half Memory.
Or is it allready to late or to complicated in this stage of development ?

This most likely couldn't be done on the fly, setting this up is usually done somewhere on start up. Also it may save a little power, but the unused DRAM chips will still draw some power as they would still cycle if they're used or not.

 

[EvilDragon]

This most likely couldn't be done on the fly, it's usually done somewhere on start up. Also it may save a little power, but the unused DRAM chips will still draw some power as they would still cycle if they're used or not.

Yes, it's being configured in the MLO.
Though Nikolaus plans to scrap U-Boot but use the MLO to boot a mini-kernel in the future that configures the system (and already has graphical output for a boot menu), but that's not yet done.
And I think that the DRAM still needs to be configured in the MLO.

 

[milkshake]

Woop for 4gb

Sent from my Nexus 6 using Tapatalk

 

[slaeshjag]

I thought the limit for 32bit systems (even x86) WAS 4GB?
Windows only could use 2GB, with some boot parameter it could use 3GB, but Linux always could use the full 4GB on a 32bit system, AFAIR.

In the windows world, "PAE" is something enterprise that needs to be enabled explicitly, is only available in pro-versions and is generally unstable. Linux doesn't give a shit and most distros automatically install a PAE kernel when it detects a system that could benefit from it. With PAE, you could address up to 64 GB ± mapped IO IIRC, on a 32-bit system.

 

[Letalis Sonus]

I thought the limit for 32bit systems (even x86) WAS 4GB?

It's not a RAM limit, it's an address space limit - memory addresses are used to access more than just the RAM. The actual RAM limit depends on the system and has always been less than 4GB (usually something between 3 and 3.5).

However, pretty much every x86 CPU since the Pentium Pro and Athlon (exception: some Pentium-Ms - damn you, Intel!) support the PAE extension, which means they have a larger physical address bus (originally 36 bit). Windows does support more than 4GB RAM, but they disabled using PAE for that on the consumer versions "for compatibility reasons", so you have to either switch to 64bit or buy the more expensive server versions - the more RAM you want to use the more expensive is the version you need, of course - not sure if that's still the case with the newest versions.

 

[Neelix]

Honestly I would like an option for a 4GB SoC board without having to invest into a cellular capable base unit. But I guess we can't have everything...

Given that the RAM chips are on the daughterboard and the 4G chip is on the main board, it should be trivial to offer both 2gb and 4gb versions of both the wifi and non-wifi editions by mix and matching PCBs.

-Neelix

 

[TrashyMG]

Given that the RAM chips are on the daughterboard and the 4G chip is on the main board, it should be trivial to offer both 2gb and 4gb versions of both the wifi and non-wifi editions by mix and matching PCBs.

-Neelix

I do know that and sure it's trivial in that sense. Right now EvilDragon has to deal with many variations of hardware already, adding two different SoC boards to the mix may complicate the assembly and ordering process. who knows It may not be as bad as I think it is.

 

[Yoyobuae]

OK, I'll be that guy and point out that taking away half the memory chips will halve memory bandwidth. That will obviously decrease active power consumption, just not energy per bit.

*hides*

But OMAP5 is dual channel, right? So two memory chips would already populate both channels (and make use of all available memory bandwidth).

 

[slaeshjag]

It depends on how the chips are connected. It could be that one memory chip is only enough to populate half of the memory channel, requiring two chips for full bandwidth on that channel. Or they could be banked, in which case removing half the chips would not cause degraded performance.

 

[comradekingu]

It would sure be sweet to be that guy who funds blinkenlights for the have nots.

Edit: My idea for spacers was to attach some of these to the back of a pandora battery:

 

[Urben]

I guess the 4G chip is not on the SOC board which might get updates, right? Id rather buy a 2GB Ram 4G Pyra then, because I dont think 4GB is that important now, but 4G more likely with future situations including future SOCs... I guess the more RAM is not that expensive to bring up a dilemma here.

 

[Kiga]

I want a 4G one with 2gb RAM though.

 

[Pocak]

But OMAP5 is dual channel, right? So two memory chips would already populate both channels (and make use of all available memory bandwidth).

Each channel is 32 bits wide, while the memory chips are 16. I've not seen x32 DDR3 chips, only x4, x8, and x16. Edit: Actually, a quick search says there are x32 packages. I wonder why that wasn't chosen to save space. Anyway, the prototype PCB here has x16 chips. It can't be changed without almost starting from scratch.

The OMAP5 does not support using only half of a channel, but I see no reason why it wouldn't work with only one channel populated.

 

[Silent-Hunter]

I don't give an arse how much ram mine has as long as I have either 3G or 4G. XD

 

[ZXDunny]

I have precisely zero use for a 4G system, but many tasks that would probably overrun 4GB of RAM (well, I have one right now that would).

So yay for 4GB RAM and I don't give a toss about phone functions for something that's not a phone.

 

[notaz]

The nub discs work perfectly, and even though the nubs themselves are a bit noisy (you can sometimes hear the springs moving inside), they feel great and moving the mouse is just awesome!

Does rotating the nub disk still destroy the nub itself?
I feel like it's going to be a problem if it's still the case.

 

[AnimatedFreak]

Awesome update! I would love a 4G with 4GB of Ram. Sounds like the perfect device.

 

[levi]

I'm very interested to hear more about the d-pad. I guess you'll need some more software to really be able to test it well, but as soon as someone ports a SNES emulator to it, you could test out doing dragon-punches in SFII. That's my standard test case, and I find I generally hit about 8 out of 10 on my Pandora d-pad; the only d-pad I know that passes that test better was the d-pad on the original (fat) DS, where I could reliably hit 9 out of 10. On an actual SNES pad I only hit it about 50% of the time, so anything better than that is pretty good in my book.

 

[rygD]

Does rotating the nub disk still destroy the nub itself?
I feel like it's going to be a problem if it's still the case.

I think you would have to go to a lot of trouble to turn the nubs. If you are just putting your thumbs on them like you are supposed to I don't see any issue with them not turning. If you try to grab them with your thumb and fingers and turn them, or use some pliers, sure, it could be a problem, but what use case requires doing that?

I could be wrong, and maybe the slight twisting from normal use is enough to destroy them, but I doubt they would have been chosen if that was the case.