ChanServ changed the topic of #linux-sunxi to: Allwinner/sunxi development - Did you try looking at our wiki? https://linux-sunxi.org - Don't ask to ask. Just ask and wait for an answer! - This channel is logged at https://oftc.irclog.whitequark.org/linux-sunxi
evgeny_boger has quit [Ping timeout: 480 seconds]
radxanaoki has joined #linux-sunxi
hexdump0815 has joined #linux-sunxi
hexdump02 has quit [Ping timeout: 480 seconds]
ftg has quit [Read error: Connection reset by peer]
<Lightsword> I have a h616 based device which appears to have the uart console disabled somehow, any idea how that might be done? I do have root ssh access but can't seem to figure out how to get any serial console output at all
apritzel has quit [Ping timeout: 480 seconds]
Daanct12 has joined #linux-sunxi
radxanaoki1 has joined #linux-sunxi
radxanaoki has quit [Ping timeout: 480 seconds]
gsz has joined #linux-sunxi
hexdump02 has joined #linux-sunxi
hexdump01 has quit [Ping timeout: 480 seconds]
dsimic is now known as Guest12359
dsimic has joined #linux-sunxi
Guest12359 has quit [Ping timeout: 480 seconds]
vagrantc has quit [Quit: leaving]
JohnDoe_71Rus has joined #linux-sunxi
gsz has quit [Ping timeout: 480 seconds]
vveapon has quit []
vveapon has joined #linux-sunxi
montjoie_ has joined #linux-sunxi
montjoie has quit [Ping timeout: 480 seconds]
gsz has joined #linux-sunxi
gsz has quit [Ping timeout: 480 seconds]
gsz has joined #linux-sunxi
apritzel has joined #linux-sunxi
hlauer[m] has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
gsz has quit [Ping timeout: 480 seconds]
warpme has joined #linux-sunxi
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
radxanaoki1 has quit []
evgeny_boger has joined #linux-sunxi
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
apritzel has joined #linux-sunxi
<apritzel> Lightsword: is that on some vendor provided firmware? And this one doesn't provide a console to UART0?
<apritzel> or don't you get any serial output at all, so this might be a hardware issue?
Net147_ has joined #linux-sunxi
Net147 has quit [Read error: Connection reset by peer]
apritzel has quit [Ping timeout: 480 seconds]
ftg has joined #linux-sunxi
warpme has quit []
warpme has joined #linux-sunxi
gsz has joined #linux-sunxi
apritzel has joined #linux-sunxi
warpme has quit []
evgeny_boger has quit [Ping timeout: 480 seconds]
Daanct12 has quit [Quit: WeeChat 4.6.0]
buZz_ is now known as buZz
apritzel has quit [Ping timeout: 480 seconds]
IlikeTech has quit [Read error: Connection reset by peer]
IlikeTech has joined #linux-sunxi
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
psydroid|2 has quit []
ungeskriptet has quit [Ping timeout: 480 seconds]
<Lightsword> apritzel, it's on some sort of vendor firmware, since I can get ssh access is there a way to say re-renable the uart from linux if they disabled it in uboot?
apritzel has joined #linux-sunxi
<Lightsword> apritzel, it's on some sort of vendor firmware, since I can get ssh access is there a way to say re-renable the uart from linux if they disabled it in uboot?
evgeny_boger has joined #linux-sunxi
<apritzel> it's tricky if UART0 is not enabled in the DT, otherwise it's a matter of running a "getty" on it
<apritzel> Lightsword: you should be able to test that with just: echo foo > /dev/ttyS0
<Lightsword> apritzel, I had the idea of running echo in a loop myself, tried it already, didn't work, in the linux cmdline console is def set to ttyS0 as well
<Lightsword> my guess is that they lock down the uart console by misconfiguring the uart0 port during early initialization somehow as an anti-reverseengineering measure
<apritzel> so do you see any kind of activity on that UART at all? Basically all of the AW based vendor firmware we have seen output boot information on UART0, and often enable a Linux console there
<Lightsword> no, we even scoped the uart ports, nothing at all
<apritzel> what kind of device is this? We have seen missing FETs on some devices, which disconnect the UART pins on the SoC from the pins on the board
<Lightsword> apritzel, control card for bitcoin miner
<apritzel> this is an example, see the emtpy SOT23 footprint next to the UART pins on the photo: https://linux-sunxi.org/Eachlink_H6_Mini#Adding_a_serial_port_.28might_void_warranty.3F.29
<Lightsword> apritzel, hmm, that only affects ability to send commands to the device right?
<apritzel> depends, on some boards it also affected the TX pin
<apritzel> (as in: another missing resistor)
<Lightsword> apritzel, hmm, how would I determine if the board I have has the issue, I see some vaguely similar looking pads need the uart header area
<apritzel> you could scope on any of those pads, typically vendor firmware is quite chatty during boot
<Lightsword> I know the vendor that makes these cards is a big fan of elaborate anti-reverseengineering techniques in general(I've already broken many of those in various ways which is how I have ssh access).
<apritzel> or directly touch the RX pin of a UART adapter, that worked for me in the past
<apritzel> yeah, was wondering, typically board vendors using Allwinner SoCs don't care much about that, on many TV boxes you get a root shell on the UART by just typing "su" ;-)
<apritzel> but AW is not a good platform for really securing things
<Lightsword> apritzel, yeah these guys are really try-harding to prevent 3rd parties from gaining access, everything from obfsucated UPX packed binaries to funky ramdisk encryption and LUKS encrypted filesystem partitions
<Lightsword> apritzel, can efuses be used to lock down uart's? they can lock down jtag at a minimum right?
<apritzel> Lightsword: there is little known about the efuses details, but I haven't heard of any like this
<apritzel> what are you after, exactly? if you have a root shell already, what would the UART give you?
<Lightsword> apritzel, I'm trying to manipulate the bootup/debug process essentially, for replacing their OS/kernel with my own
<Lightsword> manipulate/debug the bootup process*
<Lightsword> hexdump -C /sys/bus/nvmem/devices/sunxi-sid0/nvmem is how ones dumps efuse registers right?
<Lightsword> apritzel, another theory I have is that they are somehow using pinctrl configurations to kill the uart port in uboot, no idea how I would verify that though
evgeny_boger1 has joined #linux-sunxi
<apritzel> do you see /dev/ttyS0 in Linux, and can you write something to it without errors? Then output something in a loop, and try to scope those pads near the UART pins
<Lightsword> apritzel, yeah I can write to that in linux just fine, ttyS0 is what is configured for the kernel to use in cmdline as well
<Lightsword> yeah, trying to poke around at that
<apritzel> you can manually poke the pinctrl on the shell, using devmem2 or my peekpoke: https://github.com/apritzel/peekpoke
<apritzel> I made a statically linked binary of that for that purpose, mostly to dump the pinctrl configuration, but you can write to that as well
evgeny_boger has quit [Ping timeout: 480 seconds]
<Lightsword> apritzel, oh, they disable /dev/mem somehow as well
<apritzel> well, they just not enable it in the kernel config, I guess. Have you tried mknod'ing the device file manually?
<Lightsword> apritzel, I think it's some secureboot related lockdown which disables it
<apritzel> like: mknod /dev/mem c 1 1
<Lightsword> I tried mknod'ing it already I think
<Lightsword> hmm, although "mknod /dev/mem c 1 1" did seem to do something
<apritzel> well, yes, but it still doesn't mean it works: chardev 1 1 can be configured out of the kernel build
<apritzel> do they have /proc/config.gz?
<Lightsword> nope, disabled
<Lightsword> yeah, it doesn't seem to work
<apritzel> is there a "FEL" pad on the board? Sometimes labelled "uboot" as well
<Lightsword> apritzel, not that I'm seeing, most stuff is labeled with a letter+number on the board
<apritzel> does the device have an SD card? Or do they use eMMC? Or even just SPI flash?
<Lightsword> apritzel, SD card slot is how firmware is restored/flashed, device normally runs from nand or something though
<apritzel> so it boots from the SD card? do you have an update image or something?
<apritzel> because then it should be quite easy to boot a fully mainline firmware on it (U-Boot + TF-A + mainline kernel)
<apritzel> if you don't need graphics output or the integrated Ethernet PHY, then the H616 is quite well supported
<apritzel> there is some "secure boot" method for Allwinner, where the BootROM verifies the first code executed (boot0 or SPL), but we haven't seen a device yet that actually burns the key hashes, so every key works
<apritzel> which means you can create a TOC0 wrapped U-Boot, signing it using your own key, and it would boot
<apritzel> at least that's the situation on all "secure boot" devices we have seen out there so far
<apritzel> so the device seems to use raw NAND flash, which we don't support in mainline
<Lightsword> apritzel, yeah there's a bunch of restore images the vendor provides, there's no graphics output but it does have ethernet, main issue I have is that without uart I can't seem to debug the startup at all
<Lightsword> I tried poking various pads with a ttl cable while echoing to /dev/ttyS0, sometimes I get a bunch of garbage on the line but nothing readable
hentai has joined #linux-sunxi
<Lightsword> I know the vendor also makes use of the trusted execution environment on these boards as well for reverse engineering protections.
hexdump01 has joined #linux-sunxi
<Lightsword> apritzel, btw I see this in the pinctrl-maps for uart0, not sure if this looks normal or not though https://gist.github.com/jameshilliard/03442c8e7aa2c629f17ad3d975915399#file-pinctrl-maps-L214-L274
psydroid has joined #linux-sunxi
hexdump0815 has quit [Ping timeout: 480 seconds]
psydroid has quit []
psydroid has joined #linux-sunxi
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
gsz has quit [Quit: leaving]
warpme has joined #linux-sunxi
hentai has quit [Remote host closed the connection]
hentai has joined #linux-sunxi
<gamiee> hi, i would like to ask, how is H618 in terms of thermals? Does it produces a lot of heat? (like, in comparison with H3 which does not have proper CPU voltage regulation)
colinsane has joined #linux-sunxi
<Lightsword> I think the header I was looking at was an unpopulated FEL USB header
Ixnus has joined #linux-sunxi
JohnDoe_71Rus has quit [Quit: KVIrc KVIrc Quasar 5.2.6, revision: 5.2.6+git-7609-afed1336e, build type: debug, sources date: 20160102, built on: 2024-12-18 20:43:05 UTC 5.2.6+git-7609-]
colinsane has quit [Ping timeout: 480 seconds]
colinsane has joined #linux-sunxi
ungeskriptet has joined #linux-sunxi
psydroid has quit []
hentai has quit [Remote host closed the connection]
hentai has joined #linux-sunxi
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
warpme has quit []
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
<apritzel> Lightsword: so yes, all AW SoCs so far have UART0 pinmuxed to the SD card pins. Problem is you lose access to the SD card when you want that
<apritzel> what's weird is their mapping of PI7/PI8 to UART0, because it's PH0/PH1
<Lightsword> apritzel, how do I verify if the SD card pinmux is currently active from linux?
<apritzel> does the SD card work? that would give you the answer, I guess. Or you check pinctrl-maps for PF2 and PF4
<apritzel> Lightsword: can you check if your vendor images have "eGON" or "TOC0" in their first few bytes?
<apritzel> and for UART over SD access I have this one: https://www.sparkfun.com/sparkfun-microsd-sniffer.html
<Lightsword> apritzel, I see toc0 when I extract the vendor images
<apritzel> allows me to boot from SD card, then switch to UART
<apritzel> Lightsword: so in this case I wonder if you grab mainline U-Boot, do "make orangepi_zero2_defconfig", then make menuconfig to set SPL_IMAGE_TYPE_SUNXI_TOC0=y, then "make"
<Lightsword> apritzel, I tried the orangepi3 image from buildroot I think
<apritzel> then "dd if=spl/sunxi-spl.bin of=/dev/sdX bs=1k seek=8" to an SD card reader
<apritzel> they are all unsigned eGON images, the BROM will refuse to boot
<apritzel> I guess none of those images would boot easily anyway, and be it for
<apritzel> ... different DRAM parameters
<apritzel> but at least they should produce some output on UART0
<apritzel> there is also CONFIG_UART0_PORT_F=y, to have UART output on the SD pins (if you have a sniffer)
<Lightsword> apritzel, what lines does mainline uboot pinmux uart0 to?
<apritzel> PH0/PH1, that's the only pins outside of the SD card pins that the SoC supports
<apritzel> the PF2/PF4 pinmux are purely for debug/recovery, not for normal operation
<apritzel> PI7/PI8 as mentioned in your dump is one of the UART2 pinmuxes, actually
<apritzel> but it's RTS/CTS, so no good anyway
evgeny_boger has joined #linux-sunxi
evgeny_boger1 has quit [Ping timeout: 480 seconds]
evgeny_boger has quit [Remote host closed the connection]
ungeskriptet_ has joined #linux-sunxi
Ixnus has quit [Remote host closed the connection]
ungeskriptet has quit [Ping timeout: 480 seconds]
ungeskriptet_ has quit [Ping timeout: 480 seconds]
ungeskriptet has joined #linux-sunxi
kilobyte has quit [Ping timeout: 480 seconds]
kilobyte has joined #linux-sunxi
hentai has quit [Quit: SIGTERM]