[Qemu-devel] [PATCH] pl110
Hi, I think there's a small issue with the pl110 emulation. LCDIMSC and LCDControl are swapped depending whether versatile is used as a platform or not. This is done in the write function but not in the read function where it also should be done. Possible patch: Index: pl110.c === RCS file: /sources/qemu/qemu/hw/pl110.c,v retrieving revision 1.9 diff -u -r1.9 pl110.c --- pl110.c 3 Jun 2007 15:19:32 - 1.9 +++ pl110.c 17 Jun 2007 10:06:28 - @@ -302,8 +302,12 @@ case 5: /* LCDLPBASE */ return s->lpbase; case 6: /* LCDIMSC */ + if (s->versatile) + return s->cr; return s->int_mask; case 7: /* LCDControl */ + if (s->versatile) + return s->int_mask; return s->cr; case 8: /* LCDRIS */ return s->int_status; Adam -- Adam [EMAIL PROTECTED] Lackorzynski http://os.inf.tu-dresden.de/~adam/
[Qemu-devel] Re: 2.6.21 kernel on emulated/real Malta board
On Sat, 16 Jun 2007, Aurelien Jarno wrote:
> Since I switch to 2.6.21 kernel on my emulated Malta board (QEMU), I
> have noticed something strange. The kernel starts to boot up to the
> timer calibration, and then it restart the boot again. A small example:
>
> ...
>
> Primary data cache 0kB, 4-way, linesize 0 bytes.
> Synthesized TLB refill handler (36 instructions).
> Synthesized TLB load handler fastpath (48 instructions).
> Synthesized TLB store handler fastpath (48 instructions).
> Synthesized TLB modify handler fastpath (47 instructions).
> Enable cache parity protection for MIPS 20KC/25KF CPUs.
> PID hash table entries: 512 (order: 9, 4096 bytes)
> CPU frequency 100.00 MHz
> Using 100.003 MHz high precision timer.
> Linux version 2.6.21.1 ([EMAIL PROTECTED]) (gcc version 4.1.1 ()) #1 Tue
> May 15 12:22:07 CEST 2007
>
> LINUX started...
> CPU revision is: 000182a0
> FPU revision is: 000f8200
>
> ...
>
> I have traced the problem down to the CONFIG_EARLY_PRINTK option.
> Disabling it in the .config file (be aware that running make *config
> will reenable this function), removes the problem.
I guess it's just the printk buffer that's being output again to the new
console, when the console subsystem switches from early console to real
console.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
[Qemu-devel] qemu/linux-user path.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer 07/06/17 15:32:30 Modified files: linux-user : path.c Log message: Allow relative paths for the interpreter prefix in linux-user emulation. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/path.c?cvsroot=qemu&r1=1.2&r2=1.3
Re: [Qemu-devel] Re: 2.6.21 kernel on emulated/real Malta board
I just tried Linux 2.6.21.5 with Malta BE in QEMU.
I get the same console messages like Aurelien but
then Malta continues to boot normally.
So Geert is right: all output from early printk is
output again when the real console is activated.
Stefan
Geert Uytterhoeven schrieb:
> On Sat, 16 Jun 2007, Aurelien Jarno wrote:
>> Since I switch to 2.6.21 kernel on my emulated Malta board (QEMU), I
>> have noticed something strange. The kernel starts to boot up to the
>> timer calibration, and then it restart the boot again. A small example:
>>
>> ...
>>
>> Primary data cache 0kB, 4-way, linesize 0 bytes.
>> Synthesized TLB refill handler (36 instructions).
>> Synthesized TLB load handler fastpath (48 instructions).
>> Synthesized TLB store handler fastpath (48 instructions).
>> Synthesized TLB modify handler fastpath (47 instructions).
>> Enable cache parity protection for MIPS 20KC/25KF CPUs.
>> PID hash table entries: 512 (order: 9, 4096 bytes)
>> CPU frequency 100.00 MHz
>> Using 100.003 MHz high precision timer.
>> Linux version 2.6.21.1 ([EMAIL PROTECTED]) (gcc version 4.1.1 ()) #1 Tue
>> May 15 12:22:07 CEST 2007
>>
>> LINUX started...
>> CPU revision is: 000182a0
>> FPU revision is: 000f8200
>>
>> ...
>>
>> I have traced the problem down to the CONFIG_EARLY_PRINTK option.
>> Disabling it in the .config file (be aware that running make *config
>> will reenable this function), removes the problem.
>
> I guess it's just the printk buffer that's being output again to the new
> console, when the console subsystem switches from early console to real
> console.
>
> Gr{oetje,eeting}s,
>
> Geert
Re: [Qemu-devel] [PATCH][UPDATED] Fix path mangling in linux-user/path.c
Lauri Leukkunen wrote: > Attached patch fixes the linux-user path mangling code for use with > real target root filesystems that have nasty symlinks and lots of > files. The old code is terribly slow and can easily end up going > through the entire host system /usr hierarchy in a recursive loop. > > Compared to the previous version of this patch, fixes an issue with > attempting to free() a pointer returned by GNU basename(). I gave it a try, and found: - It loses the path caching (which should be done incrementally to avoid the slowness you observe) - It misses to do error handling on malloc() returns - It is broken, an emulated "/bin/ls /.." shows it ascends above the root. Thiemo
[Qemu-devel] qemu/linux-user main.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer 07/06/17 16:38:40 Modified files: linux-user : main.c Log message: Option to drop LD_PRELOAD from emulated environment, by Lauri Leukkunen. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/main.c?cvsroot=qemu&r1=1.114&r2=1.115
[Qemu-devel] qemu Makefile
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer 07/06/17 16:41:04 Modified files: . : Makefile Log message: Remove cscope.* files on 'make clean', by George G. Davis. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/Makefile?cvsroot=qemu&r1=1.119&r2=1.120
[Qemu-devel] Re: ANN: DetaolB v0.3 is released
On 6/16/07, Rob Landley <[EMAIL PROTECTED]> wrote: On Thursday 14 June 2007 17:13:32 Christian MICHON wrote: > * /proc/miniconfig.gz: main ideas from Rob Landley, need documentation Actually, there was documentation for this before there was code. You can follow my development of the concept: (...) I'm sorry Rob, I meant I need to document the changes I brought to your original idea. Download the iso, and once it's finished booting inside qemu, log in as root and do this: vi /proc/miniconfig.gz you'll understand what I meant by not having documented (my changes)... > + gcc-3.4.6 Heh. You're building qemu with your toolchain, aren't you? :) nope, not yet. the reason for this gcc version is also due to colinux requirements (I need a vmlinux api compatible with gcc-3.4.6) I actually intend to deliver a few toolchains soon. But qemu is definitely going in as a loadable module soon after Xwindows will be in. :) "One of my most productive days was throwing away 1000 lines of code." - Ken Thompson. excellent... -- Christian -- http://detaolb.sourceforge.net/, a linux distribution for Qemu
Re: [Qemu-devel] [PATCH][UPDATED] Fix path mangling in linux-user/path.c
On 17/06/07 17:30 +0100, Thiemo Seufer wrote: > Lauri Leukkunen wrote: > > Attached patch fixes the linux-user path mangling code for use with > > real target root filesystems that have nasty symlinks and lots of > > files. The old code is terribly slow and can easily end up going > > through the entire host system /usr hierarchy in a recursive loop. > > > > Compared to the previous version of this patch, fixes an issue with > > attempting to free() a pointer returned by GNU basename(). > > I gave it a try, and found: > - It loses the path caching (which should be done incrementally to > avoid the slowness you observe) Current path mangling is not just slow, it gets stuck in a loop for 15 minutes on my box and eats all my RAM until it exhausts all virtual memory: 3976 lleukkun 18 0 2641m 1.5g 188 R 68 77.4 1:26.36 qemu-arm So I don't know if losing a bit of caching is that bad in comparison. I've implemented a kinda similar path mangling system for scratchbox2, there I'm caching the translations in a cache dir as symlinks, cuts down the mangling overhead quite a bit, but on the other hand sb2 needs to do a lot more work to determine how to mangle the path. Not sure it's worth the trouble for qemu. It seems on a current debian/testing it no longer works at all, it used to hog all memory and then (maybe after getting a NULL from malloc()?) continued, now it just eats all swap and keeps going as long as the kernel permits. If you want to see the effect get a maemo rootfs from here: http://repository.maemo.org/stable/3.1/armel/maemo-sdk-rootstrap_3.1_armel.tgz and try giving the extracted dir to qemu-arm -L /path/to/the/rootfs It gets tripped up by the /usr/X11R6/bin/X11 -> . symlink, don't ask me why such a link is needed ;) > - It misses to do error handling on malloc() returns > - It is broken, an emulated "/bin/ls /.." shows it ascends above > the root. I'll try to provide an updated patch with these addressed tomorrow. /lauri
