Re: [U-Boot] Debugging why my kernel won't start

[Wolfgang Denk]

Dear Rogan Dawes,

In message <4c6c0b33.8090...@dawes.za.net> you wrote:
>
> Well, I thought that was the point of the "mkimage" header, with the
> Load Address and Entry Point fields. Although, of course, you'll never

These fields are only relevant for executable images, not for data
like ramdisk images.

> actually "enter" a ramdisk image. I had still thought that they would be
> copied, regardless. Otherwise, what is the point in specifying those
> fields? They might just as well be zero.

Indeed, and that's they usally are:

-> mkimage -l /opt/eldk-4.2/arm/images/uRamdisk
Image Name:   Simple Embedded Linux Framework
Created:  Sun Dec  7 18:27:20 2008
Image Type:   ARM Linux RAMDisk Image (gzip compressed)
Data Size:1659739 Bytes = 1620.84 kB = 1.58 MB
Load Address: 
Entry Point:  

Copying the image is just a waste of boot time. I see no reeason why
the kernel should not be able to read the image from RAM or from
flash. On PowerPC this has always been possible, for well over a
decade now.  But in ARM land they reject patches that would add such
support.

> So, the question then is, what is current u-boot doing? And why does it

In mainline code, it is supposed to verify the checksum and pass
the start address of the data to the kernel.

> not work when the ramdisk is copied over to memory?

This I cannot answer.

> It looks like U-Boot for ARM doesn't handle ramdisks at all? From
> common/cmd_bootm.c:

It does.

> #if defined(CONFIG_PPC) || defined(CONFIG_M68K) || defined(CONFIG_SPARC)
> case BOOTM_STATE_RAMDISK:

This is actually the wrong place.

> Is this the missing functionality that I am looking for?

No.

For a test you might try to hook into this part of code, though:

"common/image.c":

 952 #if defined(CONFIG_B2) || defined(CONFIG_EVB4510) || 
defined(CONFIG_ARMADILLO)
 953 /*
 954  * We need to copy the ramdisk to SRAM to let Linux boot
 955  */
 956 if (rd_data) {
 957 memmove ((void *)rd_load, (uchar *)rd_data, 
rd_len);
 958 rd_data = rd_load;
 959 }
 960 #endif /* CONFIG_B2 || CONFIG_EVB4510 || CONFIG_ARMADILLO */

This indeed performs a copy to the load address, as you expected.

Here is a log from a working example (QOng board, i. e. ARM11):

=> run flash_self
## Booting kernel from Legacy Image at a00a ...
   Image Name:   Linux-2.6.34-rc1
   Created:  2010-04-28  22:07:22 UTC
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:1964848 Bytes = 1.9 MiB
   Load Address: 80008000
   Entry Point:  80008000
   Verifying Checksum ... OK
## Loading init Ramdisk from Legacy Image at a030 ...
   Image Name:   Simple Embedded Linux Framework
   Created:  2008-11-24  16:44:17 UTC
   Image Type:   ARM Linux RAMDisk Image (gzip compressed)
   Data Size:1659703 Bytes = 1.6 MiB
   Load Address: 
   Entry Point:  
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.
Linux version 2.6.34-rc1 (w...@sirius.denx.de) (gcc version 4.2.2) #3 Thu Apr 
29 00:07:17 CEST 2010
CPU: ARMv6-compatible processor [4107b364] revision 4 (ARMv6TEJ), cr=00c5387f
CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
Machine: Dave/DENX QongEVB-LITE
Memory policy: ECC disabled, Data cache writeback
INITRD: 0xa0300040+0x00195337 extends beyond physical memory - disabling initrd
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 65024
Kernel command line: root=/dev/ram rw ramdisk_size=8192 
ip=192.168.20.12:192.168.1.1::255.255.0.0:qong:eth0:off panic=1 
console=ttymxc0,115200 
mtdparts=physmap-flash.0:384k(U-Boot),128k(env1),128k(env2),2432k(kernel),61m(rootfs),64m(user)
 ethaddr=00:50:c2:1e:af:e7 nohlt
...
Trying to unpack rootfs image as initramfs...
rootfs image is not initramfs (no cpio magic); looks like an initrd
...
RAMDISK: gzip image found at block 0
VFS: Mounted root (ext2 filesystem) on device 1:0.
Freeing init memory: 140K
init started: BusyBox v1.7.1 (2008-11-24 17:40:49 MET)
starting pid 612, tty '': '/etc/rc.sh'
starting pid 617, tty '': '/bin/application'
### Application running ...
starting pid 618, tty '': '/bin/sh'
~ # eth0: link up (100/Full)
~ # 


[Note: the Qong is running a kernel version that has the patch added
which supports loading the ramdisk image from a flash address.]

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: w...@denx.de
The years of peak mental activity are undoubtedly between the ages of
four and eighteen. At four we know all the questions, at eighteen all
the answers.
_

Re: [U-Boot] Debugging why my kernel won't start

[Rogan Dawes]

On 2010/08/18 5:33 PM, Wolfgang Denk wrote:
> Dear Rogan Dawes,
> 
> Your kernel may not be able to pick up a ramdisk image in flash.
> 
> Mainline ARM cannot do that, for example.
> 
> [Patches to support that have been submitted, but rejected.]
> 
>> Surely that should be Ok? Besides, U-boot is supposed to copy the data
>> in the image to the specified destination address, isn't it?
>
> No, why should it copy the image? It just verifies that the checksum
> is OK, and then passes the address to the kernel. The kernel will have
> to copy it anyway when uncompressing it, so ther ei no use in U-Boot
> adding another copy operation.

Well, I thought that was the point of the "mkimage" header, with the
Load Address and Entry Point fields. Although, of course, you'll never
actually "enter" a ramdisk image. I had still thought that they would be
copied, regardless. Otherwise, what is the point in specifying those
fields? They might just as well be zero.

But yes, what you say makes sense.

This appears to be the answer, from Marvell's u-boot sources, in
lib_arm/armlinux.c, inside the #ifdef RAMDISK block:

#ifdef  DEBUG
if (!data) {
printf ("No initrd\n");
}
#endif

if (data) {
#ifdef RAMDISK
initrd_start = ntohl(hdr->ih_load);
initrd_end = initrd_start + len;
memmove ((void *)initrd_start, (void *)data, len);
#else
initrd_start = data;
initrd_end = initrd_start + len;
#endif
} else {
initrd_start = 0;
initrd_end = 0;
}

and then later:

#ifdef CONFIG_INITRD_TAG
if (initrd_start && initrd_end)
setup_initrd_tag (bd, initrd_start, initrd_end);
#endif

So, clearly, the address that the kernel is expecting MUST be within
RAM, and MUST exclude the header.

So, the question then is, what is current u-boot doing? And why does it
not work when the ramdisk is copied over to memory?

It looks like U-Boot for ARM doesn't handle ramdisks at all? From
common/cmd_bootm.c:

#if defined(CONFIG_PPC) || defined(CONFIG_M68K) || defined(CONFIG_SPARC)
case BOOTM_STATE_RAMDISK:
{
ulong rd_len = images.rd_end - images.rd_start;
char str[17];

ret = boot_ramdisk_high(&images.lmb,
images.rd_start,
rd_len, &images.initrd_start,
&images.initrd_end);
if (ret)
return ret;

sprintf(str, "%lx", images.initrd_start);
setenv("initrd_start", str);
sprintf(str, "%lx", images.initrd_end);
setenv("initrd_end", str);
}
break;
#endif

But this is only enabled for PPC, M68K and SPARC.

Is this the missing functionality that I am looking for?

Rogan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Debugging why my kernel won't start

[Wolfgang Denk]

Dear Rogan Dawes,

In message <4c6bf138.20...@dawes.za.net> you wrote:
>
> > Try copying the raw ramdisk image (i. e. without the U-Boot header) to
> > RAM, and try that one, i. e. something like
> > 
> > => cp.b ff9a0040 0160 ...size...
> > ...
> > => bootm ff82 160
> 
> Unfortunately, U-boot is expecting the second parameter to point to a
> uImage-wrapped ramdisk, not just raw bytes:

Yes, I know.  I was just trying out some things - I don't know in
which way your U-Boot version might have been modified...

> Why does it make a difference if it is in RAM vs in flash? I have 8MB of

Your kernel may not be able to pick up a ramdisk image in flash.

Mainline ARM cannot do that, for example.

[Patches to support that have been submitted, but rejected.]

> Surely that should be Ok? Besides, U-boot is supposed to copy the data
> in the image to the specified destination address, isn't it?

No, why should it copy the image? It just verifies that the checksum
is OK, and then passes the address to the kernel. The kernel will have
to copy it anyway when uncompressing it, so ther ei no use in U-Boot
adding another copy operation.

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: w...@denx.de
Misquotation is, in fact, the pride and privilege of the  learned.  A
widely-read  man  never  quotes  accurately,  for  the rather obvious
reason that he has read too widely.
- Hesketh Pearson _Common Misquotations_ introduction
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Debugging why my kernel won't start

[Rogan Dawes]

On 2010/08/18 12:54 PM, Wolfgang Denk wrote:
> Dear Rogan Dawes,
> 
> In message <4c6bac5a.6060...@dawes.za.net> you wrote:
>>
>> Thanks for the suggestion. It did make a slight difference in the boot
>> logs. bootcmd uses the default (in flash) location for the ramdisk,
> 
> Actually it's a pretty significant difference, as for the first time
> you actually see the kernel trying to access the ramdisk.

Good point! :-)

>>> RAMDISK: Compressed image found at block 0
>>> invalid compressed format (err=1)
>>
>> So it seems that the ramdisk is getting corrupted somehow. And yet, it
>> is fine using the vendor u-boot. It must be something that I am doing wrong.
> 
> Try copying the raw ramdisk image (i. e. without the U-Boot header) to
> RAM, and try that one, i. e. something like
> 
>   => cp.b ff9a0040 0160 ...size...
>   ...
>   => bootm ff82 160

Unfortunately, U-boot is expecting the second parameter to point to a
uImage-wrapped ramdisk, not just raw bytes:

DNS323B1> cp.b ff9a0040 160 4ff718
DNS323B1> bootm ff82 160
## Booting kernel from Legacy Image at ff82 ...
   Image Name:   Linux-2.6.12.6-arm1
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:1490204 Bytes = 1.4 MiB
   Load Address: 8000
   Entry Point:  8000
   Verifying Checksum ... OK
Wrong Ramdisk Image Format
Ramdisk image is corrupt or invalid
DNS323B1>

Why does it make a difference if it is in RAM vs in flash? I have 8MB of
flash located at ff80, so that reaches all the way to 0x.
Surely that should be Ok? Besides, U-boot is supposed to copy the data
in the image to the specified destination address, isn't it?

Rogan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Debugging why my kernel won't start

[Wolfgang Denk]

Dear Rogan Dawes,

In message <4c6bac5a.6060...@dawes.za.net> you wrote:
>
> Thanks for the suggestion. It did make a slight difference in the boot
> logs. bootcmd uses the default (in flash) location for the ramdisk,

Actually it's a pretty significant difference, as for the first time
you actually see the kernel trying to access the ramdisk.

> > RAMDISK: Compressed image found at block 0
> > invalid compressed format (err=1)
> 
> So it seems that the ramdisk is getting corrupted somehow. And yet, it
> is fine using the vendor u-boot. It must be something that I am doing wrong.

Try copying the raw ramdisk image (i. e. without the U-Boot header) to
RAM, and try that one, i. e. something like

=> cp.b ff9a0040 0160 ...size...
...
=> bootm ff82 160

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: w...@denx.de
If in any problem you find yourself doing an immense amount of  work,
the answer can be obtained by simple inspection.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Debugging why my kernel won't start

[Rogan Dawes]

On 2010/08/18 7:51 AM, Wolfgang Denk wrote:
> Dear Rogan Dawes,
> 
> In message <4c6b08f1.9000...@dawes.za.net> you wrote:
>>
>> The ramdisk is located at ff9a (in flash). Its image header
>> relocates it to 0080:
> 
> Try to copy the ramdisk to RAM, and pass the Linux kernl an address in
> RAM.
> 
> Try it.
> 
> Best regards,
> 
> Wolfgang Denk
> 

Hi Wolfgang,

Thanks for the suggestion. It did make a slight difference in the boot
logs. bootcmd uses the default (in flash) location for the ramdisk,
while the second one has a copy of the ramdisk image at 160
(including the header). Both logs are using mainline u-boot, not the
vendor one.

< DNS323B1> run bootcmd
> DNS323B1> bootm ff82 160

< ## Loading init Ramdisk from Legacy Image at ff9a ...
> ## Loading init Ramdisk from Legacy Image at 0160 ...

< initrd (0xff9a0040 - 0xffe9f758) extends beyond physical memory -
disabling initrd

> checking if image is initramfs...it isn't (no cpio magic); looks like
an initrd
> Freeing initrd memory: 5117K

> RAMDISK: Compressed image found at block 0
> invalid compressed format (err=1)

So it seems that the ramdisk is getting corrupted somehow. And yet, it
is fine using the vendor u-boot. It must be something that I am doing wrong.

Rogan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Debugging why my kernel won't start

[Wolfgang Denk]

Dear Rogan Dawes,

In message <4c6b08f1.9000...@dawes.za.net> you wrote:
>
> The ramdisk is located at ff9a (in flash). Its image header
> relocates it to 0080:

Try to copy the ramdisk to RAM, and pass the Linux kernl an address in
RAM.

Try it.

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: w...@denx.de
I realize that command does have its fascination, even under  circum-
stances such as these, but I neither enjoy the idea of command nor am
I  frightened  of  it. It simply exists, and I will do whatever logi-
cally needs to be done.
-- Spock, "The Galileo Seven", stardate 2812.7
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Debugging why my kernel won't start

[Rogan Dawes]

On 2010/08/18 12:04 AM, Wolfgang Denk wrote:
> Dear Rogan Dawes,
> 
> In message <4c6b051a.5050...@dawes.za.net> you wrote:
>>
>> For some reason, the kernel didn't seem to think it had been given the
>> ramdisk parameter. At least, I get the following error message:
> 
> Where is the ramdisk located? Make sure it is loaded into RAM (not
> flash!).
> 
> Best regards,
> 
> Wolfgang Denk

Hi Wolfgang,

The ramdisk is located at ff9a (in flash). Its image header
relocates it to 0080:

>From the vendor u-boot:

## Loading Ramdisk Image at ff9a ...
   Image Name:   Ramdisk
   Image Type:   ARM Linux RAMDisk Image (gzip compressed)
   Data Size:5240600 Bytes =  5 MB
   Load Address: 0080
   Entry Point:  0080
   Verifying Checksum ... OK

And from mine:

DNS323B1> setenv verify no
DNS323B1> run bootcmd
## Booting kernel from Legacy Image at ff82 ...
   Image Name:   Linux-2.6.12.6-arm1
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:1490204 Bytes = 1.4 MiB
   Load Address: 8000
   Entry Point:  8000
## Loading init Ramdisk from Legacy Image at ff9a ...
   Image Name:   Ramdisk
   Image Type:   ARM Linux RAMDisk Image (gzip compressed)
   Data Size:5240600 Bytes = 5 MiB
   Load Address: 0080
   Entry Point:  0080
   Loading Kernel Image ... OK
OK

0x80 is well within the 64MB that the device has.

Regards,

Rogan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Debugging why my kernel won't start

[Wolfgang Denk]

Dear Rogan Dawes,

In message <4c6b051a.5050...@dawes.za.net> you wrote:
>
> For some reason, the kernel didn't seem to think it had been given the
> ramdisk parameter. At least, I get the following error message:

Where is the ramdisk located? Make sure it is loaded into RAM (not
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: w...@denx.de
Anyone who knows history, particularly the history of Europe, will, I
think, recognize that the domination of education or of government by
any one particular religious faith is never a happy  arrangement  for
the people.   - Eleanor Roosevelt
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Debugging why my kernel won't start

[Rogan Dawes]

On 2010/08/17 11:20 PM, Wolfgang Denk wrote:
> Dear Rogan Dawes,
> 
> In message <4c6aec70.40...@dawes.za.net> you wrote:
>>
>> No, but mistaken in thinking that the machid was in decimal, when it is
>> really in hex.
>>
>> Now to figure out why the CRC calculations are different, and I'll have
>> a fully functioning u-boot!
> 
> For a test you could as ell disable CRC checking:
> 
>   => setenv verify no
>   => save
> 
> Best regards,
> 
> Wolfgang Denk
> 

Hi Wolfgang,

Yes, I found that while I was trying to see if the CRC calculation had
changed, but it did not work.

For some reason, the kernel didn't seem to think it had been given the
ramdisk parameter. At least, I get the following error message:

Kernel panic - not syncing: VFS: Unable to mount root fs on
unknown-block(1,0)

Hmmm! Diff of the boot logs shows (mainline vs vendor):

< initrd (0xff9a0040 - 0xffe9f758) extends beyond physical memory -
disabling initrd
---
> Using UBoot passing parameters structure

Also potentially interesting is:

< Memory: 64MB = 64MB total
< Memory: 61696KB available (2599K code, 462K data, 112K init)
---
> Memory: 64MB 0MB 0MB 0MB = 64MB total
> Memory: 56576KB available (2599K code, 462K data, 112K init)

It seems that the amount of memory is being passed differently to the
kernel (1 bank vs 4)?

Keeping in mind that this is the same kernel executing, just with a
different setup code or parameters.

I'll keep investigating.

Rogan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Debugging why my kernel won't start

[Wolfgang Denk]

Dear Rogan Dawes,

In message <4c6aec70.40...@dawes.za.net> you wrote:
>
> No, but mistaken in thinking that the machid was in decimal, when it is
> really in hex.
> 
> Now to figure out why the CRC calculations are different, and I'll have
> a fully functioning u-boot!

For a test you could as ell disable CRC checking:

=> setenv verify no
=> save

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: w...@denx.de
It is much easier to suggest solutions when you know nothing
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Debugging why my kernel won't start

[Wolfgang Denk]

Dear Rogan Dawes,

In message <4c6ae955.1060...@dawes.za.net> you wrote:
>
> I'm not passing the second parameter at this stage, because the ramdisk
> is failing the CRC32 check for some reason. It may be that the CRC32
> calculation has changed between 1.1.1 which was the base for the vendor
> u-boot, and mainline. e.g. rather than being calculated over the precise
> length of the data, it is calculated over the entire block. Just a
> guess, of course.

That's a wild guess actually, and I bet a beer or two that its a
wrong one.

> I had been led to believe that it was possible to override the compiled
> in mach type by setting a "machid" environment variable. This would give
> me the best of both worlds - a u-boot compiled according to mainline
> registered numbers, with the ability to boot vendor firmware by simply
> setting an environment variable.
> 
> Unfortunately, this did not work for me :-(

This feature was introduced by commit 3c234efa, dated 2008-01-30.
Eventually your U-Bootimage predates this...

> Am I mistaken in expecting the machid environment variable trick to work?

It should work in reasonably recent versions of U-Boot.

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: w...@denx.de
If you believe that feeling bad or worrying long enough will change a
past or future event, then you are residing on another planet with  a
different reality system.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Debugging why my kernel won't start

[Rogan Dawes]

On 2010/08/17 9:56 PM, Rogan Dawes wrote:
> 
> Am I mistaken in expecting the machid environment variable trick to work?
> 
> Thanks
> 
> Rogan

No, but mistaken in thinking that the machid was in decimal, when it is
really in hex.

Now to figure out why the CRC calculations are different, and I'll have
a fully functioning u-boot!

Thanks so much to everyone who has helped me get this far!

Rogan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Debugging why my kernel won't start

[Rogan Dawes]

On 2010/08/17 5:38 PM, Albert ARIBAUD wrote:

> Ok, so u-boot is now out of the way of the linux image load area.
> 
>> Now to figure out why I'm not getting any further than this. (And why
>> the vendor ramdisk is giving me CRC errors).
> 
> What is the actual command you use for booting your kernel? IIUC (and if 
> I trust the few experiments I did on edminiv2 with ramdisks) you need to 
> pass the ramdisk address to the bootm command, e.g. bootm ff82 
> ff8x (where x is your ramdisk's location in flash (I'm assuming 
> your ramdisk image is in flash as your kernel image is). You did an 
> 'iminfo' on both images to verify their integrity, didn't you?
> 
> Amicalement,

Well, there are two approaches. The vendor u-boot uses two parameters to
pass the address of the ramdisk to the kernel.

Without that parameter, the kernel should still boot, and show the
initial messages, until it tries to mount its root filesystem, at which
point it should panic.

I'm not passing the second parameter at this stage, because the ramdisk
is failing the CRC32 check for some reason. It may be that the CRC32
calculation has changed between 1.1.1 which was the base for the vendor
u-boot, and mainline. e.g. rather than being calculated over the precise
length of the data, it is calculated over the entire block. Just a
guess, of course.

But until I can get the standard firmware to boot from my replacement
U-boot, I'll keep trying.

The hints I'm getting from googling for  are suggesting that the problem is likely a machid mismatch.

And indeed, that WAS the problem.

I had been led to believe that it was possible to override the compiled
in mach type by setting a "machid" environment variable. This would give
me the best of both worlds - a u-boot compiled according to mainline
registered numbers, with the ability to boot vendor firmware by simply
setting an environment variable.

Unfortunately, this did not work for me :-(

-#define MACH_TYPE_DNS323   1542
+#define MACH_TYPE_DNS323   526

Making the above change results in a booting kernel, until the root fs
can not be found.

Am I mistaken in expecting the machid environment variable trick to work?

Thanks

Rogan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Debugging why my kernel won't start

[Albert ARIBAUD]

Le 17/08/2010 13:42, Rogan Dawes a écrit :
> On 2010/08/17 1:19 PM, Rogan Dawes wrote:
>> I'll try with a higher value, and see what happens.
>>
>
> So, I tried with TEXT_BASE=f1, and I got a bit further:
>
> DNS323B1>  bootm FF82
> ## Booting kernel from Legacy Image at ff82 ...
> Image Name:   Linux-2.6.12.6-arm1
> Image Type:   ARM Linux Kernel Image (uncompressed)
> Data Size:1490204 Bytes = 1.4 MiB
> Load Address: 8000
> Entry Point:  8000
> Verifying Checksum ... OK
> Loading Kernel Image ... OK
> OK
> Using machid 0x526 from environment
>
> Starting kernel ...
>
> Uncompressing
> Linux...
> done, booting the kernel.
>
> So, that does appear to have been (at least part of) the problem.

Ok, so u-boot is now out of the way of the linux image load area.

> Now to figure out why I'm not getting any further than this. (And why
> the vendor ramdisk is giving me CRC errors).

What is the actual command you use for booting your kernel? IIUC (and if 
I trust the few experiments I did on edminiv2 with ramdisks) you need to 
pass the ramdisk address to the bootm command, e.g. bootm ff82 
ff8x (where x is your ramdisk's location in flash (I'm assuming 
your ramdisk image is in flash as your kernel image is). You did an 
'iminfo' on both images to verify their integrity, didn't you?

Amicalement,
-- 
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Debugging why my kernel won't start

[Rogan Dawes]

On 2010/08/17 1:19 PM, Rogan Dawes wrote:
> I'll try with a higher value, and see what happens.
> 

So, I tried with TEXT_BASE=f1, and I got a bit further:

DNS323B1> bootm FF82
## Booting kernel from Legacy Image at ff82 ...
   Image Name:   Linux-2.6.12.6-arm1
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:1490204 Bytes = 1.4 MiB
   Load Address: 8000
   Entry Point:  8000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK
Using machid 0x526 from environment

Starting kernel ...

Uncompressing
Linux...
done, booting the kernel.

So, that does appear to have been (at least part of) the problem.

Now to figure out why I'm not getting any further than this. (And why
the vendor ramdisk is giving me CRC errors).

Rogan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Debugging why my kernel won't start

[Rogan Dawes]

On 2010/08/17 12:41 PM, Albert ARIBAUD wrote:
>> I had a debug statement in the loop, printing out the above at each
>> iteration. Since it never completed the loop, copying/moving the entire
>> kernel (609564 bytes remaining), I think it is safe to assume that it
>> never got to the point of trying to boot the kernel.
> 
> Sorry, I'd missed that one.

No problem, there was a lot of data there.

> I do think you're overwriting u-boot with the kernel. What location does 
> your u-boot load at? What location is the manufacturer's u-boot supposed 
> to be loading at? See their TEXT_BASE in the board config file (or link 
> file maybe).

My U-Boot is configured to load at 0x300 (48MB), as far out of the
way as possible. That is, using the mkimage tool, which is how I get my
rebuilt u-boot onto the machine. This is my command line:

$ make clean mrproper dns323_b1_config && make && \
mkimage -A arm -O u-boot -T kernel -C none \
-a 0x300 -e 0x300 -n "UBoot dns323" \
-d u-boot.bin uImage.bin

My TEXT_BASE is identical to yours: 0x10

Does that make a difference, if the u-boot image is chain loaded from
another one?

This is what I found in the vendor code:

./board/mv88fxx81/db88f5181/config_tiny.mk:TEXT_BASE = 0x00f1
./board/mv88fxx81/db88f5181/config.mk:TEXT_BASE = 0x00f1
./board/mv88fxx81/db88f5181/config_prpmc.mk:TEXT_BASE = 0x02f1
./board/mv88fxx81/db88f5181/config_def.mk:TEXT_BASE = 0x00f1
./board/mv88fxx81/db88f5181/config_tiny_voip.mk:TEXT_BASE = 0x00f4
./board/mv88fxx81/db88f1181/config.mk:TEXT_BASE = 0x00f0

I'm not sure which config has been used for the version of u-boot on my
board, though.

At any rate, those are all substantially higher than I am currently using.

I'll try with a higher value, and see what happens.

> FYI, in my u-boot edminiv2 support code, I had issues with big kernels, 
> so I decided to move u-boot's final location as high in RAM as by board 
> allows, so that it never will be overwritten by Linux (unless I load a 
> 63+ MB kernel, that is :) )

That was my reasoning with the 48MB, too :-)

Rogan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Debugging why my kernel won't start

[Albert ARIBAUD]

Le 17/08/2010 12:21, Rogan Dawes a écrit :
> On 2010/08/17 12:10 PM, Albert ARIBAUD wrote:
>> (quick note to Wolfgang: yes, there is RAM at 0x8000 on these
>> machines. All orion5x based machines have RAM start at 0, and u-boot
>> makes sure SDRAM is set up this way)
>>
>> Rogan,
>>
>> You cannot tell from your log output that memmove never completes. It
>> could as well be the kernel not outputting to the console, or failing to
>> start at all even though the move was ok.
>
> Actually, I can tell that the memmove never completes (or if it does, it
> alters the code flow in the process):
>
>>> So I changed memmove_wd to use the watchdog style of memmove'ing, in
>>> small chunks to try to track down where the problem arises. I used 1kB
>>> chunks, and got:
>>>
>>> Moving 1024 of 611612 bytes from ff8f6840 to 000de800
>>> Moving 1024 of 610588 bytes from ff8f6c40 to 000dec00
>>> Moving 1024 of 609564 bytes from ff8f7040 to 000df000
>>>
>>> before it finally hung.
>
> I had a debug statement in the loop, printing out the above at each
> iteration. Since it never completed the loop, copying/moving the entire
> kernel (609564 bytes remaining), I think it is safe to assume that it
> never got to the point of trying to boot the kernel.

Sorry, I'd missed that one.

> Additionally, just doing a cp with the above parameters also hangs.
>
> Based on what Wolfgang has said, perhaps the address space registers are
> set up differently in the vendor u-boot to what the current mainline is
> doing. I'll check that next, I think.

> I'm just struggling to understand how the last command that I executed
> ended up in the memory where I was trying to copy the kernel to. That
> suggests that U-boot is actively using that memory for some reason, and
> copying the kernel image over the top of it seems like a very good way
> to cause u-boot to stop behaving consistently, and hang.

I do think you're overwriting u-boot with the kernel. What location does 
your u-boot load at? What location is the manufacturer's u-boot supposed 
to be loading at? See their TEXT_BASE in the board config file (or link 
file maybe).

FYI, in my u-boot edminiv2 support code, I had issues with big kernels, 
so I decided to move u-boot's final location as high in RAM as by board 
allows, so that it never will be overwritten by Linux (unless I load a 
63+ MB kernel, that is :) )

> Thanks anyway.
>
> Rogan

You're welcome.

Amicalement,
-- 
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Debugging why my kernel won't start

[Rogan Dawes]

On 2010/08/17 12:10 PM, Albert ARIBAUD wrote:
> (quick note to Wolfgang: yes, there is RAM at 0x8000 on these 
> machines. All orion5x based machines have RAM start at 0, and u-boot 
> makes sure SDRAM is set up this way)
> 
> Rogan,
> 
> You cannot tell from your log output that memmove never completes. It 
> could as well be the kernel not outputting to the console, or failing to 
> start at all even though the move was ok.

Actually, I can tell that the memmove never completes (or if it does, it
alters the code flow in the process):

>> So I changed memmove_wd to use the watchdog style of memmove'ing, in
>> small chunks to try to track down where the problem arises. I used 1kB
>> chunks, and got:
>>
>> Moving 1024 of 611612 bytes from ff8f6840 to 000de800
>> Moving 1024 of 610588 bytes from ff8f6c40 to 000dec00
>> Moving 1024 of 609564 bytes from ff8f7040 to 000df000
>>
>> before it finally hung.

I had a debug statement in the loop, printing out the above at each
iteration. Since it never completed the loop, copying/moving the entire
kernel (609564 bytes remaining), I think it is safe to assume that it
never got to the point of trying to boot the kernel.

Additionally, just doing a cp with the above parameters also hangs.

> The first thing you should do is make sure that you pass the right 
> machine-id, but also that you pass ATAGs correctly to the kernel -- it 
> seems that at least some LaCie custom u-boot  implementations use an env 
> variable ('mainlineKernel', IIRC) to differenciate between mainline and 
> LaCie custom kernels. Maybe your HW was designed the same way. Best is 
> you look up the u-boot source code provided by the manufacturer of your 
> machine.
> 
> The second thing is to make sure your kernel uses the right console. Are 
> you using netconsole? Maybe the manufacturer's kernel does not have 
> netconsole. Do you use a serial (RS-232) console? Make sure the kernel 
> has command line arguments to use it too.
> 
> Amicalement,

I'll check those once I have got the copy working correctly :-)

FWIW, I'm using a serial console, not netconsole. And the bootargs
include the console definition.

Based on what Wolfgang has said, perhaps the address space registers are
set up differently in the vendor u-boot to what the current mainline is
doing. I'll check that next, I think.

I'm just struggling to understand how the last command that I executed
ended up in the memory where I was trying to copy the kernel to. That
suggests that U-boot is actively using that memory for some reason, and
copying the kernel image over the top of it seems like a very good way
to cause u-boot to stop behaving consistently, and hang.

Thanks anyway.

Rogan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Debugging why my kernel won't start

[Albert ARIBAUD]

Le 16/08/2010 22:15, Rogan Dawes a écrit :
> On 2010/08/16 9:24 AM, Rogan Dawes wrote:
>> Hi folks,
>>
>> I'm trying to get mainline u-boot working on my DNS323 (Orion5x based).
>> Until I am confident in the config, I'm using a chainloaded approach,
>> wrapping my featureful u-boot in an image file:
>>
>> $ mkimage -A arm -O u-boot -T kernel -C none -a 0x300 -e 0x300
>> -n "UBoot dns323" -d u-boot.bin uImage.bin
>>
>> I am trying to boot the default kernel that is already flashed into the
>> device first. The first problem is that the DNS323 uses an incorrect
>> mach-type value of 526, while the registered value is 1542. See
>> ). I have modified
>> arch/arm/include/asm/mach-types.h to set MACH_TYPE_DNS323 to the
>> "correct" Dlink value, which should match what the default kernel is
>> expecting.
>>
>> Unfortunately, all I get is:
>>
>> DNS323B1>   bootm FF82
>> ## Booting kernel from Legacy Image at ff82 ...
>>   Image Name:   Linux-2.6.12.6-arm1
>>   Image Type:   ARM Linux Kernel Image (uncompressed)
>>   Data Size:1490204 Bytes = 1.4 MiB
>>   Load Address: 8000
>>   Entry Point:  8000
>>   Verifying Checksum ... OK
>>   Loading Kernel Image ...
>>
>> and it hangs there.
>>
>> That appears to be this code from cmd_bootm:
>>
>>case IH_COMP_NONE:
>>if (load == blob_start) {
>>printf ("   XIP %s ... ", type_name);
>>} else {
>>printf ("   Loading %s ... ", type_name);
>>memmove_wd ((void *)load, (void *)image_start,
>>image_len, CHUNKSZ);
>>}
>>*load_end = load + image_len;
>>puts("OK\n");
>>break;
>>
>> So, the memmove_wd never completes, it seems.
>>
>> I added a debug statement at the top of memmove_wd, and got:
>>
>> Moving memory from ff820040 to 8000
>>
>> Is that because the uImage header is 64 bytes?
>>
>> Also, the following suggests that there may be something wrong with the
>> addresses that I am using:
>>
>> DNS323B1>   bootm FF82 FF9A
>> ## Booting kernel from Legacy Image at ff82 ...
>>   Image Name:   Linux-2.6.12.6-arm1
>>   Image Type:   ARM Linux Kernel Image (uncompressed)
>>   Data Size:1490204 Bytes = 1.4 MiB
>>   Load Address: 8000
>>   Entry Point:  8000
>>   Verifying Checksum ... OK
>> ## Loading init Ramdisk from Legacy Image at ff9a ...
>>   Image Name:   Ramdisk
>>   Image Type:   ARM Linux RAMDisk Image (gzip compressed)
>>   Data Size:5240600 Bytes = 5 MiB
>>   Load Address: 0080
>>   Entry Point:  0080
>>   Verifying Checksum ... Bad Data CRC
>> Ramdisk image is corrupt or invalid
>> DNS323B1>
>>
>> My chainloaded u-boot is configured in an image to load at 0x300,
>> and stay there (no relocation), if I have understood these parameters
>> correctly:
>>
>> -a 0x300 -e 0x300
>>
>> Can anyone see what I am doing wrong?
>>
>> Many thanks!
>>
>> Rogan
>
> So I changed memmove_wd to use the watchdog style of memmove'ing, in
> small chunks to try to track down where the problem arises. I used 1kB
> chunks, and got:
>
> Moving 1024 of 611612 bytes from ff8f6840 to 000de800
> Moving 1024 of 610588 bytes from ff8f6c40 to 000dec00
> Moving 1024 of 609564 bytes from ff8f7040 to 000df000
>
> before it finally hung.
>
> So, I checked what was at that address:
>
> DNS323B1>  md.b 000df000 400
> 000df000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> 
> 000df010: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> 
> 000df020: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> 
> 000df030: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> 
> 000df040: ff ff ff ff ff ff ff ff ff df ff ff ff ff ff ff
> 
> 000df050: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> 
> 000df060: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> 
> 000df070: ff ff ff ff bf ff ff ff ff ff ff ff ff f7 ff ff
> 
> 000df080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> 
> 000df090: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> 
> 000df0a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> 
> 000df0b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> 
> 000df0c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> 
> 000df0d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> 
> 000df0e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> 
> 000df0f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> 
> 000df100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> 
> 000df110: ff ff ff ff ff 

Re: [U-Boot] Debugging why my kernel won't start

[Rogan Dawes]

On 2010/08/17 12:03 AM, Wolfgang Denk wrote:
> Dear Rogan Dawes,
> 
> In message <4c69a8da.8020...@dawes.za.net> you wrote:
>>
>>> Are you absolutely sure that you have RAM in your system at 0x8000?
>>> I doubt that your Load Address/Entry Point settings are correct.
>>
>> This is the default kernel that was shipped with the device, and so
>> those are the settings that worked with the original u-boot.
> 
> Why do you not simply answer the question I asked?

Because I don't know how to get the answer to your question.

My assumption is that, since this is the vendor kernel, and that this is
the working configuration that they were using, that there MUST be
memory at that location, otherwise the thousands of devices that they
shipped would surely not have worked.

Clearly there is a different configuration somewhere between the vendor
u-boot, and what mainline is using. All I am trying to do is figure out
where that difference might be.

> Why do you not think about what I asked, and why?

I tried to find out by looking up the default CS0 value from the
chipset, and seeing if there were any changes made to it in current
u-boot. That's all I know how to do.

>   Verifying Checksum ... Bad Data CRC
> Ramdisk image is corrupt or invalid
>>>
>>> Is there RAM at 0x0080 ?
>>
>> Again, this is from the default vendor ramdisk that ships with the device.
> 
> Why should I care about where this is coming from?
> 
> On such a base I cannot help you.

Thanks for all the help you have given me so far. I'm sorry to have been
such a pain.

Rogan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Debugging why my kernel won't start

[Wolfgang Denk]

Dear Rogan Dawes,

In message <4c69a8da.8020...@dawes.za.net> you wrote:
>
> > Are you absolutely sure that you have RAM in your system at 0x8000?
> > I doubt that your Load Address/Entry Point settings are correct.
> 
> This is the default kernel that was shipped with the device, and so
> those are the settings that worked with the original u-boot.

Why do you not simply answer the question I asked?

Why do you not think about what I asked, and why?

> >>>   Verifying Checksum ... Bad Data CRC
> >>> Ramdisk image is corrupt or invalid
> > 
> > Is there RAM at 0x0080 ?
> 
> Again, this is from the default vendor ramdisk that ships with the device.

Why should I care about where this is coming from?

On such a base I cannot help you.

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: w...@denx.de
Steal five dollars and you were a petty  thief.  Steal  thousands  of
dollars and you are either a government or a hero.
   - Terry Pratchett, _Going_Postal_
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Debugging why my kernel won't start

[Rogan Dawes]

On 2010/08/16 10:29 PM, Wolfgang Denk wrote:
> Dear Rogan Dawes,
> 
> In message<4c699c6e.2010...@dawes.za.net>  you wrote:
>>
>>> DNS323B1>   bootm FF82
>>> ## Booting kernel from Legacy Image at ff82 ...
>>>   Image Name:   Linux-2.6.12.6-arm1
>>>   Image Type:   ARM Linux Kernel Image (uncompressed)
>>>   Data Size:1490204 Bytes = 1.4 MiB
>>>   Load Address: 8000
>>>   Entry Point:  8000
>>>   Verifying Checksum ... OK
>>>   Loading Kernel Image ...
>>>
>>> and it hangs there.
> 
> Are you absolutely sure that you have RAM in your system at 0x8000?
> I doubt that your Load Address/Entry Point settings are correct.

Hi Wolfgang,

This is the default kernel that was shipped with the device, and so
those are the settings that worked with the original u-boot.

>>>   Verifying Checksum ... Bad Data CRC
>>> Ramdisk image is corrupt or invalid
> 
> Is there RAM at 0x0080 ?

Again, this is from the default vendor ramdisk that ships with the device.

>> So, I checked what was at that address:
> 
> Hm... instead of trying random things I recommend to apply common
> sense. Have a look at the memory map for your system - which memory
> types and register banks etc. are mapped to which address ragens?
> Where is your RAM and how big is it?  I seriously doubt that you have
> RAM at these low addresses.

I looked at the CPU datasheet, which shows that:

DDR SDRAM CS0 is by default 256 MB at .–0FFF.

There doesn't appear to be any code in the orion5x setup that sets this
to anything else:

$ git grep ORION5X_ATTR_DRAM_CS0
arch/arm/include/asm/arch-orion5x/cpu.h:ORION5X_ATTR_DRAM_CS0 =
0x0e,
$

The device has 64MB RAM in two banks.

>> The first 1kB was not particularly interesting (to me). But the next
>> chunk showed something interesting at 000df6e0:
>>
>> 000df6e0: ff ff ff ff 6d 64 2e 62 00 30 30 30 64 66 30 30
>> md.b.000df00
>> 000df6f0: 30 00 34 30 30 00 ff ff ff ff ff ff ff ff ff ff
>> 0.400...
>>
>> i.e. the command I had just executed.
>>
>> So, it seems that for some reason, even though I tried to place my chain
>> loaded u-boot out of harms way at 0x300, for some reason, it was
>> still allocating memory at a lower address, precisely where the kernel
>> is supposed to be copied to for execution.
>>
>> Can anyone explain why this happens? Or what I can do to fix it?
> 
> We don;t yuour hardware, we don't know your board configuration, we
> don't know your code...

Patch to follow this mail.

Thanks for your help!

Rogan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Debugging why my kernel won't start

[Wolfgang Denk]

Dear Rogan Dawes,

In message <4c699c6e.2010...@dawes.za.net> you wrote:
>
> > DNS323B1>  bootm FF82
> > ## Booting kernel from Legacy Image at ff82 ...
> >  Image Name:   Linux-2.6.12.6-arm1
> >  Image Type:   ARM Linux Kernel Image (uncompressed)
> >  Data Size:1490204 Bytes = 1.4 MiB
> >  Load Address: 8000
> >  Entry Point:  8000
> >  Verifying Checksum ... OK
> >  Loading Kernel Image ...
> >
> > and it hangs there.

Are you absolutely sure that you have RAM in your system at 0x8000?
I doubt that your Load Address/Entry Point settings are correct.

> > Moving memory from ff820040 to 8000
> >
> > Is that because the uImage header is 64 bytes?

The offset 0x40 is becaus eof the header, the 0x8000 is because
your Load Address setting.

> > ## Loading init Ramdisk from Legacy Image at ff9a ...
> >  Image Name:   Ramdisk
> >  Image Type:   ARM Linux RAMDisk Image (gzip compressed)
> >  Data Size:5240600 Bytes = 5 MiB
> >  Load Address: 0080
> >  Entry Point:  0080
> >  Verifying Checksum ... Bad Data CRC
> > Ramdisk image is corrupt or invalid

Is there RAM at 0x0080 ?

> So, I checked what was at that address:

Hm... instead of trying random things I recommend to apply common
sense. Have a look at the memory map for your system - which memory
types and register banks etc. are mapped to which address ragens?
Where is your RAM and how big is it?  I seriously doubt that you have
RAM at these low addresses.

> The first 1kB was not particularly interesting (to me). But the next 
> chunk showed something interesting at 000df6e0:
> 
> 000df6e0: ff ff ff ff 6d 64 2e 62 00 30 30 30 64 66 30 30 
> md.b.000df00
> 000df6f0: 30 00 34 30 30 00 ff ff ff ff ff ff ff ff ff ff 
> 0.400...
> 
> i.e. the command I had just executed.
> 
> So, it seems that for some reason, even though I tried to place my chain 
> loaded u-boot out of harms way at 0x300, for some reason, it was 
> still allocating memory at a lower address, precisely where the kernel 
> is supposed to be copied to for execution.
> 
> Can anyone explain why this happens? Or what I can do to fix it?

We don;t yuour hardware, we don't know your board configuration, we
don't know your code...

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: w...@denx.de
Was heißt Windows auf Indianisch? - "Weißer  Mann,  der  auf  Sanduhr
wartet!"
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Debugging why my kernel won't start

[Rogan Dawes]

On 2010/08/16 9:24 AM, Rogan Dawes wrote:
> Hi folks,
>
> I'm trying to get mainline u-boot working on my DNS323 (Orion5x based).
> Until I am confident in the config, I'm using a chainloaded approach,
> wrapping my featureful u-boot in an image file:
>
> $ mkimage -A arm -O u-boot -T kernel -C none -a 0x300 -e 0x300
> -n "UBoot dns323" -d u-boot.bin uImage.bin
>
> I am trying to boot the default kernel that is already flashed into the
> device first. The first problem is that the DNS323 uses an incorrect
> mach-type value of 526, while the registered value is 1542. See
> ). I have modified
> arch/arm/include/asm/mach-types.h to set MACH_TYPE_DNS323 to the
> "correct" Dlink value, which should match what the default kernel is
> expecting.
>
> Unfortunately, all I get is:
>
> DNS323B1>  bootm FF82
> ## Booting kernel from Legacy Image at ff82 ...
>  Image Name:   Linux-2.6.12.6-arm1
>  Image Type:   ARM Linux Kernel Image (uncompressed)
>  Data Size:1490204 Bytes = 1.4 MiB
>  Load Address: 8000
>  Entry Point:  8000
>  Verifying Checksum ... OK
>  Loading Kernel Image ...
>
> and it hangs there.
>
> That appears to be this code from cmd_bootm:
>
>   case IH_COMP_NONE:
>   if (load == blob_start) {
>   printf ("   XIP %s ... ", type_name);
>   } else {
>   printf ("   Loading %s ... ", type_name);
>   memmove_wd ((void *)load, (void *)image_start,
>   image_len, CHUNKSZ);
>   }
>   *load_end = load + image_len;
>   puts("OK\n");
>   break;
>
> So, the memmove_wd never completes, it seems.
>
> I added a debug statement at the top of memmove_wd, and got:
>
> Moving memory from ff820040 to 8000
>
> Is that because the uImage header is 64 bytes?
>
> Also, the following suggests that there may be something wrong with the
> addresses that I am using:
>
> DNS323B1>  bootm FF82 FF9A
> ## Booting kernel from Legacy Image at ff82 ...
>  Image Name:   Linux-2.6.12.6-arm1
>  Image Type:   ARM Linux Kernel Image (uncompressed)
>  Data Size:1490204 Bytes = 1.4 MiB
>  Load Address: 8000
>  Entry Point:  8000
>  Verifying Checksum ... OK
> ## Loading init Ramdisk from Legacy Image at ff9a ...
>  Image Name:   Ramdisk
>  Image Type:   ARM Linux RAMDisk Image (gzip compressed)
>  Data Size:5240600 Bytes = 5 MiB
>  Load Address: 0080
>  Entry Point:  0080
>  Verifying Checksum ... Bad Data CRC
> Ramdisk image is corrupt or invalid
> DNS323B1>
>
> My chainloaded u-boot is configured in an image to load at 0x300,
> and stay there (no relocation), if I have understood these parameters
> correctly:
>
> -a 0x300 -e 0x300
>
> Can anyone see what I am doing wrong?
>
> Many thanks!
>
> Rogan

So I changed memmove_wd to use the watchdog style of memmove'ing, in 
small chunks to try to track down where the problem arises. I used 1kB 
chunks, and got:

Moving 1024 of 611612 bytes from ff8f6840 to 000de800
Moving 1024 of 610588 bytes from ff8f6c40 to 000dec00
Moving 1024 of 609564 bytes from ff8f7040 to 000df000

before it finally hung.

So, I checked what was at that address:

DNS323B1> md.b 000df000 400
000df000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 

000df010: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 

000df020: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 

000df030: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 

000df040: ff ff ff ff ff ff ff ff ff df ff ff ff ff ff ff 

000df050: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 

000df060: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 

000df070: ff ff ff ff bf ff ff ff ff ff ff ff ff f7 ff ff 

000df080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 

000df090: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 

000df0a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 

000df0b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 

000df0c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 

000df0d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 

000df0e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 

000df0f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 

000df100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 

000df110: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 

000df120: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 

000df130: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 

000df140: ff ff ff ff ff ff ff ff 

Re: [U-Boot] Debugging why my kernel won't start

[Rogan Dawes]

On 2010/08/16 10:34 AM, Gérald Kerma wrote:
> Dear Rogan,
>
> I've you set the uboot env machid to the correct value ?
> setenv machid
> just replace HexValue with the correct MACH_TYPE.
>
> You must then see something like :
> Using machid 0xa76 from environment
> after kernel loaded by uboot.
>
> Best regards,
>

Hi Gerald,

Thanks for the hint. That'll make it easier to handle the difference 
between the official and de facto machine ids.

Unfortunately, I don't even get to that point. It seems that my true 
problem is in the memmove function.

Rogan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Debugging why my kernel won't start

[Gérald Kerma]

Dear Rogan,

I've you set the uboot env machid to the correct value ?
setenv machid 
just replace HexValue with the correct MACH_TYPE.

You must then see something like :
Using machid 0xa76 from environment
after kernel loaded by uboot.

Best regards,

Le 16/08/2010 09:24, Rogan Dawes a écrit :
> Hi folks,
> 
> I'm trying to get mainline u-boot working on my DNS323 (Orion5x based). 
> Until I am confident in the config, I'm using a chainloaded approach, 
> wrapping my featureful u-boot in an image file:
> 
> $ mkimage -A arm -O u-boot -T kernel -C none -a 0x300 -e 0x300 
> -n "UBoot dns323" -d u-boot.bin uImage.bin
> 
> I am trying to boot the default kernel that is already flashed into the 
> device first. The first problem is that the DNS323 uses an incorrect 
> mach-type value of 526, while the registered value is 1542. See 
> ). I have modified 
> arch/arm/include/asm/mach-types.h to set MACH_TYPE_DNS323 to the 
> "correct" Dlink value, which should match what the default kernel is 
> expecting.
> 
> Unfortunately, all I get is:
> 
> DNS323B1> bootm FF82
> ## Booting kernel from Legacy Image at ff82 ...
> Image Name:   Linux-2.6.12.6-arm1
> Image Type:   ARM Linux Kernel Image (uncompressed)
> Data Size:1490204 Bytes = 1.4 MiB
> Load Address: 8000
> Entry Point:  8000
> Verifying Checksum ... OK
> Loading Kernel Image ...
> 
> and it hangs there.
> 
> That appears to be this code from cmd_bootm:
> 
>  case IH_COMP_NONE:
>  if (load == blob_start) {
>  printf ("   XIP %s ... ", type_name);
>  } else {
>  printf ("   Loading %s ... ", type_name);
>  memmove_wd ((void *)load, (void *)image_start,
>  image_len, CHUNKSZ);
>  }
>  *load_end = load + image_len;
>  puts("OK\n");
>  break;
> 
> So, the memmove_wd never completes, it seems.
> 
> I added a debug statement at the top of memmove_wd, and got:
> 
> Moving memory from ff820040 to 8000
> 
> Is that because the uImage header is 64 bytes?
> 
> Also, the following suggests that there may be something wrong with the 
> addresses that I am using:
> 
> DNS323B1> bootm FF82 FF9A
> ## Booting kernel from Legacy Image at ff82 ...
> Image Name:   Linux-2.6.12.6-arm1
> Image Type:   ARM Linux Kernel Image (uncompressed)
> Data Size:1490204 Bytes = 1.4 MiB
> Load Address: 8000
> Entry Point:  8000
> Verifying Checksum ... OK
> ## Loading init Ramdisk from Legacy Image at ff9a ...
> Image Name:   Ramdisk
> Image Type:   ARM Linux RAMDisk Image (gzip compressed)
> Data Size:5240600 Bytes = 5 MiB
> Load Address: 0080
> Entry Point:  0080
> Verifying Checksum ... Bad Data CRC
> Ramdisk image is corrupt or invalid
> DNS323B1>
> 
> My chainloaded u-boot is configured in an image to load at 0x300, 
> and stay there (no relocation), if I have understood these parameters 
> correctly:
> 
> -a 0x300 -e 0x300
> 
> Can anyone see what I am doing wrong?
> 
> Many thanks!
> 
> Rogan
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot


-- 
Gérald

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] Debugging why my kernel won't start

[Rogan Dawes]

Hi folks,

I'm trying to get mainline u-boot working on my DNS323 (Orion5x based). 
Until I am confident in the config, I'm using a chainloaded approach, 
wrapping my featureful u-boot in an image file:

$ mkimage -A arm -O u-boot -T kernel -C none -a 0x300 -e 0x300 
-n "UBoot dns323" -d u-boot.bin uImage.bin

I am trying to boot the default kernel that is already flashed into the 
device first. The first problem is that the DNS323 uses an incorrect 
mach-type value of 526, while the registered value is 1542. See 
). I have modified 
arch/arm/include/asm/mach-types.h to set MACH_TYPE_DNS323 to the 
"correct" Dlink value, which should match what the default kernel is 
expecting.

Unfortunately, all I get is:

DNS323B1> bootm FF82
## Booting kernel from Legacy Image at ff82 ...
Image Name:   Linux-2.6.12.6-arm1
Image Type:   ARM Linux Kernel Image (uncompressed)
Data Size:1490204 Bytes = 1.4 MiB
Load Address: 8000
Entry Point:  8000
Verifying Checksum ... OK
Loading Kernel Image ...

and it hangs there.

That appears to be this code from cmd_bootm:

 case IH_COMP_NONE:
 if (load == blob_start) {
 printf ("   XIP %s ... ", type_name);
 } else {
 printf ("   Loading %s ... ", type_name);
 memmove_wd ((void *)load, (void *)image_start,
 image_len, CHUNKSZ);
 }
 *load_end = load + image_len;
 puts("OK\n");
 break;

So, the memmove_wd never completes, it seems.

I added a debug statement at the top of memmove_wd, and got:

Moving memory from ff820040 to 8000

Is that because the uImage header is 64 bytes?

Also, the following suggests that there may be something wrong with the 
addresses that I am using:

DNS323B1> bootm FF82 FF9A
## Booting kernel from Legacy Image at ff82 ...
Image Name:   Linux-2.6.12.6-arm1
Image Type:   ARM Linux Kernel Image (uncompressed)
Data Size:1490204 Bytes = 1.4 MiB
Load Address: 8000
Entry Point:  8000
Verifying Checksum ... OK
## Loading init Ramdisk from Legacy Image at ff9a ...
Image Name:   Ramdisk
Image Type:   ARM Linux RAMDisk Image (gzip compressed)
Data Size:5240600 Bytes = 5 MiB
Load Address: 0080
Entry Point:  0080
Verifying Checksum ... Bad Data CRC
Ramdisk image is corrupt or invalid
DNS323B1>

My chainloaded u-boot is configured in an image to load at 0x300, 
and stay there (no relocation), if I have understood these parameters 
correctly:

-a 0x300 -e 0x300

Can anyone see what I am doing wrong?

Many thanks!

Rogan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot