Tartarus changed the topic of #u-boot to: SOURCE MOVED TO https://source.denx.de/u-boot/u-boot.git / U-Boot v2021.07 is OUT / Merge Window is OPEN until 26 July 2021 / Release v2021.10 is scheduled for 04 October 2021 / http://www.denx.de/wiki/U-Boot / Channel archives at https://libera.irclog.whitequark.org/u-boot
Rusty_Almighty has quit [Ping timeout: 268 seconds]
macromorgan has quit [Quit: Leaving]
m-atoms has quit [Ping timeout: 264 seconds]
qschulz has quit [Remote host closed the connection]
zibolo has quit [Ping timeout: 265 seconds]
qschulz has joined #u-boot
zibolo has joined #u-boot
m-atoms has joined #u-boot
m-atoms has quit [Ping timeout: 245 seconds]
___nick___ has joined #u-boot
mmu_man has quit [Ping timeout: 265 seconds]
torez has quit [Remote host closed the connection]
mranostaj has quit [Ping timeout: 245 seconds]
mranostaj has joined #u-boot
LeSpocky has quit [Ping timeout: 265 seconds]
LeSpocky has joined #u-boot
milkylainen_ has quit [Ping timeout: 265 seconds]
Rusty_Almighty has joined #u-boot
<Rusty_Almighty> Hopefully I'll catch you tomorrow.
___nick___ has quit [Ping timeout: 246 seconds]
vagrantc has joined #u-boot
milkylainen_ has joined #u-boot
vagrantc has quit [Quit: leaving]
fdanis_away is now known as fdanis
guillaume_g has joined #u-boot
agust has joined #u-boot
tre has joined #u-boot
K900 has joined #u-boot
<K900> Hey guys
<K900> So what would the process be for getting a change into u-boot for someone who has never done that before?
<K900> It fixes booting NixOS and probably everything else that uses custom kernels/DTBs with u-boot on new Pi 4 revisions
<K900> (also ping samueldr)
<K900> There's a bit more context in the nixpkgs thread: https://github.com/NixOS/nixpkgs/issues/135828
<apalos> git format-patch HEAD~1
<apalos> ./scripts/checkpatch.pl <patch>
<apalos> git send-email --cc-cmd='./scripts/get_maintainer.pl --norolestats <your patch>' --to <anyone you want to add apart from what get_maintainer returned> <the patch>
<K900> So should I just send it in as is? I'm mostly worried about the state of the code, not the process
<apalos> dont mix definitions and code, iow move all the variables on top
<LeSpocky> K900: you can add --rfc to `git format-patch` if you're not sure and want to discuss the patch first
<K900> Thanks, I'll do that then
mckoan|away is now known as mckoan
<urja> yeah i've got no deep commentary here... the code is simple enough and you'll need some actual u-boot developers opinions on whether this is the right thing to do
<K900> Aight
<urja> only one that poked me is that ... maybe we have more specific debug/print levels than just printf() for all messages (or atleast, debug() or such for the normal success case maybe... again i'm not really an u-boot dev... just contributed a couple of fixes sometimes)
<K900> I'll send it in once I figure out how to get all the perl garbage git send-email requires
<K900> OK, I think it worked?
<K900> Your mail to 'U-Boot' with the subject
<K900> [RFC PATCH] rpi: copy the EMMC controller configuration from
<K900> firmware-supplied DT
<K900> Is being held until the list moderator can review it for approval.
<K900> I think that means it worked
<K900> Thanks!
<K900> Also pushed it to Github, rebased on master and with all the style fixes from checkpatch: https://github.com/K900/u-boot/commit/b3ffd90e4ae73a5787caf96ea85a0832399a06d1
<urja> ah yeah i think the list has first-submission moderation (even if you're subscribed), so as-expected
<K900> I'm also not subscribed so yeah
<K900> Actually I probably should subscribe at least for now...
<LeSpocky> ^^
frieder has joined #u-boot
<K900> Also, just to make sure, patches go on top of the master branch, correct?
<apalos> yea
<K900> I've actually built this one on top of 2021.04 since that's what NixOS currently ships
<LeSpocky> (or the latest tag)
<K900> But it applies on top of either
<apalos> unless there's a stable release pending were they end up in -next
<K900> So it should be fine
<K900> I've rebased it just to make sure
<LeSpocky> in general, if your patch is not on top of master or latest tag, you should add a note in the cover letter or below the ---
<K900> It is on top of master, so it should be good
<K900> > A*/
<K900> welp
<K900> fuck me I guess
<K900> Oh well, not going to resend the RFC for that, I've fixed it on Github
<K900> Thanks again y'all
BobBeck has quit [Quit: The Lounge - https://thelounge.chat]
MWelchUK has quit [Quit: The Lounge - https://thelounge.chat]
<K900> I'll keep an eye on the list for responses then
K900 has quit [Quit: Client closed]
GNUtoo has quit [Remote host closed the connection]
GNUtoo has joined #u-boot
BobBeck has joined #u-boot
MWelchUK50 has joined #u-boot
MWelchUK5 has quit [Quit: The Lounge - https://thelounge.chat]
MWelchUK50 is now known as MWelchUK5
MWelchUK5 has quit [Remote host closed the connection]
BobBeck has quit [Remote host closed the connection]
BobBeck has joined #u-boot
MWelchUK5 has joined #u-boot
MWelchUK5 has quit [Remote host closed the connection]
BobBeck has quit [Remote host closed the connection]
BobBeck has joined #u-boot
MWelchUK5 has joined #u-boot
MWelchUK5 has quit [Remote host closed the connection]
BobBeck has quit [Remote host closed the connection]
BobBeck has joined #u-boot
MWelchUK5 has joined #u-boot
MWelchUK5 has quit [Remote host closed the connection]
BobBeck has quit [Remote host closed the connection]
BobBeck has joined #u-boot
MWelchUK5 has joined #u-boot
BobBeck has quit [Remote host closed the connection]
MWelchUK5 has quit [Remote host closed the connection]
BobBeck has joined #u-boot
BobBeck has quit [Client Quit]
BobBeck has joined #u-boot
MWelchUK5 has joined #u-boot
samueldr has quit [Quit: Bridge terminating on SIGTERM]
LinuxHackerman has quit [Quit: Bridge terminating on SIGTERM]
edrex[m] has quit [Quit: Bridge terminating on SIGTERM]
kallisti5[m] has quit [Quit: Bridge terminating on SIGTERM]
cpackham[m] has quit [Quit: Bridge terminating on SIGTERM]
mvaittin has quit [Quit: Bridge terminating on SIGTERM]
kaji has quit [Quit: Bridge terminating on SIGTERM]
MWelchUK5 has quit [Quit: The Lounge - https://thelounge.chat]
bih420[m] has quit [Quit: Bridge terminating on SIGTERM]
[0x4A6F] has quit [Quit: Bridge terminating on SIGTERM]
jordemort has quit [Quit: Bridge terminating on SIGTERM]
MWelchUK5 has joined #u-boot
MWelchUK5 is now known as MWelchUK
MWelchUK has quit [Client Quit]
MWelchUK has joined #u-boot
zibolo has quit [Ping timeout: 265 seconds]
cpackham[m] has joined #u-boot
frieder_ has joined #u-boot
tnovotny has joined #u-boot
frieder has quit [Ping timeout: 245 seconds]
matthias_bgg has joined #u-boot
mvaittin has joined #u-boot
[0x4A6F] has joined #u-boot
LinuxHackerman has joined #u-boot
kaji has joined #u-boot
kallisti5[m] has joined #u-boot
jordemort has joined #u-boot
samueldr has joined #u-boot
edrex[m] has joined #u-boot
bih420[m] has joined #u-boot
smartin has joined #u-boot
Xavier7 has joined #u-boot
mmu_man has joined #u-boot
Xavier7 has quit [Quit: • IRcap • 8.72 •]
monstr has joined #u-boot
tre has quit [Remote host closed the connection]
<apalos> monstr: around?
<marex> another problem with xilinx stuff ?
<monstr> apalos: a little bit
<monstr> in regards of uefi?
<monstr> or acpi?
<apalos> monstr: so apparenly the xilinx boards are the only ones that are somewhat sane wrt to DT
<apalos> at least they are doing the right thing in board_fdt_blob_setup()
<monstr> I tried to cover all use cases
<apalos> But i am cleaning up that crud anyway, I was thinking of decoupling OF_BOARD and OF_SEPARATE
<apalos> (you did)
ladis has joined #u-boot
<monstr> I have added there that OF_BOARD_DTB_ADDR mostly because of qemu implementation
<apalos> but since I am decopuling those and I was wondering if it would make sense to move if (IS_ENABLED(CONFIG_SPL_BUILD)) { to the common code
<monstr> we took the same approach that qemu describe self at certain offset
<monstr> but it started to be used more widely that more or less u-boot binary doesn't have any DT inside or appended
<apalos> yea
<monstr> definitely make sense to move it to generic location because I was also took one part from it
<apalos> and that's a downhill from there since we try to treat 2 config options with a single function
<monstr> but you won't avoid writing own board_fdt_blob_setup() anyway
<apalos> So unless you cover all the cases in the board specific function, SPL might or might not work
<monstr> that amount of configuration is the problem
<apalos> in the xilinx case maybe not
<apalos> but in other boards, you can get away with it ..
<monstr> at least I am not aware about any configuration which is not working
<monstr> but it doesn't mean that there is not
<monstr> yes - our pain would be in NO_DDR options
<apalos> well the 'problem' you have in your board,
<apalos> is that you need to read the dtb differently depending on your config, (SPL or not)
<monstr> because couple of configurations don't have ddr from 0
<monstr> what do you mean by that different reading?
jwillikers has joined #u-boot
<apalos> board_fdt_blob_setup() on board/xilinx/common/board.c
<apalos> and if SPL is enabled you read it off a different location
<monstr> ok I got
<apalos> you have a single or dual config for those boards?
<apalos> e.g one with spl and one without?
<monstr> I don't think we are using configuration without SPL
<apalos> ok
<monstr> but SPL_BUILD symbol is there just when you build SPL
<apalos> let me see what I can do,
<monstr> not when you enable it in defconfig
<monstr> it means defconfig with/without SPL don't matter
<monstr> but this code definitely runs with SPL and without SPL because xilinx fsbl runs the same binary
<apalos> and this cleans up all the mess apart from OF_BOARD and OF_SEPARATE for the dtb config
<monstr> ha - we have u-boot mailing list on lore :-) nice
FredO3 has joined #u-boot
<monstr> I should be applying patches with links to lore
<apalos> yea life saving
<apalos> yep, that's what I do :D
<apalos> anyway, I got rid of all the useles config options,
<apalos> but then I was thinking I can make it even clearer
<monstr> OF_PRIOR_STAGE - I have never looked at it
<apalos> it does exactly the same thing as OF_BOARD
<apalos> (or it can do anyway)
<monstr> I expect you also check build process right?
<apalos> ya, I've build most of those
<apalos> I was just thinking I could make that even more strict
<apalos> e.g OF_SEPARATE is standard u-boot code, IOW what board_fdt_blob_setup() does in lib/fdtdec.c
<apalos> OF_BOARD = go do whatever you like
<monstr> your patch make sense
FredO2 has quit [Ping timeout: 265 seconds]
<apalos> yea risc-v was using OF_PRIOR_STAGE weirdly, they were just copying the dtb on yet *another* variable
<apalos> let me see if I can make that more strict and I'll send a v3
<monstr> sure go ahead with it
<apalos> that's whay I was asking about xilinx boards. I can't isolate OF_SEPARATE as-is right now,
<apalos> because you depend on it to have the linker overwrite the __weak symbol for board_fdt_blob_setup
<apalos> But I can live with that for now
<monstr> OF_SEPARATE is used by zynqmp
Guest6336 has joined #u-boot
<monstr> and OF_BOARD by versal
<monstr> if zynqmp is last with OF_SEPARATE we could move it to OF_BOARD too
<monstr> It shouldn't be a big problem
Guest6336 is now known as DhruvaG2000
<apalos> I just tried xilinx_versal_mini_defconfig and it's OF_SEPARATE As well
<apalos> that's ok, let me push the cleanup first and then we can discuss details of the DTB handover,
<apalos> which is part of a bigger revamp anyway
torez has joined #u-boot
monstr has quit [Ping timeout: 245 seconds]
sstiller has joined #u-boot
DhruvaG2000 has quit [Quit: Client closed]
monstr has joined #u-boot
matthias_bgg has quit [Ping timeout: 252 seconds]
kallisti5[m] has quit [Ping timeout: 252 seconds]
matthias_bgg has joined #u-boot
jwillikers has quit [Remote host closed the connection]
jwillikers has joined #u-boot
jwillikers has quit [Remote host closed the connection]
jwillikers has joined #u-boot
macromorgan has joined #u-boot
tnovotny has quit [Quit: Leaving]
sstiller has quit [Quit: Leaving]
fdanis is now known as fdanis_away
smartin has quit [Ping timeout: 245 seconds]
redbrain has joined #u-boot
ladis has quit [Quit: Leaving]
vagrantc has joined #u-boot
m-atoms has joined #u-boot
monstr has quit [Remote host closed the connection]
Rusty_Almighty has quit [Ping timeout: 245 seconds]
Rusty_Almighty has joined #u-boot
<Rusty_Almighty> I'm still trying to boot a 64-Bit ipxe uefi image. I think it's how I'm passing the FDT to the bootuefi command.
kallisti5[m] has joined #u-boot
DhruvaG2000[m] has joined #u-boot
Dhruvagole[m] has joined #u-boot
mckoan is now known as mckoan|away
matthias_bgg has quit [Ping timeout: 245 seconds]
<Rusty_Almighty> As a uboot noob, I'm running into the following with attempting to load the ipxe uefi image.
<Rusty_Almighty> ## Application terminated, r = 9
<Rusty_Almighty> ERROR : memory not allocated
macromorgan has quit [Read error: Connection reset by peer]
macromorgan has joined #u-boot
<marex> Rusty_Almighty: is that -ENOMEM, you ran out of malloc area or whatever ?
<marex> where is Heinrich when you need him
<Dhruvagole[m]> I dont mean to interrupt, but I was wondering why my messages are missing from the losg
<Dhruvagole[m]> logs*
<Dhruvagole[m]> > Hello, I'm a Final Year BTech Electrical Student from VJTI, Mumbai. I have been a Google Summer of Code 2021 participant with BeagleBoard.org
<Dhruvagole[m]> I have worked on fw development of various MCUs as well.
<Dhruvagole[m]> However, I am new to the world of u-boot and was hoping to get some guidance as to where I can get started?
<marex> there are no messages from you in the scrollback either
<marex> although I am just dead tired, I might be missing them
<marex> Dhruvagole[m]: where to start , well ... start with what ? if you have a board you want to use u-boot on, use it ...
<Dhruvagole[m]> might have been some server error
<Dhruvagole[m]> seems okay now
<Dhruvagole[m]> I am currently trying to run u-boot in qemu from my rpi
<Rusty_Almighty> Which log are you referring to?
<Rusty_Almighty> Would it help if I loaded the ipxe uefi image into address 0? is there some type of bound that I need to be aware of?
<marex> Rusty_Almighty: what are you trying to do again ?
<Dhruvagole[m]> oh I meant if there's any projects I cud work on so as to contribute to source of u-boot
<marex> Dhruvagole[m]: well sure, but it all goes much better if you have a usecase (i.e. your own motivation) for what you are doing
<marex> you can write tests for u-boot (boring, dreary, ... sjg1 says it is great)
<marex> you can do DM/DT conversion (really not exciting, but has to be done)
<Dhruvagole[m]> Rusty_Almighty: here: https://libera.irclog.whitequark.org/u-boot/2021-09-29
<marex> you can uh, write documentation (that's a great way to learn how the code really works, is to document it ... but heck that is so painfully boring)
<Rusty_Almighty> I think there is a lot going on with RISC-V if you want something scholastic.
<marex> Rusty_Almighty: oh yes, that's a good point
<marex> but really , find something you are excited about first ... else its gonna be a chore
<Rusty_Almighty> I would agree with that point.
<Dhruvagole[m]> I guess documentation sounds good as a beginner to me
<marex> I had a board which I wanted to boot linux on , when I started ... so that was my motivation, get a bootloader on it, and boot linux
<Dhruvagole[m]> okayy guys, thanks for your recommendations, I will go through and decide
<marex> kinda straightforward task ...
<marex> ... so many things can go wrong in that :)
<Dhruvagole[m]> I do have a BBB (AM335x)
<marex> thats supported upstream already, whats the fun
<Dhruvagole[m]> haha
<marex> sure, if you find a bug, debug it and fix it ... that could be interesting
<marex> or improvement, or something
<Dhruvagole[m]> or maybe could write a proper tutorial or something, I couldnt find many good blogs of how to use u-boot other than one playlist on youtube and some couple of blogs
<marex> that always helps too
<apalos> Rusty_Almighty: how are you loading ipxe?
<apalos> that shold work fine, I've even installed a distro from it
<Rusty_Almighty> ```dhcp; bootefi $kernel_addr $fdt_addr;```
<apalos> you dont need the fdt addr unless you expect ipxe to load a DTB
<apalos> but in any case that should work fine
<apalos> and I assume you loaded the ipxe.efi in kernel_addr right?
<Rusty_Almighty> If you don't include the fdt, then it throws an error.
<Rusty_Almighty> So, the dhcp command from hush should send out a dhcp request, and then load the uefi image into $kernel_addr.
<Rusty_Almighty> which it looks like it is doing according to the output.
<apalos> nop
<apalos> the dhcp command gets an ip and loads *whatever* is in that address
<vagrantc> bootefi *claims* to use the devicetree at $fdtcontroladdr if it isn't passed one
<apalos> so you are basically loading whatever the mmc initialized for you
<vagrantc> but maybe that's not getting set for your board ?
<apalos> you need something like
<vagrantc> Rusty_Almighty: what board is this?
<apalos> load mmc 0 $kernel_addr_r snp.efi; bootefi $kernel_addr_r
<Rusty_Almighty> an espressobin.
<vagrantc> Rusty_Almighty: and this is mainline u-boot?
<apalos> or ipxe.efi, or whatever
<Rusty_Almighty> AFIK, it's a mainline u-boot first stage boot loader.
<apalos> Rusty_Almighty: there's no ipxe support baked into EFI
<apalos> you need to load an external application to do that for you
<Rusty_Almighty> The ipxe image is an EFI image.
<apalos> ...
<apalos> right let me try again
<apalos> Do you loasd that application in the $kernel_addr_r
<apalos> ?
<marex> xypron: ^
<Rusty_Almighty> My understanding was that the dhcp command loads the tftp filename into the $kernel_addr memory location.
<apalos> as long as you configure it to do so
<Rusty_Almighty> I can post the output here if nobody has problems with that.
<Rusty_Almighty> I forget what the proper decorum is. I think paste-bin is proffered.
<apalos> yea pastebin will work
<apalos> right what's this: UEFIBoot-arm64.efi ?
frieder_ has quit [Remote host closed the connection]
<Rusty_Almighty> That is a 64-bit arm image that I compiled from the ipxe project.
<apalos> and I assume you renamed it ?
<Rusty_Almighty> I have put it on a tftp server: 10.10.20.2.
<vagrantc> Rusty_Almighty: you built this u-boot yourself? as there are a number of vendor forks out there which have ... who knows what in them
<Rusty_Almighty> Oh yeah.. totally renamed it to what it is currently.
<Rusty_Almighty> I didn't build this u-boot.
<apalos> Rusty_Almighty: ok how did you compile it ? Usually you need something along the lines of:
<apalos> make bin-arm64-efi/snp.efi -j6 EMBED=myscript.ipxe
<Rusty_Almighty> That's more or less how I made the ipxe.efi image.
<apalos> Rusty_Almighty: what u-boot version is this? If it's > 2 years old, it wont boot
<apalos> page 8,
<apalos> that's probably your problem
<Rusty_Almighty> apalos:This is the stock first stage loader from the espressobin. I guess the project is older. So, it may not even work.
<apalos> Rusty_Almighty: i did try to compile a master branch a few months ago on espressobin
<apalos> iirc it worked fine, but overall it was a bit of a pain
<Dhruvagole[m]> is there like a ready-to-use docker container that I can just fire up and has all the deps installed in it to build u-boot?
<apalos> since you need marvell tools to flash it etc
<vagrantc> yeah, the maze of marvell things that you need to chain together is ... mystifying
<apalos> Rusty_Almighty: you could run everything in a QEMU instance if you dont care about the hardware
<Rusty_Almighty> unfortunately, the hardware is the whole point.
<apalos> Rusty_Almighty: so you can update it, the documentation actually works,
<apalos> it's just a pita
<Rusty_Almighty> apalos: how did you update your espressobin?
<vagrantc> there's also u-boot/doc/README.marvell
<Rusty_Almighty> Is this for the first stage u-boot loader?
<apalos> I just ignored the entire 'u-boot' chapter and built an upstream one
indy has quit [Quit: ZNC 1.8.2 - https://znc.in]
<apalos> I think it does everything Rusty_Almighty
<apalos> since it updates TFA as well
<Rusty_Almighty> Apalos: This is good stuff. I need a minute to read it all.
<apalos> more :)
indy has joined #u-boot
<apalos> vagrantc: join the promised land of UEFI
<vagrantc> the part i had a hard time was identifying exactly which model i had and what variables to pass to the build process
<apalos> were we have common firmware, capsule updates, security and some unicorns stacked in the corner in case of emergency :)
<vagrantc> i used UEFI here and there, and when it works, it's fine. :)
<Rusty_Almighty> This version was built june 25th 2019. https://pastebin.com/ZD91XLtK
<Rusty_Almighty> Doesn't seem like it's terribly old.
<vagrantc> U-Boot 2017.03-armada-17.10.2-g255b9cc9c1 (Jun 25 2019 - 08:50:55 +0800)
<vagrantc> that's a version built in 2019 based on source code from 2017
<vagrantc> and probably heavily patched on top of that
<vagrantc> so it's behavior is unlikely to be similar to mainline u-boot
<vagrantc> at least it's not U-Boot 1.x :)
<Rusty_Almighty> Let me see if there is a newer firmware available.
<Rusty_Almighty> Compiling a new image if I don't have to seems like it would fraught with peril.
<vagrantc> but what makes you think the newer firmware won't be based on the same old version? :)
<Rusty_Almighty> Well, looks like there isn't one anyway.
jwillikers has quit [Remote host closed the connection]
<vagrantc> there have been a lot of fixes for espressobin in mainline in recent versions .. been meaning to try it but dreading the dance with the marvell tooling
<Rusty_Almighty> There are a lot of unknowns for me with this.
<Rusty_Almighty> I might spend a week trying to figure out how the toolchain works only to have the same bug.
jwillikers has joined #u-boot
<vagrantc> hence someone suggesting to try with qemu
<Dhruvagole[m]> Could this crash be uboot related - https://pastebin.com/JDCfupbz ?
<Dhruvagole[m]> Stacktrace*
<vagrantc> Rusty_Almighty: the other big reason is to switch to a version that people can actually help with
<Dhruvagole[m]> Here are the logs where the board simply doesn't even boot- https://pastebin.com/4kPKXv11
sd1 has joined #u-boot
torez has quit [Ping timeout: 245 seconds]
torez has joined #u-boot
guillaume_g has quit [Quit: Konversation terminated!]
sd1 has quit [Quit: Client closed]
torez has quit [Ping timeout: 245 seconds]
m-atoms has quit [Remote host closed the connection]
m-atoms has joined #u-boot
torez has joined #u-boot
sd1 has joined #u-boot
m-atoms has quit [Ping timeout: 252 seconds]
redbrain has quit [Ping timeout: 240 seconds]
sbach has quit [Read error: Connection reset by peer]
sbach has joined #u-boot
LeSpocky has quit [Quit: reboot]
qastokes has quit [Quit: qastokes]
sd1 has quit [Quit: Client closed]
qastokes has joined #u-boot
qastokes has quit [Quit: qastokes]
qastokes has joined #u-boot
jamesp_ has joined #u-boot
qastokes has quit [Quit: qastokes]
jamesp_ is now known as jamestperk
torez has quit [Quit: torez]
Rusty_Almighty has quit [Remote host closed the connection]
Xavier7 has joined #u-boot
Xavier7 has quit [Ping timeout: 252 seconds]
Xavier7 has joined #u-boot
m-atoms has joined #u-boot
Rusty_Almighty has joined #u-boot
Rusty_Almighty has quit [Remote host closed the connection]
Xavier7 has quit [Quit: • IRcap • 8.72 •]
agust has quit [Ping timeout: 246 seconds]
mmu_man has quit [Remote host closed the connection]
mmu_man has joined #u-boot
jwillikers has quit [Remote host closed the connection]