I have added some changes to the decompression options. All work on abuild, little or no testing has been possible. It's really just some renames.
Here goes:
CONFIG_PRECOMPRESSED_ROM_STREAM means that linuxbios need not run any programs in the makefiles to compress the rom stream. The rom stream is already compressed; linuxbios needs to include code to uncompress it properly. It is an error to set this variable, and not set one of the variables mentioned below; this error is only caught at compile time (Sorry! This is called "Why we need to change the Config system". )
CONFIG_COMPRESSED_ROM_STREAM now means that the rom stream is nrv2b compressed. This name is deprecated, I have tried to remove every usage of it in the tree, and this name WILL GO AWAY soon.
CONFIG_COMPRESSED_ROM_STREAM_NRV2B now means that the rom stream is nrv2b compressed. If CONFIG_PRECOMPRESSED_ROM_STREAM is not set, the makefile will try to run nrv2b on the file.
CONFIG_COMPRESSED_ROM_STREAM_LZMA now means that the rom stream is lzma compressed. The lzma uncompresser is not tested.If CONFIG_PRECOMPRESSED_ROM_STREAM is not set, the makefile will try to run lzma on the file.
I have tested all combinations of these options in a build, and they all properly build a linuxbios rom image. I have not yet tested them on a board, but almost no targets use them; I hope not to cause trouble.
Also, due to other issues, I have moved the destination of all decompressers to the 16 MB boundary. This Is A Hack. But, the other way (at the end of linuxbios, usually 2M) ran into trouble on OLPC and would have run into trouble on other systems. We need streaming decompressers.
It is an error to: set CONFIG_PRECOMPRESSED_ROM_STREAM and not set one of the others, or to set more than one of CONFIG_COMPRESSED_ROM_STREAM, CONFIG_COMPRESSED_ROM_STREAM_NRV2B, or CONFIG_COMPRESSED_ROM_STREAM_LZMA. This error is only caught at compile time. Again, sorry.
All this builds. Few platforms save OLPC use it. I doubt this change will break much if anything.
thanks
ron
I've tested the new changes in NRV2B and LZMA mode and they work on OLPC. In fact, on OLPC, it gets the kernel/initrd to 666K!
thanks
ron
I wonder if you can change CONFIG_COMPRESSED_ROM_STREAM to 0: no compress 1: NRV2B 2: LZMA 3: ...
YH
On 9/14/06, ron minnich rminnich@gmail.com wrote:
I've tested the new changes in NRV2B and LZMA mode and they work on OLPC. In fact, on OLPC, it gets the kernel/initrd to 666K!
thanks
ron
-- linuxbios mailing list linuxbios@linuxbios.org http://www.openbios.org/mailman/listinfo/linuxbios
yhlu wrote:
I wonder if you can change CONFIG_COMPRESSED_ROM_STREAM to 0: no compress 1: NRV2B 2: LZMA 3: ...
I tested this idea against several users and they really hated it.
ron
* Ronald G Minnich rminnich@lanl.gov [060915 16:44]:
yhlu wrote:
I wonder if you can change CONFIG_COMPRESSED_ROM_STREAM to 0: no compress 1: NRV2B 2: LZMA 3: ...
I tested this idea against several users and they really hated it.
weird. What were their reasons?
Giving it a glimpse it seems rather natural if you have a choice between X algorithms. So we prefer "wider" configuration instead of "deeper" configuration?
What makes "deeper configuration" really unlovable is that the current configuration tool can not represent the above.
What makes it adorable is that the dependencies between the config variables can not or are not resolved during configuration time now, but during run time.
So a configuration mistake does not lead to a configuration error, but to a compile error.
I know "go ahead and fix it" is the deserved answer, but this is something we want to discuss in more detail for v3
Stefan
I tested this idea against several users and they really hated it.
weird. What were their reasons?
I was against it because I don't see it as discoverable or self documenting.
Looking at the config file
COMPRESS= [0,1,2,3] dosen't mean much.
I suppose if you could abstract that to all symbolics such that
CONFIG_COMPRESS=[NONE,LZMA, NRV2B]
Then that would be better.
I really don't like how vague our config options are. I am IMed by people all the time asking me what config option such and such does. I have to go grep through the code to figure it all out since I can't keep them straight myself.
If we could just make those option _say_ what they are doing then its much better off in the long run. Much more discoverable
So if we can make =[foo,man,chu] really mean something and be discoverable then I'm all for it.
Richard Smith wrote:
I really don't like how vague our config options are. I am IMed by people all the time asking me what config option such and such does. I have to go grep through the code to figure it all out since I can't keep them straight myself.
if you're grepping code you're in the wrong place. The src/config/Options.lb REQUIRES a comment describing the option. There are 150 options -- there are 1700+ in linux.
I am attaching the result of egrep define|comment src/config/options.lb to this message. What should we be doing better? I'm open to any ideas. Some of those comments are quite good, e.g. define CONFIG_SERIAL_POST comment "Enable SERIAL POST codes"
Although the definition needs some work ...
but this one: define MEMORY_HOLE comment "Set to deal with memory hole"
wins the WTF prize, I suppose.
Unless we count this: define ROM_IMAGE_SIZE comment "Default image size" define ROM_SECTION_SIZE comment "Default rom section size"
eh? What's a section? I think ranchers measure land in sections ...
I think it's the lousy config interface. If we had something like kconfig, and a <help> button, and (in some cases) better comments, I think it would be better.
Another really bad aspect is the various names of sizes of things that few people get, namely:
define FALLBACK_SIZE define ROM_SIZE define ROM_IMAGE_SIZE define ROM_SECTION_SIZE define PAYLOAD_SIZE
This stuff, in my view, sucks. I mean, ROM_IMAGE_SIZE? :-)
Here's one that ought to die: define CONFIG_CONSOLE_SROM comment "Log messages to SROM console" That's for the DEC Alpha!
I intend to fix the compression setting checks so it happens at config time. Beat on me if I don't do it soon.
thanks
ron
# Each option used by a part must be defined in # define <name> # comment "<string>" # (i.e. will remain undefined) unless it has # option is defined or set and the numeric result # A comment string must be supplied for every option. define ARCH comment "Default architecture is i386, options are alpha and ppc" define HAVE_MOVNTI comment "This cpu supports the MOVNTI directive" define CROSS_COMPILE comment "Cross compiler prefix" define CC comment "Target C Compiler" define HOSTCC comment "Host C Compiler" define CPU_OPT comment "Additional per-cpu CFLAGS" define OBJCOPY comment "Objcopy command" define LINUXBIOS_VERSION comment "LinuxBIOS version" define LINUXBIOS_EXTRA_VERSION comment "LinuxBIOS extra version" define LINUXBIOS_BUILD comment "Build date" define LINUXBIOS_COMPILE_TIME comment "Build time" define LINUXBIOS_COMPILE_BY comment "Who build this image" define LINUXBIOS_COMPILE_HOST comment "Build host" define LINUXBIOS_COMPILE_DOMAIN comment "Build domain name" define LINUXBIOS_COMPILER comment "Build compiler" define LINUXBIOS_LINKER comment "Build linker" define LINUXBIOS_ASSEMBLER comment "Build assembler" define CONFIG_CHIP_CONFIGURE comment "Use new chip_configure method for configuring (non-pci) devices" define CONFIG_USE_INIT comment "Use stage 1 initialization code" define HAVE_FALLBACK_BOOT comment "Set if fallback booting required" define USE_FALLBACK_IMAGE comment "Set to build a fallback image" define FALLBACK_SIZE comment "Default fallback image size" define ROM_SIZE comment "Size of your ROM" define ROM_IMAGE_SIZE comment "Default image size" define ROM_SECTION_SIZE comment "Default rom section size" define ROM_SECTION_OFFSET comment "Default rom section offset" define PAYLOAD_SIZE comment "Default payload size" define _ROMBASE comment "Base address of LinuxBIOS in ROM" define _ROMSTART comment "Start address of LinuxBIOS in ROM" define _RESET comment "Hardware reset vector address" define _EXCEPTION_VECTORS comment "Address of exception vector table" define STACK_SIZE comment "Default stack size" define HEAP_SIZE comment "Default heap size" define _RAMBASE comment "Base address of LinuxBIOS in RAM" define _RAMSTART comment "Start address of LinuxBIOS in RAM" define USE_DCACHE_RAM comment "Use data cache as temporary RAM if possible" define DCACHE_RAM_BASE comment "Base address of data cache when using it for temporary RAM" define DCACHE_RAM_SIZE comment "Size of data cache when using it for temporary RAM" define DCACHE_RAM_GLOBAL_VAR_SIZE comment "Size of region that for global variable of cache as ram stage" define XIP_ROM_BASE comment "Start address of area to cache during LinuxBIOS execution directly from ROM" define XIP_ROM_SIZE comment "Size of area to cache during LinuxBIOS execution directly from ROM" define CONFIG_COMPRESS comment "Set for compressed image" define CONFIG_UNCOMPRESSED comment "Set for uncompressed image" define CONFIG_LB_MEM_TOPK comment "Kilobytes of memory to initialized before executing code from RAM" define HAVE_OPTION_TABLE comment "Export CMOS option table" define USE_OPTION_TABLE comment "Use option table" define LB_CKS_RANGE_START comment "First CMOS byte to use for LinuxBIOS options" define LB_CKS_RANGE_END comment "Last CMOS byte to use for LinuxBIOS options" define LB_CKS_LOC comment "Pair of bytes to use for CMOS checksum" define CRT0 comment "Main initialization target" define DEBUG comment "Enable debugging code" define CONFIG_CONSOLE_VGA comment "Log messages to VGA" define CONFIG_CONSOLE_VGA_MULTI comment "Multi VGA console" define CONFIG_CONSOLE_VGA_ONBOARD_AT_FIRST comment "Use onboard VGA instead of add on VGA card" define CONFIG_CONSOLE_BTEXT comment "Log messages to btext fb console" define CONFIG_CONSOLE_LOGBUF comment "Log messages to buffer" define CONFIG_CONSOLE_SROM comment "Log messages to SROM console" define CONFIG_CONSOLE_SERIAL8250 comment "Log messages to 8250 uart based serial console" define DEFAULT_CONSOLE_LOGLEVEL comment "Console will log at this level unless changed" define MAXIMUM_CONSOLE_LOGLEVEL comment "Error messages up to this level can be printed" define CONFIG_SERIAL_POST comment "Enable SERIAL POST codes" define NO_POST comment "Disable POST codes" define TTYS0_BASE comment "Base address for 8250 uart for the serial console" define TTYS0_BAUD comment "Default baud rate for serial console" define TTYS0_DIV comment "Allow UART divisor to be set explicitly" define TTYS0_LCS comment "Default flow control settings for the 8250 serial console uart" define MAINBOARD comment "Mainboard name" define MAINBOARD_PART_NUMBER comment "Part number of mainboard" define MAINBOARD_VENDOR comment "Vendor of mainboard" define MAINBOARD_PCI_SUBSYSTEM_VENDOR_ID comment "PCI Vendor ID of mainboard manufacturer" define MAINBOARD_PCI_SUBSYSTEM_DEVICE_ID comment "PCI susbsystem device id assigned my mainboard manufacturer" define MAINBOARD_POWER_ON_AFTER_POWER_FAIL comment "Default power on after power fail setting" define CONFIG_SYS_CLK_FREQ comment "System clock frequency in MHz" define CONFIG_MAX_PCI_BUSES comment "Maximum number of PCI buses to search for devices" define CONFIG_SMP comment "Define if we support SMP" define CONFIG_MAX_CPUS comment "Maximum CPU count for this machine" define CONFIG_MAX_PHYSICAL_CPUS comment "Maximum physical CPU count for this machine" define CONFIG_LOGICAL_CPUS comment "Should multiple cpus per die be enabled?" define HAVE_MP_TABLE comment "Define to build an MP table" define SERIAL_CPU_INIT comment "Serialize CPU init" define APIC_ID_OFFSET comment "We need to share this value between cache_as_ram_auto.c and northbridge.c" define ENABLE_APIC_EXT_ID comment "Enable APIC ext id mode 8 bit" define LIFT_BSP_APIC_ID comment "decide if we lift bsp apic id while ap apic id" define CONFIG_IDE_STREAM comment "Boot from IDE device" define CONFIG_ROM_STREAM comment "Boot image is located in ROM" define CONFIG_ROM_STREAM_START comment "ROM stream start location" define CONFIG_COMPRESSED_ROM_STREAM comment "compressed boot image is located in ROM and is assumed to be NRV2B (deprecated)" define CONFIG_COMPRESSED_ROM_STREAM_NRV2B comment "NRV2B compressed boot image is located in ROM" define CONFIG_COMPRESSED_ROM_STREAM_LZMA comment "LZMA compressed boot image is located in ROM" define CONFIG_PRECOMPRESSED_ROM_STREAM comment "boot image is already compressed" define CONFIG_FS_STREAM comment "Boot from a filesystem" define CONFIG_FS_EXT2 comment "Enable ext2 filesystem support" define CONFIG_FS_ISO9660 comment "Enable ISO9660 filesystem support" define CONFIG_FS_FAT comment "Enable FAT filesystem support" define AUTOBOOT_DELAY comment "Delay (in seconds) before autobooting" define AUTOBOOT_CMDLINE comment "Default command line when autobooting" define USE_WATCHDOG_ON_BOOT comment "Use the watchdog on booting" define CONFIG_HYPERTRANSPORT_PLUGIN_SUPPORT comment "Enable support for plugin Hypertransport busses" define CONFIG_AGP_PLUGIN_SUPPORT comment "Enable support for plugin AGP busses" define CONFIG_CARDBUS_PLUGIN_SUPPORT comment "Enable support cardbus plugin cards" define CONFIG_PCIX_PLUGIN_SUPPORT comment "Enable support for plugin PCI-X busses" define CONFIG_PCIEXP_PLUGIN_SUPPORT comment "Enable support for plugin PCI-E busses" define HAVE_PIRQ_TABLE comment "Define if we have a PIRQ table" define IRQ_SLOT_COUNT comment "Number of IRQ slots" define CONFIG_PCIBIOS_IRQ comment "PCIBIOS IRQ support" define CONFIG_IOAPIC comment "IOAPIC support" define CONFIG_IDE comment "Define to include IDE support" define IDE_BOOT_DRIVE comment "Disk number of boot drive" define IDE_SWAB comment "Swap bytes when reading from IDE device" define IDE_OFFSET comment "Sector at which to start searching for boot image" define PCIC0_CFGADDR comment "Address of PCI Configuration Address Register" define PCIC0_CFGDATA comment "Address of PCI Configuration Data Register" define ISA_IO_BASE comment "Base address of PCI/ISA I/O address range" define ISA_MEM_BASE comment "Base address of PCI/ISA memory address range" define PNP_CFGADDR comment "PNP Configuration Address Register offset" define PNP_CFGDATA comment "PNP Configuration Data Register offset" define _IO_BASE comment "Base address of memory mapped I/O operations" define EMBEDDED_RAM_SIZE comment "Embedded boards generally have fixed RAM size" define CONFIG_CHIP_NAME comment "Compile in the chip name" define CONFIG_GDB_STUB comment "Compile in gdb stub support?" define HAVE_INIT_TIMER comment "Have a init_timer function" define HAVE_HARD_RESET comment "Have hard reset" define MEMORY_HOLE comment "Set to deal with memory hole" define MAX_REBOOT_CNT comment "Set maximum reboots" define CONFIG_TSC_X86RDTSC_CALIBRATE_WITH_TIMER2 comment "Use timer2 to callibrate the x86 time stamp counter" define INTEL_PPRO_MTRR comment "" define CONFIG_UDELAY_TSC comment "Implement udelay with the x86 time stamp counter" define CONFIG_UDELAY_IO comment "Implement udelay with x86 io registers" define FAKE_SPDROM comment "Use this to fake spd rom values" define HAVE_ACPI_TABLES comment "Define to build ACPI tables" define ACPI_SSDTX_NUM comment "extra ssdt num for PCI Device" define AGP_APERTURE_SIZE comment "AGP graphics virtual memory aperture size" define HT_CHAIN_UNITID_BASE comment "first hypertransport device's unitid base. if southbridge ht chain only has one ht device, it could be 0" define HT_CHAIN_END_UNITID_BASE comment "this will be unit id of the end of hypertransport chain (usually the real SB) if it is small than HT_CHAIN_UNITID_BASE, it could be 0" define SB_HT_CHAIN_UNITID_OFFSET_ONLY comment "this will decided if only offset SB hypertransport chain" define K8_SB_HT_CHAIN_ON_BUS0 comment "this will make SB hypertransport chain sit on bus 0, if it is 2 will put other chain on 0x40, 0x80, 0xc0" define K8_HW_MEM_HOLE_SIZEK comment "Opteron E0 later memory hole size in K, 0 mean disable" define K8_HW_MEM_HOLE_SIZE_AUTO_INC comment "Opteron E0 later memory hole size auto increase to avoid hole startk equal to basek" define K8_HT_FREQ_1G_SUPPORT comment "Optern E0 later could support 1G HT, but still depends MB design" define CONFIG_PCI_ROM_RUN comment "Init PCI device option rom" define CONFIG_PCI_64BIT_PREF_MEM comment "allow PCI device get 4G above Region as pref mem" define CONFIG_SANDPOINT_ALTIMUS comment "Configure Sandpoint with Altimus PMC" define CONFIG_SANDPOINT_TALUS comment "Configure Sandpoint with Talus PMC" define CONFIG_SANDPOINT_UNITY comment "Configure Sandpoint with Unity PMC" define CONFIG_SANDPOINT_VALIS comment "Configure Sandpoint with Valis PMC" define CONFIG_SANDPOINT_GYRUS comment "Configure Sandpoint with Gyrus PMC" define CONFIG_BRIQ_750FX comment "Configure briQ with PowerPC 750FX" define CONFIG_BRIQ_7400 comment "Configure briQ with PowerPC G4"
if you're grepping code you're in the wrong place. The src/config/Options.lb REQUIRES a comment describing the option. There are 150 options -- there are 1700+ in linux.
No offense but most of those comments are worthless.
One line of text _cannot_ accurately describe these options.
How is this option used? What the valid range of settings for this option? What is a sane defaut? If no sane default then how do you discover what it need to be? What are your tradeoffs? What platform is this option valid for? (cpu?,chipset?)
I'll even take the torch here. I'll offer to be the option documenter.
Richard Smith wrote:
if you're grepping code you're in the wrong place. The src/config/Options.lb REQUIRES a comment describing the option. There are 150 options -- there are 1700+ in linux.
Oh and how does said lay reader know to go find this list of helpful descriptions?
that's "this interface sucks" part.
ron
On 9/15/06, Richard Smith smithbone@gmail.com wrote:
if you're grepping code you're in the wrong place. The src/config/Options.lb REQUIRES a comment describing the option. There are 150 options -- there are 1700+ in linux.
And while I'm on a rant about config options. Let me further add that the build system is _way_ too noisy. I started to work on fixing this one weekend but got tripped up by needing to seperate out config options that can simply be included into a .h file and one that need to be evalulated by the shell.
I'll also take that on as an action it to fix. But I'd like to discuss it at conference frist. With V3 coming maybe its not worth the effort.
ok.. </RANT>
* Richard Smith smithbone@gmail.com [060915 18:19]:
And while I'm on a rant about config options. Let me further add that the build system is _way_ too noisy. I started to work on fixing this one weekend but got tripped up by needing to seperate out config options that can simply be included into a .h file and one that need to be evalulated by the shell.
I still believe those are not config options. Config == user sets it, not a shell script.
I'll also take that on as an action it to fix. But I'd like to discuss it at conference frist. With V3 coming maybe its not worth the effort.
Maybe it is the start for v3, but we want to discuss this some more, and maybe find a solution on the symposium, face to face.
one weekend but got tripped up by needing to seperate out config options that can simply be included into a .h file and one that need to be evalulated by the shell.
I still believe those are not config options. Config == user sets it, not a shell script.
I agree. The current system has them all in a big python list which gets pushed to the shell for eval. We need to break them apart.
Lots of items to discuss in Hamburg. I'm looking forward to it.
* Richard Smith smithbone@gmail.com [060915 18:05]:
if you're grepping code you're in the wrong place. The src/config/Options.lb REQUIRES a comment describing the option. There are 150 options -- there are 1700+ in linux.
Oh and how does said lay reader know to go find this list of helpful descriptions?
Its also hidden on the wiki somewhere. ;)
But you are right: It needs to be in context.
I am asked to change option X: What is option X, what does it depend on, what depends on it, ....
Stefan
* Richard Smith smithbone@gmail.com [060915 18:03]:
One line of text _cannot_ accurately describe these options.
YES! We need Linux Kconfig.
How is this option used? What the valid range of settings for this option? What is a sane defaut? If no sane default then how do you discover what it need to be? What are your tradeoffs?
What platform is this option valid for? (cpu?,chipset?)
more generically: What dependencies does this option have? Kconfig does this dependency stuff nicely.
The only thing I dont know how to include in Kconfig is the tree in Config.lb.
But I think the tree should stay in config.lb, as it is not a config option but a hardware description. The one that we use to create pirq, mptable, acpi completely automatically some day. </vision-mode>
On 9/15/06, Stefan Reinauer stepan@coresystems.de wrote:
- Richard Smith smithbone@gmail.com [060915 18:03]:
One line of text _cannot_ accurately describe these options.
YES! We need Linux Kconfig.
I remember many moons ago we talked about using Kconfig. And we chose not to. IIRC t the time Kconfig was seen as not being able to deal with our hardware tree structures. But that was a long time ago.
Every other embedded system setup I've used ( ie ptxdist,openwrt,busybox,buildroot..) all use some version of Kconfig (or buildroot which useds Kconfig). None of them however have the advanced config issues we have with our hardware trees. Perhpas we can extend Kconfig to suite our needs or re-write 'buildtarget' to work more like Kconfig.
It is a tough issue with non-trival solutions. But we know so much more now then we did then so hopefully we can come up with a good solution.
Perhaps you should add an Agenda Item.
"Config system. How do we fix?" V3 only?
Richard Smith wrote:
On 9/15/06, Stefan Reinauer stepan@coresystems.de wrote:
- Richard Smith smithbone@gmail.com [060915 18:03]:
One line of text _cannot_ accurately describe these options.
YES! We need Linux Kconfig.
I remember many moons ago we talked about using Kconfig. And we chose not to. IIRC t the time Kconfig was seen as not being able to deal with our hardware tree structures. But that was a long time ago.
The tricky part for me is still this. If I have four instances of X driver, there's no way I know of in kconfig to set different params for each instance. In kconfig, you say "I have an X", but you can't say, "this is another instance of X, but this time, turn OFF this feature". For example, take this: config 8139TOO_PIO bool "Use PIO instead of MMIO" default y depends on 8139TOO
You can't say "use PIO for instance 1 and don't use it for instance 2". That's not doable in Konfig. There's only one 8139TOO_PIO, and it applies to ALL instances of the 8139. But in our config, we can set that option differently for each and every part. And, we have to be able to do this.
Here's the subtlety. In our config system, when you enter and exit blocks, a new local symbol table is pushed and popped for that block. Option variables not yet in use can be used in that block. The symbols are hierarchical. That's why I can, for example, have lots of these: chip northbridge/amd/amdk8 with totally different settings for each one.
Any mod to the config system -- or new config system -- needs to take this into account. Settings for instances of a given part are not the same for all instances of that part -- they can't be, at the bios level. I don't think Linux Kconfig can accomodate that, but maybe it can. The Kconfig 'all variables global' rule seems to indicate it can't.
Again, in linux kconfig, all variables are global. In our config, they are not. (hence 'uses', which I well understand we all dislike).
It's funny to hear us arguing *for* global variables :-),but we are :-)
thanks ron
* Ronald G Minnich rminnich@lanl.gov [060915 18:55]:
The tricky part for me is still this. If I have four instances of X driver, there's no way I know of in kconfig to set different params for each instance. In kconfig, you say "I have an X", but you can't say, "this is another instance of X, but this time, turn OFF this feature". For example, take this: config 8139TOO_PIO bool "Use PIO instead of MMIO" default y depends on 8139TOO
You can't say "use PIO for instance 1 and don't use it for instance 2". That's not doable in Konfig.
And not in our current tool either. I believe we should go one step at a time.
We would now do 4 options if we want 4 instances. Similar as you did with the compression algorithm
chip northbridge/amd/amdk8 with totally different settings for each one.
This is a completely different quality of tuning than "set baud rate to 19200" imho.
Any mod to the config system -- or new config system -- needs to take this into account. Settings for instances of a given part are not the same for all instances of that part -- they can't be, at the bios level.
We want
a) Kconfig for configuration issues b) a tree parser for the rest.
Remember: the tree parser does not set config options as -DCONFIG_BAUD_RATE=19200 but it creates the static device tree: a couple of C files.
We mixed these two things in v2 and taring it apart is giving us a hard time now. But we should.
I don't think Linux Kconfig can accomodate that, but maybe it can. The Kconfig 'all variables global' rule seems to indicate it can't.
It can't. And it shouldnt.
It's funny to hear us arguing *for* global variables :-),but we are :-)
Because we have an incomplete picture of the tree.
Otherwise the Cache-As-Ram enable switch would be a property of the K8 nodes in the tree. the baud rate would be a property of the serial node which hangs off the superio which hangs off the south bridge.
More logical? Yes. Easier? Dunno.
Stefan Reinauer wrote:
- Ronald G Minnich rminnich@lanl.gov [060915 18:55]:
The tricky part for me is still this. If I have four instances of X driver, there's no way I know of in kconfig to set different params for each instance. In kconfig, you say "I have an X", but you can't say, "this is another instance of X, but this time, turn OFF this feature". For example, take this: config 8139TOO_PIO bool "Use PIO instead of MMIO" default y depends on 8139TOO
You can't say "use PIO for instance 1 and don't use it for instance 2". That's not doable in Konfig.
And not in our current tool either. I believe we should go one step at a time.
It is quite doable in the current tool -- you can configure two instances of an 8111 with different settings. Maybe I am missing your point.
We would now do 4 options if we want 4 instances. Similar as you did with the compression algorithm
That was what we wanted to avoid. But we can do it I guess. I think it's ugly.
a) Kconfig for configuration issues b) a tree parser for the rest.
Remember: the tree parser does not set config options as -DCONFIG_BAUD_RATE=19200 but it creates the static device tree: a couple of C files.
ok.
Otherwise the Cache-As-Ram enable switch would be a property of the K8 nodes in the tree.
no, cache-as-ram applies to 100% of mobos, right? I miss the point.
the baud rate would be a property of the serial node which hangs off the superio which hangs off the south bridge.
agree. ron
OK, I'd like to propose a challenge for the outcome of the linuxbios summit. I think this is doable. The challenge is simple.
Let's take the good ideas from all of you, and let's try to demonstrate a working, CAR-based, Kconfig-based, linuxbios tree for the ARUMA board (the one with 32 PCI busses). Let's just do the whole thing. I think we can do this. If we pull it off, then we've got our V3 layout done and can start migration.
Any takers?
ron
On Fri, Sep 15, 2006 at 06:56:36PM -0600, ron minnich wrote:
OK, I'd like to propose a challenge for the outcome of the linuxbios summit. I think this is doable. The challenge is simple.
Hehe, we're all eager. :)
Some of my thoughts, from the user's perspective:
* Ridiculous and error-prone to require commands in three dirs for a build. (Edit targets/foo/bar/Config.lb, run ./buildtarget foo/bar in targets and finally cd targets/foo/bar/baz to make.) (Deps fail on reconfig, I've gotten the wrong payload a couple of times causing annoying extra reboots/hotswaps/flashes.)
* Flash ROM size needs to affect one option, and one option only. Maybe even autodetect it for those building on the target. All other sizes can and MUST be derived from this value. Also: What about option ROMs? Should we aim to produce a ready-to-use lb-2.0-epia.rom and require a correct (how carefully do we check?) vgabios.rom in order to build with VGA support - or just dump a half- finished product in the user's lap and require them to finish the puzzle on their own? Licensing issues? Is "cat" considered "linking"?
* Any redundancy in the config/build process should be removed. I must not need to type the target name more than once. Brings me to..
* Global vs. local builds - pros/cons with kernel style (global) build (always produces arch/x/*Image) and LBv2 style build (produces target/x/y/z/linuxbios.rom for each target) Either way the config/build system must be consistently either global or local.
* Support for target variants? Same mobo with/without certain parts populated. Perhaps just sets of default options that can be pre-selected as a base config and then still allow user to change whatever they want. (Kconfig has just one variant per arch, right?)
..basically we want a system that is able to do very complex detailed configurations but that's also able to hide all the details behind "512KiB EPIA-MII 6000E without CF addon" (hypothetical example)
Some boards will require more from the user, but when possible a config and build should be dirt simple.
One idea is a kind of iterative config with increasing resolution per iteration. Novice users with a known-good board need only complete the first iteration: flash size, board name and board variant if any. Further iterations are optional and allow increasingly specific settings. Think fdisk normal/expert mode.
* Payload. I say something must be included in the LB tree or trivially added to a tree by download or command. FILO is candidate for inclusion. What's up with FILO(EB) and FILO(LB) ? Merge them? Make EB default payload? FILO? memtest86? All about making a usable product. memtest86 would have to be explicitly selected in expert mode in favor of the default option that would be able to load an OS. Doesn't matter much if it's only Linux right now because that's the most likely boot candidate for early LB adopters.
* Payload config. Long/tedious for EB, simple default for boards with onboard LAN, what to do otherwise? Tricky for FILO. (e.g. EPIA-MII CF boot requires IDE+!PCI, !PCI requires !USB or build fails) filesystems, devices, etc.
* Kernel payload and payload utilities - where to get mkelfImage? I had to look hard. Should it be downloaded on demand? Perhaps after the user chooses her payload? Think cygwin installer that downloads selected packages. Maybe a bad idea.
* Consistent terminology - the payload seems to have many names in the decompression code. ;)
Don't flame me too hard.
//Peter
Peter, these are all good thoughts, and I am really glad you are coming. Keep thinking. One thing:
On 9/15/06, Peter Stuge stuge-linuxbios@cdy.org wrote:
- Global vs. local builds - pros/cons with kernel style (global)
build (always produces arch/x/*Image) and LBv2 style build (produces target/x/y/z/linuxbios.rom for each target) Either way the config/build system must be consistently either global or local.
I want to preserve this somehow. I want a place I build stuff and a place that sources live, a la BSD. I think the way Linux builds kernels into the middle of the source tree is a real mess.
* Support for target variants? Same mobo with/without certain parts
populated. Perhaps just sets of default options that can be pre-selected as a base config and then still allow user to change whatever they want. (Kconfig has just one variant per arch, right?)
yes, kconfig has real limits, and we need to see if we can work our way around them.
ron
On Sat, Sep 16, 2006 at 06:08:10PM -0600, ron minnich wrote:
Peter, these are all good thoughts, and I am really glad you are coming. Keep thinking.
:)
It's going to be a couple of interesting days for sure!
- Global vs. local builds - pros/cons with kernel style (global)
build (always produces arch/x/*Image) and LBv2 style build (produces target/x/y/z/linuxbios.rom for each target) Either way the config/build system must be consistently either global or local.
I want to preserve this somehow. I want a place I build stuff and a place that sources live, a la BSD. I think the way Linux builds kernels into the middle of the source tree is a real mess.
Fair enough. But does the build directory have to be per-target or would you be OK with fixing the build directory to e.g. build/ right next to src/ ?
What I like about the Linux build is that there's only ever one dir that you "make" in, and when make is done it always produces arch/*/boot/bzImage.
The current structure could be simple too, if the buildtarget step could be skipped, and there was no need for via/epia-m/epia-m but only via/epia-m, and that's where you go to make config && make to get a linuxbios.rom.
- Support for target variants? Same mobo with/without certain parts
populated. Perhaps just sets of default options that can be pre-selected as a base config and then still allow user to change whatever they want. (Kconfig has just one variant per arch, right?)
yes, kconfig has real limits, and we need to see if we can work our way around them.
Or maybe we'll extend it?
//Peter
* Peter Stuge stuge-linuxbios@cdy.org [060917 02:37]:
Fair enough. But does the build directory have to be per-target or would you be OK with fixing the build directory to e.g. build/ right next to src/ ?
The advantage we have now is that we can easily put config files for "build with VGA" "build with FILO" "built with etherboot" "build 256k/512k/1MB" etc. If we can easily fix this, we might be able to drop the hierarchy in /targets
What I like about the Linux build is that there's only ever one dir that you "make" in, and when make is done it always produces arch/*/boot/bzImage.
Good comparison. So "config" in our case is actually what we have in /targets/ now. The tree is not. Which board we build for is a config option though.
The current structure could be simple too, if the buildtarget step could be skipped, and there was no need for via/epia-m/epia-m but only via/epia-m, and that's where you go to make config && make to get a linuxbios.rom.
ready-made config directories? With Kconfig this could be a lot easier because it resolves option dependencies during compile time.
yes, kconfig has real limits, and we need to see if we can work our way around them.
Or maybe we'll extend it?
Or use it for what it can do and use different "made-to-the-task" utilities for the rest of our needs.
On Sun, Sep 17, 2006 at 11:25:02PM +0200, Stefan Reinauer wrote:
- Peter Stuge stuge-linuxbios@cdy.org [060917 02:37]:
Fair enough. But does the build directory have to be per-target or would you be OK with fixing the build directory to e.g. build/ right next to src/ ?
The advantage we have now is that we can easily put config files for "build with VGA" "build with FILO" "built with etherboot" "build 256k/512k/1MB" etc. If we can easily fix this, we might be able to drop the hierarchy in /targets
We absolutely need a way to set those high-level options in a simple-as-can-be manner.
Config.lb works very well but is a clumsy user interface.
I dislike needing to buildtarget (and the cd:ing and rm:ing that comes with it) before make. I just want one step for config and one for build.
The other main problem is that users are forced into expert mode (fdisk analogy) because they need to set the payload path.
Maybe we can get away with a Kconfig frontend for the existing system? The expert mode may still be too advanced though.
What I like about the Linux build is that there's only ever one dir that you "make" in, and when make is done it always produces arch/*/boot/bzImage.
Good comparison. So "config" in our case is actually what we have in /targets/ now. The tree is not. Which board we build for is a config option though.
Yes. As a user I don't think about the tree at all. Most of the time I don't have to. Sometimes I may want to disable a specific device that isn't populated on my board if the vendor is silly enough to have such options without changing the board name but I shouldn't have to become a developer to do so.
Maybe we could work around it by creating our own names for those variations, but with a few options on a board it gets messy.
If it's enough for users to only disable devices maybe we want to split developer config (tree) from user config, even if they in effect control the same thing. (tree AKA what code to include)
The current structure could be simple too, if the buildtarget step could be skipped, and there was no need for via/epia-m/epia-m but only via/epia-m, and that's where you go to make config && make to get a linuxbios.rom.
ready-made config directories? With Kconfig this could be a lot easier because it resolves option dependencies during compile time.
The current system is optimized for building every target. I think abuild is the only one who actually does this and hence we should optimize for the common case; building only one target.
I don't think we need the extra layer of abstraction, at least not by default.
cd targets/via/epia-m # determines which tree to start with make config # determines what the user wants to set make # builds linuxbios.rom
Better yet, skip cd and pick mainboard in make config. In root:
make config make # creates build/linuxbios.rom, maybe build/lb-2.0-filo-512.rom?
Have one expert option be "build directory" and abuild stays happy.
Only problem left is expressing dependencies in a way that make understands. Sorry if I've been slow to catch up.
Sticking with python maybe scons would be an alternative? xmms2 uses it - while they are friends of mine that I have a lot of respect for, technically and otherwise, I still believe that make is good enough at dependencies. :) May just be inexperience though. http://www.scons.org/
yes, kconfig has real limits, and we need to see if we can work our way around them.
Or maybe we'll extend it?
Or use it for what it can do and use different "made-to-the-task" utilities for the rest of our needs.
Check!
//Peter
Sticking with python maybe scons would be an alternative? xmms2 uses it - while they are friends of mine that I have a lot of respect for, technically and otherwise, I still believe that make is good enough at dependencies. :) May just be inexperience though. http://www.scons.org/
I just gave a brief look at scons and I like what I see. Need do some more reading on how we would it use the existing python config setup we have. This would at least remove all makefile magic without adding any extra dependencies.
give me one system, and I will work out all except Kconfig.
Actually extend serengeti_leopard a little could achive that.
BTW, what are the main features of V3 1. KConfig? 2. Kernel + initrd.===> BTW I can not build OLPC kernel and initrd on AMD64 LINUX 3. EFI?
YH
On 9/15/06, ron minnich rminnich@gmail.com wrote:
OK, I'd like to propose a challenge for the outcome of the linuxbios summit. I think this is doable. The challenge is simple.
Let's take the good ideas from all of you, and let's try to demonstrate a working, CAR-based, Kconfig-based, linuxbios tree for the ARUMA board (the one with 32 PCI busses). Let's just do the whole thing. I think we can do this. If we pull it off, then we've got our V3 layout done and can start migration.
Any takers?
ron
-- linuxbios mailing list linuxbios@linuxbios.org http://www.openbios.org/mailman/listinfo/linuxbios
* Richard Smith smithbone@gmail.com [060915 18:48]:
I remember many moons ago we talked about using Kconfig. And we chose not to. IIRC t the time Kconfig was seen as not being able to deal with our hardware tree structures. But that was a long time ago.
Yes. It still can't. But the tree is not something the user should configure. Its a hardware description. The motherboard support developer should do this.
We already have this seperation, although we did not dare doing it right last time: Config.lb and Options.lb in the mainboard directory.
Config.lb should be Tree.lb and contain nothing but the tree. It is not a config.
Options.lb should contain the default values for the configuration options (ie the "Kconfig" file for the kconfig mechanism) The target configuration file is .config in kconfig speak.
Stefan
Stefan Reinauer wrote:
- Richard Smith smithbone@gmail.com [060915 18:48]:
I remember many moons ago we talked about using Kconfig. And we chose not to. IIRC t the time Kconfig was seen as not being able to deal with our hardware tree structures. But that was a long time ago.
Yes. It still can't. But the tree is not something the user should configure. Its a hardware description. The motherboard support developer should do this.
yah, but, how does the developer do it? What's this stuff look like. You know last year I really wanted to make the jump to Kconfig, I just can't figure out how.
well, we'll get it in a few weeks.
no beer, just hacking.
ron
* Ronald G Minnich rminnich@lanl.gov [060915 19:19]:
yah, but, how does the developer do it? What's this stuff look like. You know last year I really wanted to make the jump to Kconfig, I just can't figure out how.
He creates/edits a file that contains only the tree, that looks exactly like it does now.
And that file is used to generate static.c during compilation. We can thin out the python tool to only do that task, or we write something together that does exactly this.
well, we'll get it in a few weeks.
no beer, just hacking.
:-)))
* Ronald G Minnich rminnich@lanl.gov [060915 17:46]:
I really don't like how vague our config options are. I am IMed by people all the time asking me what config option such and such does. I have to go grep through the code to figure it all out since I can't keep them straight myself.
if you're grepping code you're in the wrong place. The src/config/Options.lb REQUIRES a comment describing the option. There are 150 options -- there are 1700+ in linux.
But when creating a Linux .config you have two major advantages:
- all config options are hierarchically sorted - you can get the help in the context of the option you are changing.
I am attaching the result of egrep define|comment src/config/options.lb to this message. What should we be doing better? I'm open to any ideas. Some of those comments are quite good, e.g.
but this one: define MEMORY_HOLE comment "Set to deal with memory hole"
One thing I notice is the quotation marks. Linux config does not have that. You are not limited to pack everything in one line there..
I think it's the lousy config interface. If we had something like kconfig, and a <help> button, and (in some cases) better comments, I think it would be better.
I also believe we should drop "use". Just have everything exported always, and write all of them in _one_ file to check if something goes wrong. And set sane defaults. In the first place, it makes config files completely unreadable.
Stefan
Stefan Reinauer wrote:
I also believe we should drop "use". Just have everything exported always, and write all of them in _one_ file to check if something goes wrong. And set sane defaults. In the first place, it makes config files completely unreadable.
use was an idea that failed.
ron
* Ronald G Minnich rminnich@lanl.gov [060915 18:30]:
Stefan Reinauer wrote:
I also believe we should drop "use". Just have everything exported always, and write all of them in _one_ file to check if something goes wrong. And set sane defaults. In the first place, it makes config files completely unreadable.
use was an idea that failed.
It solved a problem that we dont have anymore. Next generation. Good sign. :-)
* Richard Smith smithbone@gmail.com [060915 17:18]:
I was against it because I don't see it as discoverable or self documenting.
Looking at the config file
COMPRESS= [0,1,2,3] dosen't mean much.
yes, 0,1,2,3 is useless. If multiple values, each of them needs to mean something.
Stefan Reinauer wrote:
- Ronald G Minnich rminnich@lanl.gov [060915 16:44]:
yhlu wrote:
I wonder if you can change CONFIG_COMPRESSED_ROM_STREAM to 0: no compress 1: NRV2B 2: LZMA 3: ...
why numbers? CONFIG_COMPRESSED_ROM_STREAM="NRV2B"
simple.
But, the cpp won't let you do much useful with strings, only numbers :-(
ron
-
Peter Stuge -
Richard Smith -
ron minnich -
Ronald G Minnich -
Stefan Reinauer -
yhlu