I'm programming on fpga but it is giving the following error:
ERROR:EDK:3165 - elfcheck failed!
The following sections did not fit into Processor BRAM memory:
Section .boot (0x0 - 0x3)
Try using the linker script generation tools to generate an ELF that maps
correctly to your hardware design.
Programming the FPGA failed due to errors from elfcheck
I increased the BRAM memory but it's still giving the same error.
Related
Introduction
Lua implements co-routine based on setjmp/longjmp functions. I found some problems during porting lua to these RTOS environment:
1. Zephyr RTOS: Failed
Heading
MISRA C 2012 Rule 21.4 pointed:
The standard header file <setjmp.h> shall not be used
and when I call setjmp/longjmp functions it suggests that a MPU Fault is occurred although CONFIG_MPU=n is set in prj.conf.
2. Mbed OS: Success
I call lua API in main() and it contains no other thread or task in program. It was OK. But I do not test multi-thread cases.
3. FreeRTOS: Not Tested yet, but likely ok
Opensource project like NodeMCU and Lua RTOS use Lua and FreeRTOS as their basic framework. But I am not sure that they have tested in FreeRTOS multi-task situation.
I found a thread on FreeRTOS Forum about this problem. One of FreeRTOS developer said he did not know. Another people indicated may cause unexpected behaviors in ISR or task context switching due to conflict register change.
My Question
If I disabled all interrupts during setjmp/longjmp usage, could I avoid unexpected behaviors in case of conflicting of setjmp/longjmp and ISR/task switching?
Why do setjmp/longjmp have failed in Zephyr RTOS?
I wanted to modify my ACPI tables from some simple kind of rootkit before Windows boots.
->no, I can't alter the BIOS code
->I know Clover is able to do the job, but I'm booting legacy mode and didn't manage to install it for legacy devices, yet
but now I started myself with the RSDP pointer:
->int 15h E820 reports it's memory region as "Type 2: Reserved - unusable"
And that seems to hold true, for I cannot write it. I assume it's not hard coded into BIOS but written at boot-time, so my conclusion was i had to program the DRAM controller...
Is there a common way to program the DRAM controller to get write access at these regions for kinda all platforms as INTEL32 and AMD64?
or any other method to get write access at ACPI tables?
Edit 1: EBDA is write-protected by PAM-registers and TSEG prevents from writes to higher regions such as ACPI tables.
What's the equivalence at AMD64 platform to these?
I have a Zynq 7020 chip with 250 MB of DDR memory attached to it put in ECC mode (so 125 MB effectively). It's attached to NAND flash memory and has a series of bootloaders which eventually load VxWorks to run some stuff.
We are about to do a test which will require me to read all the memory, flash, and FPGA configuration memory on the device after execution.
I have another [small] program that I will install via JTAG after the run and have it write out the rest of the RAM, then all the flash and FPGA configuration memory. This program is compiled by the Xilinx SDK and is bare-metal (no OS/bootloader).
When I load this program, I reset the processor (JTAG command), run a ps7_init.tcl script that sets all the CPU registers to a good configuration as set by Vivado, load the elf file onto the device, then run the processor. This program then tries to read memory starting at the address 0x0, but it crashes quickly. I told it to start at an address of 1 MB (1<<20) (because I know there's some weird memory map stuff at the beginning, so I tried this just in case) and it reads a little bit more then crashes again.
The crash appears to be the CPU not letting me read these areas of RAM.
Why not? How do I make it so I can read every byte of the 125 MB of RAM I have?
There is a template project that Xilinx provides that is close to exactly what you are trying to do. It is the "Memory Tests" template, and it runs through attached memory ranges and tests read/write operations. By default it tests DDR memory range and ps7_ram_1. The linker script for the application puts the program in ps7_ram_0, and doesn't test that range since you can't overwrite instruction and data memory for the application.
Code for the template can be found here:
<SDK installation directory>\data\embeddedsw\lib\sw_apps\memory_tests
I would recommend creating a new project from this template, and changing the memorytest.c file to fit your need.
To answer your question more directly: You are likely running into problems with the processors MMU (memory management unit) and cache management. If your application is being loaded into DDR, then it is possible that it is blocking you from accessing application instruction and data memory. If your application is loaded into OCM (like the template) there may be access problems with the memory in cache. If you disable cache using
Xil_DCacheDisable();
Then you should be able to read from the entire DDR memory space (as long as it exists). Make sure that you configure your applications linker script (*.ld) so that the application knows which memory devices are out there, their base addresses and size.
I was working on pandaboard, when this problem occurred to me. pandaboard uses OMAP 4430, a harvard based architecture. The board has 1GB memory (DDR2 ram). But a harvard architecture requires two memories right ?
Here is what I understand
the linux kernel image is stored in MMC/SD card and then pulled out by the bootloader into memory. Now, where is the bootloader running from (is it the 1GB ram?). Where does the bootloader dump the kernel image ?(again, is it the 1GB ram ?)
ARM architecture is often called "modified Harvard". It has a single linear (4GB) memory space, but uses different buses (and caches) for code and data. This allows it to read code or execute data, just like x86.
Note that this does not hold for all ARM chips. Some of them (e.g. Cortex-M0 cores) use single bus for code and data, so they're actually von Neumann.
How to get the CPU Temperature info from Bios using c# I gave a try to the code in CPU temperature monitoring
But no luck. enumerator.Current threw an exception.
How can i achieve this ? Thanks.
Error :
"This system doesn't support the required WMI objects(1) - check the exception file
Not supported
at System.Management.ManagementException.ThrowWithExtendedInfo(ManagementStatus errorCode)
at System.Management.ManagementObjectCollection.ManagementObjectEnumerator.MoveNext()
at CedarLogic.WmiLib.SystemStatistics.RefreshReadings() in D:\Downloads\TempMonitorSrc\TemperatureMonitorSln\WmiLib\SystemStatistics.cs:line 25
at CedarLogic.WmiLib.SystemStatistics.get_CurrentTemperature() in D:\Downloads\TempMonitorSrc\TemperatureMonitorSln\WmiLib\SystemStatistics.cs:line 87
at TemperatureMonitor.SystemTrayService.CheckSupport() in D:\Downloads\TempMonitorSrc\TemperatureMonitorSln\TemperatureMonitor\SystemTrayService.cs:line 260"
Have a look at OpenHardwareMonitor.
I'm having the exact same problem:
https://superuser.com/questions/183282/cant-query-cpu-temperature-msacpi-thermalzonetemperature-on-windows-embedded-7
The code in the link you cited is correct. My .exe works fine on Windows/XP and Windows/Vista (as long as I "run as Administrator" on Vista) ... but fails with the WMI error "not supported" on Windows Embedded 7.
At this point, I don't know if the problem is the OS (WES7) or my motherboard (an Intel DH57jg).
Although not ideal, the closest/best solution I have found is to use Speedfan (free), which can expose its probe information to external applications, via a memory-map. Somebody has done the C# conversion:
Reading SpeedFan shared memory with C#
"Building on what I spoke about in my
previous post, lets say we want to
access the data that SpeedFan provides
from a C# application. As a small
aside, reading information from the
SMBus and other low level interfaces
can only be done from the kernel. So
applications like SpeedFan (HWMonitor,
Everest, etc etc) generally run a
driver at kernel level and then a
front-end GUI to present the
information.
In the case of SpeedFan, shared memory
(actually its technically a memory
mapped file on Windows I think) is
used to communicate between the kernel
driver and the userspace GUI
application. Even better, the format
of this file has been made public by
the author of SpeedFan. So, enough
talk, lets see some code!"