"make clean" after "git pull" runs configure before cleaning.
Apparently because:
../meson.build:1:0: ERROR: Meson version is 0.59.3 but project requires
>=1.5.0
A full log can be found at
/home/landley/qemu/qemu/build/meson-logs/meson-log.txt
/home/landley/qemu/qemu/build/pyvenv/bin/meson setup --reconfigure
/home/landley/qemu/qemu
WARNING: Regenerating configuration from scratch.
Reason: Coredata file
'/home/landley/qemu/qemu/build/meson-private/coredata.dat' references
functions or classes that don't exist. This probably means that it was
generated with an old version of meson.
DEPRECATION: "pkgconfig" entry is deprecated and should be replaced by
"pkg-config"
(And then 30 screens more data...)
Seems a _bit_ awkward to do that (and potentially fail on a random new
dependency) just to delete it all again?
And I dunno what it's saying about the meson version, "aptitude show
meson" in my devuan daedalus ("debian bookworm" fork) says version
1.0.1-5 which is nowhere near 0.59.3 or 1.5.0? QEMU built fine with it
last week, and after yet another ./configure it seems to be chugging
along building the new -rc0 tag for the moment...
Rob
Re: [PATCH 2/2] tests/functional: Add a test for sh4eb
On 10/24/24 03:27, Thomas Huth wrote: Now that we are aware of binaries that are available for sh4eb, we should make sure that there are no regressions with this target and test it regularly in our CI. Any progress on restoring this? Didn't see it in "git pull" just now... +class R2dEBTest(LinuxKernelTest): + +ASSET_TGZ = Asset( +'https://landley.net/bin/mkroot/0.8.11/sh4eb.tgz', +'be8c6cb5aef8406899dc5aa5e22b6aa45840eb886cdd3ced51555c10577ada2c') Feel free to pull binaries from my site, but from a reliability perspective "some random dude got hit by a bus so a site went down that broke our test infrastructure" seems a bit dodgy. (Even the Internet Archive has been having reliability issues of late, and "as long as Brewster Kahle's dot-com money holds out" seems a similar bus number.) Building it yourself from source seems more reliable. Is there any sort of policy here? I build the toolchains, kernel, and userspace entirely from source and can provide the reproduction sequences for those if you like. It's part of my mkroot project, which is attempting to build small qemu systems for every target supported by all of: 1) qemu 2) linux 3) musl-libc 4) gcc And even do automated smoketests on them showing it can boot, run a shell script, and access a virtual block device and network connection: https://github.com/landley/toybox/blob/master/mkroot/testroot.sh Alas a lot of targets I would LIKE to support are missing something in one or more of those 4 packages. (No sparc in musl, etc.) At the moment this lack is most obvious to me for nommu support. If I want fdpic then linux/fs/Kconfig.binfmt says my options are: config BINFMT_ELF_FDPIC bool "Kernel support for FDPIC ELF binaries" default y if !BINFMT_ELF depends on ARM || ((M68K || RISCV || SUPERH || XTENSA) && !MMU) But gcc's source says my options are: $ grep -lir fdpic gcc/config | xargs dirname | uniq gcc/config/frv gcc/config/sh gcc/config/bfin gcc/config/arm Which is exactly TWO targets that overlap. (There were two more, but Linux commit f5a8eb632b56 removed bfin and frv in 2018, and while I've followed arm-fdpic development since 2016 I have yet to get it to work for me.) (NOMMU support is a bit like eukaryote cells in biology: beneath most people's notice but EVERYWHERE, to the point that ecosystem physically outweighs the "more advanced" one if you add up each instance of both.) While you can do PIE binaries on nommu (which is what buildroot and Buildroot and https://github.com/gregungerer/simple-linux do for the other nommu architectures), that just doesn't scale. If you run two PIE instances of "bash" on nommu it loads two copies of the bash binary into memory, AND each one requires one big contiguous block of memory for the text, rodata, bss, and data segments all together. The point of fdpic is those four segments relocate independently, so multiple instances of the same program can share text and rodata, and also use smaller chunks of memory for bss and data which is much easier to come by in system without an mmu to let virtual mappings collate fragmented physical memory. On nommu memory fragmentation is basically inevitable. Rob P.S. In theory I could try linux's nolibc.h instead of musl but building toybox under that is quite the lift, and I briefly had an llvm hexagon build working instead of gcc (copied from your test stuff, but https://compiler-rt.llvm.org/ is just apocalyptically badly designed that the easy way to get a portable build out of it honestly seems to be to write a new replacement library from scratch).
Re: [PATCH 1/2] Revert "Remove the unused sh4eb target"
On 10/24/24 03:27, Thomas Huth wrote: This reverts commit 73ceb12960e686b763415f0880cc5171ccce01cf. The "r2d" machine can work in big endian mode, see: https://lore.kernel.org/qemu-devel/d6755445-1060-48a8-82b6-2f392c21f...@landley.net/ So the reasoning for removing sh4eb was wrong. Signed-off-by: Thomas Huth Signed-off-by: Rob Landley Rob
Re: Please put qemu-system-sh4eb back.
On 10/24/24 00:44, Thomas Huth wrote: On 24/10/2024 02.11, Rob Landley wrote: I use it, and ship system images for it: https://landley.net/bin/mkroot/latest/sh4eb.tgz Oh, that's interesting, I've been told that the r2d machine does not work in big endian mode: https://lore.kernel.org/qemu-devel/87a5fwjjew.wl-ys...@users.sourceforge.jp/ Possibly they were referring to: https://landley.net/notes-2023.html#16-06-2023 Less-used platforms get regressions and then get fixed again. The reason I rebuilt qemu and noticed sh4eb's removal was I was checking if commit 3c5f86a22686 was still a problem before reporting it, but I see 68ad89b75ad2 already reverted it... :) But yes, your binaries apparently work there, so sorry for the confusion. I'll send a patch to revert the removal. Thank you. (The j-core SOCs are all big endian.) Rob
Re: Please put qemu-system-sh4eb back.
On 10/23/24 19:11, Rob Landley wrote: There was a big-endian issue breaking r2d last year, but it also broke big endian mips and some other targets too, and it got fixed. The binary I built a few months ago was working fine for me with vanilla qemu git source? (I don't _think_ I had local changes?) I can try to build the version removed to check that... I did $ git checkout 73ceb12960e6^1 $ ./configure --target-list-sh4eb-softmmu $ make And the resulting qemu-system-sh4eb booted my system image to a shell prompt: # cat /proc/version Linux version 6.11.0 (rob@j180) (sh4eb-linux-musl-cc (GCC) 11.4.0, GNU ld (GNU Binutils) 2.33.1) #1 Wed Oct 23 23:44:11 UTC 2024 # cat /proc/cpuinfo machine : RTS7751R2D processor : 0 cpu family : sh4eb cpu type: SH7751R cut : unknown cpu flags : fpu ptea cache type : split (harvard) icache size : 4KiB (2-way) dcache size : 4KiB (2-way) address sizes : 29 bits physical bogomips: 120.00
Please put qemu-system-sh4eb back.
I use it, and ship system images for it: https://landley.net/bin/mkroot/latest/sh4eb.tgz And here's me recentish-ly debugging an issue via it: https://landley.net/notes-2024.html#24-05-2024 (Compile/test cycles are WAY easier there than copying files onto an sd card to test on actual hardware.) There was a big-endian issue breaking r2d last year, but it also broke big endian mips and some other targets too, and it got fixed. The binary I built a few months ago was working fine for me with vanilla qemu git source? (I don't _think_ I had local changes?) I can try to build the version removed to check that... Yes I should be better about pushing local patches upstream. For example, here's the kernel patch I use to run fdpic binaries under qemu: https://landley.net/bin/mkroot/latest/linux-patches/0002-sh4-fdpic.patch Which lets you enable the FDPIC loader on an mmu kernel, which is useful for testing j-core userspace under qemu. Rob
QEMU commit 0a923be2f642 broke my or1k image.
Grab this tarball, extract it, and ./run-qemu.sh. It's a simple linux+initramfs image that boots to a shell prompt. https://landley.net/bin/mkroot/latest/or1k.tgz QEMU 7.0.0 ran that linux-or1k image, but newer qemu does not. I besected the issue to qemu commit 0a923be2f642, and it's still broken in current tip of tree. Rebuilding the image with current linux-git doesn't seem to make a difference? Either way I get serial output with old qemu and don't with current qemu. Rob P.S. Reproduction sequence for the tarball available upon request, kernel config is in the docs/ directory, userspace is just a toybox mkroot build but "not getting kernel boot messages" happens way before userspace gets a vote.
Re: [PATCH] hw/mips/gt64xxx_pci: Don't endian-swap GT_PCI0_CFGADDR
On 3/29/23 12:23, Philippe Mathieu-Daudé wrote: > On 29/3/23 18:48, Rob Landley wrote: >>>> Works fine for me. Somebody said it was the wrong fix but I don't remember >>>> why... >>> >>> This is a correct /partial/ fix. With this patch, Malta works on little >>> endian hosts. No luck with big-endian hosts, but this was broken >>> previous to 3db29dcac2 rework, so apparently not a big deal ¯\_(ツ)_/¯ >> >> No, big endian worked for me with that patch? >> >> The build in my $PATH is QEMU emulator version 7.2.50 >> (v7.2.0-873-g65cc5ccf06-dirty) with that patch, and if you wget >> https://landley.net/toybox/downloads/binaries/mkroot/0.8.9/mips.tgz and >> ./run-emulator.sh in there, the virtual net can wget http://site (the sample > > Oh, we are having some QEMU semantic confusion here... > > You are testing a QEMU big-endian *guest* (or "target") in this example. > > I presume you are testing on a little-endian *host* (x86_64, aarch64, > ppc64el or mips64el). Ah, yes. I have not tried running qemu on a big endian host system in forever, but there are some IBM people with great interest in supporting every possible thing on s390x. Elizabeth Joseph would be one and would know a bunch more: https://floss.social/@pleia2/110095815201601529 >> image hasn't got https:// support enabled because I didn't include the build >> dependency), and the virtual disk works (if you do "./run-emulator.sh -hda >> blah.img" anyway, the test wrapper I mentioned creates a squashfs image for >> it >> to mount)). Without the patch I don't even get a PCI bus. Running "file >> /bin/toybox" says MSB, and the mipsel image is the little endian one anyway. >> I > > Here you describe the little-endian MIPS *target* image. Which was broken without that patch, yes. So that's why the fix was "partial"... >> also test s390x (which is big endian 64 bit), but I don't think this needed a >> patch? (Hadn't been broken last I checked?) > > Here you describe big-endian s390x *target* image. I don't have s390x hardware to run it on. I do have an sh2eb board but it's nommu and only has 128 megs of ram, so running qemu on it would be... unlikely. > I expect if you run your test with QEMU v7.2.0-873-g65cc5ccf06-dirty > on any big-endian *host* (like a s390x), the test fails. I don't have powerpc mac hardware, which seems the easiest way to get such a test system. (Well, ok, the EASY way would be to feed qemu-system-s390x a couple gigs of ram and then build and run qemu within qemu. While I do have a native toolchain for s390x, qemu's grown an insane dependency stack these days that would be a pain to bootstrap under a musl beyond-linux-from-scratch environment...) Rob
Re: [PATCH] hw/mips/gt64xxx_pci: Don't endian-swap GT_PCI0_CFGADDR
On 3/29/23 11:07, Philippe Mathieu-Daudé wrote:
> On 29/3/23 18:09, Rob Landley wrote:
>> On 3/28/23 12:02, Philippe Mathieu-Daudé wrote:
>>> On 20/3/23 17:58, Nathan Chancellor wrote:
>>>> On Wed, Mar 08, 2023 at 12:33:38AM +0100, Philippe Mathieu-Daudé wrote:
>>>>> On 23/2/23 17:19, Jiaxun Yang wrote:
>>>>>> 145e2198d749 ("hw/mips/gt64xxx_pci: Endian-swap using PCI_HOST_BRIDGE
>>>>>> MemoryRegionOps") converted CFGADDR/CFGDATA registers to use
>>>>>> PCI_HOST_BRIDGE's
>>>>>> accessor facility and enabled byte swap for both CFGADDR/CFGDATA
>>>>>> register.
>>>>>>
>>>>>> However CFGADDR as a ISD internal register is not controled by MByteSwap
>>>>>> bit, it follows endian of all other ISD register, which means it ties to
>>>>>> little endian.
>>>>>>
>>>>>> Move mapping of CFGADDR out of gt64120_update_pci_cfgdata_mapping to
>>>>>> disable
>>>>>> endian-swapping.
>>>>>>
>>>>>> This should fix some recent reports about poweroff hang.
>>>>>>
>>>>>> Fixes: 145e2198d749 ("hw/mips/gt64xxx_pci: Endian-swap using
>>>>>> PCI_HOST_BRIDGE MemoryRegionOps")
>>>>>> Signed-off-by: Jiaxun Yang
>>>>>> ---
>>>>>> hw/pci-host/gt64120.c | 18 ++
>>>>>> 1 file changed, 6 insertions(+), 12 deletions(-)
>>>>>
>>>>> So this works on little-endian hosts, but fails on
>>>>> big-endian ones :(
>>>>>
>>>>> I.e. on Linux we have early_console_write() -> prom_putchar()
>>>>> looping:
>>>>>
>>>>> IN: prom_putchar
>>>>> 0x8010fab8: lbu v0,0(v1)
>>>>> 0x8010fabc: andi v0,v0,0x20
>>>>> 0x8010fac0: beqz v0,0x8010fab8
>>>>> 0x8010fac4: andi v0,a0,0xff
>>>>>
>>>>> gt64120: Illegal register read reg:0x3fc size:4 value:0x
>>>>> gt64120: Illegal register read reg:0x3fc size:4 value:0x
>>>>> gt64120: Illegal register read reg:0x3fc size:4 value:0x
>>>>> gt64120: Illegal register read reg:0x3fc size:4 value:0x
>>>>> gt64120: Illegal register read reg:0x3fc size:4 value:0x
>>>>> ...
>>>>>
>>>>
>>>> Is there going to be a new version of this patch or a different solution
>>>> to the poweroff hang then? I am still seeing that with tip of tree QEMU
>>>> and I see 8.0.0-rc0 has been tagged; I would hate for this to end up in
>>>> a release version.
>>>
>>> I couldn't work a fix, however I ran our (new) tests on merge
>>> commit 3db29dcac2 which is before the offending commit 145e2198d749,
>>> and they fail. So I suppose Malta on big-endian host is badly broken
>>> since quite some time. Thus clearly nobody tests/runs Malta there.
>>
>> I test/run malta with the mips and mipsel binaries at
>> https://landley.net/toybox/downloads/binaries/mkroot/0.8.9/ but I'm still
>> locally applying the first patch I saw to fix this (attached) until upstream
>> sorts itself out.
>>
>> Works fine for me. Somebody said it was the wrong fix but I don't remember
>> why...
>
> This is a correct /partial/ fix. With this patch, Malta works on little
> endian hosts. No luck with big-endian hosts, but this was broken
> previous to 3db29dcac2 rework, so apparently not a big deal ¯\_(ツ)_/¯
No, big endian worked for me with that patch?
The build in my $PATH is QEMU emulator version 7.2.50
(v7.2.0-873-g65cc5ccf06-dirty) with that patch, and if you wget
https://landley.net/toybox/downloads/binaries/mkroot/0.8.9/mips.tgz and
./run-emulator.sh in there, the virtual net can wget http://site (the sample
image hasn't got https:// support enabled because I didn't include the build
dependency), and the virtual disk works (if you do "./run-emulator.sh -hda
blah.img" anyway, the test wrapper I mentioned creates a squashfs image for it
to mount)). Without the patch I don't even get a PCI bus. Running "file
/bin/toybox" says MSB, and the mipsel image is the little endian one anyway. I
also test s390x (which is big endian 64 bit), but I don't think this needed a
patch? (Hadn't been broken last I checked?)
I vaguely recall having tested newer qemu, but couldn't say when that was (early
february at the latest, and if so I didn't install it into /usr/bin/local. It
takes a while to build all the targets so I only really do it quarterly, usually
when I'm about to cut a toybox release and want to make sure qemu hasn't broken
anything important while I wasn't looking...)
Rob
Re: [PATCH] hw/mips/gt64xxx_pci: Don't endian-swap GT_PCI0_CFGADDR
On 3/29/23 03:55, Thomas Huth wrote:
> On 28/03/2023 19.02, Philippe Mathieu-Daudé wrote:
>> On 20/3/23 17:58, Nathan Chancellor wrote:
>>> On Wed, Mar 08, 2023 at 12:33:38AM +0100, Philippe Mathieu-Daudé wrote:
On 23/2/23 17:19, Jiaxun Yang wrote:
> 145e2198d749 ("hw/mips/gt64xxx_pci: Endian-swap using PCI_HOST_BRIDGE
> MemoryRegionOps") converted CFGADDR/CFGDATA registers to use
> PCI_HOST_BRIDGE's
> accessor facility and enabled byte swap for both CFGADDR/CFGDATA register.
>
> However CFGADDR as a ISD internal register is not controled by MByteSwap
> bit, it follows endian of all other ISD register, which means it ties to
> little endian.
>
> Move mapping of CFGADDR out of gt64120_update_pci_cfgdata_mapping to
> disable
> endian-swapping.
>
> This should fix some recent reports about poweroff hang.
>
> Fixes: 145e2198d749 ("hw/mips/gt64xxx_pci: Endian-swap using
> PCI_HOST_BRIDGE MemoryRegionOps")
> Signed-off-by: Jiaxun Yang
> ---
> hw/pci-host/gt64120.c | 18 ++
> 1 file changed, 6 insertions(+), 12 deletions(-)
So this works on little-endian hosts, but fails on
big-endian ones :(
I.e. on Linux we have early_console_write() -> prom_putchar()
looping:
IN: prom_putchar
0x8010fab8: lbu v0,0(v1)
0x8010fabc: andi v0,v0,0x20
0x8010fac0: beqz v0,0x8010fab8
0x8010fac4: andi v0,a0,0xff
gt64120: Illegal register read reg:0x3fc size:4 value:0x
gt64120: Illegal register read reg:0x3fc size:4 value:0x
gt64120: Illegal register read reg:0x3fc size:4 value:0x
gt64120: Illegal register read reg:0x3fc size:4 value:0x
gt64120: Illegal register read reg:0x3fc size:4 value:0x
...
>>>
>>> Is there going to be a new version of this patch or a different solution
>>> to the poweroff hang then? I am still seeing that with tip of tree QEMU
>>> and I see 8.0.0-rc0 has been tagged; I would hate for this to end up in
>>> a release version.
>>
>> I couldn't work a fix, however I ran our (new) tests on merge
>> commit 3db29dcac2 which is before the offending commit 145e2198d749,
>> and they fail. So I suppose Malta on big-endian host is badly broken
>> since quite some time. Thus clearly nobody tests/runs Malta there.
>>
>> Is it worth fixing old bugs nobody hit / reported?
>> Should we stop wasting CI resources testing MIPS on big-endian hosts?
>
> This rather sounds like a blind spot in our CI ... we still have some big
> endian s390x machines there, so maybe this just needs a proper test to avoid
> regressions? Would it be feasible to add a test to
> tests/qtest/boot-serial-test.c for this, for example?
I have my own automated test infrastructure for the toybox project, which does a
basic automated smoketest against all the support qemu images.
https://github.com/landley/toybox/blob/master/scripts/test_mkroot.sh
I also have a 300 line bash script that builds and packages all the Linux test
systems from source (it's mkroot.sh in the same directory if you're wondering
how to build a bootable Linux system for a dozen targets in 300 lines of bash,
and it's documented at https://landley.net/toybox/faq.html#mkroot and that links
to prebuilt binaries, and the instructions and scripts to build the cross
compilers I use, and prebuilt binaries for those too...
Anyway, tl;dr I both care and can regression test this easily, but haven't seen
an agreed on "try this patch instead of the other patch" go by? (Might have
missed it?)
Rob
Re: [PATCH] hw/mips/gt64xxx_pci: Don't endian-swap GT_PCI0_CFGADDR
On 3/28/23 12:02, Philippe Mathieu-Daudé wrote:
> On 20/3/23 17:58, Nathan Chancellor wrote:
>> On Wed, Mar 08, 2023 at 12:33:38AM +0100, Philippe Mathieu-Daudé wrote:
>>> On 23/2/23 17:19, Jiaxun Yang wrote:
145e2198d749 ("hw/mips/gt64xxx_pci: Endian-swap using PCI_HOST_BRIDGE
MemoryRegionOps") converted CFGADDR/CFGDATA registers to use
PCI_HOST_BRIDGE's
accessor facility and enabled byte swap for both CFGADDR/CFGDATA register.
However CFGADDR as a ISD internal register is not controled by MByteSwap
bit, it follows endian of all other ISD register, which means it ties to
little endian.
Move mapping of CFGADDR out of gt64120_update_pci_cfgdata_mapping to
disable
endian-swapping.
This should fix some recent reports about poweroff hang.
Fixes: 145e2198d749 ("hw/mips/gt64xxx_pci: Endian-swap using
PCI_HOST_BRIDGE MemoryRegionOps")
Signed-off-by: Jiaxun Yang
---
hw/pci-host/gt64120.c | 18 ++
1 file changed, 6 insertions(+), 12 deletions(-)
>>>
>>> So this works on little-endian hosts, but fails on
>>> big-endian ones :(
>>>
>>> I.e. on Linux we have early_console_write() -> prom_putchar()
>>> looping:
>>>
>>> IN: prom_putchar
>>> 0x8010fab8: lbuv0,0(v1)
>>> 0x8010fabc: andi v0,v0,0x20
>>> 0x8010fac0: beqz v0,0x8010fab8
>>> 0x8010fac4: andi v0,a0,0xff
>>>
>>> gt64120: Illegal register read reg:0x3fc size:4 value:0x
>>> gt64120: Illegal register read reg:0x3fc size:4 value:0x
>>> gt64120: Illegal register read reg:0x3fc size:4 value:0x
>>> gt64120: Illegal register read reg:0x3fc size:4 value:0x
>>> gt64120: Illegal register read reg:0x3fc size:4 value:0x
>>> ...
>>>
>>
>> Is there going to be a new version of this patch or a different solution
>> to the poweroff hang then? I am still seeing that with tip of tree QEMU
>> and I see 8.0.0-rc0 has been tagged; I would hate for this to end up in
>> a release version.
>
> I couldn't work a fix, however I ran our (new) tests on merge
> commit 3db29dcac2 which is before the offending commit 145e2198d749,
> and they fail. So I suppose Malta on big-endian host is badly broken
> since quite some time. Thus clearly nobody tests/runs Malta there.
I test/run malta with the mips and mipsel binaries at
https://landley.net/toybox/downloads/binaries/mkroot/0.8.9/ but I'm still
locally applying the first patch I saw to fix this (attached) until upstream
sorts itself out.
Works fine for me. Somebody said it was the wrong fix but I don't remember
why...
Robdiff --git a/hw/pci-host/gt64120.c b/hw/pci-host/gt64120.c
index f226d03420..36ed01c615 100644
--- a/hw/pci-host/gt64120.c
+++ b/hw/pci-host/gt64120.c
@@ -320,13 +320,6 @@ static void gt64120_isd_mapping(GT64120State *s)
static void gt64120_update_pci_cfgdata_mapping(GT64120State *s)
{
-/* Indexed on MByteSwap bit, see Table 158: PCI_0 Command, Offset: 0xc00 */
-static const MemoryRegionOps *pci_host_conf_ops[] = {
-&pci_host_conf_be_ops, &pci_host_conf_le_ops
-};
-static const MemoryRegionOps *pci_host_data_ops[] = {
-&pci_host_data_be_ops, &pci_host_data_le_ops
-};
PCIHostState *phb = PCI_HOST_BRIDGE(s);
memory_region_transaction_begin();
@@ -339,22 +332,13 @@ static void gt64120_update_pci_cfgdata_mapping(GT64120State *s)
* - Table 16: 32-bit PCI Transaction Endianess
* - Table 158: PCI_0 Command, Offset: 0xc00
*/
-if (memory_region_is_mapped(&phb->conf_mem)) {
-memory_region_del_subregion(&s->ISD_mem, &phb->conf_mem);
-object_unparent(OBJECT(&phb->conf_mem));
-}
-memory_region_init_io(&phb->conf_mem, OBJECT(phb),
- pci_host_conf_ops[s->regs[GT_PCI0_CMD] & 1],
- s, "pci-conf-idx", 4);
-memory_region_add_subregion_overlap(&s->ISD_mem, GT_PCI0_CFGADDR << 2,
-&phb->conf_mem, 1);
-
if (memory_region_is_mapped(&phb->data_mem)) {
memory_region_del_subregion(&s->ISD_mem, &phb->data_mem);
object_unparent(OBJECT(&phb->data_mem));
}
memory_region_init_io(&phb->data_mem, OBJECT(phb),
- pci_host_data_ops[s->regs[GT_PCI0_CMD] & 1],
+ (s->regs[GT_PCI0_CMD] & 1) ? &pci_host_data_le_ops
+ : &pci_host_data_be_ops,
s, "pci-conf-data", 4);
memory_region_add_subregion_overlap(&s->ISD_mem, GT_PCI0_CFGDATA << 2,
&phb->data_mem, 1);
@@ -1207,6 +1191,11 @@ static void gt64120_realize(DeviceState *dev, Error **errp)
get_system_io(),
PCI_DEVFN(18, 0), TYPE_PCI_BUS);
+memory_region_init_io(&phb->conf_mem, OBJECT(phb), &pci_host_conf_le_ops,
+ s, "pci-conf-idx", 4);
+memory_r
Re: Commit 145e2198d749 broke mips big endian.
On 1/21/23 07:14, Peter Maydell wrote:
> On Sat, 21 Jan 2023 at 10:45, Rob Landley wrote:
>>
>> wget https://landley.net/toybox/downloads/binaries/mkroot/0.8.9/mips.tgz
>> extract
>> and ./run-qemu.sh in there. Before this commit it goes:
>
> Hi; does this patchset fix the regression for you?
> https://lore.kernel.org/qemu-devel/20230118095751.49728-1-phi...@linaro.org/
> ("[PATCH v2 0/2] hw/pci-host/gt64120: Fix regression on big-endian targets")
Yes it did.
Thanks,
Rob
Commit 145e2198d749 broke mips big endian.
wget https://landley.net/toybox/downloads/binaries/mkroot/0.8.9/mips.tgz extract and ./run-qemu.sh in there. Before this commit it goes: loop: module loaded ata_piix :00:0a.1: enabling device ( -> 0001) scsi host0: ata_piix scsi host1: ata_piix ata1: PATA max UDMA/33 cmd 0x1f0 ctl 0x3f6 bmdma 0x1080 irq 14 ata2: PATA max UDMA/33 cmd 0x170 ctl 0x376 bmdma 0x1088 irq 15 pcnet32 :00:0b.0: enabling device ( -> 0003) pcnet32: PCnet/PCI II 79C970A at 0x1060, 52:54:00:12:34:56 assigned IRQ 10 pcnet32: eth0: registered as PCnet/PCI II 79C970A pcnet32: 1 cards_found NET: Registered PF_INET6 protocol family Segment Routing with IPv6 Afterwards: loop: module loaded NET: Registered PF_INET6 protocol family Segment Routing with IPv6 and lots of hardware is missing. (I noticed ethernet first.) The mipsel.tgz in the same directory still worked. Rob
Re: serial hang in qemu-system-ppc64 -M pseries
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
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
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
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 01/20] Hexagon HVX (target/hexagon) README
On 7/26/21 8:59 AM, Taylor Simpson wrote: > We're working on system mode support for Hexagon, and we plan to upstream it > when it is ready. > > Thanks, > Taylor Any progress on this? (Is there a way for outsiders to track the status?) Thanks, Rob
Re: [PATCH for-6.2 12/43] target/sh4: Implement do_unaligned_access for user-only
On 7/29/21 8:52 AM, Peter Maydell wrote: > On Thu, 29 Jul 2021 at 02:01, Richard Henderson > wrote: >> >> Cc: Yoshinori Sato >> Signed-off-by: Richard Henderson >> --- >> linux-user/sh4/cpu_loop.c | 8 >> target/sh4/cpu.c | 2 +- >> target/sh4/op_helper.c| 3 --- >> 3 files changed, 9 insertions(+), 4 deletions(-) >> >> diff --git a/linux-user/sh4/cpu_loop.c b/linux-user/sh4/cpu_loop.c >> index 222ed1c670..21d97250a8 100644 >> --- a/linux-user/sh4/cpu_loop.c >> +++ b/linux-user/sh4/cpu_loop.c >> @@ -71,6 +71,14 @@ void cpu_loop(CPUSH4State *env) >> info._sifields._sigfault._addr = env->tea; >> queue_signal(env, info.si_signo, QEMU_SI_FAULT, &info); >> break; >> +case 0xe0: >> +case 0x100: >> +info.si_signo = TARGET_SIGBUS; >> +info.si_errno = 0; >> +info.si_code = TARGET_BUS_ADRALN; >> +info._sifields._sigfault._addr = env->tea; >> +queue_signal(env, info.si_signo, QEMU_SI_FAULT, &info); >> +break; > > sh4 kernel default for unaligned accesses seems to be "warn and fixup", > not SIGBUS, unless the user changes that by writing to /proc/cpu/alignment > or the process changes it via prctl(). It's still good to know, qemu-sh4 runs j-core binaries but that target doesn't have unaligned interrupts yet. (I think it just masks off the bottom 2 bits to do the next lowest aligned access? It's an sh2 variant and the plumbing to let interrupts restart multi-clock instructions is only in the j32 branch so far, so the j2 and ice40 targets don't generate interrupts for it. Todo item, in the meantime we need to clean unaligned access out of application code so faulting on it is good.) > -- PMM Thanks, Rob
Re: [PATCH 01/20] Hexagon HVX (target/hexagon) README
On 7/26/21 8:59 AM, Taylor Simpson wrote: >> Anyway, I still hope somebody else has already done most of this in a git >> tree somewhere. :) > > We're working on system mode support for Hexagon, and we plan to upstream it > when it is ready. Yay! Thanks. While you're at it, why is llvm's cmake config unable to do: $ cccnext/cross_bin/hexagon-unknown-linux-musl-cc \ -Xpreprocessor -P -E - <<< __SIZEOF_POINTER__ 4 I'm trying to genericize that llvm build script to do all the targets musl and llvm agree on supporting, which means not passing in -DCMAKE_SIZEOF_VOID_P=4 because the compiler ALREADY KNOWS THIS... but cmake/config-ix.cmake line 196 is REALLY going to barf if we didn't explicitly specify it on the command line? Are the llvm developers not _aware_ of the "cc -E -dM - < /dev/null" trick? Even if they aren't, why couldn't they just sizeof(void *) in a header file? *shrug* I can do the above trick in the wrapper script and then provide -DCMAKE_SIZEOF_VOID_P=$BLAH on the command line, it just seems DEEPLY pointless to go to all the trouble of having a ./configure that has to be manually told stuff the compiler already knows. Confused, Rob
Re: [PATCH 01/20] Hexagon HVX (target/hexagon) README
On 7/26/21 2:57 AM, Rob Landley wrote:
> Anyway... it doesn't look like qemu-system-hexagon (softmmu) its currently in
> vanilla qemu? Is there a public fork that has this somewhere?
I did a little wild flailing to get ./configure to give me a qemu-system-hexagon
option (patch attached), I.E. just enough to get meson to shut up and quite
possibly still missing something important. (Is this python? It looks kind of
like python.)
Unfortunately after liberally cribbing from the cris architecture (which seems
like the simplest one) I'm left with several new C files to implement, all
currently zero length in the patch:
hw/hexagon/boot.c
hw/hexagon/hexagon_comet.c
target/hexagon/machine.c
target/hexagon/mmu.c
(In theory there's a "none" board on all the current qemu-system architectures,
but I've never figured out what to DO with those...)
All this raises two problems:
1) I dunno how the hexagon mmu works. (I can presumably read the kernel code and
reverse engineer what that's looking for, but it would be really nice not to
_have_ to?)
2) What's a comet board? (Memory layout? I/O devices? I guess all I need for
serial console on initramfs is a contiguous block of DRAM, timer interrupt to
drive the scheduler, and a serial port. I keep thinking there should be a way to
tell the "none" board to add that stuff from the command line... but dunno how.
"map DRAM here". "add this clock hardware at here". "add this kind of serial
port at here." "call elf_load on this file and start executing at its entry
point"...)
3) Reading the arch/hexagon kernel stuff ala "so what IS in a comet board"...
CONFIG_HEXAGON_COMET is only ever used to guard one #define in a header file:
arch/hexagon/include/asm/timer-regs.h:#define RTOS_TIMER_REGS_ADDR
Which is then used to initialize structure members in arch/hexagon/kernel/time.c
without any sort of guard there, and no it isn't #defined to 0 by default
anywhere I can see? And of course obj-y += time.o in
arch/hexagon/kernel/Makefile has no config guard there either. So if it wasn't
set, the build would break. And that's currently all the symbol does?
Anyway, I still hope somebody else has already done most of this in a git tree
somewhere. :)
Rob
diff --git a/default-configs/devices/hexagon-softmmu.mak b/default-configs/devices/hexagon-softmmu.mak
new file mode 100644
index 00..c07ed1132f
--- /dev/null
+++ b/default-configs/devices/hexagon-softmmu.mak
@@ -0,0 +1,5 @@
+# Default configuration for hexagon-softmmu
+
+# Boards:
+#
+CONFIG_HEXAGON_COMET=y
diff --git a/default-configs/targets/hexagon-softmmu.mak b/default-configs/targets/hexagon-softmmu.mak
new file mode 100644
index 00..003ed0a408
--- /dev/null
+++ b/default-configs/targets/hexagon-softmmu.mak
@@ -0,0 +1 @@
+TARGET_ARCH=hexagon
diff --git a/hw/hexagon/Kconfig b/hw/hexagon/Kconfig
new file mode 100644
index 00..9ae8a5ce30
--- /dev/null
+++ b/hw/hexagon/Kconfig
@@ -0,0 +1,2 @@
+config HEXAGON_COMET
+bool
diff --git a/hw/hexagon/boot.c b/hw/hexagon/boot.c
new file mode 100644
index 00..e69de29bb2
diff --git a/hw/hexagon/hexagon_comet.c b/hw/hexagon/hexagon_comet.c
new file mode 100644
index 00..e69de29bb2
diff --git a/hw/hexagon/meson.build b/hw/hexagon/meson.build
new file mode 100644
index 00..83f23f5368
--- /dev/null
+++ b/hw/hexagon/meson.build
@@ -0,0 +1,5 @@
+hexagon_ss = ss.source_set()
+hexagon_ss.add(files('boot.c'))
+hexagon_ss.add(when: 'CONFIG_HEXAGON_COMET', if_true: files('hexagon_comet.c'))
+
+hw_arch += {'hexagon': hexagon_ss}
diff --git a/target/hexagon/machine.c b/target/hexagon/machine.c
new file mode 100644
index 00..e69de29bb2
diff --git a/target/hexagon/mmu.c b/target/hexagon/mmu.c
new file mode 100644
index 00..e69de29bb2
diff --git a/hw/Kconfig b/hw/Kconfig
index 805860f564..7cfd7db690 100644
--- a/hw/Kconfig
+++ b/hw/Kconfig
@@ -62,6 +62,7 @@ source sparc/Kconfig
source sparc64/Kconfig
source tricore/Kconfig
source xtensa/Kconfig
+source hexagon/Kconfig
# Symbols used by multiple targets
config TEST_DEVICES
diff --git a/hw/meson.build b/hw/meson.build
index ba0601e36e..f43c4bacdd 100644
--- a/hw/meson.build
+++ b/hw/meson.build
@@ -46,6 +46,7 @@ subdir('alpha')
subdir('arm')
subdir('avr')
subdir('cris')
+subdir('hexagon')
subdir('hppa')
subdir('i386')
subdir('m68k')
diff --git a/target/hexagon/meson.build b/target/hexagon/meson.build
index 6fd9360b74..aef434421f 100644
--- a/target/hexagon/meson.build
+++ b/target/hexagon/meson.build
@@ -176,3 +176,7 @@ hexagon_ss.add(files(
))
target_arch += {'hexagon': hexagon_ss}
+
+hexagon_softmmu_ss = ss.source_set()
+hexagon_softmmu_ss.add(files('mmu.c', 'machine.c'))
+target_softmmu_arch += {'hexagon': hexagon_softmmu_ss}
Re: [PATCH 01/20] Hexagon HVX (target/hexagon) README
On 7/19/21 11:19 AM, Sid Manning wrote:>> -Original Message-
>> From: Brian Cain
>> Sent: Monday, July 19, 2021 8:40 AM
>> To: Rob Landley ; Taylor Simpson
>> ; qemu-devel@nongnu.org; Sid Manning
>>
>> Cc: a...@rev.ng; peter.mayd...@linaro.org; richard.hender...@linaro.org;
>> phi...@redhat.com
>> Subject: RE: [EXT] Re: [PATCH 01/20] Hexagon HVX (target/hexagon)
>> README
>>
>> > -Original Message-
>> > From: Rob Landley
>> ...
>> > On 7/12/21 8:42 AM, Brian Cain wrote:
>> ...
>> > > and there's also a binary hexagon-linux cross toolchain that we
>> > > shared for use by kernel developers. The hexagon linux toolchain is
>> > > built on Ubuntu 16.04.
>> >
>> > Where's that one?
>>
>> https://codelinaro.jfrog.io/artifactory/codelinaro-qemu/2021-05-
>> 12/clang+llvm-12.0.0-cross-hexagon-unknown-linux-musl.tar.xz -
>> - Built on Ubuntu 16.04, similar dynamic dependencies as
>> releases.llvm.org binaries
Indeed, in a "that also does not run on devuan, which is 99% stock debian" way.
:(
Luckily, I built a working hexagon toolchain with the attached script, as in
"qemu-hexagon ran a statically linked toybox", and it even built a kernel.
I'm still trimming the build script down, that clang-rt section is WAY too big,
and I need to static link the binaires it produces so I can tar 'em up and use
them under a different distro, and I haven't even _started_ making a native
toolchain yet.[1]
Next question: is there a qemu-system-hexagon anywhere?
I mentioned I built a comet_defconfig kernel, ala:
LLVM_IAS=1
CROSS_COMPILE=~/toybox/hexagon/ccc/cross_bin/hexagon-unknown-linux-musl- make
ARCH=hexagon CC=~/toybox/hexagon/ccc/cross_bin/hexagon-unknown-linux-musl-cc
Which is kinda silly because:
1) Other packages figure out that ${CROSS}cc works but Linux insists on
${CROSS}gcc, and you can't even do "CC=cc make" because then it won't add the
cross compiler prefix. (And if I say LLVM=1 on the kernel command line, which I
shouldn't have to do, it uses _unprefixed_ clang as the $CC name, despite cross
compiling.)
2) If you don't set LLVM_IAS it tries to call the UNPREFIXED assembler, again
while cross compiling.
Anyway, I've got a compiler now and I (awkwardly) built a kernel and I'm sitting
down to try to figure out how to get qemu to invoke it: does this arch want
vmlinux or arch/hexagon/boot/$RANDOMFORMAT, is serial on console=ttyS0 or
/significant/dev/prefix/ttyasparagus0 or...
See https://github.com/landley/toybox/blob/master/scripts/mkroot.sh#L186 for the
other architectures I've already added to toybox's mkroot, yes I have a ~250
line bash script that builds bootable Linux systems for a bunch of different
architectures and adding a new architecture looks like:
elif [ "$TARGET" == m68k ]; then
QEMU="m68k -M q800" KARCH=m68k KARGS=ttyS0 VMLINUX=vmlinux
KCONF=MMU,M68040,M68KFPU_EMU,MAC,SCSI_MAC_ESP,MACINTOSH_DRIVERS,ADB,ADB_MACII,NET_CORE,MACSONIC,SERIAL_PMACZILOG,SERIAL_PMACZILOG_TTYS,SERIAL_PMACZILOG_CONSOLE
(There's a little documentation at https://landley.net/toybox/faq.html#mkroot if
you're curious.)
Anyway... it doesn't look like qemu-system-hexagon (softmmu) its currently in
vanilla qemu? Is there a public fork that has this somewhere?
Thanks,
Rob
[1] Why does https://llvm.org/docs/GettingStarted.html#cross-compiling-llvm talk
about osx? Dear compiler writers: a compiler is conceptually the same as an html
to pdf converter. It takes input files, it produces output files. Yes some of
the input files are common library stuff like fonts reused by multiple
input/output pairs... again like an html to pdf converter. This is not
unprecedented black magic. Sure it's clever. So was Quake, which has now been
genericized into a broad industry from WoW to Skyrim.
script.sh
Description: application/shellscript
Re: [PATCH 01/20] Hexagon HVX (target/hexagon) README
On 7/12/21 8:42 AM, Brian Cain wrote:
> If you don't mind binaries, there are x86_64 linux binary toolchains with lld
> on releases.llvm.org
I've never managed to run those binaries, because they're dynamically linked
against some specific distro I'm not using:
$ bin/clang --help
/lib/ld-linux-aarch64.so.1: No such file or directory
All the toolchains I build for distribution are statically linked on the host.
(Back in the day I even wrote a
https://github.com/landley/aboriginal/blob/master/sources/toys/ccwrap.c wrapper
to feed --nostdinc --nostdlib to gcc and build up all the includes again
manually to stop gcc from leaking random host context into the cross compilers,
but these days I use
https://github.com/landley/toybox/blob/master/scripts/mcm-buildall.sh with Rich
Felker's musl-cross-make to create statically linked cross and native musl
toolchains which I would happily post binaries of if they weren't GPLv3 and thus
non-distributable. Oh well.)
Vaguely trying to make an llvm-buildall.sh for toybox, which might be a fourth
section to https://landley.net/toybox/faq.html#cross but first I'm trying to
make the hexagon-only one work based on your model. :)
> and there's also a binary hexagon-linux cross toolchain that
> we shared for use by kernel developers. The hexagon linux
> toolchain is built on Ubuntu 16.04.
Where's that one?
> But when building your toolchain, omitting LLVM_ENABLE_LLD should work just
> fine.
It did, thanks.
Now I'm trying to figure out what all the extra CFLAGS are for.
The clang_rt build has CMAKE_ASM_FLAGS="-G0 -mlong-calls -fno-pic
--target=hexagon-unknown-linux-musl" which
https://clang.llvm.org/docs/ClangCommandLineReference.html defines as:
-G
Put objects of at most bytes into small data section (MIPS / Hexagon)
-mlong-calls
Generate branches with extended addressability, usually via indirect jumps.
I don't understand why your libcc build needs no-pic? (Are we only building
a static libgcc.a instead of a dynamic one? I'm fine with that if so, but
this needs to be specified in the MAKE_ASM_FLAGS why?)
Why is it saying --target=hexagon-random-nonsense-musl to a toolchain
we built with exactly one target type? How does it NOT default to hexagon?
(Is this related to the build writing a hexagon-potato-banana-musl.cfg file
in the bin directory, meaning the config file is in the $PATH? Does clang only
look for it in the same directory the clang executable lives in?)
And while we're at it, the CONTENTS of hexagon-gratuitous-gnu-format.cfg is:
cat < hexagon-unknown-linux-musl.cfg
-G0 --sysroot=${HEX_SYSROOT}
EOF
Which is ALREADY saying -G0? (Why does it want to do that globally? Some sort of
bug workaround?) So why do we specify it again here?
Next up build_musl_headers does CROSS_CFLAGS="-G0 -O0 -mv65 -fno-builtin
-fno-rounding-math --target=hexagon-unknown-linux-musl" which:
-O0
disable most of the optimizer
-mv65
-mtune for a specific hexagon generation.
(Why? Does qemu only support that but not newer?)
-fno-builtin
musl's ./configure already probes for this and will add it if
the compiler supports it.
-fno-rounding-math
the docs MENTION this, but do not explain it.
And again with the -G0.
These flags probably aren't needed _here_ because this is just the headers
install (which is basically a cp -a isn't it?). This looks like it's copied
verbatim from the musl library build. But that library build happens in a bit,
so relevant-ish I guess...
(Also, why does building librt-but-not-really need the libc headers?
The libgcc build EXPLICITLY does not require that, because otherwise you
have this kind of BS circular dependency. Also, how do you EVER build a
bare metal ELF toolchain with that dependency in there?)
Next up build_kernel_headers has KBUILD_CFLAGS_KERNEL="-mlong-calls" which
again, A) why does the compiler not do by default, B) can't be needed here
because you don't even have to specify a cross compiler when doing
headers_install. (I just confirmed this by diffing installs with an without a
cross compiler specified: they were identical. I remembered this from
https://github.com/torvalds/linux/commit/e0e2fa4b515c but checked again to be
sure.) Presumably this is more "shared with full kernel build".
And then build_musl, covered above under the headers build: lotsa flags, not
sure why.
> -Brian
>
Rob
P.S. It took me a while to figure out that clang_rt is NOT librt.a, I think it's
their libgcc? Especially confusing since librt.a has existed for decades and
was on solaris before it was on linux, and the OBVIOUS name is libcc
the same way "cc" is the generic compiler name instead of "gcc".
(In fact that was the posix compiler name until they decided to replace
it with "c99" and everybody ignored them the way tar->pax was ignored,
largely because make's $CC defaults to "cc" so it Just Works, and yes
the cross compiler should have that name but the prepackaged clang tarball
above does not. *shrug* I fix that up when making my pr
Re: [PATCH 01/20] Hexagon HVX (target/hexagon) README
On 7/5/21 6:34 PM, Taylor Simpson wrote: > Signed-off-by: Taylor Simpson > --- > target/hexagon/README | 83 > ++- > 1 file changed, 82 insertions(+), 1 deletion(-) I'm poking at the hexagon toolchain build script you checked into the test directory, which boils down to (starting with): git clone https://github.com/llvm/llvm-project mkdir build-llvm cd build-llvm cmake -G Ninja -DCMAKE_BUILD_TYPE=Release \ -DCMAKE_INSTALL_PREFIX=$(readlink -f ../llvm) -DLLVM_ENABLE_LLD=ON \ -DLLVM_TARGETS_TO_BUILD="Hexagon" -DLLVM_ENABLE_PROJECTS="clang;lld" \ $(readlink -f ../llvm-project/llvm) Except the LLVM_ENABLE_LLD part breaks with a standard debian/devuan x86-64 host toolchain because it ONLY works with host llvm, and apparently only a pretty current one at that: https://github.com/tensorflow/mlir-hlo/issues/4 (Devuan Beowulf only packages lld-7, not lld-10.) I'm currently building: cmake -G Ninja -DCMAKE_BUILD_TYPE=Release \ -DCMAKE_INSTALL_PREFIX=$(readlink -f ../llvm) -DLLVM_ENABLE_PROJECTS="lld" \ $(readlink -f ../llvm-project/llvm) ninja all install On the theory that should give me an lld-git I can play $PATH games and re-run the other build with, but my QUESTION is what does the LLVM_ENABLE_LLD=potato actually accomplish here? Is it a sanitizing step or is there something about building with gcc's lld that's known to break the hexagon toolchain? If I just omit it (to avoid building lld _twice_) will I (probably) get a working hexagon toolchain? (Assuming I do the musl and headers-install builds and so on?) What's the _issue_ here that this config symbol addresses? Thanks, Rob
Re: [RFC PATCH v3 00/34] Hexagon patch series
On 8/30/20 3:47 PM, Taylor Simpson wrote: > Richard, > > Thank you so much for the feedback. I really appreciate it. > > I'll get to work addressing the issues. Since some of the items will take > longer than others, please advise whether it's preferred to send intermediate > updates or wait until they are all addressed. > > Taylor Which branch of https://github.com/quic/qemu do I pull to try this without scraping 30 patches out of the mailing list? >>> Once the series is applied, the Hexagon port will pass "make check-tcg". >>> The series also includes Hexagon-specific tests in tcg/tests/hexagon. >>> >>> We have a parallel effort to make the Hexagon Linux toolchain inside a >> docker >>> container publically available. >> >> Oh, excellent. Is that a follow-up to https://www.spinics.net/lists/linux-hexagon/msg01706.html and is this a clang toolchain or a gcc toolchain? I've noticed gcc 9.2 has hexagon in config.guess and config.sub, but the only other file outside of the test suite containing the word "hexagon" in a case insensitive match is the Changelog saying Linas Veptas added it to config.guess and config.sub in 2011. And while https://github.com/quic has a musl fork it doesn't have any compiler or linker forks... Rob
Re: [Qemu-devel] [PATCH v5 00/11] hw/m68k: add Apple Machintosh Quadra 800 machine
On 11/2/18 6:25 AM, Laurent Vivier wrote: >> If that does not work, I'm also fine if we simply deprecate the simcalls >> (if possible). > > I have a patch to deprecate the interface. I will send it once the > release will be done. Did I ever point out that I got m68k running under your q800 emulation in my https://github.com/landley/mkroot project? Now that m68k is in musl-libc, you can build https://github.com/richfelker/musl-cross-make or grab a prebuilt binary a toolchain from http://b.zv.io/mcm/bin/m68k-linux-musl-cross.tar.gz and then: CROSS_COMPILE=/path/to/m68k-linux-musl-cross/bin/m68k-linux-musl- \ ./mkroot.sh kernel And then: cd output/m68k ./qemu-m68k.sh -hda log.txt The -hda is just so you have a hard drive image you can play with. Cat /dev/?da should show you the log.txt contents. The network interface works too, although I haven't got wget in toybox yet but: echo GET / | netcat landley.net / Works. :) When does this go upstream? P.S. to build a current kernel: cd download git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux cd .. And then mkroot.sh again. I tested with 4.20-rc1 and m68k worked fine. > Thanks, > Laurent Rob
Re: [Qemu-devel] [PATCH QEMU] hw/char/sh_serial: Add timeout handling to unbreak serial input
On 07/30/2018 10:18 AM, Ulrich Hecht wrote:>> On July 30, 2018 at 3:02 PM Geert Uytterhoeven wrote: >> Fix this by adding basic timeout handling. As the QEMU SCIF emulation >> ignores any serial speed programming, the timeout value used conforms to >> a default speed of 9600 bps, which is fine for any interative console. >> >> Reported-by: Rob Landley >> Signed-off-by: Geert Uytterhoeven > > Works for me, kernel 4.18-rc7 for rts7751r2dplus. Works for me too. Tested-by: Rob Landley Rob
Re: [Qemu-devel] [PULL 0/2] M68k for 2.12 patches
On 04/02/2018 02:05 PM, Laurent Vivier wrote: > Le 02/04/2018 à 20:13, Rob Landley a écrit : >>> The branch to use is q800-dev ... >> It booted Linux to a shell prompt, I could wget a file from the internet, and >> /home had the 2 gigabyte ext3 mount from the virtual block device. >> >> I.E. it works for me. Why is it still out of tree? ... > I have to submit some enhancements in the FPU emulation... > I have to add some specific m68k hardware emulation... > but via support should be rewritten... > I have to update some existing hardware emulation... ... > So, this only needs some work and time. 10 years ago: https://lists.gnu.org/archive/html/qemu-devel/2007-10/msg00248.html 6 years ago: https://lists.gnu.org/archive/html/qemu-devel/2011-08/msg02123.html > I hope q800 will be available in QEMU 2.13. Good luck, Rob
Re: [Qemu-devel] [PULL 0/2] M68k for 2.12 patches
On 03/30/2018 12:00 PM, Laurent Vivier wrote: > Le 30/03/2018 à 18:54, Rob Landley a écrit : >> On 03/20/2018 04:08 AM, Laurent Vivier wrote:> This series of patches is >> needed >> to fix a problem >>> in the m68k translator that can crash QEMU when translation >>> cache has too many instructions: >>> >>> qemu-m68k: tcg/tcg.c:883: tcg_temp_alloc: Assertion `n < 512' failed. >>> qemu: uncaught target signal 11 (Segmentation fault) - core dumped >>> >>> I have reproduced it in linux user mode, with "ghc", and in >>> system mode with the debian-installer for unstable distro >>> from debian-ports. >> >> If someone wanted to follow along with your "boot linux on qemu-system-m68k" >> work on https://github.com/vivier/qemu-m68k, which of the 51 branches should >> qemu-system-m68k with like -M q800 or whatever you had working be built from? > > The branch to use is q800-dev There isn't any m68k support in musl-libc yet, so I grabbed my old https://github.com/landley/aboriginal project, did a "./build.sh m68k", built your q800-dev branch, added the m68k-softmmu from that to the start of the $PATH, and ran "more/dev-environment-from-build.sh m68k". It booted Linux to a shell prompt, I could wget a file from the internet, and /home had the 2 gigabyte ext3 mount from the virtual block device. I.E. it works for me. Why is it still out of tree? Rob
Re: [Qemu-devel] [PULL 0/2] M68k for 2.12 patches
On 03/20/2018 04:08 AM, Laurent Vivier wrote:> This series of patches is needed to fix a problem > in the m68k translator that can crash QEMU when translation > cache has too many instructions: > > qemu-m68k: tcg/tcg.c:883: tcg_temp_alloc: Assertion `n < 512' failed. > qemu: uncaught target signal 11 (Segmentation fault) - core dumped > > I have reproduced it in linux user mode, with "ghc", and in > system mode with the debian-installer for unstable distro > from debian-ports. If someone wanted to follow along with your "boot linux on qemu-system-m68k" work on https://github.com/vivier/qemu-m68k, which of the 51 branches should qemu-system-m68k with like -M q800 or whatever you had working be built from? Also, "git pull" of the last tree I had from there exploded into a fireball of automerge conflicts. Is there something I should know? Rob
Re: [Qemu-devel] [PATCH v4 2/7] target/m68k: add MC68040 MMU
On 01/18/2018 01:38 PM, Laurent Vivier wrote: > Only add MC68040 MMU page table processing and related > registers (Special Status Word, Translation Control Register, > User Root Pointer and Supervisor Root Pointer). > > Transparent Translation Registers, DFC/SFC and pflush/ptest > will be added later. I built qemu from thursday's git and qemu-system-m68k -M ? doesn't have an obvious board emulation I can aim a linux kernel at. Is there a qemu tree I should test, or...? (I want to help out and test this stuff, but don't have context...) Rob P.S. My current project for banging on this is https://github.com/landley/mkroot
Re: [Qemu-devel] qemu-system-sh4 -M r2d serial is broken.
On 05/18/2017 06:01 PM, Aurelien Jarno wrote: > On 2017-05-18 17:37, Rob Landley wrote: >> On 05/18/2017 02:00 PM, Aurelien Jarno wrote: >>> On 2017-05-18 11:08, Rob Landley wrote: >>>> Serial input hangs after the first character in the 4.11 kernel: >>>> >>>> http://www.spinics.net/lists/linux-sh/msg51183.html >>>> >>>> Because they enabled support for a buffer size thing QEMU doesn't >>>> emulate right: >>>> >>>> http://www.spinics.net/lists/linux-sh/msg51189.html >>> >>> Indeed the SCIF emulation in QEMU is quite limited. The problem is that >>> it exposes many internal states to the software (and that's the same for >>> the SH4 CPU in general), and that's not really compatible with quick >>> emulation. In that case the timer should depend on the baud rate which >>> we don't really emulate. >>> >>> I'll try to have a look, that said my test environment is stuck with >>> kernel 4.8 due to the broken futex support on UP in kernel 4.9 (and >>> that's not QEMU specific). I'll try to build a more recent kernel with >>> additional patches. >> >> I thought Rich fixed that. Rich? > > I have sent a patch already, but TTBOMK it hasn't been applied yet. > > Aurelien I poked Rich about the futex patch again today, he's been buried up to his neck in work but has to flush his bugfix queue before -rc5 so that should get sorted this week. Also, how do I tell the kernel to read the persistent clock on r2d? Both CONFIG_RTC_DRV_R9701 (from r2d defconfig) and CONFIG_RTC_DRV_SH give error messages and fail to read anything at boot time. If you need a new test environment (simple one that doesn't use futexes that I'm aware of) https://github.com/landley/mkroot is nearing its first release. You'll need to follow the README instructions to build musl-cross-make toolchains and set up the mcm symlink, but then: ./cross.sh sh4 ./mkroot.sh kernel cd output/sh4 ./qemu-sh4.sh Should boot you to a shell prompt. And given that the root filesystem builder (mkroot.sh) is ~300 lines of bash and module/kernel is another 300 lines (mostly a big target-specific if/else staircase), it shouldn't be too hard to pull apart. :) Right now sh4 is the only target in the release list that hasn't got the full "boots to a shell prompt and exits when you type exit, clock is set to correct time, block device works, network card works" functionality list. (That's all working on arm64 armv5l armv7l i486 i686 mips mipsel powerpc s390x x86-64.) Rob
Re: [Qemu-devel] How do you -sd squashfs.img without truncating?
On 05/30/2017 07:17 AM, Peter Maydell wrote: > On 8 May 2017 at 06:08, Rob Landley wrote: >> As far as I can tell "qemu-system-arm -M vexpress-a9" only implements sd >> card, not any conventional hard drive, and it uses an sdcard block size >> of 262144 bytes rounded down. This means when I create a squashfs image >> and feed it in through the sd card, it truncates it. >> >> Wouldn't -sd rounding _up_ be more useful? > > This vaguely rings a bell but I forget exactly. I think the > intention is that you're supposed to pass it a file of > exactly the right length, not one that's too short. If we > rounded up, then it would create the awkward question of > "what happens when the guest writes into the bit of the > sd card image that doesn't actually exist in the image file". > > I'm not strongly attached to the current behaviour (especially > if the behaviour for sd card images doesn't match that for > hd images and other kinds of disk), but I think that may have > been the "this is more complicated than it appears on the surface" > reason that nobody's got round to trying to change the behaviour. > It's been years though, so I might just be completely misremembering. I worked around it by switching to the -M virt machine. (The project is https://github.com/landley/mkroot if you're curious.) Thanks, Rob
Re: [Qemu-devel] Commit b2a575a1c652 broke i486 support.
On 05/29/2017 05:14 AM, Richard W.M. Jones wrote: > I see in the disassembly use of cmovne (new in Pentium Pro) and > bswap (new in 486). > [http://cse.unl.edu/~goddard/Courses/CSCE351/IntelArchitecture/InstructionSetSummary.pdf] > > The cmovne instruction is generated by the compiler (GCC in my case), > > The following patch removes the cmovne instruction, so it should work > on 486 (although I didn't test it). It's not possible to remove bswap > without surgery on the inline assembler. Is there any way to make it just _not_ load the option rom for -cpu 486? It ran fine before that thing went in... Rob
[Qemu-devel] Commit b2a575a1c652 broke i486 support.
You can't boot a kernel under -cpu 486 since that commit (hangs producing no output) because it added a bios image that won't run on anything short of pentium II. You can try the run-emulator.sh script in http://landley.net/aboriginal/downloads/binaries/system-image-i486.tar.gz before and after that commit to check for yourself. Rob
Re: [Qemu-devel] qemu-system-sh4 -M r2d serial is broken.
On 05/18/2017 06:00 PM, Aurelien Jarno wrote: >> Exiting the linux instance says "reboot: Restarting system\nUnauthorized >> access" and then hangs eating 100% cpu, but maybe I can fix that with >> kernel configuration changes. > > I guess you mean rebooting the linux instance. This is because you do > not use a bootloader to load the kernel and the initrd. Then you might > be interested in: > > http://lists.nongnu.org/archive/html/qemu-devel/2017-05/msg03881.html That patch worked for me. Rob
Re: [Qemu-devel] qemu-system-sh4 -M r2d serial is broken.
On 05/18/2017 02:00 PM, Aurelien Jarno wrote: > On 2017-05-18 11:08, Rob Landley wrote: >> Serial input hangs after the first character in the 4.11 kernel: >> >> http://www.spinics.net/lists/linux-sh/msg51183.html >> >> Because they enabled support for a buffer size thing QEMU doesn't >> emulate right: >> >> http://www.spinics.net/lists/linux-sh/msg51189.html > > Indeed the SCIF emulation in QEMU is quite limited. The problem is that > it exposes many internal states to the software (and that's the same for > the SH4 CPU in general), and that's not really compatible with quick > emulation. In that case the timer should depend on the baud rate which > we don't really emulate. > > I'll try to have a look, that said my test environment is stuck with > kernel 4.8 due to the broken futex support on UP in kernel 4.9 (and > that's not QEMU specific). I'll try to build a more recent kernel with > additional patches. I thought Rich fixed that. Rich? I'm doing a new https://github.com/landley/mkroot thing on top of Rich's musl-cross-make toolchain, but it's still cooking and the kernels it builds are really simple so far. Rob
Re: [Qemu-devel] qemu-system-sh4 -M r2d serial is broken.
On 05/18/2017 02:57 PM, Paolo Bonzini wrote: > > > On 18/05/2017 18:08, Rob Landley wrote: >> Serial input hangs after the first character in the 4.11 kernel: >> >> http://www.spinics.net/lists/linux-sh/msg51183.html >> >> Because they enabled support for a buffer size thing QEMU doesn't >> emulate right: >> >> http://www.spinics.net/lists/linux-sh/msg51189.html > > Hey, > > regarding this: > >> The really _fun_ thing about this is qemu broke it a couple years back >> and now if you hit ctrl-c it kills the _emulator_ rather than passing it >> through to the Linux console. (Just sh4, the rest do it right.) > > Try replacing "-serial stdio" with "-serial mon:stdio". You'll also be > able to use the QEMU monitor with "Ctrl-a c", so you can quit with > "Ctrl-a c quit ". Ctrl-c now goes through. Thanks! Exiting the linux instance says "reboot: Restarting system\nUnauthorized access" and then hangs eating 100% cpu, but maybe I can fix that with kernel configuration changes. (I'm still doing a variant of https://landley.net/aboriginal/control-images so the virtual system needs to be able to indicate when it's done. But https://landley.net/aboriginal/about.html is getting replaced with https://github.com/landley/mkroot so there's some plumbing to do before that's blocking anything...) Thanks again, Rob
[Qemu-devel] qemu-system-sh4 -M r2d serial is broken.
Serial input hangs after the first character in the 4.11 kernel: http://www.spinics.net/lists/linux-sh/msg51183.html Because they enabled support for a buffer size thing QEMU doesn't emulate right: http://www.spinics.net/lists/linux-sh/msg51189.html Rob
[Qemu-devel] multiple -append?
When I feed a second -append to qemu-system-i386 they don't get concatenated, the second replaces the first. Why is it called "append" then? Rob
[Qemu-devel] How do you -sd squashfs.img without truncating?
As far as I can tell "qemu-system-arm -M vexpress-a9" only implements sd card, not any conventional hard drive, and it uses an sdcard block size of 262144 bytes rounded down. This means when I create a squashfs image and feed it in through the sd card, it truncates it. Wouldn't -sd rounding _up_ be more useful? Rob
Re: [Qemu-devel] [Question]Support of China loogson processor
On Mon, Apr 13, 2015 at 6:29 AM, vt wrote: > Hi, guys > > I saw the architecture code about mips in the qemu and kvm modules, so it is > no doubt that mips cpu can be supported. It looks like the 32 bit one should work fine. I haven't played with 64 bit yet but there's some support for it in the tree, give it a try? http://en.wikipedia.org/wiki/Loongson Heh. The background on the "4 patented instructions" mentioned above is mips' lawsuit against Lexra many years ago: http://landley.net/notes-2009.html#14-12-2009 If you were wondering why mips had a lost decade where most of its customers switched over to arm, convincing the world you're a patent troll will do that. But it's been well over a decade and most people seem to have forgotten now. And china never cared about US intellectual property infighting anyway... > But I wonder if anyone have used qemu/kvm virtualization with China loongson > processor (MIPS architecture) without modification of qemu/kvm code. > All the infomation I have searched in the Internet can't answer my question. I have a mips r4k system emulation working fine at: http://landley.net/aboriginal/bin/system-image-mips.tar.gz (That's based off of linux 3.18 I think, I have 3.19 building locally, 4.0 is on the todo list.) I haven't tried 64 bit yet but: $ qemu-system-mips64 -cpu ? | grep Loongson MIPS 'Loongson-2E' MIPS 'Loongson-2F' It's apparently there... Rob
Re: [Qemu-devel] bug (bisected): qemu-system-sh4 serial console, ctrl-C kills emulator
On 09/01/14 03:07, Paolo Bonzini wrote: > Il 01/09/2014 07:05, Rob Landley ha scritto: >> If you grab http://landley.net/aboriginal/bin/qemu-system-sh4.tar.bz2 >> extract it and ./run-emulator.sh (which is a fairly straightforward >> qemu-system-sh4 invocation on the included kernel image and squashfs >> root filesystem), older qemu versions would run it just fine, and ctrl-C >> would pass through to the shell. But current qemu, ctrl-C kills the >> emulator. >> >> I bisected this to commit 02c4bdf1d2ca, although that's between commit >> a9e8aeb3755b (which broke the sh4 pci bus) and b23ea25f5098 (which made >> it boot again), so you have to either revert the first or apply the >> second in order to test that the reverted commit fixes it. > > I get a 404 error, but this is most likely not sh4 specific---can you > just post here the command line? I just did (sorry, checked the mailing list folder and didn't see a reply, I forgot gmail filters out "duplicates" like being cc'd on the same message, because the gmail developers hate threading.) The correct URL is: http://landley.net/aboriginal/bin/system-image-sh4.tar.bz2 The command line is: qemu-system-sh4 -M r2d -nographic -no-reboot -kernel zImage -hda hda.sqf -append "root=/dev/sda rw init=/sbin/init.sh panic=1 PATH=/bin:/sbin console=ttySC1 noiotrap HOST=sh4" -monitor null -serial null -serial stdio And the email telling me to use that command line way back when was: http://lists.gnu.org/archive/html/qemu-devel/2009-02/msg00825.html More context: http://lists.gnu.org/archive/html/qemu-devel/2010-03/msg00976.html Sorry for the confusion, I _really_ need to stop sending these things after midnight... Rob
Re: [Qemu-devel] bug (bisected): qemu-system-sh4 serial console, ctrl-C kills emulator
On 09/01/14 00:05, Rob Landley wrote: > If you grab http://landley.net/aboriginal/bin/qemu-system-sh4.tar.bz2 > extract it and ./run-emulator.sh (which is a fairly straightforward > qemu-system-sh4 invocation on the included kernel image and squashfs > root filesystem), older qemu versions would run it just fine, and ctrl-C > would pass through to the shell. But current qemu, ctrl-C kills the > emulator. > > I bisected this to commit 02c4bdf1d2ca, although that's between commit > a9e8aeb3755b (which broke the sh4 pci bus) and b23ea25f5098 (which made > it boot again), so you have to either revert the first or apply the > second in order to test that the reverted commit fixes it. > > Rob This time cc'ing the people who signed-off-by the buggy commit. Before commit 02c4bdf1d2ca signal handling in qemu-system-sh4 with serial console on stdin/stdout worked properly, as in ctrl-c would kill the shell, not the emulator. After that commit, ctrl-c kills the emulator, not the shell. You can test this by grabbing the tarball in the first line above, and runnign the run-emulator.sh script, which is just: qemu-system-sh4 -M r2d -nographic -no-reboot -kernel zImage -hda hda.sqf -append "root=/dev/sda rw init=/sbin/init.sh panic=1 PATH=/bin:/sbin console=ttySC1 noiotrap HOST=sh4" -monitor null -serial null -serial stdio Again, this worked before the above commit, and has been consistently broken since that commit. Rob
[Qemu-devel] bug (bisected): qemu-system-sh4 serial console, ctrl-C kills emulator
If you grab http://landley.net/aboriginal/bin/qemu-system-sh4.tar.bz2 extract it and ./run-emulator.sh (which is a fairly straightforward qemu-system-sh4 invocation on the included kernel image and squashfs root filesystem), older qemu versions would run it just fine, and ctrl-C would pass through to the shell. But current qemu, ctrl-C kills the emulator. I bisected this to commit 02c4bdf1d2ca, although that's between commit a9e8aeb3755b (which broke the sh4 pci bus) and b23ea25f5098 (which made it boot again), so you have to either revert the first or apply the second in order to test that the reverted commit fixes it. Rob
Re: [Qemu-devel] ARM testing image
On 11/12/2013 08:30:39 AM, Peter Maydell wrote: On 12 November 2013 14:27, Xin Tong wrote: > Hi > > I would like to know where i get can 32bit ARM image For which board? > with appropriate network driver. Appropriate for what? http://people.debian.org/~aurel32/qemu/armel/ has a simple versatile kernel/initrd/filesystem (it's a little old, though). My aboriginal linux project (http://landley.net/aboriginal/about.html) is more or less aimed at this. Every new kernel release I try to have a build with the current kernel for arm, mips, ppc32, sh4, x86, x86-64, and sparc out before -rc1 hits. http://landley.net/aboriginal/downloads/binaries You probably want system-image-armv5l.tar.bz2, that's for the versatile board. The ./run-emulator.sh script should boot it to a shell prompt. These images include a native toolchain capable of rebuilding themselves under themselves, and also building linux from scratch. The ./dev-environment.sh script boots qemu with more memory and 2 gigs of persistent scratch space mounted on /home (and will even set it up to call out to the cross compiler via distcc if you've installed the appropriate stuff on the host). If you just want to jump straight to the linux from scratch images, they're in the "extras" subdirectory. The advantage of these is you can easily reproduce them from source, so they tend to have up to date kernel and busybox versions. (There's no such thing as an update uClibc version, but I'm switching that to musl-libc. And I kept the toolchains at the last gplv2 release because the FSF has gone sort of crazy, http://ellcc.org should have something I can switch to before too much longer. And yeah, I'm moving the linux from scratch build script to 7.4, I've just been buried in other todo items...) FYI, Rob
Re: [Qemu-devel] [PATCH] tcg-hppa: Remove tcg backend
On 10/01/2013 12:19:51 PM, Richard Henderson wrote: On 09/25/2013 12:27 PM, Richard Henderson wrote: > Signed-off-by: Richard Henderson > --- > > Since the GCC compile farm took their hppa machine off-line, I have no way > to test this port anymore. Worse, I can't find any distributions that still > support hppa, so I can't even download binaries for use in cross-compilation. > And I'm unwilling to bootstrap an entire system from scratch for this. Bootstrapping entire systems from scratch is a thing I do, so I poked at a uClibc config (no dynamic linker and thus no shared library support, but ok) and a kernel config (the hppa defconfig is funky, but oh well)... But there's no qemu system emulation for hppa or parisc. Bootstrapping a system doesn't help if qemu can't actually emulate a board to run it on. (Am I missing something?) Rob
Re: [Qemu-devel] bochs BIOS configuration and initialization
On 09/30/2013 12:25:45 PM, Min LI wrote: Dear all, I am very interested in QEMU and trying to figure out the boot process of guest VM. According to my understanding about QEMU code, bochs BIOS is loaded into memory by pc_system_firmware_init(…). However, I notice QEMU handles hardware initialization, allocates memory and stores user's configuration in fw_cfg. In addition, QEMU loads linux by load_linux(…). Then my question is what does bochs BIOS do during the period guest VM boots. Based on my understanding, QEMU has already finished many works belong to BIOS, why does QEMU load BIOS into memory? I will really appreciate any comments and help. The bochs BIOS loads the boot sector from emulated hard drives, provides the BIOS callbacks from Ralph Brown's interrupt list so the boot sector can load the rest of the bootloader and print messages on the screen during boot, plus some low level hardware probing like "where is the physical memory". Early boot code (BIOS, u-boot, etc) do several things: 1) Initialize hardware (most prominently the DRAM controller that does memory refresh). 2) Provide a minimal bootloader to load other code into memory and run ig. 3) Provide callbacks so that early code can access primitive I/O drivers without having to contain its own. 4) Provide hardware description data (from device tree all that horrible ACPI nonsense). Classic 16-bit PC bios did DRAM init, loaded the boot sector, and provided the "bios calls" so the boot sector could load more sectors and write text to the screen. (Ralph brown's interrupt list documented those bios calls.) Some of those bios calls returned data about how many disks you could load stuff from and how much memory was in the system (later this was replaced by data tables describing address ranges where physical memory was present, and still later by ACPI because the Intel guys didn't want itanic to depend on running 8086 code so they shoehorned a half-assed Java interpreter into ROM). Anyway, all of these BIOS functions got cloned as open source, but it took two projects: 1) Coreboot (formerly linuxbios) handles the early hardware init, primarily DRAM init. Until the DRAM controller is initialized and refreshing the DRAM, it won't remember what was stored in it so you have to run out of non-volatile memory (or at least non-DRAM, processors tend to have a little SRAM built in to act as cache. Coreboot cleverly maps the L2 cache to act as the early C stack, for example, since it doesn't need to be refreshed. Pin a TLB entry, tell it never to write back to underlying DRAM until it's evicted, zero it out, and then carefully don't touch any other memory until you finish DRAM init...) QEMU doesn't need coreboot, because it doesn't emulate the hardware at that level. 2) Bochs bios. Takes over once the system is up enough to run stuff out of DRAM. QEMU uses that to load boot sector and provide bios callbacks for basic I/O services to write to the screen and load more sectors from boot device and such. Projects like u-boot combine both functions into one giant hairball. Rob
Re: [Qemu-devel] [PATCH] Update MAINTAINERS
On 10/02/2013 06:40:18 PM, Laurent Vivier wrote: Le 02/10/2013 20:42, Rob Landley a écrit : Laurent Vivier has an m68k gitorious branch to add the q800 target, which I've occasionally tested and would really really like to see finished and merged. Alas, last time I tested it the sucker died during the kernel boot as soon as mmu setup tried to enable the page tables. But before that I got three lines printk'd! (Woo! Progress!) Now, kernel is able to try to load its first userspace process but fails in ld.so somewhere when it is trying to map process memory (another MMU bug...) Progress! Still: possible m68k guy? Maybe? If he's interested? Yes, I can do that. There is not a lot of activity on this, anyway. I still have m68k images built form current kernels, I just can't test them. I'd poke at it and report bugs, but you know what the bugs are as well as I do. I don't know what the thing _should_ be doing, so... Rob
Re: [Qemu-devel] [PATCH] Update MAINTAINERS
On 10/02/2013 12:09:58 PM, Anthony Liguori wrote: All of Paul's emails are bouncing and he hasn't been active for some time. ... M68K -M: Paul Brook -S: Odd Fixes +S: Orphan F: target-m68k/ F: hw/m68k/ Laurent Vivier has an m68k gitorious branch to add the q800 target, which I've occasionally tested and would really really like to see finished and merged. Alas, last time I tested it the sucker died during the kernel boot as soon as mmu setup tried to enable the page tables. But before that I got three lines printk'd! (Woo! Progress!) Still: possible m68k guy? Maybe? If he's interested? Rob
Re: [Qemu-devel] [RFC 0/4] ARM aarch64 disas output libvixl support
On 09/11/2013 07:54:32 AM, Claudio Fontana wrote: This is the aarch64 libvixl support patchset in the current state. It provides (limited) support for disassembly output on aarch64. Only host disassembly is enabled, since target for aarch64 is not in yet. An external objdump solution as exemplified before by R.H. seems preferable to me, even if it means giving up the monitor support. I'd rather have correct output from -d. The run time need for debugging assembly is already fulfilled by gdb better than the monitor. libvixl does not support many opcodes right now, is C++, and it is documented as working only for a 64bit host with a LP64 memory model. Wait, incorporating C++ code into qemu was considered the _good_ solution? What was the bad solution? Rob
Re: [Qemu-devel] [RFC] TCG unit testing
On 09/02/2013 11:07:03 AM, Aurelien Jarno wrote: On Fri, Aug 23, 2013 at 12:47:43PM -0700, Richard Henderson wrote: > I've been thinking for a while about how to reliably test TCG backends, and > maybe how to do regression testing on them. Having to begin the test from a > guest binary, especially considering the vast cross-compilation problem, is > pretty much a non-starter. Given the regular breakages we have with TCG, it's really a gread idea. Usually most of the targets are working correctly so the problem is not found immediately. > I've been thinking of a truly stripped down target for the purpose, with a > special-purpose machine loop and main to go with it. I.e. avoid vl.c. I think we should use as much as possible of the current infrastructure, having two different main loops means they are going to be desynchronised at some point. Ideally it would be nice to have a machine called TCG (maybe with a few variants for big/little endian, 32 and 64-bits) which loads TCG "code" from a text file and execute it. Then we can imagine zillions of small testcases like the GCC ones, and more can be added when a problem is discovered and fixed. Someday, I'd still like to hook Fabrice's old tinycc front end to tcg as the code generation backend... Rob
Re: [Qemu-devel] minimal linux distribution for qemu
On 08/18/2013 08:57:08 AM, Herbei Dacian wrote: good to know. I was working back in 2005-2006 with a company that had a 4MB kernel. At that time I was too inexperienced to work at that level but I thought now I could reproduce their work with some help. Anyhow for the moment I'll go for 256 MB of ram board just so that I don't worry too much about things that are not yet relevant for me. But thanks again for the warning. But since you helped me soo much I have another question. Is it fisible to change the emulator so that I may visualize the following aspects: _ address of the currently executed instruction from the guest system _ if this instruction is a form of jump like call return conditional jump. _ the address or range of addresses read by this instruction _ the address or range of addresses written by this instruction If you feed qemu the -s option it'll open a network port you can connect to to provide the gdbserver protocol (gdb's "target remote" command attaches to this). For system emulation it acts like a jtag attached to the emulated hardware, letting you see registers and such. I read some things about the emulator and if I understood it correctly the emulator breaks the instructions of the gurest platform in micro ops which are then executed on the host operation system. Not really, no. QEMU translates large blocks of code (used to be pages, now it's variable sized chunks depending on where the return instruction is) and keeps the translated versions cached (sort of like a java JIT). The main QEMU loop then calls the translated functions which execute until they return or get interrupted by signals (simulating things like timer IRQ). This is why QEMU is so fast, the actual translation overhead is amortized by the resulting native code being run lots of times, a function or loop gets translated once and then runs as native code. This means that "the address of the currently executing instruction" isn't really something qemu naturally tracks, because although there _is_ a copy of the untranslated code page, it's not what we're running. The gdbserver code tries to do so artifically, but it's slow and awkward and not always perfect. Self-modifying code is actually a horrible thing to do to qemu, from a performance perspective. Every time the emulated code page is modified, the cached copy of the translated code is discarded and the entire page gets retranslated. This means that in Aboriginal Linux, the shell scripts ./configure runs sped up 20% when I replaced my dynamically linked busybox with a statically linked one, due to the extra translations caused by the relocation fixups. Rob
Re: [Qemu-devel] minimal linux distribution for qemu
On 08/16/2013 11:17:06 AM, Herbei Dacian wrote: my system should run in far less memory. something like 2-4MB. but first I need to have a system running so that I can monitor with qemu the addresses accessed for read execute and write by the code run by the emulator. if I reach that is a real big deal. dacian Linux 2.6 and later won't run in 2 megs at all. You can trim it down to 4 megs on a nommu system (the page tables take up too much ram otherwise), but won't be able to do much. Really, things like kobjects in the modern kernel take up too much space. Getting anything to work in 4 megs requires diabling all the printk strings at compile time. (The last time I saw somebody do a 4 meg system was CELF in 2006. 32 bit x86.) Look at the uClinux project. Or try to bolt your app onto uboot and run it on the bare metal. Rob
Re: [Qemu-devel] minimal linux distribution for qemu
On 08/15/2013 09:18:48 AM, Herbei Dacian wrote: but you said that "qemu-system-arm" is not maintained and it doesn't work. Who said that? git log --pretty=format:"%h %ci %s" hw/arm be2f78b 2013-08-05 11:46:58 -0500 pxa2xx: Avoid object_get_link_property() asser cfc6b24 2013-07-29 21:06:27 +0200 versatilepb: QOM cast cleanup for vpb_sic_stat 0ca8187 2013-07-29 21:06:27 +0200 strongarm: QOM cast cleanup for StrongARMSSPSt fff3af9 2013-07-29 21:06:27 +0200 strongarm: QOM cast cleanup for StrongARMUARTS Something like 50 commits to hw/arm last month alone, and August was feature freeze for the 1.6.0 release. (If it _wasn't_ actively developed I wouldn't have had to work around a darn IRQ routing issue on the arm target in the last Aboriginal release...) Rob
Re: [Qemu-devel] minimal linux distribution for qemu
On 08/15/2013 09:01:19 AM, Herbei Dacian wrote: yes but which binary do I use to call to run an emulated arm image? is there an actual binary that can emulate an existing arm board, anyboard? qemu? if not which is the emulator that works with arm? If not where is the project that I can tweak to build such a binary. The arm versatilepb emulation can accept a range of processors (I've tried armv4, armv4t, armv5, armv6, and armv7), provides a PCI bus with a virtual hard drive controller and network card, and can accept 256 megs of ram. (In theory it can accept more but I have to get the discontiguous memory stuff to work, haven't done that yet.) That's the one I used in Aboriginal Linux arm images. Rob
Re: [Qemu-devel] minimal linux distribution for qemu
On 08/15/2013 06:53:30 AM, Andreas Färber wrote: Hi, Am 15.08.2013 10:57, schrieb Herbei Dacian: > > please, can anyone recommend me a distribution that offers a barebone > linux kernel. > minimum that I need on that image are: > _ the kernel > _ the compiler and development infrastructure to build it Aboriginal Linux. Andreas Aboriginal actually comes with qemu launch scripts for each target. ./run-emulator.sh is just the qemu command line, ./dev-environment.sh is a wrappe around that providing a better development enviornment (more memory and disk space). It's all described at http://landley.net/aboriginal/about.html Try this: wget http://landley.net/aboriginal/bin/system-image-armv5l.tar.bz2 tar xvjf system-image-armv5l.tar.bz2 cd system-image.armv5l ./run-emulator.sh gcc /usr/src/thread-hello2.c -lpthread ./a.out exit Thanks, Rob
Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+
On 08/12/2013 11:45:49 AM, Russell King - ARM Linux wrote: On Mon, Aug 12, 2013 at 05:24:50PM +0100, Peter Maydell wrote: > On 12 August 2013 01:40, Guenter Roeck wrote: > > On 08/11/2013 03:04 PM, Russell King - ARM Linux wrote: > >> It could be that it's qemu's PCI routing is wrong - it's not the first > >> time that qemu has got something wrong. > > QEMU 1.5 has had its Versatile PCI routing code rewritten to > correspond with the hardware (cross-tested versus Arnd Bergmann's > patchset > http://marc.info/?l=linux-arm-kernel&m=128707282403376&w=2 > which was run on real versatilePB backplane hardware and > could handle a PCI SATA card). I believe it to be correct, > and I spent a fairly long time wading through the various bits > of documentation and testing those kernel patches on h/w. The documentation is totally useless - I've been through it several times and it just doesn't give the necessary information to work out what the routing actually is. The only place that's documented is in the circuits, which are impossible to get hold of (even asking ARM for them doesn't get anywhere: basically, all information has been destroyed.) We had this argument on the qemu list. See this and Peter's reply message to it: http://lists.nongnu.org/archive/html/qemu-devel/2013-07/msg01202.html I got my images working by setting a magic value to a register to convince current qemu that it was running an old kernel, and then using the IRQ mapping of the old kernel before Linux went through multiple different random things that didn't work on the emulator _or_ any hardware. Peter says he knows somebody who knows somebody who dug some instance of this hardware out of some landfill or something. Me, I want to get something that works on new qemu _and_ last year's qemu, and that's what I got. I think that's far more interesting since the point of qemu's versatile emulation is really just "an arm board QEMU can stick a PCI bus in and thus attach arbitrary devices like network cards and hard drives to in a somewhat flexible way". > If somebody would like to fix the kernel I am happy to > locate the PCI backplane and test everything (again). > I would suggest that producing some patches which work > with QEMU 1.5 or later would be a good start; then we > can test on h/w as confirmation before they are applied. If someone is willing to send me some definitive information, then the kernel will get fixed. All the time that there is no definitive information, there is no point what so ever changing the kernel. Because working with old and new qemu, like it used to before everybody fiddled with it to not actually match hardware nobody _has_, is definitely not an interesting goal. If it was, I'd point you to: http://landley.net/hg/aboriginal/rev/c756b708583f Rob
Re: [Qemu-devel] Licensing question
On 07/31/2013 12:19:03 AM, Stefan Weil wrote: Am 31.07.2013 03:50, schrieb Erik de Castro Lopo: > Hi all, > > I have a patch I would like to submit and I am currently running it past > my employer's legal department. The legal department has identified 10 > different licenses in the Qemu codebase and has asked about the two files > I am modifying: > > linux-user/syscall.c > linux-user/syscall_defs.h > > For the first its easy as it is clearly marked as GPLv2+. The second is > unmarked. Is there some blanket statement somewhere that all files that > are not explicitly marked are under say GPLv2+? > > Cheers, > Erik No, there is no such statement. There is an agreement that files with GPL should be GPLv2+ (not only GPLv2), but files may also use other free licenses. In file LICENSE, it is said that QEMU as a whole is released under the GNU General Public License. Which, if you don't specify, could mean GPLv1. Some files are copied from Linux and therefore must use the Linux license (usually GPLv2). syscall_defs.h might be a copy from Linux (=> GPLv2). If not, the default rule from LICENSE could be applied (=> GPL). Some directories, such as TCG, have their own LICENSE files. These are generally BSD-style license which are donor-compatible (but not receiver-compatible) with GPLv2 or later. (If "you are obligated to include this license text verbatim, but it does not actually apply to the file" is an acceptable definition of "compatible", but that's a legal argument nobody's made in court yet so I'm sure you're fine. Nor has anybody recently brought up whether "the Software" you're obligated to include it in is just source versions or requires the license text to be in the binary; Android does it to be safe, most others don't bother.) Rob (Personally I look back at the days when my Commodore 64 came bundled with a "Disk Bonus Pack" of public domain software mostly written by Jim Butterfield, and going "why did we stop doing that again? Because awaiting hot coffee lawsuits was worse than awaiting patent troll lawsuits?")
Re: [Qemu-devel] Emulating mips
On 07/23/2013 12:16:53 AM, Renich Bon Ciric wrote: Hello, I am new to this... I'm trying to run some rom file I got from a client. It's a sc2005 processor; supposedly compatible with 4k. Anyway, I do this: qemu-system-mips -M mips -pflash 301-3100\ -\ user\ specified\ -\ Full.bin -serial stdio The processor goes to 100% but I see nothing, not in the serial console nor in the window (monitor, maybe?) I'd appreciate some tips I have working mips images at http://landley.net/aboriginal/bin/system-image-mips.tar.bz2 Grab that extract it, and ./run-emulator.sh. That should let you know what "working" looks like, and if you can dig a chroot or loopback mount out of your rom image, you can probably mount it under there and try running the binaries. Rob
Re: [Qemu-devel] [PATCH 0/4] alpha-softmmu fixes
On 07/10/2013 08:49:35 AM, Richard Henderson wrote:
On 07/09/2013 10:43 AM, Rob Landley wrote:
> Do you have a kernel .config that boots on this board? I'd really
like to try
> this out myself...
I haven't worked on this in quite some time. But I've located two
branches
that look like they might be the code corresponding to my image. Try
git://github.com/rth7680/linux.git axp-qemu-{1,2}
Do I just do 'make defconfig'? Or do I need to involve
arch/alpha/defconfig somehow?
The -1 branch looks newer, but the -2 branch contains more code
specific to
qemu. Both are over 2 years old, so I'm not sure what I was going
for...
There are now -3 and -4 branches...
Wow, -4 is current with upstream I think? Cool, I'll try that. Still no
obvious arch/alpha/config, but I'll just try "make defconfig" and hope
for the best...
The most important bits are trivial to Kconfig, enabling the pci
virtio
devices, as they don't require a working IOMMU.
Many moons ago (2009?) I built an alpha toolchain, userspace, and
kernel, but couldn't boot it under qemu because there was no
qemu-system-alpha.
what I'd like to do is build a 3.10 kernel with:
1) Serial console on qemu's stdin/stdout.
2) Block device driver of some kind (ide, scsi, virtio...)
3) network card
4) at least 256 megs memory
5) battery backed up clock
The IOMMU was a bit of a pipe dream 2 years ago, and only in the last
3-4
months has the code enabling that actually gotten merged. Perhaps
I'll find
some time to actually write the code to emulate that now...
As for configury, choose dp264 or generic.
"clipper" seems to be default, and that's dp264...
Rob
[Qemu-devel] Linux 3.10 test images for arm, mips, powerpc, sparc, sh4...
Prebulit binaries of all of the above are at:
http://landley.net/aboriginal/bin
The "system-image" tarballs are bootable system images, tested under
qemu 1.5.1, which provide a shell prompt on qemu's stdin/stdout and a
native compiler capable of building Linux From Scratch inside the
emulator. Each contains three wrapper scripts:
1) run-emulator.sh - boot qemu to a shell prompt.
2) dev-environment.sh - development environment (allocate extra
memory/storage).
3) native-build.sh - see http://landley.net/aboriginal/control-images
The "cross-compiler" tarballs are cross compilers, extract anywhere and
add the "bin" subdirectory to your $PATH, then use ${PREFIX}-cc as your
compiler. If this cross compiler is in your path and distccd is
isntalled on the host, the dev-environment.sh script will configure
qemu to call out to the cross compiler via loopback.
If you'd like to build these images yourself from source, grab the
tarball from:
http://landley.net/aboriginal/downloads/aboriginal-1.2.4.1.tar.bz2
And type "./build.sh armv5l" or similar. (Run it with no arguments to
see a target list.)
More documentation than anyone is likely to read is available at:
http://landley.net/aboriginal/about.html
Rob
(Sorry for the noise, but I spent _effort_ making this work with qemu
1.5.1. Almost just put "use 1.2.0" in the release notes, but eventually
got fixes for arm, sparc, and sh4 _without_ sacrificing backwards
compatability with the old releases.)
Re: [Qemu-devel] [PATCH 0/4] alpha-softmmu fixes
On 07/08/2013 08:01:08 PM, Richard Henderson wrote: The recent changes for ioport memory regions is a blessing and a curse for the simplified alpha machine model we have. On the one hand, we can eliminate two hacks present in the tsunami system chip emulation. We also now get machine checks when we access ioports that aren't connected to a device. On the other hand, we aren't currently connecting many of the silly little isa devices normally handled by the SuperIO chip hanging off the PCI bus. Stuff we don't really need for the running kernel, but gets initialized during normal startup anyway. E.g. the ISA DMA engine and the com2 uart. The later device is particularly annoying, since we can't actually get to qemu_chr_open_null at the moment. Rather than properly fill in the blanks, I cheat in the second patch and just discard unused reads and writes in the isa io region. This restores the state of affairs we had before the recent changes. Do you have a kernel .config that boots on this board? I'd really like to try this out myself... Thanks, Rob
Re: [Qemu-devel] [PATCH v4 00/11] Fix versatile_pci
On 06/29/2013 06:03:26 AM, Peter Maydell wrote: On 28 June 2013 08:01, Rob Landley wrote: > Now that the next kernel's about to come out, I'm trying to get my arm > versatile image to work under qemu 1.5.0. The old kernel doesn't work, and > the current vanilla kernel doesn't work. This change broke it. > > I'm testing current linux-git both with and without this patch: > > --- linux/arch/arm/mach-versatile/pci.c 2013-04-28 19:36:01.0 -0500 > +++ linux.bak/arch/arm/mach-versatile/pci.c 2013-04-29 > 19:09:44.857097553 -0500 > @@ -333,7 +333,7 @@ > * 26 1 IRQ_SIC_PCI2 > * 27 1 IRQ_SIC_PCI3 > */ > - irq = IRQ_SIC_PCI0 + ((slot - 24 + pin - 1) & 3); > + irq = 59; //IRQ_SIC_PCI0 + ((slot - 24 + pin - 1) & 3); > > return irq; > } > > With the patch, qemu 1.2.0 works, but qemu 1.5 versatile does not work with > or without the patch. The "with the patch" case is uninteresting, because it's not actually a fix for anything, it's just a change that happened to work with old QEMU, and it's not a change that is in upstream Linux. I want to create a kernel image that works with the existing QEMU image people are likely to have installed on their systems, _and_ with current versions of QEMU. Is that what you consider "uninteresting"? > Here's a test image to demonstrate the problem: it works fine under qemu > 1.2.0, but doesn't under 1.5.0: > > http://landley.net/aboriginal/bin/system-image-armv5l.tar.bz2 > > Extract it and ./run-emulator.sh. You get a shell prompt from 1.2.0, from > 1.5.0 it never gets a scsi interrupt, and after a timeout goes into an > abort/reset loop. Is this an image with your patch or without it? Does it work if you use the -global option to force legacy IRQ mapping? Under qemu 1.2? It goes: qemu-system-arm: Property '.broken-irq-mapping' not found See "backwards compatability", above. I am trying to produce "an image that runs under qemu". That level of genericity worked for several years, at least ever since 1.0. When it stopped, I complained. You seem to be expressing incredulity at the concept. >> >> This version of the patchset avoids breaking legacy Linux guests >> >> by automatically detecting those broken kernels and switching back >> >> to the old mapping. > > > As testing with the above image confirms: it does not. I tested with several separate variants of the Linux kernel. I tried building a vanilla linux 3.10 kernel, and it doesn't work on qemu 1.5. I confirmed their current interrupt mapping does not match any known hardware or emulator, and that it changed more than once in incompatible ways as they did wild-ass-guess du jour about what it should be now. The fact it was obviously untested (or it wouldn't keep changing, since there presumably is just one right answer) says to me that this hardware is difficult ot come by. (The fact the IRQ spent over 5 years in the old state before anyone noticed would also imply a lack of test hardware.) However, it's useful to emulate because you can stick a PCI bus in it, meaning you can stick arbitrary devices (hard drive and network card) into said bus. So I did the obvious-to-me thing and patched it back to how it _was_, which is the only thing that works with previous versions of QEMU. You seem to find this approach shocking and unexpected. Do you have a better way to achieve compatability with older versions of qemu _and_ current versions? (I'm open to suggestions...) >> >> This works by looking at the values the kernel >> >> writes to the PCI_INTERRUPT_LINE register in the config space, which >> >> is effectively the interrupt number the kernel expects the device >> >> to be using. If this doesn't match reality we use the broken mapping. >> >> (Thanks to Michael S. Tsirkin for this suggestion.) > > Define "reality". "would work on real hardware". The stuff that's so rare the kernel guys couldn't find any to test on? Maybe I haven't been clear: I want something that works with current QEMU _and_ old QEMU. Your paragraph above implies that there's smoething _different_ I can write to PCI_INTERRUPT_LINE that will trigger the old behavior. So my patch to do the old IRQ (which worked fine with qemu 1.2) needs to be bigger to humor QEMU's heuristic. I'll try to figure out how to extend my patch to avoid triggering your new "does not work" mode. Let's see, stick a printf into qemu, and: =Write 60=12,59= So it's requesting IRQ 59, and QEMU's re
Re: [Qemu-devel] Openbios upgrade broke sparc32 linux.
On 06/29/2013 03:29:08 PM, Olivier Danet wrote: How embarrassing... - QEMU 1.5.1 can boot Debian Etch (kernel 2.6.18), RedHat 4.2 (kernel 2.0.30), NetBSD 6.1 and OpenBSD 5.3. - Your image (Linux 3.8) can be started with a TurboSparc CPU : qemu -cpu "Fujitsu MB86907". Yay! That fixes it. Thanks. - My SparcStation-5 has a 110MHz MicroSPARC-II and the .attributes (aka .properties) fields are identical to OpenBIOS values, except for the mask_rev : I have 0x26, OpenBIOS sets 0x23 Before the patch, OpenBIOS had an incoherence between the PSR register content and the BIOS defined values. In Linux "arch/sparc/mm/srmmu.c:get_srmmu_type(void)", this correspond to "a TurboSparc emulating Swift". (Swift is the MS-2). TurboSPARC could be the new QEMU default, but, ideally, the MS-II should be preferred as it is compatible with more OSes ( hoping to run NextStep in QEMU one day ...). Maybe recent Linux kernels are not compatible with the way QEMU emulates the MS-II... Or it could require a config tweak to the kernel, or some -mtune a compile time. I'm happy enough with a different -cpu for sparc: I just want to run the thing to natively compile software under emulation and avoid more cross compiling. Thanks, Rob
Re: [Qemu-devel] Openbios upgrade broke sparc32 linux.
On 07/04/2013 04:52:45 PM, Olivier Danet wrote: On 29/06/2013 22:29, Olivier Danet wrote: On 28/06/2013 23:44, Mark Cave-Ayland wrote: On 28/06/13 03:08, Rob Landley wrote: Commit 467b34689d27 upgraded the openbios image, and ever since my linux system images hang about the time they try to initialize interrupts. http://landley.net/aboriginal/bin/system-image-sparc.tar.bz2 Extract that and "./run-emulator.sh" in the tarball. Using qemu 1.2.0 for example works fine, you get a shell prompt. Using 1.5.0 hangs. ... Hello I think I have found the problem. Each SPARC CPU model use different MMU TLB management functions. For Linux, the callbacks are set in arch/sparc/mm/srmmu.c : xxx_flush_tlb_all, xxx_flush_tlb_mm, xxx_flush_tlb_range, xxx_flush_tlb_page. The assembly code used for the MicroSparcII is arch/sparc/mm/swift.S. This code accesses the vm_mm member of vm_area_struct (include/linux/mm_types.h) The position of the vm_mm field in the structure was modified recently, and the assembly was not adjusted accordingly. (https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/include/linux/mm_types.h?id=e4c6bfd2d79d063017ab19a18915f0bc759f32d9) The bug was introduced in Linux 3.8 Here is a patch for swift, there are also issues in hypersparc.S, viking.S, tsunami.S ...: [snip patch that wasn't sent to linux-kernel] For a cleaner fix, arch/sparc/kernel/asm_offsets.c should be modified. Huh, confirming that my old linux 3.5 image does boot under current qemu. (I only tested back to 3.8, which worked before the qemu change for some reason.) In the meantime, the -cpu "fujitsu thx1138" workaround is working for me, well enough to ship the 3.10 images as soon as I get arm working again. (Or just go "use qemu 1.2.0 for arm" and punt until next time...) Rob
Re: [Qemu-devel] [PATCH v4 00/11] Fix versatile_pci
On 04/08/2013 03:16:18 PM, Peter Maydell wrote: On 8 April 2013 18:37, Rob Landley wrote: > On 04/06/2013 10:44:25 AM, Peter Maydell wrote: >> >> This patch series fixes a number of serious bugs in our emulation of >> the PCI controller found on VersatilePB and the early Realview boards: >> * our interrupt mapping was totally wrong > > > Yes. Yes it was. However, what you were doing matched the kernel for many > years. > The kernel guys have screwed this up three consecutive times, as described > here: > > http://landley.net/hg/aboriginal/rev/7bf850767bb8 > > Because as far as I can tell, nobody has any test hardware for this anymore. There is some but it's pretty rare. Now that the next kernel's about to come out, I'm trying to get my arm versatile image to work under qemu 1.5.0. The old kernel doesn't work, and the current vanilla kernel doesn't work. This change broke it. I'm testing current linux-git both with and without this patch: --- linux/arch/arm/mach-versatile/pci.c 2013-04-28 19:36:01.0 -0500 +++ linux.bak/arch/arm/mach-versatile/pci.c 2013-04-29 19:09:44.857097553 -0500 @@ -333,7 +333,7 @@ * 26 1 IRQ_SIC_PCI2 * 27 1 IRQ_SIC_PCI3 */ - irq = IRQ_SIC_PCI0 + ((slot - 24 + pin - 1) & 3); + irq = 59; //IRQ_SIC_PCI0 + ((slot - 24 + pin - 1) & 3); return irq; } With the patch, qemu 1.2.0 works, but qemu 1.5 versatile does not work with or without the patch. Here's a test image to demonstrate the problem: it works fine under qemu 1.2.0, but doesn't under 1.5.0: http://landley.net/aboriginal/bin/system-image-armv5l.tar.bz2 Extract it and ./run-emulator.sh. You get a shell prompt from 1.2.0, from 1.5.0 it never gets a scsi interrupt, and after a timeout goes into an abort/reset loop. >> This version of the patchset avoids breaking legacy Linux guests >> by automatically detecting those broken kernels and switching back >> to the old mapping. As testing with the above image confirms: it does not. >> This works by looking at the values the kernel >> writes to the PCI_INTERRUPT_LINE register in the config space, which >> is effectively the interrupt number the kernel expects the device >> to be using. If this doesn't match reality we use the broken mapping. >> (Thanks to Michael S. Tsirkin for this suggestion.) Define "reality". The kernel changed what irqs it was expecting _three_times_ last year, and as far as I can tell none of them were what they were _trying_ to do. Here's my blog entry and the source control comments where I diagnosed this stuff to show that the kernel guys have no flipping CLUE how an arm versatile board actually works: 1) http://landley.net/notes-2013.html#15-03-2013 2) http://landley.net/hg/aboriginal/rev/1588 3) http://landley.net/hg/aboriginal/rev/1589 Here's the text from #2: = The arm guys have now screwed up the ARM versatile board's IRQ routing three consecutive times. I'm impressed. The ARM versatile scsi IRQ is position 27 on the IRQ controller. That's what QEMU implemented, that's what worked for years. In commit 1bc39ac5dab2 the kernel guys screwed up their math (among other things doing -24 and then &3 on the result.. can we say NOP?) so it was now trying to use IRQ 28 once the unnecessary "swizzle" function got done with it. (I started reverting that 6 months ago in aboriginal changeset 1534.) Then in commit f5565295892e they incremented the IRQ controller start by 32... and didn't adjust map_irq() so it was still requesting 28, now before the start of the IRQ controller's range. Then in commit e3e92a7be693 they noticed it was broken, and added 64 to it. (So now it's requesting 64+28=92, when it _should_ be requesting 32+27=59. Their own description of what changed does not support what the patch did, and yet...) = All that was about the SCSI IRQ. Entry #3 above was about the _ethernet_ IRQ, which they screwed up in a different way (they did an &3 in a way that wrapped)about how they did the math for the ethernet irq wrong in a _different_ way than they did the scsi irq math wrong. The line that's actually calculating the IRQ is: irq = 27 + ((slot - 24 + pin - 1) & 3); Since 24 is divisible by 3, subtracting 24 and then & 3 on the result is a NOP so this math can't POSSIBLY do what they think it's doing. The kernel code in this area is CRAP, has changed multiple times in semi-random ways, has obviously NEVER been tested on real hardware, and if you've implemented what the actual versatile documentation says it's clearly not what the kernel is doing. > My concern here was that you'd g
[Qemu-devel] Patch to fix linux for sh4.
I have images that boot under qemu-system-sh4 at:
http://landley.net/aboriginal/bin/system-image-sh4.tar.bz2
But in order to get them to work with current kernels, I have to apply
the attached sh4.patch to qemu.
What I did with earlier kernels was apply the attached
linux-fixsh4-2.patch but more recent kernels added another access to
the same register somewhere and the proper fix is for qemu to ignore it
(it's a NOP) rather than exiting the emulator.
Robdiff --git a/hw/char/sh_serial.c b/hw/char/sh_serial.c
index b328643..81d374a 100644
--- a/hw/char/sh_serial.c
+++ b/hw/char/sh_serial.c
@@ -248,11 +248,9 @@ static uint64_t sh_serial_read(void *opaque, hwaddr offs,
s->flags &= ~SH_SERIAL_FLAG_RDF;
}
break;
-#if 0
case 0x18:
ret = s->fcr;
break;
-#endif
case 0x1c:
ret = s->rx_cnt;
break;
This is "the wrong fix". The correct fix is to qemu (take out the "#ifdef 0"
around the 0x18 case in hw/sh_serial.c line 250 or so, or just don't
abort() on unknown register reads), and I pinged the qemu
mailing list about that, but this works with existing qemu releases.
diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index 1bd9163..fa043f1 100644
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -1879,7 +1879,7 @@ static void sci_set_termios(struct uart_port *port, struct ktermios *termios,
sci_init_pins(port, termios->c_cflag);
- reg = sci_getreg(port, SCFCR);
+ reg = sci_getreg(port, 0x30);
if (reg->size) {
unsigned short ctrl = serial_port_in(port, SCFCR);
[Qemu-devel] Openbios upgrade broke sparc32 linux.
Commit 467b34689d27 upgraded the openbios image, and ever since my linux system images hang about the time they try to initialize interrupts. http://landley.net/aboriginal/bin/system-image-sparc.tar.bz2 Extract that and "./run-emulator.sh" in the tarball. Using qemu 1.2.0 for example works fine, you get a shell prompt. Using 1.5.0 hangs. Rob
[Qemu-devel] x86-64 apic panic on shutdown on 1.4.93.
I intermittently get this from current kernels running under currentish
qemu-git. Look familiar to anybody?
reboot: machine restart
general protection fault: fff2 [#1]
CPU: 0 PID: 44 Comm: oneit Not tainted 3.10.0-rc7+ #3
Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
task: 8800068fd500 ti: 880006a26000 task.ti: 880006a26000
RIP: 0010:[] []
lapic_shutdown+0x32/0x34
RSP: 0018:880006a27e28 EFLAGS: 0202
RAX: 2193fbf9078bfbf9 RBX: 0202 RCX:
RDX: 81015f71 RSI: 00ff RDI: 00f0
RBP: fee1dead R08: 0400 R09:
R10: R11: 88000699f500 R12:
R13: 01234567 R14: 0004 R15: 00423872
FS: () GS:81308000()
knlGS:
CS: 0010 DS: ES: CR0: 8005003b
CR2: 00657ad0 CR3: 0697c000 CR4: 06b0
DR0: DR1: DR2:
DR3: DR6: DR7:
Stack:
28121969 81013bda 03f9 81013dc5
8102ad4b
Call Trace:
[] ? native_machine_shutdown+0x6/0x1a
[] ? native_machine_restart+0x1d/0x31
[] ? SyS_reboot+0x126/0x15b
[] ? schedule_tail+0x1e/0x44
[] ? ret_from_fork+0xf/0xb0
[] ? system_call_fastpath+0x16/0x1b
Code: 53 f6 c4 02 75 1b 31 c0 83 3d af 42 50 00 00 74 0c 31 c0 83 3d b4
42 50 00 00 0f 94 c0 85 c0 74 0a 9c 5b fa e8 88 ff ff ff 53 9d <5b> c3
50 e8 11 ec 00 00 e8 d6 2f ff ff 48 8b 05 43 4b 32 00 bf
RIP [] lapic_shutdown+0x32/0x34
RSP
---[ end trace dd3c376274d1a087 ]---
Re: [Qemu-devel] [RFC] reverse execution.
On 05/19/2013 03:09:14 PM, Mark Burton wrote: Spot on Peter, The (simplistic) plan is simply to take a snapshot at regular intervals, when you want to step backwards, you return to a snapshot, and then re-run forwards to 'just before you started'. You'd have to snapshot all of memory because any of it could be used for branching decisions. You'd have to snapshot the state of I/O devices for the same reason. This includes serial ports and keyboards and your hardware random number generator and the timer interrupt and disk interrupts, all of which you have to log and replay the input from, and get the timing exactly right for the interrupts they generate. (It has to happen at the right spot because it's used to update the random number pool, it can affect scheduling decisions...) Good luck with that. A horrid thing you might do is log the instruction pointer every time it changes into a (giant) ring buffer. Possibly instrument tcg to write up that register every time it has to actually know it (jumps and when interrupts happen). (You don't have to know "advanced to next instruction". You do have to know "advanced to something other than next instruction".) It'll be slow and painful, but might be possible. Then again to make it work you'd have to log not just where you went but where you came _from_ so you could see that you got there and it's time to jump again (interrupts again, doesn't mean it's a normal departure point, could be a signal). And the problem is do you record the target's idea of "from" or the translated host idea of "from"... Rob
Re: [Qemu-devel] [RFC] reverse execution.
On 05/17/2013 12:23:51 PM, KONRAD Frédéric wrote: On 09/05/2013 19:54, Blue Swirl wrote: On Tue, May 7, 2013 at 6:27 PM, KONRAD Frédéric wrote: Hi, We are trying to find a way to do reverse execution happen with QEMU. ... For now we tried some other things which are not working very well, It appeared that the replay is not deterministic even with icount: You're aware that reverse execution means you have the "come from" problem, right? (The opposite of goto.) You literally _can't_ figure out your control flow by running the code backwards. It's equivalent to solving the halting problem. The best you can do is log and replay. Rob
Re: [Qemu-devel] Reporting Heisenbugs in qemu
On 05/08/2013 04:45:45 AM, Torbjorn Granlund wrote: Paolo Bonzini writes: I guess that's the register windows. There's only so much you can do to optimize them, and heavily recursive workloads (like Perl, or the RTL half of GCC) pay a hefty price. Two qemu targets stand out for slowness, sparc (32 and 64) and mips (64, don't know about 32). x86 (32 and 64), arm, and ppc run with a slowdown of < 30 for my bogus benchmark of GMP configure+make. With FreeBSD x86_64 I see a slowdown of just 13. (My reference system runs FreeBSD, so running FreeBSD under qemu is only far.) My claimed slowdown factors are affected by kernel, libraries, and unfortunately very much by gcc speed, which vary with target. If the sparc emulation speed is due to register windows, then why does mips seem just as slow? If register windows shortage is a problem, it should be easy to pretend to have lots of them, right? sh4 is pretty slow too. Unfortunately: http://landley.net/aboriginal/bin/system-image-sh4.tar.bz2 Only has 64 megs of memory in the emulated board. (Enough to build hello world, not enough to build most packages.) I have a vague todo item to add a command line thing to qemu to plug a physical memory address range into an aribtrary address and then tell linux discontigmem "add memory range HERE" on the command line. That way I wouldn't have to hack up each board emulation to get more memory...) Rob
Re: [Qemu-devel] Target-agnostic virtio?
On 04/30/2013 04:31:29 PM, Artyom Tarasenko wrote: On Mon, Apr 29, 2013 at 7:43 AM, Rob Landley wrote: > On 04/27/2013 03:00:06 PM, Artyom Tarasenko wrote: >> >> > For a lot of the 64-bit targets, actual 64 bit userspace support is >> > strangely lacking. For ppc64 they say to use ppc32, and I've been told >> > that >> > about sparc64 as well. I don't know if this is an optimization or a >> > requirement. I have a 32 bit image, I'd like to test the 64 bit >> > codepaths as >> > well... >> >> I guess it's rather an optimisation. At least I saw BusyBox working under >> QEMU before the sparc v8plus was fixed. > > > If you mean http://busybox.net/downloads/binaries/busybox-sparc that's a > 32-bit binary output from the Aboriginal Linux build. No, I mean busybox-static_1.18.4-2_sparc64.deb from the older Debian distribution. Meanwhile it's 1.20, http://ftp.debian-ports.org/debian/pool-sparc64/main/b/busybox/busybox-static_1.20.0-8_sparc64.deb but I only experimented with 1.18. Back then it was definitely a pure 64 bit application: let's see, wget the 1.20 version, dpkg-deb -X busybox-static* sparky, strings sparky/bin/busybox | grep -i libc... Statically linked against glibc 2.13. Still, good test for at least the application emulation side of things. I hit the limits of platform support I could beat out of uClibc a few years back, and these days I'm poking at musl. (It doesn't support much yet, but it's a _lot_ easier to add new targets and klibc provides bsd-licensed templates for most of them.) I need to reproduce the existing uClibc targets I'm using so I can wean my project off of that package before worrying too much about new stuff though. :) Thanks, Rob
Re: [Qemu-devel] [RFC] Moving Hard Freeze to Monday, May 6th.
On 04/30/2013 01:36:39 PM, Anthony Liguori wrote: The current release schedule has hard freeze happening tomorrow. There are a few things still outstanding including cpu hotplug and updating SeaBIOS. We still need to resolve how to handle the softfloat code too. I am particularly interested in this last one for the 1.5 release. Sparc's OpenBios also needs a refresh to handle longer command lines: http://lists.gnu.org/archive/html/qemu-devel/2013-04/msg03880.html Rob
[Qemu-devel] sh4 serial still screwed up.
This issue here: http://lists.nongnu.org/archive/html/qemu-devel/2012-07/msg03870.html Still hits the 3.8 kernel by the way: wget http://landley.net/aboriginal/bin/system-image-sh4.tar.bz2 tar xvjf system-image-sh4.tar.bz2 cd system-image-sh4 ./run-emulator.sh Still tracking down a different problem in the 3.9 kernel for sh4... Rob
Re: [Qemu-devel] Target-agnostic virtio?
On 04/27/2013 03:00:06 PM, Artyom Tarasenko wrote: > For a lot of the 64-bit targets, actual 64 bit userspace support is > strangely lacking. For ppc64 they say to use ppc32, and I've been told that > about sparc64 as well. I don't know if this is an optimization or a > requirement. I have a 32 bit image, I'd like to test the 64 bit codepaths as > well... I guess it's rather an optimisation. At least I saw BusyBox working under QEMU before the sparc v8plus was fixed. If you mean http://busybox.net/downloads/binaries/busybox-sparc that's a 32-bit binary output from the Aboriginal Linux build. (I try to upload new ones each time Denys has a release, but I'm buried in todo items and don't always get to it. Right now I need to clean up and repost the inittmpfs patches for 3.9...) Rob
Re: [Qemu-devel] OpenBios in Sparc can't handle long kernel command lines.
On 04/19/2013 05:27:55 AM, Mark Cave-Ayland wrote: On 22/03/13 05:19, Rob Landley wrote: If I do this: qemu-system-sparc -nographic -no-reboot -kernel image -hda hda.sqf -append 'root=/dev/sda rw init=/sbin/init.sh panic=1 PATH=/usr/distcc:/bin:/sbin console=ttyS0 HOST=sparc CPUS=1 DISTCC_HOSTS=10.0.2.2:31322/1 FTP_SERVER=10.0.2.2 FTP_PORT=31307 NATIVE_BUILD=lfs-bootstrap ' -hdb hdb.img -hdc lfs-bootstrap.hdc -m 256 qemu goes: ^[[H^[[JConfiguration device id QEMU version 1 machine id 32 CPUs: 1 x FMI,MB86904 Unhandled Exception 0x0007 PC = 0xffd07d28 NPC = 0xffd07d2c Stopping execution And then hangs. I've never figured out why it clears the screen first (none of the other targets do), but I _have_ figured out that the unhandled exception is "kernel command line too long". Because 197 bytes is just too much data for Sparc to cope with. Rob This is now fixed in OpenBIOS SVN trunk, and so should be included in QEMU 1.5 when we update the images in git master. Thanks for the report! Yay! Thank you. I look forward to trying it out when QEMU refreshes. Rob
Re: [Qemu-devel] Target-agnostic virtio?
On 04/20/2013 05:36:46 AM, Blue Swirl wrote: > I plan to add a sparc64 target built from source to Aboriginal Linux. > > For a lot of the 64-bit targets, actual 64 bit userspace support is > strangely lacking. For ppc64 they say to use ppc32, and I've been told that > about sparc64 as well. I don't know if this is an optimization or a > requirement. I have a 32 bit image, I'd like to test the 64 bit codepaths as > well... It's a sort of optimization, the pointers are smaller. OpenBSD/sparc64 takes a different approach, every binary is 64 bits. Would it be hard to make Aboriginal *BSD? ;-) Not _that_ hard, but I'm not sure it's interesting? Aboriginal Linux is basically 7 packages: linux, gcc, binutils, uClibc, make, bash, and busybox. (I also add distcc so the native toolchain can move some of the heavy lifting of compilation outside the emulator, but that's optional.) This is the smallest system capable of not only rebuilding itself under itself, but building Linux From Scratch under the result (and thus natively bootstrapping up to an arbitrary set of packages). I'm gradually replacing busybox with toybox, and I'm migrating from uClibc to musl. I vaguely plan to read the various klibc arch support bits to add new architectures to musl, but my day job doesn't have anything to do with my hobby programming so there's a chronic shortage of time, and toybox 1.0 is my priority right now for reasons I blatered at length about at ELC a month or so back (http://youtu.be/SGmtP5Lg_t0). In theory swapping in a bsd kernel and libc, and beating the toolchain into accepting it, might not be too hard. But what I'm more likely to do is try to add sparc64 support to musl and convince the toolchain it's just going to have to cope with the idea of a 64 bit sparc userspace. Rob
Re: [Qemu-devel] Target-agnostic virtio?
On 04/14/2013 04:38:23 AM, Artyom Tarasenko wrote: On Sat, Apr 13, 2013 at 7:03 PM, Rob Landley wrote: > On 03/26/2013 02:34:50 AM, Artyom Tarasenko wrote: >> >> On Tue, Mar 26, 2013 at 1:52 AM, Rob Landley wrote: >> > Can the virtio things (serial, network, block, virtfs) be used on >> > arbitrary >> > targets yet? I.E. Can I use a virtio network device on arm, mips, >> > powerpc, >> > sparc... >> >> Yes. Moreover, for sparc64 the virtio network is currently the only >> way to have a network under Linux guest (and a virtio block is the >> only to have a disk under Linux guest). > > > Do you have an example kernel .config and qemu command line showing how to > use virtio for those? (Or a working sparc64 image you can point me to?) Yes. Will send it to you as I get to my home machine. Can you make them available on your site? I plan to add a sparc64 target built from source to Aboriginal Linux. For a lot of the 64-bit targets, actual 64 bit userspace support is strangely lacking. For ppc64 they say to use ppc32, and I've been told that about sparc64 as well. I don't know if this is an optimization or a requirement. I have a 32 bit image, I'd like to test the 64 bit codepaths as well... I have a Debian Wheezy RC1 / SPARC64 How-To, it would be nice to link to the .config and kernel, so people would be able to install it just by a few clicks. I have http://landley.net/aboriginal/about.html Rob
Re: [Qemu-devel] Target-agnostic virtio?
On 04/14/2013 02:49:53 PM, Artyom Tarasenko wrote: On Sun, Apr 14, 2013 at 11:59 AM, Mark Cave-Ayland wrote: > On 14/04/13 10:38, Artyom Tarasenko wrote: > >>> Do you have an example kernel .config and qemu command line showing how >>> to >>> use virtio for those? (Or a working sparc64 image you can point me to?) >> >> >> Yes. Will send it to you as I get to my home machine. Can you make them >> available on your site? > > > Note that there is a section of test kernel images on the QEMU site at > http://wiki.qemu.org/Testing, so if you could upload it to there that would > be great :) I don't see how to upload files. Can only edit the page. I've got build scripts that reproducibly create bootable system images (with native compilers capable of building linux from scratch) for several different variants of arm, mips, ppc32, sparc32, sh4, x86, and x86-64. (It also builds m68k that runs under aranym but not qemu.) http://landley.net/aboriginal/about.html Basically go to http://landley.net/aboriginal/bin and grab a system-image-*.tar.bz2 and ./run-emulator.sh in there. If you want an extracted root-filesystem-*.tar.bz2 that's in there too, and the various config files used to make it should be in /usr/src under there. If you want to build from source, grab the http://landley.net/aboriginal/downloads most recent tarball, extract it, and "./build.sh sparc" or similar. (If it breaks, tell me. I collect reproducible bug reports.) I put out a new release about each time a kernel comes out. I don't announce 'em here because I didn't think you were interested... >> I have a Debian Wheezy RC1 / SPARC64 How-To, it would be nice to link to >> the .config and kernel, so people would be able to install it just by >> a few clicks. > > This is very interesting - could you post a link to the how-to? I temporarily put it offline till I find a hosting for the kernel. For some reason the standard Wheezy/sparc64 kernel is not stable under QEMU. How is your kernel nonstandard, and what's the instability? I booted the one you sent me but it went: netconsole: network logging started VFS: Cannot open root device "vda1" or unknown-block(253,1): error -6 Please append a correct "root=" boot option; here are the available partitions: fd00 28212 vda driver: virtio_blk Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(253,1) Call Trace: Probably because the sparc root filesystem I have lying around is squashfs. I can rebuild with ext2 but not on my lunch break. (I cleaned out the build dir so it has to build the cross toolchains first, underpowered netbook, takes a while...) I have various patches I need to apply to get stuff to work at http://landley.net/hg/aboriginal/file/tip/sources/patches and am always working out more. (I push them upstream when I can, but the maintainers aren't always interested.) (Currently the project is migrating from uClibc to musl libc, in part because I can fish target support out of klibc and apply it to musl in a way I can't for uClibc, so I can _finally_ get s390 and such to work... But day job and my other projects eat lots of time so it goes slowly...) Rob
Re: [Qemu-devel] Target-agnostic virtio?
On 03/26/2013 02:34:50 AM, Artyom Tarasenko wrote: On Tue, Mar 26, 2013 at 1:52 AM, Rob Landley wrote: > Can the virtio things (serial, network, block, virtfs) be used on arbitrary > targets yet? I.E. Can I use a virtio network device on arm, mips, powerpc, > sparc... Yes. Moreover, for sparc64 the virtio network is currently the only way to have a network under Linux guest (and a virtio block is the only to have a disk under Linux guest). Do you have an example kernel .config and qemu command line showing how to use virtio for those? (Or a working sparc64 image you can point me to?) Thanks, Rob
Re: [Qemu-devel] [PATCH v4 00/11] Fix versatile_pci
On 04/06/2013 10:44:25 AM, Peter Maydell wrote: This patch series fixes a number of serious bugs in our emulation of the PCI controller found on VersatilePB and the early Realview boards: * our interrupt mapping was totally wrong Yes. Yes it was. However, what you were doing matched the kernel for many years. I build system images that are working on versatilePB right now, with the 3.8 kernel. http://landley.net/aboriginal/bin/system-image-armv5l.tar.bz2 Grab that, ./run-emulator.sh and it should boot to a shell prompt within which you can compile hello world. The kernel guys have screwed this up three consecutive times, as described here: http://landley.net/hg/aboriginal/rev/7bf850767bb8 Because as far as I can tell, nobody has any test hardware for this anymore. (But no other board emulation I've tried lets me stick a PCI bus and a scsi controller, ethernet, and serial port into an arm board along with enough memory to natively compile stuff.) This past release I tried to fix it up properly: http://landley.net/notes.html#15-03-2013 http://landley.net/notes.html#16-03-2013 And then I gave up and hit it with a rock: http://landley.net/hg/aboriginal/rev/96fb8598a446 This version of the patchset avoids breaking legacy Linux guests by automatically detecting those broken kernels and switching back to the old mapping. This works by looking at the values the kernel writes to the PCI_INTERRUPT_LINE register in the config space, which is effectively the interrupt number the kernel expects the device to be using. If this doesn't match reality we use the broken mapping. (Thanks to Michael S. Tsirkin for this suggestion.) My concern here was that you'd going to change qemu so it doesn't run the old images, and require a very new qemu to run the new images, so there will be an incompatible flag day. This is especially a concern for me because I had to go back to qemu 1.2.0 to get stable builds on all my targets, because the 1.3.0 and 1.4.0 releases were both broken: http://landley.net/aboriginal/news.html Yay improving the latest and greatest, but when I'm regression testing as many different platforms as I can get working, stuff tends to break. (The most recent target-specific one for me on the QEMU side was probably the powerpc video thing, http://landley.net/notes-2012.html#17-11-2012 . Other than the 1.3/1.4 general TCG instability which was the translation unit size being calculated wrong.) This is why I can't demand my users upgrade each time I do a release: the target they're interested in might not work because my images depend on things you don't regression test much. I'm glad to see you're addressing backwards compatability, but it looks like I might have to patch my kernels to write the _old_ value to this register in order to get something that runs on old qemu? Because I broke my kernel to fit what qemu was doing, and I dunno when this register write changed. (I _do_ know that what the kernel guys have been doing to versatile is insane and inconsistent, and if you change your code to humor them they'll probably break it again. Their register mapping in 3.8 was so wrong even _I_ could tell.) Rob
Re: [Qemu-devel] [PATCH 3/3] PPC PReP: can run without bios image
On 04/04/2013 04:57:32 AM, Artyom Tarasenko wrote: On Thu, Apr 4, 2013 at 11:50 AM, Alexander Graf wrote: > > On 04.04.2013, at 11:46, Artyom Tarasenko wrote: > >> On Thu, Apr 4, 2013 at 10:37 AM, Fabien Chouteau wrote: >>> >>> On 04/03/2013 06:59 PM, Alexander Graf wrote: On 03.04.2013, at 18:40, Fabien Chouteau wrote: > If we use an ELF kernel there's no need for bios. '-bios -' means no > bios. This sounds like you're actually looking for a way to load an ELF blob as bios using -bios, not a kernel, no? >>> >>> No, we load the kernel with -kernel, that's what the first patch does. >>> But the board is implemented in such way that you can't start without a >>> bios. If the -bios switch is not present, then the board uses the >>> default bios. This patch allows to start without a bios: >>> >>> -kernel -bios - >> >> Regardless of the firmware vs. kernel discussion, I think the syntax >> may be improved. Under *nix '-' is commonly used for stdin. Would it >> be possible to specify /dev/null (under *NIX) or NUL (in the >> MS-World)? I think it would make the syntax more explicit. > > I'd be inclined to say that running -kernel without -bios is simply bogus and shouldn't ever happen. QEMU does it at least in one other architectures though: leon3_generic. sh4 runs without bios, arm versatile runs without bios, mips runs without bios... http://landley.net/aboriginal/bin/system-image-armv5l.tar.bz2 (or system-image-sh4.tar.bz2 or system-image-mips.tar.bz2) and ./run-emulator.sh in that. Boots to a shell prompt, no bios. Rob
Re: [Qemu-devel] [RFC PATCH 1/3] target-i386: Add 486sx, old486, and old486sx CPU models
On 03/28/2013 03:12:11 PM, H. Peter Anvin wrote: On 03/28/2013 12:15 PM, Aurelien Jarno wrote: > > This really looks like Linux kernel specific. I haven't been able to > test on a real machine, but the documentation I have found suggest that > without and x87 FPU, the FPU instructions are simply ignored. The common > way to detect an FPU is therefore to initialize registers to a given > value, run fnstsw and fnstcw instructions with the register in arguments > and see if they have been modified. > > The Linux kernel indeed set the initial value of these registers to > 0x, but I am not sure all codes are doing the same. > > For me it looks like better to skip such instructions directly in > translate.c. As a bonus it seems easy to do that for all FPU > instructions. > It might have been (and this is from memory, so don't take it for anything) that the register form receives 0x, but the memory form is ignored. Speaking of which, Solar Designer recently found a bug where pentium 3 silently ignores the 66 prefix that later became SSE2, and thus the code ran but produced the wrong result: https://twitter.com/solardiz/status/316204216962142209 https://twitter.com/solardiz/status/316207184134410240 But this isn't what QEMU does: https://twitter.com/solardiz/status/316944417871245313 Rob
Re: [Qemu-devel] Target-agnostic virtio?
On 03/25/2013 08:24:44 PM, Richard Henderson wrote: On 2013-03-25 17:52, Rob Landley wrote: Can the virtio things (serial, network, block, virtfs) be used on arbitrary targets yet? I.E. Can I use a virtio network device on arm, mips, powerpc, sparc... (And can the virtio serial console hook up to qemu's stdin/stdout in -nographic mode yet?) I asked this in 2010 and the answer at the time was "no". Still not entirely sure why. Yes, so long as the machine description has a supported bus, e.g. pci. It took almost nothing to hook up virtio-pci to alpha. I'm out of date: did Alpha get the ability to boot linux on an emulated board? (I'd like to play with it, if so.) I periodically google for it, but it comes up with stuff like this: http://stackoverflow.com/questions/10938216/install-an-os-of-alpha-architecture-in-qemu If so, is there an example image or kernel .config, and corresponding qemu command line you could point me at? The stuff on http://wiki.qemu.org/Testing is mostly way behind my own images at http://landley.net/aboriginal (which I hope to have updated to 3.8 in the next day or so), but I just checked again and there's no Alpha image there either... Rob
Re: [Qemu-devel] KVM call agenda for 2013-03-26
On 03/25/2013 08:17:44 AM, Juan Quintela wrote: Hi Please send in any agenda topics you are interested in. Later, Juan. If Google summer of code is still open: http://qemu-project.org/Google_Summer_of_Code_2013 Last I checked, the older targets haven't had a lot of love. QEMU still doesn't have qemu-system-alpha, qemu-system-m68k doesn't quite support a proper m68k mmu and the half-finished macintosh q800 board is still out of tree, the sparc32 openfirmware dies if you feed it more than a tiny kernel command line via -append, the sh4 board only supports 64 megs which isn't enough to build anything interesting natively. If anybody wanted to add Qualcomm hexagon support, I might be able to rustle up a hexagon kernel-side guy to play with it. (There are a couple of people porting hexagon to the bare metal using some hacked HP devices who would probably love a more portable test platform. They could provide test binaries, toolchain setup help, and could tell you all sorts of stuff about the kernel.) It would be really nice if I could point vanilla qemu at a device tree and have it fake up a board providing the resoruces and devices in question. (Here's some memory, give me a 16550a here, stick a PCI controller here, attach these devices to it.) It would be really nice if virtio worked in a target-agnostic way so I could use virtio devices the same way on all targets. It would be really nice if virtio serial worked the way any _other_ serial device worked so -nographic could route /dev/console through stdin and stdout of qemu when using a virtio serial console. All of these issues are from my 2010 todo list. If any of them have been resolved since, I'd love to hear about it and sorry for the noise. I've been busy with other things. Fixing the versatilepb in the 3.8 kernel, for example: http://landley.net/notes-2013.html#15-03-2013 http://landley.net/notes-2013.html#16-03-2013 http://landley.net/hg/aboriginal/rev/96fb8598a446 Rob
[Qemu-devel] Target-agnostic virtio?
Can the virtio things (serial, network, block, virtfs) be used on arbitrary targets yet? I.E. Can I use a virtio network device on arm, mips, powerpc, sparc... (And can the virtio serial console hook up to qemu's stdin/stdout in -nographic mode yet?) I asked this in 2010 and the answer at the time was "no". Still not entirely sure why. Rob
[Qemu-devel] OpenBios in Sparc can't handle long kernel command lines.
If I do this: qemu-system-sparc -nographic -no-reboot -kernel image -hda hda.sqf -append 'root=/dev/sda rw init=/sbin/init.sh panic=1 PATH=/usr/distcc:/bin:/sbin console=ttyS0 HOST=sparc CPUS=1 DISTCC_HOSTS=10.0.2.2:31322/1 FTP_SERVER=10.0.2.2 FTP_PORT=31307 NATIVE_BUILD=lfs-bootstrap ' -hdb hdb.img -hdc lfs-bootstrap.hdc -m 256 qemu goes: ^[[H^[[JConfiguration device id QEMU version 1 machine id 32 CPUs: 1 x FMI,MB86904 Unhandled Exception 0x0007 PC = 0xffd07d28 NPC = 0xffd07d2c Stopping execution And then hangs. I've never figured out why it clears the screen first (none of the other targets do), but I _have_ figured out that the unhandled exception is "kernel command line too long". Because 197 bytes is just too much data for Sparc to cope with. Rob
Re: [Qemu-devel] default guest RAM size?
On 03/06/2013 12:34:53 PM, Peter Maydell wrote: On 6 March 2013 11:59, Rob Landley wrote: > On 03/05/2013 12:09:27 AM, Peter Maydell wrote: >> On 5 March 2013 14:07, 陳韋任 (Wei-Ren Chen) >> wrote: >> > On Tue, Mar 05, 2013 at 01:40:38PM +0800, Peter Maydell wrote: >> >> On 5 March 2013 13:26, Michael Tokarev wrote: >> >> > For many years, qemu defaults to 128Mb of guest RAM size. >> >> > Today, this is just too small, and many OSes fails to boot >> >> > with this size, more, they fail to produce any reasonable >> >> > messages either (eg, windows7 just crashes at startup). >> >> >> >> If you make the default bigger then some boards will crash >> >> or behave weirdly because they try to map more RAM in than >> >> will fit into the space for RAM in their address maps. >> > >> > So, 128Mb is still a good default? I am just wondering if those >> > boards with little memory still are major user of QEMU? :) >> >> They may not be major but they're still in the codebase. You >> can't just arbitrarily break them -- you need to propose >> a path forward that doesn't do that. > > 256 can be handled by most things. I'm going to take a wild guess that Windows 7 doesn't do any better in 256MB than it does with 128 :-) Who cares? I meant that I got 256 megs in an arm board, 256 megs in a mips board, 256 megs in a powerpc board, and 256 megs in a sparc board. KVM is welcome to change its defaults however it likes. This is the qemu list. Rob
Re: [Qemu-devel] default guest RAM size?
On 03/05/2013 12:09:27 AM, Peter Maydell wrote: On 5 March 2013 14:07, 陳韋任 (Wei-Ren Chen) wrote: > On Tue, Mar 05, 2013 at 01:40:38PM +0800, Peter Maydell wrote: >> On 5 March 2013 13:26, Michael Tokarev wrote: >> > For many years, qemu defaults to 128Mb of guest RAM size. >> > Today, this is just too small, and many OSes fails to boot >> > with this size, more, they fail to produce any reasonable >> > messages either (eg, windows7 just crashes at startup). >> >> If you make the default bigger then some boards will crash >> or behave weirdly because they try to map more RAM in than >> will fit into the space for RAM in their address maps. > > So, 128Mb is still a good default? I am just wondering if those > boards with little memory still are major user of QEMU? :) They may not be major but they're still in the codebase. You can't just arbitrarily break them -- you need to propose a path forward that doesn't do that. 256 can be handled by most things. The powerpc, arm, and mips boards I use in aboriginal linux all handle 256 megs. (The main reason sh4 isn't a real platform is it's hardwired to 64 megs.) (Sparc32 can handle 256 megs ram but crashes if you feed it too long a kernel command line.) Rob
Re: [Qemu-devel] Qemu s390x emulation
On 01/15/2013 05:45:44 AM, Alexander Graf wrote: On 15.01.2013, at 12:39, Suzuki K. Poulose wrote: > On 01/15/2013 04:39 PM, Alexander Graf wrote: >> >> On 15.01.2013, at 12:05, Suzuki K. Poulose wrote: >> >>> Hi >>> >>> I have been trying to setup a qemu session for qemu-system-s390x (on >>> x86_64) using a kernel (with initramfs built-in the kernel) without a >>> disk image. The kernel was built with s390 defconfig + disabled loadable >>> modules (just to keep everything inside the kernel). >>> >>> $ qemu-system-s390x -M s390 -kernel vmlinux -m 1024 >>> >>> >>> The session dies in say 2 secs, with an exit code of 0. I searched for >>> some hints / success stories, couldn't find any. >>> >>> Am I doing something wrong here ? Please let me know the right procedure >>> for getting this up and running. >> >> S390 boots using an "image" file. Please try -kernel dir>/arch/s390/boot/image. >> > Tried that even, but not any better. btw, moved to the upstream git for qemu. > > 0 > $/data/src/qemu/s390x-softmmu/qemu-system-s390x -m 1024 -kernel ./image -nographic > $echo $? > 0 > $file ./image > ./image: Linux S390 > > $ cd /data/src/qemu/ ; git log | head -n1 > commit cf7c3f0cb5a7129f57fa9e69d410d6a05031988c Does this one work for you? http://ftp.nl.debian.org/debian/dists/stable/main/installer-s390/current/images/generic/kernel.debian I tried grabbing that and grabbing the initrd image in the same directory, booting them with: qemu-system-s390x -kernel kernel.debian -nographic -m 1024 -initrd initrd.debian \ -append "rdinit=/bin/ash" And it booted to a shell prompt... with a broken console. When I did "ls -l" at the resulting prompt it echoed back an ANSI escape sequence, one character at a time, which looks like the response to the ansi screen size probe busybox does (to query the display size of an xterm across a virtual serial console). I.E. qemu is getting deeply confused that what comes from stdin and what you type on the keyboard aren't quite the same thing. Some kind of strange ncurses hackage, looks like? I tried sticking "cat |" in front of the above qemu pipeline and it got REALLY confused. Rob
Re: [Qemu-devel] [PULL 0/6] s390 patch queue 2013-01-07
On 01/07/2013 10:09:20 AM, Alexander Graf wrote: Hi Blue / Aurelien, This is my current patch queue for s390. Please pull. Ok, you'd be a good person to ask: http://wiki.qemu.org/Testing doesn't have a s390 test image. There are Debian for s390 CD images and instruction how to install them on real hardware (http://www.debian.org/releases/stable/s390/) and under hercules (http://www.josefsipek.net/docs/s390-linux/hercules-s390.html and http://www.debian-administration.org/articles/484) but nothing about how to do it with qemu. Is there an easy way to try this? Thanks, Rob
[Qemu-devel] Panic at shutdown in x86-64 3.7 kernel under qemu 1.3.0?
Reasonably vanilla versions of both just did this. No idea why. Just did it the once, haven't gotten it to reproduce... Rob Restarting system. reboot: machine restart general protection fault: fff2 [#1] CPU 0 Pid: 8542, comm: oneit Not tainted 3.7.0 #1 Bochs Bochs RIP: 0010:[] [] lapic_shutdown+0x29/0x2b RSP: 0018:88000fb57e28 EFLAGS: 0202 RAX: 8130e2d0 RBX: 0202 RCX: RDX: 81322a40 RSI: 00ff RDI: 00f0 RBP: 28121969 R08: 88000fb57fd8 R09: R10: R11: 81015721 R12: fee1dead R13: R14: 0004 R15: 00425e02 FS: () GS:81304000() knlGS: CS: 0010 DS: ES: CR0: 8005003b CR2: 00440f11 CR3: 0fb53000 CR4: 06b0 DR0: DR1: DR2: DR3: DR6: DR7: Process oneit (pid: 8542, threadinfo 88000fb56000, task 88000e848f90) Stack: 01234567 810136cb 28121969 810136a8 01234567 8102b451 0011 00040001 0023 0006 0001802a0027 Call Trace: [] ? native_machine_shutdown+0x9/0x1e [] ? native_machine_restart+0x20/0x29 [] ? sys_reboot+0x11f/0x14a [] ? __kill_pgrp_info+0x37/0x5f [] ? do_exit+0x61f/0x623 [] ? schedule_tail+0x20/0x46 [] ? ret_from_fork+0xf/0xb0 [] ? system_call_fastpath+0x16/0x1b Code: c8 c3 48 8b 05 8a cc 31 00 53 f6 c4 02 75 12 83 3d c9 da 38 00 00 74 13 83 3d d8 ea 38 00 00 75 0a 9c 5b fa e8 3a ff ff ff 53 9d <5b> c3 48 83 ec 08 eb 02 f3 90 48 8b 05 eb db 31 00 bf 00 03 00 RIP [] lapic_shutdown+0x29/0x2b RSP ---[ end trace 0c69c9c16377bd9d ]---
Re: [Qemu-devel] [PATCH 1/4] virtio-serial: use uint32_t to count ports
Speaking of virtio-serial, is there a way to get virtio serial ports to attach to qemu's stdin/stdout the way other serial ports can (and which is the default with --nographic for conventional serial ports), or do you still have to make a magic char device on the host? I never understood why _using_ virtio serial ports was so different, but it's been about a year since I looked at them (because they were so different). Rob
Re: [Qemu-devel] [PATCH 3/8] s390: I/O interrupt and machine check injection.
What do you actually use to run Linux under this target? There are some leads at http://virtuallyfun.superglobalmegacorp.com/?p=1206 which more or less leads to http://ftp.nl.debian.org/debian/dists/Debian6.0.6/main/installer-s390/current/images/generic/ but I dunno what qemu command line would go along with those files... Any hints? Rob
[Qemu-devel] Commit b90600eed3 broke qemu-system-ppc -M g3beige.
It worked in 1.2.0, but qemu segfaults during linux boot now. Test case: grab http://landley.net/aboriginal/bin/system-image-powerpc.tar.bz2 and in that "./run-emulator.sh". Checkout the above commit and build it: the result fails. Then "git show b90600eed3 | patch -p1 -R" and rebuild, it works. Rob
Re: [Qemu-devel] [PATCH] PPC: Update openbios-bin
On 08/20/2012 05:33 PM, Alexander Graf wrote: > This updates the OpenBIOS binaries for PPC to svn revision 1063, > fixing -M g3beige with large PCI memory users. > > Signed-off-by: Alexander Graf Tested-by: Rob Landley Rob -- GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code. Either it's "mere aggregation", or a license violation. Pick one.
Re: [Qemu-devel] [PATCH] Fixing sh4 serial abort
On 07/27/2012 12:28 PM, Peter Maydell wrote: > On 27 July 2012 18:16, Rob Landley wrote: >> On 07/27/2012 09:32 AM, Peter Maydell wrote: >>> The thing this analysis is missing is any examination of the question >>> "what is the hardware we are modelling documented to do?". >> >> Given that 3.3, 3.4, and 3.5 kernels have already shipped with this, I'm >> guessing "not immediately crash"? > > I said "documented", not "what it happens to do in practice". I'm trying to make it work in practice. >> So the arm maintainer noticed a place where the code didn't match the >> documentation, changed the code to match the docs, and result doesn't >> work under qemu's versatile board emulation. But at least 3.5 doesn't >> work for a _different_ reason than 3.4 didn't work, so there's that. > > PCI on versatilepb is hopelessly broken -- the only thing the kernel > code does (or did) is work on QEMU. Which is all I used it for. >> I hadn't reported this one yet because I still haven't root caused it, >> just bisected to find the break. I know reverting the IRQ assignment >> line in 3.5 doesn't fix it, which implies the "swizzle" bit is to blame >> (which seems ot have something to do with PCI bridges), and thus calling >> the default function instead of calling no function breaks qemu's >> versatile board emulation. > > 1. Find Arnd's kernel patches and see what of them still need to > be applied (http://comments.gmane.org/gmane.linux.ports.arm.kernel/93393) > 2. Get kernel working on real hardware You seem to be under the impression I have real arm hardware. (Or real sh4 hardware, or real powerpc hardware, or real mips hardware...) I've got an armv4t board in a box (a patch to support that was submited to the list by the vendor, and never merged), and a phone that's presumably armv7l but it's in use as a phone with the vendor software on it, and at work I use an cluster of unreleased armv7 SOCs in an "I can't believe it's not NUMA" configuration. The userspaces I worked out under qemu run in a chroot under there. I've got two diferent mips routers in a box somewhere with a dongle that lets me do a serial console but both require kernel patches to add board support (neither vendor ever submitted it upstream). I've run the root filesystems I worked out under qemu in a chroot under them but haven't gotten them out of the box in over a year. (I think it's in storage, actually.) A couple of the game consoles might be powerpc, but I've never run linux on them. I don't own sh4 or sparc hardware. > 3. Submit qemu patches to fix our versatilepb PCI emulation to > match hardware 4) locally patch the kernel back to work with existing qemu releases since all I want to do is boot an arm userspace to a shell prompt and run arm code on it, and don't really care about the board emulation except for the laundry list of features I need out of it such as "a working persistent clock so make doesn't lose its marbles", "enough physical memory", "serial console", "working network device", and "three working block device I can plug filesystem images into". My goal is to run an emulated linux userspace, and application emulation is _way_ more complicated and fiddly than system emulation. If real hardware was as easily accessible for me as qemu, qemu would be significantly less useful. > If you like you can do 3 first and I'll happily apply those patches > regardless of whether anybody cares to fix the kernel. I just want it to work. Working the same way real hardware does is a bonus, but if the change isn't visible to userspace (virtio? emulated scsi? emulated ide?) it's not actually relevant to my use case. > I'm afraid I don't have a great deal of time for versatilepb > emulation fixes because it's an incredibly ancient devboard. I can switch to a newer board, but I want to plug armv4tl, armv5l, armv6l, and armv7l processors into it. (And eventually armv8 but nothing supports that yet.) If it's always running armv7 then I can't _prove_ that this userspace would actually run on armv5 and didn't leak armv7 instructions in there. Last time I looked at newer boards the idea of plugging older processors into them confused both qemu and the kernel's config stuff. Looking at current qemu-git, there's no "-M vexpress", there is instead vexpress-a9 ARM Versatile Express for Cortex-A9 vexpress-a15 ARM Versatile Express for Cortex-A15 I.E. the assumption about what processor you're plugging into this board is baked into the board _name_, and both of those are ar
Re: [Qemu-devel] [PATCH] Fixing sh4 serial abort
On 07/27/2012 09:32 AM, Peter Maydell wrote: > On 27 July 2012 14:45, Rob Landley wrote: >> I.E. sci_getreg(port, SCFCR) move to before checking whether or not >> we'll ever possibly use the result. SCFCR is 0x18 and QEMU calls abort() >> on an attempt to read from an unimplemented register. >> >> I can patch the kernel to work around this (and probably will for this >> release), but the _proper_ fix is to get qemu not to abort on a register >> read that works fine if it just returns 0. > > The thing this analysis is missing is any examination of the question > "what is the hardware we are modelling documented to do?". Given that 3.3, 3.4, and 3.5 kernels have already shipped with this, I'm guessing "not immediately crash"? Then again I can't really criticize sh4 for multiple kernel releases not working under qemu and nobody noticing when _arm_ currenty has a similar problem. The arm versatile board's scsi emulation was broken by linux commit 4d5fc58dbe34 in 3.4 (yanking the versatile's mach/io.h when the default one breaks PCI), and then before _that_ got reverted (in commit 9b0f7e399238c6) this commit went in: commit 1bc39ac5dab265b76ce6e20d6c85f900539fd190 Author: Russell King Date: Sat Mar 10 11:32:34 2012 + ARM: PCI: versatile: fix PCI interrupt setup This is at odds with the documentation in the file; it says pin 1 on slots 24,25,26,27 map to IRQs 27,28,29,30, but the function will always be entered with slot=0 due to the lack of swizzle function. Fix this function to behave as the comments say, and use the standard PCI swizzle. Signed-off-by: Russell King So the arm maintainer noticed a place where the code didn't match the documentation, changed the code to match the docs, and result doesn't work under qemu's versatile board emulation. But at least 3.5 doesn't work for a _different_ reason than 3.4 didn't work, so there's that. I dunno if this is a qemu bug or a kernel bug, but I _do_ know that I'm far more interested in getting it to work with existing software than getting it to match the docs. I hadn't reported this one yet because I still haven't root caused it, just bisected to find the break. I know reverting the IRQ assignment line in 3.5 doesn't fix it, which implies the "swizzle" bit is to blame (which seems ot have something to do with PCI bridges), and thus calling the default function instead of calling no function breaks qemu's versatile board emulation. But that part isn't trivially reverted in 3.5 becauase they "cleaned up" the code so you now get the default behavior without asking and I haven't dug deep enough to figure out what's actually going on yet. > If the hardware > is documented to have a readable register here, QEMU should be fixed. > If it is not then the kernel is buggy and should be fixed. The sh4 Linux architecture is currently maintained by Renesas developers, and they're just as good a maintainer of the dreamcast-era stuff as Oracle is of Sun workstations and HP/Compaq was of the Microvax. They have explicitly told me they aren't interested in anyone who isn't a Renesas customer, and that since attempting to run sh4 under qemu or on a dreamcast isn't what they're paid to support, they therefore do not care about it. Pointing out to them that they broke older versions of stuff has never worked for me. You're welcome to try to engage them, but personally I treat the sh4 changes as read only at this point and carry local patches to revert the really stupid bits. > As it happens, the "SH7214 Group, SH7216 Group User’s Manual: Hardware" > (which I think is the right doc for this) says the register is r/w, > so I think your suggested patch is correct. Yay! > (Aborting is a little unfriendly but our logging infrastructure > for "guest did something wrong" is not great, unfortunately.) My first fix was just replacing the abort with assigning the value to 0, but that left debug output spewing a bit. > There are an awful lot of "#if 0"s in that source file... This one was put in by Thiemo Suefer. He didn't get to finish cleaning up before he died. I'm aware there's not a huge amount of interest in Linux on sh4, but my aboriginal linux project is aimed at getting the same basic native development environment working on as many different architectures as possible, for things like automated cross-platform regression testing. (I was thinking "userspace packages", but if I can set up a cron job doing nightly builds of git maybe some of this crud would be caught earlier. Pity I have NO free time. Writing this at work over lunch.) So if qemu emulates it, I'm interested in getting a linux running on it with a native compiler. Which means I'm perpetually out of my depth, but oh well... > -- PMM Thanks for the review, Rob -- GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code. Either it's "mere aggregation", or a license violation. Pick one.
