Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 29 Sep 2009 02:45:37 +0000
From:      Tom Judge <tom@tomjudge.com>
To:        Olivier Houchard <mlfbsd@ci0.org>
Cc:        freebsd-hackers@freebsd.org
Subject:   Re: Help debugging: Fatal kernel mode data abort: 'External	Linefetch Abort (P)'
Message-ID:  <4AC174D1.8080900@tomjudge.com>
In-Reply-To: <4AC16B5A.8090407@tomjudge.com>
References:  <4AC106AA.9000305@tomjudge.com> <20090928202132.GA15236@ci0.org> <4AC16B5A.8090407@tomjudge.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Tom Judge wrote:
> Olivier Houchard wrote:
>> On Mon, Sep 28, 2009 at 06:55:38PM +0000, Tom Judge wrote:
>>  
>>> Hi,
>>>
>>> I am working on getting FreeBSD to boot on a new ARM based board, 
>>> and am hitting this issue any time I load a driver for the PCI based 
>>> devices on the board.
>>>
>>> My current code can be found here:
>>>
>>> http://www.tomjudge.com/tmp/em7210.patch
>>>
>>>     
>>
>> Hi Tom,
>>
>> My guess is, you should include std.i80219 instead of std.i80321 in 
>> std.em7210.
>> If you do not, CPU_XSCALE_80219 won't be defined, and the 80321 code to
>> check if the board is host or not will be used, and will wrongly 
>> assume it is not, and thus won't map the PCI mem correctly.
>>
>>   
> Hi Olivier,
>
> I have switched out the std file and am now using std.i80219 but am 
> still having issues.
>
> I think the problems are the pci memory mappings in the controller 
> devices.
>
> On linux em0 gets mapped as  follows:
>
> cd 0000\:00\:01.0/
> # ls
> class             device            local_cpus        subsystem_device
> config            driver            resource          subsystem_vendor
> detach_state      irq               rom               vendor
> # cat resource
> 0x0000000080000000 0x000000008001ffff 0x0000000000000200
> 0x0000000080020000 0x000000008003ffff 0x0000000000000200
> 0x00000000fe000000 0x00000000fe00003f 0x0000000000000101
> 0x0000000000000000 0x0000000000000000 0x0000000000000000
> 0x0000000000000000 0x0000000000000000 0x0000000000000000
> 0x0000000000000000 0x0000000000000000 0x0000000000000000
> 0x0000000080040000 0x000000008005ffff 0x0000000000007200
> #
>
>
>
> Where as on FreeBSD I am seeing this:
> em0: <Intel(R) PRO/1000 Network Connection 6.9.14> port 
> 0xfe400000-0xfe40003f mem 0-0x1ffff,0x20000-0x3ffff irq 29 at device 
> 1.0 on pci0
>
> Seems that I am missing the 0x800 off the front of the PCI memory 
> mappings.
>
> I have confirmed this with the ata driver also and see the same issues.
>
> Where should I be looking to fix this?
>
Forgot to include the output from VERBOSE_INIT_ARM

iq0: <Intel 80321> on motherboard
i80321: BAR0 = 20000004.00000000 BAR1 = 40000004.00000000
i80219: BAR0 = 20000000.00000000 BAR1 = 40000000.00000000
i80321: SBDR = 0xa0000000 SBR0 = 0x00000018 SBR1 = 0x00000020
i80321: BANK0 = 0x10000000 BANK1 = 0x10000000
i80321: Reserve space for private devices (Inbound Window 1)
 hi:0x00000000 lo:0x8000000c xlate:0x80000000 size:0x04000000
 i80321: RAM access (Inbound Window 2)
  hi:0x00000000 lo:0xa000000c xlate:0xa0000000 size:0x20000000
  obio0 on iq0
  uart0: <16550 or compatible> on obio0




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4AC174D1.8080900>