How do I decide starting address/load address for zImage in U-boot for beaglebone black?
Different article shows different addresses. I went through technical reference for AM335 but could not find any information.
So, the answer is that to a certain degree, it does not matter. The zImage file is designed to run from an arbitrary location. The most important constraints on where to load things to are best described in the Booting file in the Linux Kernel. A modern U-Boot, for TI platforms such as the Beaglebone Black will have a default environment that uses addresses based on that document. Looking at the code in U-Boot we see that the zImage is loaded to 0x82000000 and the device tree to 0x88000000.
Related
I've been working with a Micron BGA eMMC chip and prototyping a communication scheme with the eMMC chip inside an adapter board that connects to the GPIO pins of a TI microcontroller.
I've essentially created a communication scheme written in C code to walk through the initial handshake and initialization steps to get the eMMC to a Data Write/Read stage where I can write some small amounts of bytes to a part of the sector memory and read back the pattern I've written.
My next task is to format the eMMC into a partition format such as a FAT32 format, which is common among SD cards.
Does anyone know of any useful software or methods I could use to achieve this?
Or I've seen it's possible to format the eMMC using a Linux setup as well, but have little experience when it comes to Linux.
Any insight from anyone with past experience on the topic would be greatly appreciated!
If your system runs Linux that is the best option.
It is easy to format an eMMC using linux.
# mkfs -t fat32 /dev/mmcblk1
Is your TI microcontroller running Linux? If not, it might be diffiult connecting your BGA eMMC chip to a Linux system to format it.
Your second best option is to use a library that already supports it. Maybe something like (http://elm-chan.org/fsw/ff/00index_e.html) or (https://github.com/ryansturmer/thinfat32). There are several options I have not used any of them. To use these layers, you have to fulfill the lower level api.
I would like to use the PRUs of my Beaglebone Black. I 've been following several tuturials from the internet whithout any significant success. Most documents are outdated because the bone_capemgr is no longer supported (at least from what I understood). So how can I use the PRUs in combination with one of the Linux systems provided by beaglebone.org?
A programmable real-time unit (PRU) is a fast (200-MHz, 32-bit) processor with single-cycle I/O access to a number of pins and full access to the internal memory and peripherals of the BeagleBone (http://beagleboard.org/pru).
There are many tutorials online for PRU coding on newer beaglebone images.
I would suggest you to get familiar with the PRU Libraries and then try some simple and recent blink code or follow some example of remoteproc usage.
I can't seem to find a good comprehensive list of available ioctls for netbsd.
I am looking to do some operations on harddisk (getting size, physical sector size, model). I have the code working in linux. It looks something like this, I removed errors etc to make it more compact:
ioctl(fileno(driveptr[i]),HDIO_GET_IDENTITY,&hd);
ioctl(fileno(driveptr[i]),BLKGETSIZE64,&drivesize[i]);
ioctl(fileno(driveptr[i]),BLKPBSZGET,&psztemp);
Is there an equivalent to these ioctls in netbsd?
regards
The driver source for a given type of disk interface (or any other kind of device driver) is probably the best canonical place to find device specific ioctls.
NetBSD at a systems level, like many unix-based systems, tries hard to avoid being hardware specific, even in terms of providing detailed hardware specific information to user level. The goal of unix, after all, is to provide a system that is uniform across a wide variety of hardware platorms, not to provide detailed low-level access to specific hardware. The very best you can get in terms of hardware specific details is the information printed by the drivers at boot time about the hardware as it is probed and attached.
At a more generic level you can basically only get disk and partition labels -- i.e. information pertinent to the way the system presents disk devices to userland. Unfortunately the only driver manual page that documents these is sd(4) (cd(4) has some more detail about more ioctls specific to cd-rom devices). scsi(4) documents bus-level ioctls for SCSI and ATAPI interfaces.
On x86 platforms there's "sysctl machdep.diskinfo" (and the equivalent C level interface via sysctl(3)) to get details about what the BIOS reported about the disks it knew about at boot time, but that may be incomplete.
If I was told I needed to create a driver for some product (say, a game controller), how would I go about creating one? Is this something you could do normally in C/C++?
And what about firmware for external deviced connect to USB? How is this created usually? Is this also done in C/C++, or some lower level language?
Thanks!
Device drivers for desktop computer operating systems are generally written in either C or C++. The operating system you would target will have some form of framework or device driver development environment. Often these development kits can be obtained free of charge.
There are books available for Windows, Linux, and MacOS X (and others) that detail the process of creating a device driver.
If your driver is related to a device on a specific hardware bus (PCI, PCI-X, USB, SCSI, SATA, etc.) you can also get books on that specific technology. An understanding of that hardware system can greatly facilitate the design of your driver.
Another good resource is the open source code for similar devices to yours. You can obtain that from the Linux kernel source or FreeBSD source and study how certain aspects of your type of device are implemented.
EDIT: I nearly forgot to mention that you will also need data sheets, schematics, and/or theory of operation information about the device itself.
I'll add to Amardeep's good answer with the following books that will help you think about the context device drivers operate in, and how they're structured:
Linux:
http://www.amazon.com/Understanding-Linux-Kernel-Third-Daniel/dp/0596005652
Windows:
http://www.amazon.com/Programming-Microsoft-Windows-Driver-Model/dp/0735618038/ref=sr_1_1?ie=UTF8&s=books&qid=1277439434&sr=1-1
Mac OS:
http://www.amazon.com/Mac-OS-Internals-Systems-Approach/dp/0321278542/ref=sr_1_1?ie=UTF8&s=books&qid=1277439467&sr=1-1
You do it in any language that can talk to the interface. If it requires poking ports or addresses directly then you use assembly or C. If there's a higher-level interface such as libusb then you can use almost any language you like.
Is there an official way for an application to determine if it is running in VMWare or Virtual PC (or whatever Microsoft is calling it now)? The code I have seen is usually a hack that took advantage of some odd behavioral side effect in a specific version of VMWare or Virtual PC.
Ideally Delphi code, but if you can link to an official explanation then I am sure I can convert it.
I wrote a series of articles last year on this, with source code. VMware and Wine detection are here. Virtual PC is here. All three of these have pretty iron-clad detection because there are documented callbacks to the hypervisor (in the case of Wine, an extension to a standard DLL). I put up an untested VirtualBox detector (don't have it installed to test with) in the comment section. Parallels might be detectable using a callback also but I don't have it installed. The link for the documentation (which is poor since it's from a security researcher focusing on exploits) but located here if you have it installed and are interested. There's also a PPT here that has some information on detecting Sandbox, Bochs, and Xen. Not a lot of code in it but it might give you a starting point if you have to detect those.
Code Project shows a way to Detect if your program is running inside a Virtual Machine that goes in much detail on how to accomplish it to give a good understanding
I think the best approach to this is to check the hardware profiles. Virtualized hardware usually uses part of the companies name. If you check the motherboard description while in Virtual PC, you will notice it is made by "Microsoft Corporation". Likewise in VMWare, your ethernet adapter will be prefixed with VMNet.
This thread on the SysInternals forums has a couple of answers (in Delphi, of course), including a single IsVM function. I've tested on XP and Win2003 hosted on both XP and Vista in VMWare with good results.
There is a WMI way posted here:
http://blogs.msdn.com/virtual_pc_guy/archive/2005/10/27/484479.aspx
I've double checked in an XP image running on Virtual PC, and the value they're testing for is still the same. I won't guarantee what other VMs return here, though...
I've actually got a Delphi program I wrote a couple of years ago to get a list of and change the default printer using WMI, without requiring 3rd party components or anything like that. In case you're not used to working with WMI from Delphi, I can send you a copy so you have something to work off (it's not necessarily Unicode-compatible, though, but it shouldn't be too hard for me to upgrade it if need be).
I used the RedPill method (translated to Delphi, but the code isn't that hard to understand) which worked fairly well. I also included a few extra checks using WMI calls to get things like the network adapter vendor name and copyrights, but that was for detecting specific versions of Virtual PC.
My understanding of the RedPill method is that it should work and detect all virtual machines based on the nature of how it works. There is the possiblity that false positives might be generated also as the new Windows within Windows feature of Windows 7 can be configured to run selected programs in a copy of Windows XP seamlessly inside Windows 7.
I've had good luck with just looking at the MAC address as all manufacturers are given a block and the first 3 parts are unique to them.
//look at the MAC address and determine if it's a Virtual Machine
$temp = preg_split("/\s+/",exec("/sbin/ifconfig -a eth0 2>&1 | /bin/grep HWaddr"), -1, PREG_SPLIT_NO_EMPTY);
//Virtual Box MACs all start with '08:00:27:xx:xx:xx'
if (strpos($temp[4], '08:00:27') !== false) $_SESSION['DEVELOPMENT'] = true;
To determine the machine is physical or VM
dmidecode | egrep -i 'manufacturer|product'
If the dmidecode command not found install the respective rpm.
This is tested under EXSI, VMWARE and hyperv machines.
dmidecode -s system-product-name
Tested on VirtualBox, result:
Virtualbox
If you want to generally detect the presence of any type of virtualization, you are best analyzing performance characteristics. Take something that is significantly slower in virtualization (such as MMU heavy workload like a fork-bomb) and time it against a normal CPU bound user space app. From the ratio you can easily tell.
Easiest in terms of effort if you only care about certain VMMs is to look for their hardware- i.e. VMware PCI devices:
00:07.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 08)
Subsystem: VMware Inc Virtual Machine Chipset
15ad:1976
The vendor value is '15ad'
There are also specific backdoor ports that work across various VMMs in various versions. SIDT trick is good too, but what if a VMM is not on the list that his code is checking?