What is the CPU_STATE_MAX macro and what is it used for? I couldn't find any descriptive/relevant google results or man pages.
I am on Mac OSX Snowleopard, if that makes any difference.
See this--it corresponds to the number of CPU states defined in the machine.h header. These different states are then used to index different pieces of information about the CPU state, which can differ by CPU state--idle, 'nice', etc.
Related
Due to the current chip shortage, I have had to purchase PIC microcontrollers that have a different specification to what was initially designed.
Initial: PIC24FJ256GA606
Revision 1: PIC24FJ512GA606
Revision 2: PIC24FJ1024GA606
In this instance, the microcontrollers are within the same family but have different size of memory.
Initially, the binary was created to support multiple product variants and they all use this microcontroller (using hardware pins to define the type of product and thus the software features it supports). I would like to continue with a single binary but to be able to support the different microcontrollers specified above.
We flash the microcontrollers using a PICKIT 4 during manufacturing.
A custom bootloader is also flashed onto the microcontroller during manufacturing to allow the firmware update procedure to be is driven by another PIC microcontroller out in the field (it's a distributed system connected by RS-485).
I use MPLAB X IDE for development and buildings production binaries.
I guess the key question is about if this is even possible?
If so, then how would I achieve creating the single binary that supports multiple processors?
Normally a single binary should only correspond to the specific controller. Because especially Microchip has really wide variaty of microcontrollers. But as you mentioned in your question:
In this instance, the microcontrollers are within the same family but have different size of memory.
You can slightly use the same binary as long as you select the hardware very carefully. I mean if those 3 different models has the same pin mapping but some has less or some has more, then you would select the common corresponding pins for the I/O functions wherever possible. Since those devices are from the same family they must have common IO pins with the same port and pin numbering.
If those similarities including of that the internal registers are enough for the functionality of your system, you can use the same binary for those 3 or more devices as long as you select the right hardware very carefully and none of the functions remain without touching its hardware.
But it is very hard to say the same for the others that are not belong to a series in the same family. In this case you can check the hardware similarities for each functionality of your system. If that micro provides the same hardware, then you can go and firstly give it a try to see whether it will be programmed and then it will funtion in the same way. After making sure enough you can add that model in your usable models list, too.
Hope this give you a helpful idea.
For two microcontrollers to have compatible binaries, they need to fulfil the following:
The CPU cores must have identical Instruction Set Architecture. Be aware that the term "code compatible" by the manufacturer might only mean that two parts have the same ISA and are compatible on the assembly language level, as long as no peripherals or memories are used...
In case they have different memory sizes, the part with larger memory must be a superset of the part with smaller memory and they must map memory to the same addresses.
All hardware peripherals used must be identical and any peripheral routing registers used must also be identical. Please note that the very same core of the same family but with a different package and pin routing might mean that peripheral routing registers must be set differently.
There can be no check of MCU partnumber registers etc inside the firmware, nor can there be any in the flash programming equipment.
In general this means that the MCUs must be of the very same family and the manufacturer must guarantee that they are replaceable.
You can very likely switch between different temperature spec parts of the same model and between automotive/non-automotive qual parts of the same model without changing the code.
First : This Question have a duplicate here :
How does a modern operating system like Windows or Linux know the chipset specific memory map?
But the answer in this Question is speaking about device tree and ACPI (for legacy PCs) without the details I need to write an assembly or c code to utilize the information in ACPI tables, I am now trying to learn about legacy pc first and how to decode the tables of the ACPI , I tried doing some search and I found that the most important table is the DSDT , Now my questions How to decode the information in the table to get a detailed memory map (ranges) and also to get which devices are connected to the CPU and how to get the address of the DSDT in memory ? , I tried doing some search but I couldn't understand the AML language which i think is related to this subject .. I will be helpful if any one elaborate and provide good material for understanding ACPI tables and decoding them for beginners , The problem for me I couldn't have a standard fixed memory map in mind because i want to know how the same os version run on different chipsets , there must be a dynamic way to detect the whole map , so a suggested process for getting the whole map is also another question of me
please note also this is my first step toward learning how to communicate directly with bare metal hardware devices each individually (which is the second step)
Thanks
Let's split this into 3 different problems.
How to get the address of the DSDT in memory?
The firmware provides a pointer to (one or 2) ACPI tables that contain an index of all other tables. These tables are the RSDT (Root System Descriptor Table) and XSDT (Extended Root System Descriptor Table); and the only real difference between them is that the XSDT supports 64-bit addresses (and should be used if possible) while the older RSDT does not (and should be considered "deprecated" and only used as a fallback for modern 64-bit operating systems). These tables mostly provide the identifier and address of all other tables; so if you want to find a specific table (e.g. the DSDT) you can search the index for the identifier (e.g. the 4 ASCII characters "DSDT") and find the entry that contains the table's physical address.
The pointer/s to the index are contained in a special structure called the RSDP (Root System Description Pointer); which is found in different ways for different types of firmware. For BIOS you have to search a few specific areas of physical memory looking for a special structure (with a special signature, and a valid checksum); and for UEFI you simply ask the firmware (and avoid a "cache pounding" search).
This is all (relatively clearly) described by the ACPI specification, including how to find the RSDT (e.g. the section "Root System Description Pointer (RSDP)"), and including the format of all structures and tables, and the meaning and purpose of all fields.
How to decode the information in the DSDT?
Because things can change after boot (due to hot-plug support, etc); static tables can't be used for some things and ACPI solves this problem (and creates more problems) by defining a special language called ASL (ACPI Assembly Language) that is compiled into a portable byte-code called AML (ACPI Machine Language).
The DSDT contains this AML.
To make any sense of it you need an AML interpreter, to execute the AML that is contained in the DSDT.
This is "very challenging" - to do it yourself you'll probably need to spend months studying the ACPI specification (and years working around bugs in different computers). Most people port an open source implementation (originally created by Intel) that is called ACPICA (see https://acpica.org/ ).
Sadly; being able to execute AML is only the first step. You also need to understand ACPI's namespaces, which functions/methods are provided by the AML and what they're supposed to do. To make this worse; ACPI's AML expects to be informed of what the OS is, and then enables/disables various features and changes its behavior to suit the OS (depending on what it was told the OS is); and often the only operating systems that are recognized by AML are versions of Windows and if you tell it something else it disables various features, so most operating systems just lie and say they are a version of Windows so that AML doesn't provide a crippled subset of its capabilities. However; "what each version of Windows does" (and how AML behaves for each specific version of Windows) is a horrible undocumented (by ACPI specs) disaster. Fortunately; ACPICA also hides the majority of this pain (for people that port ACPICA).
How to get a detailed memory map (ranges) and also to get which devices are connected to the CPU?
Mostly you don't. Specifically, you don't just "get a detailed memory map" in a nice single step.
Instead; you start by getting some minimal information about the physical memory from firmware (from int 0x15, eax=0xE820 for BIOS, or from GetMemoryMap() on UEFI). Then you use a variety of different sources to add more details to that minimal information, including but not limited to the CPUID instruction (for how many bits a physical address actually has), the ACPI "APIC/MADT" table (for IO APIC and local APIC addresses), the ACPI "EDT/HPET" table (for HPET addresses), the ACPI "MCFG" table (for the addresses of PCI Express memory mapped configuration space areas), the ACPI "SRAT" table (for NUMA information for memory areas and "hot-plug RAM" information), and possibly (optionally) the SMBIOS tables (if you care about things like what type of RAM is installed, etc).
After obtaining all the information you want from static/unchanging sources; you switch to "phase 2", which involves continually managing the memory map and trying to keep it up to date as information from various devices is found (and modified via. hot-plug events). This is where being able to execute AML (from DSDT, using your AML interpreter) becomes important. It also involves bus specific approaches (e.g. scanning PCI buses and extracting information from each PCI device's BARs/Base Address Registers).
Note that this isn't purely about filling in details for the memory map. It's better to thing about it as discovering the resources that devices use, which includes IO ports, IRQ lines, DMA channels (and not just areas of the physical address space alone).
Also note that you only really information about devices if/when you have a device driver that is capable of using the information to "drive" the device. If you don't, then the memory map you have will just say "reserved" and you won't know why, but you probably won't have a reason to care why anyway.
Final Note
This is "very daunting" at first glance. Don't be worried - you can (and should) start small and ignore most of it until much much later. You can do a lot with the minimal information about the physical memory from firmware alone; and add code to do almost everything else if/when it actually matters for your OS one day.
I know there are some unix utils for simple architecture queries:
arch
nproc
lsb_release -a
are there any simple ways to find out about the cluster/supercomputer/nodes - like to find out the number of teraflops of the machine and so on?
Yes and no.
No you won't be able to find the effective number of flops the cluster is able to deliver in practice; you need a benchmark for that, such as HPL, the one used in the Top500 ranking. The value given by the benchmark will depend on the power of the processors, the speed of the memory, the latency of the network, etc.
But yes you will be able to compute the maximum theoretical power (in FLOPS) of one node from the contents of its /proc/cpuinfo, based on the processor family and frequency, and on the number of physical cores. See formulas here.
Short answer: no.
Slightly longer answer: no. You have to run benchmarks to measure those. The information should be available from the owners/administrators of the supercomputer in question.
No standard way - most such clusters/supercomputers/nodes are custom built, and the administrators may have added tools to determine current and available usage such as number of fee nodes, but simply having a tool to return such a number wouldn't be very useful, practically.
The only way to actually get the number is to measure it, and there are several different methods of approaching this. It may have been measured for the system you are using, you can presumably ask the administrators if it has been, but otherwise it's just probably a matter of "Do we have enough processing power" rather than shooting for some numerical target.
I am trying to develop a C function for getting some motherboard info (name, id, etc.) but I can't find where these info are stored. I had a look at CPUID but I could't find anything related to the motherboard there (although lots of info regarding the CPU).
Does anyone know from where can I get these info?
Thanks a lot.
CPUID returns information about the CPU itself (hence the name); it does not return information about the motherboard. Your OS will likely have some way of querying ACPI data, which may (if the motherboard's manufacturer bothered to record such information) have what you're looking for; the exact method to do so depends on your OS, however.
If you're coding to the bare metal, your first stop is the ACPI tables. Of particular interest may be the OEMID and OEM Table ID in the DSDT; you might find model information elsewhere as well. Be warned, however, that BIOSes tend to be full of interesting bugs, and there's no guarantee that the manufacturer has filled in anything that's not absolutely necessary to get Windows to boot.
Non-ACPI systems are generally obsolete, at least for PC hardware. If you're on a non-ACPI system, good luck. There is no standardized location for motherboard identification information on a non-ACPI system. You can try to probe the hardware and guess based on a table of known hardware profiles, but that's the best you can do.
I would start with the dmidecode source and the standards it references (SMBIOS/DMI).
I am working on a project, C programing language, to develop an application, that can be ported on to a number of different microcontroller platforms, such as ARM\Freescale\PIC microcontroller. I am developing this application on Linux now and then I will have to port it to the above said platforms.
I would like to know, are there any tools (open source preferably), using which I can determine the "code" and the data memory footprint\size, before porting it to the new platform.
I have been searching on "Google" for it and have not found anything so far, not even for Linux as well.
any help from you will greatly help me.
-Vikas
For a small program, much of the size is determined by the libraries/DLL your program depends on. Since you refer to ARM/Freescale/Pic I assume you're dealing with compact, embedded applications where data size is measured in bytes rather than MBytes.
For your own code, size differences will determined by:
word size (i.e. 32bit programs tend to be a bit larger /more data than 8 bit)
architecture (i.e. Intel code versus ARM, freescale, PIC)
In your case, I expect that PIC is the most critical part (for RAM/ROM constraints). So propably monitoring the PIC compile size during PC development is sufficient. The linker output will contain info on TEXT/DATA/BSS size, which you can monitor.
I generally work on embedded systems. In my work much of the data size is known at design time (i.e. number of buffers * buffer size). For code size, I have rules of thumb on different architectures which help me to do a sanity check at design time. For instance, I define a suite of some exising-code libraries, for which I know performance and size numbers for each architecture. This way I know what kind of ratio I can expect at design time. If the PC program has 1 MBytes of data, it won't fit in an 8-bit PIC.....
Nothing can tell you how much memory your application will need. You'll have to make some assumptions about how it will be used and try your application under different scenarios.
As you're testing, you can monitor the memory usage stats in the /proc file system or use the ps command to do the same.
The size of your text/code segment will depend on optimization level and back-end. GCC can be configured to generate that information for you.
Run-time is a little more difficult as Jeremy said. Besides his suggestion, you also might want to try gcov and/or gprof in order to analyse your program in the context of your most common use scenarios. This kind of instrumentation is focussed on complexity rather than size but at least you'll know better where to focus your memory analysis.
Your compiler can/will generate a map file. The map file will, generally speaking, have code and data size (or location ranges). There may be differences between different compilers for the different targets. And as pointed out in other posts here, your dependencies on supplied libraries will also impact overall memory usage.