Re: GSoC PRU: AM35xx Clock driver

Hello Nils, sorry, I missed the patch on the mailing list. Best regards Christian On 09/08/2019 20:07, Nils Hölscher wrote: > Hi Christian, > > I want to thank you again, since you actually helped me a lot with this > problem. > But I already patched this problem, didn't I. > > Thanks, >

Re: GSoC PRU: AM35xx Clock driver

Hi Christian, I want to thank you again, since you actually helped me a lot with this problem. But I already patched this problem, didn't I. Thanks, Nils Christian Mauderer schrieb am Fr., 9. Aug. 2019, 19:50: > Hello Nils, > > great that you found your problem. It sounds like it is a general

Re: GSoC PRU: AM35xx Clock driver

Hello Nils, great that you found your problem. It sounds like it is a general bug in libbsd. What did you change and do you have a patch that would fix this? Best regards Christian On 09/08/2019 15:42, Nils Hölscher wrote: > Hi, > > I was able to resolve the problem. > The reason that all the

Re: GSoC PRU: AM35xx Clock driver

Hi, I was able to resolve the problem. The reason that all the devices attached in the last pass and not in the pass they were assigned, was the nexus bus being loaded as a standard driver Module. So the pass level of nexus bus was BUS_PASS_DEFAULT and all devices depend on nexus bus. Please see

Re: GSoC PRU: AM35xx Clock driver

Hi, I was able to confirm that the current libBSD implementation scans the fdt only once. caller: https://github.com/RTEMS/rtems-libbsd/blob/f60ac53420f36060c13104f9a555f39ebc619b09/freebsd/sys/kern/subr_bus.c#L5100 callee:

Re: GSoC PRU: AM35xx Clock driver

Hello Nils, On 31/07/2019 14:54, Nils Hölscher wrote: > Hi, > > I have been reading into the FreeBSD init code the past few days, > especially for Driver_MODULE. > Expect an Blog entry today or tomorrow. > > Because I don't have JTAG, it took me quite some time. I would always suggest a JTAG

Re: GSoC PRU: AM35xx Clock driver

Hi, I have been reading into the FreeBSD init code the past few days, especially for Driver_MODULE. Expect an Blog entry today or tomorrow. Because I don't have JTAG, it took me quite some time. With BUS_DEBUG enabled I saw that the problem is indeed that the pruss unit is discovered too early.

Re: GSoC PRU: AM35xx Clock driver

On 28/07/2019 11:22, Nils Hölscher wrote: > > > On Sat, 27 Jul 2019 at 14:34, Christian Mauderer > wrote: > > On 24/07/2019 16:53, Nils Hölscher wrote: > > Hi, > > > > @Vijay Kumar Banerjee

Re: GSoC PRU: AM35xx Clock driver

On Sat, 27 Jul 2019 at 14:34, Christian Mauderer wrote: > On 24/07/2019 16:53, Nils Hölscher wrote: > > Hi, > > > > @Vijay Kumar Banerjee thanks for the > > dtb file. > > I build my file from FreeBSD master. > > > > Prcm attaches now but still after the pruss

Re: GSoC PRU: AM35xx Clock driver

On 24/07/2019 16:53, Nils Hölscher wrote: > Hi, > > @Vijay Kumar Banerjee   thanks for the > dtb file. > I build my file from FreeBSD master. > > Prcm attaches now but still after the pruss driver...: > " > nexus0: > ofwbus0: on nexus0 > simplebus0: on ofwbus0

Re: GSoC PRU: AM35xx Clock driver

Hi, I just found out that the Module Dependencies don't have any influence on the initialization process. I have to look at SYSINIT and am currently reading their docs. If anyone could point me to the rtems part of this, it would be great. Best, Nils On Wed, 24 Jul 2019 at 16:53, Nils Hölscher

Re: GSoC PRU: AM35xx Clock driver

Hi, @Vijay Kumar Banerjee thanks for the dtb file. I build my file from FreeBSD master. Prcm attaches now but still after the pruss driver...: " nexus0: ofwbus0: on nexus0 simplebus0: on ofwbus0 *ti_pruss0: mem 0x4a30-0x4a37 irq 20,21,22,23,24,25,26,27 on simplebus0ti_pruss0:

Re: GSoC PRU: AM35xx Clock driver

On Wed, 24 Jul 2019 at 15:14, Vijay Kumar Banerjee wrote: > > > > On Wed, Jul 24, 2019 at 6:36 PM Nils Hölscher wrote: > >> Hi again, >> >> Hi Nils > >> I just decompiled my device tree and checked. >> The probe code of the prcm driver is as follows: >> " >> static int >>

Re: GSoC PRU: AM35xx Clock driver

On Wed, Jul 24, 2019 at 6:36 PM Nils Hölscher wrote: > Hi again, > > Hi Nils > I just decompiled my device tree and checked. > The probe code of the prcm driver is as follows: > " > static int > am335x_prcm_probe(device_t dev) > { > printk("am335x_prcm_probe\n"); > > if

Re: GSoC PRU: AM35xx Clock driver

Hi again, I just decompiled my device tree and checked. The probe code of the prcm driver is as follows: " static int am335x_prcm_probe(device_t dev) { printk("am335x_prcm_probe\n"); if (!ofw_bus_status_okay(dev)){ printk("ofw_bus_status_not_okay\n"); return (ENXIO);

Re: GSoC PRU: AM35xx Clock driver

Hi, I just found out that the prcm driver fails to probe on the simplebus and therefore cannot apply itself. Seems like I am back to checking dtb. Best, Nils On Tue, 23 Jul 2019 at 14:26, Nils Hölscher wrote: > Hi, > > After debugging with printk, didn't get the module loading working as >

GSoC PRU: AM35xx Clock driver

Hi, After debugging with printk, didn't get the module loading working as suggested by Sebastian. I just found out that my PRU driver can't be attached, cause the AM35xx clock driver isn't loaded. The driver can be found her: