Qemu
Locked
 
|
Hi,
Last week I worked a bit on my powerpc64 port and I ran into some trouble. I'll try to formulate what that trouble was in another post (maybe) in the next few days but I just have this question: How can I use Qemu better? I'm using the 970FX emulation with 1 cpu for now and I'm running into some LR register corruption, and at first glance it seems the asm is alright (in that it saves LR on the stack after a mflr, and pops the stack later and restores LR with mtlr. Would it be beneficial to use Qemu on the macppc arch instead of the amd64 arch or doesn't it matter? One good thing with the amd64 arch is that I can take my work along on weekends to my parents house, where i have no access to the G5. I'm not letting the G5 idle at 140 Watts. The 6.5 macppc qemu is broken, so I'll have to take my G5 to -current perhaps to see if I can get qemu to compile. Another thing with Qemu that I have problems with is the entire 'show registers' output in the monitor, it doesn't feel like it correctly displays right data. I have also used the x (examine) function in the monitor which is like the gdb memory examination. Is there any other monitor commands that you might have experience with that are a really good debug tool? Regards, -peter |
|
|
Hi Peter, I think qemu on OpenBSD/macppc will not help you as this will be still using tcg IMHO. What you would need is something like Linux on PPC64 and running KVM there and then IMHO you will be able to run PPC code directly on CPU avoiding possible Qemu issues in PPC isns backend. See following URLs about how to run Mac OS X for PPC on top of Qemu/KVM on POWER9/Linux box: https://www.talospace.com/2018/08/making-your-talos-ii-into-power-mac.html https://www.talospace.com/2018/08/making-your-talos-ii-into-power-mac_29.html I have POWER8 + Linux + KVM box here which is kind of working well since in Qemu/KVM I'm running various Linuxes and FreeBSD 13-current. If you like to have something tested there, I'm open to it, either will do it myself or I'll give you account on the box. Yet another possibility would be to ask RaptorCS since they promised several times bare-metal access to POWER9 box to OS porters. Could you be also so kind and share information about how do you build OpenBSD for PPC64 and how do you boot whatever you get from the build. I'm especially curious if you build bsd.rd and somehow boot that and how exactly do you invoke Qemu and also what Qemu version exactly do you use for that. Thanks, Karel On 5/25/19 2:07 AM, Peter J. Philipp wrote: > Hi, > > Last week I worked a bit on my powerpc64 port and I ran into some trouble. > I'll try to formulate what that trouble was in another post (maybe) in the > next few days but I just have this question: How can I use Qemu better? > I'm using the 970FX emulation with 1 cpu for now and I'm running into some > LR register corruption, and at first glance it seems the asm is alright (in > that it saves LR on the stack after a mflr, and pops the stack later and > restores LR with mtlr. > > Would it be beneficial to use Qemu on the macppc arch instead of the amd64 > arch or doesn't it matter? One good thing with the amd64 arch is that I can > take my work along on weekends to my parents house, where i have no access to > the G5. I'm not letting the G5 idle at 140 Watts. > > The 6.5 macppc qemu is broken, so I'll have to take my G5 to -current perhaps > to see if I can get qemu to compile. > > Another thing with Qemu that I have problems with is the entire 'show registers' output in the monitor, it doesn't feel like it correctly displays right data. > I have also used the x (examine) function in the monitor which is like the gdb > memory examination. Is there any other monitor commands that you might have > experience with that are a really good debug tool? > > Regards, > -peter > |
|
|
On Sat, May 25, 2019 at 07:58:36PM +0200, Karel Gardas wrote:
> > Hi Peter, Hi Karel, > I think qemu on OpenBSD/macppc will not help you as this will be still using > tcg IMHO. What you would need is something like Linux on PPC64 and running > KVM there and then IMHO you will be able to run PPC code directly on CPU > avoiding possible Qemu issues in PPC isns backend. I see thanks for the info. > See following URLs about how to run Mac OS X for PPC on top of Qemu/KVM on > POWER9/Linux box: > https://www.talospace.com/2018/08/making-your-talos-ii-into-power-mac.html > > https://www.talospace.com/2018/08/making-your-talos-ii-into-power-mac_29.html > > I have POWER8 + Linux + KVM box here which is kind of working well since in > Qemu/KVM I'm running various Linuxes and FreeBSD 13-current. If you like to > have something tested there, I'm open to it, either will do it myself or > I'll give you account on the box. > Yet another possibility would be to ask RaptorCS since they promised several > times bare-metal access to POWER9 box to OS porters. I don't know if I want to go that far, just getting past the openfirmware is on my agenda for now, I still need to revisit locore.S too as all .S I wrote last year was garbage. My first most goal is to get 64 bit working on my G5 because I want to make use of the 4 GB in it. But I'd rather not boot it as 1. it sucks a lot of power, 2. I haven't turned the boot chime off yet, I want to go on with emulation somehow though until I can test it on the physical machine probably via ethernet boot. > Could you be also so kind and share information about how do you build > OpenBSD for PPC64 and how do you boot whatever you get from the build. I'm > especially curious if you build bsd.rd and somehow boot that and how exactly > do you invoke Qemu and also what Qemu version exactly do you use for that. It's not really finished, so far only the bsd kernel builds. In july last year I did a gcc cross compiler and I'm using that to compile the kernel. In theory clang also works but I had a hard time wiht it last year and since then have been poking with gcc to get the kernel compiled. Also it's still on the old 6.4-current that I used last year so everything is outdated and needs to be upgraded one day. It's late today, maybe I can make everything available for download again as a vm or vmware image next week. If you downloaded the aimee image that's basically what I'm using with qemu built from its internal ports tree. The version of qemu is old. 3.0.0 I think. Oh I don't build bsd.rd yet, also I don't see anythign on the console yet, openfirmware hasn't initialized stdout yet. I was poking at /sys/aim64/aim64/ofwreal.S for a while before being so hampered with my own lack of understanding of asm that I took many parts of FreeBSD's /sys/powerpc/ofw and connected them in place of the asm, I use the ofwreal.c functions there and modified all OF_* functions to use ofw_real_* functions. What I'm seeing now when I execute the bsd is that deep inside the ofw_real_finddevice() functions (in a function called ofw_real_map(), I think) everything falls apart after a return from that function. I think in the monitor it says a garbage pointer where it went to, meanign the LR register got a garbage value from the stack. I had a week off from this all because I needed to do some sysadmin stuff on my network this week but it's really exciting work and that's what pulls me back. I am concerned about a few things, my alignment of the asm code in locore0.S and ofwreal.S (these are the same as in /sys/arch/macppc/macppc only modified to 64 bit code). Only recently since reading teh 64-bit ABI have I been making sense of offsets in the stack, unfortunately reading the 32-bit ABI that Mark Kettenis helped me with didn't help me understand more of the ofwreal.S code from 32-bit macppc arch. There is some oddities, if I may pick on it, like an addi asm op code which has 3 registers there. Only in the spec of addi the last argument is a value not a register. Examining the code with objdump shows that r8 takes on the value 8 but it is warned about in the as stage of make. There is 2 more subi op codes that have the same problem. within 2 operations of the addi. Since ofw_init works in macppc arch I'm not too concerned about it but in my tinkering with the 64-bit port I'm exploring the import of more FreeBSD code and using a nice big asm in the ofw that makes a lot of sense to my virgin asm eyes. Weeks ago I activated the 64-bit bridge flag and actually succeeded to get past ofw_init somehow, I htink I mentioned it before in a mail. The gathered memory specs from the qemu system were so wrong that the code crashed in pmap.c in steal_avail_pages() or some function like that (forgive me I'm writing this all on memory alone, so if I am off on something it's because I haven't revisited my eyes on the code tonight). I have made aliases in the root shell of the aimee vm that allows me quick building of bsd, quick building of install64.iso and fast call of qemu. The commands are mk, bk, and qs (for qemu-start.sh a shell script that executes 64 bit powerpc qemu), I just haven't yet found out a way to pass the argument boot cd:,ofwboot /bsd and have to still type that in qemu. I use non-used floating point registers to "flag" my way past points that I define in the execution flow with a asm volatile call. This way I know that function X was called but not returned from it yet before execution stops and i'M able to dump registers to see the floating point registers. It's a somewhat tedius, glad I'm only on an emulator. 2 weeks ago I was suspicious of the registers though and something weird happend. I turned off setting the PSL_SF (to go to 64-bit mode) flag. And surprisingly the execution got quite far. Past ld opcodes which I believe would make a 32-bit mode stop in its tracks. asm is fairly finicky and I'm still learning the best way how to go about these things. It's late and I'm gushing my heart out, I better go to bed. Best Regards, -peter > Thanks, > Karel > > On 5/25/19 2:07 AM, Peter J. Philipp wrote: > > Hi, > > > > Last week I worked a bit on my powerpc64 port and I ran into some trouble. > > I'll try to formulate what that trouble was in another post (maybe) in the > > next few days but I just have this question: How can I use Qemu better? > > I'm using the 970FX emulation with 1 cpu for now and I'm running into some > > LR register corruption, and at first glance it seems the asm is alright (in > > that it saves LR on the stack after a mflr, and pops the stack later and > > restores LR with mtlr. > > > > Would it be beneficial to use Qemu on the macppc arch instead of the amd64 > > arch or doesn't it matter? One good thing with the amd64 arch is that I can > > take my work along on weekends to my parents house, where i have no access to > > the G5. I'm not letting the G5 idle at 140 Watts. > > > > The 6.5 macppc qemu is broken, so I'll have to take my G5 to -current perhaps > > to see if I can get qemu to compile. > > > > Another thing with Qemu that I have problems with is the entire 'show registers' output in the monitor, it doesn't feel like it correctly displays right data. > > I have also used the x (examine) function in the monitor which is like the gdb > > memory examination. Is there any other monitor commands that you might have > > experience with that are a really good debug tool? > > > > Regards, > > -peter > > |
|
|
On Sun, May 26, 2019 at 12:29:58AM +0200, Peter J. Philipp wrote:
> [ ... ] My first most goal is to get 64 bit working on my >G5 because I want to make use of the 4 GB in it. But I'd rather not boot it >as 1. it sucks a lot of power, 2. I haven't turned the boot chime off yet, Re. the boot chime: some live image for ppc64 might help: on Debian-like distros something like nvsetvol 0 then should do it. I've found some ppc 32-bit lubuntu live image to get that done, some time ago, IIRC. Alternatively: https://cdimage.debian.org/cdimage/ports/2019-05-09/ Starting an install with an iso from there (they have 64-bits, it seems) and then switching to a console might be worth a try. Good luck! Wolfgang |
|
|
Hi Wolfgang,
Thanks for the hint. Right now my G5 has Apple Tiger or something on the drive and on the SSD that I added to it has OpenBSD 6.5/macppc. I select from Openfirmware which one I want to run. The problem with booting a linux to install it where Apple Tiger is, is that my CD's that I have are not accepted by the DVD drive for some odd reason. It takes it, thinks a bit, motors whirr and then it opens up and spits it out. I tried netbooting OpenSUSE and debian but beyond grub I don't get anywhere...after loading the initrd it breaks out into the monitor with SRR0 and SRR1 displayed. I played a little with the boot-volume setenv in openfirmware changing it from 3 to 0, -1, but that didn't help, chime sound is still on. I remember managing to turn off the sound on my ibook 19 years ago, but that was a long time ago and I don't remember what I did except that it took me multiple tries in a library and pissing off people :-). Anyhow until I get some accepted CD's I'M kinda stuck with the setup as it is now. Best Regards, -peter On Sun, May 26, 2019 at 05:29:56PM +0200, Wolfgang Pfeiffer wrote: > On Sun, May 26, 2019 at 12:29:58AM +0200, Peter J. Philipp wrote: > > > [ ... ] My first most goal is to get 64 bit working on my > > G5 because I want to make use of the 4 GB in it. But I'd rather not boot it > > as 1. it sucks a lot of power, 2. I haven't turned the boot chime off yet, > > Re. the boot chime: some live image for ppc64 might help: on > Debian-like distros something like > > nvsetvol 0 > > then should do it. I've found some ppc 32-bit lubuntu live image to > get that done, some time ago, IIRC. Alternatively: > > https://cdimage.debian.org/cdimage/ports/2019-05-09/ > > Starting an install with an iso from there (they have 64-bits, it > seems) and then switching to a console might be worth a try. > > Good luck! > > Wolfgang |
|
|
In reply to this post by Peter J. Philipp-3
On Sun, May 26, 2019 at 12:29:58AM +0200, Peter J. Philipp wrote:
> It's late and I'm gushing my heart out, I better go to bed. I have created a second project webpage: https://centroid.eu/ppc/ Along with this I have made 3 image files available to get VMM or VMware to the point where I am now, if anyone is interested in looking. Warning it's a little messy (everything), but I intend to clean up things when I manage to make it boot. I feel confident the aimee image will help me get to booting 64-bit PPC, unless someone starts another porting attempt and beats me to it. It's not a race, and I'd be saving myself a lot of time if someone pulled a 64-bit port out of their sleeve. :-). Consumerism is easy, producing stuff is really freakin' hard. Take care, -peter |
|
|
In reply to this post by Karel Gardas
On Sat, May 25, 2019 at 07:58:36PM +0200, Karel Gardas wrote:
> Could you be also so kind and share information about how do you build > OpenBSD for PPC64 and how do you boot whatever you get from the build. I'm > especially curious if you build bsd.rd and somehow boot that and how exactly > do you invoke Qemu and also what Qemu version exactly do you use for that. > > Thanks, > Karel Hi Karel, Last weeks answer wasn't to my own satisfaction, so I'll try again. Last year I spent considerable time and effort to make the bsd kernel compile for aim64 arch. aim64 arch is like macppc arch, and powerpc64 is like powerpc, only that some variables are different and the asm has been changed. ie. ppc_mtmsr() asm macro has been changed to ppc_mtmsrd() (doubleword to indicate that 64-bit flag can be set on the MSR register, it's the highest bit also called PSL_SF found in /sys/arch/powerpc64/include/psl.h, this I also had changed). Everything was changed around ie. a long in powerpc would be a uint32_t in powerpc64 unless the variable size can go higher to 64 bit, in that case it would be uint64_t). So I get to build a 64-bit kernel whoowee, it's like a little lightbulb that goes poof when I apply current to it. Basically the kernel starts in locore0.S, and it branches off into the ofwreal.S asm file, here it stopped last year at entry into a C routine. I had given up there. Closer examination with qemu though this year showed that it can go further into C routines, I'm not sure if it was the fact that I compiled with gcc (I tried it out, basically and it worked). I was experimenting a bit with the temporary 64-bit bridge which is a bit one can set to have 32-bit functionality on opcodes like mfsrin. This for a moment got me so far as pmap.c but crashed/panic'ed on data that was supposed to be gotten from openfirmware. The fact that the stdout console was not initialized showing me the panic string was another indicator that these were awry. Last year I also hacked on the bootloader ofwboot to boot 64-bit ELF images. This works for the most part and it starts in 32-bit mode and hands off the execution to the kernel in 32-bit mode, which then does the following opcodes to set 64-bit mode: mfmsr %r0 lis %r21, 1 insrdi %r0, %r21, 1, 0 /* set PSL_SF */ mtmsrd %r0 isync nop This I learned from reading the FreeBSD asm and it's not changed much except perhaps the register #'s. Ultimately this is called first, and I don't think I'll see an alignment issue either as 64-bit opcodes are 4 bytes just like 32-bit opcodes. OK if I didn't already say it I'm focusing on bsd kernel not bsd.rd, when the day comes when bsd kernel boots but panics on no root filesystem is when I am going to work on bsd.rd. That day is still a long ways off I think as I gotta have locore0.S, open firmware routines, and locore.S right. locore.S still nees a lot of work and I'm not even there yet because I'm approaching the bootstrapping as it executes, and once I'M past the openfirmware I know it will panic or do funky things once the cpu and memory bootstrapping is done. Does this better explain where I am at? There is still a lot to do, and I'm not really that proud of what I have accomplished thus far, but I started not knowing any asm, not knowing much in general about kernel work, sure I poked in ther kernel before but mostly in the networking areas, this is totally new territory. And it's hard. I still can't turn away/walk away, somehow I keep thinking I can make the lightbulb glow. I'm approaching this different though than last year. Last year I wanted to get something done by christmas. This year there is no due date. I'm curious to see how far I can take it. Best Regards, -peter |
|
|
> Date: Thu, 30 May 2019 18:09:01 +0200
> From: "Peter J. Philipp" <[hidden email]> > > On Sat, May 25, 2019 at 07:58:36PM +0200, Karel Gardas wrote: > > Could you be also so kind and share information about how do you build > > OpenBSD for PPC64 and how do you boot whatever you get from the build. I'm > > especially curious if you build bsd.rd and somehow boot that and how exactly > > do you invoke Qemu and also what Qemu version exactly do you use for that. > > > > Thanks, > > Karel > > Hi Karel, > > Last weeks answer wasn't to my own satisfaction, so I'll try again. Last > year I spent considerable time and effort to make the bsd kernel compile for > aim64 arch. aim64 arch is like macppc arch, and powerpc64 is like powerpc, > only that some variables are different and the asm has been changed. ie. > ppc_mtmsr() asm macro has been changed to ppc_mtmsrd() (doubleword to > indicate that 64-bit flag can be set on the MSR register, it's the highest > bit also called PSL_SF found in /sys/arch/powerpc64/include/psl.h, this I > also had changed). Everything was changed around ie. a long in powerpc would > be a uint32_t in powerpc64 unless the variable size can go higher to 64 bit, in > that case it would be uint64_t). > > So I get to build a 64-bit kernel whoowee, it's like a little lightbulb that > goes poof when I apply current to it. Basically the kernel starts in locore0.S, > and it branches off into the ofwreal.S asm file, here it stopped last year at > entry into a C routine. I had given up there. Closer examination with qemu > though this year showed that it can go further into C routines, I'm not sure > if it was the fact that I compiled with gcc (I tried it out, basically and it > worked). I was experimenting a bit with the temporary 64-bit bridge which is > a bit one can set to have 32-bit functionality on opcodes like mfsrin. This > for a moment got me so far as pmap.c but crashed/panic'ed on data that was > supposed to be gotten from openfirmware. The fact that the stdout console > was not initialized showing me the panic string was another indicator that > these were awry. > > Last year I also hacked on the bootloader ofwboot to boot 64-bit ELF images. > This works for the most part and it starts in 32-bit mode and hands off the > execution to the kernel in 32-bit mode, which then does the following opcodes > to set 64-bit mode: > > mfmsr %r0 > lis %r21, 1 > insrdi %r0, %r21, 1, 0 /* set PSL_SF */ > mtmsrd %r0 > isync > nop > > This I learned from reading the FreeBSD asm and it's not changed much except > perhaps the register #'s. Ultimately this is called first, and I don't think > I'll see an alignment issue either as 64-bit opcodes are 4 bytes just like > 32-bit opcodes. > > OK if I didn't already say it I'm focusing on bsd kernel not bsd.rd, when the > day comes when bsd kernel boots but panics on no root filesystem is when I > am going to work on bsd.rd. That day is still a long ways off I think as I > gotta have locore0.S, open firmware routines, and locore.S right. locore.S > still nees a lot of work and I'm not even there yet because I'm approaching > the bootstrapping as it executes, and once I'M past the openfirmware I know > it will panic or do funky things once the cpu and memory bootstrapping is done. > > Does this better explain where I am at? There is still a lot to do, and > I'm not really that proud of what I have accomplished thus far, but I started > not knowing any asm, not knowing much in general about kernel work, sure I > poked in ther kernel before but mostly in the networking areas, this is totally > new territory. And it's hard. I still can't turn away/walk away, somehow I > keep thinking I can make the lightbulb glow. I'm approaching this different > though than last year. Last year I wanted to get something done by christmas. > This year there is no due date. I'm curious to see how far I can take it. Ome thing to keep in mind with hte G5 is that it is a bit strange and event when running in 32-bit mode it takes traps in 64-bit mode. And for some reason the bits in the MSR register aren't where you expect them to be. This is what the nop_32_Ns/Ne labels are about in the powerpc locore..S Those bits are there to fix this up on G5 and are overwritten with NOP instructions on older 32-bit CPUs. |
|
|
On Thu, May 30, 2019 at 07:03:56PM +0200, Mark Kettenis wrote:
> Ome thing to keep in mind with hte G5 is that it is a bit strange and > event when running in 32-bit mode it takes traps in 64-bit mode. And > for some reason the bits in the MSR register aren't where you expect > them to be. This is what the nop_32_Ns/Ne labels are about in the > powerpc locore..S Those bits are there to fix this up on G5 and are > overwritten with NOP instructions on older 32-bit CPUs. Hi Mark, If I read the macppc code right..., then in powerpc/cpu_subr.c cpu_bootstrap() these instructions are called, pretty ingenious I must say. However it makes me a bit unsure as this is what I see: ------> cpu = ppc_mfpvr() >> 16; switch (cpu) { case PPC_CPU_IBM970: case PPC_CPU_IBM970FX: case PPC_CPU_IBM970MP: ... break; case PPC_CPU_MPC83xx: ... /* FALLTHROUGH */ default: ... } <------ These are the G5 CPU (IBM970*) but you're not looping through nop32_start but rather rfi_start in the same manner. Is that what you meant? The default switch is for anything but G5 and does this nice for() loop on nop32_start. Could this be a bug in that it's not doing what was intended? https://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/sys/arch/powerpc/powerpc/cpu_subr.c?rev=1.8&content-type=text/plain I could see a mtmsrd being called on a G4 then if I didn't know any better, and those were 32-bit processors right? Let me know if I'm misreading this code, Best Regards, -peter |
|
|
> Date: Thu, 30 May 2019 20:12:40 +0200
> From: "Peter J. Philipp" <[hidden email]> > > On Thu, May 30, 2019 at 07:03:56PM +0200, Mark Kettenis wrote: > > Ome thing to keep in mind with hte G5 is that it is a bit strange and > > event when running in 32-bit mode it takes traps in 64-bit mode. And > > for some reason the bits in the MSR register aren't where you expect > > them to be. This is what the nop_32_Ns/Ne labels are about in the > > powerpc locore..S Those bits are there to fix this up on G5 and are > > overwritten with NOP instructions on older 32-bit CPUs. > > Hi Mark, > > If I read the macppc code right..., then in powerpc/cpu_subr.c cpu_bootstrap() > these instructions are called, pretty ingenious I must say. However it makes > me a bit unsure as this is what I see: > > ------> > cpu = ppc_mfpvr() >> 16; > > switch (cpu) { > case PPC_CPU_IBM970: > case PPC_CPU_IBM970FX: > case PPC_CPU_IBM970MP: > > ... > break; > case PPC_CPU_MPC83xx: > ... > /* FALLTHROUGH */ > default: > ... > } > <------ > > These are the G5 CPU (IBM970*) but you're not looping through nop32_start > but rather rfi_start in the same manner. Is that what you meant? > > The default switch is for anything but G5 and does this nice for() loop on > nop32_start. Could this be a bug in that it's not doing what was intended? > > https://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/sys/arch/powerpc/powerpc/cpu_subr.c?rev=1.8&content-type=text/plain > > I could see a mtmsrd being called on a G4 then if I didn't know any better, > and those were 32-bit processors right? > > Let me know if I'm misreading this code, I think you are. For the G5 the code is essentially overwriting all rfi instructions with rfid instructions. On G4 and earlier the code is overwriting the sequences that use the mtmsrd instruction with nop instructions. Anyway, all I wanted to do is give a heads-up to say that this stuff can be quite non-intuitive. Especially the how the bits move around between the 32-bit and 64-bit representation of the msr register on the G5. This isn't helped by the way IBM numbers bits from zero for the most-significant bit. |
|
|
In reply to this post by Peter J. Philipp-3
Peter, thanks for the answer, however for me the most important bit is still mising. 1) how do you invoke qemu to load bsd? 2) how do you connect qemu and gdb in order to debug bsd? 3) how do you cross-compile to ppc64? -- see my next email about issues with cross-compilation. Thanks, Karel On 5/30/19 6:09 PM, Peter J. Philipp wrote: > Hi Karel, > > Last weeks answer wasn't to my own satisfaction, so I'll try again. |
|
|
In reply to this post by Mark Kettenis
On Thu, May 30, 2019 at 08:44:43PM +0200, Mark Kettenis wrote:
> > https://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/sys/arch/powerpc/powerpc/cpu_subr.c?rev=1.8&content-type=text/plain > > > > I could see a mtmsrd being called on a G4 then if I didn't know any better, > > and those were 32-bit processors right? > > > > Let me know if I'm misreading this code, > > I think you are. For the G5 the code is essentially overwriting all > rfi instructions with rfid instructions. On G4 and earlier the code > is overwriting the sequences that use the mtmsrd instruction with > nop instructions. They are patching the instructions. Cool! If I can bug you one more time on something. I see a lot of mtmsrd opcodes then in locore.S that aren't followed with an immediate isync opcode. Isn't that needed? I'm looking at trapcode() near nop32_1e: In section 2.3.16 of "Programming Environments Manual for 64-bit Micro- processors" it talks about it, I think I have a copy of it here: https://centroid.eu/enhancedrisc/pem_64bit_v3.0.2005jul15.pdf If not I don't want to take up too much of your time. In fact I kept a low profile on asking questions anyhow since you guys are generally overloaded with work. > Anyway, all I wanted to do is give a heads-up to say that this stuff > can be quite non-intuitive. Especially the how the bits move around > between the 32-bit and 64-bit representation of the msr register on > the G5. This isn't helped by the way IBM numbers bits from zero for > the most-significant bit. I know what you mean. Like in that same hyperlinked document section 2.3.1. Best Regards, -peter |
|
|
In reply to this post by Karel Gardas
On Thu, May 30, 2019 at 09:02:54PM +0200, Karel Gardas wrote:
> > Peter, > > thanks for the answer, however for me the most important bit is still > mising. > > 1) how do you invoke qemu to load bsd? Hi Karel, Sorry for excluding this. aimee# more qemu-start.sh /usr/local/bin/qemu-system-ppc64 -machine mac99 -cpu 970fx -nographic \ -cdrom /tmp/install64.iso -boot order=d -m 2048 -d guest_errors > 2) how do you connect qemu and gdb in order to debug bsd? I don't. Inside Qemu I use the monitor control-a / show registers to see the registers and in the code I set markers in floating point registers to see where in the code it's been. It's ghetto I know. > 3) how do you cross-compile to ppc64? -- see my next email about issues with > cross-compilation. Here is what aimee vm does: ---------> aimee# which cc /usr/cross/aim64/usr/cross/aim64/usr/bin/cc aimee# head /usr/cross/aim64/usr/cross/aim64/usr/bin/cc #!/bin/sh #exec /usr/local/bin/clang --target=powerpc64-unknown-openbsd6.4 ${@} exec /usr/local/bin/powerpc64-unknown-openbsd-gcc -m64 ${@} exit 0 <------------ And the gcc I built a port for very very early last year (probably in august). All the steps (albeit kinda messy) should be described in the following diary: https://centroid.eu/enhancedrisc/ I'm just looking right now check out 2018-07-30 entry. > Thanks, > Karel Best Regards, -peter > On 5/30/19 6:09 PM, Peter J. Philipp wrote: > > Hi Karel, > > > > Last weeks answer wasn't to my own satisfaction, so I'll try again. |
|
|
In reply to this post by Peter J. Philipp-3
On Thu, May 30, 2019 at 04:46:58PM +0200, Peter J. Philipp wrote:
>Hi Wolfgang, > >Thanks for the hint. Right now my G5 has Apple Tiger or something on the drive >and on the SSD that I added to it has OpenBSD 6.5/macppc. I select from >Openfirmware which one I want to run. The problem with booting a linux to >install it where Apple Tiger is, is that my CD's that I have are not accepted >by the DVD drive for some odd reason. It takes it, thinks a bit, motors whirr >and then it opens up and spits it out. No need for a CD drive: tried to load a live or installer linux via some USB thumb already? Instructions: https://marc.info/?l=openbsd-ppc&m=155231977928919&w=2 I did complete installs (32-bit) this way ... I have no idea whether the Debian installer has that "nvsetvol" tool on board, but it might be worth a try. >I tried netbooting OpenSUSE and debian but beyond grub I don't get >anywhere...after loading the initrd it breaks out into the monitor >with SRR0 and SRR1 displayed. Maybe try newer Debian images, or try somewthing like boot [some usb pattern here??]:,\\:tbxi see: https://lists.debian.org/debian-powerpc/2019/05/msg00112.html lubuntu live: http://cdimage.ubuntu.com/lubuntu/releases/16.04/release/ And I'm not sure whether this image http://cdimage.ubuntu.com/lubuntu/releases/16.04/release/lubuntu-16.04-alternate-powerpc.iso is 64-bit or not. >I played a little with the boot-volume setenv in openfirmware >changing it from 3 to 0, -1, but that didn't help, chime sound is >still on. Thanks for the hint - but maybe you *might* (be careful, I'm not an OF expert) need to save the changes to nvram: see: " [to save the results into NVRAM] reset-all " from: https://ftp.openbsd.org/pub/OpenBSD/6.5/macppc/INSTALL.macppc Good luck! Wolfgang |
|
|
On Fri, May 31, 2019 at 09:35:32AM +0200, Wolfgang Pfeiffer wrote:
>lubuntu live: .. although I'm not sure whether they're 'live' for ppc ... > >http://cdimage.ubuntu.com/lubuntu/releases/16.04/release/ > >And I'm not sure whether this image > >http://cdimage.ubuntu.com/lubuntu/releases/16.04/release/lubuntu-16.04-alternate-powerpc.iso > >is 64-bit or not. > Wolfgang |
|
|
On Fri, May 31, 2019 at 09:53:48AM +0200, Wolfgang Pfeiffer wrote:
> On Fri, May 31, 2019 at 09:35:32AM +0200, Wolfgang Pfeiffer wrote: > > > lubuntu live: > > .. although I'm not sure whether they're 'live' for ppc ... > > > > > http://cdimage.ubuntu.com/lubuntu/releases/16.04/release/ > > > > And I'm not sure whether this image > > > > http://cdimage.ubuntu.com/lubuntu/releases/16.04/release/lubuntu-16.04-alternate-powerpc.iso > > > > is 64-bit or not. > > > > Wolfgang I managed to turn the boot chime off with Tiger. Not sure what it did in openfirmware, I did notice the boot-volume setenv was changed to 1, I think I had it at 3. There is need to install Linux just yet. (I had some problems using usb ports on this G5). Thanks for the links! Best Regards, -peter |
«
Return to openbsd port - ppc
|
1 view|%1 views
| Free forum by Nabble | Edit this page |