yoctoproject/poky-contrib
1
0
Fork 0
mirror of https://git.yoctoproject.org/poky-contrib synced 2025-05-08 23:52:25 +08:00
Code Issues Packages Projects Releases Wiki Activity
poky-contrib/meta-yocto-bsp
History
Ross Burton 959db9cb12 linux-yocto: revert omap8250 power management changes on genericarm64 
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>
2025-02-18 11:08:36 +00:00
..
conf
genericarm64.conf: allow overriding u-boot and qemuboot variables
2025-02-11 11:44:19 +00:00
lib/oeqa
oeqa/systemd_boot: Ensure ssh-pregen-hostkeys are available for the test
2024-05-13 16:28:53 +01:00
recipes-bsp/formfactor
genericx86: Drop gma500-gfx-check
2023-06-20 23:24:58 +01:00
recipes-graphics/xorg-xserver
…
recipes-kernel/linux
linux-yocto: revert omap8250 power management changes on genericarm64
2025-02-18 11:08:36 +00:00
wic
genericarm64.wks: reorder partitions
2024-03-08 08:05:44 +00:00
README.hardware.md
README.hardware.md: add myself to genericarm64 maintainers
2024-10-29 11:55:34 +00:00

README.hardware.md

Yocto Project Hardware Reference BSPs README

This file gives details about using the Yocto Project hardware reference BSPs. The machines supported can be seen in the conf/machine/ directory and are listed below. There is one per supported hardware architecture and these are primarily used to validate that the Yocto Project works on the hardware arctectures of those machines.

If you are in doubt about using Poky/OpenEmbedded/Yocto Project with your hardware, consult the documentation for your board/device.

Support for additional devices is normally added by adding BSP layers to your configuration. For more information please see the Yocto Board Support Package (BSP) Developer's Guide - documentation source is in documentation/bspguide or download the PDF from https://docs.yoctoproject.org/

Note that these reference BSPs use the linux-yocto kernel and in general don't pull in binary module support for the platforms. This means some device functionality may be limited compared to a 'full' BSP which may be available.

Hardware Reference Boards

The following boards are supported by the meta-yocto-bsp layer:

  • Texas Instruments Beaglebone (beaglebone-yocto)
  • General 64-bit Arm SystemReady platforms (genericarm64)
  • General IA platforms (genericx86 and genericx86-64)

For more information see the board's section below. The appropriate MACHINE variable value corresponding to the board is given in brackets.

Reference Board Maintenance and Contributions

Please refer to our contributor guide here: https://docs.yoctoproject.org/dev/contributor-guide/ for full details on how to submit changes.

As a quick guide, patches should be sent to poky@lists.yoctoproject.org The git command to do that would be:

 git send-email -M -1 --to poky@lists.yoctoproject.org

Send pull requests, patches, comments or questions about meta-yocto-bsp to poky@lists.yoctoproject.org.

Maintainers:

Consumer Devices

The following consumer devices are supported by the meta-yocto-bsp layer:

  • Arm-based SystemReady devices (genericarm64)
  • Intel x86 based PCs and devices (genericx86 and genericx86-64)

For more information see the device's section below. The appropriate MACHINE variable value corresponding to the device is given in brackets.

Specific Hardware Documentation

Intel x86 based PCs and devices (genericx86*)

The genericx86 and genericx86-64 MACHINE are tested on the following platforms:

Intel Xeon/Core i-Series:

  • Intel NUC5 Series - ix-52xx Series SOC (Broadwell)
  • Intel NUC6 Series - ix-62xx Series SOC (Skylake)
  • Intel Shumway Xeon Server

Intel Atom platforms:

  • MinnowBoard MAX - E3825 SOC (Bay Trail)
  • MinnowBoard MAX - Turbot (ADI Engineering) - E3826 SOC (Bay Trail)
    • These boards can be either 32bot or 64bit modes depending on firmware
    • See minnowboard.org for details
  • Intel Braswell SOC

and is likely to work on many unlisted Atom/Core/Xeon based devices. The MACHINE type supports ethernet, wifi, sound, and Intel/vesa graphics by default in addition to common PC input devices, busses, and so on.

Depending on the device, it can boot from a traditional hard-disk, a USB device, or over the network. Writing generated images to physical media is straightforward with a caveat for USB devices. The following examples assume the target boot device is /dev/sdb, be sure to verify this and use the correct device as the following commands are run as root and are not reversable.

USB Device:

  1. Build a live image. This image type consists of a simple filesystem without a partition table, which is suitable for USB keys, and with the default setup for the genericx86 machine, this image type is built automatically for any image you build. For example:

    $ bitbake core-image-minimal

  2. Use the dd utility to write the image to the raw block device. For example:

    # dd if=core-image-minimal-genericx86.hddimg of=/dev/sdb

If the device fails to boot with "Boot error" displayed, or apparently stops just after the SYSLINUX version banner, it is likely the BIOS cannot understand the physical layout of the disk (or rather it expects a particular layout and cannot handle anything else). There are two possible solutions to this problem:

  1. Change the BIOS USB Device setting to HDD mode. The label will vary by device, but the idea is to force BIOS to read the Cylinder/Head/Sector geometry from the device.

  2. Use a ".wic" image with an EFI partition

    1. With a default grub-efi bootloader:

      # dd if=core-image-minimal-genericx86-64.wic of=/dev/sdb

    2. Use systemd-boot instead. Build an image with EFI_PROVIDER="systemd-boot" then use the above dd command to write the image to a USB stick.

SystemReady Arm Platforms (genericarm64)

The genericarm64 MACHINE is designed to work on standard SystemReady IR compliant boards with preinstalled firmware.

The genericarm64 MACHINE is currently tested on the following platforms:

  • Texas Instruments BeaglePlay
  • AMD Kria KV260

The images built are EFI bootable disk images and can be written directly to a SD card for booting, for example.

There is also limited support for booting a genericarm64 image inside QEMU. When building the image also build the u-boot recipe to build the required firmware (note that this firmware will not boot on real hardware), then use runqemu as usual.

Maintainers:

Texas Instruments Beaglebone (beaglebone-yocto)

The Beaglebone is an ARM Cortex-A8 development board with USB, Ethernet, 2D/3D accelerated graphics, audio, serial, JTAG, and SD/MMC. The Black adds a faster CPU, more RAM, eMMC flash and a micro HDMI port. The beaglebone MACHINE is tested on the following platforms:

  • Beaglebone Black A6
  • Beaglebone A6 (the original "White" model)

The Beaglebone Black has eMMC, while the White does not. Pressing the USER/BOOT button when powering on will temporarily change the boot order. But for the sake of simplicity, these instructions assume you have erased the eMMC on the Black, so its boot behavior matches that of the White and boots off of SD card. To do this, issue the following commands from the u-boot prompt:

# mmc dev 1
# mmc erase 0 512

To further tailor these instructions for your board, please refer to the documentation at http://www.beagleboard.org/bone and http://www.beagleboard.org/black

From a Linux system with access to the image files perform the following steps:

  1. Build an image. For example:

    $ bitbake core-image-minimal

  2. Use the "dd" utility to write the image to the SD card. For example:

    # dd if=core-image-minimal-beaglebone-yocto.wic of=/dev/sdb

  3. Insert the SD card into the Beaglebone and boot the board.