On 2018-05-24 16:50, Giovani Gracioli wrote: > Em quinta-feira, 24 de maio de 2018 10:44:10 UTC-4, J. Kiszka escreveu: >> On 2018-05-24 16:27, Giovani Gracioli wrote: >>>> On 2018-05-24 15:59, Giovani Gracioli wrote: >>>>> Not sure about MMU on Erika. >>>>> >>>>> Yes, the fault is reported as well. This address is just another memory. >>>>> 0xA00.. is the BRAM and 0x500.. is the DRAM. Both have the same faulty >>>>> behavior when the size is 2MB. >>>> >>>> You see the issue also when mapping some arbitrary DRAM region with a >>>> size of 2MB? Can you reproduce this with an IVSHMEM region as well? What >>>> if you increase the size beyond 2M, to 3M e.g.? >>>> >>>> Jan >>>> >>>> -- >>>> Siemens AG, Corporate Technology, CT RDA IOT SES-DE >>>> Corporate Competence Center Embedded Linux >>> >>> DRAM: works with 1MB, 3MB, and 32MB. >>> does not work with 2MB. >>> >>> BRAM (is limited to 2MB): works with 1MB, does not with 2MB. >>> >>> IVSHMEM: tested with 1 and 2MB and worked in both cases. >>> >> >> That's not a consistent pattern yet because IVSHMEM and DRAM is just the >> same, use the same flags etc. >> >> Can you send a config that demonstrates the DRAM issue? Ideally very >> close to the upstream zynqmp-zcu102 configs. >> >> Thanks, >> Jan >> >> -- >> Siemens AG, Corporate Technology, CT RDA IOT SES-DE >> Corporate Competence Center Embedded Linux > > Just tested these two attached and got: > > Unhandled data write at 0x500000000(4) > > FATAL: unhandled trap (exception class 0x24) > Cell state before exception: > pc: 0000000000006944 lr: 0000000000006944 spsr: 60000005 EL1 > sp: 0000000000006870 esr: 24 1 1970045 > x0: 0000000000000000 x1: 0000000000009670 x2: 0000000000000000 > x3: 0000000000000004 x4: 00000000000027b8 x5: 0000000000000000 > x6: 0000000000000000 x7: 0000000000000080 x8: 00000000000068b0 > x9: 00000000000023e0 x10: 0000000000000000 x11: 0000000000009292 > x12: 0000000000000000 x13: 0000000000000000 x14: 0000000000000020 > x15: 0000000000000000 x16: 0000000000000000 x17: 0000000000000000 > x18: 0000000000000000 x19: 0000000000001118 x20: 00000000000092cf > x21: 0000000800700000 x22: 0000000500000000 x23: 000000000000000a > x24: 0000000000000000 x25: 0000000000000000 x26: 0000000000000000 > x27: 0000000000000000 x28: 0000000000000000 x29: 0000000000000000 > > Parking CPU 1 (Cell: "nfer") >
OK, good news, I've reproduced something very strange, and that even inside qemu. Debugging... Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux -- You received this message because you are subscribed to the Google Groups "Jailhouse" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
