12:58 <Melab> Does anyone here know how to get GRUB 2 to be booted by nv-U-Boot?

13:02 <javier__> Melab: why do you want grub2 ooi?

13:04 <Melab> It's easier to use than U-Boot as a boot manager and it can boot zImage files.

13:04 <javier__> Melab: u-boot also supports zImages

13:05 <javier__> Melab: it should be possible to chain load grub from nv-u-boot, but I don't think that grub has exynos support

13:05 <javier__> not to mention the specific exynos board you want to use

13:05 <Melab> The nv-U-Boot built by Google does not have zImage support. I am working with a Sasung XE303C12.

13:05 <javier__> Melab: yes, but you can chain load u-boot

13:06 <Melab> Yes to what?

13:07 <javier__> Melab: yes, to the nv-u-boo requiring a signed FIT image

13:07 <javier__> *nv-u-boot

13:08 <Melab> I never asked about signed FIT images. As far as I am aware, nv-U-Boot does not use them.

13:10 <javier__> Melab: ah sorry, I still didn't get my coffee

13:12 <javier__> Melab: the nv-u-boot built by google doesn't have zImage support, but you can build your own u-boot with CMD_BOOTZ enabled

13:12 <javier__> which is enabled by default for snow in mainline u-boot anyways

13:13 <javier__> so what you can do is verified-uboot -> FIT image with mainline u-boot (nv-uboot) -> zImage

13:14 <Melab> I tried that. I downloaded the source code for U-Boot from Ubuntu's repository (since I couldn't get the mainline to compile) and configured it for Snow with some of my own settings, but when it was booted on my SD card, nothing appeared on the screen.

13:15 <javier__> Melab: I wrote this how-to article https://blogs.s-osg.org/use-mainline-u-boot-non-signed-kernels-exynos-chromebooks/

13:17 <javier__> and this one if you wan't to make your own built kernel to be load by the v-uboot

13:17 <javier__> https://blogs.s-osg.org/install-linux-mainline-kernel-distro-exynos-chromebooks/

13:18 <Melab> I through in support for EFI emulation since what I've read seems to indicate that that is more reliable for booting GRUB on ARM, but I couldn't get my tools to make an EFI image out of GRUB. I'm really more interested in getting GRUB to work.

13:22 <javier__> Melab: I'm not following, the Chromebook doesn't have an UEFI firmware... it's firmware is the v-uboot

13:25 <javier__> anyways, as mentioned I suggest to read those articles and chain load your own u-boot if the nv-uboot built by google doesn't fit your needs

13:25 <Melab> U-Boot has a bootefi command. This is where I got the idea to use bootefi to load from https://lists.denx.de/pipermail/u-boot/2016-February/244378.html

13:27 <javier__> interesting, thanks for sharing that link

13:30 <Melab> If I can get U-Boot to load GRUB 2 without rebuilding U-Boot with EFI support it would be better. Those patches applies to a version of U-Boot three years younger than the code used to make U-Boot for Snow.

13:31 <Melab> Is Exynos support really the problem with GRUB or is it something to do with the display?

13:36 <javier__> Melab: I expect grub to need to know about the HW. On x86/ACPI systems this is quite standard since is abstracted by the firmware

13:37 <javier__> but on arm32 there isn't this level of standarization or hw abstraction and that's why platforms need to be ported to u-boot

13:37 <javier__> I've never tried grub on an arm system though, so I've no idea tbh

13:38 <Melab> Then how is that configured? Through a device tree? Through code in a configuration file? If it needs to be in a GRUB configuration file, then a GRUB image with an embedded configuration file can be made using grub-mkimage.

13:38 <Wizzup> Isn't the point that the efi payload would give grub a platform-agnostic way to set this up?

13:38 <Wizzup> (which would be provided by u-boot in this case)

13:39 <javier__> Wizzup: yes, that's what I understood from the link Melab shared

13:39 <javier__> but my comment was before he shared that. And I don't even know if those patches made it to upstream u-boot

13:41 <javier__> what I don't understand is why going that route instead of just chain loading an upstream u-boot that supports snow correctly

13:43 <Wizzup> yeah, that is what I do on my snow.

13:43 <Wizzup> I have grub2 on the aarch64 machine, because it does UEFI :/

13:43 <Wizzup> (on serial)

13:43 <Wizzup> s/the/this/

13:45 <Melab> Before reading that patch summary, I had read somewhere that U-Boot's API would need to be configured for GRUB to be successfully booted by it. I built GRUB from Ubuntu's GRUB, but configured it with ./configure --build=x86_64-linux-gnu --host=arm-linux-gnueabihf --with-platform=uboot

13:49 <Melab> After I built my desired configuration of U-Boot (which, again, did not end up showing anything on the display), I tried to make an EFI image of GRUB using grub-mkimage. I used the grub-core directory of my GRUB build as the directory option, but it gave me an error that said "grub-mkimage: error: no symbol table".

13:53 <Melab> I couldn't find much on that error online, but perhaps it was generated because I was using the grub-mkimage provided for my x86_64 laptop as opposed to the one built by my GRUB configuration. https://www.hellion.org.uk/blog/posts/grub-on-uboot-on-qemu/ has the author use the grub-mkimage built alongside GRUB, but since it is an ARM binary, he executes it using qemu-arm. I tried that, but it gave an error about a missing library

13:54 <Melab> So, I resorted to using my laptop's grub-mkimage. Perhaps I need to reconfigure GRUB with the platform as arm-efi. That may have an effect on the missing symbol table.

13:55 <Melab> Is there anyway to configure GRUB's build system to make the tools for one architecture and the GRUB code for another?

14:32 <libv> javier__: blogs are pretty useless

14:32 <libv> they are stale the minute you post them

14:32 <libv> howtos must be wikis so they can be kept up to date

14:33 <libv> you will not believe or accept this now

14:33 <libv> but look again to your info there in 6 months time, as quite some people will

14:34 <libv> and i have spent waaay too much time myself trying to figure out which parts of 5 different but equally stale and conflicting blog posts are still valid

14:34 <javier__> libv: the process described there are quite generic so should not stale

14:35 <libv> bs.

14:35 <libv> but as i just said

14:37 <libv> i am only the guy responsible for making linux-sunxi that good of a wiki.

14:37 <libv> whereas i really just wanted to get users for my upcoming lima driver

14:41 <libv> 6 months, and your info will be outdated.

14:41 <libv> for no good reason too.

14:44 <Wizzup> there is some similar info on the wiki, but it's not properly maintained by me and others

14:45 <javier__> libv: IMHO it depends on whether the doc explains underlaying concepts or just have a set of runes

14:45 <javier__> as long as the chromebooks are shipped with the same firmware, things are not going to change

14:46 <javier__> anyway, the content is licensed under CC so feel free to copy to a wiki if you want

14:47 <libv> Wizzup: you know what i went to with the original chromebook, all the info out there was scattered across shoot-from-the-hip blog entries from people who just wanted to play with the A15 virtualization, but who lost interest days afterwards

14:48 <libv> when i came round like 8 months after that wave of developers had made those posts and of course buggered off, very little of it was valid still, and i had to piece things together from multiple often conflicting blog entries

14:49 <libv> i had the same thing just 3 months ago with the rk3288 firefly

14:49 <libv> and i gave up after a few days (days!), and i moved it back on the shelves with all the other bricks just last week.

14:49 <Wizzup> There should be enough info to get u-boot + kernel compile going on the exynos wiki - also has readymade nv u-boot binaries on there AFAIK

14:49 <Wizzup> I don't know much about rockchip.

14:50 <libv> javier__: you mean well, but if you had spent your time typing that info into the wiki, you would've been several orders of magnitude more helpful

14:51 <libv> now you're helpfulness will turn into a drag pretty quickly

14:51 <libv> Wizzup: rockchip is much worse than exynos still

14:52 <libv> there really are very few arm soc communities where you can point your browser to and get your device working

14:52 <libv> and yet another blogpost is part of the problem and not the solution

14:52 <libv> people are all pretty keen to get code upstream to feel good about themselves

14:52 <Wizzup> what is also 'great' about allwinner devices is the huge amount of devkits/boards

14:52 <Wizzup> exynos is mostly some high end arm laptops, and odroid

14:52 <libv> which happened for two reasons

14:53 <libv> 1) tom cubie

14:53 <Wizzup> there's a lot of exynos code upstream

14:53 <libv> who worked together with the nascent sunxi community, and particularly alejandro mery, to start the cubieboard indiegogo campaign

14:53 <libv> i took over paying for the sunxi server from alejandro, as it is a business expense for me.

14:54 <libv> 2) that wiki.

14:54 <libv> for a long time, the early shitpi boards all had a page called "first steps"

14:54 <libv> ripped straight from what i had typed up while bringing up my first sunxi board

14:55 <libv> and i had to drag that info out of 3 or 4 individuals

14:56 <libv> i then spent some time exposing the shader compiler on the samsung chromebook with the t604

14:56 <libv> and then spent ages rewriting/restructuring the sunxi wiki

14:57 <libv> as i had run into exactly those stale blog entries from the people who did a fly-by a15 bringup

14:57 <javier__> libv: I think that a post explaining the underlying concepts instead of yet another wiki page with a set or runes has value

14:57 <libv> javier__: you can apologize for being this blind in 6 months.

14:58 <javier__> libv: the blog posts are 1 year old and people still use it

14:58 <javier__> as said, you can copy to a wiki if you want since the license allows you

14:58 <libv> javier__: so how many facts in there have changed already?

14:59 <javier__> libv: none as far as I can say. The process is exactly the same

14:59 <libv> things that would've been up to date if those who are using those blog entries got to fix what they found was incorrect or out of date?

15:00 <javier__> I mentioned the exact u-boot and kernel version used, and so people can use it as a reference if regressions are introduced in u-boot/linux

15:01 <libv> and then what?

15:01 <libv> or do people just keep on using that exact u-boot and kernel version?

15:01 <libv> or both?

15:02 <javier__> libv: no, the process to test current upstream u-boot and linux is the same and they *should* work

15:02 <javier__> I try to test every kernel release and fix issues as they arise

15:02 <libv> are you constantly fixing this blog post, or are you constantly fixing code?

15:03 <javier__> libv: code

15:03 <libv> how are people to know that this is the one and only blogpost that is valid forever?

15:04 <libv> do you have a special deal with google there?

15:04 <javier__> libv: I haven't said that's the one and only post. I said that I wrote an article that explains the underlaying concepts because all I found where wikis with a set or runes and not explanation

15:05 <javier__> libv: I work for Samsung and have access to documentation

15:05 <libv> what was wrong with fixing the wiki?

15:06 <javier__> libv: nothing, what's wrong with writing a post that you think it will be (and was) useful for others?

15:08 <libv> i explained that at length.

15:08 <javier__> libv: yes, and I told you that you are free to copy to a wiki

15:09 <javier__> I produced content that's freely available. I don't understand why you are so mad about it

15:09 <libv> i will not, as it is not something that i have verified.

15:09 <libv> it is not something i will associate my name with, until i have verified it

15:10 <libv> which will take a while still as i am not playing with exynos or mali atm.

15:10 <libv> but i will come back to you when i do try it.

15:11 <Wizzup> if you do, please let me/us know as well, as we can also try to help where the wiki is lacking, and then subsequentially improve the wiki