I've a tiny (task-specific) hypervisor for windows 7 x64 (as a driver). I'm testing it under vmware. Unfortunately I'm at a point where vmware either hangs (100% cpu, non-responsive) or produces "cpu reached invalid state" error.
My options are:
test on another physical machine
test inside another hypervisor/emulator that allows nesting (and EPT)
???
PROFIT
Regarding 2., which software supports nested VMX/EPT? It has to be opensource, preferably supported by LibVMI.
Regarding 3., am I missing something? Are there some secret vmware switches enabling extensive debug output, or a way to check why bare metal CPU entered an invalid state?
Related
I'm getting started with freeRTOS. I went through the documentation provided in freeRTOS.org, and had some practice with some demo projects. My question is how to install freeRTOS without using the win32 port (since it is only an emulator that doesn't provide real time behaviour)? Is it possible to install freeRTOS as a standalone OS, or is it necessary to use linux kernel or windows?
FreeRTOS is a real time operating system kernel. It's not a fully blown OS, it's just the kernel. You don't "install" FreeRTOS like you would windows or a ubuntu distro on an x86 PC. You build a project and use freeRTOS to schedule tasks, manage memory resources etc. In general, you need a different microcontroller/processor than one you're developing on as your platform.
If you want to use only your laptop, then you'll need to simulate a "target" processor (that's what that option is). You won't be able to achieve "real time" results (windows will get in the way), but you can get pretty close.
The first thing I'd do is get an eval kit for whatever microcontroller you want to actually use/target/develop on.
Im developing an uwp app on Raspberry Pi 3 with Windows IOT Core. But after I deploy my app and use it for couple days the os crashes. It says something went wrong. It says "Your pc ran into a problem and needs to restart". It restarts couple times but still same error on every boot.
I tried to remove the sd card(Class 10,64 GB) format it and reinstall everything. At first it was okay but after some time same error appears.
I tried to use different os builds and it didnt work.
I tried to use industrial power supply (5V3A) and also it didnt work.
My SD Card is not one of the recommended ones but do I really have to get the recommended sd cards to use the windows iot core properly?
"Your PC ran into a problem and needs to restart" is a typical blue screen message seen on Windows systems from the last few years - laptops and desktops with far larger hard drives and no SD card. The error is not associated with a RAM or disk space shortage (operating systems running in graphical mode usually monitor and actively warn about either). In your case, it is showing at startup, when not much is running (taking up RAM), and you can check the amount of space used on the card with the PC.
The key stats for SD cards are size (you have plenty) and speed (clearly enough or you would have trouble installing/running anything after starting the Pi). The cause is something else, and finding out what will require getting a more detailed error message from Windows - "a problem" could mean anything. In my experience, blue screen errors have mostly involved having a wrong driver installed, sometimes a bad Windows update - but IoT Core has its own alternatives, like "bad system configuration". Look for the underscored string (e.g., BAD_SYSTEM_CONFIG_INFO) at the end of your blue screen message, as that is the first hint.
Unfortunately, most Windows BSoD documentation is for traditional PCs, so I cannot recommend specific troubleshooting tools and be sure that they will run on the Pi.
You can use Windows Debugger to debug the kernel and drivers on Windows IoT Core. WinDbg is a very powerful debugger that most Windows developers are familiar with. Or you can also refer to this topic in MSDN, it shows how to create the dump file when the app crashes. If possible, you can share your code so that we can reproduce the issue.
I start to explore in the area of computer architecture. There are 2 questions about ISA that confuse me.
As far as I know, there are different kinds of ISA such as ARM, MIPS, 80x86, etc. I wonder whether a CPU can only specifically read one kind of ISA. For example, can a processor read both 80x86 and MIPS.
If a CPU is unique to an ISA, how can I check which ISA my PC processor is using? Can I find it out manually?
Thank you
All the CPU/MCU's I know of support just single instruction set.
There is capability of loading microcode to some of the newer architectures that may allow to change the instruction set behavior to some point bot strongly doubt it you can change the instruction set with it. Instruction set and internal CPU/MCU circuitry are strongly dependent. Making universal CPU with changeable instruction set is possible (for example with FPGA) but would be very slow in comparison to direct DIE encoded CPU. With similar technology of Die the clock speed would be may be just few MHz.
Some architectures like i80x86 supports modes that can switch to different kind of operation (16/32/64 bit,real,protected) but its hard to say it is different instruction set or just subset of the same thing ...(matter of perspective)
detection of instruction set.
This is madness. Yes it is possible to detect which type of instruction set you have via program but all the CPU/MCU's have different pinout, interfaces, architectures and are not interchangeable (even in the same architecture class) so you detecting instruction set is meaningless as you alredy know the architecture you are doing the wiring for ...
Anyway the detection would work like this:
have set of test programs of each supported instruction set/architecture that will set specific memory or IO to predefined state if working properly
have watch dog cycling between all the detections and stop on first valid result.
Yes, each type of CPU is unique to an instruction set. The instruction set for ARM will not work with x86, SPARC, etc. There may be some overlap by coincidence, but programs are not compatible between architectures.
Depending on your operating system, there are commands you can run to see this information. For unix/Linux, uname -a will show you what architecture you're running, as well as dmidecode. For Windows OS's, right-clicking on My Computer and selecting Properties should show you your architecture.
For example (Windows 7):
For Linux (I know, it's a super-old distro!):
$ uname -a
Linux hostname 2.6.35-22-generic #33-Ubuntu SMP Sun Sep 19 20:32:27 UTC 2010 x86_64 GNU/Linux
(In this example, the architecture is x86_64), which is 64-bit Intel or AMD. To tell for sure, you can run dmidecode as I mentioned earlier:
~# dmidecode |grep -i proc
Processor Information
Type: Central Processor
Version: AMD Opteron(tm) Processor 154
Processor Information
Type: Central Processor
Version: AMD Opteron(tm) Processor 154
It can actually read any instruction set if the support is implemented. Most of the CPUs nowadays support two/three instructions set that only slightly differ because of 32-bit/64-bit addressing.
x86 supports 16-bit, 32-bit and 64-bit instructions set, ARM support 32-bit, 64-bit, for both Thumb and Thumb-2, etc. Similarly for MIPS for example.
Original Transmeta I believe was flexible about it and supposed to transcompile any instruction set into internal set and run it natively. However it failed and nowadays there is nothing similar to it.
Anyway, once you run application, it's bound to specific instruction set in its header so it can't change it during the runtime. Well, ARM is exception to that - it's able to switch between full and Thumb versions but they are just different encoding for the same...
For the second part - either in your OS GUI or you can usually read it - in Linux by reading /proc/cpuinfo, on Windows in the environment variable PROCESSOR_ARCHITECTURE.
To better clarify my generic question:
I have gotten the Android emulator to work by running a full "make full-eng" build, as per the Google documentation. However, I wanted to debug it, so once I ran the emulator, and called "$ adb shell dmesg" and routed that to an output text file, I found a couple of strange lines:
...
<4>goldfish_new_pdev goldfish_interrupt_controller at ff000000 irq -1
<4>goldfish_new_pdev goldfish_device_bus at ff001000 irq 1
<4>goldfish_new_pdev goldfish_timer at ff003000 irq 3
<4>goldfish_new_pdev goldfish_rtc at ff01000
So when you run the Android full build, it gives you Goldfish as the system image? I want to know if it's testing the things I want for Galaxy Nexus. The kernel was a modified maguro kernel (omap project) for Galaxy Nexus, that I put into the build tree. But the platform I want to be testing is IceCreamSandwich. Is the emulator testing this platform? (b/c the output in this log is leading me to believe it isn't) Or is the emulator testing a "generic" image?
Also, an important further question: I modified the kernel's "socket.h" file, to override the INET protocol with an undefined protocol (FINS). In theory the phone should boot up, but NO internet access. Does the phone emulator care what you do to the internet protocols? Does it use your host computer's networking capabilities?
One further follow-up: What processes/system-services/events (that are involved in booting to a stable state) of the phone DEPEND on the internet protocols of the traditional underlying network stack? (protocols being defined to set up the network sockets)
At the time I wrote the question I did not understand a few things and think I've learned a little while messing with the emulator at the "kernel level". First of all, the emulator tests the "goldfish kernel" (Linux version 2.6.29, with ARM architecture) of a "generic" phone brand. It's almost as if the emulator is a type of phone in of itself, and you cannot mix these image kernels. For example, I tried building a Nexus S crespo phone image with goldfish kernel (so in other words, no crespo kernel) and the phone just "hangs" at the Google splash-screen (at least it's not a boot-loop).
My research (FINS) worked on this emulator, but did not work on any of the 3 platforms supported on actual hardware: Nexus S, Galaxy Nexus, and Motorola Xoom. I am not sure why, given Google does not seems to give users the ability to debug at the lowest level of a phone (I'm sure the actual developers use such kinds of tools in building these phones/testing them). This leads to one major issue which answers my last follow-up: The Android Debug Bridge depends upon INET protocol. My emulator boots up successfully and runs as I want (no internet, b/c there is no INET), but these actual phones do NOT. My hypothesis is that: If INET is overridden with a protocol that is empty (in this case, that would be FINS, which intends to deal with INET at the userspace level, but this appears to be too late for the phone system to be satisfied), the ADB daemon (classified as a type of system service perhaps) cannot work/be connected to and Android hardware will crash because of this. The emulator I believe is more flexible than a real phone, as the hardware is perhaps virtually represented and does not have the same limitations as physical hardware does.
You can consult my wiki/documentation (part of my research team's larger site) of my struggle with the Android phone boot process for more details and my various attempts: http://finsframework.org/mediawiki/index.php/Alexander_G._Ororbia_II
If anyone ever figures out how to get a working boot log from a Nexus S, Galaxy Nexus, or Motorola Xoom that gets stuck in a "boot-loop" (without ADB), please let let me know, as I will be working on this problem for a while to come (and I will update my other Stack Overflow-Android questions to reflect this correction). Any corrections to my understanding would also be appreciated.
NOTE: This answer is editable, as I still think there is some way of getting the phone to produce boot logs on the host machine without the ADB daemon.
I am aware that there are programs out there like lojack for laptops that get installed on the BIOS, but I'm still a little confused. When reading about lojack, it seems to me that they can't fully located the laptop's location until the user logs in and tries to access the internet. So I'm thinking that it's a BIOS application so that it wouldn't matter if the thief reformats the HD.
So my question is, does anyone have any ideas of how an internet enables BIOS application would be written. I'm not looking for full answers -- just ideas or resources to get started. For example, is such a thing written in assembly? Once one such app is written, how does it get transfered to the BIOS.
Does the BIOS program itself recognize that there is an internet connection (when the thief logs on to the OS). Or upon logon, does additional processes get spawned? Are there any resources/websites that anyone can direct me too?
You didn't mention whether you were interested in legacy BIOS or EFI BIOS, but I would mention that with EFI there is the capability of writing EFI applications. See Intel Press:
Harnessing the UEFI Shell
The EFI Application toolkit comes with a complete TCP/IP network stack:
http://www.intel.com/technology/efi/toolkit_overview.htm
More at tianocore.org
Regarding "LoJack"-style solutions, one of the providers of this technology is Absolute Software's Computrace product.
Basically there are 3 components: 1) a software component that runs in the OS; 2) a BIOS component which is baked into the system BIOS (accomplished via Absolute working with the PC vendor); 3) servers at Absolute software that talk to the PC.
For more information on how it works visit:
http://www.absolute.com/en/company/Computrace-Persistence.aspx
(see especially the demo video on this site)
To learn something about BIOS, one good source is coreboot.org. It is an open source BIOS (or firmware) and support some physical machines.
Legacy BIOS is written in assembly language, but new generations, such as UEFI or coreboot, are written mostly in C language. BIOS program is stored in the ROM, and executed by the CPU automatically.
The BIOS program itself does not access the internet or perform any of the advertised functions. The LoJack addition to the BIOS firmware is a file copying/patching utility - at boot up it can check the harddrive for a copy of Windows and proceed to silently install/repair the LoJack service if it has been removed. The service itself includes several measures to lower it's profile and prevent itself from being disabled (similar to how many trojans and malware run several processes that each restore the other if one is disabled or killed).
The LoJack BIOS program can't do anything if a unsupported operating system (like Linux) is installed after the harddrive is wiped.