<clementp[m]>
libv: I have 20 RPI4 running and it's just for benchmarking our algorithm on ARM64
<libv>
ok
<KotCzarny>
darn, that's a sweet rack
<libv>
so testing it is
<libv>
clementp[m]: what is the longevity on those displays?
<clementp[m]>
libv: I don't have display just POE Hat, display is useless
<libv>
but cool indeed
<clementp[m]>
I can have a script and can ssh each board and have a better display on my laptop remotely :P
<libv>
:)
<libv>
i immediately threw your little rack to the fosdem guys
<clementp[m]>
All the rack fully 3D printed are "bad" compare to this one
<libv>
as gerry wanted a secondary display so 100+ devices daisy chained would show their ip address on the status lcd, and the fear is/was that our brick sized goal would move the 3.5" display to the top, obscuring that information
<KotCzarny>
vertical mount also helps with cooling
<libv>
i still maintain that we should just waste 3x2.5m of wallspace for testing/deploying and properly tilt the devices, but the discussion is sporadically ongoing
<libv>
nice work
<libv>
hotsnot for the win ;)
<clementp[m]>
libv: if you use DHCP with dynamic IP you can either use mDNS, or IPv6 neighbor discovery. As our installation is now fixed with use static ip
<clementp[m]>
Each of the RPI4 is a gitlab ci worker but next plan is to have final product and use lava-ci
<clementp[m]>
to also validate kernel + drivers are working fine
<libv>
clementp[m]: there's now 60 of these, there will be 100 or so
<libv>
and each year they get set up afresh, after being used hard for 3d at the venue, and then just being tossed in their boxes and stored for 6-8 months
<libv>
and one of the first task is to verify that the note taped to the device matches the hostname
<libv>
so this is a recurring task
<ullbeking>
wow , that IS a sweet rack!!
<clementp[m]>
You mean this is a check to be sure that the HW that you think you are connected to is the correct one?
<clementp[m]>
You can use the UID in the SoC to generate the hostname ?
<libv>
clementp[m]: the board could have changed during the event
<clementp[m]>
But the Silicon stay the same
<ullbeking>
12:15 <libv> i immediately threw your little rack to the fosdem guys
<ullbeking>
what interest to the fosdem folk have with this rack?
<libv>
clementp[m]: hey, i do not do the deployment, i am working on making the replacement device
<libv>
ullbeking: read on
<libv>
anyway, interesting to see the oled in action, and sad to learn that it is not being actively used long term
<libv>
as that would be valuable info
<libv>
for me
<libv>
but depending on what the all-in-one device looks like, we will probably just wall mount them with their respective power-supplies and then daisy chain whole rows together
<libv>
and then the devices would be tilted so the 3.5"lcd will be front-facing
Mangy_Dog has joined #linux-sunxi
matthias_bgg has quit [Ping timeout: 256 seconds]
<clementp[m]>
Daisy chain make impossible to recognize the HW from the PHY it is plugged
<clementp[m]>
In a setup where we plug dynamically hardware
<clementp[m]>
we made VLAN for each port of the switch
<clementp[m]>
and can discover dynamically each product using this property
<clementp[m]>
But depending on the needs it could be proper as you will need less cables
<ullbeking>
brb
matthias_bgg has joined #linux-sunxi
<libv>
we could also daisy chain hdmi and analogue audio
<ullbeking>
clementp[m]: libv: this project you describe is super, super interesting :-)
<ullbeking>
libv: thank you, this is exactly what i've been looking for
apritzel has quit [Ping timeout: 240 seconds]
mps_ is now known as mps
jstein has joined #linux-sunxi
apritzel has joined #linux-sunxi
rex_victor has quit [Ping timeout: 272 seconds]
rex_victor has joined #linux-sunxi
apritzel has quit [Ping timeout: 272 seconds]
rex_victor has quit [Ping timeout: 240 seconds]
warpme_ has quit [Quit: Connection closed for inactivity]
rex_victor has joined #linux-sunxi
kaspter has quit [Quit: kaspter]
hexdump0815 has joined #linux-sunxi
<hexdump0815>
jernej: i did a bit more dd editing to the spl and now got them to probe the full memory - thus i can confirm what you mentioned before already i think: the h616 can use the full 4gb of ram and not only 3gb like the h6
<hexdump0815>
jernej: cpu performance wise the h616 (and h313 too) seem to be at the same level as a h6 for the same freq (1.3ghz for h313, 1.5ghz for h616 and 1.8ghz for h6) and the h616/h313 seem to run at a bit lower temps than the h6 for the same freq
<hexdump0815>
jernej: it looks like h313 are simply h616 which did not reach the qa level for the h616
iamfrankenstein has quit [Client Quit]
<jernej>
yeah, I come to the same conclusion regarding h313 and h616
apritzel has joined #linux-sunxi
<jernej>
anyway, I have to wait until I get next h616 board or sbc (I ordered both)
<jernej>
until then I can finish RE effort
lurchi_ is now known as lurchi__
lurchi__ is now known as lurchi_
sunshavi has quit [Read error: Connection reset by peer]
sunshavi has joined #linux-sunxi
vagrantc has joined #linux-sunxi
warpme_ has joined #linux-sunxi
niceplace has quit [Ping timeout: 256 seconds]
hexdump0815 has quit [Ping timeout: 245 seconds]
niceplace has joined #linux-sunxi
bauen1 has quit [Remote host closed the connection]
bauen1 has joined #linux-sunxi
lurchi_ is now known as lurchi__
apritzel has quit [Ping timeout: 244 seconds]
asdf28 has quit [Ping timeout: 258 seconds]
asdf28 has joined #linux-sunxi
jbrown has quit [Ping timeout: 246 seconds]
rex_victor has quit [Ping timeout: 246 seconds]
apritzel has joined #linux-sunxi
montjoie has quit [Remote host closed the connection]
gaston1980 has quit [Quit: Konversation terminated!]
gaston1980 has joined #linux-sunxi
gaston1980 has quit [Quit: Konversation terminated!]
montjoie has joined #linux-sunxi
tuxillo has joined #linux-sunxi
asdf28 has quit [Ping timeout: 260 seconds]
hexdump0815 has joined #linux-sunxi
gsz has quit [Ping timeout: 264 seconds]
<hexdump0815>
now i start to understand why people hate that allwinner bsp stuff so much: for instance the orange pi zero 2 image does not even read the dtb from the filesystem, but has it somehow glued to the u-boot in some way ...
<bauen1>
nice, just flashed an .xz to an microsd and wondering why it won't boot
gaston1980 has joined #linux-sunxi
<apritzel>
bauen1: you forgot to re-flash the BootROM as well ;-)
<bauen1>
i wish i could lol
<bauen1>
but i've managed to boot this pine a64 lts to linux with only uart
<bauen1>
still waiting on my usb cable to access fel and start digging at the sbrom
<bauen1>
u-boot appears to scan 4 different usb bus, a bit confusing since there should only really be 3
<bauen1>
i have to test the speed of usb 3.0 on the pine h64 tomorrow, the wiki doesn't seem to have any numbers
<bauen1>
not sure, but it should be faster than the 40mb/s achievable over the usb 2.0 from the pine a64 lts
<smaeul>
apritzel: MoeIcenowy: did either of you ever work with secure boot on the H6? Do you know if there are differences from A64/H5?
<smaeul>
I blew the LCJS fuse on a Pine H64, without programming a ROTPK hash, and it refuses to boot from a TOC0 image
<smaeul>
I can get into FEL, but the SMC workaround causes a hang, so I can't get into secure mode to dump SBROM
<smaeul>
I also tried the sboot shipped with the BSP, and SPL signed with dragonsecboot, and they don't boot either (they fall back to FEL)
<smaeul>
(bauen1: that's why I haven't provided an H6 SBROM dump yet)
<apritzel>
smaeul: sorry, never tried that on the H6
<apritzel>
smaeul: I just blew the fuse once on a Pine64, and FEL with SMC and TOC0 booting work there
<apritzel>
smaeul: reportedly there is another fuse (on the A64) to return to normal (eGON) boot, but that is then final
<apritzel>
smaeul: are you sure the ROTPK hash was empty?
<apritzel>
(but I guess you can't check this anymore)
<smaeul>
it was a factory-fresh Pine H64, so I would hope so... I believe I have a SID dump somewhere
<apritzel>
IIRC if you change all hash bits into 1's, you get back to this "ignore-hash" mode
<apritzel>
but again this won't be of help, I guess, since you can't access those bits from non-secure
<smaeul>
hmm, can't find the dump, and you're right, I can only access fuses up to 0x40 from non-secure
<smaeul>
I either need to find a way to switch back to secure from FEL (RMR? second CPU? DMA attack?) or a way to enter FEL without switching to non-secure (brute force the "enter FEL" function address in the SBROM")
<smaeul>
oh, but the second approach won't work, because the "put the entry address in the BROM" attack requires an already-valid TOC0
<apritzel>
and RMR only works from the highest exception level, which you are not in anymore
lurchi__ is now known as lurchi_
qschulz has quit [Remote host closed the connection]