<amstan>
Callmea: depends on how much work you're willing to put into it
<Callmea>
amstan, I thank you. I've already a raspberry and enjoy it (built a mini-micro computer with it). but my goal is to build a cheap notepad with Linux arm on it. cross compiling the kernel is not an issue for me, if all the tools are available. Is there things to thing before buying on of theses sticks for this plan?
<Callmea>
sorry for my limited english
nighty^ has quit [Quit: Disappears in a puff of smoke]
naobsd has joined #linux-rockchip
Tony100 has quit [Read error: Connection reset by peer]
Callmea has quit [Remote host closed the connection]
naobsd has quit [Quit: naobsd]
hahah has joined #linux-rockchip
hahah is now known as tony1000
<tony1000>
hi.
<tony1000>
is there RkFlashKit for rk3288 ?
<tony1000>
I have tried RkFlashKit for rk3188, now I want it for rk3288.
<c0d3z3r0>
hi, I didn't get an answer yesterday so here's my question again. Maybe someone has an idea? ˜/c0d3z3r0 17:27> hey guys, I'm trying to get a working kernel for my radxa rock. my current config (https://paste.mniewoehner.de/T0Y4w/) is based on the raspberry pi kernel config. the rock boots and everything seems to work but there are two problems. when I test my memory using "memtester 1900M" I get kernel BUGs https://paste.mniew
<tony1000>
ah.
<tony1000>
at first, the url you posted can be open. ;(
JohnDoe_71Rus has joined #linux-rockchip
<c0d3z3r0>
tony1000: are you talking to me?
JohnDoe_71Rus has quit [Client Quit]
JohnDoe_71Rus has joined #linux-rockchip
<karlp>
c0d3z3r0: your line was trucated.
JohnDoe_71Rus has quit [Client Quit]
<c0d3z3r0>
oh.. bad.. here again:
<c0d3z3r0>
my current config (https://paste.mniewoehner.de/T0Y4w/) is based on the raspberry pi kernel config. the rock boots and everything seems to work but there are two problems.
<c0d3z3r0>
when I test my memory using "memtester 1900M" I get kernel BUGs https://paste.mniewoehner.de/5FoGVZ/ . with just 100M there are no errors.
<c0d3z3r0>
The kernel panic only appears on reboots - after resetting the rock it boots. any ideas?
<tony1000>
c0d3z3r0, do you use rk3188?
<tony1000>
or 3288 ?
<c0d3z3r0>
it's rk3188
markm_ has quit [Ping timeout: 256 seconds]
<tony1000>
Have tried the ram test from RK ?
<c0d3z3r0>
I only tried memtest in linux mainline
<tony1000>
I've tried the rk memtest with my board, it works fine.
<c0d3z3r0>
linux mainline memtest works fine for me, too
<c0d3z3r0>
memtester doesn't work
<c0d3z3r0>
on raspberry pi it works but not on my radxa rock
<tony1000>
As I can see, You used the mainline latest version kernel. Do you have tried 3.0.xx ?
<c0d3z3r0>
some months ago and it worked fine but I don't want that old rockchip kernel :)
<tony1000>
ah, I want to try new version kernel too, but there are some trouble, so I can't do that.
<tony1000>
c0d3z3r0, without this problem, your kernel can works fine on wherever ? What I mean is such as LCD/HDMI/audio.
<tony1000>
even OTG ??
<c0d3z3r0>
HDMI won't work afaik
<c0d3z3r0>
I didn't test audio or OTG because I don't need it
<tony1000>
what kind of product do you use for ?
<tony1000>
;)
markm_ has joined #linux-rockchip
<c0d3z3r0>
the rock should replace my raspi B as a homeserver
<tony1000>
cool. You just a hacker or you want to create a product for sell ?
<c0d3z3r0>
just for personal use ;)
GriefNorth has quit [Quit: Konversation terminated!]
<tony1000>
ah, for mainline kernel, there are some hacker such as karlp, amstan, nanbsd.
<c0d3z3r0>
yeah and mmind00
<tony1000>
;P
<mmind00>
:-)
<c0d3z3r0>
ah :) mmind00, do you have an idea to my problem above? :)
<tony1000>
;P mmind00 was here.
<mmind00>
c0d3z3r0: not really ... we don't touch any settings of the memory controller currently at all on the (mainline-)kernel side, so I would've hoped that the bootloader settings would be ok
<c0d3z3r0>
I didn't get what you mean… you think the problem is the bootloader?
<mmind00>
it may be ... i.e. when the system starts, only the on-chip sram is active; the bootloader initializes the dmc with the appropriate ram settings
<c0d3z3r0>
hm ok.. is there anything I can do here?
<mmind00>
the chromeos-people already do frequency-scaling for the rk3288, but I haven't looked at this yet [it loooks like voodoo], so in the end we're always using the dmc settings set up by the loader
<mmind00>
c0d3z3r0: I guess look though the mailing lists, if any patches for the memtester are pending as fixes [in the case, where the memtest itself would be at fault]
<c0d3z3r0>
I don't think it's the memtester itself on the raspberry pi it works fine with the same binary
<c0d3z3r0>
what about the reboot problem? any ideas for that?
<mmind00>
c0d3z3r0: does the reboot issue happen always [on every reboot]?
<c0d3z3r0>
yes
markm_ has quit [Ping timeout: 272 seconds]
<c0d3z3r0>
only hard resetting the device helps to boot again
<mmind00>
c0d3z3r0: i.e. when we're doing cpu frequency scaling, we're setting some dividers accordingly, but when rebooting the maskrom maybe only reset the plls not the dividers
<mmind00>
c0d3z3r0: can you do a reboot-test with cpufreq disabled?
<c0d3z3r0>
is there a cmdline option for disabling it?
<mmind00>
I don't think so ... I guess just disable it in your kernel-config
<c0d3z3r0>
compiling atm
mrueg has quit [Ping timeout: 264 seconds]
naobsd has joined #linux-rockchip
mrueg has joined #linux-rockchip
<c0d3z3r0>
mmind00: in the mean time I was able to trigger the same kernel errors that appeared with memtester using tmpfs and dd https://paste.mniewoehner.de/ysxC/
<c0d3z3r0>
second try succeeded without kernel panic
<c0d3z3r0>
also the reboot is working now
<mmind00>
ok, so the maskrom or rkloader is probably meddling with some clocks, without adjusting others
<c0d3z3r0>
can this be fixed on the kernel side?
irsol has joined #linux-rockchip
<mmind00>
alternative issue ... when restarting with a to low voltage, the loader maybe does not readjust the core voltage
<mmind00>
i.e. at 312MHz core clock, we're probably at 0,875V ... when the loader only ramps up the core clock without adjusting the core voltage this also calls for trouble
mrueg has quit [Remote host closed the connection]
nighty^ has joined #linux-rockchip
GriefNorth has joined #linux-rockchip
tony1000 has quit [Read error: Connection reset by peer]
markm__ has joined #linux-rockchip
<naobsd>
(I'm just trying to change pll config in u-boot for another issue...)
markm_ has quit [Ping timeout: 244 seconds]
<naobsd>
btw i2c support is needed in loader for changing voltage
<naobsd>
mmind00: should we reset pmu/pmic when reboot?
eebrah has quit [Quit: leaving]
<naobsd>
well
<mmind00>
naobsd: might be nice to do ... i.e. if we adapt the core frequency we should also make sure the pmic provides a suitable voltage
<naobsd>
I remembered about "system-power-controller" in dts
eebrah has joined #linux-rockchip
<naobsd>
ah, it's for shutdown...
markm_ has joined #linux-rockchip
markm__ has quit [Ping timeout: 272 seconds]
<naobsd>
oops
JohnDoe_71Rus has joined #linux-rockchip
<naobsd>
it seems act8865 driver doesn't handle "system-power-controller"
<naobsd>
why I added it in firefly dts...
mrueg has joined #linux-rockchip
<naobsd>
I guess rperier discussed something like "system-power-controller" for reset...?
<rperier>
you probably added to your dts because when I sent the patches serie, it was planned to adapt act8865 to the property
<rperier>
that's a long long discussion
<rperier>
:D
<naobsd>
oh ;)
<rperier>
only the property itself was merged (with the documentation)
<rperier>
however, I can write a patch for it and retest again, we need to care about backward compat issues in the dts. So the driver must be compatible with both properties, that's all
<rperier>
I don't compute, it's not vendor-prefixed as it is a standard dts property, so you only need to use "of_device_is_system_power_controller" in your code, and put the property "system-power-controller;" in your dts
<rperier>
;)
<naobsd>
so firefly dts is fine ;)
<rperier>
yes, just check that "poweroff" works fine, but it should
<naobsd>
but it's for shutdown, not for reset, right?
<naobsd>
then
<rperier>
(not sure that it does something with busybox...)
<mmind00>
naobsd: correct ... it indicates that the pmic controls the system-power, so must handle the machine shutdown
<naobsd>
I think you discussed similar thing for reset,?
<mmind00>
naobsd: slightly similar ... see drivers/clk/rockchip/clk.c, which already handles the system reset
<naobsd>
register_restart_handler() hmm
mrueg has quit [Ping timeout: 255 seconds]
<naobsd>
mmind00: I think writel(0xfdb9, reg_base + reg_restart) resets only SoC, what we need is "reset entire board"
<mmind00>
naobsd: generally not
<mmind00>
the issue c0d3z3r0 seems to have is, that on shutdown/reset we leaven the cpuclk as well as the cpu-voltage in a state (like 325MHz, 825mV)
<mmind00>
the loader then (in current theory) ramps up the cpuclk but not the cpu-voltage
<naobsd>
"entire board" may be too much, but at least pmu should be reset
<mmind00>
so in this scenario it is the loader's issue to make sure voltage and frequency match
mrueg has joined #linux-rockchip
<naobsd>
I think resetting pmu makes voltage reliable state
<naobsd>
(if such a "reset pin" is available for pmu)
<naobsd>
or assert watchdog?
<mmind00>
there is no reset pin ... but the act8846 seems to have a reset-bit
<naobsd>
it may be board specific even if it's available...
<mmind00>
question would be if this functions touches the voltage settings
<naobsd>
workaround is change voltage(cpufreq) higher just before rebooting ;)
<naobsd>
mmind00: power-cycle sounds like it resets everything
<naobsd>
^act8864
<mmind00>
so someone with spare-time can give this a try :-) ... from the manuals this really seems to be a property of the act8846 only (not on act8865 or act8600 from the same driver)
<rperier>
yes but if I remember correctly there is a "driver variant" for act8846 in regulator/act8865-regulator.c , no ?
mrueg has quit [Ping timeout: 246 seconds]
<naobsd>
if power-cycle can be done by pmu, writel(0xfdb9) shouldn't be done?
<naobsd>
maybe "try to reset by pmu, but if it fails, do SoC reset"
<rperier>
or "try to reset by pmu with an higher prio than the SoC handler" ?
<rperier>
(there are priority in restart handlers)
<rperier>
priorities*
<naobsd>
oh, I have to read restart handler at first
<naobsd>
hm, rockchip_restart_handler.priority is 128
mrueg has joined #linux-rockchip
markm_ has quit [Ping timeout: 246 seconds]
<rperier>
the problem being that rockchip/clk.c is SoC specific and share between all rk SoCs, reset power cycle is PMU specific, so the solution would be to add a restart_handler in act8846 and don't touch rockchip/clk.c, otherwise you will introduce regressions
<rperier>
imho
<naobsd>
if (of_device_is_system_power_controller) { register_restart_handler(); } ?
mrueg has quit [Remote host closed the connection]
markm_ has joined #linux-rockchip
<mmind00>
naobsd: nope ... the act8846 driver should just register the restart handler (it doesn't have anything to do with system-power-controller)
<mmind00>
at least it would look like it
<rperier>
yeah, this property is not really for this purpose
<naobsd>
I can understand it but I'm feeling something strange a little... any device which has reset bit should register restart handler? (no)
<mmind00>
hmm, but in the act8846, making this dependent on system-power-controller might actually make sense ... the act8846 could also just be used as some minor secondary pmic which cannot control the system power
<naobsd>
it may be special case... it needs reset but (probably) no one can reset
<naobsd>
if it's non-system-power-controller, master pmu (or any other processor/controller) will reset it...
<naobsd>
(if necessary)
markm_ has quit [Ping timeout: 240 seconds]
<naobsd>
hm
<naobsd>
currently only radxarock, firefly, and rk3288-evb-act8846 uses "active-semi,act8846"...
<naobsd>
all of act8846 on them should be system-power-controller ;)
<naobsd>
so it may be ok to register restart handler unconditionally ;)
markm_ has joined #linux-rockchip
mrueg has joined #linux-rockchip
<naobsd>
ah, I should fix u-boot first...
<naobsd>
today...
<naobsd>
zzz
<naobsd>
sleepy :(
<rperier>
suppose that this PMU is used by another board one day... it should be configurable...