+- PINE64 (https://forum.pine64.org)
+-- Forum: ROCKPRO64 (https://forum.pine64.org/forumdisplay.php?fid=98)
+--- Forum: General Discussion on ROCKPRO64 (https://forum.pine64.org/forumdisplay.php?fid=99)
+--- Thread: A user's guide (manual) is really needed; the wiki page isn't enough (/showthread.php?tid=6412)
RE: A user's guide (manual) is really needed; the wiki page isn't enough - Luke - 08-20-2018
Posted as discussed: https://forum.pine64.org/showthread.php?tid=6436
RE: A user's guide (manual) is really needed; the wiki page isn't enough - wis - 08-20-2018
(08-19-2018, 12:54 AM)lucho Wrote: [ . . . ] How exactly does it work? Because of what? Can someone explain it in details? (I mean the internal mechanism due to which it works, not its usage, which has already been discussed.)
If you look at the schematics (rev 2, sht. 22B4), you'll see the jumper shorts the eMMC clock to ground. That severely restricts the ability of the eMMC card to respond - no clock, no data out. Whatever the RK3399 gets when it tries to read from the eMMC module, it will not be a good signature. Thus, it will be skipped and the next boot device in sequence (SD card, IIRC) is checked. [ If there is no jumper and the eMMC returns valid data for the signature, eMMC is used to boot.
Once the boot has started on the SD card, you can remove the jumper, enabling the clock to the eMMC connector. Then the eMMC module can respond to further requests.
For my part, I'm curious about some things:
- Given the scheme to look for a couple of signature bytes at the bottom memory locations, why do you need to disable the eMMC clock? As long as those first bytes aren't the signature, the eMMC should be skipped, right? And if nothing is installed, then you're going to get all ones or zeroes, depending on how (or if) the EMMC_D[7:0] lines are pulled.
[ this makes sense, but I wonder if real-world behavior deviates. it does that sometimes. ]
- Does the short on EMMC_CLKO overstress the output driver? I know there's a 22 ohm termination resistor. Is that sufficient current limit when the clock goes high?
- Does the notation "ON/OFF_KEY" on SW4 mean anything (other than perhaps this symbol was copied and only the reference designator updated)?
RE: A user's guide (manual) is really needed; the wiki page isn't enough - dukla2000 - 08-22-2018
OK - a Sit-Rep from my point of view.
lucho - all the changes you make are great - make me wish I had done it and in most cases make me wish I had your skills to do it!
For sure many sections (especially those with a note they need to be expanded) need work - I am happy to try pick them off if nobody beats me to it.
I do try to fiddle if I see queries about the ROCKPro64 on the forum or IRC to try ensure the wiki is useful as (part of) an answer.
BUT - going back to your OP (lucho), do you think it is more fit for purpose? I keep reflecting on other wiki I trip across (e.g. NanoPC-T4) and figure our aim should be to cover ROCKPro64 specific stuff. And avoid generic things (like how to partition an SSD on NanoPC) that are documented all over the www. I think we are a long way towards that goal?
RE: A user's guide (manual) is really needed; the wiki page isn't enough - lucho - 08-23-2018
Thanks, I hope it becomes better and better each day. When I have time, I'll keep contributing, but don't wait for me; if you can, go on with the "todo" stuff.
I think that we do keep in mind that all general information should go to the general pages, and only the RockPro64-specific one should be present on its wiki.
Unlike ours, the NanoPC-T4 wiki is an "all-in-one" type, where everything you need is there, much like in a manual/guide. But for a wiki, our concept is better.
Re: my original idea, writing a manual by 2 or more people requires better planning, organisation, and coordination. But a manual is more suitable for printing.
A user manual is really needed when a product is in mass-production, not in relatively small series like the RockPro64. So, at least for now, the wiki is enough.
I'm also grateful to all who replied my question regarding the "jumper removal" trick. To summarise, U-boot works with jumper on, the kernel with jumper off.
RE: A user's guide (manual) is really needed; the wiki page isn't enough - CrimsonKnight13 - 08-24-2018
For the "move rootfs to nvme", I would like to add in advance that you can (almost) fully utilize the nvme SSD (minus the ESP partition - /boot/efi). From the guide I followed, I was able to tinker a bit to make it fully bootable/rebootable. I still need to run a new kernel installation for this to complete my testing but I'm waiting for the next 4.4 ayufan release.
df -h
Code:
Filesystem Size Used Avail Use% Mounted on
udev 1.9G 0 1.9G 0% /dev
tmpfs 388M 568K 388M 1% /run
/dev/nvme0n1p2 117G 22G 90G 20% /
tmpfs 1.9G 20K 1.9G 1% /dev/shm
tmpfs 5.0M 4.0K 5.0M 1% /run/lock
tmpfs 1.9G 0 1.9G 0% /sys/fs/cgroup
/dev/nvme0n1p1 189M 38M 138M 22% /boot
/dev/mmcblk0p6 112M 10K 112M 1% /boot/efi
tmpfs 388M 0 388M 0% /run/user/1001/etc/fstab
Code:
LABEL=boot /boot/efi vfat defaults,sync 0 0
LABEL=boot-nvme /boot ext4 defaults,sync 0 0blkid
Code:
/dev/mmcblk0p6: SEC_TYPE="msdos" LABEL="boot" UUID="<UUID>" TYPE="vfat" PARTLABEL="boot" PARTUUID="<PARTUUID>"
/dev/mmcblk0p7: LABEL="oldroot" UUID="<UUID>" TYPE="ext4" PARTLABEL="oldroot" PARTUUID="<PARTUUID>"
/dev/nvme0n1p1: LABEL="boot-nvme" UUID="<UUID>" TYPE="ext4" PARTLABEL="boot-nvme" PARTUUID="<PARTUUID>"
/dev/nvme0n1p2: LABEL="linux-root" UUID="<UUID>" TYPE="ext4" PARTLABEL="root" PARTUUID="<PARTUUID>"