OpenBIOS April 2012

openbios@openbios.org

16 participants
40 discussions

[PATCH 0/8] RFC: OFMEM cleanup/memory reduction patch v2

by Mark Cave-Ayland

v2: Alter the SPARC64 video initialisation hack code so that it handles having a video memory mapping where phys_addr != virt_addr. When allocating the Forth machine memory using OFMEM, align the region on a 512K boundary on SPARC64 so that we only use 1 TLB slot for better efficiency. v1: This patchset aims to tidy up various parts of OFMEM, with the ultimate aim of reducing the image sizes. The first 4 patches perform the reorganisation, while the remainder of the patches ensure that video memory and the Forth machine memory are no longer contained within the image. Note: the resulting SPARC64 image is now approximately half of its original size - BUT because we require 512K alignment for various parts of the image because of the 512K MMU page size, our ability to claim this space back directly is limited. Any further ideas on this would be welcomed. Mark Cave-Ayland (8): Rename ofmem_arch_early_map_pages() to ofmem_arch_map_pages(). SPARC32: Move ofmem_arch_map_pages() into ofmem_sparc32.c with all the other architecture-specific code. SPARC64: Refactor tte-data code in preparation for moving architecture-specific code to ofmem_sparc64.c. SPARC64: Move ofmem_arch_map_pages()/ofmem_arch_unmap_pages() into ofmem_sparc64.c with all the other architecture-specific code. Remove architecture-specific routines from ofmem.h. SPARC64: Remove majority of the video initialisation hack. SPARC64: Swap Forth machine memory allocation over to OFMEM memory pool. SPARC32: Swap Forth machine memory allocation over to OFMEM memory pool. openbios-devel/arch/ppc/ofmem.c | 2 +- openbios-devel/arch/ppc/qemu/ofmem.c | 6 +- openbios-devel/arch/sparc32/lib.c | 95 +--------- openbios-devel/arch/sparc32/ofmem_sparc32.c | 82 ++++++++- openbios-devel/arch/sparc32/openbios.c | 27 ++- openbios-devel/arch/sparc64/ldscript | 6 - openbios-devel/arch/sparc64/lib.c | 210 ++------------------ openbios-devel/arch/sparc64/ofmem_sparc64.c | 176 ++++++++++++++++- openbios-devel/arch/sparc64/ofmem_sparc64.h | 32 --- openbios-devel/arch/sparc64/openbios.c | 30 ++- openbios-devel/drivers/iommu.c | 4 +- openbios-devel/drivers/vga_vbe.c | 9 +- .../include/arch/sparc32/ofmem_sparc32.h | 28 +++ openbios-devel/include/arch/sparc64/io.h | 2 +- .../include/arch/sparc64/ofmem_sparc64.h | 50 +++++ openbios-devel/include/libopenbios/ofmem.h | 22 +-- openbios-devel/libopenbios/ofmem_common.c | 6 +- openbios-devel/packages/video.c | 36 ++-- 18 files changed, 424 insertions(+), 399 deletions(-) delete mode 100644 openbios-devel/arch/sparc64/ofmem_sparc64.h create mode 100644 openbios-devel/include/arch/sparc32/ofmem_sparc32.h create mode 100644 openbios-devel/include/arch/sparc64/ofmem_sparc64.h -- 1.7.2.5

8 years, 12 months

Re: [OpenBIOS] [PATCH 0/8] RFC: OFMEM cleanup/memory reduction patch

by Mark Cave-Ayland

On 14/04/12 13:00, Blue Swirl wrote: >> Well, the use case I'm considering at the moment is that if you build >> OpenBIOS SPARC32 with -O0 -g and then try to load it into QEMU, QEMU reports >> that the image is too large. So I'm guessing this is a limitation of the >> memory layout of the machine, rather than the space occupied by the binary. > > I'm not sure we should have this restriction on ROM size in QEMU. > Currently PROM_SIZE_MAX in QEMU is 1M, but at first the CPU is in boot > mode and so the ROM is visible for instruction access at address 0 > upwards instead of end of memory, it could be much larger. The next > device is located 16MB higher on both SS-5 and SS-20, so the max could > be easily 16MB. Oh okay - if we do actually have more space to use, then I agree that then we don't need to worry about it. Changing QEMU will be easier than writing a new set of code ;) > However, the ROM is copied to RAM soon by OpenBIOS and the RAM copy is > mapped at 0xffd00000 upwards (3MB hole). In this hole we also have to > reserve virtual address space or VA to devices esp. frame buffer > (1MB), so the available VA during run time is limited. So I don't see > how any compression would help, because after decompression the > decompressed stuff (which should actually be slightly bigger than > original because of the decompression code) must still fit to the area > available. > > It could be possible to perform some kind of bank switching to avoid > using more address space, or for example frame buffer could be > unmapped on Forth entry and remapped afterwards but this is IMHO too > tricky. > > We could also use the other VA areas mentioned in the standard, or > just blatantly use more VA than we should, probably everything would > still work because OS should not make assumptions on the what > allocations OF has made anyway. Note that this is what the patches for SPARC32/SPARC64 do at the end of my patchset (and I believe is what PPC does already) - we allocate a separate range of memory for the Forth machine using standard OFMEM calls. Since OFMEM updates the various memory/translation properties to reflect this (and various OS read these properties upon boot) then in theory everything should just work. At least I haven't seen any regressions on my test images here. I've got a new version of the patchset with some more improvements I shall post shortly. ATB, Mark.

8 years, 12 months

Re: [OpenBIOS] [PATCH] pci: fix BAR setup

by Tarl Neustaedter

On 2012-Apr-19 16:29 , Artyom Tarasenko wrote: >> > >> > On an Ultra-5 this should be >> > 00000000.00000000.00000000.000001fe.01000000.00000000.01000000. >> > 01000000.00000000.00000000.000001fe.02000000.00000000.01000000. >> > 02000000.00000000.00000000.000001ff.00000000.00000001.00000000. >> > 03000000.00000000.00000000.000001ff.00000000.00000001.00000000 >> > >> > http://git.kernel.org/?p=linux/kernel/git/davem/prtconfs.git;a=blob;f=ultra… >> > >> > I guess the problem is that the properties are added by finding the >> > host bridge in the PCI bus (which btw isn't so nice), so we use the >> > pci_mem_base. Using pci_mem_base = 0 would probably fix the BAR, but >> > then VGA would get in the way. Probably something more complex is >> > needed. > Hmm. Complicated. What is actually the meaning of this property? Don't > we need the values ourselves? > If these are just BARs, can't we pass the configuration from qemu? > It's the usable address ranges on PCI - 00 is Config space, 01 is IO space, 02 is 32-bit memory and 03 is 64-bit memory. Two gotchas I know of around the memory properties. First, in Openboot, we had to hard-code never allocating address zero for memory. Too many cards out there treat a zero address in the bar as meaning "off". The other is that in the above 32-bit and 64-bit memory spaces overlap. If you try to implement this "correctly" (with a separate allocator for each), you'll end up stepping on yourself as you allocate the same address twice. But Ultra-5 doesn't support real 64-bit, so you end up pointing both 32-bit and 64-bit allocators to the same database.

8 years, 12 months

Re: [OpenBIOS] [PATCH] pci: fix BAR setup

by Blue Swirl

On Thu, Apr 19, 2012 at 20:29, Artyom Tarasenko <atar4qemu(a)gmail.com> wrote: > On Thu, Apr 19, 2012 at 10:04 PM, Blue Swirl <blauwirbel(a)gmail.com> wrote: >> On Thu, Apr 19, 2012 at 19:06, Artyom Tarasenko <atar4qemu(a)gmail.com> wrote: >>> On Sun, Mar 11, 2012 at 11:59 AM, Blue Swirl <blauwirbel(a)gmail.com> wrote: >>>> A change in QEMU on how PCI bridges are setup revealed >>>> a bug in OpenBIOS PCI setup. On Sparc64, the BARs just >>>> happened to get somewhat correct values by accident before >>>> the commit but not after the change. >>>> >>>> Don't use arch->io_base for PCI I/O port BARs. >>>> >>>> Fix Sparc64 PCI memory base. >>> >>> Could it be that the ranges property needs to be adjusted to look as >>> it did before the patch? >>> >>> This patch breaks HelenOS-0.4.3/sparc boot. But if I modify the ranges >>> property to the old value, HelenOS boots. >>> >>> 0 > cd /pci@1fe,0 ok >>> 0 > .properties >>> [...] >>> ranges -- 54 : 00 00 00 00 00 00 00 00 00 00 00 00 >>> 00 00 01 fe 01 00 00 00 00 00 00 00 02 00 00 00 01 00 00 00 00 00 00 >>> 00 00 00 00 00 00 00 01 fe 02 00 00 00 00 00 00 00 00 01 00 00 02 00 >>> 00 00 00 00 00 00 00 10 00 00 00 00 01 ff 00 00 00 00 00 00 00 00 10 >>> 00 00 00 >>> >>> Not sure about the best formatting. If I reformat it like this: >>> >>> 00000000 00000000 00000000 000001fe 01000000 00000000 02000000 >>> 01000000 00000000 00000000 000001fe 02000000 00000000 00010000 >>> 02000000 00000000 00100000 000001ff 00000000 00000000 10000000 >>> ^^^^ this one (the third) used to be 0 >>> >> >> On an Ultra-5 this should be >> 00000000.00000000.00000000.000001fe.01000000.00000000.01000000. >> 01000000.00000000.00000000.000001fe.02000000.00000000.01000000. >> 02000000.00000000.00000000.000001ff.00000000.00000001.00000000. >> 03000000.00000000.00000000.000001ff.00000000.00000001.00000000 >> >> http://git.kernel.org/?p=linux/kernel/git/davem/prtconfs.git;a=blob;f=ultra… >> >> I guess the problem is that the properties are added by finding the >> host bridge in the PCI bus (which btw isn't so nice), so we use the >> pci_mem_base. Using pci_mem_base = 0 would probably fix the BAR, but >> then VGA would get in the way. Probably something more complex is >> needed. > > Hmm. Complicated. What is actually the meaning of this property? Don't > we need the values ourselves? > If these are just BARs, can't we pass the configuration from qemu? The device drivers in OpenBIOS only want physical addresses, they should be getting correct values, otherwise they wouldn't work. But an OS must use 'ranges' to calculate them. Assistance from QEMU should not be needed, just bridge handling (maybe also PCI probing, again) should be fixed in OpenBIOS. > >>>> Signed-off-by: Blue Swirl <blauwirbel(a)gmail.com> >>>> --- >>>> >>>> I removed the bridge setup code, it's not really valid for Sparc64 APB >>>> bridges anyway and currently no devices exist behind the bridges (but >>>> that's where they really should be). >>>> >>>> Tested Sparc64 and PPC. >>>> >>>> --- >>>> arch/sparc64/openbios.c | 2 +- >>>> drivers/pci.c | 11 +++++++++-- >>>> 2 files changed, 10 insertions(+), 3 deletions(-) >>>> >>>> diff --git a/arch/sparc64/openbios.c b/arch/sparc64/openbios.c >>>> index ac709fe..ab32a8f 100644 >>>> --- a/arch/sparc64/openbios.c >>>> +++ b/arch/sparc64/openbios.c >>>> @@ -64,7 +64,7 @@ static const struct hwdef hwdefs[] = { >>>> .cfg_base = APB_SPECIAL_BASE, >>>> .cfg_len = 0x2000000, >>>> .host_mem_base = APB_MEM_BASE, >>>> - .pci_mem_base = 0, >>>> + .pci_mem_base = 0x100000, /* avoid VGA at 0xa0000 */ >>>> .mem_len = 0x10000000, >>>> .io_base = APB_SPECIAL_BASE + 0x2000000ULL, // PCI Bus I/O space >>>> .io_len = 0x10000, >>>> diff --git a/drivers/pci.c b/drivers/pci.c >>>> index f8c6414..e270a73 100644 >>>> --- a/drivers/pci.c >>>> +++ b/drivers/pci.c >>>> @@ -931,6 +931,7 @@ static void ob_pci_configure_bar(pci_addr addr, >>>> pci_config_t *config, >>>> >>>> if ((*p_omask & 0x0000000f) == 0x4) { >>>> /* 64 bits memory mapping */ >>>> + PCI_DPRINTF("Skipping 64 bit BARs for %s\n", config->path); >>>> return; >>>> } >>>> >>>> @@ -966,11 +967,17 @@ static void ob_pci_configure_bar(pci_addr addr, >>>> pci_config_t *config, >>>> size = min_align; >>>> reloc = (reloc + size -1) & ~(size - 1); >>>> if (*io_base == base) { >>>> + PCI_DPRINTF("changing io_base from 0x%lx to 0x%x\n", >>>> + *io_base, reloc + size); >>>> *io_base = reloc + size; >>>> - reloc -= arch->io_base; >>>> } else { >>>> + PCI_DPRINTF("changing mem_base from 0x%lx to 0x%x\n", >>>> + *mem_base, reloc + size); >>>> *mem_base = reloc + size; >>>> } >>>> + PCI_DPRINTF("Configuring BARs for %s: reloc 0x%x omask 0x%x " >>>> + "io_base 0x%lx mem_base 0x%lx size 0x%x\n", >>>> + config->path, reloc, *p_omask, *io_base, *mem_base, size); >>>> pci_config_write32(addr, config_addr, reloc | *p_omask); >>>> config->assigned[reg] = reloc | *p_omask; >>>> } >>>> @@ -1260,7 +1267,7 @@ int ob_pci_init(void) >>>> mem_base = arch->pci_mem_base; >>>> /* I/O ports under 0x400 are used by devices mapped at fixed >>>> location. */ >>>> - io_base = arch->io_base + 0x400; >>>> + io_base = 0x400; >>>> >>>> bus = 0; >>>> >>>> -- >>>> 1.7.9 >>>> >>>> -- >>>> OpenBIOS http://openbios.org/ >>>> Mailinglist: http://lists.openbios.org/mailman/listinfo >>>> Free your System - May the Forth be with you >>> >>> >>> >>> -- >>> Regards, >>> Artyom Tarasenko >>> >>> solaris/sparc under qemu blog: http://tyom.blogspot.com/search/label/qemu >>> >>> -- >>> OpenBIOS http://openbios.org/ >>> Mailinglist: http://lists.openbios.org/mailman/listinfo >>> Free your System - May the Forth be with you >> >> -- >> OpenBIOS http://openbios.org/ >> Mailinglist: http://lists.openbios.org/mailman/listinfo >> Free your System - May the Forth be with you > > > > -- > Regards, > Artyom Tarasenko > > solaris/sparc under qemu blog: http://tyom.blogspot.com/search/label/qemu > > -- > OpenBIOS http://openbios.org/ > Mailinglist: http://lists.openbios.org/mailman/listinfo > Free your System - May the Forth be with you

8 years, 12 months

Re: [OpenBIOS] [PATCH] pci: fix BAR setup

by Artyom Tarasenko

On Thu, Apr 19, 2012 at 10:04 PM, Blue Swirl <blauwirbel(a)gmail.com> wrote: > On Thu, Apr 19, 2012 at 19:06, Artyom Tarasenko <atar4qemu(a)gmail.com> wrote: >> On Sun, Mar 11, 2012 at 11:59 AM, Blue Swirl <blauwirbel(a)gmail.com> wrote: >>> A change in QEMU on how PCI bridges are setup revealed >>> a bug in OpenBIOS PCI setup. On Sparc64, the BARs just >>> happened to get somewhat correct values by accident before >>> the commit but not after the change. >>> >>> Don't use arch->io_base for PCI I/O port BARs. >>> >>> Fix Sparc64 PCI memory base. >> >> Could it be that the ranges property needs to be adjusted to look as >> it did before the patch? >> >> This patch breaks HelenOS-0.4.3/sparc boot. But if I modify the ranges >> property to the old value, HelenOS boots. >> >> 0 > cd /pci@1fe,0 ok >> 0 > .properties >> [...] >> ranges -- 54 : 00 00 00 00 00 00 00 00 00 00 00 00 >> 00 00 01 fe 01 00 00 00 00 00 00 00 02 00 00 00 01 00 00 00 00 00 00 >> 00 00 00 00 00 00 00 01 fe 02 00 00 00 00 00 00 00 00 01 00 00 02 00 >> 00 00 00 00 00 00 00 10 00 00 00 00 01 ff 00 00 00 00 00 00 00 00 10 >> 00 00 00 >> >> Not sure about the best formatting. If I reformat it like this: >> >> 00000000 00000000 00000000 000001fe 01000000 00000000 02000000 >> 01000000 00000000 00000000 000001fe 02000000 00000000 00010000 >> 02000000 00000000 00100000 000001ff 00000000 00000000 10000000 >> ^^^^ this one (the third) used to be 0 >> > > On an Ultra-5 this should be > 00000000.00000000.00000000.000001fe.01000000.00000000.01000000. > 01000000.00000000.00000000.000001fe.02000000.00000000.01000000. > 02000000.00000000.00000000.000001ff.00000000.00000001.00000000. > 03000000.00000000.00000000.000001ff.00000000.00000001.00000000 > > http://git.kernel.org/?p=linux/kernel/git/davem/prtconfs.git;a=blob;f=ultra… > > I guess the problem is that the properties are added by finding the > host bridge in the PCI bus (which btw isn't so nice), so we use the > pci_mem_base. Using pci_mem_base = 0 would probably fix the BAR, but > then VGA would get in the way. Probably something more complex is > needed. Hmm. Complicated. What is actually the meaning of this property? Don't we need the values ourselves? If these are just BARs, can't we pass the configuration from qemu? >>> Signed-off-by: Blue Swirl <blauwirbel(a)gmail.com> >>> --- >>> >>> I removed the bridge setup code, it's not really valid for Sparc64 APB >>> bridges anyway and currently no devices exist behind the bridges (but >>> that's where they really should be). >>> >>> Tested Sparc64 and PPC. >>> >>> --- >>> arch/sparc64/openbios.c | 2 +- >>> drivers/pci.c | 11 +++++++++-- >>> 2 files changed, 10 insertions(+), 3 deletions(-) >>> >>> diff --git a/arch/sparc64/openbios.c b/arch/sparc64/openbios.c >>> index ac709fe..ab32a8f 100644 >>> --- a/arch/sparc64/openbios.c >>> +++ b/arch/sparc64/openbios.c >>> @@ -64,7 +64,7 @@ static const struct hwdef hwdefs[] = { >>> .cfg_base = APB_SPECIAL_BASE, >>> .cfg_len = 0x2000000, >>> .host_mem_base = APB_MEM_BASE, >>> - .pci_mem_base = 0, >>> + .pci_mem_base = 0x100000, /* avoid VGA at 0xa0000 */ >>> .mem_len = 0x10000000, >>> .io_base = APB_SPECIAL_BASE + 0x2000000ULL, // PCI Bus I/O space >>> .io_len = 0x10000, >>> diff --git a/drivers/pci.c b/drivers/pci.c >>> index f8c6414..e270a73 100644 >>> --- a/drivers/pci.c >>> +++ b/drivers/pci.c >>> @@ -931,6 +931,7 @@ static void ob_pci_configure_bar(pci_addr addr, >>> pci_config_t *config, >>> >>> if ((*p_omask & 0x0000000f) == 0x4) { >>> /* 64 bits memory mapping */ >>> + PCI_DPRINTF("Skipping 64 bit BARs for %s\n", config->path); >>> return; >>> } >>> >>> @@ -966,11 +967,17 @@ static void ob_pci_configure_bar(pci_addr addr, >>> pci_config_t *config, >>> size = min_align; >>> reloc = (reloc + size -1) & ~(size - 1); >>> if (*io_base == base) { >>> + PCI_DPRINTF("changing io_base from 0x%lx to 0x%x\n", >>> + *io_base, reloc + size); >>> *io_base = reloc + size; >>> - reloc -= arch->io_base; >>> } else { >>> + PCI_DPRINTF("changing mem_base from 0x%lx to 0x%x\n", >>> + *mem_base, reloc + size); >>> *mem_base = reloc + size; >>> } >>> + PCI_DPRINTF("Configuring BARs for %s: reloc 0x%x omask 0x%x " >>> + "io_base 0x%lx mem_base 0x%lx size 0x%x\n", >>> + config->path, reloc, *p_omask, *io_base, *mem_base, size); >>> pci_config_write32(addr, config_addr, reloc | *p_omask); >>> config->assigned[reg] = reloc | *p_omask; >>> } >>> @@ -1260,7 +1267,7 @@ int ob_pci_init(void) >>> mem_base = arch->pci_mem_base; >>> /* I/O ports under 0x400 are used by devices mapped at fixed >>> location. */ >>> - io_base = arch->io_base + 0x400; >>> + io_base = 0x400; >>> >>> bus = 0; >>> >>> -- >>> 1.7.9 >>> >>> -- >>> OpenBIOS http://openbios.org/ >>> Mailinglist: http://lists.openbios.org/mailman/listinfo >>> Free your System - May the Forth be with you >> >> >> >> -- >> Regards, >> Artyom Tarasenko >> >> solaris/sparc under qemu blog: http://tyom.blogspot.com/search/label/qemu >> >> -- >> OpenBIOS http://openbios.org/ >> Mailinglist: http://lists.openbios.org/mailman/listinfo >> Free your System - May the Forth be with you > > -- > OpenBIOS http://openbios.org/ > Mailinglist: http://lists.openbios.org/mailman/listinfo > Free your System - May the Forth be with you -- Regards, Artyom Tarasenko solaris/sparc under qemu blog: http://tyom.blogspot.com/search/label/qemu

8 years, 12 months

Re: [OpenBIOS] [PATCH] pci: fix BAR setup

by Blue Swirl

On Thu, Apr 19, 2012 at 19:06, Artyom Tarasenko <atar4qemu(a)gmail.com> wrote: > On Sun, Mar 11, 2012 at 11:59 AM, Blue Swirl <blauwirbel(a)gmail.com> wrote: >> A change in QEMU on how PCI bridges are setup revealed >> a bug in OpenBIOS PCI setup. On Sparc64, the BARs just >> happened to get somewhat correct values by accident before >> the commit but not after the change. >> >> Don't use arch->io_base for PCI I/O port BARs. >> >> Fix Sparc64 PCI memory base. > > Could it be that the ranges property needs to be adjusted to look as > it did before the patch? > > This patch breaks HelenOS-0.4.3/sparc boot. But if I modify the ranges > property to the old value, HelenOS boots. > > 0 > cd /pci@1fe,0 ok > 0 > .properties > [...] > ranges -- 54 : 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 01 fe 01 00 00 00 00 00 00 00 02 00 00 00 01 00 00 00 00 00 00 > 00 00 00 00 00 00 00 01 fe 02 00 00 00 00 00 00 00 00 01 00 00 02 00 > 00 00 00 00 00 00 00 10 00 00 00 00 01 ff 00 00 00 00 00 00 00 00 10 > 00 00 00 > > Not sure about the best formatting. If I reformat it like this: > > 00000000 00000000 00000000 000001fe 01000000 00000000 02000000 > 01000000 00000000 00000000 000001fe 02000000 00000000 00010000 > 02000000 00000000 00100000 000001ff 00000000 00000000 10000000 > ^^^^ this one (the third) used to be 0 > On an Ultra-5 this should be 00000000.00000000.00000000.000001fe.01000000.00000000.01000000. 01000000.00000000.00000000.000001fe.02000000.00000000.01000000. 02000000.00000000.00000000.000001ff.00000000.00000001.00000000. 03000000.00000000.00000000.000001ff.00000000.00000001.00000000 http://git.kernel.org/?p=linux/kernel/git/davem/prtconfs.git;a=blob;f=ultra… I guess the problem is that the properties are added by finding the host bridge in the PCI bus (which btw isn't so nice), so we use the pci_mem_base. Using pci_mem_base = 0 would probably fix the BAR, but then VGA would get in the way. Probably something more complex is needed. >> Signed-off-by: Blue Swirl <blauwirbel(a)gmail.com> >> --- >> >> I removed the bridge setup code, it's not really valid for Sparc64 APB >> bridges anyway and currently no devices exist behind the bridges (but >> that's where they really should be). >> >> Tested Sparc64 and PPC. >> >> --- >> arch/sparc64/openbios.c | 2 +- >> drivers/pci.c | 11 +++++++++-- >> 2 files changed, 10 insertions(+), 3 deletions(-) >> >> diff --git a/arch/sparc64/openbios.c b/arch/sparc64/openbios.c >> index ac709fe..ab32a8f 100644 >> --- a/arch/sparc64/openbios.c >> +++ b/arch/sparc64/openbios.c >> @@ -64,7 +64,7 @@ static const struct hwdef hwdefs[] = { >> .cfg_base = APB_SPECIAL_BASE, >> .cfg_len = 0x2000000, >> .host_mem_base = APB_MEM_BASE, >> - .pci_mem_base = 0, >> + .pci_mem_base = 0x100000, /* avoid VGA at 0xa0000 */ >> .mem_len = 0x10000000, >> .io_base = APB_SPECIAL_BASE + 0x2000000ULL, // PCI Bus I/O space >> .io_len = 0x10000, >> diff --git a/drivers/pci.c b/drivers/pci.c >> index f8c6414..e270a73 100644 >> --- a/drivers/pci.c >> +++ b/drivers/pci.c >> @@ -931,6 +931,7 @@ static void ob_pci_configure_bar(pci_addr addr, >> pci_config_t *config, >> >> if ((*p_omask & 0x0000000f) == 0x4) { >> /* 64 bits memory mapping */ >> + PCI_DPRINTF("Skipping 64 bit BARs for %s\n", config->path); >> return; >> } >> >> @@ -966,11 +967,17 @@ static void ob_pci_configure_bar(pci_addr addr, >> pci_config_t *config, >> size = min_align; >> reloc = (reloc + size -1) & ~(size - 1); >> if (*io_base == base) { >> + PCI_DPRINTF("changing io_base from 0x%lx to 0x%x\n", >> + *io_base, reloc + size); >> *io_base = reloc + size; >> - reloc -= arch->io_base; >> } else { >> + PCI_DPRINTF("changing mem_base from 0x%lx to 0x%x\n", >> + *mem_base, reloc + size); >> *mem_base = reloc + size; >> } >> + PCI_DPRINTF("Configuring BARs for %s: reloc 0x%x omask 0x%x " >> + "io_base 0x%lx mem_base 0x%lx size 0x%x\n", >> + config->path, reloc, *p_omask, *io_base, *mem_base, size); >> pci_config_write32(addr, config_addr, reloc | *p_omask); >> config->assigned[reg] = reloc | *p_omask; >> } >> @@ -1260,7 +1267,7 @@ int ob_pci_init(void) >> mem_base = arch->pci_mem_base; >> /* I/O ports under 0x400 are used by devices mapped at fixed >> location. */ >> - io_base = arch->io_base + 0x400; >> + io_base = 0x400; >> >> bus = 0; >> >> -- >> 1.7.9 >> >> -- >> OpenBIOS http://openbios.org/ >> Mailinglist: http://lists.openbios.org/mailman/listinfo >> Free your System - May the Forth be with you > > > > -- > Regards, > Artyom Tarasenko > > solaris/sparc under qemu blog: http://tyom.blogspot.com/search/label/qemu > > -- > OpenBIOS http://openbios.org/ > Mailinglist: http://lists.openbios.org/mailman/listinfo > Free your System - May the Forth be with you

8 years, 12 months

Re: [OpenBIOS] [PATCH] pci: fix BAR setup

by Artyom Tarasenko

On Sun, Mar 11, 2012 at 11:59 AM, Blue Swirl <blauwirbel(a)gmail.com> wrote: > A change in QEMU on how PCI bridges are setup revealed > a bug in OpenBIOS PCI setup. On Sparc64, the BARs just > happened to get somewhat correct values by accident before > the commit but not after the change. > > Don't use arch->io_base for PCI I/O port BARs. > > Fix Sparc64 PCI memory base. Could it be that the ranges property needs to be adjusted to look as it did before the patch? This patch breaks HelenOS-0.4.3/sparc boot. But if I modify the ranges property to the old value, HelenOS boots. 0 > cd /pci@1fe,0 ok 0 > .properties [...] ranges -- 54 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 fe 01 00 00 00 00 00 00 00 02 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 01 fe 02 00 00 00 00 00 00 00 00 01 00 00 02 00 00 00 00 00 00 00 00 10 00 00 00 00 01 ff 00 00 00 00 00 00 00 00 10 00 00 00 Not sure about the best formatting. If I reformat it like this: 00000000 00000000 00000000 000001fe 01000000 00000000 02000000 01000000 00000000 00000000 000001fe 02000000 00000000 00010000 02000000 00000000 00100000 000001ff 00000000 00000000 10000000 ^^^^ this one (the third) used to be 0 > Signed-off-by: Blue Swirl <blauwirbel(a)gmail.com> > --- > > I removed the bridge setup code, it's not really valid for Sparc64 APB > bridges anyway and currently no devices exist behind the bridges (but > that's where they really should be). > > Tested Sparc64 and PPC. > > --- > arch/sparc64/openbios.c | 2 +- > drivers/pci.c | 11 +++++++++-- > 2 files changed, 10 insertions(+), 3 deletions(-) > > diff --git a/arch/sparc64/openbios.c b/arch/sparc64/openbios.c > index ac709fe..ab32a8f 100644 > --- a/arch/sparc64/openbios.c > +++ b/arch/sparc64/openbios.c > @@ -64,7 +64,7 @@ static const struct hwdef hwdefs[] = { > .cfg_base = APB_SPECIAL_BASE, > .cfg_len = 0x2000000, > .host_mem_base = APB_MEM_BASE, > - .pci_mem_base = 0, > + .pci_mem_base = 0x100000, /* avoid VGA at 0xa0000 */ > .mem_len = 0x10000000, > .io_base = APB_SPECIAL_BASE + 0x2000000ULL, // PCI Bus I/O space > .io_len = 0x10000, > diff --git a/drivers/pci.c b/drivers/pci.c > index f8c6414..e270a73 100644 > --- a/drivers/pci.c > +++ b/drivers/pci.c > @@ -931,6 +931,7 @@ static void ob_pci_configure_bar(pci_addr addr, > pci_config_t *config, > > if ((*p_omask & 0x0000000f) == 0x4) { > /* 64 bits memory mapping */ > + PCI_DPRINTF("Skipping 64 bit BARs for %s\n", config->path); > return; > } > > @@ -966,11 +967,17 @@ static void ob_pci_configure_bar(pci_addr addr, > pci_config_t *config, > size = min_align; > reloc = (reloc + size -1) & ~(size - 1); > if (*io_base == base) { > + PCI_DPRINTF("changing io_base from 0x%lx to 0x%x\n", > + *io_base, reloc + size); > *io_base = reloc + size; > - reloc -= arch->io_base; > } else { > + PCI_DPRINTF("changing mem_base from 0x%lx to 0x%x\n", > + *mem_base, reloc + size); > *mem_base = reloc + size; > } > + PCI_DPRINTF("Configuring BARs for %s: reloc 0x%x omask 0x%x " > + "io_base 0x%lx mem_base 0x%lx size 0x%x\n", > + config->path, reloc, *p_omask, *io_base, *mem_base, size); > pci_config_write32(addr, config_addr, reloc | *p_omask); > config->assigned[reg] = reloc | *p_omask; > } > @@ -1260,7 +1267,7 @@ int ob_pci_init(void) > mem_base = arch->pci_mem_base; > /* I/O ports under 0x400 are used by devices mapped at fixed > location. */ > - io_base = arch->io_base + 0x400; > + io_base = 0x400; > > bus = 0; > > -- > 1.7.9 > > -- > OpenBIOS http://openbios.org/ > Mailinglist: http://lists.openbios.org/mailman/listinfo > Free your System - May the Forth be with you -- Regards, Artyom Tarasenko solaris/sparc under qemu blog: http://tyom.blogspot.com/search/label/qemu

9 years

Re : [PATCH 0/8] RFC: OFMEM cleanup/memory reduction patch

by Olivier DANET

On 4/14/12, Artyom Tarasenko wrote: >Maybe you can tell whether this project uses SMP, or boots something-non Linux? >Of course if it's not top secret. I'm asking because I suspect qemu >and OpenBIOS have problems in these areas. Would be interesting to >know what are the field results. Sorry, nothing in that area for now. There is a lot of work remaining and no shortage of cool ideas !

9 years

Re : [PATCH 0/8] RFC: OFMEM cleanup/memory reduction patch

by Olivier DANET

>Interesting, can you tell more about this project? Did you also modify >QEMU to emulate the HW setup? The project is currently in stealth mode, so I can't give any details for now. >We should try to isolate the dependencies for QEMU, even if QEMU is >probably the most interesting use case for OpenBIOS these days. Could >you tell more about those bugs and even better, publish your changes? A few issues : - arch/sparc32/wuf.S : WIM register updates must not be immediately followed by instructions depending on WIM value (SparcV8, §B.29, page 133) : wr %twin_tmp1, 0x0, %wim /* Make window 'I' invalid */ + nop + nop + nop restore %g0, %g0, %g0 /* Restore to window 'O' */ - arc/sparc32/entry.S : The FP (frame ptr) register is never initialised. Registers are not initialized after a RESET (SparcV8, page 75). - arch/sparc32/entry.S : MMU activation is written as : set highmem, %g2 set 1, %g1 jmp %g2 sta %g1, [%g0] ASI_M_MMUREGS ! enable mmu It doesn't work because there is no precise synchronisation between MMU registers updates and instruction fetches (because of pipelining) MMU activation must be done in a area where virtual and physical adresses are equal ( VA=FF00_0000 --> PA=F_FF00_0000 ). The intial page table is modified to add this mapping and the activation sequence is : - jump from 0_ to F_something (PROM boot mode) - activate the MMU - plenty of NOPs - jump to "highmem" I also eventually disassembled Sun ROMs, and found sequences like that : sta %l1,[%l0],4 iflush nop nop nop nop nop I can post patches, but they won't change anything to QEMU (at best). The currently used version of OpenBIOS isn't the latest (SVN 1046), I may need to do some cleanup. (...and sorry for the previous message's bad formatting)

9 years

Re : [PATCH 0/8] RFC: OFMEM cleanup/memory reduction patch

by Olivier DANET

> The problem is currently OpenBIOS won't work on a bare metal, since > it's tightly coupled with qemu. So, PROM size at this point is a > purely academical question. I'm involved in a project where OpenBIOS for Sparc32 is actually used on bare metal (in a FPGA). OpenBIOS is installed in a 16MB NOR FLASH. There are a few QEMU dependencies and some small issues which don't appear in QEMU (for example, the MMU activation sequence does not work IRL, there is a small bug in wuf.S ...). Regards, and thank you all for your hard work ! Olivier

9 years