**** BEGIN LOGGING AT Tue Jul 16 03:02:17 2019
Jul 16 04:50:09 <pratimugale[m]> abhishek_: I will have to go to college today for registration of courses, will resume work as soon as I return.
Jul 16 05:31:22 <Abhishek_1> Ok
Jul 16 13:17:33 <embden[m]> julieng:  probably I shouldn't set up interrupts for nodes with "status=disabled" property ?
Jul 16 13:28:37 <julieng> embden[m]: Hmmm, the property indicates the device is not operational yet but might become later on. So technically, we should set up the interrupts for those nodes.
Jul 16 13:28:44 <julieng> I guess you are asking the question because of Dom0?
Jul 16 13:40:02 <embden[m]> julieng:  I think I've done a small mistake somewhere, because I can see only around 100 node with interrupts property. So, they should fit
Jul 16 13:43:40 <julieng> embden[m]: interrupts property may contain one or more interrupts.
Jul 16 13:45:46 <julieng> embden[m]: So it is quite possible to have exhaust the number of GIC interrupts.
Jul 16 13:46:09 <embden[m]> julieng:  what is the format of the additional interrupts? and how to deal with it?
Jul 16 13:47:08 <julieng> embden[m]: For the device linked to the GIC interrupts property will look like <int1 int1 int1 int2 int2 int2...>
Jul 16 13:47:15 <julieng> So 3 cells per interrupt
Jul 16 13:47:50 <julieng> We discussed about the meaning of each cells yesterday.
Jul 16 13:48:01 <julieng> The code in Xen is already able to cater with that.
Jul 16 13:48:15 <julieng> Now the problem is whether we want to route all the interrupts while building Xen.
Jul 16 13:48:32 <julieng> As the number of GIC interrupts is limited, it might be wiser to dynamically configure the routing.
Jul 16 13:49:31 <julieng> embden[m]: But before looking at this problem, I would try to make sure the UART is up and running so you can validate your crossbar driver is doing the right thing.
Jul 16 14:30:22 <embden[m]> julieng: I've just count - there are 175 different interrupts in the dt
Jul 16 14:30:54 <embden[m]> hm, wait
Jul 16 14:32:50 <embden[m]> yes, 175
Jul 16 14:53:52 <julieng> embden[m]: But the crossbar can only route 160 interrupts (see ti,max-irqs property).
Jul 16 14:54:36 <embden[m]> julieng:  so, I just mapped all the interrupts after 160 to 159th line
Jul 16 14:55:15 <embden[m]> though, it is a terrible idea probably because in the last 15 interrupts there are irqs from  mmu
Jul 16 15:49:26 <julieng> embden[m]: I don't think we can all statically route interrupts in the crossbar. We will have to do some of them (any interrupts routed to Dom0) dynamically so the domain can decide what it wants to use.
Jul 16 15:58:49 <embden[m]> julieng:  So, I tried to map only enabled devices. But it doesn't respond to triple Ctrl+A
Jul 16 15:59:07 <embden[m]> and doesn't boot dom0
Jul 16 16:02:05 <embden[m]> https://github.com/embeddedden/xen/commit/e16a32cfa7abb895c39e8bcffb05d30d4b9533b0
Jul 16 16:12:08 <julieng> embden[m]: Your function crossbar_translate doesn't look correct to me.
Jul 16 16:13:06 <julieng> Particularly these 2 lines:
Jul 16 16:13:09 <julieng> +    writel(max_busy_irq_number+1,
Jul 16 16:13:11 <julieng> +           base_ctrl+max_busy_irq_number*4);
Jul 16 16:13:23 <julieng> I would have expected you have the crossbar interrupt ID in hand.
Jul 16 16:14:37 <julieng> But here you seem to increment an index and then write this into the crossbar.
Jul 16 16:18:08 <julieng> embden[m]: Can you explain why you are doing this?
Jul 16 16:21:37 <embden[m]> julieng:  yes, I also got to this conclusion
Jul 16 16:21:47 <embden[m]> So, working on it right now
Jul 16 16:23:13 <embden[m]> (to the conclusion that something really wrong with the function)
Jul 16 17:05:59 <embden[m]> .julieng  am I right that I can write on byte-aligned addresses? or should the addresses be aligned to 4-byte boundary?
Jul 16 17:07:56 <julieng> The alignment should match the size you write. IOW, if you write a 32-bit value then it should be 32-bit aligned.
Jul 16 17:08:32 <julieng> Xen on Arm32 has been configured to check the alignment. So it will throw you an error if you don't align properly
Jul 16 17:10:43 <embden[m]> ok, thank you
Jul 16 17:26:06 <pratimugale[m]> zeekhuge abhishek_ I am unable to correctly send interrupt to PRU1 after PRU0 completes sending pulses to the motor-driver.
Jul 16 17:26:10 <pratimugale[m]> PRU0 firmware: https://github.com/pratimugale/PRUSS-Bindings/blob/sandbox/examples/firmware_examples/example7-stepper-control/PRU0/main_pru0.c
Jul 16 17:26:46 <pratimugale[m]> PRU1: https://github.com/pratimugale/PRUSS-Bindings/blob/sandbox/examples/firmware_examples/example7-stepper-control/PRU1/main.c
Jul 16 17:28:06 <embden[m]> julieng:  https://github.com/embeddedden/xen/commit/7644806dd38a71a8770b80bfd8d0717af72a9eae
Jul 16 17:28:07 <embden[m]> now it switches on triple Ctrl+A !
Jul 16 17:28:32 <julieng> embden[m]: Congrats!
Jul 16 17:29:51 <embden[m]> julieng:  I will continue to work on it tomorrow and also will push that old patch about switching to hyp mode
Jul 16 17:34:32 <pratimugale[m]> zeekhuge:  The interrupt works correctly if is is triggered (and configured) before the start() statement https://github.com/pratimugale/PRUSS-Bindings/blob/6170bc64c43f722b11f4d2f67083107e986fa3e1/examples/firmware_examples/example7-stepper-control/PRU0/main_pru0.c#L40
Jul 16 17:36:05 <pratimugale[m]> i.e. if configIntc() and PRU0_PRU1_TRIGGER are executed before start()
Jul 16 17:36:42 * zeekhuge[m] trying to go through pratimugale 's code
Jul 16 17:37:16 <zeekhuge[m]> Okay, so I think its that classical confusion.
Jul 16 17:37:41 <zeekhuge[m]> pratimugale: So, do you know that PRU interrupts don't really interrupt ?
Jul 16 17:38:24 <pratimugale[m]> Yes
Jul 16 17:39:10 <pratimugale[m]> I have read about it
Jul 16 17:40:32 <zeekhuge[m]> So, what the problem exactly  then ? Can you please elaborate ?
Jul 16 17:41:16 <pratimugale[m]> <zeekhuge[m] "Okay, so I think its that classi"> about how PRU doesn't support asynchronous interrupts and uses specialized instructions for polling of events
Jul 16 17:42:01 <pratimugale[m]> zeekhuge: I want to interrupt PRU1 once PRU0 is done sending its pulses
Jul 16 17:42:42 <pratimugale[m]> After which PRU1 will notify the ARM through rpmsg channel
Jul 16 17:42:58 <pratimugale[m]> So that multiple commands aren't sent to the stepper motor at once
Jul 16 17:47:38 <pratimugale[m]> The linux side will wait until it gets the message from pru
Jul 16 17:47:55 <pranav_kumar[m]> zeekhuge: i am able to run the program correctly and also some little suggestion on the pins that i should use for now to remove the high frequency signal which i encounter during my test on the logic analyzer . i get on my problem solved thanks from @zmatt in the #beagle irc grp . I had implemented that liittle bit  can see the updated code :
Jul 16 17:47:55 <pranav_kumar[m]> https://github.com/pranav083/pocket_beagle-work/blob/wip/pru_wip/74hc299_10_v1.p in here . Now changing all the pins which lies in p8_07-19 as it does not conflicts with the eMMC as suggested by @zmatt
Jul 16 18:03:59 <zeekhuge[m]> pratimugale: You are using HOST1 for both the rpmsg and pru0-to-pru1 ?
Jul 16 18:07:06 <zeekhuge[m]> pratimugale: yes ?
Jul 16 18:07:48 <zeekhuge[m]> rpmsg uses same host1 for the interrupt events
Jul 16 18:07:54 <zeekhuge[m]> and your configuration maps the pru0-to-pru1 interrupt to host1 as well.
Jul 16 18:08:08 <pratimugale[m]> yes
Jul 16 18:08:09 <zeekhuge[m]> that's what it seems like
Jul 16 18:08:59 <zeekhuge[m]> pratimugale: You will have to use different hosts : https://github.com/ZeekHuge/BeagleScope/blob/master/examples/firmware_exmples/pru1_to_pru0_to_arm/main_pru0.c#L50
Jul 16 18:09:21 <pratimugale[m]> zeekhuge: im having dinner, will look into it in 5 mins
Jul 16 18:09:28 <zeekhuge[m]> sure.
Jul 16 18:11:51 <pranav_kumar[m]> @zeekhuge can you suggest any thing why i am getting voltage drop when logic is high on the I/O pins of the shift register which is only 2.6v   for the high logic . All the circuit is powered by beaglebone only
Jul 16 18:13:49 <zeekhuge[m]> pranav_kumar: why do you need the shift register ?
Jul 16 18:16:44 <pranav_kumar[m]> just to do bidirctional async communication between multiple devices without getting much effected by thier operating frequency.
Jul 16 18:17:26 <zeekhuge[m]> pranav_kumar: what are *.p file ? They are the assembly files, right ? when why not use .asm as the extension ? (allows for auto code highlighting, and easily readable). Also, why are their so many *.bin files ? Use ".gitignore" to prevent them from getting commited.
Jul 16 18:18:44 <pranav_kumar[m]> ok i will remove all those *.bin file .Thanks for the suggestion
Jul 16 18:23:24 <zeekhuge[m]> pranav_kumar: I can't be sure about lower voltage, but I'd suggest to use an adpater to power BBB instead of using laptop/system
Jul 16 18:23:56 <zeekhuge[m]> s/adpater/adapter
Jul 16 18:25:53 <pratimugale[m]> zeekhuge: I get it now, will update after trying to use different hosts
Jul 16 18:26:41 <zeekhuge[m]> pratimugale: great.
Jul 16 18:27:20 <pranav_kumar[m]> ok , i will get 5v dc adapter for the market tommorow.
Jul 16 18:29:32 <zeekhuge[m]> btw, make sure you are careful with BBB gpios. They can source something like 8mA only.
Jul 16 18:30:15 <zeekhuge[m]> pranav_kumar: ^
Jul 16 18:31:26 <pranav_kumar[m]> <zeekhuge[m] "pranav_kumar: ^"> i have studied somewhere that it can give only 4mA of power through the GPIO pins. Probably in the derek molloy lectures i guess
Jul 16 18:32:16 <zeekhuge[m]> okay. Then believe on 4mA thing
Jul 16 18:32:44 <pranav_kumar[m]> though i pass all my logic through the logic level converter . so , i dont think i would be a big problem for me.
Jul 16 18:35:27 <pranav_kumar[m]> as the shift register runs on 5v logic . And it is a bidirectional logic level converter. that is this TXB0108 ic
**** ENDING LOGGING AT Wed Jul 17 02:59:57 2019