Generating elf kernel ?

Generating elf kernel ?

[Guillaume Dargaud]

Hello all,
In the past I've been using the PPC architecture to generate elf kernels (I 
wrote my own bootloader):
$ file zImage.elf 
zImage.elf: ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1 
(SYSV), statically linked, not stripped

I'm now trying to change to the PowerPC architecture, but the generated kernel 
is different and won't load:
$ file zImage
zImage: u-boot/PPCBoot image

How do I generate an elf file ?
For what it's worth, I use the Xilinx-patched kernel and I load it to a flash 
mem using impact.
-- 
Guillaume Dargaud
http://www.gdargaud.net/

Re: Generating elf kernel ?

[tiejun.chen]

Guillaume Dargaud wrote:
> Hello all,
> In the past I've been using the PPC architecture to generate elf kernels (I 
> wrote my own bootloader):
> $ file zImage.elf 
> zImage.elf: ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1 
> (SYSV), statically linked, not stripped
> 
> I'm now trying to change to the PowerPC architecture, but the generated kernel 
> is different and won't load:
> $ file zImage
> zImage: u-boot/PPCBoot image
> 
> How do I generate an elf file ?

Try simpleImage/dtbImage. But you have to check if there is a file,
arch/powerpc/boot/<platform>.c.

For more detail on this please refer to Documentation/powerpc/bootwrapper.txt.

> For what it's worth, I use the Xilinx-patched kernel and I load it to a flash 
> mem using impact.

Which bootloader? Looks you want to run it as XIP.

Tiejun

Re: Generating elf kernel ?

[Guillaume Dargaud]

> Which bootloader? Looks you want to run it as XIP.

I have my own downloader which does a few things and then transfers the kernel 
from a flash to the memory and then simply jumps to the 1st address with a 
0x40000() C function call.

But I need to first use Xilinx tools to transfer the kernel from the 
development PC to the memory of my device (and then my own 'one-time-only' 
tool to transfer from mem to flash). And the xilinx program refuses that 
kernel, complaining that it's not an elf file.
-- 
Guillaume Dargaud
http://www.gdargaud.net/

Re: Generating elf kernel ?

[Baurzhan Ismagulov]

On Tue, Sep 14, 2010 at 10:53:11AM +0200, Guillaume Dargaud wrote:
> How do I generate an elf file ?

vmlinux?

With kind regards,
-- 
Baurzhan Ismagulov
http://www.kz-easy.com/

Re: Generating elf kernel ?

[Guillaume Dargaud]

> > How do I generate an elf file ?
> vmlinux?

Thanks.

The entry point address has change and I can't upload it:
New (bad) one:
$ readelf -h vmlinux
...
  Entry point address:               0xc0000000

Old (good) one:
$ readelf -h zImage.elf 
...
  Entry point address:               0x400000

How can I change the entry point address ?
-- 
Guillaume Dargaud
http://www.gdargaud.net/

Re: Generating elf kernel ?

[tiejun.chen]

Guillaume Dargaud wrote:
>>> How do I generate an elf file ?
>> vmlinux?
> 
> Thanks.
> 
> The entry point address has change and I can't upload it:
> New (bad) one:
> $ readelf -h vmlinux
> ...
>   Entry point address:               0xc0000000
> 
> Old (good) one:
> $ readelf -h zImage.elf 
> ...
>   Entry point address:               0x400000
> 
> How can I change the entry point address ?

It's impossible to boot PPC vmlinux format directly if you only change the
original entry point address, 0xc0000000.

For kernel the following is as default:
v:0xc0000000 --> p:0x0

Please use simpleImage.<your target dts name>.elf.

Cheers
Tiejun

Re: Generating elf kernel ?

[Guillaume Dargaud]

> Please use simpleImage.<your target dts name>.elf.

Great, that seems to be it...
Except that nothing happens when I jump to 0x40000, no message from the 
kernel, nothing.
I'm a bit stumped here as my old kernel worked fine.
-- 
Guillaume Dargaud
http://www.gdargaud.net/

Re: Generating elf kernel ?

[tiejun.chen]

Guillaume Dargaud wrote:
>> Please use simpleImage.<your target dts name>.elf.
> 
> Great, that seems to be it...
> Except that nothing happens when I jump to 0x40000, no message from the 

0x40000? I recalled the entry point should be 0x400000 for simepleImage.*.elf.
So you have to change this on the file, arch/powerpc/boot/wrapper.

And also you should confirm if the upstream kernel support your board.

Additionally let's assume your bootloader create the map between the virtual
address and the physical address as 1:1. If so you want to execute from 0x40000.
 But the actual PC address should be the loader address + offset. You can get
this by readelf. Here if your loader address is zero, the offset will be pc
address, not 0x40000. You can dump your memory to check this.

Cheers
Tiejun

> kernel, nothing.
> I'm a bit stumped here as my old kernel worked fine.

Re: Generating elf kernel ?

[Guillaume Dargaud]

> >> Please use simpleImage.<your target dts name>.elf.
> > 
> > Great, that seems to be it...
> > Except that nothing happens when I jump to 0x40000, no message from the
> 
> 0x40000? I recalled the entry point should be 0x400000 for
> simepleImage.*.elf. So you have to change this on the file,
> arch/powerpc/boot/wrapper.

Correct, I skipped a zero, the address is indeed 0x400000

> And also you should confirm if the upstream kernel support your board.

Our board is a custom derivative from a ML405.
My previous project uses ARCH=PPC and has been working fine for 2 years.
I'm currently trying to go to ARCH=PowerPC and understand dts files in order to 
boot my first kernel.
I assume I shouldn't have to change anything in my bootloader.
After I jump to the kernel address, I don't even get the usual:
loaded at:     00400000 004F559C
board data at: 004F3520 004F359C
relocated to:  0040505C 004050D8
zimage at:     00405E48 004F211C
avail ram:     004F6000 08000000
Linux/PPC load: console=ttyUL0,115200 rw root=/dev/nfs ip=bootp
Uncompressing Linux...done.
Now booting the kernel

Something wrong with my serial console ?

> Additionally let's assume your bootloader create the map between the
> virtual address and the physical address as 1:1. If so you want to execute
> from 0x40000. But the actual PC address should be the loader address +
> offset. You can get this by readelf. Here if your loader address is zero,
> the offset will be pc address, not 0x40000. You can dump your memory to
> check this.

The bootloader has no concept of virtual address, right ?

-- 
Guillaume Dargaud
http://www.gdargaud.net/

Re: Generating elf kernel ?

[tiejun.chen]

Guillaume Dargaud wrote:
>>>> Please use simpleImage.<your target dts name>.elf.
>>> Great, that seems to be it...
>>> Except that nothing happens when I jump to 0x40000, no message from the
>> 0x40000? I recalled the entry point should be 0x400000 for
>> simepleImage.*.elf. So you have to change this on the file,
>> arch/powerpc/boot/wrapper.
> 
> Correct, I skipped a zero, the address is indeed 0x400000
> 
>> And also you should confirm if the upstream kernel support your board.
> 
> Our board is a custom derivative from a ML405.

Understood.

So I recommend you use the kernel tree from xilinx. You can refer to the
following website:

http://xilinx.wikidot.com/powerpc-linux

I hope you can skip many issues to accelerate your progress based on the xilinx
kernel.

> My previous project uses ARCH=PPC and has been working fine for 2 years.
> I'm currently trying to go to ARCH=PowerPC and understand dts files in order to 
> boot my first kernel.
> I assume I shouldn't have to change anything in my bootloader.
> After I jump to the kernel address, I don't even get the usual:
> loaded at:     00400000 004F559C
> board data at: 004F3520 004F359C
> relocated to:  0040505C 004050D8
> zimage at:     00405E48 004F211C
> avail ram:     004F6000 08000000
> Linux/PPC load: console=ttyUL0,115200 rw root=/dev/nfs ip=bootp
> Uncompressing Linux...done.
> Now booting the kernel
> 
> Something wrong with my serial console ?

You have to check if you go the correct PC address. Note please check the real
pc address according to the previous comments.

If yes you can check where your kernel stop. Certainly if you have some tools,
such as JTAG debug tools it's convenient to track this. But if no it will be
difficult to go no next.

But you still have ways to do, such as display LED, early printk, and dump
__log_buf.

> 
>> Additionally let's assume your bootloader create the map between the
>> virtual address and the physical address as 1:1. If so you want to execute
>> from 0x40000. But the actual PC address should be the loader address +
>> offset. You can get this by readelf. Here if your loader address is zero,
>> the offset will be pc address, not 0x40000. You can dump your memory to
>> check this.
> 
> The bootloader has no concept of virtual address, right ?

This should be depend on the given PPC core. For example, we cannot disable MMU
on e500. Bur for ML405 we can disable MMU to run real mode on 405.

Cheers
Tiejun

> 

Initial kernel command string (Was: Generating elf kernel ?)

[Guillaume Dargaud]

Thanks for helping about the elf issue, I got it running. The problem was that 
I wasn't using the proper file produced by make !


Now I have a strange and probably simple problem that the Initial kernel 
command string is incorrect. I want, and I have set in the .config:
CONFIG_CMDLINE="console=ttyUL0,115200 rw root=/dev/nfs ip=bootp"

But when my kernel boots it uses:
console=ttyUL0 root=/dev/ram

I can check:
strings arch/powerpc/boot/simpleImage.virtex405-ml405.elf | grep console
Vconsole=ttyUL0 root=/dev/ram


Also my previous kernel would wait for 2 seconds at the beginning to allow me 
to change the initial command string via the serial port, but now it just runs 
right through. How can I enable this option ?

On the plus side it boots in .5 seconds !

Here's my .config:
CONFIG_40x=y
CONFIG_4xx=y
CONFIG_PPC_MMU_NOHASH=y
CONFIG_PPC_MMU_NOHASH_32=y
CONFIG_NOT_COHERENT_CACHE=y
CONFIG_PPC32=y
CONFIG_WORD_SIZE=32
CONFIG_MMU=y
CONFIG_GENERIC_CMOS_UPDATE=y
CONFIG_GENERIC_TIME=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_HARDIRQS_NO__DO_IRQ=y
CONFIG_IRQ_PER_CPU=y
CONFIG_NR_IRQS=512
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_ARCH_HAS_ILOG2_U32=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_FIND_NEXT_BIT=y
CONFIG_GENERIC_GPIO=y
CONFIG_PPC=y
CONFIG_EARLY_PRINTK=y
CONFIG_GENERIC_NVRAM=y
CONFIG_SCHED_OMIT_FRAME_POINTER=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_PPC_OF=y
CONFIG_OF=y
CONFIG_PPC_UDBG_16550=y
CONFIG_AUDIT_ARCH=y
CONFIG_GENERIC_BUG=y
CONFIG_DTC=y
CONFIG_DEFAULT_UIMAGE=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_PPC_DCR_NATIVE=y
CONFIG_PPC_DCR_MMIO=y
CONFIG_PPC_DCR=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_PPC_ADV_DEBUG_REGS=y
CONFIG_PPC_ADV_DEBUG_IACS=2
CONFIG_PPC_ADV_DEBUG_DACS=2
CONFIG_PPC_ADV_DEBUG_DVCS=0
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_CONSTRUCTORS=y
CONFIG_EXPERIMENTAL=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_LOCALVERSION=""
CONFIG_TREE_RCU=y
CONFIG_RCU_FANOUT=32
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=14
CONFIG_NAMESPACES=y
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_SYSCTL=y
CONFIG_ANON_INODES=y
CONFIG_SYSCTL_SYSCALL=y
CONFIG_KALLSYMS=y
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_AIO=y
CONFIG_HAVE_PERF_EVENTS=y
CONFIG_PERF_EVENTS=y
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_COMPAT_BRK=y
CONFIG_SLAB=y
CONFIG_HAVE_OPROFILE=y
CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y
CONFIG_HAVE_IOREMAP_PROT=y
CONFIG_HAVE_KPROBES=y
CONFIG_HAVE_KRETPROBES=y
CONFIG_HAVE_ARCH_TRACEHOOK=y
CONFIG_HAVE_DMA_ATTRS=y
CONFIG_HAVE_DMA_API_DEBUG=y
CONFIG_SLABINFO=y
CONFIG_RT_MUTEXES=y
CONFIG_BASE_SMALL=0
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
CONFIG_BLOCK=y
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
CONFIG_DEFAULT_CFQ=y
CONFIG_DEFAULT_IOSCHED="cfq"
CONFIG_INLINE_SPIN_UNLOCK=y
CONFIG_INLINE_SPIN_UNLOCK_IRQ=y
CONFIG_INLINE_READ_UNLOCK=y
CONFIG_INLINE_READ_UNLOCK_IRQ=y
CONFIG_INLINE_WRITE_UNLOCK=y
CONFIG_INLINE_WRITE_UNLOCK_IRQ=y
CONFIG_PPC4xx_GPIO=y
CONFIG_XILINX_VIRTEX=y
CONFIG_XILINX_VIRTEX_GENERIC_BOARD=y
CONFIG_PPC40x_SIMPLE=y
CONFIG_XILINX_VIRTEX_II_PRO=y
CONFIG_XILINX_VIRTEX_4_FX=y
CONFIG_IBM405_ERR77=y
CONFIG_IBM405_ERR51=y
CONFIG_SIMPLE_GPIO=y
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
CONFIG_HZ_250=y
CONFIG_HZ=250
CONFIG_PREEMPT_VOLUNTARY=y
CONFIG_BINFMT_ELF=y
CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y
CONFIG_ARCH_HAS_WALK_MEMORY=y
CONFIG_ARCH_ENABLE_MEMORY_HOTREMOVE=y
CONFIG_SPARSE_IRQ=y
CONFIG_MAX_ACTIVE_REGIONS=32
CONFIG_ARCH_FLATMEM_ENABLE=y
CONFIG_ARCH_POPULATES_NODE_MAP=y
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_FLATMEM_MANUAL=y
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
CONFIG_PAGEFLAGS_EXTENDED=y
CONFIG_SPLIT_PTLOCK_CPUS=4
CONFIG_ZONE_DMA_FLAG=1
CONFIG_BOUNCE=y
CONFIG_VIRT_TO_BUS=y
CONFIG_DEFAULT_MMAP_MIN_ADDR=4096
CONFIG_PPC_4K_PAGES=y
CONFIG_FORCE_MAX_ZONEORDER=11
CONFIG_PROC_DEVICETREE=y
CONFIG_CMDLINE_BOOL=y
CONFIG_CMDLINE="console=ttyUL0,115200 rw root=/dev/nfs ip=bootp"
CONFIG_EXTRA_TARGETS=""
CONFIG_ISA_DMA_API=y
CONFIG_ZONE_DMA=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_4xx_SOC=y
CONFIG_PPC_PCI_CHOICE=y
CONFIG_ADVANCED_OPTIONS=y
CONFIG_LOWMEM_SIZE=0x30000000
CONFIG_PAGE_OFFSET=0xc0000000
CONFIG_KERNEL_START=0xc0000000
CONFIG_PHYSICAL_START=0x00000000
CONFIG_TASK_SIZE=0xc0000000
CONFIG_CONSISTENT_SIZE=0x00200000
CONFIG_NET=y
CONFIG_PACKET=y
CONFIG_UNIX=y
CONFIG_INET=y
CONFIG_IP_FIB_HASH=y
CONFIG_IP_PNP=y
CONFIG_IP_PNP_DHCP=y
CONFIG_IP_PNP_BOOTP=y
CONFIG_INET_DIAG=y
CONFIG_INET_TCP_DIAG=y
CONFIG_TCP_CONG_CUBIC=y
CONFIG_DEFAULT_TCP_CONG="cubic"
CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=y
CONFIG_FIRMWARE_IN_KERNEL=y
CONFIG_EXTRA_FIRMWARE=""
CONFIG_OF_FLATTREE=y
CONFIG_OF_DYNAMIC=y
CONFIG_OF_DEVICE=y
CONFIG_OF_GPIO=y
CONFIG_XILINX_DRIVERS=y
CONFIG_NEED_XILINX_LLDMA=y
CONFIG_HAVE_IDE=y
CONFIG_SCSI_MOD=y
CONFIG_NETDEVICES=y
CONFIG_NETDEV_1000=y
CONFIG_XILINX_LLTEMAC=y
CONFIG_XILINX_LLTEMAC_MARVELL_88E1111_GMII=y
CONFIG_INPUT=y
CONFIG_INPUT_MOUSEDEV=y
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
CONFIG_SERIO=y
CONFIG_SERIO_SERPORT=y
CONFIG_VT=y
CONFIG_CONSOLE_TRANSLATIONS=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
CONFIG_DEVKMEM=y
CONFIG_SERIAL_UARTLITE=y
CONFIG_SERIAL_UARTLITE_CONSOLE=y
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
CONFIG_UNIX98_PTYS=y
CONFIG_ARCH_WANT_OPTIONAL_GPIOLIB=y
CONFIG_ARCH_REQUIRE_GPIOLIB=y
CONFIG_GPIOLIB=y
CONFIG_GPIO_SYSFS=y
CONFIG_GPIO_XILINX=y
CONFIG_SSB_POSSIBLE=y
CONFIG_DUMMY_CONSOLE=y
CONFIG_XILINX_EDK=y
CONFIG_UIO=y
CONFIG_UIO_PDRV=y
CONFIG_UIO_PDRV_GENIRQ=y
CONFIG_FILE_LOCKING=y
CONFIG_PROC_FS=y
CONFIG_PROC_SYSCTL=y
CONFIG_PROC_PAGE_MONITOR=y
CONFIG_SYSFS=y
CONFIG_CONFIGFS_FS=y
CONFIG_NETWORK_FILESYSTEMS=y
CONFIG_NFS_FS=y
CONFIG_NFS_V3=y
CONFIG_ROOT_NFS=y
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y
CONFIG_NFS_COMMON=y
CONFIG_SUNRPC=y
CONFIG_MSDOS_PARTITION=y
CONFIG_BITREVERSE=y
CONFIG_GENERIC_FIND_LAST_BIT=y
CONFIG_CRC_CCITT=y
CONFIG_CRC32=y
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT=y
CONFIG_HAS_DMA=y
CONFIG_HAVE_LMB=y
CONFIG_NLATTR=y
CONFIG_GENERIC_ATOMIC64=y
CONFIG_PRINTK_TIME=y
CONFIG_ENABLE_WARN_DEPRECATED=y
CONFIG_ENABLE_MUST_CHECK=y
CONFIG_FRAME_WARN=1024
CONFIG_DEBUG_BUGVERBOSE=y
CONFIG_DEBUG_MEMORY_INIT=y
CONFIG_RCU_CPU_STALL_DETECTOR=y
CONFIG_SYSCTL_SYSCALL_CHECK=y
CONFIG_HAVE_FUNCTION_TRACER=y
CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y
CONFIG_HAVE_DYNAMIC_FTRACE=y
CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y
CONFIG_TRACING_SUPPORT=y
CONFIG_HAVE_ARCH_KGDB=y
CONFIG_PPC_WERROR=y
CONFIG_PRINT_STACK_DEPTH=64
CONFIG_DEFAULT_SECURITY_DAC=y
CONFIG_DEFAULT_SECURITY=""
CONFIG_CRYPTO=y
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_ALGAPI2=y
CONFIG_CRYPTO_RNG=y
CONFIG_CRYPTO_RNG2=y
CONFIG_CRYPTO_AES=y
CONFIG_CRYPTO_ANSI_CPRNG=y

-- 
Guillaume Dargaud
http://www.gdargaud.net/

Re: Initial kernel command string (Was: Generating elf kernel ?)

[tiejun.chen]

Guillaume Dargaud wrote:
> Thanks for helping about the elf issue, I got it running. The problem was that 
> I wasn't using the proper file produced by make !
> 
> 
> Now I have a strange and probably simple problem that the Initial kernel 
> command string is incorrect. I want, and I have set in the .config:
> CONFIG_CMDLINE="console=ttyUL0,115200 rw root=/dev/nfs ip=bootp"

I think you should modify the bootargs on your dts.
------
        chosen {
                bootargs = "console=ttyS0 root=/dev/ram";
                linux,stdout-path = "/plb@0/serial@83e00000";
        } ;

> 
> But when my kernel boots it uses:
> console=ttyUL0 root=/dev/ram
> 
> I can check:
> strings arch/powerpc/boot/simpleImage.virtex405-ml405.elf | grep console
> Vconsole=ttyUL0 root=/dev/ram
> 
> 
> Also my previous kernel would wait for 2 seconds at the beginning to allow me 
> to change the initial command string via the serial port, but now it just runs 
> right through. How can I enable this option ?

It's possible on PowerPC kernel :)

You can take a look at the file, arch/powerpc/boot/main.c.
------
static void prep_cmdline(void *chosen)
{
        if (cmdline[0] == '\0')
                getprop(chosen, "bootargs", cmdline, COMMAND_LINE_SIZE-1);

        printf("\n\rLinux/PowerPC load: %s", cmdline);
        /* If possible, edit the command line */
        if (console_ops.edit_cmdline)
                console_ops.edit_cmdline(cmdline, COMMAND_LINE_SIZE);
        printf("\n\r");
.......


So you have to define one function, console_ops.edit_cmdline -->
serial_edit_cmdline. Or you can try bind this to your boot console ops directly.
Please refer to the file, arch/powerpc/boot/serial.c.

Cheers!
Tiejun

> 
> On the plus side it boots in .5 seconds !
> 
> Here's my .config:
> CONFIG_40x=y
> CONFIG_4xx=y
> CONFIG_PPC_MMU_NOHASH=y
> CONFIG_PPC_MMU_NOHASH_32=y
> CONFIG_NOT_COHERENT_CACHE=y
> CONFIG_PPC32=y
> CONFIG_WORD_SIZE=32
> CONFIG_MMU=y
> CONFIG_GENERIC_CMOS_UPDATE=y
> CONFIG_GENERIC_TIME=y
> CONFIG_GENERIC_TIME_VSYSCALL=y
> CONFIG_GENERIC_CLOCKEVENTS=y
> CONFIG_GENERIC_HARDIRQS=y
> CONFIG_GENERIC_HARDIRQS_NO__DO_IRQ=y
> CONFIG_IRQ_PER_CPU=y
> CONFIG_NR_IRQS=512
> CONFIG_STACKTRACE_SUPPORT=y
> CONFIG_HAVE_LATENCYTOP_SUPPORT=y
> CONFIG_TRACE_IRQFLAGS_SUPPORT=y
> CONFIG_LOCKDEP_SUPPORT=y
> CONFIG_RWSEM_XCHGADD_ALGORITHM=y
> CONFIG_ARCH_HAS_ILOG2_U32=y
> CONFIG_GENERIC_HWEIGHT=y
> CONFIG_GENERIC_FIND_NEXT_BIT=y
> CONFIG_GENERIC_GPIO=y
> CONFIG_PPC=y
> CONFIG_EARLY_PRINTK=y
> CONFIG_GENERIC_NVRAM=y
> CONFIG_SCHED_OMIT_FRAME_POINTER=y
> CONFIG_ARCH_MAY_HAVE_PC_FDC=y
> CONFIG_PPC_OF=y
> CONFIG_OF=y
> CONFIG_PPC_UDBG_16550=y
> CONFIG_AUDIT_ARCH=y
> CONFIG_GENERIC_BUG=y
> CONFIG_DTC=y
> CONFIG_DEFAULT_UIMAGE=y
> CONFIG_ARCH_HIBERNATION_POSSIBLE=y
> CONFIG_PPC_DCR_NATIVE=y
> CONFIG_PPC_DCR_MMIO=y
> CONFIG_PPC_DCR=y
> CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
> CONFIG_PPC_ADV_DEBUG_REGS=y
> CONFIG_PPC_ADV_DEBUG_IACS=2
> CONFIG_PPC_ADV_DEBUG_DACS=2
> CONFIG_PPC_ADV_DEBUG_DVCS=0
> CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
> CONFIG_CONSTRUCTORS=y
> CONFIG_EXPERIMENTAL=y
> CONFIG_BROKEN_ON_SMP=y
> CONFIG_INIT_ENV_ARG_LIMIT=32
> CONFIG_LOCALVERSION=""
> CONFIG_TREE_RCU=y
> CONFIG_RCU_FANOUT=32
> CONFIG_IKCONFIG=y
> CONFIG_IKCONFIG_PROC=y
> CONFIG_LOG_BUF_SHIFT=14
> CONFIG_NAMESPACES=y
> CONFIG_CC_OPTIMIZE_FOR_SIZE=y
> CONFIG_SYSCTL=y
> CONFIG_ANON_INODES=y
> CONFIG_SYSCTL_SYSCALL=y
> CONFIG_KALLSYMS=y
> CONFIG_HOTPLUG=y
> CONFIG_PRINTK=y
> CONFIG_BUG=y
> CONFIG_ELF_CORE=y
> CONFIG_BASE_FULL=y
> CONFIG_FUTEX=y
> CONFIG_EPOLL=y
> CONFIG_SIGNALFD=y
> CONFIG_TIMERFD=y
> CONFIG_EVENTFD=y
> CONFIG_SHMEM=y
> CONFIG_AIO=y
> CONFIG_HAVE_PERF_EVENTS=y
> CONFIG_PERF_EVENTS=y
> CONFIG_VM_EVENT_COUNTERS=y
> CONFIG_COMPAT_BRK=y
> CONFIG_SLAB=y
> CONFIG_HAVE_OPROFILE=y
> CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y
> CONFIG_HAVE_IOREMAP_PROT=y
> CONFIG_HAVE_KPROBES=y
> CONFIG_HAVE_KRETPROBES=y
> CONFIG_HAVE_ARCH_TRACEHOOK=y
> CONFIG_HAVE_DMA_ATTRS=y
> CONFIG_HAVE_DMA_API_DEBUG=y
> CONFIG_SLABINFO=y
> CONFIG_RT_MUTEXES=y
> CONFIG_BASE_SMALL=0
> CONFIG_MODULES=y
> CONFIG_MODULE_UNLOAD=y
> CONFIG_MODULE_FORCE_UNLOAD=y
> CONFIG_BLOCK=y
> CONFIG_IOSCHED_NOOP=y
> CONFIG_IOSCHED_DEADLINE=y
> CONFIG_IOSCHED_CFQ=y
> CONFIG_DEFAULT_CFQ=y
> CONFIG_DEFAULT_IOSCHED="cfq"
> CONFIG_INLINE_SPIN_UNLOCK=y
> CONFIG_INLINE_SPIN_UNLOCK_IRQ=y
> CONFIG_INLINE_READ_UNLOCK=y
> CONFIG_INLINE_READ_UNLOCK_IRQ=y
> CONFIG_INLINE_WRITE_UNLOCK=y
> CONFIG_INLINE_WRITE_UNLOCK_IRQ=y
> CONFIG_PPC4xx_GPIO=y
> CONFIG_XILINX_VIRTEX=y
> CONFIG_XILINX_VIRTEX_GENERIC_BOARD=y
> CONFIG_PPC40x_SIMPLE=y
> CONFIG_XILINX_VIRTEX_II_PRO=y
> CONFIG_XILINX_VIRTEX_4_FX=y
> CONFIG_IBM405_ERR77=y
> CONFIG_IBM405_ERR51=y
> CONFIG_SIMPLE_GPIO=y
> CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
> CONFIG_HZ_250=y
> CONFIG_HZ=250
> CONFIG_PREEMPT_VOLUNTARY=y
> CONFIG_BINFMT_ELF=y
> CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y
> CONFIG_ARCH_HAS_WALK_MEMORY=y
> CONFIG_ARCH_ENABLE_MEMORY_HOTREMOVE=y
> CONFIG_SPARSE_IRQ=y
> CONFIG_MAX_ACTIVE_REGIONS=32
> CONFIG_ARCH_FLATMEM_ENABLE=y
> CONFIG_ARCH_POPULATES_NODE_MAP=y
> CONFIG_SELECT_MEMORY_MODEL=y
> CONFIG_FLATMEM_MANUAL=y
> CONFIG_FLATMEM=y
> CONFIG_FLAT_NODE_MEM_MAP=y
> CONFIG_PAGEFLAGS_EXTENDED=y
> CONFIG_SPLIT_PTLOCK_CPUS=4
> CONFIG_ZONE_DMA_FLAG=1
> CONFIG_BOUNCE=y
> CONFIG_VIRT_TO_BUS=y
> CONFIG_DEFAULT_MMAP_MIN_ADDR=4096
> CONFIG_PPC_4K_PAGES=y
> CONFIG_FORCE_MAX_ZONEORDER=11
> CONFIG_PROC_DEVICETREE=y
> CONFIG_CMDLINE_BOOL=y
> CONFIG_CMDLINE="console=ttyUL0,115200 rw root=/dev/nfs ip=bootp"
> CONFIG_EXTRA_TARGETS=""
> CONFIG_ISA_DMA_API=y
> CONFIG_ZONE_DMA=y
> CONFIG_NEED_DMA_MAP_STATE=y
> CONFIG_4xx_SOC=y
> CONFIG_PPC_PCI_CHOICE=y
> CONFIG_ADVANCED_OPTIONS=y
> CONFIG_LOWMEM_SIZE=0x30000000
> CONFIG_PAGE_OFFSET=0xc0000000
> CONFIG_KERNEL_START=0xc0000000
> CONFIG_PHYSICAL_START=0x00000000
> CONFIG_TASK_SIZE=0xc0000000
> CONFIG_CONSISTENT_SIZE=0x00200000
> CONFIG_NET=y
> CONFIG_PACKET=y
> CONFIG_UNIX=y
> CONFIG_INET=y
> CONFIG_IP_FIB_HASH=y
> CONFIG_IP_PNP=y
> CONFIG_IP_PNP_DHCP=y
> CONFIG_IP_PNP_BOOTP=y
> CONFIG_INET_DIAG=y
> CONFIG_INET_TCP_DIAG=y
> CONFIG_TCP_CONG_CUBIC=y
> CONFIG_DEFAULT_TCP_CONG="cubic"
> CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
> CONFIG_STANDALONE=y
> CONFIG_PREVENT_FIRMWARE_BUILD=y
> CONFIG_FW_LOADER=y
> CONFIG_FIRMWARE_IN_KERNEL=y
> CONFIG_EXTRA_FIRMWARE=""
> CONFIG_OF_FLATTREE=y
> CONFIG_OF_DYNAMIC=y
> CONFIG_OF_DEVICE=y
> CONFIG_OF_GPIO=y
> CONFIG_XILINX_DRIVERS=y
> CONFIG_NEED_XILINX_LLDMA=y
> CONFIG_HAVE_IDE=y
> CONFIG_SCSI_MOD=y
> CONFIG_NETDEVICES=y
> CONFIG_NETDEV_1000=y
> CONFIG_XILINX_LLTEMAC=y
> CONFIG_XILINX_LLTEMAC_MARVELL_88E1111_GMII=y
> CONFIG_INPUT=y
> CONFIG_INPUT_MOUSEDEV=y
> CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
> CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
> CONFIG_SERIO=y
> CONFIG_SERIO_SERPORT=y
> CONFIG_VT=y
> CONFIG_CONSOLE_TRANSLATIONS=y
> CONFIG_VT_CONSOLE=y
> CONFIG_HW_CONSOLE=y
> CONFIG_DEVKMEM=y
> CONFIG_SERIAL_UARTLITE=y
> CONFIG_SERIAL_UARTLITE_CONSOLE=y
> CONFIG_SERIAL_CORE=y
> CONFIG_SERIAL_CORE_CONSOLE=y
> CONFIG_UNIX98_PTYS=y
> CONFIG_ARCH_WANT_OPTIONAL_GPIOLIB=y
> CONFIG_ARCH_REQUIRE_GPIOLIB=y
> CONFIG_GPIOLIB=y
> CONFIG_GPIO_SYSFS=y
> CONFIG_GPIO_XILINX=y
> CONFIG_SSB_POSSIBLE=y
> CONFIG_DUMMY_CONSOLE=y
> CONFIG_XILINX_EDK=y
> CONFIG_UIO=y
> CONFIG_UIO_PDRV=y
> CONFIG_UIO_PDRV_GENIRQ=y
> CONFIG_FILE_LOCKING=y
> CONFIG_PROC_FS=y
> CONFIG_PROC_SYSCTL=y
> CONFIG_PROC_PAGE_MONITOR=y
> CONFIG_SYSFS=y
> CONFIG_CONFIGFS_FS=y
> CONFIG_NETWORK_FILESYSTEMS=y
> CONFIG_NFS_FS=y
> CONFIG_NFS_V3=y
> CONFIG_ROOT_NFS=y
> CONFIG_LOCKD=y
> CONFIG_LOCKD_V4=y
> CONFIG_NFS_COMMON=y
> CONFIG_SUNRPC=y
> CONFIG_MSDOS_PARTITION=y
> CONFIG_BITREVERSE=y
> CONFIG_GENERIC_FIND_LAST_BIT=y
> CONFIG_CRC_CCITT=y
> CONFIG_CRC32=y
> CONFIG_HAS_IOMEM=y
> CONFIG_HAS_IOPORT=y
> CONFIG_HAS_DMA=y
> CONFIG_HAVE_LMB=y
> CONFIG_NLATTR=y
> CONFIG_GENERIC_ATOMIC64=y
> CONFIG_PRINTK_TIME=y
> CONFIG_ENABLE_WARN_DEPRECATED=y
> CONFIG_ENABLE_MUST_CHECK=y
> CONFIG_FRAME_WARN=1024
> CONFIG_DEBUG_BUGVERBOSE=y
> CONFIG_DEBUG_MEMORY_INIT=y
> CONFIG_RCU_CPU_STALL_DETECTOR=y
> CONFIG_SYSCTL_SYSCALL_CHECK=y
> CONFIG_HAVE_FUNCTION_TRACER=y
> CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y
> CONFIG_HAVE_DYNAMIC_FTRACE=y
> CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y
> CONFIG_TRACING_SUPPORT=y
> CONFIG_HAVE_ARCH_KGDB=y
> CONFIG_PPC_WERROR=y
> CONFIG_PRINT_STACK_DEPTH=64
> CONFIG_DEFAULT_SECURITY_DAC=y
> CONFIG_DEFAULT_SECURITY=""
> CONFIG_CRYPTO=y
> CONFIG_CRYPTO_ALGAPI=y
> CONFIG_CRYPTO_ALGAPI2=y
> CONFIG_CRYPTO_RNG=y
> CONFIG_CRYPTO_RNG2=y
> CONFIG_CRYPTO_AES=y
> CONFIG_CRYPTO_ANSI_CPRNG=y
> 

Re: Initial kernel command string (Was: Generating elf kernel ?)

[Guillaume Dargaud]

> I think you should modify the bootargs on your dts.
> ------
>         chosen {
>                 bootargs = "console=ttyS0 root=/dev/ram";
>                 linux,stdout-path = "/plb@0/serial@83e00000";
>         } ;

Thanks, that worked great, I now have a fully bootable not only kernel, but 
full OS as well.

> > Also my previous kernel would wait for 2 seconds at the beginning to
> > allow me to change the initial command string via the serial port, but
> > now it just runs right through. How can I enable this option ?
> 
> It's possible on PowerPC kernel :)
> 
> You can take a look at the file, arch/powerpc/boot/main.c.
> ------
> static void prep_cmdline(void *chosen)
> {
>         if (cmdline[0] == '\0')
>                 getprop(chosen, "bootargs", cmdline, COMMAND_LINE_SIZE-1);
> 
>         printf("\n\rLinux/PowerPC load: %s", cmdline);
>         /* If possible, edit the command line */
>         if (console_ops.edit_cmdline)
>                 console_ops.edit_cmdline(cmdline, COMMAND_LINE_SIZE);
>         printf("\n\r");
> .......
> 
> 
> So you have to define one function, console_ops.edit_cmdline -->
> serial_edit_cmdline. Or you can try bind this to your boot console ops
> directly. Please refer to the file, arch/powerpc/boot/serial.c.

So I forced
 		console_ops.edit_cmdline = serial_edit_cmdline;
in serial.c, bu that didn't do the trick...
-- 
Guillaume Dargaud
http://www.gdargaud.net/

Re: Initial kernel command string (Was: Generating elf kernel ?)

[tiejun.chen]

Guillaume Dargaud wrote:
>> I think you should modify the bootargs on your dts.
>> ------
>>         chosen {
>>                 bootargs = "console=ttyS0 root=/dev/ram";
>>                 linux,stdout-path = "/plb@0/serial@83e00000";
>>         } ;
> 
> Thanks, that worked great, I now have a fully bootable not only kernel, but 
> full OS as well.

Sounds good :)

> 
>>> Also my previous kernel would wait for 2 seconds at the beginning to
>>> allow me to change the initial command string via the serial port, but
>>> now it just runs right through. How can I enable this option ?
>> It's possible on PowerPC kernel :)
>>
>> You can take a look at the file, arch/powerpc/boot/main.c.
>> ------
>> static void prep_cmdline(void *chosen)
>> {
>>         if (cmdline[0] == '\0')
>>                 getprop(chosen, "bootargs", cmdline, COMMAND_LINE_SIZE-1);
>>
>>         printf("\n\rLinux/PowerPC load: %s", cmdline);
>>         /* If possible, edit the command line */
>>         if (console_ops.edit_cmdline)
>>                 console_ops.edit_cmdline(cmdline, COMMAND_LINE_SIZE);
>>         printf("\n\r");
>> .......
>>
>>
>> So you have to define one function, console_ops.edit_cmdline -->
>> serial_edit_cmdline. Or you can try bind this to your boot console ops
>> directly. Please refer to the file, arch/powerpc/boot/serial.c.
> 
> So I forced
>  		console_ops.edit_cmdline = serial_edit_cmdline;
> in serial.c, bu that didn't do the trick...

Where are/how do your way implement? Can you paste your code sections here?

If I remember ML405 properly the serial port should be compliant to ns16550. So
I think the sub-functions, putc()/getc()/tstc(), should be from the file,
arch/powerpc/boot/ns16550.c. If so it's fine.

Maybe you can add some extra printf() into the function, serial_edit_cmdline, to
track this in detail.

Cheers
Tiejun

Re: Generating elf kernel ?

[Scott Wood]

On Wed, 15 Sep 2010 16:27:10 +0800
"tiejun.chen" <tiejun.chen@windriver.com> wrote:

> It's impossible to boot PPC vmlinux format directly if you only change the
> original entry point address, 0xc0000000.

Why?  That's pretty much what the bootwrapper does.  Our hypervisor has
directly booted vmlinux this way.

Note that in recent kernels physaddr is even set to zero, allowing the
ELF loader to just use that instead of magically knowing the kernel
wants to go at address zero.

> For kernel the following is as default:
> v:0xc0000000 --> p:0x0

That mapping is set up by code at the entry point of vmlinux, not by
the bootwrapper.

-Scott

Re: Generating elf kernel ?

[tiejun.chen]

Scott Wood wrote:
> On Wed, 15 Sep 2010 16:27:10 +0800
> "tiejun.chen" <tiejun.chen@windriver.com> wrote:
> 
>> It's impossible to boot PPC vmlinux format directly if you only change the
>> original entry point address, 0xc0000000.
> 
> Why?  That's pretty much what the bootwrapper does.  Our hypervisor has
> directly booted vmlinux this way.

Maybe you misunderstand what I mean.

Although you can change entry point of vmlinux
1> can you load the Linux vmlinux directly to the physical address '0' on
current bootloader?
2> additionally you have to find a way to pass dtb to the native vmlinux.

I believe the hypervisor can boot vmlinux directly. But your so-called vmlinux
should be guest OS. And the hypervisor will handle/assit TLB exception for the
guest OS on MMU. Right?  So you can use the hypervisor to load vmlinux to any
physical address as you expect. But the guest OS should not be same as the
native Linux.

> 
> Note that in recent kernels physaddr is even set to zero, allowing the
> ELF loader to just use that instead of magically knowing the kernel
> wants to go at address zero.

Sure.

> 
>> For kernel the following is as default:
>> v:0xc0000000 --> p:0x0
> 
> That mapping is set up by code at the entry point of vmlinux, not by
> the bootwrapper.

Absolutely.

Tiejun

> 
> -Scott
> 
> 

Re: Generating elf kernel ?

[Scott Wood]

On Thu, 16 Sep 2010 10:37:32 +0800
"tiejun.chen" <tiejun.chen@windriver.com> wrote:

> 1> can you load the Linux vmlinux directly to the physical address '0' on
> current bootloader?

That depends on what bootloader we're talking about -- I don't know
what the original poster's custom loader can do.  Obviously the
bootloader itself would have to be executing from some other address
(e.g. U-Boot runs from the top of RAM).

> 2> additionally you have to find a way to pass dtb to the native vmlinux.

Yes, of course.  But that's a different issue. :-)

> I believe the hypervisor can boot vmlinux directly. But your so-called vmlinux
> should be guest OS. And the hypervisor will handle/assit TLB exception for the
> guest OS on MMU. Right?  So you can use the hypervisor to load vmlinux to any
> physical address as you expect. 

I was just using our hypervisor as an example, since it has an ELF
loader that can pass a device tree.

> But the guest OS should not be same as the native Linux.

The guest OS *is* the same as native Linux, as far as TLB handling is
concerned.

-Scott

Re: Generating elf kernel ?

[tiejun.chen]

Scott Wood wrote:
> On Thu, 16 Sep 2010 10:37:32 +0800
> "tiejun.chen" <tiejun.chen@windriver.com> wrote:
> 
>> 1> can you load the Linux vmlinux directly to the physical address '0' on
>> current bootloader?
> 
> That depends on what bootloader we're talking about -- I don't know
> what the original poster's custom loader can do.  Obviously the
> bootloader itself would have to be executing from some other address
> (e.g. U-Boot runs from the top of RAM).
> 
>> 2> additionally you have to find a way to pass dtb to the native vmlinux.
> 
> Yes, of course.  But that's a different issue. :-)
> 
>> I believe the hypervisor can boot vmlinux directly. But your so-called vmlinux
>> should be guest OS. And the hypervisor will handle/assit TLB exception for the
>> guest OS on MMU. Right?  So you can use the hypervisor to load vmlinux to any
>> physical address as you expect. 
> 
> I was just using our hypervisor as an example, since it has an ELF
> loader that can pass a device tree.
> 
>> But the guest OS should not be same as the native Linux.
> 
> The guest OS *is* the same as native Linux, as far as TLB handling is
> concerned.

Looks you means the TLB exception handler should be same between the native and
the guest OS. Right?

Here I assume we're talking about e500mc since as far as I know for Freescale
only e500mc is designed to support virtual machine based on ISA 2.0.6.

I also know all TLB exceptions can direct to the guest OS when we enable
EPCR[DTLBGS|ITLBGS|DSIGS|ISIGS]. But some TLB instructions (i.e. tlbwe )are the
privileged instructions. So the guest OS always trap into the hypervisor and
then the hypervisor should complete the real action with appropriate physical
address. And also the hypervisor can supervisor if the guest OS want to access
the invalid physical space.

So I don't think the guest OS is same as native Linux :)

Cheers
Tiejun

> 
> -Scott
> 
> 

Re: Generating elf kernel ?

[Scott Wood]

On Fri, 17 Sep 2010 09:58:41 +0800
"tiejun.chen" <tiejun.chen@windriver.com> wrote:

> Scott Wood wrote:
> > The guest OS *is* the same as native Linux, as far as TLB handling is
> > concerned.
> 
> Looks you means the TLB exception handler should be same between the native and
> the guest OS. Right?

Yes.

> Here I assume we're talking about e500mc since as far as I know for Freescale
> only e500mc is designed to support virtual machine based on ISA 2.0.6.

Yes, though there's nothing preventing virtualization on cores without
category E.HV (KVM supports this) -- it's just slower.

> I also know all TLB exceptions can direct to the guest OS when we enable
> EPCR[DTLBGS|ITLBGS|DSIGS|ISIGS]. But some TLB instructions (i.e. tlbwe )are the
> privileged instructions. So the guest OS always trap into the hypervisor and
> then the hypervisor should complete the real action with appropriate physical
> address. 

Yes, of course.  But that's not the point.  I was just using it as a
convenient example because that's what I've recently done ELF loading
with...  There's no reason U-Boot couldn't do the same if its ELF
loader were updated to support device trees.  Currently U-Boot loads
bootwrapperless uImages to physical address zero.

And FWIW, we have run setups where our hv loads Linux to true
physical zero (with the hv living elsewhere), not just guest physical.

-Scott

Re: Generating elf kernel ?

[tiejun.chen]

Scott Wood wrote:
> On Fri, 17 Sep 2010 09:58:41 +0800
> "tiejun.chen" <tiejun.chen@windriver.com> wrote:
> 
>> Scott Wood wrote:
>>> The guest OS *is* the same as native Linux, as far as TLB handling is
>>> concerned.
>> Looks you means the TLB exception handler should be same between the native and
>> the guest OS. Right?
> 
> Yes.

I don't think so. The HY should assist the guest OS on MMU since I already point
the guest OS have no authority to create a real TLB directly as I previously said.

> 
>> Here I assume we're talking about e500mc since as far as I know for Freescale
>> only e500mc is designed to support virtual machine based on ISA 2.0.6.
> 
> Yes, though there's nothing preventing virtualization on cores without
> category E.HV (KVM supports this) -- it's just slower.

Absolutely.

> 
>> I also know all TLB exceptions can direct to the guest OS when we enable
>> EPCR[DTLBGS|ITLBGS|DSIGS|ISIGS]. But some TLB instructions (i.e. tlbwe )are the
>> privileged instructions. So the guest OS always trap into the hypervisor and
>> then the hypervisor should complete the real action with appropriate physical
>> address. 
> 
> Yes, of course.  But that's not the point.  I was just using it as a
> convenient example because that's what I've recently done ELF loading
> with...  There's no reason U-Boot couldn't do the same if its ELF
> loader were updated to support device trees.  Currently U-Boot loads
> bootwrapperless uImages to physical address zero.

I never doubt the U-boot can do this for uImage. But I think we're always
talking about vmlinux, a bare Image.

Here you already assume so many conditions for vmlinux before we were
discussing. Such as bootwrapperlee uImage, its ELF loader can update/support
dtb, the HY... I think this is just why I say we cannot boot vmlinux based on
common boot loader if only change entry point of vmlinux.

> 
> And FWIW, we have run setups where our hv loads Linux to true
> physical zero (with the hv living elsewhere), not just guest physical.

That's true. The HY should be allowed to access any address.

Best Regards
Tiejun

> 
> -Scott
> 
> 

Re: Generating elf kernel ?

[Scott Wood]

On Sun, 19 Sep 2010 09:40:15 +0800
"tiejun.chen" <tiejun.chen@windriver.com> wrote:

> Scott Wood wrote:
> > On Fri, 17 Sep 2010 09:58:41 +0800
> > "tiejun.chen" <tiejun.chen@windriver.com> wrote:
> > 
> >> Scott Wood wrote:
> >>> The guest OS *is* the same as native Linux, as far as TLB handling is
> >>> concerned.
> >> Looks you means the TLB exception handler should be same between the native and
> >> the guest OS. Right?
> > 
> > Yes.
> 
> I don't think so. The HY should assist the guest OS on MMU since I already point
> the guest OS have no authority to create a real TLB directly as I previously said.

Of course the hypervisor assists, when a trap is taken.  That doesn't
mean the code is any different in the guest.

> > Yes, of course.  But that's not the point.  I was just using it as a
> > convenient example because that's what I've recently done ELF loading
> > with...  There's no reason U-Boot couldn't do the same if its ELF
> > loader were updated to support device trees.  Currently U-Boot loads
> > bootwrapperless uImages to physical address zero.
> 
> I never doubt the U-boot can do this for uImage. But I think we're always
> talking about vmlinux, a bare Image.

uImage is pretty much a bare image.  It just has a header with a
checksum and some info like OS/architecture, kernel version, build
date, etc.

There would be *no* problem doing this with vmlinux in U-Boot if
someone put in the code to pass a device tree.

-Scott

RE: Generating elf kernel ?

[Chen, Tiejun]

> -----Original Message-----
> From: Scott Wood [mailto:scottwood@freescale.com]=20
> Sent: Monday, September 20, 2010 11:44 PM
> To: Chen, Tiejun
> Cc: linuxppc-dev@lists.ozlabs.org; Guillaume Dargaud
> Subject: Re: Generating elf kernel ?
>=20
> On Sun, 19 Sep 2010 09:40:15 +0800
> "tiejun.chen" <tiejun.chen@windriver.com> wrote:
>=20
> > Scott Wood wrote:
> > > On Fri, 17 Sep 2010 09:58:41 +0800
> > > "tiejun.chen" <tiejun.chen@windriver.com> wrote:
> > >=20
> > >> Scott Wood wrote:
> > >>> The guest OS *is* the same as native Linux, as far as=20
> TLB handling=20
> > >>> is concerned.
> > >> Looks you means the TLB exception handler should be same between=20
> > >> the native and the guest OS. Right?
> > >=20
> > > Yes.
> >=20
> > I don't think so. The HY should assist the guest OS on MMU since I=20
> > already point the guest OS have no authority to create a=20
> real TLB directly as I previously said.
>=20
> Of course the hypervisor assists, when a trap is taken.  That=20
> doesn't mean the code is any different in the guest.

This should be depend on the hypervisor design implementation. I think
your=20
option should be based on the Freescale hypervisor.

>=20
> > > Yes, of course.  But that's not the point.  I was just=20
> using it as a=20
> > > convenient example because that's what I've recently done ELF=20
> > > loading with...  There's no reason U-Boot couldn't do the same if=20
> > > its ELF loader were updated to support device trees.  Currently=20
> > > U-Boot loads bootwrapperless uImages to physical address zero.
> >=20
> > I never doubt the U-boot can do this for uImage. But I think we're=20
> > always talking about vmlinux, a bare Image.
>=20
> uImage is pretty much a bare image.  It just has a header=20
> with a checksum and some info like OS/architecture, kernel=20
> version, build date, etc.

Yes. But it also inlcude load address and entry point used to u-boot.

>=20
> There would be *no* problem doing this with vmlinux in U-Boot=20
> if someone put in the code to pass a device tree.

This is just I always emphasize previously.

Cheers
Tiejun

>=20
> -Scott
>=20
>=20

Re: Generating elf kernel ?

[Scott Wood]

On Tue, 21 Sep 2010 03:00:40 +0200
"Chen, Tiejun" <Tiejun.Chen@windriver.com> wrote:

> This should be depend on the hypervisor design implementation. I think
> your 
> option should be based on the Freescale hypervisor.

Again, I was giving an example, about ELF loading.  I was not making any
claims about what all hypervisors do. :-P

-Scott

RE: Generating elf kernel ?

[Chen, Tiejun]

> -----Original Message-----
> From: Scott Wood [mailto:scottwood@freescale.com]=20
> Sent: Wednesday, September 22, 2010 1:00 AM
> To: Chen, Tiejun
> Cc: linuxppc-dev@lists.ozlabs.org; Guillaume Dargaud
> Subject: Re: Generating elf kernel ?
>=20
> On Tue, 21 Sep 2010 03:00:40 +0200
> "Chen, Tiejun" <Tiejun.Chen@windriver.com> wrote:
>=20
> > This should be depend on the hypervisor design=20
> implementation. I think=20
> > your option should be based on the Freescale hypervisor.
>=20
> Again, I was giving an example, about ELF loading.  I was not=20
> making any claims about what all hypervisors do. :-P
>=20

When I'm free I'd like to track the Freescale hypervisor codes.=20

Thanks
Tiejun

> -Scott
>=20
>=20