Hello,
Is there a way to add a new device in the middle of the device tree
(before or after an existing node) from Forth? If I try:
dev / new-device " newdev" device-name finish-device show-devs
/newdev appears at the end of the device-tree but that's not what I want.
I need this device to go at a specific place in the middle but I could not
find out how to achieve that. Any ideas?
Thank you,
BALATON Zoltan
In order to progress further with sun4u in QEMU, it has become necessary
to introduce PCI bridges similar to a real Ultra 5. This is because several
OSs make assumptions about the PCI topology, and without the PCI bridge in
place will either crash or fail to map memory regions correctly.
This first patchset fixes up PCI bridges so that we can now enumerate them
correctly. As an idea as to where I'm going with this, if you also take the
WIP QEMU branch at https://github.com/mcayland/qemu/tree/sparc64-pcibridge
then the output of show-devs looks like this:
Welcome to OpenBIOS v1.1 built on Jun 11 2017 06:57
Type 'help' for detailed information
0 > show-devs
ffe1bf40 /
ffe1c118 /aliases
ffe1c240 /openprom (BootROM)
ffe26b58 /openprom/client-services
ffe1c4f8 /options
ffe1c5d8 /chosen
ffe1c718 /builtin
ffe1c840 /builtin/console
ffe26620 /packages
ffe28648 /packages/cmdline
ffe28898 /packages/disk-label
ffe2c8e0 /packages/deblocker
ffe2cef8 /packages/grubfs-files
ffe2d308 /packages/sun-parts
ffe2d720 /packages/elf-loader
ffe2b218 /memory@0,0 (memory)
ffe2b378 /virtual-memory
ffe2d880 /pci@1fe,0 (pci)
ffe2e1b0 /pci@1fe,0/pci@1 (pci)
ffe2e8c8 /pci@1fe,0/pci@1,1 (pci)
ffe2efb0 /pci@1fe,0/pci@1,1/ebus@1
ffe2f7f0 /pci@1fe,0/pci@1,1/ebus@1/eeprom@0
ffe2f968 /pci@1fe,0/pci@1,1/ebus@1/fdthree@0 (block)
ffe2feb8 /pci@1fe,0/pci@1,1/ebus@1/su@0 (serial)
ffe30248 /pci@1fe,0/pci@1,1/ebus@1/kb_ps2@0 (serial)
ffe305b8 /pci@1fe,0/pci@1,1/QEMU,VGA@2 (display)
ffe31c30 /pci@1fe,0/pci@1,1/pci-ata@3 (pci-ide)
ffe32188 /pci@1fe,0/pci@1,1/pci-ata@3/ide0@4000 (ide)
ffe32468 /pci@1fe,0/pci@1,1/pci-ata@3/ide1@4100 (ide)
ffe32700 /pci@1fe,0/pci@1,1/pci-ata@3/ide1@4100/cdrom@0 (block)
ffe32d88 /pci@1fe,0/NE2000@2 (network)
ffe33490 /SUNW,UltraSPARC-IIi (cpu)
ok
Note I have several more SPARC64-related fixes queued, however as this
patchset is starting to get quite unwieldy it makes sense to split this
part off separately.
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk>
Mark Cave-Ayland (8):
pci: add temporary bus-range property to PCI bridge devices
pci: include PCI bus id in ob_pci_decode_unit()
pci: create new ob_pci_bridge_node based upon ob_pci_bus_node
pci: rename ob_pci_map_in() to ob_pci_bus_map_in()
pci: implement ob_pci_bridge_map_in() for PCI-PCI bridge nodes
pci: configure base and limit registers during PCI bridge
configuration
pci: split PCI bus interrupt maps from PCI host bridge interrupt maps
pci: allow ob_pci_bus_set_interrupt_map() to take a callback function
drivers/pci.c | 186 ++++++++++++++++++++++++++++++++++++++++++++-------------
drivers/pci.h | 5 ++
2 files changed, 150 insertions(+), 41 deletions(-)
--
1.7.10.4
Commit 7130437 "fw_cfg: implement fw-cfg-read-file Forth word" added a binding
for the Forth version of fw_cfg_read_file() into libopenbios/init.c but forgot
to only include the binding when CONFIG_DRIVER_FW_CFG was defined.
This broke the build for platforms which don't have the fw_cfg interface
enabled by default such as x86.
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk>
---
libopenbios/init.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libopenbios/init.c b/libopenbios/init.c
index aa99608..e08df19 100644
--- a/libopenbios/init.c
+++ b/libopenbios/init.c
@@ -28,8 +28,10 @@ openbios_init( void )
PUSH(pointer2cell((void *)&__context));
feval("['] __context cell+ !");
+#if defined(CONFIG_DRIVER_FW_CFG)
// Bind the Forth fw_cfg file interface
bind_func("fw-cfg-read-file", forth_fw_cfg_read_file);
+#endif
// Bind the C implementation of (init-program) into Forth
bind_func("(init-program)", init_program);
--
1.7.10.4
Hi,
The git repository seems alive, so there's someone out there, but the main website hasn't been updated in a while and the list is... quiet.
I'm looking to find out where OpenBIOS is, if it handles large devices (or if I need TianoCore for that, which I'd really not like) and whether the project is still in serious development (good) or is more maintenance mode (proprietary vendors have won).
I'm also curious as to what will boot cleanly. Coreboot only seems to give results for direct payloads and SeaBIOS, and I don't see a list on OpenBIOS' site (but may have missed it), so it's not obvious what works well, what's YMMV and what's in the paperweight category.
If things are semi-active to active, and if I can find a way to program the flash chip when things fail, I'd be happy to do testing.
Jonathan Day