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
--
_
is mailing 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 comment
[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
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 fai
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,
http://www.samsung.com/Products/Semiconductor/MobileSoC/ApplicationProcessor/ARM9Series/SC32442/um_s3c2442b_r
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 implemen
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"
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"
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
> > 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
> > 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
>
> > 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 cance
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
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 a
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 rad
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
[]
> 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,
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
unity@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 communi
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
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 a
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 requi
> > 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 b
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
> 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 pro
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 actual
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.
> Th
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 over
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
> > 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 reasona
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 bri
Hello,
First of all, I will introduce myself. I was creating such projects like
Gammu and Gammu+ mainly for synchronizing informations from Nokia phones
(non Symbian) with PC using Nokia prioprietary protocols, but also for some
AT and Alcatel devices (including manufacturer commands and protocol
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 t
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 shou
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 a
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 ma
Hello,
First of all, I will introduce myself. I was creating such projects like
Gammu and Gammu+ mainly for synchronizing informations from Nokia phones
(non Symbian) with PC using Nokia prioprietary protocols, but also for some
AT and Alcatel devices (including manufacturer commands and protocol
37 matches
Mail list logo
