[U-Boot] BIOS EMULATOR driver
Hello, I'm working on one project about bios emulator and I notice that this driver is linked for boards P1022DS and sequoia too, but they don't really use any methods of it. It's safe to remove this support from configs files? Whole this driver is seems to be imported from somewhere and lots of its code is unused Actually only one method is used. It's safe to clean this too?
Thanks for answer Viktor Krivak
Dear Viktor,
In message CAJxx_ay7FAz-SJ0k2cBqWd1meVhDqm6vtESy=T6f9rs=KatBhQ@mail.gmail.com you wrote:
I'm working on one project about bios emulator and I notice that this driver is linked for boards P1022DS and sequoia too, but they don't really use any methods of it. It's safe to remove this support from configs files?
Are you sure that the code is not used?
sequoia:
#define CONFIG_BIOSEMU /* x86 bios emulator for vga bios */ #define CONFIG_ATI_RADEON_FB /* use radeon framebuffer driver */ ...
P1022DS:
#define CONFIG_BIOSEMU ... #define CONFIG_ATI_RADEON_FB
These boards enable the BIOS emulator to initialize the BIOS on ATI Radeon graphics cards; CONFIG_ATI_RADEON_FB causes that ati_radeon_fb ("drivers/video/ati_radeon_fb.c") gets included; this code calls (among other things) BootVideoCardBIOS() ...
Whole this driver is seems to be imported from somewhere and lots of its code is unused Actually only one method is used. It's safe to clean this too?
If you disable all the graphics code, yes.
Best regards,
Wolfgang Denk
Dear Wolfgang,
I'm working on one project about bios emulator and I notice that this driver is linked for boards P1022DS and sequoia too, but they don't really use any methods of it. It's safe to remove this support from configs files?
Are you sure that the code is not used?
I pretty sure because I try compile it without this driver and everything seems to be ok.
Best regards,
Wolfgang Denk
Best regards Viktor Krivak
Dear Viktor,
In message CAJxx_awWp1wSLhu0e0Dzk+ZhAYFjY+98AACo9f_6KxswZkktrA@mail.gmail.com you wrote:
I'm working on one project about bios emulator and I notice that this driver is linked for boards P1022DS and sequoia too, but they don't really use any methods of it. It's safe to remove this support from configs files?
Are you sure that the code is not used?
I pretty sure because I try compile it without this driver and everything seems to be ok.
In the given configurations, the BIOS code only gets built when you the ATI Radeon support is enabled, in which case it is needed.
If you don't enable either, then it's fine as well - but then the BIOS code does not get built anyway.
Best regards,
Wolfgang Denk
Dear Wolfgang Denk,
Dear Viktor,
In message
CAJxx_awWp1wSLhu0e0Dzk+ZhAYFjY+98AACo9f_6KxswZkktrA@mail.gmail.com you wrote:
I'm working on one project about bios emulator and I notice that this driver is linked for boards P1022DS and sequoia too, but they don't really use any methods of it. It's safe to remove this support from configs files?
Are you sure that the code is not used?
I pretty sure because I try compile it without this driver and everything seems to be ok.
In the given configurations, the BIOS code only gets built when you the ATI Radeon support is enabled, in which case it is needed.
If you don't enable either, then it's fine as well - but then the BIOS code does not get built anyway.
But we probably want this driver to work, so ...
Best regards,
Wolfgang Denk
Best regards, Marek Vasut
Dear Marek Vasut,
In message 201203261243.19732.marex@denx.de you wrote:
I pretty sure because I try compile it without this driver and everything seems to be ok.
In the given configurations, the BIOS code only gets built when you the ATI Radeon support is enabled, in which case it is needed.
If you don't enable either, then it's fine as well - but then the BIOS code does not get built anyway.
But we probably want this driver to work, so ...
I'm not sure what your comment means.
If you want to use this driver, then enable it in the configuration; this will mean the BIOS emulator also gets built and linked, and it will be needed to initialize the card's BIOS.
Everything is fine. No problems anywhere.
What exactly was your concern?
Best regards,
Wolfgang Denk
Dear Wolfgang Denk,
Dear Marek Vasut,
In message 201203261243.19732.marex@denx.de you wrote:
I pretty sure because I try compile it without this driver and everything seems to be ok.
In the given configurations, the BIOS code only gets built when you the ATI Radeon support is enabled, in which case it is needed.
If you don't enable either, then it's fine as well - but then the BIOS code does not get built anyway.
But we probably want this driver to work, so ...
I'm not sure what your comment means.
If you want to use this driver, then enable it in the configuration; this will mean the BIOS emulator also gets built and linked, and it will be needed to initialize the card's BIOS.
Everything is fine. No problems anywhere.
Right. My concern was about:
"I pretty sure because I try compile it without this driver and everything seems to be ok."
So that means the board work without this bios emulator driver if the radeon driver is disabled? But we want to use the radeon driver, so we need the bios emulator stuff.
I think the discussion quite drifted away from the original question, which was if the dead code in bios emulator stuff can be simply removed? ... and if it really is dead code.
What exactly was your concern?
Best regards,
Wolfgang Denk
Best regards, Marek Vasut
Dear Marek Vasut,
In message 201203261531.18334.marex@denx.de you wrote:
So that means the board work without this bios emulator driver if the radeon driver is disabled? But we want to use the radeon driver, so we need the bios emulator stuff.
Right. If you don't need feature X and do not configure it, then you don't need the driver that implements feature X, and building without this driver works. If you need feature X, then you must include it, and it is usually no dead code then.
And even if it was, the combination of -ffunction-sections / -fdata-sections with --gc-sections should prevent any damages.
I think the discussion quite drifted away from the original question, which was if the dead code in bios emulator stuff can be simply removed? ... and if it really is dead code.
If you need the BIOS emulator to initialize the BIOS of a graphics card it it probably not exactly "dead code".
Best regards,
Wolfgang Denk
Dear Wolfgang Denk,
Dear Marek Vasut,
In message 201203261531.18334.marex@denx.de you wrote:
So that means the board work without this bios emulator driver if the radeon driver is disabled? But we want to use the radeon driver, so we need the bios emulator stuff.
Right. If you don't need feature X and do not configure it, then you don't need the driver that implements feature X, and building without this driver works. If you need feature X, then you must include it, and it is usually no dead code then.
And even if it was, the combination of -ffunction-sections / -fdata-sections with --gc-sections should prevent any damages.
Well, certainly ... but from what Viktor told me, there are slabs of dead code in this stuff.
I think the discussion quite drifted away from the original question, which was if the dead code in bios emulator stuff can be simply removed? ... and if it really is dead code.
If you need the BIOS emulator to initialize the BIOS of a graphics card it it probably not exactly "dead code".
Certainly, though I'm not confident if all of the bios emulator stuff is used.
Best regards,
Wolfgang Denk
Best regards, Marek Vasut
Dear Wolfgang Denk and Marek Vasut,
2012/3/27 Marek Vasut marek.vasut@gmail.com:
Dear Wolfgang Denk,
Dear Marek Vasut,
In message 201203261531.18334.marex@denx.de you wrote:
So that means the board work without this bios emulator driver if the radeon driver is disabled? But we want to use the radeon driver, so we need the bios emulator stuff.
Right. If you don't need feature X and do not configure it, then you don't need the driver that implements feature X, and building without this driver works. If you need feature X, then you must include it, and it is usually no dead code then.
And even if it was, the combination of -ffunction-sections / -fdata-sections with --gc-sections should prevent any damages.
Well, certainly ... but from what Viktor told me, there are slabs of dead code in this stuff.
I think the discussion quite drifted away from the original question, which was if the dead code in bios emulator stuff can be simply removed? ... and if it really is dead code.
If you need the BIOS emulator to initialize the BIOS of a graphics card it it probably not exactly "dead code".
Certainly, though I'm not confident if all of the bios emulator stuff is used.
Yes that's the main problem. Lots of code i unused. Basically everything except BootVideoCardBIOS, that is use in ATI video driver. I've got two solution of this problem. First, mark all unused code by some macro and compile it only conditionally or remove it. But I not sure if someone use this death code for debug purposes.
Best regards,
Wolfgang Denk
Best regards, Marek Vasut
Best regards, Viktor Krivak
Dear =?ISO-8859-2?Q?Viktor_K=F8iv=E1k?=,
In message CAJxx_aysp3cO1CasSNgycqE_yDNiBcMRwJ7P6GGR6T-d9QbB-A@mail.gmail.com you wrote:
And even if it was, the combination of -ffunction-sections / -fdata-sections with --gc-sections should prevent any damages.
...
Yes that's the main problem. Lots of code i unused. Basically everything except BootVideoCardBIOS, that is use in ATI video driver. I've got two solution of this problem. First, mark all unused code by some macro and compile it only conditionally or remove it. But I not sure if someone use this death code for debug purposes.
Did you check if you really find any such code in your linked image? As I already explained, normally -ffunction-sections / -fdata-sections with --gc-sections should make sure any unused functions get dropped automatically.
Best regards,
Wolfgang Denk
Dear Wolfgang Denk,
Dear =?ISO-8859-2?Q?Viktor_K=F8iv=E1k?=,
In message <CAJxx_aysp3cO1CasSNgycqE_yDNiBcMRwJ7P6GGR6T-d9QbB-
A@mail.gmail.com> you wrote:
And even if it was, the combination of -ffunction-sections / -fdata-sections with --gc-sections should prevent any damages.
...
Yes that's the main problem. Lots of code i unused. Basically everything except BootVideoCardBIOS, that is use in ATI video driver. I've got two solution of this problem. First, mark all unused code by some macro and compile it only conditionally or remove it. But I not sure if someone use this death code for debug purposes.
Did you check if you really find any such code in your linked image? As I already explained, normally -ffunction-sections / -fdata-sections with --gc-sections should make sure any unused functions get dropped automatically.
Sure, but I see no point in keeping such dead code in U-Boot code base. Aka. why keep functions in U-Boot that are never used?
Best regards,
Wolfgang Denk
Best regards, Marek Vasut
Marek Vasut wrote:
Sure, but I see no point in keeping such dead code in U-Boot code base. Aka. why keep functions in U-Boot that are never used?
I think what Wolfgang is trying to say is that no one has proven that there actually IS any unused code. The ATI driver needs the BIOS emulator, so you need to enable support for the ATI driver to see what is and is not actually used. Just because it's not enabled currently in any board, that doesn't mean that the code is useless.
Dear Timur Tabi,
Marek Vasut wrote:
Sure, but I see no point in keeping such dead code in U-Boot code base. Aka. why keep functions in U-Boot that are never used?
I think what Wolfgang is trying to say is that no one has proven that there actually IS any unused code. The ATI driver needs the BIOS emulator, so you need to enable support for the ATI driver to see what is and is not actually used. Just because it's not enabled currently in any board, that doesn't mean that the code is useless.
Agreed, but I expected there was some dead code and that was the point I was trying to express ;-)
Best regards, Marek Vasut
Dear Timur Tabi,
Marek Vasut wrote:
Agreed, but I expected there was some dead code and that was the point I was trying to express ;-)
Well, until you do a thorough analysis, you really have no idea if there is any dead code at all.
I don't ... but Viktor probably does and I believe that's what he wants to ask about.
Best regards, Marek Vasut
Dear Timur Tabi,
2012/3/27 Marek Vasut marex@denx.de:
Dear Timur Tabi,
Marek Vasut wrote:
Agreed, but I expected there was some dead code and that was the point I was trying to express ;-)
Well, until you do a thorough analysis, you really have no idea if there is any dead code at all.
I don't ... but Viktor probably does and I believe that's what he wants to ask about.
Yes I do the analysis, actually only one method is used (PCI_mapBIOSImage), but there are two other methods related to video card. Booth in file drivers/bios_emulator/atibios.c (PCI_mapBIOSImage, PCI_unmapBIOSImage). Nothing calls they but I think they can be preserved too.
But there are a lots of other code which can be removed. For example BE_mapRealPointer() from drivers/bios_emulator/biosemu.c or BE_getVESABuf() from same file. So my question is: It is safe remove dead code or somebody can use it for debugging purposes ? I've got same problem with another driver so this is general question.
Best regards, Viktor Krivak
Hi Viktor,
On Wed, Mar 28, 2012 at 9:46 AM, Viktor Křivák viktor.krivak@gmail.com wrote:
Dear Timur Tabi,
2012/3/27 Marek Vasut marex@denx.de:
Dear Timur Tabi,
Marek Vasut wrote:
Agreed, but I expected there was some dead code and that was the point I was trying to express ;-)
Well, until you do a thorough analysis, you really have no idea if there is any dead code at all.
I don't ... but Viktor probably does and I believe that's what he wants to ask about.
Yes I do the analysis, actually only one method is used (PCI_mapBIOSImage), but there are two other methods related to video card. Booth in file drivers/bios_emulator/atibios.c (PCI_mapBIOSImage, PCI_unmapBIOSImage). Nothing calls they but I think they can be preserved too.
But there are a lots of other code which can be removed. For example BE_mapRealPointer() from drivers/bios_emulator/biosemu.c or BE_getVESABuf() from same file. So my question is: It is safe remove dead code or somebody can use it for debugging purposes ? I've got same problem with another driver so this is general question.
What exactly is the problem?
Wolfgang previously pointed out:
"Did you check if you really find any such code in your linked image? As I already explained, normally -ffunction-sections / -fdata-sections with --gc-sections should make sure any unused functions get dropped automatically."
If these linker options successfully remove all of the dead code, then there should be no urgency in removing it. However, if you are experiencing compile errors due to unused functions, then yes, removing the dead code should be investigated. But if you plan to remove any code, make sure that there are no other boards which may potentially use the code you plan to remove
Regards,
Graeme
Dear Graeme Russ,
Hi Viktor,
On Wed, Mar 28, 2012 at 9:46 AM, Viktor Křivák viktor.krivak@gmail.com
wrote:
Dear Timur Tabi,
2012/3/27 Marek Vasut marex@denx.de:
Dear Timur Tabi,
Marek Vasut wrote:
Agreed, but I expected there was some dead code and that was the point I was trying to express ;-)
Well, until you do a thorough analysis, you really have no idea if there is any dead code at all.
I don't ... but Viktor probably does and I believe that's what he wants to ask about.
Yes I do the analysis, actually only one method is used (PCI_mapBIOSImage), but there are two other methods related to video card. Booth in file drivers/bios_emulator/atibios.c (PCI_mapBIOSImage, PCI_unmapBIOSImage). Nothing calls they but I think they can be preserved too.
But there are a lots of other code which can be removed. For example BE_mapRealPointer() from drivers/bios_emulator/biosemu.c or BE_getVESABuf() from same file. So my question is: It is safe remove dead code or somebody can use it for debugging purposes ? I've got same problem with another driver so this is general question.
What exactly is the problem?
Wolfgang previously pointed out:
"Did you check if you really find any such code in your linked image? As I already explained, normally -ffunction-sections / -fdata-sections with --gc-sections should make sure any unused functions get dropped automatically."
If these linker options successfully remove all of the dead code, then there should be no urgency in removing it. However, if you are experiencing compile errors due to unused functions, then yes, removing the dead code should be investigated. But if you plan to remove any code, make sure that there are no other boards which may potentially use the code you plan to remove
Greame, it's the UDM plight ... killing all dead code really helps streamlining the API.
Regards,
Graeme
Best regards, Marek Vasut
Hi Marek,
On Wed, Mar 28, 2012 at 10:46 AM, Marek Vasut marex@denx.de wrote:
Dear Graeme Russ,
Hi Viktor,
On Wed, Mar 28, 2012 at 9:46 AM, Viktor Křivák viktor.krivak@gmail.com
wrote:
Dear Timur Tabi,
2012/3/27 Marek Vasut marex@denx.de:
Dear Timur Tabi,
Marek Vasut wrote:
Agreed, but I expected there was some dead code and that was the point I was trying to express ;-)
Well, until you do a thorough analysis, you really have no idea if there is any dead code at all.
I don't ... but Viktor probably does and I believe that's what he wants to ask about.
Yes I do the analysis, actually only one method is used (PCI_mapBIOSImage), but there are two other methods related to video card. Booth in file drivers/bios_emulator/atibios.c (PCI_mapBIOSImage, PCI_unmapBIOSImage). Nothing calls they but I think they can be preserved too.
But there are a lots of other code which can be removed. For example BE_mapRealPointer() from drivers/bios_emulator/biosemu.c or BE_getVESABuf() from same file. So my question is: It is safe remove dead code or somebody can use it for debugging purposes ? I've got same problem with another driver so this is general question.
What exactly is the problem?
Wolfgang previously pointed out:
"Did you check if you really find any such code in your linked image? As I already explained, normally -ffunction-sections / -fdata-sections with --gc-sections should make sure any unused functions get dropped automatically."
If these linker options successfully remove all of the dead code, then there should be no urgency in removing it. However, if you are experiencing compile errors due to unused functions, then yes, removing the dead code should be investigated. But if you plan to remove any code, make sure that there are no other boards which may potentially use the code you plan to remove
Greame, it's the UDM plight ... killing all dead code really helps streamlining the API.
Ah, I see - Well, I won't stand in the way of progress ;)
Regards,
Graeme
Dear Graeme Russ,
Hi Marek,
On Wed, Mar 28, 2012 at 10:46 AM, Marek Vasut marex@denx.de wrote:
Dear Graeme Russ,
Hi Viktor,
On Wed, Mar 28, 2012 at 9:46 AM, Viktor Křivák viktor.krivak@gmail.com
wrote:
Dear Timur Tabi,
2012/3/27 Marek Vasut marex@denx.de:
Dear Timur Tabi,
Marek Vasut wrote: > Agreed, but I expected there was some dead code and that was the > point I was trying to express ;-)
Well, until you do a thorough analysis, you really have no idea if there is any dead code at all.
I don't ... but Viktor probably does and I believe that's what he wants to ask about.
Yes I do the analysis, actually only one method is used (PCI_mapBIOSImage), but there are two other methods related to video card. Booth in file drivers/bios_emulator/atibios.c (PCI_mapBIOSImage, PCI_unmapBIOSImage). Nothing calls they but I think they can be preserved too.
But there are a lots of other code which can be removed. For example BE_mapRealPointer() from drivers/bios_emulator/biosemu.c or BE_getVESABuf() from same file. So my question is: It is safe remove dead code or somebody can use it for debugging purposes ? I've got same problem with another driver so this is general question.
What exactly is the problem?
Wolfgang previously pointed out:
"Did you check if you really find any such code in your linked image? As I already explained, normally -ffunction-sections / -fdata-sections with --gc-sections should make sure any unused functions get dropped automatically."
If these linker options successfully remove all of the dead code, then there should be no urgency in removing it. However, if you are experiencing compile errors due to unused functions, then yes, removing the dead code should be investigated. But if you plan to remove any code, make sure that there are no other boards which may potentially use the code you plan to remove
Greame, it's the UDM plight ... killing all dead code really helps streamlining the API.
Ah, I see - Well, I won't stand in the way of progress ;)
Perfection is reached, not when there is no longer anything to add, but when there is no longer anything to take away.
-- Antoine de Saint-Exupery
;-)
Regards,
Graeme
Best regards, Marek Vasut
Dear Graeme Russ,
Marek,
Perfection is reached, not when there is no longer anything to add, but when there is no longer anything to take away.
-- Antoine de Saint-Exupery
And:
Not all that is simple is perfect. However, all that is perfect is simple
-- Unkown
:)
That's been one of my mantras - focus and simplicity. Simple can be harder than complex: You have to work hard to get your thinking clean to make it simple. But it's worth it in the end because once you get there, you can move mountains.
-- Steve Jobs
;-)
Best regards, Marek Vasut
Dear Marek and Wolfgang,
2012/3/26 Wolfgang Denk wd@denx.de:
Dear Marek Vasut,
In message 201203261243.19732.marex@denx.de you wrote:
I pretty sure because I try compile it without this driver and everything seems to be ok.
In the given configurations, the BIOS code only gets built when you the ATI Radeon support is enabled, in which case it is needed.
If you don't enable either, then it's fine as well - but then the BIOS code does not get built anyway.
But we probably want this driver to work, so ...
I'm not sure what your comment means.
If you want to use this driver, then enable it in the configuration; this will mean the BIOS emulator also gets built and linked, and it will be needed to initialize the card's BIOS.
Everything is fine. No problems anywhere.
What exactly was your concern?
I think here may be a little misunderstanding. I don't want to remove whole driver. I only want to remove support of bios emulator form that 2 board because I think they don't use it. I try compile it without this driver and everything seems to be ok.
Best regards,
Viktor Krivak
Hi Viktor,
On Mon, 26 Mar 2012 15:47:57 +0200 Viktor Křivák viktor.krivak@gmail.com wrote: ...
What exactly was your concern?
I think here may be a little misunderstanding. I don't want to remove whole driver. I only want to remove support of bios emulator form that 2 board because I think they don't use it. I try compile it without this driver and everything seems to be ok.
BIOS emulator support is conditionally enabled on these boards, currently in mainline U-Boot it is deactivated as default. But at least on sequoia I used to activate it from time to time to test changes which may affect ATI video support. So please don't remove this optional BIOS emulator support. If you do not need it, just do not enable it in your board config file.
Thanks, Anatolij
Viktor Křivák wrote:
I think here may be a little misunderstanding. I don't want to remove whole driver. I only want to remove support of bios emulator form that 2 board because I think they don't use it. I try compile it without this driver and everything seems to be ok.
I think it's okay to remove it from the P1022DS board. I think the only reason it is enabled because of some misunderstanding of the BSP requirement, and no one ever noticed.
Dear Timur Tabi,
In message 4F70804A.5030805@freescale.com you wrote:
I think here may be a little misunderstanding. I don't want to remove whole driver. I only want to remove support of bios emulator form that 2 board because I think they don't use it. I try compile it without this driver and everything seems to be ok.
I think it's okay to remove it from the P1022DS board. I think the only reason it is enabled because of some misunderstanding of the BSP requirement, and no one ever noticed.
Please look at the code before posting.
The "#define CONFIG_BIOSEMU" is in a block "#ifdef CONFIG_ATI", and when you enable support for an ATI card you most probably want to enable BIOS emu support as well.
Everything is perfectly fine hre, nothing should be changed.
Best regards,
Wolfgang Denk
participants (7)
-
Anatolij Gustschin -
Graeme Russ -
Marek Vasut -
Marek Vasut -
Timur Tabi -
Viktor Křivák -
Wolfgang Denk