**** BEGIN LOGGING AT Tue Feb 23 03:00:05 2021
Feb 23 07:39:21 <mckoan> good morning
Feb 23 12:26:23 <Crofton|cloud> once upong a time, there would be a tarball of kernel modules in the deploy dir. I need such a thing for a quck test, but it isn't there. ANy idea if it is still a thing and what controls it?
Feb 23 12:36:13 * Crofton|cloud prods zeddii 
Feb 23 13:01:48 <likewise> Crofton|cloud: hi. Maybe the tarball is created only when you build an image? I remember it was there in my ZCU102 project at the end.
Feb 23 13:02:19 <Crofton|cloud> Hi liethanks for the help
Feb 23 13:02:27 <Crofton|cloud> Looks like there is a variable MODULE_TARBALL_DEPLOY
Feb 23 13:03:06 <Crofton|cloud> hmm, and setting it not sticking from local.conf ....
Feb 23 13:03:44 <Crofton|cloud> The 102 boots fine now, once I realized that for once xilinx decided to change psu_init config at runtime :)
Feb 23 13:04:28 <Crofton|cloud> Now I am at the phase of getting the evil vendor kernel to boot with the zcu102 board
Feb 23 13:04:50 <Crofton|cloud> basically trying to get some people setup for fpga and driver dev on a 102 instead of expensive real hardware
Feb 23 14:11:41 <likewise> Crofton|cloud: could you find the piece of code where the run-time decision was made for the DDR? I could not find it?
Feb 23 14:12:38 <likewise> evil vendor as in X? It boots here.
Feb 23 14:14:18 <Crofton|cloud> I didn't look, made new psu... files from the note
Feb 23 14:15:05 <Crofton|cloud> I took the kernel Image from the other board and tried it with the 102 device tree, not loading mmc stuff
Feb 23 14:15:33 <Crofton|cloud> I need to think about a couple of approaches to get a dev env together
Feb 23 14:15:57 <Crofton|cloud> complicated by the hardware I need to deploy to uses an old kernel
Feb 23 14:17:03 <Crofton|cloud> so many kernels, so little time
**** ENDING LOGGING AT Wed Feb 24 03:02:58 2021