[Qemu-devel] svn 6658 broke powerpc.

[Qemu-devel] svn 6658 broke powerpc.

[Rob Landley]

Up through svn 6657, I could boot a powerpc kernel with -kernel.  That commit 
changed it so now it says:
invalid/unsupported opcode: 00 - 00 - 00 (00000000) fff18f00 1
invalid/unsupported opcode: 00 - 00 - 00 (00000000) fff18f04 1
invalid/unsupported opcode: 00 - 0c - 06 (00009198) 00009214 0

And dies.

You can grab a test kernel from http://landley.net/zImage-powerpc and try 
booting it (out of the qemu source directory, this is assuming you've built it 
but haven't installed it yet) via:

ppc-softmmu/qemu-system-ppc -kernel zImage-powerpc \
  -append "console=ttyS0 panic=1" -nographic -no-reboot -L pc-bios

With svn 6657, it works.  (You get kernel boot messages up until it panics and 
dies because it can't find the root filesystem).  With 6658 it dies 
immediately with the above error message.

Unfortunately, this means that the 0.10.0 release doesn't work for powerpc for 
me, but svn a couple days _before_ the release did.

Rob

Re: [Qemu-devel] svn 6658 broke powerpc.

[Alexander Graf]

On 18.03.2009, at 00:57, Rob Landley wrote:

> Up through svn 6657, I could boot a powerpc kernel with -kernel.   
> That commit
> changed it so now it says:
> invalid/unsupported opcode: 00 - 00 - 00 (00000000) fff18f00 1
> invalid/unsupported opcode: 00 - 00 - 00 (00000000) fff18f04 1
> invalid/unsupported opcode: 00 - 0c - 06 (00009198) 00009214 0
>
> And dies.
>
> You can grab a test kernel from http://landley.net/zImage-powerpc  
> and try
> booting it (out of the qemu source directory, this is assuming  
> you've built it
> but haven't installed it yet) via:
>
> ppc-softmmu/qemu-system-ppc -kernel zImage-powerpc \
>  -append "console=ttyS0 panic=1" -nographic -no-reboot -L pc-bios
>
> With svn 6657, it works.  (You get kernel boot messages up until it  
> panics and
> dies because it can't find the root filesystem).  With 6658 it dies
> immediately with the above error message.
>
> Unfortunately, this means that the 0.10.0 release doesn't work for  
> powerpc for
> me, but svn a couple days _before_ the release did.

That specific commit shouldn't have changed anything with respect to  
ppc32 emulation. The one where your command broken is the openBIOS  
update.


Please try again without -nographic.

Alex

Re: [Qemu-devel] svn 6658 broke powerpc.

[Rob Landley]

On Wednesday 18 March 2009 03:41:05 Alexander Graf wrote:
> On 18.03.2009, at 00:57, Rob Landley wrote:
> > Up through svn 6657, I could boot a powerpc kernel with -kernel.
> > That commit
> > changed it so now it says:
> > invalid/unsupported opcode: 00 - 00 - 00 (00000000) fff18f00 1
> > invalid/unsupported opcode: 00 - 00 - 00 (00000000) fff18f04 1
> > invalid/unsupported opcode: 00 - 0c - 06 (00009198) 00009214 0
> >
> > And dies.
> >
> > You can grab a test kernel from http://landley.net/zImage-powerpc
> > and try
> > booting it (out of the qemu source directory, this is assuming
> > you've built it
> > but haven't installed it yet) via:
> >
> > ppc-softmmu/qemu-system-ppc -kernel zImage-powerpc \
> >  -append "console=ttyS0 panic=1" -nographic -no-reboot -L pc-bios
> >
> > With svn 6657, it works.  (You get kernel boot messages up until it
> > panics and
> > dies because it can't find the root filesystem).  With 6658 it dies
> > immediately with the above error message.
> >
> > Unfortunately, this means that the 0.10.0 release doesn't work for
> > powerpc for
> > me, but svn a couple days _before_ the release did.
>
> That specific commit shouldn't have changed anything with respect to
> ppc32 emulation. The one where your command broken is the openBIOS
> update.

The commit I pointed to is the openbios update, yes.

> Please try again without -nographic.

It does indeed work without nographic.  (It doesn't do anything _useful_ for 
me without nographic, since I'm scripting the emulated kernel's behavior 
through stdin and stdout, but allowing it to pop up an SDL window does make it 
out of openbios and into the kernel.)

> Alex

Thanks,

Rob

Re: [Qemu-devel] svn 6658 broke powerpc.

[Blue Swirl]

On 3/18/09, Rob Landley <rob@landley.net> wrote:
> On Wednesday 18 March 2009 03:41:05 Alexander Graf wrote:
>  > On 18.03.2009, at 00:57, Rob Landley wrote:
>  > > Up through svn 6657, I could boot a powerpc kernel with -kernel.
>  > > That commit
>  > > changed it so now it says:
>  > > invalid/unsupported opcode: 00 - 00 - 00 (00000000) fff18f00 1
>  > > invalid/unsupported opcode: 00 - 00 - 00 (00000000) fff18f04 1
>  > > invalid/unsupported opcode: 00 - 0c - 06 (00009198) 00009214 0
>  > >
>  > > And dies.
>  > >
>  > > You can grab a test kernel from http://landley.net/zImage-powerpc
>  > > and try
>  > > booting it (out of the qemu source directory, this is assuming
>  > > you've built it
>  > > but haven't installed it yet) via:
>  > >
>  > > ppc-softmmu/qemu-system-ppc -kernel zImage-powerpc \
>  > >  -append "console=ttyS0 panic=1" -nographic -no-reboot -L pc-bios
>  > >
>  > > With svn 6657, it works.  (You get kernel boot messages up until it
>  > > panics and
>  > > dies because it can't find the root filesystem).  With 6658 it dies
>  > > immediately with the above error message.
>  > >
>  > > Unfortunately, this means that the 0.10.0 release doesn't work for
>  > > powerpc for
>  > > me, but svn a couple days _before_ the release did.
>  >
>  > That specific commit shouldn't have changed anything with respect to
>  > ppc32 emulation. The one where your command broken is the openBIOS
>  > update.
>
>
> The commit I pointed to is the openbios update, yes.
>
>
>  > Please try again without -nographic.
>
>
> It does indeed work without nographic.  (It doesn't do anything _useful_ for
>  me without nographic, since I'm scripting the emulated kernel's behavior
>  through stdin and stdout, but allowing it to pop up an SDL window does make it
>  out of openbios and into the kernel.)

The kernel makes the equivalent of the following calls to OF interface:
finddevice("/") = 0x11d5c
finddevice("/chosen") = 0x1197c
finddevice("/openprom") = 0x11b3c
getprop(0x11b3c, "model", 0x78efeb0, 0x40) = 0xf
getprop(0x11d5c, "stdout", 0x78efea0, 0x4) = 0x4
instance-to-path(0x86ea0, 0x12ad0dc, 0xff) where it crashes because
memmove overwrites all memory.

But where does this 0x86ea0 come from?

Re: [Qemu-devel] svn 6658 broke powerpc.

[Rob Landley]

[-- Attachment #1: Type: text/plain, Size: 3908 bytes --]

On Wednesday 18 March 2009 14:11:19 Blue Swirl wrote:
> On 3/18/09, Rob Landley <rob@landley.net> wrote:
> > On Wednesday 18 March 2009 03:41:05 Alexander Graf wrote:
> >  > On 18.03.2009, at 00:57, Rob Landley wrote:
> >  > > Up through svn 6657, I could boot a powerpc kernel with -kernel.
> >  > > That commit
> >  > > changed it so now it says:
> >  > > invalid/unsupported opcode: 00 - 00 - 00 (00000000) fff18f00 1
> >  > > invalid/unsupported opcode: 00 - 00 - 00 (00000000) fff18f04 1
> >  > > invalid/unsupported opcode: 00 - 0c - 06 (00009198) 00009214 0
> >  > >
> >  > > And dies.
> >  > >
> >  > > You can grab a test kernel from http://landley.net/zImage-powerpc
> >  > > and try
> >  > > booting it (out of the qemu source directory, this is assuming
> >  > > you've built it
> >  > > but haven't installed it yet) via:
> >  > >
> >  > > ppc-softmmu/qemu-system-ppc -kernel zImage-powerpc \
> >  > >  -append "console=ttyS0 panic=1" -nographic -no-reboot -L pc-bios
> >  > >
> >  > > With svn 6657, it works.  (You get kernel boot messages up until it
> >  > > panics and
> >  > > dies because it can't find the root filesystem).  With 6658 it dies
> >  > > immediately with the above error message.
> >  > >
> >  > > Unfortunately, this means that the 0.10.0 release doesn't work for
> >  > > powerpc for
> >  > > me, but svn a couple days _before_ the release did.
> >  >
> >  > That specific commit shouldn't have changed anything with respect to
> >  > ppc32 emulation. The one where your command broken is the openBIOS
> >  > update.
> >
> > The commit I pointed to is the openbios update, yes.
> >
> >  > Please try again without -nographic.
> >
> > It does indeed work without nographic.  (It doesn't do anything _useful_
> > for me without nographic, since I'm scripting the emulated kernel's
> > behavior through stdin and stdout, but allowing it to pop up an SDL
> > window does make it out of openbios and into the kernel.)
>
> The kernel makes the equivalent of the following calls to OF interface:
> finddevice("/") = 0x11d5c
> finddevice("/chosen") = 0x1197c
> finddevice("/openprom") = 0x11b3c
> getprop(0x11b3c, "model", 0x78efeb0, 0x40) = 0xf
> getprop(0x11d5c, "stdout", 0x78efea0, 0x4) = 0x4
> instance-to-path(0x86ea0, 0x12ad0dc, 0xff) where it crashes because
> memmove overwrites all memory.
>
> But where does this 0x86ea0 come from?

No idea, but it worked with the previous openbios, and without --nographic.  
This is a 2.6.28.8 kernel built with the attached .config.

By the way, while binary searching the openbios repository to figure out 
exactly what commit between 450 and 463 actually caused it to stop working, 
and I hit a fun little OpenBios hiccup in the top level Makefile of current 
OpenBios svn:

build:
    @printf "Building..."
    @for dir in $(ODIRS); do \
        $(MAKE) -C $$dir > $$dir/build.log 2>&1 && echo "ok." || \
        ( echo "error:"; tail -15 $$$dir/build.log; exit 1 ) \
    done

You have one too many $ before dir/build.log in the error message, so the 
error message you get is

  Building...error:
  tail: cannot open `/build.log' for reading: No such file or directory
  make: *** [build] Error 1

Which took about 15 minutes of head scratching for a newbie like me to track 
down.  (The actual problem was that your config/examples/cross-ppc_rules.xml 
hardwires TARGET=powerpc-linux-gnu- and my cross compiler just uses powerpc- 
as the prefix, and overriding TARGET on the make command line doesn't work 
because you use recursive make, and you aren't doing the ?= conditional 
assignments that won't overwrite existing environment variable values.  I more 
or less expected it and was running the thing the first time so it would tell 
me what cross compiler name it expected when it died unable to find it.  Easy 
enough to fix by just editing the darn file, but a mention of it in the README 
wouldn't go amiss...)

Rob

[-- Attachment #2: config-linux --]
[-- Type: text/plain, Size: 22565 bytes --]

#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.28.8
# Wed Mar 18 08:24:13 2009
#
# CONFIG_PPC64 is not set

#
# Processor support
#
CONFIG_6xx=y
# CONFIG_PPC_85xx is not set
# CONFIG_PPC_8xx is not set
# CONFIG_40x is not set
# CONFIG_44x is not set
# CONFIG_E200 is not set
CONFIG_PPC_FPU=y
CONFIG_ALTIVEC=y
CONFIG_PPC_STD_MMU=y
CONFIG_PPC_STD_MMU_32=y
# CONFIG_PPC_MM_SLICES is not set
# CONFIG_SMP is not set
CONFIG_PPC32=y
CONFIG_WORD_SIZE=32
# CONFIG_ARCH_PHYS_ADDR_T_64BIT is not set
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_HAVE_SETUP_PER_CPU_AREA is not set
CONFIG_IRQ_PER_CPU=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_ARCH_HAS_ILOG2_U32=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_GENERIC_FIND_NEXT_BIT=y
# CONFIG_ARCH_NO_VIRT_TO_BUS is not set
CONFIG_PPC=y
CONFIG_EARLY_PRINTK=y
CONFIG_GENERIC_NVRAM=y
CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_PPC_OF=y
CONFIG_OF=y
# CONFIG_PPC_UDBG_16550 is not set
# CONFIG_GENERIC_TBSYNC is not set
CONFIG_AUDIT_ARCH=y
CONFIG_GENERIC_BUG=y
# CONFIG_DEFAULT_UIMAGE is not set
CONFIG_HIBERNATE_32=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
# CONFIG_PPC_DCR_NATIVE is not set
# CONFIG_PPC_DCR_MMIO is not set
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"

#
# General setup
#
CONFIG_EXPERIMENTAL=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
# CONFIG_POSIX_MQUEUE is not set
# CONFIG_BSD_PROCESS_ACCT is not set
# CONFIG_TASKSTATS is not set
# CONFIG_AUDIT is not set
# CONFIG_IKCONFIG is not set
CONFIG_LOG_BUF_SHIFT=17
# CONFIG_CGROUPS is not set
# CONFIG_GROUP_SCHED is not set
CONFIG_SYSFS_DEPRECATED=y
CONFIG_SYSFS_DEPRECATED_V2=y
# CONFIG_RELAY is not set
CONFIG_NAMESPACES=y
# CONFIG_UTS_NS is not set
# CONFIG_IPC_NS is not set
# CONFIG_USER_NS is not set
# CONFIG_PID_NS is not set
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SYSCTL=y
# CONFIG_EMBEDDED is not set
CONFIG_SYSCTL_SYSCALL=y
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_COMPAT_BRK=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_ANON_INODES=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_AIO=y
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_PCI_QUIRKS=y
CONFIG_SLAB=y
# CONFIG_SLUB is not set
# CONFIG_SLOB is not set
# CONFIG_PROFILING is not set
# CONFIG_MARKERS is not set
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_GENERIC_DMA_COHERENT is not set
CONFIG_SLABINFO=y
CONFIG_RT_MUTEXES=y
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0
# CONFIG_MODULES is not set
CONFIG_BLOCK=y
# CONFIG_LBD is not set
# CONFIG_BLK_DEV_IO_TRACE is not set
# CONFIG_LSF is not set
# CONFIG_BLK_DEV_BSG is not set
# CONFIG_BLK_DEV_INTEGRITY is not set

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
# CONFIG_IOSCHED_AS is not set
# CONFIG_IOSCHED_DEADLINE is not set
# CONFIG_IOSCHED_CFQ is not set
# CONFIG_DEFAULT_AS is not set
# CONFIG_DEFAULT_DEADLINE is not set
# CONFIG_DEFAULT_CFQ is not set
CONFIG_DEFAULT_NOOP=y
CONFIG_DEFAULT_IOSCHED="noop"
CONFIG_CLASSIC_RCU=y
# CONFIG_FREEZER is not set

#
# Platform support
#
CONFIG_PPC_MULTIPLATFORM=y
CONFIG_CLASSIC32=y
# CONFIG_PPC_CHRP is not set
# CONFIG_MPC5121_ADS is not set
# CONFIG_MPC5121_GENERIC is not set
# CONFIG_PPC_MPC52xx is not set
CONFIG_PPC_PMAC=y
# CONFIG_PPC_CELL is not set
# CONFIG_PPC_CELL_NATIVE is not set
# CONFIG_PPC_82xx is not set
# CONFIG_PQ2ADS is not set
# CONFIG_PPC_83xx is not set
# CONFIG_PPC_86xx is not set
# CONFIG_EMBEDDED6xx is not set
CONFIG_PPC_NATIVE=y
# CONFIG_IPIC is not set
CONFIG_MPIC=y
# CONFIG_MPIC_WEIRD is not set
# CONFIG_PPC_I8259 is not set
# CONFIG_PPC_RTAS is not set
# CONFIG_MMIO_NVRAM is not set
CONFIG_PPC_MPC106=y
# CONFIG_PPC_970_NAP is not set
# CONFIG_PPC_INDIRECT_IO is not set
# CONFIG_GENERIC_IOMAP is not set
# CONFIG_CPU_FREQ is not set
CONFIG_PPC601_SYNC_FIX=y
# CONFIG_TAU is not set
# CONFIG_FSL_ULI1575 is not set

#
# Kernel options
#
CONFIG_HIGHMEM=y
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ=y
# CONFIG_HIGH_RES_TIMERS is not set
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
# CONFIG_HZ_100 is not set
CONFIG_HZ_250=y
# CONFIG_HZ_300 is not set
# CONFIG_HZ_1000 is not set
CONFIG_HZ=250
# CONFIG_SCHED_HRTICK is not set
CONFIG_PREEMPT_NONE=y
# CONFIG_PREEMPT_VOLUNTARY is not set
# CONFIG_PREEMPT is not set
CONFIG_BINFMT_ELF=y
# CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
# CONFIG_HAVE_AOUT is not set
# CONFIG_BINFMT_MISC is not set
# CONFIG_IOMMU_HELPER is not set
CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y
CONFIG_ARCH_HAS_WALK_MEMORY=y
CONFIG_ARCH_ENABLE_MEMORY_HOTREMOVE=y
# CONFIG_KEXEC is not set
CONFIG_ARCH_FLATMEM_ENABLE=y
CONFIG_ARCH_POPULATES_NODE_MAP=y
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_FLATMEM_MANUAL=y
# CONFIG_DISCONTIGMEM_MANUAL is not set
# CONFIG_SPARSEMEM_MANUAL is not set
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
CONFIG_PAGEFLAGS_EXTENDED=y
CONFIG_SPLIT_PTLOCK_CPUS=4
# CONFIG_MIGRATION is not set
# CONFIG_RESOURCES_64BIT is not set
# CONFIG_PHYS_ADDR_T_64BIT is not set
CONFIG_ZONE_DMA_FLAG=1
CONFIG_BOUNCE=y
CONFIG_VIRT_TO_BUS=y
CONFIG_UNEVICTABLE_LRU=y
CONFIG_FORCE_MAX_ZONEORDER=11
CONFIG_PROC_DEVICETREE=y
# CONFIG_CMDLINE_BOOL is not set
CONFIG_EXTRA_TARGETS=""
CONFIG_ARCH_WANTS_FREEZER_CONTROL=y
CONFIG_PM=y
# CONFIG_PM_DEBUG is not set
# CONFIG_SUSPEND is not set
# CONFIG_HIBERNATION is not set
CONFIG_SECCOMP=y
CONFIG_ISA_DMA_API=y

#
# Bus options
#
CONFIG_ZONE_DMA=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_PPC_INDIRECT_PCI=y
CONFIG_PCI=y
CONFIG_PCI_DOMAINS=y
CONFIG_PCI_SYSCALL=y
# CONFIG_PCIEPORTBUS is not set
CONFIG_ARCH_SUPPORTS_MSI=y
# CONFIG_PCI_MSI is not set
# CONFIG_PCI_LEGACY is not set
CONFIG_PCCARD=y
# CONFIG_PCMCIA_DEBUG is not set
CONFIG_PCMCIA=y
CONFIG_PCMCIA_LOAD_CIS=y
CONFIG_PCMCIA_IOCTL=y
CONFIG_CARDBUS=y

#
# PC-card bridges
#
CONFIG_YENTA=y
CONFIG_YENTA_O2=y
CONFIG_YENTA_RICOH=y
CONFIG_YENTA_TI=y
CONFIG_YENTA_ENE_TUNE=y
CONFIG_YENTA_TOSHIBA=y
# CONFIG_PD6729 is not set
# CONFIG_I82092 is not set
CONFIG_PCCARD_NONSTATIC=y
# CONFIG_HOTPLUG_PCI is not set
# CONFIG_HAS_RAPIDIO is not set

#
# Advanced setup
#
CONFIG_ADVANCED_OPTIONS=y
# CONFIG_LOWMEM_SIZE_BOOL is not set
CONFIG_LOWMEM_SIZE=0x30000000
# CONFIG_PAGE_OFFSET_BOOL is not set
CONFIG_PAGE_OFFSET=0xc0000000
# CONFIG_KERNEL_START_BOOL is not set
CONFIG_KERNEL_START=0xc0000000
CONFIG_PHYSICAL_START=0x00000000
# CONFIG_TASK_SIZE_BOOL is not set
CONFIG_TASK_SIZE=0xc0000000
CONFIG_NET=y

#
# Networking options
#
CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
CONFIG_UNIX=y
# CONFIG_NET_KEY is not set
CONFIG_INET=y
# CONFIG_IP_MULTICAST is not set
# CONFIG_IP_ADVANCED_ROUTER is not set
CONFIG_IP_FIB_HASH=y
# CONFIG_IP_PNP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_ARPD is not set
# CONFIG_SYN_COOKIES is not set
# CONFIG_INET_AH is not set
# CONFIG_INET_ESP is not set
# CONFIG_INET_IPCOMP is not set
# CONFIG_INET_XFRM_TUNNEL is not set
# CONFIG_INET_TUNNEL is not set
# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
# CONFIG_INET_XFRM_MODE_TUNNEL is not set
# CONFIG_INET_XFRM_MODE_BEET is not set
CONFIG_INET_LRO=y
# CONFIG_INET_DIAG is not set
# CONFIG_TCP_CONG_ADVANCED is not set
CONFIG_TCP_CONG_CUBIC=y
CONFIG_DEFAULT_TCP_CONG="cubic"
# CONFIG_TCP_MD5SIG is not set
# CONFIG_IPV6 is not set
# CONFIG_NETWORK_SECMARK is not set
# CONFIG_NETFILTER is not set
# CONFIG_IP_DCCP is not set
# CONFIG_IP_SCTP is not set
# CONFIG_TIPC is not set
# CONFIG_ATM is not set
# CONFIG_BRIDGE is not set
# CONFIG_NET_DSA is not set
# CONFIG_VLAN_8021Q is not set
# CONFIG_DECNET is not set
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set
# CONFIG_NET_SCHED is not set

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_HAMRADIO is not set
# CONFIG_CAN is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
# CONFIG_AF_RXRPC is not set
# CONFIG_PHONET is not set
# CONFIG_WIRELESS is not set
# CONFIG_RFKILL is not set
# CONFIG_NET_9P is not set

#
# Device Drivers
#

#
# Generic Driver Options
#
CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
# CONFIG_STANDALONE is not set
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=y
CONFIG_FIRMWARE_IN_KERNEL=y
CONFIG_EXTRA_FIRMWARE=""
# CONFIG_SYS_HYPERVISOR is not set
CONFIG_CONNECTOR=y
CONFIG_PROC_EVENTS=y
# CONFIG_MTD is not set
CONFIG_OF_DEVICE=y
CONFIG_OF_I2C=y
# CONFIG_PARPORT is not set
CONFIG_BLK_DEV=y
# CONFIG_BLK_DEV_FD is not set
# CONFIG_MAC_FLOPPY is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_UMEM is not set
# CONFIG_BLK_DEV_COW_COMMON is not set
CONFIG_BLK_DEV_LOOP=y
# CONFIG_BLK_DEV_CRYPTOLOOP is not set
# CONFIG_BLK_DEV_NBD is not set
# CONFIG_BLK_DEV_SX8 is not set
# CONFIG_BLK_DEV_RAM is not set
# CONFIG_CDROM_PKTCDVD is not set
# CONFIG_ATA_OVER_ETH is not set
# CONFIG_BLK_DEV_HD is not set
# CONFIG_MISC_DEVICES is not set
CONFIG_HAVE_IDE=y
CONFIG_IDE=y

#
# Please see Documentation/ide/ide.txt for help/info on IDE drives
#
CONFIG_IDE_TIMINGS=y
# CONFIG_BLK_DEV_IDE_SATA is not set
CONFIG_IDE_GD=y
CONFIG_IDE_GD_ATA=y
# CONFIG_IDE_GD_ATAPI is not set
# CONFIG_BLK_DEV_IDECS is not set
# CONFIG_BLK_DEV_DELKIN is not set
# CONFIG_BLK_DEV_IDECD is not set
# CONFIG_BLK_DEV_IDETAPE is not set
# CONFIG_IDE_TASK_IOCTL is not set
# CONFIG_IDE_PROC_FS is not set

#
# IDE chipset support/bugfixes
#
# CONFIG_BLK_DEV_PLATFORM is not set
CONFIG_BLK_DEV_IDEDMA_SFF=y

#
# PCI IDE chipsets support
#
CONFIG_BLK_DEV_IDEPCI=y
# CONFIG_IDEPCI_PCIBUS_ORDER is not set
# CONFIG_BLK_DEV_OFFBOARD is not set
CONFIG_BLK_DEV_GENERIC=y
# CONFIG_BLK_DEV_OPTI621 is not set
CONFIG_BLK_DEV_IDEDMA_PCI=y
# CONFIG_BLK_DEV_AEC62XX is not set
# CONFIG_BLK_DEV_ALI15X3 is not set
# CONFIG_BLK_DEV_AMD74XX is not set
CONFIG_BLK_DEV_CMD64X=y
# CONFIG_BLK_DEV_TRIFLEX is not set
# CONFIG_BLK_DEV_CS5520 is not set
# CONFIG_BLK_DEV_CS5530 is not set
# CONFIG_BLK_DEV_HPT366 is not set
# CONFIG_BLK_DEV_JMICRON is not set
# CONFIG_BLK_DEV_SC1200 is not set
# CONFIG_BLK_DEV_PIIX is not set
# CONFIG_BLK_DEV_IT8213 is not set
# CONFIG_BLK_DEV_IT821X is not set
# CONFIG_BLK_DEV_NS87415 is not set
# CONFIG_BLK_DEV_PDC202XX_OLD is not set
# CONFIG_BLK_DEV_PDC202XX_NEW is not set
# CONFIG_BLK_DEV_SVWKS is not set
# CONFIG_BLK_DEV_SIIMAGE is not set
# CONFIG_BLK_DEV_SL82C105 is not set
# CONFIG_BLK_DEV_SLC90E66 is not set
# CONFIG_BLK_DEV_TRM290 is not set
# CONFIG_BLK_DEV_VIA82CXXX is not set
# CONFIG_BLK_DEV_TC86C001 is not set
CONFIG_BLK_DEV_IDE_PMAC=y
# CONFIG_BLK_DEV_IDE_PMAC_ATA100FIRST is not set
CONFIG_BLK_DEV_IDEDMA=y

#
# SCSI device support
#
# CONFIG_RAID_ATTRS is not set
# CONFIG_SCSI is not set
# CONFIG_SCSI_DMA is not set
# CONFIG_SCSI_NETLINK is not set
# CONFIG_ATA is not set
# CONFIG_MD is not set
# CONFIG_FUSION is not set

#
# IEEE 1394 (FireWire) support
#

#
# Enable only one of the two stacks, unless you know what you are doing
#
# CONFIG_FIREWIRE is not set
CONFIG_IEEE1394=y
CONFIG_IEEE1394_OHCI1394=y
# CONFIG_IEEE1394_PCILYNX is not set

#
# SBP-2 support (for storage devices) requires SCSI
#
CONFIG_IEEE1394_ETH1394_ROM_ENTRY=y
CONFIG_IEEE1394_ETH1394=y
CONFIG_IEEE1394_RAWIO=y
CONFIG_IEEE1394_VIDEO1394=y
CONFIG_IEEE1394_DV1394=y
# CONFIG_IEEE1394_VERBOSEDEBUG is not set
# CONFIG_I2O is not set
CONFIG_MACINTOSH_DRIVERS=y
CONFIG_ADB=y
CONFIG_ADB_CUDA=y
CONFIG_ADB_PMU=y
# CONFIG_ADB_PMU_LED is not set
# CONFIG_PMAC_APM_EMU is not set
# CONFIG_PMAC_MEDIABAY is not set
# CONFIG_INPUT_ADBHID is not set
# CONFIG_MAC_EMUMOUSEBTN is not set
# CONFIG_THERM_WINDTUNNEL is not set
# CONFIG_THERM_ADT746X is not set
# CONFIG_WINDFARM is not set
# CONFIG_ANSLCD is not set
# CONFIG_PMAC_RACKMETER is not set
CONFIG_NETDEVICES=y
# CONFIG_DUMMY is not set
# CONFIG_BONDING is not set
# CONFIG_MACVLAN is not set
# CONFIG_EQUALIZER is not set
# CONFIG_TUN is not set
# CONFIG_VETH is not set
# CONFIG_ARCNET is not set
# CONFIG_PHYLIB is not set
CONFIG_NET_ETHERNET=y
CONFIG_MII=y
CONFIG_MACE=y
# CONFIG_MACE_AAUI_PORT is not set
CONFIG_BMAC=y
CONFIG_HAPPYMEAL=y
CONFIG_SUNGEM=y
CONFIG_CASSINI=y
# CONFIG_NET_VENDOR_3COM is not set
# CONFIG_NET_TULIP is not set
# CONFIG_HP100 is not set
# CONFIG_IBM_NEW_EMAC_ZMII is not set
# CONFIG_IBM_NEW_EMAC_RGMII is not set
# CONFIG_IBM_NEW_EMAC_TAH is not set
# CONFIG_IBM_NEW_EMAC_EMAC4 is not set
# CONFIG_IBM_NEW_EMAC_NO_FLOW_CTRL is not set
# CONFIG_IBM_NEW_EMAC_MAL_CLR_ICINTSTAT is not set
# CONFIG_IBM_NEW_EMAC_MAL_COMMON_ERR is not set
CONFIG_NET_PCI=y
CONFIG_PCNET32=y
# CONFIG_AMD8111_ETH is not set
# CONFIG_ADAPTEC_STARFIRE is not set
# CONFIG_B44 is not set
# CONFIG_FORCEDETH is not set
# CONFIG_EEPRO100 is not set
# CONFIG_E100 is not set
# CONFIG_FEALNX is not set
# CONFIG_NATSEMI is not set
CONFIG_NE2K_PCI=y
CONFIG_8139CP=y
CONFIG_8139TOO=y
CONFIG_8139TOO_PIO=y
# CONFIG_8139TOO_TUNE_TWISTER is not set
# CONFIG_8139TOO_8129 is not set
# CONFIG_8139_OLD_RX_RESET is not set
# CONFIG_R6040 is not set
# CONFIG_SIS900 is not set
# CONFIG_EPIC100 is not set
# CONFIG_SUNDANCE is not set
# CONFIG_TLAN is not set
# CONFIG_VIA_RHINE is not set
# CONFIG_SC92031 is not set
CONFIG_ATL2=y
# CONFIG_NETDEV_1000 is not set
# CONFIG_NETDEV_10000 is not set
# CONFIG_TR is not set

#
# Wireless LAN
#
# CONFIG_WLAN_PRE80211 is not set
# CONFIG_WLAN_80211 is not set
# CONFIG_IWLWIFI_LEDS is not set
# CONFIG_NET_PCMCIA is not set
# CONFIG_WAN is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
# CONFIG_PPP is not set
# CONFIG_SLIP is not set
# CONFIG_NETCONSOLE is not set
# CONFIG_NETPOLL is not set
# CONFIG_NET_POLL_CONTROLLER is not set
# CONFIG_ISDN is not set
# CONFIG_PHONE is not set

#
# Input device support
#
CONFIG_INPUT=y
# CONFIG_INPUT_FF_MEMLESS is not set
# CONFIG_INPUT_POLLDEV is not set

#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
# CONFIG_INPUT_MOUSEDEV_PSAUX is not set
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
# CONFIG_INPUT_JOYDEV is not set
# CONFIG_INPUT_EVDEV is not set
# CONFIG_INPUT_EVBUG is not set

#
# Input Device Drivers
#
# CONFIG_INPUT_KEYBOARD is not set
# CONFIG_INPUT_MOUSE is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TABLET is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
# CONFIG_INPUT_MISC is not set

#
# Hardware I/O ports
#
CONFIG_SERIO=y
# CONFIG_SERIO_I8042 is not set
# CONFIG_SERIO_SERPORT is not set
# CONFIG_SERIO_PCIPS2 is not set
# CONFIG_SERIO_RAW is not set
# CONFIG_SERIO_XILINX_XPS_PS2 is not set
# CONFIG_GAMEPORT is not set

#
# Character devices
#
CONFIG_VT=y
CONFIG_CONSOLE_TRANSLATIONS=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
# CONFIG_VT_HW_CONSOLE_BINDING is not set
# CONFIG_DEVKMEM is not set
# CONFIG_SERIAL_NONSTANDARD is not set
# CONFIG_NOZOMI is not set

#
# Serial drivers
#
# CONFIG_SERIAL_8250 is not set

#
# Non-8250 serial port support
#
# CONFIG_SERIAL_UARTLITE is not set
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
CONFIG_SERIAL_PMACZILOG=y
CONFIG_SERIAL_PMACZILOG_TTYS=y
CONFIG_SERIAL_PMACZILOG_CONSOLE=y
# CONFIG_SERIAL_JSM is not set
CONFIG_UNIX98_PTYS=y
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=8
# CONFIG_IPMI_HANDLER is not set
CONFIG_HW_RANDOM=y
# CONFIG_NVRAM is not set
# CONFIG_GEN_RTC is not set
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set

#
# PCMCIA character devices
#
# CONFIG_SYNCLINK_CS is not set
# CONFIG_CARDMAN_4000 is not set
# CONFIG_CARDMAN_4040 is not set
# CONFIG_IPWIRELESS is not set
# CONFIG_RAW_DRIVER is not set
# CONFIG_TCG_TPM is not set
CONFIG_DEVPORT=y
CONFIG_I2C=y
CONFIG_I2C_BOARDINFO=y
# CONFIG_I2C_CHARDEV is not set
# CONFIG_I2C_HELPER_AUTO is not set

#
# I2C Algorithms
#
# CONFIG_I2C_ALGOBIT is not set
# CONFIG_I2C_ALGOPCF is not set
# CONFIG_I2C_ALGOPCA is not set

#
# I2C Hardware Bus support
#

#
# PC SMBus host controller drivers
#
# CONFIG_I2C_ALI1535 is not set
# CONFIG_I2C_ALI1563 is not set
# CONFIG_I2C_ALI15X3 is not set
# CONFIG_I2C_AMD756 is not set
# CONFIG_I2C_AMD8111 is not set
# CONFIG_I2C_I801 is not set
# CONFIG_I2C_ISCH is not set
# CONFIG_I2C_PIIX4 is not set
# CONFIG_I2C_NFORCE2 is not set
# CONFIG_I2C_SIS5595 is not set
# CONFIG_I2C_SIS630 is not set
# CONFIG_I2C_SIS96X is not set
# CONFIG_I2C_VIA is not set
# CONFIG_I2C_VIAPRO is not set

#
# Mac SMBus host controller drivers
#
CONFIG_I2C_POWERMAC=y

#
# I2C system bus drivers (mostly embedded / system-on-chip)
#
# CONFIG_I2C_MPC is not set
# CONFIG_I2C_OCORES is not set
# CONFIG_I2C_SIMTEC is not set

#
# External I2C/SMBus adapter drivers
#
# CONFIG_I2C_PARPORT_LIGHT is not set
# CONFIG_I2C_TAOS_EVM is not set

#
# Graphics adapter I2C/DDC channel drivers
#
# CONFIG_I2C_VOODOO3 is not set

#
# Other I2C/SMBus bus drivers
#
# CONFIG_I2C_PCA_PLATFORM is not set

#
# Miscellaneous I2C Chip support
#
# CONFIG_DS1682 is not set
# CONFIG_AT24 is not set
# CONFIG_SENSORS_EEPROM is not set
# CONFIG_SENSORS_PCF8574 is not set
# CONFIG_PCF8575 is not set
# CONFIG_SENSORS_PCA9539 is not set
# CONFIG_SENSORS_PCF8591 is not set
# CONFIG_SENSORS_MAX6875 is not set
# CONFIG_SENSORS_TSL2550 is not set
# CONFIG_I2C_DEBUG_CORE is not set
# CONFIG_I2C_DEBUG_ALGO is not set
# CONFIG_I2C_DEBUG_BUS is not set
# CONFIG_I2C_DEBUG_CHIP is not set
# CONFIG_SPI is not set
CONFIG_ARCH_WANT_OPTIONAL_GPIOLIB=y
# CONFIG_GPIOLIB is not set
# CONFIG_W1 is not set
# CONFIG_POWER_SUPPLY is not set
# CONFIG_HWMON is not set
# CONFIG_THERMAL is not set
# CONFIG_THERMAL_HWMON is not set
# CONFIG_WATCHDOG is not set
CONFIG_SSB_POSSIBLE=y

#
# Sonics Silicon Backplane
#
CONFIG_SSB=y
CONFIG_SSB_SPROM=y
CONFIG_SSB_PCIHOST_POSSIBLE=y
CONFIG_SSB_PCIHOST=y
# CONFIG_SSB_B43_PCI_BRIDGE is not set
CONFIG_SSB_PCMCIAHOST_POSSIBLE=y
CONFIG_SSB_PCMCIAHOST=y
# CONFIG_SSB_DEBUG is not set
CONFIG_SSB_DRIVER_PCICORE_POSSIBLE=y
CONFIG_SSB_DRIVER_PCICORE=y

#
# Multifunction device drivers
#
# CONFIG_MFD_CORE is not set
# CONFIG_MFD_SM501 is not set
# CONFIG_HTC_PASIC3 is not set
# CONFIG_MFD_TMIO is not set
# CONFIG_PMIC_DA903X is not set
CONFIG_MFD_WM8400=y
CONFIG_MFD_WM8350=y
CONFIG_MFD_WM8350_I2C=y
# CONFIG_REGULATOR is not set

#
# Multimedia devices
#

#
# Multimedia core support
#
# CONFIG_VIDEO_DEV is not set
# CONFIG_DVB_CORE is not set
# CONFIG_VIDEO_MEDIA is not set

#
# Multimedia drivers
#
# CONFIG_DAB is not set

#
# Graphics support
#
# CONFIG_AGP is not set
# CONFIG_DRM is not set
# CONFIG_VGASTATE is not set
# CONFIG_VIDEO_OUTPUT_CONTROL is not set
# CONFIG_FB is not set
# CONFIG_BACKLIGHT_LCD_SUPPORT is not set

#
# Display device support
#
# CONFIG_DISPLAY_SUPPORT is not set

#
# Console display driver support
#
# CONFIG_VGA_CONSOLE is not set
CONFIG_DUMMY_CONSOLE=y
# CONFIG_SOUND is not set
# CONFIG_HID_SUPPORT is not set
# CONFIG_USB_SUPPORT is not set
# CONFIG_UWB is not set
# CONFIG_MMC is not set
# CONFIG_MEMSTICK is not set
# CONFIG_NEW_LEDS is not set
# CONFIG_ACCESSIBILITY is not set
# CONFIG_INFINIBAND is not set
# CONFIG_EDAC is not set
# CONFIG_RTC_CLASS is not set
# CONFIG_DMADEVICES is not set
# CONFIG_UIO is not set
# CONFIG_STAGING is not set

#
# File systems
#
CONFIG_EXT2_FS=y
# CONFIG_EXT2_FS_XATTR is not set
# CONFIG_EXT2_FS_XIP is not set
CONFIG_EXT3_FS=y
# CONFIG_EXT3_FS_XATTR is not set
# CONFIG_EXT4_FS is not set
CONFIG_JBD=y
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
# CONFIG_FS_POSIX_ACL is not set
CONFIG_FILE_LOCKING=y
# CONFIG_XFS_FS is not set
# CONFIG_OCFS2_FS is not set
CONFIG_DNOTIFY=y
CONFIG_INOTIFY=y
CONFIG_INOTIFY_USER=y
# CONFIG_QUOTA is not set
# CONFIG_AUTOFS_FS is not set
# CONFIG_AUTOFS4_FS is not set
# CONFIG_FUSE_FS is not set

#
# CD-ROM/DVD Filesystems
#
# CONFIG_ISO9660_FS is not set
# CONFIG_UDF_FS is not set

#
# DOS/FAT/NT Filesystems
#
# CONFIG_MSDOS_FS is not set
# CONFIG_VFAT_FS is not set
# CONFIG_NTFS_FS is not set

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_PROC_SYSCTL=y
CONFIG_PROC_PAGE_MONITOR=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
# CONFIG_TMPFS_POSIX_ACL is not set
# CONFIG_HUGETLB_PAGE is not set
# CONFIG_CONFIGFS_FS is not set

#
# Miscellaneous filesystems
#
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
# CONFIG_CRAMFS is not set
# CONFIG_VXFS_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_OMFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_ROMFS_FS is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set
# CONFIG_NETWORK_FILESYSTEMS is not set

#
# Partition Types
#
# CONFIG_PARTITION_ADVANCED is not set
CONFIG_MAC_PARTITION=y
CONFIG_MSDOS_PARTITION=y
# CONFIG_NLS is not set
# CONFIG_DLM is not set

#
# Library routines
#
CONFIG_BITREVERSE=y
# CONFIG_CRC_CCITT is not set
# CONFIG_CRC16 is not set
# CONFIG_CRC_T10DIF is not set
# CONFIG_CRC_ITU_T is not set
CONFIG_CRC32=y
# CONFIG_CRC7 is not set
CONFIG_LIBCRC32C=y
CONFIG_PLIST=y
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT=y
CONFIG_HAS_DMA=y
CONFIG_HAVE_LMB=y

#
# Kernel hacking
#
# CONFIG_PRINTK_TIME is not set
# CONFIG_ENABLE_WARN_DEPRECATED is not set
# CONFIG_ENABLE_MUST_CHECK is not set
CONFIG_FRAME_WARN=1024
# CONFIG_MAGIC_SYSRQ is not set
# CONFIG_UNUSED_SYMBOLS is not set
# CONFIG_DEBUG_FS is not set
# CONFIG_HEADERS_CHECK is not set
# CONFIG_DEBUG_KERNEL is not set
CONFIG_DEBUG_BUGVERBOSE=y
CONFIG_DEBUG_MEMORY_INIT=y
# CONFIG_RCU_CPU_STALL_DETECTOR is not set
# CONFIG_LATENCYTOP is not set
# CONFIG_SYSCTL_SYSCALL_CHECK is not set
CONFIG_HAVE_FUNCTION_TRACER=y

#
# Tracers
#
# CONFIG_DYNAMIC_PRINTK_DEBUG is not set
# CONFIG_SAMPLES is not set
CONFIG_HAVE_ARCH_KGDB=y
# CONFIG_IRQSTACKS is not set
CONFIG_BOOTX_TEXT=y
# CONFIG_PPC_EARLY_DEBUG is not set

#
# Security options
#
# CONFIG_KEYS is not set
# CONFIG_SECURITY is not set
# CONFIG_SECURITYFS is not set
# CONFIG_SECURITY_FILE_CAPABILITIES is not set
# CONFIG_CRYPTO is not set
# CONFIG_PPC_CLOCK is not set
# CONFIG_VIRTUALIZATION is not set

Re: [Qemu-devel] svn 6658 broke powerpc.

[Blue Swirl]

On 3/19/09, Rob Landley <rob@landley.net> wrote:
> On Wednesday 18 March 2009 14:11:19 Blue Swirl wrote:
>  > On 3/18/09, Rob Landley <rob@landley.net> wrote:
>  > > On Wednesday 18 March 2009 03:41:05 Alexander Graf wrote:
>  > >  > On 18.03.2009, at 00:57, Rob Landley wrote:
>  > >  > > Up through svn 6657, I could boot a powerpc kernel with -kernel.
>  > >  > > That commit
>  > >  > > changed it so now it says:
>  > >  > > invalid/unsupported opcode: 00 - 00 - 00 (00000000) fff18f00 1
>  > >  > > invalid/unsupported opcode: 00 - 00 - 00 (00000000) fff18f04 1
>  > >  > > invalid/unsupported opcode: 00 - 0c - 06 (00009198) 00009214 0
>  > >  > >
>  > >  > > And dies.
>  > >  > >
>  > >  > > You can grab a test kernel from http://landley.net/zImage-powerpc
>  > >  > > and try
>  > >  > > booting it (out of the qemu source directory, this is assuming
>  > >  > > you've built it
>  > >  > > but haven't installed it yet) via:
>  > >  > >
>  > >  > > ppc-softmmu/qemu-system-ppc -kernel zImage-powerpc \
>  > >  > >  -append "console=ttyS0 panic=1" -nographic -no-reboot -L pc-bios
>  > >  > >
>  > >  > > With svn 6657, it works.  (You get kernel boot messages up until it
>  > >  > > panics and
>  > >  > > dies because it can't find the root filesystem).  With 6658 it dies
>  > >  > > immediately with the above error message.
>  > >  > >
>  > >  > > Unfortunately, this means that the 0.10.0 release doesn't work for
>  > >  > > powerpc for
>  > >  > > me, but svn a couple days _before_ the release did.
>  > >  >
>  > >  > That specific commit shouldn't have changed anything with respect to
>  > >  > ppc32 emulation. The one where your command broken is the openBIOS
>  > >  > update.
>  > >
>  > > The commit I pointed to is the openbios update, yes.
>  > >
>  > >  > Please try again without -nographic.
>  > >
>  > > It does indeed work without nographic.  (It doesn't do anything _useful_
>  > > for me without nographic, since I'm scripting the emulated kernel's
>  > > behavior through stdin and stdout, but allowing it to pop up an SDL
>  > > window does make it out of openbios and into the kernel.)
>  >
>  > The kernel makes the equivalent of the following calls to OF interface:
>  > finddevice("/") = 0x11d5c
>  > finddevice("/chosen") = 0x1197c
>  > finddevice("/openprom") = 0x11b3c
>  > getprop(0x11b3c, "model", 0x78efeb0, 0x40) = 0xf
>  > getprop(0x11d5c, "stdout", 0x78efea0, 0x4) = 0x4
>  > instance-to-path(0x86ea0, 0x12ad0dc, 0xff) where it crashes because
>  > memmove overwrites all memory.
>  >
>  > But where does this 0x86ea0 come from?
>
>
> No idea, but it worked with the previous openbios, and without --nographic.
>  This is a 2.6.28.8 kernel built with the attached .config.
>
>  By the way, while binary searching the openbios repository to figure out
>  exactly what commit between 450 and 463 actually caused it to stop working,
>  and I hit a fun little OpenBios hiccup in the top level Makefile of current
>  OpenBios svn:
>
>  build:
>     @printf "Building..."
>     @for dir in $(ODIRS); do \
>         $(MAKE) -C $$dir > $$dir/build.log 2>&1 && echo "ok." || \
>         ( echo "error:"; tail -15 $$$dir/build.log; exit 1 ) \
>     done
>
>  You have one too many $ before dir/build.log in the error message, so the
>  error message you get is
>
>   Building...error:
>   tail: cannot open `/build.log' for reading: No such file or directory
>   make: *** [build] Error 1

I must always have used build-verbose. Should be fixed soon.

>  Which took about 15 minutes of head scratching for a newbie like me to track
>  down.  (The actual problem was that your config/examples/cross-ppc_rules.xml
>  hardwires TARGET=powerpc-linux-gnu- and my cross compiler just uses powerpc-
>  as the prefix, and overriding TARGET on the make command line doesn't work
>  because you use recursive make, and you aren't doing the ?= conditional
>  assignments that won't overwrite existing environment variable values.  I more
>  or less expected it and was running the thing the first time so it would tell
>  me what cross compiler name it expected when it died unable to find it.  Easy
>  enough to fix by just editing the darn file, but a mention of it in the README
>  wouldn't go amiss...)

But my tools also use different prefix, powerpc-elf-
(powerpc-unknown-elf). I compile using:

make build-verbose TARGET=powerpc-elf-

without problems.

About the OpenBIOS problem, I've done further debugging. The crash can
be reproduced with (-nographic -prom-env auto-boot?=false):
0 > cd /chosen  ok
0 > .properties
name                      "chosen"
stdin                     86904
stdout                    86a08
memory                    86da0
mmu                       867e8
display                   86660
nvram                     86750
rtc                       86d3c
 ok
0 > 86904 get-instance-path  type invalid/unsupported opcode: 00 - 00
- 00 (00000000) fff18f04 1
invalid/unsupported opcode: 00 - 00 - 00 (00000000) fff18f08 1
invalid bits: 00400000 for opcode: 0b - 19 - 15 (2d746572) 00009230

But other nodes crash too:
0 >  86da0  get-instance-path  type /memory@0 ok
0 > 86660  get-instance-path  type /pci@80000000/QEMU,VGA@1 ok
0 > 86750  get-instance-path  type invalid/unsupported opcode: 00 - 00
- 00 (00000000) fff18f04 1
invalid/unsupported opcode: 00 - 00 - 00 (00000000) fff18f08 1
invalid bits: 00400000 for opcode: 0b - 19 - 15 (2d746572) 00009230

0 > 86d3c  get-instance-path  type invalid/unsupported opcode: 00 - 00
- 00 (00000000) fff18f04 1
invalid/unsupported opcode: 00 - 00 - 00 (00000000) fff18f08 1
invalid bits: 00400000 for opcode: 0b - 19 - 15 (2d746572) 00009230

Sparc32 doesn't crash:
0 > cd /chosen  ok
0 > .properties
name                      "chosen"
stdin                     ffda1824
stdout                    ffda18c0
memory                    ffda1a88
mmu                       0
screen                    ffda1a28
 ok
0 > ffda1824 get-instance-path type /obio/zs@0,100000:a ok
0 > ffda18c0 get-instance-path type /obio/zs@0,100000:a ok
0 > ffda1a28 get-instance-path type
/iommu@0,10000000/sbus@0,10001000/SUNW,tcx@3,800000 ok
0 > ffda1a88 get-instance-path type /memory@0,0 ok

Re: [Qemu-devel] svn 6658 broke powerpc.

[Rob Landley]

On Thursday 19 March 2009 12:48:09 Blue Swirl wrote:
> On 3/19/09, Rob Landley <rob@landley.net> wrote:
> > On Wednesday 18 March 2009 14:11:19 Blue Swirl wrote:
> >  > On 3/18/09, Rob Landley <rob@landley.net> wrote:
> >  > > On Wednesday 18 March 2009 03:41:05 Alexander Graf wrote:
> >  > >  > On 18.03.2009, at 00:57, Rob Landley wrote:
> >  > >  > > Up through svn 6657, I could boot a powerpc kernel with
> >  > >  > > -kernel. That commit
> >  > >  > > changed it so now it says:
> >  > >  > > invalid/unsupported opcode: 00 - 00 - 00 (00000000) fff18f00 1
> >  > >  > > invalid/unsupported opcode: 00 - 00 - 00 (00000000) fff18f04 1
> >  > >  > > invalid/unsupported opcode: 00 - 0c - 06 (00009198) 00009214 0
> >  > >  > >
> >  > >  > > And dies.
> >  > >  > >
> >  > >  > > You can grab a test kernel from
> >  > >  > > http://landley.net/zImage-powerpc and try
> >  > >  > > booting it (out of the qemu source directory, this is assuming
> >  > >  > > you've built it
> >  > >  > > but haven't installed it yet) via:
> >  > >  > >
> >  > >  > > ppc-softmmu/qemu-system-ppc -kernel zImage-powerpc \
> >  > >  > >  -append "console=ttyS0 panic=1" -nographic -no-reboot -L
> >  > >  > > pc-bios
> >  > >  > >
> >  > >  > > With svn 6657, it works.  (You get kernel boot messages up
> >  > >  > > until it panics and
> >  > >  > > dies because it can't find the root filesystem).  With 6658 it
> >  > >  > > dies immediately with the above error message.
> >  > >  > >
> >  > >  > > Unfortunately, this means that the 0.10.0 release doesn't work
> >  > >  > > for powerpc for
> >  > >  > > me, but svn a couple days _before_ the release did.
> >  > >  >
> >  > >  > That specific commit shouldn't have changed anything with respect
> >  > >  > to ppc32 emulation. The one where your command broken is the
> >  > >  > openBIOS update.
> >  > >
> >  > > The commit I pointed to is the openbios update, yes.
> >  > >
> >  > >  > Please try again without -nographic.
> >  > >
> >  > > It does indeed work without nographic.  (It doesn't do anything
> >  > > _useful_ for me without nographic, since I'm scripting the emulated
> >  > > kernel's behavior through stdin and stdout, but allowing it to pop
> >  > > up an SDL window does make it out of openbios and into the kernel.)
> >  >
> >  > The kernel makes the equivalent of the following calls to OF
> >  > interface: finddevice("/") = 0x11d5c
> >  > finddevice("/chosen") = 0x1197c
> >  > finddevice("/openprom") = 0x11b3c
> >  > getprop(0x11b3c, "model", 0x78efeb0, 0x40) = 0xf
> >  > getprop(0x11d5c, "stdout", 0x78efea0, 0x4) = 0x4
> >  > instance-to-path(0x86ea0, 0x12ad0dc, 0xff) where it crashes because
> >  > memmove overwrites all memory.
> >  >
> >  > But where does this 0x86ea0 come from?
> >
> > No idea, but it worked with the previous openbios, and without
> > --nographic. This is a 2.6.28.8 kernel built with the attached .config.
> >
> >  By the way, while binary searching the openbios repository to figure out
> >  exactly what commit between 450 and 463 actually caused it to stop
> > working, and I hit a fun little OpenBios hiccup in the top level Makefile
> > of current OpenBios svn:
> >
> >  build:
> >     @printf "Building..."
> >     @for dir in $(ODIRS); do \
> >         $(MAKE) -C $$dir > $$dir/build.log 2>&1 && echo "ok." || \
> >         ( echo "error:"; tail -15 $$$dir/build.log; exit 1 ) \
> >     done
> >
> >  You have one too many $ before dir/build.log in the error message, so
> > the error message you get is
> >
> >   Building...error:
> >   tail: cannot open `/build.log' for reading: No such file or directory
> >   make: *** [build] Error 1
>
> I must always have used build-verbose. Should be fixed soon.
>
> >  Which took about 15 minutes of head scratching for a newbie like me to
> > track down.  (The actual problem was that your
> > config/examples/cross-ppc_rules.xml hardwires TARGET=powerpc-linux-gnu-
> > and my cross compiler just uses powerpc- as the prefix, and overriding
> > TARGET on the make command line doesn't work because you use recursive
> > make, and you aren't doing the ?= conditional assignments that won't
> > overwrite existing environment variable values.  I more or less expected
> > it and was running the thing the first time so it would tell me what
> > cross compiler name it expected when it died unable to find it.  Easy
> > enough to fix by just editing the darn file, but a mention of it in the
> > README wouldn't go amiss...)
>
> But my tools also use different prefix, powerpc-elf-
> (powerpc-unknown-elf). I compile using:
>
> make build-verbose TARGET=powerpc-elf-
>
> without problems.

Eh, maybe I typoed something.  But it would still be nice if the README could 
mention TARGET.  (Or, for that matter, build-verbose.)

> About the OpenBIOS problem, I've done further debugging. The crash can
> be reproduced with (-nographic -prom-env auto-boot?=false):

And we are beyond my area of expertise.

When I grab openbios-qemu.elf built from svn 479, rename it qemu-system-ppc, 
and then fire up qemu with "-L ." it complains it can't find "video.x".  Ok, 
fine, add video.x to the current directory (that's powerpc code?) and try 
again, and it goes:

>> =============================================================
>> OpenBIOS 1.0 [Mar 19 2009 02:56]
>> Configuration device id QEMU version 1 machine id 2
>> CPUs: 1
>> Memory: 128M
>> UUID: 00000000-0000-0000-0000-000000000000
>> CPU type PowerPC,750
Welcome to OpenBIOS v1.0 built on Mar 19 2009 02:56

>> File not found
>> *** Boot failure! No secondary bootloader specified ***

Which is at least a _different_ error, but I have no idea what I did wrong...

I tried building a known working version, but svn is being stroppy:

> $ svn update -r 450
> svn: Target path does not exist

No _idea_ what that means, but apparently svn won't back up from current HEAD 
to target 450 without a fight, and won't explain why either.  Google is not 
helpful here, it talks about merging branches...

Rob

Re: [Qemu-devel] svn 6658 broke powerpc.

[Blue Swirl]

On 3/19/09, Rob Landley <rob@landley.net> wrote:
> On Thursday 19 March 2009 12:48:09 Blue Swirl wrote:
>  > On 3/19/09, Rob Landley <rob@landley.net> wrote:
>  > > On Wednesday 18 March 2009 14:11:19 Blue Swirl wrote:
>  > >  > On 3/18/09, Rob Landley <rob@landley.net> wrote:
>  > >  > > On Wednesday 18 March 2009 03:41:05 Alexander Graf wrote:
>  > >  > >  > On 18.03.2009, at 00:57, Rob Landley wrote:
>  > >  > >  > > Up through svn 6657, I could boot a powerpc kernel with
>  > >  > >  > > -kernel. That commit
>  > >  > >  > > changed it so now it says:
>  > >  > >  > > invalid/unsupported opcode: 00 - 00 - 00 (00000000) fff18f00 1
>  > >  > >  > > invalid/unsupported opcode: 00 - 00 - 00 (00000000) fff18f04 1
>  > >  > >  > > invalid/unsupported opcode: 00 - 0c - 06 (00009198) 00009214 0
>  > >  > >  > >
>  > >  > >  > > And dies.
>  > >  > >  > >
>  > >  > >  > > You can grab a test kernel from
>  > >  > >  > > http://landley.net/zImage-powerpc and try
>  > >  > >  > > booting it (out of the qemu source directory, this is assuming
>  > >  > >  > > you've built it
>  > >  > >  > > but haven't installed it yet) via:
>  > >  > >  > >
>  > >  > >  > > ppc-softmmu/qemu-system-ppc -kernel zImage-powerpc \
>  > >  > >  > >  -append "console=ttyS0 panic=1" -nographic -no-reboot -L
>  > >  > >  > > pc-bios
>  > >  > >  > >
>  > >  > >  > > With svn 6657, it works.  (You get kernel boot messages up
>  > >  > >  > > until it panics and
>  > >  > >  > > dies because it can't find the root filesystem).  With 6658 it
>  > >  > >  > > dies immediately with the above error message.
>  > >  > >  > >
>  > >  > >  > > Unfortunately, this means that the 0.10.0 release doesn't work
>  > >  > >  > > for powerpc for
>  > >  > >  > > me, but svn a couple days _before_ the release did.
>  > >  > >  >
>  > >  > >  > That specific commit shouldn't have changed anything with respect
>  > >  > >  > to ppc32 emulation. The one where your command broken is the
>  > >  > >  > openBIOS update.
>  > >  > >
>  > >  > > The commit I pointed to is the openbios update, yes.
>  > >  > >
>  > >  > >  > Please try again without -nographic.
>  > >  > >
>  > >  > > It does indeed work without nographic.  (It doesn't do anything
>  > >  > > _useful_ for me without nographic, since I'm scripting the emulated
>  > >  > > kernel's behavior through stdin and stdout, but allowing it to pop
>  > >  > > up an SDL window does make it out of openbios and into the kernel.)
>  > >  >
>  > >  > The kernel makes the equivalent of the following calls to OF
>  > >  > interface: finddevice("/") = 0x11d5c
>  > >  > finddevice("/chosen") = 0x1197c
>  > >  > finddevice("/openprom") = 0x11b3c
>  > >  > getprop(0x11b3c, "model", 0x78efeb0, 0x40) = 0xf
>  > >  > getprop(0x11d5c, "stdout", 0x78efea0, 0x4) = 0x4
>  > >  > instance-to-path(0x86ea0, 0x12ad0dc, 0xff) where it crashes because
>  > >  > memmove overwrites all memory.
>  > >  >
>  > >  > But where does this 0x86ea0 come from?
>  > >
>  > > No idea, but it worked with the previous openbios, and without
>  > > --nographic. This is a 2.6.28.8 kernel built with the attached .config.
>  > >
>  > >  By the way, while binary searching the openbios repository to figure out
>  > >  exactly what commit between 450 and 463 actually caused it to stop
>  > > working, and I hit a fun little OpenBios hiccup in the top level Makefile
>  > > of current OpenBios svn:
>  > >
>  > >  build:
>  > >     @printf "Building..."
>  > >     @for dir in $(ODIRS); do \
>  > >         $(MAKE) -C $$dir > $$dir/build.log 2>&1 && echo "ok." || \
>  > >         ( echo "error:"; tail -15 $$$dir/build.log; exit 1 ) \
>  > >     done
>  > >
>  > >  You have one too many $ before dir/build.log in the error message, so
>  > > the error message you get is
>  > >
>  > >   Building...error:
>  > >   tail: cannot open `/build.log' for reading: No such file or directory
>  > >   make: *** [build] Error 1
>  >
>  > I must always have used build-verbose. Should be fixed soon.
>  >
>  > >  Which took about 15 minutes of head scratching for a newbie like me to
>  > > track down.  (The actual problem was that your
>  > > config/examples/cross-ppc_rules.xml hardwires TARGET=powerpc-linux-gnu-
>  > > and my cross compiler just uses powerpc- as the prefix, and overriding
>  > > TARGET on the make command line doesn't work because you use recursive
>  > > make, and you aren't doing the ?= conditional assignments that won't
>  > > overwrite existing environment variable values.  I more or less expected
>  > > it and was running the thing the first time so it would tell me what
>  > > cross compiler name it expected when it died unable to find it.  Easy
>  > > enough to fix by just editing the darn file, but a mention of it in the
>  > > README wouldn't go amiss...)
>  >
>  > But my tools also use different prefix, powerpc-elf-
>  > (powerpc-unknown-elf). I compile using:
>  >
>  > make build-verbose TARGET=powerpc-elf-
>  >
>  > without problems.
>
>
> Eh, maybe I typoed something.  But it would still be nice if the README could
>  mention TARGET.  (Or, for that matter, build-verbose.)
>
>
>  > About the OpenBIOS problem, I've done further debugging. The crash can
>  > be reproduced with (-nographic -prom-env auto-boot?=false):
>
>
> And we are beyond my area of expertise.
>
>  When I grab openbios-qemu.elf built from svn 479, rename it qemu-system-ppc,
>  and then fire up qemu with "-L ." it complains it can't find "video.x".  Ok,
>  fine, add video.x to the current directory (that's powerpc code?) and try
>  again, and it goes:
>
>  >> =============================================================
>  >> OpenBIOS 1.0 [Mar 19 2009 02:56]
>  >> Configuration device id QEMU version 1 machine id 2
>  >> CPUs: 1
>  >> Memory: 128M
>  >> UUID: 00000000-0000-0000-0000-000000000000
>  >> CPU type PowerPC,750
>  Welcome to OpenBIOS v1.0 built on Mar 19 2009 02:56
>
>  >> File not found
>  >> *** Boot failure! No secondary bootloader specified ***
>
>  Which is at least a _different_ error, but I have no idea what I did wrong...

The disk boot attempt did not work.

>  I tried building a known working version, but svn is being stroppy:
>
>  > $ svn update -r 450
>  > svn: Target path does not exist
>
>  No _idea_ what that means, but apparently svn won't back up from current HEAD
>  to target 450 without a fight, and won't explain why either.  Google is not
>  helpful here, it talks about merging branches...

The repository was reorganized at r470, after that the full path has
/trunk component which was not there before.

Re: [Qemu-devel] svn 6658 broke powerpc.

[Blue Swirl]

[-- Attachment #1: Type: text/plain, Size: 7260 bytes --]

On 3/19/09, Blue Swirl <blauwirbel@gmail.com> wrote:
> On 3/19/09, Rob Landley <rob@landley.net> wrote:
>  > On Wednesday 18 March 2009 14:11:19 Blue Swirl wrote:
>  >  > On 3/18/09, Rob Landley <rob@landley.net> wrote:
>  >  > > On Wednesday 18 March 2009 03:41:05 Alexander Graf wrote:
>  >  > >  > On 18.03.2009, at 00:57, Rob Landley wrote:
>  >  > >  > > Up through svn 6657, I could boot a powerpc kernel with -kernel.
>  >  > >  > > That commit
>  >  > >  > > changed it so now it says:
>  >  > >  > > invalid/unsupported opcode: 00 - 00 - 00 (00000000) fff18f00 1
>  >  > >  > > invalid/unsupported opcode: 00 - 00 - 00 (00000000) fff18f04 1
>  >  > >  > > invalid/unsupported opcode: 00 - 0c - 06 (00009198) 00009214 0
>  >  > >  > >
>  >  > >  > > And dies.
>  >  > >  > >
>  >  > >  > > You can grab a test kernel from http://landley.net/zImage-powerpc
>  >  > >  > > and try
>  >  > >  > > booting it (out of the qemu source directory, this is assuming
>  >  > >  > > you've built it
>  >  > >  > > but haven't installed it yet) via:
>  >  > >  > >
>  >  > >  > > ppc-softmmu/qemu-system-ppc -kernel zImage-powerpc \
>  >  > >  > >  -append "console=ttyS0 panic=1" -nographic -no-reboot -L pc-bios
>  >  > >  > >
>  >  > >  > > With svn 6657, it works.  (You get kernel boot messages up until it
>  >  > >  > > panics and
>  >  > >  > > dies because it can't find the root filesystem).  With 6658 it dies
>  >  > >  > > immediately with the above error message.
>  >  > >  > >
>  >  > >  > > Unfortunately, this means that the 0.10.0 release doesn't work for
>  >  > >  > > powerpc for
>  >  > >  > > me, but svn a couple days _before_ the release did.
>  >  > >  >
>  >  > >  > That specific commit shouldn't have changed anything with respect to
>  >  > >  > ppc32 emulation. The one where your command broken is the openBIOS
>  >  > >  > update.
>  >  > >
>  >  > > The commit I pointed to is the openbios update, yes.
>  >  > >
>  >  > >  > Please try again without -nographic.
>  >  > >
>  >  > > It does indeed work without nographic.  (It doesn't do anything _useful_
>  >  > > for me without nographic, since I'm scripting the emulated kernel's
>  >  > > behavior through stdin and stdout, but allowing it to pop up an SDL
>  >  > > window does make it out of openbios and into the kernel.)
>  >  >
>  >  > The kernel makes the equivalent of the following calls to OF interface:
>  >  > finddevice("/") = 0x11d5c
>  >  > finddevice("/chosen") = 0x1197c
>  >  > finddevice("/openprom") = 0x11b3c
>  >  > getprop(0x11b3c, "model", 0x78efeb0, 0x40) = 0xf
>  >  > getprop(0x11d5c, "stdout", 0x78efea0, 0x4) = 0x4
>  >  > instance-to-path(0x86ea0, 0x12ad0dc, 0xff) where it crashes because
>  >  > memmove overwrites all memory.
>  >  >
>  >  > But where does this 0x86ea0 come from?
>  >
>  >
>  > No idea, but it worked with the previous openbios, and without --nographic.
>  >  This is a 2.6.28.8 kernel built with the attached .config.
>  >
>  >  By the way, while binary searching the openbios repository to figure out
>  >  exactly what commit between 450 and 463 actually caused it to stop working,
>  >  and I hit a fun little OpenBios hiccup in the top level Makefile of current
>  >  OpenBios svn:
>  >
>  >  build:
>  >     @printf "Building..."
>  >     @for dir in $(ODIRS); do \
>  >         $(MAKE) -C $$dir > $$dir/build.log 2>&1 && echo "ok." || \
>  >         ( echo "error:"; tail -15 $$$dir/build.log; exit 1 ) \
>  >     done
>  >
>  >  You have one too many $ before dir/build.log in the error message, so the
>  >  error message you get is
>  >
>  >   Building...error:
>  >   tail: cannot open `/build.log' for reading: No such file or directory
>  >   make: *** [build] Error 1
>
>
> I must always have used build-verbose. Should be fixed soon.
>
>
>  >  Which took about 15 minutes of head scratching for a newbie like me to track
>  >  down.  (The actual problem was that your config/examples/cross-ppc_rules.xml
>  >  hardwires TARGET=powerpc-linux-gnu- and my cross compiler just uses powerpc-
>  >  as the prefix, and overriding TARGET on the make command line doesn't work
>  >  because you use recursive make, and you aren't doing the ?= conditional
>  >  assignments that won't overwrite existing environment variable values.  I more
>  >  or less expected it and was running the thing the first time so it would tell
>  >  me what cross compiler name it expected when it died unable to find it.  Easy
>  >  enough to fix by just editing the darn file, but a mention of it in the README
>  >  wouldn't go amiss...)
>
>
> But my tools also use different prefix, powerpc-elf-
>  (powerpc-unknown-elf). I compile using:
>
>  make build-verbose TARGET=powerpc-elf-
>
>  without problems.
>
>  About the OpenBIOS problem, I've done further debugging. The crash can
>  be reproduced with (-nographic -prom-env auto-boot?=false):
>  0 > cd /chosen  ok
>  0 > .properties
>  name                      "chosen"
>  stdin                     86904
>  stdout                    86a08
>  memory                    86da0
>  mmu                       867e8
>  display                   86660
>  nvram                     86750
>  rtc                       86d3c
>   ok
>  0 > 86904 get-instance-path  type invalid/unsupported opcode: 00 - 00
>  - 00 (00000000) fff18f04 1
>  invalid/unsupported opcode: 00 - 00 - 00 (00000000) fff18f08 1
>  invalid bits: 00400000 for opcode: 0b - 19 - 15 (2d746572) 00009230
>
>  But other nodes crash too:
>  0 >  86da0  get-instance-path  type /memory@0 ok
>  0 > 86660  get-instance-path  type /pci@80000000/QEMU,VGA@1 ok
>  0 > 86750  get-instance-path  type invalid/unsupported opcode: 00 - 00
>  - 00 (00000000) fff18f04 1
>  invalid/unsupported opcode: 00 - 00 - 00 (00000000) fff18f08 1
>  invalid bits: 00400000 for opcode: 0b - 19 - 15 (2d746572) 00009230
>
>  0 > 86d3c  get-instance-path  type invalid/unsupported opcode: 00 - 00
>  - 00 (00000000) fff18f04 1
>  invalid/unsupported opcode: 00 - 00 - 00 (00000000) fff18f08 1
>  invalid bits: 00400000 for opcode: 0b - 19 - 15 (2d746572) 00009230
>
>  Sparc32 doesn't crash:
>  0 > cd /chosen  ok
>  0 > .properties
>  name                      "chosen"
>  stdin                     ffda1824
>  stdout                    ffda18c0
>  memory                    ffda1a88
>  mmu                       0
>  screen                    ffda1a28
>   ok
>  0 > ffda1824 get-instance-path type /obio/zs@0,100000:a ok
>  0 > ffda18c0 get-instance-path type /obio/zs@0,100000:a ok
>  0 > ffda1a28 get-instance-path type
>  /iommu@0,10000000/sbus@0,10001000/SUNW,tcx@3,800000 ok
>  0 > ffda1a88 get-instance-path type /memory@0,0 ok

I accidentally (by using a wrong variable in a more complex patch)
found out a workaround for the bug, now -nographic boot works. But
still the other nodes have the same problem as before and the
workaround removes the "reg" node which is present on real tree.

Now the escc node doesn't have the address appended:
1bfac /pci@80000000/mac-io@4/nvram@0 (nvram)
1c1c0 /pci@80000000/mac-io@4/escc (escc)
1c2ac /pci@80000000/mac-io@4/escc/ch-a@13020 (serial)
1c52c /pci@80000000/mac-io@4/escc/ch-b@13000 (serial)

Maybe nodes under /pci/mac-io should use custom
encode-unit/decode-unit methods instead of PCI ones?

[-- Attachment #2: fix_ppc_nographic.diff --]
[-- Type: plain/text, Size: 648 bytes --]

Re: [Qemu-devel] svn 6658 broke powerpc.

[Rob Landley]

On Saturday 21 March 2009 04:32:30 Blue Swirl wrote:
> I accidentally (by using a wrong variable in a more complex patch)
> found out a workaround for the bug, now -nographic boot works. But
> still the other nodes have the same problem as before and the
> workaround removes the "reg" node which is present on real tree.
>
> Now the escc node doesn't have the address appended:
> 1bfac /pci@80000000/mac-io@4/nvram@0 (nvram)
> 1c1c0 /pci@80000000/mac-io@4/escc (escc)
> 1c2ac /pci@80000000/mac-io@4/escc/ch-a@13020 (serial)
> 1c52c /pci@80000000/mac-io@4/escc/ch-b@13000 (serial)
>
> Maybe nodes under /pci/mac-io should use custom
> encode-unit/decode-unit methods instead of PCI ones?

My workaround at this end is to just revert openbios-ppc to the earlier 
version.

I still think that bisecting to find the specific commit that broke it would 
be informative, but your repository's move to /trunk at commit 470 essentially 
wiped all repository history before that.  Your development page doesn't say 
how to download the old versions, just the ones under "trunk":

  http://www.openfirmware.info/OpenBIOS

Nor does your repository viewer view anything before 470 from the little pull-
down menu:
http://tracker.coreboot.org/trac/openbios/browser/trunk/openbios-devel?rev=470
http://tracker.coreboot.org/trac/openbios/browser/trunk/openbios-devel?rev=469

I guessed how to get the repository viewer to show me the earlier versions:

  http://tracker.coreboot.org/trac/openbios/browser/openbios-devel?rev=469

But this doesn't work:

  $ svn co -r 469 svn://openbios.org/openbios/openbios-devel
  svn: File not found: revision 480, path '/openbios-devel'

Then again, I can always bisect by downloading tarballs from your repository 
viewer...  Eh, why not.

For easy cut and pasting, my build reproduction sequence is:

  chmod +x config/scripts/switch-arch
  config/scripts/switch-arch cross-ppc
  PATH=~/firmware/firmware/build/cross-compiler-powerpc/bin:$PATH \
    make TARGET=powerpc-
  sudo cp obj-ppc/openbios-qemu.elf /usr/local/share/qemu/openbios-ppc

469 exhibits the bug, so it's before that.  I believe 450 is the "known good" 
version, so let's try 460...  Bug.  455... Bug. 452... Bug.  451... Works.

So the bug was introduced (or at least triggered) by revision 452:

  http://tracker.coreboot.org/trac/openbios/changeset/452/openbios-devel

Anything in there look broken to you?

Rob

P.S.  Please at least put up a link to this on your development page:

  http://tracker.coreboot.org/trac/openbios/browser/openbios-devel?rev=469

Right now earlier versions of your repository are completely inaccessible to 
newbies like me...

Re: [Qemu-devel] svn 6658 broke powerpc.

[Blue Swirl]

On 3/21/09, Rob Landley <rob@landley.net> wrote:
> On Saturday 21 March 2009 04:32:30 Blue Swirl wrote:
>  > I accidentally (by using a wrong variable in a more complex patch)
>  > found out a workaround for the bug, now -nographic boot works. But
>  > still the other nodes have the same problem as before and the
>  > workaround removes the "reg" node which is present on real tree.
>  >
>  > Now the escc node doesn't have the address appended:
>  > 1bfac /pci@80000000/mac-io@4/nvram@0 (nvram)
>  > 1c1c0 /pci@80000000/mac-io@4/escc (escc)
>  > 1c2ac /pci@80000000/mac-io@4/escc/ch-a@13020 (serial)
>  > 1c52c /pci@80000000/mac-io@4/escc/ch-b@13000 (serial)
>  >
>  > Maybe nodes under /pci/mac-io should use custom
>  > encode-unit/decode-unit methods instead of PCI ones?
>
>
> My workaround at this end is to just revert openbios-ppc to the earlier
>  version.
>
>  I still think that bisecting to find the specific commit that broke it would
>  be informative, but your repository's move to /trunk at commit 470 essentially
>  wiped all repository history before that.  Your development page doesn't say
>  how to download the old versions, just the ones under "trunk":

Good point, I'll add some notes.

>   http://www.openfirmware.info/OpenBIOS
>
>  Nor does your repository viewer view anything before 470 from the little pull-
>  down menu:
>  http://tracker.coreboot.org/trac/openbios/browser/trunk/openbios-devel?rev=470
>  http://tracker.coreboot.org/trac/openbios/browser/trunk/openbios-devel?rev=469
>
>  I guessed how to get the repository viewer to show me the earlier versions:
>
>   http://tracker.coreboot.org/trac/openbios/browser/openbios-devel?rev=469
>
>  But this doesn't work:
>
>   $ svn co -r 469 svn://openbios.org/openbios/openbios-devel
>   svn: File not found: revision 480, path '/openbios-devel'

'svn switch' may help:
http://www.openfirmware.info/pipermail/openbios/2009-March/003594.html

I'll add something about this too.

>  Then again, I can always bisect by downloading tarballs from your repository
>  viewer...  Eh, why not.
>
>  For easy cut and pasting, my build reproduction sequence is:
>
>   chmod +x config/scripts/switch-arch
>   config/scripts/switch-arch cross-ppc
>   PATH=~/firmware/firmware/build/cross-compiler-powerpc/bin:$PATH \
>     make TARGET=powerpc-
>   sudo cp obj-ppc/openbios-qemu.elf /usr/local/share/qemu/openbios-ppc
>
>  469 exhibits the bug, so it's before that.  I believe 450 is the "known good"
>  version, so let's try 460...  Bug.  455... Bug. 452... Bug.  451... Works.
>
>  So the bug was introduced (or at least triggered) by revision 452:
>
>   http://tracker.coreboot.org/trac/openbios/changeset/452/openbios-devel
>
>  Anything in there look broken to you?

No. This basically enabled automatic switch of OpenBIOS input and
output to serial console when using the -nographic flag which was
already supported the same way by Sparc32 and Sparc64.

The bug is somewhere in the device path processing, probably in the
PPC specific higher level device like mac-io, that's why the same ESCC
serial console works on Sparc32.

>  Rob
>
>  P.S.  Please at least put up a link to this on your development page:
>
>   http://tracker.coreboot.org/trac/openbios/browser/openbios-devel?rev=469
>
>  Right now earlier versions of your repository are completely inaccessible to
>  newbies like me...
>

Re: [Qemu-devel] svn 6658 broke powerpc.

[Blue Swirl]

On 3/21/09, Rob Landley <rob@landley.net> wrote:
> On Saturday 21 March 2009 04:32:30 Blue Swirl wrote:
>  > I accidentally (by using a wrong variable in a more complex patch)
>  > found out a workaround for the bug, now -nographic boot works. But
>  > still the other nodes have the same problem as before and the
>  > workaround removes the "reg" node which is present on real tree.
>  >
>  > Now the escc node doesn't have the address appended:
>  > 1bfac /pci@80000000/mac-io@4/nvram@0 (nvram)
>  > 1c1c0 /pci@80000000/mac-io@4/escc (escc)
>  > 1c2ac /pci@80000000/mac-io@4/escc/ch-a@13020 (serial)
>  > 1c52c /pci@80000000/mac-io@4/escc/ch-b@13000 (serial)
>  >
>  > Maybe nodes under /pci/mac-io should use custom
>  > encode-unit/decode-unit methods instead of PCI ones?
>
>
> My workaround at this end is to just revert openbios-ppc to the earlier
>  version.
>
>  I still think that bisecting to find the specific commit that broke it would
>  be informative, but your repository's move to /trunk at commit 470 essentially
>  wiped all repository history before that.  Your development page doesn't say
>  how to download the old versions, just the ones under "trunk":
>
>   http://www.openfirmware.info/OpenBIOS
>
>  Nor does your repository viewer view anything before 470 from the little pull-
>  down menu:
>  http://tracker.coreboot.org/trac/openbios/browser/trunk/openbios-devel?rev=470
>  http://tracker.coreboot.org/trac/openbios/browser/trunk/openbios-devel?rev=469
>
>  I guessed how to get the repository viewer to show me the earlier versions:
>
>   http://tracker.coreboot.org/trac/openbios/browser/openbios-devel?rev=469
>
>  But this doesn't work:
>
>   $ svn co -r 469 svn://openbios.org/openbios/openbios-devel
>   svn: File not found: revision 480, path '/openbios-devel'
>
>  Then again, I can always bisect by downloading tarballs from your repository
>  viewer...  Eh, why not.
>
>  For easy cut and pasting, my build reproduction sequence is:
>
>   chmod +x config/scripts/switch-arch
>   config/scripts/switch-arch cross-ppc
>   PATH=~/firmware/firmware/build/cross-compiler-powerpc/bin:$PATH \
>     make TARGET=powerpc-
>   sudo cp obj-ppc/openbios-qemu.elf /usr/local/share/qemu/openbios-ppc
>
>  469 exhibits the bug, so it's before that.  I believe 450 is the "known good"
>  version, so let's try 460...  Bug.  455... Bug. 452... Bug.  451... Works.
>
>  So the bug was introduced (or at least triggered) by revision 452:
>
>   http://tracker.coreboot.org/trac/openbios/changeset/452/openbios-devel
>
>  Anything in there look broken to you?

Fixed in r481. I removed the PCI encode-unit/decode-unit methods for
non-bus devices, now get-instance-path works.

Re: [Qemu-devel] svn 6658 broke powerpc.

[Rob Landley]

On Sunday 22 March 2009 11:54:22 Blue Swirl wrote:
> >  So the bug was introduced (or at least triggered) by revision 452:
> >
> >   http://tracker.coreboot.org/trac/openbios/changeset/452/openbios-devel
> >
> >  Anything in there look broken to you?
>
> Fixed in r481. I removed the PCI encode-unit/decode-unit methods for
> non-bus devices, now get-instance-path works.


Cool!

Is there a procedure to ask how to queue this up for qemu 0.10.2? :)

Rob

(By the way: qemu is shipping a gpled bios binary without accompanying source 
code.  I realize that the maintainer of said binary checked it in, but what 
exactly is the rationale here?)

Re: [Qemu-devel] svn 6658 broke powerpc.

[Anthony Liguori]

Rob Landley wrote:
> On Sunday 22 March 2009 11:54:22 Blue Swirl wrote:
>   
>>>  So the bug was introduced (or at least triggered) by revision 452:
>>>
>>>   http://tracker.coreboot.org/trac/openbios/changeset/452/openbios-devel
>>>
>>>  Anything in there look broken to you?
>>>       
>> Fixed in r481. I removed the PCI encode-unit/decode-unit methods for
>> non-bus devices, now get-instance-path works.
>>     
>
>
> Cool!
>
> Is there a procedure to ask how to queue this up for qemu 0.10.2? :)
>
> Rob
>
> (By the way: qemu is shipping a gpled bios binary without accompanying source 
> code.  I realize that the maintainer of said binary checked it in, but what 
> exactly is the rationale here?)
>   

IANAL, but from the FSF GPL FAQ, you just have to make sure the source 
code is available.  Since Blue Swirl is an Open BIOS maintainer, I think 
we can say with confidence that the openbios code will always be 
available.  If that situation changed for some reason, we'd have to 
mirror their code.

Regards,

Anthony Liguori

Re: [Qemu-devel] svn 6658 broke powerpc.

[Anthony Liguori]

Anthony Liguori wrote:
> IANAL, but from the FSF GPL FAQ, you just have to make sure the source 
> code is available.  Since Blue Swirl is an Open BIOS maintainer, I 
> think we can say with confidence that the openbios code will always be 
> available.  If that situation changed for some reason, we'd have to 
> mirror their code.

Specifically:

http://www.fsf.org/licensing/licenses/gpl-faq.html#SourceAndBinaryOnDifferentSites

Not too long ago, I went through and attempted to make sure the 
instructions in pc-bios/README were very clear how to obtain the sources 
for the binaries we ship.  Patches are always welcome if people think 
they need clarification.

Regards,

Anthony Liguori

> Regards,
>
> Anthony Liguori
>
>

Re: [Qemu-devel] svn 6658 broke powerpc.

[M. Warner Losh]

In message: <49C9994F.2040803@codemonkey.ws>
            Anthony Liguori <anthony@codemonkey.ws> writes:
: Rob Landley wrote:
: > On Sunday 22 March 2009 11:54:22 Blue Swirl wrote:
: >   
: >>>  So the bug was introduced (or at least triggered) by revision 452:
: >>>
: >>>   http://tracker.coreboot.org/trac/openbios/changeset/452/openbios-devel
: >>>
: >>>  Anything in there look broken to you?
: >>>       
: >> Fixed in r481. I removed the PCI encode-unit/decode-unit methods for
: >> non-bus devices, now get-instance-path works.
: >>     
: >
: >
: > Cool!
: >
: > Is there a procedure to ask how to queue this up for qemu 0.10.2? :)
: >
: > Rob
: >
: > (By the way: qemu is shipping a gpled bios binary without accompanying source 
: > code.  I realize that the maintainer of said binary checked it in, but what 
: > exactly is the rationale here?)
: >   
: 
: IANAL, but from the FSF GPL FAQ, you just have to make sure the source 
: code is available.  Since Blue Swirl is an Open BIOS maintainer, I think 
: we can say with confidence that the openbios code will always be 
: available.  If that situation changed for some reason, we'd have to 
: mirror their code.

This is covered by 'third party' agreements.  Blue Swirl has agreed to
provide the source for the qemu project, as signified by his
committing the binaries to the qemu repo and since he's a cool guy.
If he decides to stop, then Anthony is right.

Warner

Re: [Qemu-devel] svn 6658 broke powerpc.

[Blue Swirl]

On 3/25/09, Rob Landley <rob@landley.net> wrote:
> On Sunday 22 March 2009 11:54:22 Blue Swirl wrote:
>  > >  So the bug was introduced (or at least triggered) by revision 452:
>  > >
>  > >   http://tracker.coreboot.org/trac/openbios/changeset/452/openbios-devel
>  > >
>  > >  Anything in there look broken to you?
>  >
>  > Fixed in r481. I removed the PCI encode-unit/decode-unit methods for
>  > non-bus devices, now get-instance-path works.
>
>
>
> Cool!
>
>  Is there a procedure to ask how to queue this up for qemu 0.10.2? :)

Technically the best solution would be to introduce a stable tree also
to OpenBIOS like Qemu. But OpenBIOS development is not as fast paced
as Qemu, so I'm not sure if it's worth the effort.

I can commit the latest version to Qemu SVN and if there are no
issues, update the version in stable before release.

>
>  Rob
>
>  (By the way: qemu is shipping a gpled bios binary without accompanying source
>  code.  I realize that the maintainer of said binary checked it in, but what
>  exactly is the rationale here?)

I see it as a service for both OpenBIOS and Qemu development
communities, also the casual users don't have to install cross
compilers just to try the Sparc/PPC emulators. The binaries are
compiled from unmodified sources as indicated in the README.

If someone finds problems with this, it's easy to put the binaries to
OpenBIOS site and remove them from Qemu SVN. That would make bisecting
a bit harder. Or Qemu could just include the OpenBIOS tree, it's only
12M.

Re: [Qemu-devel] svn 6658 broke powerpc.

[Anthony Liguori]

Blue Swirl wrote:
> Technically the best solution would be to introduce a stable tree also
> to OpenBIOS like Qemu. But OpenBIOS development is not as fast paced
> as Qemu, so I'm not sure if it's worth the effort.
>
> I can commit the latest version to Qemu SVN and if there are no
> issues, update the version in stable before release.
>   

It's your call.

For bochs, we have a patch queue built in pc-bios.  For stable, I'd add 
individual patches that fix issues if they came up.  I generally 
wouldn't update to a newer bochs SVN though b/c bochs has a bad habit of 
breaking things upstream.

So two options would be to include a new OpenBIOS version or just apply 
the patches that you think are important.

Regards,

Anthony Liguori

Re: [Qemu-devel] svn 6658 broke powerpc.

[Rob Landley]

On Friday 27 March 2009 13:59:36 Blue Swirl wrote:
> On 3/25/09, Rob Landley <rob@landley.net> wrote:
> > On Sunday 22 March 2009 11:54:22 Blue Swirl wrote:
> >  > >  So the bug was introduced (or at least triggered) by revision 452:
> >  > >
> >  > >  
> >  > > http://tracker.coreboot.org/trac/openbios/changeset/452/openbios-dev
> >  > >el
> >  > >
> >  > >  Anything in there look broken to you?
> >  >
> >  > Fixed in r481. I removed the PCI encode-unit/decode-unit methods for
> >  > non-bus devices, now get-instance-path works.
> >
> > Cool!
> >
> >  Is there a procedure to ask how to queue this up for qemu 0.10.2? :)
>
> Technically the best solution would be to introduce a stable tree also
> to OpenBIOS like Qemu. But OpenBIOS development is not as fast paced
> as Qemu, so I'm not sure if it's worth the effort.
>
> I can commit the latest version to Qemu SVN and if there are no
> issues, update the version in stable before release.
>
> >  Rob
> >
> >  (By the way: qemu is shipping a gpled bios binary without accompanying
> > source code.  I realize that the maintainer of said binary checked it in,
> > but what exactly is the rationale here?)
>
> I see it as a service for both OpenBIOS and Qemu development
> communities, also the casual users don't have to install cross
> compilers just to try the Sparc/PPC emulators. The binaries are
> compiled from unmodified sources as indicated in the README.
>
> If someone finds problems with this, it's easy to put the binaries to
> OpenBIOS site and remove them from Qemu SVN. That would make bisecting
> a bit harder. Or Qemu could just include the OpenBIOS tree, it's only
> 12M.

I'm not complaining, I just tend to pay attention to license issues.

If qemu is never going to try to enforce its license, it probably doesn't 
matter.  If it _does_ and the other side can point to you guys not honoring 
your own license terms, you may have a hard time getting them to.

Most likely you guys fall under GPLv2 section 3c anyway.  Commercial 
redistributors of qemu might have to include the openbios source in addition 
to the qemu source (and maybe the bochs bios source, who knows?)  But the 
qemu project itself probably doesn't.

Rob