<macromorgan>
I can see the EMMC just fine and write to it, I'm just trying to do some fancy stuff
<macromorgan>
okay I'll keep at it. I can't even seem to get U-Boot to see the eMMC when I put the stuff in the user partition
<macromorgan>
I guess I need to get that working first before I try something more fancy
<diederik>
I wasn't even aware of issues wrt eMMC; I just saw a bunch of recent commits with "mmc:" prefix
vagrantc has quit [Quit: leaving]
<dlg>
im booting an rk3568 off emmc
hexdump0815 has quit [Ping timeout: 260 seconds]
hexdump0815 has joined #linux-rockchip
macromorgan has quit [Read error: Connection reset by peer]
macromorgan has joined #linux-rockchip
lurchi__ has quit [Ping timeout: 246 seconds]
lurchi_ has joined #linux-rockchip
lurchi_ is now known as lurchi__
camus has quit [Ping timeout: 248 seconds]
matthias_bgg has joined #linux-rockchip
camus has joined #linux-rockchip
manawyrm has quit [Quit: Read error: 2.99792458 x 10^8 meters/second (Excessive speed of light)]
urja has quit [Read error: Connection reset by peer]
urja has joined #linux-rockchip
matthias_bgg has quit [Ping timeout: 240 seconds]
<paulk>
macromorgan: maybe that's mentionned in the TRM boot part?
stikonas has joined #linux-rockchip
jaganteki has joined #linux-rockchip
matthias_bgg has joined #linux-rockchip
stikonas has quit [Ping timeout: 265 seconds]
manawyrm has joined #linux-rockchip
pnill has quit [Ping timeout: 276 seconds]
rajkosto has joined #linux-rockchip
matthias_bgg has quit [Ping timeout: 268 seconds]
macromorgan has quit [Read error: Connection reset by peer]
macromorgan has joined #linux-rockchip
jaganteki has quit [Ping timeout: 245 seconds]
matthias_bgg has joined #linux-rockchip
macromorgan has quit [Read error: Connection reset by peer]
macromorgan has joined #linux-rockchip
Tenkawa has joined #linux-rockchip
macromorgan has quit [Read error: Connection reset by peer]
macromorgan has joined #linux-rockchip
<macromorgan>
paulk: The TRM boot section just says supports eMMC booting. In volume two though the sdhci documentation makes mention of hardware boot partition support and I see a few registers to that end. I'm just curious really if the BROM does...
<macromorgan>
dlg: You write idbloader.img to sector 64 right, just like an sdmmc card?
rajkosto has quit [Read error: Connection reset by peer]
macromorgan has quit [Read error: Connection reset by peer]
macromorgan has joined #linux-rockchip
Stat_headcrabed has joined #linux-rockchip
<Kwiboo>
macromorgan: I did not do any tests with hw boot partition, only writing rockchip-u-boot.bin to sector 64 using a emmc usb reader/writer
<Kwiboo>
are you basing on v2023.07-rc1? there is still some patches in flight that could be needed
<Kwiboo>
e.g. a patch to include pinctrl in SPL for sdmmc/sdhci/fspi, needed if you run tpl+spl from spi and want to load u-boot proper from sd/emmc
matthias_bgg has quit [Quit: Leaving]
<macromorgan>
2023.04, but I'm still working on it. For now I need a safe way to recover from a bad eMMC flash (I haven't bricked it yet but I'm planning ahead). My eMMC is soldered on the board and I can't find a test pin yet for the eMMC clk.
<CounterPillow>
is there a maskrom button/pad? That way you could force the soc to boot into maskrom and then flash over rockusb
vagrantc has joined #linux-rockchip
robmur01 has quit [Ping timeout: 252 seconds]
<macromorgan>
unless the BROM reads the status of an ADC or GPIO button, there isn't
<macromorgan>
honestly times like this it would be nice to have a bit more detail what the BROM actually does
<CounterPillow>
well there specifically is provision for a "recovery" gpio/button in the brom, which is what I meant. If it's not used on the board in some way though that may be a problem
<macromorgan>
okay cool, will check that and confirm the behavior
<CounterPillow>
so if there's a way you can get to one of those pins and ground them during boot you can get to maskrom
kevery has quit [Ping timeout: 240 seconds]
kevery1 is now known as kevery
<CounterPillow>
it also does the saradc recovery thing but the text there seems to indicate that if your thing is completely bricked you need to ground the pins to get it to maskrom
<CounterPillow>
so uh, happy testpoint hunting :P
robmur01 has joined #linux-rockchip
<macromorgan>
yeah, I don't have testpoints on a 356x platform to play with, only undocumented devices with no schematics
<macromorgan>
3588 I have a nice Rock 5B and Indiedroid Nova with full schematics though, which helps immensely (even if the schematics are sometimes wrong)
Stat_headcrabed has quit [Quit: Stat_headcrabed]
chewitt has joined #linux-rockchip
<CounterPillow>
I'd check the PCB around the eMMC chip, there might just be a pad on that D0 somewhere, since their factory/development house might need it too :)
<robmur01>
yup, I've found test points from the reference designs still present on TV box boards (albeit unlabelled and in not-too-obvious places)
tlwoerner has quit [Quit: Leaving]
tlwoerner has joined #linux-rockchip
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 252 seconds]
kevery1 is now known as kevery
stikonas has joined #linux-rockchip
jaganteki has joined #linux-rockchip
jaganteki has quit [Ping timeout: 245 seconds]
macromorgan has quit [Read error: Connection reset by peer]
macromorgan has joined #linux-rockchip
camus1 has joined #linux-rockchip
camus has quit [Ping timeout: 250 seconds]
camus1 is now known as camus
jaganteki has joined #linux-rockchip
Stat_headcrabed has joined #linux-rockchip
stikonas has quit [Remote host closed the connection]
stikonas has joined #linux-rockchip
Stat_headcrabed has quit [Quit: Stat_headcrabed]
jaganteki has quit [Ping timeout: 245 seconds]
unjust has joined #linux-rockchip
f476_ has quit [Ping timeout: 240 seconds]
<hexdump0815>
paulk: will try to retest pbp suspend/resume in the next days, but i'm very sure that it worked well for me with towboot
hexdump0815 has quit [Quit: WeeChat 1.9.1]
<Tenkawa>
I've never had suspend/resume work on the PBP (I run with Towboot)... only suspend... it boots back up as it was a crash/full restart
<paulk>
I've tried the rtc alarm too, same result
<paulk>
now it feels like swd/jtag is the way to go to debug this
<paulk>
it seems that the PMU interrupt registers I found the other day do not help
<paulk>
I have some vague memory of the PMU having a microcontroller for fine power management
<paulk>
but the chromiumos team ended up using the M0 instead
<paulk>
because of some issue with the PMU uC
<paulk>
anyway those registers seem to be to wake the PMU, not the main CPU
<paulk>
and the M0 does not seem to be doing a whole lot during suspend/resume
<paulk>
it just sets a few bits at specific steps of the fsm
<paulk>
and then goes wfi
<paulk>
as far as I can understand the suspend process puts all cores down and then puts CPU0 into wfi
<paulk>
with a resume path from sram since dram is brought down by the PMU fsm
<paulk>
anyway if anyone has more details about the process I'd definitely be interested