I tried to confirm the same thing
Used Imag was as follows.
*) u-boot-flash-spi-rock64.img.xz ( https://github.com/ayufan-rock64/linux-b...k64.img.xz)
*) xenial-minimal-rock64-0.6.33-211-arm64.img.xz ( https://github.com/ayufan-rock64/linux-b...m64.img.xz)
step 1
Expand u-boot-flash-spi-rock64.img.xz and write it to MicroSD
step 2
Set MicroSD in ROCK 64 and start up
DDR version 1.08 20170628
....
MMC read: dev # 1, block # 64, count 8000 ... 8000 blocks read: OK
SF: 4096000 bytes @ 0x8000 Erased: OK
device 0 offset 0x8000, size 0x3e 8000
SF: 4096000 bytes @ 0x8000 Written: OK
step 3
Expand xenial-minimal-rock64-0.6.33-211-arm64.img.xz and write it to MicroSD
step 4
Set MicroSD in ROCK 64 and start up
DDR version 1.08 20170628
...
333 MHz
U-Boot SPL 2017.09-ga 0 a 2 b 48 (Apr 27 2018 - 18: 00: 06)
setup_ddr_param 1
booted from SPI flash
Trying to boot from SPI
....
Welcome to Ubuntu 16.04.4 LTS!
It started without crashing
step 5
About 10 times, I tried turning the power on / off or reboot but it never crashed.
----
However, depending on MicroSD, errors like the one below occurred frequently,
but it did not lead to a crash. (In such a situation, it is not surprising even if it crashes ...)
[110.795736] mmcblk1: response CRC error sending SET_BLOCK_COUNT command, card status 0x900
> You can also try to install an image 0.5.15 and update it in 0.6.3x.
> it work but if you reboot your rock 64, it crashes at restart.
Regarding this, I remember what was mentioned in release-note/Commits ?
So I will not confirm it daringly.
-----
There are doubtful parts that seem to be individual differences,
but it does not seem to crash in all environments.
(05-02-2018, 10:33 PM)t4_4t Wrote: There are doubtful parts that seem to be individual differences,
but it does not seem to crash in all environments.
Can you try the same image I did - the xenial-containers one - so we can get a better idea of if it's hardware, image, or user specific!  I'll try with a Samsung EVO card instead of a Samsung EVO + for consistency as I haven't used the + cards with the rock64 before. I'm not surprised that there could be inconsistency as these are the bleeding edge untested images, not stable or rigorously tested ones. Hence why I never overwrite my working release and have several test cards for giving feedback
https://pastebin.com/iEwc0xUn
Well, since ↑ has detailed content
First I made a mistake in "xenial-containers-rock64-0.6.34-213-arm64.img.xz"
However, I noticed halfway and tried again with "xenial-minimal-rock64-0.6.33-211-arm64.img.xz".
There is a circumstance to say.
There are things I'd like to check for accuracy
What is "restart" ?
# reboot
Is it OK?
What is "Power ON / OFF" ?
# poweroff <-> rock64 power-button
or
// "rock64:dc-jack" <-> "pull-in / pull-out"
Which do you point to ?
If you can reply to above, I can check again with "xenial-containers-rock64-0.6.34-213-arm64.img.xz".
----
I will inquire last.
I am curious about the ↓ part of your log.
[ 2.679476] mmc1: Problem switching card into high-speed mode!
[ 2.684088] Bridge firewalling registered
[ 2.684103] mmc_host mmc1: Bus speed (slot 0) = 25000000Hz (slot req 25000000Hz, actual 25000000HZ div = 0)
[ 2.684188] mmc1: new SDHC card at address 0001
[ 2.684894] mmcblk1: mmc1:0001 SD16G 15.0 GiB
For reference, the following is the case for me log, the large number of errors came out is 14.4 GiB
[ 2.193380] mmc_host mmc1: Bus speed (slot 0) = 50000000Hz (slot req 50000000Hz, actual 50000000HZ div = 0)
[ 2.193449] mmc1: new high speed SDHC card at address 0007
[ 2.194212] mmcblk1: mmc1:0007 SD08G 7.42 GiB
[ 2.200307] mmcblk1: p1 p2 p3 p4 p5 p6 p7
[ 2.826887] mmc_host mmc1: Bus speed (slot 0) = 50000000Hz (slot req 50000000Hz, actual 50000000HZ div = 0)
[ 2.832028] mmc1: new high speed SDHC card at address 1234
[ 2.837386] mmcblk1: mmc1:1234 SA16G 14.4 GiB
[ 2.849799] mmcblk1: p1 p2 p3 p4 p5 p6 p7
Both are cheap cards, but there is no problem with the media itself
To that proof,
I tried to boot the same media via "USB-CARD-READER", but in this case no errors will be issued at all.
(05-03-2018, 05:15 AM)t4_4t Wrote: There are things I'd like to check for accuracy
What is "restart" ?
# reboot
Is it OK?
## Reset ## was a press of the reset button, since the system had locked up and wasn't going anywhere...
(05-03-2018, 05:15 AM)t4_4t Wrote: What is "Power ON / OFF" ?
# poweroff <-> rock64 power-button
or
// "rock64:dc-jack" <-> "pull-in / pull-out"
Which do you point to ?
== Output (power connect) == was a ... er... connecting the power via the jack.
(05-03-2018, 05:15 AM)t4_4t Wrote: If you can reply to above, I can check again with "xenial-containers-rock64-0.6.34-213-arm64.img.xz".
That would be great. The errors you point to in the log later relating to high-speed mode is the reason I need to try with the Samsung EVO (not plus) cards that I usually use. I know there are no issues with these other Samsung EVO + cards as they have already passed f3 integrity tests multiple times, and have booted other SBCs and also the rock64s/pine64s a couple of times, but I will use the regular EVOs just to make sure that there isn't something weird going on...
05-04-2018, 04:46 AM
(This post was last modified: 05-04-2018, 05:29 AM by pfeerick.)
I've since tried a couple more images, and so far it seems to be the consequence of a change post 0.6.27.
xenial-minimal-rock64-0.6.34-213-arm64.img.xz failed on the 4GB rock64 - https://pastebin.com/GikCB3kF
The same image you tried, the xenial-minimal-rock64-0.6.33-211-arm64.img.xz, failed on both the 4GB and the 1GB rock64s. https://pastebin.com/J7mE13fe
I then tried xenial-containers-rock64-0.6.27-196-arm64.img.xz and it was fine ( https://pastebin.com/x9nX8fig), so I'll keep working forwards till I find which version breaks things first, and then try it against both the v2.0 4GB rock64 board and the v1.1 1GB rock64 boards. Changing the memory cards didn't make any difference, so the Samsung Evo+ isn't the culprit. The issue does seem power/thermal related, as when it locks if I don't power the board down it gets pretty toasty... I'm expecting to see it all go wrong at 0.6.29 due to those cpuburn tweaks...
Edit - nope, it's looking like it's solely the memory speed tweaks in 0.6.28... xenial-minimal-rock64-0.6.28-197-arm64.img.xz just borked - https://pastebin.com/1YLrZtmS and https://pastebin.com/xpte3v5B
Good morning, this is morning.
I tried over 20 times on the conditions you presented.
However, we were unable to obtain a different result from the previous report.
I tried different things by changing the point of view.
I have two "ROCK64" units.
One is the one I used for the last time and the report this time, it is "ROCK64 (RAM-4G)"
I tried and checked with the other "ROCK64 (RAM-2G)"
With "ROCK64 (RAM-2G)", there was no problem even for cards with frequent errors.
I will write out the details of 2 cards I tried
Card-A) Silicon Power microSDHC 8GB Class10 with Adapter
Card-B) TOSHIBA EXCERIA UHS-I microSDHC 16GB class10
In order of card-grade, (including your card)
hi-grade <-> lo-grade
Your-EVO >= Card-B) > Card-A) : Card Grade
Crash Many-Err Good : Result of "ROCK64"
Will be
From this, I guess that "cards with higher grade are more prone to problems."
However, it is not a problem of the card itself,
a problem with the "ROCK64" side including the driver.
The point that pointed out your log in the previous report means the above.
"Your-EVO" is "fall-back" to 25MHz after failure occurred at initialization.
This is "Card-A)" below, it is far below the performance of the original card.
And that is probably a problem on the "ROCK64" side, not doubting your card.
(05-04-2018, 07:24 PM)t4_4t Wrote: From this, I guess that "cards with higher grade are more prone to problems."
However, it is not a problem of the card itself,
a problem with the "ROCK64" side including the driver.
The point that pointed out your log in the previous report means the above.
"Your-EVO" is "fall-back" to 25MHz after failure occurred at initialization.
This is "Card-A)" below, it is far below the performance of the original card.
And that is probably a problem on the "ROCK64" side, not doubting your card.
I think it's a bit chicken and the egg... I believe the issue is actually to do with the memory, as 0.6.28, which is the first of the images to fail to boot, and also sends the CPU into a bit of a thermal runaway, was the first build to introduce the change in DDR speed. The MMC / microSD failure may just be a red herring that resulted from issues further up the chain. rock64 boards shipped with two different speed grades of DDR, depending on cost. I have the pre-production v1.1, and also a first batch v2.0 production board, so they could have different speed RAM to your boards. The reports on the github issue tracker about kernel updates resulting in broken images may or may not also related.
Thanks for trying though. Hopefully we'll hear from ayufan or xalius, who should be able to shed some light on what the issue is.
I settled my mind and reviewed the log you up again.
When looking carefully at the log, there are two sets of logs, each of which has crashed immediately after "dmc"
And it seems that there is no direct relationship with "SD-Card type ~" we have been discussing so far.
If showed me only this log, at without "SD-Card debate" so far.
Just like you, I will also doubt the memory system first.
So, what happens if you turn off "dmc" ?
Still Crashing ?
05-05-2018, 08:10 PM
(This post was last modified: 05-05-2018, 08:21 PM by pfeerick.)
(05-05-2018, 08:44 AM)t4_4t Wrote: So, what happens if you turn off "dmc" ?
Still Crashing ?
Er, rk3288-dmc is the "Rockchip Dynamic Memory Controller Driver", so I think I'll leave that well alone. Especially since this was the main change in 0.6.28 and affects the entire boot process from uboot onwards. I would have to remove just that change, and recompile everything.
I'll just have to stick with 0.6.27 until we can find out what is going wrong with certain boards.
Ok
I intended to discuss the same thing
In my case, it is related to "SD-Card"
In the case of you, I understood that it was a problem related to "Memory"
Your problem may be difficult to improve if a lot of similar voices do not come out
It was a fun conversation, thank you pfeerick.
----
Finally, I write one
There is no need to rebuild everything in order to confirm this kind of things.
Just replace "dtb", it will not take as long as if knows where to change.
Your "ROCK64" individual needs to modify the frequency and voltage around "dmc-opp-table/opp-xxxxxx/"
Below, I will write concrete examples
# cp -a /boot/efi/dtb /boot/efi/dtb.orig
# dtc -O dts -I dtb -o ./tmp.dts /boot/efi/dtb
# vi ./tmp.dts ...
# dtc -O dtb -I dts -o ./tmp.dtb ./tmp.dts
# cp ./tmp.dtb /boot/efi/dtb
# reboot
---- ./tmp.dts ----
dmc {
compatible = "rockchip,rk3328-dmc";
devfreq-events = <0x84>;
....
// status = "okay";
status = "disabled";
....
};
dmc-opp-table {
compatible = "operating-points-v2";
rockchip,leakage-voltage-sel = <0x1 0x8 0x0 0x9 0xfe 0x1>;
nvmem-cells = <0x57>;
nvmem-cell-names = "ddr_leakage";
linux,phandle = <0x85>;
phandle = <0x85>;
opp-400000000 {
opp-hz = <0x0 0x17d78400>;
opp-microvolt = <0xe1d48>;
opp-microvolt-L0 = <0xe1d48>;
opp-microvolt-L1 = <0xdbba0>;
status = "disabled";
};
....
opp-1066000000 {
opp-hz = <0x0 0x3f89de80>;
opp-microvolt = <0x11edd8>;
opp-microvolt-L0 = <0x11edd8>;
opp-microvolt-L1 = <0x118c30>;
};
};
|
