A bug, booting up and a huge forum migration


Thanks!


Appreciate it!


Don't suppose while everyone's here - what WIFI is it going to have?


I'm after a wifi with monitor mode (old school aircrack etc).


I know I can use a USB, but wanting to know what internal is so I can see if monitor mode will work.
 
Last edited by a moderator:
I will hold off on eating my PCB until we see if chocolate cases will fit them.


Thanks for the updates.
 
Why should it be removed? You can either boot from MicroSD card or internal eMMC.

So if I understand correctly, one can have the OS on a MicroSD card while the eMMC remains dormant and serve as a backup OS should something happen to the one on the MicroSD card or something happens to the card itself?


Also out of curiosity, would there also be a way to utilize both, where the OS is on the eMMC and the MicroSD card used for general MicroSD reading rather than for an OS/booting? Does it only boot from it if it detects a bootable volume (IE, it comes before eMMC in the boot device order, sorta like how an optical or floppy drive could in a PC?) Or does the eMMC actually get deactivated when an MicroSD card is inserted?


Thanks and hope you're feeling better.
 
So if I understand correctly, one can have the OS on a MicroSD card while the eMMC remains dormant and serve as a backup OS should something happen to the one on the MicroSD card or something happens to the card itself?

You could, but why? The eMMC should be large enough and faster than the MicroSD, not much reason to use the SD.  The microSD is there as a backup in case something happens to the eMMC or if you want to experiment with different OSes.

would there also be a way to utilize both

No, the eMMC and uSD slot are literally the same port on the OMAP5, it's impossible for all practical purposes to use both at the same time.
 
  • Like
Reactions: szr
@WizardStan Thank you for the reply. I didn't quite realize that they used the same port on the SoC. So you're saying it makes more sense to use a MicroSD card to backup the OS that's on the eMMC (and thus using the eMMC for the OS/booting) rather than the other way around? That does make sense to me, especially about it being faster then microSD. Thanks again.
 
Last edited by a moderator:
Well, in theory, it IS possible using both... the switch can live-switch between both, so you could permanently switch between both lines, do the same thing in the driver and create two storages from that.


Nikolaus thought it through, it should work, but that's something that needs to be thoroughly coded and tested.


For the moment, expect to have either the eMMC or the MicroSD card as storage and see it as a bonus if both work at the same time sometime in the future :)
 
I can't really agree with that. Just do 'apt-get install texlive-full'. Then you really wanna have 16GB for rootfs.

The entire Debian repository is 131GB, and that's probably compressed.  If your argument is simply "installing XYZ will make you wanna have 16GB" then I'd just use that same argument to say "install everything, then you really wanna have 256GB for rootfs", which should hopefully be obviously ridiculous.


If you want to make a case that a specific app warrants the need for 16GB then you need to demonstrate that it's something that will benefit a significant number of people.


8GB for a standard OS, carrying the things that 90% of users will need doesn't seem unreasonable.  If you want more space, that's what the microSD slot is for.


I'm currently using 20GB of my hard drive for the OS, and that includes a fairly large /usr/share/doc folder; multiple JVMs, python, and netbeans installs; the Android SDK and TI DSP SDK; other huge development environments, 32 and 64bit versions of most libraries, etc... many things that the average person is unlikely to need, or things that really don't need to be installed to the rootfs.  Take away these things and I think I'm down to about 6GB of legitimate growth in three years.


Strictly speaking, everything else the same, more is better, but everything else is not the same: more space will cost more money.  If it isn't an unreasonable amount then you're going to have to come up with a fairly strong argument to convince many of us as to why 8GB isn't enough.  If it's, like, $20 difference to go from 8 to 16GB then I'm pretty sure no one will complain.
 
On the devboard with a fair amount of development tools, I was closing in on 8GB, why I'd like some wiggle room. Not saying I couldn't live in 8GB of space easily enough, I just would cough up the extra cost to have 16GB.
 
Last edited by a moderator:
Why not just use the internal space for the OS or use a big micro sd card instead..


There are quite inexpensive these days, i mean 32gb should cost some around 20 €/£/$


Or you can put the big dev tools on one of the 2 SD Cards in front of the device..
 
Why not just use the internal space for the OS or use a big micro sd card instead..


There are quite inexpensive these days, i mean 32gb should cost some around 20 €/£/$


Or you can put the big dev tools on one of the 2 SD Cards in front of the device..

Speeds of SD cards vs eMMC can be tremendous different in favor of eMMC.
 
dear flu, please leave ed immideately, thank you!
 
  • Like
Reactions: szr
I like to keep my Linux installs small.  On my x86 laptop my /usr partition is 3.3GB, but I understand even 32-bit ARM code tends to be more compact.  I was happy running most software off PNDs off an SD card on my Pandora, and the Pyra should have faster SD support, so I envisage that will be similar for the Pyra, with web browsers and other big things not in the OS partition, so I'll be more than happy with a 2GB partition.  4GB or more if affordable would simply be the icing on the cake.
 
I don't mind if it's a bit slow, I'm just gonna get a 64-128 GB MicroSD and put the OS on that.
 
I wonder what the difference is booting SZ on a Pandora NAND versus an interface-beating class SD card.  I could test that, but my experience so far suggests booting from Sandisk Extreme III doesn't feel that much slower.


Mind you, that o-droid test was only 53 seconds versus 68 seconds - 15 seconds per boot, or 30% slower.  I'm not sure I could reliably detect that difference in practice without a stopwatch.
 
Back
Top