Hi --
--- In Doug Chapman <> wrote:
> 1) printk doesn't work early on in the boot so the kernel may be giving
> you an error but you don't see it. To work around this you can edit
> kernel/printk.c to add a call to "printascii()" which does work early
> in the bootup:
Yes, this helps! It helped me go further looking into the same memory
problems.
>
> 2) for the TS-7260/7250 with 64MB RAM for some reason the kernel isn't
> happy with the upper 32MB of ram. I have to add the following boot
> arguments to the kernel:
>
> mem= mem= mem= mem=
>
You can shorten this to:
mem= mem= mem= mem= Not much shorter, I
know, but less likely to make a typo. There is another thread
discussing this issue of the upper 32M (see "only 32M detected by
redboot").
>
> good luck!
>
> - Doug
>
> --- Paulo Marques <> wrote:
>
> > Petr Stetiar wrote:
> > > Paulo Marques <
> > <pmarques%40grupopie.com>>
> > > [2006-11-28 18:34:39]:
> > >
> > > > Hi all,
> > > >
> > > > I was thinking about trying to build a 2.6 kernel for a TS-7400
> > board.
> > > >
> > > > Does anyone have a nice default .config file for a recent 2.6
> > kernel? I
> > > > was going to try to compile a 2.6.19-rc6 kernel.
> > > >
> > > > I searched the archives, but found no one trying to do the same
> > :(
> > >
> > > There is ep93xx_defconfig, which you could use as base. You would
Also, there is an updated ep93xx_defconfig in 2.6.20-rc2. You may
want to look over those diffs.
> > also need
> > > some of ep93xx_* patches available from Lennert's svn repository at
> > > http://svn.wantstofly.org/kernel/
> > <http://svn.wantstofly.org/kernel/>
Some patches may be needed, but Lennert has done a great job sending
his ep93xx patches upstream. There is definitely less-stable
development stuff in his repository though (look at the series file).
I'll have to try a vanilla kernel build, and see how it goes.
> > >
> > > My actual .config(ts7250_ynezz_config.gz) for ts7250 and my diff
> > against
> > > 2.6.19-rc6-git10(ts7250_ynezz_kernel.patch.gz) is available at
> > > http://ynezz.ibawizard.net/ts7250/
> > <http://ynezz.ibawizard.net/ts7250/>
> > >
> >
> > I downloaded a 2.6.19 vanilla kernel and patched with
> > ts7250_ynezz_kernel.patch.gz. The only cross-toolchain (from the
> > available toolchains at the TS site) that was able to build this
> > kernel
> > was the gcc-4.0.1 toolchain. This wasn't the one I used for the 2.4
> > kernel and this one wasn't able to build the 2.4 kernel :P
Sorry, I haven't looked much into toolchains. I wanted EABI and
crunch support, so I went with codesourcery [1]. There are several
other toolchains available though.
> >
> > I tried booting it nevertheless, but the kernel just hung after
> > "Decompressing linux......... done" (or something like that).
Printascii should help here.
> > roadmap. There are basically 2 ways (that I can see) to go from here:
> >
> > - pretend that the ts7400 board is just a small variation of the
> > ts72xx and do minor tweaks to the code to let it handle _both_
> > boards.
> >
> > - create a new machine type for the ts7400 board and do all the
> > infrastructure that is already in place for the ts72xx. Modify the
> > driver code to be 7xxx (instead of 72xx) and modify the low-level
> > 72xx
> > code to register "generic" 7xxx drivers instead of 72xx.
> >
> > This really depends on how different the 2 boards are. The first
> > option
Yes, identifying the differences is key. I haven't worked with the
7400 though, so I'm not much help here. But TS seems quite ready to
answer questions (and I would think especially so when helping out
community support for 2.6 kernels).
IMHO, it would be best to work with the MACH_TYPE_TS72XX definition if
possible. The idea is that the bootloader passes the machineid, and
then the kernel 'does the right thing'based on that. If you define a
new machine type, that would mean a different redboot image for each
machine type. (But hey, I guess that's the case already, so maybe
it's no big deal).
(Redboot currently _doesn't_ pass the right machine code, hence the
need for the head.S hack in Lennerts' "local.diff", but this may be
changing).
> > seems to be the easiest way, since the ts72xx support is already in
> > place and working. I guess most of the hardware that is provided by
> > the
> > EP3902 itself is common between the 2 boards.
> >
> > Please note that if I just wanted a kernel to work for me, I could
> > just
> > tweak the current ts72xx version until I got something workable, but
> > I
> > really wanted to do this The Right Way(tm) eventually leading to the
> > board being supported by official vanilla kernels.
I suggest you get direction from Lennert Buytenhek (maintainer of the
ep93xx stuff in the kernel). AFAIK, he would be the one to feed the
patches upstream, so it would be very good if he agreed with your
approach :) You might post on the linux-cirrus ML for feedback.[2]
> >
> > Thanks in advance for any advice,
> >
> > --
> > Paulo Marques - www.grupopie.com
regards, ......... Charlie
[1] http://www.codesourcery.com/gnu_toolchains/arm/download.html
[2] http://www.freelists.org/archives/linux-cirrus/
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/ts-7000/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/ts-7000/join
(Yahoo! ID required)
<*> To change settings via email:
<*> To unsubscribe from this group, send an email to:
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
|