Re: [PATCH] atari_keyb_init fix for my CT60
On Mon, 14 Jul 2008, Michael Schmitz wrote:
> > > I'd like to see another patch - the correction of operator precedence in
> > > atari_keyb_init which I reported yesterday to linux-m68k. The patch will
> > > be forthcoming shortly.
> >
> > Sorry folks, I will fly to Montreal tomorrow morning and I am swamped at the
> > University, I don't think I can submit those patches _and_ test them. Does
> > anybody else have access to the debian-kernel svn?
>
> Not that I know of - we'll just postpone that one for now. I'll have a couple
> more upcoming in the next days anyway (ethernec performance in 2.6.26-rc8
> seems a bit dodgy, and ethernat was missing outright).
>
> Just for the record (and of course for Geert to include in future 2.6 series):
Queued for the fast track to 2.6.27.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [buildd] chroot updates
Hi, So perl 5.10 has hit incoming/buildd. All the chroots need to be updated. The trick is to replace debconf-i18n with debconf-english. After that you can basically purge all of perl. Then perl-base will upgrade. Hobbes is done with gcc-4.3, I'll try upgrading perl now. Looks like it works fine (I had already replaced debconf-i18n by debconf-english). After that we've got a ton of perl packages and dependencies to buildd. I'm off to set all my buildds n-d-p. Hobbes should be back soon - pity I blew most of my monthly data allowance on the meeting streams :-) Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Unstable synced to debian port
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 aurel32 has finished syncing our unstable to Debian ports. If you run a buildd, please point it to upload there, as well as use debian-ports.org as your buildd server. Stephen: Please add the buildd keys to the buildd_m68k account. Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: http://getfiregpg.org iEYEARECAAYFAki7fGMACgkQpblTBJ2i2puNSgCdEwTacIMORQep3ubAzzUX4EIi 45gAn0MoVUe+d+BkD/fZZSg2kBtiBVfY =D0Xm -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Coldfire Boards
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'm just curious on who got what. I know Stephen gave me his board, but I'm curious to know which boards went where. Anyway, here are a couple of my bootstrapping notes. 1. Coldfire m68k IGNORES command line args, they're hardcoded. If you want to change it, you need to change the hardcoding. Its a configuration option. 2. Bug in usbcore prevents the detection of mountable harddrives. No matter what USB device I had plugged in, while the device itself was detected, it doesn't find any paritions. It looks like this may be an issues with the m68k SCSI handling code. 3. Possible initramfs bug - it always panics for me trying to execute /init. Can't confirm if this a legit bug, or a toolchain/user issue at this time. 4. The board has two flash chips, which may throw some people through a loop since Linux only sees one. There is a 2MB flash, address range: 0xFF80->0xFF9F dBUG and LogicLoader live on this chip. dBug is at 0xFF9F as far as I can tell. The main 16MB flash is on address range 0xE000->0xE0FF There is a kernel configuration option on this, make sure you give it the right starting range, or else the MTD device will point to the wrong flash chip and quite possible brick your device. 5. It is possible to boot a kernel from dBUG directly since the kernel will load and execute at entry point 0x20. just dn -i the image, then use go to jump to the execution point. BSP packages will configure the kernel to output on the right serial port. 6. BSP doesn't support cross-building the toolchain (not surprising, since cross-building GCC is more of an art than a science). 7. Unlike most other CF boards, I can't find anything in the specs that can change the load location of the IPL (most other CF boards have the ability via a jumper to load to the halfway point in the first flash chip), so if you want to replace dBUG with u-boot, you have to write over it. Don't try this without JTAG access or confirming the BDM module works! (for those of us with BDM modules) 8. My current technique is to write a JFFS2 filesystem to the second flashchip, and then get linux to use /dev/mtdblock0 as its root parition. Not ideal, but without replacing dBUG, and properly parationing the second flash chip, its the best I got. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: http://getfiregpg.org iEYEARECAAYFAki7krcACgkQpblTBJ2i2psQYwCfaQMrY2X34ZvWP4nitEc7cnBG n28AoJiwkx31ob+bFUzY3UuYBCojbnJw =M036 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
