<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.
<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
<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
<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