Guruplug Server Plus working to some extent...

[Rafal Jaworowski]

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 at 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?)
>> 
>> 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 at f1000000', node=0xc0a791e0
> newbus_device_create(): added child name='soc88f6281 at f1000000', 
> node=0xc0a79444
> newbus_device_create(): added child name='sram at fd000000', node=0xc0a79d90
> newbus_device_from_fdt_node(): skipping instantiating FDT device='chosen'
> simplebus0: <Flattened device tree simple bus> 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...

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