On 09/10/11 01:45 AM, Blue Swirl wrote:
>
>> I don't know enough about SPARC32 architecture to know if that gives more
>> useful information... I don't see the 0x4c value in my log file. I tried
>> turning on DEBUG_MMU, but stopped when my log file hit 4GB and I hadn't hit
>> the stopping point yet.
>>
>> Any ideas for other things to try or set for more debugging?
> Since this is repeatable, you could try something like this (untested):
> diff --git a/target-sparc/op_helper.c b/target-sparc/op_helper.c
> index d1a8dd9..2594bbd 100644
> --- a/target-sparc/op_helper.c
> +++ b/target-sparc/op_helper.c
> @@ -1836,6 +1836,11 @@ uint64_t helper_ld_asi(target_ulong addr, int
> asi, int size, int sign)
> ret = mmu_probe(env, addr, mmulev);
> DPRINTF_MMU("mmu_probe: 0x%08x (lev %d) -> 0x%08" PRIx64 "\n",
> addr, mmulev, ret);
> + if (addr == 0xf5901400) {
> + printf("mmu_probe: 0x%08x (lev %d) -> 0x%08" PRIx64 "\n",
> + addr, mmulev, ret);
> + dump_mmu(stdout, fprintf, env);
> + }
> }
> break;
> case 4: /* read MMU regs */
Tweaking that a little, I now find myself at pc=0xf01850c8, because that
is the current instruction when the page tables write out.
(qemu) info cpus
* CPU #0: pc=0xf01850c8 npc=0xf01850cc thread_id=3483
(qemu) info registers
pc: f01850c8 npc: f01850cc
General Registers:
%g0-7: 00000000 f024dc00 00000003 f5a6b104 00000004 fbf45b80 f0041000
f5dd0500
Current Register Window:
%o0-7: 00000000 f026a2d8 f5901000 f5901200 f026a2dc f018505c f026a270
f005c5a4
%l0-7: 04001fc5 f00436ac 000003a6 00000020 00000000 00000009 00000000
00000001
%i0-7: f026a6c0 f026a40c f5901000 000003a6 00000002 f026a384 f026a2e8
f005cefc
Floating Point Registers:
%f00: 000000000.000000 000000000.000000 -NaN -NaN
%f04: -NaN -NaN -NaN -NaN
....
%f28: -NaN -NaN -NaN -NaN
psr: 04401fe5 (icc: -Z-- SPE: SPE) wim: 00000002
fsr: 00080000 y: 00000000
(qemu) x /30i 0xf01850a0
0xf01850a0: and %o0, 3, %o3
0xf01850a4: cmp %o3, 2
0xf01850a8: bne 0xf01850c0
0xf01850ac: srl %o2, 0xc, %o3
0xf01850b0: and %o3, 0x3f, %o3
0xf01850b4: sll %o3, 8, %o3
0xf01850b8: b 0xf01850c8
0xf01850bc: add %o0, %o3, %o0
0xf01850c0: mov %o2, %o3
0xf01850c4: lda [ %o3 ] #ASI_M_FLUSH_PROBE, %o0
0xf01850c8: srl %o0, 0x18, %o3
0xf01850cc: andcc %o3, 7, %o3
0xf01850d0: be 0xf01850dc
0xf01850d4: nop
0xf01850d8: sta %g0, [ %o2 ] #ASI_M_FLUSH_PROBE
0xf01850dc: mov 0x300, %o2
0xf01850e0: cmp %o1, 0
0xf01850e4: be 0xf01850f0
0xf01850e8: lda [ %o2 ] #ASI_M_MMUREGS, %o2
0xf01850ec: st %o2, [ %o1 ]
0xf01850f0: retl
0xf01850f4: nop
0xf01850f8: sethi %hi(0x10003000), %o2
0xf01850fc: or %o2, 0x18, %o2 ! 0x10003018
0xf0185100: retl
0xf0185104: lda [ %o2 ] #ASI_M_BYPASS, %o0
0xf0185108: unimp 0
0xf018510c: unimp 0
0xf0185110: unimp 0
0xf0185114: unimp 0
Now I know reading fragments of assembly are lots of fun, so I've
attached the dump_mmu results, which will hopefully also be useful.
Does that help point to a next step?
Thanks!
Nathan
> Hi Nick,
>
> Thanks again for testing this. The issue with Solaris not detecting the
> disks is a known one - the following guide should point you in the right
> direction:
>
> http://virtuallyfun.blogspot.com/2010/10/formatting-disks-for-solaris.html
>
> Also don't forget the "set scsi_options" part from Artyom's SPARC/QEMU
> howto here: http://tyom.blogspot.com/2009/12/solaris-under-qemu-how-to.html
>
> I think it may actually be possible to come up with a patch for OpenBIOS
> so that the scsi_options change isn't required - let me know how you get
> on with the above links, and if it all seems to work I'll look at
> creating the patch for you.
>
>
Okay, I got passed the issue with formatting the root filesystem.
Apparently there are some limitations on the C/H/S parameters you use
for the disk that correspond with how UFS wants to format a new
filesystem. I'm not sure what exactly those limitations are at this
point, but, by adjusting a couple of the C/H/S settings when using
format to set up the disk I was able to get it to work correctly. So, I
now have Solaris 9 installed on qemu-system-sparc with OpenBIOS! I'll
probably go back to Solaris 8 as that one has a free binary license
while Solaris 9 is a commercial license, IIRC. I do own a Solaris 9
commercial license, but I like the free idea, better.
Anyway, now I'm on to an issue with networking - I've used the following
two qemu network parameter combinations:
-net nic -net tap,ifname=tap0
-net nic -net user
In the first instance, tap0 was configured on my Linux box and added to
my bridge br0. In both cases the Solaris system is unable to obtain a
DHCP address - the DHCP client times out. Not sure if I should be using
a different parameter set, or if this is another area that needs some
work either for OpenBIOS or qemu?
-Nick
--------
This e-mail may contain confidential and privileged material for the sole use of the intended recipient. If this email is not intended for you, or you are not responsible for the delivery of this message to the intended recipient, please note that this message may contain SEAKR Engineering (SEAKR) Privileged/Proprietary Information. In such a case, you are strictly prohibited from downloading, photocopying, distributing or otherwise using this message, its contents or attachments in any way. If you have received this message in error, please notify us immediately by replying to this e-mail and delete the message from your mailbox. Information contained in this message that does not relate to the business of SEAKR is neither endorsed by nor attributable to SEAKR.
On 8/21/11 8:14 PM, William Hahne wrote:
> This is a forth word that is required by BootX. It just fills some
> specified memory address and length with 32 bit integers. It is a
> non-standard addition and therefore isn't documented. Thanks to Segher
> Boessenkool for the corrected for loop.
This should be written in Forth and not added as a primitive.
On Fri, Sep 9, 2011 at 1:51 AM, Jianmin Pan <dspjm1(a)gmail.com> wrote:
> I want to study the openbios project, while there is a question, I read
> that, open bios rely on other firmware, such as coreboot, in my knowledge,
> coreboot is a bios system itself, isn't there a conflict?
Coreboot is not used on Sparc and PPC, only on x86 this is possible.
Hardware init could be moved to coreboot also on Sparc/PPC but nobody
has bothered yet. This could be a nice, well-defined project and the
person doing it would gain insight to design of both projects.
On 09/09/11 02:51, Jianmin Pan wrote:
> I want to study the openbios project, while there is a question, I read
> that, open bios rely on other firmware, such as coreboot, in my
> knowledge, coreboot is a bios system itself, isn't there a conflict?
Welcome to the OpenBIOS project :) Probably the best way to think about
it is that coreboot performs the low level hardware initialisation for
various chipsets and then executes a (generally ELF) payload in order to
handle the boot process.
In the past I've managed to successfully build CoreBoot with an OpenBIOS
payload for testing under x86 on QEMU which I think is a good way to
help get yourself familiar with the process. BTW as a matter of
interest, do you have any interesting projects in mind for OpenBIOS?
ATB,
Mark.
--
Mark Cave-Ayland - Senior Technical Architect
PostgreSQL - PostGIS
Sirius Corporation plc - control through freedom
http://www.siriusit.co.uk
t: +44 870 608 0063
Sirius Labs: http://www.siriusit.co.uk/labs
I want to study the openbios project, while there is a question, I read
that, open bios rely on other firmware, such as coreboot, in my knowledge,
coreboot is a bios system itself, isn't there a conflict?
Am 28.08.2011 um 17:28 schrieb Blue Swirl:
> Detect source path from switch-arch call path. Always use absolute
> paths. Fix bootstrap.c so that for absolute paths, in addition to
> include directives (-I), the bare path is checked.
>
> Signed-off-by: Blue Swirl <blauwirbel(a)gmail.com>
> ---
> The motivation is to integrate OpenBIOS to QEMU build system.
Are we going to switch to Git at that opportunity?
Andreas
