2021-05-15

<agraf> kettenis: just keep up the great work :D. And thanks a lot for the U-Boot port!
<kettenis> U-Boot boots GRUB and GRUB boots the kernel
<kettenis> but we need proper clock and DART DT bindings as well before I can think about upstreaming the U-Boot stuff
<kettenis> heads up to folks using u-boot: you need the code on the apple-m1-mini-pcie branch if you update m1n1 to a newer version

2021-05-12

<_andy_t_> I've added timing info to u-boot & found r8152_eth_recv can be slow
<kettenis> hmm, the default irq and fiq handers in u-boot print stuff
<maz> and I don't see this with other systems that use u-boot.
<maz> kettenis: the slowdown happens if running an EFI app under u-boot.
<kettenis> but if performance is worse than on other arm64 boards that use u-boot, this is something I should look into
<kettenis> I fear the u-boot usb stack isn't great
<kettenis> u-boot doesn't use interrupts so if the bootloader doesn't make frequent EFI bootservices calls, timeouts may be delayed
<kettenis> the efi boot services code uses the same underlying drivers as u-boot itself
<_andy_t_> Within u-boot the network is good, it can load the efi bootloader fast enough, it's just from within this bootloader I have issues
<_andy_t_> kettenis: Have you tried netbooting from U-Boot? I have a usb nic attached and have updated the config so I can use it, but it's very slow when used by an efi application.

2021-05-05

<marcan> will do more dev in the next 1-2 days; chances are good I'll have serial over a secondary CDC-ACM brought up really soon and that will mean anyone can load Linux kernels and debug m1n1 and Linux (and u-boot or whatever) bring-up with zero special hardware or cables or fuss, which is a big win

2021-05-04

<_andy_t_> kettenis1: Yes, although there is support for building the kernel so it can be run with booti in u-boot

2021-04-24

<kettenis1> u-boot generally uses polling instead of interrupts
<pipcet[m]> no keyboard support in u-boot? :-)
<kettenis1> It's just that I don't need them for u-boot ;)

2021-04-17

<arnd> any idea if macos toggles it at runtime? if not, it's probably enough again to have u-boot turn it on before starting Linux
<arnd> but isn't that someting that could be done in m1n1 or u-boot rather than having the OS know about it?
<kettenis> currently there are seperate standalone drivers for all the dwc variants u-boot supports
<arnd> kettenis: is the u-boot driver for dw-pcie derived from the Linux driver?
<arnd> my hope was that this would all be part of what m1n1 can do before u-boot does the bus scan
<kettenis> We (or at least u-boot) needs the reset gpios

2021-04-12

<kettenis_> that's for u-boot
<tmlind> hmm maybe that was actually u-boot limitation, not sure

2021-04-07

<marcan> kettenis_: right, that's fine; I just wanted to make sure u-boot wouldn't do things the kernel doesn't
<arnd> kettenis_: I suppose this means we don't put a /chosen/linux,pci-probe-only property in the DT, but u-boot may add this to speed up the boot
<kettenis_> marcan: based on the discussion from yesterday I think my immediate goal would be to let m1n1 do some minimal RC port initialization and let u-boot take it from there
<marcan> many users will probably do m1n1 -> u-boot -> grub -> Linux
<marcan> actually, m1n1 and u-boot will be upgraded together, as they are combined into one file
<amw> So m1n1 is very rarely upgraded but u-boot occasionally bugfixed/extra features, Linux regularly upgraded
<amw> If I'm understanding the end plan is signed (minimal) m1n1 -> u-boot (complex boot loader support) -> Linux
<marcan> kettenis_: one thing I do want is for Linux not to depend on u-boot initialization, unless there are very good practical reasons for that

2021-04-06

<kettenis_> anyway, back on topic, I'm going to play a bit more with having m1n1 doing some of the RC port initialization and having u-boot do the remainder
<marcan> arnd, sven, kettenis_: with u-boot I see no reason to put pcie init in m1n1, at least not in the core or in normal builds. having proxyclient scripts to do it anyway may make sense for experiments.
<kettenis_> robher: what is the policy for documenting devicetree that the Linux kernel wouldn't care about but that we need to pass information from m1n1 to u-boot?
<arnd> I think u-boot has a port of the Linux USB network drivers, so it can support a lot of hardware
<sven> u-boot already supports those with your patches, doesn't it?
<arnd> bus scanning and resource assignment probably makes sense to keep in u-boot, since that is complicated and u-boot has platform independent code for it
<kettenis_> maybe it is possible to bring the RC ports out of reset and let u-boot take care of the more complicated stuff
<kettenis_> there is quite a bit complexity, and I've already implemented that for u-boot
<arnd> If it's in m1n1, u-boot wouldn't care about the registers either, right?
<arnd> kettenis_: what is the tradeoff for having the PCIe init code in m1n1 vs u-boot?
<kettenis_> for u-boot we'd still need to pass the information in the device tree
<kettenis_> as long as m1n1 or u-boot applies these fixups that is
<kettenis_> but if m1n1 takes stuff out of PERST, U-boot and/or the OS need to be careful about doing it again
<kettenis_> yes, but in my opinion building logic in the OS driver (and duplicating it in various OSes and U-Boot) isn't sane

2021-03-29

<kettenis1> U-Boot doesn't touch the MSI-related registers
<maz> kettenis1: how are things configured in u-boot at the moment?
<winocm> Wait, there’s u-boot?
<maz> kettenis1: so far, I'm running with this (directly derived from your u-boot version): https://paste.debian.net/1191492/

2021-03-19

<maz> kettenis2: I take it that your u-boot doesn't boot from m1n1?
<kettenis2> if you use my u-boot fork you should be able to get away with a fairly minimal pcie host bridge driver

2021-02-21

<marcan> throwing uartproxy.c into u-boot?
<never_released> u-boot supports USB gadget just fine
<marcan> m1n1 is intended to do less than u-boot does
<marcan> I mean I guess you could implement the same proxy thing in u-boot but... at that point we're kind of blurring the line here
<marcan> because u-boot isn't m1n1?
<never_released> marcan: I mean why not u-boot for that
<kettenis> yes, u-boot does the tunable pokes
<marcan> kettenis: right, I mean to run u-boot; for pcie you use the tunable poke stuff, right? Anything else that should be moved into m1n1?
<kettenis> I also rely on U-Boot enabling the DART clocks
<kettenis> I currently rely on U-Boot bringing up PCIe which involves some clock gating, pin muxing, gpio poking and a hanshake with the SMC over a mailbox
<nico_32> u-boot as a secondary bootloader to get efi
<nico_32> ar: efi0: Das U-Boot rev 0x20210100

2021-02-13

<jannau> chainloading linux.macho with preleader-m1 + u-boot has u-boot with pcie/usb support
<kettenis> at that point the u-boot pcie driver can be replaced with something that is much simpler
<jannau> loading u-boot from m1ni. `python linux.py ../payload/u-boot-nodtb.bin.gz ../build/dtb/apple-j274.dtb` works
<modwizcode> jannau: you're trying to load u-boot from m1n1 or the other way around?
<jannau> sigh, I've hoped copying parts of corellium's dts and properties from apple's device tree would be enough to make m1n1 compatible with kettenis u-boot

2021-02-12

<kettenis> so one issue with my u-boot work is that up until now it uses the device tree bindings invented by corellium
<agraf> arnd: his screenshot was showing u-boot fb access, and that should automatically populate a GOP object to feed efifb unless explicitly deactivated :)

2021-02-11

<kettenis> just pushed changes to make the serial port work in u-boot

2021-02-10

<kettenis> and u-boot dies when the first varargs function gets hit
<kettenis> that would fit the OpenBSD bus/driver model nicely and U-Boot wouldn't worry about it
<kettenis> need to clean up a few things before pushing the changes to my u-boot github repository

2021-02-09

<kettenis> Ãmade some progress on u-boot
<kettenis> managed to get the xhci(4) on the pcie bus to do DMA in u-boot

2021-02-07

<arnd> it's a bit of a hack, but probably enough to get things running until everyone has moved to u-boot for their boot flow
<arnd> The approach that ardb came up with for psci over the uefi runtime interface would definitely be intended to run in u-boot, and not rely on having tianocore or something along those lines. As far as I understand it could actually be implemented in m1n1 as well, without doing any other parts of UEFI
<kettenis> and have U-Boot or tianocore expose it in a UEFI table
<kettenis> marcan: U-Boot already does too much UEFI ;)
<marcan> but I very much expect the production version of Asahi Linux to end up looking like m1n1 -> u-boot -> grub -> kernel, for end user installs
<marcan> I said I don't want to have u-boot as a hard dependency in order to boot linux *at all* because being tied to piles of bootloader code makes it harder to do back to basics tests and I do like being able to throw kernels at m1n1 and play around in a small codebase
<never_released> but be just a stub for u-boot/tianocore/whatever
<never_released> why not have it as a U-Boot SPL
<marcan> I'm wondering if I can e.g. provide all the hardware-related init stuff in m1n1, then let u-boot provide the boot sequence and disk/FS services
<marcan> kettenis: u-boot provides UEFI, right? can it enhance an existing UEFI implementation, i.e. add services?
<kettenis> U-Boot provides an implementation for some boards
<marcan> this is m1n1's entire reason to exist, to take care of as many apple-isms as it can before handing off to linux, u-boot, or whatever

2021-02-06

<kettenis> my i2c driver on u-boot is based on the pasemi linux driver but some of the additional bits that the correllium driver sets are defenitely necessary
<kettenis> anayway, u-boot has zero infrastructure for IOMMU's, so bypassing the damn thing is the only real option for now
<kettenis> for u-boot?
<kettenis> so my u-boot enumerates the pci bus now

2021-01-27

<dhewg> there are SBCs which have open source ddr ram training code in u-boot, but i don't know its origin
<marcan> 1) you *could* just throw this all away, ignore the flash, and stick the blob into u-boot in your own OS build like a normal person (yes, yes you could... so your argument is end-users can ignore your waste of time and money and do things the sane way, right)

2021-01-19

<Necrosporus> Shiz, I guess if mach-o becomes more common, generating code will be in kernel tree rather than as separate program... Though mkimage for u-boot is still separate program

2021-01-10

<Shiz> but yeah, u-boot also has its own framework so it might depending on your need also work
<Shiz> also, does u-boot's EFI do secure boot?
<artemist> The easiest way would probably be for mini or whatever to load u-boot and have u-boot do UEFI secure boot

2021-01-08

<Necrosporus> I'm wondering what does it have in there? It seems to be something similar to u-boot env
<mjg59> If you're able to get to u-boot you can present a uefi layer
<mjg59> Lightsword: In theory u-boot could be used to provide a UEFI environment
<Necrosporus> Shiz, I have experience of booting alternative kernel on Chromebook ARM, the kernel or u-boot has to be signed even with security off
<marcan> it's entirely possible that the chain will end up being mini - u-boot - linux
<marcan> u-boot will be more useful if, say, we decide that we want a bootloder that has USB support
<marcan> and if after that all I need to do to boot linux is put it in RAM and call it with some params, that's easier than porting u-boot at that point
<Alex[m]17> i only mention u-boot because i dont want you having to re-invent the wheel when it comes to a bootloader, it seems to be the standard for booting arm64 SBCs and the like
<marcan> but Linux already supports crazy ARM64 machines (see: every Android phone), so I don't see why u-boot will buy me anything at *this* stage
<marcan> whether I go straight to Linux at that point, or u-boot first, will depend on what I see when I investigate that boot protocol on ARM64
<mjg59> But once you're in u-boot you can do UEFI - there's support for providing enough UEFI boot services in u-boot to launch Linux
<mjg59> davidrysk[m]: I think that's (2), although you could theoretically have a first stage bootloader that just chained into u-boot
<davidrysk[m]> and u-boot just loads the kernel directly
<davidrysk[m]> does it have to be a UEFI environment, as opposed to a simpler bootloader like u-boot? though considering that iBoot does the hardware setup, that might not be needed
<marcan> u-boot makes sense when low level init an ATF and such are involved, but with the M1 being so custom (AIC...) and iBoot doing all the low level stuff for us, I don't feel like it'll buy us much a priori
<marcan> porting u-boot doesn't seem like worth the effort for initial bring-up
<marcan> whether it makes sense to switch to u-boot at some point or not, we will see
<Alex[m]17> what is the bootloader going to be? u-boot?

2021-01-06

<marcan> I don't know if I will use u-boot eventually yet, but I probably won't initially. it's one more thing to port, and I'd rather have my own little playground and boot kernels directly if I can, at least at first
<CDFH> I'm well aware of the capabilities of u-boot and TF-A :)
<Necrosporus> And why u-boot isn't used for x86, if it's that cool?
<CDFH> I work in bare-metal embedded, we pretty much use u-boot for everything on an A-Class core
<Shiz> I mean, if you figured out how the low-level hwinit/rom bootloader in those armv8 boards loaded u-boot, you could also port other bootloaders to them
<Necrosporus> Probably. But other armv8 board seem to use u-boot only... or not?
<diz3y> I am happy with u-boot for starters, but *ideally* SBBR would be real nice
<Necrosporus> I do not understand why are you not happy with regular u-boot like interface? Maybe it makes sense to make iBoot load Das u-boot which in turn can load any other OS
<Necrosporus> Coreboot can load u-boot as payload
<Necrosporus> U-boot can implement UEFI
<diz3y> u-boot? Would be nice to have UEFI/Coreboot instead
<jn__> yeah, u-boot is pretty common across the industry