OpenBIOS April 2011

openbios@openbios.org

10 participants
28 discussions

Re: [OpenBIOS] Solaris anyone?
by Nick Couchman 25 Apr '11

25 Apr '11

On Mon, 2011-04-25 at 19:03 +0100, Mark Cave-Ayland wrote: > On 25/04/11 18:10, Nick Couchman wrote: > > > Awesome - seems to work, at least it has picked up a DHCP address! I'm > > going to play with it and see if I can get a few other things (NFS > > client, SSH, etc.) to work correctly! > > Great - let us know how you get on :D > > SSH and NFS are working. I'm going to try to test out one of the applications - an ADA debugger - that we routinely run on the Solaris/Sparc platform to see how that works. Also, just a note - graphical console does not want to start, so I have to start with the -nographic option to boot correctly. This is fine, except that it pretty much precludes running qemu in the background, unless someone wants to give me a hint or two on a background-friendly method of running that doesn't cause the Solaris instance to lock-up. VNC did not work so well. Maybe there's something I could add to the boot prompt to force Solaris into a serial/text-only mode? Did the serial port patch ever get checked off and pushed to SVN? -Nick -------- This e-mail may contain confidential and privileged material for the sole use of the intended recipient. If this email is not intended for you, or you are not responsible for the delivery of this message to the intended recipient, please note that this message may contain SEAKR Engineering (SEAKR) Privileged/Proprietary Information. In such a case, you are strictly prohibited from downloading, photocopying, distributing or otherwise using this message, its contents or attachments in any way. If you have received this message in error, please notify us immediately by replying to this e-mail and delete the message from your mailbox. Information contained in this message that does not relate to the business of SEAKR is neither endorsed by nor attributable to SEAKR.

2 1

Solaris anyone?
by Mark Cave-Ayland 25 Apr '11

25 Apr '11

With my previously posted patched applied: ./qemu-system-sparc -cdrom /home/build/src/qemu/sparcimage/sol8-cd1.iso -boot d -nographic -prom-env 'auto-boot?=false' Configuration device id QEMU version 1 machine id 32 CPUs: 1 x FMI,MB86904 UUID: 00000000-0000-0000-0000-000000000000 Welcome to OpenBIOS v1.0 built on Apr 20 2011 18:52 Type 'help' for detailed information 0 > boot cdrom:d -v Not a bootable ELF image Loading a.out image... Loaded 7680 bytes entry point is 0x4000 bootpath: /iommu/sbus/espdma/esp/sd@2,0:d Jumping to entry point 00004000 for type 00000005... switching to new context: Size: 259040+54154+47486 Bytes SunOS Release 5.8 Version Generic_108528-09 32-bit Copyright 1983-2001 Sun Microsystems, Inc. All rights reserved. Ethernet address = 52:54:0:12:34:56 Using default device instance data vac: enabled in write through mode mem = 131072K (0x8000000) avail mem = 110260224 root nexus = SUNW,SPARCstation-5 iommu0 at root: obio 0x10000000 sbus0 at iommu0: obio 0x10001000 dma0 at sbus0: SBus slot 5 0x8400000 dma0 is /iommu@0,10000000/sbus@0,10001000/espdma@5,8400000 /iommu@0,10000000/sbus@0,10001000/espdma@5,8400000/esp@5,8800000 (esp0): esp-options=0x46 esp0 at dma0: SBus slot 5 0x8800000 sparc ipl 4 esp0 is /iommu@0,10000000/sbus@0,10001000/espdma@5,8400000/esp@5,8800000 sd2 at esp0: target 2 lun 0 sd2 is /iommu@0,10000000/sbus@0,10001000/espdma@5,8400000/esp@5,8800000/sd@2,0 root on /iommu@0,10000000/sbus@0,10001000/espdma@5,8400000/esp@5,8800000/sd@2,0:b fstype ufs obio0 at root obio0 at obio0: obio 0x100000, sparc ipl 12 zs0 is /obio/zs@0,100000 obio1 at obio0: obio 0x0, sparc ipl 12 zs1 is /obio/zs@0,0 cpu0: FMI,MB86904 (mid 0 impl 0x0 ver 0x5 clock 170 MHz) Configuring /dev and /devices pseudo-device: devinfo0 devinfo0 is /pseudo/devinfo@0 tcx0 at sbus0: SBus slot 3 0x800000 and SBus slot 3 0x2000000 and SBus slot 3 0x4000000 and SBus slot 3 0x6000000 and SBus slot 3 0xa000000 and SBus slot 3 0xc000000 and SBus slot 3 0xe000000 and SBus slot 3 0x700000 and SBus slot 3 0x200000 and SBus slot 3 0x300000 and SBus slot 3 0x0 and SBus slot 3 0x240000 and SBus slot 3 0x280000 SBus level 5 sparc ipl 9 tcx0 is /iommu@0,10000000/sbus@0,10001000/SUNW,tcx@3,800000 tcx0: revision 0, screen 1024x768 ledma0 at sbus0: SBus slot 5 0x8400010 le0 at ledma0: SBus slot 5 0x8c00000 sparc ipl 6 le0 is /iommu@0,10000000/sbus@0,10001000/ledma@5,8400010/le@5,8c00000 sbusmem0 at sbus0: SBus slot 0 0x0 sbusmem0 is /iommu@0,10000000/sbus@0,10001000/sbusmem@0,0 sbusmem1 at sbus0: SBus slot 1 0x0 sbusmem1 is /iommu@0,10000000/sbus@0,10001000/sbusmem@1,0 sbusmem2 at sbus0: SBus slot 2 0x0 sbusmem2 is /iommu@0,10000000/sbus@0,10001000/sbusmem@2,0 sbusmem3 at sbus0: SBus slot 3 0x0 sbusmem3 is /iommu@0,10000000/sbus@0,10001000/sbusmem@3,0 sbusmem4 at sbus0: SBus slot 4 0x0 sbusmem4 is /iommu@0,10000000/sbus@0,10001000/sbusmem@4,0 sbusmem5 at sbus0: SBus slot 5 0x0 sbusmem5 is /iommu@0,10000000/sbus@0,10001000/sbusmem@5,0 pseudo-device: winlock0 winlock0 is /pseudo/winlock@0 pseudo-device: llc10 llc10 is /pseudo/llc1@0 pseudo-device: lofi0 lofi0 is /pseudo/lofi@0 pseudo-device: fcp0 fcp0 is /pseudo/fcp@0 Using RPC Bootparams for network configuration information. Skipping interface le0 Searching for configuration file(s)... Select a Language 0. English 1. French 2. German 3. Italian 4. Japanese 5. Korean 6. Simplified Chinese 7. Spanish 8. Swedish 9. Traditional Chinese Please make a choice (0 - 9), or press h or ? for help: Wow. All I can say is thank you so much to everyone who helped me get this far - in particular Blue, Artyom and Tarl. Does anyone know if we are the first non-Sun firmware to be able to boot a Solaris kernel? Blue - I think you owe me that 1.1 release soon! Happy Easter everyone! Mark. -- Mark Cave-Ayland - Senior Technical Architect PostgreSQL - PostGIS Sirius Corporation plc - control through freedom http://www.siriusit.co.uk t: +44 870 608 0063 Sirius Labs: http://www.siriusit.co.uk/labs

2 2

[PATCH] Set properties to disable carrier detection on the serial ports for SPARC32.
by Mark Cave-Ayland 25 Apr '11

25 Apr '11

This prevents the Solaris 8 kernel from freezing during boot after detecting the serial ports. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)siriusit.co.uk> --- openbios-devel/drivers/escc.c | 10 ++++++++++ 1 files changed, 10 insertions(+), 0 deletions(-) diff --git a/openbios-devel/drivers/escc.c b/openbios-devel/drivers/escc.c index ef431b2..892dc8c 100644 --- a/openbios-devel/drivers/escc.c +++ b/openbios-devel/drivers/escc.c @@ -342,6 +342,16 @@ ob_zs_init(phys_addr_t base, uint64_t offset, int intr, int slave, int keyboard) ob_intr(intr); + PUSH(0); + PUSH(0); + push_str("port-a-ignore-cd"); + fword("property"); + + PUSH(0); + PUSH(0); + push_str("port-b-ignore-cd"); + fword("property"); + fword("finish-device"); snprintf(nodebuff, sizeof(nodebuff), "/obio/zs@0,%x", -- 1.7.2.5

3 2

Re: [OpenBIOS] Solaris anyone?
by Nick Couchman 25 Apr '11

25 Apr '11

> Okay - I now have a patch which appears to solve the issue here after > numerous of hours debugging. I'll clean it up and post it to the list in > a few minutes for you to test. > > Awesome - seems to work, at least it has picked up a DHCP address! I'm going to play with it and see if I can get a few other things (NFS client, SSH, etc.) to work correctly! -Nick -------- This e-mail may contain confidential and privileged material for the sole use of the intended recipient. If this email is not intended for you, or you are not responsible for the delivery of this message to the intended recipient, please note that this message may contain SEAKR Engineering (SEAKR) Privileged/Proprietary Information. In such a case, you are strictly prohibited from downloading, photocopying, distributing or otherwise using this message, its contents or attachments in any way. If you have received this message in error, please notify us immediately by replying to this e-mail and delete the message from your mailbox. Information contained in this message that does not relate to the business of SEAKR is neither endorsed by nor attributable to SEAKR.

2 1

[PATCH] Fix up LANCE ethernet DMA mapping under Solaris 8 on SPARC32.
by Mark Cave-Ayland 25 Apr '11

25 Apr '11

It seems that Solaris doesn't set up a DMA mapping for the LANCE DMA buffers and hence must inherit this from OpenBIOS. To make things more complicated, Solaris appears to assume that the buffers are fixed at 0xff000000 rather than detecting this information from the OpenBIOS IOMMU pagetable before switching. Mimicking this behaviour with a fixed location allows Solaris 8 to correctly use the network card under QEMU. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)siriusit.co.uk> --- openbios-devel/drivers/sbus.c | 55 ++++++++++++++++++++++++++++++++++++++-- 1 files changed, 52 insertions(+), 3 deletions(-) diff --git a/openbios-devel/drivers/sbus.c b/openbios-devel/drivers/sbus.c index f4a6d66..1107c1d 100644 --- a/openbios-devel/drivers/sbus.c +++ b/openbios-devel/drivers/sbus.c @@ -29,6 +29,20 @@ #define SS600MP_ESPDMA 0x00081000ULL #define SS600MP_ESP 0x00080000ULL #define SS600MP_LEBUFFER (SS600MP_ESPDMA + 0x10) // XXX should be 0x40000 +#define LEDMA_REGS 0x4 +#define LE_REGS 0x20 + +#ifdef CONFIG_DEBUG_SBUS +#define DPRINTF(fmt, args...) \ + do { printk(fmt , ##args); } while (0) +#else +#define DPRINTF(fmt, args...) +#endif + +typedef struct le_private { + uint32_t *dmaregs; + uint32_t *regs; +} le_private_t; static void ob_sbus_node_init(uint64_t base) @@ -57,8 +71,36 @@ ob_sbus_node_init(uint64_t base) } static void -ob_le_init(unsigned int slot, unsigned long leoffset, unsigned long dmaoffset) +ob_le_init(unsigned int slot, uint64_t base, unsigned long leoffset, unsigned long dmaoffset) { + le_private_t *le; + + le = malloc(sizeof(le_private_t)); + if (!le) { + DPRINTF("Can't allocate LANCE private structure\n"); + return; + } + + /* Get the IO region for DMA registers */ + le->dmaregs = (void *)ofmem_map_io(base + (uint64_t)dmaoffset, LEDMA_REGS); + if (le->dmaregs == NULL) { + DPRINTF("Can't map LANCE DMA registers\n"); + return; + } + + /* Now it appears that the Solaris kernel forgets to set up the LANCE DMA mapping + and so it must inherit the one from OpenBIOS. The symptom of this is that the + LANCE DMA base addr register is still zero, and so we start sending network + packets containing random areas of memory. + + The correct fix for this should be to use dvma_alloc() to grab a section of + memory and point the LANCE DMA buffers to use that instead; this gets + slightly further but still crashes. Time-consuming investigation on various + hacked versions of QEMU seems to indicate that Solaris always assumes the LANCE + DMA base address is fixed 0xff000000 when setting up the IOMMU for the LANCE + card. Hence we imitate this behaviour here. */ + le->dmaregs[3] = 0xff000000; + push_str("/iommu/sbus/ledma"); fword("find-device"); PUSH(slot); @@ -72,6 +114,13 @@ ob_le_init(unsigned int slot, unsigned long leoffset, unsigned long dmaoffset) push_str("reg"); fword("property"); + /* Get the IO region for Lance registers */ + le->regs = (void *)ofmem_map_io(base + (uint64_t)leoffset, LE_REGS); + if (le->regs == NULL) { + DPRINTF("Can't map LANCE registers\n"); + return; + } + push_str("/iommu/sbus/ledma/le"); fword("find-device"); PUSH(slot); @@ -371,7 +420,7 @@ ob_macio_init(unsigned int slot, uint64_t base, unsigned long offset) #endif // NCR 92C990, Am7990, Lance. See http://www.amd.com - ob_le_init(slot, offset + 0x00c00000, offset + 0x00400010); + ob_le_init(slot, base, offset + 0x00c00000, offset + 0x00400010); // Parallel port //ob_bpp_init(base); @@ -430,7 +479,7 @@ sbus_probe_slot_ss600mp(unsigned int slot, uint64_t base) ob_esp_init(slot, base, SS600MP_ESP, SS600MP_ESPDMA); #endif // NCR 92C990, Am7990, Lance. See http://www.amd.com - ob_le_init(slot, 0x00060000, SS600MP_LEBUFFER); + ob_le_init(slot, base, 0x00060000, SS600MP_LEBUFFER); // Power management (APC) XXX should not exist ob_apc_init(slot, APC_OFFSET); break; -- 1.7.2.5

1 0

Re: [OpenBIOS] Solaris anyone?
by Nick Couchman 25 Apr '11

25 Apr '11

> Awesome! If you can make a note of what you had to do in order to get it > to work and post it to the list, I'm sure lots of people will be very > grateful :) > Okay, so, if you set up, for example, an LVM disk that's 10G in size on Linux, and you do an "fdisk -l" on the LVM volume, you see the following: linux:~ # fdisk -l /dev/local/Solaris8 Disk /dev/local/Solaris8: 10.7 GB, 10737418240 bytes 255 heads, 63 sectors/track, 1305 cylinders, total 20971520 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00000000 Disk /dev/local/Solaris8 doesn't contain a valid partition table This shows C/H/S parameters of 1305/255/63. Seems reasonable enough, so, we boot the install disk in single user mode (boot cdrom:d -s) and use the format command to configure the disk with these settings. (Note: Solaris 9 accepts the heads value of 255 - Solaris 8 seems to choke on even this.) After format is finished configuring the disk, we use the "newfs /dev/rdsk/c0t0d0s0" command to try to create a new filesystem, and we get this: # newfs /dev/rdsk/c0t0d0s0 newfs: construct a new file system /dev/rdsk/c0t0d0s0: (y/n)? y With a block size of 8192 minimum bytes per inode is 5884 Minimum bytes per inode is 5884 With 16065 sectors per cylinder, minimum cylinders per group is 16 This requires the fragment size to be changed from 1024 to 4096 Please re-run mkfs with corrected parameters So, apparently there's some limitation on the C/H/S parameters and how those interact with the UFS volume you're trying to create. Obviously one solution is to run mkfs with the suggested fragment size change; however, this is hard to do during the install, and the installer isn't very forgiving about letter you tweak things and continue on with the install. So, what I did is recalculate the C/H/S parameters to reduce the Heads value and increase the Cylinders value. I stuck with the 63 sectors/track number and just recalculated the Cylinders and Heads value. So, if you multiply 1305 * 255, you get 332775. You can then reduce one of the numbers to something more sane - I, for example, reduced Heads to 16, then divide that into 332775 = 20798 (rounded down), which is your new Cylinders value. Reconfigure the disk in format with these new parameters (don't forget to label!), then use newfs, again: # newfs /dev/rdsk/c0t0d0s0 newfs: construct a new file system /dev/rdsk/c0t0d0s0: (y/n)? y /dev/rdsk/c0t0d0s0: 263088 sectors in 261 cylinders of 16 tracks, 63 sectors 128.5MB in 17 cyl groups (16 c/g, 7.88MB/g, 3776 i/g) super-block backups (for fsck -F ufs -o b=#) at: 32, 16224, 32416, 48608, 64800, 80992, 97184, 113376, 129568, 145760, 161952, 178144, 194336, 210528, 226720, 242912, 258080, Success! Now we can actually go through the installer and it will partition and format correctly during the install process! Let me know if anything looks amiss with my calculations - I haven't done any extensive testing to verify that the C/H/S values work at the disk boundaries. -Nick -------- This e-mail may contain confidential and privileged material for the sole use of the intended recipient. If this email is not intended for you, or you are not responsible for the delivery of this message to the intended recipient, please note that this message may contain SEAKR Engineering (SEAKR) Privileged/Proprietary Information. In such a case, you are strictly prohibited from downloading, photocopying, distributing or otherwise using this message, its contents or attachments in any way. If you have received this message in error, please notify us immediately by replying to this e-mail and delete the message from your mailbox. Information contained in this message that does not relate to the business of SEAKR is neither endorsed by nor attributable to SEAKR.

1 0

Re: [OpenBIOS] Solaris anyone?
by Nick Couchman 25 Apr '11

25 Apr '11

> Awesome! If you can make a note of what you had to do in order to get it > to work and post it to the list, I'm sure lots of people will be very > grateful :) I'll go back through and try to reproduce the issues and document how I worked around it. > > Okay - I missed this as when I was stepping through the installer I > didn't bother with any of the networking stuff. However there is > definitely a bug here - running tcpdump on the bridge interface shows > data packets with junk in them rather than a proper DHCP request, so I'm > wondering if OpenBIOS doesn't initialise something in the NIC correctly? > Or maybe it's another alignment issue with the the LANCE buffers? > > Anyway, I'll take a look but it may take me a little time to figure out > what's going on. Let me know if I can provide any further information. Sounds like you've reproduced the issue, but if I can provide any additional help, I'm happy to do so. -Nick -------- This e-mail may contain confidential and privileged material for the sole use of the intended recipient. If this email is not intended for you, or you are not responsible for the delivery of this message to the intended recipient, please note that this message may contain SEAKR Engineering (SEAKR) Privileged/Proprietary Information. In such a case, you are strictly prohibited from downloading, photocopying, distributing or otherwise using this message, its contents or attachments in any way. If you have received this message in error, please notify us immediately by replying to this e-mail and delete the message from your mailbox. Information contained in this message that does not relate to the business of SEAKR is neither endorsed by nor attributable to SEAKR.

2 1

Re: [OpenBIOS] Solaris anyone?
by Nick Couchman 23 Apr '11

23 Apr '11

On Sat, 2011-04-23 at 14:55 +0100, Mark Cave-Ayland wrote: > On 22/04/11 20:58, Nick Couchman wrote: > > > Thanks, again, Mark - this is fantastic! > > > > After booting the install successfully from the Solaris ISO/CDROM and > > getting through the initial configuration (on both Solaris 8 and 9), the > > install fails trying to label the hard drive. First, I see the > > following during the installer boot: > > > > WARNING: /iommu@0,10000000/sbus@0,10001000/espdma@5,8400000/esp@5,8800000/sd@0,0 (sd0): > > corrupt label - wrong magic number > > > > > > Then, after doing the system identification, I get the following: > > > > One or more disks are found, but one of the > > following problems exists: > > > > > Hardware failure > > > > > Unformatted disk. > > > > At which point I get dropped to a shell. If I try to use the format > > command from the shell, format cannot auto-configure the disk. Even if > > I try manually setting C/H/S parameters (either at qemu run time or in > > the format command), it does not seem to want to use the disk. This > > seems to happen whether I'm using an LVM volume or a file-based disk. > > Also, seems as though all changes are lost on the disk when I exit > > format and then immediately go back in. > > > > Ideas? Any further help/input/debugging I could provide? > > Hi Nick, > > Thanks again for testing this. The issue with Solaris not detecting the > disks is a known one - the following guide should point you in the right > direction: > > http://virtuallyfun.blogspot.com/2010/10/formatting-disks-for-solaris.html > > Also don't forget the "set scsi_options" part from Artyom's SPARC/QEMU > howto here: http://tyom.blogspot.com/2009/12/solaris-under-qemu-how-to.html > > I think it may actually be possible to come up with a patch for OpenBIOS > so that the scsi_options change isn't required - let me know how you get > on with the above links, and if it all seems to work I'll look at > creating the patch for you. > > Got a little further, but eventually ran into this when the Solaris installer tried to partition the formatted and labeled disk: Preparing system for Solaris install Configuring disk (c0t0d0) - Creating Solaris disk label (VTOC) Creating and checking UFS file systems - Creating / (c0t0d0s0) ERROR: File system creation failed for / (c0t0d0s0) ERROR: Could not check or create system critical file systems ERROR: Could not update disks with new configuration Could not update disks with new configuration I'm not sure if I need to do the partitioning with the format command ahead of time?? Thanks, Nick -------- This e-mail may contain confidential and privileged material for the sole use of the intended recipient. If this email is not intended for you, or you are not responsible for the delivery of this message to the intended recipient, please note that this message may contain SEAKR Engineering (SEAKR) Privileged/Proprietary Information. In such a case, you are strictly prohibited from downloading, photocopying, distributing or otherwise using this message, its contents or attachments in any way. If you have received this message in error, please notify us immediately by replying to this e-mail and delete the message from your mailbox. Information contained in this message that does not relate to the business of SEAKR is neither endorsed by nor attributable to SEAKR.

1 0

Re: [OpenBIOS] Solaris anyone?
by Nick Couchman 22 Apr '11

22 Apr '11

On Fri, 2011-04-22 at 08:08 +0100, Mark Cave-Ayland wrote: > With my previously posted patched applied: > > ./qemu-system-sparc -cdrom /home/build/src/qemu/sparcimage/sol8-cd1.iso > -boot d -nographic -prom-env 'auto-boot?=false' > > Configuration device id QEMU version 1 machine id 32 > CPUs: 1 x FMI,MB86904 > UUID: 00000000-0000-0000-0000-000000000000 > Welcome to OpenBIOS v1.0 built on Apr 20 2011 18:52 > Type 'help' for detailed information > > 0 > boot cdrom:d -v Not a bootable ELF image > Loading a.out image... > Loaded 7680 bytes > entry point is 0x4000 > bootpath: /iommu/sbus/espdma/esp/sd@2,0:d > > Jumping to entry point 00004000 for type 00000005... > switching to new context: > Size: 259040+54154+47486 Bytes > SunOS Release 5.8 Version Generic_108528-09 32-bit > Copyright 1983-2001 Sun Microsystems, Inc. All rights reserved. > Ethernet address = 52:54:0:12:34:56 > Using default device instance data > vac: enabled in write through mode > mem = 131072K (0x8000000) > avail mem = 110260224 > root nexus = SUNW,SPARCstation-5 > iommu0 at root: obio 0x10000000 > sbus0 at iommu0: obio 0x10001000 > dma0 at sbus0: SBus slot 5 0x8400000 > dma0 is /iommu@0,10000000/sbus@0,10001000/espdma@5,8400000 > /iommu@0,10000000/sbus@0,10001000/espdma@5,8400000/esp@5,8800000 (esp0): > esp-options=0x46 > esp0 at dma0: SBus slot 5 0x8800000 sparc ipl 4 > esp0 is /iommu@0,10000000/sbus@0,10001000/espdma@5,8400000/esp@5,8800000 > sd2 at esp0: target 2 lun 0 > sd2 is > /iommu@0,10000000/sbus@0,10001000/espdma@5,8400000/esp@5,8800000/sd@2,0 > root on > /iommu@0,10000000/sbus@0,10001000/espdma@5,8400000/esp@5,8800000/sd@2,0:b fstype > ufs > obio0 at root > obio0 at obio0: obio 0x100000, sparc ipl 12 > zs0 is /obio/zs@0,100000 > obio1 at obio0: obio 0x0, sparc ipl 12 > zs1 is /obio/zs@0,0 > cpu0: FMI,MB86904 (mid 0 impl 0x0 ver 0x5 clock 170 MHz) > Configuring /dev and /devices > pseudo-device: devinfo0 > devinfo0 is /pseudo/devinfo@0 > tcx0 at sbus0: SBus slot 3 0x800000 and SBus slot 3 0x2000000 and SBus > slot 3 0x4000000 and SBus slot 3 0x6000000 and SBus slot 3 0xa000000 and > SBus slot 3 0xc000000 and SBus slot 3 0xe000000 and SBus slot 3 0x700000 > and SBus slot 3 0x200000 and SBus slot 3 0x300000 and SBus slot 3 0x0 > and SBus slot 3 0x240000 and SBus slot 3 0x280000 SBus level 5 sparc ipl 9 > tcx0 is /iommu@0,10000000/sbus@0,10001000/SUNW,tcx@3,800000 > tcx0: revision 0, screen 1024x768 > ledma0 at sbus0: SBus slot 5 0x8400010 > le0 at ledma0: SBus slot 5 0x8c00000 sparc ipl 6 > le0 is /iommu@0,10000000/sbus@0,10001000/ledma@5,8400010/le@5,8c00000 > sbusmem0 at sbus0: SBus slot 0 0x0 > sbusmem0 is /iommu@0,10000000/sbus@0,10001000/sbusmem@0,0 > sbusmem1 at sbus0: SBus slot 1 0x0 > sbusmem1 is /iommu@0,10000000/sbus@0,10001000/sbusmem@1,0 > sbusmem2 at sbus0: SBus slot 2 0x0 > sbusmem2 is /iommu@0,10000000/sbus@0,10001000/sbusmem@2,0 > sbusmem3 at sbus0: SBus slot 3 0x0 > sbusmem3 is /iommu@0,10000000/sbus@0,10001000/sbusmem@3,0 > sbusmem4 at sbus0: SBus slot 4 0x0 > sbusmem4 is /iommu@0,10000000/sbus@0,10001000/sbusmem@4,0 > sbusmem5 at sbus0: SBus slot 5 0x0 > sbusmem5 is /iommu@0,10000000/sbus@0,10001000/sbusmem@5,0 > pseudo-device: winlock0 > winlock0 is /pseudo/winlock@0 > pseudo-device: llc10 > llc10 is /pseudo/llc1@0 > pseudo-device: lofi0 > lofi0 is /pseudo/lofi@0 > pseudo-device: fcp0 > fcp0 is /pseudo/fcp@0 > Using RPC Bootparams for network configuration information. > Skipping interface le0 > Searching for configuration file(s)... > > Select a Language > > 0. English > 1. French > 2. German > 3. Italian > 4. Japanese > 5. Korean > 6. Simplified Chinese > 7. Spanish > 8. Swedish > 9. Traditional Chinese > > Please make a choice (0 - 9), or press h or ? for help: > > Wow. All I can say is thank you so much to everyone who helped me get > this far - in particular Blue, Artyom and Tarl. Does anyone know if we > are the first non-Sun firmware to be able to boot a Solaris kernel? > > Blue - I think you owe me that 1.1 release soon! > > > Happy Easter everyone! > > Mark. > > -- > Mark Cave-Ayland - Senior Technical Architect > PostgreSQL - PostGIS > Sirius Corporation plc - control through freedom > http://www.siriusit.co.uk > t: +44 870 608 0063 > > Sirius Labs: http://www.siriusit.co.uk/labs > > -- > OpenBIOS http://openbios.org/ > Mailinglist: http://lists.openbios.org/mailman/listinfo > Free your System - May the Forth be with you Awesome!! Thanks for all the hard work, Mark - this is fantastic!! -Nick -------- This e-mail may contain confidential and privileged material for the sole use of the intended recipient. If this email is not intended for you, or you are not responsible for the delivery of this message to the intended recipient, please note that this message may contain SEAKR Engineering (SEAKR) Privileged/Proprietary Information. In such a case, you are strictly prohibited from downloading, photocopying, distributing or otherwise using this message, its contents or attachments in any way. If you have received this message in error, please notify us immediately by replying to this e-mail and delete the message from your mailbox. Information contained in this message that does not relate to the business of SEAKR is neither endorsed by nor attributable to SEAKR.

1 0

[commit] r1035 - trunk/openbios-devel/arch/sparc32
by repository service 22 Apr '11

22 Apr '11

Author: mcayland Date: Fri Apr 22 02:13:53 2011 New Revision: 1035 URL: http://tracker.coreboot.org/trac/openbios/changeset/1035 Log: Implement new v3_memalloc romvec interface for allocating aligned memory. When attempting to load kadb from a Solaris 8 CD at boot, it seems that in order for kadb to allocate enough memory to load the kernel (and its modules) the /openprom/aligned-allocator property must be present with length zero. This has the additional side-effect that OpenBIOS memory allocations are redirected to a new romvec offset when this property is detected, which appears to have a similar interface to obp_dumb_memalloc() but with an extra alignment parameter. Hence we include a simple implementation which seems to be enough to be able to get kadb to load and attach to the kernel. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)siriusit.co.uk> Modified: trunk/openbios-devel/arch/sparc32/call-romvec.S trunk/openbios-devel/arch/sparc32/lib.c trunk/openbios-devel/arch/sparc32/openprom.h trunk/openbios-devel/arch/sparc32/romvec.c trunk/openbios-devel/arch/sparc32/romvec.h trunk/openbios-devel/arch/sparc32/tree.fs Modified: trunk/openbios-devel/arch/sparc32/call-romvec.S ============================================================================== --- trunk/openbios-devel/arch/sparc32/call-romvec.S Fri Apr 8 11:03:59 2011 (r1034) +++ trunk/openbios-devel/arch/sparc32/call-romvec.S Fri Apr 22 02:13:53 2011 (r1035) @@ -89,4 +89,5 @@ ROMVEC_HANDLER(obp_getprop) ROMVEC_HANDLER(obp_setprop) ROMVEC_HANDLER(obp_nextprop) +ROMVEC_HANDLER(obp_memalloc) Modified: trunk/openbios-devel/arch/sparc32/lib.c ============================================================================== --- trunk/openbios-devel/arch/sparc32/lib.c Fri Apr 8 11:03:59 2011 (r1034) +++ trunk/openbios-devel/arch/sparc32/lib.c Fri Apr 22 02:13:53 2011 (r1035) @@ -347,10 +347,25 @@ map_pages(phys, virt, size, mode); } -char *obp_dumb_memalloc(char *va, unsigned int size) +char *obp_memalloc(char *va, unsigned int size, unsigned int align) { phys_addr_t phys; ucell virt; + + /* Claim physical memory */ + phys = ofmem_claim_phys(-1, size, align); + + /* Claim virtual memory */ + virt = ofmem_claim_virt(pointer2cell(va), size, 0); + + /* Map the memory */ + ofmem_map(phys, virt, size, ofmem_arch_default_translation_mode(phys)); + + return cell2pointer(virt); +} + +char *obp_dumb_memalloc(char *va, unsigned int size) +{ unsigned long align; int i; @@ -371,16 +386,7 @@ align++; } - /* Claim physical memory */ - phys = ofmem_claim_phys(-1, size, align); - - /* Claim virtual memory */ - virt = ofmem_claim_virt(pointer2cell(va), size, 0); - - /* Map the memory */ - ofmem_map(phys, virt, size, ofmem_arch_default_translation_mode(phys)); - - return cell2pointer(virt); + return obp_memalloc(va, size, align); } void obp_dumb_memfree(__attribute__((unused))char *va, Modified: trunk/openbios-devel/arch/sparc32/openprom.h ============================================================================== --- trunk/openbios-devel/arch/sparc32/openprom.h Fri Apr 8 11:03:59 2011 (r1034) +++ trunk/openbios-devel/arch/sparc32/openprom.h Fri Apr 22 02:13:53 2011 (r1035) @@ -135,7 +135,10 @@ struct linux_bootargs_v2 pv_v2bootargs; struct linux_dev_v2_funcs pv_v2devops; - int filler[15]; + /* Prom version 3 memory allocation */ + char * (*v3_memalloc)(char *va, unsigned int size, unsigned int align); + + int filler[14]; /* This one is sun4c/sun4 only. */ void (*pv_setctxt)(int ctxt, char *va, int pmeg); Modified: trunk/openbios-devel/arch/sparc32/romvec.c ============================================================================== --- trunk/openbios-devel/arch/sparc32/romvec.c Fri Apr 8 11:03:59 2011 (r1034) +++ trunk/openbios-devel/arch/sparc32/romvec.c Fri Apr 22 02:13:53 2011 (r1035) @@ -508,6 +508,8 @@ fword("open-dev"); obp_fd_stdout = POP(); + romvec0.v3_memalloc = obp_memalloc_handler; + romvec0.v3_cpustart = obp_cpustart_handler; romvec0.v3_cpustop = obp_cpustop_handler; romvec0.v3_cpuidle = obp_cpuidle_handler; Modified: trunk/openbios-devel/arch/sparc32/romvec.h ============================================================================== --- trunk/openbios-devel/arch/sparc32/romvec.h Fri Apr 8 11:03:59 2011 (r1034) +++ trunk/openbios-devel/arch/sparc32/romvec.h Fri Apr 22 02:13:53 2011 (r1035) @@ -74,3 +74,5 @@ __attribute__((unused)) int len); const char *obp_nextprop(int node, const char *name); const char *obp_nextprop_handler(int node, const char *name); +char *obp_memalloc(char *va, unsigned int size, unsigned int align); +char *obp_memalloc_handler(char *va, unsigned int size, unsigned int align); Modified: trunk/openbios-devel/arch/sparc32/tree.fs ============================================================================== --- trunk/openbios-devel/arch/sparc32/tree.fs Fri Apr 8 11:03:59 2011 (r1034) +++ trunk/openbios-devel/arch/sparc32/tree.fs Fri Apr 22 02:13:53 2011 (r1035) @@ -125,3 +125,6 @@ " /options" find-device " disk" encode-string " boot-from" property + +" /openprom" find-device + 0 0 " aligned-allocator" property

1 0