linux-automation / meta-lxatac Goto Github PK

View Code? Open in Web Editor NEW

5.0 5.0 15.0 1.57 MB

Build your own LXA TAC images and bundles

License: MIT License

BitBake 88.89% Shell 11.11%

meta-lxatac's People

Contributors

Stargazers

Watchers

Forkers

hnez a3f clementperon ph5 fiurin jluebbe ejoerns userid0x0 rohieb ukleinek basicservicepeople bastian-krause emantor pengutronix-test

meta-lxatac's Issues

The avahi daemon keeps detecting hostname conflicts

We have noticed that avahi-daemon sometimes produces a lot of log output because it keeps detecting hostname conflicts:

Mar 20 11:39:29 lxatac-00015 avahi-daemon[306]: Host name conflict, retrying with lxatac-00015-30
Mar 20 11:39:29 lxatac-00015 avahi-daemon[306]: Registering new address record for 2a0a:edc0:1:2:1a74:e2ff:fea0:113 on tac-bridge.*.
Mar 20 11:39:29 lxatac-00015 avahi-daemon[306]: Registering new address record for 192.168.9.78 on tac-bridge.IPv4.
Mar 20 11:39:29 lxatac-00015 avahi-daemon[306]: Registering new address record for ::1 on lo.*.
Mar 20 11:39:29 lxatac-00015 avahi-daemon[306]: Registering new address record for 127.0.0.1 on lo.IPv4.
Mar 20 11:39:49 lxatac-00015 avahi-daemon[306]: Server startup complete. Host name is lxatac-00015-30.local. Local service cookie is 1771495564.
Mar 20 11:39:49 lxatac-00015 avahi-daemon[306]: Withdrawing address record for 192.168.9.78 on tac-bridge.
Mar 20 11:39:49 lxatac-00015 avahi-daemon[306]: Withdrawing address record for ::1 on lo.
Mar 20 11:39:49 lxatac-00015 avahi-daemon[306]: Withdrawing address record for 127.0.0.1 on lo.
Mar 20 11:39:49 lxatac-00015 avahi-daemon[306]: Host name conflict, retrying with lxatac-00015-31
Mar 20 11:39:49 lxatac-00015 avahi-daemon[306]: Registering new address record for 2a0a:edc0:1:2:1a74:e2ff:fea0:113 on tac-bridge.*.
Mar 20 11:39:49 lxatac-00015 avahi-daemon[306]: Registering new address record for 192.168.9.78 on tac-bridge.IPv4.
Mar 20 11:39:49 lxatac-00015 avahi-daemon[306]: Registering new address record for ::1 on lo.*.
Mar 20 11:39:49 lxatac-00015 avahi-daemon[306]: Registering new address record for 127.0.0.1 on lo.IPv4.
Mar 20 11:40:09 lxatac-00015 avahi-daemon[306]: Server startup complete. Host name is lxatac-00015-31.local. Local service cookie is 1771495564.
Mar 20 11:40:09 lxatac-00015 avahi-daemon[306]: Withdrawing address record for 192.168.9.78 on tac-bridge.
Mar 20 11:40:09 lxatac-00015 avahi-daemon[306]: Withdrawing address record for ::1 on lo.
Mar 20 11:40:09 lxatac-00015 avahi-daemon[306]: Withdrawing address record for 127.0.0.1 on lo.

We should find out why that is and if we even need an avahi-daemon on the TAC or if it can be replaced by systemd-resolved.

The TAC gets stuck in bootloader when connected via USB to some PCs

When connected to some host computers via the USB-C port the LXA TAC will stop the automatic boot process without an obvious reason (no key presses were performed):

…
state: Using bucket 0@0x00000000
malloc space: 0xcfdfe5e0 -> 0xdfbfcbbf (size 254 MiB)
eth0: got preset MAC address: 18:74:e2:a0:01:a0
eth1: got preset MAC address: 18:74:e2:a0:01:a1
eth2: got preset MAC address: 18:74:e2:a0:01:a2
found force-builtin environment, using defaultenv
multi_bind: creating Fastboot function
multi_bind: creating ACM function
g_multi gadget0: Multifunction Composite Gadget
g_multi gadget0: g_multi ready
dwc2 [email protected]: bound driver g_multi
dwc2 [email protected]: new address 1

Hit m for menu or any to stop autoboot:    3g_multi gadget0: high-speed config #1: Multifunction Composite Gadget
ERROR: dwc2 [email protected]: dwc2_ep_enable: No suitable fifo found

eth0: 1000Mbps full duplex link detected
barebox@Linux Automation Test Automation Controller (TAC) Gen 3:/

This is likely due to the host performing a couple of probes via USB:

Mar 26 11:04:04 havel kernel: usb 5-2: USB disconnect, device number 39
Mar 26 11:04:07 havel kernel: usb 5-2: new high-speed USB device number 40 using xhci_hcd
Mar 26 11:04:08 havel kernel: usb 5-2: New USB device found, idVendor=1d6b, idProduct=0104, bcdDevice= 6.02
Mar 26 11:04:08 havel kernel: usb 5-2: New USB device strings: Mfr=0, Product=2, SerialNumber=3
Mar 26 11:04:08 havel kernel: usb 5-2: Product: Linux Automation Test Automation Controller (TAC) Gen 3
Mar 26 11:04:08 havel kernel: usb 5-2: SerialNumber: unset
Mar 26 11:04:08 havel kernel: cdc_acm 5-2:1.1: ttyACM0: USB ACM device
Mar 26 11:04:08 havel mtp-probe[972661]: checking bus 5, device 40: "/sys/devices/pci0000:00/0000:00:08.1/0000:07:00.4/usb5/5-2"
Mar 26 11:04:08 havel mtp-probe[972661]: bus: 5, device: 40 was not an MTP device
Mar 26 11:04:08 havel mtp-probe[972666]: checking bus 5, device 40: "/sys/devices/pci0000:00/0000:00:08.1/0000:07:00.4/usb5/5-2"
Mar 26 11:04:08 havel mtp-probe[972666]: bus: 5, device: 40 was not an MTP device
Mar 26 11:04:08 havel Thunar[972665]: thunar-volman: Unsupported USB device type "usb".
Mar 26 11:04:08 havel Thunar[972678]: thunar-volman: Unsupported USB device type "cdc_acm".
Mar 26 11:04:08 havel Thunar[972685]: thunar-volman: Unsupported USB device type "cdc_acm".
Mar 26 11:04:08 havel Thunar[972690]: thunar-volman: Unsupported USB device type "(null)".

Just connecting the TAC to a host should not prevent it from booting.

The bootloader provides too little information on the LCD

The barebox bootloaders displays the following pieces of information on the screen:

It tries to boot into root-a …
… but it failed.
It tries to boot into root-b …
… but it failed.

This is not that much information. It would be great to print at least the following additional pieces of information:

None of the two boot slots have remaining attempts, so none will be booted.
The boot was interrupted via the console / other manual interruption.

i.MX93 IMXUSBLoader compatibility

It would be nice to be able to use an i.MX93 in serial download mode with the IMXUSBLoader resource on the LXA TAC.

update barebox-tools to >= v2023.12.0 with i.MX93 imx-usb-loader support: barebox/barebox@357dd34
update labgrid to a version recognizing the i.MX93's USB ID: labgrid-project/labgrid#1331 (could be picked to stable)

Update tacd the "second release" version

Once the milestone https://github.com/linux-automation/tacd/milestone/1 there is resolved we need to bump the version in the tacd and tacd-webinterface recipes.

The LXA TAC sometimes does not reboot correctly due to kernel hang

We have seen this issue when trying to reboot after a rauc install (but it is not clear if the rauc install plays a role or is just coincidence).

Here is a log of the log output during an attempted reboot, why was kindly recorded by @Bastian-Krause:

root@lxatac-00001:~# dmesg -n 7
root@lxatac-00001:~#
root@lxatac-00001:~#
root@lxatac-00001:~# [593755.976008] EXT4-fs (mmcblk1p2): mounted filesystem 7bd8e28e-fa40-41ea-b1ee-c2e5193ff824 r/w with ordered data mode. Quota mode: disabled.
[593757.532580] EXT4-fs (mmcblk1p2): unmounting filesystem 7bd8e28e-fa40-41ea-b1ee-c2e5193ff824.
[593764.707277] block nbd0: NBD_DISCONNECT
[593764.710349] block nbd0: Disconnected due to user request.
[593764.716062] block nbd0: shutting down sockets
[593764.722040] block nbd0: NBD_DISCONNECT
[593764.725182] block nbd0: Send disconnect failed -32
[593778.142757] watchdog: watchdog0: watchdog did not stop!
[593779.907858] EXT4-fs (mmcblk1p4): re-mounted 8ac00a5a-3255-4613-9119-dc58209566e8 ro. Quota �
[593779.957491] EXT4-fs (mmcblk1p4): re-mounted 8ac00a5a-3255-4613-9119-dc58209566e8 ro. Quota �
[593779.975127] EXT4-fs (mmcblk1p4): re-mounted 8ac00a5a-3255-4613-9119-dc58209566e8 ro. Quota �
[593779.993143] EXT4-fs (mmcblk1p4): re-mounted 8ac00a5a-3255-4613-9119-dc58209566e8 ro. Quota �
[593780.051262] EXT4-fs (mmcblk1p4): unmounting filesystem 8ac00a5a-3255-4613-9119
[593780.135084] EXT4-fs (mmcblk1p3): re-mounted 7bfa8c6d-c4f2-4091-a699-93d542d10ac2 ro. Quota �
[593780.398389] watchdog: watchdog0: nowayout prevents watchdog�
[593780.404425] systemd-shutdown[1]: Failed to disable hardware watchdog, ignoring: Device or�
[593780.413160] watchdog: watchdog0: nowayout prevents watchdog�
[593780.419264] watchdog: watchdog0: watchdo�
[593780.466408] ksz-switch spi0.0 uplink
[593784.562626] ksz-switch spi0.0 uplink: Link is Up - 1Gbps/Full - flo�
[594014.802931] INFO: task kworker/0:1:30966 blocked for more tha
[594014.810866]       Not tainted 6.7.�
[594014.814523] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables
[594014.821492] task:kworker/0:1     state:D stack:0     pid:30966 tgid:30966 ppid:2      fl�
[594014.829993] Workqueue: ipv6_addrconf addrc�
[594014.834399]  __schedule from sch�
[594014.838060]  schedule from schedule_preempt_dis�
[594014.842977]  schedule_preempt_disabled from __mutex_lock.constpro�
[594014.849495]  __mutex_lock.constprop.0 from addrconf_verif�
[594014.855328]  addrconf_verify_work from process_one_wo
[594014.860626]  process_one_work from worker_thre�
[594014.865401]  worker_thread from kthre
594014.869290]  kthread from ret_from�
[594014.873065] Exception stack(0xe18f5fb0�
[594014.877034] 5fa0:                                     00000000 00000000 00�
[594014.884311] 5fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00�
[594014.891611] 5fe0: 00000000 00000000 00000000 00000000 00�
[594014.897337] INFO: task kworker/1:1:30972 blocked for more tha
[594014.903480]       Not tainted 6.7.�[594014.907149] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables�
[594014.914114] task:kworker/1:1     state:D stack:0     pid:30972 tgid:30972 ppid:2      fl�
[594014.922609] Workqueue: events �[594014.925895]  __schedule from sch�
[594014.929373]  schedule from schedule_preempt_dis�
[594014.934248]  schedule_preempt_disabled from __mutex_lock.constpro�
[594014.940812]  __mutex_lock.constprop.0 from linkwatch_
[594014.946200]  linkwatch_event from process_one_w�
[594014.951142]  process_one_work from worker_thre�
[594014.955832]  worker_thread from kthre
[594014.959809]  kthread from ret_from�
[594014.963760] Exception stack(0xe1861fb0�
[594014.967946] 1fa0:                                     00000000 00000000 00�
[594014.975336] 1fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00�
[594014.982712] 1fe0: 00000000 00000000 00000000 00000000 00��
NOTICE:  CPU: STM32MP157C?? Rev.Z
NOTICE:  Model: Linux Automation Test Automation Controller (TAC)
WARNING: VDD unknown
INFO:    Reset reason (0x214):
INFO:      IWDG2 Reset (rst_iwdg2)
INFO:    FCONF: Reading TB_FW firmware configuration file from: 0x2ffe2000
INFO:    FCONF: Reading firmware configuration information for: stm32mp_io
INFO:    Using EMMC
INFO:      Instance 2

It would also be interesting to know why log lines printed after the reboot process has started are a bit mangled and truncated.

meta-lxatac-example Priority

Hi,
I am asking for your opinion here.
Does it make sense to mention that the the priority of the newly introduced meta-lxatac-example layer should be increased in order to be able to override meta-lxatac-software?

My usecase: I had to touch the chrony configuration.

Too broad matching of USBSerialPorts

When exporting separate USBSerialPorts on the same USB port, the match of the lxatac-usb-ports-px USBSerialPort should be '{{sysfs}}:1.0' instead of '{{sysfs}}'. Otherwise udev events might confuse labgrid leading to the same ttyUSBx being used for both lxatac-usb-ports-px and lxatac-usb-ports-px.y.

meta-lxatac/meta-lxatac-software/recipes-devtools/python/python3-labgrid/configuration.yaml

Lines 89 to 102 in 6b6cbb5

 USBSerialPort: 

 match: 

 '@ID_PATH': '{{sysfs}}' 

 USBVideo: 

 match: 

 '@ID_PATH': '{{sysfs}}' 

 ## Extra USB Ports exported as separate interfaces on the same USB port 

 {% for if in [ '1', '2', '3'] %} 

 lxatac-usb-ports-p{{idx}}.{{if}}: 

 USBSerialPort: 

 match: 

 '@ID_PATH': '{{sysfs}}:1.{{if}}' 

 {% endfor %} 

 {% endfor %}

linux-automation / meta-lxatac Goto Github PK

meta-lxatac's People

Contributors

Stargazers

Watchers

Forkers

meta-lxatac's Issues

The avahi daemon keeps detecting hostname conflicts

The TAC gets stuck in bootloader when connected via USB to some PCs

The bootloader provides too little information on the LCD

i.MX93 IMXUSBLoader compatibility

Update tacd the "second release" version

The LXA TAC sometimes does not reboot correctly due to kernel hang

meta-lxatac-example Priority

Too broad matching of USBSerialPorts

Recommend Projects

React

Vue.js

Typescript

TensorFlow

Django

Laravel

D3

Recommend Topics

javascript

web

server

Machine learning

Visualization

Game

Recommend Org

Facebook

Microsoft

Google

Alibaba

D3

Tencent

	USBSerialPort:
	match:
	'@ID_PATH': '{{sysfs}}'
	USBVideo:
	match:
	'@ID_PATH': '{{sysfs}}'
	## Extra USB Ports exported as separate interfaces on the same USB port
	{% for if in [ '1', '2', '3'] %}
	lxatac-usb-ports-p{{idx}}.{{if}}:
	USBSerialPort:
	match:
	'@ID_PATH': '{{sysfs}}:1.{{if}}'
	{% endfor %}
	{% endfor %}