redbrain has quit [Read error: Connection reset by peer]
jclsn90 has quit [Ping timeout: 272 seconds]
jclsn90 has joined #u-boot
redbrain has joined #u-boot
jclsn90 has quit [Ping timeout: 272 seconds]
jclsn90 has joined #u-boot
dwrice0_ has joined #u-boot
dwrice0 has quit [Ping timeout: 248 seconds]
jclsn90 has quit [Ping timeout: 256 seconds]
jclsn90 has joined #u-boot
jclsn90 has quit [Ping timeout: 256 seconds]
flyback is now known as CARL_SAGAN
jclsn90 has joined #u-boot
CARL_SAGAN is now known as flyback
jclsn90 has quit [Ping timeout: 256 seconds]
jclsn90 has joined #u-boot
thopiekar_ has joined #u-boot
thopiekar is now known as Guest5751
Guest5751 has quit [Killed (tungsten.libera.chat (Nickname regained by services))]
thopiekar_ is now known as thopiekar
mmu_man has quit [Ping timeout: 248 seconds]
jclsn90 has quit [Ping timeout: 240 seconds]
jclsn90 has joined #u-boot
thopiekar_ has joined #u-boot
thopiekar is now known as Guest8105
thopiekar_ is now known as thopiekar
Guest8105 has quit [Ping timeout: 248 seconds]
jclsn90 has quit [Ping timeout: 248 seconds]
vagrantc has quit [Quit: leaving]
jclsn90 has joined #u-boot
akaWolf has quit [Ping timeout: 250 seconds]
akaWolf has joined #u-boot
jclsn90 has quit [Ping timeout: 256 seconds]
adeepv has quit [Quit: %exit%]
adeepv has joined #u-boot
jclsn904 has joined #u-boot
jclsn904 has quit [Ping timeout: 240 seconds]
jclsn904 has joined #u-boot
kmaincent1 has quit [Quit: WeeChat 1.9.1]
tperrot has quit [Read error: Connection reset by peer]
jamestperk has quit [Ping timeout: 240 seconds]
Crofton has quit [Ping timeout: 240 seconds]
jamestperk has joined #u-boot
elvishjerricco has quit [Ping timeout: 256 seconds]
Crofton has joined #u-boot
elvishjerricco has joined #u-boot
thopiekar has quit [Ping timeout: 248 seconds]
thopiekar has joined #u-boot
guillaume_g has joined #u-boot
milkylainen has joined #u-boot
frieder has joined #u-boot
pbergin has joined #u-boot
mckoan|away is now known as mckoan
monstr has joined #u-boot
sughosh has joined #u-boot
monstr has quit [Remote host closed the connection]
zibolo has joined #u-boot
___nick___ has joined #u-boot
<milkylainen>
I know this is the wrong channel, but I thought that someone might have dabbed with this type of problem before.
<milkylainen>
Ethernet gig PHYs can have a significant linkup time. So much it disturbs an embedded fast boot (until communication).
<milkylainen>
Since Linux nowdays seems to put all phys in off until the device is opened, prolonging the linkup time to x seconds after first poking the ethernet interface (which is rather late).
sughosh has quit [Read error: Connection reset by peer]
<milkylainen>
Is there any way to tell the kernel or phy state machine like "please, keep my ethernet phys up. I don't want them off".
Crofton has quit [Ping timeout: 248 seconds]
moto-timo has quit [Ping timeout: 240 seconds]
moto-timo has joined #u-boot
Crofton has joined #u-boot
<milkylainen>
no-one?
sss[m] has quit [Quit: You have been kicked for being idle]
<urja>
This is a problem I had in an embedded thing at a previous work (though with just a non-gig PHY ...), but i didn't have u-boot or the kernel to deal with so... dunno, probably not as-is
mmu_man has joined #u-boot
<milkylainen>
urja: It's a rather common problem, to fudge ethernet phys. I'm just annoyed that the Linux default has become "phys should be off, lets save 0.5w of power (or whatever) until somone use them." with no apparent mechanism to change it.
matthias_bgg has joined #u-boot
<milkylainen>
Commendable to save power, but link times on ethernet are just stupid slow.
<milkylainen>
So I'd like to be able to decide. :)
<marex>
milkylainen: ksz9031 sucks ? :)
<marex>
milkylainen: like it takes 10-20s to link up after reset ?
<milkylainen>
marex: No. Not those horrid things. Not this time atleast. This is a regular intel igb on an embedded machine (pcie).
<marex>
and that also takes forever ?
<milkylainen>
I've been having this problem several times before. But I do think that the "previous" Linux behavior was to bring phys out of pdown and set link parameters. Nowdays it seems to be "off is the new standard".
<milkylainen>
marex: Yeah. For some reason. Sure, gbit autoneg can take a few seconds... This one is 6-7 seconds. The kernel tinkers with stuff too. I think the igb probe resets and does whatnots, then leaves the phy in pdown.. after which you reach userspace and some if-up-mechanism somewhere... and the device is opened..
<milkylainen>
And the driver begins grokking stuff again. Which takes ages.
<milkylainen>
Like new resets, bring out of pdown etc.
<milkylainen>
A very off-topic problem for #u-boot. Not to uncommon for various embedded applications though.
<milkylainen>
I looked at the ethtool ioctls, but I don't think the kernel discerns between pdown and reset from a userspace perspective?
<marex>
milkylainen: sorry, back
tre has joined #u-boot
akaWolf has quit [Ping timeout: 256 seconds]
akaWolf has joined #u-boot
<milkylainen>
marex: np.
<marex>
milkylainen: btw are you sure the system would still be compliant if you hack around the ethernet phy link up/down ?
<milkylainen>
marex: Yes. I can't see why? This is not something that is illegal or any way peculiar. It's just a behavior. Linux, nowdays, seem to be a bit focused on power saving. So PHYs that aren't used are powered down. This wasn't the case several years back. If an ethernet phy was up because of bios/u-boot the kernel would leave it untouched for the most
<milkylainen>
part.
<milkylainen>
a gb phy link is what? 200mw-500mw? something like that.
<milkylainen>
mW even
<milkylainen>
marex: The kernel takes the link down even if I have a link partner in the other end.
mripard has quit [Quit: Reconnecting]
<milkylainen>
Because _I_ have not opened the device.
mripard has joined #u-boot
mripard has quit [Client Quit]
kettenis has quit [Ping timeout: 256 seconds]
<milkylainen>
I suspect this varies quite a bit too. Depending if a phy is attached to the generic subsystem or just managed by a driver as an integrated one.
mripard has joined #u-boot
kettenis has joined #u-boot
torez has joined #u-boot
GNUtoo has quit [Remote host closed the connection]
GNUtoo has joined #u-boot
<milkylainen>
Trying to get some help from #networking. Sigh. "Do you have an IP addres?"
* milkylainen
facepalms
<apalos>
"yes the phy link is down, bu I can download stuff"
<marex>
milkylainen: just ... use wifi ffs 3-/
<milkylainen>
I have someone there eating me alive publicly. A girl none the less.
<milkylainen>
Trying to explain to her that it has nothing to do with "what the OS does" and "IP addresses".
<cambrian_invader>
though I'm guessing that we should just imply everywhere instead of select
<cambrian_invader>
oh, we need "if SPL"
vagrantc has joined #u-boot
dwrice0 has joined #u-boot
zibolo has quit [Ping timeout: 240 seconds]
zibolo has joined #u-boot
tprrt has joined #u-boot
tprrt is now known as tperrot
tre has quit [Remote host closed the connection]
<LetoThe2nd>
do i understand it right that in an arm context, secure boot via u-boot would essentially mean using u-boot as the uefi component and then going on rather generic?
<marex>
LetoThe2nd: what exactly does "secure boot" even mean ?
<marex>
LetoThe2nd: like, bootrom authenticates the bootloader, bootloader authenticates the next step ?
<marex>
LetoThe2nd: or like, bootloader runs in EL3, OS runs in lower EL ?
<cambrian_invader>
for v2 I ran `for config in configs/*; do make $config; done` so there should be no remaining errors like that
<Tartarus>
LetoThe2nd: To echo marex, it very much depends on the SoC and "secure". One typical path is the SoC specific verification flow, and then U-Boot verifies FIT images. With my work hat on, we've done something like this with mender before even I believe. The other side is SoC specific verification flow to then something-something UEFI, but that's less supported atm I think
<LetoThe2nd>
marex: Tartarus: i meant "secure boot", as the keyword, not "securing the boot process" as a technical thing ;-)
<Tartarus>
LetoThe2nd: Right, but "secure boot" isn't meaningful without a few more words around it :)
<marex>
Tartarus: unless of course you are selling something something website-with-a-nice-lock-and-key-icon something something handwaving ...
<vagrantc>
well, you wouldn't want second-rate handwaving
<Tartarus>
Yes, but we can assume LetoThe2nd hasn't been bought out by the marketing dept at northern.tech ;)
<LetoThe2nd>
Tartarus: i can totally understand the technical view point. yet on x86 for example, "secure boot" has a defined meaning. its a thing you can toggle in whatever bios/uefi implementation you have. and now I'm trying how that relates/translates to arm.
<Tartarus>
So if my assumption about what you're driving at is right, it's whatever the SoC features are to start with, and you extend the chain of trust via FIT signatures, etc
<cambrian_invader>
on arm "secure boot" is not a specific technology
<Tartarus>
LetoThe2nd: Right, for x86 it's not "secure boot", it's "UEFI secure boot"
<Tartarus>
for arm64, "UEFI secure boot" exists I think for the edk2 flow, but it's not fully part of the U-Boot flow, and even then I assume they're leveraging the SoC features to start with to extend the chain of trust
<LetoThe2nd>
Tartarus: okay, then let me rephrase. is there an equivalent to "uefi secure boot" on arm? leaving out the vendor specifif first stage, like nxp hab. i know that it all has to start somewhere.
<Tartarus>
LetoThe2nd: Yes, in U-Boot you use FIT signatures and verified boot
<Tartarus>
We've had that for a decade or so :)
<Tartarus>
it's arch-agnostic
<Tartarus>
And extends whatever chain of trust does or does not exist prior to that point
<LetoThe2nd>
Tartarus: hmokay.
<marex>
it is also time tested technology
<cambrian_invader>
but there are (at least) 4-5 other ways to do secure boot in U-Boot afaik
<Tartarus>
configs/am335x_boneblack_vboot_defconfig is the in-tree example
<marex>
and it is based on time tested device tree technology
<cambrian_invader>
unless you put an @ in the address :)
<Tartarus>
Then yes, depending on the SoC in question, it can be augmented in various ways
<LetoThe2nd>
okay thanksß think i got another puzzle piece into my head.
Net147 has quit [Ping timeout: 272 seconds]
Net147 has joined #u-boot
Net147 has joined #u-boot
Net147 has quit [Changing host]
sobkas has joined #u-boot
mmu_man has quit [Ping timeout: 256 seconds]
dwrice0 has quit [Read error: Connection reset by peer]
dwrice0 has joined #u-boot
ldevulder has quit [Quit: Leaving]
frieder has quit [Remote host closed the connection]
indy has quit [Ping timeout: 260 seconds]
matthias_bgg has quit [Ping timeout: 250 seconds]
dwrice0_ has joined #u-boot
dwrice0 has quit [Ping timeout: 246 seconds]
mckoan is now known as mckoan|away
mmu_man has joined #u-boot
<xypron>
LetoThe2nd: UEFI secure has been implemented in U-Boot. But this does not define the start of the chain of trust. Furthermore measured boot via TPM is available in U-Boot.
LinuxHackerman[m has joined #u-boot
dormito has joined #u-boot
torez has quit [Quit: torez]
___nick___ has quit [Ping timeout: 248 seconds]
<Tartarus>
robher: Note that I'm still going to wait my usual 2 weeks or so before applying the bootconf patch so that others can chime in.
<robher>
Tartarus: I'm waiting for others to chime in too before applying the dtschema patch.
<Tartarus>
OK, figured. Just wanted to be clear on my time-table for this side, if there's no strong objections
<rfried>
I think it's related to your DM9000 patchset.
vagrantc has quit [Quit: leaving]
dwrice0_ has quit [Ping timeout: 256 seconds]
<dormito>
I wrote a new serial driver (for u-boot), and added dts entries for the relevent board. I can see in 'dm' that the driver binds to the dt entry... but "coninfo" doesn't list the device. Is there something specific that has to be done to register as a console/serial driver?
<dormito>
maybe I need to call stdio_register() in probe()...
<Tartarus>
That's on dra7xx_evm_config if it helps you compare
<Tartarus>
uclass should do that for you
<Tartarus>
it sounds like you're missing something, yeah. What'd you base your driver on?
<dormito>
I copyied the U_BOOT_DRIVER instantiation form ns16550 (because I'm actually familiar with that hw somewhat), and modified all the references.
<dormito>
the coninfo does list the "serial@ff1a0000" that is the original console, and a default 'serial' and a 'nullserial'. However none of those are the console I added.
<dormito>
from my very tentative exploration, it looks like only stuff registered with 'stdio_register' (and friends), and the first console found in the dtb (typically the /chosen/stdout) are listed in coninfo
machinehum has joined #u-boot
<dormito>
as for the driver source: I'm using a mailbox to an on-soc M0 to have the M0 forward the traffice in/out via the real hw uart. so the driver code doesn't need to be too complex (and I'm doing that so I can debug a kexec just dieing on systems that I am not able to attach a hw debugger).
<Tartarus>
Ah
<Tartarus>
Maybe poke the mailbox class instead?
<machinehum>
Hello, I'm trying to upstream support for the Allwinner V5, it's a 32bit quad core A7. I've made some Kconfig changes incorperating stuff from the H6 and Allwinner armv7 chips and am having some linking errors: https://pastebin.com/raw/H1Rkm1jk
<dormito>
I'm trying to get u-boot to use the M0 for IO (I already have the trusted firmware using it). I suppose I could implemente a mailbox device, but I dont think that's solve the connecting to u-boots idea of a console.
<machinehum>
Any general or specific guidance would be very appriciated
sbach has quit [Read error: Connection reset by peer]
<marex>
rfried: gives me 404
<marex>
rfried: the CI for net is not public maybe ?
<dormito>
well, first I just want to show up in coninfo (since I think that will indicate it *could* be activated as a replacement for the main console). But yeah the semihosting is probably a good idea (since it's probably similar...
<dormito>
oh boo. This board is base off an old u-boot. well I'll grab the latest upstream
<cambrian_invader>
dormito: there is *one* serial console
<cambrian_invader>
and the backend is chosen from among the available serial devices
<cambrian_invader>
so if you see any serial device in coninfo, you see the only serial console
<dormito>
ah
<dormito>
I guess that leads me to my next question: I need SPL/TPL to continue using the current serial driver (after the M0's programing is loaded by the trusted firmaware, which I believe starts right before u-boot does). I believe this means I can't modify the dts's /chosen/stdout (else I will break tpl/spl). Is there another way to get main u-boot to choose a different serial device?
<dormito>
*the M0's program is loaded by the "trusted firmware"
<cambrian_invader>
have a look at serial_find_console_or_panic
<machinehum>
cambrian_invader: Thanks, interestingly enough it's defined for armv7a, armv8 but not armv7m
<marex>
Tartarus: how do you do this sync of defconfigs again ? :)
<j`ey>
machinehum: because v7m has no MMU
<machinehum>
I mistyped, it's defined for armv7m and armv8. But not armv7a. Or at least not where I can find it
<machinehum>
However thanks j`ey that's good info
<machinehum>
Oh is armv7m cortex-M series? While v7a is cortexA?
<j`ey>
yeah
<machinehum>
Makes sense
<dormito>
Hmmm. what's the difference between of_get_stdout() and serial_check_stdout()? is of_get_stdout() not refereing to "/chosen/stdout-path"?
<dormito>
oh, n/m
<dormito>
I failed to notice the of_live_active() branching point
<dormito>
I think my only choice might be to make use of OF_PLATDATA, and only enable it for spl/tpl (though I haven't looked into platdata too much, so not sure if it's suitable)
<cambrian_invader>
can you detect if the mailbox exists at runtime?
<cambrian_invader>
or rather, can you disable the mailbox in SPL/TPL
<cambrian_invader>
if you can, you can make your serial driver fail to bind with -ENOENT when the mailbox is missing
<dormito>
I already have an #if SPL_BUILD (or w/e the correct define is) return -1 for the probe
<dormito>
the problem I face is: the ns16550 is using /chosen/stdout-path as it's only bind method. If I replace that with my driver, which is disabled in spl/tpl then spl/tpl panic because they find nothing.
jybz has quit [Ping timeout: 256 seconds]
<dormito>
it looks like in serial_find_console_or_panic, spl/tpl only search the of_platdata and /chose/stdout-path.
<cambrian_invader>
ah, I wasn't using DM for SPL
<cambrian_invader>
so I never ran into this
<cambrian_invader>
if it's for debugging you can always hard-code it
<cambrian_invader>
or e.g. let SPL/TPL try the CONFIG_CONS_INDEX stuff
guillaume_g has quit [Ping timeout: 240 seconds]
<hurricos>
I'm trying to configure MII on a board.
<hurricos>
I have reference values that the MII registers should have.
<hurricos>
I know those work (since they're in another u-boot implementation!)
<hurricos>
My question is: if <mii dump 1 1> shows <1. (796d) -- PHY status register --
<hurricos>
> ... how do I manually re-create that state using <mii write>?
<hurricos>
I'm struggling to understand the stated syntax: "mii write <addr> <reg> <data>"
<hurricos>
address appears to be 1, reg 1, and data 796d, yet that mii write combination does nothing.
sobkas has quit [Quit: sobkas]
<machinehum>
CONFIG_SYS_ARM_MMU had to be set to [y]
<machinehum>
:P
<hurricos>
I see, I'm writing to status registers.
<dormito>
cleanest way I found so far is to make {S,T}PL examin /chosen/xpl-stdout-path, while u-boot examins /chosen/stdout-path
<dormito>
well, my driver, in u-boot is causing an abort (which means I at least got tpl/spl using the other driver)
<dormito>
yay it works (for output... input isn't quite rigged up yet)
guillaume_g has joined #u-boot
v0|d has quit [Remote host closed the connection]
jybz has joined #u-boot
<dormito>
cambrian_invader: thanks for the help. Seems be partly working (output of things like 'help' stalls ever line until you press a key... will have to look into that)