Bug 82891

Summary: vtc1010 device no more EFI bootable after v3.14.3 (7e8213c1f)
Product: EFI Reporter: Philippe "RzR" Coval (rzr)
Component: BootAssignee: EFI Virtual User (efi)
Status: RESOLVED INSUFFICIENT_DATA    
Severity: normal CC: efi, matt
Priority: P1    
Hardware: All   
OS: Linux   
URL: https://bugs.tizen.org/jira/browse/TC-1416
Kernel Version: v3.14.17 Subsystem:
Regression: Yes Bisected commit-id:
Attachments: code32_start fix
code32_start fix for v3.14.14

Description Philippe "RzR" Coval 2014-08-20 16:38:24 UTC
Hi

A regression was found v3.14.3 regarding EFI support on vtc1010 device used in Tizen:IVI project .. it used to boot fine using v3.14.2 .

Note that latest stable v3.14.17 does not work better while the same OS is booting fine on different hardware (minnowboardmax) using gummiboot but in x64 flavour...

Anyway after invesigation (using git bissect) the regression is caused by this change :

https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=7e8213c1f3acc064aef37813a39f13cbfe7c3ce7

  Author: Matt Fleming <matt@console-pimps.org>
  Date:   Tue Apr 8 13:14:00 2014 +0100
  x86/efi: Correct EFI boot stub use of code32_start

Reverting it on v3.14.3 and v3.14.17 makes the device booting again.

May the BIOS be updated to check if the problem is fixed vendor side...

Let me crosslink the downstream bug report :

https://bugs.tizen.org/jira/browse/TC-1416

Regards
Comment 1 Philippe "RzR" Coval 2014-08-22 14:52:19 UTC
Some additional data if you care :

https://review.tizen.org/gerrit/#/c/26457/
   
    With this change in , nexcom's vtc1010 does not boot anynore
    even rebased on latest version v3.14.17
    and with latest firmware :
    ftp://ftp.nexcom.com/pub/BIOS/VTC1010/x86_32bit/MV11A109.rom
    ( md5=f5ccb5284ca5bd8668fa1031067dad27 )
    
Note tizen plan to switch to syslinux for EFI boot too .. 
I'll keep you up to date if you care.

Thanks again
Comment 2 Matt Fleming 2014-08-22 15:38:23 UTC
Created attachment 147761 [details]
code32_start fix
Comment 3 Matt Fleming 2014-08-22 15:38:43 UTC
Could someone try out the attached patch? It's based on v3.17-rc1.
Comment 4 Philippe "RzR" Coval 2014-08-22 16:50:31 UTC
Hi,

I just tested v3.17-rc1 (shared in tizen git [*])  
without reverting 7e8213c1f and not that code32_start fix.

Status is better : vc1010 does boot using gummieboot x32 

Note, there is some kind of loop of "[?]" printed on boot but it actually boots ... so that patch may not needed on master branch but on the stables ones.

Will try on both branches next week

Thank you again and see you online

[*] https://review.tizen.org/gerrit/gitweb?p=profile/common/kernel-common.git;a=shortlog;h=refs/heads/sandbox/pcoval/snapshot
Comment 5 Philippe "RzR" Coval 2014-08-25 15:02:08 UTC
Hi,

As requested this "code32_start fix" patch cause no regression on v3.17-rc1 and still makes nexcom vtc1010 booting ... after a page of "[?]" as vanilla v3.17-rc1.

I'll report how it goes with "code32_start fix"  on v3.14.17 and noting reverted ..


Let me recap :

* v3.14.2 : does boot without patches or reverted changes
* v3.17-rc1 : does boot without patches or reverted changes


But "code32_start fix" does not apply on v3.14.14 , any hint welcome :

<<<<<<< HEAD
	je	1f
	movl	0x4(%esp), %esi
	movl	(%esp), %ecx
=======
	je	fail
	leal	startup_32(%esi), %ecx
	movl	%ecx, BP_code32_start(%eax)
	popl	%ecx
>>>>>>> a864f29... WIP: hotfix vtc1010 device no more EFI bootable after
>>>>>>> v3.14.3
Comment 6 Matt Fleming 2014-08-27 11:24:35 UTC
Created attachment 148461 [details]
code32_start fix for v3.14.14

version of patch for v3.14.14.
Comment 7 Matt Fleming 2014-08-27 11:24:56 UTC
Could you try the latest attachment? I rebased it against v3.14.14.
Comment 8 Philippe "RzR" Coval 2014-08-28 13:46:58 UTC
Tested "code32_start fix for v3.14.14" on v3.14.14 , and all I see just the BIOS menu , keyboard leds no more working

About to try that same patch on v3.14.17 ...

Will reverting 7e8213c1f could cause servere regressions on other systems ?
Comment 9 Matt Fleming 2014-09-19 09:34:26 UTC
Yeah, reverting the commit will cause regressions.

Did you have any updates here? Are you still seeing this problem?