Heilpern, Mark wrote:
If you want to roll your own, with Linux support, check out
http://flash-plaice.wikispaces.com/.
Wow, this is great ! And the one on sump.org is even closer to
what I'm looking for (same hardware, but simpler design).
Thanks a lot !
- Werner
--
Simon Matthews wrote:
Could you tell me the make and model of the new MPU, and maybe some
links to datasheets.
It's the Samsung 2442,
http://www.samsung.com/Products/Semiconductor/MobileSoC/ApplicationProcessor/ARM9Series/SC32442/um_s3c2442b_rev12.pdf
I am intrigued to see how they implement
On Wed, 23 May 2007, Werner Almesberger wrote:
Simon Matthews wrote:
Could you tell me the make and model of the new MPU, and maybe some
links to datasheets.
It's the Samsung 2442,
On Wed, 23 May 2007, Werner Almesberger wrote:
[EMAIL PROTECTED] wrote:
There are a couple of PC-based LAs that work with Linux. Look for the xoscope
project, I think it has links to a couple of such LAs.
Hmm, only the BitScope, which is a nice device, but its digital
capabilities are
[EMAIL PROTECTED] wrote:
There are a couple of PC-based LAs that work with Linux. Look for the xoscope
project, I think it has links to a couple of such LAs.
Hmm, only the BitScope, which is a nice device, but its digital
capabilities are fairly limited. What I'm thinking of is something
like
list.) I haven't played with that
device, but if I had more free time
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Wednesday, May 23, 2007 12:55 PM
Cc: community@lists.openmoko.org
Subject: Re: Few comments after reading
On Wed, 2007-05-16 at 19:55 -0300, Werner Almesberger wrote:
You'll (almost certainly) be able to do this as well: the new MCU
will allow you to specify which NAND Flash area can be written to.
Once this is set, it cannot be changed without a reset. So this
would be a hardware assisted
1. I hope, that there will be made SAR tests and results
will be very
low
Why? It may help with marketing, but the worst it could do
(unless it's several orders of magnitude beyond what current
phones) is make you a bit warm. Non-ionizing radiation is not
a cause of cancer.
5. hav developers though about creating it on kind of x86
compatible
platform ? I know, it could be more difficult to create energy
efficient device, but having PC in pocket (with ability to running
dos, windows after changing SD card) would be more than
excellent
yes, i
I was thinking about protecting memory with main phone
software (like
kernel, boot loader, main apps).
You'll (almost certainly) be able to do this as well: the new
MCU will allow you to specify which NAND Flash area can be
written to. Once this is set, it cannot be changed without
Marcin Wiacek wrote:
So, the scenario can be: spefifying area by virus and getting device to
reset to have full control...
At which time your (still protected) firmware sets the protection
again, and executes the regular code. But yes, if you add an
easily changeable vector before that point,
On Wed, 2007-05-16 at 19:55 -0300, Werner Almesberger wrote:
You'll (almost certainly) be able to do this as well: the new MCU
will allow you to specify which NAND Flash area can be written to.
Once this is set, it cannot be changed without a reset. So this
would be a hardware assisted
Hello,
One additional hadrware suggestion:
6.microswitch for real hardware blocking flashing (to prevent changing
firmware)
Pozdrowienia/Best Regards
--
Marcin Wiacek (www.gammu.org, www.mwiacek.com, I'm looking for a job)
___
OpenMoko community
Marcin Wiacek wrote:
6.microswitch for real hardware blocking flashing (to prevent changing
firmware)
Flash protection is planned for the later this year aka getting
everything right this time model.
The idea is to have an emergency/recovery u-boot in a separate Flash
chip, which can be
Werner Almesberger wrote:
Our current hardware doesn't allow Flash protection to be done
sensibly :-( So software/user input can in fact brick a machine to
the point where the only recovery possible is through JTAG, e.g.,
with the debug board.
I'm not saying this isn't a nice feature.
Why
Ian Stirling wrote:
Why should a phone be better in this respect than a PC?
Well, on the PC, you don't change the BIOS very often, if ever.
Furthermore, the BIOS is in storage that your system doesn't
usually access either.
On the Neo, your BIOS is the boot loader, so every time you
upgrade the
Werner Almesberger wrote:
Ian Stirling wrote:
Why should a phone be better in this respect than a PC?
Well, on the PC, you don't change the BIOS very often, if ever.
Furthermore, the BIOS is in storage that your system doesn't
usually access either.
True, of course, though root can still
Why should a phone be better in this respect than a PC?
[...]
There are some protections, but software is very limited in
what it can do. Also, neither the MCU nor the Flash memory
have any complementary protection mechanisms. (In the next
device, also the MCU will have some reasonably
Ian Stirling wrote:
Werner Almesberger wrote:
And no, I don't think we want to get into DRM ;-)
I really think you do.
No, you don't. OPEN-Moko. You start throwing any sort of DRM in these
things and you will lose much of the community support that the moko needs.
I want to be able to
Ian Stirling wrote:
This is _not_ DRM that stops the owner of the phone doing stuff.
It's DRM that stops users of the phone that may or may not be authorised
users from doing stuff.
Think of it as a BIOS password on steroids.
DRM never worked, and never will. it's a fact of life, get
On Wednesday 16 May 2007 18:46:03 Ian Stirling wrote:
I really think you do.
I want to be able to give this phone to my (hypothetical) employees.
I do not want skilled lazy, employees able to - for example - edit their
GPS logs which corroberate the inspections they are required to do.
This
Marcin Wiacek wrote:
In worst case device should start with default parameters and without
additional apps.
Our idea is that you can at least load a new boot loader, kernel,
etc. over DFU. That's the minimum sane unbricking requirement.
Anything else would require more space. (We may actually
Per-block protection is tricky. There are only very few
companies out there who have chips with this, and even fewer
whose chips we could actually use. I don't know of any Flash
chip with useful zone protection (you get a lot that protect
about 16 kB, but that's not enough). Just
Marcin Wiacek wrote:
Can be done something like that (I'm not hardware guy) ?
Sure, that's basically what we have in mind, except that there may
not even be a microswitch (although I'd like to have at least a
jumper), but just a resistor you'd have to unsolder to do this.
The issue is that our
Can be done something like that (I'm not hardware guy) ?
Sure, that's basically what we have in mind, except that
there may not even be a microswitch (although I'd like to
have at least a jumper), but just a resistor you'd have to
unsolder to do this.
Resistor - wrong. It must be
Attila Csipa wrote:
On Wednesday 16 May 2007 18:46:03 Ian Stirling wrote:
I really think you do.
I want to be able to give this phone to my (hypothetical) employees.
I do not want skilled lazy, employees able to - for example - edit their
GPS logs which corroberate the inspections they are
Marcin Wiacek wrote:
Resistor - wrong. It must be available for user without technical knowledge
and tools.
No, this memory is the one only users who know exactly what they're
doing and have the right tools should ever change. And even those
normally shouldn't even want to.
The things there
Raphaël Jacquot wrote:
Ian Stirling wrote:
This is _not_ DRM that stops the owner of the phone doing stuff.
It's DRM that stops users of the phone that may or may not be
authorised users from doing stuff.
Think of it as a BIOS password on steroids.
DRM never worked, and never will. it's
@lists.openmoko.org
Subject: Re: Few comments after reading Wiki
there's no such thing as a secure system. You can have a somewhat
secure thing, that will be able to resist to X but the 100% secure
thing doesn't exist.
___
OpenMoko community mailing list
community
Ian Stirling wrote:
Raphaël Jacquot wrote:
DRM never worked, and never will. it's a fact of life, get over it.
It's not DRM. It's a BIOS password, which doesn't let you flash it
without the password.
Without it, any employee/pervert that wants to drop a logger on your
childs phone can do
[]
In normal use, this Flash is not accessed. You can still
change kernels, boot loader, and all that, with maximum ease.
(They're all in the regular Flash.)
Of I see that we think about different things
I was thinking about protecting memory with main phone software (like
kernel,
On 5/16/07, Ian Stirling [EMAIL PROTECTED] wrote:
Raphaël Jacquot wrote:
Ian Stirling wrote:
This is _not_ DRM that stops the owner of the phone doing stuff.
It's DRM that stops users of the phone that may or may not be
authorised users from doing stuff.
Think of it as a BIOS password
On 5/16/07, Marcin Wiacek [EMAIL PROTECTED] wrote:
1. I hope, that there will be made SAR tests and results will be very low
Why? It may help with marketing, but the worst it could do (unless
it's several orders of magnitude beyond what current phones) is make
you a bit warm. Non-ionizing
5. hav developers though about creating it on kind of x86 compatible
platform ? I know, it could be more difficult to create energy efficient
device, but having PC in pocket (with ability to running dos, windows after
changing SD card) would be more than excellent
yes, i have. i don't know
Marcin Wiacek wrote:
Of I see that we think about different things
Yup :-)
I was thinking about protecting memory with main phone software (like
kernel, boot loader, main apps).
You'll (almost certainly) be able to do this as well: the new MCU
will allow you to specify which NAND Flash
35 matches
Mail list logo
