[U-Boot-Users] environment problem with new board

[U-Boot-Users] environment problem with new board

[Joe Steeve]

I'm porting u-boot to a Sigma Designs em8620L based board. The em8620L
is an SOC with an ARMv4t core (pT-110).

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
in the sources. Any pointers would be of help. I'm defining
'CFG_ENV_IS_NOWHERE'.

I also have defined CONFIG_COMMANDS to CFG_CMD_ALL., however I see only
the following commands when i issue a 'help' on the prompt.,

?       - alias for 'help'
bootm   - boot application image from memory
go      - start application at address 'addr'
help    - print online help
printenv- print environment variables
reset   - Perform RESET of the CPU
saveenv - save environment variables to persistent storage
setenv  - set environment variables
version - print monitor version

Is this right??

-- 
Joe Steeve
Sliceware Private Limited

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: OpenPGP digital signature
Url : http://lists.denx.de/pipermail/u-boot/attachments/20061122/842a5bbe/attachment.pgp 

[U-Boot-Users] environment problem with new board

[Wolfgang Denk]

In message <4563CB86.1060006@sliceware.com> you 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?

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

Why are you doing this?

> 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.]

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Never underestimate the power of human stupidity  when  it  comes  to
using technology they don't understand.

[U-Boot-Users] environment problem with new board

[Joe Steeve]

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.

-- 
Joe Steeve
Sliceware Private Limited

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: OpenPGP digital signature
Url : http://lists.denx.de/pipermail/u-boot/attachments/20061122/abd00b93/attachment.pgp 

[U-Boot-Users] environment problem with new board

[Wolfgang Denk]

In message <456459DC.7020905@sliceware.com> you wrote:
>
> 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.
...
> >> in the sources. Any pointers would be of help. I'm defining 
> >> 'CFG_ENV_IS_NOWHERE'.
...
> 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

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.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Writing a book is like washing an elephant: there's no good place  to
begin  or  end,  and  it's  hard to keep track of what you've already
covered.

[U-Boot-Users] environment problem with new board

[Joe Steeve]

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?

-- 
Joe Steeve
Sliceware Private Limited

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: OpenPGP digital signature
Url : http://lists.denx.de/pipermail/u-boot/attachments/20061123/04761734/attachment.pgp 

[U-Boot-Users] environment problem with new board

[Wolfgang Denk]

In message <45649FEE.6030107@sliceware.com> you wrote:
>
> > 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

No. You _though_ you had to do this. This was one of your errors.

> 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.

...or with your configuration

> is defined in include/cmd_confdefs.h. Should I be including this header
> in the configs/myboard.h?

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>

Guess what that does?

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"Everything should be made as simple as possible, but not simpler."
                                                    - Albert Einstein

[U-Boot-Users] PCI Initialization for AMCC440EP

[Pras]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20061122/943378b1/attachment.htm 

[U-Boot-Users] environment problem with new board

[Joe Steeve]

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.

-- 
Joe Steeve
Sliceware Private Limited

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: OpenPGP digital signature
Url : http://lists.denx.de/pipermail/u-boot/attachments/20061123/fb2bbdf2/attachment.pgp 

[U-Boot-Users] environment problem with new board

[Joe Steeve]

Wolfgang Denk wrote:
> In message <45649FEE.6030107@sliceware.com> you wrote:
>>> 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
> 
> No. You _though_ you had to do this. This was one of your errors.

Yeah., I actually I thought I had to do this. I did notice the -Ttext
being passed to the linker. And I saw that., because of that all the
sections were being linked to the TEXT_BASE. That meant I'd have to
write position independant code in my start.S until till u-boot is
relocated outside.

Or am i still missing something :-S

-- 
Joe Steeve
Sliceware Private Limited

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: OpenPGP digital signature
Url : http://lists.denx.de/pipermail/u-boot/attachments/20061123/3618dfb1/attachment.pgp 

[U-Boot-Users] PCI Initialization for AMCC440EP

[Wolfgang Denk]

In message <845975.48557.qm@web32014.mail.mud.yahoo.com> you wrote:
>
>   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.

Have a look at the header files. These functions get auto-built by
concatenating strings... It's just a bit of CPP trickery.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
If I had to live my life again,  I'd  make  the  same  mistakes, only
sooner.                                          -- Tallulah Bankhead