**** BEGIN LOGGING AT Thu Jun 27 02:59:57 2019
**** BEGIN LOGGING AT Thu Jun 27 11:55:06 2019
Jun 27 13:46:35 <pratimugale[m]> zeekhuge: I was able to study about .asm and implement a simple  example.(I haven't used assembly before) I am now working on taking inputs and adjusting frequency.
Jun 27 13:50:52 <pratimugale[m]> I started working a bit late today
Jun 27 14:08:16 <zeekhuge[m]> pratimugale: okay.
Jun 27 14:08:55 <zeekhuge[m]> pranav_kumar: what's the project repo? Link please?
Jun 27 14:31:47 <zeekhuge[m]> pranav_kumar ^
Jun 27 14:40:46 <julieng> embden[m]: Any update?
Jun 27 14:46:52 <embden[m]> julieng: I will start in three hours.
Jun 27 14:48:22 <julieng> embden[m]: I am a bit confused, are you working only evening on your GSOC?
Jun 27 14:48:37 <embden[m]> julieng:  this week I have workers repairing the building, so, I work in the evenings
Jun 27 14:49:17 <julieng> embden[m]: Got it.
Jun 27 15:10:47 <pranav_kumar[m]> <zeekhuge[m] "pranav_kumar: what's the project"> Sry for the delay i was outside today for my brother college councelling https://github.com/pranav083/pocket_beagle-work
Jun 27 17:32:44 <embden[m]> julieng:  with that xen option the output is quite long - I need to find the way to  log it into a file
Jun 27 18:16:14 <embden[m]> julieng: https://drive.google.com/open?id=15YTsCKYUTbG2i-siWezJXKWuG0H1VfQz
Jun 27 19:09:30 <embden[m]> julieng: also, those are parameters with which function fails: part = 5, inst = 400, idx = 4
Jun 27 19:09:31 <embden[m]> I will expand a bit later
Jun 27 19:11:59 <embden[m]> part=5 is for ***_PRCM_MPU_PARTITION
Jun 27 19:25:54 <embden[m]> julieng:  https://github.com/torvalds/linux/blob/master/arch/arm/mach-omap2/prcm_mpu44xx.c#L54
Jun 27 19:30:00 <embden[m]> hm, I forgot that I should do it in ML
Jun 27 19:57:57 <julieng[m]> <embden[m] "hm, I forgot that I should do it"> Please CC all the mentors. So one of them can answer when I am unable to.
Jun 27 19:58:51 <embden[m]> julieng: I wanted but forgot to do it. Should I resend?
Jun 27 20:05:20 <embden[m]> julieng:  ^
Jun 27 20:07:29 <julieng[m]> <embden[m] "julieng: I wanted but forgot to "> No need to resend. Just reply on the e-mail and CC the other please.
Jun 27 20:08:30 <embden[m]> ok
Jun 27 21:55:44 <ds2> embden[m]: it appears the kernel is initializing power management. Do you know if the power management registers are faked/remapped or otherwise restricted under Xen?
Jun 27 21:57:27 <embden[m]> I think that xen does some kind of remapping, better to ask julieng  or sstabellini
Jun 27 21:59:02 <embden[m]> ds2:  I also posted this on xen-devel ml: https://lists.xenproject.org/archives/html/xen-devel/2019-06/msg01895.html
Jun 27 22:05:52 <ds2> embden[m]: those are still access to the PRCM... look at the call chain...powerdomains...the TI processors have registers that can shutdown parts of the chip
Jun 27 22:07:03 <sstabellini> embden[m]: can you point me to the device tree you are using and to the Linux kernel tree that you are using?
Jun 27 22:07:32 <sstabellini> ds2: wild guess here -- Xen is prevent access to them, either on purpose or just because they haven't been mapped to dom0
Jun 27 22:08:39 <ds2> sstabellini: yes
Jun 27 22:09:09 <ds2> I'd try to build the kernel w/o power management support but I don't recall if that actually does anything after the last round of changes
Jun 27 22:09:18 <sstabellini> ds2: as far as you know, are they described in device tree?
Jun 27 22:09:25 <sstabellini> ds2:  do they fall into one of the DT regions?
Jun 27 22:09:41 <sstabellini> ds2: if they are "secret" it is not going to work out of the box
Jun 27 22:10:02 <ds2> sstabellini: AFAIK, they are not in the DT... I don't see how that can be done easily but maybe they have refactored it to allow that
Jun 27 22:10:16 <sstabellini> ds2: do you know the range?
Jun 27 22:10:17 <ds2> got a git repo with the exact kernel tree being used?
Jun 27 22:10:30 <sstabellini> ds2: no, I was asking for it too :-)
Jun 27 22:10:38 <ds2> let me dig out the manual
Jun 27 22:11:12 <sstabellini> ds2: thank you. If we find out the exact range, and confirm that it is not in the DT, then it is easy to fix in Xen
Jun 27 22:11:34 <embden[m]> sstabellini:  Linux 5.1.9, device tree is beagle-x15-revC
Jun 27 22:11:45 <ds2> embden[m]: what's the GIT URL for the kernel repo?
Jun 27 22:12:05 <ds2> it'll take a bit of time...large PDF takes a while to load
Jun 27 22:13:50 <sstabellini> embden[m]: is that 5.1.9 from linux-stable?
Jun 27 22:14:05 <embden[m]> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm/boot/dts/am57xx-beagle-x15-revc.dts?h=v5.1.9
Jun 27 22:14:06 <embden[m]> yes
Jun 27 22:14:35 <embden[m]> am57xx-beagle-x15-revc.dts
Jun 27 22:16:10 <embden[m]> ds2:  sstabellini  ^
Jun 27 22:16:45 <sstabellini> embden[m]: it would be useful to add a printk in linux to know exactly the address causing the problem
Jun 27 22:16:59 <sstabellini> from the logs, I see there is an offset of 0xb2000000
Jun 27 22:17:08 <sstabellini> but I don't know the whole range, what it is supposed to be
Jun 27 22:18:23 <embden[m]> here are the logs: https://pastebin.com/BBAFPkVU
Jun 27 22:18:54 <ds2> I think the address blocks are described here - https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm/mach-omap2/prm54xx.h
Jun 27 22:19:01 <embden[m]> here I believe the address: 0x00000048243404
Jun 27 22:19:07 <ds2> the physical address  base is 0x4ae06000
Jun 27 22:19:22 <ds2> during startup it'd IO map that into some other range
Jun 27 22:19:30 <sstabellini> ds2: where is the iomap in linux?
Jun 27 22:19:41 <embden[m]> ds2:  no, it should be prm7xx.h
Jun 27 22:19:47 <ds2> sstabllini: does it matter?
Jun 27 22:20:10 <sstabellini> ds2: well no. It only matter the precise range. If we know this, we are set
Jun 27 22:20:17 <ds2> as far a I know that is choosen at run time but nothing should care what it comes out (it is returned by the ioremap called)
Jun 27 22:20:29 <sstabellini> ds2: I mean the physical range not the virtual range
Jun 27 22:20:37 <sstabellini> start_address and end_address
Jun 27 22:20:42 <ds2> sstabellini: Oh.... that's that base plus those offsets
Jun 27 22:21:03 <sstabellini> ds2: I was thinking that by looking at the ioremap commands I could figure it out
Jun 27 22:21:31 <ds2> embden[m]: sure... I don't think prm7xx and prm5 is that different
Jun 27 22:21:55 <ds2> sstabellini: that header file should define the addresses... the prm7xx.h is technically the one to use
Jun 27 22:22:41 <ds2> sstabellini: grep'ing for ioremap won't help...it references a structure that is setup differently depending on what platform (O2/O3/I4/O5 and their assorted derivatives)
Jun 27 22:23:10 <sstabellini> ds2: if the base is DRA7XX_PRM_BASE, I cannot see it being ioremapped anywhere
Jun 27 22:23:55 <sstabellini> embden[m]: once we find the ranges, you just need to add them to xen/arch/arm/platforms/omap5.c
Jun 27 22:23:59 <ds2> sstabellini: how are you checking?
Jun 27 22:23:59 <sstabellini> in Xen
Jun 27 22:24:06 <embden[m]> sstabellini: have you seen my mail in ML? is it useful?
Jun 27 22:24:59 <sstabellini> embden[m]: yes it is useful. If we know that we need to remap 0x4ae06000 for instance, we can add a map_mmio_regions call in omap5_specific_mapping
Jun 27 22:25:11 <sstabellini> ds2: I grepped for ioremap :-)
Jun 27 22:26:08 <embden[m]> I mentioned in the last sentence that they transform the physical address using macro
Jun 27 22:26:14 <ds2> sstabellini: you need to chase down the inits for the structures to find that  and I suspect it is not mapped broardly... might be done as DRA7XX_PRM_BASE+blah, .....
Jun 27 22:27:41 <ds2> if it is just a config line, I'd try enabling 0x4ae06000 - 0x4ae06000 + 0x3fff (very board but should cover everything
Jun 27 22:27:54 <ds2> if that works then chase down the narrower range to use
Jun 27 22:29:33 <embden[m]> The register they try to reach is described in AM472x TRM p.1673 if that helps ds2
Jun 27 22:29:52 <ds2> AM472x?
Jun 27 22:30:04 <embden[m]> 572x*
Jun 27 22:30:20 <ds2> Oh okay...
Jun 27 22:31:02 <ds2> what's the title of that chapter? the page number are specific to the edition of the TRM
Jun 27 22:31:58 <embden[m]> 4.4.6 MPU_PRCM_PRM_C0 Registers
Jun 27 22:31:59 <embden[m]> ds2:
Jun 27 22:34:56 <ds2> hmmm that's different
Jun 27 22:35:51 <ds2> Ohhh this is PM for the processor not for the peripherals
Jun 27 22:36:23 <ds2> 0x48243400 - 0x48243400+512 is the range for this stuff
Jun 27 23:19:06 <embden[m]> I need to sleep a bit, I will try to understand tomorrow what to do with that region
Jun 28 00:10:40 <sstabellini> ds2: thanks for finding the range, it should be "easy" now
Jun 28 00:10:54 <sstabellini> embden[m]: you just need to remap it into dom0, I'll reply to the email with more details
Jun 28 00:27:40 <vaishnav98_[m]> jkridner ravikp7: where should I be setting 'status=disabled' to disable the mmc driver? I wasn't able to find how to do it, should my modifications reflect to /boot/dtbs/'uname -r'/am335x-pocketbeagle.dtb ? I did fdtdump on that file could not find exactly how to modify it.
**** ENDING LOGGING AT Fri Jun 28 02:59:57 2019