Re: d-i on Firefly-rk3288
On 12/10/16, Diego Roversi <diegor@tiscali.it> wrote:
> On Sat, 10 Dec 2016 04:42:19 +0000
> Luke Kenneth Casson Leighton <lkcl@lkcl.net> 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.
Reply to: