From: Sean Cross <xobs@kosagi.com>
To: Sascha Hauer <s.hauer@pengutronix.de>
Cc: barebox@lists.infradead.org
Subject: Re: Porting barebox to Novena: misc questions
Date: Thu, 13 Mar 2014 18:18:44 +0800 [thread overview]
Message-ID: <53218604.6080702@kosagi.com> (raw)
In-Reply-To: <20140313073817.GR17250@pengutronix.de>
On 13/3/14 3:38 PM, Sascha Hauer wrote:
> Hi Sean,
>
> On Thu, Mar 13, 2014 at 10:04:35AM +0800, Sean Cross wrote:
>> Hi,
>>
>> I've finally managed to get U-Boot's SPL to configure DDR3 and load
>> barebox off of a FAT partition on an i.MX6DL. I also have a barebox
>> build with most features turned on, and I'm running into a number of
>> problems. barebox is able to load a zImage off of the FAT partition,
>> set up ATAGs, and jump to it. So I have the basics done. But there are
>> lots of little things that aren't working.
>>
>> When I boot without an Ethernet cable plugged in, the "timeout" command
>> takes a very long time to complete. It generally freezes at "Hit any
>> key to stop autoboot: 3" and tends to ignore input for around ten
>> seconds. How can I prevent this from happening, short of compiling out
>> FEC support?
>
> Are you trying to start from network without a cable plugged in? When I
> start from network without a cable I get:
>
> running /env/bin/init...
>
> Hit m for menu or any other key to stop autoboot: 1
> blspec: blspec_scan_directory: net loader/entries
> booting net
> dhcp failed: Network is down
> dhcp: Network is down
>
> It indeed takes some seconds until we are sure that the link is down.
> That timeout could be reduced, but we must give the phy some time to
> bring up the link.
>
> Or does this happen when you are not trying to boot from network at all?
> That shouldn't happen. If it does, maybe some automount command triggers
> network accesses.
This was caused by the default environment I imported. It set
"ip=dhcp", which I guess caused it to try and obtain an address. I've
set it to "ip=none" for now, and the problem has gone away.
>> The "usb" command just hangs the system. It should at least detect the
>> other ASIX Ethernet port. I have &usbh1 configured identically to
>> sabrelite. Is there something else I need to configure?
>
> This usually means the phys are not configured correctly. Are you
> probing from devicetree?
I am probing from devicetree. I don't see phys mentioned anywhere
except in the imx6qdl.dtsi file, which means that in theory there
shouldn't be anything for me to modify.
>>
>> The "usbserial" command returns "usbserial: No such device". Like usb,
>> I have &usbotg configured the same as sabrelite. It doesn't work with
>> dr_mode set to either "host" or "otg".
>
> Ok, from devicetree it seems. I can say that there shouldn't be any bugs
> in the common usb code preventing your devices from being probed. It
> normally boils down to some usbmisc register setting being wrong.
I don't see any usbmisc register mentioned in any of the board bringup
files. The first time I run usbserial it says "No such device", and
subsequent runs cause it to print out "Invalid argument".
>> How can I pass the correct ram size to Linux? The comment on
>> barebox_arm_entry() notes that "[memsize] doesn't necessarily have to be
>> the full SDRAM", and indeed I notice that barebox hangs if I pass it the
>> full 3840 MB passed from U-Boot. So I'm currently limiting it to 1GB in
>> my start_imx6dl_kosagi_novena_6dl routine. Do I need to somehow add the
>> remainder as another bank somewhere? Or modify the bank size in my
>> kosagi_novena_init() in board.c?
>
> If you probe from devicetree the correct amount of memory is taken from
> there. If that doesn't work (dynamic amount of memory for example) you
> can set the memory in the devicetree to 0 and call arm_add_mem_device
> instead.
Thank you. Now I've got the full memory amount showing up.
>> Finally, I was unable to get barebox to boot with MMU support. For some
>> reason it kept trying to allocate memory just outside of allocated RAM.
>
> This is related to the wrong memory setup. That should be solved when
> you get that straight.
>
>> Is there any benefit to running with the MMU enabled on i.MX6?
>
> Definitely, yes. barebox runs much faster with MMU enabled.
If I enable the MMU but disable early MMU, it hangs with this error:
Board: Kosagi i.MX6DL Novena Board
detected i.MX6 DualLite revision 1.1
ERROR: out of memory
[<5062e9ed>] (unwind_backtrace+0x1/0x74) from [<5061c525>] (panic+0x1d/0x34)
[<5061c525>] (panic+0x1d/0x34) from [<5061cc27>] (xmemalign+0xf/0x14)
[<5061cc27>] (xmemalign+0xf/0x14) from [<5062f687>] (mmu_init+0x16b/0x1f8)
[<5062f687>] (mmu_init+0x16b/0x1f8) from [<50600797>]
(start_barebox+0x1b/0xd0)
[<50600797>] (start_barebox+0x1b/0xd0) from [<5062efcd>] (__start+0x91/0xa4)
[<5062efcd>] (__start+0x91/0xa4) from [<50600005>]
(__bare_init_start+0x1/0xc)
### ERROR ### Please RESET the board ###
If I also enable early MMU, it hangs much much earlier. When I dug into
it, it looked like it was trying to place a TTB just outside of the
allocated memory region, for some reason.
This is with me passing SZ_1G to barebox_arm_entry(). If I pass
something small like SZ_64M, it hangs completely. If I instead pass it
SZ_128M, it works just fine, but of course the MMU still doesn't work.
Sean
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
next prev parent reply other threads:[~2014-03-13 10:19 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-13 2:04 Sean Cross
2014-03-13 7:38 ` Sascha Hauer
2014-03-13 10:18 ` Sean Cross [this message]
2014-03-13 20:27 ` Sascha Hauer
2014-03-14 3:35 ` Sean Cross
2014-03-14 8:22 ` Sascha Hauer
2014-03-17 4:28 ` Sean Cross
2014-03-17 7:18 ` Sascha Hauer
2014-03-17 7:31 ` Alexander Aring
2014-03-17 7:44 ` Sean Cross
2014-03-17 10:53 ` Sascha Hauer
2014-03-18 3:35 ` Sean Cross
2014-03-18 8:36 ` Sascha Hauer
2014-03-18 8:43 ` Sean Cross
2014-03-18 8:58 ` Sascha Hauer
2014-03-18 9:04 ` Sean Cross
2014-03-13 19:42 ` Jean-Christophe PLAGNIOL-VILLARD
2014-03-13 20:30 ` Sascha Hauer
2014-03-14 3:03 ` Jean-Christophe PLAGNIOL-VILLARD
2014-03-13 20:43 ` Eric Bénard
2014-03-13 21:26 ` Sascha Hauer
2014-03-14 3:13 ` Jean-Christophe PLAGNIOL-VILLARD
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=53218604.6080702@kosagi.com \
--to=xobs@kosagi.com \
--cc=barebox@lists.infradead.org \
--cc=s.hauer@pengutronix.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