Hi
I am trying to run uboot standalone application (hello_world.bin given in examples of uboot source) on beagle.
OMAP3 Beagleboard.org#mmcinit
OMAP3 Beagleboard.org#fatload mmc 0 0x80300000 hello_world.bin
reading hello_world.bin
540 bytes read
OMAP3 Beagleboard.org#go 0x80300000 hello
It stucked up there.help me int this regard
Thanks
Tilak
I am also interesting about this topic now, so please update if you have any progress in it. I use kermeit and sendb to upload the file. I just don’t sure why sometime I can send the file and most of the time it try to resend but it wasn’t success.
Thang
I did try to check the memory before I load the example by md command:
OMAP3 beagleboard.org # md 80000000
80000000: e92d4070 e1a05000 e1a00001 e1a06001 p@-…P…`…
80000010: eb000054 e3a01004 e59f007c eb000030 T…|…0…
80000020: eb000025 e3a04000 e1a01000 e59f006c %…@…l…
80000030: eb00002b e59f0068 eb000029 e59f0064 +…h…)…d…
80000040: e1a01005 eb000026 ea000005 e7963104 …&…1…
then I load the file. The process didn’t return any error but when I check the memory again, I didn’t see anything changes.
OMAP3 beagleboard.org # loadb
(Back at naruto-laptop)
Hi all
Actually it got stuck up there.Is there any other way so that we can
run only our application in the user space.(rather we can say without
OS )so that overhead of that will not effect our codec application
while calculating cycles(profiling).
Thanks
Ajay.
The problem is down to a conflict between Makefiles and the board
configuration. During compilation the Makefiles set the memory offset
(TEXT_BASE) to "0x80e80000". However, during the link stage it uses
an invalid value of "0xc100000" which results in random code being
executed when you try and call one of U-Boot's helper functions - like
printf().
The fix is pretty simple: edit examples/Makefile and change line 36
from CPU to VENDOR. So, "ifeq ($(CPU),omap3)" becomes "ifeq ($
(VENDOR),omap3)". This fix should also resolve the same problem for
overo, evm, pandora and zoom.
Having made the change you will need to clean and rebuild (i.e. don't
forget the "make mrproper")
Finally, when you load and execute the code you should use address
0x80e80000.
Hi,
As I understand, you used the u-boot source from main u-boot website not from google code website.
I tried as you said with the u-boot source from this site:
But when I run the app, I receive a bundle of letters:
OMAP3 beagleboard.org # loadb 80e80000
(Back at naruto-laptop)
Yup, I used the the mainline U-Boot source code (see: http://elinux.org/BeagleBoard#U-Boot).
While debugging the problem I found the following useful:
The output of my compile is here: “http://pastebin.com/m744cbf5c”. The TEXT_BASE values on lines 44 and 45 need to match and this is where you need to load the program in memory. I originally fudged line 48 so that Ttext matched TEXT_BASE - but that doesn’t appear to be necessary…
I think I’ll delete everything and restart as I’m more than a little confused and might have fixed the problem elsewhere inadvertently 
FYI: deleted everything and re-downloaded. Original fix still works as expected for mainline U-Boot.
U-Boot 1.3.3 source code doesn’t appear to be on Google Code anymore. But, since I had an old copy lying around I thought I’d take a look at that. Its Makefile/config setup doesn’t set the VENDOR variable for BeagleBoard. So the following line should add it:
“echo VENDOR=omap3 >> board/omap3530beagle/config.mk”
Regards,
Mike
Hi Mike,
Thank you so much for your instruction. I tried it and it run now ^_^.
As I understand you use VENDOR as a way to make it run the condition in Makefile right?
I can run it at the address 80300000 which indicates in the Makefile.
I am not quite understand about the location of the memory TEXTBASE. Why we have to indicate it in Makefile. Could you please tell me about this?
Best regards,
Thang Nguyen.
Glad you’ve got it working You are right, setting the VENDOR variable is only required to get the Makefile to set a reasonable TEXT_BASE value.
Bit of background: The OMAP3530 has an address space from 0x00000000 all the way through to 0xffffffff which is 4Gb of addressable memory. Obviously, not all of this is actual memory and mostly its just empty space. SDRAM starts at 0x80000000 and if you’ve got 256M ends at 0x8fffffff. Take a look here if you want to know more about memory addressing: http://focus.ti.com/lit/ug/spruff2a/spruff2a.pdf
So the value it was using before 0x0c100000 is way outside of useful memory. I assume, but haven’t actually checked that the memory starting at 0x80300000 is just used as stack memory, so you probably don’t want to load your program to that memory address as it will start overwriting itself…!
Provided you load the program into a memory address that isn’t needed for anything else then it “should” be fine. I’ve personally been using 0x80e80000 and 0x81000000.
Hi Mike,
Somehow I cannot load app to 0x81000000. It just displays random stuffs. It can run when I load to 0x80300000.
I checked to see what that address was used for (i.e. to test my assumption that its used for stack). Its not the stack address, but rather the address of where the application needs to be loaded to and run from. I had a couple of very simple applications that were luckily working from pretty much any address (mostly because they were only writing to memory and then exitting).
Hi all,
ifeq ($(ARCH),arm)
ifeq ($(BOARD),omap2420h4)
LOAD_ADDR = 0x80300000
else
ifeq ($(CPU),omap3)
LOAD_ADDR = 0x80300000
else
LOAD_ADDR = 0xc100000
endif
endif
endif
for this, I observed that the LOAD_ADDR variable in makefile is taking
the address in the else part means 0x1c000000, so for this I changed
directly to take 0x80300000 address by placing where LOAD_ADDR
variable using in makefile.
so that it can easily run.
But I surely didn't know it is right way of doing it.
Thanks,
Vinay.
If you have a look at the latest U-Boot Makefile there are a bunch of configuration settings that set things like ARCH, CPU, BOARD, VENDOR depending on the chosen board configuration.
The various OMAP boards set the VENDOR to “omap3” and set CPU to “arm_cortexa8”. A patch has been submitted to the U-Boot mailing list to check VENDOR rather than CPU… In the meantime the easiest fix that works with most versions of U-Boot is to simply remove that whole section you quoted and just leave “LOAD_ADDR = 0x80300000”. Of course this assumes you aren’t building U-Boot for other systems…
Hi all,
Now, Iam trying the build the binary files for my own applications and
using them as stand-alone application binary image as previously
hello_world.bin is given. so I need help to how to build our own
application binaries or is there any other way.
and second one I want to explain is as Iam trying to make RVDS build
binary image to start address of 0x80300000 and I builded that image
to that location. now this Image can I place directly as stand-alone
application binary image in u-boot and run ?.
please suggest me and help me in this work.
Thanks in Advance,
Vinay.
There is a makefile in the examples folder, you should be able to find the lines:
ELF = hello_world
SREC = hello_world.srec
BIN = hello_world.bin
replacing them by the name of your application files.
My question is can we use all of the C standard funtion to write program here?
Best regards,
Thang Nguyen
Yes and no… everything needs to be statically linked with no dependencies… you also need to be aware that syscall() based functions won’t work because there is no kernel on the other end. You also need to be aware that the hardware is in an effectively uninitialised state - so realistically a standalone application isn’t really going to be able to do much unless you get down and dirty and intimate with the hardware.
vinay (vinay07sm@gmail.com) said:
Hi all,
Now, Iam trying the build the binary files for my own applications and
using them as stand-alone application binary image as previously
hello_world.bin is given. so I need help to how to build our own
application binaries or is there any other way.and second one I want to explain is as Iam trying to make RVDS build
binary image to start address of 0x80300000 and I builded that image
to that location. now this Image can I place directly as stand-alone
application binary image in u-boot and run ?.please suggest me and help me in this work."
I’m not familiar with RVDS, but for basic gcc build I snagged the output from running make. This shows the various commands that need to be run with the associated flags. You can then build your own Makefile based on that and drop all the U-Boot baggage… You might want to consider using a “tiny” linux image: if you trim down the kernel (remove hardware drivers that you don’t need) and write your own /sbin/init program then you can get control very quickly in a much more flexible environment…
I spent about a week getting libjpeg to compile and work properly to make a trivial “photoframe” kind of application… its really rather basic and was a right pain in the @r$3…
Thank Micheal,
I am still learning, and I would like to port the uC/OS-II on BB. So I like to get down, dirty, and intimate with the hardware LOL.