OpenBIOS September 2011

openbios@openbios.org

6 participants
7 discussions

Re: [OpenBIOS] Solaris anyone? Solaris 9 04/04

by Nathan Kunkee

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

10 years, 8 months

Re: [OpenBIOS] Solaris anyone?

by Nick Couchman

> 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.

10 years, 8 months

Re: [OpenBIOS] [PATCH 10/10] Adding filll Forth primitive (v2)

by Stefan Reinauer

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.

10 years, 8 months

Re: [OpenBIOS] Openbios rely on other lower-level firmware

by Blue Swirl

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.

10 years, 8 months

Re: [OpenBIOS] Openbios rely on other lower-level firmware

by Mark Cave-Ayland

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

10 years, 8 months

Openbios rely on other lower-level firmware

by Jianmin Pan

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?

10 years, 8 months

Re: [OpenBIOS] [PATCH] Support any build directory

by Andreas Färber

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

10 years, 8 months