Serial Debug Header access query

Hi!
Just wondering if something's changed recently in the way the Serial Debug Header operates?

I'm asking because I've grabbed the recent release, updated to stretch, and OK yes sure added a couple of what I'd call 'basic' things in - nothing too major - but now I don't get access via the Serial Debug Header. All output looks normal on boot and I can't see anything in particular standing out in the boot log, either.

It may well be that I'm missing sufficient amounts of coffee. But any thoughts/comments appreciated at this stage.

Cheers,

Pete.

Output on Serial Debug:

U-Boot SPL 2017.03-00002-gd12b1519b4 (Mar 14 2017 - 10:28:26)
Trying to boot from MMC2

U-Boot 2017.03-00002-gd12b1519b4 (Mar 14 2017 - 10:28:26 -0500), Build: jenkins-github_Bootloader-Builder-532

CPU : AM335X-GP rev 2.1
I2C: ready
DRAM: 512 MiB
Reset Source: Power-on reset has occurred.
MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1
Using default environment

<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
Press SPACE to abort autoboot in 2 seconds
board_name=[A335BNLT] ...
board_rev=[00A5] ...
switch to partitions #0, OK
mmc0 is current device
SD/MMC found on device 0
** Bad device 0:2 0x82000000 **
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
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 ...
Checking for: /boot.scr ...
Checking for: /boot/boot.scr ...
Checking for: /boot/uEnv.txt ...
gpio: pin 55 (gpio 55) value is 1
1972 bytes read in 42 ms (44.9 KiB/s)
Loaded environment from /boot/uEnv.txt
Checking if uname_r is set in /boot/uEnv.txt...
gpio: pin 56 (gpio 56) value is 1
Running uname_boot ...
loading /boot/vmlinuz-4.4.68-ti-r106 ...
8608104 bytes read in 590 ms (13.9 MiB/s)
loading /boot/dtbs/4.4.68-ti-r106/am335x-boneblack.dtb ...
56827 bytes read in 88 ms (629.9 KiB/s)
uboot_overlays: add [enable_uboot_overlays=1] to /boot/uEnv.txt to enable...
loading /boot/initrd.img-4.4.68-ti-r106 ...
5940425 bytes read in 424 ms (13.4 MiB/s)
debug: [console=ttyO0,115200n8 root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait coherent_pool=1M net.ifnames=0 quiet cape_universal=enable] ...
debug: [bootz 0x82000000 0x88080000:5aa4c9 0x88000000] ...
## Flattened Device Tree blob at 88000000
    Booting using the fdt blob at 0x88000000
    Loading Ramdisk to 8fa55000, end 8ffff4c9 ... OK
    Loading Device Tree to 8fa44000, end 8fa54dfa ... OK

Starting kernel ...

[ 0.001026] clocksource_probe: no matching clocksources found
[ 2.109460] wkup_m3_ipc 44e11324.wkup_m3_ipc: could not get rproc handle
[ 2.291426] omap_voltage_late_init: Voltage driver support not added
[ 2.299156] PM: Cannot get wkup_m3_ipc handle
rootfs: clean, 112476/959616 files, 663500/3888512 blocks

Debian GNU/Linux 9 beaglebone ttyS0
beaglebone login:

Hi Peter,

Hi!
Just wondering if something's changed recently in the way the Serial Debug
Header operates?

There shouldn't be anything that changed that. I use the hardware
serial debug interface on a daily basis..

I'm asking because I've grabbed the recent release, updated to stretch, and
OK yes sure added a couple of what I'd call 'basic' things in - nothing too
major - but now I don't get access via the Serial Debug Header. All output
looks normal on boot and I can't see anything in particular standing out in
the boot log, either.

It may well be that I'm missing sufficient amounts of coffee. But any
thoughts/comments appreciated at this stage.

systemd should trigger on:

debug: [console=ttyO0,115200n8 root=/dev/mmcblk0p1 ro rootfstype=ext4
rootwait coherent_pool=1M net.ifnames=0 quiet cape_universal=enable]
...

and setup a serial login console...

do you have this udev rule installed?

https://github.com/rcn-ee/repos/blob/master/bb-customizations/suite/jessie/debian/60-omap-tty.rules

Regards,

Thanks for that, Robert. On my way to second job. Will check it out when I get back to the desk in about 6 hours.

Peter:

Edit the line in /boot/uEnv.txt

cmdline=coherent_pool=1M net.ifnames=0 quiet cape_universal=enable

to remove the work ‘quiet’

— Graham

Graham, that wont fix the issue. The problem he’s having is because the OS( Linux ) is not setup to use the serial interface. You can tell, because he is getting serial messages from the kernel until after the kernel is loaded. Which means the rootfs is meant to “take over” but isn’t.

Hi Peter,

<snip>
>
> systemd should trigger on:
>
> debug: [console=ttyO0,115200n8 root=/dev/mmcblk0p1 ro rootfstype=ext4
> rootwait coherent_pool=1M net.ifnames=0 quiet cape_universal=enable]
> ...
>
> and setup a serial login console...
>
> do you have this udev rule installed?
>
> https://github.com/rcn-ee/repos/blob/master/bb-customizations/suite/jessie/debian/60-omap-tty.rules

Yes

$cat /etc/udev/rules.d/60-omap-tty.rules
# Backward compatibility with old OMAP UART-style ttyO0 naming

SUBSYSTEM=="tty", ATTR{uartclk}!="0", KERNEL=="ttyS[0-9]", SYMLINK+="ttyO%n"