| 00:07:20 | Sammy | mornong ... |
| 07:21:40 | erikm | morning |
| 07:21:59 | erikm | is in lurk mode, so don't expect answers |
| 07:55:32 | Russ | you have 24hr remaining.... |
| 08:05:44 | erikm | no, 48hr |
| 16:53:31 | erikm | re * |
| 16:54:14 | erikm | Russ: I've given up the hope that we'll get a working demo ;) |
| 16:54:46 | erikm | Russ: so tomorrow I'l start digging up my own working "plan B" demos |
| 17:41:20 | Russ | erikm: bummer |
| 17:41:45 | erikm | Russ: what, the demos? |
| 17:42:13 | Russ | yah |
| 17:44:31 | erikm | Russ: I don't care, the guy that had to write a crucial part of the system started too late and didn't want listen to our advice |
| 17:45:56 | erikm | oh, btw, the cs89x0 will be done in linux-2.5 |
| 17:46:05 | erikm | cs89x0 rewrite, I mean |
| 17:46:16 | Russ | we still need to work on the fixed up version a bit |
| 17:46:46 | erikm | yeah, this morning I found out that it really doesn't want to work with 2.4.8-ac12-rmk1-np1 |
| 17:46:57 | Russ | its broken in many places |
| 17:50:42 | erikm | btw, the ethernet address is easy: just do what SUN and SGI machines do: use part of the machine serial number as ethernet address |
| 17:51:12 | erikm | and we already *have* ATAG nodes for serial numbers |
| 17:51:42 | Russ | or just keep it in the paramater block |
| 17:51:47 | Russ | er |
| 17:51:53 | Russ | the actual address that is |
| 17:52:04 | Russ | serial number node? |
| 17:52:08 | erikm | yep |
| 17:52:13 | Russ | char serial[16]? |
| 17:52:23 | erikm | ATAG_SERIAL |
| 17:52:32 | erikm | u32 low and ure high |
| 17:52:38 | Russ | I mean in blob |
| 17:52:45 | erikm | like I said in the comments: "64 bits should be enough for everybody" |
| 17:52:51 | erikm | no, I mean in the kernel |
| 17:53:04 | Russ | where do you store it in the flash? it goes in the kernel? |
| 17:54:16 | erikm | make a paramater tag for the serial number. if there is a serial number parameter tag, we pass it to the kernel by issuing an ATAG_SERIAL node |
| 17:54:29 | Russ | so you want it to just be u32 |
| 17:54:31 | erikm | same for board revision, that might also be handy |
| 17:54:36 | Russ | I would think char[16] |
| 17:54:43 | erikm | no, that would be a waste |
| 17:55:03 | Russ | why? |
| 17:55:20 | erikm | why put it in chars when we can encode it in a 64 it entity? |
| 17:56:06 | Russ | simplicity |
| 17:56:21 | erikm | if you make it the same as the kernel expects it to be, you can very easily make issue an ATAG_SERIAL node to the kernel |
| 17:56:36 | erikm | that's what I think is simplicity |
| 17:56:39 | Russ | ok |
| 17:56:52 | erikm | and really: 64 bit *is* enough |
| 17:57:02 | Russ | I thought you said u32 |
| 17:57:12 | erikm | struct tag_serialnr { |
| 17:57:12 | erikm | u32 low; |
| 17:57:12 | erikm | u32 high; |
| 17:57:12 | erikm | }; |
| 17:57:17 | erikm | 2x u32 |
| 17:57:22 | Russ | ah |
| 17:57:59 | Russ | is it ATAG_SERIAL, or ATAG_SERIALNR |
| 17:58:42 | erikm | ATAG_SERIAL |
| 17:58:54 | erikm | see include/asm-arm/setup.h |
| 17:59:11 | Russ | #define PTAG_SERIAL(PTAG_MAGIC | 0xA) |
| 17:59:11 | Russ | struct ptag_serialnr { |
| 17:59:11 | Russ | u32 low; |
| 17:59:11 | Russ | u32high; |
| 17:59:11 | Russ | }; |
| 17:59:45 | erikm | (I documented the various ATAG_* nodes, so I almost know them by heart :) |
| 18:00:05 | Russ | so far I have 10 nodes |
| 18:00:36 | erikm | and while you're at it: also make a PTAG_REVISION node: |
| 18:00:39 | erikm | struct tag_revision { |
| 18:00:39 | erikm | u32 rev; |
| 18:00:39 | erikm | }; |
| 18:00:49 | erikm | that is for the board revision number |
| 18:01:00 | Russ | does that have an associated ATAG? |
| 18:01:15 | erikm | yes, ATAG_REVISION |
| 18:01:33 | erikm | it's an u32, but that's nice for alignment |
| 18:03:25 | erikm | so what's the idea about the PTAG_REVISION node? do something like this in linux.c: |
| 18:03:42 | Russ | ? |
| 18:03:53 | erikm | if((node == ptag_get_node(PTAG_REVISION))) { |
| 18:04:05 | erikm | issue_atag_revsion_node() |
| 18:04:06 | erikm | } |
| 18:05:08 | Russ | there is no ptag_get_node at the moment |
| 18:05:32 | Russ | I was just going to parse it and add it to a global, but that creates the problem of not knowing if its set |
| 18:07:25 | Russ | which would you rather have? |
| 18:07:44 | erikm | I think that parsing the list at the moment you realy need it is good. in that case you can also change the values before you boot |
| 18:07:54 | erikm | like "set serial=42" |
| 18:08:00 | Russ | I could just do this: |
| 18:08:22 | Russ | static int parse_ptag_serialnr(const struct ptag *ptag) |
| 18:08:22 | Russ | { |
| 18:08:22 | Russ | blob_status.serialnr = ptag; |
| 18:08:22 | Russ | return 0; |
| 18:08:22 | Russ | } |
| 18:08:23 | Russ | __ptagtable(PTAG_SERIAL, parse_ptag_serialnr); |
| 18:08:35 | Russ | if (blob_status.serialnr) { |
| 18:08:45 | Russ | issue_atag_revision_node() |
| 18:08:46 | Russ | } |
| 18:10:55 | Russ | right now, the ptag list is a "preboot" thing, it well (eventually) controll the loading of the kernel/ramdisk and getting tags ready, etc |
| 18:11:13 | erikm | btw, how are you going to change the parameter list? |
| 18:11:18 | Russ | before booting, it would still do the "autoboot" ... thing |
| 18:11:40 | Russ | you mean the hdr part of it? |
| 18:14:12 | erikm | no, suppose I want to save a different default command line. how are you going to write that to flash? |
| 18:15:59 | Russ | run your config through the external parser, download and flash it |
| 18:16:59 | erikm | hmm |
| 18:17:18 | erikm | why can't blob safe it's setting itself? |
| 18:17:51 | Russ | was trying to keep it simple |
| 18:18:34 | erikm | well, I think this is too simple |
| 18:19:24 | Russ | ok, I'll see what I can do then |
| 18:19:58 | erikm | I think you shouldn't put the parameter list into the blob binary, but put it somewhere in the flash. at 64K boundary, for example |
| 18:20:10 | Russ | it is in the flash |
| 18:20:23 | Russ | there are 4 paramater blocks on the tuxscreen flash |
| 18:20:28 | Russ | I put it on the last paramater bolck |
| 18:20:29 | Russ | er |
| 18:20:29 | Russ | block |
| 18:21:00 | erikm | so why do we need all that linker magic if the parameters are not in the blob binary? |
| 18:21:16 | Russ | to tell the kernel where the paramater block is |
| 18:22:49 | erikm | kernel? |
| 18:22:51 | Russ | which linker magic? |
| 18:23:22 | erikm | the .ptaglist ELF section |
| 18:23:39 | Russ | oh, to simplify the function list that handles ptags |
| 18:24:00 | erikm | oh, ok |
| 18:24:10 | erikm | I see, just like linux __init functions |
| 18:24:21 | Russ | like, if you have ptags that initialize a net device, all that needs to be done is link those .o's in |
| 18:24:26 | Russ | no #ifdefs in the parsing |
| 18:24:53 | erikm | BTW, I'm going to rewrite the command parser to use the same kind of magic |
| 18:24:54 | Russ | the splash screen patch is an example of that |
| 18:25:23 | Russ | good |
| 18:25:39 | Russ | because the way you want to rewrite the paramater block on the fly, it will need that |
| 18:26:15 | Russ | note that there may be more than one command line in the paramater block, and you need to select which "config" you want to modify |
| 18:26:37 | erikm | hmm. just thinking about it: I think we should copy the parameter block to RAM and use that copy to play with |
| 18:26:52 | Russ | right now I'm not, but its an easy change |
| 18:27:32 | erikm | if you want to save it, you just say "save parameters" and only at that point the list is cleaned up (dead nodes thrown out, duplicates removed, etc) and saved to flash |
| 18:28:33 | Russ | you would need to do the cleanup as paramater are changed I would think |
| 18:29:23 | erikm | no. I think you'll need a PTAG_DEAD node that indicates that the current node is no longer active and the parser should ignore it and continue with the next node. only when you want to save it back to flash, you should clean up the list |
| 18:29:47 | Russ | well |
| 18:29:48 | erikm | because in most cases you only want to make temporary changes from the default configuration that you're not going to save anyway |
| 18:29:51 | Russ | a tag can grow |
| 18:30:39 | erikm | no, don't let it grow. just copy it to the end of the list and modify it, and mark the old one as DEAD |
| 18:30:46 | erikm | makes your code a lot easier |
| 18:30:46 | Russ | with some tags, the order matters |
| 18:31:33 | erikm | like? |
| 18:31:49 | Russ | /* check a GPIO */ |
| 18:31:50 | Russ | #define PTAG_GPIO(PTAG_MAGIC | 8) |
| 18:31:50 | Russ | struct ptag_gpio { |
| 18:31:50 | Russ | u32 mask; |
| 18:31:50 | Russ | u32level; |
| 18:31:50 | Russ | }; |
| 18:33:02 | erikm | what's that for? to see if a certain key is pressed or so? |
| 18:33:19 | Russ | or maybe if there is a pcmcia card inserted |
| 18:33:32 | Russ | or the flash_ext thing on the lart |
| 18:33:52 | Russ | there are lots of reasons you'd want to boot differently based an a gpio |
| 18:35:46 | Russ | as well as other things, such as if configuring a net device succeeds, or a tftp retrieval, etc |
| 18:37:38 | erikm | hmm |
| 18:37:57 | erikm | I'm really going to think about it over the weekend |
| 18:38:00 | Russ | /* what to do with the config bits */ |
| 18:38:00 | Russ | u8fail_set; |
| 18:38:00 | Russ | u8fail_clear; |
| 18:38:00 | Russ | u8pass_set; |
| 18:38:00 | Russ | u8pass_clear; |
| 18:38:35 | Russ | then each tag has a config mask, and config, so if config & tagmask == tagconfig |
| 18:38:40 | Russ | then the tag is proccessed |
| 18:39:18 | Russ | when it returns, it looks at the return value, and the fail/pass masks, and modifies the config accordingly |
| 18:42:02 | Russ | also, reloading the config from another location can probably be done (ie, jffs2, tftp) |
| 18:43:35 | erikm | ok, makes sense, just like we discussed with rmk |
| 18:44:26 | Russ | I think that most (probably all) tags you'd want to change from blob won't require anything complex |
| 18:45:31 | Russ | either that, or we just link blob tighter with the host |
| 18:45:50 | Russ | so if you want to change stuff, the host does it transparently |
| 18:46:33 | erikm | I think you see the parameter list as something static that is only set at compile time, while in my opinion it is very dynamic |
| 18:46:47 | Russ | its not set at compile time |
| 18:47:01 | Russ | its a seperate entity, like the kernel or ramdisk |
| 18:47:16 | erikm | I agree that we need some default settings, but you should be able to change it and save it to flash at all times |
| 18:47:17 | Russ | maybe it could be seperated into two halves |
| 18:47:39 | erikm | just like the bootproms for SUN or SGI machines |
| 18:47:59 | Russ | not familar with those |
| 18:50:12 | Russ | I see giving the boot process intellegence that is generated by a program on the host, a boot process to follow |
| 18:50:50 | erikm | Russ: I really like the SUN proms because they are completely written in Forth. every card comes with a small EPROM with some forth code to initialise the card, and it also has some test programs and settings |
| 18:51:39 | erikm | so you just put a SCSI SBUS card in the machine, you cd to the correct device node, and run the diag program over there |
| 18:52:01 | Russ | hmm |
| 18:52:31 | erikm | the main prom also has some stuff in it, like "scsi-probe-all" which probes all scsi devices on all scsi cards |
| 18:53:00 | erikm | and setting variables is very easy: set boot-device disk1 |
| 18:53:38 | Russ | so there are some basic paramaters that are settable |
| 18:53:47 | Russ | and there are some other processes that just happen |
| 18:54:23 | erikm | well, you can actually set whatever parameter you like, but not all parameters make sense |
| 18:54:55 | erikm | things like "set the=meaning-of-life-the-universe-and-everything=42" is nice, but doesn't buy you anything |
| 18:56:01 | Russ | so you would only have a fixed set of boot logic, and choose one? (ala: C:, A:, SCSI) |
| 18:56:31 | erikm | the machine boots by calling all init procedures for the complete device tree (so a bus bridge will get initialised before the scsi device) and after that calling the boot procedure from the boot device |
| 18:56:54 | erikm | you can boot from any device that implements the boot function |
| 18:58:24 | erikm | that's called OpenPROM, btw, or IEEE 1275. the PCI SIG should have made that mandatory for PCI devices |
| 18:58:30 | Russ | so a bootfunction at its core would be kernel, ramdisk (optional), and cmdline |
| 18:59:52 | erikm | afaik the disk driver boot function loads a couple of blocks from a magic part of the disk and gives control to it (SILO, for sparc-linux), the network driver implements it as bootp+tftp |
| 19:00:25 | Russ | I'm talking with blob |
| 19:00:51 | Russ | seems to static for blob to me, too many cases in blob, like if you have a CF card, net card, and your own flash |
| 19:00:53 | erikm | oh, sorry %-) |
| 19:01:11 | Russ | and you want to try the CF, then tftp, then flash |
| 19:01:49 | erikm | oh, but openprom allows you to do so. remember: it's a forth interpreter, so you can write forth programs to control the boot proces :) |
| 19:02:07 | Russ | which is what the paramater tags are |
| 19:02:17 | Russ | basically a program to control the boot process |
| 19:02:26 | erikm | yes and no |
| 19:02:50 | erikm | in some way it controls the boot process, in other ways it just contains parameters |
| 19:03:17 | Russ | right, but those paramaters can vary based on which tags succeded/failed (ie, cmdline) |
| 19:03:51 | Russ | ah |
| 19:03:57 | erikm | some of them, yes. others not. |
| 19:04:06 | Russ | each boot medium has a paramater lists that tells how to boot it |
| 19:04:32 | erikm | that's only *one* of the uses of the parameter list |
| 19:04:35 | Russ | hmm...or |
| 19:04:53 | erikm | we only want to be able to set the for example the serial speed with it |
| 19:05:13 | Russ | terminal speed is in the core tag |
| 19:05:50 | Russ | because it needs to be read before the rest of the list is parsed (and before the memory map thing is done) |
| 19:12:30 | Russ | maybe i could make a set of N paramater lists |
| 19:12:51 | Russ | and the action of a certain tag could jump to another list |
| 19:12:51 | erikm | maybe you'd better discuss it on the LART list |
| 19:13:12 | erikm | that would be an idea, yeah |
| 19:13:47 | Russ | I'll brainstorm how to do that best |
| 19:15:50 | erikm | just write down your ideas. it forces you to think about it, and it will give other an opportunity to comment |
| 19:19:16 | erikm | s/other/others/ |
| 19:20:52 | Russ | anyway, class |
| 19:21:35 | erikm | yeah, home |
| 19:21:46 | erikm | or better: bed |
| 19:21:53 | erikm | bye |