<sjg1>
Tartarus: Thanks very much. I'll start with fedora which seems to work OK
<sjg1>
Tartarus: I'm fiddling with the bootmethod/bootflow stuff and trying to hook it to distroboot as a starting point
birkoff has joined #u-boot
birkoff has quit [Changing host]
birkoff has joined #u-boot
akaWolf has joined #u-boot
sbach has quit [Read error: Connection reset by peer]
sbach has joined #u-boot
agust has joined #u-boot
alpernebbi has joined #u-boot
<milkylainen_>
sjg1: But if I interpreted xypron right, it won't matter if im running in application or payload mode since BLOCK_IO isn't implemented at all? I'm sorry. But I'm rather confused about what works when and how.
indiana-bones has joined #u-boot
redbrain has joined #u-boot
gsz has joined #u-boot
maxs has joined #u-boot
mmu_man has joined #u-boot
akaWolf has quit [Ping timeout: 248 seconds]
akaWolf has joined #u-boot
jwillikers has joined #u-boot
indiana-bones has quit [Quit: Leaving]
gsz has quit [Ping timeout: 268 seconds]
gsz has joined #u-boot
maxs has quit [Quit: Client closed]
<sjg1>
milkylainen_: Yes that sounds right. I'm a bit confused too. The EFI payload turns off EFI services before jumping to U-Boot, so you need U-Boot drivers for all block devices. See efi_main() in efi_stub.c
<sjg1>
milkylainen_: I suppose we could delay disabling boot services until later, so that a block driver could work
<milkylainen_>
But what would be the differences if I ran u-boot in app mode?
<milkylainen_>
For U-boot that is.
<sjg1>
milkylainen_: Well in app mode it doesn't turn off boot services, so you could write a block driver
<milkylainen_>
Downsides of running in app mode?
<sjg1>
milkylainen_: You can't really take over the machine, since EFI is still there. Also U-Boot returns to EFI later. It is just an app that runs and then returns
<sjg1>
milkylainen_: I suppose it would be possible to boot a kernel from the app, since grub does it. I'm not sure what that would entail though
<sjg1>
milkylainen_: So maybe the stub is the easiest way
<milkylainen_>
So you can't turn off EFI from inside APP mode?
<sjg1>
milkylainen_: Search for efi_get_sys_table() to find drivers that use EFI...there is only serial
<sjg1>
milkylainen_: Well you could, but we are blurring the line between stub and app here
<milkylainen_>
sjg1: Does it matter to the user? Why would you run u-boot as an app and return to EFI? Isn't the purpose always to boot something else?
<sjg1>
I think updating the stub makes more sense if you are trying to do everything in U-Boot. If you want to write another version of grub :-) then perhaps the app
<sjg1>
milkylainen_: The app is mostly for testing. It might be worth experimenting with the stub to see where you get to
<sjg1>
or the app
<milkylainen_>
Mmm.
<milkylainen_>
I think it would be a boon to have EFI services available. That way U-boot could cover more hardware solutions without native drivers.
<milkylainen_>
Like my ACPI eMMC controller.
<sjg1>
milkylainen_: Sounds reasonable to me. But I wonder why your controller doesn't work?
<milkylainen_>
sjg1: Does U-boot know anything about acpi-presented devices?
<sjg1>
milkylainen_: Not at present. It generates ACPI tables but SFAIK doesn't parse them
<sjg1>
As a workaround you could add the info statically to the U-Boot devicetree
<milkylainen_>
sjg1: hmm?
<milkylainen_>
Who would pick that up?
<sjg1>
I mean put it in the payload .dts file and see if the driver will come up
<sjg1>
milkylainen_: ^
gsz has quit [Ping timeout: 248 seconds]
<sjg1>
milkylainen_: Re using EFI block devices, I thought that was supported and have a project that could perhaps use it, so I may take a look. Need to finish the v1 bootflow stuff first though
redbrain has quit [Ping timeout: 248 seconds]
Danilo82 has joined #u-boot
<Danilo82>
hello can someone help me make a cript to boot uboot into a shell?
<Danilo82>
i got the idea right but there is something about a 24 bits footer crc32 things that i just don't understand
gsz has joined #u-boot
<marex>
Danilo82: like setenv bootdelay -1 ; saveenv ?
<marex>
or just hold spacebar on boot ?
<Danilo82>
i got a little linux box fot hdtv conversor, i found out it is using a uboot script to update the system, the script can be set to do anything, my idea is to tell the script to set /bin/sh as the init, the problem i have noticed with some help is that it check the crc of the file
<Danilo82>
i don't know how to work this crc32 stuff
<Danilo82>
and its mstar, fork of uboot
<marex>
look at mkimage -T script then
<marex>
that generates you the uImage header around a text script and spits out the boot.scr or whatever you need
<Danilo82>
so i just make the script and the mkimage will do the thing?
<marex>
Danilo82: sounds about right
<Danilo82>
what mkimage are you talking about?
<marex>
Danilo82: the one in u-boot source /tools dir
<marex>
hmmm, that might be some non-standard script format, maybe for some downstream u-boot fork
<marex>
crc32 is 32bits btw
<marex>
you can always try to strip the last four bytes of the script, run 'crc32' from linux command line on the result and see if it matches that crc32 that was in the script