early_printk_console is enabled but no more outputs after

[fargierp]

Hello,

I have a Microblaze system based on Uartlite and EthernetLite IP mainly. I am struggling to launch Linux on it and I am following directions from Xilinx Open Source website.

I configured my kernel to get finally my elf image then I launch the execution and I get only the following line:

early_printk_console is enabled at 0x93000000
Ramdisk addr 0x00000003, Compiled-in FDT at 0xa024a2a0

Here are my device tree settings into xps:

-console_device: xps_uartlite_0 

-bootargs: console=ttyUL0 ip=X.X.X.X

Because I receive something from Uart on my terminal, it should be good but I indicate it only because I didn't use the "root=/dev/ram" as it is adviced on the Xilinx Open Source tutorial.

I think there is a problem with how I compile the kernel  and how to indicate the initramfs_complete filesystem to use at boot.

I copied the initramfs_complete.cpio.gz into the "kernel" directory and here is how I configured the .config file:

 # CONFIG_INITRAMFS_NO_CHECK is not set
CONFIG_INITRAMFS_SOURCE=""
CONFIG_RD_GZIP=y
# CONFIG_RD_BZIP2 is not set
# CONFIG_RD_LZMA is not set
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set

#
# Advanced setup
#
CONFIG_ADVANCED_OPTIONS=y
CONFIG_HIGHMEM_START=0xfe000000
CONFIG_LOWMEM_SIZE_BOOL=y
CONFIG_LOWMEM_SIZE=0x01000000
CONFIG_KERNEL_START_BOOL=y
CONFIG_KERNEL_START=0xa0000000
# CONFIG_TASK_SIZE_BOOL is not set
CONFIG_TASK_SIZE=0x80000000
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_FLATMEM_MANUAL=y

My DDRRAM starts at 0xA000000  and my UARTLITE address space starts from 0x93000000.

I don't understand why it outputs:

" Ramdisk addr 0x00000003 "

Do you have to set the parameter

 CONFIG_INITRAMFS_SOURCE=""

I set it to "kernel/initramfs_complete.cpio.gz"  and I tried "kernel/initramfs_complete.cpio" decompressing the ramdisk image but without success.

I would be grateful to receive help on this topic, can somebody knows if my .config configuration seems right? And why the output is not more than these two lines?

Thanks and best regards,

Pierre

PS: I am attaching my MHS file.

[Anonymous]

What do you have CONFIG_KERNEL_BASE_ADDR set to?  I think this might be your problem, it probably doens't line up with your memory base address.

Terry

[fargierp]

Hi Terry,

I set the following options like that:

-CONFIG_KERNEL_BASE_ADDR = 0xA0000000

because my RAM physical address space starts at this address (see .mhs file attached).

In the Linux configuration help the parameter  CONFIG_KERNEL_START is used to set a VIRTUAL address.

I tried:

- not to set it as adviced and I can't download my elf properly (see snapshot fail_to_load_without_KERNEL_START).

  The elf file contains code at address 0xC0000000 that is not accessible in my system. Actually it seems this address is the default value when

  the option is not set by user.

- to set it at CONFIG_KERNEL_START=0xA0000000, then the program runs but stops after displaying two lines on the UART (early_printk_console is enabled at 0x93000000, etc...)

What do you think of these options and do you think they are set properly?

Thanks and best regards,

Pierre

[Anonymous]

Try putting CONFIG_KERNEL_START back to 0xc0000000 then (or unsetting CONFIG_ADVANCED_OPTIONS), then instead of invoking xmd from the xps gui, try running from the command line:

> xmd

%XMD> conncect mbmdm

%XMD> dow simpleImage.... 

See if that gets you any further.. 

[fargierp]

Terry,

I launched XMD from cmd line:

xmd

connect mb mdm

dow simpleImage.xilinx

run

This time I don't have any output on UART, it seems that the ELF is loaded in 0xC0000000. Please have a look at file command_line_without_xps.jpg.

I am attaching the .config file too.  

Thanks and best regards,

Pierre

[Anonymous]

The example design on the wiki for microblaze has memory at 0x50000000 - not sure, but that may be a requirement the way the images are built right now.. Try moving your memory to 0x50000000 (don't forget to update the .dts) and see if that works..

Terry

[linnj]

The memory does not have to be at 0x50000000 as it has been tested at 0x90000000 also.

This is the physical address of memory where it's put in the EDK project.

[linnj]

You should only be changing the kernel config item that is shown on the wiki, not others. 

From http://xilinx.wikidot.com/microblaze-linux

Kernel Configuration Details

A significant difference with the MicroBlaze Linux kernel configuration is that it must contain parameters to match the processor hardware configuration (barrel shifter, multiplier, etc). This is because the GCC must be passed flags when the kernel is built to build code that matches the processor hardware.

From the top level menu in the kernel configuation, select "Platform options" such that a menu similar as shown below is displayed. The values in this menu should match the values for the Microblaze in the device tree file which was generated from the EDK project.

[fargierp]

Hi,

I retried to configure the .config. I need the UARTLite and Ethernet Lite support so I have to modify it besides the Platform settings, haven't I?

I have a doubt about my Microblaze version following this line from wiki:

MicroBlaze version 7.20c has problems with write back caches such that 7.20d must be used 

Does it mean that all versions before 7.20d don't work ? I am using a 7.10c so it may be the problem.

Regards,

Pierre

[linnj]

I started reviewing more of your system details and found problems.

On the MicroBlaze, the MMU is not setup for virtual mode as it should be 3.

From your MHS file,  PARAMETER C_USE_MMU = 2, this should be 3

IMHO only, your system is a little more complex than I personally like when trying to bring up Linux on a new unknown system. I'm not saying it shouldn't work, I just saying that when getting the 1st system running it's easier to use the minimal system (uart, timer, memory, mb) without a lot of other stuff.  There are a lot of variables with this so reducing them can help.

The version of microblaze shouldn't be a problem I believe as we're not using write back caches yet in our tree and your not using usb host or other cores with dma.  Using the latest version of MicroBlaze is important if you're using any cached and non-cached memory together in the kernel like buffer descriptors for ethernet with dma. That's not your case I think.

Assuming you configure using xilinx_mmu_defconfig like the wiki suggests, it has UART Lite turned on and Emac Lite turned on also. This default configuration also has the initramfs image setup to be the "initramfs_minimal.cpio.gz" in the kernel root directory. The root file system won't keep the kernel from starting up so that you get some console output.

Hope that helps.

[fargierp]

Hello John,

I thank you for your help. You are rigth it is better to start from a smaller system. I changed mine to have it minimal but I kept Ethernet Lite IP.

I hadn't understood that I had to use the xilinx_mmu_defconfig even if I don't have the ML507 board, so it is why I tried to configure the .config on my side.

Thank you for your advice.

Here is what I did:

-make ARCH=microblaze xilinx_mmu_config => it created a .config file into the root directory

-make ARCH=microblaze menuconfig to customize the previous .config. I only changed the "Physical address where Linux kernel is" and I set it at 0xA0000000 (start of my RAM)and the  "microblaze version".

 I checked that the "Platform options" match the device tree file:

BEGIN microblaze
 PARAMETER INSTANCE = microblaze_0
 PARAMETER HW_VER = 7.10.c
 PARAMETER C_DEBUG_ENABLED = 1
 PARAMETER C_USE_MMU = 3
 PARAMETER C_MMU_ZONES = 2
 PARAMETER C_FAMILY = virtex5
 PARAMETER C_INSTANCE = microblaze_0
 BUS_INTERFACE DPLB = mb_plb
 BUS_INTERFACE IPLB = mb_plb
 BUS_INTERFACE DEBUG = microblaze_0_dbg
 BUS_INTERFACE DLMB = dlmb
 BUS_INTERFACE ILMB = ilmb
 PORT MB_RESET = mb_reset
 PORT Interrupt = Interrupt
END

I can make the simpleImage.xilinx but when I download it into XMD, it tries to store it at 0xc0000000. 

It is the a virtual address described by option:  CONFIG_KERNEL_START=0xC0000000

So I thought that MMU was not enabled but in XMD I can read Full_MMU.

I am sending you snapshot from XPS and XMD so that your can see my system more easily.

I thank you in advance for your help. Best regards,

Pierre

[Anonymous]

Try the command line XMD method again:

> xmd

%XMD> conncect mb mdm

%XMD> dow simpleImage....

[fargierp]

Hi,

Thank you it works now but could you please tell me why I have a ELF image with section addresses at 0xC0000000? And i don't have any memory at this address?

I really don't undertand why XMD from XPS doesn't work but using command line  to launch it works.

Moreover, are you sure that I don't have to indicate the root=/dev/ram (as indicated in Wiki) in the boot option because I got:

Root-NFS: No NFS server available, giving up.
VFS: Unable to mount root fs via NFS, trying floppy.
VFS: Cannot open root device "<NULL>" or unknown-block(2,0)
Please append a correct "root=" boot option; here are the available partitions:
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(2,0)
Rebooting in 120
Machine restart...

Stack:
  cf821eb8 00000000 00000000 00000000 cf821ed4 c0028138 c02a0d80 0000026f
  0000e800 00000000 19981fc0 00000000 c001560c c00155e0 00000000 00000000
  cf8bd000 00008001 c029f3f4 c0353054 c02a3270 00000078 c043c944 ffffffff
Call Trace:

[<c0028138>] emergency_restart+0xc/0x20
[<c001560c>] panic+0x158/0x210
[<c00155e0>] panic+0x12c/0x210
[<c0353054>] mount_block_root+0x124/0x298
[<c03533d0>] mount_root+0x208/0x224
[<c03533b8>] mount_root+0x1f0/0x224
[<c03535f4>] prepare_namespace+0x208/0x274
[<c0352240>] kernel_init+0x13c/0x178
[<c0352228>] kernel_init+0x124/0x178
[<c0002698>] kernel_thread_helper+0xc/0x20
[<c000268c>] kernel_thread_helper+0x0/0x20

[Anonymous]

When launching XMD from XPS, it specifies the project as an input file, so XMD does some design rule checking - one of those being that it checks to make sure you're accessing memory that is actually defined. Since the .elf references virtual addresses (0xC00000000) that don't exist physically, XMD complains.    By lauching xmd standalone, it doesn't do the DRCs since it has no knowledge of the project, and the .elf actually loads properly since the physical address offset is also available in the .elf.  Not sure if there is a better workaround, but I'm going to look into it.

Now as far as why the .elf is the way it is, or how exaclty the virtual->physical address magic happens when loading the .elf -  I'll defer to John or Brian, they're be able to explain it better. 

You don't have to have root=/dev/ram  - my current project that uses initramfs has bootargs set to  "console=ttyUL0,115200 ip=192.168.0.2" in the .dts and it works just fine.  What do you have bootargs set to?

Terry

[fargierp]

I have  bootargs = "console=ttyUL0 ip=164.129.69.34"; (my dts file is into this xilinx forum thread)

and as John adviced me I put the initramfs_minimal.cpio.gz in the root directory of the files (not into the directory "kernel" at the same level as arch because it didn't work).

So I am going to try with /dev/ram maybe it is going to work.

Just to know, how big the simpleImage should be? Is 4MB enough to be sure that the root filesystem has been taken into account for the make process?

 It would be great too to add to the forum that one must launch XMD from command-line. 

And if John or Brian can explain a little bit the magical thing about the elf virtual-physical addresses...

I did mb-objdump on my image and all addresses are virtual. So I assume that when I launch XMD> dow simpleImage the MMU is already configured properly and the page table too, but which code did it? Or maybe the TLB are already configured in hardware when you program the FPGA?

I am curious

[fargierp]

Hi,

It was a problem of compilation, I "make mrproper" and it worked finally.

I would be really thankfull to know why all the simpleImage elf file is in virtual address space? And where was the code that initialized the MMU?

Anyway, thank you a lot to all of you for your kind help and support.

Best regards, 

Pierre

[linnj]

Sorry for the delay, I was out of the office. 

When you do an objdump on the elf file, use a -h option and it will show the headers which will also show you that there are real and virtual addresses being used.

Hope that helps. I realize it's not crystal clear, as many things in the kernel tend to not to be.

Thanks.