Bug 1594402

Summary: aarch64 kernel has CONFIG_CMDLINE="console=ttyAMA0", unlike other arches, should probably be removed
Product: [Fedora] Fedora Reporter: Adam Williamson <awilliam>
Component: kernelAssignee: Peter Robinson <pbrobinson>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: airlied, bskeggs, crosa, ewk, hdegoede, ichavero, itamar, jarodwilson, jglisse, john.j5live, jonathan, josef, kernel-maint, linville, mchehab, mjg59, pbrobinson, pwhalen, steved
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: 4.18.0-0.rc2.git1.1.fc29.aarch64 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-06-25 23:17:55 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 245418    

Description Adam Williamson 2018-06-22 20:45:29 UTC
This is kind of an offshoot of https://bugzilla.redhat.com/show_bug.cgi?id=1593028 . One thing I figured out while investigating that bug is that the Fedora aarch64 kernel builds have this in their kernel config:

CONFIG_CMDLINE="console=ttyAMA0"

that's not done for any other arch (not even armv7hl) - only aarch64. It basically 'bakes' console=ttyAMA0 into the cmdline on any boot of a Fedora aarch64 kernel. You can specify *additional* consoles, but you can never *not* have a console on ttyAMA0.

This has various consequences. Not least, it means that if an aarch64 system actually has both a 'real' display and a serial console on ttyAMA0 - e.g. a typical aarch64 VM - you will not get plymouth displayed on its physical display unless you manually add 'console=tty0' to its boot parameters, due to details of how plymouth works. plymouth will only show up on the serial console.

pbrobinson and pwhalen seem to be of the opinion that this was basically an ugly hack from the early early days and it should probably go away now, so I'm filing this bug to make sure this isn't forgotten.

I also happened to notice a small inconsistency between the other arches here. Other arm arch configs (armv7hl, armv7hl-debug, armv7hl-lpae, armv7hl-lpae-debug) have CONFIG_CMDLINE="" , but all the other arches do not mention it at all (not even an 'is not set' line). I'm not sure if this is significant, just thought I'd mention it.

Comment 1 Peter Robinson 2018-06-23 10:56:49 UTC
I'm looking at this.

Comment 2 Peter Robinson 2018-06-25 16:56:52 UTC
I've pushed this, it'll be in the rc2 build, I've not tested as much as I'd have liked due to dealing with other issues so we'll see how we get on with this.

Comment 3 Adam Williamson 2018-06-25 16:58:40 UTC
WHAT COULD POSSIBLY GO WRONG

Comment 4 Peter Robinson 2018-06-25 23:17:55 UTC
So looks fine via serial console on:
* mustang
* Pine64
* Dragonboard 410c

Boot tested on Raspberry Pi 3B+ but not tested serial console but it's not ttyAMA0 anyway.

Config looks fine:
$ grep CONFIG_CMDLINE /boot/config-4.18.0-0.rc2.git1.1.fc29.aarch64 
# CONFIG_CMDLINE_PARTITION is not set
CONFIG_CMDLINE=""
# CONFIG_CMDLINE_FORCE is not set

So I think this should be all good, kernel should be in tomorrow's compose

Comment 5 Adam Williamson 2018-06-25 23:32:30 UTC
thanks, now I guess I get to take all those workarounds I wrote into openqa tests back out again :)

Comment 6 Adam Williamson 2019-03-29 22:17:40 UTC
So, it seems that that actually does not do the trick. See https://bugzilla.redhat.com/show_bug.cgi?id=1661288 , which goes a long way around the houses, but eventually works out that, right after I took the workaround out of the openQA tests (the 'workaround' is to pass 'console=tty0' on the cmdline), this broke again - aarch64 tests stopped seeing boot messages. Somehow I forgot about this whole thing, though, and wasted a bunch of time trying to figure out why.

For now I'm going to put the workaround back in the openQA tests.

Comment 7 Hans de Goede 2019-03-30 11:36:17 UTC
Is the qemu based vm on which openQA is running perhaps using devicetree rather then UEFI ?  In devicetree it is possible the indicate the prefered/defailt console= value by setting stdout-path in the chosen node in devicetree:

https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/chosen.txt

Doing a "grep -R stdout-path arch/arm64/boot/dts" in the kernel tree shows that most
dts files define stdout-path and point this to the serial0 or serial1 alias.

Comment 8 Adam Williamson 2019-03-31 00:35:39 UTC
No, it's UEFI.

Comment 9 Hans de Goede 2019-03-31 07:43:07 UTC
(In reply to Adam Williamson from comment #8)
> No, it's UEFI.

Well could still be something similar, ACPI tables can embed devicetree-data and on aarch64 this is sometimes being used AFAIK.