I am using Openbsd, when the kernel has not yet loaded, and you are in the boot console, the printf function writes directly to the VGA memory 0xb8000.
Using the i / o ports maybe?
boot code
prinf code
The printf code, according to manual.
That is my question, it is supposed to write in memory directly, since the kernel has not been loaded, or anything like that, someone can guide me.
Thanks.
Related
I have a code where I use the pcl/gpu namespace:
pcl::gpu::Octree::PointCloud clusterCloud;
clusterCloud.upload(cloud_filtered->points);
pcl::gpu::Octree::Ptr octree_device (new pcl::gpu::Octree);
octree_device->setCloud(clusterCloud);
octree_device->build();
/*tree->setCloud (clusterCloud);*/
// Create the cluster extractor object for the planar model and set all the parameters
std::vector<pcl::PointIndices> cluster_indices;
pcl::gpu::EuclideanClusterExtraction ec;
ec.setClusterTolerance (0.1);
ec.setMinClusterSize (2000);
ec.setMaxClusterSize (250000);
ec.setSearchMethod (octree_device);
ec.setHostCloud (cloud_filtered);
ec.extract (cluster_indices);
I have installed CUDA and included the needed pcl/gpu ".hpp"s to do this. It compiles (I have a catkin workspace with ROS) and when I do run it works really slow. I used nvidia-smi and my code is only running in the CPU, and I don't know why and how to solve it.
This code is an implementation of the gpu/segmentation example here:
pcl/seg.cpp
(Making this an answer since it's too long for a comment.)
I don't know pcl, but maybe it's because you pass a host-side std::vector rather than data that's on the device side.
... what is "host side" and "device side", you ask? And what's std?
Well, std is just a namespace used by the C++ standard library. std::vector is a (templated) class in the C++ standard library, which dynamically allocates memory for the elements you put in it.
The thing is, the memory std::vector uses is your main system memory (RAM) which doesn't have anything to do with the GPU. But it's likely that your pcl library requires that you pass data that's in GPU memory - which can't be the data in an std::vector. You would need to allocate device-side memory and copy your data there from the host side memory.
See also:
Why we do not have access to device memory on host side?
and consult the CUDA programming guide regarding how to perform this allocation and copying (at least, how to perform it at the lowest possible level; your "pcl" may have its own facilities for this.)
Why would the file system (CIRCUITPY) of an Adafruit board running CircuitPython not show up when connecting it to a suitable host via a micro usb cable?
This happens to me often, usually when I am copying files via Windows, most often with my trinket which uses the integrated chip flash memory rather than the separate SPI flash chip. Why? I don't know. A bug somewhere obviously. :)
So the solution.
Always save your work files locally or use a source code solution like git
Switch to the boot mode (double click reset)
Drag the erase.uf2 file to clear the flash memory
Drag the circuit python uf2 file to reflash python
Restore your files saved on your PC
Basically, I've made it a habit to assume the flash memory is temporary and volatile and not store any critical code only there.
You can read more about the erase uf2 and reflashing, general troubleshooting here:
https://learn.adafruit.com/welcome-to-circuitpython/troubleshooting
Besides your first answer about the cable, because of the relatively inexpensive nature of the boards and direct access to their power/ground sometimes the EPROMs that the file system are hosted on just go bad and give unexpected results. Best idea is to:
Test your environment with another board.
Reflash micro python on your board so you can start from scratch (didn't mention if you'd tried that).
JerryN mentioned the most common cause of this is using a USB cable with no data wires. Some USB cables are designed for power-only and have 2 rather than 4 conductors. These will power the device but will prevent mounting of the drive and use of the serial connection over USB.
Unfortunately these cables are often not marked as power-only so can be difficult to spot.
Another case is where CPLAYBOOT (this varies per board, e.g. GEMMABOOT, FEATHERBOOT, TRINKETBOOT) disappears on Windows. This can be caused by installation of the Arduino software which has an old, conflicting driver from 2007. More information on Adafruit: Circuit Playground Express: Troubleshooting.
A very rare case is a mis-seated USB connector. In my case the power was ok but the data wasn't for a good quality cable which had previously worked fine. Unplugging the USB cable at the host end and re-inserting it solved the problem.
I am migrating a code from Linux to Vxworks. The code requires opening physical/main memory and then map the physical to virtual memory using mmap.
In Linux, main memory is accessed by
fd = open("/dev/mem", O_RDONLY);
Can you please let me know how this can be accomplished in Vxworks.
Thanks in advance
It depends on which programming environment your migrated code will be running.
For kernel mode, it is much easier as generally you can access everywhere in the system memory in read-only mode as long as its memory region is mapped in the page table. No special API is needed in your code to access the memory.
For user mode (aka Real Time Process, only available starting from VxWorks 6.0), things are a little bit complicated. You need write a pair of code blocks, with one operating in the kernel mode while the other one in the user mode. Please refer to the comment block in the VxWorks source codes for a code example # vxworks-6.9/target/usr/src/os/mm/devMemLib.c (taking VxWorks 6.9 for example).
I just got my BeagleBoard-Xm and I'm wondering if there is any detailed step by step tutorials on how to get a very simple bare metal software running on the hardware?
The reason I ask is I want to deeply understand how the hardware architecture works, everything from the bootloader, linkers, interrupts, exceptions, MMU etc. I figured the best way is to get a simple hello world program to execute on the beagleboard xm without an OS. Nothing advanced, just start up the board and get a "hello world" output on the screen. thats it!
The next step would be getting an tiny OS to run, that can schedule some very simple tasks. No filesystem needed, just to understand the basics of the OS.
Absolutely no problem...
First off get the serial port up and running, I have one of the older/earlier beagleboards and remember the serial port and just about everything about the I/O being painful, nevertheless get a serial port on it so you can see it boot.
It boots uboot I think and you can press a key or esc or something like that to interrupt the normal boot (into linux). From the uboot prompt it is easy to load your first simple programs.
I have some beagleboard code handy at the moment but dont have my beagleboard itself handy to try them. So go to http://sam7stuff.blogspot.com/ to get an idea of how to mix some startup assembler and C code for OSless embedded programs (for arm, I have a number of examples out there for other thumb/cortex-m3 platforms, but those boot a little differently).
The sam7 ports for things and memory address space is totally different from the beagleboard/omap. The above is a framework that you can change or re-invent.
You will need the OMAP 35x techincal reference manual from ti.com. Search for the omap part on their site OMAP3530.
Also the beagleboard documentation. For example this statement:
A single RS232 port is provided on the BeagleBoard and provides access to the TX and
RX lines of UART3
So in the trm for the omap searching for UART3 shows that it is at a base address of 0x49020000. (often it is very difficult to figure out the entire address for something as the manuals usually have part of the memory map here, and another part there, and near the register descriptions only the lower few bits of the address are called out.)
Looking at the uart registers THR_REG is where you write bytes to be sent out the uart, note that it is a 16 bit register.
Knowing this we can make the first program:
.globl _start
_start:
ldr r0,=0x49020000
mov r1,#0x55
strh r1,[r0]
strh r1,[r0]
strh r1,[r0]
strh r1,[r0]
strh r1,[r0]
hang: b hang
Here is a makefile for it:
ARMGNU = arm-none-linux-gnueabi
AOPS = --warn --fatal-warnings
COPS = -Wall -Werror -O2 -nostdlib -nostartfiles -ffreestanding
uarttest.bin : uarttest.s
$(ARMGNU)-as $(AOPS) uarttest.s -o uarttest.o
$(ARMGNU)-ld -T rammap uarttest.o -o uarttest.elf
$(ARMGNU)-objdump -D uarttest.elf > uarttest.list
$(ARMGNU)-objcopy uarttest.elf -O srec uarttest.srec
$(ARMGNU)-objcopy uarttest.elf -O binary uarttest.bin
And the linker script that is used:
/* rammap */
MEMORY
{
ram : ORIGIN = 0x80300000, LENGTH = 0x10000
}
SECTIONS
{
.text : { *(.text*) } > ram
}
Note the linux version from codesourcery is called out, you do not need that version of a gnu cross compiler, in fact this code being asm only needs an assembler and linker (binutils stuff). The arm-none-eabi-... type cross compiler will work as well (assuming you get the lite tools from codesourcery).
Once you have a .bin file look at the help on uboot, I dont remember the exact command but it is probably an l 0x80300000 or load_xmodem or some such thing. Basically you want to x, or y or z modem the .bin file over the serial port into memory space for the processor, then using a go or whatever the command is tell uboot to branch to your program.
You should see a handful of U characters (0x55 is 'U') come out the serial port when run.
Your main goal up front is to get a simple serial port routine up so you can print stuff out to debug and otherwise see what your programs are doing. Later you can get into graphics, etc. but first use the serial port.
There was some cheating going on. Since uboot came up and initialized the serial port we didnt have to, just shove bytes into the thr. but quickly you will overflow the thr's storage and lose bytes, so you then need to read the trm for the omap and find some sort of bit that indicates the transmitter is empty, it has transmitted everything, then create a uart_send type function that polls for transmitter empty then sends the one byte out.
also forget about printf(), you need to create your own print a number (octal or hex are the easiest) and perhaps print string. I do this sort of work all day and all night and 99% of the time all I use is a small routine that prints 32 bit hex numbers out the uart. from the numbers I can debug and see the status of the programs.
So take the sam7 model or something like it (note the compiler and linker command line options are important as is the order of files on the link command line, the first file has to be your entry point if you want to have the first instruction/word in the .bin file be your entry point, which is usually a good idea as down the road you want to know how to control this for booting from a rom).
You can probably do quite a bit without removing or replacing uboot, if you start to look at the linux based boot commands for uboot you will see that it is copying what is pretty much a .bin file from flash or somewhere into a spot in ram, then branching to it. Now branching to linux, esp arm linux involves some arm tables and possible setting up some registers, where your programs wont want or need that. basically whatever command you figure out to use, after you have copied your program to ram, is what you will script in a boot script for uboot should you choose to have the board boot and run like it does with linux.
Saying that you can use jtag and not rely on uboot to work, when you go that path though there are likely a certain number of things you have to do on boot to get the chip up and running, in particular configuring the uart is likely a few clock dividers somewhere, clock enables, I/O enables, various things like that. Which is why the sam7 example starts with a blink the led thing instead of a uart thing. The amotek jtag-tiny is a good jtag wiggler, I have been quite pleased, use these all day long every day at work. The beagleboard probably uses a TI pinout and not the standard ARM pinout so you will likely need to change the cabling. And I dont know if the OMAP gives you direct access to the arm tap controller or if you have to do something ti specific. You are better off just going the uboot route for the time being.
Once you have a framework where you have a small amount of asm to setup the stack and branch to your entrypoint C code, you can start to turn that C code into an OS or do whatever you want. If you look at chibios or prex or others like it you will find they have small asm boot code that gets them into their system. Likewise there are uart debug and non-debug routines in there. Many rtoses are going to want to use interrupts and not poll for thr to be empty.
If this post doesnt get you up and running with your hello world (letting you do some of the work), let me know and i will dig out my beagleboard and create a complete example. My board doesnt exactly match yours but as far as hello world goes it should be close enough.
You could also try TI StarterWare:
http://www.ti.com/tool/starterware-sitara
I have a kernel 2.6.31 booting from a USB stick using Intel 915 based KMS to get to graphics mode. It appears to be setting itself to the native resolution and its booting nicely into framebuffer console with a beautiful Tux logo!
Question is, how do I access the inteldrmfb? How do I get it into /dev? Will udev do this for me?
What is the API for programming the framebuffer directly?
Thanks,
FM
Try the directfb library?
edit:
The kernel API is documented in linux/Documentation/fb. See Documentation/fb/framebuffer.txt in the kernel git tree, for starters. Doesn't seem to have changed for a long time. Probably still accurate. Kernel<->user APIs tend to be stable.
http://www.linux-fbdev.org/HOWTO/index.html. May be useful, but it's probably not as useful as the kernel docs.
Probably, as you say, the library source would be the best reference on how to do things.
If you're not seeing /dev/fb0, even though you have the module loaded, then maybe you need to configure udev for it? Or just mknod yourself.