The T2 SDE project - feedback?

Go To Last Post
17 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

anyone w/ feedback on the release? I plan to take a long look at this release for AVR32 and Blackfin next week.

http://www.t2-project.org/about....

Quote:

7.0 release in summer 2007
User visible

* Atmel AVR32 CPU support
* Analog Devices Blackfin CPU support
* GCC 4.2
* GlibC 2.6
* X.Org 7.3
* over 400 more packages
* most existing packages received an update
* over 4500 SVN revisions since the 6.0 branch!

Anyone using Timesys? I enjoy their podcasts (sometimes) about embeded linux, but frankly it's too high level and removed from hardware for my liking...and they don't port to ADIs Blackfin.
http://www.timesys.com/products/...

Fedora 7 is now spinning distros, but just for desktop systems...

Quote:
2.2.1. Spins

For the first time, Fedora includes several different spins, which are variations of Fedora built from a specific set of software packages. Each spin has a combination of software to meet the requirements of a specific kind of end user.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have tried several times to build with T2, but have yet to succeed. There are hints on the web site that there would be specific examples for AVR32 in the book, so I downloaded the book and there were no such examples. I have not been able to dig deep enough to figure out why, but there are always failures in uClibc.

I also tried to build with buildroot

http://buildroot.uclibc.org

Which I have used successfully on other processors in the past, but it seems to have numerous issues with the AVR32 platform.

It would be really nice to see one or both of these build systems fully supported, or any other for that matter.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yeah you have to play with buildroot a fair bit to make it fly.

I haven't got T2 to happen either actually. For me it keeps failing while trying to patch the kernel. It looks just like the application order of the patches is horked, shall try to debug.

[Error log attached for those what care. Config was Generic Embedded on AVR32]

-S.

EDIT: Khay so the UnionFS and SquashFS patches clash with the arch ones. Modifying pkg_linux26_pre.conf to not apply these patches has allowed the build to proceed. Lets see how far we get now.

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Are you working from the head of svn on T2? Can you commit your changes?

Thanks.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Are the things you have to do to buildroot documented anywhere? Wiki page maybe?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

eokerson wrote:
Are you working from the head of svn on T2? Can you commit your changes?
Yup, working from HEAD. I still don't have a completely working setup, I should nail it tonight hopefully. Once I've got it completely operational I'll post the config and packages lists and a bit of a how-to as well. I'm gradually working through it. So far the issues I've found:
- The CramFS/ SquashFS patches conflict with the ARCH patches in Linux. Must disable all CramFS/ SquashFS tools.
- You must not build the standalone versions of any programs which are also included in Busybox
- Various things marked as correctly cross-compiling but don't, simply need to be disabled for now.
- Few other things I can't currently recall ;)

-S.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

eokerson wrote:
Are the things you have to do to buildroot documented anywhere? Wiki page maybe?
I'm not even sure anyone has got it working completely well yet actually, so no, no docco yet. As I say, should nail the T2 stuff tonight and shall make some docco surrounding that once it's all flying.

-S.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Squidgit,

Did you manage to get T2 flying?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Not yet, the final hurdle is that both busybox and binutils want to provide ar and strings. Both binutils and busybox are critical pieces of kit so I can't just cleanly disable one of them ;)

I've done up a custom busybox config which doesn't build either of these utils and that's compiling right now (literally on my other monitor). We'll see whether that works, fingers crossed! (I'm not familiar enough with T2 to know whether I put the config in the right place :) )

-S.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Khay, got it working.

I just had to add

O CONFIG_AR
O CONFIG_STRINGS

to architecture/avr32/busybox.conf. Attached is a minimalistic packages, config and busybox.conf. With these 3 you should get something building.

Shall test more packages and get something more complete soon.

And shall wrap this up in docco on the wiki some time soon too :)

-S.

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

squidgit,

Thanks! That appears to have worked, the build completed! Now I just need to flash it on an NGW.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The T2 build produced a squashfs image, but all of the example images for the NGW100 are JFFS2. Is one better than the other? Should I rebuild for JFFS2?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The squashfs patches are not compatible with the avr32 arch patches (nothing technical, just the patches need to be respun). This means that that kernel cannot boot from squashfs. And AFAIK u-boot can't boot from squashfs either. So no, the squashfs images won't work.

I'm working on an STK1000 right about now where I just copied the generated directory structure to my NFS share. This can of course be done for NGW as well. If you want to program to flash yep, you really should create a jffs2 image (instructions on the wiki somewhere :) ).

-S.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This project caught my interest because the Blackfin must run uClinux (there is no MMU). AVR32 however can run the native kernel yet it T2 SDE doesn't show these differences to the user during compilation.

It seems harder to port a new target to T2 SDE (like the ARM7) than it is to learn POSIX shell commands for the target's toolchain, defeating the purpose of the project IMO.

I guess I'm missing the big picture for T2. OTOH, this might be a new trend; uCs without MMU merging upstream into the kernel and futher blurring distinctions between server,desktop, and uC distros. :shock: Until that time, workarounds will have to suffice.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

squidgit wrote:
The squashfs patches are not compatible with the avr32 arch patches (nothing technical, just the patches need to be respun).

Oh. You mean there's a problem with the squashfs patches or the avr32 arch patches?

Btw, I think initrd is broken on avr32 at the moment. Try searching for CONFIG_INITRD and replace it with CONFIG_BLK_DEV_INITRD in arch/avr32/kernel/setup.c. I'll see if I can come up with a patch soon.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

how wrote:
squidgit wrote:
The squashfs patches are not compatible with the avr32 arch patches (nothing technical, just the patches need to be respun).

Oh. You mean there's a problem with the squashfs patches or the avr32 arch patches?

There's no problem with the _content_ of the patches afaict, just that one set of patches needs to be rebased upon the other :). If you apply the patches from architecture/avr32/package/linux26 as well as the squashfs patches some hunks conflict, fail, esplode etc ;)

-S.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sonos wrote:
This project caught my interest because the Blackfin must run uClinux (there is no MMU). AVR32 however can run the native kernel yet it T2 SDE doesn't show these differences to the user during compilation.

It seems harder to port a new target to T2 SDE (like the ARM7) than it is to learn POSIX shell commands for the target's toolchain, defeating the purpose of the project IMO.

Hehe, I think what you've put there /is/ kinda the point of T2: you can compile the same kinds of things for a number of different archs without actually seeing the differences yourself.

There's certainly nothing T2 can do which a sufficiently elite hand can't do manually. The thing is, once all the bugs are ironed out and the thing actually is working well, ease of use. Sure you can compile something, come back, compile the next thing, get all the binaries and cut and paste them to the correct place in a filesystem tree. The idea with T2 though is that you don't have to do that, you give it a package manifest with all the things you need to compile, come back a few hours/days later and it's all done for you including source download and patching etc.

Probably personal preference, if you're only going to have a few programs then using the Atmel BSP rootfs and just pasting in some extra binaries is probably a good plan but if you want to build up something nice and big complete with the best parts of Life, The Universe and Everything then the T2 scripts will help you out a lot :)

Of course our use of T2 is about as basic as can be, it can be used like Gentoo to build a massive source-based distro.

-S.