Re: ARM Firewall Hardware
Am 16.01.2015 um 08:49 schrieb Jonathan Gray j...@jsg.id.au: On Fri, Jan 16, 2015 at 07:59:49AM +0100, Christer Solskogen wrote: On Wed, Jan 14, 2015 at 7:19 PM, Christer Solskogen christer.solsko...@gmail.com wrote: On Wed, Jan 14, 2015 at 3:39 PM, Jonathan Gray j...@jsg.id.au wrote: I've updated the kernel at http://jsg.id.au/openbsd/bsd.IMX.umg And we have lift-off! Will the changes go in-tree soon? :-) The diffs are up for review, I'll likely commit them sometime soon if I don't hear any objections. A new snapshot with the changes should hit the mirrors in a day or two. Keep in mind not everything will work. Looking at http://compulab.co.il/utilite-computer/web/wp-content/uploads/2013/07/Utilite-block-diagram.png imx PCIE isn't supported currently so the I211 em(4) won't attach. The i2c connected eeprom with the mac address for the ixmnet(4) interface and the i2c connected rtc won't work. And I don't see how audio/video/wifi could work currently. Got PCIe to work. Unfortunately the i211 em(4) doesn’t attach as it doesn’t have the usual eeprom, but some kind of OTP which needs to be read differently. I wrote a working diff and mail it to jsg@ for advice and review. Unfortunately the i211’s mac address isn’t in the Utilite’s em(4) OTP either, which it usually should be. Apparently they put in the cheapest hardware to „make it work“. The mac address is stored in another eeprom connected to i2c. I don’t really see a way to make em(4) get that mac address. It’d probably either need a huge hack or some other API that does not exist. :( As of now I made it use a random address every time. For the mac address eeprom at least there is some code in Bitrig which could be used.
Re: ARM Firewall Hardware
Am 16.01.2015 um 08:49 schrieb Jonathan Gray j...@jsg.id.au: On Fri, Jan 16, 2015 at 07:59:49AM +0100, Christer Solskogen wrote: On Wed, Jan 14, 2015 at 7:19 PM, Christer Solskogen christer.solsko...@gmail.com wrote: On Wed, Jan 14, 2015 at 3:39 PM, Jonathan Gray j...@jsg.id.au wrote: I've updated the kernel at http://jsg.id.au/openbsd/bsd.IMX.umg And we have lift-off! Will the changes go in-tree soon? :-) The diffs are up for review, I'll likely commit them sometime soon if I don't hear any objections. A new snapshot with the changes should hit the mirrors in a day or two. Keep in mind not everything will work. Looking at http://compulab.co.il/utilite-computer/web/wp-content/uploads/2013/07/Utilite-block-diagram.png imx PCIE isn't supported currently so the I211 em(4) won't attach. The i2c connected eeprom with the mac address for the ixmnet(4) interface and the i2c connected rtc won't work. And I don't see how audio/video/wifi could work currently. For the mac address eeprom at least there is some code in Bitrig which could be used. I do have some PCIe code, but as I already stated somewhere it’s functional enough to have the em(4) or other devices work. :(
Re: ARM Firewall Hardware
On Wed, Jan 14, 2015 at 7:19 PM, Christer Solskogen christer.solsko...@gmail.com wrote: On Wed, Jan 14, 2015 at 3:39 PM, Jonathan Gray j...@jsg.id.au wrote: I've updated the kernel at http://jsg.id.au/openbsd/bsd.IMX.umg And we have lift-off! Will the changes go in-tree soon? :-) -- chs
Re: ARM Firewall Hardware
On Fri, Jan 16, 2015 at 07:59:49AM +0100, Christer Solskogen wrote: On Wed, Jan 14, 2015 at 7:19 PM, Christer Solskogen christer.solsko...@gmail.com wrote: On Wed, Jan 14, 2015 at 3:39 PM, Jonathan Gray j...@jsg.id.au wrote: I've updated the kernel at http://jsg.id.au/openbsd/bsd.IMX.umg And we have lift-off! Will the changes go in-tree soon? :-) The diffs are up for review, I'll likely commit them sometime soon if I don't hear any objections. A new snapshot with the changes should hit the mirrors in a day or two. Keep in mind not everything will work. Looking at http://compulab.co.il/utilite-computer/web/wp-content/uploads/2013/07/Utilite-block-diagram.png imx PCIE isn't supported currently so the I211 em(4) won't attach. The i2c connected eeprom with the mac address for the ixmnet(4) interface and the i2c connected rtc won't work. And I don't see how audio/video/wifi could work currently. For the mac address eeprom at least there is some code in Bitrig which could be used.
Re: ARM Firewall Hardware
On Tue, Jan 13, 2015 at 06:52:00PM +0100, Christer Solskogen wrote:
On Tue, Jan 13, 2015 at 5:45 PM, Jonathan Gray j...@jsg.id.au wrote:
Your earlier mail had a different load address than what I'd expect.
Try 0x1880
Same. I've tried the following staring adresses: 0x1060 -
0x1880 - 0x1080
The last one is what I use to boot bitrig.
I've updated the kernel at
http://jsg.id.au/openbsd/bsd.IMX.umg
Includes changes similiar to those made in the following Bitrig commits:
commit f2fb0a86fc740253d02c7eb3f6d26ea48346be55
Author: Patrick Wildt patr...@blueri.se
Date: Thu Jan 16 15:37:54 2014 +0100
When restoring SPSR, use spsr_fsxc so bits[23-8] are restored.
Spsr_all doesn't restore all bits!
This should fix use of simd instructions that rely on
the GE bits. Also, this fixes our cold boot crash on
the Utilite and Nitrogen 6x.
From NetBSD.
ok drahn@
commit 6ea8cdd3daffb2edde3eadf87d3fea6d2f47384c
Author: Patrick Wildt patr...@blueri.se
Date: Sat Dec 7 15:04:09 2013 +0100
Load additional memory space into UVM.
Also bump the amount of 'space' to 2. More space has not
been observed yet.
ok drahn@
Index: arm/arm/cpufunc_asm_sa1.S
===
RCS file: /cvs/src/sys/arch/arm/arm/cpufunc_asm_sa1.S,v
retrieving revision 1.3
diff -u -p -r1.3 cpufunc_asm_sa1.S
--- arm/arm/cpufunc_asm_sa1.S 20 Sep 2011 22:11:40 - 1.3
+++ arm/arm/cpufunc_asm_sa1.S 14 Jan 2015 13:06:40 -
@@ -46,9 +46,9 @@
* addresses that are about to change.
*/
ENTRY(sa1_setttb)
- mrs r3, cpsr_all
+ mrs r3, cpsr
orr r1, r3, #(I32_bit | F32_bit)
- msr cpsr_all, r1
+ msr cpsr_fsxc, r1
stmfd sp!, {r0-r3, lr}
bl _C_LABEL(sa1_cache_cleanID)
@@ -69,7 +69,7 @@ ENTRY(sa1_setttb)
mov r0, r0
mov r0, r0
- msr cpsr_all, r3
+ msr cpsr_fsxc, r3
mov pc, lr
/*
@@ -131,12 +131,12 @@ _C_LABEL(sa1_cache_clean_size):
.word _C_LABEL(sa1_cache_clean_size)
#defineSA1_CACHE_CLEAN_BLOCK
\
- mrs r3, cpsr_all; \
+ mrs r3, cpsr; \
orr r0, r3, #(I32_bit | F32_bit); \
- msr cpsr_all, r0
+ msr cpsr_fsxc, r0
#defineSA1_CACHE_CLEAN_UNBLOCK
\
- msr cpsr_all, r3
+ msr cpsr_fsxc, r3
#ifdef DOUBLE_CACHE_CLEAN_BANK
#defineSA1_DOUBLE_CACHE_CLEAN_BANK
\
Index: arm/arm/cpufunc_asm_xscale.S
===
RCS file: /cvs/src/sys/arch/arm/arm/cpufunc_asm_xscale.S,v
retrieving revision 1.4
diff -u -p -r1.4 cpufunc_asm_xscale.S
--- arm/arm/cpufunc_asm_xscale.S20 Sep 2011 22:11:40 - 1.4
+++ arm/arm/cpufunc_asm_xscale.S14 Jan 2015 13:06:40 -
@@ -128,9 +128,9 @@ ENTRY(xscale_control)
* addresses that are about to change.
*/
ENTRY(xscale_setttb)
- mrs r3, cpsr_all
+ mrs r3, cpsr
orr r1, r3, #(I32_bit | F32_bit)
- msr cpsr_all, r1
+ msr cpsr_fsxc, r1
stmfd sp!, {r0-r3, lr}
bl _C_LABEL(xscale_cache_cleanID)
@@ -152,7 +152,7 @@ ENTRY(xscale_setttb)
CPWAIT(r0)
- msr cpsr_all, r3
+ msr cpsr_fsxc, r3
mov pc, lr
/*
@@ -244,12 +244,12 @@ _C_LABEL(xscale_cache_clean_size):
.word _C_LABEL(xscale_minidata_clean_size)
#defineXSCALE_CACHE_CLEAN_BLOCK
\
- mrs r3, cpsr_all; \
+ mrs r3, cpsr; \
orr r0, r3, #(I32_bit | F32_bit); \
- msr cpsr_all, r0
+ msr cpsr_fsxc, r0
#defineXSCALE_CACHE_CLEAN_UNBLOCK
\
- msr cpsr_all, r3
+ msr cpsr_fsxc, r3
#defineXSCALE_CACHE_CLEAN_PROLOGUE
\
XSCALE_CACHE_CLEAN_BLOCK; \
Index: arm/arm/exception.S
===
RCS file: /cvs/src/sys/arch/arm/arm/exception.S,v
retrieving revision 1.3
diff -u -p -r1.3 exception.S
--- arm/arm/exception.S 20 Sep 2011 22:02:10 - 1.3
+++ arm/arm/exception.S 14 Jan 2015 13:06:41 -
@@ -169,8 +169,8 @@ abortdatamsg:
* it like a Data Abort.
*/
ASENTRY_NP(address_exception_entry)
- mrs r1, cpsr_all
- mrs r2, spsr_all
+ mrs r1, cpsr
+ mrs r2, spsr
mov r3, lr
adr r0, Laddress_exception_msg
Re: ARM Firewall Hardware
On Wed, Jan 14, 2015 at 3:39 PM, Jonathan Gray j...@jsg.id.au wrote: I've updated the kernel at http://jsg.id.au/openbsd/bsd.IMX.umg And we have lift-off! ## Booting kernel from Legacy Image at 1080 ... Image Name: boot Created: 2015-01-14 14:13:27 UTC Image Type: ARM Linux Kernel Image (uncompressed) Data Size:3772972 Bytes = 3.6 MiB Load Address: 1080 Entry Point: 1080 Verifying Checksum ... OK Loading Kernel Image ... OK Starting kernel ... OpenBSD/imx booting ... arg0 0x0 arg1 0x10b1 arg2 0x1100 atag core flags 0 pagesize 0 rootdev 0 atag serial 0x: atag cmdline [sd0a] atag revision 0064 atag mem start 0x1000 size 0x4000 atag mem start 0x8000 size 0x4000 bootfile: sd0a bootargs: Allocating page tables freestart = 0x10b9a000, free_pages = 259174 (0x0003f466) IRQ stack: p0x10bc8000 v0xc0bc8000 ABT stack: p0x10bc9000 v0xc0bc9000 UND stack: p0x10bca000 v0xc0bca000 SVC stack: p0x10bcb000 v0xc0bcb000 Creating L1 page table at 0x10b9c000 Mapping kernel Constructing L2 page tables undefined page pmap [ using 302096 bytes of bsd ELF symbol table ] board type: Utilite Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2015 OpenBSD. All rights reserved. http://www.OpenBSD.org OpenBSD 5.7-beta (GENERIC-IMX) #4: Thu Jan 15 01:09:46 AEDT 2015 j...@armv7.jsg.id.au:/sys/arch/armv7/compile/GENERIC-IMX real mem = 2147483648 (2048MB) avail mem = 2091868160 (1994MB) warning: no entropy supplied by boot loader mainbus0 at root cortex0 at mainbus0 ampintc0 at cortex0 nirq 160 amptimer0 at cortex0: tick rate 396000 KHz armliicc0 at cortex0: rtl 7 waymask: 0x000f cpu0 at mainbus0: ARM Cortex A9 R2 rev 10 (ARMv7 core) cpu0: DC enabled IC enabled WB disabled EABT branch prediction enabled cpu0: 32KB(32b/l,4way) I-cache, 32KB(32b/l,4way) wr-back D-cache imx0 at mainbus0: i.MX6 Utilite imxocotp0 at imx0 imxccm0 at imx0: imx6 rev 1.2 CPU freq: 792 MHz imxiomuxc0 at imx0 imxdog0 at imx0 imxuart0 at imx0 console imxgpio0 at imx0 imxgpio1 at imx0 imxgpio2 at imx0 imxgpio3 at imx0 imxgpio4 at imx0 imxgpio5 at imx0 imxgpio6 at imx0 imxiic0 at imx0 iic0 at imxiic0 imxesdhc0 at imx0 sdmmc0 at imxesdhc0 ehci0 at imx0 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 i.MX6 EHCI root hub rev 2.00/1.00 addr 1 imxenet0 at imx0 imxenet0: address 00:00:00:00:00:00 atphy0 at imxenet0 phy 0: F1 10/100/1000 PHY, rev. 4 ahci0 at imx0 AHCI 1.3 scsibus0 at ahci0: 32 targets sd0 at scsibus0 targ 0 lun 0: ATA, \240\021`\022\202\014`\204@0dB\004@\215, \010t SCSI3 0/direct fixed naa.5001b449fca55860 sd0: 30533MB, 512 bytes/sector, 62533296 sectors, thin sdmmc0: can't enable card uhub1 at uhub0 port 1 Standard Microsystems product 0x2514 rev 2.00/b.b3 addr 2 uhidev0 at uhub1 port 4 configuration 1 interface 0 KB USB Keyboard rev 1.10/1.01 addr 3 uhidev0: iclass 3/1 ukbd0 at uhidev0: 8 variable keys, 6 key codes wskbd0 at ukbd0 uhidev1 at uhub1 port 4 configuration 1 interface 1 KB USB Keyboard rev 1.10/1.01 addr 3 uhidev1: iclass 3/1, 2 report ids uhid0 at uhidev1 reportid 1: input=2, output=0, feature=0 uhid1 at uhidev1 reportid 2: input=1, output=0, feature=0 vscsi0 at root scsibus1 at vscsi0: 256 targets softraid0 at root scsibus2 at softraid0: 256 targets boot device: sd0 root on sd0a (62c54f8337f6f4b8.a) swap on sd0b dump on sd0b WARNING: CHECK AND RESET THE DATE! exec /sbin/init: error 8 init: not found panic: no init Stopped at Debugger+0x4: ldrbr15, [r15, r15, ror r15]! RUN AT LEAST 'trace' AND 'ps' AND INCLUDE OUTPUT WHEN REPORTING THIS PANIC! DO NOT EVEN BOTHER REPORTING THIS WITHOUT INCLUDING THAT INFORMATION! ddb
Re: ARM Firewall Hardware
On Tue, Jan 13, 2015 at 5:45 PM, Jonathan Gray j...@jsg.id.au wrote: Your earlier mail had a different load address than what I'd expect. Try 0x1880 Same. I've tried the following staring adresses: 0x1060 - 0x1880 - 0x1080 The last one is what I use to boot bitrig. CM-FX6 # tftp 0x1080 bsd.umg Using FEC device TFTP from server 192.168.0.4; our IP address is 192.168.0.9 Filename 'bsd.umg'. Load address: 0x1080 Loading: # # # ### 1.3 MiB/s done Bytes transferred = 3772872 (3991c8 hex) CM-FX6 # bootm ## Booting kernel from Legacy Image at 1080 ... Image Name: boot Created: 2015-01-13 1:37:16 UTC Image Type: ARM Linux Kernel Image (uncompressed) Data Size:3772808 Bytes = 3.6 MiB Load Address: 1080 Entry Point: 1080 Verifying Checksum ... OK Loading Kernel Image ... OK Starting kernel ... OpenBSD/imx booting ... arg0 0x0 arg1 0x10b1 arg2 0x1100 atag core flags 0 pagesize 0 rootdev 0 atag serial 0x: atag cmdline [sd0a] atag revision 0064 atag mem start 0x1000 size 0x4000 atag mem start 0x8000 size 0x4000 bootfile: sd0a bootargs: Allocating page tables freestart = 0x10b9a000, free_pages = 259174 (0x0003f466) IRQ stack: p0x10bc8000 v0xc0bc8000 ABT stack: p0x10bc9000 v0xc0bc9000 UND stack: p0x10bca000 v0xc0bca000 SVC stack: p0x10bcb000 v0xc0bcb000 Creating L1 page table at 0x10b9c000 Mapping kernel Constructing L2 page tables undefined page pmap [ using 301948 bytes of bsd ELF symbol table ] board type: Utilite Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2015 OpenBSD. All rights reserved. http://www.OpenBSD.org
Re: ARM Firewall Hardware
On Tue, Jan 13, 2015 at 2:42 AM, Jonathan Gray j...@jsg.id.au wrote: Thanks, I've added the missing case for Utilite. A kernel that includes this change can be found here: http://jsg.id.au/openbsd/bsd.IMX.umg Now I got a bit further: Starting kernel ... OpenBSD/imx booting ... arg0 0x0 arg1 0x10b1 arg2 0x1100 atag core flags 0 pagesize 0 rootdev 0 atag serial 0x: atag cmdline [sd0a] atag revision 0064 atag mem start 0x1000 size 0x4000 atag mem start 0x8000 size 0x4000 bootfile: sd0a bootargs: Allocating page tables freestart = 0x10b9a000, free_pages = 259174 (0x0003f466) IRQ stack: p0x10bc8000 v0xc0bc8000 ABT stack: p0x10bc9000 v0xc0bc9000 UND stack: p0x10bca000 v0xc0bca000 SVC stack: p0x10bcb000 v0xc0bcb000 Creating L1 page table at 0x10b9c000 Mapping kernel Constructing L2 page tables undefined page pmap [ using 301948 bytes of bsd ELF symbol table ] board type: Utilite Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2015 OpenBSD. All rights reserved. http://www.OpenBSD.org (and then it hangs again)
Re: ARM Firewall Hardware
On Tue, Jan 13, 2015 at 04:56:22PM +0100, Christer Solskogen wrote: On Tue, Jan 13, 2015 at 2:42 AM, Jonathan Gray j...@jsg.id.au wrote: Thanks, I've added the missing case for Utilite. A kernel that includes this change can be found here: http://jsg.id.au/openbsd/bsd.IMX.umg Now I got a bit further: Starting kernel ... OpenBSD/imx booting ... arg0 0x0 arg1 0x10b1 arg2 0x1100 atag core flags 0 pagesize 0 rootdev 0 atag serial 0x: atag cmdline [sd0a] atag revision 0064 atag mem start 0x1000 size 0x4000 atag mem start 0x8000 size 0x4000 bootfile: sd0a bootargs: Allocating page tables freestart = 0x10b9a000, free_pages = 259174 (0x0003f466) IRQ stack: p0x10bc8000 v0xc0bc8000 ABT stack: p0x10bc9000 v0xc0bc9000 UND stack: p0x10bca000 v0xc0bca000 SVC stack: p0x10bcb000 v0xc0bcb000 Creating L1 page table at 0x10b9c000 Mapping kernel Constructing L2 page tables undefined page pmap [ using 301948 bytes of bsd ELF symbol table ] board type: Utilite Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2015 OpenBSD. All rights reserved. http://www.OpenBSD.org (and then it hangs again) Your earlier mail had a different load address than what I'd expect. Try 0x1880
Re: ARM Firewall Hardware
On Mon, Jan 12, 2015 at 2:07 PM, Jonathan Gray j...@jsg.id.au wrote: If you could provide some details as to why it doesn't boot perhaps it will in future. Sure thing. What do you need? -- chs
Re: ARM Firewall Hardware
On Sun, Jan 11, 2015 at 02:27:38PM +0100, Christer Solskogen wrote: On Mon, Jan 5, 2015 at 10:31 AM, f5b f...@163.com wrote: according http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/arch/armv7/armv7/armv7.c?rev=1.4 Only one board supported in current with two Gigabit ports ,Compulab UTILITE box ? Anyone can make sure? OpenBSD still does not boot on that board. Bitrig boots fine. (used snapshot from 10th of january) If you could provide some details as to why it doesn't boot perhaps it will in future. The board specific settings from Bitrig should be in the snap you tested.
Re: ARM Firewall Hardware
Thanks, I've added the missing case for Utilite. A kernel that includes this change can be found here: http://jsg.id.au/openbsd/bsd.IMX.umg On Mon, Jan 12, 2015 at 07:12:51PM +0100, Patrick Wildt wrote: Looks like the Utilite wasn???t added in the console init code: http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/arch/armv7/imx/imx_machdep.c.diff?r1=1.7r2=1.8 Am 12.01.2015 um 18:57 schrieb Christer Solskogen christer.solsko...@gmail.com: On Mon, Jan 12, 2015 at 3:30 PM, Jonathan Gray j...@jsg.id.au wrote: The serial console output would be a good starting point. (bsd.umg is really bsd.rd.IMX.umg) CM-FX6 # tftp 0x1080 bsd.umg Using FEC device TFTP from server 192.168.0.4; our IP address is 192.168.0.9 Filename 'bsd.umg'. Load address: 0x1080 Loading: # # # # # # # ## 1.2 MiB/s done Bytes transferred = 7461928 (71dc28 hex) CM-FX6 # bootm ## Booting kernel from Legacy Image at 1080 ... Image Name: boot Created: 2015-01-09 8:29:22 UTC Image Type: ARM Linux Kernel Image (uncompressed) Data Size:7461864 Bytes = 7.1 MiB Load Address: 1080 Entry Point: 1080 Verifying Checksum ... OK Loading Kernel Image ... OK Starting kernel ... And here it hangs forever. -- chs
Re: ARM Firewall Hardware
Looks like the Utilite wasn’t added in the console init code: http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/arch/armv7/imx/imx_machdep.c.diff?r1=1.7r2=1.8 Am 12.01.2015 um 18:57 schrieb Christer Solskogen christer.solsko...@gmail.com: On Mon, Jan 12, 2015 at 3:30 PM, Jonathan Gray j...@jsg.id.au wrote: The serial console output would be a good starting point. (bsd.umg is really bsd.rd.IMX.umg) CM-FX6 # tftp 0x1080 bsd.umg Using FEC device TFTP from server 192.168.0.4; our IP address is 192.168.0.9 Filename 'bsd.umg'. Load address: 0x1080 Loading: # # # # # # # ## 1.2 MiB/s done Bytes transferred = 7461928 (71dc28 hex) CM-FX6 # bootm ## Booting kernel from Legacy Image at 1080 ... Image Name: boot Created: 2015-01-09 8:29:22 UTC Image Type: ARM Linux Kernel Image (uncompressed) Data Size:7461864 Bytes = 7.1 MiB Load Address: 1080 Entry Point: 1080 Verifying Checksum ... OK Loading Kernel Image ... OK Starting kernel ... And here it hangs forever. -- chs
Re: ARM Firewall Hardware
On Mon, Jan 12, 2015 at 3:30 PM, Jonathan Gray j...@jsg.id.au wrote: The serial console output would be a good starting point. (bsd.umg is really bsd.rd.IMX.umg) CM-FX6 # tftp 0x1080 bsd.umg Using FEC device TFTP from server 192.168.0.4; our IP address is 192.168.0.9 Filename 'bsd.umg'. Load address: 0x1080 Loading: # # # # # # # ## 1.2 MiB/s done Bytes transferred = 7461928 (71dc28 hex) CM-FX6 # bootm ## Booting kernel from Legacy Image at 1080 ... Image Name: boot Created: 2015-01-09 8:29:22 UTC Image Type: ARM Linux Kernel Image (uncompressed) Data Size:7461864 Bytes = 7.1 MiB Load Address: 1080 Entry Point: 1080 Verifying Checksum ... OK Loading Kernel Image ... OK Starting kernel ... And here it hangs forever. -- chs
Re: ARM Firewall Hardware
On Mon, Jan 5, 2015 at 10:31 AM, f5b f...@163.com wrote: according http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/arch/armv7/armv7/armv7.c?rev=1.4 Only one board supported in current with two Gigabit ports ,Compulab UTILITE box ? Anyone can make sure? OpenBSD still does not boot on that board. Bitrig boots fine. (used snapshot from 10th of january) -- chs
Re: ARM Firewall Hardware
Am 11.01.2015 um 14:27 schrieb Christer Solskogen christer.solsko...@gmail.com: On Mon, Jan 5, 2015 at 10:31 AM, f5b f...@163.com wrote: according http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/arch/armv7/armv7/armv7.c?rev=1.4 Only one board supported in current with two Gigabit ports ,Compulab UTILITE box ? Anyone can make sure? OpenBSD still does not boot on that board. Bitrig boots fine. (used snapshot from 10th of january) -- chs One Port is limited to 540MBit/s by design. The other one is connected to the PCIe 1x slot which I still cannot get to run properly. It detects the device easily, but „talking“ to it doesn’t work. It looks like there’s some kind of DMA issue I haven’t figured out. Otherwise that device runs great here. I’m using it as build machine, with the in-built SSD.
Re: ARM Firewall Hardware
Also worth a mention is that only one core is enabled(no smp) and that one core that is active works at 792Mzh and not 1.2 Ghz. On Jan 11, 2015 5:03 PM, Patrick Wildt m...@patrick-wildt.de wrote: Am 11.01.2015 um 14:27 schrieb Christer Solskogen christer.solsko...@gmail.com: On Mon, Jan 5, 2015 at 10:31 AM, f5b f...@163.com wrote: according http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/arch/armv7/armv7/armv7.c?rev =1.4 Only one board supported in current with two Gigabit ports ,Compulab UTILITE box ? Anyone can make sure? OpenBSD still does not boot on that board. Bitrig boots fine. (used snapshot from 10th of january) -- chs One Port is limited to 540MBit/s by design. The other one is connected to the PCIe 1x slot which I still cannot get to run properly. It detects the device easily, but âtalkingâ to it doesnât work. It looks like thereâs some kind of DMA issue I havenât figured out. Otherwise that device runs great here. Iâm using it as build machine, with the in-built SSD.
Re: ARM Firewall Hardware
according http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/arch/armv7/armv7/armv7.c?rev=1.4 Only one board supported in current with two Gigabit ports ,Compulab UTILITE box ? Anyone can make sure? http://www.compulab.co.il/utilite-computer/web/utilite-models http://www.compulab.co.il/support/life-cycle/ start $159 Freescale i.MX6 @1.2GHz Up to 4GB DDR3 Up to 512GB SSD HDMI + DVI-D, 1920x1200 12V supply, 3-8W WiFi 802.11b/g/n + BT 3.0 1000Mb Ethernet x2 USB2.0 x4 Audio I/O RS232 x2 --- case BOARD_ID_IMX6_CUBOXI: printf(: i.MX6 SolidRun CuBox-i\n); imx6_init(); sc-sc_board_devs = hummingboard_devs; break; case BOARD_ID_IMX6_HUMMINGBOARD: printf(: i.MX6 SolidRun HummingBoard\n); imx6_init(); sc-sc_board_devs = hummingboard_devs; break; case BOARD_ID_IMX6_PHYFLEX: printf(: PhyFLEX-i.MX6\n); imx6_init(); sc-sc_board_devs = phyflex_imx6_devs; break; case BOARD_ID_IMX6_SABRELITE: printf(: i.MX6 SABRE Lite\n); imx6_init(); sc-sc_board_devs = sabrelite_devs; break; case BOARD_ID_IMX6_UDOO: printf(: i.MX6 UDOO\n); imx6_init(); sc-sc_board_devs = udoo_devs; break; case BOARD_ID_IMX6_UTILITE: printf(: i.MX6 Utilite\n); imx6_init(); sc-sc_board_devs = utilite_devs; break; case BOARD_ID_IMX6_WANDBOARD: printf(: i.MX6 Wandboard\n); imx6_init(); sc-sc_board_devs = wandboard_devs; break; case BOARD_ID_OMAP3_BEAGLE: printf(: BeagleBoard\n); omap3_init(); sc-sc_board_devs = beagleboard_devs; break; case BOARD_ID_AM335X_BEAGLEBONE: printf(: BeagleBone\n); am335x_init(); sc-sc_board_devs = beaglebone_devs; break; case BOARD_ID_OMAP3_OVERO: printf(: Gumstix Overo\n); omap3_init(); sc-sc_board_devs = overo_devs; break; case BOARD_ID_OMAP4_PANDA: printf(: PandaBoard\n); omap4_init(); sc-sc_board_devs = pandaboard_devs; break; case BOARD_ID_SUN4I_A10: printf(: A1X\n); sxia1x_init(); sc-sc_board_devs = sun4i_devs; issunxi = 1; break; case BOARD_ID_SUN7I_A20: printf(: A20\n); sxia20_init(); sc-sc_board_devs = sun7i_devs; issunxi = 1; break;
Re: ARM Firewall Hardware
Do the 1Gb interfaces support real 1Gb/sec? I know there was some arm h/w with 1Gb interfaces that would not run at 1Gb speed. diana On Mon, 5 Jan 2015, Patrick Wildt wrote: Until recently there has not been ARM hardware that actually has more than two Gigabit Ethernet ports. As of now there are two options: Thereâs the Banana Pi R1, which basically is a bigger Banana Pi with 5 Gigabit Ports connected to a Broadcom BCM53125 Switch. The BPI-R1, also called Lamobo R1 is based on an Allwinner A20. There currently seems to be only minimal support for the SoC in OpenBSD. FreeScale has recently been working on ARM-based network chips. They already had QorIQ network chips based on PowerPC and now basically replaced the PPC core with an ARM one, keeping the âoldâ peripherals. They are be working on LS1 and LS2 SoCs of varying performance. One of them is a dual-core Cortex A7, another one a Cortex A9, a rather slow ARM11 and even a few ARM 64-bit cores. As far as I know they already supply development boards[0] and reference design[1] hardware for the LS1021A, the dual core Cortex A7. That hardware is really interesting, but rather expensive and not supported by OpenBSD. \Patrick [0] http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=TWR-LS1021A [1] http://cache.freescale.com/files/32bit/doc/quick_ref_guide/LS1021A-IOTGS.pdf On Sun, Jan 04, 2015 at 10:41:14PM -0500, Predrag Punosevac wrote: I started entertain the idea of getting ARM based hardware for my new home firewall. Are there ARM based consumer motherboards with Gigabit lan controller which can be used for home firewall hobby project? How close is armv7 or any other OpenBSD version of being fully functional on such hardware? Cheers, Predrag
Re: ARM Firewall Hardware
You mean the i.MX6 SoC? Yeah, that one is limited to 540 MBit/s by design. In comparison to the i.MX series the LayerScape models are supposed to be network processors. So, even though they have a tendency to fuck things up, I don't think they also do that on something that already worked with PPC for some time. I have not yet run performance tests on the TWR-LS1021A. \Patrick Am 05.01.2015 um 14:54 schrieb Diana Eichert deich...@wrench.com: Do the 1Gb interfaces support real 1Gb/sec? I know there was some arm h/w with 1Gb interfaces that would not run at 1Gb speed. diana On Mon, 5 Jan 2015, Patrick Wildt wrote: Until recently there has not been ARM hardware that actually has more than two Gigabit Ethernet ports. As of now there are two options: There’s the Banana Pi R1, which basically is a bigger Banana Pi with 5 Gigabit Ports connected to a Broadcom BCM53125 Switch. The BPI-R1, also called Lamobo R1 is based on an Allwinner A20. There currently seems to be only minimal support for the SoC in OpenBSD. FreeScale has recently been working on ARM-based network chips. They already had QorIQ network chips based on PowerPC and now basically replaced the PPC core with an ARM one, keeping the „old“ peripherals. They are be working on LS1 and LS2 SoCs of varying performance. One of them is a dual-core Cortex A7, another one a Cortex A9, a rather slow ARM11 and even a few ARM 64-bit cores. As far as I know they already supply development boards[0] and reference design[1] hardware for the LS1021A, the dual core Cortex A7. That hardware is really interesting, but rather expensive and not supported by OpenBSD. \Patrick [0] http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=TWR-LS1021A [1] http://cache.freescale.com/files/32bit/doc/quick_ref_guide/LS1021A-IOTGS.pdf On Sun, Jan 04, 2015 at 10:41:14PM -0500, Predrag Punosevac wrote: I started entertain the idea of getting ARM based hardware for my new home firewall. Are there ARM based consumer motherboards with Gigabit lan controller which can be used for home firewall hobby project? How close is armv7 or any other OpenBSD version of being fully functional on such hardware? Cheers, Predrag
ARM Firewall Hardware
I started entertain the idea of getting ARM based hardware for my new home firewall. Are there ARM based consumer motherboards with Gigabit lan controller which can be used for home firewall hobby project? How close is armv7 or any other OpenBSD version of being fully functional on such hardware? Cheers, Predrag
Re: ARM Firewall Hardware
Until recently there has not been ARM hardware that actually has more than two Gigabit Ethernet ports. As of now there are two options: There’s the Banana Pi R1, which basically is a bigger Banana Pi with 5 Gigabit Ports connected to a Broadcom BCM53125 Switch. The BPI-R1, also called Lamobo R1 is based on an Allwinner A20. There currently seems to be only minimal support for the SoC in OpenBSD. FreeScale has recently been working on ARM-based network chips. They already had QorIQ network chips based on PowerPC and now basically replaced the PPC core with an ARM one, keeping the „old“ peripherals. They are be working on LS1 and LS2 SoCs of varying performance. One of them is a dual-core Cortex A7, another one a Cortex A9, a rather slow ARM11 and even a few ARM 64-bit cores. As far as I know they already supply development boards[0] and reference design[1] hardware for the LS1021A, the dual core Cortex A7. That hardware is really interesting, but rather expensive and not supported by OpenBSD. \Patrick [0] http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=TWR-LS1021A [1] http://cache.freescale.com/files/32bit/doc/quick_ref_guide/LS1021A-IOTGS.pdf On Sun, Jan 04, 2015 at 10:41:14PM -0500, Predrag Punosevac wrote: I started entertain the idea of getting ARM based hardware for my new home firewall. Are there ARM based consumer motherboards with Gigabit lan controller which can be used for home firewall hobby project? How close is armv7 or any other OpenBSD version of being fully functional on such hardware? Cheers, Predrag
