01:59.25 | *** join/#htc-linux nearst (~nearst@pdpc/supporter/monthlybyte/nearst) |
02:27.56 | *** join/#htc-linux detule (~detule@unaffiliated/d3tul3) |
04:05.30 | *** join/#htc-linux ccxCZ (~ccxCZ@156.200.broadband11.iol.cz) |
04:25.38 | *** join/#htc-linux NEMESIS| (nembnc@bash0rt.euch.kacknubs.de) |
04:25.50 | *** join/#htc-linux swc|666 (~sdub@Aircrack-NG/Friend) |
04:25.50 | *** join/#htc-linux pigeon (~pigeon@eth5284.nsw.adsl.internode.on.net) |
04:25.50 | *** join/#htc-linux NetRippah (~netripper@tikkie.net) |
04:26.01 | *** join/#htc-linux lilstevie (~null@2a00:dcc0:eda:3748:247:48:46:1) |
04:26.01 | *** join/#htc-linux Willd (willd@citu-202.citu.kth.se) |
04:26.34 | *** join/#htc-linux d3tul3 (~d3tul3@unaffiliated/d3tul3) |
04:26.34 | *** join/#htc-linux bartman (~bart@2607:f2c0:f00e:700::dd) |
04:26.45 | *** join/#htc-linux |lippa|^ (~lippa@CPE-121-219-244-246.lnse1.win.bigpond.net.au) |
04:27.00 | *** join/#htc-linux surge (surge@pool-98-118-154-23.bflony.fios.verizon.net) |
04:27.01 | *** join/#htc-linux jonpry (~jon@2602:306:c417:8aa0:e107:cfb:6290:8135) |
04:27.01 | *** join/#htc-linux hasi (hasi@mausi.hasicon.org) |
04:27.13 | *** join/#htc-linux phh (~quassel@137.194.15.151) |
04:27.14 | *** join/#htc-linux nrirclog (~nrirclog@jongkorendijk.nl) |
04:27.24 | *** join/#htc-linux detule (~detule@pool-96-234-132-77.bltmmd.east.verizon.net) |
04:27.24 | *** join/#htc-linux Ondalf (~ondalf@cable-roi-50ddf8-39.dhcp.inet.fi) |
04:27.24 | *** join/#htc-linux the-leviathan (~quassel@c-82-192-226-27.customer.ggaweb.ch) |
04:27.24 | *** join/#htc-linux _me (kayser@sur-internet.net) |
04:27.42 | *** join/#htc-linux tomaw (tom@freenode/staff/tomaw) |
04:27.49 | *** join/#htc-linux ltxda (~anon@unaffiliated/ltxda) |
04:27.49 | *** join/#htc-linux toastcfh (~toastcfh@unaffiliated/toastcfh) |
04:27.49 | *** join/#htc-linux sado1 (~sado1@static.79.37.46.78.clients.your-server.de) |
04:27.49 | *** join/#htc-linux arrrghhh (~arrrghhh@unaffiliated/arrrghhh) |
04:29.19 | *** join/#htc-linux ALoGeNo (~alogeno@unaffiliated/alogeno) |
04:39.30 | *** join/#htc-linux detule (~detule@unaffiliated/d3tul3) |
04:48.18 | *** join/#htc-linux ALoGeNo (~alogeno@unaffiliated/alogeno) |
05:00.40 | *** join/#htc-linux ccxCZ (~ccxCZ@156.200.broadband11.iol.cz) |
05:44.16 | *** join/#htc-linux lipp[a] (~lippa@101.160.128.97) |
05:56.46 | *** join/#htc-linux |lippa|^ (~lippa@CPE-121-214-44-91.lnse4.win.bigpond.net.au) |
06:26.46 | *** join/#htc-linux lipp[a] (~lippa@CPE-121-219-253-2.lnse1.win.bigpond.net.au) |
06:30.46 | *** join/#htc-linux |lippa|^ (~lippa@CPE-124-181-208-248.lnse3.win.bigpond.net.au) |
06:38.47 | *** join/#htc-linux Bry8Star (~Bry8Star@gateway/tor-sasl/bry8star) |
06:51.45 | *** join/#htc-linux Bry8Star (~Bry8Star@gateway/tor-sasl/bry8star) |
06:54.57 | *** join/#htc-linux kiozen (~kiozen@p578a42db.dip0.t-ipconnect.de) |
07:12.12 | *** join/#htc-linux lamikr (lamikr@nat/nokia/x-aslgxuveynhzrhtp) |
07:20.38 | *** join/#htc-linux Cotulla (~myfakemai@109.205.253.11) |
08:08.16 | *** join/#htc-linux lamikr (lamikr@nat/nokia/x-rrrnvyyaglebzjle) |
08:54.36 | *** join/#htc-linux eR^zeRa` (~zzeratul@ip-84-42-202-42.net.upcbroadband.cz) |
09:18.43 | *** join/#htc-linux stroughtonsmith (~steven@86-42-150-7-dynamic.b-ras1.bbh.dublin.eircom.net) |
09:25.39 | *** join/#htc-linux helicopter88 (~helicopte@host177-112-dynamic.46-79-r.retail.telecomitalia.it) |
09:38.41 | *** join/#htc-linux lipp[a] (~lippa@CPE-124-181-208-248.lnse3.win.bigpond.net.au) |
09:46.46 | *** join/#htc-linux lipp[a] (~lippa@CPE-124-181-208-248.lnse3.win.bigpond.net.au) |
10:02.15 | *** join/#htc-linux helicopter88 (~helicopte@host177-112-dynamic.46-79-r.retail.telecomitalia.it) |
10:02.35 | *** join/#htc-linux rajkosto (~rajkosto@wan.rajkonet.info) |
10:16.35 | *** join/#htc-linux helicopter88_2 (~helicopte@host129-54-dynamic.40-79-r.retail.telecomitalia.it) |
10:42.04 | *** join/#htc-linux lamikr (lamikr@nat/nokia/x-srfwfuyxwivcvefa) |
10:42.16 | *** join/#htc-linux ElFinLazz (~elfinlazz@182.215.84.22) |
11:06.15 | *** join/#htc-linux lipp[a] (~lippa@CPE-121-219-112-163.lnse2.lon.bigpond.net.au) |
11:16.13 | *** join/#htc-linux detule (~detule@unaffiliated/d3tul3) |
11:52.48 | *** join/#htc-linux |lippa|^ (~lippa@CPE-121-219-4-139.lnse1.lon.bigpond.net.au) |
11:53.59 | *** join/#htc-linux arif-ali (~arif-ali@81.144.163.60) |
11:59.17 | *** join/#htc-linux lipp[a] (~lippa@CPE-121-214-31-234.lnse3.win.bigpond.net.au) |
12:02.47 | *** part/#htc-linux Cotulla (~myfakemai@109.205.253.11) |
12:17.53 | *** join/#htc-linux gauner1986 (~Adium@pd95b906c.dip0.t-ipconnect.de) |
12:59.01 | *** join/#htc-linux lamikr (lamikr@nat/nokia/x-kduyhjvgqafuoluz) |
14:46.47 | *** join/#htc-linux Cotulla (~myfakemai@109.205.253.11) |
14:49.31 | *** part/#htc-linux Cotulla (~myfakemai@109.205.253.11) |
14:50.30 | *** join/#htc-linux Cotulla (~myfakemai@109.205.253.11) |
14:50.33 | Cotulla | hello |
15:02.43 | jonpry | hi Cotulla |
15:03.03 | Cotulla | hey |
15:03.06 | Cotulla | just thought about u :P |
15:03.15 | Cotulla | I looked to sources more deep |
15:03.19 | jonpry | so about the page tables |
15:03.22 | Cotulla | as well looked how CE do that for MIPS |
15:03.24 | Cotulla | yes |
15:03.34 | jonpry | kernel is split |
15:03.41 | Cotulla | so u looked too? |
15:04.07 | jonpry | so there is only 1GB of kernel memory |
15:04.25 | jonpry | so level 1 and 2 fit into a single page |
15:04.25 | Cotulla | yes |
15:04.31 | Cotulla | from C000 0000 + |
15:04.45 | jonpry | which is just permanently in the TLB |
15:05.10 | jonpry | and per thread page tables are in kernel memory |
15:05.19 | jonpry | so worst case is a nested fault |
15:05.35 | Cotulla | hm wait |
15:05.41 | Cotulla | kernel memory is still splitted |
15:05.46 | Cotulla | by 4K pages |
15:06.15 | Cotulla | otherwise u need reserve too much amount of physical memory |
15:06.39 | jonpry | 4k entries right? |
15:06.48 | d3tul3 | how much would you need to reserve |
15:06.56 | Cotulla | yes I think |
15:07.07 | Cotulla | and linux kernel doesn't map all ram to kernel space |
15:07.16 | Cotulla | my current idea is simple: |
15:07.21 | Cotulla | just made it two levels |
15:08.05 | Cotulla | so inside tlbmiss handler we will need replace TLB entry for L2 page table, then read value and put another TLB entry. it looks like only one way for me . . . |
15:08.31 | Cotulla | I assuem that L1 page table is always in TLB |
15:08.59 | jonpry | l2 kernel table should fit |
15:09.04 | jonpry | it's only 1 page |
15:09.19 | Cotulla | well it can be optimized |
15:09.55 | Cotulla | I think |
15:10.05 | Cotulla | that we should put most of that data to area |
15:10.07 | Cotulla | like 64K |
15:10.14 | Cotulla | to map it via 1 TLB entry |
15:10.21 | Cotulla | inside can be: |
15:10.33 | Cotulla | 1)6 * L1 Page Tables (6 * 4K) |
15:10.56 | Cotulla | hm |
15:10.59 | jonpry | i think 7 |
15:11.01 | Cotulla | what do u mean under |
15:11.02 | Cotulla | jonpryl2 kernel table should fit |
15:11.03 | Cotulla | jonpryit's only 1 page |
15:11.06 | Cotulla | ? |
15:11.17 | Cotulla | one L2 table describes 4M |
15:11.53 | jonpry | ic |
15:12.05 | jonpry | i got confused |
15:12.28 | Cotulla | so |
15:12.33 | jonpry | so map in 256 pages? |
15:12.39 | Cotulla | as well |
15:12.42 | jonpry | 1M region for kernels l2? |
15:12.44 | Cotulla | 2)tlbmiss code |
15:13.01 | Cotulla | I am not sure about kernel ELF itself. there is init code which maps it |
15:13.17 | Cotulla | and |
15:13.23 | Cotulla | 1 TLB entry for that area |
15:13.33 | Cotulla | maybe 3 TLB entries for spare L2 access |
15:13.47 | Cotulla | and 6 * 10 entries for 6 HW threads code/data accesses |
15:14.05 | Cotulla | or maybe made 6 * 5 for code and 6 * 5 for data |
15:14.15 | Cotulla | not sure about the best way |
15:14.47 | jonpry | i think FILO |
15:15.56 | jonpry | except for kernel stuff that needs permanent mapping |
15:16.15 | Cotulla | 1 TLB can be enough |
15:16.31 | Cotulla | 64K for tlbmiss code, L1 and etc |
15:16.46 | Cotulla | or maybe ever 16K |
15:17.04 | jonpry | then its PTE_R PTE_W PTE_X |
15:17.21 | Cotulla | kinda yes |
15:21.36 | Cotulla | dunno how fast it will be |
15:21.51 | Cotulla | but HW MMU in ARM also should take some time |
15:22.56 | Cotulla | also we need to add PHYS_OFFSET I think |
15:23.02 | Cotulla | it's missing there |
15:33.49 | Cotulla | they assume that it's loaded at 0x00000000 seems |
15:42.30 | jonpry | there's no memory at 0 |
15:42.57 | Cotulla | for LEO I need 0x10000000 offset |
15:50.38 | Cotulla | did u look into setup_arch_memory? |
15:55.09 | jonpry | qdsp is using a hole at 0x8da0 0000 on 8x60 it seems |
16:01.31 | Cotulla | yes |
16:01.35 | Cotulla | so also some offset must be |
16:01.42 | Cotulla | we need add it |
16:01.59 | Cotulla | setup_arch_memory() is strange |
16:02.08 | Cotulla | dunno who was an author |
16:07.08 | jonpry | i guess hypervisor is able to hide physical layout |
16:09.14 | jonpry | i think head.S code is not position independent |
16:09.15 | Cotulla | it could |
16:09.23 | Cotulla | u can add offset to PTE actually |
16:09.30 | Cotulla | but there are also IO mappings |
16:09.47 | jonpry | somehow linker needs to know physical entry point |
16:09.59 | Cotulla | it always was |
16:10.03 | Cotulla | ever ARM kernels |
16:10.15 | Cotulla | they are always builded for specific PA/VA combination |
16:10.30 | jonpry | yes |
16:10.34 | Cotulla | so it should be same |
16:10.41 | jonpry | i don't see that machinery in hexagon |
16:10.52 | Cotulla | just I need my kernel to be at PA=0x10000000 VA=0xC0000000 |
16:10.58 | Cotulla | in ur case 0x8da0 0000 |
16:11.04 | Cotulla | or 0x8e00 0000 |
16:11.27 | jonpry | 8da sounds good to me |
16:11.38 | Cotulla | 1 mb aligned |
16:11.46 | Cotulla | 8e0 is 16 mb aligned |
16:11.59 | jonpry | for huge tlb? |
16:13.25 | Cotulla | yes |
16:13.33 | Cotulla | but I don't really understand |
16:13.37 | Cotulla | that they are doing in setup_arch_memory |
16:13.39 | Cotulla | strange logic |
16:13.45 | Cotulla | I think author used somethikng |
16:15.17 | Cotulla | they made a present for me |
16:15.23 | Cotulla | some definitions from COMET |
16:18.44 | jonpry | i don't see the problem |
16:19.04 | jonpry | segtable is like l1 right? |
16:19.15 | Cotulla | it's bad documented |
16:19.19 | Cotulla | as well bad variables usage |
16:19.21 | jonpry | 4M per entry |
16:19.36 | jonpry | 256 entries lol |
16:19.51 | Cotulla | where |
16:20.03 | Cotulla | L1 yes |
16:20.08 | jonpry | /* this actually only goes to the end of the first gig */ |
16:20.09 | jonpry | segtable_end = segtable + (1<<(30-22)); |
16:20.35 | Cotulla | and what did he mean? |
16:20.39 | Cotulla | 30 - 22 wtf |
16:23.30 | Cotulla | we should rewrite it maybe |
16:23.38 | Cotulla | setup_arch_memory() |
16:27.08 | jonpry | it's like c++ iterator style |
16:27.24 | jonpry | for(i=begin(); i!=end();i++) |
16:27.54 | jonpry | 1 << log2(1GB) - log2(4MB) |
16:29.54 | Cotulla | where is it |
16:30.08 | Cotulla | bootmem_startpg is after kernel ELF |
16:30.15 | Cotulla | bootmem_lastpg end of mem seems |
16:40.29 | Cotulla | why wee need DMA RESERVE? |
16:41.02 | *** join/#htc-linux paulk-desktop (~paulk@lib33-1-82-233-88-171.fbx.proxad.net) |
16:41.46 | Cotulla | so they made top of ram uncached |
16:41.48 | Cotulla | it's like PMEM! |
16:41.52 | Cotulla | pfff |
16:57.27 | jonpry | all kernels have upper memory as DMA region |
16:57.37 | jonpry | even x86 |
16:58.56 | Cotulla | in ARM it's implemented different |
16:59.02 | Cotulla | I am talking about physical memory |
16:59.41 | Cotulla | or wait |
16:59.46 | Cotulla | it's virtual space?? |
16:59.57 | Cotulla | yes looks like virtual :( |
17:00.28 | Cotulla | but why they setup uncached attribute |
17:00.38 | Cotulla | and use 4M sections |
17:03.58 | jonpry | why is it segtable[-i] |
17:04.14 | Cotulla | from end to start |
17:04.31 | Cotulla | or wait |
17:04.35 | Cotulla | bootmem_lastpg is last ram |
17:04.41 | Cotulla | or not? |
17:05.44 | jonpry | yeah i think segtable[0] is the first invalid page |
17:05.53 | Cotulla | they have |
17:06.05 | jonpry | i guess DMA_RESERVE is just n*4MB |
17:06.08 | Cotulla | segtable = L1_PTE |
17:06.20 | Cotulla | segtable += 0xC00 |
17:06.31 | Cotulla | move to entries for 0xC0000000 |
17:06.46 | Cotulla | segtable_end = segtable + 0x100 ? |
17:06.48 | jonpry | <PROTECTED> |
17:07.26 | Cotulla | yes, but it should be done by 4K uncached pages like in ARM |
17:07.45 | jonpry | why? |
17:07.51 | Cotulla | to prevent ram memory lost |
17:07.59 | Cotulla | they implemented it like PMEM |
17:08.05 | jonpry | is there is 4MB of DMA, why not use course |
17:08.08 | Cotulla | some memory block is reserved |
17:08.14 | Cotulla | at the start up |
17:08.18 | jonpry | s/is/if |
17:08.31 | Cotulla | but it's physical ram |
17:08.56 | jonpry | so? |
17:09.01 | Cotulla | so it's like PMEM |
17:09.08 | jonpry | not exactly |
17:09.12 | Cotulla | why? |
17:09.16 | Cotulla | it looks same |
17:09.20 | jonpry | my phone has a 4MB DMA region |
17:09.35 | jonpry | it's for kernel use. not crazy userland blobs |
17:09.39 | jonpry | so does my laptop |
17:09.47 | Cotulla | wait |
17:09.55 | Cotulla | look at dma_alloc_from_coherent() for ARM |
17:10.00 | Cotulla | it's implemented different |
17:10.08 | Cotulla | they are searching pages near |
17:10.16 | Cotulla | and map them to virtual region by 4K uncached pages |
17:11.12 | jonpry | but if the DMA region is a multiple of 4MB, that is a waste of time |
17:11.40 | Cotulla | but who need 4 mb of dma? |
17:11.48 | Cotulla | it's like buffers for SD and etc |
17:11.52 | Cotulla | in ur case it's different |
17:12.02 | Cotulla | SMMU change that behavior |
17:12.25 | jonpry | it's also packet buffers |
17:12.33 | jonpry | virtio |
17:12.42 | Cotulla | packet buffers? |
17:12.48 | Cotulla | it should be only used for hardware devices |
17:12.53 | jonpry | like network packets |
17:12.59 | Cotulla | hm no? |
17:13.04 | jonpry | are sent by the network hardware |
17:13.06 | Cotulla | they can use just a vmalloc |
17:13.10 | jonpry | at least on pcie devices |
17:13.19 | Cotulla | yes, but we have no pcie :) |
17:13.20 | jonpry | so the buffers are allocated in coherent memory |
17:13.38 | jonpry | linux architecture doesn't know what card will eventually transmit a packet |
17:13.50 | jonpry | so it's all zero copy buffers in coherent memory |
17:14.01 | Cotulla | it can run out of them |
17:14.04 | Cotulla | hm |
17:14.20 | Cotulla | anyway it doesn't matter for current state |
17:14.33 | Cotulla | kernel is not up |
17:14.37 | jonpry | except i only have a 16mb hole |
17:14.42 | jonpry | fuck |
17:14.48 | jonpry | gonna have to mangle atags |
17:14.52 | Cotulla | I can use any memory |
17:14.58 | jonpry | :p |
17:14.59 | Cotulla | but original one is 24M |
17:15.36 | Cotulla | I think I will implement SW MMU in qMAGLDR before |
17:15.42 | Cotulla | and then port code to kernel |
17:15.58 | jonpry | alright |
17:16.04 | Cotulla | kinda those calls |
17:16.06 | Cotulla | vmset |
17:16.08 | Cotulla | vmclr |
17:16.10 | jonpry | i'm still working on running an ELF through PIL |
17:16.47 | Cotulla | I mean vmnewmap |
17:16.51 | Cotulla | and vmclrmap |
17:17.21 | jonpry | bbl |
17:17.51 | Cotulla | oki |
17:25.05 | *** join/#htc-linux tehtrk (~The@rrcs-24-173-220-30.sw.biz.rr.com) |
17:33.08 | Cotulla | hm how in GAS define big array? |
17:33.29 | fakker | atomic value |
17:33.30 | fakker | duh |
17:33.42 | Cotulla | lol fakker as usual miss |
17:33.45 | fakker | :D |
17:33.50 | Cotulla | :D |
17:33.56 | Cotulla | u got that miss means? |
17:34.05 | fakker | no, but i don't care |
17:34.11 | Cotulla | lol |
17:46.45 | fakker | smoke me a kipper, i'll be back for breakfast |
18:14.56 | Cotulla | what did he say?!? |
18:37.55 | *** join/#htc-linux khorben__ (~dont@91.102.9.98) |
18:53.59 | Cotulla | jonpry, maybe better to keep code inside kernel. just put that 1M mapping always to TLB. |
19:05.23 | *** join/#htc-linux helicopter88 (~helicopte@host169-226-dynamic.37-79-r.retail.telecomitalia.it) |
19:17.05 | *** join/#htc-linux kiozen (~kiozen@ppp-93-104-86-54.dynamic.mnet-online.de) |
19:30.32 | *** join/#htc-linux helicopter88 (~helicopte@host169-226-dynamic.37-79-r.retail.telecomitalia.it) |
19:32.03 | *** join/#htc-linux helicopter88 (~helicopte@host169-226-dynamic.37-79-r.retail.telecomitalia.it) |
20:15.37 | *** join/#htc-linux arif-ali (~arif-ali@94-192-24-56.zone6.bethere.co.uk) |
21:13.19 | *** join/#htc-linux detule (~detule@unaffiliated/d3tul3) |
21:25.51 | *** join/#htc-linux arif-ali (~arif-ali@81.144.163.60) |
21:33.47 | *** join/#htc-linux lamikr (lamikr@nat/nokia/x-xqjmqshlxahwmwoz) |
22:14.22 | *** part/#htc-linux Cotulla (~myfakemai@109.205.253.11) |
22:24.03 | *** join/#htc-linux detule (~detule@unaffiliated/d3tul3) |
22:28.30 | *** join/#htc-linux gassed (faxed@c-76-30-161-228.hsd1.tx.comcast.net) |