iamfrankenstein has quit [Ping timeout: 272 seconds]
reinforce has joined #linux-sunxi
alexxy has joined #linux-sunxi
sunshavi has quit [Ping timeout: 244 seconds]
vagrantc has joined #linux-sunxi
CC0422 has joined #linux-sunxi
fkluknav has joined #linux-sunxi
vagrantc has quit [Quit: leaving]
clemens3_ has joined #linux-sunxi
CC0422 has quit [Quit: -a- IRC for Android 2.1.43]
fkluknav has quit [Ping timeout: 240 seconds]
f0xx has joined #linux-sunxi
plaes has quit [Quit: Changing server]
plaes has joined #linux-sunxi
plaes has quit [Changing host]
plaes has joined #linux-sunxi
plaes has quit [Client Quit]
plaes has joined #linux-sunxi
plaes has joined #linux-sunxi
plaes has quit [Changing host]
chewitt has quit [Quit: Adios!]
matthias_bgg has joined #linux-sunxi
yann|work has quit [Ping timeout: 252 seconds]
fkluknav has joined #linux-sunxi
msimpson has joined #linux-sunxi
Andy-D has joined #linux-sunxi
nuuuciano__ has joined #linux-sunxi
nuuuciano_ has quit [Ping timeout: 252 seconds]
Kwiboo has quit [Ping timeout: 252 seconds]
<lvrp16>
jernej: are there any limits on the size of the input planes for h3/h5?
<lvrp16>
can I have multiple 4k planes?
msimpson_ has joined #linux-sunxi
guest65776126 has joined #linux-sunxi
msimpson__ has joined #linux-sunxi
guest65776126 has quit [Client Quit]
msimpson has quit [Ping timeout: 240 seconds]
Gerwin_J has joined #linux-sunxi
msimpson_ has quit [Ping timeout: 245 seconds]
t0dd1v has quit [Quit: Connection closed for inactivity]
KotCzarny has quit [Ping timeout: 252 seconds]
KotCzarny has joined #linux-sunxi
alexxy has quit [Ping timeout: 252 seconds]
alexxy has joined #linux-sunxi
KotCzarny has quit [Ping timeout: 240 seconds]
KotCzarny has joined #linux-sunxi
KotCzarny has quit [Ping timeout: 246 seconds]
KotCzarny has joined #linux-sunxi
yann|work has joined #linux-sunxi
KotCzarny has quit [Ping timeout: 240 seconds]
KotCzarny has joined #linux-sunxi
swiftgeek has quit [Ping timeout: 246 seconds]
dev1990 has quit [Quit: Konversation terminated!]
florianH has joined #linux-sunxi
<lvrp16>
"H2+ is a variant of H3, targeted at low-end OTT boxes, which lacks Gigabit MAC and 4K HDMI output support." is this correct? 4K HDMI seems to work...
<KotCzarny>
did you try decoding at 4k?
<lvrp16>
no, hence why I am wondering whether I should test it
f0xx has quit [Ping timeout: 245 seconds]
pgreco has quit [Ping timeout: 240 seconds]
pgreco has joined #linux-sunxi
tuxillo has quit [Ping timeout: 246 seconds]
NiteHawk has joined #linux-sunxi
pgreco has quit [Ping timeout: 240 seconds]
tuxillo has joined #linux-sunxi
pgreco has joined #linux-sunxi
mavkhimenia has quit [Remote host closed the connection]
mavkhimenia has joined #linux-sunxi
f0xx has joined #linux-sunxi
msimpson_ has joined #linux-sunxi
matthias_bgg has quit [Read error: Connection reset by peer]
msimpson__ has quit [Ping timeout: 246 seconds]
Andy-D has quit [Remote host closed the connection]
matthias_bgg has joined #linux-sunxi
rexxster has quit [Remote host closed the connection]
tnovotny has joined #linux-sunxi
<plaes>
has anyone gotten the olimex-lime2-emmc boot from emmc?
<ElBarto>
I did a long time ago yes
<plaes>
ok, then it's PEBKAC issue ;)
<ElBarto>
what's your problem exactly ?
<plaes>
trying to install debian on eMMC
<plaes>
I can actually load rootfs and stuff from eMMC when booting from sd-card, but I cannot get it booting from eMMC
<ElBarto>
you have u-boot on the sd or eMMC ? (or both ?)
<plaes>
eMMC
<ElBarto>
and the u-boot part is ok ? I mean without an sdcad inserted you have u-boot ?
<plaes>
nope :(
<plaes>
I tried debian and armbian installers and couldn't get u-boot properly installed there
<plaes>
and then there's also two boot partitions on eMMC
<plaes>
all this is eMMC stuff is new to me
<ElBarto>
just dd u-boot from a running system on the eMMC ?
<plaes>
yeah, that's the plan now :)
mavkhimenia has quit [Remote host closed the connection]
mavkhimenia has joined #linux-sunxi
dddddd has joined #linux-sunxi
dev1990 has joined #linux-sunxi
<wens>
plaes: allwinner brom doesn't look at the eMMC boot partitions. ignore them
<plaes>
oh
<plaes>
thanks :)
hipboi has joined #linux-sunxi
The_Loko has joined #linux-sunxi
<plaes>
ok, so I should write 'u-boot-sunxi-with-spl.bin' to mmcblk0 ?
Guest33392 has left #linux-sunxi [#linux-sunxi]
jacobgorm_ has joined #linux-sunxi
jacobgorm has joined #linux-sunxi
jacobgorm has left #linux-sunxi [#linux-sunxi]
lurchi_ is now known as lurchi__
jacobgorm has joined #linux-sunxi
<jacobgorm>
wrt the uboot install issues;
<jacobgorm>
what I have found (using buildroot) is that the mainline uboot was unable to use the eMMC
<jacobgorm>
but when I switched to the linux-sunxi tree, and use the relevant defconfig from there, it worked
<jacobgorm>
also, the block device to dd to is mmcblk2 not 0
<jacobgorm>
hope this helps
<dgp>
jacobgorm: run diff on the two .config files, maybe there is some option you need not in mainline yet
<jacobgorm>
dgp: yes it may be been a config or the DTS missing the eMMC entry, for me switching buildroot to use another git tree was enough of a solution at the time
<dgp>
I actually prefer to point buildroot at my own kernel and uboot branches instead of messing around with patch directories.. :)
<jacobgorm>
dgp: yes I am on the brink of doing that for linux too, but I am helping a client with this, so it has to be kept as simple as possible
<jacobgorm>
I also have question of my own;
<jacobgorm>
did anyone succeed in writing to the H5's eFUSE/SID yet?
<jacobgorm>
I would like to use a higher entropy key than what is there from the factory, but so far I can only read not write it
lurchi__ is now known as lurchi_
<jacobgorm>
I added the missing write impl to Linux, but the writes appear to get ignore by the hardware
<dgp>
do you have the write supply wired up?
<jacobgorm>
no, I didnt change anything wrt wiring
<dgp>
from what I remember of the h2 and h3 there is a pin to supply power to write the efuse and it's not usually wired up
<jacobgorm>
dgp: ok ,that defeats my plan to use it for securing the boot then :-(
<dgp>
you're trying to use the signature verification in the boot rom?
<jacobgorm>
dgp: that would be the 2nd step, the 1st step would be to change the first 16 bytes to a proper-random value for use as board ID
<jacobgorm>
but yes, I would like to ideally switch on the TOC0 stuff, to prevent the board booting unsigned uboots/kernels
<jacobgorm>
is the efuse fully writable NVRAM, or is it actually made with fuses?
<dgp>
AFAIK it's fuses. You pop a fuse and it's popped forever
<jacobgorm>
dgp: ok, which I suppose means the bits can be set not cleared right?
<dgp>
And to stop you from popping fuses in the future the supply is on a special pin you don't wire up
<dgp>
jacobgorm: I think so
<jacobgorm>
dgp: thanks, I'll have to consult with my hardware guys then, to see if they can give me a wire then
<dgp>
I'm not sure if anyone has gotten the secure boot stuff working. I looked at the bootrom code for the H3 and it looked pretty simple but I never got around to actually trying it
<jacobgorm>
dgp: I imagine you need a large stack of boards to get it working, as you'll likely brick a few before you understand what is going on
<dgp>
yeah. For a similar chip the advice was to get a test socket so chips instead of boards could be thrown away
<jacobgorm>
dgp: that is a good idea, thanks
<dgp>
a few orange pis is cheaper than a BGA test socket though :)
<plaes>
:D
<jacobgorm>
yes, I am on the friendlyarm nanos, I should be able get a good stack of those if I need them
<MoeIcenowy>
lvrp16: as I know, in BSP less memory is reserved for H2+
<MoeIcenowy>
which may prevents H2+ from decoding 4K
rexxster has joined #linux-sunxi
<MoeIcenowy>
but in mainline we don't have this mechanism
<MoeIcenowy>
dgp: H2+ BROM has a N-BROM and a S-BROM
<MoeIcenowy>
S-BROM seems to be resposible for secure boot
<dgp>
MoeIcenowy: Yeah and the code for the S-BROM is in on of the SDK dumps and it shows you just need a trusted cert in the OTP and a signed u-boot
<dgp>
I think we had this conversation a few years ago :)
<MoeIcenowy>
dgp: I don't think it's in SDK dump
<MoeIcenowy>
the "sbrom" in it seems to be TOC0
<dgp>
The source I looked at showed where the cert should be I and think the format the binary needed to be in
<dgp>
and I think we had this conversation and came to the conclusion that it should be easy to do but getting it working will probably result in a few dead boards
<jacobgorm>
if anyone has an interest in freelancing this I'd be happy to
<jacobgorm>
try and set something up with my client
The_Loko has quit [Remote host closed the connection]
<dgp>
jacobgorm: I think there should be tools from allwinner that write the OTP and do the bootloader signing. Finding them might not be easy
<dgp>
maybe one of those sellers on taobao that sells schematics and sdks could get them
The_Loko has joined #linux-sunxi
<jacobgorm>
dgp: thanks
<dgp>
assuming they actually tested it works ;)
<plaes>
hrm.. I have rev. K board of Lime2 :S
<MoeIcenowy>
dgp: I think it's called DragonKey
<MoeIcenowy>
which is used to write rotpk
<MoeIcenowy>
and the secure boot bit is burned by the BSP flashing process
<jacobgorm>
jemk: and if anybody can boot the board from other media, then they can also read out the secret from the efuse
<dgp>
Sounds like it's good enough to stop most people poking around
<dgp>
jacobgorm: there are i2c secure elements you could use instead to store some secrets
<jemk>
(the link above is the code to use the backdoor, just a 'smc #0' call from fel)
<dgp>
The main reason I wanted to use the secure boot was to have a signed image on SPI flash and not have it super simple to get it to boot anything else but I think I gave up because it looked like the secure boot rom couldn't boot from SPI
<jacobgorm>
dgp: you mean I could attach the secure element over i2c?
<MoeIcenowy>
jemk: oh haven't seen you on IRC for a long time
<jacobgorm>
I was hoping to do this with a vanilla nanopi plus2 board though
<jacobgorm>
if I could prevent the board ever booting unsigned code, I could put my secrets in the efuse
<jemk>
MoeIcenowy: yeah, I sometimes watch when I have the time, but since I'm not up-to-date with current things I rarely speak
<jacobgorm>
I could also put them on the eMMC, but then somebody with a soldering iron migth still be able to get to them
<dgp>
jacobgorm: stick the whole thing in epoxy
<jacobgorm>
dpg: yes that is an option, will the heat dissipate through that though? we are maxing out the CPU
megi has joined #linux-sunxi
<jemk>
The only way to boot unsigned code is over fel (so far), the normal boot seems to be safe.
<dgp>
put some mains through the usb pins to deactivate them?
<jacobgorm>
dgp: yes we can do that
<jacobgorm>
probably glue up the sdcard slot as well
<KotCzarny>
jemk: does it that key (extracted from sid) can be used to sign another code?
<jemk>
KotCzarny: no, the efuse/sid only contains a sha256 hash of the public key
<jacobgorm>
KotCzarny: In the normal case I would say no, it is just a hash of a public key
t0dd1v has joined #linux-sunxi
reinforce has quit [Quit: Leaving.]
JohnDoe_71Rus has joined #linux-sunxi
fkluknav has quit [Ping timeout: 244 seconds]
<jacobgorm>
jemk: so what you are saying is that if I manage to get secure boot going for the eMMC/SD, then it can only be bypassed through FEL?
<jacobgorm>
jemk: but that is almost a good thing, because it means I can recover a bricked board that way, right?
<jacobgorm>
jemk: in then in production, perhaps I can kill the USB port some way
<KotCzarny>
epoxy?
<KotCzarny>
:)
<jemk>
jacobgorm: yes, only bypass I found so far is fel-mode
<jacobgorm>
jemk: and for writing to SID, I need to wire up a PIN?
<jacobgorm>
pin
<jacobgorm>
sorry
<karlp>
hrm, nanopi neoplus 2 is smaller thanI thought. I should have bought that. seems to have much better supported wifi than the rtl8189ftv on the orangepi zero plus
<karlp>
proper emmc for a rootfs too.
<jacobgorm>
karlp: yes it is a great little board
<jemk>
jacobgorm: I think so, some power for the efuse block, but most devboards seem to have it wired
<buZz>
karlp: i like the friendlyarm boards
<buZz>
especially the ones where 'no pin headers' are an option
<jemk>
if it's wired you can however also use fel do disable secure boot again, by flipping additional fuses
<karlp>
ahh, mcirousb is not OTG capable, that's why I crossed it off the list first
<karlp>
probably much better for a different project, but wasns't suitable at the time
<jacobgorm>
jemk: what I tried was add the write support to linux, but writes seemed to have no effect
<buZz>
its not? i thought the 'nanopi neo2 core' does have that
<jacobgorm>
jemk: perhaps because I was writing from /dev/zero
<karlp>
well, it says power only.
<karlp>
and the schmeatic shows it's not connected, so can't even use gadgetmode stuff, let alone dual role
<karlp>
yeah, that's no fun for anyting more than a proto :)
<buZz>
hehe, well
<buZz>
'final product' is just 1 item
<buZz>
so its still fine
<karlp>
does the BT work as well with that out of three driver?
<buZz>
yeah
<jemk>
jacobgorm: I manually wrote my fuses from u-boot, since it was just a test. Did you use the right programming sequence? You can't just write directly to the fuses
<karlp>
yeah, core module says that the microusb is both power and otg,
<buZz>
hmhm, and its even smaller ;)
<karlp>
the neoplus2 is just power
<buZz>
although the heatsink on that is quite big
<karlp>
yeah, but gotta add ethernet back onto it.
<buZz>
hmhm
<karlp>
(for my needs)
<jacobgorm>
jemk: no I probably didn't do it right, I just wrote the addresses directly, reverse of what the linux read code does
<jacobgorm>
jemk: on the H5 it works to read them directly, but must be different for writes then?
swiftgeek has joined #linux-sunxi
dev1990_ has joined #linux-sunxi
<jernej>
lvrp16: I never tried multiple 4K images
<swiftgeek>
somehow my a13 boards dies on http://dpaste.com/17HPRXT (goes into reset) and i can't trace down where pwm-backlight backlight does come from. If i stop it at initrd stage, it works there without issue (so it cannot be some strange watchdog)
<jemk>
jacobgorm: there was some code somewhere in bsp, can't find it right now. I used the u-boot commandline, so no code.
dev1990 has quit [Ping timeout: 272 seconds]
<jernej>
lvrp16: On mainline scaling down images with width greater than 2048 doesn't work yet
<jernej>
but non-scaled 4K should work (others reported that it works)