<Tartarus>
sjg1: Our kbuild port is un-upgradable really. I managed to get a v4.20 resync done but going to v5.0 is (a) another one with over 100 patches and (b) shows other missed older upgrades. All for, well, I don't really see _what_ now. It was a good idea at the time, and when Yamada-san was doing both U-Boot work and part of the linux kernel kbuild team, it worked great. Now? Not so much :(
<Tartarus>
ninja sounds bad, yeah, but cmake+make is pretty nice in general.
<Tartarus>
Looking at my local DM_USB migration branch (one with the most board removals applied), it's down to 3500 symbols and that's just needing to pick a group and do it, and repeat
<Tartarus>
re kbuild, it's tons and tons of changes for things within the kernel and other issues we simply don't have. Our hard problem is building tpl, spl and main U-Boot from a single set of code, with a few changes here and there, which will make any other system also a pain.
<sjg1>
Tartarus: Hmm yes well that's the way it goes, when people own and push things all is well :-)
<sjg1>
I have no idea about kbuild but I quite like our simple makefiles. Even cmake ones seem to have a lot of unnecessary stuff. Having said that, it is certainly able to do just about anything, perhaps without all the special rules we have. I'm just not sure
georgem has quit [Quit: Connection closed for inactivity]
<milkylainen>
sjg1: I saw your suggestion on the mailing list. But I've reverted back to u-boot 2021.04. Can't get u-boot to start in VBox UEFI after 07-rc1. Also 07-rc1 won't start a kernel with zboot. 21.04 will. I have not bisected yet. Atleast now I have a happily booting setup.
matthias_bgg has joined #u-boot
alpernebbi has joined #u-boot
sszy has joined #u-boot
tnovotny has joined #u-boot
mmu_man has joined #u-boot
pbrobinson_AFK is now known as pbrobinson
mranostaj has quit [Remote host closed the connection]
mranostaj has joined #u-boot
frieder has quit [Ping timeout: 268 seconds]
frieder has joined #u-boot
mmu_man has quit [Ping timeout: 268 seconds]
frieder has quit [Ping timeout: 272 seconds]
redbrain has joined #u-boot
Wizzup has joined #u-boot
mmu_man has joined #u-boot
Pali has joined #u-boot
frieder has joined #u-boot
akaWolf has quit [Ping timeout: 268 seconds]
akaWolf has joined #u-boot
davlefou_ has joined #u-boot
matthias_bgg is now known as matthias_bgg2
matthias_bgg2 has quit [Quit: Leaving]
matthias_bgg has joined #u-boot
matthias_bgg2 has joined #u-boot
matthias_bgg2 has quit [Remote host closed the connection]
matthias_bgg has quit [Client Quit]
matthias_bgg has joined #u-boot
georgem has joined #u-boot
mmu_man has quit [Ping timeout: 268 seconds]
mmu_man has joined #u-boot
smartin has joined #u-boot
francis_ has joined #u-boot
<francis_>
Hi everyone.
<francis_>
I hope you are fine and the same for your families.
<francis_>
I ran into a "bug" with fw_setenv and setenv.
<francis_>
I used fw_setenv in a bash script and I did a mistake calling it with fw_setenv "$key" "$value" where $key was empty, so I finished with the following environment:
<francis_>
"="$key""
<francis_>
Which leads to problem parsing it once in U-Boot.
francis_ is now known as Guest1802
<Guest1802>
Hi everyone
<Guest1802>
I hope you are fine and the same for your families.
<Guest1802>
I ran into a "bug" with fw_setenv and setenv.
<Guest1802>
I used fw_setenv in a bash script and I did a mistake calling it with fw_setenv "$key" "$value" where $key was empty, so I finished with the following environment:
<Guest1802>
=$key [replace $key with its value]
<Guest1802>
Which leads to problem parsing it once in U-Boot as there is no name for the key.
<Guest1802>
Is this normal? I mean what is the use case where we can have empty key?
<Guest1802>
I wanted to ask this on this channel before trying to add a check for length and submit it to mainline U-Boot to avoid other people having this problem in the future.
GNUtoo has joined #u-boot
tlwoerner has quit [Remote host closed the connection]
tlwoerner has joined #u-boot
tnovotny has quit [Quit: Leaving]
<sjg1>
milkylainen: OK, so just to check, you are running in x86 vbox, booting UEFI and then UEFI is starting U-Boot, then U-Boot starts a kernel? A bisect would help, or if you can share any info on how to set it up
redbrain has quit [Ping timeout: 272 seconds]
<marex>
darn ... a patch I posted in 2018 got ignored on "does it have a test" and a year later the same fix was applied with a CVE :(
<Sout>
the cve was the test :P
<milkylainen>
sjg1: x86 vbox, uefi stubbed uboot. U-boot starts a regular bzImage. I'd be happy to share all configuration. But bisecting right now is not that high up on the priority list. Need to catch up first after being stuck for so long.
<sjg1>
milkylainen: OK thanks, will give it a try sometime
akaWolf has quit [Ping timeout: 268 seconds]
monstr has quit [Remote host closed the connection]
fdanis is now known as fdanis_away
frieder has quit [Remote host closed the connection]
matthias_bgg has quit [Read error: Connection reset by peer]
matthias_bgg has joined #u-boot
akaWolf has joined #u-boot
mmu_man has quit [Ping timeout: 265 seconds]
redbrain has joined #u-boot
frieder has joined #u-boot
frieder_ has joined #u-boot
frieder has quit [Ping timeout: 265 seconds]
frieder_ has quit [Remote host closed the connection]
<Guest1802>
Have a nice day.
Guest1802 has quit [Quit: Konversation terminated!]
<freemangordon>
Pali: Wizzup: did I miss something? Sorry, I was on holiday, just came home.
<Pali>
nothing
<freemangordon>
Pali: ok. I've read through the mails and to me it seems the maintainers have left us with the only option to migrate to DT.
<freemangordon>
marex: do I get it right that there is nothing that can convince you to take my "DM_USB: allow building without OF_CONTROL" patch and the only thing we can do to keep N900 from being dropped is to migrate to DT?
<marex>
freemangordon: er, slow down a bit
<marex>
freemangordon: the problem seems a bit larger than the USB
<marex>
it seems it is possible to reduce the u-boot size by disabling ebbr and efi to just ... fit ...
<marex>
that's what sjg1 suggested anyway
<marex>
but I think you will run into size issues repeatedly, so the better solution would be to boot with nolo->spl->u-boot, which is future-proof
<marex>
(and I dont think much of this discussion is even about USB anymore)
<freemangordon>
well, not really, as we already (tried) to explain, this will just increase the complexity. Also, we shall keep it backward-compatible - u-boot is packaged for Fremantle(the original N900 OS) for 10 years or so.
<marex>
basically we tried to get rid of as many ifdefs as possible over time, so I'm not particularly inclined to re-add them and undo that effort
<freemangordon>
if the size issue comes from the fact that OF_CONTROL pulls things not really needed, I'd rather fix that first
<freemangordon>
marex: yes, thats understandable
<marex>
freemangordon: so, what is the problem with packaging the u-boot for fremantle and making it compatible ?
<marex>
just stick u-boot img into the filesystem and SPL where the old u-boot used to be, that should be enough
<marex>
and if you want to downgrade, rewrite the SPL back with old u-boot
<marex>
that should work
<freemangordon>
not really, what if we decide to flash another OS?
<freemangordon>
this will lead to unbootable device
<marex>
freemangordon: do you rewrite the entire partition in that case ?
<freemangordon>
yes
<marex>
freemangordon: look at falcon boot
<freemangordon>
marex: see, lets not reinvent the wheel
<marex>
freemangordon: it allows the SPL to boot the kernel directly
<marex>
freemangordon: and only drop into u-boot (the shell) if some button combination is pressed
<freemangordon>
we already have a working sequence, lets stick to it and see what can be done for it
<freemangordon>
size limitation can be overcome by enabling -mthumb, hopefully. Or by optimizing the build scripts to not include stuff that's not needed
<marex>
freemangordon: except then you will keep running into those size limitations as you keep updating
<marex>
I'm not happy about the bloat though ... paging sjg1
<freemangordon>
well, we have a bigger and particular issue now - DM :)
<freemangordon>
lets worry about future when it comes to it
<marex>
btw DM is optional in SPL
<Wizzup>
One of the problems is that the flashing tools cannot write anything to eMMC I believe, which is what makes it a little more tricky to flash u-boot if it requires eMMC access
<freemangordon>
but is not in u-boot, so we are back to swuare one
<freemangordon>
*square
<freemangordon>
Wizzup: SPL is really a nogo, IIUC. Also, I don;t think it is really needed
<marex>
so, why is SPL a no-go ?
<freemangordon>
because it doesn;t solve the particular issue we have - DT migration
<marex>
it allows you to boot kernel and drop into u-boot only if needed, plus it doesnt mandate DM and your size issue is not present anymore forever
<marex>
freemangordon: it might make sense to zoom out a bit and look at the bigger picture
<marex>
freemangordon: I dont think Tartarus is gonna remove the n900 considering there is interest in maintaining it
<marex>
i.e. it is not as much on fire as you possibly think it is
<Tartarus>
freemangordon: Well, is there still a size problem with EFI_LOADER off, and without tacking if thumb does or doesn't work at this point?
<freemangordon>
Tartarus: with -mthumb and EFI_LOADER off, the binary is about 210k, so we have some room for DT blob
<freemangordon>
~40kB left
<Tartarus>
But since there's still an open question about thumb, what about just EFI_LOADER off?
<freemangordon>
without -mthumb it is too big (260kB iirc)
<Tartarus>
(Which isn't pulled in by OF_CONTROL, OF_CONTROL is a requirement of EFI_LOADER, which is also an intentional 'default y' but of course can be turned off)
<Tartarus>
Just a bit too big, OK. I guess testing out thumb really needs to be done.
<freemangordon>
it is just a bit too big, but this doesn;t include DT blob
<freemangordon>
I think -mthumb should not be a problem
<freemangordon>
we can issue PPA call in early stages if it turns out we have issues
<Tartarus>
Well, if we can enable and test thumb, it sounds like we don't have any other problem to solve here, make a DT and cleaning up (if needed/possible) the USB stuff that's being pulled in, but not required on a USB gadget only device, to not be pulled in, can be later.
<freemangordon>
Tartarus: I am not sure we have the experience to do the latter (clean-up the USB hostmode stuff)
<freemangordon>
it may turn out that with those parts removed, -mthumb might not be needed, however, this is a wild guess
<freemangordon>
can we get some help there?
<marex>
freemangordon: what is there to clean up in the USB hostmode stuff ?
<freemangordon>
marex: don't know, hostmode is not used at all on n900
<marex>
freemangordon: I thought the n900 could be used as a USB host too, no ? :)
<freemangordon>
no
<marex>
really ?
<Pali>
there are hw bugs
<marex>
the musb is OTG core, no?
<freemangordon>
well, ID pin is grounded
<marex>
doh
<freemangordon>
it is, but doesn;t function on n900
<Pali>
we were able to implement it in nokia 2.6.28 kernel with userspace helpers
<Pali>
it worked fine with patched nokia kernel
<Pali>
but required my power supply kernel drivers
<freemangordon>
Pali: but is not OTG anyways
<Pali>
plus my userspace scripts which did lot of magic
<freemangordon>
we are hacking through test mode registers and whatnot
<Pali>
with musb debug registers
<marex>
sounds like MUSB all right
<Pali>
yes, it was that musb test mode
<Pali>
but not only that
<Pali>
also it accessed ULPI (usb phy part) of some isp chip
<marex>
the ulpi is a bus between the USB controller and the PHY, apparently the ISP was external PHY for the MUSB
<Pali>
with that userspace script, some kind of auto detection worked, but user has to manually start enumeration (via script)
<freemangordon>
anyways, I doubt u-boot supports that and also we're not interested in implementing it as it is not really useful without OS
<marex>
u-boot does support host and otg modes
<marex>
but yes, I think in your case, gadget is more then enough
<Pali>
nobody is going to implement this kind of hack (again)
<marex>
famous last words
<freemangordon>
so, any hostmode code is just a dead-weight
<freemangordon>
marex: well it took 1 or 2 years back then