Clamor has quit [Read error: Connection reset by peer]
Clamor has joined #u-boot
smoothdev has joined #u-boot
Stat_headcrabed has joined #u-boot
Stat_headcrabed has quit [Client Quit]
broonie has quit [Server closed connection]
broonie has joined #u-boot
zear has joined #u-boot
<zear>
hey guys
<zear>
checkpatch keeps tripping on "Use 'if (IS_ENABLED(CONFIG...))' instead of '#if or #ifdef' where possible" in my code, however most of those places are outside function bodies, and where they are, inserting C style if statement would reference symbols that don't exist if the condition is false. Should I safely ignore those warnings and proceed with sending the patch for review as-is?
Clamor has quit [Ping timeout: 240 seconds]
Clamor has joined #u-boot
Clamor has quit [Read error: Connection reset by peer]
Clamor has joined #u-boot
Clamor has quit [Ping timeout: 244 seconds]
Clamor has joined #u-boot
<paulbarker>
zear: I've seen the same warnings in similar situations. I think you just have to focus on the "where possible" in that wording
* zear
nods
<zear>
thanks, I'll proceed with sending the patch and see where that goes :)
thopiekar_ has quit [Ping timeout: 252 seconds]
thopiekar has joined #u-boot
f_ has joined #u-boot
smoothdev has quit [Quit: smoothdev]
monstr has joined #u-boot
<Forty-Bot>
it's a warning and not an error for a reason
goliath has quit [Quit: SIGSEGV]
thopiekar has quit [Ping timeout: 264 seconds]
thopiekar has joined #u-boot
stefanro has quit [Quit: Leaving.]
vagrantc has joined #u-boot
smoothdev has joined #u-boot
Clamor has quit [Ping timeout: 260 seconds]
Clamor has joined #u-boot
mmu_man has quit [Ping timeout: 252 seconds]
frieder has quit [Remote host closed the connection]
<f_>
I disabled MMC support in TPL for now. I'll investigate later
sjg1 has quit [Server closed connection]
sjg1 has joined #u-boot
mmu_man has joined #u-boot
qqq has quit [Remote host closed the connection]
mmu_man has quit [Ping timeout: 245 seconds]
umbramalison has joined #u-boot
ikarso has quit [Quit: Connection closed for inactivity]
<umbramalison>
Learning uboot. the board folder is confusing me. For instance, in ti folder, there is am57xx, which isn't a board on it's own. but it's board.c file describes multiple boards. So two questions, 1 is board.c\h files not deprecated? and 2, is it right to append new boards here rather than in a new folder? the vendor of the board isn't really ti is it? not sure why beaglebone-x15 is in here
mmu_man has joined #u-boot
<umbramalison>
reason i'm picking this apart is that I have both a phytec am57 dev kit (which seemingly never swam upstream) and a custom board with an am57 on it that I need to bring up
goliath has joined #u-boot
Xogium has joined #u-boot
<Xogium>
is there any way to make u-boot pass 2 mac addresses to linux ? I've set ethaddr, eth1addr and eth2addr, but linux gets the same mac for 2 different eth devices
<Xogium>
my vendor left the OTP empty so no mac burned up there. But I suspect, even if there was, linux would still get the same mac for the 2 interfaces
<silurian_invader>
the mac addresses should be set in the appropriate devicetree nodes based on /aliases
<Xogium>
silurian_invader: how do you mean ? My dt has nvmem cell selecting mac for eth1, but since it's empty, well
<Xogium>
all 0's
<silurian_invader>
U-Boot will set local-mac-address (I think)
<Xogium>
eht2 has no such nvmem cell
<Xogium>
nop it just tells me invalid address
<silurian_invader>
there are three things to check: is local-mac-address set in Linux's devicetree properly, is the alias correct, and does U-Boot have the env vars set correctly
<Xogium>
there's no mac address set in dt
<Xogium>
it just tries to access a nvmem cell, aka the OTP
<silurian_invader>
in your runtime dt?
<Xogium>
in u-boot and in linux
<silurian_invader>
ok, check your aliases
<Xogium>
aliases has the typical stuff, serial0, serial1, ethernet0 and so on
<Xogium>
but I haven't seen any mac address aliases
<silurian_invader>
just for the ethernet
<silurian_invader>
you can add some debugs to fdt_fixup_ethernet
<Xogium>
I'm a bit confused there, I thought mac addresses would be randomly assigned
<silurian_invader>
only if you enable the appropriate config and there is no environmental variable
<Xogium>
I know another bootloader where it finds the srial number stored in the OTP and generates a mac based on this at runtime. Is that what u-boot can do also ?
<silurian_invader>
yes
<Xogium>
*serial
<silurian_invader>
sometimes it is done in board code; the generic way is the nvmem framework
<Xogium>
what do I need to have access to for it to do that though ?
<Xogium>
hmm
<silurian_invader>
but first make sure your env vars are making their way to Linux
<silurian_invader>
if you set ethXaddr, U-Boot should set the appropriate variables
<Xogium>
well ethaddr is definitely taken into account, and dupplicated on the two eth devices
<Xogium>
eth1addr and eth2addr don't seem to matter at all. In fact if I only set those two, u-boot will refuse to do nfs saying eth1 address not set
<Xogium>
it absolutely wants ethaddr set
Clamor has quit [Read error: Connection reset by peer]
<Xogium>
I do have an eeprom, but I've never toyed with one of these just yet
<marex>
Xogium: is that the devkit ?
<marex>
135F ?
goliath has quit [Quit: SIGSEGV]
<marex>
I think I will have much to discuss next week with ST
<Xogium>
no, a board from seeed. They've just done so poor a job at software that using the st softwares is better
<Xogium>
st is nice and actually provides a mac address
<Xogium>
seeed doesn't
<Xogium>
so I'm rather confused. I understand that eht1 has a nvmem cell associated to the OTP, which is invalid since it's enpty. I don't get however, why setting eth1addr and eth2addr seems to have no effect, and why I must absolutely set ethaddr, which then gets picked up by linux, duplicating it on both interfaces
prabhakarlad has joined #u-boot
<Xogium>
maybe I have to write a board file for it, as well. I don't quite know. Seeed didn't write one of those, either. They've just copied a dt, along with broken things they didn't bother checking if were fine to copy like enabling secure boot peripherals on a SoC that doesn't have them, added in the makefile for dts and that was it
slobodan has quit [Read error: Connection reset by peer]
<marex>
Xogium: hold on
slobodan has joined #u-boot
<marex>
Xogium: see fdt_fixup_ethernet() in common/fdt_support.c , is that called just before kernel boot ?
<marex>
Xogium: notice the eth%daddr part there
<marex>
Xogium: does your Linux DT have /aliases/ethernet0 and /aliases/ethernet1 ?
mps has quit [Ping timeout: 244 seconds]
<Xogium>
yea
<Xogium>
both for u-boot and for linux, actually
mps has joined #u-boot
<marex>
Xogium: does U-Boot create local-mac-address node in the ethernet device nodes ?
<marex>
Xogium: in Linux, find /sys/firmware -name local-mac-address
<Xogium>
let me check
<Xogium>
it has it set, but it is binary so can't read its content
<Xogium>
but there's that, definitely
Clamor has quit [Ping timeout: 244 seconds]
ikarso has joined #u-boot
<marex>
Xogium: hexdump -vC or od -tx4
<Xogium>
hmm good idea
<Xogium>
marex: the mac address is the same for both interfaces, eth1 and eth2
<Xogium>
duplicated eth1
vagrantc has quit [Ping timeout: 240 seconds]
vagrantc has joined #u-boot
<marex>
Xogium: how about the /sys/firmware/...aliases/ethernet* , does that point to different MACs ?
<silurian_invader>
*does that point to different ethernet interfaces
<Xogium>
silurian_invader: yes, eth1@5800a00 and eth2@5800e00
<silurian_invader>
anyway, I suggest the same thing as before: add some debugs to fdt_fixup_ethernet
<Xogium>
I can try. I'm not very good at C and quite slow, but I'll try
<silurian_invader>
getting a little good at C will be invaluble for getting linux systems working ;)
<Xogium>
heh
<Xogium>
it's just very slow with only text to speech
<Xogium>
the good thing I guess is I've got an eeprom to toy with, so I could in theory store 2 mac addresses in there and tell linux and u-boot to grab this via the nvmem cell. I just don't quite know if u-boot sees eeprom as nvmem like linux does
<silurian_invader>
if you enable CONFIG_NVMEM and CONFIG_I2C_EEPROM, U-Boot will see it like Linux does (more or less)
<Xogium>
so then I can store data in there and retrieve it with the dt nvmem cell property ?
<Xogium>
I mean I have OTP, but I'd rather not store the mac in there, cause, it's well, OTP
gmcastil_at_work has joined #u-boot
gmcastil has quit [Ping timeout: 244 seconds]
slobodan has quit [Ping timeout: 255 seconds]
prabhakarlad has quit [Quit: Client closed]
<silurian_invader>
yes
pivi has quit [Ping timeout: 252 seconds]
ikarso has quit [Quit: Connection closed for inactivity]