camus has quit [Read error: Connection reset by peer]
camus has joined #u-boot
camus has quit [Remote host closed the connection]
camus has joined #u-boot
sbach has quit [Read error: Connection reset by peer]
sbach has joined #u-boot
camus has quit [Remote host closed the connection]
camus has joined #u-boot
mmu_man has quit [Ping timeout: 252 seconds]
camus has quit [Ping timeout: 264 seconds]
<hanetzer>
suppose that works.
camus has joined #u-boot
thopiekar has quit [Ping timeout: 252 seconds]
thopiekar has joined #u-boot
scientes has joined #u-boot
jclsn has quit [Ping timeout: 240 seconds]
jclsn has joined #u-boot
vagrantc has quit [Quit: leaving]
sakman has quit [Remote host closed the connection]
mrnuke has quit [Ping timeout: 240 seconds]
mrnuke has joined #u-boot
persmule has quit [Remote host closed the connection]
persmule has joined #u-boot
persmule has quit [Remote host closed the connection]
persmule has joined #u-boot
scientes has quit [Ping timeout: 252 seconds]
jagan has joined #u-boot
paddymahoney2 has joined #u-boot
paddymahoney2 has quit [Remote host closed the connection]
wyre_ is now known as wyre
akaWolf has quit [Ping timeout: 252 seconds]
persmule has quit [Remote host closed the connection]
persmule has joined #u-boot
hanetzer has quit [Ping timeout: 268 seconds]
hanetzer has joined #u-boot
akaWolf has joined #u-boot
hanetzer1 has joined #u-boot
hanetzer has quit [Ping timeout: 260 seconds]
ldevulder_ has quit [Quit: Leaving]
frieder has joined #u-boot
guillaume_g has joined #u-boot
GNUtoo has quit [Remote host closed the connection]
persmule has quit [Remote host closed the connection]
persmule has joined #u-boot
GNUtoo has joined #u-boot
ldevulder has joined #u-boot
tre has joined #u-boot
jagan has quit [Ping timeout: 260 seconds]
prabhakarlad has joined #u-boot
jagan has joined #u-boot
persmule has quit [Ping timeout: 258 seconds]
persmule has joined #u-boot
apritzel has joined #u-boot
elafon has quit [Ping timeout: 255 seconds]
elafon has joined #u-boot
pratyush has joined #u-boot
GNUtoo has quit [Remote host closed the connection]
persmule has quit [Remote host closed the connection]
persmule has joined #u-boot
GNUtoo has joined #u-boot
clarity_ is now known as clarity
jagan has quit [Ping timeout: 252 seconds]
pratyush_ has joined #u-boot
ddevault_ has joined #u-boot
ddevault has quit [Killed (zirconium.libera.chat (Nickname regained by services))]
ddevault_ is now known as ddevault
elafon has quit [*.net *.split]
pratyush has quit [*.net *.split]
mrnuke has quit [*.net *.split]
kallisti5[m]1 has quit [*.net *.split]
JBB[m] has quit [*.net *.split]
mvaittin has quit [*.net *.split]
tafama has quit [*.net *.split]
rvalue has quit [*.net *.split]
qschulz has quit [*.net *.split]
davlefou has quit [*.net *.split]
redbrain has quit [*.net *.split]
aggi has quit [*.net *.split]
jsmolic has quit [*.net *.split]
mlaga97 has quit [*.net *.split]
Epakai has quit [*.net *.split]
robher has quit [*.net *.split]
bq has quit [*.net *.split]
ldts has quit [*.net *.split]
m5zs7k has quit [*.net *.split]
cbmuser_ has quit [*.net *.split]
pratyush_ is now known as pratyush
robher has joined #u-boot
kallisti5[m]1 has joined #u-boot
qschulz has joined #u-boot
jsmolic has joined #u-boot
mrnuke has joined #u-boot
tafama has joined #u-boot
mvaittin has joined #u-boot
JBB[m] has joined #u-boot
aggi has joined #u-boot
rvalue has joined #u-boot
davlefou has joined #u-boot
mlaga97 has joined #u-boot
redbrain has joined #u-boot
bq has joined #u-boot
elafon has joined #u-boot
Epakai has joined #u-boot
ldts has joined #u-boot
m5zs7k has joined #u-boot
cbmuser_ has joined #u-boot
m5zs7k has quit [Max SendQ exceeded]
m5zs7k_ has joined #u-boot
m5zs7k_ is now known as m5zs7k
matthias_bgg has joined #u-boot
mmu_man has joined #u-boot
jagan has joined #u-boot
ldevulder has quit [Remote host closed the connection]
ldevulder has joined #u-boot
monstr has joined #u-boot
tre has quit [Remote host closed the connection]
sam_sepi0l has quit [Remote host closed the connection]
Ntemis has joined #u-boot
<Ntemis>
hello
<Ntemis>
i have an issue with rk3288
<Ntemis>
compile finishes ok but i get this scary logs
<Ntemis>
Image 'main-section' is missing external blobs and is non-functional: blob-ext Image 'main-section' has faked external blobs and is non-functional: tee.bin
<Ntemis>
it is still fuctional or i am missing anything essential for uboot to work?
<Ntemis>
Image 'main-section' is missing external blobs and is non-functional: blob-ext
<Ntemis>
Image 'main-section' has faked external blobs and is non-functional: tee.bin
<Ntemis>
H.e..l.p!
<Ntemis>
H.e.l.p!
<Ntemis>
H.e.lp!
<Ntemis>
H.elp!
<Ntemis>
Help!
<urja>
Chill your beans, you could start by telling us which rk3288 board you're targeting?
<urja>
And no, i have no clue about that, maybe someone will pass by who does.
minimal has joined #u-boot
<Ntemis>
@urja: can you help me witht he blobs produced? i am trying to understand how to flash them correctly
<Ntemis>
urja: can you help me witht he blobs produced? i am trying to understand how to flash them correctly
<Ntemis>
am targeting tinkerboard and miqi boards now btw
<Ntemis>
documentaion says i can usethis single u-boot-rockchip.bin and should boot fine, is that correct?
<Ntemis>
which is 8,9 MB btw
<Ntemis>
or do i need to use u-boot-rockchip.bin in stage1 and u-boot-dtb.img in stage 2
<Ntemis>
not very clear to me the correct steps
<sjg1>
Ntemis: Yes you are missing tee.bin but perhaps it doesn't matter. What instructions are you following?
<Ntemis>
sjg1: uboot compiles clean now , need further guidance on correct blobs i need to boot them up succefully
<sjg1>
Ntemis: What instructions are you following?
<vagrantc>
at least with most of the rockchip boards i've been using
<Ntemis>
so idbloader.img with u-boot.itb ?
<vagrantc>
yup
<vagrantc>
you typically need a different u-boot build for different boards though
<vagrantc>
e.g. not the *same* blobs ... but blobs built for the other board
<Ntemis>
do i have to use makeimage or i can take them sraight from uboot directory after they are compiled?
<Ntemis>
*straight
redbrain has quit [Read error: Connection reset by peer]
<vagrantc>
should work out of the box, unless there are some specific instructions for your specific board
<vagrantc>
see doc/README.rockchip
<Ntemis>
i have to support various boards Rock960/rockpro64/rockpi4/orangepi4
<vagrantc>
oh wow, the documentation for rk3399 still mentions running mkimage manually
<Ntemis>
thats why am here actually
<Ntemis>
bacause docu is a mess
<Ntemis>
*because
<vagrantc>
ah, it documents both approaches
<Ntemis>
i need the one that works so please enlight me
<vagrantc>
but still has the manual process to create idbloader ... gah.
<vagrantc>
Ntemis: it may be board-specific, so ...
<Ntemis>
how i know that?
<Ntemis>
and what i have to change
<vagrantc>
Ntemis: for the boards you listed, i know rockpro64 works with just writing idbloader.img and u-boot.itb to the standard offsets on microsd
<vagrantc>
ah, option 3 for rk3399 ... eesh. that's confusing
<vagrantc>
there are three different paths for rk3399 in README.rockchip ...
<vagrantc>
i use option 3 for all my rk3399 boards, except for puma-rk3399, which has it's own README
redbrain has joined #u-boot
<vagrantc>
Ntemis: dare i say it, but booting arm boards is just ... a mess ... so the documentation reflects that
<vagrantc>
there are often several different ways to accomplish something, and at various points in the development process one or the other didn't yet work, etc.
<Ntemis>
vagrantc: so you use idbloader.img and u-boot.itb directly from finished compiled u-boot directory without doing anything else to them(vanilla?)
<Ntemis>
i need to know that so i can continue
<Ntemis>
do you use any mkimage or/and cat magic on them?
<vagrantc>
Ntemis: yup, option 3 in rk3399 instructions for installing to microsd
<vagrantc>
Ntemis: no magic
<sjg1>
vagrantc: I don't use the idbloader on my 3399 boards, just the same instructions (even for SPI boot)
<Ntemis>
hmm also didnt wotk for me on rock960 and rockpro64 last time i tried that path
<Ntemis>
*work
<Ntemis>
sjg1: what do you use
<Ntemis>
please help me out by giving more details
<vagrantc>
sjg1: what do you mean by "same instructions" ?
<Ntemis>
exactly ^ this
<Ntemis>
we need to know what "same instructions" means to you
<Ntemis>
so you only flash u-boot-rockchip.bin and nothing else?
Ntemis has quit [Remote host closed the connection]
Ntemis has joined #u-boot
<sjg1>
yes
<sjg1>
This is just for U-Boot. I need to add a distro if using that
Ntemis has quit [Remote host closed the connection]
Ntemis has joined #u-boot
mmu_man has quit [Ping timeout: 268 seconds]
persmule has quit [Ping timeout: 258 seconds]
frieder has quit [Remote host closed the connection]
<Ntemis>
sure :)
<Ntemis>
ussually a kernel/initrd+extlinux
persmule has joined #u-boot
Guest44 has joined #u-boot
<Guest44>
hi
<Guest44>
im trying to get into the shell of this avermedia capture box via a uart adapter
<Guest44>
but every time i boot it this message pops up `"Hit any key to stop autoboot: 0 "`
<Forty-Bot>
try holding down a key while booting
<Guest44>
only nothing ever happens no matter how fast i press
<Guest44>
tried that too
<Forty-Bot>
before the message?
<Guest44>
picocom is up, box is turned off, key is maintained throughout the whole process
<Guest44>
and even then nothing changes
<Guest44>
ut just proceeds to extracting the kernel and finishing the boot process
<Forty-Bot>
hm, I don't know
<urja>
IIRC, if the boot delay is set to actually 0, it can be pretty much impossible to interrupt via UART
<Forty-Bot>
urja: if the uart has a buffer, you can often get a keypress in there before U-Boot checks it
<Forty-Bot>
Guest44: do you have access to the system after it boots?
<Forty-Bot>
if so you can try modifying the environment to add a better bootdelay
<urja>
I was about to go on that you should check that your TX is working tho
<Guest44>
nope that's the whole reason im trynna hack it
<Guest44>
the box has so much potential, but i cant even get my captured footage out through lan
<Guest44>
yeah i checked it with another router i have laying around and it works fine
<Guest44>
also i checked the solder and everything
<Guest44>
it's that boot delay thing i think (a security measure by the devs ig)
<Forty-Bot>
if they wanted a security measure they would have used -1 for bootdelay
<Forty-Bot>
which doesn't prompt
<Guest44>
hmm why chosing 0 instead
<kettenis_>
makes the board boot faster ;)
<Guest44>
it does turn to 1 after a while
<Guest44>
on its own i mean
<urja>
I had one board (a MIPS router...) where the TX (well RX on the router side :P) being shorted to ground caused it to just skip the countdown and continue booting
<urja>
I'm not sure if that was intentional or accidental (and if so, by who), so that's why i asked you to check it :P
<urja>
(I only noticed that when i couldnt login lol)
<urja>
and yeah, i don't think it is intentional security (if so, poor security), but just a "we dont need to wait in production, make it zero" (if its zero, that is)
mckoan is now known as mckoan|away
<Guest44>
yeah not in my case i have testing equipments and everything (a multi-meter :p) and i can confirm that there is no shortage
<Guest44>
where do you guys stand on asking devs for help with hacking devices
<Guest44>
cause i found an exploit that lead me to dump the rcS file and i found out some info about the dev
<Guest44>
i tracked him down, but he wouldnt answer my messages
<Guest44>
are they not allowed to?
<Guest44>
im not big on licenses and ip stuff
<Guest44>
i mean knowing they use open source software in their products i thought maybe there is a chance of them helping me
<urja>
more like, is there anything in it for them to respond? ... not really (and likely a chance to get in trouble at work)
<Guest44>
they guy wouldnt even tell me if the uart logic is 3.3 or 5v
<urja>
well that you can just multimeter...
<Guest44>
i almost fried my frdi thinking it was 3v3 at first lol
<Guest44>
that was before i bought a battery for my multimeter
<Guest44>
stupid move i know
<urja>
and if i had to bet, i'd put my money on the FTDI surviving that...
<Guest44>
its 5v and it survived it for some reason
<Guest44>
maybe it has some ic protection
<Guest44>
@urja
<urja>
it's only a couple of volts extra from an I/O pin... I'd actually guess on it flowing through protection diode to the FTDIs VCCIO and lifting it (and the FTDI is fine with VCCIO at 5V, so...)
<Guest44>
probably
<Guest44>
urja more like we Taiwanese devs dont help foreigners
<urja>
Yeah I've been on the internet trying to figure out how to find the developers of various pieces of firmware (for different things), and well I dunno where they spend their time, but it seems like not in the english web (or IRC for that matter)
<Guest44>
kinda off the topic question, but how do you think people figure out decryption keys of firmware
<Guest44>
do the keys exist on the firmware itself?
<Guest44>
im such a noob i should just give up lol
<Guest44>
always saddens me to see a piece of technology with so much wasted potential
<urja>
you don't, unless someone was stupid and pulled the private key off an example in an online tutorial
<urja>
(atleast if it's a proper public/private key system, basically they're leaked, or the system is broken in some other way)
<Guest44>
lol talk about a one in a million chance
<Guest44>
isnt that also what happened with the ps4
<Guest44>
"greenluigi1" lmao
<Guest44>
"found within the firmware"
<Guest44>
how did he know which portion to google though
<Forty-Bot>
xypron: so EFI payloads started by U-Boot are single-processor only?
persmule has quit [Remote host closed the connection]
persmule has joined #u-boot
justache- has joined #u-boot
Guest44 has quit [Quit: Client closed]
justache has quit [Ping timeout: 252 seconds]
minimal has left #u-boot [Leaving]
apritzel has quit [Ping timeout: 240 seconds]
GNUtoo has quit [Remote host closed the connection]
GNUtoo has joined #u-boot
vagrantc has quit [Quit: leaving]
pratyush has quit [Quit: Connection closed for inactivity]
mps has quit [Quit: leaving]
mps has joined #u-boot
<kettenis_>
all EFI implementations are single-processor only
Ntemis has quit [Remote host closed the connection]
Zapy_ has joined #u-boot
Zapy has quit [Ping timeout: 252 seconds]
Zapy_ is now known as Zapy
mmu_man has joined #u-boot
hanetzer1 is now known as hanetzer
sam_sepi0l has joined #u-boot
justache- is now known as justache
<Forty-Bot>
huh
<Forty-Bot>
so once the OS boots, how does it become multi-processor?
matthias_bgg has quit [Quit: Leaving]
<kettenis_>
the OS starts the secondary processors
<sjg1>
Forty-Bot: kettenis_ For x86, I think the firmware actually starts the other CPUs. At least that is what happens in U-Boot. But they are just parked up ready for the OS
vagrantc has joined #u-boot
vagrantc has quit [Quit: leaving]
<Forty-Bot>
so how does it work in U-Boot?
<Forty-Bot>
because the harts are parked by U-Boot and (presumably) can only be un-parked by U-Boot
<Forty-Bot>
AIUI regular Linux on RISC-V expects to be called by all harts
<marex>
Forty-Bot: there are different ways how this can be achieved
<marex>
Forty-Bot: for example, on ancient SMP MIPS, all CPU cores started and jumped to reset vector, but each CPU core could do some instruction which would return its CPU ID (core number)
<marex>
so the code at reset vector would do basically (if cpuid==0 , continue ; else busy wait in a loop for variable at some address to be set and once set, jump to specified address)
<marex>
the OS would then set the address, set the variable, and the core would enter some secondary_cpu_os_entrypoint() function
<marex>
Forty-Bot: more modern SoC may have per-CPU core jump address in some registers, so when the primary CPU pulls secondary CPUs from reset, they immediatelly jump to that address, that avoids the spinning on trampoline
<marex>
Forty-Bot: sometimes, OS does that, sometimes the firmware does that (like PSCI)