Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 27 Oct 2010 18:44:23 +0200
From:      Rafal Jaworowski <raj@semihalf.com>
To:        Milan Obuch <freebsd-arm@dino.sk>
Cc:        freebsd-arm@freebsd.org
Subject:   Re: Guruplug Server Plus working to some extent...
Message-ID:  <7C9980A5-1812-4162-82E0-2374EACFA24A@semihalf.com>
In-Reply-To: <201010271656.53245.freebsd-arm@dino.sk>
References:  <201010202309.40148.freebsd-arm@dino.sk> <201010262200.09364.freebsd-arm@dino.sk> <20101026211958.GC24690@nereid> <201010271656.53245.freebsd-arm@dino.sk>

next in thread | previous in thread | raw e-mail | index | archive | help

On 2010-10-27, at 16:56, Milan Obuch wrote:

> On Tuesday 26 October 2010 23:19:59 Kristof Provost wrote:
>> On 2010-10-26 22:00:07 (+0200), Milan Obuch <freebsd-arm@dino.sk> =
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?)
>>=20
>> I mostly wanted to see the debug print statements in the simplebus =
code.
>> I think you need to set 'options DEBUG=3D1' 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.
>>=20
>=20
> OK, I am trying... but there is something a bit strange in=20
> sys/dev/fdt/fdtbus.c, lines 49 and 50:
>=20
> #define DEBUG
> #undef DEBUG
>=20
> I commented #undef out for now, rebuild kernel, but all I get from =
this new is
>=20
> newbus_device_from_fdt_node(): skipping instantiating FDT =
device=3D'aliases'
> newbus_device_create(): added child name=3D'cpus', node=3D0xc0a790c0
> newbus_device_from_fdt_node(): skipping instantiating FDT =
device=3D'memory'
> newbus_device_create(): added child name=3D'localbus@f1000000', =
node=3D0xc0a791e0
> newbus_device_create(): added child name=3D'soc88f6281@f1000000',=20
> node=3D0xc0a79444
> newbus_device_create(): added child name=3D'sram@fd000000', =
node=3D0xc0a79d90
> newbus_device_from_fdt_node(): skipping instantiating FDT =
device=3D'chosen'
> simplebus0: <Flattened device tree simple bus> on fdtbus0
>=20
> at the beginning of the boot instead of just the last line. Nothing =
new=20
> telling anything about mge1...
>=20
>> 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.
>>=20
>> Did you statically configure the mac addresses in the DTS for this =
boot?
>>=20
>=20
> Yes. Without that, ether addres did not initialize and needs to be set=20=

> manually.
>=20
> However, after looking over older mails again and trying to look at it =
from=20
> the other side, I found the reason. I am going to write a follow-up =
explaining=20
> the whole issue and how succesfully solved the problem... please wait =
a bit,=20
> something unrelated needs to be done now...

Have you got your MPP settings sorted out correctly? The second GE unit =
connections are multiplexed with other functions of the SOC and won't =
work without proper set-up, see the hardware spec and the description of =
MPP bindings in the DTS sys/boot/fdt/dts/bindings-mpp.txt

Rafal




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7C9980A5-1812-4162-82E0-2374EACFA24A>