attach ampintc/ampintcmsi early on arm64
Attach ampintc/ampintcmsi0 early. Makes it possible to use qemu_arm64 U-Boot (which isn't aware of virtio devices) with root on pci ahci. U-Boot 2018.01-00547-g651bfbd6dd (Jan 28 2018 - 13:00:19 +1100) DRAM: 2 GiB In:pl011@900 Out: pl011@900 Err: pl011@900 Net: No ethernet found. Hit any key to stop autoboot: 0 scanning bus for devices... Target spinup took 0 ms. SATA link 1 timeout. SATA link 2 timeout. SATA link 3 timeout. SATA link 4 timeout. SATA link 5 timeout. AHCI 0001. 32 slots 6 ports 1.5 Gbps 0x3f impl SATA mode flags: 64bit ncq only Device 0: (0:0) Vendor: ATA Prod.: QEMU HARDDISK Rev: 2.5+ Type: Hard Disk Capacity: 2048.0 MB = 2.0 GB (4194304 x 512) Device 0: (0:0) Vendor: ATA Prod.: QEMU HARDDISK Rev: 2.5+ Type: Hard Disk Capacity: 2048.0 MB = 2.0 GB (4194304 x 512) ... is now current device Scanning scsi 0:1... load - load binary file from a filesystem Usage: load [ [ [ [bytes [pos] - Load binary file 'filename' from partition 'part' on device type 'interface' instance 'dev' to address 'addr' in memory. 'bytes' gives the size to load in bytes. If 'bytes' is 0 or omitted, the file is read until the end. 'pos' gives the file byte position to start reading from. If 'pos' is 0 or omitted, the file is read from the start. Found EFI removable media binary efi/boot/bootaa64.efi Scanning disk ahci_scsi.id0lun0... Found 3 disks 78335 bytes read in 8 ms (9.3 MiB/s) ## Starting EFI application at 4040 ... >> OpenBSD/arm64 BOOTAA64 0.8 boot> booting sd0a:/bsd: 3898820+575652+585656+806088|[277688+96+457680+243174]=0x842e90 type 0x2 pa 0x4000 va 0x4000 pages 0x4000 attr 0x8 type 0x7 pa 0x4400 va 0x4000 pages 0x4000 attr 0x8 type 0x6 pa 0x4800 va 0x1528a72000 pages 0x11 attr 0x8008 type 0x7 pa 0x48011000 va 0x4000 pages 0x7581e attr 0x8 type 0x2 pa 0xbd82f000 va 0xbd82f000 pages 0x4 attr 0x8 type 0x2 pa 0xbd833000 va 0xbd833000 pages 0x4 attr 0x8 type 0x2 pa 0xbd837000 va 0xbd837000 pages 0x4 attr 0x8 type 0x2 pa 0xbd83b000 va 0xbd83b000 pages 0x4 attr 0x8 type 0x2 pa 0xbd83f000 va 0xbd83f000 pages 0x4 attr 0x8 type 0x2 pa 0xbd843000 va 0xbd843000 pages 0x4 attr 0x8 type 0x2 pa 0xbd847000 va 0xbd847000 pages 0x4 attr 0x8 type 0x2 pa 0xbd84b000 va 0xbd84b000 pages 0x4 attr 0x8 type 0x2 pa 0xbd84f000 va 0xbd84f000 pages 0x4 attr 0x8 type 0x2 pa 0xbd853000 va 0xbd853000 pages 0x4 attr 0x8 type 0x2 pa 0xbd857000 va 0xbd857000 pages 0x4 attr 0x8 type 0x2 pa 0xbd85b000 va 0xbd85b000 pages 0x4 attr 0x8 type 0x2 pa 0xbd85f000 va 0xbd85f000 pages 0x4 attr 0x8 type 0x2 pa 0xbd863000 va 0xbd863000 pages 0x4 attr 0x8 type 0x2 pa 0xbd867000 va 0xbd867000 pages 0x4 attr 0x8 type 0x2 pa 0xbd86b000 va 0xbd86b000 pages 0x4 attr 0x8 type 0x2 pa 0xbd86f000 va 0xbd86f000 pages 0x4 attr 0x8 type 0x2 pa 0xbd873000 va 0xbd873000 pages 0x4 attr 0x8 type 0x2 pa 0xbd877000 va 0xbd877000 pages 0x4 attr 0x8 type 0x2 pa 0xbd87b000 va 0xbd87b000 pages 0x4 attr 0x8 type 0x2 pa 0xbd87f000 va 0xbd87f000 pages 0x4 attr 0x8 type 0x2 pa 0xbd883000 va 0xbd883000 pages 0x4 attr 0x8 type 0x2 pa 0xbd887000 va 0xbd887000 pages 0x4 attr 0x8 type 0x2 pa 0xbd88b000 va 0xbd88b000 pages 0x4 attr 0x8 type 0x2 pa 0xbd88f000 va 0xbd88f000 pages 0x4 attr 0x8 type 0x2 pa 0xbd893000 va 0xbd893000 pages 0x4 attr 0x8 type 0x2 pa 0xbd897000 va 0xbd897000 pages 0x4 attr 0x8 type 0x2 pa 0xbd89b000 va 0xbd89b000 pages 0x4 attr 0x8 type 0x2 pa 0xbd89f000 va 0xbd89f000 pages 0x4 attr 0x8 type 0x2 pa 0xbd8a3000 va 0xbd8a3000 pages 0x4 attr 0x8 type 0x2 pa 0xbd8a7000 va 0xbd8a7000 pages 0x4 attr 0x8 type 0x2 pa 0xbd8ab000 va 0xbd8ab000 pages 0x4 attr 0x8 type 0x2 pa 0xbd8af000 va 0xbd8af000 pages 0x4 attr 0x8 type 0x2 pa 0xbd8b3000 va 0xbd8b3000 pages 0x4 attr 0x8 type 0x2 pa 0xbd8b7000 va 0xbd8b7000 pages 0x4 attr 0x8 type 0x2 pa 0xbd8bb000 va 0xbd8bb000 pages 0x4 attr 0x8 type 0x2 pa 0xbd8bf000 va 0xbd8bf000 pages 0x4 attr 0x8 type 0x2 pa 0xbd8c3000 va 0xbd8c3000 pages 0x4 attr 0x8 type 0x2 pa 0xbd8c7000 va 0xbd8c7000 pages 0x4 attr 0x8 type 0x2 pa 0xbd8cb000 va 0xbd8cb000 pages 0x4 attr 0x8 type 0x2 pa 0xbd8cf000 va 0xbd8cf000 pages 0x4 attr 0x8 type 0x2 pa 0xbd8d3000 va 0xbd8d3000 pages 0x4 attr 0x8 type 0x2 pa 0xbd8d7000 va 0xbd8d7000 pages 0x4 attr 0x8 type 0x2 pa 0xbd8db000 va 0xbd8db000 pages 0x4 attr 0x8 type 0x2 pa 0xbd8df000 va 0xbd8df000 pages 0x4 attr 0x8 type 0x2 pa 0xbd8e3000 va 0xbd8e3000 pages 0x4 attr 0x8 type 0x2 pa 0xbd8e7000 va 0xbd8e7000 pages 0x4 attr 0x8 type 0x2 pa 0xbd8eb000 va 0xbd8eb000 pages 0x4 attr 0x8 type 0x2 pa 0xbd8ef000 va 0xbd8ef000 pages 0x4 attr 0x8 type 0x2 pa 0xbd8f3000 va 0xbd8f3000 pages 0x4 attr 0x8 type 0x2 pa 0xbd8f7000 va 0xbd8f7000 pages 0x4 attr 0x8 type 0x2 pa 0xbd8fb000 va 0xbd8fb000 pages 0x4 attr 0x8 type 0x2 pa 0xbd8ff000 va 0xbd8ff000 pages 0x4 attr 0x8 type 0x2 pa 0xbd903000 va 0xbd903000 pages 0x4 attr 0x8 type 0x2 pa 0xbd907000 va 0xbd907000 pages 0
psci function id register on arm64
semarie reported problems with running arm64 on qemu which turned out to be triggered by the psci version call. [ using 979488 bytes of bsd ELF symbol table ] Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2018 OpenBSD. All rights reserved. https://www.OpenBSD.org OpenBSD 6.2-current (GENERIC) #160: Wed Jan 24 18:26:59 MST 2018 dera...@arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC real mem = 2105647104 (2008MB) avail mem = 2017124352 (1923MB) mainbus0 at root: unknown model cpu0 at mainbus0: ARM Cortex-A57 r1p0 efi0 at mainbus0: UEFI 2.0.5 efi0: Das U-Boot rev 0x0 psci0 at mainbus0Stopped at psci_attach+0xf4: ddb> tr hvc_call() at psci_attach+0xf0 psci_attach() at mainbus_attach_node+0x244 mainbus_attach_node() at mainbus_attach+0x1ec mainbus_attach() at config_attach+0x214 config_attach() at config_rootfound+0xc0 config_rootfound() at cpu_configure+0x34 cpu_configure() at main+0x348 main() at $x.2+0x70 ddb> sh reg x00x8400 x1 0 x2 0 x3 0 x40xff80008bf258initstack+0x4a68 x50x1323 x60x861e4d1cb67f8248 x70x861e4d1cb67f8248 x80xff8000571978hvc_call x90x8408 x10 0x8409 x110 x120 x130 x14 0xff80073ad744_end+0x6a5ac0c x15 0xff8000671f20ap_bits_user x16 0xb64c1a07 x17 0xef56e85d x18 0xff80008bf200initstack+0x4a10 x19 0xff80073ac200_end+0x6a596c8 x20 0xff80008bf310initstack+0x4b20 x21 0xff800080$d.5 x220 x23 0xff80073ac224_end+0x6a596ec x24 0xff8000813388psci_cd x25 0xff8000813360psci_ca x26 0xff800095gf_log+0x1bc x27 0x4085f000 x28 0x4020 x29 0xff80008bf2b0initstack+0x4ac0 x300 sp0xff80008bf200initstack+0x4a10 spsr 0x63c5 elr 0xff8000571978hvc_call lr0xff8000254d08psci_attach+0xf4 psci_attach+0xf4: Though it seems other calls had trouble before that, likely since the psci changes made in december. Attempting to power down... Stopped at boot+0xd4: ddb> tr hvc_call() at boot+0xd0 boot() at sys_reboot+0x2c reboot() at svc_handler+0x1bc svc_handler() at do_el0_sync+0xbc do_el0_sync() at handle_el0_sync+0x68 handle_el0_sync() at 0x4ca7b07a4 --- trap --- ddb> sh reg x00x8408 x1 0 x2 0 x3 0 x40xff8000277918hvc_call x5 0 x60x33781a588ce87b4c x70x33781a588ce87b4c x80xff80072f7200_end+0x69a49d8 x90x25bf00aba3ce1b98 x10 0x16707157c x11 0x64 x120x1dcd662__ALIGN_SIZE+0x1bcd662 x13 0xc x14 0xff8007235184_end+0x68e295c x150 x160 x17 0x10 x18 0xff8018b00d90 x19 0x1008 x20 0xff8000805000nv2tov_type+0x8 x21 0x37 x22 0x37 x23 0xff8018b00f00 x24 0xff800080$d.5 x25 0xff8000856360sysent x26 0x37 x27 0xff80008566d2sysent+0x372 x28 0x1 x29 0xff8018b00da0 x30 0x4f49c4fa sp0xff8018b00d90 spsr 0x63c5 elr 0xff8000277918hvc_call lr0xff80002433f0boot+0xd4 boot+0xd4: qemu-system-aarch64 doesn't recognise the psci call when the high 32 bits of x0 are not zero. The PSCI implemented by the ATF in the overdrive 1000 only looks at the low 32 bits. And all the function ids we use set bit 31. Bit 30 is used to indicate smc64/hvc64 calling convention. The smc calling convention specification states that up to six registers are used, but nothing we call needs that many yet. Tested on overdrive 1000, and 32/64 bit qemu -M virt. Index: psci.c ===
Re: Kernel: clean up nam2blk
> Date: Sat, 27 Jan 2018 21:30:38 +0100
> From: Christian Weisgerber
>
> The nam2blk[] array contains MD mappings between block device names and
> major device numbers.
>
> This patch syncs the nam2blk entries with the bdevsw table, which
> is the definitive list of block devices supported on an architecture.
> This fixes the non-OpenBSD entries on arm64, removes obsolete
> mentions of tape block devices, and cleans up various other
> inconsistencies and omissions.
>
> OK?
ok kettenis@
> Index: arch/alpha/alpha/autoconf.c
> ===
> RCS file: /cvs/src/sys/arch/alpha/alpha/autoconf.c,v
> retrieving revision 1.37
> diff -u -p -r1.37 autoconf.c
> --- arch/alpha/alpha/autoconf.c 5 Jun 2017 17:49:05 - 1.37
> +++ arch/alpha/alpha/autoconf.c 27 Jan 2018 20:05:01 -
> @@ -221,12 +221,11 @@ device_register(dev, aux)
> }
>
> struct nam2blk nam2blk[] = {
> - { "st", 2 },
> + { "wd", 0 },
> { "cd", 3 },
> { "fd", 4 },
> { "rd", 6 },
> { "sd", 8 },
> - { "wd", 0 },
> { "vnd",9 },
> { NULL, -1 }
> };
> Index: arch/arm64/arm64/autoconf.c
> ===
> RCS file: /cvs/src/sys/arch/arm64/arm64/autoconf.c,v
> retrieving revision 1.7
> diff -u -p -r1.7 autoconf.c
> --- arch/arm64/arm64/autoconf.c 20 Jan 2018 18:35:41 - 1.7
> +++ arch/arm64/arm64/autoconf.c 27 Jan 2018 20:18:35 -
> @@ -96,10 +96,10 @@ device_register(struct device *dev, void
> }
>
> struct nam2blk nam2blk[] = {
> - { "sd", 4 },
> - { "nbd",20 },
> - { "tmpfsrd",19 },
> - { "cd", 6},
> - { "wd", 0 },
> + { "wd", 0 },
> + { "sd", 4 },
> + { "cd", 6 },
> + { "vnd",14 },
> + { "rd", 17 },
> { NULL, -1 }
> };
> Index: arch/armv7/armv7/autoconf.c
> ===
> RCS file: /cvs/src/sys/arch/armv7/armv7/autoconf.c,v
> retrieving revision 1.6
> diff -u -p -r1.6 autoconf.c
> --- arch/armv7/armv7/autoconf.c 8 Jun 2016 17:24:44 - 1.6
> +++ arch/armv7/armv7/autoconf.c 27 Jan 2018 20:07:04 -
> @@ -137,9 +137,10 @@ diskconf(void)
>
> struct nam2blk nam2blk[] = {
> { "wd", 16 },
> + { "rd", 18 },
> + } "vnd",19 },
> { "sd", 24 },
> { "cd", 26 },
> - { "rd", 18 },
> { NULL, -1 }
> };
>
> Index: arch/hppa/hppa/autoconf.c
> ===
> RCS file: /cvs/src/sys/arch/hppa/hppa/autoconf.c,v
> retrieving revision 1.61
> diff -u -p -r1.61 autoconf.c
> --- arch/hppa/hppa/autoconf.c 15 Sep 2014 19:08:21 - 1.61
> +++ arch/hppa/hppa/autoconf.c 27 Jan 2018 20:08:40 -
> @@ -512,12 +512,11 @@ diskconf(void)
> }
>
> struct nam2blk nam2blk[] = {
> + { "vnd",2 },
> { "rd", 3 },
> { "sd", 4 },
> - { "st", 5 },
> { "cd", 6 },
> { "fd", 7 },
> { "wd", 8 },
> - { "vnd",2 },
> { NULL, -1 }
> };
> Index: arch/i386/i386/autoconf.c
> ===
> RCS file: /cvs/src/sys/arch/i386/i386/autoconf.c,v
> retrieving revision 1.103
> diff -u -p -r1.103 autoconf.c
> --- arch/i386/i386/autoconf.c 20 Jun 2017 21:05:46 - 1.103
> +++ arch/i386/i386/autoconf.c 27 Jan 2018 20:09:27 -
> @@ -270,7 +270,7 @@ struct nam2blk nam2blk[] = {
> { "fd", 2 },
> { "sd", 4 },
> { "cd", 6 },
> - { "rd", 17 },
> { "vnd",14 },
> + { "rd", 17 },
> { NULL, -1 }
> };
> Index: arch/landisk/landisk/autoconf.c
> ===
> RCS file: /cvs/src/sys/arch/landisk/landisk/autoconf.c,v
> retrieving revision 1.11
> diff -u -p -r1.11 autoconf.c
> --- arch/landisk/landisk/autoconf.c 21 Jul 2008 04:35:54 - 1.11
> +++ arch/landisk/landisk/autoconf.c 27 Jan 2018 20:10:36 -
> @@ -76,7 +76,8 @@ diskconf(void)
> struct nam2blk nam2blk[] = {
> { "wd", 16 },
> { "rd", 18 },
> - { "sd", 24 },
> { "vnd",19 },
> + { "sd", 24 },
> + { "cd", 26 },
> { NULL, -1 }
> };
> Index: arch/loongson/loongson/autoconf.c
> ===
> RCS file: /cvs/src/sys/arch/loongson/loongson/autoconf.c,v
> retrieving revision 1.8
> diff -u -p -r1.8 autoconf.c
> --- arch/loongson/loongson/autoconf.c 8 Jun 2017 12:02:52 - 1.8
> +++ arch/loongson/loongson/autoconf.c 27 Jan 2018 20:11:41 -
>
Kernel: clean up nam2blk
The nam2blk[] array contains MD mappings between block device names and
major device numbers.
This patch syncs the nam2blk entries with the bdevsw table, which
is the definitive list of block devices supported on an architecture.
This fixes the non-OpenBSD entries on arm64, removes obsolete
mentions of tape block devices, and cleans up various other
inconsistencies and omissions.
OK?
Index: arch/alpha/alpha/autoconf.c
===
RCS file: /cvs/src/sys/arch/alpha/alpha/autoconf.c,v
retrieving revision 1.37
diff -u -p -r1.37 autoconf.c
--- arch/alpha/alpha/autoconf.c 5 Jun 2017 17:49:05 - 1.37
+++ arch/alpha/alpha/autoconf.c 27 Jan 2018 20:05:01 -
@@ -221,12 +221,11 @@ device_register(dev, aux)
}
struct nam2blk nam2blk[] = {
- { "st", 2 },
+ { "wd", 0 },
{ "cd", 3 },
{ "fd", 4 },
{ "rd", 6 },
{ "sd", 8 },
- { "wd", 0 },
{ "vnd",9 },
{ NULL, -1 }
};
Index: arch/arm64/arm64/autoconf.c
===
RCS file: /cvs/src/sys/arch/arm64/arm64/autoconf.c,v
retrieving revision 1.7
diff -u -p -r1.7 autoconf.c
--- arch/arm64/arm64/autoconf.c 20 Jan 2018 18:35:41 - 1.7
+++ arch/arm64/arm64/autoconf.c 27 Jan 2018 20:18:35 -
@@ -96,10 +96,10 @@ device_register(struct device *dev, void
}
struct nam2blk nam2blk[] = {
- { "sd", 4 },
- { "nbd",20 },
- { "tmpfsrd",19 },
- { "cd", 6},
- { "wd", 0 },
+ { "wd", 0 },
+ { "sd", 4 },
+ { "cd", 6 },
+ { "vnd",14 },
+ { "rd", 17 },
{ NULL, -1 }
};
Index: arch/armv7/armv7/autoconf.c
===
RCS file: /cvs/src/sys/arch/armv7/armv7/autoconf.c,v
retrieving revision 1.6
diff -u -p -r1.6 autoconf.c
--- arch/armv7/armv7/autoconf.c 8 Jun 2016 17:24:44 - 1.6
+++ arch/armv7/armv7/autoconf.c 27 Jan 2018 20:07:04 -
@@ -137,9 +137,10 @@ diskconf(void)
struct nam2blk nam2blk[] = {
{ "wd", 16 },
+ { "rd", 18 },
+ } "vnd",19 },
{ "sd", 24 },
{ "cd", 26 },
- { "rd", 18 },
{ NULL, -1 }
};
Index: arch/hppa/hppa/autoconf.c
===
RCS file: /cvs/src/sys/arch/hppa/hppa/autoconf.c,v
retrieving revision 1.61
diff -u -p -r1.61 autoconf.c
--- arch/hppa/hppa/autoconf.c 15 Sep 2014 19:08:21 - 1.61
+++ arch/hppa/hppa/autoconf.c 27 Jan 2018 20:08:40 -
@@ -512,12 +512,11 @@ diskconf(void)
}
struct nam2blk nam2blk[] = {
+ { "vnd",2 },
{ "rd", 3 },
{ "sd", 4 },
- { "st", 5 },
{ "cd", 6 },
{ "fd", 7 },
{ "wd", 8 },
- { "vnd",2 },
{ NULL, -1 }
};
Index: arch/i386/i386/autoconf.c
===
RCS file: /cvs/src/sys/arch/i386/i386/autoconf.c,v
retrieving revision 1.103
diff -u -p -r1.103 autoconf.c
--- arch/i386/i386/autoconf.c 20 Jun 2017 21:05:46 - 1.103
+++ arch/i386/i386/autoconf.c 27 Jan 2018 20:09:27 -
@@ -270,7 +270,7 @@ struct nam2blk nam2blk[] = {
{ "fd", 2 },
{ "sd", 4 },
{ "cd", 6 },
- { "rd", 17 },
{ "vnd",14 },
+ { "rd", 17 },
{ NULL, -1 }
};
Index: arch/landisk/landisk/autoconf.c
===
RCS file: /cvs/src/sys/arch/landisk/landisk/autoconf.c,v
retrieving revision 1.11
diff -u -p -r1.11 autoconf.c
--- arch/landisk/landisk/autoconf.c 21 Jul 2008 04:35:54 - 1.11
+++ arch/landisk/landisk/autoconf.c 27 Jan 2018 20:10:36 -
@@ -76,7 +76,8 @@ diskconf(void)
struct nam2blk nam2blk[] = {
{ "wd", 16 },
{ "rd", 18 },
- { "sd", 24 },
{ "vnd",19 },
+ { "sd", 24 },
+ { "cd", 26 },
{ NULL, -1 }
};
Index: arch/loongson/loongson/autoconf.c
===
RCS file: /cvs/src/sys/arch/loongson/loongson/autoconf.c,v
retrieving revision 1.8
diff -u -p -r1.8 autoconf.c
--- arch/loongson/loongson/autoconf.c 8 Jun 2017 12:02:52 - 1.8
+++ arch/loongson/loongson/autoconf.c 27 Jan 2018 20:11:41 -
@@ -113,9 +113,9 @@ device_register(struct device *dev, void
struct nam2blk nam2blk[] = {
{ "sd", 0 },
+ { "vnd",2 },
{ "cd", 3 },
{ "wd", 4 },
{ "rd", 8 },
- { "vnd",2 },
{
Re: on-line kernel debugging
Thank you (for the quick response) and sorry if I was not as clear as I should have been! what I meant and was hoping to find was a source code debugger support, like gdb[1], where one can debug a running kernel with full access to the source code in a gdb session environment from a remote machine. I'm new to OpenBSD and found kgdb(7)[2] manual from 6.1 describing the process very similar to what I do daily with FreeBSD but (as I mentioned earlier) the code seems to be removed since 6.2. So, is there any alternative for remote debugging a running OpenBSD kernel using gdb? anyhow, I appreciate it if one can point me to the right direction and I don't mind any hard work in the process :-) [1]: https://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug-online-gdb.html [2]: https://man.openbsd.org/OpenBSD-6.1/kgdb.7 On 01/27/18 21:00, Todd C. Miller wrote: On Sat, 27 Jan 2018 20:46:18 +0330, bijan wrote: does OpenBSD support on-line kernel debugging as FreeBSD does[1]? Yes, see the ddb(4) manual page. - todd
Re: on-line kernel debugging
On Sat, 27 Jan 2018 20:46:18 +0330, bijan wrote: > does OpenBSD support on-line kernel debugging as FreeBSD does[1]? Yes, see the ddb(4) manual page. - todd
on-line kernel debugging
Hi! (Don't know if tech@ is the right place to ask such questions, just hope it is) does OpenBSD support on-line kernel debugging as FreeBSD does[1]? The only document I managed to find was a fairly old one[2] by QEMU over GNU/Linux but it seems kgdb(7) is removed since 6.2 (apparently for not even working before[3]). Thank you! [1]: https://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug-online-ddb.html [2]: https://markshroyer.com/2013/01/debugging-openbsd-via-qemu/ [3]: https://github.com/openbsd/src/commits/master/sys/sys/kgdb.h
Atheros AR2425 Wi-Fi chip - Driver Patch
Hi all,
Its my first time to contributing to a OpenBSD Project!
so ...
I have Atheros AR2425 Wi-Fi chip (MAC: 0xe2, PHY: 0x70) on my
FijitsuSiemens Laptop (U9210)
I'm trying to connect to my WPA2 wireless but my DMESG is like this:
> ath0: unable to reset hardware.
Please see an attachment my patch for this issue.
I have already tested it on my Laptop. Work's fine: Stable signal and so on.
Please investigate this issue. I am waiting for your feedback.
P.S. If you need more info, just inform me per E-Mail.
Sorry for my English. See you on FOSDEM'18
BR
Oleg Pahl (Munich)
459d458
< #define AR5K_AR5212_DCU_MISC_FRAG_WAIT 0x0100
1103,1104d1101
< #define AR5K_AR5212_PHY_SCAL_32MHZ_2417 0x000a
< #define AR5K_AR5212_PHY_SCAL_32MHZ_HB63 0x0032
238,240c238
< } else if (hal->ah_mac_version == (AR5K_SREV_VER_AR2425 >> 4) ||
< hal->ah_mac_version == (AR5K_SREV_VER_AR2417 >> 4) ||
< hal->ah_phy_revision == (AR5K_SREV_PHY_2425)) {
---
> } else if (srev == AR5K_SREV_VER_AR2425) {
242,248c240
< hal->ah_single_chip = AH_TRUE;
< hal->ah_radio_5ghz_revision= AR5K_SREV_RAD_2425;
< } else if ((hal->ah_mac_version == (AR5K_SREV_VER_AR2424 >> 4)) ||
< (hal->ah_phy_revision == AR5K_SREV_PHY_5413)) {
< hal->ah_radio = AR5K_AR5413;
< hal->ah_single_chip = AH_TRUE;
< hal->ah_radio_5ghz_revision = AR5K_SREV_RAD_5413;
---
> hal->ah_phy_spending = AR5K_AR5212_PHY_SPENDING_AR5112;
2878a2871
> #if 0
2880a2874
> #endif
626,627d625
< #define AR5K_EEPROM_IS_HB63 0x000b /* Talon detect */
<
770d767
< HAL_BOOL ee_is_hb63;
1241,1242c1238
< #define AR5K_SREV_VER_AR2425 0xe0/* PCI-Express (Swan, was 0xe2) */
< #define AR5K_SREV_VER_AR2417 0xf0/* PCI-Express (Nala) */
---
> #define AR5K_SREV_VER_AR2425 0xe2 /* PCI-Express */
1243a1240
>
1255,1256d1251
< #define AR5K_SREV_RAD_5413 0x60
< #define AR5K_SREV_RAD_2425 0xa2
1259,1260c1254
< #define AR5K_SREV_PHY_5413 0x61
< #define AR5K_SREV_PHY_2425 0x70
---
>
89d88
< HAL_BOOL ar5k_ar2425_channel(struct ath_hal *, HAL_CHANNEL *);
894,899d892
< AR5K_EEPROM_READ(AR5K_EEPROM_IS_HB63, val);
< if ((hal->ah_mac_version == (AR5K_SREV_VER_AR2425 >> 4)) && val)
< ee->ee_is_hb63 = AH_TRUE;
< else
< ee->ee_is_hb63 = AH_FALSE;
<
1119,1120d
< else if (hal->ah_radio == AR5K_AR2425)
< ret = ar5k_ar2425_channel(hal, channel);
1272,1309d1262
<
< AR5K_PHY_WRITE(0x27, data & 0xff);
< AR5K_PHY_WRITE(0x36, (data >> 8) & 0x7f);
<
< return (AH_TRUE)
< }
<
< HAL_BOOL
< ar5k_ar2425_channel(struct ath_hal *hal, HAL_CHANNEL *channel)
< {
< u_int32_t data, data0, data2;
< u_int16_t c;
<
< data = data0 = data2 = 0;
< c = channel->c_channel + hal->ah_chanoff;
<
< /*
< * Set the channel on the AR2425
< */
< if (c < 4800) {
< data0 = ar5k_bitswap((c - 2272), 8);
< data2 = 0;
< } else if ((c - (c % 5)) != 2 || c > 5435) {
< if (!(c % 20) && c < 5120)
< data0 = ar5k_bitswap(((c - 4800) / 20 << 2), 8);
< else if (!(c % 10))
< data0 = ar5k_bitswap(((c - 4800) / 10 << 1), 8);
< else if (!(c % 5))
< data0 = ar5k_bitswap((c - 4800) / 5, 8);
< else
< return (AH_FALSE);
< data2 = ar5k_bitswap(1, 2);
< } else {
< data0 = ar5k_bitswap((10 * (c - 2) - 4800) / 25 + 1, 8);
< data2 = ar5k_bitswap(0, 2);
< }
<
< data = (data0 << 4) | (data2 << 2) | 0x1001;
arm64 genassym.cf
This brings the arm64 genassym.cf file a bit closer to what we have on other architectures. No functional change. ok? Index: arch/arm64/arm64/genassym.cf === RCS file: /cvs/src/sys/arch/arm64/arm64/genassym.cf,v retrieving revision 1.3 diff -u -p -r1.3 genassym.cf --- arch/arm64/arm64/genassym.cf24 Mar 2017 19:48:01 - 1.3 +++ arch/arm64/arm64/genassym.cf27 Jan 2018 11:59:56 - @@ -49,44 +49,44 @@ include include include -struct sigframe -member SF_SC sf_sc -struct cpu_info -member CI_CURPROC ci_curproc +struct sigframe +member sf_sc -struct proc -member P_ASTPENDING p_md.md_astpending -member P_STAT p_stat - -struct pcb -member PCB_ONFAULT pcb_onfault -member PCB_FLAGS pcb_flags -member PCB_SP pcb_sp -member PCB_TCB pcb_tcb - -struct trapframe -member TF_X tf_x -member TF_SP tf_sp -member TF_ELR tf_elr -define TF_SIZE sizeof(struct trapframe) - -define PCB_FPU PCB_FPU -define SONPROC SONPROC - -struct cpu_info -member CI_CURPCB ci_curpcb - -struct proc -member P_ADDR p_addr - -struct switchframe -member SF_X19 sf_x19 -member SF_X21 sf_x21 -member SF_X23 sf_x23 -member SF_X25 sf_x25 -member SF_X27 sf_x27 -member SF_X29 sf_x29 -define SWITCHFRAME_SZ sizeof(struct switchframe) +struct cpu_info +member ci_curproc -define IPL_NONE IPL_NONE +struct proc +member p_addr +member p_stat +member P_ASTPENDINGp_md.md_astpending + +export SONPROC + +struct pcb +member pcb_onfault +member pcb_flags +member pcb_sp +member pcb_tcb + +export PCB_FPU + +struct trapframe +member tf_x +member tf_sp +member tf_elr +define TF_SIZE sizeof(struct trapframe) + +struct cpu_info +member ci_curpcb + +struct switchframe +member sf_x19 +member sf_x21 +member sf_x23 +member sf_x25 +member sf_x27 +member sf_x29 +define SWITCHFRAME_SZ sizeof(struct switchframe) + +export IPL_NONE
Re: bridge(4): protected interface (port)
On Wed, Jan 24, 2018 at 11:27:51PM +, Tom Smyth wrote:
> Hello, Martin, Remi, All
> Im very excited about this feature, Thanks Martin,
> Please see Comments inline below
>
> On 23 January 2018 at 18:06, Remi Locherer wrote:
> > On Mon, Jan 22, 2018 at 04:23:59PM +0100, Martin Pieuchot wrote:
> >> Diff below adds a new feature to bridge(4), similar to Cisco's Protected
> >> Port but with more possibilities.
> >>
> >> The idea is to prevent traffic to flow between some members of a bridge(4).
> >> For example:
> >> - you want to prevent some of your servers to talk to each others, or
> >> - you want employees/students/clients to have access to internet and a
> >> printer but not to each other, or
> >> - you want VMs to have access to an uplink but not to each other
> >
> > I think the last example is really useful and makes sense.
> Agreed
> >
> > For the other cases there would most likely be a switch between the other
> > host and the OpenBSD box. Then you need to enforce the policy on that
> > switch.
> Other examples where it would be useful if the OpenBSD box is terminating
> alot of Tunnels and you want to limit broadcast domains.
> >
> >> With the diff below it is now possible to defined "protected groups".
> >> Interface that are part of such groups cannot send/receive traffic
> >> to/from any other member of the group.
> >
> > Why several protected groups and not just a single one?
> Having multiple protected groups can be useful in the following circumstances:
> Where you want to isolate clients / vms from each other,
> and where you have 2 redundant up-link ports in the bridge that could other
> wise
> create a loop.
> (where spanning tree cannot be deployed (due to incompatible or
> limited switches)
Wouldn't this duplicate BUM traffic? In this situation I would try a setup with
trunk(4) for the uplinks. At least the failover mode should work if your
switches have a limited feature set.
> e.g
> a) loop prevention in 2 up link ports on a bridge
> so if the 2 up-link ports are added to the same protected group they cannot
> form a loop as the 2 up-links are isolated from each other
> Uplink ports would be em1 and em2 and we would add them to protected group1
> em1 and em2 cannot communicate with each other and cant create a loop
> b)preventing vms from talking to each other by adding them to another
> protected
> group
> e.g.
> tap1 and tap2 would be added to protected group 2
> so tap1 and tap2 would be isolated from each other, and because they are
> members
> of a different protected group to em1 and em2 in the same bridge they
> can communicate
> freely with either em1 or em2
>
> I have used this technique on certain Layer 2 networks where STP was
> not possible or
> desirable,, and it would give the administrator granular control
> of traffic flow in the bridge
> Other Added benefits
> (control broadcast domains etc)
> increase security for access networks (prevent rogue dhcp Servers)
>
> I hope this helps and Im really excited with this diff :)
> Thanks Guys
>
>
> >
> >>
> >> In the example below, em1 and em2 can only send/receive traffic through
> >> em0 because they are both in the protected group 2.
> >>
> >> bridge0: flags=41
> >> index 9 llprio 3
> >> groups: bridge
> >> priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto
> >> rstp
> >> designated: id 00:00:00:00:00:00 priority 0
> >> em0 flags=3
> >> port 6 ifpriority 0 ifcost 0
> >> em1 flags=3
> >> port 7 ifpriority 0 ifcost 0 protected 2
> >> em2 flags=3
> >> port 8 ifpriority 0 ifcost 0 protected 2
> >>
> >> Adding an interface to a protected group is as simple as:
> >>
> >> # ifconfig bridge0 protected em1 2
> >>
> >> Removing it:
> >>
> >> # ifconfig bridge0 -protected em1
> >>
> >> Comments? Oks?
> >>
> >> Index: sys/net/if_bridge.c
> >> ===
> >> RCS file: /cvs/src/sys/net/if_bridge.c,v
> >> retrieving revision 1.301
> >> diff -u -p -r1.301 if_bridge.c
> >> --- sys/net/if_bridge.c 10 Jan 2018 23:50:39 - 1.301
> >> +++ sys/net/if_bridge.c 22 Jan 2018 14:27:41 -
> >> @@ -409,6 +409,7 @@ bridge_ioctl(struct ifnet *ifp, u_long c
> >> }
> >> req->ifbr_ifsflags = p->bif_flags;
> >> req->ifbr_portno = p->ifp->if_index & 0xfff;
> >> + req->ifbr_protected = p->bif_protected;
> >> if (p->bif_flags & IFBIF_STP) {
> >> bp = p->bif_stp;
> >> req->ifbr_state = bstp_getstate(bs, bp);
> >> @@ -496,6 +497,19 @@ bridge_ioctl(struct ifnet *ifp, u_long c
> >> brop->ifbop_last_tc_time.tv_sec = bs->bs_last_tc_time.tv_sec;
> >> brop->ifbop_last_tc_time.tv_usec =
> >> bs->bs_last_tc_time.tv_usec;
> >> break;
> >> + case SIOCBRDGSIFPROT:
> >> + ifs
