heads
heads copied to clipboard
linuxboot
X230 maximized fhd (edp connector based mods)
Addresses https://github.com/osresearch/heads/issues/614
The whole trailing of how this PoC happened can be read https://github.com/osresearch/heads/issues/614#issuecomment-770431146
EDIT: as of Aug 12 2022, the current patchset upstream is still a moving target.
- to be able to apply vbt binary patch, global Makefile needed to have
patchswitched togit apply - Doing so, some patches needing to apply fuzzing (flashrom) and having invalid target (gpg2 latest at time of writing) needed to be fixed.
This PR was raised back to my attention yersterday, and as pointed above, I intend to fix these maximized boards (hotp/non-hotp) so that the community has an example of what is needed to do to port to a variant, and/or to create a new port, so that this can serve a new entree/augment the porting guide.
Discussions restarted at https://github.com/osresearch/heads/pull/967#issuecomment-1212385495 with new patchset, including upstream vbt configuration blob and distinct edp boards selection under coreboot. This requires libgfxinit to be enabled to use edp instead of the normal vga output and vbt config blob for Qubes 4.1 and other framebuffer enabled OSes to be driven by vbt config without any additional kernel options tuning.
- [x] Tested
- [x] No regression testing for other boards (x230-hotp-maximized)
- [ ] To be rebased on master once #1201 is merged
Build is happening from commits under https://github.com/tlaurion/heads/tree/x230-maximized-fhd CircleCI build https://app.circleci.com/pipelines/github/tlaurion/heads/694/workflows/9d351748-166a-4fa6-b0e4-7a08510cedcc/jobs/765
Artifacts will be there to test.
I can test this, can't remember which kit mine is but it works vanilla coreboot with the fhd variant
Build will take a while since only musl-cross cache can be reused; adding patches to coreboot invalidated the two fuller caches, so all boards needs to be recompiled.
So participants of #614: @n4ru @arl4223 @tslilc @computer-user123 @Thrilleratplay @Tonux599, you might want to read and understand what happened https://github.com/osresearch/heads/issues/614#issuecomment-770431146 while the build is successful (or fails)
You can come back to https://app.circleci.com/pipelines/github/tlaurion/heads/694/workflows/9d351748-166a-4fa6-b0e4-7a08510cedcc/jobs/765 artifact section in like 3 hours or ping me if it fails before then, or play around the PR if you find something weird in there.
I do not care about the ownership of this code. Please take it, change it, and recreate another PR that would supersede this one. As long as your commits are signed, that functional tested PR by one of FHD owner will get merged in.
Thanks. This was my tutorial attempt to make this community a bit more autonomous on their owned boards to create new board configs.
https://github.com/osresearch/heads/pull/967/commits/2df946f9c31dabb5c3cac2cdbf64428f37553b8d should be successful, rebased on master which tweaked CircleCI to build with 24 cores.
@Tonux599 check it out and report back :)
Damn. forgot to change path in coreboot config pointed to that board to proper initrd and bzImage... Rebuilding.
Commits will be squashed.
1rst commit shows how to upgrade board configs, coreboot configs to latest coreboot version. Second commit reverts the changes for other boards so only the fhd one is based on coreboot (since other boards, like the t430, requires feedback on built roms prior of bumpping to coreboot 4.13 in other tickets: #944 #949 specifically).
Superseded but not included in https://github.com/osresearch/heads/pull/1015 Wondering if https://github.com/osresearch/heads/pull/944#issuecomment-886840825 is relevant here? @Tonux599 ?
What's the current process for building an x230 FHD ROM? Been a while and haven't been tracking as closely.
@n4ru just checked the current patchset and it seems that you could apply the patch over master and make BOARD=x230-maximized-fhd on a clean checkout.
The magic is in the patch, which creates a new board under coreboot 4.13
Checking the coreboot config, I'm pretty sure Qubes won't install since VBT is not activated under coreboot config.
Also note that this is maximized board config, so should be flashed externally through bottom and top ROM files, and the board config doesn't include HOTP support.
This is a bit off compared to master. A quick diff between that board config and x230-maximized should show what was improved (coreboot/linux configs pointed per board config)
From a cloned coreboot tree:
git fetch https://review.coreboot.org/coreboot refs/changes/50/28950/22 && git format-patch -1 --stdout FETCH_HEAD
Results in:
From 06fe32bb5f65c784e7819b875c505fcceab11b99 Mon Sep 17 00:00:00 2001
From: Alexander Couzens <[email protected]>
Date: Sat, 19 Mar 2022 13:42:33 +0000
Subject: [PATCH] lenovo/x230: introduce FHD variant
There is a modification for the x230 which uses the 2nd DP from the dock
as the integrated panel's connection, which allows using a custom eDP
panel instead of the stock LVDS display.
There are several adapter boards present on the market and all of them
uses the same method of enabling the custom eDP panel.
To make this work with coreboot, the internal LVDS connector should be
disabled in libgfxinit. The VBT has been modified as well, which allows
brightness controls to work out of the box.
The modifications done to the VBT are:
- Remove the LVDS port entry.
- Move the DP-3 (which is the 2nd DP on the dock) entry to the first
position on the list.
- Set the DP-3 as internally connected.
This has been reported to work with the following panels:
- LP125WF2-SPB4 (1920*1080, 12.5")
- LQ125T1JW02 (2560*1440, 12.5")
- LQ133M1JW21 (1920*1080, 13.3")
- LTN133HL10-201 (1920*1080, 13.3")
- B133HAN04.6 (1920*1080, 13.3")
- B133QAN02.0 (2560*1600, 13.3")
Other eDP panels not on this list should work as well.
Change-Id: I0355d39a61956792e69bccd5274cfc2749d72bf0
Signed-off-by: Alexander Couzens <[email protected]>
Signed-off-by: Felix Singer <[email protected]>
---
src/mainboard/lenovo/x230/Kconfig | 15 ++++++++-----
src/mainboard/lenovo/x230/Kconfig.name | 3 +++
src/mainboard/lenovo/x230/Makefile.inc | 5 +++++
.../lenovo/x230/variants/x230_edp/data.vbt | Bin 0 -> 4281 bytes
.../x230/variants/x230_edp/gma-mainboard.ads | 21 ++++++++++++++++++
5 files changed, 38 insertions(+), 6 deletions(-)
create mode 100644 src/mainboard/lenovo/x230/variants/x230_edp/data.vbt
create mode 100644 src/mainboard/lenovo/x230/variants/x230_edp/gma-mainboard.ads
diff --git a/src/mainboard/lenovo/x230/Kconfig b/src/mainboard/lenovo/x230/Kconfig
index a6fd796206..7aa5af6d85 100644
--- a/src/mainboard/lenovo/x230/Kconfig
+++ b/src/mainboard/lenovo/x230/Kconfig
@@ -1,4 +1,4 @@
-if BOARD_LENOVO_X230 || BOARD_LENOVO_X230T || BOARD_LENOVO_X230S
+if BOARD_LENOVO_X230 || BOARD_LENOVO_X230T || BOARD_LENOVO_X230S || BOARD_LENOVO_X230_EDP
config BOARD_SPECIFIC_OPTIONS
def_bool y
@@ -11,7 +11,7 @@ config BOARD_SPECIFIC_OPTIONS
select H8_HAS_BAT_TRESHOLDS_IMPL
select H8_HAS_PRIMARY_FN_KEYS if BOARD_LENOVO_X230S
select NO_UART_ON_SUPERIO
- select BOARD_ROMSIZE_KB_12288 if BOARD_LENOVO_X230 || BOARD_LENOVO_X230T
+ select BOARD_ROMSIZE_KB_12288 if BOARD_LENOVO_X230 || BOARD_LENOVO_X230T || BOARD_LENOVO_X230_EDP
select BOARD_ROMSIZE_KB_16384 if BOARD_LENOVO_X230S
select HAVE_ACPI_TABLES
select HAVE_OPTION_TABLE
@@ -20,7 +20,7 @@ config BOARD_SPECIFIC_OPTIONS
select INTEL_INT15
select DRIVERS_RICOH_RCE822
select MEMORY_MAPPED_TPM
- select MAINBOARD_HAS_TPM1 if BOARD_LENOVO_X230 || BOARD_LENOVO_X230T
+ select MAINBOARD_HAS_TPM1 if BOARD_LENOVO_X230 || BOARD_LENOVO_X230T || BOARD_LENOVO_X230_EDP
select MAINBOARD_HAS_LIBGFXINIT
select GFX_GMA_PANEL_1_ON_LVDS if BOARD_LENOVO_X230 || BOARD_LENOVO_X230T
select INTEL_GMA_HAVE_VBT
@@ -51,17 +51,20 @@ config MAINBOARD_DIR
default "lenovo/x230"
config VARIANT_DIR
- default "x230" if BOARD_LENOVO_X230 || BOARD_LENOVO_X230T
+ default "x230" if BOARD_LENOVO_X230 || BOARD_LENOVO_X230T || BOARD_LENOVO_X230_EDP
default "x230s" if BOARD_LENOVO_X230S
config MAINBOARD_PART_NUMBER
- default "ThinkPad X230" if BOARD_LENOVO_X230
+ default "ThinkPad X230" if BOARD_LENOVO_X230 || BOARD_LENOVO_X230_EDP
default "ThinkPad X230t" if BOARD_LENOVO_X230T
default "ThinkPad X230s" if BOARD_LENOVO_X230S
config OVERRIDE_DEVICETREE
default "variants/\$(CONFIG_VARIANT_DIR)/overridetree.cb"
+config INTEL_GMA_VBT_FILE
+ default "variants/x230_edp/data.vbt" if BOARD_LENOVO_X230_EDP
+
config USBDEBUG_HCD_INDEX
int
default 2
@@ -83,4 +86,4 @@ config PS2M_EISAID
config THINKPADEC_HKEY_EISAID
default "LEN0068"
-endif # BOARD_LENOVO_X230 || BOARD_LENOVO_X230T || BOARD_LENOVO_X230S
+endif # BOARD_LENOVO_X230 || BOARD_LENOVO_X230T || BOARD_LENOVO_X230S || BOARD_LENOVO_X230_EDP
diff --git a/src/mainboard/lenovo/x230/Kconfig.name b/src/mainboard/lenovo/x230/Kconfig.name
index 1a01436879..e7290a12dd 100644
--- a/src/mainboard/lenovo/x230/Kconfig.name
+++ b/src/mainboard/lenovo/x230/Kconfig.name
@@ -6,3 +6,6 @@ config BOARD_LENOVO_X230T
config BOARD_LENOVO_X230S
bool "ThinkPad X230s"
+
+config BOARD_LENOVO_X230_EDP
+ bool "ThinkPad X230 eDP Mod (2K/FHD)"
diff --git a/src/mainboard/lenovo/x230/Makefile.inc b/src/mainboard/lenovo/x230/Makefile.inc
index 8e801f145d..6e6f9f90b9 100644
--- a/src/mainboard/lenovo/x230/Makefile.inc
+++ b/src/mainboard/lenovo/x230/Makefile.inc
@@ -5,4 +5,9 @@ bootblock-y += variants/$(VARIANT_DIR)/gpio.c
romstage-y += variants/$(VARIANT_DIR)/early_init.c
romstage-y += variants/$(VARIANT_DIR)/gpio.c
ramstage-y += variants/$(VARIANT_DIR)/hda_verb.c
+
+ifeq ($(CONFIG_BOARD_LENOVO_X230_EDP),y)
+ramstage-$(CONFIG_MAINBOARD_USE_LIBGFXINIT) += variants/x230_edp/gma-mainboard.ads
+else
ramstage-$(CONFIG_MAINBOARD_USE_LIBGFXINIT) += variants/$(VARIANT_DIR)/gma-mainboard.ads
+endif
diff --git a/src/mainboard/lenovo/x230/variants/x230_edp/data.vbt b/src/mainboard/lenovo/x230/variants/x230_edp/data.vbt
new file mode 100644
index 0000000000000000000000000000000000000000..13384d45571ff76e592335143d01315e37893186
GIT binary patch
literal 4281
zcmdT`Z)_aZ5&ym0y}P}=-MjTVC6^<yCLz$XvE%h&S*h!)@6LAcg^PXugKH2XcDRE^
zHNiLuN+i^5TbBk=p_5vr0Ri$CB!v1Q6%yhL5TS}%ZG|E}(5mW(6!8It5AdN?tBP`+
zx3_i!7V#AnmCow7GdpkI?0YkBW_RywafYVHi@l}UV$Y$8VyQezRd{&CInDRYR4h$Q
zA08>p6b={56T^4V^SA+LolmX+RUx+79#iSqiP~ars*|P{j#W<|Sw32Qpw?S@B$TK!
zT%y8#_th3_%L^xJRhpi?y+F#XZ5B@+U98gh$p??rmIq1sVr%N_-*;O-QJ>e_m+#Gc
zeSJjvzQO*1!F<1Mj*JdZ9IBMcg_+XCI898^NNKt-Jw1A;SiXxYQxjvQVrgb{#5RMi
z3_rAVdim%B-#tOO;ZDl)3wi>F!IEkCq2;B0R9IZ3DP?n<rfSD)%a7Em`)pG=xClcR
zfQTY3AQJz|BVh>3(8mm!Gbk$bf{?ofjp)+WX;f0xKuMreM_FPop&M`zu|-4&b{lx}
z6dXr%nIN^a1Q1g^?g`SApyQo+We^Ju;y^Soa0Kxp0ExE)gG^{(s5wk=5)@Iwe?zpD
z@%1v$crW@+c=`T;{ewfYIC5a@V7W3iGdp+pJ^l}V_@k99K7NB27i?KEp$JF`50mi@
zjG1XXrseRG7Qw69ek|x~_*Klqd$9}}jBGpu*K}~RX~1KAld;P%uwb}2&iFCo7mQyT
zCSGP-Wc-%#2gY9*A29yLh$l?6F>Yks%;;r&gE7oF#P|+lf$=@YNyZt*<BXp%o@K;N
z;^Rid2d9zA7a?zJayUAk?1cYJsDCEZCq4>N3Nz%%kOxj$xHTH_I6i5-#j$7@-%=}(
z?1954MnX?xAuk79(<<Tf409Fpx$wEsNX+wNp0De7H-87y*XOlHqw#v9f#_UhUAnlg
zi_2(JC*w<@<i}S-iI)}-&;1HW$=_hN&+7=v86dSJ5nbA)_y+kbU2PDFE??VVW9GW>
zSr6;_4gTc~tacpa=As!xD;@CT7xX)U4}W57_`9~2N<i$1-Hq?ZdXRnseAKTSC4vUn
zvU_KR`>pCP65!^@JyGbYMG6B#@{r1i&qF#431THdvdmK?gb!}@x&d86kH8RtSun)L
zMg&qo8p@sxlqPr)H*t1i5Xc8fNK*dW_}wA77I--u)J{nAs;))bo<l6#G>8v<p5gy;
z<c2$V&sxyMI7lIRD=DCSpmMmfaICgCzVKkJ#fR-<sP2F);1(})cA)7k<8|TuBs}RY
zwKp{#FZ7<eJej>k&YfS^jD1^rM=s>0ytuB(<S=kXYsT9eI1^R*2UrsIpx#)DflmYL
zcI2=F|Kw{2>VlIOTx;M223I$qhjl3%0pyLp$ECQ*_^UYE{?(M!zFMP3W9I<gN%(cT
zyvs4>_cUj9w4&M7&s8K0k<cwUM!E2PTu7mct3rr`5sB*7)nZ4R`hWT~<uZuic%Tb%
z5{?q{&YwfGl9W%nBS~{SNhgx-V@b1~q?eQKTGD(wN&iT?re$ukXwY)YmN{$Dqn7)m
zWuCX_HOswZnSZhfw(HvFPMeChJ7b&o+O%T3=WKJ;rZ;W(kGA=)O-9Pirp&!5I+$|r
zNtySj=%*?7xs>@rirz}Oms94I6gg>kPulEG+g%^&e&n+7+xV#SfijjY{5o+C7V}H-
zZs9PGrN7SK-OZ8YGZ>yr(&i#tdss~q`sQ|0&fnIIOUJ;O2*-=b;v=kW?O}6KsoH4P
z0smI&%EQn#cd@w$RZTVP=TtP?l7~|?nRTSIQO2qkgO+Z!=3#T$D-XeMvn68}T3Ey8
zHleye(7mkLXe*JtfA{Q*lj!gc)Wck4IFj|C#q&~HiNmA&>Z|kF4(U<Y;5eIloj)C%
zP4#WvIv2Sie|71?P3)md%>vj%v~DWNT8*x>a2}rST)i~8vd61DwO!2$JZMNNi6hyH
z2d_)6&979w%w$-vyatVrqw??t&t%}iZhDAP3%j_I#cGANdzLq>W;J(F=Xwkxxj%^H
zwQDmn=w}|@-y`RG{*wz0>A(ZGtk~AM=#-fE(LV1uZE98+Nk>UmiyyuJ8?##<Mr{1g
p(B@uj-Va_SU#<T#GXLCvin_ms#}9BYOE7UKDyX7coWuJX{tbC=%boxL
literal 0
HcmV?d00001
diff --git a/src/mainboard/lenovo/x230/variants/x230_edp/gma-mainboard.ads b/src/mainboard/lenovo/x230/variants/x230_edp/gma-mainboard.ads
new file mode 100644
index 0000000000..f7cf0bc264
--- /dev/null
+++ b/src/mainboard/lenovo/x230/variants/x230_edp/gma-mainboard.ads
@@ -0,0 +1,21 @@
+-- SPDX-License-Identifier: GPL-2.0-or-later
+
+with HW.GFX.GMA;
+with HW.GFX.GMA.Display_Probing;
+
+use HW.GFX.GMA;
+use HW.GFX.GMA.Display_Probing;
+
+private package GMA.Mainboard is
+
+ ports : constant Port_List :=
+ (DP1,
+ DP2,
+ DP3,
+ HDMI1,
+ HDMI2,
+ HDMI3,
+ Analog,
+ others => Disabled);
+
+end GMA.Mainboard;
--
2.30.2
Missing bits should be added in the patch under this PR.
Guys, I would have replied earlier to this thread/email , but I’ve been busy af at work … no time to form a quality reply filled with substance.
I would really like to help, and I am even open to sharing my “personal” x230-FHD image, working with qubes … everything works. (HOTP & TOTP )
Let me know if you would like a copy of the FW I am running on my personal machine (x230-FHD)
Heads works beautifully and I have no issues, other the clock drift (manually resetting machines time in UTC) .
I have so many projects going rn, the x230 is the last on my mind… If you would like a copy of my running FW, I have no problems making a copy, and re-setting intel nic to DEADCOFFEE.
Let me know. I’m sorry I do not have time to formulate a “proper” reply.
Thank you.
On Thu, Aug 11, 2022 at 7:26 PM tlaurion @.***> wrote:
Patch refuses to apply got created binary patch....
— Reply to this email directly, view it on GitHub https://github.com/osresearch/heads/pull/967#issuecomment-1212587438, or unsubscribe https://github.com/notifications/unsubscribe-auth/ASIUQUBCIS34RBNZEV7DJNDVYWD4BANCNFSM4W3TU3BA . You are receiving this because you were mentioned.Message ID: @.***>
@computer-user123 question here would be to know if you needed vbt in your rom
Edit: referred issue shows you added it manually. So vbt is needed. Got my answer here, where I guess @Tonux599 test was prior of Qubes 4.1 installer (current tested PR for x230-fhd didn't include vbt)
So next step is to change Make file patch tool reference to git, see below
Patch above coming from more recent changeset https://review.coreboot.org/c/coreboot/+/28950
But cannot be applied with patch because vbt file is binary.
It seems that we just hit our first corner case where global Makefile will need to use git instead of patch to apply binary patches, since patch still don't know how to apply binary diff even if we just want to create a binary file:
lenovo/x230/variants/x230_edp/data.vbt
Which in above patch description is required for:
The VBT has been modified as well, which allows brightness controls to work out of the box.
Otherwise not created, as in this PR.
The modifications done to the VBT are:
- Remove the LVDS port entry.
- Move the DP-3 (which is the 2nd DP on the dock) entry to the first position on the list.
- Set the DP-3 as internally connected.
Also, coreboot changeset is still not merged, but:
This has been reported to work with the following panels:
- LP125WF2-SPB4 (1920*1080, 12.5")
- LQ125T1JW02 (2560*1440, 12.5")
- LQ133M1JW21 (1920*1080, 13.3")
- LTN133HL10-201 (1920*1080, 13.3")
- B133HAN04.6 (1920*1080, 13.3")
- B133QAN02.0 (2560*1600, 13.3")
Other eDP panels not on this list should work as well.
- [x] PR to change Make patch references to use proper git apply (might break things but doubtful)
Yet again, this is not nitrocaster mod, which doesn't need any firmware mod.
@n4ru applies or not? Willing to do the Makefile PR to switch patch calls to git?
From my understanding it "should" be as simple as replacing patch references with git --unsafe-paths
From https://git-scm.com/docs/git-apply.html
--allow-binary-replacement --binary
Historically we did not allow binary patch applied without an explicit permission from the user, and this flag was the way to do so. Currently we always allow binary patch application, so this is a no-op.
--unsafe-paths
By default, a patch that affects outside the working area (either a Git controlled working tree, or the current working directory when "git apply" is used as a replacement of GNU patch) is rejected as a mistake (or a mischief).
When git apply is used as a "better GNU patch", the user can pass the --unsafe-paths option to override this safety check. This option has no effect when --index or --cached is in use.
Yes, I used the vbt from coreboot patch. I remember battling with it, and not getting anything to boot without it.
I should have my x230-FHD (successful) build tree and commands/ configs used… somewhere..
Qubes works, and
On Thu, Aug 11, 2022 at 9:59 PM tlaurion @.***> wrote:
@computer-user123 https://github.com/computer-user123 question here would be to know if you needed vbt in your rom
— Reply to this email directly, view it on GitHub https://github.com/osresearch/heads/pull/967#issuecomment-1212657072, or unsubscribe https://github.com/notifications/unsubscribe-auth/ASIUQUDWYIUBT4O5TRKRREDVYWVWTANCNFSM4W3TU3BA . You are receiving this because you were mentioned.Message ID: @.***>
I am only familiar with my own (2) x230 machines. One of which has a fried Mobo (due to me being an idiot in the “learning” stages) , the other has a nitro caster daughter board soldered onto x230 main board (by a helping friend)
All I can confirm is that heads with HOTP/topt works 100% fine as it is, with a x230 3320m, with nitro caster board.
This is / was my main coreboot device (because it is trusted). Since then, I have a w530 k2000, running without dgpu , and using AFAIK intel 4000 gfx (same as x230)
At this point , I am working on assembling a KGPE-D16 with 128gb ram ….
I am busy at work and personal life, i unfortunately cannot spend more then 20-30min of my time, unless they’re is a specific goal or ?
I do remain honest, I know that I have the (my local build) x230-FHD-nitrocaster FW somewhere close, as it currently runs in my machine, and works problem free
Im thinking in todays work/time/hobby/budget, etc that my current time spent on (hobbies) heads/coreboot , would be better served adding additional 2/3gen intell Mobo / laptops to the project.
I just read yday, that coreboot repo has a utility called auto-port.
I wish to focus my efforts on future coreboot/heads/FW to help with research, testing, and hopefully soon, porting and writing docs for heads proj.
Look forward to taking “my chance” at cracking Panasonic toughbook fw/ec
It’s not an easy task, but I feel I want to try, Do or do not, there is no try
On Fri, Aug 12, 2022 at 12:02 AM Evan Lausch @.***> wrote:
Yes, I used the vbt from coreboot patch. I remember battling with it, and not getting anything to boot without it.
I should have my x230-FHD (successful) build tree and commands/ configs used… somewhere..
Qubes works, and
On Thu, Aug 11, 2022 at 9:59 PM tlaurion @.***> wrote:
@computer-user123 https://github.com/computer-user123 question here would be to know if you needed vbt in your rom
— Reply to this email directly, view it on GitHub https://github.com/osresearch/heads/pull/967#issuecomment-1212657072, or unsubscribe https://github.com/notifications/unsubscribe-auth/ASIUQUDWYIUBT4O5TRKRREDVYWVWTANCNFSM4W3TU3BA . You are receiving this because you were mentioned.Message ID: @.***>
@Tonux599 @computer-user123 @n4ru : I changed the title to FHD (Not Nitrocaster) since I've read that that mod didn't required any firmware mod. Since i'm not an owner of any of those mods, I would love to hear what that mod part is and if the name of this PR should be modified accordingly
@n4ru @computer-user123 : if you already flashed a maximized board before, you can flash internally the ROMs produced by CircleCI for each commit following https://osresearch.net/Downloading
Of course, you should only do that if you own an external programmer to be able to revert to taken backups. As said everywhere else, you cannot flash maximized boards from 1vyrain blahblablah, this requires initial external flashing.
I will check to make sure this PR works, tracing CircleCI fresh build with patches applied by git here (see Makefile changes). This will probably result into a single individual PR just for Makefile changes, and this PR will be rebased on master after that PR works. But as of now, be precautious flashing roms coming from this PR. Some patches might not be applied as expected because of Makefile changes.
Following x230-hotp-maximized build that is happening under https://app.circleci.com/jobs/github/tlaurion/heads/8346?utm_campaign=vcs-integration-link&utm_medium=referral&utm_source=github-build-link where full build log is at https://circleci.com/api/v1.1/project/github/tlaurion/heads/8346/output/103/0?file=true&allocation-id=62f67dfd11f310285d2a0333-0-build%2F2DC2F74E.
Patching with git seems to be functional and my local tests were exiting early, but I only tested by removing build/coreboot-4.13 and adapting the patch so that no rejection was made, to adapt Makefile to be able to apply binary patches with --directory pointing to relative path from git local dir. Otherwise it was failing silently (weird). Hacks found online where to create local git init in extracted dir when not a git repository, where forcing --directory seemed to be the cleaner approach, but now we expect to by under git dir, where some modules change directories to do make kung fu. Hopefully everything will work as expected.
If you have something cleaner then this patch against Makefile, please tell me: https://github.com/osresearch/heads/pull/967/commits/8adca9a9d6eadd26277ec2fa1e3609fdf866ee47
Seems to be ok as of now, but it is still early to tell, with linux having been extracted and coreboot being built:
if [ -r patches/coreboot-4.13.patch ]; then ( git apply --verbose --reject --binary --directory build/coreboot-4.13 ) < patches/coreboot-4.13.patch || exit 1 ; fi
if [ -d patches/coreboot-4.13 ] && [ -r patches/coreboot-4.13 ] ; then for patch in patches/coreboot-4.13/*.patch ; do echo "Applying patch file : $patch " ; ( git apply --verbose --reject --binary --directory build/coreboot-4.13 ) < $patch || exit 1 ; done ; fi
Applying patch file : patches/coreboot-4.13/0002-x230-fhd-variant.patch
Checking patch build/coreboot-4.13/src/mainboard/lenovo/x230/Kconfig...
Checking patch build/coreboot-4.13/src/mainboard/lenovo/x230/Kconfig.name...
Checking patch build/coreboot-4.13/src/mainboard/lenovo/x230/Makefile.inc...
Checking patch build/coreboot-4.13/src/mainboard/lenovo/x230/variants/x230_edp/data.vbt...
Checking patch build/coreboot-4.13/src/mainboard/lenovo/x230/variants/x230_edp/gma-mainboard.ads...
Applied patch build/coreboot-4.13/src/mainboard/lenovo/x230/Kconfig cleanly.
Applied patch build/coreboot-4.13/src/mainboard/lenovo/x230/Kconfig.name cleanly.
Applied patch build/coreboot-4.13/src/mainboard/lenovo/x230/Makefile.inc cleanly.
Applied patch build/coreboot-4.13/src/mainboard/lenovo/x230/variants/x230_edp/data.vbt cleanly.
Applied patch build/coreboot-4.13/src/mainboard/lenovo/x230/variants/x230_edp/gma-mainboard.ads cleanly.
Applying patch file : patches/coreboot-4.13/0080-util-crossgcc-builgcc_temp_fix_from_https_to_http.patch
Checking patch build/coreboot-4.13/util/crossgcc/buildgcc...
Applied patch build/coreboot-4.13/util/crossgcc/buildgcc cleanly.
if [ -d patches/linux-4.14.62 ] && [ -r patches/linux-4.14.62 ] ; then for patch in patches/linux-4.14.62/*.patch ; do echo "Applying patch file : $patch " ; ( git apply --verbose --reject --binary --directory build/linux-4.14.62 ) < $patch || exit 1 ; done ; fi
Applying patch file : patches/linux-4.14.62/0000-efi_bds.patch
Checking patch build/linux-4.14.62/arch/x86/boot/compressed/eboot.c...
Checking patch build/linux-4.14.62/arch/x86/boot/compressed/early_serial_console.c...
Applied patch build/linux-4.14.62/arch/x86/boot/compressed/eboot.c cleanly.
Applied patch build/linux-4.14.62/arch/x86/boot/compressed/early_serial_console.c cleanly.
Applying patch file : patches/linux-4.14.62/0001-fake-acpi.patch
Checking patch build/linux-4.14.62/drivers/acpi/acpica/evxfevnt.c...
Checking patch build/linux-4.14.62/drivers/acpi/acpica/hwacpi.c...
Applied patch build/linux-4.14.62/drivers/acpi/acpica/evxfevnt.c cleanly.
Applied patch build/linux-4.14.62/drivers/acpi/acpica/hwacpi.c cleanly.
Applying patch file : patches/linux-4.14.62/0002-nmi-squelch.patch
Checking patch build/linux-4.14.62/arch/x86/kernel/nmi.c...
Hunk #1 succeeded at 292 (offset -11 lines).
Hunk #2 succeeded at 302 (offset -11 lines).
Applied patch build/linux-4.14.62/arch/x86/kernel/nmi.c cleanly.
Applying patch file : patches/linux-4.14.62/0003-fake-trampoline.patch
Checking patch build/linux-4.14.62/arch/x86/realmode/init.c...
Hunk #1 succeeded at 37 (offset 2 lines).
Hunk #2 succeeded at 151 (offset 13 lines).
Applied patch build/linux-4.14.62/arch/x86/realmode/init.c cleanly.
Applying patch file : patches/linux-4.14.62/0010-winterfell-ahci.patch
Checking patch build/linux-4.14.62/drivers/ata/libahci.c...
Hunk #1 succeeded at 543 (offset 6 lines).
Applied patch build/linux-4.14.62/drivers/ata/libahci.c cleanly.
And..... flashrom fails to be patched by git apply. Interesting, where before, patch was simply applying fuzziness and succeeded:
tar -xf "/root/project/packages/flashrom-b1f858f65b2abd276542650d8cb9e382da258967.tar.gz" --strip 1 -C "/root/project/build/flashrom-b1f858f65b2abd276542650d8cb9e382da258967/"
if [ -r patches/flashrom-b1f858f65b2abd276542650d8cb9e382da258967.patch ]; then ( cd /root/project/build/flashrom-b1f858f65b2abd276542650d8cb9e382da258967/ ; patch -p1 ) < patches/flashrom-b1f858f65b2abd276542650d8cb9e382da258967.patch || exit 1 ; fi
if [ -d patches/flashrom-b1f858f65b2abd276542650d8cb9e382da258967 ] && [ -r patches/flashrom-b1f858f65b2abd276542650d8cb9e382da258967 ] ; then for patch in patches/flashrom-b1f858f65b2abd276542650d8cb9e382da258967/*.patch ; do echo "Applying patch file : $patch " ; ( cd /root/project/build/flashrom-b1f858f65b2abd276542650d8cb9e382da258967/ ; patch -p1 ) < $patch || exit 1 ; done ; fi
Applying patch file : patches/flashrom-b1f858f65b2abd276542650d8cb9e382da258967/0100-enable-kgpe-d16.patch
patching file Makefile
Hunk #1 succeeded at 263 (offset 27 lines).
Hunk #2 succeeded at 575 (offset 73 lines).
Hunk #3 succeeded at 712 (offset 76 lines).
Hunk #4 succeeded at 845 (offset 91 lines).
Hunk #5 succeeded at 974 (offset 106 lines).
patching file ast1100.c
patching file ast2400.c
patching file flashchips.c
Hunk #1 succeeded at 12388 (offset 115 lines).
Hunk #2 succeeded at 16774 (offset 115 lines).
patching file flashrom.c
Hunk #2 succeeded at 158 (offset 24 lines).
patching file pcidev.c
patching file programmer.h
Hunk #2 succeeded at 47 with fuzz 2 (offset 3 lines).
Hunk #3 succeeded at 429 with fuzz 1 (offset 21 lines).
Looking at referred log, nothing else seemed to apply fuzziness for patches. Correcting flashrom patch and force pushing first commit to test this against clean CircleCI build (clean build since ./patches/ found files changed resulting in no matching caches names which includes digest final hash).
https://github.com/osresearch/heads/pull/967/commits/0dd1d543b4895a1f6401ce3330eb27141a15a544 fixes gpg2 patch which had invalid dest target:
if [ -r patches/gpg2-2.2.21.patch ]; then ( git apply --verbose --reject --binary --directory build/gnupg-2.2.21 ) < patches/gpg2-2.2.21.patch || exit 1 ; fi
Checking patch build/gnupg-2.2.21/configure...
Checking patch build/gnupg-2.2.21/common/ttyio.c.mod...
error: build/gnupg-2.2.21/common/ttyio.c.mod: No such file or directory
Applied patch build/gnupg-2.2.21/configure cleanly.
make: *** [Makefile:391: /root/project/build/gnupg-2.2.21/.canary] Error 1
git apply is definitely more picky vs patch....
The current defconfig points to invalid path for vbt for X230_EDP variant in coreboot config derivating from defconfig (Kconfig options not being right)
Changed both coreboot config to reuse variant board path where vbt is supposed to be found for variants https://github.com/osresearch/heads/pull/967/commits/1de3d658291f774dbfd562e0854dda34a48a0774#diff-12c0587222da4ad08ae93273acb68ea1e965fbcaab71d7e967623da2a6b22c3eR5
Made a review/comment upstream: https://review.coreboot.org/c/coreboot/+/28950/22#message-4904ce82f01ba0505b391e072e4537b6a9f1a229
Following sporadically throughout the day, will wait until the changes slow down to test on my hardware.
@n4ru It built. :)
@n4ru @computer-user123 : if you already flashed a maximized board before, you can flash internally the ROMs produced by CircleCI for each commit following https://osresearch.net/Downloading
Same applies to the greenmark in this PR, where clicking fhd for hotp/non-hotp(maximized) will lead you to CircleCI where the artifacts section of a board will provide you with board's artifacts ( roms (full, bottom, top) and hashes.txt file ) for that board.
Please report here. Would also love to know if the nitrocaster doesn't need firmware mod, as said in earlier reply since I understood from upstream it wasn't required.
Is it possible to easily tell somehow whether a maximised board was flashed last time?
For the life of me, personally, I’ve totally forgotten.
On Fri, Aug 12, 2022 at 22:27, tlaurion @.***> wrote:
@.***(https://github.com/n4ru) It built.
@.(https://github.com/n4ru) @.(https://github.com/computer-user123) : if you already flashed a maximized board before, you can flash internally the ROMs produced by CircleCI for each commit following https://osresearch.net/Downloading
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: @.***>
Is it possible to easily tell somehow whether a maximised board was flashed last time? For the life of me, personally, I’ve totally forgotten. … On Fri, Aug 12, 2022 at 22:27, tlaurion @.> wrote: @.(https://github.com/n4ru) It built. > @.(https://github.com/n4ru) @.(https://github.com/computer-user123) : if you already flashed a maximized board before, you can flash internally the ROMs produced by CircleCI for each commit following https://osresearch.net/Downloading — Reply to this email directly, [view it on GitHub](#967 (comment)), or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: @.***>
@househead You scolled to next section? https://osresearch.net/Downloading#migrating-from-on-board-configuration-to-another