http://permalink.gmane.org/gmane.comp.bios.openbios hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.bios.openbios/5917 <pre> It also doesn't exist before 10.5; on 10.4 you test for 64-bit differently. And again, ppc-elf- is just a random made-up name. Segher </pre> Segher Boessenkool 2013-05-10T00:09:35 http://permalink.gmane.org/gmane.comp.bios.openbios/5915 <pre>Am 08.05.2013 01:54, schrieb Programmingkid: This is clearly wrong, Segher already pointed you to that: You are wrongly assuming Darwin to mean x86/amd64 exclusively! "hw.cpu64bit_capable: 1" can mean ppc64 just as well on 10.5, so it would be best to check for Darwin 64-bitness *after* the original `uname -m` architecture sanitization. This has nothing to do with Mac OS X and thus, if we want this at all, belongs in a separate patch. git-svn can help with that. I think it is wrong that you are hardcoding ppc here, so it will fall back to ppc-elf- prefix for sparc, etc. as well. powerpc-elf- prefix is covered by ${1}-elf- here, so you'd need to check the call sites of select_prefix() instead. Regards, Andreas </pre> Andreas Färber 2013-05-09T09:48:02 http://permalink.gmane.org/gmane.comp.bios.openbios/5914 <pre> That is what this function does. And ignoring it does not tell you if the machine is x86 at all, which you just blindly assume. It might work for you, but it is just wrong and breaks things for other people. Yes I do. It is not valid on any OSX version; it is only valid on x86. Everything builds fine on 10.3 and 10.4, fwiw. Let's add a "butterfly-cherry-blossom-sortofelf-" prefix as well! I have many toolchains with custom program prefixes; I don't expect the openbios scripts to automatically pick those up, either. It is not going to scale... Segher </pre> Segher Boessenkool 2013-05-09T00:08:02 http://permalink.gmane.org/gmane.comp.bios.openbios/5913 <pre> This patch allows for building OpenBIOS on Mac OS X, but without the "Trying" output. It has been tested on Mac OS 10.6 and Debian Linux. signed-off-by: John Arbuckle &lt;programmingkidx-Re5JQEeQqe8AvxtiuMwx3w&lt; at &gt;public.gmane.org&gt; Index: trunk/openbios-devel/config/scripts/switch-arch =================================================================== --- trunk/openbios-devel/config/scripts/switch-arch(revision 1133) +++ trunk/openbios-devel/config/scripts/switch-arch(working copy) &lt; at &gt;&lt; at &gt; -89,15 +89,25 &lt; at &gt;&lt; at &gt; archname() { - HOSTARCH=`uname -m | sed -e s/i.86/x86/ -e s/i86pc/x86/ \ --e s/sun4u/sparc64/ -e s/sparc$/sparc32/ \ --e s/arm.*/arm/ -e s/sa110/arm/ -e s/x86_64/amd64/ \ --e "s/Power Macintosh/ppc/"` + OS_NAME=`uname` +if test "$OS_NAME" = "Darwin"; then # Can't depend on uname -m on Mac OS X +IS_64BIT=`sysctl hw.cpu64bit_capable` +if test "$IS_64BIT" = "hw.cpu64bit_capable: 1"; then +HOSTARCH="amd64" +else +HOSTARCH="x86" +fi +else + HOSTARCH=`uname -m | sed -e s/i.86/x86/ -e s</pre> Programmingkid 2013-05-07T23:54:49 http://permalink.gmane.org/gmane.comp.bios.openbios/5911 <pre>Author: blueswirl Date: Sat May 4 13:01:04 2013 New Revision: 1136 URL: http://tracker.coreboot.org/trac/openbios/changeset/1136 Log: Tag version 1.1 Signed-off-by: Blue Swirl &lt;blauwirbel-Re5JQEeQqe8AvxtiuMwx3w&lt; at &gt;public.gmane.org&gt; Added: tags/openbios-1.1/ - copied from r1135, trunk/openbios-devel/ </pre> repository service 2013-05-04T11:01:05 http://permalink.gmane.org/gmane.comp.bios.openbios/5910 <pre>Author: blueswirl Date: Sat May 4 12:56:49 2013 New Revision: 1135 URL: http://tracker.coreboot.org/trac/openbios/changeset/1135 Log: Bump version to 1.1 Signed-off-by: Blue Swirl &lt;blauwirbel-Re5JQEeQqe8AvxtiuMwx3w&lt; at &gt;public.gmane.org&gt; Modified: trunk/openbios-devel/VERSION Modified: trunk/openbios-devel/VERSION ============================================================================== --- trunk/openbios-devel/VERSIONFri May 3 23:45:00 2013(r1134) +++ trunk/openbios-devel/VERSIONSat May 4 12:56:49 2013(r1135) &lt; at &gt;&lt; at &gt; -1 +1 &lt; at &gt;&lt; at &gt; -1.0 +1.1 </pre> repository service 2013-05-04T10:56:51 http://permalink.gmane.org/gmane.comp.bios.openbios/5909 <pre> I would have thought the compiler was allowed to optimize away a loop that incremented something that noone ever looks at. It doesn't do anything after all. </pre> Lennart Sorensen 2013-05-03T21:54:24 http://permalink.gmane.org/gmane.comp.bios.openbios/5908 <pre> Oh yes of course. I missed that detail. Oops. Makes sense now. </pre> Lennart Sorensen 2013-05-03T22:11:39 http://permalink.gmane.org/gmane.comp.bios.openbios/5907 <pre> Fortunately the use of the "volatile" quantifier in the patch makes sure that this doesn't happen. Both myself and Artyom have tested the patch and it works for both of us, so I'm reasonably confident. The reason that the udelay() implementation is a trivial one is because we need something simple in order to get a working OpenBIOS (and hopefully 1.1 release) into QEMU git master in time for feature freeze on Monday. If anyone else would like to investigate using timers for udelay() on SPARC32/64, I'd be very happy to accept patches from next week onwards. ATB, Mark. </pre> Mark Cave-Ayland 2013-05-03T22:07:24 http://permalink.gmane.org/gmane.comp.bios.openbios/5906 <pre>I see that you used a loop to simulate a wait time. I think there must be a better way of doing it. Doesn't the Sparc emulator have access to a hardware clock that we can use instead of a loop? </pre> Programmingkid 2013-05-03T21:50:39 http://permalink.gmane.org/gmane.comp.bios.openbios/5905 <pre>Author: mcayland Date: Fri May 3 23:45:00 2013 New Revision: 1134 URL: http://tracker.coreboot.org/trac/openbios/changeset/1134 Log: SPARC64: Add trivial implementation of udelay() The OpenBIOS IDE driver calls udelay() in order to wait for IDE transfers to complete. Without an implementation of udelay(), the IDE timeout is too low causing sporadic errors during periods of high I/O activity. As reported by Artyom Tarasenko. Signed-off-by: Mark Cave-Ayland &lt;mark.cave-ayland-r2/yp8inhXLQXOPxS62xeg&lt; at &gt;public.gmane.org&gt; Modified: trunk/openbios-devel/arch/sparc64/openbios.c Modified: trunk/openbios-devel/arch/sparc64/openbios.c ============================================================================== --- trunk/openbios-devel/arch/sparc64/openbios.cSat Apr 27 13:42:18 2013(r1133) +++ trunk/openbios-devel/arch/sparc64/openbios.cFri May 3 23:45:00 2013(r1134) &lt; at &gt;&lt; at &gt; -547,6 +547,9 &lt; at &gt;&lt; at &gt; void udelay(unsigned int usecs) { + volatile int i; + + for (i = 0; i &lt; usecs * 100; i++); } static void ini</pre> repository service 2013-05-03T21:45:03 http://permalink.gmane.org/gmane.comp.bios.openbios/5904 <pre>On Sun, Apr 28, 2013 at 10:29 PM, Mark Cave-Ayland &lt;mark.cave-ayland-r2/yp8inhXLQXOPxS62xeg&lt; at &gt;public.gmane.org&gt; wrote: Ha. Told ya, it's a race in OpenBIOS. :-) . AFAIK that's what OBP does on sun4m. Obviously worked good back then, but nowadays it's not so attractive: even bare metal CPUs may have frequency scaling. In the virtual world the number of instructions per millisecond is even more volatile. Also some day the TCG optimiser may just optimise the empty loops away. If we need a precise sleep, we need timer interrupts, or a paravirtual sleep device. Though in this particular case, why not just replace "5000" with some value large enough? Reading from a hardware register is a good delay itself. Artyom -- Regards, Artyom Tarasenko linux/sparc and solaris/sparc under qemu blog: http://tyom.blogspot.com/search/label/qemu </pre> Artyom Tarasenko 2013-04-28T21:56:51 http://permalink.gmane.org/gmane.comp.bios.openbios/5903 <pre> Ha okay - I finally figured this one out with a reproducible test case like this: 1) First drop the Linux filesystem cache: echo 3 &gt; /proc/sys/vm/drop_caches 2) Start up QEMU - this now blows up in SILO: ./qemu-system-sparc64 -hda /home/build/src/qemu/image/sparc64/debian-wheezy.qcow2 -boot c -nographic -snapshot 3) Load the debian-wheezy.qcow2 image into the filesystem cache cat debian-wheezy.qcow2 &gt; /dev/null 4) Restart QEMU again and the image boots ./qemu-system-sparc64 -hda /home/build/src/qemu/image/sparc64/debian-wheezy.qcow2 -boot c -nographic -snapshot Once I could reproduce this at will, I recompiled OpenBIOS with CONFIG_DEBUG_IDE enabled and got the following output: Jumping to entry point 0000000000004000 for type 0000000000000005... switching to new context: entry point 0x4000 stack 0x00000000ffe86a39 SIDE - ob_ide_open: opening channel -1539032 unit 0 IDE DRIVE &lt; at &gt;ffe88428: unit: 0 present: 1 type: 1 media: 32 model: QEMU HARDDISK nr: 0 cyl: 8322 head: 16 sect: 63 bs: 512 IDE - ob_i</pre> Mark Cave-Ayland 2013-04-28T20:29:05 http://permalink.gmane.org/gmane.comp.bios.openbios/5902 <pre> But in your patch above you didn't touch the Ethernet, only cmd646 and vga, or am I missing something? Another question - is VGA legacy low mem area turned on by the PCI feature called "DOS Compatibility" in the PBM and APB docs? Both PBM and APB docs say that they don't have "DOS Compatibility" feature. Maybe it's possible to tell the VGA card, that we don't need the low mem area? -- Regards, Artyom Tarasenko linux/sparc and solaris/sparc under qemu blog: http://tyom.blogspot.com/search/label/qemu </pre> Artyom Tarasenko 2013-04-28T16:28:50 http://permalink.gmane.org/gmane.comp.bios.openbios/5901 <pre> Hmmm yes. That could be a nice tidy-up... ATB, Mark. </pre> Mark Cave-Ayland 2013-04-27T11:56:26 http://permalink.gmane.org/gmane.comp.bios.openbios/5900 <pre> Hi Artyom, Nice patchset! Any reason why this invokes get_cur_dev() rather than just using dev as per the OLDWORLD/NEWWORLD calls? ATB, Mark. </pre> Mark Cave-Ayland 2013-04-27T11:55:21 http://permalink.gmane.org/gmane.comp.bios.openbios/5899 <pre> Maybe we should make a macro similar to OLDWORLD() and NEWWORLD() for Sparc64? </pre> Blue Swirl 2013-04-27T11:47:11 http://permalink.gmane.org/gmane.comp.bios.openbios/5898 <pre>Thanks, applied all. On Sat, Apr 27, 2013 at 5:58 AM, Artyom Tarasenko &lt;atar4qemu-Re5JQEeQqe8AvxtiuMwx3w&lt; at &gt;public.gmane.org&gt; wrote: </pre> Blue Swirl 2013-04-27T11:44:34 http://permalink.gmane.org/gmane.comp.bios.openbios/5897 <pre>Author: blueswirl Date: Sat Apr 27 13:42:18 2013 New Revision: 1133 URL: http://tracker.coreboot.org/trac/openbios/changeset/1133 Log: use the proper name for the virtio-blk devices The name 'virtio-scsi' is misleading, since there is another device called 'virtio-scsi' in QEMU. Use the name 'virtio-blk' instead. Signed-off-by: Artyom Tarasenko &lt;atar4qemu-Re5JQEeQqe8AvxtiuMwx3w&lt; at &gt;public.gmane.org&gt; Signed-off-by: Blue Swirl &lt;blauwirbel-Re5JQEeQqe8AvxtiuMwx3w&lt; at &gt;public.gmane.org&gt; Modified: trunk/openbios-devel/drivers/pci_database.c Modified: trunk/openbios-devel/drivers/pci_database.c ============================================================================== --- trunk/openbios-devel/drivers/pci_database.cSat Apr 27 13:42:16 2013(r1132) +++ trunk/openbios-devel/drivers/pci_database.cSat Apr 27 13:42:18 2013(r1133) &lt; at &gt;&lt; at &gt; -49,7 +49,7 &lt; at &gt;&lt; at &gt; { /* Virtio-block controller */ PCI_VENDOR_ID_REDHAT_QUMRANET, PCI_DEVICE_ID_VIRTIO_BLOCK, - NULL, "virtio-scsi", NULL, + NULL, "virt</pre> repository service 2013-04-27T11:42:19 http://permalink.gmane.org/gmane.comp.bios.openbios/5896 <pre>Author: blueswirl Date: Sat Apr 27 13:42:16 2013 New Revision: 1132 URL: http://tracker.coreboot.org/trac/openbios/changeset/1132 Log: sparc64: remove hacks for the "interrupts" property Forcing the "interrupts" property to the value of zero is not necessary, and is incompatible with the IRQ mapping schema introduced in the previous commit Signed-off-by: Artyom Tarasenko &lt;atar4qemu-Re5JQEeQqe8AvxtiuMwx3w&lt; at &gt;public.gmane.org&gt; Signed-off-by: Blue Swirl &lt;blauwirbel-Re5JQEeQqe8AvxtiuMwx3w&lt; at &gt;public.gmane.org&gt; Modified: trunk/openbios-devel/drivers/ide.c trunk/openbios-devel/drivers/pci.c trunk/openbios-devel/drivers/pci_database.c trunk/openbios-devel/drivers/pci_database.h Modified: trunk/openbios-devel/drivers/ide.c ============================================================================== --- trunk/openbios-devel/drivers/ide.cSat Apr 27 13:42:14 2013(r1131) +++ trunk/openbios-devel/drivers/ide.cSat Apr 27 13:42:16 2013(r1132) &lt; at &gt;&lt; at &gt; -1432,8 +1432,6 &lt; at &gt;&lt; at &gt; props[0]=14; props[1]=0; set_property</pre> repository service 2013-04-27T11:42:17 http://permalink.gmane.org/gmane.comp.bios.openbios/5895 <pre>Author: blueswirl Date: Sat Apr 27 13:42:14 2013 New Revision: 1131 URL: http://tracker.coreboot.org/trac/openbios/changeset/1131 Log: sparc64: use direct interrupt mapping for PCI devices Every PCI Slot in PBM has 4 directly mapped IRQ lines. Use the IRQ routing schema 0bssnn (Bus, Slot, interrupt Number) described in Section 19.3.3 of UltraSPARC™-IIi User's Manual. Please note that this patch requires the QEMU counterpart patch. Signed-off-by: Artyom Tarasenko &lt;atar4qemu&lt; at &gt;gmail.com&gt; Signed-off-by: Blue Swirl &lt;blauwirbel&lt; at &gt;gmail.com&gt; Modified: trunk/openbios-devel/drivers/pci.c Modified: trunk/openbios-devel/drivers/pci.c ============================================================================== --- trunk/openbios-devel/drivers/pci.cSat Apr 27 13:30:16 2013(r1130) +++ trunk/openbios-devel/drivers/pci.cSat Apr 27 13:42:14 2013(r1131) &lt; at &gt;&lt; at &gt; -854,7 +854,14 &lt; at &gt;&lt; at &gt; if (config-&gt;irq_pin) { OLDWORLD(set_int_property(dev, "AAPL,interrupts", config-&gt;irq_line)); +#if defined(CONFIG_SPARC64) + </pre> repository service 2013-04-27T11:42:14 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.bios.openbios