From: Przemyslaw Marczak <p.marczak@samsung.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] uboot/odroid test report
Date: Fri, 18 Jul 2014 16:48:02 +0200 [thread overview]
Message-ID: <53C933A2.1070004@samsung.com> (raw)
In-Reply-To: <CAD8Lp46XK35JXFksGb2MAUNeR8z6LjDcJqTWun4SU=-u4txAeQ@mail.gmail.com>
Hello Daniel,
On 07/17/2014 05:35 PM, Daniel Drake wrote:
> On Thu, Jul 17, 2014 at 3:59 PM, Przemyslaw Marczak
> <p.marczak@samsung.com> wrote:
>> So BL1, BL2 are running in iRAM(required small size), and u-boot is running
>> from a RAM.
>>
>> The main reason for using existing BL1 and BL2 binaries is
>> that bl1 and bl2 are just working proper.
>
> Fair enough, I was just a bit worried/curious that bl2 is only working
> "by accident", and we have some strange mashup of 2 uboot versions
> involved in the boot process.
>
>> I will check it tomorrow but it has works on Ubuntu.
>> The bootz command takes only 2 arguments here -> ${image_addr}
>> ${ramdisk_addr} which are the numbers set by:
>> "run check_dtb" and "run check_ramdisk"
>
> Maybe I made a mistake in my testing then, either way I've moved onto
> a custom boot script now.
>
> But just to clarify the bootz usage..
>
> image_addr is defined as:
> setenv image_addr ${kerneladdr} - ${fdtaddr};
>
> so with
> bootz ${image_addr} ${ramdisk_addr};
>
> you are actually passing
> bootz ${kerneladdr} - ${fdtaddr} ${ramdisk_addr};
>
> Maybe it works for you, although the documentation suggests its usage
> is not quite like that:
> static char bootz_help_text[] =
> "[addr [initrd[:size]] [fdt]]\n"
> " - boot Linux zImage stored in memory\n"
> "\tThe argument 'initrd' is optional and specifies the address\n"
> "\tof the initrd in memory. The optional argument ':size' allows\n"
> "\tspecifying the size of RAW initrd.\n"
> #if defined(CONFIG_OF_LIBFDT)
> "\tWhen booting a Linux kernel which requires a flat device-tree\n"
> "\ta third argument is required which is the address of the\n"
> "\tdevice-tree blob. To boot that kernel without an initrd image,\n"
> "\tuse a '-' for the second argument. If you do not pass a third\n"
> "\ta bd_info struct will be passed instead\n"
> #endif
> "";
> #endif
>
> Daniel
>
You were right. I made a mistake, but even that - the ramdisk for ubuntu
was loaded - because of kernel without fdt.
Thank you for testing, I will fix this and send the patches again.
Regards,
--
Przemyslaw Marczak
Samsung R&D Institute Poland
Samsung Electronics
p.marczak at samsung.com
prev parent reply other threads:[~2014-07-18 14:48 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-17 12:31 [U-Boot] uboot/odroid test report Daniel Drake
2014-07-17 13:00 ` Marek Szyprowski
2014-07-17 13:20 ` Daniel Drake
2014-07-17 13:36 ` Daniel Drake
2014-07-17 13:38 ` Daniel Drake
2014-07-17 14:30 ` Daniel Drake
2014-07-17 15:00 ` Przemyslaw Marczak
2014-07-17 14:59 ` Przemyslaw Marczak
2014-07-17 14:59 ` Przemyslaw Marczak
2014-07-17 15:35 ` Daniel Drake
2014-07-18 14:48 ` Przemyslaw Marczak [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53C933A2.1070004@samsung.com \
--to=p.marczak@samsung.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox