<Duality>
though to be absolutely sure i can disable the hogs in the device tree and see if that makes it work.
<marex>
Duality: ah, so it works if you start U-Boot from U-Boot ?
<marex>
that's unsupported btw
<marex>
Duality: start with what you know worked before and try to reproduce that, then add stuff, one step at a time
<Duality>
marex: u-boot form u-boot? no loading it through serial like with x-modem is what i meant
<Duality>
marex: yea will do that one step at a time :)
guillaume_g has quit [Quit: Konversation terminated!]
redbrain has joined #u-boot
Gravis has quit [Quit: No Ping reply in 180 seconds.]
Gravis has joined #u-boot
Gravis has joined #u-boot
Gravis has quit [Changing host]
<gsz>
Hi! I see that, in some cases, new patchset versions refer to (In-Reply-To/References) the earlier ones, while in others they don’t. git-format-patch(1) suggests they should do, while the Linux kernel docs say the opposite. Is there a preferred approach in U-Boot?
frieder has quit [Remote host closed the connection]
<marex>
gsz: just do as linux does
<gsz>
marex: thanks, will do so
tnovotny has quit [Read error: Connection reset by peer]
tnovotny has joined #u-boot
LokeshV has joined #u-boot
<marex>
gsz: sure, you can very well just send patch for the docs too
<gsz>
I’m too happy with mutt to move to git send-email
<gsz>
Though, again, it would probably be easier to use…
<mrnuke>
gsz: the easisest thing for me to use doesn't have to be the easiest thing for you to use
<mrnuke>
gsz: Once the patch is on the ML I couldn;t care less if you used git or mutt or Winblows Mail (RTM)
<gsz>
All’s well as long as it’s not Outlook :)
tnovotny has quit [Quit: Leaving]
Gravis has joined #u-boot
Gravis has joined #u-boot
Gravis has quit [Changing host]
Gravis has quit [Ping timeout: 244 seconds]
Gravis has joined #u-boot
Gravis has joined #u-boot
Gravis has quit [Changing host]
Gravis has quit [Client Quit]
Gravis has joined #u-boot
blmaier has quit [Quit: ZNC 1.7.5+deb4 - https://znc.in]
blmaier has joined #u-boot
gsz has quit [Quit: Lost terminal]
Guest31 has joined #u-boot
<milkylainen_>
marex: Indeed. Seems when I start to actually configure u-boot beyond defconfig I fall into all sorts of undefined stuff from just toplevel cmd selection.
<marex>
milkylainen_: soooo ... you know what that means, right ?
<milkylainen_>
marex: Sure. :)
<marex>
milkylainen_: glad we're on the same page, do you expect many patches ? :)
<milkylainen_>
marex: That x86 asm stuff. I need core developers for that though.
<mrnuke>
That's one of the reasons I've been yelling against more Kconfig options (and being quite loud about it) :)
<marex>
mrnuke: yelling doesn't help, patches do
<mrnuke>
marex: i've been yelling at other people's patches that make the sutuation worse. You're welcome
<milkylainen_>
mrnuke: I'm not complaining about the options. Just that there seems to be a lack of exercising configuration for various builds. :)
<mrnuke>
milkylainen_: the issue is that Kconfig is not used for its purpose, which is enabling and disabling features. It is so convenient to use it for enabling and disabling code, that people find all sort of creative ways with it
<milkylainen_>
marex: I had a really strange error with uboot on VBox UEFI. Barebox boots fine on Vbox UEFI. But U-Boot would give me grief. I have a GCC 9.3 toolchain with default -march=znver1. Actual executing CPU is a skylake-ish for my laptop. Seems the U-boot build allows whatever intrinisc emission without being detailed about it? So I had a faulting
<milkylainen_>
insn.... Not sure if the insn is misaligned or if it's some derivative of AVX that isn't supported.
<milkylainen_>
Changing the toolchain to -mtune=znver1 instead makes U-boot work though.
<milkylainen_>
Barebox works fine with both variants of compilers though.
<milkylainen_>
Maybe U-boot archs should default to turning off fancy intrinsics?
<milkylainen_>
What would be the need of AVX shenanigans in U-boot?
<milkylainen_>
Sure. Faster, but it's not like U-boot deals with datacenter style loads. :P
<milkylainen_>
mrnuke: I see.
Gravis has quit [Ping timeout: 245 seconds]
<milkylainen_>
marex: seems only the function definition is broken?
<milkylainen_>
int write_mbr_partitions(struct blk_desc *dev,
<milkylainen_>
not dev_desc
<milkylainen_>
brb
gsz has joined #u-boot
Gravis has joined #u-boot
<milkylainen_>
next kconfig error. Tons of missing do_reset.
kpo has quit [Read error: Connection reset by peer]
<milkylainen_>
Sigh.
kpo has joined #u-boot
vagrantc has joined #u-boot
gsz has quit [Quit: leaving]
Guest31 has quit [Quit: Client closed]
smartin has quit [Quit: smartin]
<Duality>
marex: so i commented the parts of the device tree that do the gpio hogging and when i set GPIO_HOG=n it works but when i set GPIO_HOG=y it doesn't work anymore. I do not understand though there is no output when it's enabled like zero serial output. the MLO shouldn't concern it's self with like gpio-hogs right. it should just like load u-boot nothing more
alpernebbi has quit [Quit: alpernebbi]
kpo has quit [Ping timeout: 264 seconds]
<Duality>
i noticed something looking through the config
<Duality>
this was enabled: SPL_DM_GPIO
<Duality>
so now i set it to n and enabled gpio hog and it boots
<Duality>
re-enabled gpio hog in device tree and the leds light up and u-boot works so it was that option SPL_DM_GPIO getting in the way
<Duality>
but it still bothers me that loading the spl through xmodem worked but when loaded from mmc/emmc it didn't