IRC log for #htc-linux on 20130208

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.33Cotullahello
15:02.43jonpryhi Cotulla
15:03.03Cotullahey
15:03.06Cotullajust thought about u :P
15:03.15CotullaI looked to sources more deep
15:03.19jonpryso about the page tables
15:03.22Cotullaas well looked how CE do that for MIPS
15:03.24Cotullayes
15:03.34jonprykernel is split
15:03.41Cotullaso u looked too?
15:04.07jonpryso there is only 1GB of kernel memory
15:04.25jonpryso level 1 and 2 fit into a single page
15:04.25Cotullayes
15:04.31Cotullafrom C000 0000 +
15:04.45jonprywhich is just permanently in the TLB
15:05.10jonpryand per thread page tables are in kernel memory
15:05.19jonpryso worst case is a nested fault
15:05.35Cotullahm wait
15:05.41Cotullakernel memory is still splitted
15:05.46Cotullaby 4K pages
15:06.15Cotullaotherwise u need reserve too much amount of physical memory
15:06.39jonpry4k entries right?
15:06.48d3tul3how much would you need to reserve
15:06.56Cotullayes I think
15:07.07Cotullaand linux kernel doesn't map all ram to kernel space
15:07.16Cotullamy current idea is simple:
15:07.21Cotullajust made it two levels
15:08.05Cotullaso 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.31CotullaI assuem that L1 page table is always in TLB
15:08.59jonpryl2 kernel table should fit
15:09.04jonpryit's only 1 page
15:09.19Cotullawell it can be optimized
15:09.55CotullaI think
15:10.05Cotullathat we should put most of that data to area
15:10.07Cotullalike 64K
15:10.14Cotullato map it via 1 TLB entry
15:10.21Cotullainside can be:
15:10.33Cotulla1)6 * L1 Page Tables (6 * 4K)
15:10.56Cotullahm
15:10.59jonpryi think 7
15:11.01Cotullawhat do u mean under
15:11.02Cotullajonpryl2 kernel table should fit
15:11.03Cotullajonpryit's only 1 page
15:11.06Cotulla?
15:11.17Cotullaone L2 table describes 4M
15:11.53jonpryic
15:12.05jonpryi got confused
15:12.28Cotullaso
15:12.33jonpryso map in 256 pages?
15:12.39Cotullaas well
15:12.42jonpry1M region for kernels l2?
15:12.44Cotulla2)tlbmiss code
15:13.01CotullaI am not sure about kernel ELF itself. there is init code which maps it
15:13.17Cotullaand
15:13.23Cotulla1 TLB entry for that area
15:13.33Cotullamaybe 3 TLB entries for spare L2 access
15:13.47Cotullaand 6 * 10 entries for 6 HW threads code/data accesses
15:14.05Cotullaor maybe made 6 * 5 for code and 6 * 5 for data
15:14.15Cotullanot sure about the best way
15:14.47jonpryi think FILO
15:15.56jonpryexcept for kernel stuff that needs permanent mapping
15:16.15Cotulla1 TLB can be enough
15:16.31Cotulla64K for tlbmiss code, L1 and etc
15:16.46Cotullaor maybe ever 16K
15:17.04jonprythen its PTE_R PTE_W PTE_X
15:17.21Cotullakinda yes
15:21.36Cotulladunno how fast it will be
15:21.51Cotullabut HW MMU in ARM also should take some time
15:22.56Cotullaalso we need to add PHYS_OFFSET I think
15:23.02Cotullait's missing there
15:33.49Cotullathey assume that it's loaded at 0x00000000 seems
15:42.30jonprythere's no memory at 0
15:42.57Cotullafor LEO I need 0x10000000 offset
15:50.38Cotulladid u look into setup_arch_memory?
15:55.09jonpryqdsp is using a hole at 0x8da0 0000 on 8x60 it seems
16:01.31Cotullayes
16:01.35Cotullaso also some offset must be
16:01.42Cotullawe need add it
16:01.59Cotullasetup_arch_memory() is strange
16:02.08Cotulladunno who was an author
16:07.08jonpryi guess hypervisor is able to hide physical layout
16:09.14jonpryi think head.S code is not position independent
16:09.15Cotullait could
16:09.23Cotullau can add offset to PTE actually
16:09.30Cotullabut there are also IO mappings
16:09.47jonprysomehow linker needs to know physical entry point
16:09.59Cotullait always was
16:10.03Cotullaever ARM kernels
16:10.15Cotullathey are always builded for specific PA/VA combination
16:10.30jonpryyes
16:10.34Cotullaso it should be same
16:10.41jonpryi don't see that machinery in hexagon
16:10.52Cotullajust I need my kernel to be at PA=0x10000000 VA=0xC0000000
16:10.58Cotullain ur case 0x8da0 0000
16:11.04Cotullaor 0x8e00 0000
16:11.27jonpry8da sounds good to me
16:11.38Cotulla1 mb aligned
16:11.46Cotulla8e0 is  16 mb aligned
16:11.59jonpryfor huge tlb?
16:13.25Cotullayes
16:13.33Cotullabut I don't really understand
16:13.37Cotullathat they are doing in setup_arch_memory
16:13.39Cotullastrange logic
16:13.45CotullaI think author used somethikng
16:15.17Cotullathey made a present for me
16:15.23Cotullasome definitions from COMET
16:18.44jonpryi don't see the problem
16:19.04jonprysegtable is like l1 right?
16:19.15Cotullait's bad documented
16:19.19Cotullaas well bad variables usage
16:19.21jonpry4M per entry
16:19.36jonpry256 entries lol
16:19.51Cotullawhere
16:20.03CotullaL1 yes
16:20.08jonpry/*  this actually only goes to the end of the first gig  */
16:20.09jonprysegtable_end = segtable + (1<<(30-22));
16:20.35Cotullaand what did he mean?
16:20.39Cotulla30 - 22 wtf
16:23.30Cotullawe should rewrite it maybe
16:23.38Cotullasetup_arch_memory()
16:27.08jonpryit's like c++ iterator style
16:27.24jonpryfor(i=begin(); i!=end();i++)
16:27.54jonpry1 << log2(1GB) - log2(4MB)
16:29.54Cotullawhere is it
16:30.08Cotullabootmem_startpg is after kernel ELF
16:30.15Cotullabootmem_lastpg end of mem seems
16:40.29Cotullawhy wee need DMA RESERVE?
16:41.02*** join/#htc-linux paulk-desktop (~paulk@lib33-1-82-233-88-171.fbx.proxad.net)
16:41.46Cotullaso they made top of ram uncached
16:41.48Cotullait's like PMEM!
16:41.52Cotullapfff
16:57.27jonpryall kernels have upper memory as DMA region
16:57.37jonpryeven x86
16:58.56Cotullain ARM it's implemented different
16:59.02CotullaI am talking about physical memory
16:59.41Cotullaor wait
16:59.46Cotullait's virtual space??
16:59.57Cotullayes looks like virtual :(
17:00.28Cotullabut why they setup uncached attribute
17:00.38Cotullaand use 4M sections
17:03.58jonprywhy is it segtable[-i]
17:04.14Cotullafrom end to start
17:04.31Cotullaor wait
17:04.35Cotullabootmem_lastpg is last ram
17:04.41Cotullaor not?
17:05.44jonpryyeah i think segtable[0] is the first invalid page
17:05.53Cotullathey have
17:06.05jonpryi guess DMA_RESERVE is just n*4MB
17:06.08Cotullasegtable = L1_PTE
17:06.20Cotullasegtable += 0xC00
17:06.31Cotullamove to entries for 0xC0000000
17:06.46Cotullasegtable_end = segtable + 0x100 ?
17:06.48jonpry<PROTECTED>
17:07.26Cotullayes, but it should be done by 4K uncached pages like in ARM
17:07.45jonprywhy?
17:07.51Cotullato prevent ram memory lost
17:07.59Cotullathey implemented it like PMEM
17:08.05jonpryis there is 4MB of DMA, why not use course
17:08.08Cotullasome memory block is reserved
17:08.14Cotullaat the start up
17:08.18jonprys/is/if
17:08.31Cotullabut it's physical ram
17:08.56jonpryso?
17:09.01Cotullaso it's like PMEM
17:09.08jonprynot exactly
17:09.12Cotullawhy?
17:09.16Cotullait looks same
17:09.20jonprymy phone has a 4MB DMA region
17:09.35jonpryit's for kernel use. not crazy userland blobs
17:09.39jonpryso does my laptop
17:09.47Cotullawait
17:09.55Cotullalook at dma_alloc_from_coherent() for ARM
17:10.00Cotullait's implemented different
17:10.08Cotullathey are searching pages near
17:10.16Cotullaand map them to virtual region by 4K uncached pages
17:11.12jonprybut if the DMA region is a multiple of 4MB, that is a waste of time
17:11.40Cotullabut who need 4 mb of dma?
17:11.48Cotullait's like buffers for SD and etc
17:11.52Cotullain ur case it's different
17:12.02CotullaSMMU change that behavior
17:12.25jonpryit's also packet buffers
17:12.33jonpryvirtio
17:12.42Cotullapacket buffers?
17:12.48Cotullait should be only used for hardware devices
17:12.53jonprylike network packets
17:12.59Cotullahm no?
17:13.04jonpryare sent by the network hardware
17:13.06Cotullathey can use just a vmalloc
17:13.10jonpryat least on pcie devices
17:13.19Cotullayes, but we have no pcie :)
17:13.20jonpryso the buffers are allocated in coherent memory
17:13.38jonprylinux architecture doesn't know what card will eventually transmit a packet
17:13.50jonpryso it's all zero copy buffers in coherent memory
17:14.01Cotullait can run out of them
17:14.04Cotullahm
17:14.20Cotullaanyway it doesn't matter for current state
17:14.33Cotullakernel is not up
17:14.37jonpryexcept i only have a 16mb hole
17:14.42jonpryfuck
17:14.48jonprygonna have to mangle atags
17:14.52CotullaI can use any memory
17:14.58jonpry:p
17:14.59Cotullabut original one is 24M
17:15.36CotullaI think I will implement SW MMU in qMAGLDR before
17:15.42Cotullaand then port code to kernel
17:15.58jonpryalright
17:16.04Cotullakinda those calls
17:16.06Cotullavmset
17:16.08Cotullavmclr
17:16.10jonpryi'm still working on running an ELF through PIL
17:16.47CotullaI mean vmnewmap
17:16.51Cotullaand vmclrmap
17:17.21jonprybbl
17:17.51Cotullaoki
17:25.05*** join/#htc-linux tehtrk (~The@rrcs-24-173-220-30.sw.biz.rr.com)
17:33.08Cotullahm how in GAS define big array?
17:33.29fakkeratomic value
17:33.30fakkerduh
17:33.42Cotullalol fakker as usual miss
17:33.45fakker:D
17:33.50Cotulla:D
17:33.56Cotullau got that miss means?
17:34.05fakkerno, but i don't care
17:34.11Cotullalol
17:46.45fakkersmoke me a kipper, i'll be back for breakfast
18:14.56Cotullawhat did he say?!?
18:37.55*** join/#htc-linux khorben__ (~dont@91.102.9.98)
18:53.59Cotullajonpry, 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)

Generated by irclog2html.pl Modified by Tim Riker to work with infobot.