[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v3 1/1] tricore: added triboard with tc27x_soc
From: |
Bastian Koppelmann |
Subject: |
Re: [PATCH v3 1/1] tricore: added triboard with tc27x_soc |
Date: |
Wed, 1 Jul 2020 10:46:49 +0200 |
Hi Andreas,
On Tue, Jun 30, 2020 at 10:28:57AM +0000, Konopik, Andreas (EFS-GH2) wrote:
> Hi Bastian,
>
> > On Mon, Jun 22, 2020 at 03:19:34PM +0200, David Brenken wrote:
> > > From: Andreas Konopik <andreas.konopik@efs-auto.de>
> > > +const MemmapEntry tc27x_soc_memmap[] = {
> > > + [TC27XD_DSPR2] = { 0x50000000, 0x1E000 },
> > > + [TC27XD_DCACHE2] = { 0x5001E000, 0x2000 },
> > > + [TC27XD_DTAG2] = { 0x500C0000, 0xC00 },
> >
> > The size changed from 0xa00 to 0xc00 from v2. The manual states that it has
> > no
> > size. I guess you inferred the size from the address range. How does real hw
> > behave if you access DTAG2?
>
> DTAG size of 0xa00 was a mistake, 0xc00 is correct. Even though the manual
> does not assign sizes, DTAG and PTAG can be mapped for memory testing
> purposes.
> Therefore memory accesses to DTAG/PTAG are possible (see Footnote 3 & 4 [1,
> Page 3-10]).
>
> Real hardware has to be configured via MTU before accessing DTAG/PTAG.
> Because QEMU tricore has no MTU, we wanted to be less restrictive by mapping
> DTAG/PTAG into memory.
Ok, that sound reasonable to me.
>
> > Why not use KiB/MiB sizes as before? I created a patch for that. Can you
> > check
> > that I didn't skrew up the sizes?
>
> Thank you, the patch looks good to me.
> How do you want to proceed? Should we send you a Patch v4?
Yes, that would be best.
Cheers,
Bastian
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: [PATCH v3 1/1] tricore: added triboard with tc27x_soc,
Bastian Koppelmann <=