* AT91RM9200 hang in atmel_serial_putc @ 2016-08-18 1:08 Peter Kardos 2016-08-18 7:38 ` Sascha Hauer 0 siblings, 1 reply; 9+ messages in thread From: Peter Kardos @ 2016-08-18 1:08 UTC (permalink / raw) To: barebox Greetings, I'm looking for a AT91 specialist that could help me debug barebox v2016.08. I have a custom board running AT91RM9200 that came with a really old custom u-boot (v1.1.4, no ubifs support)... The first bootloader I've ported (barebox v2015.07, using AT91RM9200ek as template) almost works; I'm having trouble getting networking (ping, dhcp) working with Micrel KSZ8721 phy. But it boots, works with the Flash, etc... With hopes, that this (networking issue) is resolved with the latest barebox release (using the same patchset and config) I've found (??) a another issue. At first it seemed the board just does not boot, after having a look with a j-link it seems the board "hangs" in atmel_serial_putc(). I've tried to look at the AT91RM9200 init (lowlevel, peripherals, driver) and could not find any significant change (rewrite, define changes, etc)... Any help, ideas, even flame is welcome. Thanks in advance. Cheers, Peter _______________________________________________ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: AT91RM9200 hang in atmel_serial_putc 2016-08-18 1:08 AT91RM9200 hang in atmel_serial_putc Peter Kardos @ 2016-08-18 7:38 ` Sascha Hauer 2016-08-18 8:00 ` Peter Kardos 0 siblings, 1 reply; 9+ messages in thread From: Sascha Hauer @ 2016-08-18 7:38 UTC (permalink / raw) To: Peter Kardos; +Cc: barebox Hi Peter, On Thu, Aug 18, 2016 at 03:08:36AM +0200, Peter Kardos wrote: > Greetings, > > I'm looking for a AT91 specialist that could help me debug barebox v2016.08. > > I have a custom board running AT91RM9200 that came with a really old custom > u-boot (v1.1.4, no ubifs support)... > > The first bootloader I've ported (barebox v2015.07, using AT91RM9200ek as > template) almost works; I'm having trouble getting networking (ping, dhcp) > working with Micrel KSZ8721 phy. But it boots, works with the Flash, etc... > With hopes, that this (networking issue) is resolved with the latest barebox > release (using the same patchset and config) I've found (??) a another > issue. > > At first it seemed the board just does not boot, after having a look with a > j-link it seems the board "hangs" in atmel_serial_putc(). > I've tried to look at the AT91RM9200 init (lowlevel, peripherals, driver) > and could not find any significant change (rewrite, define changes, etc)... So you have a jtag debugger attached, does it support showing registers? What is the value of uart->base? Is it correct? Also you could compare the UART registers with the ones from a working U-Boot/barebox. Does atmel_serial_init_port() do everything correctly? Finally it may be that the clock is disabled for some reason, then the values written to the UART would never be shifted out. Which instance of the UART are you using? It seems we have: static struct clk_lookup usart_clocks_lookups[] = { CLKDEV_CON_DEV_ID("usart", "atmel_usart0", &mck), CLKDEV_CON_DEV_ID("usart", "atmel_usart1", &usart0_clk), CLKDEV_CON_DEV_ID("usart", "atmel_usart2", &usart1_clk), CLKDEV_CON_DEV_ID("usart", "atmel_usart3", &usart2_clk), CLKDEV_CON_DEV_ID("usart", "atmel_usart4", &usart3_clk), }; The first clock seems to be always-on, but the others could be turned off. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | _______________________________________________ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: AT91RM9200 hang in atmel_serial_putc 2016-08-18 7:38 ` Sascha Hauer @ 2016-08-18 8:00 ` Peter Kardos 2016-08-18 21:15 ` Peter Kardos 0 siblings, 1 reply; 9+ messages in thread From: Peter Kardos @ 2016-08-18 8:00 UTC (permalink / raw) To: Sascha Hauer; +Cc: barebox Hi Sascha, > So you have a jtag debugger attached, does it support showing registers? > What is the value of uart->base? Is it correct? > Also you could compare the UART registers with the ones from a working > U-Boot/barebox. Yes, I have, it does. I've checked, and it seems to be correct, pointing to 0xFFFFF200. However I didn't think to check the register offset and mask (it was late). > Which instance of the UART are you using? It seems we have: I'm using the debug UART (USART0)... > Does atmel_serial_init_port() do everything correctly? > Finally it may be that the clock is disabled for some reason, Was thinking the same thing. I'll check it (compare reg dumps, console init) tonight and report my findings. Cheers, Peter On 2016-08-18 09:38, Sascha Hauer wrote: > Hi Peter, > > On Thu, Aug 18, 2016 at 03:08:36AM +0200, Peter Kardos wrote: >> Greetings, >> >> I'm looking for a AT91 specialist that could help me debug barebox v2016.08. >> >> I have a custom board running AT91RM9200 that came with a really old custom >> u-boot (v1.1.4, no ubifs support)... >> >> The first bootloader I've ported (barebox v2015.07, using AT91RM9200ek as >> template) almost works; I'm having trouble getting networking (ping, dhcp) >> working with Micrel KSZ8721 phy. But it boots, works with the Flash, etc... >> With hopes, that this (networking issue) is resolved with the latest barebox >> release (using the same patchset and config) I've found (??) a another >> issue. >> >> At first it seemed the board just does not boot, after having a look with a >> j-link it seems the board "hangs" in atmel_serial_putc(). >> I've tried to look at the AT91RM9200 init (lowlevel, peripherals, driver) >> and could not find any significant change (rewrite, define changes, etc)... > So you have a jtag debugger attached, does it support showing registers? > What is the value of uart->base? Is it correct? > Also you could compare the UART registers with the ones from a working > U-Boot/barebox. Does atmel_serial_init_port() do everything correctly? > Finally it may be that the clock is disabled for some reason, then the > values written to the UART would never be shifted out. > Which instance of the UART are you using? It seems we have: > > static struct clk_lookup usart_clocks_lookups[] = { > CLKDEV_CON_DEV_ID("usart", "atmel_usart0", &mck), > CLKDEV_CON_DEV_ID("usart", "atmel_usart1", &usart0_clk), > CLKDEV_CON_DEV_ID("usart", "atmel_usart2", &usart1_clk), > CLKDEV_CON_DEV_ID("usart", "atmel_usart3", &usart2_clk), > CLKDEV_CON_DEV_ID("usart", "atmel_usart4", &usart3_clk), > }; > > The first clock seems to be always-on, but the others could be turned off. > > Sascha > _______________________________________________ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: AT91RM9200 hang in atmel_serial_putc 2016-08-18 8:00 ` Peter Kardos @ 2016-08-18 21:15 ` Peter Kardos 2016-08-22 6:10 ` Sascha Hauer 0 siblings, 1 reply; 9+ messages in thread From: Peter Kardos @ 2016-08-18 21:15 UTC (permalink / raw) To: Sascha Hauer; +Cc: barebox Hi Sascha, I may have something. It seems the memory (MMU?) gets "messed" up; Reading the debug uart registers (v2015.07) gives reasonable results, like (gdb) x/32w 0xfffff200 0xfffff200: 0x00000000 0x00000800 0x00000000 0x00000000 0xfffff210: 0x00000000 0x40001a1a 0x00000000 0x00000000 0xfffff220: 0x00000021 0x00000000 0x00000000 0x00000000 0xfffff230: 0x00000000 0x00000000 0x00000000 0x00000000 0xfffff240: 0x09290781 0x00000000 0x00000000 0x00000000 However the content from v2016.08 gives 0xFFFFF200 D78D7E1F F1139ADE 413E0FE5 BBFB6DF2 0xFFFFF210 7D78666E 79CBDEA6 8FB2CB03 BEF6C2B7 0xFFFFF220 C9071D17 FA1EFA2D C4BCD95E 27D73C7C 0xFFFFF230 727C3437 DFBDEBED 69C45C2A 7F5958F6 0xFFFFF240 834B237E F8B8A211 1AC74D66 FAE06274 Peter On 8/18/2016 10:00 AM, Peter Kardos wrote: > Hi Sascha, > >> So you have a jtag debugger attached, does it support showing registers? >> What is the value of uart->base? Is it correct? >> Also you could compare the UART registers with the ones from a working >> U-Boot/barebox. > Yes, I have, it does. I've checked, and it seems to be correct, > pointing to 0xFFFFF200. > > However I didn't think to check the register offset and mask (it was > late). > >> Which instance of the UART are you using? It seems we have: > I'm using the debug UART (USART0)... > >> Does atmel_serial_init_port() do everything correctly? >> Finally it may be that the clock is disabled for some reason, > Was thinking the same thing. > > I'll check it (compare reg dumps, console init) tonight and report my > findings. > > > Cheers, Peter > > On 2016-08-18 09:38, Sascha Hauer wrote: >> Hi Peter, >> >> On Thu, Aug 18, 2016 at 03:08:36AM +0200, Peter Kardos wrote: >>> Greetings, >>> >>> I'm looking for a AT91 specialist that could help me debug barebox >>> v2016.08. >>> >>> I have a custom board running AT91RM9200 that came with a really old >>> custom >>> u-boot (v1.1.4, no ubifs support)... >>> >>> The first bootloader I've ported (barebox v2015.07, using >>> AT91RM9200ek as >>> template) almost works; I'm having trouble getting networking (ping, >>> dhcp) >>> working with Micrel KSZ8721 phy. But it boots, works with the Flash, >>> etc... >>> With hopes, that this (networking issue) is resolved with the latest >>> barebox >>> release (using the same patchset and config) I've found (??) a another >>> issue. >>> >>> At first it seemed the board just does not boot, after having a look >>> with a >>> j-link it seems the board "hangs" in atmel_serial_putc(). >>> I've tried to look at the AT91RM9200 init (lowlevel, peripherals, >>> driver) >>> and could not find any significant change (rewrite, define changes, >>> etc)... >> So you have a jtag debugger attached, does it support showing registers? >> What is the value of uart->base? Is it correct? >> Also you could compare the UART registers with the ones from a working >> U-Boot/barebox. Does atmel_serial_init_port() do everything correctly? >> Finally it may be that the clock is disabled for some reason, then the >> values written to the UART would never be shifted out. >> Which instance of the UART are you using? It seems we have: >> >> static struct clk_lookup usart_clocks_lookups[] = { >> CLKDEV_CON_DEV_ID("usart", "atmel_usart0", &mck), >> CLKDEV_CON_DEV_ID("usart", "atmel_usart1", &usart0_clk), >> CLKDEV_CON_DEV_ID("usart", "atmel_usart2", &usart1_clk), >> CLKDEV_CON_DEV_ID("usart", "atmel_usart3", &usart2_clk), >> CLKDEV_CON_DEV_ID("usart", "atmel_usart4", &usart3_clk), >> }; >> >> The first clock seems to be always-on, but the others could be turned >> off. >> >> Sascha >> > _______________________________________________ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: AT91RM9200 hang in atmel_serial_putc 2016-08-18 21:15 ` Peter Kardos @ 2016-08-22 6:10 ` Sascha Hauer 2016-08-22 9:00 ` Peter Kardos 0 siblings, 1 reply; 9+ messages in thread From: Sascha Hauer @ 2016-08-22 6:10 UTC (permalink / raw) To: Peter Kardos; +Cc: barebox On Thu, Aug 18, 2016 at 11:15:33PM +0200, Peter Kardos wrote: > Hi Sascha, > > I may have something. It seems the memory (MMU?) gets "messed" up; > > Reading the debug uart registers (v2015.07) gives reasonable results, like > (gdb) x/32w 0xfffff200 > 0xfffff200: 0x00000000 0x00000800 0x00000000 0x00000000 > 0xfffff210: 0x00000000 0x40001a1a 0x00000000 0x00000000 > 0xfffff220: 0x00000021 0x00000000 0x00000000 0x00000000 > 0xfffff230: 0x00000000 0x00000000 0x00000000 0x00000000 > 0xfffff240: 0x09290781 0x00000000 0x00000000 0x00000000 > > However the content from v2016.08 gives > > 0xFFFFF200 D78D7E1F F1139ADE 413E0FE5 BBFB6DF2 > 0xFFFFF210 7D78666E 79CBDEA6 8FB2CB03 BEF6C2B7 > 0xFFFFF220 C9071D17 FA1EFA2D C4BCD95E 27D73C7C > 0xFFFFF230 727C3437 DFBDEBED 69C45C2A 7F5958F6 > 0xFFFFF240 834B237E F8B8A211 1AC74D66 FAE06274 Uh, this indeed seems to be messed up by the MMU, more specifically during setup of the vector table. Could you try the attached patch? It's not a solution, but is a clear indication that the bug is in this area. Sascha ---------------------------8<-------------------------------- From eb66f09db694a0bc1fc88cde8d86e47faf6debf9 Mon Sep 17 00:00:00 2001 From: Sascha Hauer <s.hauer@pengutronix.de> Date: Mon, 22 Aug 2016 08:05:38 +0200 Subject: [PATCH] ARM: Disable vector table (tmp) Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> --- arch/arm/cpu/mmu.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/cpu/mmu.c b/arch/arm/cpu/mmu.c index a31bce4..fc26077 100644 --- a/arch/arm/cpu/mmu.c +++ b/arch/arm/cpu/mmu.c @@ -289,6 +289,8 @@ static void create_vector_table(unsigned long adr) u32 *exc; int idx; + return; + vectors_sdram = request_sdram_region("vector table", adr, SZ_4K); if (vectors_sdram) { /* -- 2.8.1 -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | _______________________________________________ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: AT91RM9200 hang in atmel_serial_putc 2016-08-22 6:10 ` Sascha Hauer @ 2016-08-22 9:00 ` Peter Kardos 2016-08-22 20:39 ` Peter Kardos 0 siblings, 1 reply; 9+ messages in thread From: Peter Kardos @ 2016-08-22 9:00 UTC (permalink / raw) To: Sascha Hauer; +Cc: barebox During the weekend I've played with this some more... It seems that the "breakage" was introduced with v2016.05. This version introduced the "exception vector remapping to 0xFFFF*". Unfortunately AT91RM9200 has peripherals in this region. I'll test the patch tonight when i get home. Peter On 2016-08-22 08:10, Sascha Hauer wrote: > On Thu, Aug 18, 2016 at 11:15:33PM +0200, Peter Kardos wrote: >> Hi Sascha, >> >> I may have something. It seems the memory (MMU?) gets "messed" up; >> >> Reading the debug uart registers (v2015.07) gives reasonable results, like >> (gdb) x/32w 0xfffff200 >> 0xfffff200: 0x00000000 0x00000800 0x00000000 0x00000000 >> 0xfffff210: 0x00000000 0x40001a1a 0x00000000 0x00000000 >> 0xfffff220: 0x00000021 0x00000000 0x00000000 0x00000000 >> 0xfffff230: 0x00000000 0x00000000 0x00000000 0x00000000 >> 0xfffff240: 0x09290781 0x00000000 0x00000000 0x00000000 >> >> However the content from v2016.08 gives >> >> 0xFFFFF200 D78D7E1F F1139ADE 413E0FE5 BBFB6DF2 >> 0xFFFFF210 7D78666E 79CBDEA6 8FB2CB03 BEF6C2B7 >> 0xFFFFF220 C9071D17 FA1EFA2D C4BCD95E 27D73C7C >> 0xFFFFF230 727C3437 DFBDEBED 69C45C2A 7F5958F6 >> 0xFFFFF240 834B237E F8B8A211 1AC74D66 FAE06274 > Uh, this indeed seems to be messed up by the MMU, more specifically > during setup of the vector table. Could you try the attached patch? > It's not a solution, but is a clear indication that the bug is in this > area. > > Sascha > > ---------------------------8<-------------------------------- > > From eb66f09db694a0bc1fc88cde8d86e47faf6debf9 Mon Sep 17 00:00:00 2001 > From: Sascha Hauer <s.hauer@pengutronix.de> > Date: Mon, 22 Aug 2016 08:05:38 +0200 > Subject: [PATCH] ARM: Disable vector table (tmp) > > Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> > --- > arch/arm/cpu/mmu.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/arch/arm/cpu/mmu.c b/arch/arm/cpu/mmu.c > index a31bce4..fc26077 100644 > --- a/arch/arm/cpu/mmu.c > +++ b/arch/arm/cpu/mmu.c > @@ -289,6 +289,8 @@ static void create_vector_table(unsigned long adr) > u32 *exc; > int idx; > > + return; > + > vectors_sdram = request_sdram_region("vector table", adr, SZ_4K); > if (vectors_sdram) { > /* _______________________________________________ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: AT91RM9200 hang in atmel_serial_putc 2016-08-22 9:00 ` Peter Kardos @ 2016-08-22 20:39 ` Peter Kardos 2016-08-24 12:24 ` Sascha Hauer 0 siblings, 1 reply; 9+ messages in thread From: Peter Kardos @ 2016-08-22 20:39 UTC (permalink / raw) To: Sascha Hauer; +Cc: barebox Hi Sascha, I've tested your workaround and it seems to work; the board starts and attempts to boot. Peter On 8/22/2016 11:00 AM, Peter Kardos wrote: > During the weekend I've played with this some more... > It seems that the "breakage" was introduced with v2016.05. This version > introduced the "exception vector remapping to 0xFFFF*". > Unfortunately AT91RM9200 has peripherals in this region. > > I'll test the patch tonight when i get home. > > Peter > > On 2016-08-22 08:10, Sascha Hauer wrote: >> On Thu, Aug 18, 2016 at 11:15:33PM +0200, Peter Kardos wrote: >>> Hi Sascha, >>> >>> I may have something. It seems the memory (MMU?) gets "messed" up; >>> >>> Reading the debug uart registers (v2015.07) gives reasonable >>> results, like >>> (gdb) x/32w 0xfffff200 >>> 0xfffff200: 0x00000000 0x00000800 0x00000000 0x00000000 >>> 0xfffff210: 0x00000000 0x40001a1a 0x00000000 0x00000000 >>> 0xfffff220: 0x00000021 0x00000000 0x00000000 0x00000000 >>> 0xfffff230: 0x00000000 0x00000000 0x00000000 0x00000000 >>> 0xfffff240: 0x09290781 0x00000000 0x00000000 0x00000000 >>> >>> However the content from v2016.08 gives >>> >>> 0xFFFFF200 D78D7E1F F1139ADE 413E0FE5 BBFB6DF2 >>> 0xFFFFF210 7D78666E 79CBDEA6 8FB2CB03 BEF6C2B7 >>> 0xFFFFF220 C9071D17 FA1EFA2D C4BCD95E 27D73C7C >>> 0xFFFFF230 727C3437 DFBDEBED 69C45C2A 7F5958F6 >>> 0xFFFFF240 834B237E F8B8A211 1AC74D66 FAE06274 >> Uh, this indeed seems to be messed up by the MMU, more specifically >> during setup of the vector table. Could you try the attached patch? >> It's not a solution, but is a clear indication that the bug is in this >> area. >> >> Sascha >> >> ---------------------------8<-------------------------------- >> >> From eb66f09db694a0bc1fc88cde8d86e47faf6debf9 Mon Sep 17 00:00:00 2001 >> From: Sascha Hauer <s.hauer@pengutronix.de> >> Date: Mon, 22 Aug 2016 08:05:38 +0200 >> Subject: [PATCH] ARM: Disable vector table (tmp) >> >> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> >> --- >> arch/arm/cpu/mmu.c | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/arch/arm/cpu/mmu.c b/arch/arm/cpu/mmu.c >> index a31bce4..fc26077 100644 >> --- a/arch/arm/cpu/mmu.c >> +++ b/arch/arm/cpu/mmu.c >> @@ -289,6 +289,8 @@ static void create_vector_table(unsigned long adr) >> u32 *exc; >> int idx; >> + return; >> + >> vectors_sdram = request_sdram_region("vector table", adr, SZ_4K); >> if (vectors_sdram) { >> /* > _______________________________________________ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: AT91RM9200 hang in atmel_serial_putc 2016-08-22 20:39 ` Peter Kardos @ 2016-08-24 12:24 ` Sascha Hauer 2016-08-25 20:53 ` Peter Kardos 0 siblings, 1 reply; 9+ messages in thread From: Sascha Hauer @ 2016-08-24 12:24 UTC (permalink / raw) To: Peter Kardos; +Cc: barebox Hi Peter, On Mon, Aug 22, 2016 at 10:39:24PM +0200, Peter Kardos wrote: > Hi Sascha, > > I've tested your workaround and it seems to work; the board starts and > attempts > to boot. I just sent a proper solution for that problem, you're on Cc. I'm confident that this solves your problem. Could you give this a test please? Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | _______________________________________________ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: AT91RM9200 hang in atmel_serial_putc 2016-08-24 12:24 ` Sascha Hauer @ 2016-08-25 20:53 ` Peter Kardos 0 siblings, 0 replies; 9+ messages in thread From: Peter Kardos @ 2016-08-25 20:53 UTC (permalink / raw) To: Sascha Hauer; +Cc: barebox Hi Sascha, Can confirm, with v2016.08 + patch the system boots and seems to work as expected. Thanks for your help with this issue. Cheers, Peter On 8/24/2016 2:24 PM, Sascha Hauer wrote: > Hi Peter, > > On Mon, Aug 22, 2016 at 10:39:24PM +0200, Peter Kardos wrote: >> Hi Sascha, >> >> I've tested your workaround and it seems to work; the board starts and >> attempts >> to boot. > I just sent a proper solution for that problem, you're on Cc. I'm > confident that this solves your problem. Could you give this a test > please? > > Sascha > _______________________________________________ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2016-08-25 20:53 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-08-18 1:08 AT91RM9200 hang in atmel_serial_putc Peter Kardos 2016-08-18 7:38 ` Sascha Hauer 2016-08-18 8:00 ` Peter Kardos 2016-08-18 21:15 ` Peter Kardos 2016-08-22 6:10 ` Sascha Hauer 2016-08-22 9:00 ` Peter Kardos 2016-08-22 20:39 ` Peter Kardos 2016-08-24 12:24 ` Sascha Hauer 2016-08-25 20:53 ` Peter Kardos
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox