Clamor has quit [Read error: Connection reset by peer]
sakman_ has quit [Remote host closed the connection]
qschulz has quit [Quit: qschulz]
qschulz has joined #u-boot
sakman has joined #u-boot
mmu_man has quit [Ping timeout: 246 seconds]
pivi has joined #u-boot
thopiekar has quit [Ping timeout: 260 seconds]
thopiekar has joined #u-boot
luneff has quit [Ping timeout: 264 seconds]
luneff has joined #u-boot
<sjg1>
Tartarus: xypron: I've lost track of what the next step is on the lmb series. From my side I feel we should decide whether to follow the linux naming, or not
<sjg1>
(i.e. memregion)
<sjg1>
Tartarus: Also should I pull in the qconfig series to -next ?
<sjg1>
Tartarus: I see your review tag on the buildman one, so I will do that
thopiekar has quit [Ping timeout: 240 seconds]
thopiekar has joined #u-boot
pavelow has quit [Quit: No Ping reply in 180 seconds.]
pavelow has joined #u-boot
thopiekar has quit [Ping timeout: 260 seconds]
thopiekar has joined #u-boot
flyback has quit [Quit: Leaving]
flyback has joined #u-boot
flyback has quit [Remote host closed the connection]
flyback has joined #u-boot
thopiekar has quit [Ping timeout: 240 seconds]
thopiekar has joined #u-boot
Mis012 has quit [Remote host closed the connection]
Leopold_ has quit [Remote host closed the connection]
Leopold has joined #u-boot
Mis012 has joined #u-boot
jclsn has quit [Ping timeout: 260 seconds]
jclsn has joined #u-boot
naoki has joined #u-boot
thopiekar has quit [Ping timeout: 255 seconds]
Clamor has joined #u-boot
thopiekar has joined #u-boot
sakman has quit [Remote host closed the connection]
Mis012 has quit [*.net *.split]
persmule has quit [*.net *.split]
GNUtoo has quit [*.net *.split]
Mis012 has joined #u-boot
GNUtoo has joined #u-boot
qqq has joined #u-boot
brassado has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
slobodan has quit [Remote host closed the connection]
dsimic has quit [Ping timeout: 245 seconds]
dsimic has joined #u-boot
dsimic has quit [Client Quit]
dsimic has joined #u-boot
ldevulder has joined #u-boot
<Tartarus>
sjg1: The next steps are for xypron to chime in about a better scheme overall, or someone to investigate if making LMB cover the EFI regions is reasonably, or unreasonably leading to exhaustion so frequently now
<Tartarus>
The qconfig series hasn't been posted for that long, perhaps wait a bit longer?
mmu_man has joined #u-boot
alpernebbi_ has quit []
Clamor has quit [Ping timeout: 258 seconds]
Clamor has joined #u-boot
prabhakarlad has joined #u-boot
<sjg1>
Tartarus: Yes I saw your EFI question, but I don't know why EFI people have not responded. Looking at all the regions it sets up, it could be EFI:
<sjg1>
That's 12 regions which is close to the common limit of 16
<sjg1>
Tartarus: I also see that efi_lmb_reserve() has no error checking :-(
<sjg1>
Re qconfig...OK
<Tartarus>
Yes, and why aren't they coalescing since they're adjacent
<Tartarus>
That should be one LMB not 8
mmu_man has quit [Ping timeout: 258 seconds]
Ntemis has joined #u-boot
Ntemis has quit [Read error: Connection reset by peer]
<sjg1>
Tartarus: Ah yes I suppose they do...having said that, it seems sideways from my series. The lack of error checking is a problem that should be fixed. If the EFI people don't want to look at it, what do we do?
<Raito_Bezarius>
sjg1: btw, the patch (which Bin Meng applied) you mentioned for boot on x86 and initrd file size does not seem to exist as far as I see it
<Raito_Bezarius>
the patch I sent fixed x86 zboot for me
frieder has quit [Remote host closed the connection]
<Xogium>
most probably a dumb question but would you say it is a good or bad idea to store a boot script onto an eeprom ? Actually, can you even do that in the first place ?
slobodan has joined #u-boot
<xypron>
sjg1: Tartarus: Coalescing of adjacent regions is handled by LMB in lmb_coalesce_regions(). We don't want to repete ourselves in code. So it is not efi_lmb_reserve() but lmb_add_region_flags() that should write an error message. The whole idea of recreating lmb entries on every load file makes no sense to me. When a file is loaded to memoryk, that memory should be blocked until the file is unloaded explicitly.
<xypron>
Xogium: You can put your script into a variable and store the environment. Is your script too big to fit into a variable?
<Tartarus>
Why are we never seeming to coalesce regions?
<xypron>
Tartarus: We should create a unit test for coalescing.
<Xogium>
xypron: I'm not sure. I don't think so. It's a 1693 bytes file when being in scr format
<Tartarus>
We should see why we aren't seeming to coalesce anything first
<Tartarus>
And also, we don't need to prevent a file loaded into memory from being modified
<Tartarus>
It's that we need to make sure we aren't overwriting ourselves when loading a file
<Xogium>
this script does a/b boot so it alters the env when switching from one slot to the other
ikarso has quit [Quit: Connection closed for inactivity]
<Tartarus>
sjg1: I don't think the rename things portion of the LMB series is helpful. Maybe 1, 9, 10, 11. I don't like "document and change" things in a single patch which is 12 and 13 and then no, it's not clear that 14 is improving things
mmu_man has joined #u-boot
Stat_headcrabed has joined #u-boot
Stat_headcrabed has quit [Client Quit]
FergusL has quit [Ping timeout: 255 seconds]
Stat_headcrabed has joined #u-boot
mmu_man has quit [Ping timeout: 258 seconds]
stefanro has quit [Quit: Leaving.]
vagrantc has joined #u-boot
<sjg1>
zear: Use static inline functions if needed, e.g. see clk.h
<sjg1>
zear: paulbarker: If it is a missing struct member, consider whether it is easier to just add it (without code-size increase), or us an accessor as in asm-generic/global-data.h
<sjg1>
Tartarus: Did you see that region refers to both the individual pieces in the region as well as the collection of regions?
qqq has joined #u-boot
<Tartarus>
sjg1: OK. But that gets back to what I've been trying to emphasize. The biggest problem with the code is that it's seemingly broken (why are all of these adjacent requests not being coalesced? should the EFI code be requesting all of these like it is, given xypron's comment just now where it sounds like we're protecting every file that's loaded, which isn't what we should be doing at all?) not that the long standing naming within the code
<Tartarus>
is... suboptimal.
mmu_man has joined #u-boot
xroumegue has quit [Ping timeout: 245 seconds]
xroumegue has joined #u-boot
mckoan is now known as mckoan|away
Stat_headcrabed has quit [Quit: Stat_headcrabed]
<sjg1>
Tartarus: We have an error that is incorrectly reported as an overlap, but is not. It is really confusing. The code is a mess, which I was trying to help with
<sjg1>
EFI support is hacked in there, too
<Tartarus>
Yes, xypron wasn't happy about adding LMB calls in to the EFI loader code, so it's possible we did something wrong there in the end.
<xypron>
Do you have a reproducible problem on QEMU or sandbox?
<xypron>
Tartarus: EFI implements a proper memory management on page level. We could use the same type of page level memory management to check if space is available for loading files.
<sjg1>
Tartarus: Yes, we did something wrong there in the end. At the very least, the code should have been fixed to have error checking. But putting EFI code in the lmb code is just a hack, IMO
<f_>
hi all. Does anyone know why TPL doesn't have DM_MMC?
<marex>
f_: because TPL is supposed to be minimal
<sjg1>
xypron: For the repro case, I did have one, which is why I sent the series...I might be able to find it in my notes. I suspect it was qemu case mentioned by someone on irc, where we load a few files including ramdisk, then boot
<sjg1>
xypron: But my memory fails me
<xypron>
sjg1: I don't doubt that EFI memory may have a lot of regions depending on what you have done before. But this would not be a LMB coalesce issue.
<f_>
marex: am porting TPL/SPL to Amlogic which uses an mmc driver that uses DM...
<f_>
For now I have it in a Kconfig but perhaps (especially since according to my decompilation of their proprietary BL2 they don't seem to do any init) in the long term I should probably get something minimal to work..
<f_>
(any MMC init, that is)
<Tartarus>
Oh, right, that was an efi dump, sorry
<Tartarus>
xypron: It's not about "do we have space", it's "are we overwriting ourselves"
<f_>
Screw it. Will get the driver to work without DM
<xypron>
Tartarus: it could also be loading initrd overwrites kernel which we don't want to happen.
<Tartarus>
f_: Yes, within TPL we do whatever needs to be done to have a minimal image
<Tartarus>
xypron: That's not our problem
<Tartarus>
And handled elsewhere
iprusov has quit [Quit: WeeChat 3.5]
<f_>
Tartarus: Sure.
<Tartarus>
You aren't making an LMB reserve for every file load location, are you today, xypron ?
<xypron>
Tartarus: EFI was added to LMB because kernel extraction was overwriting EFI memory.
<Tartarus>
Yes, and EFI memory needs to be in an LMB, not whatever EFI loads
<xypron>
Tartarus: EFI memory is persistent. LMB goes away after every check. EFI loads things only into what it has allocated from EFI memory.
iprusov has joined #u-boot
<Tartarus>
xypron: Maybe the question is what was the use case where loading something was overwriting EFI?
<xypron>
Tartarus: decompression I think is what tried to use high memory.
<f_>
By the way, is having DRAM init in TPL ok?
<f_>
or should that be done in SPL?
<Tartarus>
xypron: And what was it overwriting, kernel/initrd/dtb, or U-Boot?
<xypron>
f_: You use TPL to load SPL to DRAM? Than you need to initialize it first.
<Tartarus>
f_: It Depends on what the use case is and what's required
<f_>
xypron: Initialise the DRAM, you mean?
<xypron>
Tartarus: it was overwriting EFI objects and then later we got a crash
<Tartarus>
SPL can run from say SRAM and init DRAM
<f_>
Yeah I'm aware
<f_>
xypron: DRAM init works on gxbb, still have to port to gxl eventually
<xypron>
Tartarus: It is the allocated EFI memory that we must protect.
<Tartarus>
xypron: And by EFI objects what do you mean? Something else that was loaded via EFI_LOADER, or something that's generally part of U-Boot itself?
<Tartarus>
xypron: Allocated EFI memory that we must protect from what?
<xypron>
Tartarus: any of these. E.g. a region to which U-Boot holds a pointer.
<xypron>
Image decompression or loading must not overwrite what EFI has allocated.
<xypron>
Tartarus: It the same as with the stack and malloced memory. You don't want to overright these either.
<xypron>
overwrite
<Tartarus>
Yes, but we take care (generally speaking) to have all of our normal memory usage grouped together
<Tartarus>
and I'm worrying that rather than being adjacent to our existing allocations we're making big holes
<f_>
Tartarus: BL1 loads the first 48K from either eMMC, an SD card, or SPI. 4K is taken by an @AML header
<f_>
so that leaves you with 44K
<xypron>
EFI memory allocation is similar to malloc. We allocate the highest free memory that is available.
<xypron>
and large enough
<Tartarus>
f_: OK. And how much further functionality do we need to have in that 44K ? "SPL" can be that small
<f_>
being able to load ATF and the SCP firmware, as well as initialise the DRAM
<Tartarus>
And is that payload placed in to SRAM or similar, rather than DRAM? Or is that header supposed to also contain some memory init sequence
<f_>
It's in SRAM
<f_>
and no, the header doesn't contain any memory init sequence. It's just for signing
<Tartarus>
ok
<Tartarus>
(the imx DCD header does stuff like that is why I ask)
<f_>
Would be nice if Amlogic did that :)
<f_>
but I have working DRAM init anyway now after some reverse-engineering, looking at some old sources, and a little bit of help
<Tartarus>
So, in sum, yeah, having TPL do dram init and so on is fine, and then op-tee loads SPL loads U-Boot isn't unusual
<f_>
Fourtunately that BL2 header hasn't changed much for a while. This signing tool was tested and confirmed to work on at least gxbb, gxl, and sm1
<Tartarus>
xypron, sjg1 what I'd really like to do / understand wrt LMB, is how we end up in the situation where our LMB allocations are full and so the "fix" is to bump up the overall possible number to 64
<f_>
And best of all: it's open source :)
<Tartarus>
Then we can figure out what, if anything, is being done sub-optimally, and where / what error messages should be from where
<sjg1>
Tartarus: Yes, I fully understand what you are looking for, but that isn't what my series does, unfortunately. I looked through my notes and unfortunately don't have a record of what board I was using. It might come to me if I keep thinking about it