public inbox for
 help / color / mirror / Atom feed
From: Bart Veer <>
To: Jonathan Larmour <>
Subject: Re: [flashv2 merge] io/flash
Date: Tue, 18 Nov 2008 16:53:00 -0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <> (message from Jonathan Larmour 	on Tue, 18 Nov 2008 15:58:26 +0000)

>>>>> "Jifl" == Jonathan Larmour <> writes:

    >> Now, I suspect that no solution is going to work for every bit of
    >> hardware that people can conceive off. As and when we run into
    >> problems we may have to add configury for setting certain init
    >> priorities, together with requires constraints in the platform HAL, to
    >> ensure that everything initializes in the correct order for a specific
    >> platform. However the following order should work for most systems:
    >> #define CYG_INIT_BUS_PRIMARY
    >> #define CYG_INIT_BUS_PCI		(alias for PRIMARY)
    >> #define CYG_INIT_BUS_USBHOST		(alias for secondary)
    >> #define CYG_INIT_BUS_TERTIARY
    >> #define CYG_INIT_BUS_SPI		(alias for tertiary)
    >> #define CYG_INIT_BUS_I2C		(ditto)
    >> #define CYG_INIT_BUS_CAN		(?)
    >> #define CYG_INIT_DEV_WATCHDOG
    >> #define CYG_INIT_DEV_FLASH		(alias for BLOCK_PRIMARY)
    >> #define CYG_INIT_CONFIG
    >> #define CYG_INIT_DEV_CHAR		(all other devices)
    >> #define CYG_INIT_IO_FS
    Jifl> [big snip]

    Jifl> I think this is all absolutely fine.

Actually, it is wrong in at least one place. I remember one board
where the CAN interface was hanging off an SPI bus instead of being
on-chip. That implies CAN should be treated as a network device, not a
bus, and should init at CYG_INIT_DEV_CHAR.

Everybody, please think carefully about any funny boards you have come
across over the years, and whether or not the above order makes sense.

    >> Finally the file I/O subsystem. Possibly this should happen
    >> earlier, between DEV_BLOCK_PRIMARY and CONFIG, so that an
    >> implementation of the config data module can be layered on top
    >> of file I/O. Or possibly CYG_INIT_IO_FS should happen
    >> immediately after CYG_INIT_MEMALLOC, with the proviso that file
    >> I/O operations for devices may fail until later in the init
    >> sequence.

    Jifl> It's certainly plausible to want to read config data from an
    Jifl> FS, IMHO. But CYG_INIT_MEMALLOC seems unnecessarily early
    Jifl> and would probably cause more problems than it solves.

I am not sure I agree with that. MEMALLOC should only involve main
memory, with no need to worry about whether or not any of the I/O
subsystem is available yet. Initializing MEMALLOC early means that
device drivers could perform run-time detection and dynamically
allocate any buffers required, instead of statically allocating for
the worst case.

On the other hand, some drivers for e.g. framebuffer devices may need
to mess about with the memory map and lower memtop. Although really
that kind of thing should be handled at the platform linker script
level, not at run-time.

I suspect that in the long term we'll be happier initializing memalloc
early on.


Bart Veer                                   eCos Configuration Architect
eCosCentric Limited    The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.      Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.

  reply	other threads:[~2008-11-18 16:53 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <>
     [not found] ` <>
     [not found]   ` <>
2008-11-18 15:59     ` Jonathan Larmour
2008-11-18 16:53       ` Bart Veer [this message]
2008-11-18 17:22         ` Jonathan Larmour
2008-11-18 17:59           ` Bart Veer
2008-11-18 18:35             ` Jonathan Larmour

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \

* 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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).