ikarso has quit [Quit: Connection closed for inactivity]
mmu_man has quit [Ping timeout: 264 seconds]
jclsn has quit [Ping timeout: 260 seconds]
jclsn has joined #u-boot
naoki has quit [Quit: naoki]
enok has joined #u-boot
enok has quit [Client Quit]
mrnuke has joined #u-boot
tpw_rules has quit [Server closed connection]
tpw_rules has joined #u-boot
naoki has joined #u-boot
enok has joined #u-boot
enok has quit [Quit: enok]
mrnuke has quit [Ping timeout: 246 seconds]
enok has joined #u-boot
mrnuke has joined #u-boot
enok has quit [Ping timeout: 260 seconds]
mrnuke has quit [Ping timeout: 256 seconds]
mrnuke has joined #u-boot
mrnuke has quit [Ping timeout: 252 seconds]
mrnuke has joined #u-boot
joeskb7 has quit [Ping timeout: 268 seconds]
mrnuke has quit [Ping timeout: 268 seconds]
mrnuke has joined #u-boot
njha has quit [Server closed connection]
njha has joined #u-boot
mrnuke has quit [Ping timeout: 264 seconds]
monstr has joined #u-boot
mrnuke has joined #u-boot
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #u-boot
mrnuke has quit [Ping timeout: 252 seconds]
mrnuke has joined #u-boot
goliath has joined #u-boot
mrnuke has quit [Ping timeout: 252 seconds]
mrnuke has joined #u-boot
frieder has joined #u-boot
warpme has joined #u-boot
bq has quit [Server closed connection]
bq has joined #u-boot
<calebccff>
CounterPillow: ohh no lol
<derRichard>
CounterPillow: the rhel kernel is not closed source
mckoan|away is now known as mckoan
ldevulder has joined #u-boot
sszy has joined #u-boot
alperak has joined #u-boot
fionera has quit [Server closed connection]
fionera has joined #u-boot
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
warpme has joined #u-boot
enok has joined #u-boot
prabhakalad has quit [Quit: Konversation terminated!]
prabhakalad has joined #u-boot
enok has quit [Ping timeout: 240 seconds]
wooosaiiii has quit [Ping timeout: 246 seconds]
mmu_man has joined #u-boot
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
warpme has joined #u-boot
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
warpme has joined #u-boot
<marex>
derRichard: it would be if RH could close it
ikarso has joined #u-boot
enok has joined #u-boot
enok has quit [Ping timeout: 268 seconds]
alpernebbi has quit [Ping timeout: 255 seconds]
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
tlwoerner has quit [Ping timeout: 264 seconds]
tlwoerner has joined #u-boot
warpme has joined #u-boot
alpernebbi has joined #u-boot
naoki has quit [Quit: naoki]
monstr has quit [Remote host closed the connection]
rvalue has quit [Ping timeout: 268 seconds]
rvalue- has joined #u-boot
<paulbarker>
calebccff: As I commented on the article, supporting a kernel build small enough to fit in the on-chip SRAM available before DRAM is initialised on many embedded processor would have a massive, and likely unwelcome, complexity and maintenance cost
<paulbarker>
Maybe you could do U-Boot falcon mode -> nmbl -> real kernel, but why? If you're going to use U-boot for the first stage, may as well keep it for the second stage as well
<paulbarker>
I don't expect nmbl to get much support outside of a narrow market
rvalue- is now known as rvalue
monstr has joined #u-boot
<derRichard>
marex: where comes all this hate from?
thopiekar has quit [Quit: Likely restarting quassel...]
<LetoThe2nd>
in the board file if there are definitions like stdin=serial,... stdout=serial,... stderr=serial,... - can I disable u-boot caring for the serial port by removing the "serial," parts of the settings? is that a reasonable approach?
<LetoThe2nd>
to be more precise: I am on a rpi-cm based platform where the hw needs the serial port to access some subsystems, so enable_uart=1 is set in the config.txt, but u-boot should just disregard it completely.
monstr has quit [Ping timeout: 252 seconds]
tgamblin has quit [Remote host closed the connection]
<rfs613>
back in 1998 or so, the NetWinder firmware also used a linux kernel, which then loaded a linux kernel from disk info RAM, and "rebooted" into the second kernel
<derRichard>
marex: regarding redhat
<marex>
derRichard: there is no hate, just oh well ...
<rfs613>
it wasn't quite kexec, i think that came a bit later
<marex>
rfs613: clearly we need to find the oldest linux-as-bootloader in existence now :)
<rfs613>
marex: all i can remember is tha kernel was too big to fit easily. There was a linux-tiny project that helped trim off stuff. But it was a battle to fit into the 1MB flash chip.
<rfs613>
marex: yeah there were probably others doing similar things, even before the NetWinder...
<marex>
iirc zaurus did similar thing, it was some linux 2.4 kernel module as far as I recall, but maybe that was already some proto-kexec
<rfs613>
marex: netwinder firmware used a 2.0 kernel...the 2.2 and later 2.4 were way too big
d4ve has quit [Server closed connection]
d4ve has joined #u-boot
<marex>
rfs613: wow :)
<rfs613>
and there was some very creative hackery to start a single userspace task, which was the command interpreter that you'd interact with.
<sng>
sjg1: hi Simon, i am trying to get size imact of some patches with buildman. the document says that this can be done with -SB option. the build does go through but i do not get any size impact summary as is shown in the document
<sng>
am i missing something ? i use the following command - './tools/buildman/buildman stm32mp15_dhcom* -o /tmp/build -SBs'
<sng>
tried without the -s option as well, but no change in the output
<sjg1>
sng: Tartarus: Buildman was partially broken by a patch, but I believe Tom reverted it already. I am going to rebase and resend the earlier patch, which I hope won't have this problem
<marex>
sng: do you see a problem with the dhcom ?
<sng>
marex: no, i am building one of the boards which does not have efi enabled to get the size impact of the lmb patches
<sng>
sjg1: okay, can you point me to the patch, so that i can apply it locally and see if that helps.
<sjg1>
sng: e13fcae3fce Revert "buildman: Always use the full path in CROSS_COMPILE"
<sng>
sjg1: so this patch is part of the branch that i am testing on
<pbrobinson>
Tartarus: a little while back you mentioned in a thread that the CONFIG_LED_STATUS was obsolete, is there a replacement or is it "TBD"?
<sjg1>
sng: Oh dear, then I don't know what is going on. It works for me (TM)
<sng>
sjg1: mostly me doing something wrong. i haven't used buildman much earlier. can you please paste the command that you use for checking the size changes with buildman
<sng>
sjg1: my patches are on top of the current master branch. i also tried without the -b option, which the documentation says makes buildman use the source tree. but that too does not help
<Tartarus>
Assuming current branch has the changes, and "git branch -u" has been done to point at the correct upstream branch, uboot-size-test.sh --all stm32mp15_dhcom
<Tartarus>
And wait a moment
joeskb7 has joined #u-boot
<sng>
Tartarus: thanks much
<sjg1>
sng: Your first command probably does nothing, since -s puts it into 'summary' mode
<sjg1>
sng: Your second command does nothing since there is no build yet
monstr has joined #u-boot
<sjg1>
If you try again with the -sS then you should see the results of the build in your second command
<sjg1>
sng: I just sent a new version of alist...but didn't bring in your additions, so you will still need patches for those (although I might have comments on them)
<marex>
sng: ah ok
<sjg1>
sng: Actually, I made one other change, so sent v3
<sng>
sjg1: okay, will check your updated version of alist patches. if you can comment on my patches, i will incorporate the changes in my next version
<pbrobinson>
Tartarus: do you have an example config that's using drivers/led/ for status? Basically I had this on my todo for various devices so I thought I'd start by looking at converting the pinephone config
<sng>
sjg1: that is strange indeed. although i suspect there is some configuration that you have set up which is missing on my end
<sng>
sjg1: btw, if you have any comments on my lmb patches, it'd be great if you can post them
<sjg1>
sng: I don't have a lot of time this week as I am trying to get the UPL stuff posted...but will do
<sng>
sjg1: okay, thanks
alpernebbi has quit [Ping timeout: 252 seconds]
<sng>
sjg1: btw, it turns out that the buildman build creates a .bm-work dir which has the builds. that was stale. removed that directory as well. did a fresh build followed by the -sB, and now it does work.
<Tartarus>
pbrobinson: Not off-hand, I'd have to use tools/qconfig.py to build the db and then query it to see, if just greping defconfigs didn't help
alpernebbi has joined #u-boot
<sjg1>
sng: That's odd. It can happen if you did an initial build without a toolchain present? You can work around it with -f
vagrantc has joined #u-boot
monstr has quit [Remote host closed the connection]
mckoan is now known as mckoan|away
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<MrTrueDev>
ARM trusted firmware seems to be having trouble finding the U-Boot device tree. I've been trying to insert printf statements in the early stages of U-Boot to print the address of gd->fdt_blob, but so far, I've just been getting NULL. Any hints on when gd->fdt_blob gets populated?
<MrTrueDev>
I've got a PineA64LTS board if it matters
niska has quit [Quit: Leaving]
mmind00 has quit [Server closed connection]
mmind00 has joined #u-boot
niska has joined #u-boot
crb_ has quit [Server closed connection]
eballetbo has quit [Quit: Connection closed for inactivity]
___nick___ has quit [Ping timeout: 246 seconds]
ex-parrot has quit [Quit: _b]
ex-parrot has joined #u-boot
naoki has joined #u-boot
enok has joined #u-boot
enok has quit [Quit: enok]
enok has joined #u-boot
enok has quit [Ping timeout: 246 seconds]
alperak has quit [Quit: Connection closed for inactivity]
mmu_man has quit [Ping timeout: 246 seconds]
enok has joined #u-boot
mmu_man has joined #u-boot
edwinistrator231 has joined #u-boot
edwinistrator23 has quit [Ping timeout: 268 seconds]
edwinistrator231 is now known as edwinistrator23
ldevulder has quit [Quit: Leaving]
MrTrueDev has quit [Quit: Client closed]
mmu_man has quit [Ping timeout: 252 seconds]
mmu_man has joined #u-boot
MrTrueDev has joined #u-boot
<MrTrueDev>
I suspect there may be a bug in the PineA64Lts port of Uboot. Namely, in u-boot/common/spl/spl.c, spl_image.os never seems to get properly set, it remains zero. This means that in the following if statement switches, U-Boot never preforms an fdt fixup. I think its just chance that BL31(usually ATF) ends up finding the device tree...