On 12/10/16, Diego Roversi <[email protected]> wrote: > On Sat, 10 Dec 2016 04:42:19 +0000 > Luke Kenneth Casson Leighton <[email protected]> wrote: > > >> yep - this is the recommended method [for now] because the default >> hardware boot order is something like eMMC microsd USB. the technical >> reference manual is available, some references here >> http://rhombus-tech.net/rock_chips/rk3288/ > > Thanks for the links.
no problem >> recovery OS, yes? you'd expect the u-boot SPL loader to help you out, >> there, yes? by always looking on the external microsd first, and THEN >> looking on the eMMC, yes? > > Uhm, loading spl and u-boot from the same device it may be a sensible > advice, because not always spl and uboot code from different version of > u-boot are compatible. wtf? a sub-16k loader basically a few hundred lines of code in total and they couldn't be bothered to make sure it has interoperable chainloading?? there'd better be a *really* good reason for that. > And with rkflashkit you could always reflash spl and > u-boot on emmc, at least I hope so, because I've not really tried yet. took a look at it, went "GUI? f*** that". saw that various people have been using it as a command-line tool, investigated further and still didn't like it. i'm used to the USB-FEL of the A20, where i can upload the SPL, execute it, upload u-boot, kernel, initramfs and dtb direct into memory, then execute u-boot with some default parameters... takes a while but it works, and *all automated* entirely over the USB interface... with *no* proprietary software or libraries. i can't exactly recall if this is correct but i got the impression that rkflashkit required proprietary drivers, or required a proprietary program to be on the eMMC in order for it to "talk" to rkflashkit... there was something weird and i just couldn't be bothered to investigate. in the u-boot docs on the rk3288 which were written by a chromium developer from google he *nearly* got USB-MASKROM bootloading up and running. i suspect he ran out of time, but actually managed to do the job: i suspect that it would be possible to compile up what he did, enable the "load from external sd" as a compile-time option and i would expect it to actually work. has to be a very *very* basic mmc loader though. > And > after loading spl+u-boot, from u-boot you can choose to boot from sd or > emmc. yeah... as long as u-boot on the eMMC is never corrupted / default parameters partition never corrupted / etc. / etc. / etc. > Documentation on rk3288 devices are quite sparse, at least compared to > allwinner devices. So I think, I'll write a bit on debian wiki after some > experiment. what i've found is that the info *is* actually out there, but the signal-to-noise ratio where a ton of people have written "how i are installing mi favurit OS on the Acur C201" isn't really helping. also to watch out for is the fact that because google said that UEFI support is important, a lot of the documentation is "HOWTO boot from UEFI". you do NOT need to format the eMMC or sd card as UEFI. that is a SOFTWARE compile option that google put BY DEFAULT into their u-boot and linux kernel releases on the chromium web site. two people (including myself) have managed to use mmc boot directly from legacy-formatted partitions: the other guy (nvm i think on #linux-rockchip) used fat32, i used ext2 so our arrangements are slightly different, but are basically adaptations of the exact same mmc_boot commands commonly used for the A20 and placed into uEnv.txt. i do have to document what i did to get up-and-running, too >> in this way you will be able to do test out future upgrades to u-boot >> by putting them onto the external microsd card, without having to do a >> one-off potentially-destructive "i hope like hell this is going to >> work first time" overwrite of u-boot, because the eMMC SPL-u-boot >> loader will be configured to help you. you'll also be able to recover >> the system should the eMMC u-boot ever become corrupted. > > That's quite a problem, but a this point you should reflash the uboot with a > usb cable. Because even spl can became corrupted, and you need to cover also > this case (imho). the SPL is far, far smaller (and is on a separate - single - NAND block) so is far less likely to get corrupted. reflashing with a USB cable at this point requires that you short out *two* GPIO pins to GND (one is EMMC_D1 and the other EMMC_CLK i think). that's the only way to recover the system if the eMMC becomes corrupted and u-boot is *NOT* configured to look on external sd card. it's not enough to *hope* that the system will drop into MASKROM (USB loader) mode. >> >> the firefly's a really nice board, btw. did you get one with 4GB RAM? > > 2GB ram model. I found it on sale on a online shop. I agree that is a nice > board. The cpu is quite fast. The only thing I miss is a native sata port > (or usb 3.0). yehh, these are sub-$10 SoCs, operating in an extremely cut-throat market: it's hard to justify the inclusion of a hard macro that costs $100k to license and way more than that to test... when most of your customers are never going to add a SATA drive in their target products. the only reason SATA was included with the A20 is because it was multi-product-targetted, including for the IPTV / Set-Top Box market. l.
