959db9cb12
The genericarm64 machine sets SERIAL_CONSOLES to a number of potential devices: SERIAL_CONSOLES ?= "115200;ttyAMA0 115200;hvc0 115200;ttyS0 115200;ttyS1 115200;ttyS2" With sysvinit this turns into getty lines in inittab, and with systemd the systemd-serialgetty recipe creates explicit units to spawn gettys. This worked fine with 6.6, but since "serial: 8250_omap: Drop pm_runtime_irq_safe()"[1] in 6.7 onwards we see kernel hangs: BUG: scheduling while atomic: getty/957/0x00000002 Call trace: dump_stack+0x1c/0x30 __schedule_bug+0x60/0x90 __schedule+0x83c/0xcf8 schedule+0x40/0x158 schedule_timeout+0xb0/0x1b0 wait_for_completion_timeout+0x84/0x188 ti_sci_set_device_state+0x134/0x220 ti_sci_cmd_get_device_exclusive+0x24/0x40 ti_sci_pd_power_on+0x34/0x68 [ti_sci_pm_domains] _genpd_power_on+0xa4/0x178 genpd_power_on+0xb4/0x190 genpd_runtime_resume+0xc8/0x260 __rpm_callback+0x54/0x200 rpm_callback+0x78/0x90 rpm_resume+0x420/0x690 __pm_runtime_resume+0x5c/0xb0 omap8250_set_mctrl+0x38/0xe0 [8250_omap] serial8250_set_mctrl+0x2c/0x60 uart_update_mctrl+0x98/0x120 uart_shutdown+0x124/0x180 uart_hangup+0x7c/0x180 __tty_hangup.part.0+0x408/0x440 tty_vhangup_session+0x24/0x40 disassociate_ctty.part.0+0x48/0x1b0 disassociate_ctty+0x30/0x48 (full backtrace elided) With many thanks to TI, my understanding is that it was determined that the problem here is that we have a getty connected to ttyS1 which is actually the expansion port uart and on the BeaglePlay wired up to the wifi controller's debug port. The getty receives noise it doesn't know what to do with, and at some point the power management code does a suspend/result cycle of the device. The serial drivers assume that child nodes use the serdev driver and they manage runtime_pm, but the getty opening the tty breaks a series of bad assumptions in the drivers. So, there are two bugs: 1) The kernel shouldn't crash if this tty is opened 2) The only serial port for a console on the BeaglePlay is ttyS2, despite others existing. TI are looking at (1) and other patches to follow will deal with (2). Until one of these is resolved entirely, reverting this change to power management stops the crashes. [ YOCTO #15704 ] [1] linux 8700a7ea5519fb0b3bad2362adfeac358c2119ce (From meta-yocto rev: 49519579f8b6bacf181d2f00bdd256e71d0880c4) Signed-off-by: Ross Burton <ross.burton@arm.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> |
||
|---|---|---|
| bitbake | ||
| contrib | ||
| documentation | ||
| meta | ||
| meta-poky | ||
| meta-selftest | ||
| meta-skeleton | ||
| meta-yocto-bsp | ||
| scripts | ||
| .b4-config | ||
| .gitignore | ||
| .templateconf | ||
| LICENSE | ||
| LICENSE.GPL-2.0-only | ||
| LICENSE.MIT | ||
| MAINTAINERS.md | ||
| MEMORIAM | ||
| oe-init-build-env | ||
| README.hardware.md | ||
| README.md | ||
| README.OE-Core.md | ||
| README.poky.md | ||
| README.qemu.md | ||
| SECURITY.md | ||
Poky
Poky is an integration of various components to form a pre-packaged build system and development environment which is used as a development and validation tool by the Yocto Project. It features support for building customised embedded style device images and custom containers. There are reference demo images ranging from X11/GTK+ to Weston, commandline and more. The system supports cross-architecture application development using QEMU emulation and a standalone toolchain and SDK suitable for IDE integration.
Additional information on the specifics of hardware that Poky supports is available in README.hardware. Further hardware support can easily be added in the form of BSP layers which extend the systems capabilities in a modular way. Many layers are available and can be found through the layer index.
As an integration layer Poky consists of several upstream projects such as BitBake, OpenEmbedded-Core, Yocto documentation, the 'meta-yocto' layer which has configuration and hardware support components. These components are all part of the Yocto Project and OpenEmbedded ecosystems.
The Yocto Project has extensive documentation about the system including a reference manual which can be found at https://docs.yoctoproject.org/
OpenEmbedded is the build architecture used by Poky and the Yocto project. For information about OpenEmbedded, see the OpenEmbedded website.
Contribution Guidelines
Please refer to our contributor guide here: https://docs.yoctoproject.org/dev/contributor-guide/ for full details on how to submit changes.
Where to Send Patches
As Poky is an integration repository (built using a tool called combo-layer), patches against the various components should be sent to their respective upstreams:
OpenEmbedded-Core (files in meta/, meta-selftest/, meta-skeleton/, scripts/):
- Git repository: https://git.openembedded.org/openembedded-core/
- Mailing list: openembedded-core@lists.openembedded.org
BitBake (files in bitbake/):
- Git repository: https://git.openembedded.org/bitbake/
- Mailing list: bitbake-devel@lists.openembedded.org
Documentation (files in documentation/):
- Git repository: https://git.yoctoproject.org/cgit/cgit.cgi/yocto-docs/
- Mailing list: docs@lists.yoctoproject.org
meta-yocto (files in meta-poky/, meta-yocto-bsp/):
- Git repository: https://git.yoctoproject.org/cgit/cgit.cgi/meta-yocto
- Mailing list: poky@lists.yoctoproject.org
If in doubt, check the openembedded-core git repository for the content you intend to modify as most files are from there unless clearly one of the above categories. Before sending, be sure the patches apply cleanly to the current git repository branch in question.