<milkylainen>
marex: I understand that. But wth? :)
<milkylainen>
how can usbkbd be wrong?
<milkylainen>
Statically compiled, keyboard found but not working
<milkylainen>
Ignore the static part. Builtin is what I meant to say.
<milkylainen>
I don't understand. Literally _every_ part of U-boot I touch is broken to bits.
<marex>
its awful, yeah ...
<milkylainen>
efi, x86, usbkbd, serial... etc.
<marex>
milkylainen: obvious question, did you run usb reset or usb start ? what does coninfo print ?
<marex>
milkylainen: probably ask xypron then
* milkylainen
is just slightly disheartened...
<milkylainen>
marex: yes. usb reset, usb start.
<milkylainen>
I don't get that far as U-boot hangs when polling the console.
<xypron>
milkylainen: what system, which defconfig are you using?
<milkylainen>
xypron: x86_64 efi payload.
Peng_Fan has joined #u-boot
<xypron>
milkylainen: efi_payload was developed and is maintained by sjg1. 2021.07-rc3-00033-gaab8b17e94 (May 28, 2021) was working for me.
<xypron>
milkylainen: running on an Asus mainboard.
<xypron>
milkylainen: on what sort of a system do you try to run x86_64 efi_payload?
<milkylainen>
Well. I can't get 2021.07 to work on either Virtualbox or real hardware.
<milkylainen>
Virtualbox and a DFI GHF51.
<milkylainen>
u-boot comes up with serial set (stupid). I make sure preboot sets all std* variables. err and out to vidconsole and in to usbkbd: usb reset, usb start, usb info. Lists my usb keyboard. Autoboot hangs when polling.
<Peng_Fan>
mwalle: what issue do you see regarding NXPs code?
<xypron>
milkylainen: I never tried to boot anything with it. Just used the U-Boot command line.
<xypron>
milkylainen: but why do you need U-Boot if you have EFI?
<milkylainen>
xypron: Booting works fine. Finally. When the e820 map got unbricked.
<milkylainen>
xypron: Stopgap measure. I probably aim to remove U-boot in the longer run.
<milkylainen>
xypron: I use u-boot to implement a fallback/redundant load scheme.
<milkylainen>
Haven't gotten around to implement it as an EFI application or as a userland program for a kernel with kexec.
<xypron>
milkylainen: U-Boot on EFI does not offer EFI itself. Implementing an EFI application seems the easier path.
<xypron>
milkylainen: you just need an UEFI variable to remember if you are booting A or B and LoadImage(), StartImage().
<milkylainen>
xypron: Most likely. Right now I enjoy the relative simplicity of implementing disk access / flash handling under U-boot. I.e U-boot has a large ecosystem of functions.
<mwalle>
Peng_Fan: eh? do you mean my rant a week (or two) ago?
<Peng_Fan>
"if only more vendors would see NXPs behavior regardings issues, that is rather disable an important feature but debugging it"
<Peng_Fan>
mwalle: yes
pratyush has quit [Read error: Connection reset by peer]
narmstrong has quit [Ping timeout: 252 seconds]
<milkylainen>
xypron: I have an n-redundant scheme with fallback and test boot understanding. So a bit more complex than a simple a or b boot.
narmstrong has joined #u-boot
pratyush has joined #u-boot
<milkylainen>
Anyway. Can't get USB kbd to work right now.
<Peng_Fan>
mwalle: Thanks. I thought i.MX. Let me check with LS people about this.
<mwalle>
Peng_Fan: thanks :)
mmu_man has quit [Ping timeout: 272 seconds]
lukma has quit [Ping timeout: 240 seconds]
<marex>
and so just yesterday, I tried starting CM7 on MX8MN ... the system crashed completely ...
<marex>
after a bit of debugging, I realized both mainline U-Boot and Linux now depend on non-mainline completely custom firmware interfaces implemented in imx-atf fork ... oh well
<marex>
Peng_Fan: ^ here is one iMX specific rant if you want one
<marex>
I have many more :-)
<Peng_Fan>
marex: for AMP management, there is indeed some downstream code needed.
<Peng_Fan>
marex: do you kick CM7 in linux kernel or U-Boot?
<marex>
Peng_Fan: how come mainline Linux and mainline U-Boot depends on downstream non-standard interface ?
<marex>
Peng_Fan: either is broken :-)
<Peng_Fan>
marex: I mean upstream is ready for a full functional AMP system.
<marex>
Peng_Fan: and really, the fix is simple, just use the MMIO interface instead ...
<marex>
Peng_Fan: yes, AMP in upstream is full non-functional if you use everything upstream including upstream ATF
<Peng_Fan>
marex: oh, you mean SRC MMIO access?
<marex>
Peng_Fan: yes, the fix is to use MMIO access instead of this custom non-standard SMCCC call
<marex>
same argument as the GPCv2 discussion, really
<Peng_Fan>
marex: to have a stable AMP system, the clock management, the device rdc settings, all needs to be considered.
<Peng_Fan>
marex: there are several things missing, SRC is just a minor part.
<marex>
I am surprised that upstream would accept interface which depends on non-standard downstream firmware call ... sigh :(
<marex>
that should really be fixed by switching to the MMIO interface instead
<marex>
Peng_Fan: btw mx8mn is missing the CM7 root clock in the clock driver, so I dunno who tested the CM7 support there, but it couldn't work in mainline even with the SMCCC call and custom firmware :-)
<marex>
... which reminds me, I should send you a patch for that cm7 clock
lukma has joined #u-boot
<Peng_Fan>
marex: per my recall, the smp core reset address is controlled by SRC, export SRC to Linux would expose the risk the hacker could modify the 2nd core resume address.
<Peng_Fan>
marex: and make it easy to root the system.
<marex>
Peng_Fan: that's about as likely as modifying the CA53 start address , right ?
<Peng_Fan>
marex: yes
<marex>
the firmware is in the root filesystem
<marex>
such a hacker could replace the firmware, or replace the kernel, heck they could even replace the ATF if they have physical access :)
<Peng_Fan>
marex: I mean 2nd cores resume entry address is in SRC, hacker could try modify it and got secret data.
<Peng_Fan>
marex: we have resolved such design limitation in new silicon. There are some security researchers do concern on exporting the permission to change entry address in NS-world.
<marex>
Peng_Fan: the attacker would have to have kernel level access to the machine, at which point it is already game over
<marex>
the kernel has access to SRC right now, to GPC and GPR as well
<marex>
so hiding part of the CM7 startup into imx-atf fork PSCI implementation isnt gonna make the machine more secure anyway
<Peng_Fan>
marex: it depends what it wanna to access. it is the 2nd core entry address is in SRC, we have to move the IP to Secure world.
<marex>
(this starts to sound like the GPCv2 discussion all over again btw)
matthias_bgg has joined #u-boot
<Peng_Fan>
marex: No. GPCv2 could just hang the system, the attacker not able to steal critical data. But SRC is different, system could be still alive
alpernebbi has joined #u-boot
<marex>
Peng_Fan: SRC is currently exposed to Linux kernel ...
<Peng_Fan>
marex: I suppose you mean CSU not restrict access to SRC
<marex>
Peng_Fan: CSU ?
<Peng_Fan>
marex: Central Security Unit
<marex>
Peng_Fan: er, no, I mean, on mx8mn, Linux binds a driver to SRC, so SRC access is available to Linux in full
<marex>
Peng_Fan: btw I dont expect we will solve this here, just FYI, there is this problem of mainline depending on non-mainline interface and that should be solved
<marex>
that's my whole point
<Peng_Fan>
marex: I see, let me check about the reset vector, and see whether it exist in 8MN or else.
<marex>
Peng_Fan: on mx8mn, the reset vector is hard-wired into SRAM iirc
<marex>
Peng_Fan: so that's all exposed to Linux right now anyway
frieder_ has joined #u-boot
<Peng_Fan>
marex: well. depends on what you wann to protect, you could ignore or protect.
<marex>
Peng_Fan: my whole point is, upstream should not depend on custom downstream interfaces
frieder has quit [Quit: Leaving]
frieder_ has quit [Client Quit]
<Peng_Fan>
marex: I see. But if upstream ATF has that support, that should be ok?
<marex>
Peng_Fan: if upstream ATF grows support for that, then it is using the PSCI interface wrong (so I suppose that is not gonna happen), and also the same GPCv2 argument applies
milkylainen_ has quit [Ping timeout: 258 seconds]
frieder has joined #u-boot
mmu_man has joined #u-boot
Net147 has quit [Ping timeout: 258 seconds]
Net147 has joined #u-boot
Net147 has joined #u-boot
Net147 has quit [Changing host]
haritz has joined #u-boot
<haritz>
Hi, I was wondering, how can I setenv a variable that depends on other variables without these getting expanded to their actual values?
<haritz>
turns out single quotes was the answer
monstr has joined #u-boot
wyre_ has joined #u-boot
jwillikers has joined #u-boot
Gravis_ has joined #u-boot
indy_ has joined #u-boot
mranosta1 has joined #u-boot
srk_ has joined #u-boot
blmaier_ has joined #u-boot
GNUtoo has quit [*.net *.split]
cbmuser has quit [*.net *.split]
marex has quit [*.net *.split]
Zapy has quit [*.net *.split]
smurray has quit [*.net *.split]
sjg1 has quit [*.net *.split]
indy has quit [*.net *.split]
Peng_Fan has quit [*.net *.split]
jordemort has quit [*.net *.split]
milkylainen has quit [*.net *.split]
rfried has quit [*.net *.split]
Tartarus has quit [*.net *.split]
flyback has quit [*.net *.split]
wyre has quit [*.net *.split]
pavelow has quit [*.net *.split]
mmu_man has quit [*.net *.split]
samueldr has quit [*.net *.split]
cpackham[m] has quit [*.net *.split]
mrnuke has quit [*.net *.split]
Wizzup has quit [*.net *.split]
xypron has quit [*.net *.split]
Patater has quit [*.net *.split]
srk has quit [*.net *.split]
sicelo has quit [*.net *.split]
Gravis has quit [*.net *.split]
Sout_ has quit [*.net *.split]
mranostaj has quit [*.net *.split]
blmaier has quit [*.net *.split]
elafon_ has quit [*.net *.split]
ElementW has quit [*.net *.split]
yorick has quit [*.net *.split]
mripard has quit [*.net *.split]
qschulz has quit [*.net *.split]
niska has quit [*.net *.split]
davlefou has quit [*.net *.split]
Luker has quit [*.net *.split]
mwalle has quit [*.net *.split]
g5pw has quit [*.net *.split]
srk_ is now known as srk
indy_ is now known as indy
wyre_ is now known as wyre
marex has joined #u-boot
Zapy has joined #u-boot
GNUtoo has joined #u-boot
sjg1 has joined #u-boot
smurray has joined #u-boot
cbmuser has joined #u-boot
kaji has quit [Ping timeout: 276 seconds]
mripard has joined #u-boot
davlefou has joined #u-boot
Luker has joined #u-boot
niska has joined #u-boot
qschulz has joined #u-boot
g5pw has joined #u-boot
mwalle has joined #u-boot
Peng_Fan has joined #u-boot
Tartarus has joined #u-boot
rfried has joined #u-boot
jordemort has joined #u-boot
flyback has joined #u-boot
pavelow has joined #u-boot
Sout_ has joined #u-boot
sicelo has joined #u-boot
yorick has joined #u-boot
elafon_ has joined #u-boot
ElementW has joined #u-boot
mmu_man has joined #u-boot
Wizzup has joined #u-boot
xypron has joined #u-boot
samueldr has joined #u-boot
mrnuke has joined #u-boot
Patater has joined #u-boot
mvaittin has quit [Ping timeout: 252 seconds]
jordemort has quit [Ping timeout: 256 seconds]
samueldr has quit [Ping timeout: 272 seconds]
torez has joined #u-boot
frieder_ has joined #u-boot
frieder_ has quit [Remote host closed the connection]
mvaittin has joined #u-boot
georgem has joined #u-boot
Peng_Fan has quit [Quit: Connection closed for inactivity]
kaji has joined #u-boot
alan_o has quit [Ping timeout: 258 seconds]
cpackham[m] has joined #u-boot
tre has quit [Remote host closed the connection]
alan_o has joined #u-boot
GNUtoo has quit [Quit: leaving]
GNUtoo has joined #u-boot
jordemort has joined #u-boot
samueldr has joined #u-boot
tuxlovesyou has quit [Ping timeout: 258 seconds]
milkylainen has joined #u-boot
<milkylainen>
Can u-boot detect ACPI devices like an EMMC?
elafon_ has quit [Remote host closed the connection]
cyrozap has quit [Ping timeout: 248 seconds]
elafon has joined #u-boot
cyrozap has joined #u-boot
macromorgan has quit [Quit: Leaving]
monstr has quit [Ping timeout: 276 seconds]
monstr has joined #u-boot
<sjg1>
milkylainen: Yes it could need VIDEO_COPY or it could be the mtrrs. Try 'mtrr list'
matthias_bgg has quit [Ping timeout: 268 seconds]
<sjg1>
milkylainen: Also did you see 2f91fc40039 x86: Ensure the e820 map is installed in all cases
mranosta1 is now known as mranostaj
matthias_bgg has joined #u-boot
monstr has quit [Remote host closed the connection]
redbrain has joined #u-boot
matthias_bgg has quit [Ping timeout: 258 seconds]
matthias_bgg has joined #u-boot
behanw has joined #u-boot
Gravis_ is now known as Gravis
milkylainen_ has joined #u-boot
<milkylainen_>
sjg1: Regarding the e820 map. I thought I gave you feedback on IRC? Works fine for me.
sszy has quit [Ping timeout: 268 seconds]
<milkylainen_>
sjg1: Ack. Will check the mtrrs.
torez has quit [Quit: torez]
fdanis is now known as fdanis_away
paulbarker has quit [Ping timeout: 240 seconds]
lvrp16 has quit [Ping timeout: 240 seconds]
dgilmore has quit [Ping timeout: 240 seconds]
frieder has quit [Remote host closed the connection]
sjg1 has quit [Ping timeout: 245 seconds]
ldts has quit [Ping timeout: 240 seconds]
ldts has joined #u-boot
sjg1 has joined #u-boot
redbrain has quit [Ping timeout: 258 seconds]
lvrp16 has joined #u-boot
paulbarker has joined #u-boot
dgilmore has joined #u-boot
redbrain has joined #u-boot
matthias_bgg has quit [Quit: Leaving]
redbrain has quit [Ping timeout: 268 seconds]
GNUtoo has quit [Quit: leaving]
GNUtoo has joined #u-boot
redbrain has joined #u-boot
paulbarker_ has joined #u-boot
paulbarker has quit [Ping timeout: 248 seconds]
paulbarker_ is now known as paulbarker
dgilmore_ has joined #u-boot
ldts_ has joined #u-boot
sjg1 has quit [Ping timeout: 268 seconds]
ldts has quit [Ping timeout: 258 seconds]
ldts_ is now known as ldts
sjg1 has joined #u-boot
dgilmore has quit [Ping timeout: 272 seconds]
dgilmore_ is now known as dgilmore
lvrp16 has quit [Ping timeout: 248 seconds]
lvrp16 has joined #u-boot
<milkylainen_>
x86 ACPI SDHCI?
macromorgan has joined #u-boot
redbrain has quit [Quit: leaving]
alpernebbi has quit [Quit: alpernebbi]
Forty-Bot has quit [Ping timeout: 268 seconds]
macromorgan has quit [Read error: Connection reset by peer]