Is there any alternative benchmarking to SPEC 2006 for ARM devices with limited memory. Unfortunately, SPEC 2006 needs 1GB ram for 32bit platform and 2GB for 64bit devices (without considering OS requirement for RAM,so your RAM must be even more than that).
Unfortunately, my test platform is an ARM v8 (64bit) with 256 MB of RAM. I am looking for alternatives for SPEC 2006 in my system. Is there any?
Related
In the case of x86 the same (real mode) bootloader works on virtually any x86 device.
Is that possible on ARM or do I need to create a specific bootloader for each 'cortex'?
x86 or lets say PC compatible systems are ... pc compatible. They support the ancient bios calls so that there is massive compatibility. by design, by the chip vendor (intel) the software vendors (bios, operating system) and the motherboard vendors.
ARM is in now way shape or form like that. There are instruction sets you can choose that work almost or all the way across, but remember ARM systems you buy an ARM core and add it to your special chip, you and your special/custom stuff, then that is put on one or more different boards. There is little to no compatibility. Instruction set and arm core is a small part of the whole picture most of the code is for the non-arm stuff.
u-boot and perhaps others are fairly massive bootloaders, pretty much an operating system themselves, and have to be ported just like an operating system to each chip/board combination. The chip vendor, if this is a linux compatible system, most likely has a reference design and a BSP including a u-boot port and/or some other solution (rasberry pi is a good example). it is fairly trivial to boot linux or used to be, there is no reason for the massively overcomplicated u-boot. without a DTB you setup a few memory locations a register or two and branch to the kernel, thats it (again look at the raspberry pi), I assume with DTB you build the dtb then put it somewhere, setup a few registers and branch to the linux kernel (raspberry pi? ntc chip?)
There is a Arm open source project that can cover Armv7/v8 Cortex-A processors bootloaders.
https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/
Another open source project for Cortex-M processors:
https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/
Is it possible to compile some Linux Kernel and run it over QEMU, emulating some Big Endian ARM processor?
If QEMU is not capable of that, I'd love to hear about other system emulators than can.
My basic goal is to run and debug dedicated Big Endian ELFs in as much as possible native environment.
Every close solution or idea would help!
QEMU has support for big-endian ARM CPUs, but it does not currently have support for emulation of any specific machines (boards) which have big-endian ARM CPUs in them. ARM Linux kernels will generally only run on the hardware they're compiled for, so you can't just take a random big-endian ARM Linux kernel and run it on anything -- you'd need to model the hardware the kernel wanted to see first.
The underlying reason for this is that big-endian ARM systems are very rare -- almost everybody runs ARM CPUs in little-endian mode, and all the boards QEMU models today are little-endian.
In ARM microprocessors, is the only available memory space the 37 or so general and status registers, or is there a separate accessible memory space within the microprocessor chip?
For example, in the Atmel AVR microcontroller, to my understanding, the memory is mapped internally within the same chip, with data memory, program memory (containing program memory) and EEPROM memory. Does the same apply to ARM microprocessors, or does a microcontroller with an ARM microprocessor require separate external memory?
Your interpretation of the Atmel AVR architecture is not quite correct.
Of course it's possible to integrate memory of virtually any kind on the same die as the CPU core. However, that doesn't mean you can compare flash memory available on one such integrated system to registers on another.
A CPU core needs a memory interface and that's all that counts: Flash is slower than registers. So if you connect Flash to an ARM processor it will behave similar (in the same order of magniture regarding speed) as the on-board Flash of the AVR.
Besides, ARM is solely an IP (design concept) and licenced by numerous companies which build efficient peripherals and sometimes also memory around the core. So you will find chips with an ARM core and on-board memory on the market.
(I simplified things a bit in the above description but I was focusing on trying to point out where I think you misunderstand how the two processors compare.)
Below link talks a lot about how memory management is done in ARM processor. Hope it helps
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0471c/CHDDJIFI.html
I know the default page size of a 32-bit process running on 32-bit Windows is 4K, whereas that of a 64-bit process running on 64-bit Windows is 8K. However, what is the actual page size of a 32-bit process running on 64-bit Windows (i.e. WOW64) ? 4K? 8K?
Ideally, you should call GetSystemInfo() and examine SYSTEM_INFO.dwPageSize.
Btw, I doubt that you have 8KB pages in 64-bit Windows. x86/64 CPUs support pages of the following sizes: 4KB (all modes), 4MB (32-bit non-PAE), 2MB (32/64-bit PAE), 1GB (64-bit, always PAE). You can find this in the CPU manual from Intel (or AMD).
The page size is still 4K - 1M pages at 4GB maximum addressable RAM memory
Virtual memory size. On the Intel Itanium processor, WOW64 adds
significant overhead if two or more instances of the same 32-bit
application are running concurrently. This is due to the native 8 KB
pages on the Intel Itanium, which complicates the emulation of the
native 4 KB pages on the x86 architecture (more pages are marked as
writable; all writable pages are private to the process). This can
adversely affect the scalability of Terminal Services on certain
processors. This is not the case for the x64 processor.
Read more about WOW64 here
The correct answer to this question is "It depends on which processor".
Itanium uses 8KB pages.
X86-32 and x86-64 uses 4KB, 2MB and 1GB pages as appropriate [note that for 2MB and 1GB pages to work, the memory needs to be a multiple of 2MB/1GB in size and be aligned to 2MB/1GB respectively].
Other processors, such as ARM (currently only 32-bit OS), typically uses 4KB pages, but can also use 64KB pages.
If you can find an old DEC Alpha processor, and operating system to match, that would also use 8KB pages.
I have a RDK-IDM from Luminary Micro. This board has a 32-bit ARM® Cortex™-M3 core. Has anybody tried to run a .NET Micro Framework application on such a device?
I don't have any hands on experience but based on http://www.microsoft.com/netmf/about/gettingstarted.mspx The smallest footprint supported is 64kb RAM, 256kb Flash and MMU is not required. Therefore your applications needs would be the determining factor.
FYI: the .NET Micro Framework was released as Open Source under the Apache 2.0 License November 16, 2009
It seems that the LM3S6918 (The chip on the RDK-IDM) has only 256KB Flash and 64Kb SRAM but .NET Micro Framework requires 256KB RAM and 512K Flash/ROM!
Read more here
We have ported .NET Micro Framework to TI Stellaris MCU, ARM Cortex-M3 core,
currently we have a port for EK-LM3S8962 board, and it is working.
.NET Micro Framework Minimal memory footprint:
Flash: 155KB
RAM: 32KB
The cortex M3 is a very cut-down core, it lacks an MMU, for example, and is intended to run very simple operating systems. Specifically, not Symbian/Windows Mobile/Linux/etc. Rather OSEck, OSEK, iTRON, or similar. I think this is actually totally infeasible due to that.