persmule has quit [Remote host closed the connection]
sbach has quit [Ping timeout: 252 seconds]
persmule has joined #u-boot
clamor has joined #u-boot
goliath has joined #u-boot
sbach has joined #u-boot
vardhan has quit [Ping timeout: 252 seconds]
gsz has joined #u-boot
monstr has joined #u-boot
sbach has quit [Ping timeout: 244 seconds]
mwalle has joined #u-boot
monstr has quit [Ping timeout: 252 seconds]
haritz has quit [Remote host closed the connection]
monstr has joined #u-boot
mckoan|away is now known as mckoan
Tyaku has joined #u-boot
<Tyaku>
marex: Which feature are you talking about when you say "WRITEABLE ENV" ? Because what you talk about seems to be what I try to use. I know about "Vendor Parameter Protection" so that we can "protect" some variables, but it works on the CLI but doesn't seems to work with fw_setenv.
<Tyaku>
The idea of this trick is: Ok we are not able to secure U-Boot-Env (because no encryption etc). But we can secure the bootargs and make sure when we call bootm only two variants of bootargs are accepted: The variant to boot in partition 1 and the variant to boot in partition 2. So at this point, if any variables is changed: no problems. it will simply not boot. This is the heavy artillery but should work.
sbach has joined #u-boot
ldevulder has joined #u-boot
eballetbo has joined #u-boot
goliath has quit [Ping timeout: 252 seconds]
naoki has quit [Ping timeout: 272 seconds]
sbach has quit [Ping timeout: 272 seconds]
ikarso has joined #u-boot
sbach has joined #u-boot
goliath has joined #u-boot
sbach has quit [Ping timeout: 252 seconds]
persmule has quit [Ping timeout: 264 seconds]
sbach has joined #u-boot
monstr has quit [Ping timeout: 252 seconds]
persmule has joined #u-boot
sbach has quit [Ping timeout: 268 seconds]
naoki has joined #u-boot
brujah has joined #u-boot
naoki1 has joined #u-boot
naoki1 has quit [Client Quit]
naoki has quit [Ping timeout: 248 seconds]
naoki has joined #u-boot
naoki1 has joined #u-boot
naoki has quit [Ping timeout: 276 seconds]
naoki has joined #u-boot
naoki1 has quit [Ping timeout: 248 seconds]
naoki1 has joined #u-boot
naoki has quit [Ping timeout: 252 seconds]
naoki1 is now known as naoki
naoki has quit [Client Quit]
naoki1 has joined #u-boot
naoki1 has quit [Read error: Connection reset by peer]
naoki has joined #u-boot
naoki1 has joined #u-boot
clamor has quit [Ping timeout: 265 seconds]
clamor has joined #u-boot
naoki has quit [Ping timeout: 244 seconds]
naoki1 has quit [Ping timeout: 252 seconds]
K900 has quit [Remote host closed the connection]
K900 has joined #u-boot
naoki has joined #u-boot
<marex>
Tyaku: CONFIG_ENV_WRITEABLE_LIST and CFG_ENV_FLAGS_LIST_STATIC
<marex>
Tyaku: the fw_* tools can write into the environment storage whatever they want, but U-Boot will import only whatever is in CFG_ENV_FLAGS_LIST_STATIC into its environment, the rest is used from its built-in environment copy
sbach has joined #u-boot
gsz has quit [Ping timeout: 252 seconds]
<Tyaku>
marex: Thanks I'm going to check it!!!!!
<Tyaku>
If it works; it prevents me to use the heavy artillery which is good.
<Tyaku>
hum, it seems to be the same mechanism as the mechanism to lock ethaddr variable. If yes, it doesn't lock anything from fw_setenv.
rfs613 has quit [Quit: restart]
rfs613 has joined #u-boot
clamor has quit [Read error: Connection reset by peer]
clamor has joined #u-boot
f_|DEPRECATED has quit [Remote host closed the connection]
mmu_man has joined #u-boot
naoki1 has joined #u-boot
mckoan is now known as mckoan|away
sbach has quit [Ping timeout: 268 seconds]
naoki has quit [Ping timeout: 276 seconds]
naoki1 has quit [Ping timeout: 244 seconds]
naoki has joined #u-boot
bjoto has joined #u-boot
<marex>
Tyaku: what do you mean "lock anything" ?
<Tyaku>
marex: From the CLI: If I change ethaddr, then it's not possible to change (the protection take effect). From Linux, with fw_setenv we can write ethaddr as we want, so yes on reboot it takes a now mac address. So the "protection" provided by these flags is not always working.
<Tyaku>
The reason is also probably because we enable the ethaddr protection on u-boot, but not on fw_setenv (this is two different recipes on yocto). But anyways if it's the reason, then it's is not a security at all. (anybody can build a fw_setenv/libubootenv and write it).
<marex>
Tyaku: could it be that your board code is messing with ethaddr ?
<marex>
hmmmmm, write-once ... I wonder how well that mixes with CONFIG_ENV_WRITEABLE_LIST and CFG_ENV_FLAGS_LIST_STATIC
<marex>
I dont think I ever used the 'o' modifier with writeable list, it was always either ... fully writeable unconditionally (and the variable was always an integer or boolean) or read-only
<marex>
I think you should be able to set the variable as read-only, let board-code set the variable up (or board env scripts set it) and that should work
<marex>
dont make the variable writeable in env storage itself
levitating has quit [Read error: Connection reset by peer]
levitating has joined #u-boot
levitating has quit [Quit: levitating]
levitating has joined #u-boot
levitating has quit [Read error: Connection reset by peer]
levitating has joined #u-boot
sbach has quit [Ping timeout: 244 seconds]
KREYREN has joined #u-boot
sszy has joined #u-boot
<Tyaku>
Even the readonly stuff, in my case it's not an option.
<Tyaku>
If a variable is read-only, then when U-Boot start, it wont be loaded in the environement.
<Tyaku>
bootargs needs to be calculated in startup by some variables (to adjust boot source, etc).
<Tyaku>
Is it normal that Read only variables produce this on startup ? '## Error: Can't create "adjustbootsource"' -> They wont be loaded in environment so wont be used when they are part of a script.
<Tyaku>
This is right after 'Loading Environment from MMC...'
sbach has joined #u-boot
<Tyaku>
I also implemented the suggestion of my previous link, it seems to be working: Like so: If we try to change the bootargs, then when booti/m command is used, it check bootargs before starting the kernel.
KREYREN has quit [Remote host closed the connection]
KREYREN has joined #u-boot
sbach has quit [Ping timeout: 260 seconds]
KREYREN has quit [Ping timeout: 264 seconds]
sakman has joined #u-boot
Tyaku has quit [Ping timeout: 276 seconds]
naoki has quit [Quit: naoki]
goliath has quit [Quit: SIGSEGV]
Tyaku has joined #u-boot
haritz has joined #u-boot
haritz has joined #u-boot
haritz has quit [Changing host]
Tyaku has quit [Ping timeout: 244 seconds]
ikarso has quit [Quit: Connection closed for inactivity]
ikarso has joined #u-boot
ldevulder has quit [Ping timeout: 272 seconds]
KREYREN has joined #u-boot
dsimic has quit [Ping timeout: 252 seconds]
dsimic has joined #u-boot
RoganDawes has joined #u-boot
<RoganDawes>
Hi folks. I have a MYZR EK140 (i.MX6ULL-based, 256MB RAM, 256MB NAND) module, and the vendor u-boot from 2016.3. What is the easiest way to get a mainline u-boot running on this? It's a bare module that I have soldered USB and UART to, and confirmed working using the vendor code drop.
<RoganDawes>
I got the vendor u-boot running using `make u-boot.imx && imx-usb u-boot.imx` - downloading via SDP
jfsimon1981a has quit [Remote host closed the connection]
jfsimon1981a has joined #u-boot
jfsimon1981a has quit [Remote host closed the connection]
jfsimon1981a has joined #u-boot
jfsimon1981a has quit [Remote host closed the connection]
<RoganDawes>
marex: Yeah, that probably makes the most sense. Will start by comparing the mainline mx6ull config and the vendor board files, etc to see where they diverge.
<RoganDawes>
Thanks
clamor has quit [Ping timeout: 276 seconds]
rvalue- has joined #u-boot
rvalue has quit [Ping timeout: 252 seconds]
clamor has joined #u-boot
rvalue- is now known as rvalue
eballetbo has quit [Quit: Connection closed for inactivity]
sbach has joined #u-boot
mmu_man has quit [Ping timeout: 268 seconds]
mmu_man has joined #u-boot
clamor has quit [Read error: Connection reset by peer]
KREYREN__ has joined #u-boot
KREYREN_ has quit [Remote host closed the connection]
sbach has quit [Ping timeout: 260 seconds]
<marex>
qschulz: I would argue we should only use well defined types, i.e. s32/u32/... and not int at all, unless the size does really not matter