I have a little more info on this...
I ignored the conflict and with some pain finally got an SREC file built and
ready to load.
I failed to get kermit and ymodem to work. If anyone knows a way of loading
with ymodem from linux using telnet or similar application over IP, I could use
a recipe. TFTP is hard to make work with VMs when you have ethernet and
wireless.
I finally was able to load via TFTP, and I get an error from the loader saying
the address was not a valid address. The image tries to load at 0x1FFF 0400.
This seems to be the address in the image.
Using version, the valid range starts at 0x1FFF CC70. So I load specifically to
that address and use "go" with the specified entry point of 0x1FFF CC89.
The result: no output from printf.
telnet 192.168.0.10 9000
RedBoot> load -v -h 192.168.0.2 -b 0x1fffcc70 hello.srec
Address offset = 0xffffc890
Entry point: 0x1fffcc89, address range: 0x1fffcc79-0x20007bec
RedBoot> go 0x1fffcc89
The app is nothing more than:
#include <stdio.h>
int main(void)
{
printf("Hello, eCos world!\n");
return 0;
}
I still have the same original questions about SRAM vs RAM and the conflict I
ignored. I have no idea if the image will work with this conflict.
Now I have more questions:
1) Why is the range of valid addresses in RedBoot different than the starting
address in the image? Is RedBoot using some RAM? Am I supposed to manually set
the start address to a safe place?
2) Is it valid to load at a different address and use the new entry point as I
showed above? Meaning, is the image relocatable?
3) Should the printf have printed on the RedBoot console?
4) What is the effect of the return 0 on the RedBoot prompt? Should it release
control so you can type?
Mike
On Dec 1, 2012, at 2:07 PM, Michael Jones <[email protected]> wrote:
> BACKGROUND
> ----------------------
>
> I am having a little bit of trouble trying to get my first hello world app on
> a K60 Tower Board.
>
> I have RedBoot running from ROM and I can ping the ethernet port, so
> presumably I will eventually get GDB to talk to it.
>
> I am having trouble building an initial app that uses the ROM monitor.
> Following the example in the eCos book, I went hunting for
> CYGSEM_HAL_USE_ROM_MONITOR, enabled it and then set startup to SRAM. This
> seems the obvious way to run and debug.
>
> PROBLEM
> --------------
>
> I am getting a conflict I don't know how to resolve. I have set
> CYG_HAL_STARTUP_VAR = SRAM. This results in CYG_HAL_STARTUP = SRAM by
> calculation.
>
> But I get a conflict from CYGSEM_HAL_USE_ROM_MONITOR that wants
> CYG_HAL_STARTUP == RAM
>
> QUESTIONS
> -----------------
>
> 1) Can I ignore this conflict and get the monitor and app to work?
>
> 2) Is there a better approach?
>
> 3) Has anyone succeeded to use RedBoot on the K60 and can you supply an
> example config project that works that I can look at?
>
> Thanks,
>
> Mike
>
> --
> Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
>
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
