OpenBIOS April 2012

openbios@openbios.org

16 participants
40 discussions

Re: [OpenBIOS] [PATCH 0/8] RFC: OFMEM cleanup/memory reduction patch
by Mark Cave-Ayland 10 Apr '12

10 Apr '12

On 07/04/12 12:09, Blue Swirl wrote: >> 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. > > Patches look OK. Coding style could be adjusted while moving the code > and 'extern' is not useful in C for function prototypes. Okay great :) I know you've mentioned the extern in the past, however I'd like to focus on making the API more consistent first and then do a prototype clear-up once all of that is in place. >> 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. > > At least FSYS_BUF in grubfs could be dynamically allocated and/or > shrunk, maybe some others also from this list: > $ nm --size --size-sort obj-sparc64/openbios-builtin.elf.nostrip | > egrep -v ' [tTrR] ' | tail > 0000000000000100 b dp2.1303 > 0000000000000100 b file_descriptors > 0000000000000100 b obio_cmdline > 0000000000000118 d main_ctx > 0000000000001000 B dstack > 0000000000001000 B rstack > 0000000000004000 b image_stack > 0000000000008000 B FSYS_BUF > 0000000000080000 d forth_dictionary > 00000000000c0000 b s_ofmem_data > > It wouldn't help here, but sections .text and .rodata could be merged, > GCC already assumes that .text is readable. This would save one TLB > entry since combined size is still< 512k. With my patchset applied, SPARC64 now looks like this: $ nm --size --size-sort obj-sparc64/openbios-builtin.elf.nostrip | egrep -v ' [tTrR] ' | tail 0000000000000100 b dp2.1302 0000000000000100 b file_descriptors 0000000000000100 b obio_cmdline 0000000000000118 d main_ctx 0000000000001000 B dstack 0000000000001000 B rstack 0000000000004000 b image_stack 0000000000008000 B FSYS_BUF 0000000000020000 b s_ofmem_data 0000000000080000 d forth_dictionary So by reducing s_ofmem_data, the main component is now the size of the Forth dictionary. Hmmm I've had an idea though - we could compress the dictionary, and then decompress/relocate into another set of OFMEM-allocated memory in a similar way so that the entire dictionary doesn't have to be part of the image. For example: $ ls -l obj-sparc64/openbios-sparc64.dict -rw-r--r-- 1 build build 181560 Apr 10 15:08 obj-sparc64/openbios-sparc64.dict Now we need to allocate 512K in total within the image in order to allow for new entries created by bootloaders etc. If we compress the image aswell, e.g. using gzip: $ ls -l obj-sparc64/openbios-sparc64.dict.gz -rw-r--r-- 1 build build 37933 Apr 10 15:08 obj-sparc64/openbios-sparc64.dict.gz Then we can dramatically reduce the dictionary usage within the file too. I wonder if we could incorporate a simple decompressor based upon something like pdlzip (http://lzip.nongnu.org/pdlzip.html) to perform LZMA decompression/relocation on the dictionary early within the startup process? ATB, Mark.

2 2

OT: Brooktree IC used in cg3 graphics framebuffer?
by Mark Cave-Ayland 10 Apr '12

10 Apr '12

Hi all, A slightly off-topic question, however there may be some people on the list who will know the answer to this: what was the number of the Brooktree IC used on the cg3 framebuffer? According to various sources, it looks like the BT458 was used on the cg6 - is this the same as the cg3? ATB, Mark.

1 0

Re: [OpenBIOS] sun4u interrupt-map
by Tarl Neustaedter 09 Apr '12

09 Apr '12

On 2012-Apr-5 17:37 , Artyom Tarasenko wrote: > I gave the following shot: > > 0> show-devs > ffe1a2b0 / > ( ... ) > ffe29140 /pci@1fe,0 (pci) > ffe299a8 /pci@1fe,0/pci@1 (pci) > ffe2a060 /pci@1fe,0/pci@1,1 (pci) > ffe2aeb8 /pci@1fe,0/ebus@3 > ffe2bb00 /pci@1fe,0/ebus@3/su@0,1 (serial) > ( ... ) > > ok > cd /pci@1fe,0/ebus > 000001fe encode-int 020003f8 encode-int encode+ 1 encode-int encode+ > ffe29140 encode-int encode+ 2b encode-int encode+ " interrupt-map" property > > 0000001f encode-int 00ffffff encode-int encode+ 00000003 encode-int encode+ > " interrupt-map-mask" property > > cd /pci@1fe,0/ebus@3/su > 1 encode-int " interrupts" property > device-end > > And Linux's of_device_64 interprets it the following way: > > /pci@1f,0: direct translate 7f0 --> 1 > /pci@1f,0: direct translate 7ee --> 1 > /pci@1f,0: direct translate 7ef --> 1 > /pci@1f,0: direct translate 7e5 --> 1 > > ^^^^^ This is strange but is the same regardless my interrupt-map try above. > > /pci@1f,0/ebus@3/su@1fe,20003f8: Apply [/pci@1f,0/ebus@3:1] imap --> [NULL:1] > > ^^^^^ Have I done something wrong, or more interrupt mappings is needed? Well, it looks like Linux is correctly identifying that you want to translate interrupt 1 from ebus to something else. That something else is where it's getting hung up - what are your #address-cells and #interrupt-cells? Although I don't think you're using the right numbers.... It looks like you set up a property containing: 1fe, 200.03f8, 1, ffe2.9140, 2b The two cells at the front look wrong. I think you want the contents of the reg property of the su node, and I'm pretty sure that doesn't have "1fe". I recall ebus only has a one-cell address property, in which case that should be: 20003f8, 1, ffe2.9140, 2b The interrupt mask property should probably be 00ff.ffff, ff .

2 1

Re: [OpenBIOS] sun4u interrupt-map
by Tarl Neustaedter 05 Apr '12

05 Apr '12

On 2012-Apr-4 18:15 , Artyom Tarasenko wrote: >> > Evidently on the Ultra-5, we aren't using three cells to identify the child, >> > only two. So we probably skip child.mid in both of the above specifications. > And what are child.hi and child.lo? Is it the physical address, stored > in the reg property? Yes. It's bus-binding specific. I don't remember what the parent bus of the PCI node was on an Ultra-5, but presumably <3c,0> indicates the PCI root complex. It should be from the reg property of that same PCI node. > But then the filter (address& 0x3e) == 0x3c can potentially hit > really a lot of devices? In this case, the mask of 0x3e (0011.1110) presumably indicates there are only five meaningful bits in the child address that should be used for comparison. Interestingly, by having a zero in the intrspec field, presumably it only allows one interrupt (zero) to be mapped in this case.

2 1

[PATCH] Support any build directory
by Kristen Eisenberg 05 Apr '12

05 Apr '12

On Sat, Sep 3, 2011 at 10:58 AM, Andreas Färber <andreas.faerber at web.de> wrote: > 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. Kristen Eisenberg Billige Flüge Marketing GmbH Emanuelstr. 3, 10317 Berlin Deutschland Telefon: +49 (33) 5310967 Email: utebachmeier at gmail.com Site: http://flug.airego.de - Billige Flüge vergleichen

1 0

Re: [OpenBIOS] sun4u interrupt-map
by Tarl Neustaedter 05 Apr '12

05 Apr '12

On 2012-Apr-4 13:30 , Artyom Tarasenko wrote: > Could it be that OpenBIOS is missing interrupt-map and > interrupt-map-mask properties for the PCI bus? > > On a real Ultra-5 it looks like this: > interrupt-map 0000003c 00000000 00000000 f005fa24 80000033 > interrupt-map-mask 0000003e 00000000 00000000 > > What is mapped to what? > > I couldn't find any documentation how these properties work, except > for Linux and OpenSolaris sources. Thought I ask here before trying to > reconstruct the picture from them. These are documented at least as far back as the Safari binding, in section 5.2.1.4 (assuming that spec got published). They are used to route interrupts differently than the data interconnects for devices - specifically, when hardware has taken the interrupt pins from a device and brought them in to the CPU through a path which bypasses all the intervening bridges. The specification for interrupt-map is: child.hi child.mid child.lo child.intrspec intr-parent.phandle intr-parent.intrspec Basically, it defines the child, the child's interrupt then points to the parent where the interrupt appears and what interrupt it appears as. In the above Ultra-5 spec, it looks like the first three cells are defining the child (3c?), and the interrupt from that child (presumably zero), saying that this interrupt appears under node f005fa24 as interrupt 33. The interrupt-map-mask is simply a mask applied to the child information it's defined as child.hi child.mid child.lo child.intrspec Evidently on the Ultra-5, we aren't using three cells to identify the child, only two. So we probably skip child.mid in both of the above specifications.

3 2

Re: [OpenBIOS] sun4u interrupt-map
by Blue Swirl 04 Apr '12

04 Apr '12

On Wed, Apr 4, 2012 at 20:15, Artyom Tarasenko <atar4qemu(a)gmail.com> wrote: > On Wed, Apr 4, 2012 at 9:58 PM, Blue Swirl <blauwirbel(a)gmail.com> wrote: >> On Wed, Apr 4, 2012 at 17:59, Tarl Neustaedter <tarl-b2(a)tarl.net> wrote: >>> On 2012-Apr-4 13:30 , Artyom Tarasenko wrote: >>>> >>>> Could it be that OpenBIOS is missing interrupt-map and >>>> interrupt-map-mask properties for the PCI bus? >>>> >>>> On a real Ultra-5 it looks like this: >>>> interrupt-map 0000003c 00000000 00000000 f005fa24 80000033 >>>> interrupt-map-mask 0000003e 00000000 00000000 >>>> >>>> What is mapped to what? >>>> >>>> I couldn't find any documentation how these properties work, except >>>> for Linux and OpenSolaris sources. Thought I ask here before trying to >>>> reconstruct the picture from them. >>> >>> >>> These are documented at least as far back as the Safari binding, in section >>> 5.2.1.4 (assuming that spec got published). They are used to route >>> interrupts differently than the data interconnects for devices - >>> specifically, when hardware has taken the interrupt pins from a device and >>> brought them in to the CPU through a path which bypasses all the intervening >>> bridges. The specification for interrupt-map is: >>> >>> child.hi child.mid child.lo child.intrspec intr-parent.phandle >>> intr-parent.intrspec >>> >>> Basically, it defines the child, the child's interrupt then points to the >>> parent where the interrupt appears and what interrupt it appears as. In the >>> above Ultra-5 spec, it looks like the first three cells are defining the >>> child (3c?), and the interrupt from that child (presumably zero), saying >>> that this interrupt appears under node f005fa24 as interrupt 33. > > So, basically, without these properties, software would have no way to > tell what CPU interrupt is pulled when the device irq becomes active, > right? > >>> The interrupt-map-mask is simply a mask applied to the child information >>> it's defined as >>> >>> child.hi child.mid child.lo child.intrspec >>> >>> Evidently on the Ultra-5, we aren't using three cells to identify the child, >>> only two. So we probably skip child.mid in both of the above specifications. >> >> Nice explanation. I read the Open Firmware draft interrupt mapping >> document (http://www.openfirmware.org/1275/practice/imap/imap0_9d.pdf), >> but I was more confused after reading it than before. > > Hm. Since it's a part of a standard specification, the other machines > (i.e. PPC) might need these properties as well? Probably. There used to be PPC OF device tree dumps in this site but it's no longer there: http://penguinppc.org/historical/dev-trees-html/ > > Artyom > > -- > 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

1 0

Re: [OpenBIOS] sun4u interrupt-map
by Tarl Neustaedter 04 Apr '12

04 Apr '12

On 2012-Apr-4 16:15 , Artyom Tarasenko wrote: > So, basically, without these properties, software would have no way to > tell what CPU interrupt is pulled when the device irq becomes active, > right? That's correct. The normal, default, cases work fine - where the interrupts are routed along the same paths as the data. These properties let us work around the cases where hardware engineers decided to wire things differently. >> >> > >> > Nice explanation. I read the Open Firmware draft interrupt mapping >> > document (http://www.openfirmware.org/1275/practice/imap/imap0_9d.pdf), >> > but I was more confused after reading it than before. > Hm. Since it's a part of a standard specification, the other machines > (i.e. PPC) might need these properties as well? Only if they have hardware where interrupts are routed in strange ways. This originally came about when we wanted separate interrupts for a bunch of small devices which were all connected through the same bridge - and normal behaviour would have muxed several of these interrupts onto overlapping A/B/C/D interrupt lines. By routing the interrupts directly into pins giving us unique interrupts, we avoided having OS software having to poll each of several devices on every interrupt. Note that these interrupt properties aren't actually used by Openboot - they're just passed along to make life easier on Solaris (and other clients).

1 0

Re: [OpenBIOS] sun4u interrupt-map
by Artyom Tarasenko 04 Apr '12

04 Apr '12

On Wed, Apr 4, 2012 at 9:58 PM, Blue Swirl <blauwirbel(a)gmail.com> wrote: > On Wed, Apr 4, 2012 at 17:59, Tarl Neustaedter <tarl-b2(a)tarl.net> wrote: >> On 2012-Apr-4 13:30 , Artyom Tarasenko wrote: >>> >>> Could it be that OpenBIOS is missing interrupt-map and >>> interrupt-map-mask properties for the PCI bus? >>> >>> On a real Ultra-5 it looks like this: >>> interrupt-map 0000003c 00000000 00000000 f005fa24 80000033 >>> interrupt-map-mask 0000003e 00000000 00000000 >>> >>> What is mapped to what? >>> >>> I couldn't find any documentation how these properties work, except >>> for Linux and OpenSolaris sources. Thought I ask here before trying to >>> reconstruct the picture from them. >> >> >> These are documented at least as far back as the Safari binding, in section >> 5.2.1.4 (assuming that spec got published). They are used to route >> interrupts differently than the data interconnects for devices - >> specifically, when hardware has taken the interrupt pins from a device and >> brought them in to the CPU through a path which bypasses all the intervening >> bridges. The specification for interrupt-map is: >> >> child.hi child.mid child.lo child.intrspec intr-parent.phandle >> intr-parent.intrspec >> >> Basically, it defines the child, the child's interrupt then points to the >> parent where the interrupt appears and what interrupt it appears as. In the >> above Ultra-5 spec, it looks like the first three cells are defining the >> child (3c?), and the interrupt from that child (presumably zero), saying >> that this interrupt appears under node f005fa24 as interrupt 33. So, basically, without these properties, software would have no way to tell what CPU interrupt is pulled when the device irq becomes active, right? >> The interrupt-map-mask is simply a mask applied to the child information >> it's defined as >> >> child.hi child.mid child.lo child.intrspec >> >> Evidently on the Ultra-5, we aren't using three cells to identify the child, >> only two. So we probably skip child.mid in both of the above specifications. > > Nice explanation. I read the Open Firmware draft interrupt mapping > document (http://www.openfirmware.org/1275/practice/imap/imap0_9d.pdf), > but I was more confused after reading it than before. Hm. Since it's a part of a standard specification, the other machines (i.e. PPC) might need these properties as well? Artyom -- Regards, Artyom Tarasenko solaris/sparc under qemu blog: http://tyom.blogspot.com/search/label/qemu

1 0

sun4u interrupt-map
by Artyom Tarasenko 04 Apr '12

04 Apr '12

Could it be that OpenBIOS is missing interrupt-map and interrupt-map-mask properties for the PCI bus? On a real Ultra-5 it looks like this: interrupt-map 0000003c 00000000 00000000 f005fa24 80000033 interrupt-map-mask 0000003e 00000000 00000000 What is mapped to what? I couldn't find any documentation how these properties work, except for Linux and OpenSolaris sources. Thought I ask here before trying to reconstruct the picture from them. Artyom -- Regards, Artyom Tarasenko solaris/sparc under qemu blog: http://tyom.blogspot.com/search/label/qemu

1 0