Wolfgang Denk wrote:

...

I managed to get u-boot to the prompt :) However., a 'printenv' dumps garbage on the console. I've been slightly clueless as to where to look

Is anything else working? Does "md" work as expected? Can you "cp" data fromone part of the RAM to the other, and verify that it gets copied ok?

When i try those commands i get an 'unknown command'. The only thing that works apart from 'help' is 'version' :P I think I screwed something with the cmdtbl. I've a slightly messed up u-boot.lds where all input sections (.text, .data, .rodata*, . u_boot_cmd,..) in one huge section. So., maybe something is going wrong with it. I'm going to split up the sections like on the other boards and see if that makes a difference. The following is the relevant part of the map file (the whole thing is a part of the .text section of the output file..).

0x9100abb0 __u_boot_cmd_start = . *(.u_boot_cmd) .u_boot_cmd 0x9100abb0 0x30 common/libcommon.a(cmd_boot.o) 0x9100abb0 __u_boot_cmd_reset 0x9100abc8 __u_boot_cmd_go .u_boot_cmd 0x9100abe0 0x18 common/libcommon.a(cmd_bootm.o) 0x9100abe0 __u_boot_cmd_bootm .u_boot_cmd 0x9100abf8 0x48 common/libcommon.a(cmd_nvedit.o) 0x9100abf8 __u_boot_cmd_saveenv 0x9100ac28 __u_boot_cmd_printenv 0x9100ac10 __u_boot_cmd_setenv .u_boot_cmd 0x9100ac40 0x48 common/libcommon.a(command.o) 0x9100ac40 __u_boot_cmd_question_mark 0x9100ac70 __u_boot_cmd_version 0x9100ac58 __u_boot_cmd_help 0x9100ac88 __u_boot_cmd_end = .

...

in the sources. Any pointers would be of help. I'm defining 'CFG_ENV_IS_NOWHERE'.

Why are you doing this?

Basically., I just want a default environment which was defined at compile time (for starters). I thought I'll get the basic functionality working before getting all the features to work. Finally the bootloader is going to sit inside an SPI-EPROM (SST25).

...

Is this right??

No. You don't provide much information, but my first guess is that you have RAM problems. [Yes, that's always my first guess. But I know that this is the cause of 99% of all initial problems.]

Hmm., right now I already have a proprietary bootloader sitting in the EPROM. I'm making that bootloader load the u-boot image in the right place and transfer control to it. So., I dont see how the RAM could be a problem. However., I dont do a 'dram memory test yet' in the code., I think I should do that to verify things are actually fine.

Wolfgang Denk wrote:

...

that works apart from 'help' is 'version' :P I think I screwed something with the cmdtbl. I've a slightly messed up u-boot.lds where all input sections (.text, .data, .rodata*, . u_boot_cmd,..) in one huge section.

You're meddling with a lot of pretty critical places all at once. I wouldn't do that, if I were you. I see no reason to mess with the linker script, for example.

I had to do that because., the boot code starts executing at 0x40000000 which is a ROM., and the DRAM is at 0x90000000. So., the startup relocation code is linked at 0x40000000 while the relocatable code (the rest of u-boot) is linked at 0x90000000. In the startup code., i move u-boot out to the DRAM and transfer control to 'start_armboot' in lib_arm/board.c

All existing linker scripts start at one constant address., and so have no issues. Anywayz., I figured the problem is not with the linker script., but something weird with the macros.

For example., I checked using #error messages and found that the following '#if' in common/cmd_mem.c is failing.,

#if (CONFIG_COMMANDS & (CFG_CMD_MEMORY | \ CFG_CMD_I2C | \ CFG_CMD_ITEST | \ CFG_CMD_PCI | \ CMD_CMD_PORTIO ) )

I have '#define CONFIG_COMMANDS CFG_CMD_ALL' in my configs/myboard.h.

I'm quite confused how the compiler did not throw an error. When compiling common/cmd_mem.c, the first header to be included is the config.h, in which CFG_CMD_ALL is used but not defined. I found that it is defined in include/cmd_confdefs.h. Should I be including this header in the configs/myboard.h?

Hello Folks,

I was trying to understand the PCI initialization for the Yellowstone board in file

/board/amcc/yellowstone/yellowstone.c

I was looking for the function

pci_write_config_word(0, PCI_SUBSYSTEM_VENDOR_ID, CFG_PCI_SUBSYS_VENDORID);

for which I could not find the declaration.

There was one in

board/amirix/ap1000/powerspan.c

and one in

cpu/ixp/pci.c

but both don't seem to be revelant to AMCC 440EP. A cscope search didn't help. Appreciate if anybody can point me to the right function for Yellowstone board.

thank you Pras

--------------------------------- Everyone is raving about the all-new Yahoo! Mail beta.

Wolfgang Denk wrote:

If you had just compared your ocnfiguration agains any other existing, known to be working board, you should have run over this comment in all board config files:

/* this must be included AFTER the definition of CONFIG_COMMANDS (if any) */ #include <cmd_confdefs.h>

Yeah., I missed it. Thanks.

common/cmd_mem.c functions work now. However., a printenv is still crashing.