Re: [microblaze-uclinux] "Found romfs @... klimit" message during kernel boot

["Victor G." <vga9@xxxxxx>]

>> petalinux-dist/u-boot/System.map
>> linux-2.6-x-petalogix/System.map <- "__log_buf" is at address 0x901b3df8
>>
>> When I md this address right after u-boot upload (without kernel
>> start), I see Linux version 2.6.20, PetaLinux build, CPU info, etc.
>
> this is correct - you should see there what you should see on console. Is there any problem with
> kernel? (Kernel panic or whatever non standard?)

I did not see any panic messages. Since this is the first time booting
it up, I might be looking in the wrong place for them (i.e. I am just
referring to kermit and u-boot's messages).

Nothing is displayed on screen except :
Console 1:
xmd> dow -data /tftpboot/image.bin 0x90000000
xmd> rst

Console 2:
# Uploaded u-boot via serial cat /tftpboot/u-boot.srec > /dev/ttyUSB1
# Then stopped it and
U-boot> go 0x90000000
## Starting application at 0x90000000 ...
Found romfs @ 0x901b108c (0x000f7000)
#### klimit 901c9000 ####
Moving 0x000f7000 bytes from 0x901b108c to 0x901c8868
New klimit: 0x902c0000
L

Note that the last line displays "L", which is the first letter of the
bootup sequence!

So, what I've done now is via console 1's xmd, I reset the processor
and it printed "i" to console 2!
So, every "xmd> rst" in console 1 prints another letter of __log_buf
to console 2!

Could it be uart flushing problem? When I am running "xmd> rst", it is
probably re-starting FS-boot at 0x0, but what I see on console 2 is
the old buffered message sitting in uart. Maybe it has to do something
with uart interrupts?

It could be that the "klimit" message is normal. I've checked
0x901b108c and it has "Compressed ROMFS" text. It is also found at the
"moved" location as per the message (i.e. 0x901c8868). Looks like it's
copied there. (it does not lie, there is romfs there).

Does __log_buf address (0x901b3df8) store the messages written by
kernel? And uart just reads from there and send it over the serial
link? Then it is booting!

>> If I upload kernel, however, using xmd as described in my previous
>> post, the "klimit" message is displayed and u-boot becomes
>> inaccessible. Did you want me to check this address after kernel
>> loading attempt by any chance?
>
> Workflow - load kernel via xmd, wait some time - xmd - load U-BOOT (dow u-boot),
> md 0x901b3df8 to see what kernel did.

After the above debugging, I re-uploaded the system bitstream via
impact because I could not get back to normal u-boot prompt. Checking
0x901b3df8 showed the expected bootup sequence "Linux version
2.6.20"etc. I scrolled down the memory and saw that the last messages
displayed were (followed by empty lines):
"io scheduler deadline registered
io scheduler cfq registered (default)
uartlite.0: ttyUL0 at MMIO 0x84000000 (irq = 2) is uartlite"

Another thing I've seen above in __log_buf was:
OPB INTC #0 at 0x81800000
which calls for another question. I enabled OPB interrupt controller
in menuconfig. However, I am using PLB bus. Does it make sense? I
didn't see any warnings.

Maybe something is screwed with Uartlite's interrupts because of that.

Thanks,
Victor
___________________________
microblaze-uclinux mailing list
microblaze-uclinux@xxxxxxxxxxxxxx
Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
Mailing List Archive : http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/