From don at donhayford.com  Fri May  1 04:11:09 2009
From: don at donhayford.com (Donald T Hayford)
Date: Fri May  1 04:11:15 2009
Subject: Help with Marvel kernel for 88F5512
Message-ID: <49FA5952.20800@donhayford.com>

I built FreeBSD kernel and world for the Marvel chipsets using the 
instructions here:
http://wiki.freebsd.org/FreeBSDMarvell

When I tried booting a Kurobox Pro (Marvel 88F5512) I see the following:

Marvell>> tftp 0x900000 sheeva/5XXXkernel.bin
Using egiga0 device
TFTP from server 192.168.11.1; our IP address is 192.168.11.150
Filename 'sheeva/5XXXkernel.bin'.
Load address: 0x900000
Loading: #################################################################
     #################################################################
     #################################################################
     #################################################################
     #################################################################
     #################################################################
     #################################################################
     #################################################################
     #########################################
done
Bytes transferred = 2870196 (2bcbb4 hex)
Marvell>> go 0x900000
## Starting application at 0x00900000 ...
KDB: debugger backends: ddb
KDB: current backend: ddb
Copyright (c) 1992-2009 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
    The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 8.0-CURRENT #0: Sun Apr 26 16:12:12 EDT 2009
    hayford@freeqemu:/usr/obj/arm/usr/src/sys/DB-88F5XXX
WARNING: WITNESS option enabled, expect reduced performance.
WARNING: DIAGNOSTIC option enabled, expect reduced performance.
Preloaded elf kernel "elf kernel" at 0xc0d2f988.
CPU: ARM926EJ-S rev 0 (ARM9EJ-S core)
  DC enabled IC enabled WB enabled EABT branch prediction enabled
  32KB/32B 1-way Instruction cache
  32KB/32B 1-way write-back-locking-C Data cache
real memory  = 134217728 (128 MB)
Physical memory chunk(s):
00000000 - 0x8fffff, 9437184 bytes (2304 pages)
0xe21000 - 0x7d8efff, 116842496 bytes (28526 pages)
avail memory = 125272064 (119 MB)
SOC: (0x5182:0x02) Marvell 88F5182 rev A2, TClock 166MHz
mem: <memory>
random: <entropy source, Software, Yarrow>
null: <null device, zero device>
nfslock: pseudo-device
mbus0: <Marvell Internal Bus (Mbus)> on motherboard
ic0: <Marvell Integrated Interrupt Controller> at mem 
0xf1020200-0xf102023b on mbus0
timer0: <Marvell CPU Timer> at mem 0xf1020300-0xf102032f irq 0 on mbus0
timer0: [FILTER]
gpio0: <Marvell Integrated GPIO Controller> at mem 0xf1010100-0xf101011f 
irq 6,7,8,9 on mbus0
gpio0: [FILTER]
gpio0: [FILTER]
gpio0: [FILTER]
gpio0: [FILTER]
uart0: <16550 or compatible> at mem 0xf1012000-0xf101201f irq 3 on mbus0
uart0: [FILTER]
uart0: fast interrupt
uart0: console (115740,n,8,1)
uart1: <16550 or compatible> at mem 0xf1012100-0xf101211f irq 4 on mbus0
uart1: [FILTER]
uart1: fast interrupt
ehci0: <Marvell Integrated USB 2.0 controller> at mem 
0xf1050000-0xf1050fff irq 16,17 on mbus0
ehci0: [FILTER]
ehci0: [MPSAFE]
ehci0: [ITHREAD]
ehci0: 5.24 GL USB-2 workaround enabled
usbus0: EHCI version 1.0
usbus0: set host controller mode
usbus0: <Marvell Integrated USB 2.0 controller> on ehci0
mge0: <Marvell Gigabit Ethernet controller> at mem 0xf1072000-0xf1073fff 
irq 18,19,20,21,22 on mbus0
mge0: bpf attached
mge0: Ethernet address: 00:16:01:a4:e4:87
miibus0: <MII bus> on mge0
e1000phy0: <Marvell 88E1116 Gigabit PHY> PHY 8 on miibus0
e1000phy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 
1000baseTX-FDX, auto
mge0: [MPSAFE]
mge0: [ITHREAD]
mge0: [MPSAFE]
mge0: [ITHREAD]
twsi0: <Marvell Integrated I2C Bus Controller> at mem 
0xf1011000-0xf101101f on mbus0
iicbus0: <Philips I2C bus> on twsi0
iicbus0: <unknown card> at addr 0
iic0: <I2C generic I/O> on iicbus0
pcib1: <Marvell 88F5182 PCI-X host controller> at mem 
0xf1030000-0xf1031fff on mbus0

At this point, the device hangs until I reboot it.

Any advice is greatly appreciated.
Thanks,
Don

From don at donhayford.com  Fri May  1 04:17:30 2009
From: don at donhayford.com (Donald T Hayford)
Date: Fri May  1 04:17:36 2009
Subject: Help with Marvel kernel for 88F6281
Message-ID: <49FA5B75.9090008@donhayford.com>

I built FreeBSD-8 (current) kernel and world for the Marvel chipsets 
using the instructions here:
http://wiki.freebsd.org/FreeBSDMarvell

When I tried booting a Sheevaplug (Marvel 88F6281), the system hangs as 
soon as I start it:

Restarting system.
         __  __                      _ _
        |  \/  | __ _ _ ____   _____| | |
        | |\/| |/ _` | '__\ \ / / _ \ | |
        | |  | | (_| | |   \ V /  __/ | |
        |_|  |_|\__,_|_|    \_/ \___|_|_|
 _   _     ____              _
| | | |   | __ )  ___   ___ | |_
| | | |___|  _ \ / _ \ / _ \| __|
| |_| |___| |_) | (_) | (_) | |_
 \___/    |____/ \___/ \___/ \__|
 ** MARVELL BOARD: SHEEVA PLUG LE

U-Boot 1.1.4 (Mar 19 2009 - 16:06:59) Marvell version: 3.4.16

U-Boot code: 00600000 -> 0067FFF0  BSS: -> 006CEE80

Soc: 88F6281 A0 (DDR2)
CPU running @ 1200Mhz L2 running @ 400Mhz
SysClock = 400Mhz , TClock = 200Mhz

DRAM CAS Latency = 5 tRP = 5 tRAS = 18 tRCD=6
DRAM CS[0] base 0x00000000   size 256MB
DRAM CS[1] base 0x10000000   size 256MB
DRAM Total size 512MB  16bit width
Flash:  0 kB
Addresses 8M - 0M are saved for the U-Boot usage.
Mem malloc Initialization (8M - 7M): Done
NAND:512 MB

CPU : Marvell Feroceon (Rev 1)

Streaming disabled
Write allocate disabled


USB 0: host mode
PEX 0: interface detected no Link.
Net:   egiga0 [PRIME], egiga1
Hit any key to stop autoboot:   0
Marvell>> <INTERRUPT>
Marvell>> dhcp

BOOTP broadcast 1
DHCP client bound to address 192.168.1.246
Marvell>> tftpboot 0x900000 sheeva/6XXXkernel.bin

Using egiga0 device
TFTP from server 192.168.1.102; our IP address is 192.168.1.246
Filename 'sheeva/6XXXkernel.bin'.
Load address: 0x900000
Loading: *#################################################################
     #################################################################
     #################################################################
     #################################################################
     #################################################################
     #################################################################
     #################################################################
     #################################################################
     ########################################
done
Bytes transferred = 2863204 (2bb064 hex)
Marvell>> g 0x900000

This command can be used only if enaMonExt is set!
Marvell>> go 0x900000

## Starting application at 0x00900000 ...


Then nothing more...

Any help or suggestions would be greatly appreciated.

Thanks,
Don
From raj at semihalf.com  Fri May  1 09:39:00 2009
From: raj at semihalf.com (Rafal Jaworowski)
Date: Fri May  1 09:39:06 2009
Subject: Help with Marvel kernel for 88F5512
In-Reply-To: <49FA5952.20800@donhayford.com>
References: <49FA5952.20800@donhayford.com>
Message-ID: <1324A9FE-D45B-479E-9705-5FCFA2FAC9E0@semihalf.com>


On 2009-05-01, at 04:07, Donald T Hayford wrote:

> I built FreeBSD kernel and world for the Marvel chipsets using the  
> instructions here:
> http://wiki.freebsd.org/FreeBSDMarvell
>
> When I tried booting a Kurobox Pro (Marvel 88F5512) I see the  
> following:
>
> Marvell>> tftp 0x900000 sheeva/5XXXkernel.bin
> Using egiga0 device
> TFTP from server 192.168.11.1; our IP address is 192.168.11.150
> Filename 'sheeva/5XXXkernel.bin'.
> Load address: 0x900000
> Loading:  
> #################################################################
>    #################################################################
>    #################################################################
>    #################################################################
>    #################################################################
>    #################################################################
>    #################################################################
>    #################################################################
>    #########################################
> done
> Bytes transferred = 2870196 (2bcbb4 hex)
> Marvell>> go 0x900000
> ## Starting application at 0x00900000 ...
> KDB: debugger backends: ddb
> KDB: current backend: ddb
> Copyright (c) 1992-2009 The FreeBSD Project.
> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993,  
> 1994
>   The Regents of the University of California. All rights reserved.
> FreeBSD is a registered trademark of The FreeBSD Foundation.
> FreeBSD 8.0-CURRENT #0: Sun Apr 26 16:12:12 EDT 2009
>   hayford@freeqemu:/usr/obj/arm/usr/src/sys/DB-88F5XXX
> WARNING: WITNESS option enabled, expect reduced performance.
> WARNING: DIAGNOSTIC option enabled, expect reduced performance.
> Preloaded elf kernel "elf kernel" at 0xc0d2f988.
> CPU: ARM926EJ-S rev 0 (ARM9EJ-S core)
> DC enabled IC enabled WB enabled EABT branch prediction enabled
> 32KB/32B 1-way Instruction cache
> 32KB/32B 1-way write-back-locking-C Data cache
> real memory  = 134217728 (128 MB)
> Physical memory chunk(s):
> 00000000 - 0x8fffff, 9437184 bytes (2304 pages)
> 0xe21000 - 0x7d8efff, 116842496 bytes (28526 pages)
> avail memory = 125272064 (119 MB)
> SOC: (0x5182:0x02) Marvell 88F5182 rev A2, TClock 166MHz

[...]

> twsi0: <Marvell Integrated I2C Bus Controller> at mem  
> 0xf1011000-0xf101101f on mbus0
> iicbus0: <Philips I2C bus> on twsi0
> iicbus0: <unknown card> at addr 0
> iic0: <I2C generic I/O> on iicbus0
> pcib1: <Marvell 88F5182 PCI-X host controller> at mem  
> 0xf1030000-0xf1031fff on mbus0
>
> At this point, the device hangs until I reboot it.

Could you please compile out PCI support to see whether this hang is  
somehow PCI-related?

If it still hangs, please try to remove (comment out) an entry for  
UART1 in obio_devices[] (sys/arm/mv/orion/orion.c), recompile and try  
again. I've heard reports that second uart on some 88F51xx systems  
causes strange problems like this, but couldn't reproduce it.
Rafal

From raj at semihalf.com  Fri May  1 09:50:31 2009
From: raj at semihalf.com (Rafal Jaworowski)
Date: Fri May  1 09:50:38 2009
Subject: Help with Marvel kernel for 88F6281
In-Reply-To: <49FA5B75.9090008@donhayford.com>
References: <49FA5B75.9090008@donhayford.com>
Message-ID: <D12A7520-0AA8-4A25-8FF7-EE75FE91C89D@semihalf.com>


On 2009-05-01, at 04:16, Donald T Hayford wrote:

> I built FreeBSD-8 (current) kernel and world for the Marvel chipsets  
> using the instructions here:
> http://wiki.freebsd.org/FreeBSDMarvell
>
> When I tried booting a Sheevaplug (Marvel 88F6281), the system hangs  
> as soon as I start it:
>
> Restarting system.
>        __  __                      _ _
>       |  \/  | __ _ _ ____   _____| | |
>       | |\/| |/ _` | '__\ \ / / _ \ | |
>       | |  | | (_| | |   \ V /  __/ | |
>       |_|  |_|\__,_|_|    \_/ \___|_|_|
> _   _     ____              _
> | | | |   | __ )  ___   ___ | |_
> | | | |___|  _ \ / _ \ / _ \| __|
> | |_| |___| |_) | (_) | (_) | |_
> \___/    |____/ \___/ \___/ \__|
> ** MARVELL BOARD: SHEEVA PLUG LE
>
> U-Boot 1.1.4 (Mar 19 2009 - 16:06:59) Marvell version: 3.4.16
>
> U-Boot code: 00600000 -> 0067FFF0  BSS: -> 006CEE80
>
> Soc: 88F6281 A0 (DDR2)
> CPU running @ 1200Mhz L2 running @ 400Mhz
> SysClock = 400Mhz , TClock = 200Mhz
>
> DRAM CAS Latency = 5 tRP = 5 tRAS = 18 tRCD=6
> DRAM CS[0] base 0x00000000   size 256MB
> DRAM CS[1] base 0x10000000   size 256MB
> DRAM Total size 512MB  16bit width
> Flash:  0 kB
> Addresses 8M - 0M are saved for the U-Boot usage.
> Mem malloc Initialization (8M - 7M): Done
> NAND:512 MB
>
> CPU : Marvell Feroceon (Rev 1)
>
> Streaming disabled
> Write allocate disabled
>
>
> USB 0: host mode
> PEX 0: interface detected no Link.
> Net:   egiga0 [PRIME], egiga1
> Hit any key to stop autoboot:   0
> Marvell>> <INTERRUPT>
> Marvell>> dhcp
>
> BOOTP broadcast 1
> DHCP client bound to address 192.168.1.246
> Marvell>> tftpboot 0x900000 sheeva/6XXXkernel.bin
>
> Using egiga0 device
> TFTP from server 192.168.1.102; our IP address is 192.168.1.246
> Filename 'sheeva/6XXXkernel.bin'.
> Load address: 0x900000
> Loading:  
> *#################################################################
>    #################################################################
>    #################################################################
>    #################################################################
>    #################################################################
>    #################################################################
>    #################################################################
>    #################################################################
>    ########################################
> done
> Bytes transferred = 2863204 (2bb064 hex)
> Marvell>> g 0x900000
>
> This command can be used only if enaMonExt is set!
> Marvell>> go 0x900000
>
> ## Starting application at 0x00900000 ...
>
>
> Then nothing more...
>
> Any help or suggestions would be greatly appreciated.

Please show the output of the 'map' command at U-Boot prompt.

Rafal

From don at donhayford.com  Fri May  1 11:31:38 2009
From: don at donhayford.com (Donald T Hayford)
Date: Fri May  1 11:31:43 2009
Subject: Help with Marvel kernel for 88F6281
In-Reply-To: <D12A7520-0AA8-4A25-8FF7-EE75FE91C89D@semihalf.com>
References: <49FA5B75.9090008@donhayford.com>
	<D12A7520-0AA8-4A25-8FF7-EE75FE91C89D@semihalf.com>
Message-ID: <49FADD97.5040305@donhayford.com>

Rafal Jaworowski wrote:
>
> On 2009-05-01, at 04:16, Donald T Hayford wrote:
>
>> I built FreeBSD-8 (current) kernel and world for the Marvel chipsets 
>> using the instructions here:
>> http://wiki.freebsd.org/FreeBSDMarvell
>>
>> When I tried booting a Sheevaplug (Marvel 88F6281), the system hangs 
>> as soon as I start it:
>
> Please show the output of the 'map' command at U-Boot prompt.
>

Marvell>> map


CPU Interface
-------------
SDRAM_CS0 ....base 00000000, size 256MB 
SDRAM_CS1 ....base 10000000, size 256MB 
SDRAM_CS2 ....disable
SDRAM_CS3 ....disable
PEX0_MEM ....base 90000000, size 256MB 
PEX0_IO ....base f0000000, size  16MB 
INTER_REGS ....base f1000000, size   1MB 
NFLASH_CS ....base f9000000, size   8MB 
SPI_CS ....base f8000000, size  16MB 
BOOT_ROM_CS ....base ff000000, size  16MB 
DEV_BOOTCS ....base ff000000, size  16MB 
CRYPT_ENG ....base fb000000, size  64KB 

AHB To MBUS Bridge:
-------------------
win0 - PEX0_MEM base 90000000, ....size 256MB 
win1 - NFLASH_CS base f9000000, ....size   8MB 
win2 - PEX0_IO base f0000000, ....size  16MB 
win3 - SPI_CS base f8000000, ....size  16MB 
win4 - BOOT_ROM_CS base ff000000, ....size  16MB 
win5 - disable
win6 - disable
win7 - CRYPT_ENG base fb000000, ....size  64KB 
win8 - INTER_REGS base f1000000, ....size   1MB 

PEX0:
-----

Pex Bars 

Internal Regs Bar0.... base f1000000, size   1MB 
DRAM Bar1............. base 00000000, size 512MB 
Devices Bar2.......... disable

Pex Decode Windows

win0 - SDRAM_CS0 base 00000000, ....size 256MB 
win1 - SDRAM_CS1 base 10000000, ....size 256MB 
win2 - disable
win3 - disable
win4 - disable
win5 - disable
default win - target unknown 
Expansion ROM - NFLASH_CS 

USB:
----
Device 0:
win0 - SDRAM_CS0 base 00000000, size 256MB 
win1 - SDRAM_CS1 base 10000000, size 256MB 
win2 - PEX0_MEM base 90000000, size 256MB 
win3 - disable

ETH 0:
----
win0 - SDRAM_CS0 base 00000000, ....size 256MB 
win1 - SDRAM_CS1 base 10000000, ....size 256MB 
win2 - NFLASH_CS base f9000000, ....size   8MB 
win3 - SPI_CS base f8000000, ....size  16MB 
win4 - BOOT_ROM_CS base ff000000, ....size  16MB 
win5 - disable

ETH 1:
----
win0 - SDRAM_CS0 base 00000000, ....size 256MB 
win1 - SDRAM_CS1 base 10000000, ....size 256MB 
win2 - NFLASH_CS base f9000000, ....size   8MB 
win3 - SPI_CS base f8000000, ....size  16MB 
win4 - BOOT_ROM_CS base ff000000, ....size  16MB 
win5 - disable

XOR 0:
----
win0 - NFLASH_CS base f9000000, size   8MB 
win1 - PEX0_MEM base 90000000, size 256MB 
win2 - SDRAM_CS0 base 0, size 256MB 
win3 - SDRAM_CS1 base 10000000, size 256MB 
win4 - SPI_CS base f8000000, size  16MB 
win5 - CRYPT_ENG base fb000000, size  64KB 
win6 - disable
win7 - disable

XOR 1:
----
win0 - NFLASH_CS base f9000000, size   8MB 
win1 - PEX0_MEM base 90000000, size 256MB 
win2 - SDRAM_CS0 base 0, size 256MB 
win3 - SDRAM_CS1 base 10000000, size 256MB 
win4 - SPI_CS base f8000000, size  16MB 
win5 - CRYPT_ENG base fb000000, size  64KB 
win6 - disable
win7 - disable

AUDIO:
----
win0 - SDRAM_CS0 base 00000000, ....size 256MB 
win1 - SDRAM_CS1 base 10000000, ....size 256MB 
Marvell>> 

Thanks,
Don

From don at donhayford.com  Fri May  1 11:35:57 2009
From: don at donhayford.com (Donald T Hayford)
Date: Fri May  1 11:36:03 2009
Subject: Help with Marvel kernel for 88F6281
In-Reply-To: <D12A7520-0AA8-4A25-8FF7-EE75FE91C89D@semihalf.com>
References: <49FA5B75.9090008@donhayford.com>
	<D12A7520-0AA8-4A25-8FF7-EE75FE91C89D@semihalf.com>
Message-ID: <49FADE9B.1080806@donhayford.com>

Rafal Jaworowski wrote:
>
> On 2009-05-01, at 04:16, Donald T Hayford wrote:
>
>> I built FreeBSD-8 (current) kernel and world for the Marvel chipsets 
>> using the instructions here:
>> http://wiki.freebsd.org/FreeBSDMarvell
>>
>> When I tried booting a Sheevaplug (Marvel 88F6281), the system hangs 
>> as soon as I start it:
>
> Please show the output of the 'map' command at U-Boot prompt.
>
I apologize for the bad pasting job - I'll try again.  Hopefully this 
one is easier to read.

Marvell>> map 
 
CPU Interface
-------------
SDRAM_CS0 ....base 00000000, size 256MB 
SDRAM_CS1 ....base 10000000, size 256MB 
SDRAM_CS2 ....disable
SDRAM_CS3 ....disable
PEX0_MEM ....base 90000000, size 256MB 
PEX0_IO ....base f0000000, size  16MB 
INTER_REGS ....base f1000000, size   1MB 
NFLASH_CS ....base f9000000, size   8MB 
SPI_CS ....base f8000000, size  16MB 
BOOT_ROM_CS ....base ff000000, size  16MB 
DEV_BOOTCS ....base ff000000, size  16MB 
CRYPT_ENG ....base fb000000, size  64KB 
 
AHB To MBUS Bridge:
-------------------
win0 - PEX0_MEM base 90000000, ....size 256MB 
win1 - NFLASH_CS base f9000000, ....size   8MB 
win2 - PEX0_IO base f0000000, ....size  16MB 
win3 - SPI_CS base f8000000, ....size  16MB 
win4 - BOOT_ROM_CS base ff000000, ....size  16MB 
win5 - disable
win6 - disable
win7 - CRYPT_ENG base fb000000, ....size  64KB 
win8 - INTER_REGS base f1000000, ....size   1MB 
 
PEX0:
-----
 
Pex Bars 
 
Internal Regs Bar0.... base f1000000, size   1MB 
DRAM Bar1............. base 00000000, size 512MB 
Devices Bar2.......... disable
 
Pex Decode Windows
 
win0 - SDRAM_CS0 base 00000000, ....size 256MB 
win1 - SDRAM_CS1 base 10000000, ....size 256MB 
win2 - disable
win3 - disable
win4 - disable
win5 - disable
default win - target unknown 
Expansion ROM - NFLASH_CS 
 
USB:
----
Device 0:
win0 - SDRAM_CS0 base 00000000, size 256MB 
win1 - SDRAM_CS1 base 10000000, size 256MB 
win2 - PEX0_MEM base 90000000, size 256MB 
win3 - disable
 
ETH 0:
----
win0 - SDRAM_CS0 base 00000000, ....size 256MB 
win1 - SDRAM_CS1 base 10000000, ....size 256MB 
win2 - NFLASH_CS base f9000000, ....size   8MB 
win3 - SPI_CS base f8000000, ....size  16MB 
win4 - BOOT_ROM_CS base ff000000, ....size  16MB 
win5 - disable
 
ETH 1:
----
win0 - SDRAM_CS0 base 00000000, ....size 256MB 
win1 - SDRAM_CS1 base 10000000, ....size 256MB 
win2 - NFLASH_CS base f9000000, ....size   8MB 
win3 - SPI_CS base f8000000, ....size  16MB 
win4 - BOOT_ROM_CS base ff000000, ....size  16MB 
win5 - disable
 
XOR 0:
----
win0 - NFLASH_CS base f9000000, size   8MB 
win1 - PEX0_MEM base 90000000, size 256MB 
win2 - SDRAM_CS0 base 0, size 256MB 
win3 - SDRAM_CS1 base 10000000, size 256MB 
win4 - SPI_CS base f8000000, size  16MB 
win5 - CRYPT_ENG base fb000000, size  64KB 
win6 - disable
win7 - disable
 
XOR 1:
----
win0 - NFLASH_CS base f9000000, size   8MB 
win1 - PEX0_MEM base 90000000, size 256MB 
win2 - SDRAM_CS0 base 0, size 256MB 
win3 - SDRAM_CS1 base 10000000, size 256MB 
win4 - SPI_CS base f8000000, size  16MB 
win5 - CRYPT_ENG base fb000000, size  64KB 
win6 - disable
win7 - disable
 
AUDIO:
----
win0 - SDRAM_CS0 base 00000000, ....size 256MB 
win1 - SDRAM_CS1 base 10000000, ....size 256MB 
Marvell>>


> Rafal
>

From raj at semihalf.com  Fri May  1 12:07:25 2009
From: raj at semihalf.com (Rafal Jaworowski)
Date: Fri May  1 12:07:33 2009
Subject: Help with Marvel kernel for 88F6281
In-Reply-To: <49FADE9B.1080806@donhayford.com>
References: <49FA5B75.9090008@donhayford.com>
	<D12A7520-0AA8-4A25-8FF7-EE75FE91C89D@semihalf.com>
	<49FADE9B.1080806@donhayford.com>
Message-ID: <494D378B-B243-4D97-8554-AC3E74A30B8C@semihalf.com>


On 2009-05-01, at 13:35, Donald T Hayford wrote:

> Rafal Jaworowski wrote:
>>
>> On 2009-05-01, at 04:16, Donald T Hayford wrote:
>>
>>> I built FreeBSD-8 (current) kernel and world for the Marvel  
>>> chipsets using the instructions here:
>>> http://wiki.freebsd.org/FreeBSDMarvell
>>>
>>> When I tried booting a Sheevaplug (Marvel 88F6281), the system  
>>> hangs as soon as I start it:
>>
>> Please show the output of the 'map' command at U-Boot prompt.
>>
> I apologize for the bad pasting job - I'll try again.  Hopefully  
> this one is easier to read.
>
> Marvell>> map CPU Interface
> -------------

[...]

I don't see any mismatches WRT internal SOC registers location etc.  
and need to look a bit closer to the SheevaPlug docs.

Just a basic clarification: you are 100% sure the correct DB-88F6XXX  
kernel image is used, right?

Rafal

From jacques.fourie at gmail.com  Fri May  1 13:55:49 2009
From: jacques.fourie at gmail.com (Jacques Fourie)
Date: Fri May  1 13:55:57 2009
Subject: PXA27X support
Message-ID: <be2f52430905010626s212cf8ebt2a22899297629802@mail.gmail.com>

Hi,

I've been working on getting FreeBSD to boot on my Yoggie
(http://www.yoggie.com/open-firewall-soho) platform.
The only major missing piece is that set_cpufuncs() doesn't support the PXA270 :

--- a/sys/arm/arm/cpufunc.c
+++ b/sys/arm/arm/cpufunc.c
@@ -1192,6 +1192,7 @@ set_cpufuncs()
 #ifdef CPU_XSCALE_PXA2X0
        /* ignore core revision to test PXA2xx CPUs */
        if ((cputype & ~CPU_ID_XSCALE_COREREV_MASK) == CPU_ID_PXA250 ||
+           (cputype & ~CPU_ID_XSCALE_COREREV_MASK) == CPU_ID_PXA27X ||
            (cputype & ~CPU_ID_XSCALE_COREREV_MASK) == CPU_ID_PXA210) {

There are some other differences between the PXA255 and PXA270 such as
different gpio pins etc. but I'm
unsure as to what the best way is to handle this elegantly in the
current pxa code. Currently I'm using a bunch
of #ifdefs in files such as pxa_machdep.c.

Regards,
Jacques
From stas at FreeBSD.org  Fri May  1 20:29:02 2009
From: stas at FreeBSD.org (Stanislav Sedov)
Date: Fri May  1 20:29:09 2009
Subject: PXA27X support
In-Reply-To: <be2f52430905010626s212cf8ebt2a22899297629802@mail.gmail.com>
References: <be2f52430905010626s212cf8ebt2a22899297629802@mail.gmail.com>
Message-ID: <20090502002910.8890ddac.stas@FreeBSD.org>

On Fri, 1 May 2009 15:26:22 +0200
Jacques Fourie <jacques.fourie@gmail.com> mentioned:

> Hi,
> 
> I've been working on getting FreeBSD to boot on my Yoggie
> (http://www.yoggie.com/open-firewall-soho) platform.
> The only major missing piece is that set_cpufuncs() doesn't support the PXA270 :
> 
> --- a/sys/arm/arm/cpufunc.c
> +++ b/sys/arm/arm/cpufunc.c
> @@ -1192,6 +1192,7 @@ set_cpufuncs()
>  #ifdef CPU_XSCALE_PXA2X0
>         /* ignore core revision to test PXA2xx CPUs */
>         if ((cputype & ~CPU_ID_XSCALE_COREREV_MASK) == CPU_ID_PXA250 ||
> +           (cputype & ~CPU_ID_XSCALE_COREREV_MASK) == CPU_ID_PXA27X ||
>             (cputype & ~CPU_ID_XSCALE_COREREV_MASK) == CPU_ID_PXA210) {
> 
> There are some other differences between the PXA255 and PXA270 such as
> different gpio pins etc. but I'm
> unsure as to what the best way is to handle this elegantly in the
> current pxa code. Currently I'm using a bunch
> of #ifdefs in files such as pxa_machdep.c.
> 

Hi!

Can you, please, share you code so we can see how to better intergrate
it with the current code?

-- 
Stanislav Sedov
ST4096-RIPE

From don at donhayford.com  Fri May  1 23:32:44 2009
From: don at donhayford.com (Donald T Hayford)
Date: Fri May  1 23:32:50 2009
Subject: Help with Marvel kernel for 88F6281
In-Reply-To: <494D378B-B243-4D97-8554-AC3E74A30B8C@semihalf.com>
References: <49FA5B75.9090008@donhayford.com>
	<D12A7520-0AA8-4A25-8FF7-EE75FE91C89D@semihalf.com>
	<49FADE9B.1080806@donhayford.com>
	<494D378B-B243-4D97-8554-AC3E74A30B8C@semihalf.com>
Message-ID: <49FB8696.8020907@donhayford.com>

Rafal Jaworowski wrote:
>
> On 2009-05-01, at 13:35, Donald T Hayford wrote:
>
>> Rafal Jaworowski wrote:
>>>
>>> On 2009-05-01, at 04:16, Donald T Hayford wrote:
>>>
>>>> I built FreeBSD-8 (current) kernel and world for the Marvel 
>>>> chipsets using the instructions here:
>>>> http://wiki.freebsd.org/FreeBSDMarvell
>>>>
>>>> When I tried booting a Sheevaplug (Marvel 88F6281), the system 
>>>> hangs as soon as I start it:
>>>
>>> Please show the output of the 'map' command at U-Boot prompt.
>>>
>> I apologize for the bad pasting job - I'll try again.  Hopefully this 
>> one is easier to read.
>>
>> Marvell>> map CPU Interface
>> -------------
>
> [...]
>
> I don't see any mismatches WRT internal SOC registers location etc. 
> and need to look a bit closer to the SheevaPlug docs.
>
> Just a basic clarification: you are 100% sure the correct DB-88F6XXX 
> kernel image is used, right?
>
> Rafal
>
I'm as sure as I can be.

[verify the directory on the FreeBSD machine is the 6XXX directory]
$ pwd
/usr/obj/arm/usr/src/sys/DB-88F6XXX
$ ls -la | grep kernel
-rwxr-xr-x  1 root  wheel  3656905 Apr 26 16:55 kernel
-rwxr-xr-x  1 root  wheel  2863204 Apr 26 16:55 kernel.bin
-rwxr-xr-x  1 root  wheel  1467105 Apr 26 16:55 kernel.gz.tramp
-rwxr-xr-x  1 root  wheel  1455194 Apr 26 16:55 kernel.gz.tramp.bin
-rwxr-xr-x  1 root  wheel  3494694 Apr 26 16:55 kernel.tramp
-rwxr-xr-x  1 root  wheel  3483799 Apr 26 16:55 kernel.tramp.bin
[copy kernel.bin to my tftp server as /tftpboot/sheeva/6XXXkernel.bin]
$ scp kernel.bin mythtv:/tftpboot/sheeva/6XXXkernel.bin
hayford@mythtv's password: 
 kernel.bin                                      0%    0     0.0KB/s   
--:-- ETA kernel.bin                                    100% 2796KB   
2.7MB/s   00:01    
[log onto tftp server and list the appropriate directory]
$ ssh mythtv
hayford@mythtv's password: 
Last login: Wed Apr 29 21:04:11 2009 from fed8-1 
hayford@mythtv$ cd /tftpboot/sheeva
hayford@mythtv$ ls -la
total 8428
drwxrwxr-x  2 hayford hayford    4096 2009-04-30 20:47 .
drwxrwxrwx 17 nobody  nobody     4096 2009-04-26 12:22 ..
-rwxr-xr-x  1 hayford hayford 2870196 2009-04-30 20:47 5XXXkernel.bin
-rwxr-xr-x  1 hayford hayford 2863204 2009-05-01 18:17 6XXXkernel.bin
-rwxr-xr-x  1 hayford hayford 2863204 2009-04-26 12:27 kernel.bin
hayford@mythtv$ exit
[now boot up the sheevaplug]
Marvell>> tftpboot 0x900000 sheeva/6XXXkernel.bin

Using egiga0 device
TFTP from server 192.168.1.102; our IP address is 192.168.1.246
Filename 'sheeva/6XXXkernel.bin'.
Load address: 0x900000
Loading: *#################################################################\
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
########################################
done
Bytes transferred = 2863204 (2bb064 hex)
Marvell>> go 0x900000
## Starting application at 0x00900000 ...
[sheevaplug hangs up]

Note that the file size that was loaded by UBoot was 2863204 bytes long, 
the same as the length of the file in the directory listing above.  The 
5XXX kernel is slightly longer at 2870196 bytes.

Thanks for looking into it.

Regards,
Don
From don at donhayford.com  Sat May  2 02:54:51 2009
From: don at donhayford.com (Donald T Hayford)
Date: Sat May  2 02:54:57 2009
Subject: Help with Marvel kernel for 88F5512
In-Reply-To: <1324A9FE-D45B-479E-9705-5FCFA2FAC9E0@semihalf.com>
References: <49FA5952.20800@donhayford.com>
	<1324A9FE-D45B-479E-9705-5FCFA2FAC9E0@semihalf.com>
Message-ID: <49FBB5F8.3090104@donhayford.com>

Rafal Jaworowski wrote:
>
> On 2009-05-01, at 04:07, Donald T Hayford wrote:
>> twsi0: <Marvell Integrated I2C Bus Controller> at mem 
>> 0xf1011000-0xf101101f on mbus0
>> iicbus0: <Philips I2C bus> on twsi0
>> iicbus0: <unknown card> at addr 0
>> iic0: <I2C generic I/O> on iicbus0
>> pcib1: <Marvell 88F5182 PCI-X host controller> at mem 
>> 0xf1030000-0xf1031fff on mbus0
>>
>> At this point, the device hangs until I reboot it.
>
> Could you please compile out PCI support to see whether this hang is 
> somehow PCI-related?
>
The Kurobox Pro appears to be booting more-or-less correctly now.  
Following is the boot up message.
Note towards the end a warning about "no time-of-day clock".  The kernel 
is also not recognizing the attached SATA drive (because PCI is 
disabled?) or USB disk.

## Starting application at 0x00900000 ...
KDB: debugger backends: ddb
KDB: current backend: ddb
Copyright (c) 1992-2009 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
    The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 8.0-CURRENT #1: Sat May  2 02:17:44 EDT 2009
    hayford@freeqemu:/usr/obj/arm/usr/src/sys/DB-88F5XXX
WARNING: WITNESS option enabled, expect reduced performance.
WARNING: DIAGNOSTIC option enabled, expect reduced performance.
Preloaded elf kernel "elf kernel" at 0xc0d1c598.
CPU: ARM926EJ-S rev 0 (ARM9EJ-S core)
  DC enabled IC enabled WB enabled EABT branch prediction enabled
  32KB/32B 1-way Instruction cache
  32KB/32B 1-way write-back-locking-C Data cache
real memory  = 134217728 (128 MB)
Physical memory chunk(s):
00000000 - 0x8fffff, 9437184 bytes (2304 pages)
0xe0d000 - 0x7d8efff, 116924416 bytes (28546 pages)
avail memory = 125353984 (119 MB)
SOC: (0x5182:0x02) Marvell 88F5182 rev A2, TClock 166MHz
mem: <memory>
nfslock: pseudo-device
null: <null device, zero device>
random: <entropy source, Software, Yarrow>
mbus0: <Marvell Internal Bus (Mbus)> on motherboard
ic0: <Marvell Integrated Interrupt Controller> at mem 
0xf1020200-0xf102023b on mbus0
timer0: <Marvell CPU Timer> at mem 0xf1020300-0xf102032f irq 0 on mbus0
timer0: [FILTER]
gpio0: <Marvell Integrated GPIO Controller> at mem 0xf1010100-0xf101011f 
irq 6,7,8,9 on mbus0
gpio0: [FILTER]
gpio0: [FILTER]
gpio0: [FILTER]
gpio0: [FILTER]
uart0: <16550 or compatible> at mem 0xf1012000-0xf101201f irq 3 on mbus0
uart0: [FILTER]
uart0: fast interrupt
uart0: console (115740,n,8,1)
uart1: <16550 or compatible> at mem 0xf1012100-0xf101211f irq 4 on mbus0
uart1: [FILTER]
uart1: fast interrupt
ehci0: <Marvell Integrated USB 2.0 controller> at mem 
0xf1050000-0xf1050fff irq 16,17 on mbus0
ehci0: [FILTER]
ehci0: [MPSAFE]
ehci0: [ITHREAD]
ehci0: 5.24 GL USB-2 workaround enabled
usbus0: EHCI version 1.0
usbus0: set host controller mode
usbus0: <Marvell Integrated USB 2.0 controller> on ehci0
mge0: <Marvell Gigabit Ethernet controller> at mem 0xf1072000-0xf1073fff 
irq 18,19,20,21,22 on mbus0
mge0: bpf attached
mge0: Ethernet address: 00:16:01:a4:e4:87
miibus0: <MII bus> on mge0
e1000phy0: <Marvell 88E1116 Gigabit PHY> PHY 8 on miibus0
e1000phy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 
1000baseTX-FDX, auto
mge0: [MPSAFE]
mge0: [ITHREAD]
mge0: [MPSAFE]
mge0: [ITHREAD]
twsi0: <Marvell Integrated I2C Bus Controller> at mem 
0xf1011000-0xf101101f on mbus0
iicbus0: <Philips I2C bus> on twsi0
iicbus0: <unknown card> at addr 0
iic0: <I2C generic I/O> on iicbus0
Timecounter "CPU Timer" frequency 166666667 Hz quality 1000
Timecounters tick every 1.000 msec
lo0: bpf attached
usbus0: 480Mbps High Speed USB v2.0
bootpc_init: wired to interface 'mge0'
Sending DHCP Discover packet from interface mge0 (00:16:01:a4:e4:87)
ugen0.1: <Marvell> at usbus0
uhub0: <Marvell EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus0
uhub0: 1 port with 1 removable, self powered
mge0: link state changed to UP
Received DHCP Offer packet on mge0 from 192.168.1.102 (accepted) (no 
root path)
Received DHCP Offer packet on mge0 from 192.168.1.1 (ignored) (no root path)
Sending DHCP Request packet from interface mge0 (00:16:01:a4:e4:87)
Received DHCP Ack packet on mge0 from 192.168.1.102 (accepted) (got root 
path)
mge0 at 192.168.1.178 server 192.168.1.102
subnet mask 255.255.255.0 router 192.168.1.1 root_server 192.168.1.102 
rootfs /export/client/froot
Adjusted interface mge0
WARNING: WITNESS option enabled, expect reduced performance.
WARNING: DIAGNOSTIC option enabled, expect reduced performance.
Trying to mount root from nfs:
NFS ROOT: 192.168.1.102:/export/client/froot
warning: no time-of-day clock registered, system time will not be set 
accurately
warning: no time-of-day clock registered, system time will not be set 
accurately
start_init: trying /sbin/init
Enter full pathname of shell or RETURN for /bin/sh:
# df
Filesystem                         512-blocks     Used     Avail 
Capacity  Mounted on
192.168.1.102:/export/client/froot  374169032 46198576 308657000    13%    /
devfs                                       2        2         0   
100%    /dev
#

Thanks,
Don
From jacques.fourie at gmail.com  Sat May  2 06:28:02 2009
From: jacques.fourie at gmail.com (Jacques Fourie)
Date: Sat May  2 06:28:08 2009
Subject: PXA27X support
In-Reply-To: <20090502002910.8890ddac.stas@FreeBSD.org>
References: <be2f52430905010626s212cf8ebt2a22899297629802@mail.gmail.com>
	<20090502002910.8890ddac.stas@FreeBSD.org>
Message-ID: <be2f52430905012327g33ff7193h9228b739d1a42e9e@mail.gmail.com>

On Fri, May 1, 2009 at 10:29 PM, Stanislav Sedov <stas@freebsd.org> wrote:
> On Fri, 1 May 2009 15:26:22 +0200
> Jacques Fourie <jacques.fourie@gmail.com> mentioned:
>
>> Hi,
>>
>> I've been working on getting FreeBSD to boot on my Yoggie
>> (http://www.yoggie.com/open-firewall-soho) platform.
>> The only major missing piece is that set_cpufuncs() doesn't support the PXA270 :
>>
>> --- a/sys/arm/arm/cpufunc.c
>> +++ b/sys/arm/arm/cpufunc.c
>> @@ -1192,6 +1192,7 @@ set_cpufuncs()
>> ?#ifdef CPU_XSCALE_PXA2X0
>> ? ? ? ? /* ignore core revision to test PXA2xx CPUs */
>> ? ? ? ? if ((cputype & ~CPU_ID_XSCALE_COREREV_MASK) == CPU_ID_PXA250 ||
>> + ? ? ? ? ? (cputype & ~CPU_ID_XSCALE_COREREV_MASK) == CPU_ID_PXA27X ||
>> ? ? ? ? ? ? (cputype & ~CPU_ID_XSCALE_COREREV_MASK) == CPU_ID_PXA210) {
>>
>> There are some other differences between the PXA255 and PXA270 such as
>> different gpio pins etc. but I'm
>> unsure as to what the best way is to handle this elegantly in the
>> current pxa code. Currently I'm using a bunch
>> of #ifdefs in files such as pxa_machdep.c.
>>
>
> Hi!
>
> Can you, please, share you code so we can see how to better intergrate
> it with the current code?

I'll be happy to share the code but I really need to clean it up first. I think
the PXA support can do with some seperation of functionality into board
support files. I'll try to put something together...

>
> --
> Stanislav Sedov
> ST4096-RIPE
>
> _______________________________________________
> freebsd-arm@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arm
> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org"
>
From raj at semihalf.com  Sat May  2 15:19:30 2009
From: raj at semihalf.com (Rafal Jaworowski)
Date: Sat May  2 15:19:37 2009
Subject: Help with Marvel kernel for 88F5512
In-Reply-To: <49FBB5F8.3090104@donhayford.com>
References: <49FA5952.20800@donhayford.com>
	<1324A9FE-D45B-479E-9705-5FCFA2FAC9E0@semihalf.com>
	<49FBB5F8.3090104@donhayford.com>
Message-ID: <8A5691CD-5E1B-4C5F-BC45-6AC8AEEEAD51@semihalf.com>


On 2009-05-02, at 04:54, Donald T Hayford wrote:

> Rafal Jaworowski wrote:
>>
>> On 2009-05-01, at 04:07, Donald T Hayford wrote:
>>> twsi0: <Marvell Integrated I2C Bus Controller> at mem  
>>> 0xf1011000-0xf101101f on mbus0
>>> iicbus0: <Philips I2C bus> on twsi0
>>> iicbus0: <unknown card> at addr 0
>>> iic0: <I2C generic I/O> on iicbus0
>>> pcib1: <Marvell 88F5182 PCI-X host controller> at mem  
>>> 0xf1030000-0xf1031fff on mbus0
>>>
>>> At this point, the device hangs until I reboot it.
>>
>> Could you please compile out PCI support to see whether this hang  
>> is somehow PCI-related?
>>
> The Kurobox Pro appears to be booting more-or-less correctly now.   
> Following is the boot up message.

It appears there are some problems around PCI then. Are there any  
peripheral devices behind the PCI bridge on the KBP device? Very  
likely the IRQ routing map is different on your board than the default  
(DB-88F5281 board). The pci_irq_map[] table (sys/arm/mv/orion/ 
db88f5xxx.c) needs to be verified against KBP interrupts connections  
and adjusted accordingly (actually a dedicated file should be provided  
as a final solution for your device: sys/arm/mv/orion/kuroboxpro.c or  
so, with with all board-specific items equivalent to what we have for  
DB- systems).

> Note towards the end a warning about "no time-of-day clock".  The  
> kernel is also not recognizing the attached SATA drive (because PCI  
> is disabled?) or USB disk.

Time of day wanings are likely due to no driver for the RTC part (the  
default compiled in is DS133x). What RTC chip is there on the KBP  
device?

There's no driver in the tree for the integrated SATA controller at  
the moment, but it's currently under work.

The problems with USB device not recognized could be related to the  
new USB stack, which wasn't much tested on MV systems. Please switch  
to the legacy stack and let us know if the problem persists.

Rafal

From raj at semihalf.com  Sat May  2 15:30:50 2009
From: raj at semihalf.com (Rafal Jaworowski)
Date: Sat May  2 15:30:55 2009
Subject: Help with Marvel kernel for 88F6281
In-Reply-To: <49FB8696.8020907@donhayford.com>
References: <49FA5B75.9090008@donhayford.com>
	<D12A7520-0AA8-4A25-8FF7-EE75FE91C89D@semihalf.com>
	<49FADE9B.1080806@donhayford.com>
	<494D378B-B243-4D97-8554-AC3E74A30B8C@semihalf.com>
	<49FB8696.8020907@donhayford.com>
Message-ID: <72D23F68-EE62-4297-88F4-6CA0132F0293@semihalf.com>


On 2009-05-02, at 01:32, Donald T Hayford wrote:

> Rafal Jaworowski wrote:
>>
>> On 2009-05-01, at 13:35, Donald T Hayford wrote:
>>
>>> Rafal Jaworowski wrote:
>>>>
>>>> On 2009-05-01, at 04:16, Donald T Hayford wrote:
>>>>
>>>>> I built FreeBSD-8 (current) kernel and world for the Marvel  
>>>>> chipsets using the instructions here:
>>>>> http://wiki.freebsd.org/FreeBSDMarvell
>>>>>
>>>>> When I tried booting a Sheevaplug (Marvel 88F6281), the system  
>>>>> hangs as soon as I start it:
>>>>
>>>> Please show the output of the 'map' command at U-Boot prompt.
>>>>
>>> I apologize for the bad pasting job - I'll try again.  Hopefully  
>>> this one is easier to read.
>>>
>>> Marvell>> map CPU Interface
>>> -------------
>>
>> [...]
>>
>> I don't see any mismatches WRT internal SOC registers location etc.  
>> and need to look a bit closer to the SheevaPlug docs.
>>
>> Just a basic clarification: you are 100% sure the correct  
>> DB-88F6XXX kernel image is used, right?
>>
>> Rafal
>>
> I'm as sure as I can be.
>
> [verify the directory on the FreeBSD machine is the 6XXX directory]

OK, thanks for verfiication.

> Marvell>> go 0x900000
> ## Starting application at 0x00900000 ...
> [sheevaplug hangs up]
>
> Note that the file size that was loaded by UBoot was 2863204 bytes  
> long, the same as the length of the file in the directory listing  
> above.  The 5XXX kernel is slightly longer at 2870196 bytes.

Please do a quick experiment: eliminate (#if 0) contents of the  
platform_mpp_init() in sys/arm/mv/kirkwood/db88f6xxx.c and recompile/ 
rerun. The SP device could have MPP/GPIO layed out differently (note  
you're using DB-88F6281 dev board configuration): we could be  
overwriting UART lines connection settings and hence lose console  
output.

Rafal

From channa.kad at gmail.com  Mon May  4 06:52:51 2009
From: channa.kad at gmail.com (Channa)
Date: Mon May  4 06:52:56 2009
Subject: strncmp issue
In-Reply-To: <200904301705.n3UH5wg2057498@casselton.net>
References: <20090430.000846.1484329326.imp@bsdimp.com>
	<200904301705.n3UH5wg2057498@casselton.net>
Message-ID: <515c64960905032352j25edfbcajb3d146fa769b97bb@mail.gmail.com>

Hi,
Thanks for the fix.
I used your code and tested it works fine.
But i have one doubt in the code below you have added
:
 -        cmpcs r2, #1
 +       beq     2f
 +       cmp     r2, #1
:

Instead of the branch instruction above replace the instruction
'cmpcs' with 'cmp'
since we are comparing unsigned value in 'r2' with a constant.

So the code looks as below

:
-  cmpcs r2, #1
+ cmp   r2, #1
:

I have tested the above fix it works good for me.

Please let me know your views.

Thanks & Regards,
Channa


2009/4/30 Mark Tinguely <tinguely@casselton.net>:
>
>> ?Yes. ?We should get the following results:
>>
>> ? ? ? strncmp("a", "b", 0); ? ? 0
>> ? ? ? strncmp("a", "b", *); ? ? < 0
>>
>> ?where * is any other number :)
>>
>> ?Warner
>
> ENTRY(strncmp)
> /* if (len == 0) return 0 */
> ? ? ? ?cmp ? ? r2, #0
> ? ? ? ?moveq ? r0, #0
> ? ? ? ?RETeq
>
> /* ip == last src address to compare */
> ? ? ? ?add ? ? ip, r0, r2
> 1:
> ? ? ? ?ldrb ? ?r2, [r0], #1
> ? ? ? ?ldrb ? ?r3, [r1], #1
> ? ? ? ?cmp ? ? ip, r0
> - ? ? ? cmpcs ? r2, #1
> + ? ? ? beq ? ? 2f
> + ? ? ? cmp ? ? r2, #1
> ? ? ? ?cmpcs ? r2, r3
> ? ? ? ?beq ? ? 1b
> +2:
> ? ? ? ?sub ? ? r0, r2, r3
> ? ? ? ?RET
>
> also ip < r0 if r2 = (unsigned int) -1 using 32 bit math. so original
> loop will terminate and compare the first characters. For example
> strncmp("ab", "aa", -1) will result is 0.
>
> I sent Olivier a couple patches, both wrong. Again, sorry for all the noise.
>
> The above code, though, should work in all cases.
>
> ? ? ? ?strncmp("b", "a", 0) ?result is 0
> ? ? ? ?strncmp("abcdef", "abcdef", n) ?result is 0
> ? ? ? ?strncmp("abcde", "abcdef", n) ? 0 if 0 <= n < 6 ?neg if n < 0 or n > 5
> ? ? ? ?strncmp("abcdef", "abcde", n) ? 0 if 0 <= n < 6 ?pos if n < 0 or n > 5
>
>
> The "beq" will break out of the loop if we give a count <= the string
> length the first arguement.
>
> The next cmp looks for the NULL byte, and the last cmp checks the characters
> in the strings.
>
> --Mark.
>
From venkiece2005 at gmail.com  Mon May  4 07:27:05 2009
From: venkiece2005 at gmail.com (venki kaps)
Date: Mon May  4 07:27:11 2009
Subject: Regarding strncmp fix
Message-ID: <6d53329e0905040003sf72dddax16512347142ade3c@mail.gmail.com>

Hi,
 This is my idea only.

strncmp problem report:
========================
In the following below website:
*http://archive.netbsd.se/?ml=freebsd-arm&a=2009-04&m=10547557*

Hi,

 I am using the freebsd implementation of strncmp for ARM which is an

 assembly implementation.



 I have a small doubt, when i tested the strncmp by passing the third
argument:

 'n' as -1 the return values is '0' instead it should '-1'.



 When the third argument to strncmp is as below:

      ret = strncmp("a","b",-1)



I think the assembly implementation in > src/lib/libc/arm/string/strncmp.S
file needs

to be modified to take care of the above condition.

In the current implementation



 /* if ((len - 1)

subs r2, r2, #1

movmi r0, #0

RETc(mi)



This should be changed to check as below

 /* if ((len ) /* Assembly code here */



FreeBSD source:

===============



ENTRY(strncmp)

/* if ((len - 1) < 0) return 0 */

      subs  r2, r2, #1

      movmi r0, #0

      RETc(mi)



/* ip == last src address to compare */

      add   ip, r0, r2

1:

      ldrb  r2, [r0], #1

      ldrb  r3, [r1], #1

      cmp   ip, r0

      cmpcs r2, #1

      cmpcs r2, r3

      beq   1b

      sub   r0, r2, r3

      RET





Tinguely has given one solution for this:



ENTRY(strncmp)

      /* if (len == 0) return 0 */

      cmp r2, #0

      moveq r0, #0

      RETeq

      /* ip == last src address to compare */

      add ip, r0, r2

1:

      ldrb r2, [r0], #1

      ldrb r3, [r1], #1

      cmp ip, r0

-     cmpcs r2, #1

+     beq 2f

+     cmp r2, #1

      cmpcs r2, r3

      beq 1b

+2:

      sub r0, r2, r3

      RET



The above fix is nice.



But small change in the fix:



ENTRY(strncmp)

      /* if (len == 0) return 0 */

      cmp r2, #0

      moveq r0, #0

      RETeq

      /* ip == last src address to compare */

      add ip, r0, r2

1:

      ldrb r2, [r0], #1

      ldrb r3, [r1], #1

      cmp ip, r0

-     cmpcs r2, #1

+     cmp r2, #1 /* to igonre Carry falg set (unsigned higher or same) */

      cmpcs r2, r3

      beq 1b

      sub r0, r2, r3

      RET



Branch to 2f is not required since conditional

assemblers automatically calls subroutine when

compare fails.

And also we can reduce no. of cycles(3 cycles) since
3 cycles required to branch.





But I have one smaller query:

Will it support the above code in the ARM-thumb mode?



NOTE:

      Thumb mode and traditional mode instruction sets are different.



Thumb mode implementation:



/* if (len == 0) return 0 */

      cmp r2, #0

      bne 1f

      mov r0, #0

      RET

1:

      /* ip == last src address to compare */

      add ip, r0, r2

2:

      cmp ip, r0

      beq 3f

      ldrb r2, [r0]

      add r0, r0, #1

      ldrb r3, [r1]

      add r1, r1, #1

      cmp r2, #0

      beq 3f

      cmp r2, r3

      beq 2b

3:

      sub r0, r2, r3

      RET



Will need to support both thumb mode as well as traditional mode?



Example:

#ifdef __thumb__

      /* thumb code here */

#else

      /* traditional code here */

#endif





Thanks & Regards,

Venkappa
From bugmaster at FreeBSD.org  Mon May  4 11:07:43 2009
From: bugmaster at FreeBSD.org (FreeBSD bugmaster)
Date: Mon May  4 11:08:05 2009
Subject: Current problem reports assigned to freebsd-arm@FreeBSD.org
Message-ID: <200905041107.n44B7fJW098409@freefall.freebsd.org>

Note: to view an individual PR, use:
  http://www.freebsd.org/cgi/query-pr.cgi?pr=(number).

The following is a listing of current problems submitted by FreeBSD users.
These represent problem reports covering all versions including
experimental development code and obsolete releases.


S Tracker      Resp.      Description
--------------------------------------------------------------------------------
o arm/134092   arm        [patch] NSLU.hints contains wrong hints for on board n

1 problem total.

From tinguely at casselton.net  Mon May  4 13:01:16 2009
From: tinguely at casselton.net (Mark Tinguely)
Date: Mon May  4 13:01:23 2009
Subject: strncmp issue
In-Reply-To: <515c64960905032352j25edfbcajb3d146fa769b97bb@mail.gmail.com>
Message-ID: <200905041259.n44CxtV2077931@casselton.net>


Hi, the propose code by both of you two:

/* if (len == 0) return 0 */
	cmp	r2, #0
	moveq	r0, #0
	moveq	pc, lr

/* ip == last src address to compare */
	add	ip, r0, r2
1:
	ldrb	r2, [r0], #1
	ldrb	r3, [r1], #1
	cmp	ip, r0
	cmp	r2, #1
	cmpcs	r2, r3
	beq	1b
	sub	r0, r2, r3

That was one of my failed attempts. I to was hoping to not add the branch
to cut down in cycles. A person has to test every possible call to strncmp.
This will fail on a positive string length less than strlen length of the
input strings:

strncmp("abcdefg", "abcdefh", 6)

Will return (-1) str1 < str2 at 6 characters which is wrong.


/* if (len == 0) return 0 */
	cmp	r2, #0
	moveq	r0, #0
	moveq	pc, lr

/* ip == last src address to compare */
	add	ip, r0, r2
1:
	ldrb	r2, [r0], #1
	ldrb	r3, [r1], #1
	cmp	ip, r0
	beq	2f		<- stops in the case where strlen(s1) > len
	cmp	r2, #1		<- stops thea NULL case, we can't just change
				   the comparison because below we loop on
				   an equality and can end up in a big loop
				
	cmpcs	r2, r3		<- compare characters.
	beq	1b
2:
	sub	r0, r2, r3

From don at donhayford.com  Tue May  5 00:12:21 2009
From: don at donhayford.com (Donald T Hayford)
Date: Tue May  5 00:12:28 2009
Subject: Help with Marvel kernel for 88F6281
In-Reply-To: <72D23F68-EE62-4297-88F4-6CA0132F0293@semihalf.com>
References: <49FA5B75.9090008@donhayford.com>
	<D12A7520-0AA8-4A25-8FF7-EE75FE91C89D@semihalf.com>
	<49FADE9B.1080806@donhayford.com>
	<494D378B-B243-4D97-8554-AC3E74A30B8C@semihalf.com>
	<49FB8696.8020907@donhayford.com>
	<72D23F68-EE62-4297-88F4-6CA0132F0293@semihalf.com>
Message-ID: <49FF8461.6020406@donhayford.com>

Rafal Jaworowski wrote:
>
> On 2009-05-02, at 01:32, Donald T Hayford wrote:
>
>> Rafal Jaworowski wrote:
>>>
>>> On 2009-05-01, at 13:35, Donald T Hayford wrote:
>>>
>>>> Rafal Jaworowski wrote:
>>>>
>>>
>>> [...]
>>>
>>> I don't see any mismatches WRT internal SOC registers location etc. 
>>> and need to look a bit closer to the SheevaPlug docs.
>>>
>>> Just a basic clarification: you are 100% sure the correct DB-88F6XXX 
>>> kernel image is used, right?
>>>
>>> Rafal
>>>
>> I'm as sure as I can be.
>>
>> [verify the directory on the FreeBSD machine is the 6XXX directory]
>
> OK, thanks for verfiication.
>
>> Marvell>> go 0x900000
>> ## Starting application at 0x00900000 ...
>> [sheevaplug hangs up]
>>
>> Note that the file size that was loaded by UBoot was 2863204 bytes 
>> long, the same as the length of the file in the directory listing 
>> above.  The 5XXX kernel is slightly longer at 2870196 bytes.
>
> Please do a quick experiment: eliminate (#if 0) contents of the 
> platform_mpp_init() in sys/arm/mv/kirkwood/db88f6xxx.c and 
> recompile/rerun. The SP device could have MPP/GPIO layed out 
> differently (note you're using DB-88F6281 dev board configuration): we 
> could be overwriting UART lines connection settings and hence lose 
> console output.
>
> Rafal
>
Commented out all of the code in 
/usr/src/sys/arm/mv/kirkwood/db88f6xxx.c/platform_mpp_init().  New 
kernel size is 2862968; i.e., 336 bytes shorter.

Unfortunately, the same result:
Marvell>> go 0x900000
## Starting application at 0x00900000 ...
[sheevaplug hangs up]

Regards,
Don
From venkiece2005 at gmail.com  Tue May  5 07:04:21 2009
From: venkiece2005 at gmail.com (venki kaps)
Date: Tue May  5 07:04:41 2009
Subject: strncmp issue
In-Reply-To: <200905041259.n44CxtV2077931@casselton.net>
References: <515c64960905032352j25edfbcajb3d146fa769b97bb@mail.gmail.com>
	<200905041259.n44CxtV2077931@casselton.net>
Message-ID: <6d53329e0905050004k27d957bve15d37113b5fedbb@mail.gmail.com>

Hi,

I have tested strncmp("abcdefg", "abcdefh", 6) without beq   2f.
It returns zero not -1.

I have checked with conditional assembler but not normal assembler.
The beq 2f  is required for normal assembler.
Right/Wrong?

However also checked with strncmp.c implementation:

int strnncmp(const char *s1, const char *s2, size_t n) {
        if (n == 0)
                return (0);
        do {
                if (*s1 != *s2++)
                        return (*(const unsigned char *)s1 -
                            *(const unsigned char *)--s2);
                if (*s1++ == 0)
                        break;
        } while (--n != 0);
        return (0);
}
the equivalent assembly code:

        cmp     r2, #0
        mov     ip, r0
        beq     2f
1:
        ldrb    r0, [ip, #0]
        ldrb    r3, [r1], #1
        add     ip, ip, #1
        cmp     r0, r3
        bne     3f
        cmp     r0, #0
        beq     2f
        subs    r2, r2, #1
        bne     1b
2:
        mov     r0, #0
        mov     pc, lr
3:
        ldrb    r3, [r1, #-1]
        rsb     r0, r3, r0 /* operand2 - operand1 */
        mov     pc, lr

The results are same.

what could you suggest?

Thanks & Regards,
Venkappa

On Mon, May 4, 2009 at 6:29 PM, Mark Tinguely <tinguely@casselton.net>wrote:

>
> Hi, the propose code by both of you two:
>
> /* if (len == 0) return 0 */
>        cmp     r2, #0
>        moveq   r0, #0
>        moveq   pc, lr
>
> /* ip == last src address to compare */
>        add     ip, r0, r2
> 1:
>        ldrb    r2, [r0], #1
>        ldrb    r3, [r1], #1
>        cmp     ip, r0
>        cmp     r2, #1
>        cmpcs   r2, r3
>        beq     1b
>        sub     r0, r2, r3
>
> That was one of my failed attempts. I to was hoping to not add the branch
> to cut down in cycles. A person has to test every possible call to strncmp.
> This will fail on a positive string length less than strlen length of the
> input strings:
>
> strncmp("abcdefg", "abcdefh", 6)
>
> Will return (-1) str1 < str2 at 6 characters which is wrong.
>
>
> /* if (len == 0) return 0 */
>        cmp     r2, #0
>        moveq   r0, #0
>        moveq   pc, lr
>
> /* ip == last src address to compare */
>        add     ip, r0, r2
> 1:
>        ldrb    r2, [r0], #1
>        ldrb    r3, [r1], #1
>        cmp     ip, r0
>        beq     2f              <- stops in the case where strlen(s1) > len
>        cmp     r2, #1          <- stops thea NULL case, we can't just
> change
>                                   the comparison because below we loop on
>                                   an equality and can end up in a big loop
>
>        cmpcs   r2, r3          <- compare characters.
>        beq     1b
> 2:
>        sub     r0, r2, r3
>
>
From venkiece2005 at gmail.com  Tue May  5 10:20:35 2009
From: venkiece2005 at gmail.com (venki kaps)
Date: Tue May  5 10:20:41 2009
Subject: strncmp issue
In-Reply-To: <6d53329e0905050004k27d957bve15d37113b5fedbb@mail.gmail.com>
References: <515c64960905032352j25edfbcajb3d146fa769b97bb@mail.gmail.com>
	<200905041259.n44CxtV2077931@casselton.net>
	<6d53329e0905050004k27d957bve15d37113b5fedbb@mail.gmail.com>
Message-ID: <6d53329e0905050320q5c7480e9h4bcb629222fce16@mail.gmail.com>

Conditional compares are difficult but compilers are very good at:

if (len == 0) return 0;

cmp r2, 0
moveq r0, #0
moveq pc, lr

while (r0 = *s1++, r1 = *s2++, ip = r0 + len;  ip == r0 && r0 >= 1 && r0 ==
r1);
    add ip, r0, r2
loop
  ldrb r0, [s1],#1
  ldrb r1, [s2],#1
  cmp ip, r0
  cmp r0,#1
  cmpcs r0,r1
  beq loop
  subroutine here

Regards,
Venkappa

On Tue, May 5, 2009 at 12:34 PM, venki kaps <venkiece2005@gmail.com> wrote:

> Hi,
>
> I have tested strncmp("abcdefg", "abcdefh", 6) without beq   2f.
> It returns zero not -1.
>
> I have checked with conditional assembler but not normal assembler.
> The beq 2f  is required for normal assembler.
> Right/Wrong?
>
> However also checked with strncmp.c implementation:
>
> int strnncmp(const char *s1, const char *s2, size_t n) {
>         if (n == 0)
>                 return (0);
>         do {
>                 if (*s1 != *s2++)
>                         return (*(const unsigned char *)s1 -
>                             *(const unsigned char *)--s2);
>                 if (*s1++ == 0)
>                         break;
>         } while (--n != 0);
>         return (0);
> }
> the equivalent assembly code:
>
>         cmp     r2, #0
>         mov     ip, r0
>         beq     2f
> 1:
>         ldrb    r0, [ip, #0]
>         ldrb    r3, [r1], #1
>         add     ip, ip, #1
>         cmp     r0, r3
>         bne     3f
>         cmp     r0, #0
>         beq     2f
>         subs    r2, r2, #1
>         bne     1b
> 2:
>         mov     r0, #0
>         mov     pc, lr
> 3:
>         ldrb    r3, [r1, #-1]
>         rsb     r0, r3, r0 /* operand2 - operand1 */
>         mov     pc, lr
>
> The results are same.
>
> what could you suggest?
>
> Thanks & Regards,
> Venkappa
>
> On Mon, May 4, 2009 at 6:29 PM, Mark Tinguely <tinguely@casselton.net>wrote:
>
>>
>> Hi, the propose code by both of you two:
>>
>> /* if (len == 0) return 0 */
>>        cmp     r2, #0
>>        moveq   r0, #0
>>        moveq   pc, lr
>>
>> /* ip == last src address to compare */
>>        add     ip, r0, r2
>> 1:
>>        ldrb    r2, [r0], #1
>>        ldrb    r3, [r1], #1
>>        cmp     ip, r0
>>        cmp     r2, #1
>>        cmpcs   r2, r3
>>        beq     1b
>>        sub     r0, r2, r3
>>
>> That was one of my failed attempts. I to was hoping to not add the branch
>> to cut down in cycles. A person has to test every possible call to
>> strncmp.
>> This will fail on a positive string length less than strlen length of the
>> input strings:
>>
>> strncmp("abcdefg", "abcdefh", 6)
>>
>> Will return (-1) str1 < str2 at 6 characters which is wrong.
>>
>>
>> /* if (len == 0) return 0 */
>>        cmp     r2, #0
>>        moveq   r0, #0
>>        moveq   pc, lr
>>
>> /* ip == last src address to compare */
>>        add     ip, r0, r2
>> 1:
>>        ldrb    r2, [r0], #1
>>        ldrb    r3, [r1], #1
>>        cmp     ip, r0
>>        beq     2f              <- stops in the case where strlen(s1) > len
>>        cmp     r2, #1          <- stops thea NULL case, we can't just
>> change
>>                                   the comparison because below we loop on
>>                                   an equality and can end up in a big loop
>>
>>        cmpcs   r2, r3          <- compare characters.
>>        beq     1b
>> 2:
>>        sub     r0, r2, r3
>>
>>
>
From tinguely at casselton.net  Tue May  5 13:17:57 2009
From: tinguely at casselton.net (Mark Tinguely)
Date: Tue May  5 13:18:52 2009
Subject: strncmp issue
In-Reply-To: <6d53329e0905050004k27d957bve15d37113b5fedbb@mail.gmail.com>
Message-ID: <200905051317.n45DHtKW044428@casselton.net>


>  I have tested strncmp("abcdefg", "abcdefh", 6) without beq   2f.
>  It returns zero not -1.
>
>  I have checked with conditional assembler but not normal assembler.
>  The beq 2f  is required for normal assembler.
>  Right/Wrong?

Yes, the compiler with FreeBSD-current needs the "beq 2f".

Can can one do 2 unconditional "cmp" in sequence without losing the condition
codes of the first "cmp"?

I am sure this is becoming a 'bikeshed' topic. I built way more than my
share of the shed. So, as long as it works, I will be happy.

--Mark.
From imp at bsdimp.com  Tue May  5 14:19:14 2009
From: imp at bsdimp.com (M. Warner Losh)
Date: Tue May  5 14:19:20 2009
Subject: strncmp issue
In-Reply-To: <200905051317.n45DHtKW044428@casselton.net>
References: <6d53329e0905050004k27d957bve15d37113b5fedbb@mail.gmail.com>
	<200905051317.n45DHtKW044428@casselton.net>
Message-ID: <20090505.081701.569396874.imp@bsdimp.com>

In message: <200905051317.n45DHtKW044428@casselton.net>
            Mark Tinguely <tinguely@casselton.net> writes:
: 
: >  I have tested strncmp("abcdefg", "abcdefh", 6) without beq   2f.
: >  It returns zero not -1.
: >
: >  I have checked with conditional assembler but not normal assembler.
: >  The beq 2f  is required for normal assembler.
: >  Right/Wrong?
: 
: Yes, the compiler with FreeBSD-current needs the "beq 2f".
: 
: Can can one do 2 unconditional "cmp" in sequence without losing the condition
: codes of the first "cmp"?
: 
: I am sure this is becoming a 'bikeshed' topic. I built way more than my
: share of the shed. So, as long as it works, I will be happy.

Is the hand rolled assembler still better than what gcc can produce?

Warner
From tinguely at casselton.net  Tue May  5 16:37:20 2009
From: tinguely at casselton.net (Mark Tinguely)
Date: Tue May  5 16:37:26 2009
Subject: strncmp issue
In-Reply-To: <20090505.081701.569396874.imp@bsdimp.com>
Message-ID: <200905051637.n45GbE7Q057469@casselton.net>


>  Is the hand rolled assembler still better than what gcc can produce?
>
>  Warner

Assuming my additional conditional branch, we can save at least an add and
a branch in the comparison loop with the hard rolled assembler over the
"cc -O2 head/lib/libc/string/strncmp.c" code.

If the conditional branch can be deleted, then even better.

--Mark.
From rpaulo at gmail.com  Wed May  6 17:22:40 2009
From: rpaulo at gmail.com (Rui Paulo)
Date: Wed May  6 17:23:12 2009
Subject: Can't build ports and/or system on HEAD
Message-ID: <1D99BB94-12E9-4425-AA1D-0CC3FAFF016C@gmail.com>

Hi,
I can't build ports on an arm embedded system. After the recent  
strncmp() problem, I'm suspecting this is a fallout of something than  
a misconfiguration of my part.

My sys.mk MD5 is:
$ md5 /usr/share/mk/sys.mk
MD5 (/usr/share/mk/sys.mk) = 5f02492bd3dc89d976067eeaa75d4d76

Which I think is correct. Any ideas?

# make -d A
Global:.MAKEFLAGS =  -d
Global:.MAKEFLAGS =  -d A
Global:MFLAGS =  -d
Global:MFLAGS =  -d A
Caching ....done
Global:.ST_EXPORTVAR = YES
Global:.CURDIR = /usr/ports/editors/elvis
Global:.OBJDIR = /usr/ports/editors/elvis
Global:.TARGETS =
Caching /usr/share/mk...done
expanding "sys.mk".../usr/share/mk/sys.mk
Global:MAKEFILE = /usr/share/mk/sys.mk
Global:.MAKEFILE_LIST = /usr/share/mk/sys.mk
Global:unix = We run FreeBSD, not UNIX.
Global:.FreeBSD = true
"/usr/share/mk/sys.mk", line 16: Missing dependency operator
"/usr/share/mk/sys.mk", line 18: if-less else
"/usr/share/mk/sys.mk", line 20: if-less endif
Global:AR = ar
"/usr/share/mk/sys.mk", line 23: Missing dependency operator
Global:ARFLAGS = -rv
"/usr/share/mk/sys.mk", line 25: if-less else
"/usr/share/mk/sys.mk", line 27: if-less endif
Global:RANLIB = ranlib
Global:AS = as
Global:AFLAGS =
"/usr/share/mk/sys.mk", line 33: Missing dependency operator
Global:CC = c89
Global:CFLAGS = -O
"/usr/share/mk/sys.mk", line 36: if-less else
"/usr/share/mk/sys.mk", line 38: Need an operator
"/usr/share/mk/sys.mk", line 40: if-less else
"/usr/share/mk/sys.mk", line 42: if-less endif
"/usr/share/mk/sys.mk", line 43: Missing dependency operator
Global:CFLAGS = -O -fno-strict-aliasing
"/usr/share/mk/sys.mk", line 45: if-less endif
"/usr/share/mk/sys.mk", line 46: if-less endif
Global:NO_CTF = 1
"/usr/share/mk/sys.mk", line 52: if-less endif
Global:CTFFLAGS = -L VERSION
Global:CTFCONVERT = ctfconvert
Global:CTFMERGE = ctfmerge
Applying :M to "-O -fno-strict-aliasing"
Result is ""
"/usr/share/mk/sys.mk", line 60: Missing dependency operator
Global:CTFFLAGS = -L VERSION -g
"/usr/share/mk/sys.mk", line 62: if-less else
Global:CFLAGS = -O -fno-strict-aliasing -g
"/usr/share/mk/sys.mk", line 64: if-less endif
"/usr/share/mk/sys.mk", line 65: if-less endif
Global:CXX = c++
Global:CXXFLAGS = ${CFLAGS:N-std=*:N-Wnested-externs:N-W*-prototypes:N- 
Wno-pointer-sign}
Global:CPP = cpp
"/usr/share/mk/sys.mk", line 72: Missing dependency operator
Global:ECHO = echo
Global:ECHODIR = echo
"/usr/share/mk/sys.mk", line 75: if-less else
Applying :M to " -d A"
Result is ""
"/usr/share/mk/sys.mk", line 77: Need an operator
"/usr/share/mk/sys.mk", line 79: if-less else
"/usr/share/mk/sys.mk", line 81: if-less endif
"/usr/share/mk/sys.mk", line 82: if-less endif
Applying :M to " -d A"
Result is ""
Global:_+_ =
"/usr/share/mk/sys.mk", line 86: if-less else
"/usr/share/mk/sys.mk", line 88: if-less endif
"/usr/share/mk/sys.mk", line 90: Missing dependency operator
Global:FC = fort77
Global:FFLAGS = -O 1
"/usr/share/mk/sys.mk", line 93: if-less else
"/usr/share/mk/sys.mk", line 96: if-less endif
Global:EFLAGS =
Global:INSTALL = install
Global:LEX = lex
Global:LFLAGS =
Global:LD = ld
Global:LDFLAGS =
Global:LINT = lint
Global:LINTFLAGS = -cghapbx
Global:LINTKERNFLAGS = ${LINTFLAGS}
Global:LINTOBJFLAGS = -cghapbxu -i
Global:LINTOBJKERNFLAGS = ${LINTOBJFLAGS}
Global:LINTLIBFLAGS = -cghapbxu -C ${LIB}
Global:OBJC = cc
Global:OBJCFLAGS = ${OBJCINCLUDES} ${CFLAGS} -Wno-import
Global:PC = pc
Global:PFLAGS =
Global:RC = f77
Global:RFLAGS =
Global:YACC = yacc
"/usr/share/mk/sys.mk", line 128: Missing dependency operator
Global:YFLAGS =
"/usr/share/mk/sys.mk", line 130: if-less else
"/usr/share/mk/sys.mk", line 132: if-less endif
"/usr/share/mk/sys.mk", line 134: Missing dependency operator
defining transformation from `.c' to `'
inserting an empty list?...inserting .c(2)...at end of list
inserting an empty list?...inserting (0)...at end of list
transformation .c complete
"/usr/share/mk/sys.mk", line 145: Missing dependency operator
"/usr/share/mk/sys.mk", line 147: if-less endif
defining transformation from `.f' to `'
inserting .f(7)...at end of list
inserting an empty list?...inserting (0)...at end of list
transformation .f complete
"/usr/share/mk/sys.mk", line 151: Missing dependency operator
"/usr/share/mk/sys.mk", line 152: warning: duplicate script for target  
".if" ignored
"/usr/share/mk/sys.mk", line 152: warning: duplicate script for target  
"defined(CTFCONVERT)" ignored
"/usr/share/mk/sys.mk", line 153: if-less endif
defining transformation from `.sh' to `'
inserting .sh(6)...before .f(7)
inserting an empty list?...inserting (0)...at end of list
transformation .sh complete
"/usr/share/mk/sys.mk", line 163: Missing dependency operator
"/usr/share/mk/sys.mk", line 164: warning: duplicate script for target  
".if" ignored
"/usr/share/mk/sys.mk", line 164: warning: duplicate script for target  
"defined(CTFCONVERT)" ignored
"/usr/share/mk/sys.mk", line 165: if-less endif
"/usr/share/mk/sys.mk", line 169: Missing dependency operator
"/usr/share/mk/sys.mk", line 170: warning: duplicate script for target  
".if" ignored
"/usr/share/mk/sys.mk", line 170: warning: duplicate script for target  
"defined(CTFCONVERT)" ignored
"/usr/share/mk/sys.mk", line 171: if-less endif
"/usr/share/mk/sys.mk", line 178: Missing dependency operator
"/usr/share/mk/sys.mk", line 179: warning: duplicate script for target  
".if" ignored
"/usr/share/mk/sys.mk", line 179: warning: duplicate script for target  
"defined(CTFCONVERT)" ignored
"/usr/share/mk/sys.mk", line 180: if-less endif
"/usr/share/mk/sys.mk", line 187: Missing dependency operator
"/usr/share/mk/sys.mk", line 188: warning: duplicate script for target  
".if" ignored
"/usr/share/mk/sys.mk", line 188: warning: duplicate script for target  
"defined(CTFCONVERT)" ignored
"/usr/share/mk/sys.mk", line 189: if-less endif
"/usr/share/mk/sys.mk", line 209: if-less else
defining transformation from `.sh' to `'
inserting .sh(6)...already there
inserting (0)...already there
transformation .sh complete
defining transformation from `.c' to `'
inserting .c(2)...already there
inserting (0)...already there
transformation .c complete
"/usr/share/mk/sys.mk", line 227: Missing dependency operator
"/usr/share/mk/sys.mk", line 228: warning: duplicate script for target  
".if" ignored
"/usr/share/mk/sys.mk", line 228: warning: duplicate script for target  
"defined(CTFCONVERT)" ignored
"/usr/share/mk/sys.mk", line 229: if-less endif
"/usr/share/mk/sys.mk", line 232: warning: duplicate script for target  
".c.o" ignored
"/usr/share/mk/sys.mk", line 233: Missing dependency operator
"/usr/share/mk/sys.mk", line 234: warning: duplicate script for target  
".if" ignored
"/usr/share/mk/sys.mk", line 234: warning: duplicate script for target  
"defined(CTFCONVERT)" ignored
"/usr/share/mk/sys.mk", line 235: if-less endif
defining transformation from `.cc' to `'
inserting .cc(10)...at end of list
inserting an empty list?...inserting (0)...at end of list
defining transformation from `.cpp' to `'
inserting .cpp(11)...at end of list
inserting an empty list?...inserting (0)...at end of list
defining transformation from `.cxx' to `'
inserting .cxx(12)...at end of list
inserting an empty list?...inserting (0)...at end of list
defining transformation from `.C' to `'
inserting .C(13)...at end of list
inserting an empty list?...inserting (0)...at end of list
transformation .cc complete
transformation .cpp complete
transformation .cxx complete
transformation .C complete
"/usr/share/mk/sys.mk", line 245: Missing dependency operator
"/usr/share/mk/sys.mk", line 246: warning: duplicate script for target  
".if" ignored
"/usr/share/mk/sys.mk", line 246: warning: duplicate script for target  
"defined(CTFCONVERT)" ignored
"/usr/share/mk/sys.mk", line 247: if-less endif
"/usr/share/mk/sys.mk", line 251: Missing dependency operator
"/usr/share/mk/sys.mk", line 252: warning: duplicate script for target  
".if" ignored
"/usr/share/mk/sys.mk", line 252: warning: duplicate script for target  
"defined(CTFCONVERT)" ignored
"/usr/share/mk/sys.mk", line 253: if-less endif
defining transformation from `.e' to `'
inserting .e(16)...at end of list
inserting an empty list?...inserting (0)...at end of list
defining transformation from `.r' to `'
inserting .r(17)...at end of list
inserting an empty list?...inserting (0)...at end of list
defining transformation from `.F' to `'
inserting .F(15)...before .e(16)
inserting an empty list?...inserting (0)...at end of list
defining transformation from `.f' to `'
inserting .f(7)...already there
inserting (0)...already there
transformation .e complete
transformation .r complete
transformation .F complete
transformation .f complete
"/usr/share/mk/sys.mk", line 260: warning: duplicate script for target  
".f.o" ignored
"/usr/share/mk/sys.mk", line 264: Missing dependency operator
"/usr/share/mk/sys.mk", line 265: warning: duplicate script for target  
".if" ignored
"/usr/share/mk/sys.mk", line 265: warning: duplicate script for target  
"defined(CTFCONVERT)" ignored
"/usr/share/mk/sys.mk", line 266: if-less endif
"/usr/share/mk/sys.mk", line 270: Missing dependency operator
"/usr/share/mk/sys.mk", line 271: warning: duplicate script for target  
".if" ignored
"/usr/share/mk/sys.mk", line 271: warning: duplicate script for target  
"defined(CTFCONVERT)" ignored
"/usr/share/mk/sys.mk", line 272: if-less endif
"/usr/share/mk/sys.mk", line 276: Missing dependency operator
"/usr/share/mk/sys.mk", line 277: warning: duplicate script for target  
".if" ignored
"/usr/share/mk/sys.mk", line 277: warning: duplicate script for target  
"defined(CTFCONVERT)" ignored
"/usr/share/mk/sys.mk", line 278: if-less endif
"/usr/share/mk/sys.mk", line 282: warning: duplicate script for target  
".y.o" ignored
"/usr/share/mk/sys.mk", line 283: warning: duplicate script for target  
".y.o" ignored
"/usr/share/mk/sys.mk", line 284: warning: duplicate script for target  
".y.o" ignored
"/usr/share/mk/sys.mk", line 285: Missing dependency operator
"/usr/share/mk/sys.mk", line 286: warning: duplicate script for target  
".if" ignored
"/usr/share/mk/sys.mk", line 286: warning: duplicate script for target  
"defined(CTFCONVERT)" ignored
"/usr/share/mk/sys.mk", line 287: if-less endif
"/usr/share/mk/sys.mk", line 290: warning: duplicate script for target  
".l.o" ignored
"/usr/share/mk/sys.mk", line 291: warning: duplicate script for target  
".l.o" ignored
"/usr/share/mk/sys.mk", line 292: warning: duplicate script for target  
".l.o" ignored
"/usr/share/mk/sys.mk", line 293: Missing dependency operator
"/usr/share/mk/sys.mk", line 294: warning: duplicate script for target  
".if" ignored
"/usr/share/mk/sys.mk", line 294: warning: duplicate script for target  
"defined(CTFCONVERT)" ignored
"/usr/share/mk/sys.mk", line 295: if-less endif
"/usr/share/mk/sys.mk", line 299: warning: duplicate script for target  
".y.c" ignored
"/usr/share/mk/sys.mk", line 300: warning: duplicate script for target  
".y.c" ignored
"/usr/share/mk/sys.mk", line 303: warning: duplicate script for target  
".l.c" ignored
"/usr/share/mk/sys.mk", line 307: Missing dependency operator
"/usr/share/mk/sys.mk", line 308: warning: duplicate script for target  
".if" ignored
"/usr/share/mk/sys.mk", line 308: warning: duplicate script for target  
"defined(CTFCONVERT)" ignored
"/usr/share/mk/sys.mk", line 309: if-less endif
"/usr/share/mk/sys.mk", line 315: Missing dependency operator
"/usr/share/mk/sys.mk", line 316: warning: duplicate script for target  
".if" ignored
"/usr/share/mk/sys.mk", line 316: warning: duplicate script for target  
"defined(CTFCONVERT)" ignored
"/usr/share/mk/sys.mk", line 317: if-less endif
"/usr/share/mk/sys.mk", line 324: Missing dependency operator
"/usr/share/mk/sys.mk", line 325: warning: duplicate script for target  
".if" ignored
"/usr/share/mk/sys.mk", line 325: warning: duplicate script for target  
"defined(CTFCONVERT)" ignored
"/usr/share/mk/sys.mk", line 326: if-less endif
"/usr/share/mk/sys.mk", line 332: Missing dependency operator
"/usr/share/mk/sys.mk", line 333: warning: duplicate script for target  
".if" ignored
"/usr/share/mk/sys.mk", line 333: warning: duplicate script for target  
"defined(CTFCONVERT)" ignored
"/usr/share/mk/sys.mk", line 334: if-less endif
Global:__MAKE_CONF = /etc/make.conf
"/usr/share/mk/sys.mk", line 338: Missing dependency operator
"/usr/share/mk/sys.mk", line 339: Need an operator
"/usr/share/mk/sys.mk", line 340: if-less endif
Global:SHELL = ${__MAKE_SHELL}
"/usr/share/mk/sys.mk", line 344: : no matching shell
"/usr/share/mk/sys.mk", line 344: improper shell specification
"/usr/share/mk/sys.mk", line 345: if-less endif
Global:OBJFORMAT = elf
"/usr/share/mk/sys.mk", line 354: if-less endif
"/usr/share/mk/sys.mk", line 356: Need an operator
"/usr/share/mk/sys.mk", line 357: Need an operator
Global:.MAKEFILE_LIST = /usr/share/mk/sys.mk ..
make: fatal errors encountered -- cannot continue


--
Rui Paulo

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-arm/attachments/20090506/ebe2d1bd/PGP.pgp
From stas at FreeBSD.org  Wed May  6 18:08:30 2009
From: stas at FreeBSD.org (Stanislav Sedov)
Date: Wed May  6 18:08:36 2009
Subject: Can't build ports and/or system on HEAD
In-Reply-To: <1D99BB94-12E9-4425-AA1D-0CC3FAFF016C@gmail.com>
References: <1D99BB94-12E9-4425-AA1D-0CC3FAFF016C@gmail.com>
Message-ID: <20090506220842.23137b20.stas@FreeBSD.org>

On Wed, 6 May 2009 17:53:44 +0100
Rui Paulo <rpaulo@gmail.com> mentioned:

> Hi,
> I can't build ports on an arm embedded system. After the recent  
> strncmp() problem, I'm suspecting this is a fallout of something than  
> a misconfiguration of my part.
> 
> My sys.mk MD5 is:
> $ md5 /usr/share/mk/sys.mk
> MD5 (/usr/share/mk/sys.mk) = 5f02492bd3dc89d976067eeaa75d4d76
> 
> Which I think is correct. Any ideas?
> 
> # make -d A
> Global:.MAKEFLAGS =  -d
> Global:.MAKEFLAGS =  -d A
> Global:MFLAGS =  -d
> Global:MFLAGS =  -d A
> Caching ....done
> Global:.ST_EXPORTVAR = YES
> Global:.CURDIR = /usr/ports/editors/elvis
> Global:.OBJDIR = /usr/ports/editors/elvis
> Global:.TARGETS =
> Caching /usr/share/mk...done
> expanding "sys.mk".../usr/share/mk/sys.mk
> Global:MAKEFILE = /usr/share/mk/sys.mk
> Global:.MAKEFILE_LIST = /usr/share/mk/sys.mk
> Global:unix = We run FreeBSD, not UNIX.
> Global:.FreeBSD = true
> "/usr/share/mk/sys.mk", line 16: Missing dependency operator
> "/usr/share/mk/sys.mk", line 18: if-less else
> "/usr/share/mk/sys.mk", line 20: if-less endif
> Global:AR = ar
> "/usr/share/mk/sys.mk", line 23: Missing dependency operator
> Global:ARFLAGS = -rv
> "/usr/share/mk/sys.mk", line 25: if-less else
> "/usr/share/mk/sys.mk", line 27: if-less endif
> Global:RANLIB = ranlib
> Global:AS = as
> Global:AFLAGS =
> "/usr/share/mk/sys.mk", line 33: Missing dependency operator
> Global:CC = c89
> Global:CFLAGS = -O
> "/usr/share/mk/sys.mk", line 36: if-less else
> "/usr/share/mk/sys.mk", line 38: Need an operator
> "/usr/share/mk/sys.mk", line 40: if-less else
> "/usr/share/mk/sys.mk", line 42: if-less endif
> "/usr/share/mk/sys.mk", line 43: Missing dependency operator
> Global:CFLAGS = -O -fno-strict-aliasing
> "/usr/share/mk/sys.mk", line 45: if-less endif
> "/usr/share/mk/sys.mk", line 46: if-less endif
> Global:NO_CTF = 1
> "/usr/share/mk/sys.mk", line 52: if-less endif
> Global:CTFFLAGS = -L VERSION
> Global:CTFCONVERT = ctfconvert
> Global:CTFMERGE = ctfmerge
> Applying :M to "-O -fno-strict-aliasing"
> Result is ""
> "/usr/share/mk/sys.mk", line 60: Missing dependency operator
> Global:CTFFLAGS = -L VERSION -g
> "/usr/share/mk/sys.mk", line 62: if-less else
> Global:CFLAGS = -O -fno-strict-aliasing -g
> "/usr/share/mk/sys.mk", line 64: if-less endif
> "/usr/share/mk/sys.mk", line 65: if-less endif
> Global:CXX = c++
> Global:CXXFLAGS = ${CFLAGS:N-std=*:N-Wnested-externs:N-W*-prototypes:N- 
> Wno-pointer-sign}
> Global:CPP = cpp
> "/usr/share/mk/sys.mk", line 72: Missing dependency operator
> Global:ECHO = echo
> Global:ECHODIR = echo
> "/usr/share/mk/sys.mk", line 75: if-less else
> Applying :M to " -d A"
> Result is ""
> "/usr/share/mk/sys.mk", line 77: Need an operator
> "/usr/share/mk/sys.mk", line 79: if-less else
> "/usr/share/mk/sys.mk", line 81: if-less endif
> "/usr/share/mk/sys.mk", line 82: if-less endif
> Applying :M to " -d A"
> Result is ""
> Global:_+_ =
> "/usr/share/mk/sys.mk", line 86: if-less else
> "/usr/share/mk/sys.mk", line 88: if-less endif
> "/usr/share/mk/sys.mk", line 90: Missing dependency operator
> Global:FC = fort77
> Global:FFLAGS = -O 1
> "/usr/share/mk/sys.mk", line 93: if-less else
> "/usr/share/mk/sys.mk", line 96: if-less endif
> Global:EFLAGS =
> Global:INSTALL = install
> Global:LEX = lex
> Global:LFLAGS =
> Global:LD = ld
> Global:LDFLAGS =
> Global:LINT = lint
> Global:LINTFLAGS = -cghapbx
> Global:LINTKERNFLAGS = ${LINTFLAGS}
> Global:LINTOBJFLAGS = -cghapbxu -i
> Global:LINTOBJKERNFLAGS = ${LINTOBJFLAGS}
> Global:LINTLIBFLAGS = -cghapbxu -C ${LIB}
> Global:OBJC = cc
> Global:OBJCFLAGS = ${OBJCINCLUDES} ${CFLAGS} -Wno-import
> Global:PC = pc
> Global:PFLAGS =
> Global:RC = f77
> Global:RFLAGS =
> Global:YACC = yacc
> "/usr/share/mk/sys.mk", line 128: Missing dependency operator
> Global:YFLAGS =
> "/usr/share/mk/sys.mk", line 130: if-less else
> "/usr/share/mk/sys.mk", line 132: if-less endif
> "/usr/share/mk/sys.mk", line 134: Missing dependency operator
> defining transformation from `.c' to `'
> inserting an empty list?...inserting .c(2)...at end of list
> inserting an empty list?...inserting (0)...at end of list
> transformation .c complete
> "/usr/share/mk/sys.mk", line 145: Missing dependency operator
> "/usr/share/mk/sys.mk", line 147: if-less endif
> defining transformation from `.f' to `'
> inserting .f(7)...at end of list
> inserting an empty list?...inserting (0)...at end of list
> transformation .f complete
> "/usr/share/mk/sys.mk", line 151: Missing dependency operator
> "/usr/share/mk/sys.mk", line 152: warning: duplicate script for target  
> ".if" ignored
> "/usr/share/mk/sys.mk", line 152: warning: duplicate script for target  
> "defined(CTFCONVERT)" ignored
> "/usr/share/mk/sys.mk", line 153: if-less endif
> defining transformation from `.sh' to `'
> inserting .sh(6)...before .f(7)
> inserting an empty list?...inserting (0)...at end of list
> transformation .sh complete
> "/usr/share/mk/sys.mk", line 163: Missing dependency operator
> "/usr/share/mk/sys.mk", line 164: warning: duplicate script for target  
> ".if" ignored
> "/usr/share/mk/sys.mk", line 164: warning: duplicate script for target  
> "defined(CTFCONVERT)" ignored
> "/usr/share/mk/sys.mk", line 165: if-less endif
> "/usr/share/mk/sys.mk", line 169: Missing dependency operator
> "/usr/share/mk/sys.mk", line 170: warning: duplicate script for target  
> ".if" ignored
> "/usr/share/mk/sys.mk", line 170: warning: duplicate script for target  
> "defined(CTFCONVERT)" ignored
> "/usr/share/mk/sys.mk", line 171: if-less endif
> "/usr/share/mk/sys.mk", line 178: Missing dependency operator
> "/usr/share/mk/sys.mk", line 179: warning: duplicate script for target  
> ".if" ignored
> "/usr/share/mk/sys.mk", line 179: warning: duplicate script for target  
> "defined(CTFCONVERT)" ignored
> "/usr/share/mk/sys.mk", line 180: if-less endif
> "/usr/share/mk/sys.mk", line 187: Missing dependency operator
> "/usr/share/mk/sys.mk", line 188: warning: duplicate script for target  
> ".if" ignored
> "/usr/share/mk/sys.mk", line 188: warning: duplicate script for target  
> "defined(CTFCONVERT)" ignored
> "/usr/share/mk/sys.mk", line 189: if-less endif
> "/usr/share/mk/sys.mk", line 209: if-less else
> defining transformation from `.sh' to `'
> inserting .sh(6)...already there
> inserting (0)...already there
> transformation .sh complete
> defining transformation from `.c' to `'
> inserting .c(2)...already there
> inserting (0)...already there
> transformation .c complete
> "/usr/share/mk/sys.mk", line 227: Missing dependency operator
> "/usr/share/mk/sys.mk", line 228: warning: duplicate script for target  
> ".if" ignored
> "/usr/share/mk/sys.mk", line 228: warning: duplicate script for target  
> "defined(CTFCONVERT)" ignored
> "/usr/share/mk/sys.mk", line 229: if-less endif
> "/usr/share/mk/sys.mk", line 232: warning: duplicate script for target  
> ".c.o" ignored
> "/usr/share/mk/sys.mk", line 233: Missing dependency operator
> "/usr/share/mk/sys.mk", line 234: warning: duplicate script for target  
> ".if" ignored
> "/usr/share/mk/sys.mk", line 234: warning: duplicate script for target  
> "defined(CTFCONVERT)" ignored
> "/usr/share/mk/sys.mk", line 235: if-less endif
> defining transformation from `.cc' to `'
> inserting .cc(10)...at end of list
> inserting an empty list?...inserting (0)...at end of list
> defining transformation from `.cpp' to `'
> inserting .cpp(11)...at end of list
> inserting an empty list?...inserting (0)...at end of list
> defining transformation from `.cxx' to `'
> inserting .cxx(12)...at end of list
> inserting an empty list?...inserting (0)...at end of list
> defining transformation from `.C' to `'
> inserting .C(13)...at end of list
> inserting an empty list?...inserting (0)...at end of list
> transformation .cc complete
> transformation .cpp complete
> transformation .cxx complete
> transformation .C complete
> "/usr/share/mk/sys.mk", line 245: Missing dependency operator
> "/usr/share/mk/sys.mk", line 246: warning: duplicate script for target  
> ".if" ignored
> "/usr/share/mk/sys.mk", line 246: warning: duplicate script for target  
> "defined(CTFCONVERT)" ignored
> "/usr/share/mk/sys.mk", line 247: if-less endif
> "/usr/share/mk/sys.mk", line 251: Missing dependency operator
> "/usr/share/mk/sys.mk", line 252: warning: duplicate script for target  
> ".if" ignored
> "/usr/share/mk/sys.mk", line 252: warning: duplicate script for target  
> "defined(CTFCONVERT)" ignored
> "/usr/share/mk/sys.mk", line 253: if-less endif
> defining transformation from `.e' to `'
> inserting .e(16)...at end of list
> inserting an empty list?...inserting (0)...at end of list
> defining transformation from `.r' to `'
> inserting .r(17)...at end of list
> inserting an empty list?...inserting (0)...at end of list
> defining transformation from `.F' to `'
> inserting .F(15)...before .e(16)
> inserting an empty list?...inserting (0)...at end of list
> defining transformation from `.f' to `'
> inserting .f(7)...already there
> inserting (0)...already there
> transformation .e complete
> transformation .r complete
> transformation .F complete
> transformation .f complete
> "/usr/share/mk/sys.mk", line 260: warning: duplicate script for target  
> ".f.o" ignored
> "/usr/share/mk/sys.mk", line 264: Missing dependency operator
> "/usr/share/mk/sys.mk", line 265: warning: duplicate script for target  
> ".if" ignored
> "/usr/share/mk/sys.mk", line 265: warning: duplicate script for target  
> "defined(CTFCONVERT)" ignored
> "/usr/share/mk/sys.mk", line 266: if-less endif
> "/usr/share/mk/sys.mk", line 270: Missing dependency operator
> "/usr/share/mk/sys.mk", line 271: warning: duplicate script for target  
> ".if" ignored
> "/usr/share/mk/sys.mk", line 271: warning: duplicate script for target  
> "defined(CTFCONVERT)" ignored
> "/usr/share/mk/sys.mk", line 272: if-less endif
> "/usr/share/mk/sys.mk", line 276: Missing dependency operator
> "/usr/share/mk/sys.mk", line 277: warning: duplicate script for target  
> ".if" ignored
> "/usr/share/mk/sys.mk", line 277: warning: duplicate script for target  
> "defined(CTFCONVERT)" ignored
> "/usr/share/mk/sys.mk", line 278: if-less endif
> "/usr/share/mk/sys.mk", line 282: warning: duplicate script for target  
> ".y.o" ignored
> "/usr/share/mk/sys.mk", line 283: warning: duplicate script for target  
> ".y.o" ignored
> "/usr/share/mk/sys.mk", line 284: warning: duplicate script for target  
> ".y.o" ignored
> "/usr/share/mk/sys.mk", line 285: Missing dependency operator
> "/usr/share/mk/sys.mk", line 286: warning: duplicate script for target  
> ".if" ignored
> "/usr/share/mk/sys.mk", line 286: warning: duplicate script for target  
> "defined(CTFCONVERT)" ignored
> "/usr/share/mk/sys.mk", line 287: if-less endif
> "/usr/share/mk/sys.mk", line 290: warning: duplicate script for target  
> ".l.o" ignored
> "/usr/share/mk/sys.mk", line 291: warning: duplicate script for target  
> ".l.o" ignored
> "/usr/share/mk/sys.mk", line 292: warning: duplicate script for target  
> ".l.o" ignored
> "/usr/share/mk/sys.mk", line 293: Missing dependency operator
> "/usr/share/mk/sys.mk", line 294: warning: duplicate script for target  
> ".if" ignored
> "/usr/share/mk/sys.mk", line 294: warning: duplicate script for target  
> "defined(CTFCONVERT)" ignored
> "/usr/share/mk/sys.mk", line 295: if-less endif
> "/usr/share/mk/sys.mk", line 299: warning: duplicate script for target  
> ".y.c" ignored
> "/usr/share/mk/sys.mk", line 300: warning: duplicate script for target  
> ".y.c" ignored
> "/usr/share/mk/sys.mk", line 303: warning: duplicate script for target  
> ".l.c" ignored
> "/usr/share/mk/sys.mk", line 307: Missing dependency operator
> "/usr/share/mk/sys.mk", line 308: warning: duplicate script for target  
> ".if" ignored
> "/usr/share/mk/sys.mk", line 308: warning: duplicate script for target  
> "defined(CTFCONVERT)" ignored
> "/usr/share/mk/sys.mk", line 309: if-less endif
> "/usr/share/mk/sys.mk", line 315: Missing dependency operator
> "/usr/share/mk/sys.mk", line 316: warning: duplicate script for target  
> ".if" ignored
> "/usr/share/mk/sys.mk", line 316: warning: duplicate script for target  
> "defined(CTFCONVERT)" ignored
> "/usr/share/mk/sys.mk", line 317: if-less endif
> "/usr/share/mk/sys.mk", line 324: Missing dependency operator
> "/usr/share/mk/sys.mk", line 325: warning: duplicate script for target  
> ".if" ignored
> "/usr/share/mk/sys.mk", line 325: warning: duplicate script for target  
> "defined(CTFCONVERT)" ignored
> "/usr/share/mk/sys.mk", line 326: if-less endif
> "/usr/share/mk/sys.mk", line 332: Missing dependency operator
> "/usr/share/mk/sys.mk", line 333: warning: duplicate script for target  
> ".if" ignored
> "/usr/share/mk/sys.mk", line 333: warning: duplicate script for target  
> "defined(CTFCONVERT)" ignored
> "/usr/share/mk/sys.mk", line 334: if-less endif
> Global:__MAKE_CONF = /etc/make.conf
> "/usr/share/mk/sys.mk", line 338: Missing dependency operator
> "/usr/share/mk/sys.mk", line 339: Need an operator
> "/usr/share/mk/sys.mk", line 340: if-less endif
> Global:SHELL = ${__MAKE_SHELL}
> "/usr/share/mk/sys.mk", line 344: : no matching shell
> "/usr/share/mk/sys.mk", line 344: improper shell specification
> "/usr/share/mk/sys.mk", line 345: if-less endif
> Global:OBJFORMAT = elf
> "/usr/share/mk/sys.mk", line 354: if-less endif
> "/usr/share/mk/sys.mk", line 356: Need an operator
> "/usr/share/mk/sys.mk", line 357: Need an operator
> Global:.MAKEFILE_LIST = /usr/share/mk/sys.mk ..
> make: fatal errors encountered -- cannot continue
> 

Are your sure you have the proper libc with strncmp fix applied? Looks like
either the makefile or make itself is broken.

-- 
Stanislav Sedov
ST4096-RIPE

!DSPAM:4a01d21a994291890464748!


From rpaulo at gmail.com  Wed May  6 18:12:23 2009
From: rpaulo at gmail.com (Rui Paulo)
Date: Wed May  6 18:13:53 2009
Subject: Can't build ports and/or system on HEAD
In-Reply-To: <20090506220842.23137b20.stas@FreeBSD.org>
References: <1D99BB94-12E9-4425-AA1D-0CC3FAFF016C@gmail.com>
	<20090506220842.23137b20.stas@FreeBSD.org>
Message-ID: <26D2DB35-7397-4C7B-8141-8E295F134F4A@gmail.com>

Sorry, false alarm, pilot error...

--
Rui Paulo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-arm/attachments/20090506/735f3a86/PGP.pgp
From dfilter at FreeBSD.ORG  Wed May  6 20:30:04 2009
From: dfilter at FreeBSD.ORG (dfilter service)
Date: Wed May  6 20:30:10 2009
Subject: arm/134092: commit references a PR
Message-ID: <200905062030.n46KU37G013575@freefall.freebsd.org>

The following reply was made to PR arm/134092; it has been noted by GNATS.

From: dfilter@FreeBSD.ORG (dfilter service)
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: arm/134092: commit references a PR
Date: Wed,  6 May 2009 20:24:27 +0000 (UTC)

 Author: cognet
 Date: Wed May  6 20:24:17 2009
 New Revision: 191858
 URL: http://svn.freebsd.org/changeset/base/191858
 
 Log:
   Use the good hints for the NSLU, it should fix the network adapter.
   
   PR:		arm/134092
   Submitted by:	gavin
 
 Modified:
   head/sys/arm/conf/NSLU.hints
 
 Modified: head/sys/arm/conf/NSLU.hints
 ==============================================================================
 --- head/sys/arm/conf/NSLU.hints	Wed May  6 20:07:28 2009	(r191857)
 +++ head/sys/arm/conf/NSLU.hints	Wed May  6 20:24:17 2009	(r191858)
 @@ -17,17 +17,17 @@ hint.uart.1.irq=13
  # NPE Hardware Queue Manager
  hint.ixpqmgr.0.at="ixp0"
  
 -# NPE wireless NIC's, requires ixpqmgr
 +# NPE wired NICs, requires ixpqmgr
  hint.npe.0.at="ixp0"
 -hint.npe.0.mac="A"
 -hint.npe.0.mii="A"
 +hint.npe.0.mac="B"
 +hint.npe.0.mii="B"
  hint.npe.0.phy=1
  # The second MAC isn't used on the NSLU, but it needs to be configured or
  # we timeout on dhcp packets
  hint.npe.1.at="ixp0"
 -hint.npe.1.mac="B"
 -hint.npe.1.mii="A"
 -hint.npe.1.phy=0
 +#hint.npe.1.mac="B"
 +#hint.npe.1.mii="A"
 +#hint.npe.1.phy=0
  
  #not yet
  # RTC
 _______________________________________________
 svn-src-all@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/svn-src-all
 To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org"
 
From venkiece2005 at gmail.com  Thu May  7 04:44:15 2009
From: venkiece2005 at gmail.com (venki kaps)
Date: Thu May  7 04:44:21 2009
Subject: strncmp issue
In-Reply-To: <200905051637.n45GbE7Q057469@casselton.net>
References: <20090505.081701.569396874.imp@bsdimp.com>
	<200905051637.n45GbE7Q057469@casselton.net>
Message-ID: <6d53329e0905062136x58b4ca4eh9ebd9f45c34e565@mail.gmail.com>

Hi Tinguely,

Thanks for the fix.
i am also agreeing with you.

A small doubt:

ENTRY(strncmp)
     /* if (len == 0) return 0 */
     cmp r2, #0
     moveq r0, #0
     RETc(eq)

     /* ip == last src address to compare */
     add ip, r0, r2
1:
     ldrb r2, [r0], #1
     ldrb r3, [r1], #1
     cmp ip, r0
     beq 2f          <----  if (strlen(str1) > len) break;
     cmp r2, #0
     beq 2f          <----- if (*str1++ == 0) break;
     cmpcs r2, r3 <----- if (*str1 == *str2) return s1-s2;
     beq 1b
2:
    sub r0, r2, r3
    RET
END(strncmp)

Expecting beq 2f after cmp r2, #0 to break the loop.

Is it good to use?
OR
Is cmp r2, #1 enough?

Regards,
Venkappa

On Tue, May 5, 2009 at 10:07 PM, Mark Tinguely <tinguely@casselton.net>wrote:

>
> >  Is the hand rolled assembler still better than what gcc can produce?
> >
> >  Warner
>
> Assuming my additional conditional branch, we can save at least an add and
> a branch in the comparison loop with the hard rolled assembler over the
> "cc -O2 head/lib/libc/string/strncmp.c" code.
>
> If the conditional branch can be deleted, then even better.
>
> --Mark.
>
From tinguely at casselton.net  Thu May  7 13:58:44 2009
From: tinguely at casselton.net (Mark Tinguely)
Date: Thu May  7 13:58:51 2009
Subject: strncmp issue
In-Reply-To: <6d53329e0905062136x58b4ca4eh9ebd9f45c34e565@mail.gmail.com>
Message-ID: <200905071358.n47DwZLG085417@casselton.net>


I assumed that sam@ commit to head/lib/libc/arm/string/strncmp.S on yesterday
that just returns 0 on strncmp(s1, s2, -n) where n is positive int put the
issue to rest.

--Mark.
From gavin at FreeBSD.org  Thu May  7 16:40:02 2009
From: gavin at FreeBSD.org (Gavin Atkinson)
Date: Thu May  7 16:40:09 2009
Subject: arm/134338: [patch] Lock GPIO accesses on ixp425
Message-ID: <200905071632.n47GWYKf083347@buffy.york.ac.uk>


>Number:         134338
>Category:       arm
>Synopsis:       [patch] Lock GPIO accesses on ixp425
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-arm
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Thu May 07 16:40:01 UTC 2009
>Closed-Date:
>Last-Modified:
>Originator:     Gavin Atkinson
>Release:        FreeBSD 7.1-STABLE amd64
>Organization:
>Environment:
System: FreeBSD buffy.york.ac.uk 7.1-STABLE FreeBSD 7.1-STABLE #5: Fri Feb 13 11:25:58 GMT 2009 root@buffy.york.ac.uk:/usr/obj/usr/src/sys/GENERIC amd64

>Description:
	There are several points in the code where GPIO registers are read,
various operations are performed with the result, then GPIO registers are
written back to.  The problem here is that there is nothing preventing other
access occuring between the read and the write.  Some parts of the code (IIC)
go one step further and use Giant as a lock around these accesses, but as it
is not done globally, this makes little difference.

I stumbled on this while writing a driver for the NSLU LEDs, while hammering
the driver I saw interrupts being missed.  Whilst I have no absolute proof
that this is the cause, I've not been able to recreate it with this patch
in place.

I've gone for a seperate spin lock for the GPIO pins as it is used in various
contexts where a spin lock seems to be the correct choice.  It's also
implemented as a global lock rather than being stored in a softc or similar -
until there is a GPIO driver, I can't see any better solution.

Something like this is probably also needed for the other arm platforms,
however I do not have the hardware required to test these.

>How-To-Repeat:
	(ab)use code paths that toggle GPIO lines (e.g. use IIC heavily while
USB generates interrupts)

>Fix:

--- ixp425-gpio-locking.diff begins here ---
Index: src-head/sys/arm/xscale/ixp425/avila_ata.c
===================================================================
RCS file: /home/ncvs/src/sys/arm/xscale/ixp425/avila_ata.c,v
retrieving revision 1.6
diff -u -r1.6 avila_ata.c
--- src-head/sys/arm/xscale/ixp425/avila_ata.c	20 Dec 2008 03:26:09 -0000	1.6
+++ src-head/sys/arm/xscale/ixp425/avila_ata.c	7 May 2009 16:16:12 -0000
@@ -44,7 +44,9 @@
 #include <sys/param.h>
 #include <sys/systm.h>
 #include <sys/kernel.h>
+#include <sys/lock.h>
 #include <sys/module.h>
+#include <sys/mutex.h>
 #include <sys/time.h>
 #include <sys/bus.h>
 #include <sys/resource.h>
@@ -151,6 +153,7 @@
 		u_int16_t *, bus_size_t);
 static	void ata_bs_wm_2_s(void *, bus_space_handle_t, bus_size_t,
 		const u_int16_t *, bus_size_t);
+extern	struct mtx ixp425_gpio_mtx;
 
 static int
 ata_avila_probe(device_t dev)
@@ -218,6 +221,8 @@
 	rman_set_bustag(&sc->sc_alt_ata, &sc->sc_expbus_tag);
 	rman_set_bushandle(&sc->sc_alt_ata, sc->sc_alt_ioh);
 
+	mtx_lock(&ixp425_gpio_mtx);
+
 	GPIO_CONF_WRITE_4(sa, IXP425_GPIO_GPOER, 
 	    GPIO_CONF_READ_4(sa, IXP425_GPIO_GPOER) | (1<<config->gpin));
 	/* set interrupt type */
@@ -229,6 +234,8 @@
 	/* clear ISR */
 	GPIO_CONF_WRITE_4(sa, IXP425_GPIO_GPISR, (1<<config->gpin));
 
+	mtx_unlock(&ixp425_gpio_mtx);
+
 	/* configure CS1/3 window, leaving timing unchanged */
 	EXP_BUS_WRITE_4(sc, sc->sc_16bit_off,
 	    EXP_BUS_READ_4(sc, sc->sc_16bit_off) |
Index: src-head/sys/arm/xscale/ixp425/avila_led.c
===================================================================
RCS file: /home/ncvs/src/sys/arm/xscale/ixp425/avila_led.c,v
retrieving revision 1.2
diff -u -r1.2 avila_led.c
--- src-head/sys/arm/xscale/ixp425/avila_led.c	20 Dec 2008 03:26:09 -0000	1.2
+++ src-head/sys/arm/xscale/ixp425/avila_led.c	7 May 2009 16:16:28 -0000
@@ -28,7 +28,9 @@
 #include <sys/param.h>
 #include <sys/systm.h>
 #include <sys/kernel.h>
+#include <sys/lock.h>
 #include <sys/module.h>
+#include <sys/mutex.h>
 #include <sys/bus.h>
 
 #include <arm/xscale/ixp425/ixp425reg.h>
@@ -46,18 +48,22 @@
 	struct cdev		*sc_led;
 };
 
+extern struct mtx ixp425_gpio_mtx;
+
 static void
 led_func(void *arg, int onoff)
 {
 	struct led_avila_softc *sc = arg;
 	uint32_t reg;
 
+	mtx_lock(&ixp425_gpio_mtx);
 	reg = GPIO_CONF_READ_4(sc, IXP425_GPIO_GPOUTR);
 	if (onoff)
 		reg &= ~GPIO_LED_STATUS_BIT;
 	else
 		reg |= GPIO_LED_STATUS_BIT;
 	GPIO_CONF_WRITE_4(sc, IXP425_GPIO_GPOUTR, reg);
+	mtx_unlock(&ixp425_gpio_mtx);
 }
 
 static int
@@ -78,8 +84,10 @@
 	sc->sc_gpio_ioh = sa->sc_gpio_ioh;
 
 	/* Configure LED GPIO pin as output */
+	mtx_lock(&ixp425_gpio_mtx);
 	GPIO_CONF_WRITE_4(sc, IXP425_GPIO_GPOER,
 	    GPIO_CONF_READ_4(sc, IXP425_GPIO_GPOER) &~ GPIO_LED_STATUS_BIT);
+	mtx_unlock(&ixp425_gpio_mtx);
 
 	sc->sc_led = led_create(led_func, sc, "gpioled");
 
Index: src-head/sys/arm/xscale/ixp425/ixdp425_pci.c
===================================================================
RCS file: /home/ncvs/src/sys/arm/xscale/ixp425/ixdp425_pci.c,v
retrieving revision 1.2
diff -u -r1.2 ixdp425_pci.c
--- src-head/sys/arm/xscale/ixp425/ixdp425_pci.c	20 Mar 2008 15:54:19 -0000	1.2
+++ src-head/sys/arm/xscale/ixp425/ixdp425_pci.c	7 May 2009 16:16:43 -0000
@@ -40,7 +40,9 @@
 #include <sys/systm.h>
 #include <sys/bus.h>
 #include <sys/kernel.h>
+#include <sys/lock.h>
 #include <sys/module.h>
+#include <sys/mutex.h>
 #include <sys/malloc.h>
 #include <sys/rman.h>
 #include <machine/bus.h>
@@ -51,6 +53,8 @@
 #include <arm/xscale/ixp425/ixp425_intr.h>
 #include <arm/xscale/ixp425/ixdp425reg.h>
 
+extern struct mtx ixp425_gpio_mtx;
+
 void
 ixp425_md_attach(device_t dev)
 {
@@ -58,7 +62,7 @@
 	struct ixppcib_softc *pci_sc = device_get_softc(dev);
 	uint32_t reg;
 
-	
+	mtx_lock(&ixp425_gpio_mtx);
 	/* PCI Reset Assert */
 	reg = GPIO_CONF_READ_4(sc, IXP425_GPIO_GPOUTR);
 	reg &= ~(1U << GPIO_PCI_RESET);
@@ -130,6 +134,7 @@
 	reg = GPIO_CONF_READ_4(sc, IXP425_GPIO_GPOUTR);
 	reg |= 1U << GPIO_PCI_RESET;
 	GPIO_CONF_WRITE_4(sc, IXP425_GPIO_GPOUTR, reg | (1U << GPIO_PCI_RESET));
+	mtx_unlock(&ixp425_gpio_mtx);
 	pci_sc->sc_irq_rman.rm_type = RMAN_ARRAY;
 	pci_sc->sc_irq_rman.rm_descr = "IXP425 PCI IRQs";
 	CTASSERT(PCI_INT_D < PCI_INT_A);
Index: src-head/sys/arm/xscale/ixp425/ixp425.c
===================================================================
RCS file: /home/ncvs/src/sys/arm/xscale/ixp425/ixp425.c,v
retrieving revision 1.17
diff -u -r1.17 ixp425.c
--- src-head/sys/arm/xscale/ixp425/ixp425.c	10 Mar 2009 19:15:35 -0000	1.17
+++ src-head/sys/arm/xscale/ixp425/ixp425.c	7 May 2009 16:17:00 -0000
@@ -43,7 +43,9 @@
 #include <sys/systm.h>
 #include <sys/bus.h>
 #include <sys/kernel.h>
+#include <sys/lock.h>
 #include <sys/module.h>
+#include <sys/mutex.h>
 #include <sys/malloc.h>
 #include <sys/rman.h>
 #include <machine/bus.h>
@@ -65,6 +67,7 @@
 uint32_t intr_steer2 = 0;
 
 struct	ixp425_softc *ixp425_softc = NULL;
+struct mtx ixp425_gpio_mtx;
 
 static int	ixp425_probe(device_t);
 static void	ixp425_identify(driver_t *, device_t);
@@ -253,6 +256,7 @@
 	KASSERT(ixp425_softc == NULL, ("%s called twice?", __func__));
 	ixp425_softc = sc;
 
+	mtx_init(&ixp425_gpio_mtx, "GPIO register mutex", NULL, MTX_SPIN);
 	intr_enabled = 0;
 	ixp425_set_intrmask();
 	ixp425_set_intrsteer();
Index: src-head/sys/arm/xscale/ixp425/ixp425_iic.c
===================================================================
RCS file: /home/ncvs/src/sys/arm/xscale/ixp425/ixp425_iic.c,v
retrieving revision 1.4
diff -u -r1.4 ixp425_iic.c
--- src-head/sys/arm/xscale/ixp425/ixp425_iic.c	20 Dec 2008 03:26:09 -0000	1.4
+++ src-head/sys/arm/xscale/ixp425/ixp425_iic.c	7 May 2009 16:17:16 -0000
@@ -29,7 +29,9 @@
 #include <sys/param.h>
 #include <sys/systm.h>
 #include <sys/kernel.h>
+#include <sys/lock.h>
 #include <sys/module.h>
+#include <sys/mutex.h>
 #include <sys/bus.h>
 #include <sys/uio.h>
 
@@ -60,6 +62,8 @@
 
 static struct ixpiic_softc *ixpiic_sc = NULL;
 
+extern struct mtx ixp425_gpio_mtx;
+
 static int
 ixpiic_probe(device_t dev)
 {
@@ -79,10 +83,12 @@
 	sc->sc_iot = sa->sc_iot;
 	sc->sc_gpio_ioh = sa->sc_gpio_ioh;
 
+	mtx_lock(&ixp425_gpio_mtx);
 	GPIO_CONF_SET(sc, IXP425_GPIO_GPOER,
 		GPIO_I2C_SCL_BIT | GPIO_I2C_SDA_BIT);
 	GPIO_CONF_CLR(sc, IXP425_GPIO_GPOUTR,
 		GPIO_I2C_SCL_BIT | GPIO_I2C_SDA_BIT);
+	mtx_unlock(&ixp425_gpio_mtx);
 
 	/* add generic bit-banging code */	
 	if ((sc->iicbb = device_add_child(dev, "iicbb", -1)) == NULL)
@@ -106,11 +112,11 @@
 	struct ixpiic_softc *sc = ixpiic_sc;
 	uint32_t reg;
 
-	mtx_lock(&Giant);
+	mtx_lock(&ixp425_gpio_mtx);
 	GPIO_CONF_SET(sc, IXP425_GPIO_GPOER, GPIO_I2C_SCL_BIT);
 
 	reg = GPIO_CONF_READ_4(sc, IXP425_GPIO_GPINR);
-	mtx_unlock(&Giant);
+	mtx_unlock(&ixp425_gpio_mtx);
 	return (reg & GPIO_I2C_SCL_BIT);
 }
 
@@ -120,11 +126,11 @@
 	struct ixpiic_softc *sc = ixpiic_sc;
 	uint32_t reg;
 
-	mtx_lock(&Giant);
+	mtx_lock(&ixp425_gpio_mtx);
 	GPIO_CONF_SET(sc, IXP425_GPIO_GPOER, GPIO_I2C_SDA_BIT);
 
 	reg = GPIO_CONF_READ_4(sc, IXP425_GPIO_GPINR);
-	mtx_unlock(&Giant);
+	mtx_unlock(&ixp425_gpio_mtx);
 	return (reg & GPIO_I2C_SDA_BIT);
 }
 
@@ -133,13 +139,13 @@
 {
 	struct ixpiic_softc *sc = ixpiic_sc;
 
-	mtx_lock(&Giant);
+	mtx_lock(&ixp425_gpio_mtx);
 	GPIO_CONF_CLR(sc, IXP425_GPIO_GPOUTR, GPIO_I2C_SDA_BIT);
 	if (val)
 		GPIO_CONF_SET(sc, IXP425_GPIO_GPOER, GPIO_I2C_SDA_BIT);
 	else
 		GPIO_CONF_CLR(sc, IXP425_GPIO_GPOER, GPIO_I2C_SDA_BIT);
-	mtx_unlock(&Giant);
+	mtx_unlock(&ixp425_gpio_mtx);
 	DELAY(I2C_DELAY);
 }
 
@@ -148,13 +154,13 @@
 {
 	struct ixpiic_softc *sc = ixpiic_sc;
 
-	mtx_lock(&Giant);
+	mtx_lock(&ixp425_gpio_mtx);
 	GPIO_CONF_CLR(sc, IXP425_GPIO_GPOUTR, GPIO_I2C_SCL_BIT);
 	if (val)
 		GPIO_CONF_SET(sc, IXP425_GPIO_GPOER, GPIO_I2C_SCL_BIT);
 	else
 		GPIO_CONF_CLR(sc, IXP425_GPIO_GPOER, GPIO_I2C_SCL_BIT);
-	mtx_unlock(&Giant);
+	mtx_unlock(&ixp425_gpio_mtx);
 	DELAY(I2C_DELAY);
 }
 
--- ixp425-gpio-locking.diff ends here ---


>Release-Note:
>Audit-Trail:
>Unformatted:
From tinderbox at freebsd.org  Thu May  7 23:03:35 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Thu May  7 23:03:42 2009
Subject: [head tinderbox] failure on arm/arm
Message-ID: <20090507230331.1C16E7302F@freebsd-current.sentex.ca>

TB --- 2009-05-07 22:20:00 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2009-05-07 22:20:00 - starting HEAD tinderbox run for arm/arm
TB --- 2009-05-07 22:20:00 - cleaning the object tree
TB --- 2009-05-07 22:20:48 - cvsupping the source tree
TB --- 2009-05-07 22:20:48 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/arm/arm/supfile
TB --- 2009-05-07 22:20:58 - building world
TB --- 2009-05-07 22:20:58 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-05-07 22:20:58 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-05-07 22:20:58 - TARGET=arm
TB --- 2009-05-07 22:20:58 - TARGET_ARCH=arm
TB --- 2009-05-07 22:20:58 - TZ=UTC
TB --- 2009-05-07 22:20:58 - __MAKE_CONF=/dev/null
TB --- 2009-05-07 22:20:58 - cd /src
TB --- 2009-05-07 22:20:58 - /usr/bin/make -B buildworld
>>> World build started on Thu May  7 22:21:00 UTC 2009
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3: cross tools
>>> stage 4.1: building includes
>>> stage 4.2: building libraries
>>> stage 4.3: make dependencies
>>> stage 4.4: building everything
[...]
cc -O -pipe  -DNEED_SOLARIS_BOOLEAN -I/src/cddl/usr.bin/sgsmsg/../../../sys/cddl/compat/opensolaris  -I/src/cddl/usr.bin/sgsmsg/../../../cddl/compat/opensolaris/include  -I/src/cddl/usr.bin/sgsmsg/../../../cddl/contrib/opensolaris/cmd/sgs/include  -I/src/cddl/usr.bin/sgsmsg/../../../sys/cddl/contrib/opensolaris/uts/common -DNEED_SOLARIS_BOOLEAN -std=gnu89 -Wno-unknown-pragmas  -o sgsmsg avl.o sgsmsg.o string_table.o findprime.o 
===> cddl/usr.bin/zinject (all)
cc -O -pipe  -I/src/cddl/usr.bin/zinject/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/include -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/lib/libumem -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzfs/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libnvpair -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/head -I/src/cddl/usr.bin/zinject/../../lib/libumem -DNEED_SOLARIS_BOOLEAN -std=gnu89 -Wno-unknown-pragmas -c /src/cddl/usr.bin/zinject/../../contrib/opensolaris/cmd/zinject/zinject.c
cc -O -pipe  -I/src/cddl/usr.bin/zinject/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/include -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/lib/libumem -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzfs/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libnvpair -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/head -I/src/cddl/usr.bin/zinject/../../lib/libumem -DNEED_SOLARIS_BOOLEAN -std=gnu89 -Wno-unknown-pragmas -c /src/cddl/usr.bin/zinject/../../contrib/opensolaris/cmd/zinject/translate.c
/src/cddl/usr.bin/zinject/../../contrib/opensolaris/cmd/zinject/translate.c: In function 'translate_record':
/src/cddl/usr.bin/zinject/../../contrib/opensolaris/cmd/zinject/translate.c:373: warning: passing argument 4 of 'calculate_range' discards qualifiers from pointer target type
cc -O -pipe  -I/src/cddl/usr.bin/zinject/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/include -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/lib/libumem -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzfs/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libnvpair -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/head -I/src/cddl/usr.bin/zinject/../../lib/libumem -DNEED_SOLARIS_BOOLEAN -std=gnu89 -Wno-unknown-pragmas  -o zinject zinject.o translate.o -lavl -lgeom -lm -lnvpair -lumem -luutil -lzfs -lzpool
/obj/arm/src/tmp/usr/lib/libzpool.so: undefined reference to `vn_rele_async_fini'
*** Error code 1

Stop in /src/cddl/usr.bin/zinject.
*** Error code 1

Stop in /src/cddl/usr.bin.
*** Error code 1

Stop in /src/cddl.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2009-05-07 23:03:30 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-05-07 23:03:30 - ERROR: failed to build world
TB --- 2009-05-07 23:03:30 - 1926.59 user 271.18 system 2610.58 real


http://tinderbox.des.no/tinderbox-head-HEAD-arm-arm.full
From gavin at FreeBSD.org  Fri May  8 14:30:03 2009
From: gavin at FreeBSD.org (Gavin Atkinson)
Date: Fri May  8 14:30:10 2009
Subject: arm/134368: [patch] nslu2_led driver for the LEDs on the NSLU2
Message-ID: <200905081422.n48EMArP073408@buffy.york.ac.uk>


>Number:         134368
>Category:       arm
>Synopsis:       [patch] nslu2_led driver for the LEDs on the NSLU2
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-arm
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Fri May 08 14:30:02 UTC 2009
>Closed-Date:
>Last-Modified:
>Originator:     Gavin Atkinson
>Release:        FreeBSD 7.1-STABLE amd64
>Organization:
>Environment:
System: FreeBSD buffy.york.ac.uk 7.1-STABLE FreeBSD 7.1-STABLE #5: Fri Feb 13 11:25:58 GMT 2009 root@buffy.york.ac.uk:/usr/obj/usr/src/sys/GENERIC amd64

>Description:
	Simple driver for the LEDs on the NSLU2.  This uses the led(4)
API and provides devices under /dev/led/ to set the state of the four
LEDs.  It also switches the power LED to green on boot and to amber
on shutdown, like the original NSLU2 does.  Note that this requires
the GPIO locking changes submitted in PR arm/134338.

I've also created a new "files.nslu2" and "std.nslu2" file, as I have
drivers for the buttons and RTC to be submitted soon, so it makes
sense to factor NSLU out from the avila config now.

Written by myself, under the 2-clause BSD license.
>How-To-Repeat:
	N/A
>Fix:

--- nslu2_led.diff begins here ---
Index: sys/arm/conf/NSLU
===================================================================
RCS file: /home/ncvs/src/sys/arm/conf/NSLU,v
retrieving revision 1.6
diff -u -r1.6 NSLU
--- sys/arm/conf/NSLU	23 Feb 2009 18:34:56 -0000	1.6
+++ sys/arm/conf/NSLU	8 May 2009 14:12:48 -0000
@@ -30,6 +30,7 @@
 include		"../xscale/ixp425/std.ixp425"
 # NB: memory mapping is defined in std.avila (see also comment above)
 include		"../xscale/ixp425/std.avila"
+include		"../xscale/ixp425/std.nslu2"
 options 	XSCALE_CACHE_READ_WRITE_ALLOCATE
 #To statically compile in device wiring instead of /boot/device.hints
 hints		"NSLU.hints"		#Default places to look for devices.
@@ -91,6 +92,8 @@
 device		ixpiic		# I2C bus glue
 device		ixpwdog		# watchdog timer
 
+device		nslu2_led	# NSLU2 LEDs
+
 device		npe		# Network Processing Engine
 device		npe_fw
 device		firmware
Index: sys/arm/conf/NSLU.hints
===================================================================
RCS file: /home/ncvs/src/sys/arm/conf/NSLU.hints,v
retrieving revision 1.2
diff -u -r1.2 NSLU.hints
--- sys/arm/conf/NSLU.hints	6 May 2009 20:24:17 -0000	1.2
+++ sys/arm/conf/NSLU.hints	8 May 2009 13:14:07 -0000
@@ -34,5 +34,6 @@
 #hint.xrtc.0.at="iicbus0"
 #hint.xrtc.0.addr=0xde
 # Slug LED
+hint.nslu2_led.0.at="ixp0"
 # Slug button
 # Slug Buzzer
--- /dev/null	2009-05-08 15:11:01.000000000 +0100
+++ sys/arm/xscale/ixp425/nslu2_led.c	2009-05-08 15:14:11.000000000 +0100
@@ -0,0 +1,232 @@
+/*-
+ * Copyright (c) 2009, Gavin Atkinson <gavin@FreeBSD.org>
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *    notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *    notice, this list of conditions and the following disclaimer in the
+ *    documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
+ * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
+ * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
+ * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
+ * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
+ * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#include <sys/cdefs.h>
+__FBSDID("$FreeBSD$");
+
+#include <sys/param.h>
+
+#include <sys/bus.h>
+#include <sys/eventhandler.h>
+#include <sys/lock.h>
+#include <sys/kernel.h>
+#include <sys/module.h>
+#include <sys/mutex.h>
+#include <sys/systm.h>
+
+#include <arm/xscale/ixp425/ixp425reg.h>
+#include <arm/xscale/ixp425/ixp425var.h>
+
+#include <dev/led/led.h>
+
+#define	GPIO_LED_STATUS_RED	0
+#define	GPIO_LED_STATUS_GREEN	1
+#define	GPIO_LED_DISK2		2
+#define	GPIO_LED_DISK1		3
+
+#define	GPIO_LED_STATUS_RED_BIT		(1U << GPIO_LED_STATUS_RED)
+#define	GPIO_LED_STATUS_GREEN_BIT	(1U << GPIO_LED_STATUS_GREEN)
+#define	GPIO_LED_DISK2_BIT		(1U << GPIO_LED_DISK2)
+#define	GPIO_LED_DISK1_BIT		(1U << GPIO_LED_DISK1)
+
+/* Amber is produced by switching both red and green LEDs on */
+#define	GPIO_LED_STATUS_AMBER_BITS	(GPIO_LED_STATUS_RED_BIT | \
+					 GPIO_LED_STATUS_GREEN_BIT)
+
+#define	GPIO_ALL_LED_BITS		(GPIO_LED_STATUS_RED_BIT | \
+					 GPIO_LED_STATUS_GREEN_BIT | \
+					 GPIO_LED_DISK2_BIT | \
+					 GPIO_LED_DISK1_BIT)
+
+struct nslu2_led_softc {
+	device_t		sc_dev;
+	bus_space_tag_t		sc_iot;
+	bus_space_handle_t	sc_gpio_ioh;
+	eventhandler_tag	sc_shutdown_eh;
+	struct cdev		*sc_srled;
+	struct cdev		*sc_saled;
+	struct cdev		*sc_sgled;
+	struct cdev		*sc_d1led;
+	struct cdev		*sc_d2led;
+};
+
+extern struct mtx ixp425_gpio_mtx;
+
+static void
+nslu2_led_set(struct nslu2_led_softc *sc, int leds, int mask) 
+{
+	uint32_t reg;
+
+	/* On the NSLU2 hardware, a "1" written to the status LED outputs
+	 * will switch the LEDs on, but for the disk LEDs a "1" switches
+	 * them off. Handle that here, so the rest of the code doesn't
+	 * have to deal with this detail.
+	 */
+	leds ^= (GPIO_LED_DISK1_BIT | GPIO_LED_DISK2_BIT);
+
+	mtx_lock(&ixp425_gpio_mtx);
+	reg = GPIO_CONF_READ_4(sc, IXP425_GPIO_GPOUTR);
+	reg &= ~mask;
+	reg |= (leds & mask);
+	GPIO_CONF_WRITE_4(sc, IXP425_GPIO_GPOUTR, reg);
+	mtx_unlock(&ixp425_gpio_mtx);
+}
+
+static void
+nslu2_led_status_red_func(void *arg, int onoff)
+{
+	struct nslu2_led_softc *sc = arg;
+
+	nslu2_led_set(sc, (onoff ? GPIO_LED_STATUS_RED_BIT : 0),
+	    GPIO_LED_STATUS_RED_BIT);
+}
+
+static void
+nslu2_led_status_amber_func(void *arg, int onoff)
+{
+	struct nslu2_led_softc *sc = arg;
+
+	/* XXX: Ideally this should be done through the led(4) interface,
+	 * but there isn't currently a published interface to change
+	 * state from the kernel, so we go behind led(4)'s back.
+	 */
+	nslu2_led_set(sc, (onoff ? GPIO_LED_STATUS_AMBER_BITS : 0),
+	    GPIO_LED_STATUS_AMBER_BITS);
+}
+
+static void
+nslu2_led_status_green_func(void *arg, int onoff)
+{
+	struct nslu2_led_softc *sc = arg;
+
+	nslu2_led_set(sc, (onoff ? GPIO_LED_STATUS_GREEN_BIT : 0),
+	    GPIO_LED_STATUS_GREEN_BIT);
+}
+
+static void
+nslu2_led_status_disk1_func(void *arg, int onoff)
+{
+	struct nslu2_led_softc *sc = arg;
+
+	nslu2_led_set(sc, (onoff ? GPIO_LED_DISK1_BIT : 0),
+	    GPIO_LED_DISK1_BIT);
+}
+
+static void
+nslu2_led_status_disk2_func(void *arg, int onoff)
+{
+	struct nslu2_led_softc *sc = arg;
+
+	nslu2_led_set(sc, (onoff ? GPIO_LED_DISK2_BIT : 0),
+	    GPIO_LED_DISK2_BIT);
+}
+
+static void
+nslu2_led_shutdown(void *arg)
+{
+	struct nslu2_led_softc *sc = arg;
+
+	EVENTHANDLER_DEREGISTER(shutdown_pre_sync, sc->sc_shutdown_eh);
+
+	/* Shutting down...  Set status to amber */
+	nslu2_led_set(sc, GPIO_LED_STATUS_AMBER_BITS,
+	    GPIO_LED_STATUS_AMBER_BITS);
+}
+
+static int
+nslu2_led_probe(device_t dev)
+{
+	device_set_desc(dev, "NSLU2 LEDs");
+	return (BUS_PROBE_DEFAULT);
+}
+
+static int
+nslu2_led_attach(device_t dev)
+{
+	struct nslu2_led_softc *sc = device_get_softc(dev);
+	struct ixp425_softc *sa = device_get_softc(device_get_parent(dev));
+
+	sc->sc_dev = dev;
+	sc->sc_iot = sa->sc_iot;
+	sc->sc_gpio_ioh = sa->sc_gpio_ioh;
+
+	/* Configure LED GPIO pins as output */
+	mtx_lock(&ixp425_gpio_mtx);
+	GPIO_CONF_WRITE_4(sc, IXP425_GPIO_GPOER,
+	    GPIO_CONF_READ_4(sc, IXP425_GPIO_GPOER) &~ GPIO_ALL_LED_BITS);
+	mtx_unlock(&ixp425_gpio_mtx);
+
+	/* Start with status LED green and disk LEDs off */
+	sc->sc_srled = led_create_state(nslu2_led_status_red_func,
+	    sc, "status-red", 0);
+	sc->sc_saled = led_create_state(nslu2_led_status_amber_func,
+	    sc, "status-amber", 0);
+	sc->sc_sgled = led_create_state(nslu2_led_status_green_func,
+	    sc, "status-green", 1);
+	sc->sc_d1led = led_create_state(nslu2_led_status_disk1_func,
+	    sc, "disk1", 0);
+	sc->sc_d2led = led_create_state(nslu2_led_status_disk2_func,
+	    sc, "disk2", 0);
+
+	sc->sc_shutdown_eh = EVENTHANDLER_REGISTER(shutdown_pre_sync,
+	    nslu2_led_shutdown, sc, SHUTDOWN_PRI_FIRST);
+	return (0);
+}
+
+static void
+nslu2_led_detach(device_t dev)
+{
+	struct nslu2_led_softc *sc = device_get_softc(dev);
+
+	if (sc->sc_shutdown_eh)
+	    EVENTHANDLER_DEREGISTER(shutdown_pre_sync, sc->sc_shutdown_eh);
+	if (sc->sc_srled != NULL)
+	    led_destroy(sc->sc_srled);
+	if (sc->sc_saled != NULL)
+	    led_destroy(sc->sc_saled);
+	if (sc->sc_sgled != NULL)
+	    led_destroy(sc->sc_sgled);
+	if (sc->sc_d1led != NULL)
+	    led_destroy(sc->sc_d1led);
+	if (sc->sc_d2led != NULL)
+	    led_destroy(sc->sc_d2led);
+}
+
+static device_method_t nslu2_led_methods[] = {
+	DEVMETHOD(device_probe,		nslu2_led_probe),
+	DEVMETHOD(device_attach,	nslu2_led_attach),
+	DEVMETHOD(device_detach,	nslu2_led_detach),
+
+	{0, 0},
+};
+
+static driver_t nslu2_led_driver = {
+	"nslu2_led",
+	nslu2_led_methods,
+	sizeof(struct nslu2_led_softc),
+};
+static devclass_t nslu2_led_devclass;
+
+DRIVER_MODULE(nslu2_led, ixp, nslu2_led_driver, nslu2_led_devclass, 0, 0);
--- /dev/null	2009-05-08 15:11:01.000000000 +0100
+++ sys/arm/xscale/ixp425/std.nslu2	2009-05-08 14:14:50.000000000 +0100
@@ -0,0 +1,7 @@
+#$FreeBSD$
+
+#
+# Linksys NSLU2 board configuration
+#
+files		"../xscale/ixp425/files.nslu2"
+#
--- /dev/null	2009-05-08 15:11:01.000000000 +0100
+++ sys/arm/xscale/ixp425/files.nslu2	2009-05-08 14:14:55.000000000 +0100
@@ -0,0 +1,2 @@
+#$FreeBSD$
+arm/xscale/ixp425/nslu2_led.c		optional nslu2_led
--- nslu2_led.diff ends here ---


>Release-Note:
>Audit-Trail:
>Unformatted:
From yohanes at gmail.com  Sat May  9 05:11:23 2009
From: yohanes at gmail.com (Yohanes Nugroho)
Date: Sat May  9 05:11:36 2009
Subject: EHCI Problem on FreeBSD arm port
Message-ID: <260bb65e0905082115l4f017fb8g85ec88b81c191dc6@mail.gmail.com>

Hi all,

Bruce M Simpson has donated me an Emprex NSD 100 for porting FreeBSD
to it, and currently I am working to port FreeBSD to this machine,
which is ARM SoC Cavium Econa CNS11XX (formerly Star 91XX).

But now I am stuck in implementing the USB EHCI controller. Before
getting into the question, I would like to give some background. This
SoC uses Faraday FA526 Arm CPU (arm4), and I have worked on Linux port
of this SoC.

The current progress is as follows:
- FA526 CPU support is working (taken from NetBSD with minor adjustment)
- Interrupt controller, timer, and serial console is working

There are several more things that i need to implement: EHCI
controller driver, OHCI controller driver, and network driver. I am
starting with EHCI because then I would be able to use USB disk for
booting, and I will be able to use my USB-Ethernet adapter (supported
by FreeBSD) to test the networking stuff.

This is where I got stuck. The EHCI controller is detected, most of
the time the hub is detected (2 ports), and some of the time the USB
mass controller is loaded. From my observation, it seems that even
though the USB transaction is completed successfully, it sometimes
doesn't return correct data. By "completing successfully", The result
is (error=0):

ehci_device_done:2149: xfer=0xc19360b0, pipe=0xc192b878, error=0

It is obvious that the data is sometimes invalid, because the display
name of the device is sometimes corrupted.

For example, this is when it is ok (see: "Kingston DataTraveler"):

pass0: <Kingston DataTraveler 2.0 1.00> Removable Direct Access SCSI-2 device

and when it is error ("Kingston DataTravele2F921"):

umass0: <Kingston DataTravele2F921, class 0/0, rev 2.00/1.00, addr 2> on usbus0

(and sometimes even weirder string is shown)

This invalid data happens randomly, and causes the error to move
around (USB_ERR_NO_PIPE, CAM_REQ_CMP_ERR, etc). I have checked these
parts:

- I have verified that the device itself is working fine in Linux (always fine)
- the Linux implementation doesn't have any quirks for this SoC's EHCI
controller
- Timer: the timer is working OK, so this should not be a timing problem
- Interrupt controller: interrupt controller is also working OK, EHCI
interrupt handler is called as it should
- Caching/sync problem. I don't have deep understanding about ARM
cache mechanism, but I have tried adding a code to flush the all of
Dcache at the end of ehci_device_done, and it doesn't help.

My current code is quite messy (many debugging printf). I am currently
cleaning the source code so that everyone can have a look. But while I
am cleaning, maybe anyone can point out things that I need to check.

Here is the boot log of the most successful boot.

KDB: debugger backends: ddb
KDB: current backend: ddb
kernel stack c12eb000
Copyright (c) 1992-2009 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
	The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 8.0-CURRENT #153: Sat May  9 10:19:30 WIT 2009
    yohanes@cameron:/usr/home/yohanes/freebsd/freebsd/src/sys/arm/compile/CNS11XXNAS
WARNING: DIAGNOSTIC option enabled, expect reduced performance.
Preloaded elf kernel "elf kernel" at 0xc12d6f4c.
unknown CPU (ID = 0x66015261)
  WB enabled LABT
  16KB/16B 2-way Instruction cache
  16KB/16B 2-way write-back-locking-B Data cache
real memory  = 67108864 (64 MB)
Physical memory chunk(s):
00000000 - 0xffffff, 16777216 bytes (4096 pages)
0x133b000 - 0x3eaefff, 45563904 bytes (11124 pages)
avail memory = 61702144 (58 MB)
ULE: setup cpu 0
nfslock: pseudo-device
null: <null device, zero device>
random: <entropy source, Software, Yarrow>
mem: <memory>
econa identify
econa probe
econaarm0: <ECONA device bus> on motherboard
econa attach
econa add children
econa add child econa_ic addr 7d000000
econa add child uart addr 78000000
econa add child timer addr 79000000
econa add child ehci addr f8000000
timer0: <Econa CPU Timer> mem 0x79000000-0x79ffffff irq 0,1 on econaarm0
econa_alloc_resource start 00000000 end ffffffff, count = 00000001
econa_alloc_resource start 79000000 end 79ffffff, count = 01000000
sys_res_memory
Alloc OK
econa_alloc_resource start 00000000 end ffffffff, count = 00000001
econa_alloc_resource start 00000000 end 00000000, count = 00000001
sys_res_irq
Alloc OK
STR9100 CPU Clock: 200 MHz
HZ = 100
reload value = 500000
IRQ Timer1 at int #0x0 clock 100000000(Hz)
econa_setup_intr
done econa_setup_intr 0
timer0: [FILTER]
DONE timer
done00000000
ehci probe
ehci probe
ehci0: <CNS11XX USB EHCI> mem 0xf8000000-0xffffffff irq 24 on econaarm0
econa_alloc_resource start 00000000 end ffffffff, count = 00000001
econa_alloc_resource start f8000000 end ffffffff, count = 08000000
sys_res_memory
Alloc OK
econa_alloc_resource start 00000000 end ffffffff, count = 00000001
econa_alloc_resource start 00000018 end 00000018, count = 00000001
sys_res_irq
Alloc OK
add USB device
setup intr
econa_setup_intr
done econa_setup_intr 24
ehci0: [MPSAFE]
ehci0: [ITHREAD]
init ehci
ehci_init:222: start
cmd=0x01000020
 EHCI_CMD_ASE
sts=0x00101202
 EHCI_STS_HCH
 EHCI_STS_ERRINT
ien=0x00007070
frindex=0x00000000 ctrdsegm=0x00000000 periodic=0x00000000 async=0x00000000
usbus0: EHCI version 1.0
ehci_init:240: sparams=0x101202
ehci_init:244: cparams=0x7070
ehci_init:255: usbus0: resetting
QH(0xcd001800) at 0x03e3b800:
  link=0x03e3b802<QH>
  endp=0x0000a000
    addr=0x00 inact=0 endpt=0 eps=2 dtc=0 hrecl=1
    mpl=0x0 ctl=0 nrl=0
  endphub=0x40000000
    smask=0x00 cmask=0x00 huba=0x00 port=0 mult=1
  curqtd=0x00000000<>
Overlay qTD:
  next=0x00000001<T> altnext=0x00000001<T>
  status=0x00000040: toggle=0 bytes=0x0 ioc=0 c_page=0x0
    cerr=0 pid=0 stat=NOT_ACTIVE-HALTED
  buffer[0]=0x00000000
  buffer[1]=0x00000000
  buffer[2]=0x00000000
  buffer[3]=0x00000000
  buffer[4]=0x00000000
  buffer_hi[0]=0x00000000
  buffer_hi[1]=0x00000000
  buffer_hi[2]=0x00000000
  buffer_hi[3]=0x00000000
  buffer_hi[4]=0x00000000
probe and attach
usbus0: <CNS11XX USB EHCI> on ehci0
done
initcloks
enabling timer
Timecounter "CPU Timer" frequency 50000000 Hz quality 1000
Timecounters tick every 10.000 msec
ehci_root_intr:2001: port 2 changed
usbus0: 480Mbps High Speed USB v2.0
ehci_set_hw_power:3793:
ehci_set_hw_power:3805: Async is active
ehci_set_hw_power:3810: Periodic is active
ehci_pipe_init:3663: pipe=0xc1928078, addr=0, endpt=0, mode=0 (0)
ehci_roothub_exec:3032: type=0x00 request=0x05 wLen=0x0000
wValue=0x0001 wIndex=0x0000
ehci_roothub_exec:3032: type=0x80 request=0x06 wLen=0x0008
wValue=0x0100 wIndex=0x0000
ehci_roothub_exec:3032: type=0x80 request=0x06 wLen=0x0012
wValue=0x0100 wIndex=0x0000
ehci_roothub_exec:3032: type=0x80 request=0x06 wLen=0x0002
wValue=0x0300 wIndex=0x0080
ehci_roothub_exec:3032: type=0x80 request=0x06 wLen=0x0004
wValue=0x0300 wIndex=0x0080
ehci_roothub_exec:3032: type=0x80 request=0x06 wLen=0x0002
wValue=0x0301 wIndex=0x0001
ehci_roothub_exec:3032: type=0x80 request=0x06 wLen=0x000e
wValue=0x0301 wIndex=0x0001
ehci_roothub_exec:3032: type=0x80 request=0x06 wLen=0x0002
wValue=0x0302 wIndex=0x0001
ehci_roothub_exec:3032: type=0x80 request=0x06 wLen=0x001c
wValue=0x0302 wIndex=0x0001
ehci_roothub_exec:3032: type=0x80 request=0x06 wLen=0x0009
wValue=0x0200 wIndex=0x0000
ehci_roothub_exec:3032: type=0x80 request=0x06 wLen=0x0019
wValue=0x0200 wIndex=0x0000
ehci_roothub_exec:3032: type=0x00 request=0x09 wLen=0x0000
wValue=0x0001 wIndex=0x0000
ehci_pipe_init:3663: pipe=0xc18a1900, addr=1, endpt=129, mode=0 (1)
ugen0.1: <Cavium> at usbus0
uhub0: <Cavium EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus0
ehci_roothub_exec:3032: type=0xa0 request=0x06 wLen=0x0009
wValue=0x2900 wIndex=0x0000
WARNING: DIAGNOSTIC option enabled, expect reduced performance.
ehci_roothub_exec:3032: type=0x23 request=0x03 wLen=0x0000
wValue=0x0008 wIndex=0x0001
ehci_roothub_exec:3364: set port power 1
ehci_root_intr:2001: port 2 changed
ehci_roothub_exec:3032: type=0x23 request=0x03 wLen=0x0000
wValue=0x0008 wIndex=0x0002
ehci_roothub_exec:3364: set port power 2
uhub0: 2 ports with 2 removable, self powered
ehci_set_hw_power:3793:
ehci_roothub_exec:3032: type=0xa3 request=0x00 wLen=0x0004
wValue=0x0000 wIndex=0x0001
port 68 (idx=1) status=0x1000
ehci_roothub_exec:3032: type=0x23 request=0x01 wLen=0x0000
wValue=0x0010 wIndex=0x0001
ehci_roothub_exec:3032: type=0xa3 request=0x00 wLen=0x0004
wValue=0x0000 wIndex=0x0001
port 68 (idx=1) status=0x1000
ehci_roothub_exec:3032: type=0xa3 request=0x00 wLen=0x0004
wValue=0x0000 wIndex=0x0002
port 72 (idx=2) status=0x1803
ehci_roothub_exec:3032: type=0x23 request=0x01 wLen=0x0000
wValue=0x0010 wIndex=0x0002
ehci_roothub_exec:3032: type=0xa3 request=0x00 wLen=0x0004
wValue=0x0000 wIndex=0x0002
port 72 (idx=2) status=0x1801
ehci_roothub_exec:3032: type=0x23 request=0x03 wLen=0x0000
wValue=0x0004 wIndex=0x0002
ehci_roothub_exec:3345: ehci after reset, status=0x00001005
ehci_roothub_exec:3360: ehci port 2 reset, status = 0x00001005
ehci_roothub_exec:3032: type=0xa3 request=0x00 wLen=0x0004
wValue=0x0000 wIndex=0x0002
port 72 (idx=2) status=0x1005
ehci_roothub_exec:3032: type=0x23 request=0x01 wLen=0x0000
wValue=0x0014 wIndex=0x0002
ehci_roothub_exec:3032: type=0xa3 request=0x00 wLen=0x0004
wValue=0x0000 wIndex=0x0002
port 72 (idx=2) status=0x1005
ehci_pipe_init:3663: pipe=0xc1927878, addr=0, endpt=0, mode=0 (1)
usb2_transfer_setup ../../../dev/usb/usb_transfer.c:743
ehci_set_hw_power:3793:
ehci_set_hw_power:3805: Async is active
ehci_non_isoc_done ../../../dev/usb/controller/ehci.c:1276
ehci_device_done:2134: xfer=0xc19340b0, pipe=0xc1927878, error=0
ehci_non_isoc_done ../../../dev/usb/controller/ehci.c:1276
ehci_device_done:2134: xfer=0xc19340b0, pipe=0xc1927878, error=0
ehci_device_ctrl_close ../../../dev/usb/controller/ehci.c:2236
ehci_device_done:2134: xfer=0xc19340b0, pipe=0xc1927878, error=5
usb2_transfer_setup ../../../dev/usb/usb_transfer.c:743
ehci_non_isoc_done ../../../dev/usb/controller/ehci.c:1276
ehci_device_done:2134: xfer=0xc19330b0, pipe=0xc1927878, error=0
ehci_device_ctrl_close ../../../dev/usb/controller/ehci.c:2236
ehci_device_done:2134: xfer=0xc19330b0, pipe=0xc1927878, error=5
usb2_transfer_setup ../../../dev/usb/usb_transfer.c:743
ehci_non_isoc_done ../../../dev/usb/controller/ehci.c:1276
ehci_device_done:2134: xfer=0xc19320b0, pipe=0xc1927878, error=0
ehci_device_ctrl_close ../../../dev/usb/controller/ehci.c:2236
ehci_device_done:2134: xfer=0xc19320b0, pipe=0xc1927878, error=5
usb2_transfer_setup ../../../dev/usb/usb_transfer.c:743
ehci_non_isoc_done ../../../dev/usb/controller/ehci.c:1276
ehci_device_done:2134: xfer=0xc19310b0, pipe=0xc1927878, error=0
ehci_non_isoc_done ../../../dev/usb/controller/ehci.c:1276
ehci_device_done:2134: xfer=0xc19310b0, pipe=0xc1927878, error=0
ehci_roothub_exec:3032: type=0x23 request=0x03 wLen=0x0000
wValue=0x0004 wIndex=0x0002
ehci_roothub_exec:3345: ehci after reset, status=0x00001005
ehci_roothub_exec:3360: ehci port 2 reset, status = 0x00001005
ehci_roothub_exec:3032: type=0xa3 request=0x00 wLen=0x0004
wValue=0x0000 wIndex=0x0002
port 72 (idx=2) status=0x1005
ehci_roothub_exec:3032: type=0x23 request=0x01 wLen=0x0000
wValue=0x0014 wIndex=0x0002
ehci_device_ctrl_close ../../../dev/usb/controller/ehci.c:2236
ehci_device_done:2134: xfer=0xc19310b0, pipe=0xc1927878, error=5
usb2_transfer_setup ../../../dev/usb/usb_transfer.c:743
ehci_non_isoc_done ../../../dev/usb/controller/ehci.c:1276
ehci_device_done:2134: xfer=0xc19300b0, pipe=0xc1927878, error=0
ehci_non_isoc_done ../../../dev/usb/controller/ehci.c:1276
ehci_device_done:2134: xfer=0xc19300b0, pipe=0xc1927878, error=0
ehci_device_ctrl_close ../../../dev/usb/controller/ehci.c:2236
ehci_device_done:2134: xfer=0xc19300b0, pipe=0xc1927878, error=5
usb2_transfer_setup ../../../dev/usb/usb_transfer.c:743
ehci_non_isoc_done ../../../dev/usb/controller/ehci.c:1276
ehci_device_done:2134: xfer=0xc19300b0, pipe=0xc1927878, error=0
ehci_device_ctrl_close ../../../dev/usb/controller/ehci.c:2236
ehci_device_done:2134: xfer=0xc19300b0, pipe=0xc1927878, error=5
usb2_transfer_setup ../../../dev/usb/usb_transfer.c:743
ehci_non_isoc_done ../../../dev/usb/controller/ehci.c:1276
ehci_device_done:2134: xfer=0xc19310b0, pipe=0xc1927878, error=0
ehci_device_ctrl_close ../../../dev/usb/controller/ehci.c:2236
ehci_device_done:2134: xfer=0xc19310b0, pipe=0xc1927878, error=5
usb2_transfer_setup ../../../dev/usb/usb_transfer.c:743
ehci_non_isoc_done ../../../dev/usb/controller/ehci.c:1276
ehci_device_done:2134: xfer=0xc19320b0, pipe=0xc1927878, error=0
ehci_non_isoc_done ../../../dev/usb/controller/ehci.c:1276
ehci_device_done:2134: xfer=0xc19320b0, pipe=0xc1927878, error=0
ehci_non_isoc_done ../../../dev/usb/controller/ehci.c:1276
ehci_device_done:2134: xfer=0xc19320b0, pipe=0xc1927878, error=0
ehci_pipe_init:3663: pipe=0xc1871a80, addr=2, endpt=129, mode=0 (1)
ehci_pipe_init:3663: pipe=0xc1871aa4, addr=2, endpt=2, mode=0 (1)
usb2_transfer_setup ../../../dev/usb/usb_transfer.c:743
ehci_set_hw_power:3793:
ehci_set_hw_power:3805: Async is active
ehci_non_isoc_done ../../../dev/usb/controller/ehci.c:1276
ehci_device_done:2134: xfer=0xc19390b0, pipe=0xc1871aa4, error=0
ehci_non_isoc_done ../../../dev/usb/controller/ehci.c:1276
ehci_device_done:2134: xfer=0xc1939180, pipe=0xc1871a80, error=0
ehci_non_isoc_done ../../../dev/usb/controller/ehci.c:1276
ehci_device_done:2134: xfer=0xc1939850, pipe=0xc1871a80, error=0
ehci_device_bulk_close ../../../dev/usb/controller/ehci.c:2185
ehci_device_done:2134: xfer=0xc1939850, pipe=0xc1871a80, error=5
ehci_device_bulk_close ../../../dev/usb/controller/ehci.c:2185
ehci_device_done:2134: xfer=0xc1939180, pipe=0xc1871a80, error=5
ehci_device_bulk_close ../../../dev/usb/controller/ehci.c:2185
ehci_device_done:2134: xfer=0xc19390b0, pipe=0xc1871aa4, error=5
ugen0.2: <Kingston Technology> at usbus0
umass_probe_proto ../../../dev/usb/storage/umass.c:1297
retrieving interface descriptors
done ../../../dev/usb/storage/umass.c:1405
umass_probe_proto ../../../dev/usb/storage/umass.c:1297
retrieving interface descriptors
done ../../../dev/usb/storage/umass.c:1405
umass0: <Kingston Technology product 0x1607, class 0/0, rev
0.00/c0.de, addr 2> on usbus0
umass0:  SCSI over Bulk-Only; quirks = 0x0000
umass_attach ../../../dev/usb/storage/umass.c:1526
usb2_transfer_setup ../../../dev/usb/usb_transfer.c:743
ehci_non_isoc_done ../../../dev/usb/controller/ehci.c:1276
ehci_device_done:2134: xfer=0xc19320b0, pipe=0xc1927878, error=0
register sim 0
scanning the sim
umass0:0:0:-1: Attached to scbus0
probestart ../../../cam/cam_xpt.c:5768
scsi_inquiry ../../../cam/scsi/scsi_all.c:3608
probestart ../../../cam/cam_xpt.c:5779
probestart ../../../cam/cam_xpt.c:5887
ehci_set_hw_power:3793:
ehci_roothub_exec:3032: type=0xa3 request=0x00 wLen=0x0004
wValue=0x0000 wIndex=0x0001
port 68 (idx=1) status=0x1000
ehci_roothub_exec:3032: type=0xa3 request=0x00 wLen=0x0004
wValue=0x0000 wIndex=0x0002
port 72 (idx=2) status=0x1005
ehci_set_hw_power:3793:
ehci_set_hw_power:3805: Async is active
ehci_non_isoc_done ../../../dev/usb/controller/ehci.c:1276
ehci_device_done:2134: xfer=0xc19412d8, pipe=0xc1871aa4, error=0
ehci_non_isoc_done ../../../dev/usb/controller/ehci.c:1276
ehci_device_done:2134: xfer=0xc19413a8, pipe=0xc1871a80, error=0
ehci_non_isoc_done ../../../dev/usb/controller/ehci.c:1276
ehci_device_done:2134: xfer=0xc1941678, pipe=0xc1871a80, error=0
probestart ../../../cam/cam_xpt.c:5823
scsi_inquiry ../../../cam/scsi/scsi_all.c:3608
probestart ../../../cam/cam_xpt.c:5887
ehci_non_isoc_done ../../../dev/usb/controller/ehci.c:1276
ehci_device_done:2134: xfer=0xc19412d8, pipe=0xc1871aa4, error=0
ehci_non_isoc_done ../../../dev/usb/controller/ehci.c:1276
ehci_device_done:2134: xfer=0xc19413a8, pipe=0xc1871a80, error=22
ehci_set_hw_power:3793:
ehci_set_hw_power:3805: Async is active
ehci_non_isoc_done ../../../dev/usb/controller/ehci.c:1276
ehci_device_done:2134: xfer=0xc1941458, pipe=0xc1927878, error=0
ehci_non_isoc_done ../../../dev/usb/controller/ehci.c:1276
ehci_device_done:2134: xfer=0xc1941678, pipe=0xc1871a80, error=0
cam_periph_error ../../../cam/cam_periph.c:1563
probestart ../../../cam/cam_xpt.c:5696
probestart ../../../cam/cam_xpt.c:5887
ehci_non_isoc_done ../../../dev/usb/controller/ehci.c:1276
ehci_device_done:2134: xfer=0xc19412d8, pipe=0xc1871aa4, error=0
ehci_non_isoc_done ../../../dev/usb/controller/ehci.c:1276
ehci_device_done:2134: xfer=0xc1941678, pipe=0xc1871a80, error=0
ehci_non_isoc_done ../../../dev/usb/controller/ehci.c:1276
ehci_device_done:2134: xfer=0xc19412d8, pipe=0xc1871aa4, error=0
ehci_non_isoc_done ../../../dev/usb/controller/ehci.c:1276
ehci_device_done:2134: xfer=0xc19413a8, pipe=0xc1871a80, error=0
ehci_non_isoc_done ../../../dev/usb/controller/ehci.c:1276
ehci_device_done:2134: xfer=0xc1941678, pipe=0xc1871a80, error=0
cam_periph_error ../../../cam/cam_periph.c:1563
(probe0:umass-sim0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0
(probe0:umass-sim0:0:0:0): CAM Status: SCSI Status Error
(probe0:umass-sim0:0:0:0): SCSI Status: Check Condition
(probe0:umass-sim0:0:0:0): UNIT ATTENTION asc:28,0
(probe0:umass-sim0:0:0:0): Not ready to ready change, medium may have changed
(probe0:umass-sim0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0
(probe0:umass-sim0:0:0:0): UNIT ATTENTION asc:28,0
(probe0:umass-sim0:0:0:0): Not ready to ready change, medium may have changed
Retrying Command (per Sense Data)
(probe0:umass-sim0:0:0:0): Retrying Command
probedone ../../../cam/cam_xpt.c:6326
ehci_non_isoc_done ../../../dev/usb/controller/ehci.c:1276
ehci_device_done:2134: xfer=0xc19412d8, pipe=0xc1871aa4, error=0
ehci_non_isoc_done ../../../dev/usb/controller/ehci.c:1276
ehci_device_done:2134: xfer=0xc1941678, pipe=0xc1871a80, error=0
pass0 at umass-sim0 bus 0 target 0 lun 0
pass0: <Kingston DataTraveler 2.0 1.00> Removable Direct Access SCSI-2 device
pass0: 40.000MB/s transfers
ehci_non_isoc_done ../../../dev/usb/controller/ehci.c:1276
ehci_device_done:2134: xfer=0xc19412d8, pipe=0xc1871aa4, error=0
ehci_non_isoc_done ../../../dev/usb/controller/ehci.c:1276
ehci_device_done:2134: xfer=0xc19413a8, pipe=0xc1871a80, error=0
ehci_non_isoc_done ../../../dev/usb/controller/ehci.c:1276
ehci_device_done:2134: xfer=0xc1941678, pipe=0xc1871a80, error=0
da0 at umass-sim0 bus 0 target 0 lun 0
da0: <Kingston DataTraveler 2.0 1.00> Removable Direct Access SCSI-2 device
da0: 40.000MB/s transfers
da0: 1906MB (3903578 512 byte sectors: 255H 63S/T 242C)
GEOM: new disk da0
dagetcapacity ../../../cam/scsi/scsi_da.c:1894
ehci_non_isoc_done ../../../dev/usb/controller/ehci.c:1276
ehci_device_done:2134: xfer=0xc19412d8, pipe=0xc1871aa4, error=0
ehci_non_isoc_done ../../../dev/usb/controller/ehci.c:1276
ehci_device_done:2134: xfer=0xc19413a8, pipe=0xc1871a80, error=0
ehci_non_isoc_done ../../../dev/usb/controller/ehci.c:1276
ehci_device_done:2134: xfer=0xc1941678, pipe=0xc1871a80, error=0
ehci_non_isoc_done ../../../dev/usb/controller/ehci.c:1276
ehci_device_done:2134: xfer=0xc19412d8, pipe=0xc1871aa4, error=0
ehci_non_isoc_done ../../../dev/usb/controller/ehci.c:1276
ehci_device_done:2134: xfer=0xc1941678, pipe=0xc1871a80, error=0
ehci_non_isoc_done ../../../dev/usb/controller/ehci.c:1276
ehci_device_done:2134: xfer=0xc19412d8, pipe=0xc1871aa4, error=0
Expensive timeout(9) function: 0xc10ee6bc(0xc1885000) -1.990236639 s
ehci_non_isoc_done ../../../dev/usb/controller/ehci.c:1276
ehci_device_done:2134: xfer=0xc19413a8, pipe=0xc1871a80, error=0
ehci_non_isoc_done ../../../dev/usb/controller/ehci.c:1276
ehci_device_done:2134: xfer=0xc1941678, pipe=0xc1871a80, error=0
name = da0 geom da0 sector size = 1886417008
name = da0 geom da0 sector size = 1886417008
Offset = 0 length = 1886417008
panic: g_read_data(): invalid length 1886417008
KDB: enter: panic
[thread pid 2 tid 100006 ]
Stopped at      kdb_enter+0x44: ldrb    r15, [r15, r15, ror r15]!

-- 
Regards
Yohanes
http://yohan.es


-- 
Regards
Yohanes
http://yohan.es/
From hselasky at c2i.net  Sat May  9 09:06:38 2009
From: hselasky at c2i.net (Hans Petter Selasky)
Date: Sat May  9 09:06:44 2009
Subject: EHCI Problem on FreeBSD arm port
In-Reply-To: <260bb65e0905082115l4f017fb8g85ec88b81c191dc6@mail.gmail.com>
References: <260bb65e0905082115l4f017fb8g85ec88b81c191dc6@mail.gmail.com>
Message-ID: <200905091009.06658.hselasky@c2i.net>

On Saturday 09 May 2009, Yohanes Nugroho wrote:
> Hi all,

>
> This is where I got stuck. The EHCI controller is detected, most of
> the time the hub is detected (2 ports), and some of the time the USB
> mass controller is loaded. From my observation, it seems that even
> though the USB transaction is completed successfully, it sometimes
> doesn't return correct data. By "completing successfully", The result
> is (error=0):

Hi,

If the strings are corrupt I would guess at a busdma issue.

Flusing in device done is too late.

Put your flush all / invalidate all code into:

#if USB_HAVE_BUSDMA && defined(__FreeBSD__)

...

usb2_pc_cpu_flush()

usb2_pc_cpu_invalidate()

...

#endif

In "src/sys/dev/usb/usb_busdma.c".

Are you running stock 8-current ?

--HPS
From yohanes at gmail.com  Sat May  9 18:03:06 2009
From: yohanes at gmail.com (Yohanes Nugroho)
Date: Sat May  9 18:03:13 2009
Subject: EHCI Problem on FreeBSD arm port
In-Reply-To: <200905091009.06658.hselasky@c2i.net>
References: <260bb65e0905082115l4f017fb8g85ec88b81c191dc6@mail.gmail.com> 
	<200905091009.06658.hselasky@c2i.net>
Message-ID: <260bb65e0905091102y272de752r750a3a79940486f@mail.gmail.com>

On Sat, May 9, 2009 at 3:09 PM, Hans Petter Selasky <hselasky@c2i.net> wrote:

> Hi,
>
> If the strings are corrupt I would guess at a busdma issue.

thank you, adding a "flush all" instruction makes the USB controller
works properly.

Now i should check the implementation of the FA526 invalidate/flush
instruction, because I shouldn't need the extra flush instruction if
bus_dmamap_sync works properly, right?.

> Are you running stock 8-current ?

yes

-- 
Regards
Yohanes
http://yohan.es/
From imp at bsdimp.com  Sat May  9 18:16:36 2009
From: imp at bsdimp.com (M. Warner Losh)
Date: Sat May  9 18:16:47 2009
Subject: EHCI Problem on FreeBSD arm port
In-Reply-To: <260bb65e0905091102y272de752r750a3a79940486f@mail.gmail.com>
References: <260bb65e0905082115l4f017fb8g85ec88b81c191dc6@mail.gmail.com>
	<200905091009.06658.hselasky@c2i.net>
	<260bb65e0905091102y272de752r750a3a79940486f@mail.gmail.com>
Message-ID: <20090509.121327.-1592325297.imp@bsdimp.com>

In message: <260bb65e0905091102y272de752r750a3a79940486f@mail.gmail.com>
            Yohanes Nugroho <yohanes@gmail.com> writes:
: On Sat, May 9, 2009 at 3:09 PM, Hans Petter Selasky <hselasky@c2i.net> wrote:
: 
: > Hi,
: >
: > If the strings are corrupt I would guess at a busdma issue.
: 
: thank you, adding a "flush all" instruction makes the USB controller
: works properly.
: 
: Now i should check the implementation of the FA526 invalidate/flush
: instruction, because I shouldn't need the extra flush instruction if
: bus_dmamap_sync works properly, right?.

I believe so.

Warner
From tinguely at casselton.net  Sat May  9 19:06:40 2009
From: tinguely at casselton.net (Mark Tinguely)
Date: Sat May  9 19:06:46 2009
Subject: EHCI Problem on FreeBSD arm port
In-Reply-To: <260bb65e0905091102y272de752r750a3a79940486f@mail.gmail.com>
Message-ID: <200905091906.n49J6ahs025537@casselton.net>

>
>  On Sat, May 9, 2009 at 3:09 PM, Hans Petter Selasky <hselasky@c2i.net> wrote:
>
>  > Hi,
>  >
>  > If the strings are corrupt I would guess at a busdma issue.
>
>  thank you, adding a "flush all" instruction makes the USB controller
>  works properly.
>
>  Now i should check the implementation of the FA526 invalidate/flush
>  instruction, because I shouldn't need the extra flush instruction if
>  bus_dmamap_sync works properly, right?.
>
>  > Are you running stock 8-current ?
>
>  yes

Sounds like the multiple kernel mapping problem in ARM. It was mentioned
when the new USB stack was comitted. Muliple kernel mappings can also
occur in other situations.

There is a patch that has been around for a month and is about to be
committed. I just put three counters in the patch to determine if
PG_UNMANAGED pages could also be shared.

--Mark Tinguely
From bugmaster at FreeBSD.org  Mon May 11 11:06:51 2009
From: bugmaster at FreeBSD.org (FreeBSD bugmaster)
Date: Mon May 11 11:07:29 2009
Subject: Current problem reports assigned to freebsd-arm@FreeBSD.org
Message-ID: <200905111106.n4BB6oBS085882@freefall.freebsd.org>

Note: to view an individual PR, use:
  http://www.freebsd.org/cgi/query-pr.cgi?pr=(number).

The following is a listing of current problems submitted by FreeBSD users.
These represent problem reports covering all versions including
experimental development code and obsolete releases.


S Tracker      Resp.      Description
--------------------------------------------------------------------------------
o arm/134368   arm        [patch] nslu2_led driver for the LEDs on the NSLU2
o arm/134338   arm        [patch] Lock GPIO accesses on ixp425
o arm/134092   arm        [patch] NSLU.hints contains wrong hints for on board n

3 problems total.

From tinderbox at freebsd.org  Mon May 11 21:42:44 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Mon May 11 21:42:51 2009
Subject: [head tinderbox] failure on arm/arm
Message-ID: <20090511214241.03B367302F@freebsd-current.sentex.ca>

TB --- 2009-05-11 20:40:00 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2009-05-11 20:40:00 - starting HEAD tinderbox run for arm/arm
TB --- 2009-05-11 20:40:00 - cleaning the object tree
TB --- 2009-05-11 20:40:46 - cvsupping the source tree
TB --- 2009-05-11 20:40:46 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/arm/arm/supfile
TB --- 2009-05-11 20:40:57 - building world
TB --- 2009-05-11 20:40:57 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-05-11 20:40:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-05-11 20:40:57 - TARGET=arm
TB --- 2009-05-11 20:40:57 - TARGET_ARCH=arm
TB --- 2009-05-11 20:40:57 - TZ=UTC
TB --- 2009-05-11 20:40:57 - __MAKE_CONF=/dev/null
TB --- 2009-05-11 20:40:57 - cd /src
TB --- 2009-05-11 20:40:57 - /usr/bin/make -B buildworld
>>> World build started on Mon May 11 20:41:00 UTC 2009
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3: cross tools
>>> stage 4.1: building includes
>>> stage 4.2: building libraries
>>> stage 4.3: make dependencies
>>> stage 4.4: building everything
[...]
cc -O -pipe  -std=gnu99  -c /src/usr.bin/mail/vars.c
cc -O -pipe  -std=gnu99   -o mail version.o cmd1.o cmd2.o cmd3.o cmdtab.o collect.o edit.o fio.o getname.o head.o v7.local.o lex.o list.o main.o names.o popen.o quit.o send.o strings.o temp.o tty.o util.o vars.o 
gzip -cn /src/usr.bin/mail/mail.1 > mail.1.gz
===> usr.bin/make (all)
cc -O -pipe  -I/src/usr.bin/make -DMAKE_VERSION=\"5200408120\" -DDEFSHELLNAME=\"sh\" -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/usr.bin/make/arch.c
cc1: warnings being treated as errors
/src/usr.bin/make/arch.c: In function 'Arch_ParseArchive':
/src/usr.bin/make/arch.c:402: warning: the address of 'members' will never be NULL
*** Error code 1

Stop in /src/usr.bin/make.
*** Error code 1

Stop in /src/usr.bin.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2009-05-11 21:42:40 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-05-11 21:42:40 - ERROR: failed to build world
TB --- 2009-05-11 21:42:40 - 2860.98 user 355.03 system 3760.12 real


http://tinderbox.des.no/tinderbox-head-HEAD-arm-arm.full
From jdl at jdl.com  Wed May 13 17:47:59 2009
From: jdl at jdl.com (Jon Loeliger)
Date: Wed May 13 17:48:05 2009
Subject: Building boot2 for the avila
Message-ID: <E1M4IJc-0006hM-0e@jdl.com>


[ Apologies for any duplicates you may see as I incorrectly
  posted to the freebsd-current list earlier.  -- jdl ]


Folks,

I'm following the instructions on the Wiki here:

    http://wiki.freebsd.org/FreeBSDAvila

After successfully building FreeBSD current using nanobsd
and placing it onto a Compact Flash, I am now trying to
build the boot2 image so that I can boot it.

The instructions say:

    Build a kernel configured to mount the file system from ad0. This is
    most easily done by copying the AVILA config file and stripping out
    the BOOTP* options.

Which I think I did, but I'm not sure.

I placed a new "BOOT2" config file in /usr/src/sys/arm/conf.

By the phrase "Build a kernel configured to ..." here, does it
really mean a whole new "make buildworld" like this:

    make KERNCONF=BOOT2 TARGET=arm TARGET_CPUTYPE=xscale \
                    TARGET_BIG_ENDIAN=true buildworld

or perhaps just:

    make KERNCONF=BOOT2 TARGET=arm TARGET_CPUTYPE=xscale \
                    TARGET_BIG_ENDIAN=true buildkernel

    make KERNCONF=BOOT2 TARGET=arm TARGET_CPUTYPE=xscale \
                    TARGET_BIG_ENDIAN=true DESTDIR=/some/where \
                    installkernel

within the existing (from nanobsd) environment?


Then the wiki page says:

    Build the second level bootstrap program by entering the arm/xscale
    build environment and building sys/boot2/ixdp425:

         make TARGET_ARCH=arm TARGET_CPUTYPE=xscale \
                              TARGET_BIG_ENDIAN=true buildenv
         cd sys/boot/arm/ixp425/boot2/
         make

The problem arises from that make:

    # make
    Warning: Object directory not changed from original /usr/src/sys/boot/arm/ixp425/boot2
    cc -O -pipe -mbig-endian -march=armv5te -D__XSCALE__ -DBOOT_STACK=0x200000-4  -I/usr/src/sys/boot/arm/ixp425/boot2/../../../common  -I/usr/src/sys/boot/arm/ixp425/boot2 -DFIXUP_BOOT_DRV -Os -ffreestanding  -I/usr/src/sys/boot/arm/ixp425/boot2/../../../..  -I/usr/src/sys/boot/arm/ixp425/boot2/../../../../arm  -DCPU_XSCALE_IXP425  -Wall -Waggregate-return   -Werror  -Wnested-externs  -Wpointer-arith -Wshadow -Wwrite-strings  -Wmissing-prototypes  -Wmissing-declarations -DBOOT_IXP425 -std=gnu99  -c arm_init.S
    cc1: error: unrecognized command line option "-mbig-endian"
    arm_init.S:0: error: bad value (armv5te) for -march= switch
    arm_init.S:0: error: bad value (armv5te) for -mtune= switch
    *** Error code 1

    Stop in /usr/src/sys/boot/arm/ixp425/boot2.

Any advice for the weary here?  If I just strip the three
offending flags from the Makefile, will it build properly?
I'm dubious, except that there are also these in the environment now:

    TARGET_CPUTYPE=xscale
    CPUTYPE=xscale
    TARGET_BIG_ENDIAN=true
    MACHINE_ARCH=arm
    MAKEOBJDIRPREFIX=/usr/obj/arm
    MAKEFLAGS= TARGET_ARCH=arm TARGET_CPUTYPE=xscale TARGET_BIG_ENDIAN=true -m /usr/src/share/mk

I feel like maybe I missed the middle part somewhere?

Thanks,
jdl
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
From jdl at jdl.com  Thu May 14 14:28:12 2009
From: jdl at jdl.com (Jon Loeliger)
Date: Thu May 14 14:28:19 2009
Subject: Building boot2 under arm?
Message-ID: <E1M4bup-00015Z-Hm@jdl.com>


[ Forwarded from -current as I am still trying to resolve
  this problem of building boot2 for the avila board. -- jdl ]

------- Forwarded Message

To: Andrew Thompson <thompsa@FreeBSD.org>
Cc: freebsd-current@freebsd.org
In-reply-to: <20090513175000.GA2635@citylink.fud.org.nz> 
Date: Wed, 13 May 2009 17:02:04 -0500
From: Jon Loeliger <jdl@jdl.com>
Message-Id: <E1M4MWa-0007qE-6m@jdl.com>
Subject: Re: Building boot2 for ixp425 

> The buildenv command is the one that spawns a new shell with all the
> correct paths to use the new compiler. just do the kernel-toolchain
> before it, as in.
> 
> make TARGET_ARCH=arm TARGET_CPUTYPE=xscale \                                 
> 	TARGET_BIG_ENDIAN=true kernel-toolchain                                
>                                                
> make TARGET_ARCH=arm TARGET_CPUTYPE=xscale \                                 
> 	TARGET_BIG_ENDIAN=true buildenv                                        
>                                        
> cd sys/boot/arm/ixp425/boot2/
> make   
> 
> That should work :)

But alas, it did not.

So I ran the first two make commands as above but with
my KERNCONF=BOOT2 in the mix as well.  Built a toolchain
and all just fine.  And switched into a "buildenv" as well.

However:

    # make
    Warning: Object directory not changed from original /usr/src/sys/boot/arm/ixp425/boot2
    cc -O -pipe -mbig-endian -march=armv5te -D__XSCALE__ -DBOOT_STACK=0x200000-4  -I/usr/src/sys/boot/arm/ixp425/boot2/../../../common  -I/usr/src/sys/boot/arm/ixp425/boot2 -DFIXUP_BOOT_DRV -Os -ffreestanding  -I/usr/src/sys/boot/arm/ixp425/boot2/../../../..  -I/usr/src/sys/boot/arm/ixp425/boot2/../../../../arm  -DCPU_XSCALE_IXP425  -Wall -Waggregate-return   -Werror  -Wnested-externs  -Wpointer-arith -Wshadow -Wwrite-strings  -Wmissing-prototypes  -Wmissing-declarations -DBOOT_IXP425 -std=gnu99  -c arm_init.S
    arm_init.S:27:25: error: machine/asm.h: No such file or directory
    arm_init.S: Assembler messages:
    arm_init.S:29: Error: bad instruction `asentry_np(start)'
    arm_init.S:52: Error: bad instruction `entry(cpu_id)'
    arm_init.S:54: Error: bad instruction `ret'
    *** Error code 1

*sigh*

Trying to simply build a kernel in this "buildenv" didn't work.
Same results from either:

    # make KERNCONF=BOOT2 buildkernel
or
    # make TARGET_ARCH=arm TARGET_CPUTYPE=xscale TARGET_BIG_ENDIAN=true KERNCONF=BOOT2 buildkernel

Like this:

    # make TARGET_ARCH=arm TARGET_CPUTYPE=xscale TARGET_BIG_ENDIAN=true KERNCONF=BOOT2 buildenv
    Entering world for arm:arm
    # cd /usr/src/sys/boot/arm/ixp425/boot2
    # make
    Warning: Object directory not changed from original /usr/src/sys/boot/arm/ixp425/boot2
    cc -O -pipe -mbig-endian -march=armv5te -D__XSCALE__ -DBOOT_STACK=0x200000-4  -I/usr/src/sys/boot/arm/ixp425/boot2/../../../common  -I/usr/src/sys/boot/arm/ixp425/boot2 -DFIXUP_BOOT_DRV -Os -ffreestanding  -I/usr/src/sys/boot/arm/ixp425/boot2/../../../..  -I/usr/src/sys/boot/arm/ixp425/boot2/../../../../arm  -DCPU_XSCALE_IXP425  -Wall -Waggregate-return   -Werror  -Wnested-externs  -Wpointer-arith -Wshadow -Wwrite-strings  -Wmissing-prototypes  -Wmissing-declarations -DBOOT_IXP425 -std=gnu99  -c arm_init.S
    arm_init.S:27:25: error: machine/asm.h: No such file or directory
    arm_init.S: Assembler messages:
    arm_init.S:29: Error: bad instruction `asentry_np(start)'
    arm_init.S:52: Error: bad instruction `entry(cpu_id)'
    arm_init.S:54: Error: bad instruction `ret'
    *** Error code 1

    Stop in /usr/src/sys/boot/arm/ixp425/boot2.

So I tried to construct the tree as it would be after a buildkernel,
but that didn't go well at all.

Should it be trying to find the file /usr/src/sys/arm/include/asm.h ?

Thanks,
jdl

------- End of Forwarded Message

From stas at FreeBSD.org  Thu May 14 17:26:22 2009
From: stas at FreeBSD.org (Stanislav Sedov)
Date: Thu May 14 17:26:29 2009
Subject: Building boot2 under arm?
In-Reply-To: <E1M4bup-00015Z-Hm@jdl.com>
References: <E1M4bup-00015Z-Hm@jdl.com>
Message-ID: <20090514212647.d79860a2.stas@FreeBSD.org>

On Thu, 14 May 2009 09:28:07 -0500
Jon Loeliger <jdl@jdl.com> mentioned:

> 
> [ Forwarded from -current as I am still trying to resolve
>   this problem of building boot2 for the avila board. -- jdl ]
> 
> ------- Forwarded Message
> 
> To: Andrew Thompson <thompsa@FreeBSD.org>
> Cc: freebsd-current@freebsd.org
> In-reply-to: <20090513175000.GA2635@citylink.fud.org.nz> 
> Date: Wed, 13 May 2009 17:02:04 -0500
> From: Jon Loeliger <jdl@jdl.com>
> Message-Id: <E1M4MWa-0007qE-6m@jdl.com>
> Subject: Re: Building boot2 for ixp425 
> 
> > The buildenv command is the one that spawns a new shell with all the
> > correct paths to use the new compiler. just do the kernel-toolchain
> > before it, as in.
> > 
> > make TARGET_ARCH=arm TARGET_CPUTYPE=xscale \                                 
> > 	TARGET_BIG_ENDIAN=true kernel-toolchain                                
> >                                                
> > make TARGET_ARCH=arm TARGET_CPUTYPE=xscale \                                 
> > 	TARGET_BIG_ENDIAN=true buildenv                                        
> >                                        
> > cd sys/boot/arm/ixp425/boot2/
> > make   
> > 
> > That should work :)
> 
> But alas, it did not.
> 
> So I ran the first two make commands as above but with
> my KERNCONF=BOOT2 in the mix as well.  Built a toolchain
> and all just fine.  And switched into a "buildenv" as well.
> 
> However:
> 
>     # make
>     Warning: Object directory not changed from original /usr/src/sys/boot/arm/ixp425/boot2
>     cc -O -pipe -mbig-endian -march=armv5te -D__XSCALE__ -DBOOT_STACK=0x200000-4  -I/usr/src/sys/boot/arm/ixp425/boot2/../../../common  -I/usr/src/sys/boot/arm/ixp425/boot2 -DFIXUP_BOOT_DRV -Os -ffreestanding  -I/usr/src/sys/boot/arm/ixp425/boot2/../../../..  -I/usr/src/sys/boot/arm/ixp425/boot2/../../../../arm  -DCPU_XSCALE_IXP425  -Wall -Waggregate-return   -Werror  -Wnested-externs  -Wpointer-arith -Wshadow -Wwrite-strings  -Wmissing-prototypes  -Wmissing-declarations -DBOOT_IXP425 -std=gnu99  -c arm_init.S
>     arm_init.S:27:25: error: machine/asm.h: No such file or directory
>     arm_init.S: Assembler messages:
>     arm_init.S:29: Error: bad instruction `asentry_np(start)'
>     arm_init.S:52: Error: bad instruction `entry(cpu_id)'
>     arm_init.S:54: Error: bad instruction `ret'
>     *** Error code 1
> 
> *sigh*
> 
> Trying to simply build a kernel in this "buildenv" didn't work.
> Same results from either:
> 
>     # make KERNCONF=BOOT2 buildkernel
> or
>     # make TARGET_ARCH=arm TARGET_CPUTYPE=xscale TARGET_BIG_ENDIAN=true KERNCONF=BOOT2 buildkernel
> 
> Like this:
> 
>     # make TARGET_ARCH=arm TARGET_CPUTYPE=xscale TARGET_BIG_ENDIAN=true KERNCONF=BOOT2 buildenv
>     Entering world for arm:arm
>     # cd /usr/src/sys/boot/arm/ixp425/boot2
>     # make
>     Warning: Object directory not changed from original /usr/src/sys/boot/arm/ixp425/boot2
>     cc -O -pipe -mbig-endian -march=armv5te -D__XSCALE__ -DBOOT_STACK=0x200000-4  -I/usr/src/sys/boot/arm/ixp425/boot2/../../../common  -I/usr/src/sys/boot/arm/ixp425/boot2 -DFIXUP_BOOT_DRV -Os -ffreestanding  -I/usr/src/sys/boot/arm/ixp425/boot2/../../../..  -I/usr/src/sys/boot/arm/ixp425/boot2/../../../../arm  -DCPU_XSCALE_IXP425  -Wall -Waggregate-return   -Werror  -Wnested-externs  -Wpointer-arith -Wshadow -Wwrite-strings  -Wmissing-prototypes  -Wmissing-declarations -DBOOT_IXP425 -std=gnu99  -c arm_init.S
>     arm_init.S:27:25: error: machine/asm.h: No such file or directory
>     arm_init.S: Assembler messages:
>     arm_init.S:29: Error: bad instruction `asentry_np(start)'
>     arm_init.S:52: Error: bad instruction `entry(cpu_id)'
>     arm_init.S:54: Error: bad instruction `ret'
>     *** Error code 1
> 
>     Stop in /usr/src/sys/boot/arm/ixp425/boot2.
> 
> So I tried to construct the tree as it would be after a buildkernel,
> but that didn't go well at all.
> 
> Should it be trying to find the file /usr/src/sys/arm/include/asm.h ?

Have you tried building the world first?

-- 
Stanislav Sedov
ST4096-RIPE

!DSPAM:4a0c543b994291766630182!


From mike.gordon at primus.ca  Sun May 17 14:32:38 2009
From: mike.gordon at primus.ca (mike gordon)
Date: Sun May 17 14:32:52 2009
Subject: Technology - Oracle, IBM, ERP - SAP, QAD, CRM - Siebel,
	Communication - Cisco, Manufacturing, Healthcare customer lists
Message-ID: <200905171330.n4HDUoht025535@matrix.start.ca>

This email is to introduce our company Repharm and services we offer.
Repharm is an international leader of sales and marketing database products for high technology businesses. We provide installed customer lists for companies such as Oracle, PeopleSoft, Siebel, etc. Our lists are continuously maintained to ensure the highest level of accuracy and completeness. We have hundreds of industry leaders as customers today - many whose names you would recognize.
If you are interested, we could send you a sample of one of our lists complete with summary information, so that you could evaluate our content. To find out about the various lists we have available, in preparation for any sales or marketing campaigns that your organization may be considering in future, we'd love to hear from you. Or, perhaps you'd be interested in acquiring your competitors' customer lists? 
If you would like more information, please contact us at (905) 721-8456 or email us at repharm1@aol.com
Below are just some of the lists available:
ERP (ENTERPRISE RESOURCE PLANNING):
Baan
JD Edwards
Lawson
Made2Manage
Mapics
Marcam
Oracle
Peoplesoft
SAP
SSA
 
E-BUSINESS APPLICATIONS:
Ariba
BMC
BroadVision
Commerce One
Webtrends
 
MIDDLEWARE/CONNECTIVITY/APP SERVERS/WEB SERVERS:
Bea Systems
Iona
Unisys
 
OPERATING SYSTEMS/HARDWARE/SOFTWARE:
COMPAQ
HP 3000
HP 9000
HP-UX
IBM AS/400
IBM OS/390
Lotus Notes
Microsoft
Sun Microsystems
DATABASE:
DB2
FileMaker
Informix
Oracle
SQL
SybaseCRM (CUSTOMER RELATIONSHIP MANAGEMENT):
Clarify
E.piphany
HNC
Onyx
Pivotal
Siebel
Vantive
Xchange
 
SUPPLY CHAIN:
Agile
i2 Technologies
Manugistics
QAD
Webplan
COMMUNICATIONS:
Nortel
Cisco
3com
Siemens
Alcatel
Telecom Vars
ASP?s
CLECS
ISP?s
 
E-COMMERCE:
Dot Com Directory
Consultant Directory
Software Directory
 
EXECUTIVE DIRECTORIES:
Chief Executive Officer
Chief Financial Officer
Chief Information Officer
Engineering
Human Resources
Purchasing
Sales/Marketing
 
INDUSTRY SPECIFIC LISTS:
Agriculture, Forestry and Fishing, Communications, Construction,
Finance, Insurance and Real Estate, Manufacturing, Mining, Public Administration,
Retail Trade, Services, Transportation,
Utilities, Wholesale Trade
From bugmaster at FreeBSD.org  Mon May 18 11:06:49 2009
From: bugmaster at FreeBSD.org (FreeBSD bugmaster)
Date: Mon May 18 11:07:32 2009
Subject: Current problem reports assigned to freebsd-arm@FreeBSD.org
Message-ID: <200905181106.n4IB6mTr075582@freefall.freebsd.org>

Note: to view an individual PR, use:
  http://www.freebsd.org/cgi/query-pr.cgi?pr=(number).

The following is a listing of current problems submitted by FreeBSD users.
These represent problem reports covering all versions including
experimental development code and obsolete releases.


S Tracker      Resp.      Description
--------------------------------------------------------------------------------
o arm/134368   arm        [patch] nslu2_led driver for the LEDs on the NSLU2
o arm/134338   arm        [patch] Lock GPIO accesses on ixp425
o arm/134092   arm        [patch] NSLU.hints contains wrong hints for on board n

3 problems total.

From jdl at jdl.com  Tue May 19 14:54:22 2009
From: jdl at jdl.com (Jon Loeliger)
Date: Tue May 19 14:54:29 2009
Subject: Out of swap in a nanobsd build
Message-ID: <E1M6Qhw-00066O-Uh@jdl.com>

Folks,

I have a nanobsd build for the Gateworks aviala board
that ran out of swap last night.

    avila# May 13 03:01:13 avila-master kernel: pid 2642 (sort), uid 0, was killed: out of swap space

That suggests /etc/periodic/daily/470.status-named was the source.

As per the "avila" nano-config file, there is no swap.
I only possibly have compact flash space available.
So my real question is, should I try to configure some,
or should we be able to re-formulate the 470.staus-named
such that it doesn't need to swap?

Thanks,
jdl
From stas at FreeBSD.org  Tue May 19 15:27:48 2009
From: stas at FreeBSD.org (Stanislav Sedov)
Date: Tue May 19 15:27:53 2009
Subject: Out of swap in a nanobsd build
In-Reply-To: <E1M6Qhw-00066O-Uh@jdl.com>
References: <E1M6Qhw-00066O-Uh@jdl.com>
Message-ID: <20090519192744.9f22f76d.stas@FreeBSD.org>

On Tue, 19 May 2009 09:54:20 -0500
Jon Loeliger <jdl@jdl.com> mentioned:

> Folks,
> 
> I have a nanobsd build for the Gateworks aviala board
> that ran out of swap last night.
> 
>     avila# May 13 03:01:13 avila-master kernel: pid 2642 (sort), uid 0, was killed: out of swap space
> 
> That suggests /etc/periodic/daily/470.status-named was the source.
> 
> As per the "avila" nano-config file, there is no swap.
> I only possibly have compact flash space available.
> So my real question is, should I try to configure some,
> or should we be able to re-formulate the 470.staus-named
> such that it doesn't need to swap?
> 

The "out of swap" message means that there were unsufficien memory while
running some of these processes. So the only solutions to this problem are
either install additional memory, optimize the memory usage or configure
some swap space storage (e.g. USB attached hard drive).

-- 
Stanislav Sedov
ST4096-RIPE

!DSPAM:4a12cff1994299690386551!


From chuckr at telenix.org  Tue May 19 15:46:50 2009
From: chuckr at telenix.org (Chuck Robey)
Date: Tue May 19 15:46:56 2009
Subject: crosscompiler and porting notes
Message-ID: <4A12D46B.8040808@telenix.org>

two completely separate questions here.

First, for the processor OMAP3530 (the Cortex), is it possible to use the
llvm/clang compiler?  Or, is gcc the compiler being used, for cross compiling?
What sources are being used?  If it's the same gcc in sources, then I need to
know what are the flags used to build with (or, if it's actually in the build
already, where is it, how to do that?

2nd question, is there any document, set of notes, anything at all, to give any
sort of info at all so that I might have some idea of what needs to be changed
in the kernel sources.  I figure it's probably not going to be anything like a
complete document, but I'm quite willing to try to use any level of document
that might exist.  Understand, I *don't* want some general purpose porting guide
(something that would be used to create a bsd.port.mk-type port, I need this to
be specific for the kernel sources.

As far as that goes, are all the sources for the current level of work on the
arm ports in the svn repository, or if it's somewhere else, where might that be?

Thanks for two answers, I need to start leasrning this stuff, and these two
points seem to me to give me a firm enough place to begin.
From chuckr at telenix.org  Tue May 19 19:53:11 2009
From: chuckr at telenix.org (Chuck Robey)
Date: Tue May 19 19:53:18 2009
Subject: making  the cross tools
Message-ID: <4A130E2A.3060900@telenix.org>

Referring to the "Mini-install guide" that's on the Arm web page, I've
built/installed the compiler, but when I got to the 2nd set of instructions,
about building the binutils, it gives me this error after doing quite a bit of
building:

make: don't know how to make /usr/cross/usr/lib/libc.a. Stop
*** Error code 2

The DESTDIR is /usr/cross, and the command itself from the guide sets the
TOOLS_PREFIX also to /usr/cross.  Any idea what's going on, that it's refusing
to use my system libc.a?  It's a cross-compiler here, which means it's going to
execute here on my i386 machine, so it really SHOULD use my local libc.a (not
some libc.a for the Arm arch), right?
From imp at bsdimp.com  Tue May 19 20:02:16 2009
From: imp at bsdimp.com (M. Warner Losh)
Date: Tue May 19 20:02:22 2009
Subject: making the cross tools
In-Reply-To: <4A130E2A.3060900@telenix.org>
References: <4A130E2A.3060900@telenix.org>
Message-ID: <20090519.135928.-79138351.imp@bsdimp.com>

In message: <4A130E2A.3060900@telenix.org>
            Chuck Robey <chuckr@telenix.org> writes:
: Referring to the "Mini-install guide" that's on the Arm web page, I've
: built/installed the compiler, but when I got to the 2nd set of instructions,
: about building the binutils, it gives me this error after doing quite a bit of
: building:
: 
: make: don't know how to make /usr/cross/usr/lib/libc.a. Stop
: *** Error code 2
: 
: The DESTDIR is /usr/cross, and the command itself from the guide sets the
: TOOLS_PREFIX also to /usr/cross.  Any idea what's going on, that it's refusing
: to use my system libc.a?  It's a cross-compiler here, which means it's going to
: execute here on my i386 machine, so it really SHOULD use my local libc.a (not
: some libc.a for the Arm arch), right?

Please provide a reference here to the URL you are using, since this
makes no sense at all...  TOOLS_RPEFIX isn't a FreeBSDism.

Warner
From imp at bsdimp.com  Tue May 19 20:04:51 2009
From: imp at bsdimp.com (M. Warner Losh)
Date: Tue May 19 20:04:59 2009
Subject: crosscompiler and porting notes
In-Reply-To: <4A12D46B.8040808@telenix.org>
References: <4A12D46B.8040808@telenix.org>
Message-ID: <20090519.140258.1756924732.imp@bsdimp.com>

In message: <4A12D46B.8040808@telenix.org>
            Chuck Robey <chuckr@telenix.org> writes:
: First, for the processor OMAP3530 (the Cortex), is it possible to
: use the llvm/clang compiler?  Or, is gcc the compiler being used,
: for cross compiling?  What sources are being used?  If it's the same
: gcc in sources, then I need to know what are the flags used to build
: with (or, if it's actually in the build already, where is it, how to
: do that?

The in-tree compiler currently is gcc/binutils, which we use for all
ARM builds.  I don't know if it has the newer ARM instructions for the
OMAP3530.

: 2nd question, is there any document, set of notes, anything at all,
: to give any sort of info at all so that I might have some idea of
: what needs to be changed in the kernel sources.  I figure it's
: probably not going to be anything like a complete document, but I'm
: quite willing to try to use any level of document that might exist.
: Understand, I *don't* want some general purpose porting guide
: (something that would be used to create a bsd.port.mk-type port, I
: need this to be specific for the kernel sources.

No.  You have to read the source to get this information at the
present time.

: As far as that goes, are all the sources for the current level of
: work on the arm ports in the svn repository, or if it's somewhere
: else, where might that be?

Most of the work is in head.  However, there's some still straggling
in from the p4 //depot/projects/arm tree and I think we may have
created a base/projects/arm tree in svn as well, but I'm not sure
about that.

Warner
From chuckr at telenix.org  Tue May 19 20:05:11 2009
From: chuckr at telenix.org (Chuck Robey)
Date: Tue May 19 20:05:18 2009
Subject: making  the cross tools- more info
Message-ID: <4A1310F8.3070202@telenix.org>

I have one bit more of info, so I'm going to paste it at the end.
-------------------------------------
Referring to the "Mini-install guide" that's on the Arm web page, I've
built/installed the compiler, but when I got to the 2nd set of instructions,
about building the binutils, it gives me this error after doing quite a bit of
building:

make: don't know how to make /usr/cross/usr/lib/libc.a. Stop
*** Error code 2

The DESTDIR is /usr/cross, and the command itself from the guide sets the
TOOLS_PREFIX also to /usr/cross.  Any idea what's going on, that it's refusing
to use my system libc.a?  It's a cross-compiler here, which means it's going to
execute here on my i386 machine, so it really SHOULD use my local libc.a (not
some libc.a for the Arm arch), right?


[ADDED} the build error came in the "all" target part of building of ld, which
is the 7th app in that subdir (all the others went beautifully).  Svn diff
doesn't tell me that I have any mods, and seeing as I only recently changed
from cvs to svn (about 2 months ago) I'm really pretty sure I haven't hacked
into there any.
From chuckr at telenix.org  Tue May 19 20:09:36 2009
From: chuckr at telenix.org (Chuck Robey)
Date: Tue May 19 20:09:43 2009
Subject: making the cross tools
In-Reply-To: <20090519.135928.-79138351.imp@bsdimp.com>
References: <4A130E2A.3060900@telenix.org>
	<20090519.135928.-79138351.imp@bsdimp.com>
Message-ID: <4A131202.1080308@telenix.org>

M. Warner Losh wrote:
> In message: <4A130E2A.3060900@telenix.org>
>             Chuck Robey <chuckr@telenix.org> writes:
> : Referring to the "Mini-install guide" that's on the Arm web page, I've
> : built/installed the compiler, but when I got to the 2nd set of instructions,
> : about building the binutils, it gives me this error after doing quite a bit of
> : building:
> : 
> : make: don't know how to make /usr/cross/usr/lib/libc.a. Stop
> : *** Error code 2
> : 
> : The DESTDIR is /usr/cross, and the command itself from the guide sets the
> : TOOLS_PREFIX also to /usr/cross.  Any idea what's going on, that it's refusing
> : to use my system libc.a?  It's a cross-compiler here, which means it's going to
> : execute here on my i386 machine, so it really SHOULD use my local libc.a (not
> : some libc.a for the Arm arch), right?
> 
> Please provide a reference here to the URL you are using, since this
> makes no sense at all...  TOOLS_RPEFIX isn't a FreeBSDism.

OK, it's http://www.freebsd.org/platforms/arm.html, the section title is
"Mini-install Guide", by Olivier Houchard (which I'm probably making a hash of).
 Thanks for that ref to the p4 archive, I haven't used that yet, wasn't sure
where it is.  I know that the current gcc does provide support for the Cortex,
but I don't know exactly (yet) how old it is, I need to see, I guess, if it's at
least as old as the gcc (4.2.1).  That's not too hard to find out.

> 
> Warner
> _______________________________________________
> freebsd-arm@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arm
> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org"

From imp at bsdimp.com  Tue May 19 20:17:32 2009
From: imp at bsdimp.com (M. Warner Losh)
Date: Tue May 19 20:17:38 2009
Subject: making the cross tools- more info
In-Reply-To: <4A1310F8.3070202@telenix.org>
References: <4A1310F8.3070202@telenix.org>
Message-ID: <20090519.141224.556005618.imp@bsdimp.com>

In message: <4A1310F8.3070202@telenix.org>
            Chuck Robey <chuckr@telenix.org> writes:
: I have one bit more of info, so I'm going to paste it at the end.
: -------------------------------------
: Referring to the "Mini-install guide" that's on the Arm web page, I've
: built/installed the compiler, but when I got to the 2nd set of instructions,
: about building the binutils, it gives me this error after doing quite a bit of
: building:
: 
: make: don't know how to make /usr/cross/usr/lib/libc.a. Stop
: *** Error code 2
: 
: The DESTDIR is /usr/cross, and the command itself from the guide sets the
: TOOLS_PREFIX also to /usr/cross.  Any idea what's going on, that it's refusing
: to use my system libc.a?  It's a cross-compiler here, which means it's going to
: execute here on my i386 machine, so it really SHOULD use my local libc.a (not
: some libc.a for the Arm arch), right?
: 
: 
: [ADDED} the build error came in the "all" target part of building of ld, which
: is the 7th app in that subdir (all the others went beautifully).  Svn diff
: doesn't tell me that I have any mods, and seeing as I only recently changed
: from cvs to svn (about 2 months ago) I'm really pretty sure I haven't hacked
: into there any.

I usually use:

cd /usr/src
sudo make xdev TARGET=arm TARGET_ARCH=arm

to do all that...

Warner
From chuckr at telenix.org  Tue May 19 20:21:40 2009
From: chuckr at telenix.org (Chuck Robey)
Date: Tue May 19 20:21:46 2009
Subject: making the cross tools- more info
In-Reply-To: <20090519.141224.556005618.imp@bsdimp.com>
References: <4A1310F8.3070202@telenix.org>
	<20090519.141224.556005618.imp@bsdimp.com>
Message-ID: <4A1314D3.1010603@telenix.org>

M. Warner Losh wrote:
> In message: <4A1310F8.3070202@telenix.org>
>             Chuck Robey <chuckr@telenix.org> writes:
> : I have one bit more of info, so I'm going to paste it at the end.
> : -------------------------------------
> : Referring to the "Mini-install guide" that's on the Arm web page, I've
> : built/installed the compiler, but when I got to the 2nd set of instructions,
> : about building the binutils, it gives me this error after doing quite a bit of
> : building:
> : 
> : make: don't know how to make /usr/cross/usr/lib/libc.a. Stop
> : *** Error code 2
> : 
> : The DESTDIR is /usr/cross, and the command itself from the guide sets the
> : TOOLS_PREFIX also to /usr/cross.  Any idea what's going on, that it's refusing
> : to use my system libc.a?  It's a cross-compiler here, which means it's going to
> : execute here on my i386 machine, so it really SHOULD use my local libc.a (not
> : some libc.a for the Arm arch), right?
> : 
> : 
> : [ADDED} the build error came in the "all" target part of building of ld, which
> : is the 7th app in that subdir (all the others went beautifully).  Svn diff
> : doesn't tell me that I have any mods, and seeing as I only recently changed
> : from cvs to svn (about 2 months ago) I'm really pretty sure I haven't hacked
> : into there any.
> 
> I usually use:
> 
> cd /usr/src
> sudo make xdev TARGET=arm TARGET_ARCH=arm

OK, does xdev just do the cross tools?  The port I'm after doesn't yet exist,
after all.  Oh, BTW, I checked and (wouldn't you know it) the first gcc that
added Cortex support is (I think) 4.3.0.  Well, maybe I can get 4.3.0 to build,
who knows?  I know very well I can do it directly from the gcc sources, I
alreqady tried that, excepting I used a machine description I can't end up with
(derivative of Linux).

> 
> to do all that...
> 
> Warner

From imp at bsdimp.com  Tue May 19 20:31:34 2009
From: imp at bsdimp.com (M. Warner Losh)
Date: Tue May 19 20:31:41 2009
Subject: making the cross tools- more info
In-Reply-To: <20090519.141224.556005618.imp@bsdimp.com>
References: <4A1310F8.3070202@telenix.org>
	<20090519.141224.556005618.imp@bsdimp.com>
Message-ID: <20090519.142824.570083563.imp@bsdimp.com>

In message: <20090519.141224.556005618.imp@bsdimp.com>
            "M. Warner Losh" <imp@bsdimp.com> writes:
: In message: <4A1310F8.3070202@telenix.org>
:             Chuck Robey <chuckr@telenix.org> writes:
: : I have one bit more of info, so I'm going to paste it at the end.
: : -------------------------------------
: : Referring to the "Mini-install guide" that's on the Arm web page, I've
: : built/installed the compiler, but when I got to the 2nd set of instructions,
: : about building the binutils, it gives me this error after doing quite a bit of
: : building:
: : 
: : make: don't know how to make /usr/cross/usr/lib/libc.a. Stop
: : *** Error code 2
: : 
: : The DESTDIR is /usr/cross, and the command itself from the guide sets the
: : TOOLS_PREFIX also to /usr/cross.  Any idea what's going on, that it's refusing
: : to use my system libc.a?  It's a cross-compiler here, which means it's going to
: : execute here on my i386 machine, so it really SHOULD use my local libc.a (not
: : some libc.a for the Arm arch), right?
: : 
: : 
: : [ADDED} the build error came in the "all" target part of building of ld, which
: : is the 7th app in that subdir (all the others went beautifully).  Svn diff
: : doesn't tell me that I have any mods, and seeing as I only recently changed
: : from cvs to svn (about 2 months ago) I'm really pretty sure I haven't hacked
: : into there any.
: 
: I usually use:
: 
: cd /usr/src
: sudo make xdev TARGET=arm TARGET_ARCH=arm
: to do all that...

Err, got confused between the buildworld method and the xdev method:

sudo make xdev XDEV=arm XDEV_ARCH=arm

is what I use.  Well, really, what I usually use is:

setenv TARGET arm
make buildworld
make buildkernel KERNCONF=blah

and then s/KERNCONF/KERNFAST/ after the first time unless I'm hacking
the config files.  This just works and I don't have to think about
it.  The xdev stuff is more tailored to cross building whole projects
as well (or hacking on ports support for cross build :).

Warner
From tinguely at casselton.net  Tue May 19 20:54:49 2009
From: tinguely at casselton.net (Mark Tinguely)
Date: Tue May 19 20:54:56 2009
Subject: crosscompiler and porting notes
In-Reply-To: <4A12D46B.8040808@telenix.org>
Message-ID: <200905192054.n4JKslT6079244@casselton.net>

From tinguely at casselton.net  Tue May 19 21:00:54 2009
From: tinguely at casselton.net (Mark Tinguely)
Date: Tue May 19 21:00:59 2009
Subject: crosscompiler and porting notes
In-Reply-To: <4A12D46B.8040808@telenix.org>
Message-ID: <200905192100.n4JL0qNx079696@casselton.net>


sorry for the blank reply. It should have said

Looking at the current sources for the GNU assembler, it appears to me that
the "gas" sources do not have some new and important ARMv7 commands such as
"dmb", "dsb", and "isb" (barriers). There ARMv6 equivalent command, but
are not recommended.
			---
I looked at the Cortex document, the first thing that changed in ARMv7
is the information registers (for example information on the caches).
You will need to replace the CPU information and intialization code.

It would be nice to get an ARMv7 ARM. Someone with authority, like the
FreeBSD Foundation may be needed.
			---
You will need to write a new cpufunc_asm_XXX.S file of routines. The
existing routines assume the pmap will flush the caches on context change.
			---
I would suggest you start by using the existing memory model of flushing
caches on context changes until we learn more on the Cortex cache - are they
*really* not effected by the cache coloring problem.

If you can get the console working, and are willing to put some test
code into somewhere like pmap_bootstrap(), to test if the cache coloring
is really fixed, I would write it up.
			---
I have some rough code for the new ARMv6/ARMv7 TLS registers, the tlb ASID
and load and store exclusive. You have plenty to do to get the board up
to single user, without having to worry about this other stuff.

--Mark.
From cwenqi at gmail.com  Tue May 19 21:57:05 2009
From: cwenqi at gmail.com (Wenqi Chen)
Date: Tue May 19 21:57:11 2009
Subject: crosscompiler and porting notes
In-Reply-To: <c9a286a60905191433xbf1bfd3i653562b99e17f87d@mail.gmail.com>
References: <4A12D46B.8040808@telenix.org>
	<200905192100.n4JL0qNx079696@casselton.net>
	<c9a286a60905191433xbf1bfd3i653562b99e17f87d@mail.gmail.com>
Message-ID: <c9a286a60905191434q24ce39a8x7c76df5dd1191cb7@mail.gmail.com>

forgot to mention the compiler revision: codesourcery arm2008q3



2009/5/19 Wenqi Chen <cwenqi@gmail.com>:
> codesourcery revison of GCC-4.3 does seem to support armv7-a compiler
> flag/NEON instruction set.
>
> 2009/5/19 Mark Tinguely <tinguely@casselton.net>:
>>
>> sorry for the blank reply. It should have said
>>
>> Looking at the current sources for the GNU assembler, it appears to me that
>> the "gas" sources do not have some new and important ARMv7 commands such as
>> "dmb", "dsb", and "isb" (barriers). There ARMv6 equivalent command, but
>> are not recommended.
>> ? ? ? ? ? ? ? ? ? ? ? ?---
>> I looked at the Cortex document, the first thing that changed in ARMv7
>> is the information registers (for example information on the caches).
>> You will need to replace the CPU information and intialization code.
>>
>> It would be nice to get an ARMv7 ARM. Someone with authority, like the
>> FreeBSD Foundation may be needed.
>> ? ? ? ? ? ? ? ? ? ? ? ?---
>> You will need to write a new cpufunc_asm_XXX.S file of routines. The
>> existing routines assume the pmap will flush the caches on context change.
>> ? ? ? ? ? ? ? ? ? ? ? ?---
>> I would suggest you start by using the existing memory model of flushing
>> caches on context changes until we learn more on the Cortex cache - are they
>> *really* not effected by the cache coloring problem.
>>
>> If you can get the console working, and are willing to put some test
>> code into somewhere like pmap_bootstrap(), to test if the cache coloring
>> is really fixed, I would write it up.
>> ? ? ? ? ? ? ? ? ? ? ? ?---
>> I have some rough code for the new ARMv6/ARMv7 TLS registers, the tlb ASID
>> and load and store exclusive. You have plenty to do to get the board up
>> to single user, without having to worry about this other stuff.
>>
>> --Mark.
>> _______________________________________________
>> freebsd-arm@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-arm
>> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org"
>>
>
>
>
> --
> WC
>



-- 
WC
From cwenqi at gmail.com  Tue May 19 22:01:03 2009
From: cwenqi at gmail.com (Wenqi Chen)
Date: Tue May 19 22:01:09 2009
Subject: crosscompiler and porting notes
In-Reply-To: <200905192100.n4JL0qNx079696@casselton.net>
References: <4A12D46B.8040808@telenix.org>
	<200905192100.n4JL0qNx079696@casselton.net>
Message-ID: <c9a286a60905191433xbf1bfd3i653562b99e17f87d@mail.gmail.com>

codesourcery revison of GCC-4.3 does seem to support armv7-a compiler
flag/NEON instruction set.

2009/5/19 Mark Tinguely <tinguely@casselton.net>:
>
> sorry for the blank reply. It should have said
>
> Looking at the current sources for the GNU assembler, it appears to me that
> the "gas" sources do not have some new and important ARMv7 commands such as
> "dmb", "dsb", and "isb" (barriers). There ARMv6 equivalent command, but
> are not recommended.
> ? ? ? ? ? ? ? ? ? ? ? ?---
> I looked at the Cortex document, the first thing that changed in ARMv7
> is the information registers (for example information on the caches).
> You will need to replace the CPU information and intialization code.
>
> It would be nice to get an ARMv7 ARM. Someone with authority, like the
> FreeBSD Foundation may be needed.
> ? ? ? ? ? ? ? ? ? ? ? ?---
> You will need to write a new cpufunc_asm_XXX.S file of routines. The
> existing routines assume the pmap will flush the caches on context change.
> ? ? ? ? ? ? ? ? ? ? ? ?---
> I would suggest you start by using the existing memory model of flushing
> caches on context changes until we learn more on the Cortex cache - are they
> *really* not effected by the cache coloring problem.
>
> If you can get the console working, and are willing to put some test
> code into somewhere like pmap_bootstrap(), to test if the cache coloring
> is really fixed, I would write it up.
> ? ? ? ? ? ? ? ? ? ? ? ?---
> I have some rough code for the new ARMv6/ARMv7 TLS registers, the tlb ASID
> and load and store exclusive. You have plenty to do to get the board up
> to single user, without having to worry about this other stuff.
>
> --Mark.
> _______________________________________________
> freebsd-arm@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arm
> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org"
>



-- 
WC
From chuckr at telenix.org  Wed May 20 00:42:17 2009
From: chuckr at telenix.org (Chuck Robey)
Date: Wed May 20 00:42:24 2009
Subject: crosscompiler and porting notes
In-Reply-To: <200905192100.n4JL0qNx079696@casselton.net>
References: <200905192100.n4JL0qNx079696@casselton.net>
Message-ID: <4A1351EC.2010904@telenix.org>

Mark Tinguely wrote:
> sorry for the blank reply. It should have said
> 
> Looking at the current sources for the GNU assembler, it appears to me that
> the "gas" sources do not have some new and important ARMv7 commands such as
> "dmb", "dsb", and "isb" (barriers). There ARMv6 equivalent command, but
> are not recommended.
> 			---
> I looked at the Cortex document, the first thing that changed in ARMv7
> is the information registers (for example information on the caches).
> You will need to replace the CPU information and intialization code.
> 
> It would be nice to get an ARMv7 ARM. Someone with authority, like the
> FreeBSD Foundation may be needed.
> 			---
> You will need to write a new cpufunc_asm_XXX.S file of routines. The
> existing routines assume the pmap will flush the caches on context change.
> 			---
> I would suggest you start by using the existing memory model of flushing
> caches on context changes until we learn more on the Cortex cache - are they
> *really* not effected by the cache coloring problem.
> 
> If you can get the console working, and are willing to put some test
> code into somewhere like pmap_bootstrap(), to test if the cache coloring
> is really fixed, I would write it up.
> 			---
> I have some rough code for the new ARMv6/ARMv7 TLS registers, the tlb ASID
> and load and store exclusive. You have plenty to do to get the board up
> to single user, without having to worry about this other stuff.

Thanks for the comments, Mark, I'll use them to begin my code research.  I would
VERY much like to put my hands on whatever is written today, and I actually do
hope that it's not all written today, I would like to add to the code, it's a
learning experience.  I also have probably a fiar amount of time, because I sent
away for the Pandora about 6 weeks ago, and it looks like it won't ship for
maybe another month or two.  I'm really anxious for it to show up, but it does
allow me to start the research right away.

> 
> --Mark.

From chuckr at telenix.org  Wed May 20 19:31:35 2009
From: chuckr at telenix.org (Chuck Robey)
Date: Wed May 20 19:31:42 2009
Subject: what compiler?
Message-ID: <4A145A9B.2020001@telenix.org>

I'm trying to see what compiler would be chosen, if any work is contemplated on
the Cortex-A8 processor (BeagleBoard, Pandora, and I think the Nokia N800/N810,
and others).  From what I've read, LLVM has support for the V6, but isn't it
true that the Bortex-A8 needs V7 compatibility?  I'm not sure if the LLVM *can*
yet do the task.  Considering gcc instead, it's not until version 4.3.0 that
they added the Cortex support, and I've heard that gcc on FreeBSD, currently at
4.2.1, isn't likely to move forward to anything 4.3.+ any time soon.

So, I'm curious, what might be used for a Cortex port?  I guess you might tell
me that FreeBSD won't be supporting it any time soon, but I'd really not like to
hear that (I wanted to see what I could personally help on that) but I think
that what compiler to use,  it's got to be my first question.  I have time (my
Pandora hasn't even arrived yet), I'm just very curious on this point (the
compiler to use).
From gballet at gmail.com  Thu May 21 20:44:15 2009
From: gballet at gmail.com (Guillaume Ballet)
Date: Thu May 21 20:44:22 2009
Subject: LMA != VMA when compiling a kernel
Message-ID: <fd183dc60905211318v67d77378t4100f3a0035124ed@mail.gmail.com>

Hello list,

I am still working on a port of FreeBSD to the beagleboard, and am
currently working on enabling the VM. So far, I have loaded the kernel
at phys_addr = virt_addr = 0x80000000, because that is where the RAM
is. However, when enabling the VM, I would like the kernel virtual
addresses to start with 0xC0000000 as they do on most other platform.

Hence, I have been trying to set the ELF file sections' VMAs to
something starting with 0xC and the LMAs to something starting with
0x8. It turns out that just setting KERNPHYSADDR and KERNVIRTADDR is
not enough >.< If found a way to do this by chaning the script linker
and adding AT after each section declaration, and it works fine. But
it's tedious, hacky and lots of hardcoded values only work with my
platform.

Googling for ideas, I found that there has been some discussion about
it barely a year ago. Yet, it doesn't seem to have yielded any
tangible result. Would someone have addressed the progress in the mean
time?

I guess another way to look at it would be to work it around by also
porting a full-fledged loader(8). A task which I have delayed to until
I get a booting kernel - maybe not the wisest move :) Still, I'm
curious about the possibility of specifying distinct LMAs and VMAs for
the kernel executable.

Guillaume
From imp at bsdimp.com  Thu May 21 20:58:22 2009
From: imp at bsdimp.com (M. Warner Losh)
Date: Thu May 21 20:58:29 2009
Subject: LMA != VMA when compiling a kernel
In-Reply-To: <fd183dc60905211318v67d77378t4100f3a0035124ed@mail.gmail.com>
References: <fd183dc60905211318v67d77378t4100f3a0035124ed@mail.gmail.com>
Message-ID: <20090521.145552.410235390.imp@bsdimp.com>

In message: <fd183dc60905211318v67d77378t4100f3a0035124ed@mail.gmail.com>
            Guillaume Ballet <gballet@gmail.com> writes:
: I am still working on a port of FreeBSD to the beagleboard, and am
: currently working on enabling the VM. So far, I have loaded the kernel
: at phys_addr = virt_addr = 0x80000000, because that is where the RAM
: is. However, when enabling the VM, I would like the kernel virtual
: addresses to start with 0xC0000000 as they do on most other platform.

This isn't a bad idea...

: Hence, I have been trying to set the ELF file sections' VMAs to
: something starting with 0xC and the LMAs to something starting with
: 0x8. It turns out that just setting KERNPHYSADDR and KERNVIRTADDR is
: not enough >.< If found a way to do this by chaning the script linker
: and adding AT after each section declaration, and it works fine. But
: it's tedious, hacky and lots of hardcoded values only work with my
: platform.

Want to share?

: Googling for ideas, I found that there has been some discussion about
: it barely a year ago. Yet, it doesn't seem to have yielded any
: tangible result. Would someone have addressed the progress in the mean
: time?
: 
: I guess another way to look at it would be to work it around by also
: porting a full-fledged loader(8). A task which I have delayed to until
: I get a booting kernel - maybe not the wisest move :) Still, I'm
: curious about the possibility of specifying distinct LMAs and VMAs for
: the kernel executable.

Its already there, but requires a lot of code in the primary boot
loader to call back into to do things like loading files and doing
network I/O.

Also, while a secondary boot loader makes sense in the higher end
booting environment where you have lots of storage (say an SD or CF
card), it doesn't make so much sense for a more constrained boot a
ramdisk from flash setup.

Warner
From stas at FreeBSD.org  Thu May 21 21:04:08 2009
From: stas at FreeBSD.org (Stanislav Sedov)
Date: Thu May 21 21:04:15 2009
Subject: LMA != VMA when compiling a kernel
In-Reply-To: <fd183dc60905211318v67d77378t4100f3a0035124ed@mail.gmail.com>
References: <fd183dc60905211318v67d77378t4100f3a0035124ed@mail.gmail.com>
Message-ID: <20090522010439.1ae3d8c1.stas@FreeBSD.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, 21 May 2009 22:18:11 +0200
Guillaume Ballet <gballet@gmail.com> mentioned:

> Hello list,
> 
> I am still working on a port of FreeBSD to the beagleboard, and am
> currently working on enabling the VM. So far, I have loaded the kernel
> at phys_addr = virt_addr = 0x80000000, because that is where the RAM
> is. However, when enabling the VM, I would like the kernel virtual
> addresses to start with 0xC0000000 as they do on most other platform.
> 
> Hence, I have been trying to set the ELF file sections' VMAs to
> something starting with 0xC and the LMAs to something starting with
> 0x8. It turns out that just setting KERNPHYSADDR and KERNVIRTADDR is
> not enough >.< If found a way to do this by chaning the script linker
> and adding AT after each section declaration, and it works fine. But
> it's tedious, hacky and lots of hardcoded values only work with my
> platform.
> 

Does beagleboard use PXA cpu? I know only one place where the physical
memory location for PXA is hardcoded, and I belive it should work fine
after changing it...

- -- 
Stanislav Sedov
ST4096-RIPE
-----BEGIN PGP SIGNATURE-----

iEYEARECAAYFAkoVwe0ACgkQK/VZk+smlYEfZgCfdTzYvcyQhghzClcHkXV3ccI7
8JwAn36Gw/pkJVS+jPEM3MiUiSqRKrOE
=hWi6
-----END PGP SIGNATURE-----

!DSPAM:4a15c1c6994291674276043!


From raj at semihalf.com  Sat May 23 16:43:36 2009
From: raj at semihalf.com (Rafal Jaworowski)
Date: Sat May 23 16:43:43 2009
Subject: LMA != VMA when compiling a kernel
In-Reply-To: <fd183dc60905211318v67d77378t4100f3a0035124ed@mail.gmail.com>
References: <fd183dc60905211318v67d77378t4100f3a0035124ed@mail.gmail.com>
Message-ID: <C6332D5C-8497-4209-ABE2-C535737A589B@semihalf.com>


On 2009-05-21, at 22:18, Guillaume Ballet wrote:

> I am still working on a port of FreeBSD to the beagleboard, and am
> currently working on enabling the VM. So far, I have loaded the kernel
> at phys_addr = virt_addr = 0x80000000, because that is where the RAM
> is. However, when enabling the VM, I would like the kernel virtual
> addresses to start with 0xC0000000 as they do on most other platform.
>
> Hence, I have been trying to set the ELF file sections' VMAs to
> something starting with 0xC and the LMAs to something starting with
> 0x8. It turns out that just setting KERNPHYSADDR and KERNVIRTADDR is
> not enough >.< If found a way to do this by chaning the script linker
> and adding AT after each section declaration, and it works fine. But
> it's tedious, hacky and lots of hardcoded values only work with my
> platform.

What exactly are your problems with getting 0xC0000000 as the KVA  
base? It seems that all our current ARM variations follow this route  
and they all use a single linker script, so there shouldn't be major  
problems doing likewise with yet another port..

> Googling for ideas, I found that there has been some discussion about
> it barely a year ago. Yet, it doesn't seem to have yielded any
> tangible result. Would someone have addressed the progress in the mean
> time?
>
> I guess another way to look at it would be to work it around by also
> porting a full-fledged loader(8). A task which I have delayed to until
> I get a booting kernel - maybe not the wisest move :) Still, I'm
> curious about the possibility of specifying distinct LMAs and VMAs for
> the kernel executable.


The loader(8) entity is separate from how the kernel is linked, so I  
don't think that problems with kernel virtual addresses you mention  
could be worked around at the loader(8) level. Kernel linking/mapping  
should be addressed independently of any booting method involved.

Rafal

From ccna.syl at gmail.com  Sun May 24 19:31:19 2009
From: ccna.syl at gmail.com (Sylvestre Gallon)
Date: Sun May 24 19:31:26 2009
Subject: at91 SoC separation
Message-ID: <164b4c9c0905241206s570a15b1ob6214e9505329ae@mail.gmail.com>

Hi,

I am currently working on the at91sam9261ek port for the
Google Summer Of Code 2009.

Currently I work on how I could implement the at91sam9261ek
most efficiently. I notice that all the at91 code could be at91
System On Chip independent with some few changes.

The big work is to extract the SoC specific code in a separate file
by SoC. It's what I tried to do on my perforce :

perforce repo :
http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=//depot/projects/soc2009/syl_usb/src/sys/arm/at91&HIDEDEL=NO

Changes that I've done :
http://perforce.freebsd.org/changeList.cgi?FSPC=%2F%2Fdepot%2Fprojects%2Fsoc2009%2Fsyl_usb%2Fsrc%2Fsys%2Farm%2Fat91%2F...&USERS=syl&GROUPS=soc2009&ignore=GO!

One thing that continues to disturb me : On At91 SoC, the IPs and
their registers are quite the same. The only big change that exists
between these SoC are the base addresses for each IPs.  The different
SoC generic drivers may need IPs base addresses to perform the
mapping of registers. For the moment to not have some ugly
#ifdef like :

#ifdef __AT91RM9200__
#include <at91rm92reg.h>
#elif __AT91SAM9261__
#include <at91sam9261.h>
#elfi __ANOTHER_SOC__
#include <another_soc.h>
#endif

I have created base address accessors in the SoC file. But I'm not
sure I like that... Do you have some ideas to handle it in a better
way ?

When All the code of at91 will be SoC independents It will be very
easy to port any other at91 board (1 or 2 days of work by cpu).
I have also access to a lot of atmel board, I live near Atmel French
R&D  and know some people who work there who are ready to lend
me boards with these SoC :

- at91sam9260
- at91sam9261
- at91sam9263
- at91sam9rl
- at91sam9m10 (not officially out, and not yet in Linux ;) )
- at91cap9
- ..

I'am open to all suggestions, it is important for me to implement
the at91sam9261ek (and perhaps other) port the best way I can
to have a chance to see it in current after the Google Summer Of
Code :)

Cheers,

-- 
Sylvestre Gallon (http://devsyl.blogspot.com)
Fifth Grade Student @ Epitech & Researcher @ LSE
R&D @ Rathaxes (http://www.rathaxes.org)
From imp at bsdimp.com  Sun May 24 22:39:58 2009
From: imp at bsdimp.com (M. Warner Losh)
Date: Sun May 24 22:40:05 2009
Subject: at91 SoC separation
In-Reply-To: <164b4c9c0905241206s570a15b1ob6214e9505329ae@mail.gmail.com>
References: <164b4c9c0905241206s570a15b1ob6214e9505329ae@mail.gmail.com>
Message-ID: <20090524.163838.113805925.imp@bsdimp.com>

In message: <164b4c9c0905241206s570a15b1ob6214e9505329ae@mail.gmail.com>
            Sylvestre Gallon <ccna.syl@gmail.com> writes:
: Hi,
: 
: I am currently working on the at91sam9261ek port for the
: Google Summer Of Code 2009.
: 
: Currently I work on how I could implement the at91sam9261ek
: most efficiently. I notice that all the at91 code could be at91
: System On Chip independent with some few changes.
: 
: The big work is to extract the SoC specific code in a separate file
: by SoC. It's what I tried to do on my perforce :
: 
: perforce repo :
: http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=//depot/projects/soc2009/syl_usb/src/sys/arm/at91&HIDEDEL=NO
: 
: Changes that I've done :
: http://perforce.freebsd.org/changeList.cgi?FSPC=%2F%2Fdepot%2Fprojects%2Fsoc2009%2Fsyl_usb%2Fsrc%2Fsys%2Farm%2Fat91%2F...&USERS=syl&GROUPS=soc2009&ignore=GO!
: 
: One thing that continues to disturb me : On At91 SoC, the IPs and
: their registers are quite the same. The only big change that exists
: between these SoC are the base addresses for each IPs.  The different
: SoC generic drivers may need IPs base addresses to perform the
: mapping of registers. For the moment to not have some ugly
: #ifdef like :
: 
: #ifdef __AT91RM9200__
: #include <at91rm92reg.h>
: #elif __AT91SAM9261__
: #include <at91sam9261.h>
: #elfi __ANOTHER_SOC__
: #include <another_soc.h>
: #endif
: 
: I have created base address accessors in the SoC file. But I'm not
: sure I like that... Do you have some ideas to handle it in a better
: way ?
: 
: When All the code of at91 will be SoC independents It will be very
: easy to port any other at91 board (1 or 2 days of work by cpu).
: I have also access to a lot of atmel board, I live near Atmel French
: R&D  and know some people who work there who are ready to lend
: me boards with these SoC :
: 
: - at91sam9260
: - at91sam9261
: - at91sam9263
: - at91sam9rl
: - at91sam9m10 (not officially out, and not yet in Linux ;) )
: - at91cap9
: - ..
: 
: I'am open to all suggestions, it is important for me to implement
: the at91sam9261ek (and perhaps other) port the best way I can
: to have a chance to see it in current after the Google Summer Of
: Code :)


I've been thinking about the issues for a long time.  And there's a
number of interrelated problems.  All of them are related to the fact
that we have the core, SoC and board smashed into one file right now.
We really need to finish separating out the core support (it is mostly
done right now, except for some of the bus space stuff).  The SoC and
board support is all in at91.c, which really should be about
infrastructure not about boards...

First, you need to know what board you are on when you boot.  uboot
and others pass this information into the kernel using register r3,
IIRC.  So, there would need to be a way for the early boot code to
probe for one of a number of different boards.  For SoC, this could be
just one board compiled into the kernel (eg, you don't have run time
select), but Sam has done some work in this area on the xscale parts
you may be able to snag.

If we assume that there's a board init routine, we can assume that
init routine knows what kind of SoC is installed on the board and can
populate the atmelbus with the right devices by calling something like
at91rm9200_soc_init().  Then, that board routine can also do the
proper routing of the pins to the different peripherals as well,
possibly calling some generic peripheral init routines as well
(although that's a lot harder to arrange than you might otherwise
think given just how flexible these things are).  The board routine
would also be responsible for calling cninit() as well.

If we go this route, we can eliminate much of the #ifdef soup that you
were otherwise looking at doing.  The AT91RM9200 registers would be
defined in one place, but we'd try to use the base + offset approach
to isolate the number places that need this information.  That's one
of the problems with the current set of patches for the at91sam
boards: they just do ifdefs rather than do the proper refactoring to
get us the most amount of support.

So the typical board package would look something like:

int
kb9202_probe()
{
	if (arm_board_id_from_loader() != KB9202_BOARD_ID)
		return ENXIO;
	return 0;
}

int
kb9202_init()
{
	at91rm9200_soc_init();
	/*
	 * <insert the contents from board_kb920x.c's board_init()
	 * here>
	 */
	/*
	 * Map in the pmap entries needed on this board for flash, CF,
	 * etc
	 */
	/*
	 * Create some kind of descriptor to tell the SD card what GPIO
	 * pins are used for different things, what the MAC address
	 * of the board is, etc.  Maybe need one per driver and a list
	 * of them for this board
	 */
}

ARM_BOARD_TYPE(kb9202_probe, kb9202_init);

As an aside, you may also need to make the different boot loaders
pluggable as well, or maybe we would do that as part of another pass.
You could assume they were all uboot compatible or something...  Linux
defines a standard here, and we'd be wise to follow it...

Obviously, you'd need to rewrite arm_init as well to defer some of the
things it does now.  You'd need to move pmap init stuff to the
at91rm9200_soc_init(), except for the CF/FLASH stuff, which would move
to a board-level init.  Some of the mappings might need to change that
are done currently inline (which may mean we'd have to do some much
needed refactoring here).  Right now board_init is in a very special
place, and we'd likely need to move the cninit() into each board init
so that the boards could control which console was used.

There's also some ideas going around about being able to load hints
dynamically at run time and the foo_soc_init() and board_init routines
would just load them up correctly.  That's another orthogonal way to
move the tables out of at91rm9200_soc_init and into an easier to
manage text form, but at the expense of needing to add code to the
hints mechanism, and fight the bike-sheds that surround its
replacement.  So I'd frankly avoid this for the SoC project.  Getting
good separation is more important than having a perfect mechanism the
separation can use.

Those are just the top level ideas I have with respect to this port.
In fact, we could generalize this to all embedded boards since I
believe it scales well.  Linux does something similar, and to add a
new board is about a hundred lines, and a new SoC maybe ~400 more.

I think getting a good separation would be the key element to focus
on, as well as picking one or two other SoCs/boards to validate that
the design works and scales.  Make those the first priority.  Once you
have them in place and working, then if you've done things right
you'll be able to add all those other cool boards quickly, subject to
the availability of drivers and quirks for silicon bugs (oh, and free
time).

Comments?

Warner
From ccna.syl at gmail.com  Mon May 25 07:41:04 2009
From: ccna.syl at gmail.com (Sylvestre Gallon)
Date: Mon May 25 07:41:16 2009
Subject: at91 SoC separation
In-Reply-To: <20090524.163838.113805925.imp@bsdimp.com>
References: <164b4c9c0905241206s570a15b1ob6214e9505329ae@mail.gmail.com> 
	<20090524.163838.113805925.imp@bsdimp.com>
Message-ID: <164b4c9c0905250039o73cd1833xbbe3aeaa9ea0f3a6@mail.gmail.com>

On Mon, May 25, 2009 at 12:38 AM, M. Warner Losh <imp@bsdimp.com> wrote:
>
> I've been thinking about the issues for a long time. ?And there's a
> number of interrelated problems. ?All of them are related to the fact
> that we have the core, SoC and board smashed into one file right now.
> We really need to finish separating out the core support (it is mostly
> done right now, except for some of the bus space stuff). ?The SoC and
> board support is all in at91.c, which really should be about
> infrastructure not about boards...
>
> First, you need to know what board you are on when you boot. ?uboot
> and others pass this information into the kernel using register r3,
> IIRC. ?So, there would need to be a way for the early boot code to
> probe for one of a number of different boards. ?For SoC, this could be
> just one board compiled into the kernel (eg, you don't have run time
> select), but Sam has done some work in this area on the xscale parts
> you may be able to snag.

It is what I've tried to do for SoC:

Each board must have a device with a SoC name :

http://perforce.freebsd.org/fileViewer.cgi?FSPC=//depot/projects/soc2009/syl_usb/src/sys/arm/at91/std.bwct&REV=2
http://perforce.freebsd.org/fileViewer.cgi?FSPC=//depot/projects/soc2009/syl_usb/src/sys/arm/at91/std.at91sam9261ek&REV=1

This allow the compile of the good SoC file :

http://perforce.freebsd.org/fileViewer.cgi?FSPC=//depot/projects/soc2009/syl_usb/src/sys/arm/at91/files.at91&REV=3

The SoC file contains the code SoC dependent :

http://perforce.freebsd.org/fileViewer.cgi?FSPC=//depot/projects/soc2009/syl_usb/src/sys/arm/at91/soc_at91rm9200.c&REV=4
http://perforce.freebsd.org/fileViewer.cgi?FSPC=//depot/projects/soc2009/syl_usb/src/sys/arm/at91/soc_at91sam9261.c&REV=3

All this changes allow me to move at91.c into a code SoC independent :

http://perforce.freebsd.org/fileViewer.cgi?FSPC=//depot/projects/soc2009/syl_usb/src/sys/arm/at91/at91.c&REV=3

I think this is important to have a SoC file because there are some
big changes between each SoC the at91_master_clock, cpu_devs
and the pmap_devmap are not the same on each SoC.

>
> If we assume that there's a board init routine, we can assume that
> init routine knows what kind of SoC is installed on the board and can
> populate the atmelbus with the right devices by calling something like
> at91rm9200_soc_init(). ?Then, that board routine can also do the
> proper routing of the pins to the different peripherals as well,
> possibly calling some generic peripheral init routines as well
> (although that's a lot harder to arrange than you might otherwise
> think given just how flexible these things are). ?The board routine
> would also be responsible for calling cninit() as well.
>
> If we go this route, we can eliminate much of the #ifdef soup that you
> were otherwise looking at doing. ?The AT91RM9200 registers would be
> defined in one place, but we'd try to use the base + offset approach
> to isolate the number places that need this information. ?That's one
> of the problems with the current set of patches for the at91sam
> boards: they just do ifdefs rather than do the proper refactoring to
> get us the most amount of support.
>
> So the typical board package would look something like:
>
> int
> kb9202_probe()
> {
> ? ? ? ?if (arm_board_id_from_loader() != KB9202_BOARD_ID)
> ? ? ? ? ? ? ? ?return ENXIO;
> ? ? ? ?return 0;
> }
>
> int
> kb9202_init()
> {
> ? ? ? ?at91rm9200_soc_init();
> ? ? ? ?/*
> ? ? ? ? * <insert the contents from board_kb920x.c's board_init()
> ? ? ? ? * here>
> ? ? ? ? */
> ? ? ? ?/*
> ? ? ? ? * Map in the pmap entries needed on this board for flash, CF,
> ? ? ? ? * etc
> ? ? ? ? */
> ? ? ? ?/*
> ? ? ? ? * Create some kind of descriptor to tell the SD card what GPIO
> ? ? ? ? * pins are used for different things, what the MAC address
> ? ? ? ? * of the board is, etc. ?Maybe need one per driver and a list
> ? ? ? ? * of them for this board
> ? ? ? ? */
> }
>
> ARM_BOARD_TYPE(kb9202_probe, kb9202_init);
>
> As an aside, you may also need to make the different boot loaders
> pluggable as well, or maybe we would do that as part of another pass.
> You could assume they were all uboot compatible or something... ?Linux
> defines a standard here, and we'd be wise to follow it...
>
> Obviously, you'd need to rewrite arm_init as well to defer some of the
> things it does now. ?You'd need to move pmap init stuff to the
> at91rm9200_soc_init(), except for the CF/FLASH stuff, which would move
> to a board-level init. ?Some of the mappings might need to change that
> are done currently inline (which may mean we'd have to do some much
> needed refactoring here). ?Right now board_init is in a very special
> place, and we'd likely need to move the cninit() into each board init
> so that the boards could control which console was used.

The cninit has not move now but I have also moved pmap init stuff into
the SoC file :

http://perforce.freebsd.org/fileViewer.cgi?FSPC=//depot/projects/soc2009/syl_usb/src/sys/arm/at91/soc_at91rm9200.c&REV=4
http://perforce.freebsd.org/fileViewer.cgi?FSPC=//depot/projects/soc2009/syl_usb/src/sys/arm/at91/soc_at91sam9261.c&REV=3

For that have done some little change in the machedep.c to be
SoC independent :

http://perforce.freebsd.org/fileViewer.cgi?FSPC=//depot/projects/soc2009/syl_usb/src/sys/arm/at91/at91_machdep.c&REV=2

>
> There's also some ideas going around about being able to load hints
> dynamically at run time and the foo_soc_init() and board_init routines
> would just load them up correctly. ?That's another orthogonal way to
> move the tables out of at91rm9200_soc_init and into an easier to
> manage text form, but at the expense of needing to add code to the
> hints mechanism, and fight the bike-sheds that surround its
> replacement. ?So I'd frankly avoid this for the SoC project. ?Getting
> good separation is more important than having a perfect mechanism the
> separation can use.

I am totally agree.

Thanks for your help :)

Cheers,

-- 
Sylvestre Gallon (http://devsyl.blogspot.com)
Fifth Grade Student @ Epitech & Researcher @ LSE
R&D @ Rathaxes (http://www.rathaxes.org)
From bugmaster at FreeBSD.org  Mon May 25 11:06:48 2009
From: bugmaster at FreeBSD.org (FreeBSD bugmaster)
Date: Mon May 25 11:07:30 2009
Subject: Current problem reports assigned to freebsd-arm@FreeBSD.org
Message-ID: <200905251106.n4PB6lLe092717@freefall.freebsd.org>

Note: to view an individual PR, use:
  http://www.freebsd.org/cgi/query-pr.cgi?pr=(number).

The following is a listing of current problems submitted by FreeBSD users.
These represent problem reports covering all versions including
experimental development code and obsolete releases.


S Tracker      Resp.      Description
--------------------------------------------------------------------------------
o arm/134368   arm        [patch] nslu2_led driver for the LEDs on the NSLU2
o arm/134338   arm        [patch] Lock GPIO accesses on ixp425
o arm/134092   arm        [patch] NSLU.hints contains wrong hints for on board n

3 problems total.

From tinguely at casselton.net  Tue May 26 15:52:01 2009
From: tinguely at casselton.net (Mark Tinguely)
Date: Tue May 26 15:52:09 2009
Subject: at91 SoC separation
In-Reply-To: <20090524.163838.113805925.imp@bsdimp.com>
Message-ID: <200905261551.n4QFpt1w084810@casselton.net>


As a side, slightly off-topic note, I have been thinking of the whole boot
process. 

The different ARM architecture/board boot sequences are basically the same.
I agree that the main difference between the different ARM boards are the
difference in the locations of devices map.

Right now, the init_arm() manually allocates the "level one" page tables 
so they are available for the pmap_devmap_bootstrap() call.

The devmap bootstrap can be modified to automatically allocate any missing
"level one" page tables from the end of the free memory pointer. The
updated end of free memory is sent back to the initialation routine.
Add a few calls for architecture initialization and ever board can use
the same boot routine.

I agree this is not a SoC scoped add-on project.

--Mark Tinguely
From imp at bsdimp.com  Tue May 26 17:13:24 2009
From: imp at bsdimp.com (M. Warner Losh)
Date: Tue May 26 17:13:30 2009
Subject: at91 SoC separation
In-Reply-To: <200905261551.n4QFpt1w084810@casselton.net>
References: <20090524.163838.113805925.imp@bsdimp.com>
	<200905261551.n4QFpt1w084810@casselton.net>
Message-ID: <20090526.111055.1849561573.imp@bsdimp.com>

In message: <200905261551.n4QFpt1w084810@casselton.net>
            Mark Tinguely <tinguely@casselton.net> writes:
: 
: As a side, slightly off-topic note, I have been thinking of the whole boot
: process. 
: 
: The different ARM architecture/board boot sequences are basically the same.
: I agree that the main difference between the different ARM boards are the
: difference in the locations of devices map.
: 
: Right now, the init_arm() manually allocates the "level one" page tables 
: so they are available for the pmap_devmap_bootstrap() call.
: 
: The devmap bootstrap can be modified to automatically allocate any missing
: "level one" page tables from the end of the free memory pointer. The
: updated end of free memory is sent back to the initialation routine.
: Add a few calls for architecture initialization and ever board can use
: the same boot routine.

That's another can of worms that we need to detangle :)

I rather like this idea.  I also like the idea of having different
boot loader front ends that drive this rather than having the SoC code
drive it.  We are a little too tightly coupled between boot loader and
soc at the moment as well.

The work isn't horribly hard, just tedious because you have to run
down a bunch of different boards we support and see why the routines
are different and account for those differences, or hopefully,
eliminate them.  It is the latter that's going to be a challenge.

Warner
From tinderbox at freebsd.org  Wed May 27 10:24:33 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Wed May 27 10:24:40 2009
Subject: [head tinderbox] failure on arm/arm
Message-ID: <20090527102430.61B2B7302F@freebsd-current.sentex.ca>

TB --- 2009-05-27 09:40:01 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2009-05-27 09:40:01 - starting HEAD tinderbox run for arm/arm
TB --- 2009-05-27 09:40:01 - cleaning the object tree
TB --- 2009-05-27 09:40:35 - cvsupping the source tree
TB --- 2009-05-27 09:40:35 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/arm/arm/supfile
TB --- 2009-05-27 09:40:46 - building world
TB --- 2009-05-27 09:40:46 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-05-27 09:40:46 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-05-27 09:40:46 - TARGET=arm
TB --- 2009-05-27 09:40:46 - TARGET_ARCH=arm
TB --- 2009-05-27 09:40:46 - TZ=UTC
TB --- 2009-05-27 09:40:46 - __MAKE_CONF=/dev/null
TB --- 2009-05-27 09:40:46 - cd /src
TB --- 2009-05-27 09:40:46 - /usr/bin/make -B buildworld
>>> World build started on Wed May 27 09:40:49 UTC 2009
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3: cross tools
>>> stage 4.1: building includes
>>> stage 4.2: building libraries
>>> stage 4.3: make dependencies
>>> stage 4.4: building everything
[...]
cc -O -pipe  -DNEED_SOLARIS_BOOLEAN -I/src/cddl/usr.sbin/dtrace/../../../sys/cddl/compat/opensolaris  -I/src/cddl/usr.sbin/dtrace/../../../cddl/compat/opensolaris/include  -I/src/cddl/usr.sbin/dtrace/../../../cddl/contrib/opensolaris/head  -I/src/cddl/usr.sbin/dtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common  -I/src/cddl/usr.sbin/dtrace/../../../cddl/contrib/opensolaris/lib/libproc/common  -I/src/cddl/usr.sbin/dtrace/../../../sys/cddl/contrib/opensolaris/uts/common  -I/src/cddl/usr.sbin/dtrace/../../../sys/cddl/contrib/opensolaris/compat -DNEED_SOLARIS_BOOLEAN -std=gnu89 -Wsystem-headers -Werror -Wno-pointer-sign -Wno-unknown-pragmas  -pthread  -L/obj/arm/src/cddl/usr.sbin/dtrace/../../lib/libdtrace  -L/obj/arm/src/cddl/usr.sbin/dtrace/../../lib/libproc  -L/obj/arm/src/cddl/usr.sbin/dtrace/../../lib/libctf  -L/obj/arm/src/cddl/usr.sbin/dtrace/../../../lib/libelf -o dtrace dtrace.o -ldtrace -ly -ll -lproc -lctf -lelf -lz
gzip -cn /src/cddl/usr.sbin/dtrace/../../../cddl/contrib/opensolaris/cmd/dtrace/dtrace.1 > dtrace.1.gz
===> cddl/usr.sbin/lockstat (all)
cc -O -pipe  -DNEED_SOLARIS_BOOLEAN -I/src/cddl/usr.sbin/lockstat/../../../sys/cddl/compat/opensolaris  -I/src/cddl/usr.sbin/lockstat/../../../cddl/compat/opensolaris/include  -I/src/cddl/usr.sbin/lockstat/../../../cddl/contrib/opensolaris/head  -I/src/cddl/usr.sbin/lockstat/../../../cddl/contrib/opensolaris/lib/libdtrace/common  -I/src/cddl/usr.sbin/lockstat/../../../cddl/contrib/opensolaris/lib/libproc/common  -I/src/cddl/usr.sbin/lockstat/../../../sys/cddl/contrib/opensolaris/uts/common  -I/src/cddl/usr.sbin/lockstat/../../../sys/cddl/contrib/opensolaris/compat  -I/src/cddl/usr.sbin/lockstat/../../../sys -DNEED_ERRLOC -g -DNEED_SOLARIS_BOOLEAN -std=gnu89 -Wsystem-headers -Werror -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/usr.sbin/lockstat/../../../cddl/contrib/opensolaris/cmd/lockstat/lockstat.c
cc1: warnings being treated as errors
/src/cddl/usr.sbin/lockstat/../../../cddl/contrib/opensolaris/cmd/lockstat/lockstat.c: In function 'main':
/src/cddl/usr.sbin/lockstat/../../../cddl/contrib/opensolaris/cmd/lockstat/lockstat.c:1095: warning: comparison is always true due to limited range of data type
/src/cddl/usr.sbin/lockstat/../../../cddl/contrib/opensolaris/cmd/lockstat/lockstat.c:1389: warning: comparison is always true due to limited range of data type
*** Error code 1

Stop in /src/cddl/usr.sbin/lockstat.
*** Error code 1

Stop in /src/cddl/usr.sbin.
*** Error code 1

Stop in /src/cddl.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2009-05-27 10:24:30 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-05-27 10:24:30 - ERROR: failed to build world
TB --- 2009-05-27 10:24:30 - 1940.66 user 272.73 system 2669.09 real


http://tinderbox.des.no/tinderbox-head-HEAD-arm-arm.full
From tinderbox at freebsd.org  Wed May 27 19:24:39 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Wed May 27 19:24:52 2009
Subject: [head tinderbox] failure on arm/arm
Message-ID: <20090527192436.0CA2D7302F@freebsd-current.sentex.ca>

TB --- 2009-05-27 18:40:00 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2009-05-27 18:40:00 - starting HEAD tinderbox run for arm/arm
TB --- 2009-05-27 18:40:00 - cleaning the object tree
TB --- 2009-05-27 18:40:30 - cvsupping the source tree
TB --- 2009-05-27 18:40:30 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/arm/arm/supfile
TB --- 2009-05-27 18:40:51 - building world
TB --- 2009-05-27 18:40:51 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-05-27 18:40:51 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-05-27 18:40:51 - TARGET=arm
TB --- 2009-05-27 18:40:51 - TARGET_ARCH=arm
TB --- 2009-05-27 18:40:51 - TZ=UTC
TB --- 2009-05-27 18:40:51 - __MAKE_CONF=/dev/null
TB --- 2009-05-27 18:40:51 - cd /src
TB --- 2009-05-27 18:40:51 - /usr/bin/make -B buildworld
>>> World build started on Wed May 27 18:40:53 UTC 2009
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3: cross tools
>>> stage 4.1: building includes
>>> stage 4.2: building libraries
>>> stage 4.3: make dependencies
>>> stage 4.4: building everything
[...]
cc -O -pipe  -DNEED_SOLARIS_BOOLEAN -I/src/cddl/usr.sbin/dtrace/../../../sys/cddl/compat/opensolaris  -I/src/cddl/usr.sbin/dtrace/../../../cddl/compat/opensolaris/include  -I/src/cddl/usr.sbin/dtrace/../../../cddl/contrib/opensolaris/head  -I/src/cddl/usr.sbin/dtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common  -I/src/cddl/usr.sbin/dtrace/../../../cddl/contrib/opensolaris/lib/libproc/common  -I/src/cddl/usr.sbin/dtrace/../../../sys/cddl/contrib/opensolaris/uts/common  -I/src/cddl/usr.sbin/dtrace/../../../sys/cddl/contrib/opensolaris/compat -DNEED_SOLARIS_BOOLEAN -std=gnu89 -Wsystem-headers -Werror -Wno-pointer-sign -Wno-unknown-pragmas  -pthread  -L/obj/arm/src/cddl/usr.sbin/dtrace/../../lib/libdtrace  -L/obj/arm/src/cddl/usr.sbin/dtrace/../../lib/libproc  -L/obj/arm/src/cddl/usr.sbin/dtrace/../../lib/libctf  -L/obj/arm/src/cddl/usr.sbin/dtrace/../../../lib/libelf -o dtrace dtrace.o -ldtrace -ly -ll -lproc -lctf -lelf -lz
gzip -cn /src/cddl/usr.sbin/dtrace/../../../cddl/contrib/opensolaris/cmd/dtrace/dtrace.1 > dtrace.1.gz
===> cddl/usr.sbin/lockstat (all)
cc -O -pipe  -DNEED_SOLARIS_BOOLEAN -I/src/cddl/usr.sbin/lockstat/../../../sys/cddl/compat/opensolaris  -I/src/cddl/usr.sbin/lockstat/../../../cddl/compat/opensolaris/include  -I/src/cddl/usr.sbin/lockstat/../../../cddl/contrib/opensolaris/head  -I/src/cddl/usr.sbin/lockstat/../../../cddl/contrib/opensolaris/lib/libdtrace/common  -I/src/cddl/usr.sbin/lockstat/../../../cddl/contrib/opensolaris/lib/libproc/common  -I/src/cddl/usr.sbin/lockstat/../../../sys/cddl/contrib/opensolaris/uts/common  -I/src/cddl/usr.sbin/lockstat/../../../sys/cddl/contrib/opensolaris/compat  -I/src/cddl/usr.sbin/lockstat/../../../sys -DNEED_ERRLOC -g -DNEED_SOLARIS_BOOLEAN -std=gnu89 -Wsystem-headers -Werror -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/usr.sbin/lockstat/../../../cddl/contrib/opensolaris/cmd/lockstat/lockstat.c
cc1: warnings being treated as errors
/src/cddl/usr.sbin/lockstat/../../../cddl/contrib/opensolaris/cmd/lockstat/lockstat.c: In function 'main':
/src/cddl/usr.sbin/lockstat/../../../cddl/contrib/opensolaris/cmd/lockstat/lockstat.c:1095: warning: comparison is always true due to limited range of data type
/src/cddl/usr.sbin/lockstat/../../../cddl/contrib/opensolaris/cmd/lockstat/lockstat.c:1389: warning: comparison is always true due to limited range of data type
*** Error code 1

Stop in /src/cddl/usr.sbin/lockstat.
*** Error code 1

Stop in /src/cddl/usr.sbin.
*** Error code 1

Stop in /src/cddl.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2009-05-27 19:24:35 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-05-27 19:24:35 - ERROR: failed to build world
TB --- 2009-05-27 19:24:35 - 1937.95 user 273.95 system 2675.49 real


http://tinderbox.des.no/tinderbox-head-HEAD-arm-arm.full
From tinderbox at freebsd.org  Thu May 28 05:02:16 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Thu May 28 05:02:28 2009
Subject: [head tinderbox] failure on arm/arm
Message-ID: <20090528050213.5623F7302F@freebsd-current.sentex.ca>

TB --- 2009-05-28 04:00:00 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2009-05-28 04:00:00 - starting HEAD tinderbox run for arm/arm
TB --- 2009-05-28 04:00:00 - cleaning the object tree
TB --- 2009-05-28 04:00:33 - cvsupping the source tree
TB --- 2009-05-28 04:00:33 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/arm/arm/supfile
TB --- 2009-05-28 04:00:45 - building world
TB --- 2009-05-28 04:00:45 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-05-28 04:00:45 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-05-28 04:00:45 - TARGET=arm
TB --- 2009-05-28 04:00:45 - TARGET_ARCH=arm
TB --- 2009-05-28 04:00:45 - TZ=UTC
TB --- 2009-05-28 04:00:45 - __MAKE_CONF=/dev/null
TB --- 2009-05-28 04:00:45 - cd /src
TB --- 2009-05-28 04:00:45 - /usr/bin/make -B buildworld
>>> World build started on Thu May 28 04:00:49 UTC 2009
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3: cross tools
>>> stage 4.1: building includes
>>> stage 4.2: building libraries
>>> stage 4.3: make dependencies
>>> stage 4.4: building everything
[...]
cc1: warnings being treated as errors
/src/usr.bin/ee/../../contrib/ee/ee.c: In function 'out_char':
/src/usr.bin/ee/../../contrib/ee/ee.c:957: warning: comparison is always true due to limited range of data type
/src/usr.bin/ee/../../contrib/ee/ee.c:961: warning: comparison is always false due to limited range of data type
/src/usr.bin/ee/../../contrib/ee/ee.c:967: warning: comparison is always false due to limited range of data type
/src/usr.bin/ee/../../contrib/ee/ee.c: In function 'len_char':
/src/usr.bin/ee/../../contrib/ee/ee.c:995: warning: comparison is always true due to limited range of data type
/src/usr.bin/ee/../../contrib/ee/ee.c:1001: warning: comparison is always false due to limited range of data type
*** Error code 1

Stop in /src/usr.bin/ee.
*** Error code 1

Stop in /src/usr.bin.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2009-05-28 05:02:13 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-05-28 05:02:13 - ERROR: failed to build world
TB --- 2009-05-28 05:02:13 - 2841.54 user 358.69 system 3732.62 real


http://tinderbox.des.no/tinderbox-head-HEAD-arm-arm.full
From tinguely at casselton.net  Thu May 28 23:20:10 2009
From: tinguely at casselton.net (Mark Tinguely)
Date: Thu May 28 23:20:19 2009
Subject: cache corruption patch
Message-ID: <200905282320.n4SNK87M043401@casselton.net>


There has been several occurrences of memory corruption in ARM due to caching
issues. A couple recent examples are problems with the SATA drive and new USB
code.

This patch tracks kernel mapped pages and detects when they are shared
with existing user mapped pages and other kernel mapped pages. This patch
has gone through some refinement in the last couple days with feed back
from testers and is getting ready for being committed before the FreeBSD 8.0
freeze.

This patch should allow the removal of added cache invalidation commands to
the dma. 

The patch is located at:

	http://www.casselton.net/~tinguely/arm_pmap_unmanaged.diff

For those interested, I can give a long explanation of the patch.

--Mark Tinguely
From gballet at gmail.com  Sat May 30 13:24:13 2009
From: gballet at gmail.com (Guillaume Ballet)
Date: Sat May 30 13:24:20 2009
Subject: LMA != VMA when compiling a kernel
In-Reply-To: <20090521.145552.410235390.imp@bsdimp.com>
References: <fd183dc60905211318v67d77378t4100f3a0035124ed@mail.gmail.com>
	<20090521.145552.410235390.imp@bsdimp.com>
Message-ID: <fd183dc60905300624r64914527wd7700a22a797a645@mail.gmail.com>

> : Hence, I have been trying to set the ELF file sections' VMAs to
> : something starting with 0xC and the LMAs to something starting with
> : 0x8. It turns out that just setting KERNPHYSADDR and KERNVIRTADDR is
> : not enough >.< If found a way to do this by chaning the script linker
> : and adding AT after each section declaration, and it works fine. But
> : it's tedious, hacky and lots of hardcoded values only work with my
> : platform.
>
> Want to share?

There's not much to share actually: I tried to use the AT keyword in
the script linker. What I did was essentially:

--- conf/ldscript.arm   2009-05-30 14:05:44.000000000 +0000
+++ conf/ldscript.arm.lma       2009-05-30 14:05:24.000000000 +0000
@@ -8,7 +8,7 @@
 {
   /* Read-only sections, merged into text segment: */
   . = KERNVIRTADDR + SIZEOF_HEADERS;
-  .text      : AT(KERNPHYSADDR + SIZEOF_HEADERS)
+  .text      :
   {
     *(.text)
     *(.stub)

Doing so, I was able to change the LMA for the text section. The
problem is that address arithmetic doesn't seem to work that well
inside AT() - so at this moment I am unable to do this for _every_
section. I'm sure it should be possible, but haven't found the time to
study this just yet. I don't think I will investigate this any
further: Indeed, locore.S sets up a temporary TLB system to be able to
access virtual addresses during boot.
If someones knows the syntax to do address calculations inside AT(),
however, I am interested nonetheless :) I was thinking about using
something like MEMORY, but that idea needs some thinking through.

>
> Also, while a secondary boot loader makes sense in the higher end
> booting environment where you have lots of storage (say an SD or CF
> card), it doesn't make so much sense for a more constrained boot a
> ramdisk from flash setup.

I am indeed running from SD card. I face two choices: My first choice
is to load everything with u-boot prior to starting the kernel. The
other one is to have the whole loader(8) facility. Since the first
choice requires some tedious typing in u-boot, I would love to have a
loader(8) script to do all the dirty work for me :D But it can wait.

Cheers,
Guillaume
From gballet at gmail.com  Sat May 30 13:26:59 2009
From: gballet at gmail.com (Guillaume Ballet)
Date: Sat May 30 13:27:06 2009
Subject: LMA != VMA when compiling a kernel
In-Reply-To: <20090522010439.1ae3d8c1.stas@FreeBSD.org>
References: <fd183dc60905211318v67d77378t4100f3a0035124ed@mail.gmail.com>
	<20090522010439.1ae3d8c1.stas@FreeBSD.org>
Message-ID: <fd183dc60905300626g5d8dbc6ak5ee24c8b10083dd8@mail.gmail.com>

>
> Does beagleboard use PXA cpu? I know only one place where the physical
> memory location for PXA is hardcoded, and I belive it should work fine
> after changing it...
>

Actually, it's based on the Cortex-A8, not Xscale. Still, my aim is
obviously to hardcode as little as possible :)
From gballet at gmail.com  Sat May 30 13:34:24 2009
From: gballet at gmail.com (Guillaume Ballet)
Date: Sat May 30 13:34:30 2009
Subject: LMA != VMA when compiling a kernel
In-Reply-To: <C6332D5C-8497-4209-ABE2-C535737A589B@semihalf.com>
References: <fd183dc60905211318v67d77378t4100f3a0035124ed@mail.gmail.com>
	<C6332D5C-8497-4209-ABE2-C535737A589B@semihalf.com>
Message-ID: <fd183dc60905300634q17c390bdwe1301d57d4ab83fc@mail.gmail.com>

On Sat, May 23, 2009 at 6:43 PM, Rafal Jaworowski <raj@semihalf.com> wrote:
>
> On 2009-05-21, at 22:18, Guillaume Ballet wrote:
>
>> I am still working on a port of FreeBSD to the beagleboard, and am
>> currently working on enabling the VM. So far, I have loaded the kernel
>> at phys_addr = virt_addr = 0x80000000, because that is where the RAM
>> is. However, when enabling the VM, I would like the kernel virtual
>> addresses to start with 0xC0000000 as they do on most other platform.
>>
>> Hence, I have been trying to set the ELF file sections' VMAs to
>> something starting with 0xC and the LMAs to something starting with
>> 0x8. It turns out that just setting KERNPHYSADDR and KERNVIRTADDR is
>> not enough >.< If found a way to do this by chaning the script linker
>> and adding AT after each section declaration, and it works fine. But
>> it's tedious, hacky and lots of hardcoded values only work with my
>> platform.
>
> What exactly are your problems with getting 0xC0000000 as the KVA base? It
> seems that all our current ARM variations follow this route and they all use
> a single linker script, so there shouldn't be major problems doing likewise
> with yet another port..

The problem is not setting 0xC0000000 as the KVA base, it's that when
KVA != KPA, the ELF header creates a file that has KVA == KLA anyway.
Now, as I found out, most of the problems can be circumvented by
setting up a temporary TLB system so that the startup code can still
access its data segments even though the final VM system has not been
initialized.
The last remaining problem I face is that the loader (not loader(8) at
the moment) needs to know the physical address at which the kernel
must be loaded. But since KVA==LMA in the ELF header, some information
is lost as far as I know. Now, if the loader for other boards is
indeed able to extract that piece of information from the ELF header
itself, I would love to get some pointers to the solution :)

>
> The loader(8) entity is separate from how the kernel is linked, so I don't
> think that problems with kernel virtual addresses you mention could be
> worked around at the loader(8) level. Kernel linking/mapping should be
> addressed independently of any booting method involved.
>

I agree, they should :P I am surely not searching at the right
location, but I haven't found anything like a complete loader + boot
stages in the source tree. Where should I look? I wonder if most
system start in locore.S with the MMU already enabled from the loader,
or most of them use the one that is built from scratch in that file?