ChanServ changed the topic of #linux-rockchip to: Rockchip development discussion | IRC log http://irclog.whitequark.org/linux-rockchip | Community GH https://github.com/linux-rockchip | Rockchip GH https://github.com/rockchip-linux | ML https://groups.google.com/group/linux-rockchip
vstehle has quit [Ping timeout: 245 seconds]
lkcl has quit [Ping timeout: 252 seconds]
anarsoul|2 has quit [Ping timeout: 244 seconds]
kaspter has quit [Remote host closed the connection]
kaspter has joined #linux-rockchip
vstehle has joined #linux-rockchip
_whitelogger has joined #linux-rockchip
<hanetzer> s_frit: you're prolly gonna have a bad time with that
<s_frit> hanetzer: hence why i am asking first. what's your theory?
<hanetzer> s_frit: my theory is ARM SoC are really close to being an entire mobo in a package, and one snafu will put you out of the whole thing.
<s_frit> hanetzer: do you know if the SoC is likely to have more than one silicon die?
<s_frit> i was thinking of trying to find a dead one to experiment on
<hanetzer> s_frit: this one? don't think so, but some SoC have dram in the package as well :P
_whitelogger has joined #linux-rockchip
_whitelogger has joined #linux-rockchip
_whitelogger has joined #linux-rockchip
lkcl has joined #linux-rockchip
ayaka has quit [Ping timeout: 252 seconds]
ayaka has joined #linux-rockchip
ayaka has quit [Ping timeout: 252 seconds]
ayaka has joined #linux-rockchip
vicencb has joined #linux-rockchip
lkcl has quit [Ping timeout: 252 seconds]
s_frit has quit [Remote host closed the connection]
s_frit has joined #linux-rockchip
lkcl has joined #linux-rockchip
ShapeShifter499 has quit [Quit: ZNC 1.7.1 - https://znc.in]
vicencb has quit [Remote host closed the connection]
vicencb has joined #linux-rockchip
s_frit has quit [Remote host closed the connection]
s_frit has joined #linux-rockchip
_whitelogger has joined #linux-rockchip
urjaman has quit [Ping timeout: 240 seconds]
urjaman has joined #linux-rockchip
vicencb has quit [Quit: Leaving.]
ldevulder_ has quit [Read error: Connection reset by peer]
ldevulder_ has joined #linux-rockchip
lkcl has quit [Ping timeout: 252 seconds]
default__ has joined #linux-rockchip
ldevulder_ has quit [Ping timeout: 244 seconds]
<mmind00> asciilifeform: the comment section on your blog fails due to the captcha-service being shutdown
<mmind00> asciilifeform: anyway, what I wanted to write: "Just to fix the misunderstanding regarding the log output: The Cr50 most likely did nothing to the generated output. There can not be any "Rockchip DDR init info" as the device uses coreboot exclusivly and the mass-production units start with the coreboot console output disabled. To get bootloader output you would need to build and flash a dev-mode coreboot to the device."
<asciilifeform> mmind00: the first 4080 bytes of the rom is ddr init.
<asciilifeform> iirc the vendor docs call it 'bootloader'
<asciilifeform> there is also the rk33 thing ( arm 'trustzone' crapola ) after it
<asciilifeform> and yes i know that the vendor's rom does not produce uart output on apuart. was speaking of stock uboot, which (if it actually ran, which it thus far does not) ~does~.
<asciilifeform> https://github.com/rockchip-linux/rkbin/tree/29mirror/bin/rk33 << the rk manufacturer's init bins
<asciilifeform> (none of them correspond to the one in c101pa factory rom)
<asciilifeform> http://www.loper-os.org/pub/current_c101pa_main.bin << my unit's factory rom, 8MB
<asciilifeform> last night i set out to try & replicate google's build of the boot rom, but so far no luck, the docs are nonexistent and it seems to want a nonstandard toolchain (vs ordinary aarch64 gcc) and various env paths to ???
<asciilifeform> all i found so far was https://www.chromium.org/chromium-os/2014-firmware-summit , which is worse than useless
<asciilifeform> my objective for this box is to lift whatever driver magic required from google's rom, and get ordinary uboot, which loads ordinary (non-signed) kernels from a non-googlistic partition, like exists on every other rockchip board.
vicencb has joined #linux-rockchip
<mmind00> asciilifeform: that's all part of the vendor-uboot solution ... if you look at mainline uboot you will find source-ful DDR init code inside uboot itself ... coreboot also does its own ddr init
<mmind00> asciilifeform: aka both mainline uboot-spl and coreboot are the first stage loaders which the rom of the soc loads
lkcl has joined #linux-rockchip
<mmind00> asciilifeform: as for building a coreboot boot image, you'll need a ChromeOS repo https://chromium.googlesource.com/chromiumos/docs/+/master/developer_guide.md#Get-the-Source first
<mmind00> asciilifeform: ideally using the firmware branch ... which is "firmware-gru-8785.B"
<mmind00> asciilifeform: then the chromeos chroot, which is their standard way of building things https://chromium.googlesource.com/chromiumos/docs/+/master/developer_guide.md#Building-Chromium-OS
<mmind00> asciilifeform: and if I remember correctly, I did a "emerge bootimage" or something like that to build ... which will create mp, dev and netboot images
lkcl has quit [Ping timeout: 252 seconds]
vicencb has quit [Quit: Leaving.]
_whitelogger has joined #linux-rockchip
<asciilifeform> ty mmind00 , i will try this recipe