I have used CellSDK in past to emulate/debug and test code for powerpc7 architecture on x86_64 machines. Now i want to emulate test code for upcoming (Google/intel etc) PowerPC8 compiler is available, can someone tell me qemu that can emulate ppc64 on x86_64 so i can test code(scheduler) on it .
The minimum Requirement to emulate ppc kernel on Qemu is qemu binaries kenrel image and rootfs.
For arm its like this
qemu-system-arm -M versatilepb -m 128M -kernel zImage -hda rootfs.ext3 -no-reboot -show-cursor -usb -usbdevice wacom-tablet -no-reboot -serial stdio -m 256 --append "root=/dev/sda rw console=ttyAMA0,115200 console=tty mem=256M highres=off console=ttyS0"
For more details on ppc_64 have a look at
http://gmplib.org/~tege/qemu.html
here 10 and 11
You might want to use IBM SDK other than CellIDE.
https://www-304.ibm.com/webapp/set2/sas/f/lopdiags/sdklop.html
Also, if you are doing open source development, you can try to get a free access to real ppc64 machines. It works pretty well.
http://openpower.ic.unicamp.br/minicloud/
Related
Windows10 eclipse esp-idf latest version 2021-03
With the command line idf.py I can build and flash the esp-idf\examples\get-started\blink programme which run on a ESP32.
In eclipse, the buils works but the run command display in console
Usage: C:\Users\peter\esp-idf\tools\idf.py [OPTIONS] COMMAND1 [ARGS]...
[COMMAND2 [ARGS]...]...
ESP-IDF CLI build management tool. For commands that are not known to
idf.py an attempt to execute it as a build system target will be made.
.... bla bla ...
Can anybody tells me what is wrong ?
Regards
There is a bug in the eclipse/esp-idf launch bar.
The ESP target for esp32 is defined with a Serial Port COM3.
But that info is not used.
If one redefine a new ESP Target with the same serial port under a different name, then the run command will work!
See hereafter for the people interested in the details
cmd.exe /C "cd /D C:\Users\peter\esp-idf\components\esptool_py && C:\Users\peter.espressif\tools\cmake\3.16.4\bin\cmake.exe -D IDF_PATH="C:/Users/peter/esp-idf" -D ESPTOOLPY="C:\Users\peter.espressif\python_env\idf4.2_py3.8_env\Scripts\python.exe C:/Users/peter/esp-idf/components/esptool_py/esptool/esptool.py --chip esp32" -D ESPTOOL_ARGS="--before=default_reset --after=hard_reset write_flash #flash_args" -D WORKING_DIRECTORY="C:/Users/peter/eclipse-workspace/blink/build" -P C:/Users/peter/esp-idf/components/esptool_py/run_esptool.cmake"
esptool.py --chip esp32 -p COM3 -b 460800 --before=default_reset --after=hard_reset write_flash --flash_mode dio --flash_freq 40m --flash_size 2MB 0x8000 partition_table/partition-table.bin 0x1000 bootloader/bootloader.bin 0x10000 blink.bin
esptool.py v3.0
I am attempting to build a 5.1 x86 Emulator "System Image" that can be used by the latest Android Emulator, which uses a much newer Qemu code base, and has fewer problems with network bridging (for example). But I've run into a real mystery, the answer to which might explain why this task is giving me so much trouble. So first, a little back-story...
Android-19 (KitKat, ~4.4) used an ancient version of Qemu as the base for its emulator. The Android team subsequently announced that they were moving to "Qemu2", a newer/better code base, and its first use would be to support arm64 emulation, using a new emulator hardware definition called "ranchu". This did ship in Lollipop (~5.x, android-20-22), and unfortunately the x86 support was in fact omitted.
But here's the mystery - when you run the 4.4/KitKat x86 system image that is in Studio 2.2/Build Tools 25.0.2 with the -verbose flag, you can see that it is using the new Qemu, as well as the "ranchu" hardware definition and kernel:
Concatenated QEMU options:
/Users/xx
xx/.android-sdk/emulator/qemu/darwin-x86_64/qemu-system-i386
-dns-server 10.11.11.11,10.11.11.14 -serial null -cpu android32
-enable-hax -smp cores=2 -m 1536 -lcd-density 320 -kernel /Users/xx
xx/.android-sdk/system-images/android-19/default/x86//kernel-ranchu
-initrd /Users/xx
xx/.android-sdk/system-images/android-19/default/x86//ramdisk.img
-object iothread,id=disk-iothread -drive
if=none,overlap-check=none,cache=unsafe,index=0,id=system,file=/Users/xx
xx/.android/avd/Nexus_10_API_19.avd/system.img.qcow2,read-only
-device
virtio-blk-pci,drive=system,iothread=disk-iothread,modern-pio-notify
-drive
if=none,overlap-check=none,cache=unsafe,index=1,id=cache,file=/Users/xx
xx/.android/avd/Nexus_10_API_19.avd/cache.img.qcow2,l2-cache-size=1048576
-device
virtio-blk-pci,drive=cache,iothread=disk-iothread,modern-pio-notify
-drive
if=none,overlap-check=none,cache=unsafe,index=2,id=userdata,file=/Users/xx
xx/.android/avd/Nexus_10_API_19.avd/userdata-qemu.img.qcow2,l2-cache-size=1048576
-device
virtio-blk-pci,drive=userdata,iothread=disk-iothread,modern-pio-notify
-drive
if=none,overlap-check=none,cache=unsafe,index=3,id=sdcard,file=/Users/xx
xx/.android/avd/Nexus_10_API_19.avd/sdcard.img.qcow2,l2-cache-size=1048576
-device
virtio-blk-pci,drive=sdcard,iothread=disk-iothread,modern-pio-notify
-netdev user,id=mynet -device virtio-net-pci,netdev=mynet -netdev
user,id=mynet2,net=10.0.3.0/24 -device virtio-net-pci,netdev=mynet2
-show-cursor -L /Users/xx xx/.android-sdk/emulator/lib/pc-bios
-soundhw hda -vga none -append 'qemu=1 androidboot.hardware=ranchu
clocksource=pit android.qemud=1 console=0 console=0
android.checkjni=1 qemu.gles=1 ndns=2' -android-hw /Users/xx
xx/.android/avd/Nexus_10_API_19.avd/hardware-qemu.ini
So my question is - how was this system image created? The facts imply that an entirely different build system put it together. The code that would create a 4.4 system.img file that supported ranchu doesn't exist in the aosp 4.4 branch! And while it does exist in the 5.1 branch, it only supports arm64. So - is there anyone out there that can explain what up here?
I've just installed RASPBIAN 3.18 and next packages:
wget http://mirrordirector.raspbian.org/raspbian/pool/main/b/bluez/bluez_4.99- 2_armhf.deb
wget http://mirrordirector.raspbian.org/raspbian/pool/main/libc/libcap- ng/libcap-ng0_0.6.6-2_armhf.deb
wget http://mirrordirector.raspbian.org/raspbian/pool/main/r/radvd/radvd_1.8.5- 1_armhf.deb
wget -O kernel.zip http://www.nordicsemi.com/eng/nordic/download_resource/41602/5/28710770
unzip kernel.zip
sudo dpkg -i radvd_1.8.5-1_armhf.deb
sudo dpkg -i libcap-ng0_0.6.6-2_armhf.deb
sudo dpkg -i bluez_4.99-2_armhf.deb
sudo dpkg -i linux-image-3.17.4-release+_1_armhf.deb
sudo dpkg -i linux-headers-3.17.4-release+_1_armhf.deb
sudo nano /boot/config.txt
Add the following line:
kernel=vmlinuz-3.17.4-release+ to config.txt
save and exit
sudo reboot
and when I restart I got an screen more or less as the print screen attached. Any idea ?
One thing is sure: The rainbow screen means the GPU firmware is loaded, but there is a problem with the kernel image. Which one? Impossible to say from here. Perhaps not found or corrupt. Might be that the kernel you got from www.nordicsemi.com is broken. Might be you have a typo somewhere. But it can also be a faulty SD-card. Or a wrong power supply. According to Google:
In some cases (Stuck on the Rainbow Screen), freezing at this point has been fixed by adding "boot_delay=1" to the config.txt file.
If nothing helps, you probably have to go back to the default Raspian kernel. If you need a more recent kernel than in the default Raspian, you can switch to Raspian testing. The testing kernel should be a bit more recent... and definitely works for me.
This might also help you (https://www.raspberrypi.org/forums/viewtopic.php?t=58151)
Error ACT LED patterns
While booting the ACT LED should blink in an irregular pattern, indicating it is reading from the card. If it starts blinking in a regular (Morse code like) pattern then it is signaling an error.
When it blinks just once: possibly you have a Rpi from Micron. Take a good look at the processor if it says M with an orbit around it, then using the latest software ( after Sept 2013 ) will solve your problem. Also make sure you have a 4Gb SD card: a 2Gb doesn't work in this particular case.
Other patterns that might appear during a failed boot mean:
3 flashes: start.elf not found
4 flashes: start.elf not launch-able (corrupt)
7 flashes: kernel.img not found
8 flashes: SDRAM not recognized. You need newer bootcode.bin/start.elf firmware, or your SDRAM is damaged
Firmware before 20th October 2012 required loader.bin, and the meaning of the flashes was slightly different:
3 flashes: loader.bin not found
4 flashes: loader.bin not launch-able (corrupt)
5 flashes: start.elf not found
6 flashes: start.elf not launch-able
7 flashes: kernel.img not found
I am new to this, or better rusted (being 62).
Trying to develop on Beaglebone Black running Debian over IP using Eclipse Luna CDT and linaro tools.
I succeed in running and debugging standard helloworld.c.
Need to control GPIO fast (to connect to uncommon peripheral) but
all attempts to read or write to memory mapped registers fail.
Instruction
i = (*((volatile unsigned int *)(0x4804c130)))
which should read GPIO status register results in
Child terminated with signal = 0xb (SIGSEGV)
GDBserver exiting
logout
This is the source (hellobone.c) I compile without errors:
int main(void)
{
unsigned int i = 1;
i = (*((volatile unsigned int *)(0x4804c130))) ;
}
(I tried all variations on this pointer arithmetic)
Makefile trace: (ignore includes)
---COMPILE--- C:/hellobone/source/hellobone.c
"C:\gcc-linaro\bin\arm-linux-gnueabihf-gcc.exe" -c -o C:/hellobone/object/hellobone.o C:/hellobone/source/hellobone.c -marm -O0 -g -I. -IC:/hellobone/include
.
---LINK---
"C:\gcc-linaro\bin\arm-linux-gnueabihf-gcc.exe" -o hellobone C:/hellobone/object/hellobone.o C:/hellobone/object/tools.o C:/hellobone/object/gpio_v2.o -marm -O0 -g -I. -IC:/hellobone/include
.
The binary also crashes running as root from TTY:
root#beaglebone:~# ./hellobone
Segmentation fault
I installed Eclipse on the BBB Debian and read and write to memory works just fine. Just too slow compiling, and unstable, to be practical.
Reading memory should be doable. What am I doing wrong?
I suspect
GNU gdbserver (GDB) 7.4.1-debian
This gdbserver was configured as "arm-linux-gnueabihf"
But maybe I am missing something obvious, have not seen any post on this problem...
Really stuck. Being working on this for months now. Setting up toolchain very frustrating, nothing works as in YouTube videos..
Any help would be really appreciated
Marco
You need to mmap /dev/mem to access memory mapped peripherals through physical addresses. Easiest example / code I know does this goes by the name devmem2.
Thank you a lot, that certainly helped.
I compiled the program you gave me and it worked perfect in run mode in Eclipse, and in terminal on the remote machine.
Curiously, when running the Eclipse debugger, it crashes executing:
if((fd = open("/dev/mem", O_RDWR | O_SYNC)) == -1) FATAL;
I get this error message from gdbserver
Remote debugging from host 192.168.1.2
/root/hellobone: relocation error: /root/hellobone: symbol �pen, version GLIBC_2.4 not defined in file libc.so.6 with link time reference
Child exited with status 127
GDBserver exiting
Have been trying to use fopen but that gives a segmentation fault. Anyhow, I think that is a toolchain issue and not a programming issue.
This call fails on Solaris with EACCES when ran as ordinary user:
sem_open(fileName.c_str(), O_CREAT, S_IRWXU | S_IRWXG | S_IRWXO, 1);
When process is started as root, it runs fine. Is this expected behavior?
Environment:
$ uname -a
SunOS solaris 5.11 11.0 i86pc i386 i86pc
$ g++ --version
g++ (GCC) 4.5.2
At the command line try:
prctl $$
These are the system enforced resource limits your process has. Note there are
process.max-sem-ops
process.max-sem-nsems
project.max-sem-ids
These are limits that have a number, if you do not see them (or the limits are already reached) then you have to add them to your account's profile with projadd or projmod to increase them if your project already exists.
If you cannot do this (no root access) consult with your sysadmin, s/he probably has some reason for not allowing semapahore access.
Note carefully:
sempahores are kernel persistent. If you ran your code a bunch of times the sempahores you created are likely still out there.
To see existing semaphores try ipcs -as
To remove lingering sempahores that your code should have removed use ipcrm