[U-Boot] How to recognize need for new configuration

[Simon Glass]

Hi David,

On 13 August 2014 09:00, David Nelson <djhenjin1 at gmail.com> wrote:
> good morning/afternoon/evening
>
> I have long been aware of my current project's implicit requirement of
> building a custom bootloader with repeatable and consistent results, and as
> such decided thatI would use U-Boot.
>
> That decision was made months ago however I am still without a bootloader
> for my target. This is for a couple reasons that I Sincerely hope can be
> addressed within the not too distant future.
>
> The first being Apprehension, this is simply due to a lack of knowlege. For
> instance I have absolutely 0% of a clue about how to tell if a device is
> even capable of having the existing boot loader binary replaced permanently
> by U-Boot. For example, my Samsung galaxy tab pro 10.1 picassowifi built on
> the exynos 5420 SOC, board name seems to be UNIVERSAL5420, what I DO know
> about this device however is that the revision is r2p3, Architecture ARM
> Cortex-A15+ARM Cortex-A7, with the Mali T628 GPU, with 1.7GB RAM available
> to the CPU and 11.6GB flash available. And with existing facilities I am
> capable of dumping any/all of the apparent 24 partitions to files on my
> desktop and analyse with a hex editor. I am almost finished programming a
> disassembler for static analysis of executables themselves to further
> understanding of the underlying system. But im still afraid that i will end
> up doing something  inherently stupid and seemingly obvious... and then
> ending up with a nearly Letter size paperweight..
>
> Secondly I favour where possible using a prebuilt version of a tool until i
> understand it fully and have  deeper knowledge of the requirements/features
> associated with tools of that type. at which time I can then develop my own
> or contribute to an open project.
>
> But it seems that no matter how I have approached the problem to date, I
> always end up with an equally useless, albeit slightly larger pool of
> resources to pull from..
>
> TL:DR;
>
> Is anyone able to offer up a shortlist of "If you do this, you will have a
> paperweight" type  guidance?

I'd suggest you are taking a risk by rewriting the firmware
irreversibly in a device. It's nice to be able to boot firmware from a
different source (e.g. SD card) before you commit it to internal
memory.

>
> And, How does a person go about determining within a small margin of error,
> whether any existing configuration/board is appropriate for a device,.

Normally you check the board name against your device very carefully :-)

Regards,
Simon