<override>
what yocto is there for modifying stuff like bootargs?
<milkylainen_>
override: que? You mean like what tools there is to modify a u-boot environment from a Linux runtime
<milkylainen_>
?
matthias_bgg has quit [Quit: Leaving]
<override>
milkylainen_: sorry. meant to say yocto recipe. what yocto recipe is there for modifying bootargs..
<macromorgan>
is there a handy way to report a bug? sorry still new here.
<milkylainen_>
override: Umm. That would depend on a lot of things. If it's your bsp that provides things or some default. I think the first google hit should point you in the right direction? I think you're asking for fw_printenv and fw_setenv?
<macromorgan>
as a result MMC and other devices cannot load (can't set the clock rate), and therefore cannot boot
<macromorgan>
curiously enough it's the GPU clock it cannot set, which isn't even used until Linux
<milkylainen_>
macromorgan: Author is Simon. sjg1 -^
<override>
milkylainen_: im trying to set the rooftfs partion that linux should boot from. Yesterday I was given the idea to look into bootargs. My bsp doesnt seem to talk a lot about modifying uboot. is there like a standard meta-layer or something that deal with uboot?
<override>
my bsp is from toradex, its yocto based
<override>
its fot the imx8mm-verdin, not sure if thats popular here..
<milkylainen_>
macromorgan: Code looks correct enough. Seems you were previously riding on a clock failure pretty late in the setup and got away with it. Might the suggested fix be to stop declaring clocks that can't be used? That code looks like it treats clock failures as complete failures.
<macromorgan>
right... I guess I'll find where this clock is getting set and remove it from the DTREE? Or failing that, actually support setting it in the clock driver?
<milkylainen_>
override: Either you just change it in runtime and save the environment. Or you can permanently change it in your u-boot as it builds. Then install another u-boot onto the board.
<macromorgan>
either way I think this at a minimum will affect all the px30 boards and possibly more rockchip devices, just FYI
<milkylainen_>
macromorgan: It's a valid bug report. Don't worry. :)
<override>
milkylainen_: i was thinking when stuff gets built in yocto, I can have uboot build out the way I want it to, so was wondering if theres like a convention for what recipes are used for uboot (in yocto)
<milkylainen_>
override: Not sure I follow. But your environment for u-boot is probably baked with u-boot. So if you want to change the environment bootargs, check the u-boot recipe. You already said that you can have it built?
<override>
yeah, the stuff that came with the bsp builds / bakes uboot
<override>
trying to see what recipe it uses tho..
<cambrian_invader>
hm, actually I think that commit will break k210 as well, since it will complain that PLL1 can't be set post-relocation
<cambrian_invader>
ack, I even reviewed this patch (but simon didn't pick it up for v2)
<milkylainen_>
cambrian_invader: Personally I think it might be a bit overzealous? Isn't a bit of whining enough? I'd rather things did continue.
<cambrian_invader>
sure
<cambrian_invader>
OTOH I have spent far too long debugging a case where the clock rate was not actual set and the board subsequently crashed
<cambrian_invader>
can you just remove the assignment for the GPU clock?
<milkylainen_>
Not set as in "wasnt declared"?
<cambrian_invader>
as in, I had something like
<macromorgan>
I can, I just know at least for this one board that behavior occured. Plus removing the clock will cause our DTS to diverge from upstream Linux.
<cambrian_invader>
assigned-clock-rates = <something which can't be set>
<milkylainen_>
I was thinking, missing declarations won't get set. So this correctness fix will not help, and nagging won't help either.
<milkylainen_>
Ah. But that should create some nag, instead of the silent treatment?
<cambrian_invader>
but clk_set_defaults failing is still a bug]
<milkylainen_>
As I said. Asking for full correctness at that level is asking quite a lot. Probably boards with tons of various clock errors in them.
<cambrian_invader>
so maybe revert that commit and fix the bug while you're at it :)
<milkylainen_>
I guess it boils down to design choice? Ask for full correctness, fix all errors or not?
<marex>
override: I've seem some mx8mm SoM nearby
<marex>
*seen
<marex>
override: do you have V1.0 V1.1A or V1.1B MX8MM Verdin ?
<marex>
I'm using mainline u-boot on 1.1A , that one uses distro bootcommand, so it should pick boot.scr from mmc1/mmc0/dhcp (in that order)
monstr has quit [Remote host closed the connection]
m4t has quit [Ping timeout: 268 seconds]
torez has quit [Quit: torez]
m4t has joined #u-boot
<milkylainen_>
Ok. Someone please tell me what kind of magic sauce needs to be used to get usb keyboard working on an x86 platform? Because I sure can't get it to work. Tried on real hardware. Won't work. Tried in Virtualbox with a physical keyboard behind a xhci or an ehci, ohci. No go.
<milkylainen_>
env: stdin=usbkbd, cmd: usb start, config: CMD_USB=y, USB=y, DM_USB=y, USB_HOST=y, XHCI, ECHI, UHCI and PCI counterparts enabled, USB_KEYBOARD=y, SYS_USB_EVENT_POLL=y