[U-Boot] U-boot broken on e500v2 soc
Valentin,
Can you refresh my memory why you needed this commitac337168ad81a18e768e5e3cfff8d229adeb2b25 (patch http://patchwork.ozlabs.org/patch/455439)? Today I bisect an issue back to this commit.
Scott,
Can you help to examine this u-boot commit? Before this commit, 512x/5xxx/83xx/85xx do nothing on function invalidate_dcache_range() and flush_dcache_range(). With this patch, I found e500v2 is broken on Intel e1000 card when testing v2016-rc1. I didn't catch this issue when testing this patch.
I wonder if this code is not safe for e500v2, or because the cache line size should be determined by reading L1CFG0. Why didn't we see any issue with Linux with the same code.
Log for testing on e500v2
P1023RDB
U-Boot 2016.01-rc1-00115-g2b24e09 (Nov 20 2015 - 22:01:56 -0800)
CPU0: P1023E, Version: 1.1, (0x80fe0011) Core: e500, Version: 5.1, (0x80212151) Clock Configuration: CPU0:500 MHz, CPU1:500 MHz, CCB:333.333 MHz, DDR:333.333 MHz (666.667 MT/s data rate) (Asynchronous), LBC:41.667 MHz FMAN1: 333.333 MHz QMAN: 0 MHz L1: D-cache 32 KiB enabled I-cache 32 KiB enabled Board: P1023 RDB I2C: ready DRAM: DIMM 0: is not a DDR3 SPD. SPD error on controller 0! Trying fallback to raw timing calculation Detected UDIMM Fixed DDR on board 512 MiB (DDR3, 32-bit, CL=5, ECC off) Flash: 64 MiB L2: 256 KiB enabled NAND: 128 MiB EEPROM: CRC mismatch (a7fdad5b != ffffffff) PCIe1: Root Complex of Slot 1, no link, regs @ 0xff60a000 PCIe1: Bus 00 - 00 PCIe2: Root Complex of Slot 2, x1 gen1, regs @ 0xff609000 02:00.0 - 8086:107d - Network controller PCIe2: Bus 01 - 02 PCIe3: Root Complex of Slot 3, x1 gen1, regs @ 0xff60b000 04:00.0 - 168c:0030 - Network controller PCIe3: Bus 03 - 04 In: serial Out: serial Err: serial Net: Fman1: Uploading microcode version 160.0.18 e1000: 00:15:17:8e:7b:8d FM1@DTSEC1, FM1@DTSEC2, e1000#0 [PRIME] Warning: e1000#0 MAC addresses don't match: Address in SROM is 00:15:17:8e:7b:8d Address in environment is 00:e0:0c:00:06:02
=> ping $serverip Using e1000#0 device Bad trap at PC: 1ffc6f10, SR: 6049434, vector=e00 NIP: 1FFC6F10 XER: 00000000 LR: 1FEF0B6C REGS: 1f8eda70 TRAP: 0e00 DAR: 20000000 MSR: 06049434 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
GPR00: 1FF457D4 1F8EDB60 1F8EDF14 20000000 00020000 0000001F 00000000 1F8EDAB8 GPR08: A0003818 00004000 00000003 1F8EDB80 1FF457D4 EC662032 1FFC8D50 1FFC6F24 GPR16: 1FFB0074 1FFB005C 1FF59701 1FF5971F 1FF49C37 1FFB0068 00000000 1FFC6F10 GPR24: 1FFB00CC 1FF48D60 00000000 1F8F3D70 1FFC5600 00400000 1FF5C610 00400000 Call backtrace: 1FF2F350 1FF457D4 1FF06888 1FF13AF8 1FEFA180 1FEFA7FC 1FEF9A90 1FEFA124 1FEFA7FC 1FEFAA1C 1FF12B54 1FEFB140 1FF3AA7C 1FEFB454 1FEF0F4C Exception in kernel pc 1ffc6f10 signal 0 ### ERROR ### Please RESET the board ###
P1022DS log
U-Boot 2016.01-rc1-00115-g2b24e09 (Nov 20 2015 - 22:17:10 -0800)
CPU0: P1022E, Version: 1.0, (0x80ee0010) Core: e500, Version: 5.0, (0x80211050) Clock Configuration: CPU0:999.990 MHz, CPU1:999.990 MHz, CCB:499.995 MHz, DDR:333.330 MHz (666.660 MT/s data rate) (Asynchronous), LBC:31.250 MHz L1: D-cache 32 KiB enabled I-cache 32 KiB enabled Board: P1022DS Sys ID: 0x19, Sys Ver: 0x03, FPGA Ver: 0x09, vBank: 0 I2C: ready SPI: ready DRAM: Detected RDIMM 18JSF51272PDZ1G4D1 Detected 4 GiB of memory This U-Boot only supports < 4G of DDR You could rebuild it with CONFIG_PHYS_64BIT 2 GiB (DDR3, 64-bit, CL=5, ECC off) Flash: 128 MiB L2: 256 KiB enabled NAND: 1024 MiB MMC: FSL_SDHC: 0 EEPROM: NXID v0 PCIe1: Root Complex of Slot 1, no link, regs @ 0xffe0a000 PCIe1: Bus 00 - 00 PCIe2: Root Complex of Slot 3, x1 gen1, regs @ 0xffe09000 02:00.0 - 8086:10b9 - Network controller PCIe2: Bus 01 - 02 PCIe3: Root Complex of Slot 2, no link, regs @ 0xffe0b000 PCIe3: Bus 03 - 03 In: serial Out: serial Err: serial Net: e1000: 00:15:17:0b:8c:74 eTSEC1, eTSEC2, e1000#0 [PRIME] Hit any key to stop autoboot: 0 => ping $serverip Using e1000#0 device pci_bus_to_hose() failed pci_hose_phys_to_bus: invalid hose pci_bus_to_hose() failed pci_hose_phys_to_bus: invalid hose
Abort
Hi York,
On 21/11/2015 07:33, York Sun wrote:
Valentin,
Can you refresh my memory why you needed this commitac337168ad81a18e768e5e3cfff8d229adeb2b25 (patch http://patchwork.ozlabs.org/patch/455439)? Today I bisect an issue back to this commit.
In the patch description, there is a link to another patch that introduced some problems with the bootcounter driver (http://patchwork.ozlabs.org/patch/448849/). On the Keymile boards, we use this bootcounter functionality that must call dcache_flush after the above change. Tom suggested that powerpc required the kernel's corresponding cache function from arch/powerpc/kernel/misc_32.S ported over to u-boot. That's what I did and it allowed to solve the bootcounter problem.
Unfortunately, we don't have e500v2 CPUs at Keymile, only e300 and e500mc so this patch was not tested from my side on e500v2 either.
Valentin
Scott,
Can you help to examine this u-boot commit? Before this commit, 512x/5xxx/83xx/85xx do nothing on function invalidate_dcache_range() and flush_dcache_range(). With this patch, I found e500v2 is broken on Intel e1000 card when testing v2016-rc1. I didn't catch this issue when testing this patch.
I wonder if this code is not safe for e500v2, or because the cache line size should be determined by reading L1CFG0. Why didn't we see any issue with Linux with the same code.
Log for testing on e500v2
P1023RDB
U-Boot 2016.01-rc1-00115-g2b24e09 (Nov 20 2015 - 22:01:56 -0800)
CPU0: P1023E, Version: 1.1, (0x80fe0011) Core: e500, Version: 5.1, (0x80212151) Clock Configuration: CPU0:500 MHz, CPU1:500 MHz, CCB:333.333 MHz, DDR:333.333 MHz (666.667 MT/s data rate) (Asynchronous), LBC:41.667 MHz FMAN1: 333.333 MHz QMAN: 0 MHz L1: D-cache 32 KiB enabled I-cache 32 KiB enabled Board: P1023 RDB I2C: ready DRAM: DIMM 0: is not a DDR3 SPD. SPD error on controller 0! Trying fallback to raw timing calculation Detected UDIMM Fixed DDR on board 512 MiB (DDR3, 32-bit, CL=5, ECC off) Flash: 64 MiB L2: 256 KiB enabled NAND: 128 MiB EEPROM: CRC mismatch (a7fdad5b != ffffffff) PCIe1: Root Complex of Slot 1, no link, regs @ 0xff60a000 PCIe1: Bus 00 - 00 PCIe2: Root Complex of Slot 2, x1 gen1, regs @ 0xff609000 02:00.0 - 8086:107d - Network controller PCIe2: Bus 01 - 02 PCIe3: Root Complex of Slot 3, x1 gen1, regs @ 0xff60b000 04:00.0 - 168c:0030 - Network controller PCIe3: Bus 03 - 04 In: serial Out: serial Err: serial Net: Fman1: Uploading microcode version 160.0.18 e1000: 00:15:17:8e:7b:8d FM1@DTSEC1, FM1@DTSEC2, e1000#0 [PRIME] Warning: e1000#0 MAC addresses don't match: Address in SROM is 00:15:17:8e:7b:8d Address in environment is 00:e0:0c:00:06:02
=> ping $serverip Using e1000#0 device Bad trap at PC: 1ffc6f10, SR: 6049434, vector=e00 NIP: 1FFC6F10 XER: 00000000 LR: 1FEF0B6C REGS: 1f8eda70 TRAP: 0e00 DAR: 20000000 MSR: 06049434 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
GPR00: 1FF457D4 1F8EDB60 1F8EDF14 20000000 00020000 0000001F 00000000 1F8EDAB8 GPR08: A0003818 00004000 00000003 1F8EDB80 1FF457D4 EC662032 1FFC8D50 1FFC6F24 GPR16: 1FFB0074 1FFB005C 1FF59701 1FF5971F 1FF49C37 1FFB0068 00000000 1FFC6F10 GPR24: 1FFB00CC 1FF48D60 00000000 1F8F3D70 1FFC5600 00400000 1FF5C610 00400000 Call backtrace: 1FF2F350 1FF457D4 1FF06888 1FF13AF8 1FEFA180 1FEFA7FC 1FEF9A90 1FEFA124 1FEFA7FC 1FEFAA1C 1FF12B54 1FEFB140 1FF3AA7C 1FEFB454 1FEF0F4C Exception in kernel pc 1ffc6f10 signal 0 ### ERROR ### Please RESET the board ###
P1022DS log
U-Boot 2016.01-rc1-00115-g2b24e09 (Nov 20 2015 - 22:17:10 -0800)
CPU0: P1022E, Version: 1.0, (0x80ee0010) Core: e500, Version: 5.0, (0x80211050) Clock Configuration: CPU0:999.990 MHz, CPU1:999.990 MHz, CCB:499.995 MHz, DDR:333.330 MHz (666.660 MT/s data rate) (Asynchronous), LBC:31.250 MHz L1: D-cache 32 KiB enabled I-cache 32 KiB enabled Board: P1022DS Sys ID: 0x19, Sys Ver: 0x03, FPGA Ver: 0x09, vBank: 0 I2C: ready SPI: ready DRAM: Detected RDIMM 18JSF51272PDZ1G4D1 Detected 4 GiB of memory This U-Boot only supports < 4G of DDR You could rebuild it with CONFIG_PHYS_64BIT 2 GiB (DDR3, 64-bit, CL=5, ECC off) Flash: 128 MiB L2: 256 KiB enabled NAND: 1024 MiB MMC: FSL_SDHC: 0 EEPROM: NXID v0 PCIe1: Root Complex of Slot 1, no link, regs @ 0xffe0a000 PCIe1: Bus 00 - 00 PCIe2: Root Complex of Slot 3, x1 gen1, regs @ 0xffe09000 02:00.0 - 8086:10b9 - Network controller PCIe2: Bus 01 - 02 PCIe3: Root Complex of Slot 2, no link, regs @ 0xffe0b000 PCIe3: Bus 03 - 03 In: serial Out: serial Err: serial Net: e1000: 00:15:17:0b:8c:74 eTSEC1, eTSEC2, e1000#0 [PRIME] Hit any key to stop autoboot: 0 => ping $serverip Using e1000#0 device pci_bus_to_hose() failed pci_hose_phys_to_bus: invalid hose pci_bus_to_hose() failed pci_hose_phys_to_bus: invalid hose
Abort
On Fri, 2015-11-20 at 22:33 -0800, York Sun wrote:
Valentin,
Can you refresh my memory why you needed this commitac337168ad81a18e768e5e3cfff8d229adeb2b25 (patch http://patchwork.ozlabs.org/patch/455439)? Today I bisect an issue back to this commit.
Scott,
Can you help to examine this u-boot commit? Before this commit, 512x/5xxx/83xx/85xx do nothing on function invalidate_dcache_range() and flush_dcache_range(). With this patch, I found e500v2 is broken on Intel e1000 card when testing v2016-rc1. I didn't catch this issue when testing this patch.
I wonder if this code is not safe for e500v2, or because the cache line size should be determined by reading L1CFG0. Why didn't we see any issue with Linux with the same code.
L1_CACHE_SIZE should be 5 as long as CONFIG_E500MC is not defined. I'm not sure what Linux has to do with this since it isn't the same code (in particular, Linux knows that the I/O is coherent and doesn't flush on e500).
What happens if you comment out invalidate_cache_range() but leave flush_cache_range()? We should never need to do the former on e500.
Log for testing on e500v2
P1023RDB
U-Boot 2016.01-rc1-00115-g2b24e09 (Nov 20 2015 - 22:01:56 -0800)
CPU0: P1023E, Version: 1.1, (0x80fe0011) Core: e500, Version: 5.1, (0x80212151) Clock Configuration: CPU0:500 MHz, CPU1:500 MHz, CCB:333.333 MHz, DDR:333.333 MHz (666.667 MT/s data rate) (Asynchronous), LBC:41.667 MHz FMAN1: 333.333 MHz QMAN: 0 MHz L1: D-cache 32 KiB enabled I-cache 32 KiB enabled Board: P1023 RDB I2C: ready DRAM: DIMM 0: is not a DDR3 SPD. SPD error on controller 0! Trying fallback to raw timing calculation Detected UDIMM Fixed DDR on board 512 MiB (DDR3, 32-bit, CL=5, ECC off) Flash: 64 MiB L2: 256 KiB enabled NAND: 128 MiB EEPROM: CRC mismatch (a7fdad5b != ffffffff) PCIe1: Root Complex of Slot 1, no link, regs @ 0xff60a000 PCIe1: Bus 00 - 00 PCIe2: Root Complex of Slot 2, x1 gen1, regs @ 0xff609000 02:00.0 - 8086:107d - Network controller PCIe2: Bus 01 - 02 PCIe3: Root Complex of Slot 3, x1 gen1, regs @ 0xff60b000 04:00.0 - 168c:0030 - Network controller PCIe3: Bus 03 - 04 In: serial Out: serial Err: serial Net: Fman1: Uploading microcode version 160.0.18 e1000: 00:15:17:8e:7b:8d FM1@DTSEC1, FM1@DTSEC2, e1000#0 [PRIME] Warning: e1000#0 MAC addresses don't match: Address in SROM is 00:15:17:8e:7b:8d Address in environment is 00:e0:0c:00:06:02
=> ping $serverip Using e1000#0 device Bad trap at PC: 1ffc6f10, SR: 6049434, vector=e00 NIP: 1FFC6F10 XER: 00000000 LR: 1FEF0B6C REGS: 1f8eda70 TRAP: 0e00 DAR: 20000000 MSR: 06049434 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
GPR00: 1FF457D4 1F8EDB60 1F8EDF14 20000000 00020000 0000001F 00000000 1F8EDAB8 GPR08: A0003818 00004000 00000003 1F8EDB80 1FF457D4 EC662032 1FFC8D50 1FFC6F24 GPR16: 1FFB0074 1FFB005C 1FF59701 1FF5971F 1FF49C37 1FFB0068 00000000 1FFC6F10 GPR24: 1FFB00CC 1FF48D60 00000000 1F8F3D70 1FFC5600 00400000 1FF5C610 00400000 Call backtrace: 1FF2F350 1FF457D4 1FF06888 1FF13AF8 1FEFA180 1FEFA7FC 1FEF9A90 1FEFA124 1FEFA7FC 1FEFAA1C 1FF12B54 1FEFB140 1FF3AA7C 1FEFB454 1FEF0F4C Exception in kernel pc 1ffc6f10 signal 0 ### ERROR ### Please RESET the board ###
0xe00 is an instruction TLB error. Could you dump the TLB when this happens?
DAR of 0x20000000 looks like something that would actually cause a problem, but that's only relevant to data exceptions, not instruction.
What is the instruction at 0x1ffc6f10?
-Scott
On 11/23/2015 03:19 PM, Scott Wood wrote:
On Fri, 2015-11-20 at 22:33 -0800, York Sun wrote:
Valentin,
Can you refresh my memory why you needed this commitac337168ad81a18e768e5e3cfff8d229adeb2b25 (patch http://patchwork.ozlabs.org/patch/455439)? Today I bisect an issue back to this commit.
Scott,
Can you help to examine this u-boot commit? Before this commit, 512x/5xxx/83xx/85xx do nothing on function invalidate_dcache_range() and flush_dcache_range(). With this patch, I found e500v2 is broken on Intel e1000 card when testing v2016-rc1. I didn't catch this issue when testing this patch.
I wonder if this code is not safe for e500v2, or because the cache line size should be determined by reading L1CFG0. Why didn't we see any issue with Linux with the same code.
L1_CACHE_SIZE should be 5 as long as CONFIG_E500MC is not defined. I'm not sure what Linux has to do with this since it isn't the same code (in particular, Linux knows that the I/O is coherent and doesn't flush on e500).
What happens if you comment out invalidate_cache_range() but leave flush_cache_range()? We should never need to do the former on e500.
If comment out the invalidate_cache_range(), this problem goes away. I can see several calls of this function in e1000 driver.
Shall we keep this function only for CONFIG_4xx and CONFIG_MPC86xx? That's what we had before.
Log for testing on e500v2
P1023RDB
U-Boot 2016.01-rc1-00115-g2b24e09 (Nov 20 2015 - 22:01:56 -0800)
CPU0: P1023E, Version: 1.1, (0x80fe0011) Core: e500, Version: 5.1, (0x80212151) Clock Configuration: CPU0:500 MHz, CPU1:500 MHz, CCB:333.333 MHz, DDR:333.333 MHz (666.667 MT/s data rate) (Asynchronous), LBC:41.667 MHz FMAN1: 333.333 MHz QMAN: 0 MHz L1: D-cache 32 KiB enabled I-cache 32 KiB enabled Board: P1023 RDB I2C: ready DRAM: DIMM 0: is not a DDR3 SPD. SPD error on controller 0! Trying fallback to raw timing calculation Detected UDIMM Fixed DDR on board 512 MiB (DDR3, 32-bit, CL=5, ECC off) Flash: 64 MiB L2: 256 KiB enabled NAND: 128 MiB EEPROM: CRC mismatch (a7fdad5b != ffffffff) PCIe1: Root Complex of Slot 1, no link, regs @ 0xff60a000 PCIe1: Bus 00 - 00 PCIe2: Root Complex of Slot 2, x1 gen1, regs @ 0xff609000 02:00.0 - 8086:107d - Network controller PCIe2: Bus 01 - 02 PCIe3: Root Complex of Slot 3, x1 gen1, regs @ 0xff60b000 04:00.0 - 168c:0030 - Network controller PCIe3: Bus 03 - 04 In: serial Out: serial Err: serial Net: Fman1: Uploading microcode version 160.0.18 e1000: 00:15:17:8e:7b:8d FM1@DTSEC1, FM1@DTSEC2, e1000#0 [PRIME] Warning: e1000#0 MAC addresses don't match: Address in SROM is 00:15:17:8e:7b:8d Address in environment is 00:e0:0c:00:06:02
=> ping $serverip Using e1000#0 device Bad trap at PC: 1ffc6f10, SR: 6049434, vector=e00 NIP: 1FFC6F10 XER: 00000000 LR: 1FEF0B6C REGS: 1f8eda70 TRAP: 0e00 DAR: 20000000 MSR: 06049434 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
GPR00: 1FF457D4 1F8EDB60 1F8EDF14 20000000 00020000 0000001F 00000000 1F8EDAB8 GPR08: A0003818 00004000 00000003 1F8EDB80 1FF457D4 EC662032 1FFC8D50 1FFC6F24 GPR16: 1FFB0074 1FFB005C 1FF59701 1FF5971F 1FF49C37 1FFB0068 00000000 1FFC6F10 GPR24: 1FFB00CC 1FF48D60 00000000 1F8F3D70 1FFC5600 00400000 1FF5C610 00400000 Call backtrace: 1FF2F350 1FF457D4 1FF06888 1FF13AF8 1FEFA180 1FEFA7FC 1FEF9A90 1FEFA124 1FEFA7FC 1FEFAA1C 1FF12B54 1FEFB140 1FF3AA7C 1FEFB454 1FEF0F4C Exception in kernel pc 1ffc6f10 signal 0 ### ERROR ### Please RESET the board ###
0xe00 is an instruction TLB error. Could you dump the TLB when this happens?
DAR of 0x20000000 looks like something that would actually cause a problem, but that's only relevant to data exceptions, not instruction.
What is the instruction at 0x1ffc6f10?
It is not a valid instruction. The reloacaddr is 0x1FEF0000. Doing the math, the original instruction would be at 0xF0016F10 which is beyond the image. I think this is caused by wrongly invalidated data.
York
On Tue, 2015-12-01 at 10:39 -0800, York Sun wrote:
On 11/23/2015 03:19 PM, Scott Wood wrote:
On Fri, 2015-11-20 at 22:33 -0800, York Sun wrote:
Valentin,
Can you refresh my memory why you needed this commitac337168ad81a18e768e5e3cfff8d229adeb2b25 (patch http://patchwork.ozlabs.org/patch/455439)? Today I bisect an issue back to this commit.
Scott,
Can you help to examine this u-boot commit? Before this commit, 512x/5xxx/83xx/85xx do nothing on function invalidate_dcache_range() and flush_dcache_range(). With this patch, I found e500v2 is broken on Intel e1000 card when testing v2016-rc1. I didn't catch this issue when testing this patch.
I wonder if this code is not safe for e500v2, or because the cache line size should be determined by reading L1CFG0. Why didn't we see any issue with Linux with the same code.
L1_CACHE_SIZE should be 5 as long as CONFIG_E500MC is not defined. I'm not sure what Linux has to do with this since it isn't the same code (in particular, Linux knows that the I/O is coherent and doesn't flush on e500).
What happens if you comment out invalidate_cache_range() but leave flush_cache_range()? We should never need to do the former on e500.
If comment out the invalidate_cache_range(), this problem goes away. I can see several calls of this function in e1000 driver.
Shall we keep this function only for CONFIG_4xx and CONFIG_MPC86xx? That's what we had before.
Maybe, though it would be good to know what the actual problem is... The driver should not be invalidating anything that was not previously flushed.
=> ping $serverip Using e1000#0 device Bad trap at PC: 1ffc6f10, SR: 6049434, vector=e00 NIP: 1FFC6F10 XER: 00000000 LR: 1FEF0B6C REGS: 1f8eda70 TRAP: 0e00 DAR: 20000000 MSR: 06049434 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
GPR00: 1FF457D4 1F8EDB60 1F8EDF14 20000000 00020000 0000001F 00000000 1F8EDAB8 GPR08: A0003818 00004000 00000003 1F8EDB80 1FF457D4 EC662032 1FFC8D50 1FFC6F24 GPR16: 1FFB0074 1FFB005C 1FF59701 1FF5971F 1FF49C37 1FFB0068 00000000 1FFC6F10 GPR24: 1FFB00CC 1FF48D60 00000000 1F8F3D70 1FFC5600 00400000 1FF5C610 00400000 Call backtrace: 1FF2F350 1FF457D4 1FF06888 1FF13AF8 1FEFA180 1FEFA7FC 1FEF9A90 1FEFA124 1FEFA7FC 1FEFAA1C 1FF12B54 1FEFB140 1FF3AA7C 1FEFB454 1FEF0F4C Exception in kernel pc 1ffc6f10 signal 0 ### ERROR ### Please RESET the board ###
0xe00 is an instruction TLB error. Could you dump the TLB when this happens?
DAR of 0x20000000 looks like something that would actually cause a problem, but that's only relevant to data exceptions, not instruction.
What is the instruction at 0x1ffc6f10?
It is not a valid instruction. The reloacaddr is 0x1FEF0000. Doing the math, the original instruction would be at 0xF0016F10 which is beyond the image. I think this is caused by wrongly invalidated data.
Is the LR valid, or the backtrace?
-Scott
participants (3)
-
Scott Wood -
Valentin Longchamp -
York Sun