On 10/26/2016 02:00 PM, Stephen Warren wrote: > On 10/26/2016 02:29 PM, york sun wrote: >> On 10/26/2016 01:12 PM, Stephen Warren wrote: >>> On 10/26/2016 01:54 PM, york sun wrote: >>>> On 10/26/2016 12:47 PM, Stephen Warren wrote: >>>>> >>>>> There are two data structures in ARM U-Boot that describe memory layout: >>>>> >>>>> 1) A list of RAM memory regions. U-Boot uses these to know where to >>>>> relocate itself to (it relocates itself to the top of RAM at boot), and >>>>> to fill in the /memory node when booting an OS using DT (and other >>>>> equivalent mechanisms when not using DT.) >>>>> >>>>> 2) For AArch64 specifically, there's a memory map table that defines all >>>>> RAM and MMIO regions, and the translation table attributes required for >>>>> those regions. >>>>> >>>>> Judging by your comments later in the original message, it sounds like >>>>> it'd be fine to read from these structures during any dcache clean >>>>> routine provided the table has already been cleaned. That makes using >>>>> the tables much more tractable:-) >>>>> >>>> >>>> I think we need to benchmark walking through the MMU tables. It can map >>>> huge amount of memory. For our case, it is more than 16GB. I have been >>>> reluctant to do so for the size. I am now back testing to revert _this_ >>>> patch, hoping to confirm what I learned from this discussion. After >>>> that, I will see how long it takes to flush all cached addresses by VA. >>> >>> Given the existence of the two data structures I mentioned above, I >>> don't think we'd ever need to walk the MMU translation tables (assuming >>> you mean the data structures U-Boot creates and configures into the >>> CPU's MMU), rather than just walking over the tiny number of entries in >>> those data structures? >>> >> >> The list of RAM used by U-Boot is different from the total memory. >> U-Boot relocates itself to the gd->ram_top. We may have memory in second >> region, or even the third region. >> >> We also have other cached region other than RAM. I know for Layerscape >> SoCs, there is QMan portal has 64MB cached. If we consider to flush >> _all_ address, they should be included. >> >> I think the 2nd data structure you mentioned is the MMU table for >> aarch64, isn't it? > > The 2nd data structure I mentioned is what U-Boot uses to create the > translation tables, but isn't the translation table itself. >
I see. You were referring the struct mm_region. It does simplify walking the address. You presumption is we don't update the MMU table after creating it. It is mostly true, but current MMU code allows updating. York _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
