Re: Calculating array sizes in C - was: Re: Build regressions/improvements in v6.2-rc1

[Rob Landley]

On 1/19/23 16:11, Michael.Karcher wrote:
> Isn't this supposed to be caught by this check:

  a, __same_type(a, NULL)

 ?
>>>
>>> Yeah, but gcc thinks it is smarter than us...
>>> Probably it drops the test, assuming UB cannot happen.
>> Hmm, sounds like a GGC bug to me then. Not sure how to fix this then.
> 
> 
> I don't see a clear bug at this point. We are talking about the C expression
> 
>    __same_type((void*)0, (void*)0)? 0 : sizeof((void*)0)/sizeof(*((void*0))

*(void*) is type "void" which does not have a size.

The problem is gcc "optimizing out" an earlier type check, the same way it
"optimizes out" checks for signed integer math overflowing, or "optimizes out" a
comparison to pointers from two different local variables from different
function calls trying to calculate the amount of stack used, or "optimizes out"
using char *x = (char *)1; as a flag value and then doing "if (!(x-1)) because
it can "never happen"...
> I suggest to file a bug against gcc complaining about a "spurious 
> warning", and using "-Werror -Wno-error-sizeof-pointer-div" until gcc is 
> adapted to not emit the warning about the pointer division if the result 
> is not used.

Remember when gcc got rewritten in c++ starting in 2007?

Historically the main marketing push of C++ was that it contains the whole of C
and therefore MUST be just as good a language, the same way a mud pie contains
an entire glass of water and therefore MUST be just as good a beverage. Anything
C can do that C++ _can't_ do is seen as an existential threat by C++ developers.
They've worked dilligently to "fix" C not being a giant pile of "undefined
behavior" the way C++ is for 15 years now.

I have... opinions on this.

> Regards,
>    Michael Karcher

Rob

Re: serial hang in qemu-system-ppc64 -M pseries

[Rob Landley]

On 4/29/22 16:43, Fabiano Rosas wrote:
> Rob Landley  writes:
>> Then paste something longer than 16 characters at the eventual command prompt
>> once the kernel finishes booting.
> 
> I suspect this is due to how the tty driver (n_tty.c) interacts with
> the console (hvc_console.c) driver's buffer size.
> 
> This is the stack:
> 
> #0 hvc_push  <-- calls into KVM/QEMU to write up to 16 bytes
> #1 hvc_write
> #2 tty_put_char
> #3 do_output_char
> #4 __process_echoes  <-- writes up to tty_write_room() chars
> #5 flush_echoes  <-- returns early if ~ECHO && ~ECHONL
> #6 n_tty_receive_buf_common  <-- buffers more than 16 bytes
> #7 tty_ldisc_receive_buf
> #8 tty_port_default_receive_buf
> #9 receive_buf
> #10 process_one_work
> 
> In my busybox instance which does not have this issue I can see that
> termios.c_lflag = 0x447, so in the stack above #4 is not called (ECHO
> is 0x8, ECHONL is 0x10).
> 
> In the bug scenario: termios.c_lflag = 0x5cf, so we go into #4 which
> is supposed to write (say) 17 bytes, but ends up writing only 16
> because that is what tty_write_room() returns.

I think my init script left the terminal wherever the hardware defaults
initialized it to?

(I note that sh4 also has a variant of this problem, but instead of the
stutter-and-flush behavior it just hard discards everything after the first 16
characters of a paste. Large pastes seemsto work without issue on all the other
targets I've tried so far, I.E. x86, arm, mips, powerpc -M g3beige, s390x, and
m68k. And by "large" I mean I've fed half a megabyte of uuencode output into
uudecode as a single paste.)

> What I think is causing this issue is that the hvc_vio.c driver is
> configured with hp->outbuf_size = 16. That number comes from the
> H_PUT_TERM_CHAR hypercall spec which reads two registers at a
> time. However, the hvc_write function supports writes larger than 16
> bytes so it seems we're needlessly propagating the 16 byte limitation
> to the upper layer.

Looks like the call is:

  hp = hvc_alloc(termno, vdev->irq, ops, MAX_VIO_PUT_CHARS);

MAX_VIO_PUT_CHARS implies it's the maximum allowed write size. Understandable if
writes bigger than that didn't get a lot of testing. (There's an identical call
in hvc_opal.c, by the way.)

> The driver is also not buffering the write, so if it gets called to
> write one char at a time (like __process_echoes does) there should be no
> limit to how much it can write.
> 
> I think if we increase hp->outbuf_size to a value that is larger than
> N_TTY_BUF_SIZE=4096 the echo buffer would drain before reaching this new
> hvc driver limit.

How is this handled on any of the architectures where it works? (Or do their tty
flags just start at different defaults so I don't see it there?)

> I tested that and it seems to work, but I'm not sure if it's the right
> fix, there are some things I couldn't figure out:

Let me know if I can help, although this sounds like it's moved a bit beyond
areas I'm familiar with.

Thanks,

Rob

Re: serial hang in qemu-system-ppc64 -M pseries

[Rob Landley]

On 4/28/22 00:41, Rob Landley wrote:
> On 4/27/22 10:27, Thomas Huth wrote:
>> On 26/04/2022 12.26, Rob Landley wrote:
>>> When I cut and paste 80-ish characters of text into the Linux serial 
>>> console, it
>>> reads 16 characters and stops. When I hit space, it reads another 16 
>>> characters,
>>> and if I keep at it will eventually catch up without losing data. If I type,
>>> every character shows up immediately.
>> 
>> That "16" certainly comes from VTERM_BUFSIZE in hw/char/spapr_vty.c in the 
>> QEMU sources, I think.
>> 
>>> (On other qemu targets and kernels I can cut and paste an entire uuencoded
>>> binary and it goes through just fine in one go, but this target hangs with 
>>> big
>>> pastes until I hit keys.)
>>> 
>>> Is this a qemu-side bug, or a kernel-side bug?
>>> 
>>> Kernel config attached (linux 5.18-rc3 or thereabouts), qemu invocation is:
>>> 
>>> qemu-system-ppc64 -M pseries -vga none -nographic -no-reboot -m 256 -kernel
>>> vmlinux -initrd powerpc64leroot.cpio.gz -append "panic=1 HOST=powerpc64le
>>> console=hvc0"
>> 
>> Which version of QEMU are you using?
> 
> $ qemu-system-ppc64 --version
> QEMU emulator version 6.2.92 (v6.2.0-rc2)
> Copyright (c) 2003-2021 Fabrice Bellard and the QEMU Project developers

Just confirmed it behaves the same with current git (commit cf6f26d6f9b2).

Rob

Re: serial hang in qemu-system-ppc64 -M pseries

[Rob Landley]

On 4/27/22 10:27, Thomas Huth wrote:
> On 26/04/2022 12.26, Rob Landley wrote:
>> When I cut and paste 80-ish characters of text into the Linux serial 
>> console, it
>> reads 16 characters and stops. When I hit space, it reads another 16 
>> characters,
>> and if I keep at it will eventually catch up without losing data. If I type,
>> every character shows up immediately.
> 
> That "16" certainly comes from VTERM_BUFSIZE in hw/char/spapr_vty.c in the 
> QEMU sources, I think.
> 
>> (On other qemu targets and kernels I can cut and paste an entire uuencoded
>> binary and it goes through just fine in one go, but this target hangs with 
>> big
>> pastes until I hit keys.)
>> 
>> Is this a qemu-side bug, or a kernel-side bug?
>> 
>> Kernel config attached (linux 5.18-rc3 or thereabouts), qemu invocation is:
>> 
>> qemu-system-ppc64 -M pseries -vga none -nographic -no-reboot -m 256 -kernel
>> vmlinux -initrd powerpc64leroot.cpio.gz -append "panic=1 HOST=powerpc64le
>> console=hvc0"
> 
> Which version of QEMU are you using?

$ qemu-system-ppc64 --version
QEMU emulator version 6.2.92 (v6.2.0-rc2)
Copyright (c) 2003-2021 Fabrice Bellard and the QEMU Project developers

>From november. I can pull and rebuild but it'll take a bit. (Hopefully
rebuilding would fix the need to echo -e '\e[?7h' afterwards to undo the "bash
command line history marches up the screen because qemu's x86 bios disabled line
wrap and then left it that way" issue...)

> Which frontend (GTK or terminal?) ... 

The above command line has -nographic, forcing terminal. Running ldd on the
binary doesn't pull up anything gtk. (It pulls up libncursesw though.)

If you want to reproduce my test locally:

wget https://landley.net/toybox/downloads/binaries/mkroot/0.8.5/powerpc64le.tgz
tar xvzf powerpc64le.tgz
cd powerpc64le
./qemu-*.sh

Then paste something longer than 16 characters at the eventual command prompt
once the kernel finishes booting.

If you want to reproduce it all from source:

git clone https://github.com/landley/toybox
cd toybox && mkdir ccc && cd ccc
wget
https://landley.net/toybox/downloads/binaries/toolchains/latest/powerpc64le-linux-musl-cross.tar.xz
-O - | tar xv
cd ..
CROSS=powerpc64le LINUX=~/linux scripts/mkroot.sh
cd root/powerpc64le
./qemu-*.sh

This assumes your linux kernel source directory is in ~/linux of course, and
that qemu-system-ppc64 is in the $PATH...

> this rings a distant bell, but I thought we had fixed these issues long ago 
> in the past... e.g.:
>
> https://yhbt.net/lore/all/1380113886-16845-10-git-send-email-mdr...@linux.vnet.ibm.com/
> 
> https://git.qemu.org/?p=qemu.git;a=commitdiff;h=8a273cbe53221d28

The qemu I'm running is newer than 2016. :)

Most targets are fine with this: I cut and paste entire uuencoded binaries into
the serial console as an easy way to insert a file into an initramfs. It can
usually take multiple megabytes without dropping a character, so you just
"uudecode" enter, and then paste.

Even my 32 bit powerpc target works fine with this. (Although -M g3beige is a
very different machine from -M pseries...)

Alas this target (and sh4 -m r2d) stop at 16 chars. (On sh4 the extra is
discarded, not delivered progressively as more interrupts are generated.)

> ... but maybe my memory also just fails and this has never been properly 
> fixed.
> 
>   Thomas

Rob

serial hang in qemu-system-ppc64 -M pseries

[Rob Landley]

When I cut and paste 80-ish characters of text into the Linux serial console, it
reads 16 characters and stops. When I hit space, it reads another 16 characters,
and if I keep at it will eventually catch up without losing data. If I type,
every character shows up immediately.

(On other qemu targets and kernels I can cut and paste an entire uuencoded
binary and it goes through just fine in one go, but this target hangs with big
pastes until I hit keys.)

Is this a qemu-side bug, or a kernel-side bug?

Kernel config attached (linux 5.18-rc3 or thereabouts), qemu invocation is:

qemu-system-ppc64 -M pseries -vga none -nographic -no-reboot -m 256 -kernel
vmlinux -initrd powerpc64leroot.cpio.gz -append "panic=1 HOST=powerpc64le
console=hvc0"

Rob

linux-fullconfig.gz
Description: application/gzip

Re: [PATCH RESEND v4] reboot: support offline CPUs before reboot

[Rob Landley]

On 1/14/20 5:06 AM, Hsin-Yi Wang wrote:
> This patch adds a config ARCH_OFFLINE_CPUS_ON_REBOOT, which would offline 
> cpus in
> migrate_to_reboot_cpu(). If non reboot cpus are all offlined here, the loop 
> for
> checking online cpus would be an empty loop. If architecture don't enable this
> config, or some cpus somehow fails to offline, it would fallback to ipi
> function.

I'm curious:

> +# Select to do a full offline on secondary CPUs before reboot.
> +config ARCH_OFFLINE_CPUS_ON_REBOOT
> + bool "Support for offline CPUs before reboot"
> + depends on HOTPLUG_CPU

The new symbol can't be selected without the other symbol.

> + select ARCH_OFFLINE_CPUS_ON_REBOOT if HOTPLUG_CPU

And the other symbol automatically selects the new one.

Why are you adding a second symbol that means the same thing as the existing 
symbol?

> +#if defined(CONFIG_PM_SLEEP_SMP) || 
> defined(CONFIG_ARCH_OFFLINE_CPUS_ON_REBOOT)
> +extern int freeze_secondary_cpus(int primary, bool reboot);
> +#endif

Couldn't that just test HOTPLUG_CPU? What's the second symbol for? (You can have
empty stub functions when architectures don't support a thing...)

Rob

Re: [PATCH] Extract initrd free logic from arch-specific code.

[Rob Landley]

On 03/29/2018 10:27 AM, Russell King - ARM Linux wrote:
> On Thu, Mar 29, 2018 at 09:37:52AM +1100, Oliver wrote:
>> On Thu, Mar 29, 2018 at 9:14 AM, Russell King - ARM Linux
>>> LD_DEAD_CODE_DATA_ELIMINATION is a symbol without a prompt, and from
>>> what I can see, nothing selects it.  Therefore, the symbol is always
>>> disabled, and so the feature never gets used in mainline kernels.
>>>
>>> Brings up the obvious question - why is it there if it's completely
>>> unused?  (Maybe to cause confusion, and allowing a justification
>>> for __weak ?)
>>
>> IIRC Nick had some patches to do the arch enablement for powerpc, but
>> I'm not sure what happened to them though. I suspect it just fell down
>> Nick's ever growing TODO list.
> 
> I've given it a go on ARM, marking every linker-built table with KEEP()
> and comparing the System.map files.  The resulting kernel is around
> 150k smaller, which seems good.
> 
> However, it doesn't boot - and I don't know why.  Booting the kernel
> under kvmtool in a VM using virtio-console, I can find no way to get
> any kernel messages out of it.  Using lkvm debug, I can see that the
> PC is stuck inside die(), and that's the only information I have.

qemu-system-arm's "-s" option lets you hook to the hardware with gdb, as if
using one of those jtags that speaks gdbserver protocol. It stops waiting for
you to attach with 'target remote' it, then 'file vmlinux' to load the 
symbols...

The miniconfig and qemu invocation I use for arm64 are attached, tested with
2.11.0 on a 4.14 kernel. You should be able to just "qemu-aarch64.sh -s" and
then probably "target remote 127.0.0.1:1234"? (Been a while since I've used it,
don't have a cross-gdb for arm64 lying around...)

Sigh, I just tried -s and qemu 2.11.0 is _not_ waiting for gdb to attach on
arm64, despite what the docs say:

$ qemu-system-aarch64 --help | grep gdb
-gdb devwait for gdb connection on 'dev'
-s  shorthand for -gdb tcp::1234

Another random regression in qemu, gee what a surprise.

> It dies before bringing up the other CPUs, so it's a very early death.
> 
> I don't think other console types are available under ARM64.

I've often found useful the two line version of:

https://balau82.wordpress.com/2010/02/28/hello-world-for-bare-metal-arm-using-qemu/

Which is generally some variant of:

{char *XX = "blah"; while (*XX) {while (*SERIAL_STATUS_REGISTER & OUT_READY);
*SERIAL_OUT = *XX++;}}

(I.E. balu cheated not spinning checking the ready-for-next-byte bit, because
qemu's always angry.)

That trick lets you cut and paste a print statement into all sorts of early
hardware nonsense, on most architectures. You just have to look up
SERIAL_STATUS_REGISTER, OUT_OK_BIT, and SERIAL_OUT values for the serial port du
jour.

That said I've mostly used it in things like u-boot. I dunno at what point the
kernel's done enough setup that direct banging on registers would stop working.
(Works in the decompresion code, anyway.) And it assumes the port's set to the
right speed (usually left there by the bootloader)...

Rob
# make ARCH=arm64 allnoconfig KCONFIG_ALLCONFIG=aarch64.miniconf
# make ARCH=arm64 -j $(nproc)
# boot arch/arm64/boot/Image


CONFIG_MMU=y
CONFIG_ARCH_MULTI_V7=y
CONFIG_ARCH_VIRT=y
CONFIG_SOC_DRA7XX=y
CONFIG_ARCH_OMAP2PLUS_TYPICAL=y
CONFIG_ARCH_ALPINE=y
CONFIG_ARM_THUMB=y
CONFIG_VDSO=y
CONFIG_CPU_IDLE=y
CONFIG_ARM_CPUIDLE=y
CONFIG_KERNEL_MODE_NEON=y

CONFIG_SERIAL_AMBA_PL011=y
CONFIG_SERIAL_AMBA_PL011_CONSOLE=y

CONFIG_RTC_CLASS=y
CONFIG_RTC_HCTOSYS=y
CONFIG_RTC_DRV_PL031=y

CONFIG_NET_CORE=y
CONFIG_VIRTIO_NET=y

CONFIG_PCI=y
CONFIG_PCI_HOST_GENERIC=y
CONFIG_VIRTIO_BLK=y
CONFIG_VIRTIO_PCI=y
CONFIG_VIRTIO_MMIO=y

CONFIG_ATA=y
CONFIG_ATA_SFF=y
CONFIG_ATA_BMDMA=y
CONFIG_ATA_PIIX=y

CONFIG_PATA_PLATFORM=y
CONFIG_PATA_OF_PLATFORM=y
CONFIG_ATA_GENERIC=y


# CONFIG_EMBEDDED is not set
CONFIG_EARLY_PRINTK=y
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_SCRIPT=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y

CONFIG_BLK_DEV=y
CONFIG_BLK_DEV_INITRD=y
CONFIG_RD_GZIP=y

CONFIG_BLK_DEV_LOOP=y
CONFIG_EXT4_FS=y
CONFIG_EXT4_USE_FOR_EXT2=y
CONFIG_VFAT_FS=y
CONFIG_FAT_DEFAULT_UTF8=y
CONFIG_MISC_FILESYSTEMS=y
CONFIG_SQUASHFS=y
CONFIG_SQUASHFS_XATTR=y
CONFIG_SQUASHFS_ZLIB=y
CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y
CONFIG_TMPFS=y
CONFIG_TMPFS_POSIX_ACL=y

CONFIG_NET=y
CONFIG_PACKET=y
CONFIG_UNIX=y
CONFIG_INET=y
CONFIG_IPV6=y
CONFIG_NETDEVICES=y
#CONFIG_NET_CORE=y
#CONFIG_NETCONSOLE=y
CONFIG_ETHERNET=y



qemu-aarch64.sh
Description: application/shellscript

Re: [PATCH] Extract initrd free logic from arch-specific code.

[Rob Landley]

On 03/28/2018 05:14 PM, Russell King - ARM Linux wrote:
> On Wed, Mar 28, 2018 at 02:04:22PM -0500, Rob Landley wrote:
>>
>>
>> On 03/28/2018 11:48 AM, Russell King - ARM Linux wrote:
>>> On Wed, Mar 28, 2018 at 10:58:51AM -0500, Rob Landley wrote:
>>>> On 03/28/2018 10:26 AM, Shea Levy wrote:
>>>>> Now only those architectures that have custom initrd free requirements
>>>>> need to define free_initrd_mem.
>>>> ...
>>>>> --- a/arch/arc/mm/init.c
>>>>> +++ b/arch/arc/mm/init.c
>>>>> @@ -229,10 +229,3 @@ void __ref free_initmem(void)
>>>>>  {
>>>>>   free_initmem_default(-1);
>>>>>  }
>>>>> -
>>>>> -#ifdef CONFIG_BLK_DEV_INITRD
>>>>> -void __init free_initrd_mem(unsigned long start, unsigned long end)
>>>>> -{
>>>>> - free_reserved_area((void *)start, (void *)end, -1, "initrd");
>>>>> -}
>>>>> -#endif
>>>>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
>>>>> index 3f972e83909b..19d1c5594e2d 100644
>>>>> --- a/arch/arm/Kconfig
>>>>> +++ b/arch/arm/Kconfig
>>>>> @@ -47,6 +47,7 @@ config ARM
>>>>>   select HARDIRQS_SW_RESEND
>>>>>   select HAVE_ARCH_AUDITSYSCALL if (AEABI && !OABI_COMPAT)
>>>>>   select HAVE_ARCH_BITREVERSE if (CPU_32v7M || CPU_32v7) && !CPU_32v6
>>>>> + select HAVE_ARCH_FREE_INITRD_MEM
>>>>>   select HAVE_ARCH_JUMP_LABEL if !XIP_KERNEL && !CPU_ENDIAN_BE32 && MMU
>>>>>   select HAVE_ARCH_KGDB if !CPU_ENDIAN_BE32 && MMU
>>>>>   select HAVE_ARCH_MMAP_RND_BITS if MMU
>>>>
>>>> Isn't this why weak symbols were invented?
>>>
>>> Weak symbols means that we end up with both the weakly-referenced code
>>> and the arch code in the kernel image.  That's fine if the weak code
>>> is small.
>>
>> The kernel's been able to build with link time garbage collection since 2016:
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b67067f1176d
>>
>> Wouldn't that remove the unused one?
> 
> Probably, if anyone bothered to use that, which they don't.
> 
> LD_DEAD_CODE_DATA_ELIMINATION is a symbol without a prompt, and from
> what I can see, nothing selects it.  Therefore, the symbol is always
> disabled, and so the feature never gets used in mainline kernels.

It looks like there are per-architecture linker scripts that need to be updated?
So if an architecture supports it, it's always done (well, it probes for the
toolchain supporting the flag). And if the architecture doesn't support it, the
linker script needs to be updated to mark sections with "I know nothing seems to
reference this at the ELF level but keep it anyway, we're pulling an assembly
trick".

> Brings up the obvious question - why is it there if it's completely
> unused?  (Maybe to cause confusion, and allowing a justification
> for __weak ?)

Presumably it will become the default on architectures as their linker scripts
are converted. Once they're all converted the config symbol can go away. (Given
the move to requiring gcc 4.7 or whatever it is, there can't be an architecture
depending on a toolchain that _doesn't_ support it after that point. I doubt you
can pair gcc 4.7 with a >12 year old binutils and expect good things...)

Rob

Re: [PATCH] Extract initrd free logic from arch-specific code.

[Rob Landley]

On 03/28/2018 11:48 AM, Russell King - ARM Linux wrote:
> On Wed, Mar 28, 2018 at 10:58:51AM -0500, Rob Landley wrote:
>> On 03/28/2018 10:26 AM, Shea Levy wrote:
>>> Now only those architectures that have custom initrd free requirements
>>> need to define free_initrd_mem.
>> ...
>>> --- a/arch/arc/mm/init.c
>>> +++ b/arch/arc/mm/init.c
>>> @@ -229,10 +229,3 @@ void __ref free_initmem(void)
>>>  {
>>> free_initmem_default(-1);
>>>  }
>>> -
>>> -#ifdef CONFIG_BLK_DEV_INITRD
>>> -void __init free_initrd_mem(unsigned long start, unsigned long end)
>>> -{
>>> -   free_reserved_area((void *)start, (void *)end, -1, "initrd");
>>> -}
>>> -#endif
>>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
>>> index 3f972e83909b..19d1c5594e2d 100644
>>> --- a/arch/arm/Kconfig
>>> +++ b/arch/arm/Kconfig
>>> @@ -47,6 +47,7 @@ config ARM
>>> select HARDIRQS_SW_RESEND
>>> select HAVE_ARCH_AUDITSYSCALL if (AEABI && !OABI_COMPAT)
>>> select HAVE_ARCH_BITREVERSE if (CPU_32v7M || CPU_32v7) && !CPU_32v6
>>> +   select HAVE_ARCH_FREE_INITRD_MEM
>>> select HAVE_ARCH_JUMP_LABEL if !XIP_KERNEL && !CPU_ENDIAN_BE32 && MMU
>>> select HAVE_ARCH_KGDB if !CPU_ENDIAN_BE32 && MMU
>>> select HAVE_ARCH_MMAP_RND_BITS if MMU
>>
>> Isn't this why weak symbols were invented?
> 
> Weak symbols means that we end up with both the weakly-referenced code
> and the arch code in the kernel image.  That's fine if the weak code
> is small.

The kernel's been able to build with link time garbage collection since 2016:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b67067f1176d

Wouldn't that remove the unused one?

Rob

Re: [PATCH] Extract initrd free logic from arch-specific code.

[Rob Landley]

On 03/28/2018 10:26 AM, Shea Levy wrote:
> Now only those architectures that have custom initrd free requirements
> need to define free_initrd_mem.
...
> --- a/arch/arc/mm/init.c
> +++ b/arch/arc/mm/init.c
> @@ -229,10 +229,3 @@ void __ref free_initmem(void)
>  {
>   free_initmem_default(-1);
>  }
> -
> -#ifdef CONFIG_BLK_DEV_INITRD
> -void __init free_initrd_mem(unsigned long start, unsigned long end)
> -{
> - free_reserved_area((void *)start, (void *)end, -1, "initrd");
> -}
> -#endif
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 3f972e83909b..19d1c5594e2d 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -47,6 +47,7 @@ config ARM
>   select HARDIRQS_SW_RESEND
>   select HAVE_ARCH_AUDITSYSCALL if (AEABI && !OABI_COMPAT)
>   select HAVE_ARCH_BITREVERSE if (CPU_32v7M || CPU_32v7) && !CPU_32v6
> + select HAVE_ARCH_FREE_INITRD_MEM
>   select HAVE_ARCH_JUMP_LABEL if !XIP_KERNEL && !CPU_ENDIAN_BE32 && MMU
>   select HAVE_ARCH_KGDB if !CPU_ENDIAN_BE32 && MMU
>   select HAVE_ARCH_MMAP_RND_BITS if MMU

Isn't this why weak symbols were invented?

Confused,

Rob

Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.

[Rob Landley]

On 03/23/2018 02:06 PM, Matthew Wilcox wrote:
> On Fri, Mar 23, 2018 at 02:00:24PM -0400, Rich Felker wrote:
>> On Fri, Mar 23, 2018 at 05:48:06AM -0700, Matthew Wilcox wrote:
>>> On Thu, Mar 22, 2018 at 07:36:36PM +0300, Ilya Smith wrote:
 Current implementation doesn't randomize address returned by mmap.
 All the entropy ends with choosing mmap_base_addr at the process
 creation. After that mmap build very predictable layout of address
 space. It allows to bypass ASLR in many cases. This patch make
 randomization of address on any mmap call.
>>>
>>> Why should this be done in the kernel rather than libc?  libc is perfectly
>>> capable of specifying random numbers in the first argument of mmap.
>>
>> Generally libc does not have a view of the current vm maps, and thus
>> in passing "random numbers", they would have to be uniform across the
>> whole vm space and thus non-uniform once the kernel rounds up to avoid
>> existing mappings.
> 
> I'm aware that you're the musl author, but glibc somehow manages to
> provide etext, edata and end, demonstrating that it does know where at
> least some of the memory map lies.

You can parse /proc/self/maps, but it's really expensive and disgusting.

Rob

powerpc64 kernel panic if you disable CONFIG_PPC_TRANSACTIONAL_MEM?

[Rob Landley]

I just added a ppc64 target to https://github.com/landley/mkroot which
means I built 4.14 with the attached miniconfig and ran it with the
attached qemu command line, and it works fine as is but if you remove
the transactional mem line from the config the kernel panics instead
of launching a shell prompt:

init[1]: unhandled signal 4 at 10001a04 nip 10001a04
lr 1002ebe8 code 1
Kernel panic - not syncing: Attempted to kill init! exitcode=0x0004

CPU: 0 PID: 1 Comm: init Not tainted 4.14.0 #1
Call Trace:
[ce02fa40] [c04ba730] dump_stack+0xb0/0xf0 (unreliable)
[ce02fa80] [c00602a0] panic+0x138/0x2f8
[ce02fb20] [c006541c] do_exit+0xa9c/0xaa0
[ce02fbe0] [c00654d8] do_group_exit+0x58/0xf0
[ce02fc20] [c0073274] get_signal+0x1c4/0x6b0
[ce02fd10] [c00142a0] do_signal+0x60/0x290
[ce02fe00] [c001461c] do_notify_resume+0x8c/0xd0
[ce02fe30] [c000b630] ret_from_except_lite+0x5c/0x60
Rebooting in 1 seconds..

Rob


powerpc64le.miniconf
Description: Binary data


qemu-powerpc64le.sh
Description: Bourne shell script

Re: [PATCH v3] Make initramfs honor CONFIG_DEVTMPFS_MOUNT

[Rob Landley]

On 09/17/2017 08:51 AM, Henrique de Moraes Holschuh wrote:
> On Sat, 16 Sep 2017, Rob Landley wrote:
>> So, I added a workaround with a printk in hopes of embarassing them into
>> someday fixing it.
> 
> Oh, it will be fixed in Debian alright.

Cool!

But part of the problem is people upgrade the kernel on existing
deployed root filesystems, some of which are a fork off of a fork off of
debian, so we won't exhaust the broken userspace for probably a couple
years.

I'd put it in feature-removal-schedule.txt but Linus zapped that, so...

> I am just waiting the issue to
> settle a bit to file the bug reports, or maybe even send in the Debian
> patches myself (note that I am not responsible for the code in question,
> so I am not wearing a brown paperbag at this time).  Even if I didn't do
> it, there are several other Debian Developers reading LKML that could do
> it (provided they noticed this specific thread and are aware of the
> situation) :p

There was a previous thread last merge window they didn't notice. I was
hoping the warning would be obvious enough. :)

> I can even push for the fixes to be accepted into the stable and
> oldstable branches of Debian, but that can take anything from a few
> weeks to several months, due to the way our stable releases work.  But
> it would eventually happen.
> 
> Whether such fixes will ever make it to LTS branches, especially
> Ubuntu's, *that* I don't know.

I have no idea what that powerpc system was, the guy didn't say...

Rob

Re: [PATCH v3] Make initramfs honor CONFIG_DEVTMPFS_MOUNT

[Rob Landley]

On 09/14/2017 04:17 AM, Christophe LEROY wrote:
> Le 14/09/2017 à 01:51, Rob Landley a écrit :
>> From: Rob Landley <r...@landley.net>
>>
>> Make initramfs honor CONFIG_DEVTMPFS_MOUNT, and move
>> /dev/console open after devtmpfs mount.
>>
>> Add workaround for Debian bug that was copied by Ubuntu.
> 
> Is that a bug only for Debian ? Why ?

Look down, specifically this bit:

>> v2 discussion:
>> http://lkml.iu.edu/hypermail/linux/kernel/1705.2/05611.html

That's some discussion of version 2 of this patch, which was merged for
a while last dev cycle, then backed out again because it triggered the
same bug in a number of system init scripts:

  http://lkml.iu.edu/hypermail/linux/kernel/1705.2/07072.html
  http://lkml.iu.edu/hypermail/linux/kernel/1705.3/01182.html
  http://lkml.iu.edu/hypermail/linux/kernel/1705.3/01505.html
  http://lkml.iu.edu/hypermail/linux/kernel/1705.3/01320.html

All of whom copied the broken error "recovery" path from debian. If they
checked whether it was already mounted, or didn't _blank_ the /dev
directory in response to mounting the exact same filesystem over itself
giving -EBUSY, the system would work fine. Heck, if you built a kernel
with a static /dev in initramfs and no devtmpfs configured in, the
script would break things exactly the same way. The breakage is that
script takes a hammer to a perfectly functional /dev directory and then
continues the boot with an empty /dev. That's bonkers.

> Why should a Debian bug be fixed by a workaround in the mainline kernel ?

That was my argument last time, and the answer was "Breaking userspace
is bad, mmmkay." Even when userspace is doing something REALLY OBVIOUSLY
STUPID and it is _clearly_ their fault, as long as they got there first
they've established the status quo and it doesn't matter how silly it is.

This was explicitly stated to me here:

  http://lkml.iu.edu/hypermail/linux/kernel/1705.3/03292.html

I.E. don't argue with me, argue with him. :)

So, I added a workaround with a printk in hopes of embarassing them into
someday fixing it.

Rob

[PATCH v3] Make initramfs honor CONFIG_DEVTMPFS_MOUNT

[Rob Landley]

From: Rob Landley <r...@landley.net>

Make initramfs honor CONFIG_DEVTMPFS_MOUNT, and move
/dev/console open after devtmpfs mount.

Add workaround for Debian bug that was copied by Ubuntu.

Signed-off-by: Rob Landley <r...@landley.net>
---

v2 discussion: http://lkml.iu.edu/hypermail/linux/kernel/1705.2/05611.html

 drivers/base/Kconfig |   14 --
 fs/namespace.c   |   14 ++
 init/main.c  |   15 +--
 3 files changed, 27 insertions(+), 16 deletions(-)

diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
index f046d21..97352d4 100644
--- a/drivers/base/Kconfig
+++ b/drivers/base/Kconfig
@@ -48,16 +48,10 @@ config DEVTMPFS_MOUNT
bool "Automount devtmpfs at /dev, after the kernel mounted the rootfs"
depends on DEVTMPFS
help
- This will instruct the kernel to automatically mount the
- devtmpfs filesystem at /dev, directly after the kernel has
- mounted the root filesystem. The behavior can be overridden
- with the commandline parameter: devtmpfs.mount=0|1.
- This option does not affect initramfs based booting, here
- the devtmpfs filesystem always needs to be mounted manually
- after the rootfs is mounted.
- With this option enabled, it allows to bring up a system in
- rescue mode with init=/bin/sh, even when the /dev directory
- on the rootfs is completely empty.
+ Automatically mount devtmpfs at /dev on the root filesystem, which
+ lets the system to come up in rescue mode with [rd]init=/bin/sh.
+ Override with devtmpfs.mount=0 on the commandline. Initramfs can
+ create a /dev dir as needed, other rootfs needs the mount point.
 
 config STANDALONE
bool "Select only drivers that don't need compile-time external 
firmware"
diff --git a/fs/namespace.c b/fs/namespace.c
index f8893dc..06057d7 100644
--- a/fs/namespace.c
+++ b/fs/namespace.c
@@ -2417,7 +2417,21 @@ static int do_add_mount(struct mount *newmnt, struct 
path *path, int mnt_flags)
err = -EBUSY;
if (path->mnt->mnt_sb == newmnt->mnt.mnt_sb &&
path->mnt->mnt_root == path->dentry)
+   {
+   if (IS_ENABLED(CONFIG_DEVTMPFS_MOUNT) &&
+   !strcmp(path->mnt->mnt_sb->s_type->name, "devtmpfs"))
+   {
+   /* Debian's kernel config enables DEVTMPFS_MOUNT, then
+  its initramfs setup script tries to mount devtmpfs
+  again, and if the second mount-over-itself fails
+  the script overmounts a tmpfs on /dev to hide the
+  existing contents, then boot fails with empty /dev. 
*/
+   printk(KERN_WARNING "Debian bug workaround for devtmpfs 
overmount.");
+
+   err = 0;
+   }
goto unlock;
+   }
 
err = -EINVAL;
if (d_is_symlink(newmnt->mnt.mnt_root))
diff --git a/init/main.c b/init/main.c
index 0ee9c686..0d8e5ec 100644
--- a/init/main.c
+++ b/init/main.c
@@ -1065,12 +1065,6 @@ static noinline void __init kernel_init_freeable(void)
 
do_basic_setup();
 
-   /* Open the /dev/console on the rootfs, this should never fail */
-   if (sys_open((const char __user *) "/dev/console", O_RDWR, 0) < 0)
-   pr_err("Warning: unable to open an initial console.\n");
-
-   (void) sys_dup(0);
-   (void) sys_dup(0);
/*
 * check if there is an early userspace init.  If yes, let it do all
 * the work
@@ -1082,8 +1076,17 @@ static noinline void __init kernel_init_freeable(void)
if (sys_access((const char __user *) ramdisk_execute_command, 0) != 0) {
ramdisk_execute_command = NULL;
prepare_namespace();
+   } else if (IS_ENABLED(CONFIG_DEVTMPFS_MOUNT)) {
+   sys_mkdir("/dev", 0755);
+   devtmpfs_mount("/dev");
}
 
+   /* Open the /dev/console on the rootfs, this should never fail */
+   if (sys_open((const char __user *) "/dev/console", O_RDWR, 0) < 0)
+   pr_err("Warning: unable to open an initial console.\n");
+   (void) sys_dup(0);
+   (void) sys_dup(0);
+
/*
 * Ok, we have completed the initial bootup, and
 * we're essentially up and running. Get rid of the

Re: [linux-next] PPC Lpar fail to boot with error hid: module verification failed: signature and/or required key missing - tainting kernel

[Rob Landley]

On 05/25/2017 04:24 PM, Stephen Rothwell wrote:
> Hi Michael,
> 
> On Thu, 25 May 2017 23:02:06 +1000 Michael Ellerman  
> wrote:
>>
>> It'll be:
>>
>> ee35011fd032 ("initramfs: make initramfs honor CONFIG_DEVTMPFS_MOUNT")
>
> And Andrew has asked me to drop that patch from linux-next which will
> happen today.

What approach do the kernel developers suggest I take here?

I would have thought letting it soak in linux-next for a release so
people could fix userspace bugs would be the next step, but this sounds
like that's not an option?

Is the behavior the patch implements wrong?

Rob

Re: [PATCH 1/3] futex: remove duplicated code

[Rob Landley]

On 03/04/2017 07:05 AM, Russell King - ARM Linux wrote:
> On Fri, Mar 03, 2017 at 01:27:10PM +0100, Jiri Slaby wrote:
>> diff --git a/kernel/futex.c b/kernel/futex.c
>> index b687cb22301c..c5ff9850952f 100644
>> --- a/kernel/futex.c
>> +++ b/kernel/futex.c
>> @@ -1457,6 +1457,42 @@ futex_wake(u32 __user *uaddr, unsigned int flags, int 
>> nr_wake, u32 bitset)
>>  return ret;
>>  }
>>  
>> +static int futex_atomic_op_inuser(int encoded_op, u32 __user *uaddr)
>> +{
>> +int op = (encoded_op >> 28) & 7;
>> +int cmp = (encoded_op >> 24) & 15;
>> +int oparg = (encoded_op << 8) >> 20;
>> +int cmparg = (encoded_op << 20) >> 20;
> 
> Hmm.  oparg and cmparg look like they're doing these shifts to get sign
> extension of the 12-bit values by assuming that "int" is 32-bit -
> probably worth a comment, or for safety, they should be "s32" so it's
> not dependent on the bit-width of "int".

I thought Linux depended on the LP64 standard for all architectures?

Standard: http://www.unix.org/whitepapers/64bit.html
Rationale: http://www.unix.org/version2/whatsnew/lp64_wp.html

So int has a defined bit width (32) on linux?

Rob

Re: [RFC] fs: add userspace critical mounts event support

[Rob Landley]

On 09/02/2016 07:20 PM, Luis R. Rodriguez wrote:
> kernel_read_file_from_path() can try to read a file from
> the system's filesystem. This is typically done for firmware
> for instance, which lives in /lib/firmware. One issue with
> this is that the kernel cannot know for sure when the real
> final /lib/firmare/ is ready, and even if you use initramfs
> drivers are currently initialized *first* prior to the initramfs
> kicking off.

Why?

> During init we run through all init calls first
> (do_initcalls()) and finally the initramfs is processed via
> prepare_namespace():

What's the downside of moving initramfs cpio extraction earlier in the boot?

I did some shuffling around of those code to make initmpfs work, does
anybody know why initramfs extraction _before_ we initialize drivers
would be a bad thing? (The cpio is in memory, either linked into the
kernel or from the bootloader. No drivers are needed to extract it,
that's sort of the point.)

The only things I can think of are memory churn (large contiguous
physical page allocations), or if a driver somehow got us access to more
physical memory?

Rob

Re: [PATCH 05/44] mfd: as3722: Drop reference to pm_power_off from devicetree bindings

[Rob Landley]

On 10/07/14 00:28, Guenter Roeck wrote:
 Devicetree bindings are supposed to be operating system independent
 and should thus not describe how a specific functionality is implemented
 in Linux.

So your argument is that linux/Documentation/devicetree/bindings should
not be specific to Linux. Merely hosted in the Linux kernel source
repository.

Well that's certainly a point of view.

Rob
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 05/44] mfd: as3722: Drop reference to pm_power_off from devicetree bindings

[Rob Landley]

On 10/07/14 11:59, David Daney wrote:
 On 10/07/2014 09:31 AM, Guenter Roeck wrote:
 On Tue, Oct 07, 2014 at 11:21:11AM -0500, Rob Landley wrote:
 On 10/07/14 00:28, Guenter Roeck wrote:
 Devicetree bindings are supposed to be operating system independent
 and should thus not describe how a specific functionality is
 implemented
 in Linux.

 So your argument is that linux/Documentation/devicetree/bindings should
 not be specific to Linux. Merely hosted in the Linux kernel source
 repository.

 Well that's certainly a point of view.

 Not specifically my argument, really, and nothing new either. But,
 yes, I do
 think that devicetree bindings descriptions should not include
 implementation
 details, especially since those may change over time (as is the case
 here).

 
 I fully agree.
 
 Many device trees come from outside the kernel (i.e. they are supplied
 by the system boot environment).  Obviously these device trees cannot be
 changed at the whim of kernel developers, *and* it is perfectly
 reasonable to think that software other than the Linux kernel will run
 on this type of system too.
 
 So yes, it is really true, device trees are not a Linux kernel private
 implementation detail, they are really an external ABI that, although
 documented in the kernel source tree, cannot be changed in incompatible
 ways as time progresses.

Ah. Existing thing with backstory among the in-crowd, so I'll assume
git subtree was previously suggested and you had that discussion
already and decided against it.

Carry on,

Rob
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: bit fields data tearing

[Rob Landley]

On Wed, Sep 10, 2014 at 3:18 PM, H. Peter Anvin h...@zytor.com wrote:
 On 09/08/2014 10:52 AM, One Thousand Gnomes wrote:

 I think the whole removing Alpha EV5 support is basically bonkers. Just
 use set_bit in the tty layer. Alpha will continue to work as well as it
 always has done and you won't design out support for any future processor
 that turns out not to do byte aligned stores.


 I think it's pretty safe to say such a processor is unlikely to ever be
 created, for the same reason there weren't any 48-bit computers when
 32-bit computers ran out of steam: it caused more problems than it
 solved, and Alpha pretty much proved that.  The engineering advantages
 would have to be so overwhelmingly in favor for someone to want to walk
 down that road again.

 -hpa

I note for the record I'm trying to get basic Alpha support working in
http://landley.net/aboriginal/about.html now that qemu at least offers
a qemu-system-alpha, and if I do get it working I may take a stab at
adding alpha support to musl-libc.

It's not just that I want to get cross platform testing of package
builds working on a convenient/reproducible/portable way on as many
different targets as I can. My project is designed the way it is
because I think losing the ability to reproduce things from first
principles (and thus understand why it was done that way in the first
place) is a _bad_idea_. And an increasingly real-world problem, see
http://wrttn.in/04af1a for example. (And the way NASA lost the plans
for the Saturn V rocket... In fact scientists' general disinclination
to reproduce old experimental results to see if they were actually
true or not comes up on a regular basis, most recent I saw was
http://www.theglobeandmail.com/life/health-and-fitness/health/the-curious-case-of-the-cyclists-unshaved-legs/article20370814/
)

Of course Peter has consistently dismissed my concerns as academic:

http://lkml.iu.edu/hypermail/linux/kernel/0802.1/4400.html

Personally, I hope the projects I work on _do_ outlive me, an try to
make it easy for newbies to recapitulate phylogeny. That's why I
thought requiring perl dependencies to build was a bad idea, and why I
thought removing 386 support entirely (instead of restricting it to
UP) was a bad idea. The idea that Linux no longer needs to build on
the original machine Linus designed it for, and now it no longer needs
to work on the machine the arch directory was created for (and the
first 64 bit machine)... These positions would appear to have a single
consistent proponent, with whom I disagree.

Oh well, just wanted to get that out there,

Rob
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

PMAC_ZILOG serial driver locks up.

[Rob Landley]

The powerpc systems I emulate under qemu use the mac99 board 
emulation, which routes the serial console through a PMAC_ZILOG serial 
chip.

It got screwed up by Alan Cox's refactoring of the tty layer in 2.6.28:

  http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-December/078700.html

And then partially fixed here:

  http://www.mail-archive.com/linuxppc-dev@lists.ozlabs.org/msg40477.html

However, if significant input and output traffic overlaps, the serial 
port locks up.  Here's a test for that.  Grab this tarball:

  http://landley.net/aboriginal/downloads/binaries/system-image-powerpc.tar.bz2

And do this:

  echo -e \necho hello world | ./run-emulator.sh

That's echo a line of 20 spaces, a newline, and a command to see
if it makes it through to the comand prompt.

Data makes it out the serial console right up until init launches
(and interrupts are enabled), then it locks hard.

if you just ./run-emulator.sh directly and don't type anything until
you get a shell prompt, it works fine.  It's the data crossing in
both directions at once that screws the driver up.

Trivially reproducible.  I've tested back to 2.6.32 and it was doing
it back then.  (2.6.31 was a build break.)

Rob
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] pmac_zilog: Workaround problem due to interrupt on closed port

[Rob Landley]

On Sunday 10 January 2010 21:51:42 Benjamin Herrenschmidt wrote:
 It seems that in qemu, we can see an interrupt in R3 despite the
 fact that it's masked in W1. The chip doesn't actually issue an
 interrupt, but we can see it when taking an interrupt for the
 other channel. This may be a qemu bug ... or not, so let's be
 safe and avoid calling into the UART layer when that happens which
 woulc cause a crash.

 Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org

Acked-by: Rob Landley r...@landley.net

Tested it, and it worked for me.

Thanks,

Rob
-- 
Latency is more important than throughput. It's that simple. - Linus Torvalds
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] Re: ZILOG serial port broken in 2.6.32

[Rob Landley]

On Sunday 10 January 2010 21:02:16 Benjamin Herrenschmidt wrote:
 On Sat, 2010-01-09 at 02:17 -0600, Rob Landley wrote:
  On Thursday 07 January 2010 21:00:43 Benjamin Herrenschmidt wrote:
Ok, here's the fix.  It's not the _right_ fix, but it Works For Me
(tm) and I'll leave it to you guys to figure out what this _means_:
  
   I've failed to reproduce so far on both a Wallstreet powerbook (similar
   generation and chipset as your beige G3) and a G5 with an added serial
   port using current upstream...
  
   Can you verify it's still there ? I might be able to reproduce on a
   Beige G3 as well next week.
 
  It's still there on qemu 0.11.0's g3beige emulation when you use
  CONFIG_SERIAL_PMACZILOG as the serial console.  (QEMU 0.10.x used a 16550
  serial chip for its g3beige emulation instead of the actual ZILOG one.) 
  Still dunno if it's a qemu or bug or a kernel bug, I just know that
  kernel patch fixes it for me, and it comes back without the patch.
 
  I tested 2.6.32.  Haven't tried the 2.6.32.3 but don't see why it would
  change this...

 Ok so I compiled qemu and things are a bit strange.

 How do you get the output of both channels of the serial port with it ?

 If I use -nographics, what happens is that OpenBIOS, for some reason,
 tells qemu that the console on the second channel of the ESCC.

Instead of -nographic, you could try -serial stdio instead?

 I see my kernel messages in the console if I do console=ttyPZ0 but the
 debug stuff goes where udbg initializes it, which is where OpenBIOS says
 the FW console is, which is channel B and I don't know how to see that
 with qemu.

I'm just trying to get a serial console, which is why I'm booting the sucker 
with:

qemu-system-ppc -M g3beige -nographic -no-reboot -kernel zImage-powerpc -hda 
image-powerpc.sqf -append root=/dev/hda rw init=/usr/sbin/init.sh panic=1 
PATH=/usr/bin console=ttyS0

I didn't even know there were more debug messages...

I have CONFIG_SERIAL_PMACZILOG_TTYS=y of course:

pmac_zilog: 0.6 (Benjamin Herrenschmidt b...@kernel.crashing.org)
ttyS0 at MMIO 0x80813020 (irq = 16) is a Z85c30 ESCC - Serial port
ttyS1 at MMIO 0x80813000 (irq = 17) is a Z85c30 ESCC - Serial port

CONFIG_SERIO=y
CONFIG_SERIAL_PMACZILOG=y
CONFIG_SERIAL_PMACZILOG_TTYS=y
CONFIG_SERIAL_PMACZILOG_CONSOLE=y

 I do see it crash due to a message from the kernel but I can't get into
 xmon which is a pain.

Does the -serial stdio thing help?

(I know to switch between screens in the qemu x11 window, it's ctrl-alt-number 
(so ctrl-alt-1, ctrl-alt-2, and so on.  I really don't use 'em much, though.)

 If I modify the kernel to force udbg on channel A (same channel as the
 console), then the problem doesn't appear (it doesn't crash) :-)

You can attach gdb to qemu via the qemu -s option and then in gdb use the 
target remote stuff like you would with gdbserver.  It acts a bit like you've 
connected it to a jtag through openocd, if that helps...

(I know qemu has many, many options I don't really use much.)

 Cheers
 Ben.

Rob
-- 
Latency is more important than throughput. It's that simple. - Linus Torvalds
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] Re: ZILOG serial port broken in 2.6.32

[Rob Landley]

On Thursday 07 January 2010 21:00:43 Benjamin Herrenschmidt wrote:
  Ok, here's the fix.  It's not the _right_ fix, but it Works For Me (tm)
  and I'll leave it to you guys to figure out what this _means_:

 I've failed to reproduce so far on both a Wallstreet powerbook (similar
 generation and chipset as your beige G3) and a G5 with an added serial
 port using current upstream...

 Can you verify it's still there ? I might be able to reproduce on a
 Beige G3 as well next week.

It's still there on qemu 0.11.0's g3beige emulation when you use 
CONFIG_SERIAL_PMACZILOG as the serial console.  (QEMU 0.10.x used a 16550 
serial chip for its g3beige emulation instead of the actual ZILOG one.)  Still 
dunno if it's a qemu or bug or a kernel bug, I just know that kernel patch 
fixes it for me, and it comes back without the patch.

I tested 2.6.32.  Haven't tried the 2.6.32.3 but don't see why it would change 
this...

Rob
-- 
Latency is more important than throughput. It's that simple. - Linus Torvalds
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH] Re: ZILOG serial port broken in 2.6.32

[Rob Landley]

On Sunday 06 December 2009 19:10:48 Benjamin Herrenschmidt wrote:
 On Sun, 2009-12-06 at 01:01 -0600, Rob Landley wrote:
  Trying again with a few likely-looking cc's from the MAINTAINERS file:
 
  Summary:
 
  The PMACZILOG serial driver last worked in 2.6.28.  It was broken by
  commit f751928e0ddf54ea4fe5546f35e99efc5b5d9938 by Alan Cox making bits
  of the tty layer dynamically allocated.  The PMACZILOG driver wasn't
  properly converted, it works with interrupts disabled (for boot
  messages), but as soon as interrupts are enabled (PID 1 spawns) the next
  write to the serial console panics the kernel.

 Ah looks like I missed that... I'll dig. Thanks for the report.

 Cheers,
 Ben.

Ok, here's the fix.  It's not the _right_ fix, but it Works For Me (tm) and I'll
leave it to you guys to figure out what this _means_:

Signed-off-by: Rob Landley r...@landley.net

diff -ru build/packages/linux/drivers/serial/serial_core.c 
build/packages/linux2/drivers/serial/serial_core.c
--- build/packages/linux/drivers/serial/serial_core.c   2009-12-02 
21:51:21.0 -0600
+++ build/packages/linux2/drivers/serial/serial_core.c  2009-12-08 
06:17:06.0 -0600
@@ -113,7 +113,7 @@
 static void uart_tasklet_action(unsigned long data)
 {
struct uart_state *state = (struct uart_state *)data;
-   tty_wakeup(state-port.tty);
+   if (state-port.tty) tty_wakeup(state-port.tty);
 }
 
 static inline void

That one line workaround makes the panic go away, and things seem to work fine 
from there.

I note that pmac_zilog.c function pmz_receiv_chars() has the following chunk:

/* Sanity check, make sure the old bug is no longer happening */
if (uap-port.state == NULL || uap-port.state-port.tty == NULL) {
WARN_ON(1);
(void)read_zsdata(uap);
return NULL;
}

Which doesn't catch this because it's the write code path (not the read code 
path) that's running into 
this.

Rob
-- 
Latency is more important than throughput. It's that simple. - Linus Torvalds
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: ZILOG serial port broken in 2.6.32

[Rob Landley]

On Sunday 06 December 2009 19:10:48 Benjamin Herrenschmidt wrote:
 On Sun, 2009-12-06 at 01:01 -0600, Rob Landley wrote:
  Trying again with a few likely-looking cc's from the MAINTAINERS file:
 
  Summary:
 
  The PMACZILOG serial driver last worked in 2.6.28.  It was broken by
  commit f751928e0ddf54ea4fe5546f35e99efc5b5d9938 by Alan Cox making bits
  of the tty layer dynamically allocated.  The PMACZILOG driver wasn't
  properly converted, it works with interrupts disabled (for boot
  messages), but as soon as interrupts are enabled (PID 1 spawns) the next
  write to the serial console panics the kernel.

 Ah looks like I missed that... I'll dig. Thanks for the report.

Ooh, thanks!

I've been digging into it myself this weekend, but I don't understand any of 
this code, so it's going slowly...

Rob
-- 
Latency is more important than throughput. It's that simple. - Linus Torvalds

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

4th attempt: ZILOG serial console broken in 2.6.32

[Rob Landley]

My posts are showing up in the archive...

http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-October/076727.html
http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-October/077059.html
http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-December/078498.html

But no replies.  Is there somebody specific I should be addressing this to?

Rob
-- 
Latency is more important than throughput. It's that simple. - Linus Torvalds
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

ZILOG serial port broken in 2.6.32

[Rob Landley]

Trying again with a few likely-looking cc's from the MAINTAINERS file:

Summary: 

The PMACZILOG serial driver last worked in 2.6.28.  It was broken by commit 
f751928e0ddf54ea4fe5546f35e99efc5b5d9938 by Alan Cox making bits of the tty 
layer dynamically allocated.  The PMACZILOG driver wasn't properly converted, 
it works with interrupts disabled (for boot messages), but as soon as 
interrupts are enabled (PID 1 spawns) the next write to the serial console 
panics the kernel.

Up through 2.6.31 I could fix it by reverting that patch (which isn't a proper 
fix but it made it work).  In 2.6.32 the patch no longer cleanly reverts.

I reported the issue here (with a cut and paste of the panic trace):

  http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-October/076727.html

And reported the results of bisecting the issue here:

  http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-October/077059.html

I noted that 2.6.32-pre had broken my workaround here:

  http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-December/078498.html

Background:

I have a project that builds the same native Linux development environment for 
multiple hardware targets.  It aims to support all the targets QEMU system 
emulation can boot Linux under, although I'm still a few short.  It creates a 
cross compiler and uses it to build a root filesystem from uClibc and busybox, 
adds a native toolchain, and packages it up into a system image (squashfs, 
ext2, or initramfs depending on the config you selected).

Anyone can then boot the resulting system image under qemu and use it to wet 
source and compile stuff natively.   (If the cross compiler is in the $PATH on 
the host, it will even configure distcc to call out to that cross compiler to 
speed up the builds to merely painfully slow, with some pretense of SMP 
scalability).

Prebuilt binaries of all the targets I had working last release are at 
http://impactlinux.com/fwl/downloads/binaries (with obligatory screenshots at 
http://impactlinux.com/fwl/screenshots/ even).  They use the 2.6.31 kernel.

It supports powerpc.  If you look at system-image-powerpc.tar.bz2 you'll see 
that the run-emulator.sh script has been using qemu's g3beige target board 
emulation, which provides all the hardware I need for a development 
environment (hard drive, network card, at least 256 megs of memory, working 
clock chip, and of course a serial console).  Userspace doesn't care what I 
use, it's the same processor instruction set and same C library either way, 
the board emulation's just something to boot it on, only the kernel .config 
really cares as long as the appropriate resources are there.

Unfortunately, g3beige seems to have bit-rotted, and thus the serial console 
is now panicing.  This is a regression, and thus blocking a release of my 
project using the 2.6.32 kernel.  Is this of interest to anyone other than me?

Rob
-- 
Latency is more important than throughput. It's that simple. - Linus Torvalds
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Serial console under current qemu is still an issue.

[Rob Landley]

Last month I reported a serial console problem:
  http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-October/076727.html

And bisected the problem to find the patch to revert that fixed it for me:
  http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-October/077059.html

The bug still hasn't been fixed, but reverting the patch stopped working during 
this developmpent series (because it no longer cleanly reverse applies).

Would anybody like to comment on this?  I can provide a qemu-based test 
environment if you'd like, it's easily reproducible...

Rob
-- 
Latency is more important than throughput. It's that simple. - Linus Torvalds


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Serial console under current qemu: bisected.

[Rob Landley]

Last week I reported a bug:

http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-October/076727.html

I managed to drill past the unrelated breakage and bisect it back to the 
relevant commit: It was introduced leading up to 2.6.29, by commit 
f751928e0ddf54ea4fe5546f35e99efc5b5d9938 written by Alan Cox.

It seems to make the kernel panic as soon as IRQs are enabled in the presence 
of CONFIG_SERIAL_PMACZILOG=y.  It's trivially reproducible under current qemu-
git.  Kernels before that boot to a shell prompt, kernels after that panic as 
soon as init launches.  (They work fine when you're not using a serial 
console.)

Rob
-- 
Latency is more important than throughput. It's that simple. - Linus Torvalds
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Serial console under current qemu?

[Rob Landley]

Has anybody gotten a serial console to work under current qemu (ala the 0.11.0 
release)?

I've tried the 2.6.30 and 2.6.31.4 kernels, and in both cases both the 
bootloader and the kernel's boot messages write to the serial console just 
fine, but as soon as userspace tries to write to /dev/console the kernel panics 
with:

ieee1394: raw1394: /dev/raw1394 device initialized
mice: PS/2 mouse device common for all mice
TCP cubic registered
NET: Registered protocol family 17
VFS: Mounted root (squashfs filesystem) readonly on device 3:0.
Freeing unused kernel memory: 168k init
Type exit when done.Unable to handle kernel paging request for data at address 
0x0084
Faulting instruction address: 0xc012dc9c
Oops: Kernel access of bad area, sig: 11 [#1]
PowerMac
NIP: c012dc9c LR: c01467c0 CTR: c01467ac
REGS: cf831be0 TRAP: 0300   Not tainted  (2.6.31.4)
MSR: 9032 EE,ME,IR,DR  CR: 42224022  XER: 
DAR: 0084, DSISR: 4000
TASK = cf82f8f0[1] 'init.sh' THREAD: cf83
GPR00: c01467c0 cf831c90 cf82f8f0  cf82f920 cf824e40 91a8bb6b  
GPR08: 0001 0001 c01467ac  90778e6b 100834dc 0127e698 1005b940 
GPR16: 100859a0  1007d074 100429a4  c02dc614 c0281678 c02dc498 
GPR24: 000a cf83 c0321e00 0005 0014 c0321e00 c02dc638  
NIP [c012dc9c] tty_wakeup+0x14/0xa0
LR [c01467c0] uart_tasklet_action+0x14/0x24
Call Trace:
[cf831c90] [c012dcbc] tty_wakeup+0x34/0xa0 (unreliable)
[cf831ca0] [c01467c0] uart_tasklet_action+0x14/0x24
[cf831cb0] [c003123c] tasklet_action+0x80/0x104
[cf831cd0] [c0031368] __do_softirq+0xa8/0x120
[cf831d10] [c0006ea4] do_softirq+0x58/0x5c
[cf831d20] [c00311b8] irq_exit+0x98/0x9c
[cf831d30] [c0006f44] do_IRQ+0x9c/0xb4
[cf831d50] [c0012b60] ret_from_except+0x0/0x1c
--- Exception: 501 at uart_start+0x24/0x38
LR = uart_start+0x20/0x38
[cf831e20] [c0148130] uart_write+0xc0/0xe4
[cf831e50] [c0130bc0] n_tty_write+0x1d4/0x430
[cf831eb0] [c012db30] tty_write+0x188/0x268
[cf831ef0] [c0082314] vfs_write+0xb4/0x188
[cf831f10] [c008287c] sys_write+0x4c/0x90
[cf831f40] [c0012494] ret_from_syscall+0x0/0x40
--- Exception: c01 at 0x48039f8c
LR = 0x4804c4bc
Instruction dump:
7c0803a6 4e800020 80010024 bba10014 38210020 7c0803a6 4bfffd24 9421fff0 
7c0802a6 bfc10008 7c7f1b78 90010014 80030084 70090020 4082002c 387f00e0 
Kernel panic - not syncing: Fatal exception in interrupt
Call Trace:
[cf831b10] [c0008d74] show_stack+0x4c/0x16c (unreliable)
[cf831b50] [c002b600] panic+0x90/0x160
[cf831ba0] [c0010064] die+0x148/0x154
[cf831bc0] [c0015b34] bad_page_fault+0x90/0xd8
[cf831bd0] [c001294c] handle_page_fault+0x7c/0x80
--- Exception: 300 at tty_wakeup+0x14/0xa0
LR = uart_tasklet_action+0x14/0x24
[cf831c90] [c012dcbc] tty_wakeup+0x34/0xa0 (unreliable)
[cf831ca0] [c01467c0] uart_tasklet_action+0x14/0x24
[cf831cb0] [c003123c] tasklet_action+0x80/0x104
[cf831cd0] [c0031368] __do_softirq+0xa8/0x120
[cf831d10] [c0006ea4] do_softirq+0x58/0x5c
[cf831d20] [c00311b8] irq_exit+0x98/0x9c
[cf831d30] [c0006f44] do_IRQ+0x9c/0xb4
[cf831d50] [c0012b60] ret_from_except+0x0/0x1c
--- Exception: 501 at uart_start+0x24/0x38
LR = uart_start+0x20/0x38
[cf831e20] [c0148130] uart_write+0xc0/0xe4
[cf831e50] [c0130bc0] n_tty_write+0x1d4/0x430
[cf831eb0] [c012db30] tty_write+0x188/0x268
[cf831ef0] [c0082314] vfs_write+0xb4/0x188
[cf831f10] [c008287c] sys_write+0x4c/0x90
[cf831f40] [c0012494] ret_from_syscall+0x0/0x40
--- Exception: c01 at 0x48039f8c
LR = 0x4804c4bc
Rebooting in 1 seconds..

I've reproduced this with my Firmware Linux project (download 
http://impactlinux.com/fwl/downloads/binaries/system-image-powerpc.tar.bz2 , 
extract it, run sed -i 's...@-hda @-hdc @' run-emulator.sh because qemu's 
device tree layout changed betwee 0.10.0 and 0.11.0, and then ./run-
emulator.sh).

I've also reproduced it with debian's kernel .config and root filesystem image, 
details on that posted here:
  http://lists.gnu.org/archive/html/qemu-devel/2009-10/msg01056.html

(Oddly, with debian's kernel .config -hda sets /dev/hda instead of /dev/hdc, I 
need to track down why so I can fix it in my project's .config.)

The debian image boots fine with a graphics console, it's just trying to use 
the serial console that panics it.  I don't know if this is a qemu device 
emulation issue, a kernel issue, or maybe something to do with the device tree 
qemu's openbios is feeding in at boot time?  I'm stumped.

Er... Help?  Pretty please?

Rob
-- 
Latency is more important than throughput. It's that simple. - Linus Torvalds
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RFC PATCH 00/12] Merge common OpenFirmware device tree code

[Rob Landley]

On Tuesday 06 October 2009 23:49:04 Grant Likely wrote:

 However, I've completely devoted to this work for at least the next
 two months, so there are plenty more patches to follow.  Once I've
 got all the common code merged between Microblaze, PowerPC and Sparc
 I'll be fix the endian problems and making it easily usable by other
 architectures like ARM and MIPS.  Lots of work to be done.

Is there any news on getting QEMU to parse a device tree to figure out what 
hardware to emulate?  (I.E. using the device tree code to let qemu provide 
configurable board emulations instead of hardwiring them in C code?)

Also, what would be involved in getting x86 to (at least have the option to) 
use the device tree stuff?

Rob
-- 
Latency is more important than throughput. It's that simple. - Linus Torvalds
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: Can't boot 2.6.30 powerpc kernel under qemu.

[Rob Landley]

On Saturday 27 June 2009 21:33:09 Jeremy Kerr wrote:
 Hi Rob,

  I bisected the problem in the linux kernel repository, and wound up
  here:
 
  60ee031940c1b09c137b617a8829e2f081961fe0 is first bad commit
  commit 60ee031940c1b09c137b617a8829e2f081961fe0
  Author: Jeremy Kerr j...@ozlabs.org
  Date:   Tue Feb 17 11:44:14 2009 +1100
 
  powerpc/spufs: Use correct return value for spu_handle_mm_fault

 I think it's very unlikely that this commit would be causing the
 problem, as qemu doesn't have any SPEs (they're specific to the Cell
 architecture), which would be required to hit this code. Also, you're
 not compiling with CONFIG_SPU_BASE, so the file that this changed
 shouldn't even be built.

Yeah, it seemed odd.  That's why I needed help. :)

 Perhaps try the bisect again?

Sorry about that.  I suck at git.

Part of the reason is that git bisect assumes that good always comes before 
bad in the repository, so if you're looking for the patch that _fixed_ a bug 
(I.E. good == new and bad == old), you have to reverse 'em to humor git 
bisect.  I had to do that this time to patch an intermediate version that 
build breaks, which git bisect run called skip on over a dozen times 
without noticeable progress.  If good and bad then mean the opposite on the 
_next_ bisect, I tend to get 'em confused occasionally.  (Especially when I've 
hit three or more unrelated bugs in the same bisect run.  In this case the 
build break in kmap_atomic_prot, whatever memory glitch is corrupting the 
squashfs root filesystem image and spamming the console about it, and this bug. 
 
Oh, and the really _fun_ part is that the squashfs bug only reproduces about 
half the time.  If you run the same binary twice, sometimes it'll work and 
sometimes it'll spam squashfs errors to the console.  Wheee...)

Anyway, on something like my fifth attempt I managed to bisect it to:

28794d34ecb6815a3fa0a4256027c9b081a17c5f is first bad commit
commit 28794d34ecb6815a3fa0a4256027c9b081a17c5f
Author: Benjamin Herrenschmidt b...@kernel.crashing.org
Date:   Tue Mar 10 17:53:27 2009 +

powerpc/kconfig: Kill PPC_MULTIPLATFORM

CONFIG_PPC_MULTIPLATFORM is a remain of the pre-powerpc days and isn't
really meaningful anymore. It was basically equivalent to PPC64 || 6xx.

This removes it along with the following changes:

 - 32-bit platforms that relied on PPC32  PPC_MULTIPLATFORM now rely
   on 6xx which is what they want anyway.

 - A new symbol, PPC_BOOK3S, is defined that represent compliance with
   the Server variant of the architecture. This is set when either 6xx
   or PPC64 is set and open the door for future BOOK3E 64-bit.

 - 64-bit platforms that relied on PPC64  PPC_MULTIPLATFORM now use
   PPC64  PPC_BOOK3S

 - A separate and selectable CONFIG_PPC_OF_BOOT_TRAMPOLINE option is now
   used to control the use of prom_init.c

Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org

Which suggested that the problem was the new CONFIG_PPC_OF_BOOT_TRAMPOLINE 
symbol wasn't set, and once I switched that on it started working again.

 linuxppc-dev@lists.ozlabs.org is the one you want for this:

  https://lists.ozlabs.org/listinfo/linuxppc-dev

Cool!  Is there a reason it's hidden?  (Or at least not listed in either 
vger.kernel.org's list info page or in the Maling lists page linked from 
ozlabs.org's top level web page.)  Just curious, I couldn't find it when I 
looked in the obvious (to me) places.

Rob

P.S.  Yes I tried google: top hit for linux powerpc list is penguinppc.org, 
which links to mailing lists on the right which is the ozlabs.org page that 
doesn't list linuxppc-dev.  In fact the entire first page of google hits for 
that search doesn't give a hint of the existence of that list, although some 
of the later ones might if I clicked through more of them...
-- 
Latency is more important than throughput. It's that simple. - Linus Torvalds
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 1/2] qemu platform, v2

[Rob Landley]

On Thursday 18 October 2007 12:29:08 pm Grant Likely wrote:
 On 10/18/07, Milton Miller [EMAIL PROTECTED] wrote:
  If we say only some boards or ports are special and need to build then
  I would vote for shipping asm files.  If we think we need to build any
  random embedded platform without installing dtc then we should merge
  dtc.

 I don't think we do.  It's looking like there are going to be out of
 tree users of dtc also (The are some patches floating around for
 u-boot to use the device tree for it's own initialization).  I don't
 think it's unreasonable to install dtc for embedded development.

There are out of tree users of yacc and lex, but the kernel has *.c_shipped 
files so as not to require that external tool of people who simply want to 
build the sucker without modifying it.  make oldconfig was modified not to 
require curses.

How about *.S_shipped files?

 I like the idea of shipping asm files to support the qemu target; at
 least until qemu gets better firmware.

I've now gotten qemu to boot a kernel I built, using Milton's 1/2 patch and a 
a self-contained build of a 4k ppc_boot.rom (which includes the dtc source 
because I don't expect anybody else to have it installed, either).  
Description and links to source, binaries, and build scripts in this message:

http://lists.gnu.org/archive/html/qemu-devel/2007-10/msg00415.html

There's a problem with qemu-cvs (detailed in the message), but qemu-system-ppc 
0.9.0 boots fine, up to a shell prompt.

 Cheers,
 g.

Rob
-- 
One of my most productive days was throwing away 1000 lines of code.
  - Ken Thompson.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 1/2] qemu platform, v2

[Rob Landley]

On Wednesday 17 October 2007 3:28:41 pm Grant Likely wrote:
  Including .dtbs in the kernel tree has a big practical problem:
  they're binary, so can't be patch(1)ed, which makes updating them a
  complete PITA.

I note that kconfig includes the lex/yacc output files (blah.c_shipped) so you 
don't have to have lex and yacc installed to run menuconfig.  It _also_ 
includes the lex/yacc source which is what you patch and rebuild the _shipped 
files from when they need to be changed.

  I'm working on merging dtc into the kernel tree instead.

 I'm kind of late to this party; but I have to say I disagree.  Most of
 us are doing just fine installing the dtc tool (and mkimage tool for
 that matter).  Cloning it in the kernel tree is just asking for
 divergence.

Milton Miller has some patches that make a PPC qemu target kernel image 
which doesn't include a device tree, and generates a rom image to boot qemu 
with which contains a device tree and hands it off to the Linux kernel.  If 
qemu can merge that rom image in its BIOS collection, this approach would 
meet my immediate needs.

 Cheers,
 g.

Rob
-- 
One of my most productive days was throwing away 1000 lines of code.
  - Ken Thompson.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 1/2] qemu platform, v2

[Rob Landley]

On Friday 28 September 2007 11:53:28 am Segher Boessenkool wrote:
  I'd be following this more closely if compiling a device tree didn't
  currently
  require an external utility (dtc or some such) that doesn't come with
  the
  Linux kernel.  No other target platform I've built kernels for
  requires such
  an environmental dependency.
 
  No?  You haven't built kernels for other platforms that have external
  dependencies such as perl, gcc, make, binutils, etc.? :)

 Two of the supported Linux archs cannot be built with a mainline
 compiler, even!

Strange definition of supported...

 And I have to install GNU sed/awk to get builds to work, too.

I extended busybox sed until it built everything I threw at it.  (I even added 
a lie to autoconf step that replies to --version to say This is not gnu 
sed 4.0 so a regex in autoconf doesn't do something stupid.)

That's how I got into busybox development in the first place...

 OTOH, it would be nice if we didn't need DTC -- it itself doesn't
 build out-of-the-box on all systems, either ;-)

I've built x86, x86-64, mips, arm, and sparc.  None of them needed anything 
but the seven packages I mentioned.  I'm poking at adding m68k, alpha, bfin, 
and powerpc, but my free time's been spoken for recently.  (I'll become 
interested in sh or parisc when qemu grows support for it.  I'm only 
interested in bfin because I was given some free blackfin hardware at OLS.)

I've even poked at running s390 under Hercules but the setup was insane enough 
to throw it way the heck down on my todo list.  (Step 1: download and 
configure an IBM operating system image from the 1970's...  Oh yeah, fills me 
with enthusiasm...)

   (This is a problem both for hardwiring the
  device tree into the kernel and for building a new boot rom from the
  linux
  kernel's ppc boot wrapper that would contain such a device tree to
  feed to
  the kernel.)
 
  It's only really been a problem for ps3 so far, since the embedded
  guys don't seem to have any difficulty with installing dtc.  We are
  looking at what to do for ps3 and prep, and the answer may well
  involve bundling dtc in the kernel source (it's not too big, around
  3400 lines).

 If only a few platforms have this problem, we could instead include
 their .dtb files in the kernel source tree.

I've had it clarified that the recent qemu-ppc patches from Milton only 
require dtc to build the ROM image to boot qemu with.  The Linux kernel image 
you build hasn't got a device tree in it (although that means it needs one 
passed in from the rom image)...

Using some other patches that floated by, I did build a prep kernel a couple 
of weeks ago, which qemu happily handed control off to...  which then failed 
to boot because it couldn't parse the incomplete residual data left over from 
open hackware.  The solution the ppc list recommended?  Hardwire a device 
tree into said linux kernel using dtc...


 Segher

Rob
-- 
One of my most productive days was throwing away 1000 lines of code.
  - Ken Thompson.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 1/2] qemu platform, v2

[Rob Landley]

On Saturday 22 September 2007 4:55:46 am Christoph Hellwig wrote:
 On Fri, Sep 21, 2007 at 06:08:31PM -0500, Milton Miller wrote:
  Here is the second rev of patches to boot a arch powerpc kernel on
  qemu with the prep architecture.

 So if this is supposed to be prep why do you need additional kernel
 support?  And if you really needed why isn't it under platforms/prep?

The device tree provided by qemu's open hackware violates some of the 
assumptions the Linux kernel is making?  (Although things like the cpu cache 
size is zero are, technically speaking, probably correct. :)

There are three different problems here:

1) porting prep from arch=ppc to arch=powerpc so you can build it on an arch 
that also supports make headers_install.

2) PowerPC uses a device tree supplied by the hardware to identify the 
available hardware, even for stuff living on PCI busses which it could 
theoretically probe for but doesn't.

3) The PPC firmware qemu comes with (Open Hackware) sucks rocks, is hard to 
modify, isn't quite being maintained.  As mentioned above, the device tree it 
passes in (including prep residual data from which more nodes in the device 
tree can be constructed, and here my understanding goes all fuzzy) does not 
make for a happy Linux kernel.

Proposed solutions to all this involve various combinations of creating a 
target platform aimed directly at qemu and not pretending to be prep at all 
(so it doesn't have to parse residual data), creating our own boot rom image 
out of some of the wrapper code the linux kernel's already got and feeding 
that to qemu instead of using open hackware at all, hard wiring a device tree 
into the kernel and not looking at the one open hackware passes in...)

I'd be following this more closely if compiling a device tree didn't currently 
require an external utility (dtc or some such) that doesn't come with the 
Linux kernel.  No other target platform I've built kernels for requires such 
an environmental dependency.  (This is a problem both for hardwiring the 
device tree into the kernel and for building a new boot rom from the linux 
kernel's ppc boot wrapper that would contain such a device tree to feed to 
the kernel.)

Rob
-- 
One of my most productive days was throwing away 1000 lines of code.
  - Ken Thompson.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev