**** BEGIN LOGGING AT Sun Oct 25 02:59:57 2020 Oct 25 17:53:39 so... I was kind of able to boot the odroid H2+ with the help of meta-secure-core, not saying I understand all of the UEFI stuff yet, but the keys provided in that layer seem to satisfy the BIOS Oct 25 17:54:09 question is, if we wanted to have proper H2+ support in meta-odroid, how we'd go about it with al the UEFI stuff involved... Oct 25 17:54:30 I'll try to strip things down since I am not really interested in "true secure boot", just booting would aleady make me happy Oct 25 17:55:03 but in a more broad perspective - not sure if proper secure boot support as offered in meta-secure-core would be something for meta-odroid or not Oct 25 17:55:08 I guess I should raise those questions on the ML? Oct 25 18:08:14 Jin^eLD: H2+ is the x86 based one? Should be a lot easier than that if no secure boot is required, there are wks files for wic that make EFI disk images Oct 25 18:10:28 Jin^eLD: AFAIK nothing particularly special was done re that in AGL for supporting the minnowboard or UpSquared which have UEFI Oct 25 18:10:41 smurray: its an x86 which has no leagacy boot option in BIOS anymore Oct 25 18:11:03 i.e. it requires all the efi crap in order to boot Oct 25 18:11:15 Jin^eLD: yeah, I believe the Up^2 is the same Oct 25 18:11:29 what layer is upsquare in? Oct 25 18:11:38 let me have a look how its solved there Oct 25 18:11:48 actually, let me search for it in the layer index... Oct 25 18:12:35 it doesn't have its own machine AFAIK. AGL was using intel-corei7-64 from meta-intel for those boards, but now uses a tweaked qemux86-64 image Oct 25 18:12:59 btw AGL is what? Oct 25 18:13:04 not familiar with the term... Oct 25 18:13:06 I believe the EFI bits get pulled in when you use a wks file that specifies a EFI partition Oct 25 18:13:22 AGL = Automotive Grade Linux, it's based on OE/YP Oct 25 18:13:24 so it will build all that shim and .efi stuff? Oct 25 18:13:37 that's my understanding Oct 25 18:14:22 let me browse their git and see if I find something Oct 25 18:14:36 see the mkefidisk.wks or efi-bootdisk.wks.in wks files for wic Oct 25 18:15:08 thanks for the pointer Oct 25 18:15:36 I work on AGL ;) AFAIK, they're specifying a tweaked wks, but the base EFI support is coming from what's in wic itself Oct 25 18:16:39 there was a desire to not build two different images for qemux86-64 and the mmax/Up^2, so some work was done to add bits into the qemux86-64 image that's non-standard Oct 25 18:16:51 ah ;) cool :> Oct 25 18:17:06 and it's self-signing stuff I guess? Oct 25 18:17:13 or did you go for "true secure boot"? Oct 25 18:17:48 no, there is no secure boot support in upstream AGL, since so far every downstream wants something different Oct 25 18:18:17 ok, good, because I do not need "secure boot" either.. just need to boot Oct 25 18:18:26 and for AGL, the x86 support is purely for dev/testing, almost no one uses x86 in production vehicles Oct 25 18:18:36 I find it super stupid that intel started to remove legacy boot option from bioses Oct 25 18:18:57 at this point it is what it is, UEFI has been around for a long time Oct 25 18:19:16 we'll be living with it on a lot more ARM hardware now going forward as well Oct 25 18:19:24 oh noooo Oct 25 18:19:39 I was not aware that it's also moving to ARM now... Oct 25 18:19:54 I mean - it's OK as long as one has the choice, if you need secure boot, fine, enable it and use if not, ignore it Oct 25 18:20:00 but no, everyone is now forced to work around it Oct 25 18:20:04 has been for years and years, ever since the aarch64 server stuff came on the scene Oct 25 18:20:17 so you to remember, UEFI != secure boot Oct 25 18:20:27 err, have to remember Oct 25 18:20:46 I thought that was the whole point of uefi? Oct 25 18:20:51 no Oct 25 18:21:03 hmmm :) then.. what is the reason for all of our usffering? Oct 25 18:21:06 UEFI is just a replacement for the BIOS Oct 25 18:21:10 oh Oct 25 18:21:19 the secure boot stuff happens to be based on top of it Oct 25 18:23:00 anyways, I suspect you can just try a genericx86-64 build in oe-core/poky with mkefidisk.wks specified with wic and get an image that will boot Oct 25 18:23:56 the fun around these embedded x86 boards tends to be more that they need some tweaking to expose stuff like i2c and SPI to use them Oct 25 18:25:02 hmm indeed, mkefidisk is in poky already Oct 25 18:25:06 let me try... Oct 25 18:25:10 if that works, that'd be awesome Oct 25 18:25:29 luckily the only thing I need from the H2+ is the 2Gbit ethernet Oct 25 18:25:47 so I may get away without having to look at i2c/spi support :) Oct 25 18:26:01 is the driver for that ethernet in the mainline kernel? Oct 25 18:26:02 I am not a kernel hacker/hw guy anyway Oct 25 18:26:16 does not seem so, hardkernel say one needs to patch the kernel Oct 25 18:27:20 seems like it'll be in 5.9 Oct 25 18:27:30 or, rather is, I guess Oct 25 18:28:43 hmm, not sure if I should try to upgrade or patch, meta-odroid uses an older kernel Oct 25 18:28:55 but that'll be my concern after I come up with a bootable image :) Oct 25 18:30:19 so looking at meta-odroid, does the odroid-h2 machine in there not work on the h2+? Oct 25 18:31:17 no, it does not boot Oct 25 18:31:54 that was my starting point, technically both are compatible, but it seems h2 supports legacy boot and h2+ only uefi boot Oct 25 18:32:08 so the h2 image did not work Oct 25 18:32:41 I then an image built by meta-secure-core and that one did work, BIOS accepted it and loaded grub Oct 25 18:32:45 this wks file looks like it's set up for EFI, though: https://github.com/akuster/meta-odroid/blob/master/wic/odroid-h2.wks Oct 25 18:32:57 yes, it looks pretty much like mkefidisk.wks Oct 25 18:33:05 but the whole stuff in efi/boot is missing Oct 25 18:33:42 and I am not sure who is providing it, actually I thought only meta-secure-core has those things, thats why I tried that layer Oct 25 18:33:59 all the basic EFI stuff comes from oe-core Oct 25 18:34:30 but now I understand taht this is not necessarily true, meta-secure-core just aims to provide secure-boot, but all the .efi files, shims and what not may come from somewhere else. Oct 25 18:34:37 ok, then I got it all wrong Oct 25 18:34:43 perhaps better to ask armpit if he's around, since he's the meta-odroid maintainer Oct 25 18:34:54 I have no experiene with uefi to be honest, I think thats the first non u-boot box I hve :) Oct 25 18:35:07 I failed to catch him on IRC for several days Oct 25 18:35:23 the EFI bits should end up in the .wic.* images Oct 25 18:36:49 but the wks alone does not pull it in Oct 25 18:37:11 oh.. maybe I need efi in MACHINE or DISTRO_FEATURES... Oct 25 18:37:20 let me look at the manual :> Oct 25 18:38:34 AIUI stuff is triggered in wic to do so when you have "--source bootimg-efi" set for the boot partition as mkefidisk.wks does Oct 25 18:39:10 I suspect you'll probably need to muck around in the wic source, in my experience the documentation leaves lots out Oct 25 18:40:01 well, not quite, as you noted - odroid-h2.wic already sets: part /boot --source bootimg-efi --sourceparams="loader=grub-efi" --ondisk sda --label msdos --active --align 1024 Oct 25 18:40:32 and it only created efi/boot with a grub.conf in there, but no .efi files, no shims and nothing else, the h2+ BIOS just ignored that boot medium Oct 25 18:40:46 k, that's surprising Oct 25 18:40:53 that's definitely not what we see in AGL Oct 25 18:41:32 if you keep missing armpit here, probably best to email whatever list he mentions in the meta-odroid README Oct 25 18:42:14 smurray: looking at the Yocto manual I think I am simply missing efi in MACHINE_FEATURES Oct 25 18:43:01 yeah, that'd explain a difference Oct 25 18:44:11 ok let me get rid of meta-secure-core, enable efi in my features and try again :> Oct 25 18:45:50 if that works that'd be a lot easier than expected and I'd feel somewhat stupid :) Oct 25 19:32:13 marex, is it ok for you if I send the patches regarding PARALLEL MAKE for meta-java, or do you want to send them? ... regarding your "fun with zeus" ... I'll setup my automated tests and then investigate in backporting the changes ;-) Oct 25 19:36:41 smurray: lol.... "efi" in MACHINE_FEATURES did it... sstill have to tune the root option, but it got into grub and booted the kernel Oct 25 19:36:45 thank you :) Oct 25 19:37:05 I was approaching this whole thing from a too complicated perspective Oct 25 19:37:46 Jin^eLD: no worries. It's definitely been confusing over the years, you're not the first to see UEFI + secure boot as a single thing Oct 25 19:38:40 :) Oct 25 19:40:56 g0hl1n: just send them Oct 25 20:17:02 marex, the patches are on the ml and master-next. Would be great if you can test them whenever you have time for it ;-) Oct 25 21:20:17 what is this KMETA stuff? I don't see it in the Yocto manual Oct 25 21:20:29 how is it being used and what is it good ofr? Oct 25 21:20:31 *for Oct 25 21:25:12 ah never mind, its in the kernel dev manual, I was looking in the main docs Oct 25 21:35:01 hmm, I still dont quite get the kmeta thing, if I wanted to update the kernel to 5.9.1... do I need the kmeta stuff? in the old days I'd just set the SRC_URI to the tarball... Oct 25 22:00:40 doh.. when I pass the SRC_URI to a kernel tarball it complains about wrong S, shouldn't kernel.bbclass STAGING_KERNEL_DIR somehow or how do I make sure that the kernel tarball gets unpacked there? Oct 25 22:02:58 basically bitbake complains about S being wrong because there is nothing under STAGING_KERNEL_DIR, but I can't set S because kernel.bbclass overwrites it... Oct 25 22:42:42 I don't get it... fetching the kernel, fetcher says "Fetcher failure: Unable to find revision" (i set an SRCREV) but when I check out the kernel repo manuall I can checkout this rev just fine, what is going on? Oct 25 22:48:04 adding nobranch=1 did the trick, weird **** ENDING LOGGING AT Mon Oct 26 02:59:57 2020