raspbian kernel

[plugwash]

Just thought i'd let you guys know that I have succesfully modified the debian "linux-2.6" source package to build a Pi kernel and I have successfully booted the resulting kernel.

There is still some stuff to be done before I can upload to the repo but an upload should hopefully happen in the next day or so. I also hope to build a qemu kernel from the same source package.

BTW the rpi patch used to build this kernel is based on diffing bootc's 3.2.18 tree against plain 3.2.18 from kernel.org. I then added the resutling patch to the debian kernel packaging (so it is applied on top of the debian patches).

[mpthompson]

plugwash, this is terrific news. By maintaining our own kernel package, we'll be able to configure the kernel to be more Debian-like with the enabled features, track bugs against a known base kernel, and have kernel header packages that mirror the kernel binary package to aid building driver modules and such. The installer can also be improved as well. Having Raspbian continue to use a separate kernel was problematic in all these regards.

It would be useful if the Debian Wheezy armel image that is coming up could use this same package as it would help both Debian and Raspbian share efforts to refine the kernel package.

BTW, I noticed that Debian Wheezy just moved up to kernel 3.2.19. Not sure if the goal is to track the sub-versions so much or not.

[asb]

It would be useful if the Debian Wheezy armel image that is coming up could use this same package as it would help both Debian and Raspbian share efforts to refine the kernel package.

BTW, I noticed that Debian Wheezy just moved up to kernel 3.2.19. Not sure if the goal is to track the sub-versions so much or not.

bootc has moved to 3.2.19 now too. I'm not convinced now is the right time to move to 3.2.x for the armel image, even though I love the idea of having a kernel with the standard Debian kernel packaging. 3.1.x at github.com/raspberrypi/linux matches what is used internally at Broadcom and is still the "officicially supported" kernel.

[bob_binz]

Out of curiosity, I've downloaded the bootc source tree with the hope of building a new kernel, but oldconfig is asking me for physical memory offset (CONFIG_PHYS_OFFSET.) I don't recall setting this value before - where would I find what this needs to be? Or, can I remove it and if so, how? Unsure at editing .config directly.

[plugwash]

I just used bootc's config as a base but i'm not sure how I got it (I think it was extracted from his deb package but I don't remember for sure).

But anyway I took a look at it and I don't seem to have that option in it.

Are you sure you are using his rpi 3.2.<whatever> branch? IIRC the default branch in his github repo is not Pi related and some of the other branches are for things that aren't ready yet.

[bob_binz]

Thanks for replying plugwash.

I pulled the source from https://github.com/bootc/linux/tree/rpi-3.2.19, which I assumed was Raspi specific. I then used my .config from the current raspberrybi source tree. It was the first question to be asked after ARM_PATCH_PHYS_VIRT :

Code: Select all

[email protected]:~/nfsexport/linux-3.2.19-bootc$ make ARCH=arm CROSS_COMPILE=/usr/bin/arm-linux-gnueabi- oldconfig
scripts/kconfig/conf --oldconfig Kconfig
*
* Restart config...
*
*
* Linux/arm 3.4.0-rc2 Kernel Configuration
*
Patch physical to virtual translations at runtime (ARM_PATCH_PHYS_VIRT) [N/y/?] n
Physical address of main memory (PHYS_OFFSET) [] (NEW) 

Anyway, setting it to 0x0 results in a non-booting kernel (unsurprisingly I suppose.) Ok, will nosey around some more, or maybe pull bootc's .config as you did.

EDIT: Ok, your comment about the default branch being non-rpi specific seems key - I wasn't specifying the branch (although I assumed git clone pulled all branches?) So I'm currently trying:

Code: Select all

git clone -b rpi-3.2.19 https://github.com/bootc/linux.git linux-3.2.19-bootc

TODO: learn git properly!!

[bob_binz]

Just an update - checking out the correct branch (D'oh) works, so thanks again for the pointers plugwash

[marsman2020]

It looks like bootc is moving right along with new kernels - http://www.bootc.net/projects/raspberry-pi-kernel/

A (probably silly, because git hurts my brain) question - by pulling in bootc's changes, are you also getting all the changes from the official raspberrypi/linux branch as well at the same time? Or does that depend on if bootc has pulled them into his branch yet or no.

[chrisw2]

Hi Plugwash,

That is excellent news.

Could you clarify if your kernel package will be built with a configuration from debian or the cut down version used by the Raspberry Pi kernel. ie: will it include an wider range of built in support. My particular interest is support for iptables & scsii tape.

Thanks.

[plugwash]

Currently i'm using a slightly modified version of configuration bootc uses, i'm not sure exactly how stripped down it is.

At some point I will need to compare it to the configs debian use and build system.

OOI why are you interested in SCSI tape?

[louisb]

If you have not seen this topic yet there are some interesting kernel patches being evaluated which result in at least a doubling of the SD card read speed. See http://www.raspberrypi.org/phpBB3/viewt ... 578#p98578

Looks very promising and hopefully it will eventually speed up all our rpi with Raspbian.

[chrisw2]

...
OOI why are you interested in SCSI tape?

One of my plans for the Pi is to use it as a bacula storage server with 1) a large USB hard disk and 2) a USB to SCSI adaptor to connect the DLT. 1) is currently implemented on a NSLU2 running debian and 2) is currently attached to my MythTV backend machine (not ideal). The bacula director & database sits on another machine.

[marsman2020]

If you have not seen this topic yet there are some interesting kernel patches being evaluated which result in at least a doubling of the SD card read speed. See http://www.raspberrypi.org/phpBB3/viewt ... 578#p98578

Looks very promising and hopefully it will eventually speed up all our rpi with Raspbian.

Looks like those SD card patches have been pulled into the github kernel, and bootc is looking at getting them into his 3.2 kernel.

I've accepted lb's pull request, and rebuilt the firmware in github, and updated Hexxeh's repo.
An rpi-update should now give you improved sdcard speed. init_emmc_clock now defaults to 50Mhz, so config.txt entry is not required.

Please update and report back on success or failures.

Yay!

The pace at which things are being worked out is pretty awesome. Now if only we could fix the USB issues.

[plugwash]

Just to give you a progress update on the raspbian kernel packaging i'm currently trying to sort out a workaround for dpkg's inability to upgrade stuff on fat filesystems.

[ScoobyDoo]

Will the SD patches that have been put into the 3.2 kernel of debian be updated for raspbian via rpi-update ?

[plugwash]

Last I checked rpi-update was still pulling down a 3.1 kernel provided by the foundation, I dunno what exactly goes into this kernel because I wasn't involved in making it but from doms posts above it should contain the SD card patch.

Long term the aim for both debian and raspbian images is to phase out rpi-update and replace it with properly packaged kernels/firmware/libraries. This may take a while though.

[marsman2020]

What would the best method be for me to use bootc's 3.2.19 kernel with Raspbian?

I'd like to play with the I2C and SPI drivers.

Can I just install the .deb that he has provided at http://www.bootc.net/projects/raspberry-pi-kernel/?

[eppe]

The currently missing nfs kernel server module would be great too.

[chrisw2]

The currently missing nfs kernel server module would be great too.

Another vote for this, please.

[plugwash]

When asking for features can you please tell me the exact options you want setting in the kernel configuration.

Thanks

[chrisw2]

When asking for features can you please tell me the exact options you want setting in the kernel configuration.

Thanks

Serious question:
Is there any reason not to go with: "the same options that are configured in the kernel from the debian armel repository"?

[plugwash]

Can you clarify exactly what you mean by "the same options that are configured in the kernel from the debian armel repository", debian does not build a Pi kernel. Do you mean the kernel debian builds for some other arm system? (i've considered doing that but it's potentially a lot of work to figure out what should and shouldn't be carried over to a Pi kernel). Do you mean the kernel the foundation are packaging for their wheezy releases?

[chrisw2]

Can you clarify exactly what you mean by "the same options that are configured in the kernel from the debian armel repository", debian does not build a Pi kernel. Do you mean the kernel debian builds for some other arm system? (i've considered doing that but it's potentially a lot of work to figure out what should and shouldn't be carried over to a Pi kernel). Do you mean the kernel the foundation are packaging for their wheezy releases?

I mean "the kernel debian builds for some other arm system"

I have no expertise in kernel compilation (although I have done it in the past) but my reasoning was that a stock debian armel kernel from the official debian repositry installed, for instance, on an NSLU2 seems to include a lot of the things asked for in this thread (eg: iptables. NFS kernel server). I, perhaps foolishly, thought it would be easier to add the Raspberry Pi specific stuff to that, than to start with the cut down foundation kernel and add stuff to it as people gradually discover exactly what is missing over a period of time.

Otherwise I guess I'll have to start trying to figure out the kernel config options required for iptables, NFS kernel server etc with a good chance of getting it wrong.

I hope you see what I'm getting at

[chrisw2]

in continuation...

Please excuse me if these are stupid questions but...

You seem to be assuming that some bits of the debian armel configuration won't be able to be carried over to a Pi kernel. Why do you make this assumption?

Or to put it another way:
Do we know why the foundation used a cut down kernel configuration? To save space? Or because they had reason to believe a kernel built with the configuration used by debians armel + the Pi bits would cause problems?

Or to put it yet another way:
I understand the Pi needs extra (Pi specific) bits adding to the kernel but is there any reason to believe the Pi is so different from any other arm processor that some kernel options in debians armel configuration will not work on the Pi?

[SirLagz]

Why not just roll your own kernel with the features you need if you already know how to do it ?
According to the latest guide at elinux.org, all you need is the kernel source from git, then get the config from the running kernel, then you can start slapping your own things on and then can boot from that.

That's what I'm attempting to do now to make my RaspCam work...

Edit - It helps if I read correctly....
I can roll a kernel for NFS / IPTables for anyone who's interested in one.
If you can specify a kernel base for what you want, I'll roll one up, e.g. bootc or RPi stock.