<Pinchiukas>
Looks like odroid-c2 has this same SoC.
<Pinchiukas>
Hmm I burned its image onto an SD card and still it booted the Android. This is so hard because I can't get an UART to see what's happening or interact with it.
gamiee has quit [Remote host closed the connection]
apritzel has quit [Ping timeout: 480 seconds]
macromorgan has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
ftg has quit [Ping timeout: 480 seconds]
vagrantc has quit [Quit: leaving]
mripard_ has joined #linux-sunxi
mripard has quit [Ping timeout: 480 seconds]
JohnDoe_71Rus has joined #linux-sunxi
JohnDoe_71Rus has quit []
bauen1 has quit [Ping timeout: 480 seconds]
apritzel has joined #linux-sunxi
AntoniAloyTorrens[m] has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
bauen1 has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
enick_689 has joined #linux-sunxi
gsz has joined #linux-sunxi
aperezdc has joined #linux-sunxi
aperezdc is now known as Guest2068
Tooniis[m] has joined #linux-sunxi
apritzel has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
Guest2068 is now known as aperezdc
bauen1 has quit [Remote host closed the connection]
apritzel has joined #linux-sunxi
mripard_ has quit []
mripard has joined #linux-sunxi
landnode has joined #linux-sunxi
evgeny_boger has quit [Quit: evgeny_boger]
evgeny_boger has joined #linux-sunxi
bauen1 has joined #linux-sunxi
bauen1 has quit []
bauen1 has joined #linux-sunxi
bauen1 has quit []
bauen1 has joined #linux-sunxi
rajkosto has joined #linux-sunxi
hakkou has joined #linux-sunxi
<bauen1>
the u-boot configurations for e.g. pine-a64-lts, pine-h6 should probably enable CONFIG_SPI=y, CONFIG_SPI_DM=y, CONFIG_CMD_SF=y, CONFIG_SPI_FLASH=y ; that flash is only good for something if you can access it
<bauen1>
weirdly enough `sf probe` then fails with `Invalid bus`, so i'm still doing something wrong
<bauen1>
oh, it's disabled in the device tree because of the shared pin ...
<bauen1>
yeah, it's just easier to add a git remote and merge a branch
<bauen1>
apritzel: and in theory, "sf probe" should then work ?
<apritzel>
bauen1: well, if everything else is in place, which means an alias in the DT and the DT node being enabled
<bauen1>
hm, `** Warning - spi_flash_probe_bus_cs() failed, using default environment`, so something is still off, let me play around some more with my defconfig
<apritzel>
I think the DT spi0 alias is somewhat annoying here, I wonder if we should patch that in similar to what we do with the mmc alias
<apritzel>
bauen1: defconfig should be good now for the Pine64-LTS
evgeny_boger has joined #linux-sunxi
evgeny_boger has quit []
<apritzel>
bauen1: thanks for testing this, and please do complain if something doesn't work
<apritzel>
the plan is to make this work out of the box
evgeny_boger has joined #linux-sunxi
evgeny_boger1 has joined #linux-sunxi
<bauen1>
apritzel: so as far as i understand u-boot code, ft_board_setup only gets called when booting another image, so the spi flash would not be available to u-boot itself but only to linux ?
<apritzel>
bauen1: yes, that's one problem
<apritzel>
but we could patch the DT that U-Boot gets to see, using the -u-boot.dtsi mechanism
evgeny_boger has quit [Ping timeout: 480 seconds]
<apritzel>
since the H6 hack patches it both ways
<bauen1>
getting u-boot to use the spi flash for also keeping its variables is the interesting part for me
<apritzel>
bauen1: I totally agree
<apritzel>
technically U-Boot doesn't use devices concurrently, so we could get away with it
<apritzel>
but the current code doesn't do the pinmux setup on device init, but only once at probe time
<bauen1>
that sounds like a horrible temporary workaround that becomes a feature, i love it :D
<apritzel>
well, we could all hide this behind this SUNXI_H6_ENABLE_SPIFLASH symbol, in the true U-Boot fashion ;-)
<bauen1>
apritzel: so manually changing the status in the dtsi after adjusting my defconfig to match the SPI adjustments you made for pine_h64 it can now access the spi-flash from u-boot, so some parts of your patch series worked
<apritzel>
in general enabling/disabling the pinmux when needed doesn't sound too bad, architecturally. This might become cleaner with smaeul's DT pinmux series
evgeny_boger1 has quit [Ping timeout: 480 seconds]
JohnDoe_71Rus has joined #linux-sunxi
<bauen1>
smaeul: in mmc_get_env_dev CONFIG_SYS_MMC_ENV_DEV isn't always defined
cnxsoft has quit []
<bauen1>
and another question, i'm trying to hook up a tpm2 to spi1, for that i've modified the dtsi to enable spi1 and add a tpm node, but how exactly do i reference the PD17 pin on the pio gpio controller for the reset-gpios field ?
<bauen1>
or rather why is sunxi doing things in a seemingly special way with pins defined as part of `pio` ?
<apritzel>
bauen1: do you mean: reset-gpios = <&pio 3 17 GPIO_ACTIVE_LOW>;?
<apritzel>
and what do you mean with "special way", exactly?
<bauen1>
i think i was confusing telling pio to setup pins with special functions and accessing gpio
<apritzel>
"pio" is just the label we use to point to the GPIO/pinmux controller, which is the same device on Allwinner
<apritzel>
pio: pinctrl@300b000 {
<bauen1>
thanks, i'm getting the hang of it again
<bauen1>
i still need to figure out how to make the spi driver use PC16 as CS, is that even trivial ? seems that the PIO only supports setting PH3 as SPI1_CS
<bauen1>
or at least if i'm understanding drivers/spi/spi-sunxi.c right, there is no way to use an arbitrary pin for CS
<bauen1>
but maybe i can just pull CS low before accessing the tpm hm
<apritzel>
bauen1: it *should* work to just specify any random GPIO as chip select
<apritzel>
the SPI IP seems to support 4 internal chip selects, but only one of them seems to be wired in most SoCs that I checked
<bauen1>
apritzel: but where would i do that, in the pio to setup the port as special function port ?
<apritzel>
bauen1: no, in the SPI DT node, let me find this again ...
<apritzel>
problem is that I figured lately that the GPIO chip selects doesn't really work, for some reason. But I haven't found the time to really debug this
<bauen1>
but wouldn't the u-boot/drivers/spi/spi-sunxi.c need to support that ?
<apritzel>
that is actually a generic Linux SPI subsystem feature
<bauen1>
apritzel: i'm still in u-boot not linux :/
<apritzel>
I haven't checked U-Boot in this regard
<apritzel>
the point is that this is more a generic DT feature, so U-Boot could just implement this - if it doesn't already
<bauen1>
weird, if i do `gpio clear PC16` then `tpm2 init` complains about `tpm_tis_spi_probe: missing reset GPIO` again ...
<bauen1>
apritzel: thanks, seems that is sometimes supported by u-boot, but i see no mention of it in th sunxi_spi driver
<apritzel>
bauen1: because the gpio command grabs that pin away?
<bauen1>
it really shouldn't ...
<apritzel>
bauen1: there wouldn't need to be a mention of it in the specific driver, necessarily
<bauen1>
is the gpio bank 0 or 1 indexed ?
<apritzel>
0 = A, 1 = B , ..
<apritzel>
bauen1: in Linux the CS GPIO is handled by the subsystem, it just calls into the driver for the "native" CS feature
<apritzel>
bauen1: "it really shouldn't"> why not? You just explicitly requested control over this GPIO, probably for a reason, now a device wants to grab this as well: that sounds like a conflict
<bauen1>
apritzel: well, the reset and cs pin should be different
<apritzel>
bauen1: oh, you mean PC16 is the CS, and there is another reset pin?
<apritzel>
if looks like the driver requires a reset GPIO, why don't you just give it one in the DT?
<bauen1>
apritzel: so i did that, the correct one if `<&pio 3 17 GPIO_ACTIVE_LOW>` is PD17
<bauen1>
apritzel: now i also need to set the chip select but i was trying to "work around" that by just pulling PC16 lown before running `tpm2 init`
<apritzel>
that's what I thought, but then you really get this error above?
<bauen1>
apritzel: yes
<bauen1>
gpio: pin PC16 (gpio 80) value is 0
<bauen1>
tpm_tis_spi_probe: missing reset GPIO
<bauen1>
and i'm a bit confused, as those should be separate pins right
<bauen1>
there's a few other options, set PC16 to input and short it with PH3, the normal SPI1_CS ; find a soldering iron to move the 0 Ohm resistor on this letstrust TPM a few milimeters over
<apritzel>
so that means something goes wrong with claiming this GPIO
<apritzel>
that should work in general, since we use that function in sunxi-mmc.c
<bauen1>
apritzel: what do you mean by "<that> should work in general" ?
<apritzel>
bauen1: are you running on latest master? I think you need one of smaeul's patches (just merged last week) to allow parameters to gpio_request_by_name()
<apritzel>
I mean this way of claiming a GPIO
<bauen1>
i wonder if `PC16: output: 1 [x] macpwr` is screwing with me
<apritzel>
ah, of course!
<apritzel>
so yes, it's already claimed by Ethernet
<bauen1>
any u-boot command to "unclaim it" ?
<bauen1>
and a much better question, what is ethernet doing with that pin
<apritzel>
actually you should not use that pin at all, because it's wired on the board laready
<apritzel>
it enables power to the Ethernet *PHY*, I think
<apritzel>
it's a bit weird, but actually many of the GPIO header pins on the LTS and PineH64 are internally wired already, for instance to the SPI flash and eMMC
<apritzel>
to keep compatibility with the original Pine64
<bauen1>
i think i'll just use a bunch of wires to make it use cs0 for testing
<apritzel>
bauen1: this is caused by CONFIG_MACPWR="PC16" in the defconfig
<apritzel>
which is also referenced as "gpio = <&pio 2 16 GPIO_ACTIVE_HIGH>;" in the DT, in the gmac-3v3 node
<apritzel>
and used by "phy-supply = <®_gmac_3v3>;" in the emac node
ftg has joined #linux-sunxi
<bauen1>
apritzel: yes, you've added that in 3940a471553a31cda4e19024a1bf5bbdc4ac9e46
<bauen1>
apritzel: actually the `tpm_tis_spi_probe: missing reset GPIO` happens when invoking `tpm2 init` for the second time, so that's just the tpm2 command being broken
<apritzel>
bauen1: I think I double checked this, but indeed the schematic I stare at says MAC-RST is at PD6 ...
<apritzel>
bauen1: but yeah, it shouldn't claim again unless it has released that pin before
<apritzel>
yeah, that's what I just said, but I am pretty sure this is more a bug in the schematic
<apritzel>
CONFIG_MACPWR is PC16 because the DT says so as well, and so far the sunxi U-Boot code cannot parse the DT properly to catch this
<bauen1>
so right now i have https://paste.debian.net/1229919/ for the dtsi, and connected the letstrust tpm over wires to 3.3v, GND, MOSI, MISO, CLK, CE0, RESET/PD17 and of course it's not working :D
<apritzel>
and CE0 is connected to PH3?
<apritzel>
but in general I am not too much surprised, enabling random drivers or features in U-Boot rarely works out of the box ;-)
<bauen1>
apritzel: yes, i've tested it with both PH3 - CE0, PH3 - CE1
<Pinchiukas>
Any ideas how to figure out why my S905 device isn't booting from the SD card? I think I toasted the UART interface while trying to solder the headers. :(
<apritzel>
Pinchiukas: have you tried #linux-amlogic over at Libera?
<Pinchiukas>
apritzel: no but I will, thanks!
<bauen1>
and something i did along the way broke ethernet, it only "sends once" and then linux can't seem to send packages over the phy (the switches led doesn't light up) ; who doesn't like fun bugs
kilobyte_ch has joined #linux-sunxi
<bauen1>
and trying another thing, the i2c1_pins also uses PH5 / PH6 but comes after the spi1 pins declaration, so lets see if commenting it out helps ; really shouldn't make a difference - and it did not
kilobyte2 has joined #linux-sunxi
kilobyte1 has quit [Ping timeout: 480 seconds]
kilobyte_ch has quit [Ping timeout: 480 seconds]
apritzel has quit [Ping timeout: 480 seconds]
<bauen1>
i think i may have found the problem, sunxi_gpio_set_cfgpin(pin = 228, val = 4) is wrong, val should be 2 ; probably because nobody was ever crazy enough to use SPI1 instead of SPI0
<bauen1>
at least now it's no longer timing out on spi transfer, so i suppose that's progress :D
<bauen1>
so at least the sunxi spi driver uses the wrong "cfg" value for the pins when configuring SPI1
JohnDoe_71Rus has quit []
prefixcactus has quit [Ping timeout: 480 seconds]
apritzel has joined #linux-sunxi
<bauen1>
apritzel: i figured out one problem, the sunxi spi driver uses the wrong cfg value when configuring pins for spi1
<apritzel>
shocking! ;-)
<apritzel>
bauen1: until recently even SPI0 wouldn't work, because of a similar issue
<apritzel>
bauen1: but I guess you know the drill: patches welcomed
gamiee has joined #linux-sunxi
PPAChao has joined #linux-sunxi
hakkou has quit []
menomc has joined #linux-sunxi
heap01__ has joined #linux-sunxi
maz_ has joined #linux-sunxi
aggi has quit [charon.oftc.net helix.oftc.net]
karlp has quit [charon.oftc.net helix.oftc.net]
megi1 has quit [charon.oftc.net helix.oftc.net]
juri_ has quit [charon.oftc.net helix.oftc.net]
libv has quit [charon.oftc.net helix.oftc.net]
jernej has quit [charon.oftc.net helix.oftc.net]
sajattack[m] has quit [charon.oftc.net helix.oftc.net]
mnemoc has quit [charon.oftc.net helix.oftc.net]
juri__ has joined #linux-sunxi
<bauen1>
`tpm2 init` still doesn't work, but in theory the spi bus now works and it finds a device, just can't talk to it or something like that
<apritzel>
bauen1: did you try with Linux?
<bauen1>
not yet
karlp has joined #linux-sunxi
aggi has joined #linux-sunxi
megi1 has joined #linux-sunxi
DuClare has joined #linux-sunxi
sajattack[m] has joined #linux-sunxi
jernej has joined #linux-sunxi
libv has joined #linux-sunxi
diego71 has joined #linux-sunxi
aedancullen has joined #linux-sunxi
DavidHeidelberg[m] has joined #linux-sunxi
swiftgeek has joined #linux-sunxi
DavidHeidelberg[m] has quit [Server closed connection]
DavidHeidelberg[m] has joined #linux-sunxi
sunshavi has quit [Remote host closed the connection]
sunshavi has joined #linux-sunxi
sajattack[m] has quit [Server closed connection]
sajattack[m] has joined #linux-sunxi
diego71 has quit [Ping timeout: 480 seconds]
* karlp
is kinda glad he didn't push ahead on his plan to use spiflash on a sunxi board, and just has emmc instead :)
<bauen1>
karlp: well, the spi flash is working quite well now, the tpm isn't :D