<apritzel_>
Jookia: ok, thanks, I will have a look later, I don't use FIT images for kernels, so have to check this out first: the bootm code is nothing for the faint of heart ...
<Jookia>
apritzel_: my only intended use case for this is to include a different dt for a newer kernel if it gets out of sync without updating the bootloader
<apritzel_>
Jookia: mmh, but you always *can* still load a DTB to $fdt_addr_r and use that, you wouldn't need a FIT image for that?
<Jookia>
yes but fit images are signed
<Jookia>
having one image you can load, check and boot is nice
<Jookia>
all the u-boot docs are big in to using FIT too
<apritzel_>
yes, but U-Boot is also great in inventing its own embedded boot flows ...
<Jookia>
if you were to ask me how to make a better system i'm not sure what i would've done. probably just a signed zip file. definitely not use RSA
cmeerw[m] has quit []
<Jookia>
probably use falcon mode or something? i don't know
<Jookia>
but i really don't feel great loading unverified data in to u-boot
<Jookia>
i'm happy for any alternate ideas you have
<apritzel_>
for an embedded system using a FIT image for signing is probably one of the easier things to pull off
<apritzel_>
though normally I would defer secure boot to some UEFI bootloader like grub
<apritzel_>
though personally I don't really care about secure boot or signed images, there are still enough other problems to solve ;-)
<apritzel_>
and it should be a generic problem, solved already out there, and nothing platform specific
<apritzel_>
if U-Boot bootm command requires a DTB in a FIT image, that should be fixed
dickenhobelix[m] has quit []
<Jookia>
apritzel_: how do you defer secure boot? every step has to be signed doesn't it?
<apritzel_>
I mean I leave this up to distros to figure out, since that's a generic problem
<Jookia>
ah, so distros modify/sign u-boot?
<apritzel_>
they have it surely working with grub, for instance, so that would be where I would turn to first
<Jookia>
yes but the bootloader needs to do secure boot too
<Jookia>
so i guess they'd just package it or something with their keys
<apritzel_>
I don't think many distros support U-Boot directly anymore these days, and those that do might not care about secure booting
<Jookia>
so grub replaces u-boot these days?
<apritzel_>
grub (or any other UEFI bootloader, really) is the default bootloader for distros on the x86 side, and for any more serious arm64 machine
<Jookia>
i didn't know it did firmware init stuff
<apritzel_>
and U-Boot happily provides the UEFI boot services required for running grub
<Jookia>
oh
<Jookia>
so u-boot would verify then run grub
<apritzel_>
yes, there must be something in U-Boot that verifies UEFI payloads
<apritzel_>
so you can think of U-Boot just replacing EDK II, which is the UEFI firmware reference implementation, but cannot act as a bootloader on its own: it leaves that to UEFI apps like grub
<Jookia>
so ah
<Jookia>
i'd rather not deal with UEFI in an embedded system
<Jookia>
it seems a bit overkill for just loading a kernel
<apritzel_>
well, I can understand the reservations, though I think it's less of a trouble than you think
<Jookia>
i'm salty with how badly UEFI is implemented on PCs
<apritzel_>
UEFI has a bad reputation, mostly due to it's closed-source vendor hacked-up implementations on the x86 side
<Jookia>
sticking another bootloader in the mix seems like it would increase boot times too -_-
<apritzel_>
but in fact it's just an innocent spec, that specifies an interface between platform firmware on one side and bootloaders and kernels on the other
<Jookia>
i don't think the set of problems i have overlap with UEFI
<Jookia>
i get the impression it's intended to let you run mainline kernels on arbitrary devices, which isn't useful for me
<apritzel_>
if you have a truly embedded use case, then it might seem overkill, but that also means that you cannot piggy back on all the solutions out there, and have to solve stuff on your own
<apritzel_>
so it's a tradeoff, I'd say
<Jookia>
maybe efistub would work? idk
<Jookia>
in my experience you're always running a custom kernel anyway so there's no gain to try and move everything board/soc-specific to uefi
<Jookia>
i'm more of the idea that the kernel belongs as part of the firmware, not the distro
<Jookia>
maybe that's an unpopular thought :)
<tokyovigilante>
apritzel: sure, just meant 5mins being a big improvement from not even getting to a console.
<tokyovigilante>
ok, have enabled all the bins in the original opp table, looks good
<buZz>
gives you another frontend to that data, tokyovigilante
<tokyovigilante>
ah right, thanks
<buZz>
yw
exkcmoeadmin[m] has quit []
exkc has quit []
hexdump0815 has joined #linux-sunxi
hexdump01 has quit [Ping timeout: 480 seconds]
Asara_ has joined #linux-sunxi
Asara has quit [Ping timeout: 480 seconds]
JohnDoe_71Rus has joined #linux-sunxi
Jookia_ has joined #linux-sunxi
Jookia has quit [Ping timeout: 480 seconds]
warpme has joined #linux-sunxi
Schimsalabim has quit [Ping timeout: 480 seconds]
<tokyovigilante>
loki666: Ok have rebased all my trees, h700-frequency-fix is the hopefully-correct DVFS patches ready for mainline, then anbernic-display-mainline is the WIP mainline DE and TCON code on top of that, and then anbernic-image-hacks is the GPU support and other misc. patches which in no state for the kernel yet but does work.
<tokyovigilante>
the LCD patchset is still in those trees but has been applied to drm-misc-next
<tokyovigilante>
apritzel: I think the cpufreq patches are more or less ready to go but I'm just not 100% sure about the opp-supported-hw mask changes I've made, are they documented anywhere?
warpme has quit []
<loki666>
thanks
<tokyovigilante>
I think I will just send all the DE -> TCON -> DTS patches to enable the LCD as one set, then just take feedback on splitting them up. Will be good to get the YUV support in too.
mripard has joined #linux-sunxi
warpme has joined #linux-sunxi
<apritzel>
Jookia_: efistub is the code that wraps around the Linux kernel and disguises it as an EFI application, which gives it access to the UEFI boot and runtime services
<apritzel>
Jookia_: so you can use the EFI shell, U-Boot's bootefi command or any UEFI bootloader like grub or systemd-boot to boot the kernel
<apritzel>
Jookia_: this "kernel belongs to the firmware" is the classic *embedded* approach, which is fair *if* you have a truly embedded use case
<apritzel>
like a tiny device with very little memory, or a real opaque device, like an internet radio or some smart TV or something like that
warpme has quit []
<apritzel>
but that also means you have to solve all those problems yourself, like how to boot, how to configure your kernel, how to update etc.
<apritzel>
which is what all those Linux distributions have solved a long time ago, and for which they spend a lot of time and effort maintaining
<apritzel>
so in the interest of making progress on the aspects that really matter (like new driver or SoC support), I like to piggy back on existing solutions, like distros booting via UEFI
Jookia_ has quit []
Jookia has joined #linux-sunxi
<Jookia>
usually you need custom kernel patches for a device, distros don't really carry those
<Jookia>
so you end up having to ship a kernel anyway
<Jookia>
so having a single set of firmware with the kernel included means you can run many root filesystems without distros breaking your kernel
<Jookia>
Maybe I'm stuck in 2015 Linux land
<Jookia>
But I know most ARM Linux distros still build all the firmware anyway, so they control u-boot, grub, ATF
<Jookia>
open source projects like u-boot and the kernel aren't obligated to support your hardware, the only person that can do that is you, so i think shipping everything up including the kernel seems reasonable enough
<Jookia>
and at that point you control the entire boot flow anyway
<Jookia>
that said, someone may want to poke the u-boot maintainer and tell him to extend his gpg key so it's not expired
<Jookia>
since at this point his key has been expired for months :(
<tokyovigilante>
apritzel: just re-rebased my display code, is it worth rebasing on top of your IOMMU branch?
<tokyovigilante>
[ 11.714875] sun8i-mixer 1100000.mixer: iommu configuration for device failed with -ETIMEDOUT
<tokyovigilante>
[ 11.731210] sun4i-drm display-engine: iommu configuration for device failed with -ETIMEDOUT
<tokyovigilante>
With the IOMMU patches and an iommu reference in the BUS node
<tokyovigilante>
sorry ignore that, would help if I compiled the iommu driver
<apritzel>
tokyovigilante: you can just cherry-pick the IOMMU patches, but please note that there were comments on the list, so I need to do some rework
<apritzel>
tokyovigilante: it would be good if you test them anyway
<tokyovigilante>
[ 1.772457] sun4i-drm display-engine: Adding to iommu group 0
<tokyovigilante>
nice
<tokyovigilante>
yeah I did see that, but agree given that there's nothing upstream using it yet, makes sense to have the IOMMU in first as it will be needed for the video engine, which I'm keen to work on after the DE
<tokyovigilante>
this seems to be working well, and enabling it doesn't give a garbled display as it did with Jernej's previous set
<apritzel>
well, I meant the problem that the IOMMU framework cannot really support a 32-bit only IOMMU in a system with a PA larger than 32 bits
<tokyovigilante>
oh right
<tokyovigilante>
are there any 4GB+ devices where that is a practical concern though? I thought even the OPis were only up to 4GB
<apritzel>
4GB of physical address, and since DRAM starts at 1 GB, it ends at 5GB in the address space
<apritzel>
so any buffer coming from the last GB will have bit 32 set, which cannot be encoded in the IOMMU
<tokyovigilante>
ah right, sorry i'd forgotten about the offset
<apritzel>
and Linux tends to allocate some buffers from the end of memory
JohnDoe_71Rus has quit [Read error: Connection timed out]
<tokyovigilante>
that is a problem then.
JohnDoe_71Rus has joined #linux-sunxi
<apritzel>
in my experiments I saw the kmalloc's for the page tables indeed returning memory from the last GB of DRAM
<apritzel>
that is fixed by the patch
<apritzel>
courtesy of DMA32 limiting the allocation to below 4GB
<apritzel>
what is not fixed and might potentially not be easily fixable is the DMA address that we want to *translate to*
<apritzel>
I was hoping that the IOMMU users (DE and VE) limit themselves to 4GB as well, but I don't know if they can cope with larger addresses or if they are using DMA32 themselves already anyway
<apritzel>
jernej might know ^^^^
<apritzel>
I have a patch that adds a warning should a bigger address sneak it, let me post that somewhere. I would be grateful if you could run with this patch and see it if screams for you
<tokyovigilante>
Definitely working better here than previously in any case, with the dubious benefit that the RG35XX has only 1GB of RAM. Shall I hold the DE patches then, or is it still worth sending them without the IOMMU enabled for the DE, given it's only actually required for the VE?
<tokyovigilante>
Is there anything else to test operationally, other than just the display working?
<apritzel>
please do not hold any patches back, especially not the DE ones. They probably need time to discuss on the list, so the sooner they go out the better
<apritzel>
just ignore the IOMMU in the DT for now, we can sort out the order when we know the patches are going to be applied
<apritzel>
ah right, with only 1GB of DRAM we will never see an PA beyond 4GB, so there is no point in this experiment with the warning patch
<apritzel>
I don't think the IOMMU is *required* for the VE, is it? It just makes its life much easier, since its now trivial to find a large physically "contiguous" buffer, to improve efficiency
<tokyovigilante>
ok, I'll send what I have more or less, still needs DT docs etc
<apritzel>
but I don't know if some codecs requires a certain buffer size, and we cannot find a large enough contiguous area without the IOMMU, just relying on CMA
<tokyovigilante>
I'm also just going off what jernej has said/included previously, and probably not much point worrying until HDMI is working, as the experience of watching a 4K movie on a VGA LCD is probably not going to be great ;)
<apritzel>
Jookia: if you need "custom kernel patches for a device" you are in a very bad place, and I'd argue that puts you even before 2015 ;-)
<apritzel>
Jookia: people apparently accepting that is the whole reason the Arm Linux world for smaller devices is still such a mess
JohnDoe_71Rus has quit [Read error: Connection timed out]
JohnDoe_71Rus has joined #linux-sunxi
<tokyovigilante>
FWIW I'm hoping to get every piece of HW on this device into mainline, even if I still build a custom kernel for CFW or my own purposes
warpme has joined #linux-sunxi
<apritzel>
of course it's natural to have this situation during development, but the goal is of course to have everything in mainline
<apritzel>
and not only for the practical reason of being able to use a distro kernel, but more importantly for the proper review that is required to get it merged
<apritzel>
my IOMMU patch is a good example: I totally missed that part, but Robin pointed that out immediately
<Jookia>
apritzel: mainlining code is not an easy process, projects are backed up (look at u-boot for example), it's often just not viable to have things mainlined when needed
warpme has quit []
<apritzel>
for U-Boot (being part of firmware) that's a slightly different problem, since you naturally ship the firmware yourself, so it's easy to include extra patches
<apritzel>
but for the kernel you should always push for upstream, to enable distributions
<apritzel>
Jookia: and I understand that mainlining is time consuming and not easy, but we need to do it anyway, and be it for the quality aspect
bauen1 has quit [Ping timeout: 480 seconds]
<Jookia>
the distinction of 'firmware' here sounds arbitrary to me
<apritzel>
Jookia: out of curiosity: what are the off-tree kernel patches? display engine/LCD?
<Jookia>
yeah things like that. i'm mainly thinking of another device
<apritzel>
Firmware is any *device specific* software. The kernel is not.
<Jookia>
why not?
<Jookia>
is it because on x86 you download a distro+kernel bundle?
<Jookia>
so ARM land is trying to match that
<apritzel>
yes, because that's the only sane approach, if you ask me
<apritzel>
this idea of: "here is your device, and here is the respective custom kernel to boot it" is insane
<apritzel>
that doesn't scale at all
<Jookia>
i'm not so convinced about that. ideally everything should be mainline, no? including bootloader
<Jookia>
otherwise you're not going to get fixes and updates from your distro
<apritzel>
yes, I am not disputing that
<Jookia>
the idea of being able to download and install a 'distro' for non-x86 seems to be a myth at this point
<apritzel>
though I don't think the distros should be in the game of shipping firmware updates
<Jookia>
distros ship SD card images, including all firmware
<Jookia>
including the kernel
<apritzel>
this all makes me so sad ...
<Jookia>
i think that's the right approach, just with mainline components
<Jookia>
the bootloader/kernel vendor distinction comes from vendors shipping parts of the machine you can't update, and ARM tends to avoid that
<apritzel>
I heavily disagree. There is no technical reason for this, the DT is really the only device specific part you need
<Jookia>
there's no technical reason for anything, it's a social issue isn't it?
<Jookia>
the situation we have now is made because the community insists on mainlined code
<Jookia>
i think mimicing how x86 does it is just a bad idea that's all
<Jookia>
I don't think it's in the end user's best interest to have vendors ship ANY code that runs on their device
apritzel has quit [Ping timeout: 480 seconds]
vagrantc has quit [Quit: leaving]
bauen1 has joined #linux-sunxi
mripard1 has quit []
bauen1 has quit [Ping timeout: 480 seconds]
<diego71>
there are some installer distributed for arm