Forum Discussion
Altera_Forum
Honored Contributor
21 years agoScott,
My system has the same 8MB flash device as the PK1C20 at 0x0, and 2MB sram at 0x800000. My HW has already been fully tested under uCos, and I thought the bootloader functions would be a nice addition. The download image is the same size (90KB) as the PK1C20 consuming 2 sectors of flash. The ram usage described in the CFG settings is roughly: 128K of relocated code, 64K of env space, 128K of heap, plus whatever stack space say 64K. This all adds up to 384K of RAM in rough numbers. I was saying sectors before, but of course this is ram so it is not quite so bad. The code does not fill up the entire 128K, and the stack wont use up the entire 64K. Probably closer to 300K actual ram use. If I am missing something, let me know. I have not burned u-boot into my flash on this board. I have download u-boot over jtag to get it running, but have been unable to use u-boot to download an image of itself for flashing because this step crashes. My TEXT_BASE is 0x9D0000, so I would expect no u-boot use below 0x9A0000 (256K). When I do a mw.b for the memory from 0x800000 to 0x9D0000, u-boot crashes (locks) apparently because I am writing over some parts it is actively using. There are two regions. First, I see three long words at 0x800020 that I verified with objdump are the trampoline instructions you mentioned, but writing over them causes u-boot to either reset, lockup or stop working correctly (depends on which one I write over). If I understand the trampoline, it is only using during relocation, and it should't matter what happens to that memory afterwards. Also my <myboard>.h file I created defines CFG_EXCEPTION_ADDR to be x900020. Isn't this where the trampoline should be? Likewise there is a region from x8cfa00 - x8d0000 (~1500 bytes) that seems to be a critical area of some kind. When I try to write over this region I get a lockup. A subsequent download and md shows this region to be unchanged as if it were .data or vector table. Lots of xdeadbeef entries in the region. Hmm.. I don't think I am getting a good build. I see some inconsistent behavior. The prompt doesn't appear after the splash screen when I re-download after a crash as if u-boot were not inited properly. Some things I have changed: TEXT_BASE 0x9D0000 CFG_RESET_ADDR 0x900000 CFG_EXCEPTION_ADDR 0x900020 CFG_NIOS_TMRMS 1 base addresses for uarts etc are different in general I started with u-boot 1.1.2 src. If I change the first three to 0x900000, 0x800000, 0x800020 I get more consistent behavior, but I still cant use the lower memory. BTW the netconsole stuff appears to be just stubs.