[U-Boot-Users] CFG_MONITOR_BASE

[U-Boot-Users] CFG_MONITOR_BASE

[Fundu]

Is the CFG_MONITOR_BASE the location where the processor reads the first instruction after reset ? is that right ?

any clarification would be appreciated.
thanks !




      

[U-Boot-Users] u-boot.bin

[Fundu]

i'm working on taishan ppc440gx.

now here's what i noticed. snippet of u-boot.bin opened with a hex editor.


fffbffff : 27051956 552d426f 6f742031 2e322e30  '..VU-Boot 1.2.0
fffc000f : 20284a75 6c203232 20323030 38202d20   (Jul 22 2008 -
fffc001f : 31343a31 363a3037 29000000 00000000  14:16:07).......
fffc002f : 00000000 00000000 00000000 00000000  ................
fffc003f : 00000000 00000000 00000000 00000000  ................

and my u-boot.map  

.text           0xfffc0000    0x2aa9c
 cpu/ppc4xx/start.o(.text)
 .text          0xfffc0000     0x2704 cpu/ppc4xx/start.o
                0xfffc01bc                _start_of_vectors
                0xfffc0004                version_string
                0xfffc2424                dcache_enable
                0xfffc24dc                relocate_code
                0xfffc24b4                in32
                0xfffc24ac                in16r
                0xfffc2474                in8
                0xfffc24bc                in32r
                0xfffc2484                out16
                0xfffc24a4                in16
                0xfffc23ec                icache_enable
                0xfffc246c                wr_tcr
                0xfffc2100                transfer_to_handler
                0xfffc24cc                ppcDcbi
                0xfffc0100                _start

couple of question.
1) this line ".text           0xfffc0000    0x2aa9c" from u-boot.map 
which means .text starts at 0xfffc0000 and with length of 0x2aa9c. right ?

then looking at the hex dump of u-boot.bin looks like there's some data right after first word (U-Boot 1.2.0...) 
what am i missing ? 

2) when ppc440gx reset it has 0xfffffffc in its program counter, the instr at this location is a branch instr. right ?
b) this branch should go to TEXT_BASE which is 0xfffc0000 in my case. 
and that location contains 0x05195655. which looks like a "rlwimix" instr. (rotate left word immediate then mask insert). does this look start of monitor ?

Any insight on how the bootldr starts up would be appreciated too.
thanks ! 


      

[U-Boot-Users] u-boot.bin

[Fundu]

ok, looks like 0x27051956 is uboot magic number (from start.S)
why is the CFG_MONITOR_BASE points to the magic number ? 

--- On Tue, 7/22/08, Fundu <fundu_1999@yahoo.com> wrote:

> From: Fundu <fundu_1999@yahoo.com>
> Subject: [U-Boot-Users] u-boot.bin
> To: u-boot-users at lists.sourceforge.net
> Date: Tuesday, July 22, 2008, 3:44 PM
> i'm working on taishan ppc440gx.
> 
> now here's what i noticed. snippet of u-boot.bin opened
> with a hex editor.
> 
> 
> fffbffff : 27051956 552d426f 6f742031 2e322e30 
> '..VU-Boot 1.2.0
> fffc000f : 20284a75 6c203232 20323030 38202d20   (Jul 22
> 2008 -
> fffc001f : 31343a31 363a3037 29000000 00000000 
> 14:16:07).......
> fffc002f : 00000000 00000000 00000000 00000000 
> ................
> fffc003f : 00000000 00000000 00000000 00000000 
> ................
> 
> and my u-boot.map  
> 
> .text           0xfffc0000    0x2aa9c
>  cpu/ppc4xx/start.o(.text)
>  .text          0xfffc0000     0x2704 cpu/ppc4xx/start.o
>                 0xfffc01bc                _start_of_vectors
>                 0xfffc0004                version_string
>                 0xfffc2424                dcache_enable
>                 0xfffc24dc                relocate_code
>                 0xfffc24b4                in32
>                 0xfffc24ac                in16r
>                 0xfffc2474                in8
>                 0xfffc24bc                in32r
>                 0xfffc2484                out16
>                 0xfffc24a4                in16
>                 0xfffc23ec                icache_enable
>                 0xfffc246c                wr_tcr
>                 0xfffc2100               
> transfer_to_handler
>                 0xfffc24cc                ppcDcbi
>                 0xfffc0100                _start
> 
> couple of question.
> 1) this line ".text           0xfffc0000   
> 0x2aa9c" from u-boot.map 
> which means .text starts at 0xfffc0000 and with length of
> 0x2aa9c. right ?
> 
> then looking at the hex dump of u-boot.bin looks like
> there's some data right after first word (U-Boot
> 1.2.0...) 
> what am i missing ? 
> 
> 2) when ppc440gx reset it has 0xfffffffc in its program
> counter, the instr at this location is a branch instr.
> right ?
> b) this branch should go to TEXT_BASE which is 0xfffc0000
> in my case. 
> and that location contains 0x05195655. which looks like a
> "rlwimix" instr. (rotate left word immediate then
> mask insert). does this look start of monitor ?
> 
> Any insight on how the bootldr starts up would be
> appreciated too.
> thanks ! 
> 
> 
>       
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move
> Developer's challenge
> Build the coolest Linux based applications with Moblin SDK
> & win great prizes
> Grand prize is a trip for two to an Open Source event
> anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users


      

[U-Boot-Users] u-boot.bin

[Jerry Van Baren]

Fundu wrote:
> ok, looks like 0x27051956 is uboot magic number (from start.S)
> why is the CFG_MONITOR_BASE points to the magic number ? 

Because that is the definition.  From the file README:

- CFG_MONITOR_BASE:
                 Physical start address of boot monitor code (set by
                 make config files to be same as the text base address
                 (TEXT_BASE) used when linking) - same as
                 CFG_FLASH_BASE when booting from flash.

> --- On Tue, 7/22/08, Fundu <fundu_1999@yahoo.com> wrote:
> 
>> From: Fundu <fundu_1999@yahoo.com>
>> Subject: [U-Boot-Users] u-boot.bin
>> To: u-boot-users at lists.sourceforge.net
>> Date: Tuesday, July 22, 2008, 3:44 PM
>> i'm working on taishan ppc440gx.
>>
>> now here's what i noticed. snippet of u-boot.bin opened
>> with a hex editor.
>>
>>
>> fffbffff : 27051956 552d426f 6f742031 2e322e30 

This is the start, it should be (and probably is) at fffc0000.  Why does 
your dump start at fff*bffff* (one byte before where it should)?

>> '..VU-Boot 1.2.0
>> fffc000f : 20284a75 6c203232 20323030 38202d20   (Jul 22
>> 2008 -
>> fffc001f : 31343a31 363a3037 29000000 00000000 
>> 14:16:07).......
>> fffc002f : 00000000 00000000 00000000 00000000 
>> ................
>> fffc003f : 00000000 00000000 00000000 00000000 
>> ................
>>
>> and my u-boot.map  
>>
>> .text           0xfffc0000    0x2aa9c
>>  cpu/ppc4xx/start.o(.text)
>>  .text          0xfffc0000     0x2704 cpu/ppc4xx/start.o

Note the start address is fffc0000, not fffbffff.

[snip]

>> couple of question.
>> 1) this line ".text           0xfffc0000   
>> 0x2aa9c" from u-boot.map 
>> which means .text starts at 0xfffc0000 and with length of
>> 0x2aa9c. right ?

Yes.

>> then looking at the hex dump of u-boot.bin looks like
>> there's some data right after first word (U-Boot
>> 1.2.0...) 
>> what am i missing ? 

The first word is the u-boot magic number, followed by the u-boot build 
information (text).

>> 2) when ppc440gx reset it has 0xfffffffc in its program
>> counter, the instr at this location is a branch instr.
>> right ?

Yes.  See cpu/ppc4xx/start.S

>> b) this branch should go to TEXT_BASE which is 0xfffc0000
>> in my case. 

No, it jumps to the start of some CPU initialization code in the last 4K 
page (when released from reset, only the last 4K page is mapped).  That 
code maps the rest of memory and jumps to the traditional PPC startup 
code.  0xfffc0000 isn't involved.

>> and that location contains 0x05195655. which looks like a
>> "rlwimix" instr. (rotate left word immediate then
>> mask insert). does this look start of monitor ?

No, it looks like operator error.

>> Any insight on how the bootldr starts up would be
>> appreciated too.
>> thanks ! 

HTH,
gvb

[U-Boot-Users] u-boot.bin

[Fundu]

Thanks gvb!
that definitely makes sense. 

i see the u-boot.elf file is a lot bigger than the u-boot.bin. why is that ?

TIA !
--- On Wed, 7/23/08, Jerry Van Baren <gerald.vanbaren@GE.com> wrote:

> From: Jerry Van Baren <gerald.vanbaren@GE.com>
> Subject: Re: [U-Boot-Users] u-boot.bin
> To: fundu_1999 at yahoo.com
> Cc: u-boot-users at lists.sourceforge.net
> Date: Wednesday, July 23, 2008, 6:24 AM
> Fundu wrote:
> > ok, looks like 0x27051956 is uboot magic number (from
> start.S)
> > why is the CFG_MONITOR_BASE points to the magic number
> ? 
> 
> Because that is the definition.  From the file README:
> 
> - CFG_MONITOR_BASE:
>                  Physical start address of boot monitor
> code (set by
>                  make config files to be same as the text
> base address
>                  (TEXT_BASE) used when linking) - same as
>                  CFG_FLASH_BASE when booting from flash.
> 
> > --- On Tue, 7/22/08, Fundu
> <fundu_1999@yahoo.com> wrote:
> > 
> >> From: Fundu <fundu_1999@yahoo.com>
> >> Subject: [U-Boot-Users] u-boot.bin
> >> To: u-boot-users at lists.sourceforge.net
> >> Date: Tuesday, July 22, 2008, 3:44 PM
> >> i'm working on taishan ppc440gx.
> >>
> >> now here's what i noticed. snippet of
> u-boot.bin opened
> >> with a hex editor.
> >>
> >>
> >> fffbffff : 27051956 552d426f 6f742031 2e322e30 
> 
> This is the start, it should be (and probably is) at
> fffc0000.  Why does 
> your dump start at fff*bffff* (one byte before where it
> should)?
> 
> >> '..VU-Boot 1.2.0
> >> fffc000f : 20284a75 6c203232 20323030 38202d20  
> (Jul 22
> >> 2008 -
> >> fffc001f : 31343a31 363a3037 29000000 00000000 
> >> 14:16:07).......
> >> fffc002f : 00000000 00000000 00000000 00000000 
> >> ................
> >> fffc003f : 00000000 00000000 00000000 00000000 
> >> ................
> >>
> >> and my u-boot.map  
> >>
> >> .text           0xfffc0000    0x2aa9c
> >>  cpu/ppc4xx/start.o(.text)
> >>  .text          0xfffc0000     0x2704
> cpu/ppc4xx/start.o
> 
> Note the start address is fffc0000, not fffbffff.
> 
> [snip]
> 
> >> couple of question.
> >> 1) this line ".text           0xfffc0000   
> >> 0x2aa9c" from u-boot.map 
> >> which means .text starts at 0xfffc0000 and with
> length of
> >> 0x2aa9c. right ?
> 
> Yes.
> 
> >> then looking at the hex dump of u-boot.bin looks
> like
> >> there's some data right after first word
> (U-Boot
> >> 1.2.0...) 
> >> what am i missing ? 
> 
> The first word is the u-boot magic number, followed by the
> u-boot build 
> information (text).
> 
> >> 2) when ppc440gx reset it has 0xfffffffc in its
> program
> >> counter, the instr at this location is a branch
> instr.
> >> right ?
> 
> Yes.  See cpu/ppc4xx/start.S
> 
> >> b) this branch should go to TEXT_BASE which is
> 0xfffc0000
> >> in my case. 
> 
> No, it jumps to the start of some CPU initialization code
> in the last 4K 
> page (when released from reset, only the last 4K page is
> mapped).  That 
> code maps the rest of memory and jumps to the traditional
> PPC startup 
> code.  0xfffc0000 isn't involved.
> 
> >> and that location contains 0x05195655. which looks
> like a
> >> "rlwimix" instr. (rotate left word
> immediate then
> >> mask insert). does this look start of monitor ?
> 
> No, it looks like operator error.
> 
> >> Any insight on how the bootldr starts up would be
> >> appreciated too.
> >> thanks ! 
> 
> HTH,
> gvb


      

[U-Boot-Users] u-boot.bin

[Jerry Van Baren]

Fundu wrote:
> Thanks gvb!
> that definitely makes sense. 
> 
> i see the u-boot.elf file is a lot bigger than the u-boot.bin. why is that ?

Hi Fundu,

Please bottom post.

Run "${CROSS_COMPILE}objdump -h u-boot" and you will see that there are 
lots of non-loaded segments (symbols, etc.) in there.

Run "${CROSS_COMPILE}strip -s u-boot -o=u-boot.strip" and you will see 
that u-boot.strip is approximately the same size as u-boot.bin.  NOTE: I 
would *NOT* recommend stripping the ELF file unless you have a real need 
to do so.

gvb

[U-Boot-Users] u-boot.bin

[Fundu]

> Please bottom post.
will do.

> Run "${CROSS_COMPILE}strip -s u-boot
> -o=u-boot.strip" and you will see 
> that u-boot.strip is approximately the same size as
> u-boot.bin.  NOTE: I 
> would *NOT* recommend stripping the ELF file unless you
> have a real need to do so.
that make it much clear thx. is the stripped out file of any use ? it won't work with gdb ? so then under what situation would you want to strip.

TIA.



      

[U-Boot-Users] u-boot.bin

[Jerry Van Baren]

Fundu wrote:
>> Please bottom post.
> will do.
> 
>> Run "${CROSS_COMPILE}strip -s u-boot
>> -o=u-boot.strip" and you will see 
>> that u-boot.strip is approximately the same size as
>> u-boot.bin.  NOTE: I 
>> would *NOT* recommend stripping the ELF file unless you
>> have a real need to do so.
> that make it much clear thx. is the stripped out file of any use ? it won't work with gdb ? so then under what situation would you want to strip.
> 
> TIA.

The two reasons I can think of for stripping elf files...
1) Make it smaller if you have to transport it on/over a size sensitive 
medium (floppy, modem).  Maybe also to cram more on a limited size 
embedded file system.

2) Most proprietary packages strip their packages to try to prevent 
their "valuable intellectual property" from leaking out.  (This has 
limited real value, but PHBs think it is a very valuable thing to do.)

To reiterate, there is almost no reason to strip elf files.

Best regards,
gvb

[U-Boot-Users] CFG_MONITOR_BASE

[Wolfgang Denk]

In message <420794.71173.qm@web63409.mail.re1.yahoo.com> you wrote:
> Is the CFG_MONITOR_BASE the location where the processor reads the first instruction after reset ? is that right ?

No. The processor starts the execution at the reset entry point. This
may be 0x100 or 0xFFF00100 on some PowerPC processors or 0xFFFFFFFC on
some others, or 0x00000000 on ARM, or ...

CFG_MONITOR_BASE is the start address of the U-Boot image in flash.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
You go slow, be gentle. It's no one-way street -- you  know  how  you
feel and that's all. It's how the girl feels too. Don't press. If the
girl feels anything for you at all, you'll know.
	-- Kirk, "Charlie X", stardate 1535.8