Re: Detecting XO-1.5 in kernel boot
On 9/21/2010 7:24 AM, Andres Salomon wrote: > On Tue, 21 Sep 2010 06:35:48 -1000 > Mitch Bradley wrote: > > ... >> You could get all the information from the device tree, after having >> first checked for the presence of the device tree by looking for the >> relevant "files". "/ofw/architecture", for example, contains >> "OLPC\0". The "/ofw" may turn into "/proc/something" or something >> else once Andres finishes, so it's probably a good idea to bury that >> prefix in a subroutine somewhere. >> >>> Thanks, >>> Daniel > > Right, so there's shiny new code in arch/x86/kernel/olpc_ofw.c that > checks for the OFW signature in the boot page signature, and > sets up OFW for calling into. This is done very early in boot > (during setup_arch, so before any of the initcall stuff happens), and > would make a much better detection scheme than the VSA2 check.. > > if (!ofw_installed()) > return; At this point it would be a good idea to look in /ofw/architecture for the "OLPC\0" string. There are a couple of other systems that use OFW on x86 (embedded computers from an Italian company named DAVE). > spin_lock_init(&ec_lock); > /* don't bother with the rom signature check */ > olpc_platform_info.flags |= OLPC_F_PRESENT; > > platform_detect(); > > ... > > if (!olpc_board_at_least(olpc_board(0xc3))&& !cs5535_has_vsa2()) > x86_init.pci.arch_init = pci_olpc_init; > > > > Note that this scheme would make the OLPC stuff _very_ dependent upon a > fully functional OFW, but I don't really see that as a problem. > > Oh, I wanted to chat with you and pgf about the 1.5 olpc_board() stuff > with you at some point, but I'd like to get the dcon 1.0 stuff finished > up first. > ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Detecting XO-1.5 in kernel boot
On 09/21/2010 12:35 PM, Mitch Bradley wrote: > On 9/21/2010 6:15 AM, Daniel Drake wrote: >> One idea: check the DMI info, look for the OLPC XO-1.5 >> manufacturer/product codes. >> >> Others? > > You could get all the information from the device tree, after having first > checked for the presence of the device tree > by looking for the relevant "files". "/ofw/architecture", for example, > contains "OLPC\0". The "/ofw" may turn into > "/proc/something" or something else once Andres finishes, so it's probably a > good idea to bury that prefix in a > subroutine somewhere. The device tree is the Right Way to do this. Thats what its designed for and we should encourage its use. Another possible way would be for OFW to pass the model in on the kernel command line. That involves a /boot/olpc.fth change but OLPC shipped kernels could include a fall back check for older setups. -- Richard A. Smith One Laptop per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Detecting XO-1.5 in kernel boot
On Tue, 21 Sep 2010 06:35:48 -1000 Mitch Bradley wrote: > > On 9/21/2010 6:15 AM, Daniel Drake wrote: > > I'm working on XO-1.5 support upstream and would appreciate comments > > on the following: > > > > > > > > The very core "am I an XO?" check that runs during boot is this: > > > > http://lxr.free-electrons.com/source/arch/x86/kernel/olpc.c#L212 > > > > It runs ioremap() on 0xffc0 and expects to read the OFW > > signature "CL1 Q" > > > > If we pass the check, we then go on to call into OFW to read the > > board revision, etc. > > > > We're talking upstream kernel here, so this would normally run on > > every kernel (i.e. all the distro kernels) that compile with OLPC > > support. According to comments in the file, the check is dangerous, > > so we cut down where it is run, bailing out early: > > > > /* The ioremap check is dangerous; limit what we run it on > > */ if (!is_geode() || cs5535_has_vsa2()) > > return 0; > > > > > > This needs an update for XO-1.5, where we want this code to run, but > > we aren't a geode or cs5535. > > How should we update the check? > > > > One idea: check the DMI info, look for the OLPC XO-1.5 > > manufacturer/product codes. > > > > Others? > > You could get all the information from the device tree, after having > first checked for the presence of the device tree by looking for the > relevant "files". "/ofw/architecture", for example, contains > "OLPC\0". The "/ofw" may turn into "/proc/something" or something > else once Andres finishes, so it's probably a good idea to bury that > prefix in a subroutine somewhere. > > > Thanks, > > Daniel Right, so there's shiny new code in arch/x86/kernel/olpc_ofw.c that checks for the OFW signature in the boot page signature, and sets up OFW for calling into. This is done very early in boot (during setup_arch, so before any of the initcall stuff happens), and would make a much better detection scheme than the VSA2 check.. if (!ofw_installed()) return; spin_lock_init(&ec_lock); /* don't bother with the rom signature check */ olpc_platform_info.flags |= OLPC_F_PRESENT; platform_detect(); ... if (!olpc_board_at_least(olpc_board(0xc3)) && !cs5535_has_vsa2()) x86_init.pci.arch_init = pci_olpc_init; Note that this scheme would make the OLPC stuff _very_ dependent upon a fully functional OFW, but I don't really see that as a problem. Oh, I wanted to chat with you and pgf about the 1.5 olpc_board() stuff with you at some point, but I'd like to get the dcon 1.0 stuff finished up first. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Detecting XO-1.5 in kernel boot
On 9/21/2010 6:15 AM, Daniel Drake wrote: > I'm working on XO-1.5 support upstream and would appreciate comments > on the following: > > > > The very core "am I an XO?" check that runs during boot is this: > > http://lxr.free-electrons.com/source/arch/x86/kernel/olpc.c#L212 > > It runs ioremap() on 0xffc0 and expects to read the OFW signature "CL1 > Q" > > If we pass the check, we then go on to call into OFW to read the board > revision, etc. > > We're talking upstream kernel here, so this would normally run on > every kernel (i.e. all the distro kernels) that compile with OLPC > support. According to comments in the file, the check is dangerous, so > we cut down where it is run, bailing out early: > > /* The ioremap check is dangerous; limit what we run it on */ > if (!is_geode() || cs5535_has_vsa2()) > return 0; > > > This needs an update for XO-1.5, where we want this code to run, but > we aren't a geode or cs5535. > How should we update the check? > > One idea: check the DMI info, look for the OLPC XO-1.5 > manufacturer/product codes. > > Others? You could get all the information from the device tree, after having first checked for the presence of the device tree by looking for the relevant "files". "/ofw/architecture", for example, contains "OLPC\0". The "/ofw" may turn into "/proc/something" or something else once Andres finishes, so it's probably a good idea to bury that prefix in a subroutine somewhere. > Thanks, > Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Detecting XO-1.5 in kernel boot
I'm working on XO-1.5 support upstream and would appreciate comments on the following: The very core "am I an XO?" check that runs during boot is this: http://lxr.free-electrons.com/source/arch/x86/kernel/olpc.c#L212 It runs ioremap() on 0xffc0 and expects to read the OFW signature "CL1 Q" If we pass the check, we then go on to call into OFW to read the board revision, etc. We're talking upstream kernel here, so this would normally run on every kernel (i.e. all the distro kernels) that compile with OLPC support. According to comments in the file, the check is dangerous, so we cut down where it is run, bailing out early: /* The ioremap check is dangerous; limit what we run it on */ if (!is_geode() || cs5535_has_vsa2()) return 0; This needs an update for XO-1.5, where we want this code to run, but we aren't a geode or cs5535. How should we update the check? One idea: check the DMI info, look for the OLPC XO-1.5 manufacturer/product codes. Others? Thanks, Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
