All of lore.kernel.org
 help / color / mirror / Atom feed
From: Simon Glass <sjg@chromium.org>
To: u-boot@lists.denx.de
Subject: [U-Boot] [Question] Driver-Model UART on NOR-boot ? Work?
Date: Wed, 1 Oct 2014 09:31:22 -0600	[thread overview]
Message-ID: <CAPnjgZ0BHsg+Qj9i-79rE33b=Cx20m6sV37PE+eVujzfYVGdow@mail.gmail.com> (raw)
In-Reply-To: <20141001202307.90B5.AA925319@jp.panasonic.com>

Hi Masahiro,

On 1 October 2014 05:23, Masahiro Yamada <yamada.m@jp.panasonic.com> wrote:
> Hi Simon,
>
>
>
> I am looking at the driver-model serial code.
>
>
> I notice driver-model serial code uses ".data" section
> for storing the current device even before relocation.
>
>
> This code in drivers/serial/serial-uclass.c:
>
>   /* The currently-selected console serial device */
>   struct udevice *cur_dev __attribute__ ((section(".data")));
>
>
>
> In my understanding, we should not write any data to
> .data section before relocation.
>
>
> Let's say we are booting U-Boot from NOR flash.
>
> Before relocation, everything (including .data section)
> is placed on NOR flash which is read-only.
> (Please point out if I am wrong.)
>
> We are only allowed to write data to the stack, gd_t, bd_t
> and malloc area (if CONFIG_SYS_MALLOC_F_LEN is defined)
> before relocation, I think.
>
>
>
> I think that is why pre-driver-model serial uses a hard-coded
> default serial port before relocation.
>
>
>   This code in driver/serial/serial.c:
>
>      if (!(gd->flags & GD_FLG_RELOC))
>                 dev = default_serial_console();
>      else if (!serial_current)
>                 dev = default_serial_console();
>      else
>                 dev = serial_current;
>
>
>
>
> My question is,  does printf() work
> with driver-model UART and XIP device such NOR flash?

The global_data structure needs to go somewhere, even before
relocation. On ARM this is general SRAM I suppose. In your case I
think you have some cache RAM to use. Do you use SPL?

The pre-reloc malloc() area goes below global_data so uses the same mechanism.

Yes it is true that strictly speaking we should not use data before
relocation. I suppose we could move cur_dev to global_data instead for
this particular case. It doesn't really scale to other drivers, but
then I expect that only serial needs to keep a 'current' pointer
before relocation, and even that will eventually go away once the
serial stuff is cleaned up.

So let me know if that solution works.

Regards,
Simon

  reply	other threads:[~2014-10-01 15:31 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-01 11:23 [U-Boot] [Question] Driver-Model UART on NOR-boot ? Work? Masahiro Yamada
2014-10-01 15:31 ` Simon Glass [this message]
2014-10-01 16:27   ` Masahiro YAMADA
2014-10-01 23:43     ` Simon Glass
2014-10-02  5:18       ` Masahiro Yamada
2014-10-04  2:19         ` Simon Glass

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='CAPnjgZ0BHsg+Qj9i-79rE33b=Cx20m6sV37PE+eVujzfYVGdow@mail.gmail.com' \
    --to=sjg@chromium.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.