Em quinta-feira, 24 de maio de 2018 14:57:18 UTC-4, J. Kiszka escreveu: > 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
Let me know if you want me to test on the real hardware once you have figure it out. -- 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.
