From owner-freebsd-sparc64@freebsd.org Sun May 21 07:36:16 2017 Return-Path: Delivered-To: freebsd-sparc64@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D3295D77657 for ; Sun, 21 May 2017 07:36:16 +0000 (UTC) (envelope-from iwama@t3.rim.or.jp) Received: from mail06.SiriusCloud.jp (mail06.SiriusCloud.jp [219.118.72.6]) by mx1.freebsd.org (Postfix) with ESMTP id 7AD27D5E for ; Sun, 21 May 2017 07:36:15 +0000 (UTC) (envelope-from iwama@t3.rim.or.jp) Received: from t43 (124x37x209x7.ap124.ftth.ucom.ne.jp [124.37.209.7]) (Authenticated sender: iwama@t3.rim.or.jp) by access06.SiriusCloud.jp (Postfix) with ESMTPA id 3wVtd65cmxz1BsJ; Sun, 21 May 2017 16:26:18 +0900 (JST) Authentication-Results: access06.SiriusCloud.jp; dkim=none reason="no signature"; dkim-adsp=none (unprotected policy); dkim-atps=neutral Message-ID: <84871009D30A40E594081306CC201653@t43> From: "Yoshihiko Iwama" To: "Zaphod Beeblebrox" , References: In-Reply-To: Subject: Re: Ultra 5 Boot Hang Update. Date: Sun, 21 May 2017 16:26:15 +0900 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 X-Virus-Scanned: clamav-milter 0.99.2 at si-mail06 X-Virus-Status: Clean X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 May 2017 07:36:16 -0000 This mail does not describe the solution but I believe it contains useful content. I saw the boot -v log and thought that it contained two important sections. These are: from the line "pcib1: at device 1.1 on pci0" to last line and from the line "found-> vendor=0x1002, dev=0x4754, revid=0x9a" to last line(included above). The memory range decoded by APB is displied "0xe0000000-0xffffffff" but assigned range is form "0x0"(to "0xfff") because displied by next line: " map[18]: type Memory, range 32, base 0, size 12, enabled" Obviously, 0x0 is not within the range of 0xe0000000-0xffffffff, so this is probably an incorrect value. I also look the comment in /sys/dev/fb/machfb.c: === /* * Depending on the firmware version the VGA I/O and/or memory * resources of the Mach64 chips come up disabled. These will be * enabled by pci(4) when activating the resource in question but * this doesn't necessarily mean that the resource is valid. * Invalid resources seem to have in common that they start at * address 0. We don't allocate the VGA memory in this case in * order to avoid warnings in apb(4) and crashes when using this * invalid resources. X.Org is aware of this and doesn't use the * VGA memory resource in this case (but demands it if it's valid). */ === Here, compared with the boot -v log of PR121539, assigned rande is from "0xe2000000"(to "0xe2000fff") by below line: " map[18]: type Memory, range 32, base rxe2000000, size 12, enabled" I believe there may be problems with allocating memory on the bus. The story changes, about the second section, this is about graphics chips. The vender ID=0x1002 and dev ID=0x4754 means AMD(formerly ATI) and Rage 3D II Graphics Accelerator by http://pcidatabase.com/ or source code. Compared with the boot -v log of PR121539, the dev ID is 0x4750 in PR121539. This means ATI 3D Rage Pro 215GP. Perhaps there is a problem with FreeBSD and may not be able to cope well with ATI 3D Rage Pro 215 GP. So, what to do the most recently, I suggest you connect serial console to Ultra 5. Of course, even if you simply connect to the serial console, it will hang if ATI 3D Rage Pro 215GP is detected on FreeBSD. Therefore, disable ATI 3D Rage Pro 215GP. This method is described below: https://docs.oracle.com/cd/E19455-01/806-4629-05/6jdmq4im5/index.html Unfortunately, since I do not own Ultra 5, I have not tried the above method in practice. Therefore, the above method merely invalidates the graphic chip on the OBP, and it may still be detected by FreeBSD. In this way, Ultra 5 will hang as well. I advise that you should make sure you can make serial console connections before disabling graphics chips. --- Yoshihiko Iwama -----Original Message----- From: Zaphod Beeblebrox Sent: Tuesday, May 9, 2017 6:11 AM To: freebsd-sparc64@freebsd.org Subject: Ultra 5 Boot Hang Update. so the whole boot -v is attached via the link below. Please help. Hangs forever after the last pcib1 line (and STOP-A doesn't drop to a prompt) ... just to jog everyone's memory, to get this going I (translate / to enter): set-defaults/1 0 mkp/80 1 mkp/8 2 mkp/0 3 mkp/20 4 mkp/c0 5 mkp/ff 6 mkp/ee 7 mkp/0 8 mkp/0 9 mkp/0 a mkp/0 b mkp/c0 c mkp/ff d mkp/ee e mkp/0 f 0 do i idprom@ xor loop f mkp ... does that initialization pose some problem for FreeBSD? https://owncloud.towernet.ca/index.php/s/14awIqSzdOBexok _______________________________________________ freebsd-sparc64@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-sparc64 To unsubscribe, send any mail to "freebsd-sparc64-unsubscribe@freebsd.org"