OpenBIOS January 2009

openbios@openbios.org

14 participants
148 discussions

OpenBIOS dictionary relocation - can anyone explain this?
by Mark Cave-Ayland 22 Jan '09

22 Jan '09

Hi everyone, I'm trying to check the the forth dictionary is being loaded correctly on Sparc64, and I'm struggling to understand the dynamic relocation code from kernel/dict.c: ==== cut ==== dicthead = target_long(header->length); memcpy(dict, data, dicthead); reloc_table=(ucell *)(data+dicthead); #ifdef CONFIG_DEBUG_DICTIONARY printk("\nmoving dictionary (%x bytes) to %x\n", (ucell)dicthead, (ucell)dict); printk("\ndynamic relocation..."); #endif for (walk = (ucell *) dict; walk < (ucell *) (dict + dicthead); walk++) { int pos, bit, l; l=(walk-(ucell *)dict); pos=l/BITS; bit=l&~(-BITS); if (reloc_table[pos]&target_ucell(1UL<<bit)) { // printk("%lx, pos %x, bit %d\n",*walk, pos, bit); write_ucell(walk, read_ucell(walk)+pointer2cell(dict)); } } #ifdef CONFIG_DEBUG_DICTIONARY printk(" done.\n"); #endif ==== cut ==== Stepping through with the debugger, l appears to be a count of the number of words from the beginning of the dictionary, pos is set to either 0 or 1 depending upon whether the word offset is a multiple of the target word size and bit is a modulo of l, again based upon the word size. It looks as if bit is being used to set up a shifting bit mask up to the word size in bits, and it is based upon the interaction of this and reloc_table[pos] which decides whether any code is moved. Can anyone shed any light on exactly what this code does, and how it actually does it? The part that confuses me the most is that decisions are being made on which words to relocate, but these criteria are based upon some strange combination of arithmetic involving the current offset and the target word size. Many thanks, Mark. -- Mark Cave-Ayland Sirius Corporation - The Open Source Experts http://www.siriusit.co.uk T: +44 870 608 0063

2 3

[sparc64] Problematic pci@0 and pci nodes in the device tree
by Jakub Jermar 18 Jan '09

18 Jan '09

Hi, I have the following problem with the OpenBIOS device tree (the current Qemu version): In the root directory, there are currently two pci nodes: ffd97778 pci@0 ffd98808 pci The "screen" alias is defined as: /pci/pci/pci/QEMU,VGA When HelenOS attempts to lookup this path, it fails, because it matches /pci instead of /pci@0 and /pci does not have any children. HelenOS is normally designed to cope with ambiguous node names, but in this case the /pci node matches and sends it to the wrong direction. I think the "screen" alias should be either defined using the non-ambiguous pci@0 path components or the /pci node should not exist at all. Can you confirm this is a problem in the tree? Thanks, Jakub

2 6

[PATCH][RFC] Consolidate Makefiles
by Blue Swirl 18 Jan '09

18 Jan '09

Hi, This patch (to be applied after the previous one) collects identical Makefile fragments to common files. Known bugs: Cross compiling should be detected automatically. I should also revert the rules.xml change in the previous patch to avoid one extra link for each target.

1 0

[PATCH][RFC] mac-io IDE support
by Laurent Vivier 18 Jan '09

18 Jan '09

Hi, this patch adds the mac-io IDE support to openBIOS. It works well with openBIOS (to load kernel) and with kernel 2.4 but has some problems with linux 2.6. For instance, using debian-31r8-powerpc-netinst.iso with kernel 2.4 works well (but not kernel 2.6), but using debian-40r6-powerpc- netinst.iso fails when debian-installer loads all udeb components. Is there a bug in qemu, linux or the mac-io IDE device tree is not initialized correctly ? Regards, Laurent

3 4

[PATCH][RFC] Multiple target support
by Blue Swirl 18 Jan '09

18 Jan '09

Hi, This patch allows configuration for multiple targets, like: ./config/scripts/switch-arch amd64 cross-ppc cross-sparc32 cross-sparc64 cross-x86 The command creates directories (obj-amd64 obj-ppc obj-sparc32 obj-sparc64 obj-x86), Makefiles and other config stuff. To build all configured targets, use: make build or make build-verbose The benefit is that after a change to a file that affect several architectures, total recompile time is reduced greatly because only the changed file need to be recompiled and linked. Also there is no need to use rules.xml and config.xml links in the top level directory. I've only tested the following targets: amd64 cross-ppc cross-sparc32 cross-sparc64 cross-x86. Maybe with small further changes it would also be possible to put the object directories completely outside of the source tree. Comments?

1 0

r419 - openbios-devel/config/scripts
by svn＠openbios.org 18 Jan '09

18 Jan '09

Author: blueswirl Date: 2009-01-18 11:14:58 +0100 (Sun, 18 Jan 2009) New Revision: 419 Modified: openbios-devel/config/scripts/switch-arch Log: Update build target description Modified: openbios-devel/config/scripts/switch-arch =================================================================== --- openbios-devel/config/scripts/switch-arch 2009-01-17 20:39:12 UTC (rev 418) +++ openbios-devel/config/scripts/switch-arch 2009-01-18 10:14:58 UTC (rev 419) @@ -1,8 +1,11 @@ #!/bin/sh if [ x"$1" = x ]; then - printf "Usage:\n $0 [arch-config]" - printf "\narch-config: cross-ppc, x86\n" + printf "Usage:\n $0 [arch-config]\n" + printf "arch-config values supported for native builds:\n" + printf " amd64, ppc, sparc32, sparc64, x86\n" + printf "arch-config values supported for cross compiled builds:\n" + printf " cross-ppc, cross-sparc32, cross-sparc64, cross-x86\n" exit 0 fi

1 0

r418 - openbios-devel/drivers
by svn＠openbios.org 17 Jan '09

17 Jan '09

Author: blueswirl Date: 2009-01-17 21:39:12 +0100 (Sat, 17 Jan 2009) New Revision: 418 Modified: openbios-devel/drivers/escc.c Log: Send key on key press, not release: closes #26 Modified: openbios-devel/drivers/escc.c =================================================================== --- openbios-devel/drivers/escc.c 2009-01-17 20:28:21 UTC (rev 417) +++ openbios-devel/drivers/escc.c 2009-01-17 20:39:12 UTC (rev 418) @@ -272,8 +272,8 @@ else if (ch == 238) shiftstate &= ~2; //printk("getch: %d\n", ch); - } - while ((ch & 0x80) == 0 || ch == 238 || ch == 227); // Wait for key release + } // If release, wait for key press + while ((ch & 0x80) == 0x80 || ch == 238 || ch == 227); //printk("getch rel: %d\n", ch); ch &= 0x7f; if (shiftstate)

1 0

r417 - openbios-devel/kernel
by svn＠openbios.org 17 Jan '09

17 Jan '09

Author: blueswirl Date: 2009-01-17 21:28:21 +0100 (Sat, 17 Jan 2009) New Revision: 417 Modified: openbios-devel/kernel/bootstrap.c Log: Suppress OpenBSD linker warning Modified: openbios-devel/kernel/bootstrap.c =================================================================== --- openbios-devel/kernel/bootstrap.c 2009-01-17 19:02:38 UTC (rev 416) +++ openbios-devel/kernel/bootstrap.c 2009-01-17 20:28:21 UTC (rev 417) @@ -447,9 +447,7 @@ include *incl = &includes; while (incl) { - strncpy(fullpath, incl->path, MAX_PATH_LEN); - strncat(fullpath, "/", MAX_PATH_LEN); - strncat(fullpath, fil, MAX_PATH_LEN); + snprintf(fullpath, sizeof(fullpath), "%s/%s", incl->path, fil); ret = fopen(fullpath, "r"); if (ret != NULL) return ret;

1 0

[PATCH] PowerPC: Fix PCI I/O ports allocation
by Aurelien Jarno 17 Jan '09

17 Jan '09

Long story, small patch... On the PowerPC target, the PCI devices using I/O ports are currently not working correctly with a relatively old kernel (<= 2.6.24). This is due to the assignation of I/O port 0, while the I/O ports start at 1, which keeps the device disabled. Recent version of Linux assign resources to those devices, that's why the problem wasn't present on those versions. Moreover the QEMU OldWorld machine have a few devices mapped on fixed I/O ports, that should be skipped when assigning I/O ports to PCI devices. Those devices are: - video card (0x3c0-0x3cf, 0x3b4-0x3b5, 0x3ba, 0x1ce-0x1cf, 0x1d0-0x1d1) - i8259 (0x20-0x21, 0xa0-0x1a, 0x4d0-0x4d1) - m48t59 (0x74-0x79) - OpenBIOS debug port (0xf00-0xf03) Given that ranges, I have decided to start mapping PCI I/O ports at 0x1000. Note that real G3 beige starts to map them at 0x400. This can be changed later, when we get rid of the i8259 and m48t59 and if we move the OpenBIOS debug port. I have done this change unconditionally because Sparc also have the problem, though the first I/O port can be chosen differently. Index: drivers/pci.c =================================================================== --- drivers/pci.c (révision 411) +++ drivers/pci.c (copie de travail) @@ -760,7 +760,8 @@ /* Find all PCI bridges */ mem_base = arch->mem_base; - io_base = arch->io_base; + /* I/O ports under 0x1000 are used by devices mapped at fixed location. */ + io_base = arch->io_base + 0x1000; path = strdup(""); for (bus = 0; bus<0x100; bus++) { ob_scan_pci_bus(bus, &mem_base, &io_base, &path); -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' aurel32(a)debian.org | aurelien(a)aurel32.net `- people.debian.org/~aurel32 | www.aurel32.net

2 2

r416 - openbios-devel/drivers
by svn＠openbios.org 17 Jan '09

17 Jan '09

Author: blueswirl Date: 2009-01-17 20:02:38 +0100 (Sat, 17 Jan 2009) New Revision: 416 Modified: openbios-devel/drivers/pci.c Log: Fix PCI I/O ports allocation (Aurelien Jarno) Modified: openbios-devel/drivers/pci.c =================================================================== --- openbios-devel/drivers/pci.c 2009-01-17 18:42:48 UTC (rev 415) +++ openbios-devel/drivers/pci.c 2009-01-17 19:02:38 UTC (rev 416) @@ -760,7 +760,9 @@ /* Find all PCI bridges */ mem_base = arch->mem_base; - io_base = arch->io_base; + /* I/O ports under 0x400 are used by devices mapped at fixed + location. */ + io_base = arch->io_base + 0x400; path = strdup(""); for (bus = 0; bus<0x100; bus++) { ob_scan_pci_bus(bus, &mem_base, &io_base, &path);

1 0

← Newer
1
2
3
4
5
6
7
...
15
Older →

Jump to page: