Poll: How much would you be willing to pay for a Neo900 (complete device) with TI DM3730 1GHz/512M-RAM/1GB
Poll Options
How much would you be willing to pay for a Neo900 (complete device) with TI DM3730 1GHz/512M-RAM/1GB

Reply
Thread Tools
joerg_rw's Avatar
Posts: 2,222 | Thanked: 12,651 times | Joined on Mar 2010 @ SOL 3
#2751
Originally Posted by ibero View Post
No offence meant. We can all see that you're the guy holding project together, and we all appreciate it greatly.

As I read it, the bugtracker page you link to says that for security reasons the sys_boot5 pin will be linked to the Hall switch (which senses the state of the battery cover - i.e. battery cover off; sys_boot5=1), and that for additional security it may be possible to hardwire the sys_boot5 low, and hence override the Hall switch and not allow the boot sequence to be modified at all. Is this right?
Yes, exactly. Also keep in mind that SYS_BOOT only defines where from ROMBOOT loads xloader aka MLO. The latter then loads uBoot from arbitrary storage - depending on what's coded into xloader. Finally uBoot loads the kernel and tells kernel where is /-fs. So even without any control over SYS_BOOT[5] the natural method to do "multiboot" is to have uBoot (as well as xloader) loaded from NAND and uBoot then lets user decide where kernel and system should get fetched from. In case xloader in NAND is not found, the ROMBOOT will fall through to next source in boot sequence
Code:
sys_boot5=0:  sys_boot[4:0]=0b10000 --> OneNAND USB UART3 MMC1
sys_boot5=1:  sys_boot[4:0]=0b10000 --> USB UART3 MMC1 OneNAND
So SYS_BOOT[5]=1 is only needed to recover from a broken xloader/uBoot in OneNAND, by booting from either USB, UART3 (HackerBus) or MMC1. While normal changing of boot device (and thus kernel and system) is done in uBoot which can have all the protection against attacks you could think of. And since OneNAND is first in normal boot sequence, if you locked your device there's no way for an attacker to bypass that security in uBoot, except of unlocking the device again which means disassemble and solder which can't get done without losing RAM content. So your encrypted filesystem is secure when your device has a lockscreen enabled :-) The less concerned user would keep the battery lid hallswitch connected to SYS_BOOT[5] to allow forcing of e.g. USB (xloader) boot in case some mishap messed up e.g. uBoot. For added safety you would want your system to erase from RAM any cryptokeys for your encrypted filesystems as soon as a battery lid removal gets detected on a screenlocked device.

cheers
/j

Last edited by joerg_rw; 2016-01-06 at 07:37.
 

The Following 10 Users Say Thank You to joerg_rw For This Useful Post:
Posts: 13 | Thanked: 43 times | Joined on Apr 2015
#2752
Originally Posted by joerg_rw View Post
if you locked your device there's no way for an attacker to bypass that security in uBoot, except of unlocking the device again which means disassemble and solder
I hadn't thought of that obvious risk. It sounds good then that SYS_BOOT5 is not easily accessible without removing the whole board and maybe soldering something first.

Originally Posted by joerg_rw View Post
The less concerned user would keep the battery lid hallswitch connected to SYS_BOOT[5] to allow forcing of e.g. USB (xloader) boot in case some mishap messed up e.g. uBoot.
Why use the hallswitch for that purpose? If we have the Hackerbus, could one of its pins be jumper-able to SYS_BOOT5 instead? Basically so that test automation is easier, like if having to bisect a uBoot bug or something. Not my idea, but its something I've heard from a Linaro developer while visiting ARM so probably has wisdom in it.

Thanks!

p.s. this is also a defence against supply-chain interdiction - the paranoid end-user should be able to re-flash MLO/uBoot - even if the ones in flash are not 'broken' they may be considered untrusted.

Last edited by stevenc; 2016-01-06 at 14:48.
 

The Following 4 Users Say Thank You to stevenc For This Useful Post:
Posts: 79 | Thanked: 719 times | Joined on May 2014 @ Buenos Aires, Argentina
#2753
As I mentioned in the announcements thread
http://talk.maemo.org/showthread.php?p=1493994
we have promising candidates for the flash LEDs, which were one of the remaining few problem spots.

Now the question is what color temperature to choose. Unfortunately, it seems that we don't have much information about the original LEDs. Would anyone happen to be able to measure or estimate the color temperature of the N900 flash LEDs ?

My guess would be "higher is better" (for a flash), but then that's not really my domain, and the experts seem to have a variety of opinions on this, too:
http://www.flashlightuniversity.com/...r-temperature/

Wikipedia suggests 5500 K:
https://en.wikipedia.org/wiki/Flash_(photography)

In any case, we should try to match the color of the original N900 flash.

Worst case, we can always try a side-by-side comparison, but I hope there's a more exact way.

Suggestions ?
- Werner
 

The Following 8 Users Say Thank You to wpwrak For This Useful Post:
Posts: 1,994 | Thanked: 3,342 times | Joined on Jun 2010 @ N900: Battery low. N950: torx 4 re-used once and fine; SIM port torn apart
#2754
Does anybody have RX-51 schematics, and do they help any?

Thank you. Best wishes.
 

The Following User Says Thank You to Wikiwide For This Useful Post:
Posts: 3,074 | Thanked: 12,960 times | Joined on Mar 2010 @ Sofia,Bulgaria
#2755
Originally Posted by Wikiwide View Post
Does anybody have RX-51 schematics, and do they help any?

Thank you. Best wishes.
No idea about anybody, but google has it :P

http://plan9.stanleylieber.com/hardw...schematics.pdf
__________________
Never fear. I is here.

720p video support on N900,SmartReflex on N900,Keyboard and mouse support on N900
Nothing is impossible - Stable thumb2 on n900

Community SSU developer
kernel-power developer and maintainer

 

The Following 7 Users Say Thank You to freemangordon For This Useful Post:
joerg_rw's Avatar
Posts: 2,222 | Thanked: 12,651 times | Joined on Mar 2010 @ SOL 3
#2756
also see http://wiki.maemo.org/N900_Hardware_Schematic
/j

ps: ooops, stale links

Last edited by joerg_rw; 2016-01-09 at 00:13.
 

The Following 7 Users Say Thank You to joerg_rw For This Useful Post:
Posts: 79 | Thanked: 719 times | Joined on May 2014 @ Buenos Aires, Argentina
#2757
Originally Posted by Wikiwide View Post
Does anybody have RX-51 schematics, and do they help any?
The ones I know unfortunately don't contain part numbers.

Also
http://www.electronicproducts.com/No...e_text-90.aspx
knows the price has nothing else to say but "Primary Camera Flash - High Intensity White".

A search for that would lead us here
http://www.carclo-optics.com/optic-1...ntensity-white
But no, that one is rather far off

- Werner
 

The Following 2 Users Say Thank You to wpwrak For This Useful Post:
Posts: 72 | Thanked: 184 times | Joined on Apr 2011 @ Germany
#2758
Originally Posted by wpwrak View Post

Now the question is what color temperature to choose. Unfortunately, it seems that we don't have much information about the original LEDs. Would anyone happen to be able to measure or estimate the color temperature of the N900 flash LEDs ?
I just did a quick & dirty test (rather unscientific) by taking a direct photograph of the n900's LED with a DSLR and setting white balance manually in rawtherapee (you basically specify a region that is supposed to be white and it gives you the color temperature then). I get about 5600 Kelvin, so 5500 does seem reasonable. Please keep in mind that this is in no way a calibrated measurement, but it should give you an idea.
 

The Following 12 Users Say Thank You to Oblomow For This Useful Post:
Posts: 79 | Thanked: 719 times | Joined on May 2014 @ Buenos Aires, Argentina
#2759
Originally Posted by Oblomow View Post
I get about 5600 Kelvin, so 5500 does seem reasonable.
Great, thanks a lot !

I currently have my eyes set on the L130-5780002011001 with 5700 K and a minimum CRI of 80%. CRI is something new I found:
https://en.wikipedia.org/wiki/Color_rendering_index

Of course, two parameters are still a very course approximation of the actual spectrum. But you'd probably need serious lab equipment to determine that. (A comparison between two LEDs would be easier, though, since any systematic errors of the test setup would affect both measurements in the same way. Joerg suggested using a prism. You'd still need a proper lab setup, though, if only to make sure the geometry doesn't change between tests.)

- Werner
 

The Following 5 Users Say Thank You to wpwrak For This Useful Post:
Posts: 72 | Thanked: 184 times | Joined on Apr 2011 @ Germany
#2760
Originally Posted by wpwrak View Post
Of course, two parameters are still a very course approximation of the actual spectrum. But you'd probably need serious lab equipment to determine that. (A comparison between two LEDs would be easier, though, since any systematic errors of the test setup would affect both measurements in the same way. Joerg suggested using a prism. You'd still need a proper lab setup, though, if only to make sure the geometry doesn't change between tests.)

- Werner
There's a nice instruction on how making a spectrometer out of cardbox and a DVD-R as a diffraction grating:
https://publiclab.org/sites/default/...ni-spec3.8.pdf
Using a good camera, it seems possible to get surprisingly good results from this:
https://publiclab.org/notes/cfastie/...ometer-testing

So, if you're a bit into that stuff, it could be fun to build one (I feel a bit tempted to do this myself now ).

But the most pragmatic solution probably is this: get a colorchecker chart, take a raw image on the n900 with fcamera using LED illumination, compare using a standard white balance setting, pick the LED closest to the original one. Just from the spectrum, the effects of different LEDs could be a bit hard to predict, because of the color filter array on the sensor and its transmission function.
 

The Following 7 Users Say Thank You to Oblomow For This Useful Post:
Reply

Tags
neo900, thank you!

Thread Tools

 
Forum Jump


All times are GMT. The time now is 14:09.