* Patch moving latest linux-galileo common & ev64260 code to 2_4_devel @ 2002-12-24 16:34 Mark A. Greer 2002-12-24 18:36 ` Mark A. Greer 0 siblings, 1 reply; 5+ messages in thread From: Mark A. Greer @ 2002-12-24 16:34 UTC (permalink / raw) To: linuxppc-dev Below is a link to a patch against the latest linuxppc_2_4_devel tree that brings the Marvell/Galileo GT64260 and EV64260 code up to the latest version that's in the linux-galileo tree. ftp://source.mvista.com/linuxppc/galileo_2_4_devel.diff Comments welcome. Mark ** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/ ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Patch moving latest linux-galileo common & ev64260 code to 2_4_devel 2002-12-24 16:34 Patch moving latest linux-galileo common & ev64260 code to 2_4_devel Mark A. Greer @ 2002-12-24 18:36 ` Mark A. Greer 2003-01-14 16:32 ` Tom Rini 0 siblings, 1 reply; 5+ messages in thread From: Mark A. Greer @ 2002-12-24 18:36 UTC (permalink / raw) To: Mark A. Greer; +Cc: linuxppc-dev Okay, as requested, the big patch has been broken up into somewhat logical pieces (although not perfect). They are available here: ftp://source.mvista.com/linuxppc/gal/ Mark -- ** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/ ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Patch moving latest linux-galileo common & ev64260 code to 2_4_devel 2002-12-24 18:36 ` Mark A. Greer @ 2003-01-14 16:32 ` Tom Rini 2003-01-14 23:47 ` Mark A. Greer 0 siblings, 1 reply; 5+ messages in thread From: Tom Rini @ 2003-01-14 16:32 UTC (permalink / raw) To: Mark A. Greer; +Cc: linuxppc-dev On Tue, Dec 24, 2002 at 11:36:46AM -0700, Mark A. Greer wrote: > Okay, as requested, the big patch has been broken up into somewhat > logical pieces (although not perfect). They are available here: > > ftp://source.mvista.com/linuxppc/gal/ I've applied all of this, in the interest of getting things back into sync. What I want to know 'tho, is why is there still the 'reg base' being either here or there. How hard would it be to always have it at the 'other' location? Or, was it decided that it was best to allow this to end up anywhere? Also, I would really like to see the if/else of PPCBoot go away in favor of something like parsing PPCBoot, if it exists, and if not setting up things the 'other' way. ie: platform_init(...) { if (r3 == ppcboot) parse_ppcboot() else find_things_out() ... } find_things_out() { bd_t.memsize = gt64260_find_end_of_memory(); ... } IOW, if we don't have PPCBoot and it's 'bd_t', fill it out.[1] [1] And of course this brings us to bi_recs, which is another flamewar^H^H^H^H^H^H^H^Hdiscussion. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ ** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/ ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Patch moving latest linux-galileo common & ev64260 code to 2_4_devel 2003-01-14 16:32 ` Tom Rini @ 2003-01-14 23:47 ` Mark A. Greer 2003-02-06 19:37 ` Tom Rini 0 siblings, 1 reply; 5+ messages in thread From: Mark A. Greer @ 2003-01-14 23:47 UTC (permalink / raw) To: Tom Rini; +Cc: linuxppc-dev [-- Attachment #1: Type: text/plain, Size: 1796 bytes --] Tom Rini wrote: >I've applied all of this, in the interest of getting things back into >sync. > Thanks. >What I want to know 'tho, is why is there still the 'reg base' being >either here or there. How hard would it be to always have it at the >'other' location? Or, was it decided that it was best to allow this to >end up anywhere? > There wasn't a decision per se but there were 2 versions of DINK and different versions of PPCBoot that left the bridge at different locations so I made the "incoming" base address configurable to anywhere (but with different default for PPCBoot vs. something else). Also, people wanted the base moved to different locations for the kernel so I made the "outgoing" base address configurable as well. Note: The linuxppc bootwrapper is what takes the "incoming" base address & moves it to the specified "outgoing" base address. I sort of like having that flexibility but then I seem to like config options more than others here so... I can get rid of the different defaults and have included a patch to do so. Is that enough? >Also, I would really like to see the if/else of PPCBoot go away in favor >of something like parsing PPCBoot, if it exists, and if not setting up >things the 'other' way. ie: >platform_init(...) { > if (r3 == ppcboot) > parse_ppcboot() > else > find_things_out() > ... >} > >find_things_out() { > bd_t.memsize = gt64260_find_end_of_memory(); > ... >} > >IOW, if we don't have PPCBoot and it's 'bd_t', fill it out.[1] > I suppose but there is code that can be ifdef'd out which makes the executable smaller. Isn't it worth keeping them for that reason? > >[1] And of course this brings us to bi_recs, which is another >flamewar^H^H^H^H^H^H^H^Hdiscussion. > I've totally punted on this for the same reason... Mark [-- Attachment #2: cfg.diff --] [-- Type: text/plain, Size: 2090 bytes --] ===== arch/ppc/config.in 1.163 vs edited ===== --- 1.163/arch/ppc/config.in Tue Jan 14 09:08:28 2003 +++ edited/arch/ppc/config.in Tue Jan 14 16:08:59 2003 @@ -176,31 +176,27 @@ fi if [ "$CONFIG_GT64260" = "y" ]; then - mainmenu_option next_comment - comment 'Marvell/Galileo GT64260 Options' + mainmenu_option next_comment + comment 'Marvell/Galileo GT64260 Options' - dep_bool 'PCI Bus 0 Snooping Disable (experimental)' \ - CONFIG_GT64260_BUS_0_NOT_COHERENT $CONFIG_EXPERIMENTAL - dep_bool 'PCI Bus 1 Snooping Disable (experimental)' \ - CONFIG_GT64260_BUS_1_NOT_COHERENT $CONFIG_EXPERIMENTAL + dep_bool 'PCI Bus 0 Snooping Disable (experimental)' \ + CONFIG_GT64260_BUS_0_NOT_COHERENT $CONFIG_EXPERIMENTAL + dep_bool 'PCI Bus 1 Snooping Disable (experimental)' \ + CONFIG_GT64260_BUS_1_NOT_COHERENT $CONFIG_EXPERIMENTAL - if [ "$CONFIG_GT64260_BUS_0_NOT_COHERENT" = "y" \ - -o "$CONFIG_GT64260_BUS_1_NOT_COHERENT" = "y" ]; then - define_bool CONFIG_NOT_COHERENT_CACHE y - fi + if [ "$CONFIG_GT64260_BUS_0_NOT_COHERENT" = "y" \ + -o "$CONFIG_GT64260_BUS_1_NOT_COHERENT" = "y" ]; then + define_bool CONFIG_NOT_COHERENT_CACHE y + fi - bool 'Board uses PPCBoot' CONFIG_USE_PPCBOOT - if [ "$CONFIG_USE_PPCBOOT" = "y" ]; then - hex 'Base Address assigned by Firmware' CONFIG_GT64260_ORIG_REG_BASE 0xf8000000 - else - hex 'Base Address assigned by Firmware' CONFIG_GT64260_ORIG_REG_BASE 0x14000000 + bool 'Board uses PPCBoot' CONFIG_USE_PPCBOOT + hex 'Base Address assigned by Firmware' CONFIG_GT64260_ORIG_REG_BASE 0x14000000 - bool 'Change Base Address in Bootloader' CONFIG_GT64260_NEW_BASE - if [ "$CONFIG_GT64260_NEW_BASE" = "y" ]; then - hex 'New Base Address' CONFIG_GT64260_NEW_REG_BASE 0x14000000 - fi - fi - endmenu + bool 'Change Base Address in Linux/PPC Bootwrapper' CONFIG_GT64260_NEW_BASE + if [ "$CONFIG_GT64260_NEW_BASE" = "y" ]; then + hex 'New Base Address' CONFIG_GT64260_NEW_REG_BASE 0x14000000 + fi + endmenu fi if [ "$CONFIG_FORCE" = "y" -o "$CONFIG_MENF1" = "y" \ ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Patch moving latest linux-galileo common & ev64260 code to 2_4_devel 2003-01-14 23:47 ` Mark A. Greer @ 2003-02-06 19:37 ` Tom Rini 0 siblings, 0 replies; 5+ messages in thread From: Tom Rini @ 2003-02-06 19:37 UTC (permalink / raw) To: Mark A. Greer; +Cc: linuxppc-dev On Tue, Jan 14, 2003 at 04:47:20PM -0700, Mark A. Greer wrote: > Tom Rini wrote: > > >Also, I would really like to see the if/else of PPCBoot go away in favor > >of something like parsing PPCBoot, if it exists, and if not setting up > >things the 'other' way. ie: > >platform_init(...) { > > if (r3 == ppcboot) > > parse_ppcboot() > > else > > find_things_out() > > ... > >} > > > >find_things_out() { > > bd_t.memsize = gt64260_find_end_of_memory(); > > ... > >} > > > >IOW, if we don't have PPCBoot and it's 'bd_t', fill it out.[1] > > I suppose but there is code that can be ifdef'd out which makes the > executable smaller. Isn't it worth keeping them for that reason? That's the exact opposite of what I intended, actually. I want CONFIG_USE_PPCBOOT to go away. For example, in gt64260_eth.c::gt64260_eth_init yoou do: #ifndef CONFIG_USE_PPCBOOT else { return -ENODEV; } #else ... magic to find an enet addr from PPCBOOT #endif IMHO, this should all be: if (gt64260_info_struct.enet_addr) memcpy(..) else return -ENODEV And so on. Convert the bd_t into a 'generic' struct, fill it out with what PPCBoot passes, or is gleaned from the cmdline, or bi_recs of stuff gleaned from i2c, or whatever. -- Tom Rini http://gate.crashing.org/~trini/ ** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/ ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2003-02-06 19:37 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2002-12-24 16:34 Patch moving latest linux-galileo common & ev64260 code to 2_4_devel Mark A. Greer 2002-12-24 18:36 ` Mark A. Greer 2003-01-14 16:32 ` Tom Rini 2003-01-14 23:47 ` Mark A. Greer 2003-02-06 19:37 ` Tom Rini
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.