warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
alperak has joined #u-boot
warpme has joined #u-boot
prabhakalad has joined #u-boot
slobodan has joined #u-boot
sszy has joined #u-boot
Guest19 has joined #u-boot
<Guest19>
Can anyone give me a tip, what to do if DHCP command doesn't retrieve an IP?
<quinq>
Fix network
<quinq>
Guest19, question is a bit vague
ikarso has joined #u-boot
<quinq>
But you could do a debug build (network driver / bootp commands), maybe you'll get more diagnosis there, if your network setup is sound from the outside perspective
<quinq>
Maybe your env doesn't select the correct interface? (and you have fallback on other interfaces disabled)
<Guest19>
quinq I am sorry if I haven't express correctly. Could you please elaborate your first point. Should I add debug symbols or are you mean to say something else? I thought DHCP command knows which interface it has to select. I haven't defined any interfaces in my envs. Should I add it?
<zenomat>
hello everyone, i hope this is the proper channel. i am trying to compile a uboot source tree (https://github.com/Ingenic-community/uboot-xburst) for ingenics xburst cpu. i am facing severl problems with the build process. I circumvented some, the hacks can be seen here: https://0x0.st/X6TW.diff . Now I am stuck on `.tbss mismatches non-TLS reference` (full log here: https://0x0.st/X6Ty.txt). I would really apprechiate any pointers you can give me
<quinq>
Guest19, I meant in your U-Boot build, you can define DEBUG usually, and you get diagnosis messages that the developer decided to put there
<quinq>
Regarding the env, if you have several interfaces, you need to tell U-Boot which one you want to use
<Guest19>
Guest19 I'll try with debug option. I just have one interface eth0
<quinq>
ok
goliath has joined #u-boot
Guest19 has quit [Quit: Client closed]
mmu_man has joined #u-boot
mckoan is now known as mckoan|away
<marex>
zenomat: at least the ci20 jz4780 is upstream, but whether it still works beyond compiling correctly is unclear
Guest19 has joined #u-boot
slobodan has quit [Remote host closed the connection]
<zenomat>
ah thank you. i might try that. compiling is absolutely sufficient for now
Guest19 has quit [Quit: Client closed]
Guest19 has joined #u-boot
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<Guest19>
quinq I have added debug logs with log level 9. I see hardware initialisation logs however nothing except Bootp Broadcast if I call dhcp.
<quinq>
I can see several debug() calls in net/bootp.c
<quinq>
like debug("dhcp_send_request_packet: Sending DHCPREQUEST\n");
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
slobodan has joined #u-boot
monstr has quit [Ping timeout: 252 seconds]
slobodan has quit [Read error: Connection reset by peer]
eballetbo has quit [Quit: Connection closed for inactivity]
Stat_headcrabbed has joined #u-boot
jfsimon1981 has joined #u-boot
slobodan has joined #u-boot
warpme has joined #u-boot
slobodan has quit [Remote host closed the connection]
slobodan has joined #u-boot
Stat_headcrabbed has quit [Quit: Stat_headcrabbed]
Stat_headcrabbed has joined #u-boot
jkt has joined #u-boot
<jkt>
hi there, I'm using Clearfog Base (mvebu, armada a388). We've been building some random git snapshot of u-boot (2021.01-900-..., WIP/28Jan2021), so I'm upgrading to v2024.10, via Buildroot
<jkt>
and I'm getting an error message "Didn't find the file 'spl/u-boot-spl.bin' in ... which is mandatory to generate the image", and that message about DDR3 training code
<jkt>
where do I get that file from?
<jkt>
it seems that in the past I have not needed it, ever, and now it's telling me to extract it from an existing bootable image, which sounds strange to me
<jkt>
ah, I guess I need buildroot's BR2_TARGET_UBOOT_FORMAT_CUSTOM_NAME="u-boot-with-spl.kwb", OK
mmu_man has quit [Ping timeout: 244 seconds]
dsimic has quit [Ping timeout: 264 seconds]
dsimic has joined #u-boot
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
davlefou has quit [Ping timeout: 265 seconds]
joeskb7 has quit [Quit: Lost terminal]
warpme has joined #u-boot
warpme has quit [Client Quit]
davlefou has joined #u-boot
mmu_man has joined #u-boot
warpme has joined #u-boot
<marex>
so it seems
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
vfazio_ has quit [Remote host closed the connection]
ikarso has quit [Quit: Connection closed for inactivity]
fatal has quit [Remote host closed the connection]
fatal has joined #u-boot
<Tartarus>
But, qemu doesn't have a bounce buffer?
<Tartarus>
That's a specific foot-gun that some platforms enable, and needs to be under an LMB
<Tartarus>
That option should be select'd based on ARCH/SOC or similar and not bool'd
<Tartarus>
or def_bool y if ...
<Tartarus>
xypron, apalos ^^^
mmu_man has quit [Ping timeout: 252 seconds]
<xypron>
Tartarus: we have bounce buffers at the block driver level. This should replace the EFI bounce buffer in future.
ikarso has joined #u-boot
<Tartarus>
xypron: OK, what's missing for just removing EFI_LOADER_BOUNCE_BUFFER ?
<sjg1>
Tartarus: Yes, you were just asking for the specific command I used, so there it is
<Tartarus>
sjg1: Right. But that's ignoring the specific feedback you got with that example.
<sjg1>
Tartarus: The bounce buffers currently use malloc(), so should perhaps move into the reservation system
<Tartarus>
That's not a general feature, if you turn that on without having broken hardware, you should expect failures
<sjg1>
Tartarus: Feedback about the user not being able to do anything about it?
<Tartarus>
sjg1: The generic BOUNCE_BUFFER option?
<sjg1>
Tartarus: OK. Yes but as Heinrich mentions, the malloc() is small on many boards. I can only imagine that is why Alex went with this approach?
<Tartarus>
sjg1: No? If the user enables the bounce buffer on hardware that does not need the bounce buffer, the problem is they should not have enabled the bounce buffer (which the help explains what it's for), and I'm further saying it should be select'd / similar and not prompted for
<Tartarus>
As it's a binary choice, your hardware needs it, or your hardware needs to not have it.
<Tartarus>
sjg1: OK, but there was an answer in v2
<Tartarus>
> It supports reading multiple blocks. If not all blocks fit into the memory that can be assigned via memalgn, the block layer coud separate the blocks into chunks. This would replace the EFI bounce buffer.
<Tartarus>
Ah OK, yes it could do that.
<Tartarus>
Regards,
<Tartarus>
Simon
<Tartarus>
Which is also what xypron said just now when I said we should not be asking the user about that option. That option needs to be removed, and EFI_LOADER should be able to be using the normal bounce buffer we have that's not at all EFI_LOADER related
<sjg1>
Tartarus: Which is what I said on my patch...
<Tartarus>
Removing code and making EFI_LOADER more tightly coupled with other U-Boot functionality is good
<Tartarus>
Is v3 doing that then, sorry?
<sjg1>
So yes someone should take the bounce buffer and make it have a limit on allocations (not quite sure what) and break up the transfers. It also needs to do the allocation in advance, so we know it won't fail. Probably the same allocation should be used for all device. I can file an issue if you like
<sjg1>
All of this is completely sideways to the patch I sent though, which was to give an example of why EFI should not be doing such allocations
<Tartarus>
I assume that bounce buffer predates the more generic one that marex did?
<Tartarus>
But now I'm lost as to why you're doing something other than gleeful removal of EFI_LOADER code and making it instead use the generic U-Boot functionality
<Tartarus>
If you want to file an issue on the efi subtree instead about removing EFI_LOADER_BOUNCE_BUFFER in favor of using BOUNCE_BUFFER, please do.
<Tartarus>
But also, this isn't an example of "discussion died out", the discussion ended with the maintainer saying that the area you see a problem in should be removed and the generic functionality used, yes?
<sjg1>
Tartarus: No, Marek's had been there for about four years
<Tartarus>
sjg1: OK? I see commit messages about EFI_LOADER_BOUNCE_BUFFER from six years ago
<Tartarus>
Now, generic is still older
<Tartarus>
So then yes, it shouldn't have come in to start with, unless perhaps it just wasn't tied to the block uclass? I don't know.
<Tartarus>
But again, the key point here is, discussion didn't just die off, a solution was suggested
<sjg1>
Never mind, it doesn't really matter
<Tartarus>
Of the type that frankly you had spent a lot of time arguing for in general, that EFI_LOADER needs to be more tightly integrated with generic U-Boot functionality
<sjg1>
Yes I think using the generic bounce buffer is best
<Tartarus>
OK, great!
<sjg1>
Yes. So are you happy with the example I gave?
<Tartarus>
Only if you're also happy with the solution to that problem that xypron said
<sjg1>
BTW I am not bothered about that particular patch, as I said in the conversation. I was just trying to get people to see my point about EFI allocating things 'in space'
<Tartarus>
You're saying there's a systemic problem, when I believe xypron and apalos are saying no, there's a single place, and agreeing it shouldn't do that
<sjg1>
Yes the solution seems fine to me, as I said on the patch. I am certainly keen to move EFI things to generic U-Boot things
<sjg1>
Also I'm about to send v4 of the series, so I hope it will get a serious look
<sjg1>
Well it is systemic, in the sense that various things use the EFI allocators before EFI boots
<sjg1>
I can give some more examples...
<sjg1>
copy_fdt() is a bit strange, since it would be better to use the fdt where it is (with the 12KB of breathing room)
<sjg1>
efi_disk_add_dev() is called whenever a new disk / partition is created, and it allocates quite a few blocks
<sjg1>
efi_init_variables() creates some space for variables
alperak has quit [Quit: Connection closed for inactivity]
<sjg1>
efi_tcg2_register() allocates an event log (which I'd like to move to a more generic allocation, i.e. bloblist)
<sjg1>
smbios and ACPI are OK, since they use memalign(). But as mentioned I'd like to move smbios to bloblist too
<Tartarus>
But all of that is within the normal top down pool growth, and not semi-arbitrary locations, yes?
<sjg1>
Yes, that's right, below the stack, in the image region. That really is all I am trying to clean up. It shouldn't be such a big deal. That's also why I sent the README patch, since people seemed not to have read it
slobodan has quit [Ping timeout: 252 seconds]
<Tartarus>
I mean, that gets back to what I was saying too. The README describes the design goals 25 years ago. That is not 100% binding today.
<Tartarus>
I'll look at your series, like I said
<Tartarus>
But also please think about just considering the well defined and not arbitrary growth downward from the stack boundary, once it's also under lmb, just part of the u-boot memory region too
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<Tartarus>
"app starts", or the various phrases we tried using are artificial lines in the sand, to use a different euphimism
<Tartarus>
Be it an EFI app, or an ELF application, or something we fire off via bootm, there are hard points where U-Boot is done, and needs to have performed X/Y/Z actions, and then otherwise U-Boot is still otherwise responsible for transition to the next phase.
<Tartarus>
Some of those payloads may be more and some less responsive to the API we use to communicate with them
<sjg1>
Before the artificial line in the sand, I would like all used memory to be in the U-Boot region. After that, I believe it is fine to use whatever memory there is
<Tartarus>
entirely unrelated, "b4 mbox" to the rescuce
<Tartarus>
That, rather than digging about in patchwork to see where the hell a patch is, is so so so much quicker
<xypron>
Tartarus: If you launch a kernel with bootm you have reached the point of no return. If you launch an EFI app it may return. E.g. in the GRUB console or the EFI shell you may type exit to return to the U-Boot console. For EFI applications the point of no return is ExitBootServices.
<Tartarus>
xypron: Agreed
<Tartarus>
I don't see what the artificial line gets us