From owner-freebsd-arm@FreeBSD.ORG Wed Oct 27 14:56:35 2010 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6A88F106566C for ; Wed, 27 Oct 2010 14:56:35 +0000 (UTC) (envelope-from freebsd-arm@dino.sk) Received: from loki.netlab.sk (ns3.netlab.sk [84.245.65.11]) by mx1.freebsd.org (Postfix) with ESMTP id 034488FC16 for ; Wed, 27 Oct 2010 14:56:33 +0000 (UTC) Received: from door.dino.sk (fw1.dino.sk [84.245.95.252]) (AUTH: PLAIN milan, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by loki.netlab.sk with esmtp; Wed, 27 Oct 2010 16:57:22 +0200 id 00033C0A.4CC83DD2.00002115 From: Milan Obuch To: Kristof Provost Date: Wed, 27 Oct 2010 16:56:51 +0200 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.5.2; i386; ; ) References: <201010202309.40148.freebsd-arm@dino.sk> <201010262200.09364.freebsd-arm@dino.sk> <20101026211958.GC24690@nereid> In-Reply-To: <20101026211958.GC24690@nereid> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201010271656.53245.freebsd-arm@dino.sk> Cc: freebsd-arm@freebsd.org Subject: Re: Guruplug Server Plus working to some extent... X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 14:56:35 -0000 On Tuesday 26 October 2010 23:19:59 Kristof Provost wrote: > On 2010-10-26 22:00:07 (+0200), Milan Obuch wrote: > > Well, 'makeoptions DEBUG' just creates kernel.symbols, nothing else... > > there must be some other way to create more debug output, but I did not > > find it. If I could convert elf-structured ubldr to binary ubldr.bin, > > maybe I can boot kernel with verbose output... but I did not find the > > way to do it. (Any hint on this?) > > I mostly wanted to see the debug print statements in the simplebus code. > I think you need to set 'options DEBUG=1' in the config file to get > them. I seem to remember making a few changes in other parts of the code > to get that to build though. > OK, I am trying... but there is something a bit strange in sys/dev/fdt/fdtbus.c, lines 49 and 50: #define DEBUG #undef DEBUG I commented #undef out for now, rebuild kernel, but all I get from this new is newbus_device_from_fdt_node(): skipping instantiating FDT device='aliases' newbus_device_create(): added child name='cpus', node=0xc0a790c0 newbus_device_from_fdt_node(): skipping instantiating FDT device='memory' newbus_device_create(): added child name='localbus@f1000000', node=0xc0a791e0 newbus_device_create(): added child name='soc88f6281@f1000000', node=0xc0a79444 newbus_device_create(): added child name='sram@fd000000', node=0xc0a79d90 newbus_device_from_fdt_node(): skipping instantiating FDT device='chosen' simplebus0: on fdtbus0 at the beginning of the boot instead of just the last line. Nothing new telling anything about mge1... > In any case, what I wanted to see is already printed in the boot log. > Both mge interfaces are using the correct memory locatins (0xf1076000 > for mge1) and the correct PHY numbers. > > Did you statically configure the mac addresses in the DTS for this boot? > Yes. Without that, ether addres did not initialize and needs to be set manually. However, after looking over older mails again and trying to look at it from the other side, I found the reason. I am going to write a follow-up explaining the whole issue and how succesfully solved the problem... please wait a bit, something unrelated needs to be done now... Regards, Milan