First arm only does the cpu, everything that it is around it (timer, interrupt controller, memory controller, uart,...) can be anything.
And there is no easy way to discover them (like pci bus, acpi,...). That what device tree want to do. But that won't really solve the code size. Embedded company want to reduce cost and often design simple soc block (gpio, uart,...), and this make the number of driver very big. Also there no standard interface like ehci, ahci,... Even the same vendor can change the controller across the chip generation.
So I think it will be very difficult to unify things. What the advantage of arm for soc maker. There are free to do what they want.
The update is managed by gsm carrier/phone maker and lot's of phone don't get any update.
That's a broken model.
With apple the device is close, but all devices get new update.
All version of android will got some local exploit bugs (from kernel, app running as root,...). This means people can create valid application (without any specific perm), that can : - run exploit and become root - destroy your phone (erase bootloader) - steal your information (spy your location, your call) - make your phone a spam relay,...
Yes but linux kernel need a direct ram mapping. And kernel mapping is 1G.
That's why highmem exist http://linux-mm.org/HighMemory.
However, many people insist on using more than 1GB of physical memory on such a 32 bit system. This makes it necessary for the Linux kernel to jump through some interesting hoops...
Basically the system uses the following tactics:
*
Memory above the physical address of 896MB are temporarily mapped into kernel virtual memory whenever the kernel needs to access that memory.
*
Data which the kernel frequently needs to access is allocated in the lower 896MB of memory (ZONE_NORMAL) and can be immediately accessed by the kernel (see Temporary mapping).
*
Data which the kernel only needs to access occasionally, including page cache, process memory and page tables, are preferentially allocated from ZONE_HIGHMEM.
*
The system can have additional physical memory zones to deal with devices that can only perform DMA to a limited amount of physical memory, ZONE_DMA and ZONE_DMA32.
*
Allocations and pageout pressure on the various memory zones need to be balanced (see Memory Balancing).
Cortex A15 uses 40-bit physical addressing is really useless : it is x86 PAE
Yes PAE is ugly and slow. It's been long time MIPS switch to 64 bits. I wonder why arm don't do it. Smartphone tends to get bigger and bigger memory...
It's mathematically impossible to make a device completely safe from someone who has complete physical control over it. You can encrypt this and that all you like, but it's literally only a matter of time before someone applies enough computing power and breaks said rights-management. Boot loaders can be heavily obfuscated against reverse engineering, but since the device has to actually boot and work at some point, there's a key to the proverbial lock in that haystack somewhere. I hope I'm making sense, coffee hasn't kicked in yet.
You are wrong.
First encryption is not used, it is digital signature (rsa).
Second to be safe the first signature check should be done on the CPU ROM using internal RAM (no MITM).
In this case if the signature algorithm is mathematically safe, you're device is broken if :
- if somebody publish private key
- if there bug in the ROM
There can be others bugs/holes in upper layer of software (bootloader, kernel,...), they can be patched by an update.
Not really some architectures like arm doesn't have this bug (because page 0 is used for something else). Also one of the most use of mapping page0 is for running... dosemulator on x86 via vm86 [1].
Especially since on a 64 bit distro pretty much everything, with very few exceptions is 64 bit.
You should look at ppc and sparc distro : pretty much everything is... 32 bit.
That because 32bit is more efficiant than 64 bits (less code/data size). But on x86 that's different because that's on the same arch at all (not the same register/feature,...).
You will be glad to learn that last arm cpu (cortex A9) do OoOE.
Also newer arm got mixed 16/32 bits instruction with thumb2.
And yes newer arm CPU eat lot's of more power that older generation (armv5), but there are more powerfull.
Slashdot Mirror
> In the end, the few uses of conditional execution
That why x86 introduced cmov for doing conditional mov ?
> and the ability to move anything to the PC without using a branch or return style instruction was probably so limited, there was no point.
Well most of time gcc use pop instruction for returning of a function
push {r4, r5, r6, lr}
[...]
pop {r4, r5, r6, pc}
They already started the mess with thumb2.
The first arm32 encoding was clean (stack pointer was a generic register), now with thumb2 and arm64 we got pop, push, ret instruction...
It is like the Antiope teletext we got in france : http://en.wikipedia.org/wiki/Antiope_(teletext)
Yes it is opensource, the but code look very ugly : http://anonscm.debian.org/gitweb/?p=arm-netbook/arm-netbook.git;a=commit;h=fe9f45a106b84dacf86117a5953b5efa57bae223 Good luck to people that will work with these drivers !
You means the tegra2 that lacks neon support and have low memory bandwidth ?
Looking at the teardown show us a ST Ericsson CPCAP 6556002, not a TI OMAP...
The irony is that the first version of android contains gplv3 software : https://android.git.kernel.org/?p=platform/external/dosfstools.git;a=summary .
But it was quickly replaced by a bsd clone : fsck_msdos.git
I don't know if there are any product with the gplv3 fsck. May be some cupcake versions.
First arm only does the cpu, everything that it is around it (timer, interrupt controller, memory controller, uart ,...) can be anything.
And there is no easy way to discover them (like pci bus, acpi, ...). That what device tree want to do. ...), and this make the number of driver very big. ...
But that won't really solve the code size. Embedded company want to reduce cost and often design simple soc block (gpio, uart,
Also there no standard interface like ehci, ahci,
Even the same vendor can change the controller across the chip generation.
So I think it will be very difficult to unify things. What the advantage of arm for soc maker. There are free to do what they want.
The update is managed by gsm carrier/phone maker and lot's of phone don't get any update.
That's a broken model.
With apple the device is close, but all devices get new update.
All version of android will got some local exploit bugs (from kernel, app running as root, ...). ...
This means people can create valid application (without any specific perm), that can :
- run exploit and become root
- destroy your phone (erase bootloader)
- steal your information (spy your location, your call)
- make your phone a spam relay,
On my computer, I got on old version of SeaMonkey (1.1.18), and the new design doesn't display correctly.
Does it use html 5.0 ?
What a shame
That's why highmem exist http://linux-mm.org/HighMemory
Cortex A15 uses 40-bit physical addressing is really useless : it is x86 PAE
But 64 bits is really interesting for the kernel. With Linux you can only map 1G of map without using segmentation (highmem).
Using 64 bits kernel with 32 bit programs solve the issue. And that's what is done on sparc, ppc, mips...
Also some algorithm really need 64 bits arithmetic to be faster.
No they should have construct IP adress like phone number : an extend it by adding prefix/suffix.
It should have simplified router job, because they could have done the routing only on some part of the number
Yes PAE is ugly and slow. It's been long time MIPS switch to 64 bits. I wonder why arm don't do it. Smartphone tends to get bigger and bigger memory...
It's mathematically impossible to make a device completely safe from someone who has complete physical control over it. You can encrypt this and that all you like, but it's literally only a matter of time before someone applies enough computing power and breaks said rights-management. Boot loaders can be heavily obfuscated against reverse engineering, but since the device has to actually boot and work at some point, there's a key to the proverbial lock in that haystack somewhere. I hope I'm making sense, coffee hasn't kicked in yet. You are wrong. First encryption is not used, it is digital signature (rsa). Second to be safe the first signature check should be done on the CPU ROM using internal RAM (no MITM). In this case if the signature algorithm is mathematically safe, you're device is broken if : - if somebody publish private key - if there bug in the ROM There can be others bugs/holes in upper layer of software (bootloader, kernel, ...), they can be patched by an update.
could be great to propagate rootkited OS ;) Of course authentication is needed (but the code for doing that could be big and complex).
Did you notice that the author of the blog entry is a developer of theorarm. His point of vue is not necessary the same as google...
And people seems to also forget that nouveau is ATM Linux only. Bsd users will have to use vesa or the binary blob...
http://x264dev.multimedia.cx/?p=292 list some missing feature a html5 :
- buffering control
- signalling back to server
- Quality of implementations
So why nobody have wrote a codec for theora on this dsp ?
AFAIK theora spec is quite old
PS : a dsp is not magic, you have limitation and can't make all codec work on it
Not really some architectures like arm doesn't have this bug (because page 0 is used for something else). ... dosemulator on x86 via vm86 [1].
Also one of the most use of mapping page0 is for running
So they seems related.
Especially since on a 64 bit distro pretty much everything, with very few exceptions is 64 bit. ... 32 bit.
That because 32bit is more efficiant than 64 bits (less code/data size). But on x86 that's different because that's on the same arch at all (not the same register/feature, ...).
You should look at ppc and sparc distro : pretty much everything is
You will be glad to learn that last arm cpu (cortex A9) do OoOE. Also newer arm got mixed 16/32 bits instruction with thumb2. And yes newer arm CPU eat lot's of more power that older generation (armv5), but there are more powerfull.
But lot's of media oriented ARM platform already got h264 (and other) hardware accelerator...
It will be difficult to beat them with pure software.
And how will you recover the data ? The keyboard can't call home on its own.