Re: cannot boot from microSD card on aarch64 machine

[Ricardo Wurmus]

Vagrant Cascadian <vagrant@debian.org> writes:

> [[PGP Signed Part:Undecided]]
> On 2022-03-02, Ricardo Wurmus wrote:
>> I got myself a rockpro64 board.
> ...
>> So I then decided to build my own system and install a new u-boot onto
>> the microSD card.  Here’s the system I built:
> ...
>>   (bootloader (bootloader-configuration
>>                (bootloader u-boot-rockpro64-rk3399-bootloader)
>>                ;; SD card/eMMC (SD priority) storage
>>                (target "/dev/mmcblk1")))
>
> You need to leave a pretty generous gap at the partition table of your
> microSD, either a GPT partition table with various partitions for the
> various u-boot bits:
>
>   http://opensource.rock-chips.com/wiki_Partitions
>
> or an MBR partition table with the first partition starting at sector
> 32768, and the previous sectors empty.
>
> Otherwise, the u-boot installation may clobber parts of your partition
> table or vice-versa.

Do I need to prepare the microSD card at all?  There’s no documentation
in the manual, so I have no idea what to do with it prior to “guix
system init”.  Looking at the code I assumed that the
disk-image-installer procedures take care of placing whatever blobs are
needed at the expected locations.

> Also, if you have a different u-boot installed to SPI or eMMC, those
> will take priority over microSD on most rockchip platforms.

There is no other u-boot installed.  The machine does not show any
activity when powered on without microSD card.

>>   (kernel linux-libre)
>>   (kernel-arguments
>>    (list "console=ttyS2")) ; UART2 connected on the Pi2 bus
>
> I assume you're using a serial console. The rockchip platforms usually
> default 1500000 for baud ... usually I use:
>
>   screen /dev/ttyUSB0 1500000
>
> Oh, now that I think about it, you might also want to set the speed for
> your console in kernel-arguments:
>
>    (kernel-arguments
>     (list "console=ttyS2,1500000"))

I’m not yet using a serial console, but I’ll come back to this later if
necessary.

>> Does it perhaps install the u-boot files at the wrong offsets?  How
>> would I begin to debug this?
>
> It is also entirely possible something is wrong with rockpro64 u-boot
> offsets or u-boot itself ... been a while since I've tested.

Hmm, okay.

Thanks for the hints!

-- 
Ricardo