Re: d-i on Firefly-rk3288
On Sat, 10 Dec 2016 21:02:18 +0000
Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote:
>
> 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.
>
Small chance, but still there are. For example how and when the hardware is initialized.
>
> > 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.
Yes, usb-fel is more convient. Expecially when you can load your code directly in ram and run it.
> 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.
My understanding, based on documentation readed online, is that rkflashkit it just talk to mask-rom code (that is just in the cpu) using usb. rkflashkit can only used to read and write the flash memory, and reboot the board. It just what you need to debrick the board.
>
> 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.
But still, you don't want to be brick your board, if by chance write the wrong code in spl block :). So you need to considerate this case.
>
> 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.
>
--
Diego Roversi <diegor@tiscali.it>
Reply to: