| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Fri, 12 Jun 2009 17:05:04 +0200 From: Pavel Machek <pavel@....cz> To: Brian Swetland <swetland@...gle.com> Cc: Russell King - ARM Linux <linux@....linux.org.uk>, kernel list <linux-kernel@...r.kernel.org>, linux-arm-kernel <linux-arm-kernel@...ts.arm.linux.org.uk>, san@...roid.com, rlove@...gle.com, Greg KH <greg@...ah.com> Subject: Re: HTC Dream aka. t-mobile g1 support On Thu 2009-06-11 01:48:57, Brian Swetland wrote: > On Thu, Jun 11, 2009 at 1:25 AM, Pavel Machek<pavel@....cz> wrote: > > On Wed 2009-06-10 14:55:52, Brian Swetland wrote: > >> I'm not sure the smd (shared memory driver / virtual serial channels) > >> that everything else depends on makes sense outside of mach-msm, given > >> it's all very specific to the baseband and firmware that runs on it. > > > > Well, it is still a driver for your baseband chip, right? > > Yes -- what I meant is more "does it belong under arch/arm/mach-msm/" > (given that it's very specific to that architecture and unlikely to > ever be useful elsewhere) or "does it belong somewhere else" (because > it's a pretty big pile of code compared to other stuff like > gpio/interrupt/etc stuff that tends to live under arch/arm/mach-*/). If it is driver for baseband, then it could live outside mach-msm, right? > > ...drivers/staging is _not_ final place for your code. When the code > > is good enough, it should move. But it is place where stuff like TI > > wifi driver would be acceptable. > > Interesting -- reading up more on staging now. I know that Greg KH > has been pulling some of the "generic" android drivers into staging > (Thanks, Greg!), but hadn't really looked at the rationale behind > staging in general. staging is for GPLed code that needs to be cleaned up, first. Horrible stuff like drivers for windows in windows coding style go there. > Sounds like packing up the serial, sdio, nand, framebuffer, etc > drivers for submission into staging might make sense. We can do the > obvious stuff like make sure they're checkpatch clean and reasonably > tidy first. Actually, I believe it would be better to submit them first and checkpatch later. I quickly went through the patches (122KLoC)... and most are pretty much okay, but some have issues bigger than coding style (like wrong userland interfaces). > In order to actually have the peripherals work, though, we'd need to > add to board-*.c, devices.c, etc so that the platform devices are > defined so the platform drivers (which almost all of these are) are > actually probed. Well, applying smaller patch is better than applying big patch... > >> Basically there's a stack: > >> > >> smsm -- "shared memory state machine" (used for power collapse coordination) > >> smd -- "shared memory driver" (virtual serial channels, 8k bidirectional fifos) > >> rpcrouter/oncrpc -- rpc transport layer used for audio, audio > >>routing, etc What is htc_pwrsink infrastructure? Some kind of power accounting infrastructure for better battery estimates? > >> These are linux implementations of protocols the baseband speaks. > >> > >> Other stuff then stacks on smd (rmnet -- virtual ethernet, at control > >> channels, etc) and oncrpc (dsp control, rtc, gps, some media control). I see stuff like jpeg and mp3 coprocessors. That's oncrpc? > > Is it all neccessary for boot? Getting it booting with display should > > be the first goal... GPS/RTC/... can come later. > > The lowest layer IPC (proc_comm) is used for clock/power control and > is already in mainline, and that gets the clk_* framework functional > and allows most of the peripheral drivers to work, thankfully. Things > like the serial driver, framebuffer, sdio, nand controller, etc all > should be happy without additional core architecture support. Good, with framebuffer+nand we have "usable" machine, right? Can someone apply this? --- Improve documentation, add machine description to Kconfig, remove misleading comment. Signed-off-by: Pavel Machek <pavel@....cz> diff --git a/Documentation/android.txt b/Documentation/android.txt index 72a62af..15922d6 100644 --- a/Documentation/android.txt +++ b/Documentation/android.txt @@ -14,6 +14,12 @@ CONTENTS: 1.3 Recommended enabled config options 2. Contact +0. Getting sources: +----------------- + +git clone --reference /path/to/linux-git/for/speedup/ git://android.git.kernel.org/kernel/msm.git +git checkout -b android-msm-2.6.29 origin/android-msm-2.6.29 + 1. Android ========== @@ -26,6 +32,7 @@ To see a working defconfig look at msm_defconfig or goldfish_defconfig which can be found at http://android.git.kernel.org in kernel/common.git and kernel/msm.git +msm_defconfig should work on qualcomm reference design, HTC Magic and G1/ADP1. 1.1 Required enabled config options ----------------------------------- @@ -114,6 +121,22 @@ SERIAL_CORE SERIAL_CORE_CONSOLE +Board code names +---------------- + +board-halibut is a qualcomm reference design. board-sapphire is HTC +Magic. board-trout is HTC Dream/G1/ADP1. + +Booting your kernel +------------------- + +hold down camera and red button to boot into rainbow screen. Then + +./fastboot boot linux-msm/arch/arm/boot/zImage ramdisk.img + +Machine will freeze at rainbow screen for a while, be +patient. ramdisk.img is required. + 2. Contact ========== website: http://android.git.kernel.org diff --git a/arch/arm/mach-msm/Kconfig b/arch/arm/mach-msm/Kconfig index 310caeb..478d20a 100644 --- a/arch/arm/mach-msm/Kconfig +++ b/arch/arm/mach-msm/Kconfig @@ -62,7 +62,9 @@ config MACH_HALIBUT config MACH_TROUT depends on ARCH_MSM default y - bool "Trout" + bool "Trout (HTC Dream, T-Mobile G1, Google ADP1)" + help + Select this to support HTC Dream, T-Mobile G1, Google ADP1. config MACH_SAPPHIRE depends on ARCH_MSM diff --git a/include/linux/usb/mass_storage_function.h b/include/linux/usb/mass_storage_function.h index 75ebce0..73cf1d4 100644 --- a/include/linux/usb/mass_storage_function.h +++ b/include/linux/usb/mass_storage_function.h @@ -1,5 +1,4 @@ /* - * Switch class driver * * Copyright (C) 2008 Google, Inc. * Author: Mike Lockwood <lockwood@...roid.com> -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists