From: fjohnber@zoho.com (Fredrick)
To: kernelnewbies@lists.kernelnewbies.org
Subject: kmalloc before kmem_cache_init
Date: Sun, 29 Jan 2012 05:27:30 -0800 [thread overview]
Message-ID: <4F254942.30505@zoho.com> (raw)
In-Reply-To: <CAEfq6QQbK6Aq7kVCJGU8rF=DPVt+FwUzZXpZYaDuJAFyoFT4OA@mail.gmail.com>
On 01/29/2012 04:29 AM, Sukanto Ghosh wrote:
> So to use a MMIO based 8250 as "earlycon", either we need to have some
> sort of fixmap
> (as in case of x86) or otherwise we need to have a ioremap_nocache()
> version that works
> even before kmem_cache_init() is called.
> I am not sure how many architectures will have such form of ioremap
> other than maybe
> nommu variants.
>
Some architectures check for mem_init_done.
Probably every architecture must provide an "early_ioremap" function to
be used in early _code_.
> Greg,
>
> Has anyone used the ioremap path so far ? If not, then why have it
> there as usual ioremap
> can be used only after mm_init(), but this driver whenever used will
> get called earlier than that ?
>
> Regards,
> Sukanto
>
>
>
> On Sun, Jan 29, 2012 at 3:03 PM, Dave Hylands<dhylands@gmail.com> wrote:
>> Hi Sukanto,
>>
>> On Sat, Jan 28, 2012 at 11:25 PM, Sukanto Ghosh
>> <sukanto.cse.iitb@gmail.com> wrote:
>>> Hi Dave,
>>>
>>> If you look into start_kernel() the call to parse_early_param()
>>> precedes mm_init().
>>> parse_early_param() eventually calls do_early_param().
>>> do_early_param() parses for "earlycon" in kernel commandline and then calls the
>>> setup_function associated with earlycon.
>>>
>>> I have in my commandline: earlycon=uart8250,mmio32,0x10000000,9600
>>>
>>> Call flow starting from drivers/tty/serial/8250_early.c will lead to kmalloc
>>>
>>> early_param("early_con", setup_early_serial8250_console)
>>> setup_early_serial8250_console()
>>> early_serial8250_setup()
>>> parse_options()
>>> ioremap_nocache()
>>> ... arch-specific-ioremap
>>> -- some form of arch specific __ioremap_caller
>>> --- get_vm_area_caller()
>>> __get_vm_area_node
>>> kzalloc_node
>>> kmalloc_node
>>> kmalloc
>>
>> It looks like CONFIG_FIX_EARLYCON_MEM defaults to y (on x86 anyways),
>> so this would cause the path that doesn't call ioremam_nocache to be
>> taken.
>>
>> I'm guessing that if you specify earycon, then you also need to ensure
>> that CONFIG_FIX_EARLYCON is set.
>>
>> You didn't mention which architecture you were using. ARM has an
>> early_printk which is sort of like an early console.
>>
>> --
>> Dave Hylands
>> Shuswap, BC, Canada
>> http://www.davehylands.com
>
>
>
-Fredrick
prev parent reply other threads:[~2012-01-29 13:27 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CAEfq6QR4K1i4Xp8TBYxorFYnDk1CPM1F2c+gYnfoc3J3Zj4yvA@mail.gmail.com>
2012-01-29 6:02 ` kmalloc before kmem_cache_init Sukanto Ghosh
2012-01-29 6:58 ` Dave Hylands
2012-01-29 7:25 ` Sukanto Ghosh
2012-01-29 9:33 ` Dave Hylands
2012-01-29 12:29 ` Sukanto Ghosh
2012-01-29 13:27 ` Fredrick [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=4F254942.30505@zoho.com \
--to=fjohnber@zoho.com \
--cc=kernelnewbies@lists.kernelnewbies.org \
/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.