<marex>
jeeze, that ultra96 is like a jet plane was taking off in board shelf 3-/
<marex>
ok, board doesn't boot anymore with latest upstream ... great
<marex>
time to download 50 GiB+ of xilinx goo , only to compile 1 MiB of PMUFW 3-/
<marex>
oh of course ... the 96boards compatible Ultra96 does not use the LS header UART like all the other 96boards, there is a special UART next to it which it now uses ...
* marex
shakes head
WoC` has quit [Quit: Leaving]
<marex>
well OK, at least there is no official documentation how to build the damn PMUFW, and the unofficial fails to document step 1 -- prerequisite for the next steps, and then vivado crashes in step 3
<marex>
grumb
<marex>
words elude me ... vivado 2020 cannot deal with vivado 2019 tcl scripts, 50 more GiB to go
<marex>
this is supposed to be an easy-to-get-started with board ... well ... obviously total fail on Xilinx side
<marex>
easy to get started with surely doesn't mean "hunt down documentation all over the internet, find out most of it is lacking required steps, or outdated , usually both ... "
<Forty-Bot>
the documentation is meta-xilinx
<Forty-Bot>
;)
<marex>
the documentation is petalinux ...
<marex>
which is meta-xilinx plus gigabytes of ...
<marex>
dont even get me started
<Forty-Bot>
I have no idea what petalinux is for
<Forty-Bot>
seems kinda vestigial from when the whole thing wasn't yocto
<marex>
hmmmm, OK, so the optional pmufw configuration object is not so optional after all
<marex>
and of course, it fails to load if built per documentation
WoC` has joined #u-boot
<marex>
Forty-Bot: petalinux is the same thing like vitis
<marex>
Forty-Bot: if you need to compile a single source file or a couple, like ... trivial firmware ... you need the entire design software (tens of gib download, hundred or so unpacked), then vitis (eclipse and ton of useless crud), and then you get the compiler among this mountain of useless goop
<marex>
Forty-Bot: petalinux is the same ... Kconfig frontend to ton of broken OE layers, which, if you want to modify them in any standard manner, breaks down completely
<Forty-Bot>
there is a meta-xilinx-standalone-experimental which builds stuff without vitis
<Forty-Bot>
but as you might be able to tell by the name it isn't really supported
<Forty-Bot>
and AFAIK it's half-baked
<marex>
Forty-Bot: you won't be able to build pmufw without xsct I think
<Forty-Bot>
yes...
<marex>
unless there is some neat trick
<Forty-Bot>
of course the way they install xcst is insane IMO
<Forty-Bot>
it happens during recipe parsing
<Forty-Bot>
why they don't just create a recipe for it I have no idea
<Forty-Bot>
the other fun thing is that the PMU firmware sources come from xsct and not the embeddedsw repo you downloaded
<Forty-Bot>
so if you edit what should be the real sources, nothing happens
<marex>
Forty-Bot: yes, the whole thing with xsct in xilinx OE integration is ... mind bogglingly tragic
<marex>
Forty-Bot: my english skill is insufficient to describe xilinx
<Forty-Bot>
lol
<Forty-Bot>
I found out about this the other day when I decided to revisit a xilinx project
<Forty-Bot>
I ended up having to clear out 200 GB(!) of space in order to get a matching xsct
<Forty-Bot>
that's larger that the gta v installer
<marex>
Forty-Bot: and how much of that did you actually make use of , 100 MiB toolchain ?
<Forty-Bot>
I needed the xsct binary, so however large that is
<Forty-Bot>
and presumably at some point I will resynthesize the design
<marex>
there is portable xsct which is only 700 MiB or so
<marex>
its still a bit too much for something which only generates a Makefile if you ask me
<Forty-Bot>
IMO the biggest annoyance is that things like e.g. what peripherals you are using are configured in vivado
<Forty-Bot>
so you have to resynthesize your whole design if you want to e.g. switch the serdes protocol
<Forty-Bot>
which in an FPGA should be reconfigurable at runtime
<marex>
Forty-Bot: so ... it is very much inline with the rest of xilinx software quality
<marex>
any other surprises ?
<Forty-Bot>
documentation voluminous and yet somehow incomplete
<Forty-Bot>
not surprising :)
<marex>
that is mind boggling too
<marex>
ton of useless documentation
<marex>
och ... finally ... platform boots and then powers off
<marex>
weird
<marex>
this is such a major pain in the ... aaaaaargh
<marex>
OK, I needed the ultra96 to debug USB issue, but ... v2020.01 does not even boot, platform crashes outright, v2020.04..10 has broken USB... so the entire attempt to get this xilinx platform booting was a total waste of time
<marex>
probably should've expected this level of quality from Xilinx
<sjg1>
marex: Whatever happened to that imx binman thing...it seemed to be closed when you stopped?
<marex>
sjg1: project is done
<marex>
sjg1: there are no more resources
<sjg1>
marex: Oh so you mean it stopped short of upstreaming the stuff?
<marex>
sjg1: the result was not usable, so it was discarded, there is nothing to upstream
<sjg1>
marex: Oh I wish you had told me it wasn't going anywhere before I spent all that time on it
<marex>
sjg1: maybe if binman was documented at all, it wouldn't be such an experience in utter frustration and it might've been implemented and upstreamed in the time that was available
<marex>
sjg1: instead, it was constant "hmmm , this ... needs to be completely reworked, yeah, sure ... this too ... oh, and this ... we are not getting anywhere near to any usable result ... "
<marex>
and then all the resources were up and over
<marex>
sjg1: so please, don't shift the blame on me, I tried ...
<sjg1>
marex: From my side it seems that you just assumed a new entry type would already be supported somehow
<marex>
this discussion is over
<sjg1>
marex: anyway it doesn't matter. I'll just be more wary of engaging in future
<sjg1>
marex: I do try to help people do new things, but I don't understand why the very first command was 'nothing works, I'm frustated'
<sjg1>
marex: *comment
<sjg1>
marex: OK
<marex>
sjg1: I am already stressed out enough as it is, I really don't need to get flak for trying to implement some feature into a tool you wrote and failed because the complexity got so overblown and the amount of changes so massive, that the project ran out of resources before anything could come out of it
<marex>
sjg1: you can try and talk to e.g. Peng_Fan , maybe NXP can allocate someone to fix the mkimage implementation properly ?
<sjg1>
marex: OK sorry to stress you out more
<marex>
sjg1: no worries, if I can find some way to continue it, I will, but for now, this is on ice
<marex>
sjg1: btw what really triggered me above was the 'Oh I wish you had told me' ... I couldn't have predicted that, sorry
<marex>
sjg1: I also want to see the mkimage fixed, I just dont have the resources right now