<per1cycle_>
is there any changlog for release 2024-10?
sakman_ has joined #u-boot
sakman has quit [Read error: Connection reset by peer]
Guest85 has joined #u-boot
sakman_ is now known as sakman
<sng>
xypron thank you and all other reviewers for reviewing the patches. the patches evoked some strong opinions for sure, but it was good fun :)
monstr has joined #u-boot
<mps>
per1cycle_: git log (I asked same after 2024.10 released though I knew there is no such thing)
<mps>
Debian have Changelog related to debian but maybe reading it could give some info
ldevulder has joined #u-boot
<apalos>
So, to all pls. We made big changes in U-Boot's memory management and the TCP stack
<apalos>
The memory management is included by default, if you see any problems pls yell so we can fix it before 2025.01
<apalos>
the TCP stack changes are optional, but generally speaking behave better than the default TCP stack
<apalos>
So if you can enable LWIP and do some testing on top, it would be much appreciated
<apalos>
same goes for crypto, if you can run your boards enabling mbedTLS, it uses an external library for crypto now
<LeSpocky>
apalos: did I understand corretly lwIP does not work with DM_ETH? then how should that be tested on real hardware?
<apalos>
LeSpocky: it does that's probably a leftover on the cover letter
<apalos>
We have tested it on a number of boards
<LeSpocky>
nice to know :-)
<apalos>
generally speaking it behaves a lot nicer
<apalos>
TCP ACKs, SACKs etc that used to be buggy are a lot more reliable
<LeSpocky>
I'm all in for using a well tested IP stack
<apalos>
but it's a big change anyway, so we need more testing!
<apalos>
yea, that was the reason for picking up mbedTLS for crypto and l;wip for TCP
<LeSpocky>
^^
<apalos>
I mean our TLS code was mported from the kernel ~8years ago
<apalos>
and I am not saying it was bad, it was just unmaintained
<apalos>
it's way easier to pick it up from a project that's used, well mainatined, has CVEs etc
<LeSpocky>
just using tftp for bootstrapping our boards, but I will test it in the next weeks
<LeSpocky>
right
<apalos>
thanks
<apalos>
LeSpocky: oh and there's an end goal
<LeSpocky>
o.O
<apalos>
With mbedTLS & lwip we can enable HTTPs downloads relatively easy
<apalos>
I'll send the patches enabling it within the week
<apalos>
The idea was that we have a lot of machinery in EFI now, to automatically install distros
<apalos>
So basically you can ship a board with just the firmware, which automatically installs the OS the first time it boots
<LeSpocky>
wow
sszy has joined #u-boot
<Guest85>
I'm reading MAC address from EEPROM and write in ethaddr env variable in board_late_init. One I printenv for it in U-Boot console it gives me all zeros. Can you please tell me what is over writing
<apalos>
also that out of memory print,, is all over the place,
<apalos>
why are those prints from EFI?
<apalos>
well the "ERROR:" one is
<calebccff>
apalos: only "out of memory" string with no newline which could be relevant :P
<apalos>
well that's the weird one
<apalos>
I cant grep a print without \n
<calebccff>
apalos: memmap fails with "Error: Cannot initialize UEFI sub-system, r = 9", but i stacktraced the alloc failure... https://p.calebs.dev/f36849@raw
<calebccff>
apalos: I did $ rg "\"out of memory\""
<apalos>
'ERROR: Out of memory' does indeed come from EFI
<apalos>
ok, then something does indeed fail to init
<apalos>
does the rb2 have a similar memory layout?
<apalos>
My first thought is that somehow we dont account for all the memory and we ideed "run out"
<apalos>
the backtrace helps btw thanks
<calebccff>
apalos: really no idea what's up, the allocation simply works on rb2 and not on rb3gen2
<calebccff>
must be some quirk with the memory map
<apalos>
yes
<apalos>
it's either an oversight from lmb or the map on that was always borked and it unearthed now
<apalos>
but whatever it is we need to sort it quickly
<apalos>
ok, there's a lot of holes in that map :<
<apalos>
anyway, got to run now, I'll ping you tomorrow and we can sort it
<calebccff>
sounds good
<apalos>
hrrm if you can dump the efi memory map pre -lmb patches that would help
ikarso has quit [Quit: Connection closed for inactivity]
<apalos>
and can you check lmb_add() in lmb_add_memory() fails at any point on your board?
<xypron>
Tartarus: I wonder why CONFIG_NXP_ESBC ended up in the main menu. Shouldn't we put this under 'Security support'?
<Tartarus>
xypron: Because it's part of arch/Kconfig.nxp for arm and powerpc shared stuff, yeah. If you can safely move it around somewhere else please do
<xypron>
orangepi_pc_defconfig puts it into the main menu.
<Tartarus>
I think it just didn't get past stage one "move it out of arch/arm and arch/power being duped" or so
<xypron>
That is sunxi not NXP
<Tartarus>
Oh, so just the general lack of depends on ...
<Tartarus>
which is hard for some of these parts
<Tartarus>
If you want to figure out some "depends on" line that doesn't break the platforms, please do
prabhakalad has quit [Ping timeout: 252 seconds]
prabhakalad has joined #u-boot
<xypron>
apalos: I just booted PineA64 LTS and OrangePi PC with the LMB changes and found not problems there. calebccff's problem seems to be board specific.
xroumegue has quit [Quit: WeeChat 2.3]
xroumegue has joined #u-boot
xroumegue has quit [Client Quit]
xroumegue has joined #u-boot
slobodan has quit [Ping timeout: 248 seconds]
prabhakalad has quit [Ping timeout: 246 seconds]
prabhakalad has joined #u-boot
mmu_man has quit [Ping timeout: 252 seconds]
ldevulder has quit [Quit: Leaving]
mmu_man has joined #u-boot
<xypron>
apalos: host bind 0 disk.img after efi_init_obj_list does not cause an EVT_DM_POST_PROBE. So in the EFI sub-system we do not see the drive. We should ensure that binding a block device leads to probing.