#11315 NORM 1.75-fi: XO 1.75 secure mode gets ttyS0 console instead of ttyS2

[Zarro Boogs per Child]

#11315: XO 1.75 secure mode gets ttyS0 console instead of ttyS2
-------------------------------------------+--------------------------------
           Reporter:  greenfeld            |       Owner:  wmb at firmworks.com                
               Type:  defect               |      Status:  assigned                         
           Priority:  normal               |   Milestone:  1.75-firmware                    
          Component:  ofw - open firmware  |     Version:  Development build as of this date
         Resolution:                       |    Keywords:                                   
        Next_action:  diagnose             |    Verified:  0                                
Deployment_affected:                       |   Blockedby:                                   
           Blocking:                       |  
-------------------------------------------+--------------------------------

Comment(by dsd):

 I think we can solve this cleanly enough without having to rename ttyS2
 through moving the console= (and fbcon=) params out of OFW (and out of
 olpc.fth too), into the kernel CONFIG_CMDLINE, for all laptop models.

 I have confirmed (by looking at the code and testing) that the kernel
 copes fine if the console= and fbcon= parameters are passed multiple
 times. It ignores the repeated ones. So that avoids any possible headaches
 of mixing an old firmware (which passes the parameters in secure mode)
 with a new kernel (which also has the parameters specified in
 CONFIG_CMDLINE).

 The one corner case happens when we mix a new firmware (which doesn't pass
 parameters) with an old OS build, which has a kernel that expects (in
 secure mode) to receive those parameters from OFW. In that case, in secure
 mode, early boot will have the smaller font, and no kernel messages are
 sent over serial console. (Unsecure mode is fine still since the params
 will come from the olpc.fth shipped in that OS build).

 If we can live with that corner case (I think we can) then we can move
 this info out of OFW into the kernel CONFIG_CMDLINE, which would allow us
 to solve this bug at the same time. Thoughts?

-- 
Ticket URL: <http://dev.laptop.org/ticket/11315#comment:5>
One Laptop Per Child <http://laptop.org/>
OLPC bug tracking system