| Message ID | 1315865067-1443-2-git-send-email-sjg@chromium.org |
|---|---|
| State | New, archived |
| Headers | show |
On Tuesday, September 13, 2011 12:04:22 AM Simon Glass wrote: > This adds a device tree pointer to the global data. It can be set by > board code. A later commit will add support for embedding it in U-Boot. > > Signed-off-by: Simon Glass <sjg@chromium.org> > --- > README | 11 +++++++++++ > arch/arm/include/asm/global_data.h | 1 + > 2 files changed, 12 insertions(+), 0 deletions(-) > Hi, do you actually intend to introduce some kind of a driver model to uboot ?
Hi Merek, On Mon, Sep 12, 2011 at 8:10 PM, Marek Vasut <marek.vasut@gmail.com> wrote: > On Tuesday, September 13, 2011 12:04:22 AM Simon Glass wrote: >> This adds a device tree pointer to the global data. It can be set by >> board code. A later commit will add support for embedding it in U-Boot. >> >> Signed-off-by: Simon Glass <sjg@chromium.org> >> --- >> README | 11 +++++++++++ >> arch/arm/include/asm/global_data.h | 1 + >> 2 files changed, 12 insertions(+), 0 deletions(-) >> > Hi, > > do you actually intend to introduce some kind of a driver model to uboot ? > I would love to, yes. To some extent there is a bit of this already, at least for specific subsystems. Clearly the fdt would work better if we could just hand U-Boot the fdt and say 'init yourself'. It would then scan the tree and init all the drivers for all active devices. However, we can achieve most of the aims using something along the lines of what I have proposed, where the existing call (say to nand_init()) can look up the fdt for its node, and then get the information it needs. The only really difference is the explicit hard-coded call to nand_init, rather than a general purpose routine to find a nand node and then locate a driver for it. To some extent that way of doing things would invert the way U-Boot currently works. It would also introduce questions about dealing with multiple devices of the same type (e.g. two different i2c controllers (not just instances) or driving two displays. These sorts of things are tricky in U-Boot at the moment. So overall I think a unified driver model is a separate problem, and one that we should discuss and perhaps move forward on separately. Regards. Simon
On Tuesday, September 13, 2011 06:52:34 AM Simon Glass wrote: > Hi Merek, > > On Mon, Sep 12, 2011 at 8:10 PM, Marek Vasut <marek.vasut@gmail.com> wrote: > > On Tuesday, September 13, 2011 12:04:22 AM Simon Glass wrote: > >> This adds a device tree pointer to the global data. It can be set by > >> board code. A later commit will add support for embedding it in U-Boot. > >> > >> Signed-off-by: Simon Glass <sjg@chromium.org> > >> --- > >> README | 11 +++++++++++ > >> arch/arm/include/asm/global_data.h | 1 + > >> 2 files changed, 12 insertions(+), 0 deletions(-) > > > > Hi, > > > > do you actually intend to introduce some kind of a driver model to uboot > > ? > > I would love to, yes. To some extent there is a bit of this already, > at least for specific subsystems. Clearly the fdt would work better if > we could just hand U-Boot the fdt and say 'init yourself'. It would > then scan the tree and init all the drivers for all active devices. > > However, we can achieve most of the aims using something along the > lines of what I have proposed, where the existing call (say to > nand_init()) can look up the fdt for its node, and then get the > information it needs. The only really difference is the explicit > hard-coded call to nand_init, rather than a general purpose routine to > find a nand node and then locate a driver for it. > > To some extent that way of doing things would invert the way U-Boot > currently works. It would also introduce questions about dealing with > multiple devices of the same type (e.g. two different i2c controllers > (not just instances) or driving two displays. These sorts of things > are tricky in U-Boot at the moment. > > So overall I think a unified driver model is a separate problem, and > one that we should discuss and perhaps move forward on separately. Well, I have this kind of stuff in mind and I plan to try pushing it as a university project in a month or so. But (!) if you plan to init U-Boot according to FDT and I plan to add driver model, we should keep in tight contact so the driver model would be close to the FDT. And yea -- dealing with the "dirty work" like fixing subsystems etc. would be part of the driver model stuff. Cheers > > Regards. > Simon
Dear Simon Glass, In message <CAPnjgZ3kZJoAGJFkPkxQp+-jnztYECUaEtLZ0nvgzV1f-xUQgQ@mail.gmail.com> you wrote: > > I would love to, yes. To some extent there is a bit of this already, > at least for specific subsystems. Clearly the fdt would work better if > we could just hand U-Boot the fdt and say 'init yourself'. It would > then scan the tree and init all the drivers for all active devices. No, it would definitely not do that. U-Boot shall not initialize all possible available devices, but always only those that it needs itself to perform it's task, which usually is just to load and start an OS. It makes no sense to initialize all network interfaces (and eventually wait for the link to come up), to initialize all attached disk drives (and wait for them to spin up) or to scan the whole USB bus and initialize all attached devices when we don't need any of these to boot the OS. Suchinitializations shall always be done on demand only, i. e. when a command is run that accesses any such device. > However, we can achieve most of the aims using something along the > lines of what I have proposed, where the existing call (say to > nand_init()) can look up the fdt for its node, and then get the > information it needs. The only really difference is the explicit > hard-coded call to nand_init, rather than a general purpose routine to > find a nand node and then locate a driver for it. I can;t parse that. Why cannot nand_init() do exactly what you suggest, i. e. find a nand node and then locate a driver for it? OK, by then it will probably be something like driver_init("nand") or the like, but that's just a detail. > To some extent that way of doing things would invert the way U-Boot > currently works. It would also introduce questions about dealing with > multiple devices of the same type (e.g. two different i2c controllers > (not just instances) or driving two displays. These sorts of things > are tricky in U-Boot at the moment. Keep in mind that devices are always accessedonly on demand, so you will have the needed information which device needs to be opened. > So overall I think a unified driver model is a separate problem, and > one that we should discuss and perhaps move forward on separately. Agreed. Best regards, Wolfgang Denk
Hi Wolfgang, On Tue, Sep 13, 2011 at 2:47 AM, Wolfgang Denk <wd@denx.de> wrote: > Dear Simon Glass, > > In message <CAPnjgZ3kZJoAGJFkPkxQp+-jnztYECUaEtLZ0nvgzV1f-xUQgQ@mail.gmail.com> you wrote: >> >> I would love to, yes. To some extent there is a bit of this already, >> at least for specific subsystems. Clearly the fdt would work better if >> we could just hand U-Boot the fdt and say 'init yourself'. It would >> then scan the tree and init all the drivers for all active devices. > > No, it would definitely not do that. > > U-Boot shall not initialize all possible available devices, but always > only those that it needs itself to perform it's task, which usually is > just to load and start an OS. It makes no sense to initialize all > network interfaces (and eventually wait for the link to come up), to > initialize all attached disk drives (and wait for them to spin up) or > to scan the whole USB bus and initialize all attached devices when we > don't need any of these to boot the OS. > > Suchinitializations shall always be done on demand only, i. e. when a > command is run that accesses any such device. Yes thanks for pointing that out. I am really thinking of the init sequence in board_init_r() where we init NAND, MMC and the like. So yes it makes no sense to blindly init everything we can find. The fdt can provide a list of available options for each device type (although in practice often it will provide only one option, perhaps with multiple instances). > >> However, we can achieve most of the aims using something along the >> lines of what I have proposed, where the existing call (say to >> nand_init()) can look up the fdt for its node, and then get the >> information it needs. The only really difference is the explicit >> hard-coded call to nand_init, rather than a general purpose routine to >> find a nand node and then locate a driver for it. > > I can;t parse that. Why cannot nand_init() do exactly what you > suggest, i. e. find a nand node and then locate a driver for it? > OK, by then it will probably be something like driver_init("nand") or > the like, but that's just a detail. That's certainly the current approach, yes. It does work well I think, and has the virtue of being simple, with minimal changes required to code. > >> To some extent that way of doing things would invert the way U-Boot >> currently works. It would also introduce questions about dealing with >> multiple devices of the same type (e.g. two different i2c controllers >> (not just instances) or driving two displays. These sorts of things >> are tricky in U-Boot at the moment. > > Keep in mind that devices are always accessedonly on demand, so you > will have the needed information which device needs to be opened. Yes, that's true and we mustn't do anything which blurs or weakens that link. When I think of multiple LCD support for example, while there is hardware support for it, do we have a need for it? Sometimes this sort of thing is a solution looking for a problem. Yes it would be easier to implement this feature with a unified driver model, but... On the other hand I think serial could benefit from a unified driver model quite nicely :-) > >> So overall I think a unified driver model is a separate problem, and >> one that we should discuss and perhaps move forward on separately. > > Agreed. OK good. There seem to be a lot of different activities going on, as Graeme says in the other thread. Regards, Simon > > Best regards, > > Wolfgang Denk > > -- > DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany > Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de > If you want strict real-time behavior, run in the real time schedu- > ling class. But there are no seatbelts or airbags; main(){for(;;);} > can hard hang your system. -- Bart Smaalders >
Dear Simon, In message <CAPnjgZ1y+i0FdawcbBuOi0+SC+Xq3AS=ZZtTi1tVjv8CcNw6Og@mail.gmail.com> you wrote: > > > U-Boot shall not initialize all possible available devices, but always > > only those that it needs itself to perform it's task, which usually is > > just to load and start an OS. =A0It makes no sense to initialize all > > network interfaces (and eventually wait for the link to come up), to > > initialize all attached disk drives (and wait for them to spin up) or > > to scan the whole USB bus and initialize all attached devices when we > > don't need any of these to boot the OS. > > > > Suchinitializations shall always be done on demand only, i. e. when a > > command is run that accesses any such device. > > Yes thanks for pointing that out. I am really thinking of the init > sequence in board_init_r() where we init NAND, MMC and the like. So I'm thinking of that, too. This list initializes a lot of things it actually should not. When this code got written, we had only a few boards, an all init steps took just a few milliseconds, so it appeared a good idea to print a "complete" system status at boot - always. Now we don't consider this approach practical any more, especially when targetting for short boot times. When introducing a device model, one of the tasks will be to change this part, too. > On the other hand I think serial could benefit from a unified driver > model quite nicely :-) Agreed, and not only serial. > OK good. There seem to be a lot of different activities going on, as > Graeme says in the other thread. Indeed. I'm actually amazed how many different things suddenly start moving :-) Best regards, Wolfgang Denk
Hi Wolfgang, On Tue, Sep 13, 2011 at 4:57 AM, Wolfgang Denk <wd@denx.de> wrote: > Dear Simon, > > In message <CAPnjgZ1y+i0FdawcbBuOi0+SC+Xq3AS=ZZtTi1tVjv8CcNw6Og@mail.gmail.com> you wrote: >> >> > U-Boot shall not initialize all possible available devices, but always >> > only those that it needs itself to perform it's task, which usually is >> > just to load and start an OS. =A0It makes no sense to initialize all >> > network interfaces (and eventually wait for the link to come up), to >> > initialize all attached disk drives (and wait for them to spin up) or >> > to scan the whole USB bus and initialize all attached devices when we >> > don't need any of these to boot the OS. >> > >> > Suchinitializations shall always be done on demand only, i. e. when a >> > command is run that accesses any such device. >> >> Yes thanks for pointing that out. I am really thinking of the init >> sequence in board_init_r() where we init NAND, MMC and the like. So > > I'm thinking of that, too. This list initializes a lot of things it > actually should not. When this code got written, we had only a few > boards, an all init steps took just a few milliseconds, so it appeared > a good idea to print a "complete" system status at boot - always. > > Now we don't consider this approach practical any more, especially > when targetting for short boot times. Oh OK, well that's actually quite good then. For one thing it means that the idea of init order is perhaps not so critical, since we actually want to remove most of this mandatory init. I mean that if we are not trying to replicate the init sequence in board_init_r (but in fact remove most of it) then things are simpler, and perhaps even fall back to a call to the board code and not much else. > > When introducing a device model, one of the tasks will be to change > this part, too. Well it seems like it might fit quite nicely. For example cmd_usb can make a call to get a USB driver pointer/context, which can do start-of-day init if not already done. There are some complexities with shared clock/pinmux config, but it shouldn't be too bad. It might mean that U-Boot takes back control of firing off vendor init code, currently done at start of day in board_init and the like. > >> On the other hand I think serial could benefit from a unified driver >> model quite nicely :-) > > Agreed, and not only serial. I admit I haven't been through every subsystem... > >> OK good. There seem to be a lot of different activities going on, as >> Graeme says in the other thread. > > Indeed. I'm actually amazed how many different things suddenly start > moving :-) Yes, it is certainly moving. Boot time optimisation, code clean-up/rationalisation and run-time config should provide plenty of impetus. Regards, Simon > > Best regards, > > Wolfgang Denk > > -- > DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany > Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de > There are no data that cannot be plotted on a straight line if the > axis are chosen correctly. >
Dear Simon Glass, In message <CAPnjgZ0FvaM-dM0Af_ZiAT9EKho+zeT4HF_Vx9AqSXALp0pVhA@mail.gmail.com> you wrote: > > Oh OK, well that's actually quite good then. For one thing it means > that the idea of init order is perhaps not so critical, since we > actually want to remove most of this mandatory init. I mean that if we > are not trying to replicate the init sequence in board_init_r (but in > fact remove most of it) then things are simpler, and perhaps even fall > back to a call to the board code and not much else. I think there are at least two parts of it. One is driver init stuff. Here it should indeed be sufficient when each command that tries to open a driver will trigger the initialization of the device if thios has not been done before (this sounds simple enough, but I see some complexity because some of these things _will_ be done before relocation, i. e. without BSS and without writable data segment, so we only havce the space-limited gd ...). The other part is board specific dependencies that are not that easy to detect. I consider it a pity that Detlev's suggestion went by uncommented: http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/105824/focus=106328 The "init a driver when it's needed" is some automatic part of such dependency base intialization. Eventually we should follow that method for the remaining parts, too. Best regards, Wolfgang Denk
On Monday, September 12, 2011 18:04:22 Simon Glass wrote: > --- a/arch/arm/include/asm/global_data.h > +++ b/arch/arm/include/asm/global_data.h > > + const void *blob; /* Our device tree, NULL if none */ still "blob" and not "fdt_blob" ? one man's blob is another man's blub ;) -mike
Hi Mike, On Tue, Sep 13, 2011 at 11:16 AM, Mike Frysinger <vapier@gentoo.org> wrote: > On Monday, September 12, 2011 18:04:22 Simon Glass wrote: >> --- a/arch/arm/include/asm/global_data.h >> +++ b/arch/arm/include/asm/global_data.h >> >> + const void *blob; /* Our device tree, NULL if none */ > > still "blob" and not "fdt_blob" ? one man's blob is another man's blub ;) > -mike > Sorry I did say I would change this - will do so before I send out a real (not RFC) patch. Regards, Simon
diff --git a/README b/README index 0886987..812805f 100644 --- a/README +++ b/README @@ -795,6 +795,17 @@ The following options need to be configured: XXX - this list needs to get updated! +- Device tree: + CONFIG_OF_CONTROL + If this variable is defined, U-Boot will use a device tree + to configure its devices, instead of relying on statically + compiled #defines in the board file. This option is + experimental and only available on a few boards. The device + tree is available in the global data as gd->blob. + + U-Boot needs to get its device tree from somewhere. This will + be enabled in a future patch. + - Watchdog: CONFIG_WATCHDOG If this variable is defined, it enables watchdog diff --git a/arch/arm/include/asm/global_data.h b/arch/arm/include/asm/global_data.h index 4fc51fd..818eced 100644 --- a/arch/arm/include/asm/global_data.h +++ b/arch/arm/include/asm/global_data.h @@ -73,6 +73,7 @@ typedef struct global_data { #if !(defined(CONFIG_SYS_ICACHE_OFF) && defined(CONFIG_SYS_DCACHE_OFF)) unsigned long tlb_addr; #endif + const void *blob; /* Our device tree, NULL if none */ void **jt; /* jump table */ char env_buf[32]; /* buffer for getenv() before reloc. */ } gd_t;
This adds a device tree pointer to the global data. It can be set by board code. A later commit will add support for embedding it in U-Boot. Signed-off-by: Simon Glass <sjg@chromium.org> --- README | 11 +++++++++++ arch/arm/include/asm/global_data.h | 1 + 2 files changed, 12 insertions(+), 0 deletions(-)