I am a newbie of u-boot and I have a question when I am developing u-boot that if I add/init a device driver into u-boot, how does the u-boot know where and what the corresponding device is? Is there a way to register a device or device tree like the kernel does?
Adding the new board to U-boot it goes like this. When you config the Uboot it will select the corresponding device that is mentioned at step 4.
Device tree(DTS) also used where you can list the device info that is introduced from 2012. This just describes about the hardware of your board.
The board file needs to be created -> board/x_vendor/your_board/your_board.c
Config file can be Kconfig -> board/x_vendor/x_board/Kconfig
Makefile for the board -> board/x_vendor/your_board/Makefile
defconfig for the board
When you do this it will add the corresponding device code.
Example.
configs/your_board_defconfig
CONFIG_ARM=y
CONFIG_ARCH_MX6=y
CONFIG_TARGET_MY_BOARD=y
CONFIG_MXC_UART=y
Header file for the board ->include/configs/your_board.h
board Kconfig needs to be sourced in architecture Kconfig. -> arch/arm/Kconfig
Related
Is it possible to programmatically add file tag to a file of type image (png/jpeg) in iOS? I am using the camera to capture the image and am writing the data into a file in the Documents folder in my iOS app.
Then, i use the file sharing capability in iTunes to transfer the images out to my MAC or Windows Desktop.
After i export all the files in this fashion, i would like to sort the images by tag on my MAC or Windows Desktop.
The definition of tag in the MAC world is different than that of the Windows, it appears. But setting that difference aside for a moment, both MAC and Windows allow the user to manually assign some sort of a TAG to the file so that we can sort it and view it in Finder or File explorer applications respectively on those platforms.
So, the question is: In an iOS app, when i am creating an image file, can i programmatically assign some sort of tag which i can then leverage to sort on my MAC or Windows after i export those files.
Thanks for your time all.
I am porting binutils to a new arch. What is the sim folder for ? and how can I use it ? If I understand correctly, the sim folder suppose to build some kind of simulator for the new arch but I can't find any information about it. Is there more information anywhere ?
The sim directory is indeed for simulators. When you build gdb, you can choose to enable a simulator, if one exists, for the primary target (there's no support for building multiple simulators). The simulator is then linked into gdb and can be accessed using target sim. There's a section in the manual explaining more about this.
It's certainly possible to write a new sim. However, if I was doing a port to a new arch, I would instead consider writing a qemu port. Qemu is faster and useful for more things than the gdb sims.
I need to debug the startup for an ios application on an actual device... and by start up I mean the very first instruction that is is executed when the OS hands control over to the app. Not "main". Also, this application doesn't have any symbols (ie. the debug information isn't available.. yet). I don't care if I have to debug at the CPU instruction level. I know how to do that (done it for over 30 years). I want the debugger to stop when control is about to transfer to the app. When I use the Attach|by Name command and run, it just says "Finished running".
Oh, and this application was not built in XCode. It is, however an application I built, signed and provisioned and moved to the device. The application does run since I can see the console output. Just in case you're thinking I'm some hacker trying to debug someone's application.
How's that for a tall order? I'll bet nobody can answer this... I've not been able to find any information on how I could do this with an XCode-built project. I wonder if it is simply not possible or "allowed" by the Apple overlords?
What do you say, Stack Overflow gods?
UPDATE: I should clarify something. This application is not built with any commercially available or open-source tool. I work with a tools vendor creating compilers, frameworks, and IDEs. IOW, you cannot get this tool... yet. In the process of bootstrapping a new tool chain, one regularly must resort to some very low-level raw debugging. Especially if there are bugs in the code generated by the tools.
I'm going to answer my own question because I think I've stumbled upon a solution. If anyone has anything more elegant and simple than this, please answer as well. On to the steps:
Starting with a raw monolithic iOS executable (not a bundled .app, but the actual binary mach-o file that is the machine code).
Create a new like-named empty Xcode project. Build and run it on the device.
Locate the output bundle's .app folder.
Copy the above raw iOS executable over the existing one in the .app bundle's folder.
The application will now have an invalid signature and cannot be deployed and run.
Run codesign against the app bundle (you can find out the command-line by running xcodebuild on the above Xcode project).
In the bundle's .app folder, run otool -h -l on the binary image. Locate the LC_UNIXTHREAD load command and find the value associated with the 'pc' register. This is address where the os loader will jump to your application. If this address is odd, then these are Thumb instructions otherwise it will be ARM (I think that's how it works).
Add a symbolic breakpoint (I used GDB instead of LLDB) and enter the address as '*0x00001234' as the symbol.
Select Product|Perform Action|Run Without Building.
Assuming that GDB is able to evaluate the breakpoint expression and set the break point, and you've selected Product|Debug Workflow|Show Disassembly When Debugging, the process should break at the very first instruction to be executed in the application.
You can now single step the instructions and use the GDB console to get/set register values.
Your question does not make sense - main is the entry point into the application. It is the first code that should be encountered, unless possibly you have initialize() overridden for some classes (but even then I think main would get hit before the runtime).
I think you are seeing some kind of odd error on launch and you think you want to set a breakpoint on entry to catch it, but far more likely what would help you is to describe the problem on launch and let one of the 4000 people who have seen and fixed the same crash help you...
However, if you really want to use GDB to break on an application with no symbols (but that you launch from XCode) you can have GDB break on an assembly address as per:
How to break on assembly instruction at a given address in gdb?
To find the address of main (or other methods) you can use tool or atos, some examples in this question:
Matching up offsets in iOS crash dump to disassembled binary
ADDITION:
If for some reason XCode cannot launch your application for debugging, you could also jailbreak and install GDB on the device itself which would give complete control over debugging. If XCode can launch you application I see no reason why being able to break at an arbitrary memory address does not give you the ability you seek...
One solution for applications with webviews is to run them in the iOS Simulator, and connect to that with the remote-debugger in macOS Safari. This is off-topic but maybe the one or other could benefit.
http://hiediutley.com/2011/11/22/debugging-ios-apps-using-safari-web-inspector/
Or use NetCat for iOS... not the most perfect solution, but at least you see what's going on.
I am providing this for everyone to hopefully save you some brain damage in finding this yourself.
As I'm working on a BlackBerry project that will run on various devices I ran into an issue grabbing screenshots from the handset (including the Torch 9850 ... not quite as good as my iPhones or my Android EVO or Infuse, but much better than the Storm and finally starting to look like a real smartphone - great performance and battery life too).
Normally I'd use my trusty BBScreenShooter and everything would be fine, but it kept crashing when attempting to capture images on the 9850. I posted a couple of requests for help on this site, but nobody could tell me why my BBScreenShooter was crashing or why I'd get "Retrieving screen <active> data ... Error: buffer too small" when using RIM's JavaLoader utility directly.
For those who didn't know BBScreenShooter delegates the "heavy lifting" to JavaLoader to grab the images.
With the help of Mark Sohm (easily one of the most knowledgable BB guys I know walking the planet) he asked me to verify I was using JavaLoader that is included in the v7 SDK. Turns out I wasn't. Good catch Mark, and thanks!
From the looks of things it appears the earlier versions of the JavaLoader utility have byte[] buffers they use for image capture that are hardcoded ... and too small.
So, for all those who need to capture screen shots from RIM's new 480 x 800 based handsets I have included a quick "how to" guide to help you get productive ASAP.
Step 1 - Make sure you have the v7.0 SDK downloaded (doesn't have to be installed, though I cannot think of a good reason not to). For Eclipse users:
Step 1a) Go to the Help menu
Step 1b) Install New Software menu choice
Step 1c) Add the "BlackBerry - http://www.blackberry.com/go/eclipseUpdate/3.6/java" items in your "work with" field.
Step 1d) Under the "BlackBerry Java Plug-in Category", look for the "BlackBerry Java SDK v7.0.0.X" checkbox and click NEXT.
Step 1e) Accept the license agreements and continue the download and installation process.
Step 2 - Go to the installation directory for your newly added SDK. We're going to grab a copy of the path to the JavaLoader utility and use it within a BAT file that will automate the capture and naming of screen shots. This will be found at /plugins/net.rim.ejde.componentpack7.0.0_7.0.0.28/components/bin/JavaLoader.exe
Step 3 - Create a folder you'd like to use to save screen captures. This will also hold your BAT file as the BAT file is specific to this particular project.
Step 4 - Create the BAT file. In my example here I keep all my IDEs, SDK, ... effectively all development environments on a different hard drive than my OS. I keep these on drive D, but modify your BAT to reflect the location and needs of your configuration.
Step 4a) It's important to turn the echo off, otherwise you will probably be unable to use the icon on the desktop to launch this script/utility.
Step 4b) If your BAT file is running locally (same folder) as JavaLoader then this step will be unnecessary. On the other hand if your JavaLoader is on a different hard drive and tucked away deep in folders then you'll have to "change directory" to get to it. Notice the "/D" switch that is used with the "change directory - cd" command so that we can change drives and paths in the same step.
Step 4c) As I like to use timestamps for part of my file names ... set local variables to represent the current date and time.
step 4d) The following "for" statements parse out the current date and time from my Windows 7 computer into a format that I want to include as the file names for my screen captures ... file name == BlackBerry_<date image was taken>_<time image was taken>.bmp.
Step 4e) Copy the newly created device screen shot that JavaLoader captured to your target folder and use the file name we've just created.
Step 4f) Now that we've successfully got a copy of the screenshot saved in our desired target folder we can delete the temporary image that JavaLoader created.
Step 4g) I echo a little statement that lets me know it all worked.
Example BAT file:
#echo off
cd /D D:\Program Files (x86)\EclipseBlackBerry\plugins\net.rim.ejde.componentpack7.0.0_7.0.0.28\components\bin
JavaLoader screenshot tempImage.bmp
set timestampdate=%date%
set timestamptime=%time%
For /f "tokens=2-4 delims=/ " %%a in ('date /t') do (set timestampdate=%%c-%%a-%%b)
For /f "tokens=1-2 delims=/:" %%a in ('time /t') do (set timestamptime=%%a%%b)
copy tempImage.bmp "C:\Users\CirrusFlyer\Desktop\<project name>\Testing\Screenshots\BlackBerry_%timestampdate%_%timestamptime%.bmp"
DEL tempImage.bmp
echo Completed "...\<project name>\Testing\Screenshots\BlackBerry_%timestampdate%_%timestamptime%.bmp"
Step 5 - Close and save your BAT file. I kept the BAT in my actual project folder, then created a shortcut and placed it on my desktop. This way I can have my Eclipse up and running and be debugging the application on my handset, and when I want to grab a screen shot simply double-click the shortcut to execute the capture.
This will create screen shots and place them in the target directory: BlackBerry_2011-10-07_1015 PM.bmp, for example.
Step 6 - Your done. Happy coding. Hope this helps.
My next project: extending Eclipse so that I can do screen captures directly from within the IDE the same way I can when doing Android based programming.
At my job, I was tasked with making a prototype of a new audio device. The heart of the prototype will be an Analog Devices, Inc. Ez-Board with a SHARC 21469 chip.
Using VisualDSP++ 5.0, I wrote the necessary software in C, and it runs perfectly now. But I only know how to download the program into RAM using VisualDSP++ and the JTAG emulator.
I have been trying to figure out how to program the flash memory on the Ez-Board so that any time the board powers up, it will run my C program. How does that work?
I figured this out.
First, in VisualDSP++, under the "Tools" menu, there is a nice GUI for programming flash memory. However, different hardware platforms need different code to do the flash programming, so the GUI is designed to take a "plugin" program that will do the actual flash programming. The Analog Devices Inc. term for this plugin is a "driver". So, before you do anything else, you need to set the correct plugin for flash programming; you do this on the first "tab" of the flash programmer tabbed dialog (the "Driver" tab). Choose the correct driver .dxe file and click on the "Load" button.
Since I am using the 21469 Ez-Board, the "plugin" is available from the sample code for that board. Here is the full pathname of the driver file:
c:\Program Files\Analog Devices\VisualDSP 5.0\214xx\Examples\ADSP-21469 EZ-Board\Flash Programmer\Parallel\21469EzFlashDriver_Parallel.dxe
With that done, you can now build a "loader" file instead of the usual executable. Open your code project in VisualDSP++, and go to the Project Options dialog (Alt+F7). From the "Project" page, change "Type:" from "Executable file" to "Loader file". An "executable file" has the extension ".dxe" while a "loader file" has the extension ".ldr". There are some options that control how the .ldr file is built, but the defaults work fine (at least they did for me with an Ez-Board).
Now build your project as usual. Instead of building a .dxe file, it will build a .ldr file.
Finally, choose "Tools/Flash Programmer..." to bring up the flash programming GUI, and click on the second tab in the tabbed dialog, "Programming". For some reason the loader file is called the "data" file on this page of the dialog. Choose your .ldr file for programming, and hit the "program" button.