From: Benjamin Herrenschmidt <benh@kernel.crashing.org> To: Kazutomo Yoshii <kazutomo@mcs.anl.gov> Cc: Eric Van Hensbergen <ericvh@gmail.com>, linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org, bg-linux@lists.anl-external.org Subject: Re: [bg-linux] [PATCH 6/7] [RFC] enable early TLBs for BG/P Date: Fri, 20 May 2011 13:52:21 +1000 [thread overview] Message-ID: <1305863541.7481.132.camel@pasglop> (raw) In-Reply-To: <4DD5E218.5030508@mcs.anl.gov> > Unfortunately, the firmware is also required: > - to configure Blue Gene Interrupt Controller(BIC) Can't we just write bare metal code for that ? > - to configure Torus DMA unit. e.g. fifo Same > - to configure global interrupt (even we don't use, we need to disable > some channel correctly) Same > - to access node personality information (node id, DDR size, HZ, etc) or > maybe we can directly access SRAM? That should be turned into device-tree at boot, possibly from a bootloader or from the zImage wrapper. > etc, etc. > > >> As such the IO Node guys, the Compute Node Kernel guys and the > >> ZeptoOS guys use it quite a bit. The kittyhawk guys on the other hand > >> barely use it at all, in fact I believe they do all the interaction with > >> it during uboot and then shut it off. > >> > > > (I'm one of the ZeptoOS guys, btw) Heh ok. > As a regular ppc linux usage, our firmware dependency is minimum as well. > However, with our HPC extension, the firmware functions are called when > it configures BGP specific network hardware. > > We are not planning to submit our HPC extension here anytime soon > because our work is very special purpose and includes lots of dirty hack > right now. Ok. Cheers, Ben. > Thanks, > Kaz > > I would prefer that approach. > > > > > >> IIRC, the sticky question is RAS support, there are certain things it > >> wants to jump to firmware to deal with and expects things to be mapped > >> an pinned into memory. > >> > >> Furthermore, I think it may make assumptions about where in the TLB the > >> mappings are. > >> > > This is gross, especially on a system with only 64 SW loaded TLB > > entries :-( > > > > > >> Since the kittyhawk guys > >> obviously ignore this by shutting it down, its not clear just how > >> important this is. I'm game to > >> try the dynamic mapping as you suggest if you would prefer it. > >> > > I would yes, we can sort things out later for RAS. > > > > > >> Its worth mentioning that I believe with BG/Q, the plan is to rely on > >> the firmware even more extensively, but I haven't looked at any of the code yet to verify > >> whether or not this is true. > >> > > This is tantamount to linking a binary blob with the kernel ... it's a > > fine line. At some point we might refuse the patches if they go too far > > in that direction. > > > > Cheers, > > Ben. > > > > > >> -eric > >> -- > >> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > >> the body of a message to majordomo@vger.kernel.org > >> More majordomo info at http://vger.kernel.org/majordomo-info.html > >> Please read the FAQ at http://www.tux.org/lkml/ > >> > > > > _______________________________________________ > > bg-linux mailing list > > bg-linux@lists.anl-external.org > > https://lists.anl-external.org/mailman/listinfo/bg-linux > > http://bg-linux.anl-external.org/wiki > >
WARNING: multiple messages have this Message-ID (diff)
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> To: Kazutomo Yoshii <kazutomo@mcs.anl.gov> Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org, bg-linux@lists.anl-external.org Subject: Re: [bg-linux] [PATCH 6/7] [RFC] enable early TLBs for BG/P Date: Fri, 20 May 2011 13:52:21 +1000 [thread overview] Message-ID: <1305863541.7481.132.camel@pasglop> (raw) In-Reply-To: <4DD5E218.5030508@mcs.anl.gov> > Unfortunately, the firmware is also required: > - to configure Blue Gene Interrupt Controller(BIC) Can't we just write bare metal code for that ? > - to configure Torus DMA unit. e.g. fifo Same > - to configure global interrupt (even we don't use, we need to disable > some channel correctly) Same > - to access node personality information (node id, DDR size, HZ, etc) or > maybe we can directly access SRAM? That should be turned into device-tree at boot, possibly from a bootloader or from the zImage wrapper. > etc, etc. > > >> As such the IO Node guys, the Compute Node Kernel guys and the > >> ZeptoOS guys use it quite a bit. The kittyhawk guys on the other hand > >> barely use it at all, in fact I believe they do all the interaction with > >> it during uboot and then shut it off. > >> > > > (I'm one of the ZeptoOS guys, btw) Heh ok. > As a regular ppc linux usage, our firmware dependency is minimum as well. > However, with our HPC extension, the firmware functions are called when > it configures BGP specific network hardware. > > We are not planning to submit our HPC extension here anytime soon > because our work is very special purpose and includes lots of dirty hack > right now. Ok. Cheers, Ben. > Thanks, > Kaz > > I would prefer that approach. > > > > > >> IIRC, the sticky question is RAS support, there are certain things it > >> wants to jump to firmware to deal with and expects things to be mapped > >> an pinned into memory. > >> > >> Furthermore, I think it may make assumptions about where in the TLB the > >> mappings are. > >> > > This is gross, especially on a system with only 64 SW loaded TLB > > entries :-( > > > > > >> Since the kittyhawk guys > >> obviously ignore this by shutting it down, its not clear just how > >> important this is. I'm game to > >> try the dynamic mapping as you suggest if you would prefer it. > >> > > I would yes, we can sort things out later for RAS. > > > > > >> Its worth mentioning that I believe with BG/Q, the plan is to rely on > >> the firmware even more extensively, but I haven't looked at any of the code yet to verify > >> whether or not this is true. > >> > > This is tantamount to linking a binary blob with the kernel ... it's a > > fine line. At some point we might refuse the patches if they go too far > > in that direction. > > > > Cheers, > > Ben. > > > > > >> -eric > >> -- > >> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > >> the body of a message to majordomo@vger.kernel.org > >> More majordomo info at http://vger.kernel.org/majordomo-info.html > >> Please read the FAQ at http://www.tux.org/lkml/ > >> > > > > _______________________________________________ > > bg-linux mailing list > > bg-linux@lists.anl-external.org > > https://lists.anl-external.org/mailman/listinfo/bg-linux > > http://bg-linux.anl-external.org/wiki > >
next prev parent reply other threads:[~2011-05-20 3:52 UTC|newest] Thread overview: 79+ messages / expand[flat|nested] mbox.gz Atom feed top 2011-05-18 21:24 [PATCH 1/7] [RFC] Mainline BG/P platform support Eric Van Hensbergen 2011-05-18 21:24 ` Eric Van Hensbergen 2011-05-18 21:24 ` [PATCH 2/7] [RFC] add bluegene entry to cputable Eric Van Hensbergen 2011-05-18 21:24 ` Eric Van Hensbergen 2011-05-20 0:35 ` Benjamin Herrenschmidt 2011-05-20 0:35 ` Benjamin Herrenschmidt 2011-05-20 1:08 ` Eric Van Hensbergen 2011-05-20 1:08 ` Eric Van Hensbergen 2011-05-20 1:50 ` Benjamin Herrenschmidt 2011-05-20 1:50 ` Benjamin Herrenschmidt 2011-05-18 21:24 ` [PATCH 3/7] [RFC] add support for BlueGene/P FPU Eric Van Hensbergen 2011-05-18 21:24 ` Eric Van Hensbergen 2011-05-19 5:58 ` Michael Neuling 2011-05-19 5:58 ` Michael Neuling 2011-05-19 13:53 ` Eric Van Hensbergen 2011-05-19 13:53 ` Eric Van Hensbergen 2011-05-19 15:22 ` [bg-linux] " Kazutomo Yoshii 2011-05-19 21:36 ` Michael Neuling 2011-05-19 21:36 ` Michael Neuling 2011-05-19 21:55 ` Eric Van Hensbergen 2011-05-19 21:55 ` Eric Van Hensbergen 2011-05-19 23:16 ` Michael Neuling 2011-05-19 23:16 ` Michael Neuling 2011-05-20 0:30 ` Eric Van Hensbergen 2011-05-20 0:30 ` Eric Van Hensbergen 2011-05-20 0:43 ` Michael Neuling 2011-05-20 0:43 ` Michael Neuling 2011-05-20 0:53 ` Benjamin Herrenschmidt 2011-05-20 0:52 ` Benjamin Herrenschmidt 2011-05-20 0:52 ` Benjamin Herrenschmidt 2011-05-19 21:41 ` [PATCH 3/7] [RFC][V2] add support for BlueGene/P Double FPU Eric Van Hensbergen 2011-05-19 21:41 ` Eric Van Hensbergen 2011-05-18 21:24 ` [PATCH 4/7] [RFC] enable L1_WRITETHROUGH mode for BG/P Eric Van Hensbergen 2011-05-18 21:24 ` Eric Van Hensbergen 2011-05-19 10:43 ` Josh Boyer 2011-05-19 10:43 ` Josh Boyer 2011-05-19 12:53 ` Eric Van Hensbergen 2011-05-19 12:53 ` Eric Van Hensbergen 2011-05-19 21:42 ` [PATCH 4/7] [RFC][V2] enable BGP_L1_WRITETHROUGH " Eric Van Hensbergen 2011-05-19 21:42 ` Eric Van Hensbergen 2011-05-20 1:01 ` [PATCH 4/7] [RFC] enable L1_WRITETHROUGH " Benjamin Herrenschmidt 2011-05-20 1:01 ` Benjamin Herrenschmidt 2011-05-18 21:24 ` [PATCH 5/7] [RFC] force 32-byte aligned kmallocs Eric Van Hensbergen 2011-05-18 21:24 ` Eric Van Hensbergen 2011-05-20 0:36 ` Benjamin Herrenschmidt 2011-05-20 0:36 ` Benjamin Herrenschmidt 2011-05-20 0:47 ` Eric Van Hensbergen 2011-05-20 0:47 ` Eric Van Hensbergen 2011-05-20 1:50 ` Benjamin Herrenschmidt 2011-05-20 1:50 ` Benjamin Herrenschmidt 2011-05-20 1:32 ` [bg-linux] " Kazutomo Yoshii 2011-05-20 2:08 ` Benjamin Herrenschmidt 2011-05-20 2:08 ` Benjamin Herrenschmidt 2011-05-20 2:13 ` Benjamin Herrenschmidt 2011-05-20 2:13 ` Benjamin Herrenschmidt 2011-05-20 3:02 ` Kazutomo Yoshii 2011-05-20 3:13 ` Benjamin Herrenschmidt 2011-05-18 21:24 ` [PATCH 6/7] [RFC] enable early TLBs for BG/P Eric Van Hensbergen 2011-05-18 21:24 ` Eric Van Hensbergen 2011-05-20 0:39 ` Benjamin Herrenschmidt 2011-05-20 0:39 ` Benjamin Herrenschmidt 2011-05-20 1:21 ` Eric Van Hensbergen 2011-05-20 1:21 ` Eric Van Hensbergen 2011-05-20 1:54 ` Benjamin Herrenschmidt 2011-05-20 1:54 ` Benjamin Herrenschmidt 2011-05-20 3:38 ` [bg-linux] " Kazutomo Yoshii 2011-05-20 3:38 ` Kazutomo Yoshii 2011-05-20 3:52 ` Benjamin Herrenschmidt [this message] 2011-05-20 3:52 ` Benjamin Herrenschmidt 2011-05-20 13:01 ` Eric Van Hensbergen 2011-05-20 22:20 ` Benjamin Herrenschmidt 2011-05-18 21:24 ` [PATCH 7/7] [RFC] SMP support code Eric Van Hensbergen 2011-05-18 21:24 ` Eric Van Hensbergen 2011-05-20 1:05 ` Benjamin Herrenschmidt 2011-05-20 1:05 ` Benjamin Herrenschmidt 2011-05-19 11:01 ` [PATCH 1/7] [RFC] Mainline BG/P platform support Josh Boyer 2011-05-19 11:01 ` Josh Boyer 2011-05-19 12:35 ` Eric Van Hensbergen 2011-05-19 12:35 ` Eric Van Hensbergen
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=1305863541.7481.132.camel@pasglop \ --to=benh@kernel.crashing.org \ --cc=bg-linux@lists.anl-external.org \ --cc=ericvh@gmail.com \ --cc=kazutomo@mcs.anl.gov \ --cc=linux-kernel@vger.kernel.org \ --cc=linuxppc-dev@lists.ozlabs.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: linkBe 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.