GSoC PRU: AM35xx Clock driver
Nils Hölscher
nilhoel1 at gmail.com
Fri Aug 9 13:42:59 UTC 2019
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 my Output attached.
The prints print the linkpass list and the link list and some other parts.
At the bottom you can also see the pruss device in /dev.
I will create a patch right away.
Best,
Nils
On Wed, 7 Aug 2019 at 11:35, Nils Hölscher <nilhoel1 at gmail.com> wrote:
> 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:
> https://github.com/RTEMS/rtems-libbsd/blob/f60ac53420f36060c13104f9a555f39ebc619b09/freebsd/sys/kern/subr_bus.c#L969
> The function BUS_NEW_PASS initialises a pass over fdt with all drivers of
> the current pass level.
>
> However after trying to add another pass, I realized that all drivers are
> on the DEFAULT_PASS_LEVEL (max_integer).
>
> Best and thanks,
> Nils
>
> On Thu, 1 Aug 2019 at 11:36, Christian Mauderer <
> christian.mauderer at embedded-brains.de> wrote:
>
>> 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 or some other kind of debugger for
>> embedded work. In a professional work environment you should try to
>> convince your boss that it is a big time saver (which is definitively
>> true) so that even an expensive debugger is a good investment
>>
>> By the way: For understanding the initialization sequence you might can
>> use a simulator too. For the basic sequence you can simulate any BSP and
>> are not bound to BBB.
>>
>> > With BUS_DEBUG enabled I saw that the problem is indeed that the pruss
>> > unit is discovered too early.
>> > Is this device tree related?
>>
>> It's possible that this is a difference in how modules are handled. I'm
>> not sure whether FreeBSD loads EARLY_MODULES dynamically at another time
>> during boot while we link everything in from the start. If that is true,
>> the mechanism might not work the same like in FreeBSD. You might want to
>> have a look at that.
>>
>> >
>> > I am not sure, cause the overlay I am using is from the BSD community.
>> >
>> > I added my output to a gist and link to the interesting parts.
>> > The EARLY_DRIVER_MODULE's are indeed loaded first.
>> >
>> https://gist.github.com/nilhoel1/dac4b9d6b1798b97846b24162ef227e4#file-bus_debug-output-log-L125
>> > Nexus bus attaches and the driver goes over every discovered device and
>> > tries to attach the drivers in order:
>> >
>> https://gist.github.com/nilhoel1/dac4b9d6b1798b97846b24162ef227e4#file-bus_debug-output-log-L326
>> > ofwbus gets discovered:
>> >
>> https://gist.github.com/nilhoel1/dac4b9d6b1798b97846b24162ef227e4#file-bus_debug-output-log-L747
>> > Here the ti_pruss device gets discovered too early in the fdt and fails:
>> >
>> https://gist.github.com/nilhoel1/dac4b9d6b1798b97846b24162ef227e4#file-bus_debug-output-log-L904
>> >
>> > I still haven't found the loop running over fdt.
>>
>> Don't have a test environment ready so this is just from a quick glance
>> at the code. I might have missed something:
>>
>> simplebus_attach adds all child nodes from the tree to the bus:
>>
>>
>> https://git.rtems.org/rtems-libbsd/tree/freebsd/sys/dev/fdt/simplebus.c#n157
>>
>> The bus_generic_attach then loops over all children and calls their
>> probe and attach functions:
>>
>> https://git.rtems.org/rtems-libbsd/tree/freebsd/sys/kern/subr_bus.c#n3768
>>
>> Best regards
>>
>> Christian
>>
>> > And it seems that the device tree only gets one iteration.
>> > But the BSD man page for EARLY_DRIVER_MODULE states that every
>> > PASS_LEVEL has an iteration.
>> > "
>> >
>> > The *EARLY*_*DRIVER*_*MODULE*() macro allows a driver to be
>> registered for a
>> > specific pass level. The boot time probe and attach process
>> makes *_multi- _ _ple passes over the device tree_*. Certain
>> critical drivers that provide
>> > basic services needed by other devices are attach during
>> earlier passes.
>> > Most drivers are attached in a final general pass. A driver
>> that
>> > attaches during an early pass must register for a specific
>> pass level
>> > (BUS_PASS_*) via the /pass/ argument. Once a driver is
>> registered it is
>> > available to attach to devices for all subsequent passes."
>> >
>> >
>> https://www.freebsd.org/cgi/man.cgi?query=DRIVER_MODULE&sektion=9&apropos=0&manpath=FreeBSD+12.0-RELEASE+and+Ports
>> >
>> > Best,
>> > Nils
>> >
>> >
>> > On Sun, 28 Jul 2019 at 11:34, Christian Mauderer <list at c-mauderer.de
>> > <mailto:list at c-mauderer.de>> wrote:
>> >
>> > On 28/07/2019 11:22, Nils Hölscher wrote:
>> > >
>> > >
>> > > On Sat, 27 Jul 2019 at 14:34, Christian Mauderer
>> > <list at c-mauderer.de <mailto:list at c-mauderer.de>
>> > > <mailto:list at c-mauderer.de <mailto:list at c-mauderer.de>>> wrote:
>> > >
>> > > On 24/07/2019 16:53, Nils Hölscher wrote:
>> > > > Hi,
>> > > >
>> > > > @Vijay Kumar Banerjee <mailto:vijaykumar9597 at gmail.com
>> > <mailto:vijaykumar9597 at gmail.com>
>> > > <mailto:vijaykumar9597 at gmail.com
>> > <mailto:vijaykumar9597 at gmail.com>>> thanks for the
>> > > > dtb file.
>> > > > I build my file from FreeBSD master.
>> > > >
>> > > > Prcm attaches now but still after the pruss driver...:
>> > > > "
>> > > > nexus0: <RTEMS Nexus device>
>> > > > ofwbus0: <Open Firmware Device Tree> on nexus0
>> > > > simplebus0: <Flattened device tree simple bus> on ofwbus0
>> > > > *ti_pruss0: <TI Programmable Realtime Unit Subsystem> mem
>> > > > 0x4a300000-0x4a37ffff irq 20,21,22,23,24,25,26,27 on
>> simplebus0
>> > > > ti_pruss0: could not enable PRUSS clock
>> > > > device_attach: ti_pruss0 attach returned 6*
>> > > > simplebus1: <Flattened device tree simple bus> on
>> simplebus0*
>> > > > am335x_prcm0: <AM335x Power and Clock Management> mem
>> > > 0x200000-0x203fff
>> > > > on simplebus1*
>> > >
>> > > Hello Nils,
>> > >
>> > > I'm not sure about the order. But what seems a little bit odd
>> > is that
>> > > the prcm0 is found in simplebus0 while am335x_prcm0 is found
>> on
>> > > simplebus1. Maybe it's worth investigating how that order is
>> > created and
>> > > how it is handled in RTEMS.
>> > >
>> > >
>> > > Thanks for the information.
>> > > I think the way rtems initializes the bsd modules differs from
>> the way
>> > > described in the libbsd manuel.
>> > > But I will have to investigate that further.
>> > >
>> > >
>> >
>> > I'm not 100% sure but as far as I know the _modules_ should be
>> > initialized in the given order (early module prior to normal
>> module).
>> > But the device detection is something different. I think there is
>> some
>> > loop in simplebus that loops over the devices and asks every driver
>> > whether it wants to handle that device. If yes the driver can have
>> it.
>> > If no the device is unhandled.
>> >
>> > For a module that is mentioned in the device tree I would expect
>> that
>> > the order in the device tree binary is the one used. For devices
>> outside
>> > of the device tree most likely some link order is used.
>> >
>> > If you have a debugger you might want to search for the loops and
>> take a
>> > look at when they are called and how they add devices. I don't think
>> > that there are that many early modules yet that would use the device
>> > tree. So it's possible that there is some call missing that would
>> parse
>> > the device tree for early modules.
>> >
>> > >
>> > >
>> > > A general note regarding the prcm module: In RTEMS most
>> > (non-libbsd)
>> > > drivers enable their power and clocks themself. Please make
>> > sure that
>> > > the FreeBSD prcm doesn't interfere with that. Otherwise you
>> > might get
>> > > odd effects.
>> > >
>> > > Thanks I will keep that in mind.
>> > >
>> > > Best,
>> > > Nils
>> > >
>> > >
>> > > Best regards
>> > >
>> > > Christian
>> > >
>> > > > *====am335x_prcm_attach====*
>> > > > "
>> > > >
>> > > > Is there anything else I can do besides using
>> MODULE_DEPENDENCY,
>> > > which I
>> > > > already use.
>> > > > The prcm module is also a EARLY_DRIVER_MODULE.
>> > > >
>> > > > Best,
>> > > > Nils
>> > > >
>> > > > On Wed, 24 Jul 2019 at 16:04, Vijay Kumar Banerjee
>> > > > <vijaykumar9597 at gmail.com <mailto:vijaykumar9597 at gmail.com>
>> > <mailto:vijaykumar9597 at gmail.com <mailto:vijaykumar9597 at gmail.com>>
>> > > <mailto:vijaykumar9597 at gmail.com
>> > <mailto:vijaykumar9597 at gmail.com> <mailto:vijaykumar9597 at gmail.com
>> > <mailto:vijaykumar9597 at gmail.com>>>>
>> > > wrote:
>> > > >
>> > > >
>> > > >
>> > > > On Wed, Jul 24, 2019 at 7:03 PM Nils Hölscher
>> > > <nilhoel1 at gmail.com <mailto:nilhoel1 at gmail.com>
>> > <mailto:nilhoel1 at gmail.com <mailto:nilhoel1 at gmail.com>>
>> > > > <mailto:nilhoel1 at gmail.com <mailto:nilhoel1 at gmail.com>
>> > <mailto:nilhoel1 at gmail.com <mailto:nilhoel1 at gmail.com>>>> wrote:
>> > > >
>> > > >
>> > > >
>> > > > On Wed, 24 Jul 2019 at 15:14, Vijay Kumar Banerjee
>> > > > <vijaykumar9597 at gmail.com
>> > <mailto:vijaykumar9597 at gmail.com>
>> > > <mailto:vijaykumar9597 at gmail.com
>> > <mailto:vijaykumar9597 at gmail.com>> <mailto:vijaykumar9597 at gmail.com
>> > <mailto:vijaykumar9597 at gmail.com>
>> > > <mailto:vijaykumar9597 at gmail.com
>> > <mailto:vijaykumar9597 at gmail.com>>>> wrote:
>> > > >
>> > > >
>> > > >
>> > > >
>> > > > On Wed, Jul 24, 2019 at 6:36 PM Nils Hölscher
>> > > > <nilhoel1 at gmail.com <mailto:nilhoel1 at gmail.com>
>> > <mailto:nilhoel1 at gmail.com <mailto:nilhoel1 at gmail.com>>
>> > > <mailto:nilhoel1 at gmail.com <mailto:nilhoel1 at gmail.com>
>> > <mailto:nilhoel1 at gmail.com <mailto:nilhoel1 at gmail.com>>>> 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 (!ofw_bus_status_okay(dev)){
>> > > > printk("ofw_bus_status_not_okay\n");
>> > > > return (ENXIO);
>> > > > }
>> > > >
>> > > > Do you get the "ofw_bus_status_not_okay" print
>> ?
>> > > >
>> > > > Yes. But I also see the other print. except the
>> > success one.
>> > > >
>> > > > if (ofw_bus_is_compatible(dev,
>> > "ti,am3-prcm")) {
>> > > > device_set_desc(dev, "AM335x Power
>> > and Clock
>> > > > Management");
>> > > > printk("PROBE SUCESSFULL\n");
>> > > > return(BUS_PROBE_DEFAULT);
>> > > > }
>> > > > printk("ofw_bus incompatible\n");
>> > > > return (ENXIO);
>> > > > }
>> > > > "
>> > > > So it seems the prcm part in the device tree
>> > has to be
>> > > > compatible to "ti,am3-prcm".
>> > > > The thing is the decompiled device tree
>> states
>> > > just that:
>> > > > "
>> > > > prcm at 0 {
>> > > > compatible =
>> > > > "ti,am3-prcm\0simple-bus";
>> > > >
>> > > > In my device tree, it runs successfully and the
>> > decompiled
>> > > > compatible looks like :
>> > > > ```
>> > > > prcm at 200000 {
>> > > > compatible = "ti,am3-prcm";
>> > > > reg = < 0x200000 0x4000 >;
>> > > > linux,phandle = < 0x4a >;
>> > > > phandle = < 0x4a >;
>> > > > ```
>> > > >
>> > > > OK, this is awkward, cause we both should have used
>> > the same
>> > > > sources.
>> > > >
>> > > > Have you checked that your source is from the tree
>> > matching the
>> > > > libBSD HEAD
>> > > > commit?
>> > > >
>> > > > reg = <0x00 0x2000>;
>> > > > #address-cells =
>> <0x01>;
>> > > > #size-cells =
>> <0x01>;
>> > > > ranges = <0x00 0x00
>> > 0x2000>;
>> > > > phandle = <0x5a>;
>> > > > [...]
>> > > > "
>> > > > Any ideas would help, cause I am currently
>> > not able to
>> > > > understand this behaviour.
>> > > > Also without this driver even the
>> > dev_usb_bbb driver
>> > > > shouldn't work.
>> > > > However it attaches because it doesn't check
>> > for the
>> > > > clocks error code.
>> > > >
>> > > > I remember testing this a few days ago for my fb
>> > > drivers and
>> > > > it was attaching alright,
>> > > > if I remember correctly. If changing the dtb
>> > doesn't work
>> > > > for you, I won't mind checking
>> > > > again, this will give me a hint for the display
>> > issue
>> > > as well.
>> > > >
>> > > > I will keep you updated on this.
>> > > > Would you be so kind and send me your compiled
>> > device tree?
>> > > >
>> > > > Please find it attached in this mail.
>> > > >
>> > > > Note: I have removed the devel from the cc because the
>> > attachment
>> > > > might be
>> > > > big for the list. Please continue the discussion in the
>> > > mailing list
>> > > > and maybe note
>> > > > it somewhere that you already received the dtb from me
>> in
>> > > private mail.
>> > > >
>> > > > Regards,
>> > > > Vijay
>> > > >
>> > > >
>> > > >
>> > > > Best,
>> > > > Nils
>> > > >
>> > > >
>> > > >
>> > > > On Wed, 24 Jul 2019 at 14:43, Nils Hölscher
>> > > > <nilhoel1 at gmail.com
>> > <mailto:nilhoel1 at gmail.com> <mailto:nilhoel1 at gmail.com
>> > <mailto:nilhoel1 at gmail.com>>
>> > > <mailto:nilhoel1 at gmail.com <mailto:nilhoel1 at gmail.com>
>> > <mailto:nilhoel1 at gmail.com <mailto:nilhoel1 at gmail.com>>>> wrote:
>> > > >
>> > > > 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
>> > > > <nilhoel1 at gmail.com
>> > <mailto:nilhoel1 at gmail.com>
>> > > <mailto:nilhoel1 at gmail.com <mailto:nilhoel1 at gmail.com>>
>> > <mailto:nilhoel1 at gmail.com <mailto:nilhoel1 at gmail.com>
>> > > <mailto:nilhoel1 at gmail.com <mailto:nilhoel1 at gmail.com>>>>
>> wrote:
>> > > >
>> > > > 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:
>> > > >
>> > >
>> >
>> https://github.com/RTEMS/rtems-libbsd/blob/610349693dd31d8b0efd33776516b7187cc5cda2/freebsd/sys/arm/ti/am335x/am335x_prcm.c
>> > > >
>> > > > Can anyone tell me how to load this
>> > driver and
>> > > > obisouly before I initialize my BSD
>> > modules?
>> > > >
>> > > > FYI: The code line that fails is
>> > this one,
>> > > cause
>> > > > the driver hasn't been initialized.
>> > > >
>> > >
>> >
>> https://github.com/RTEMS/rtems-libbsd/blob/610349693dd31d8b0efd33776516b7187cc5cda2/freebsd/sys/arm/ti/am335x/am335x_prcm.c#L854
>> > > >
>> > > > Thanks,
>> > > > Nils
>> > > >
>> > > >
>> _______________________________________________
>> > > > devel mailing list
>> > > > devel at rtems.org <mailto:devel at rtems.org>
>> > <mailto:devel at rtems.org <mailto:devel at rtems.org>>
>> > > <mailto:devel at rtems.org <mailto:devel at rtems.org>
>> > <mailto:devel at rtems.org <mailto:devel at rtems.org>>>
>> > > >
>> http://lists.rtems.org/mailman/listinfo/devel
>> > > >
>> > > >
>> > > > _______________________________________________
>> > > > devel mailing list
>> > > > devel at rtems.org <mailto:devel at rtems.org>
>> > <mailto:devel at rtems.org <mailto:devel at rtems.org>>
>> > > > http://lists.rtems.org/mailman/listinfo/devel
>> > > >
>> > >
>> >
>> >
>> > _______________________________________________
>> > devel mailing list
>> > devel at rtems.org
>> > http://lists.rtems.org/mailman/listinfo/devel
>> >
>>
>> --
>> --------------------------------------------
>> embedded brains GmbH
>> Herr Christian Mauderer
>> Dornierstr. 4
>> D-82178 Puchheim
>> Germany
>> email: christian.mauderer at embedded-brains.de
>> Phone: +49-89-18 94 741 - 18
>> Fax: +49-89-18 94 741 - 08
>> PGP: Public key available on request.
>>
>> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20190809/940e2525/attachment-0002.html>
-------------- next part --------------
Skript gestartet auf 2019-08-09 15:33:21+02:00 [TERM="xterm-256color" TTY="/dev/pts/2" COLUMNS="238" LINES="27"]
]0;nils at nils-Laptop:~/Downloads[nils at nils-Laptop Downloads]$ beagleserial
[sudo] Passwort f眉r nils:
picocom v3.1
port is : /dev/ttyUSB0
flowcontrol : none
baudrate is : 115200
parity is : none
databits are : 8
stopbits are : 1
escape is : C-a
local echo is : no
noinit is : no
noreset is : no
hangup is : no
nolock is : no
send_cmd is : sz -vv
receive_cmd is : rz -vv -E
imap is :
omap is :
emap is : crcrlf,delbs,
logfile is : none
initstring : none
exit_after is : not set
exit is : no
Type [C-a] [C-h] to see available commands
Terminal ready
FATAL: read zero bytes from port
term_exitfunc: reset failed for dev UNKNOWN: Input/output error
]0;nils at nils-Laptop:~/Downloads[nils at nils-Laptop Downloads]$ beagleserial
picocom v3.1
port is : /dev/ttyUSB0
flowcontrol : none
baudrate is : 115200
parity is : none
databits are : 8
stopbits are : 1
escape is : C-a
local echo is : no
noinit is : no
noreset is : no
hangup is : no
nolock is : no
send_cmd is : sz -vv
receive_cmd is : rz -vv -E
imap is :
omap is :
emap is : crcrlf,delbs,
logfile is : none
initstring : none
exit_after is : not set
exit is : no
Type [C-a] [C-h] to see available commands
Terminal ready
U-Boot SPL 2019.04-00002-gc8b5ad3a1f (Apr 16 2019 - 09:21:31 -0500)
Trying to boot from MMC2
Loading Environment from EXT4...
** Unable to use mmc 0:1 for loading the env **
U-Boot 2019.04-00002-gc8b5ad3a1f (Apr 16 2019 - 09:21:31 -0500), Build: jenkins-github_Bootloader-Builder-116
CPU : AM335X-GP rev 2.1
I2C: ready
DRAM: 512 MiB
No match for driver 'omap_hsmmc'
No match for driver 'omap_hsmmc'
Some drivers were not found
Reset Source: Power-on reset has occurred.
RTC 32KCLK Source: External.
MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1
Loading Environment from EXT4...
** Unable to use mmc 0:1 for loading the env **
Board: BeagleBone Black
<ethaddr> not set. Validating first E-fuse MAC
BeagleBone Black:
BeagleBone: cape eeprom: i2c_probe: 0x54:
BeagleBone: cape eeprom: i2c_probe: 0x55:
BeagleBone: cape eeprom: i2c_probe: 0x56:
BeagleBone: cape eeprom: i2c_probe: 0x57:
Net: eth0: MII MODE
cpsw, usb_ether
Press SPACE to abort autoboot in 2 seconds
board_name=[A335BNLT] ...
board_rev=[00C0] ...
switch to partitions #0, OK
mmc0 is current device
SD/MMC found on device 0
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
51485 bytes read in 7 ms (7 MiB/s)
gpio: pin 56 (gpio 56) value is 0
gpio: pin 55 (gpio 55) value is 0
gpio: pin 54 (gpio 54) value is 0
gpio: pin 53 (gpio 53) value is 1
switch to partitions #0, OK
mmc0 is current device
gpio: pin 54 (gpio 54) value is 1
Checking for: /uEnv.txt ...
560 bytes read in 3 ms (181.6 KiB/s)
gpio: pin 55 (gpio 55) value is 1
Loaded environment from /uEnv.txt
Importing environment from mmc ...
Checking if uenvcmd is set ...
gpio: pin 56 (gpio 56) value is 1
Running uenvcmd ...
RTEMS u-boot-beaglebone (arm-ti-am335x_evm)
rtems-boot-image v5.0.not_released
Loading pru.exe.img
1876948 bytes read in 123 ms (14.6 MiB/s)
Loading am335x-boneblack.dtb
51485 bytes read in 6 ms (8.2 MiB/s)
Loading AM335X-PRU-UIO-00A0.dtbo
883 bytes read in 2 ms (430.7 KiB/s)
Applying fdt overlay
## Booting kernel from Legacy Image at 82000000 ...
Image Name: RTEMS
Created: 2019-08-09 13:31:03 UTC
Image Type: ARM Linux Kernel Image (gzip compressed)
Data Size: 1876884 Bytes = 1.8 MiB
Load Address: 80000000
Entry Point: 80000000
Verifying Checksum ... OK
## Flattened Device Tree blob at 88000000
Booting using the fdt blob at 0x88000000
Uncompressing Kernel Image ... OK
Loading Device Tree to 8ff8b000, end 8fffffff ... OK
Starting kernel ...
RTEMS Beagleboard: am335x-based
ARM Debug: 0x4b141000
RTEMS BBB PRU Tester
========== passlink List ==========
Name: nexus, Pass: 10
Name: simplebus, Pass: 15
Name: uhub, Pass: 2147483647
========== link List ==========
DevClass: root, Maxunit: 4, ParentClass: NULL
DevClass: nexus, Maxunit: 4, ParentClass: NULL
DevClass: usbus, Maxunit: 0, ParentClass: NULL
DevClass: uhub, Maxunit: 0, ParentClass: NULL
DevClass: simplebus, Maxunit: 0, ParentClass: NULL
DevClass: ti_pruss, Maxunit: 0, ParentClass: NULL
DevClass: ti_scm, Maxunit: 0, ParentClass: NULL
DevClass: sdhci_ti, Maxunit: 0, ParentClass: NULL
DevClass: mmc, Maxunit: 0, ParentClass: NULL
DevClass: ofwbus, Maxunit: 0, ParentClass: simplebus
DevClass: iicbus, Maxunit: 0, ParentClass: NULL
DevClass: iic, Maxunit: 0, ParentClass: NULL
DevClass: usbss, Maxunit: 0, ParentClass: simplebus
DevClass: musbotg, Maxunit: 0, ParentClass: NULL
DevClass: iichb, Maxunit: 0, ParentClass: NULL
DevClass: miibus, Maxunit: 0, ParentClass: NULL
DevClass: ukphy, Maxunit: 0, ParentClass: NULL
DevClass: mmcsd, Maxunit: 0, ParentClass: NULL
DevClass: am335x_prcm, Maxunit: 0, ParentClass: NULL
DevClass: rtwn, Maxunit: 0, ParentClass: NULL
DevClass: saf1761otg, Maxunit: 0, ParentClass: NULL
DevClass: dwcotg, Maxunit: 0, ParentClass: NULL
DevClass: octusb, Maxunit: 0, ParentClass: NULL
DevClass: uss820dci, Maxunit: 0, ParentClass: NULL
DevClass: xhci, Maxunit: 0, ParentClass: NULL
DevClass: ehci, Maxunit: 0, ParentClass: NULL
DevClass: uhci, Maxunit: 0, ParentClass: NULL
DevClass: ohci, Maxunit: 0, ParentClass: NULL
DevClass: cpsw, Maxunit: 0, ParentClass: NULL
DevClass: rtems_i2c, Maxunit: 0, ParentClass: NULL
DevClass: umass, Maxunit: 0, ParentClass: NULL
DevClass: cpswss, Maxunit: 0, ParentClass: NULL
DevClass: gpio, Maxunit: 0, ParentClass: NULL
DevClass: gpiobus, Maxunit: 0, ParentClass: NULL
DevClass: twsi, Maxunit: 0, ParentClass: NULL
DevClass: iicbb, Maxunit: 0, ParentClass: NULL
========== First Pass ==========
==== CurrentPass: 10, Device nexus, dl->pass: 10 ===
nexus0: <RTEMS Nexus device>
========== Second Pass ==========
==== CurrentPass: 15, Device nexus, dl->pass: 10 ===
==== CurrentPass: 15, Device ofwbus, dl->pass: 15 ===
ofwbus0: <Open Firmware Device Tree> on nexus0
simplebus0: <Flattened device tree simple bus> on ofwbus0
simplebus1: <Flattened device tree simple bus> on simplebus0
am335x_prcm0: <AM335x Power and Clock Management> mem 0x200000-0x203fff on simplebus1
simplebus2: <Flattened device tree simple bus> mem 0x210000-0x211fff on simplebus1
ti_scm0: <TI Control Module> mem 0-0x7ff on simplebus2
==== CurrentPass: 2147483647, Device nexus, dl->pass: 10 ===
==== CurrentPass: 2147483647, Device ofwbus, dl->pass: 15 ===
==== CurrentPass: 2147483647, Device simplebus, dl->pass: 10 ===
==== CurrentPass: 2147483647, Device ti_pruss, dl->pass: 2147483647 ===
==== CurrentPass: 2147483647, Device ti_scm, dl->pass: 10 ===
==== CurrentPass: 2147483647, Device sdhci_ti, dl->pass: 2147483647 ===
==== CurrentPass: 2147483647, Device simplebus, dl->pass: 15 ===
==== CurrentPass: 2147483647, Device am335x_prcm, dl->pass: 10 ===
==== CurrentPass: 2147483647, Device usbss, dl->pass: 2147483647 ===
==== CurrentPass: 2147483647, Device rtems_i2c, dl->pass: 2147483647 ===
==== CurrentPass: 2147483647, Device cpswss, dl->pass: 2147483647 ===
ti_pruss0: <TI Programmable Realtime Unit Subsystem> mem 0x4a300000-0x4a37ffff irq 20,21,22,23,24,25,26,27 on simplebus0
ti_pruss0: AM33xx PRU-ICSS
==== CurrentPass: 2147483647, Device ti_pruss, dl->pass: 2147483647 ===
==== CurrentPass: 2147483647, Device ti_scm, dl->pass: 10 ===
==== CurrentPass: 2147483647, Device sdhci_ti, dl->pass: 2147483647 ===
==== CurrentPass: 2147483647, Device simplebus, dl->pass: 15 ===
==== CurrentPass: 2147483647, Device am335x_prcm, dl->pass: 10 ===
==== CurrentPass: 2147483647, Device usbss, dl->pass: 2147483647 ===
==== CurrentPass: 2147483647, Device rtems_i2c, dl->pass: 2147483647 ===
==== CurrentPass: 2147483647, Device cpswss, dl->pass: 2147483647 ===
am335x_prcm0: Clocks: System 24.0 MHz, CPU 1000 MHz
==== CurrentPass: 2147483647, Device ti_pruss, dl->pass: 2147483647 ===
==== CurrentPass: 2147483647, Device ti_scm, dl->pass: 10 ===
==== CurrentPass: 2147483647, Device sdhci_ti, dl->pass: 2147483647 ===
==== CurrentPass: 2147483647, Device simplebus, dl->pass: 15 ===
==== CurrentPass: 2147483647, Device am335x_prcm, dl->pass: 10 ===
==== CurrentPass: 2147483647, Device usbss, dl->pass: 2147483647 ===
==== CurrentPass: 2147483647, Device rtems_i2c, dl->pass: 2147483647 ===
==== CurrentPass: 2147483647, Device cpswss, dl->pass: 2147483647 ===
sdhci_ti0: <TI MMCHS (SDHCI 2.0)> mem 0x48060000-0x48060fff irq 64 on simplebus0
mmc0: <MMC/SD bus> on sdhci_ti0
sdhci_ti1: <TI MMCHS (SDHCI 2.0)> mem 0x481d8000-0x481d8fff irq 28 on simplebus0
mmc1: <MMC/SD bus> on sdhci_ti1
usbss0: <TI AM33xx integrated USB OTG controller> mem 0x47400000-0x47400fff on simplebus0
usbss0: TI AM335X USBSS v0.0.13
musbotg0: <TI AM33xx integrated USB OTG controller> mem 0x47401400-0x474017ff,0x47401000-0x474011ff irq 18 on usbss0
usbus0: Dynamic FIFO sizing detected, assuming 16Kbytes of FIFO RAM
usbus0 on musbotg0
musbotg1: <TI AM33xx integrated USB OTG controller> mem 0x47401c00-0x47401fff,0x47401800-0x474019ff irq 19 on usbss0
usbus1: Dynamic FIFO sizing detected, assuming 16Kbytes of FIFO RAM
usbus1 on musbotg1
cpswss0: <3-port Switch Ethernet Subsystem> mem 0x4a100000-0x4a1007ff,0x4a101200-0x4a1012ff irq 40,41,42,43 on simplebus0
cpswss0: CPSW SS Version 1.12 (0)
cpswss0: Initial queue size TX=128 RX=384
cpsw0: <Ethernet Switch Port> on cpswss0
miibus0: <MII bus> on cpsw0
ukphy0: <Generic IEEE 802.3u media interface> PHY 0 on miibus0
ukphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
info: cpsw0: Ethernet address: 74:e1:82:73:a0:89
mmcsd0: 4GB <SDHC 0.2 SN 00338E00 MFG 05/2017 by 158 BE> at mmc0 48.0MHz/4bit/65535-block
sdhci_ti1-slot0: Controller never released inhibit bit(s).
sdhci_ti1-slot0: ============== REGISTER DUMP ==============
sdhci_ti1-slot0: Sys addr: 0x00000000 | Version: 0x00003101
sdhci_ti1-slot0: Blk size: 0x00000004 | Blk cnt: 0x00000001
sdhci_ti1-slot0: Argument: 0x00000000 | Trn mode: 0x0000133a
sdhci_ti1-slot0: Present: 0x01f70006 | Host ctl: 0x00000002
sdhci_ti1-slot0: Power: 0x0000000d | Blk gap: 0x00000000
sdhci_ti1-slot0: Wake-up: 0x00000000 | Clock: 0x00008007
sdhci_ti1-slot0: Timeout: 0x00000006 | Int stat: 0x00108000
sdhci_ti1-slot0: Int enab: 0x017f00fb | Sig enab: 0x017f00fb
sdhci_ti1-slot0: AC12 err: 0x00000000 | Host ctl2:0x00000000
sdhci_ti1-slot0: Caps: 0x06e10080 | Caps2: 0x00000000
sdhci_ti1-slot0: Max curr: 0x00000000 | ADMA err: 0x00000000
sdhci_ti1-slot0: ADMA addr:0x00000000 | Slot int: 0x00000001
sdhci_ti1-slot0: ===========================================
sdhci_ti1-slot0: Controller never released inhibit bit(s).
sdhci_ti1-slot0: ============== REGISTER DUMP ==============
sdhci_ti1-slot0: Sys addr: 0x00000000 | Version: 0x00003101
sdhci_ti1-slot0: Blk size: 0x00000004 | Blk cnt: 0x00000001
sdhci_ti1-slot0: Argument: 0x00000000 | Trn mode: 0x0000133a
sdhci_ti1-slot0: Present: 0x01f70006 | Host ctl: 0x00000000
sdhci_ti1-slot0: Power: 0x0000000d | Blk gap: 0x00000000
sdhci_ti1-slot0: Wake-up: 0x00000000 | Clock: 0x00008007
sdhci_ti1-slot0: Timeout: 0x00000006 | Int stat: 0x00108000
sdhci_ti1-slot0: Int enab: 0x017f00fb | Sig enab: 0x017f00fb
sdhci_ti1-slot0: AC12 err: 0x00000000 | Host ctl2:0x00000000
sdhci_ti1-slot0: Caps: 0x06e10080 | Caps2: 0x00000000
sdhci_ti1-slot0: Max curr: 0x00000000 | ADMA err: 0x00000000
sdhci_ti1-slot0: ADMA addr:0x00000000 | Slot int: 0x00000001
sdhci_ti1-slot0: ===========================================
sdhci_ti1-slot0: Controller never released inhibit bit(s).
sdhci_ti1-slot0: ============== REGISTER DUMP ==============
sdhci_ti1-slot0: Sys addr: 0x00000000 | Version: 0x00003101
sdhci_ti1-slot0: Blk size: 0x00000004 | Blk cnt: 0x00000001
sdhci_ti1-slot0: Argument: 0x00000000 | Trn mode: 0x0000133a
sdhci_ti1-slot0: Present: 0x01f70006 | Host ctl: 0x00000000
sdhci_ti1-slot0: Power: 0x0000000d | Blk gap: 0x00000000
sdhci_ti1-slot0: Wake-up: 0x00000000 | Clock: 0x00008007
sdhci_ti1-slot0: Timeout: 0x00000006 | Int stat: 0x00108000
sdhci_ti1-slot0: Int enab: 0x017f00fb | Sig enab: 0x017f00fb
sdhci_ti1-slot0: AC12 err: 0x00000000 | Host ctl2:0x00000000
sdhci_ti1-slot0: Caps: 0x06e10080 | Caps2: 0x00000000
sdhci_ti1-slot0: Max curr: 0x00000000 | ADMA err: 0x00000000
sdhci_ti1-slot0: ADMA addr:0x00000000 | Slot int: 0x00000001
sdhci_ti1-slot0: ===========================================
sdhci_ti1-slot0: Controller never released inhibit bit(s).
sdhci_ti1-slot0: ============== REGISTER DUMP ==============
sdhci_ti1-slot0: Sys addr: 0x00000000 | Version: 0x00003101
sdhci_ti1-slot0: Blk size: 0x00000004 | Blk cnt: 0x00000001
sdhci_ti1-slot0: Argument: 0x00000000 | Trn mode: 0x0000133a
sdhci_ti1-slot0: Present: 0x01f70006 | Host ctl: 0x00000000
sdhci_ti1-slot0: Power: 0x0000000d | Blk gap: 0x00000000
sdhci_ti1-slot0: Wake-up: 0x00000000 | Clock: 0x00008007
sdhci_ti1-slot0: Timeout: 0x00000006 | Int stat: 0x00108000
sdhci_ti1-slot0: Int enab: 0x017f00fb | Sig enab: 0x017f00fb
sdhci_ti1-slot0: AC12 err: 0x00000000 | Host ctl2:0x00000000
sdhci_ti1-slot0: Caps: 0x06e10080 | Caps2: 0x00000000
sdhci_ti1-slot0: Max curr: 0x00000000 | ADMA err: 0x00000000
sdhci_ti1-slot0: ADMA addr:0x00000000 | Slot int: 0x00000001
sdhci_ti1-slot0: ===========================================
sdhci_ti1-slot0: Controller never released inhibit bit(s).
sdhci_ti1-slot0: ============== REGISTER DUMP ==============
sdhci_ti1-slot0: Sys addr: 0x00000000 | Version: 0x00003101
sdhci_ti1-slot0: Blk size: 0x00000004 | Blk cnt: 0x00000001
sdhci_ti1-slot0: Argument: 0x00000000 | Trn mode: 0x0000133a
sdhci_ti1-slot0: Present: 0x01f70006 | Host ctl: 0x00000000
sdhci_ti1-slot0: Power: 0x0000000d | Blk gap: 0x00000000
sdhci_ti1-slot0: Wake-up: 0x00000000 | Clock: 0x00008007
sdhci_ti1-slot0: Timeout: 0x00000006 | Int stat: 0x00108000
sdhci_ti1-slot0: Int enab: 0x017f00fb | Sig enab: 0x017f00fb
sdhci_ti1-slot0: AC12 err: 0x00000000 | Host ctl2:0x00000000
sdhci_ti1-slot0: Caps: 0x06e10080 | Caps2: 0x00000000
sdhci_ti1-slot0: Max curr: 0x00000000 | ADMA err: 0x00000000
sdhci_ti1-slot0: ADMA addr:0x00000000 | Slot int: 0x00000001
sdhci_ti1-slot0: ===========================================
mmc1: CMD6 failed, RESULT: 4
mmc1: Error setting erase group 4
sdhci_ti1-slot0: Got data interrupt 0x00100000, but there is no active data operation.
sdhci_ti1-slot0: ============== REGISTER DUMP ==============
sdhci_ti1-slot0: Sys addr: 0x00000000 | Version: 0x00003101
sdhci_ti1-slot0: Blk size: 0x00000004 | Blk cnt: 0x00000001
sdhci_ti1-slot0: Argument: 0x00000000 | Trn mode: 0x00000700
sdhci_ti1-slot0: Present: 0x01f70006 | Host ctl: 0x00000000
sdhci_ti1-slot0: Power: 0x0000000d | Blk gap: 0x00000000
sdhci_ti1-slot0: Wake-up: 0x00000000 | Clock: 0x00008007
sdhci_ti1-slot0: Timeout: 0x00000006 | Int stat: 0x00000001
sdhci_ti1-slot0: Int enab: 0x017f00fb | Sig enab: 0x017f00fb
sdhci_ti1-slot0: AC12 err: 0x00000000 | Host ctl2:0x00000000
sdhci_ti1-slot0: Caps: 0x06e10080 | Caps2: 0x00000000
sdhci_ti1-slot0: Max curr: 0x00000000 | ADMA err: 0x00000000
sdhci_ti1-slot0: ADMA addr:0x00000000 | Slot int: 0x00000001
sdhci_ti1-slot0: ===========================================
LibBSD initialized
rc.conf: loading: /etc/rc.conf
rc.conf: start: /etc/rc.conf size:136, timeout: 10
rc.conf: running
Setting hostname: bbbpru.
Starting network: lo0 cpsw0 .
rc.conf: /etc/rc.conf: ifconfig: ifconfig lo0 inet 127.0.0.1 netmask 255.0.0.0 up
rc.conf: /etc/rc.conf: ifconfig: ifconfig cpsw0
cpsw0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=8000b<RXCSUM,TXCSUM,VLAN_MTU,LINKSTATE>
ether 74:e1:82:73:a0:89
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
media: Ethernet autoselect (none)
status: no carrier
cpsw0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=8000b<RXCSUM,TXCSUM,VLAN_MTU,LINKSTATE>
ether 74:e1:82:73:a0:89
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
media: Ethernet autoselect (none)
status: no carrier
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
options=680003<RXCSUM,TXCSUM,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6>
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2
inet 127.0.0.1 netmask 0xff000000
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
groups: lo
info: lo0: link state changed to UP
info: cpsw0: link state changed to DOWN
usbus0: 480Mbps High Speed USB v2.0
usbus1: 480Mbps High Speed USB v2.0
ugen0.1: <Mentor Graphics OTG Root HUB> at usbus0
uhub0: <Mentor Graphics OTG Root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus0
ugen1.1: <Mentor Graphics OTG Root HUB> at usbus1
uhub1: <Mentor Graphics OTG Root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus1
uhub0: 1 port with 1 removable, self powered
uhub1: 1 port with 1 removable, self powered
ugen0.2: <Unknown > at usbus0 (disconnected)
Waiting 30s for default route interface: warning: no interfaces have a carrier
ugen0.2: <Unknown > at usbus0 (disconnected)
error: net /etc/rc.conf failed: Connection timed out
Starting a shell ...
[CPU:0] rtems-db: remote running
[CPU:0] rtems-db: tcp remote: listing on port: 1122
RTEMS Shell on /dev/console. Use 'help' to list commands.
SHLL [/] # ls /dev
bpf bpf0 console pruss0 ttyS0 ugen0.1 ugen1.1 usb usbctl
SHLL [/] # ugen0.2: <Unknown > at usbus0 (disconnected)
ugen0.2: <Unknown > at usbus0 (disconnected)
FATAL: read zero bytes from port
term_exitfunc: reset failed for dev UNKNOWN: Input/output error
]0;nils at nils-Laptop:~/Downloads[nils at nils-Laptop Downloads]$ exit
Skript beendet auf 2019-08-09 15:34:33+02:00 [COMMAND_EXIT_CODE="1"]
More information about the devel
mailing list