[coreboot] Apollolake: SATA issues
Hi all I have ported coreboot to a custom design based on APL and have random SATA problems with CFast cards. I am using the latest public APL FSP from github with the latest coreboot master. >From time to time the SATA link 'dies' during runtime or I it is not possible to establish the SATA link at all (in the used u-boot payload). At the moment I am running out of ideas and I hope someone can point me in the right direction. Btw. with the vendor blob SATA works with out any problems :/ -- greets -- Christian Gmeiner, MSc https://christian-gmeiner.info/privacypolicy ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Intel APL: calculating CBFS master header position
ff ff3c38d0: ff3c38e0: ff3c38f0: Nope After some try and error I found the real start of the bios region: 0xFF102000 => md 0xFF102000 ff102000: 55aa 0001000d .U.. ff102010: 00010003 08e8003c 0009 <... ff102020: 000a 0200 0010 ff102030: 0005 00149000 000ff000 0001 ff102040: 000c3000 a000 000c .0.. ff102050: 000d ff102060: 0011 0210 0108 0004 ff102070: 1000 000be000 000bf000 ff102080: 4000 000e 000cd000 0001.@.. ff102090: 0002 000dd000 00061000 0003 ff1020a0: 0013e000 9000 000b 00147000.p.. ff1020b0: 2000 . .. ff1020c0: ff1020d0: ff1020e0: ff1020f0: 0xFF102000 + 0x301800 = 0xFF403800 => md 0xFF403800 ff403800: 448bc3ff 408b0424 244489f4 ffd1e904...D$..@..D$ ff403810: 8353 448b18ec 548d2824 5c8b0824..SD$(.T$..\ ff403820: 44892024 448b0824 44892c24 438d0c24$ .D$..D$,.D$..C ff403830: fec0e808 c289 85ffc883 8b1d74d2.t.. ff403840: 0fc08503 508bc344 2474ff04 2474ff0cD..P..t$..t$ ff403850: 2474ff0c 52ff502c 10c48308 5b18c483..t$,P.R...[ ff403860: 835356c3 448b14ec 748b2c24 5c8b2024.VSD$,.t$ .\ ff403870: 44892824 448d0c24 5c890824 8d500824$(.D$..D$..\$.P. ff403880: e850f846 fe42 c085595a 5e2b1874F.P.B...ZY..t.+^ ff403890: 245c89f8 f4468b28 20244489 5b14c483..\$(.F..D$ ...[ ff4038a0: ff6ce95e c483 ffc88314 53c35e5b^.l.[^.S ff4038b0: 8b18ec83 8d282444 8b082454 8920245cD$(.T$..\$ . ff4038c0: 8b082444 892c2444 8d0c2444 23e80843D$..D$,.D$..C..# ff4038d0: 89fe ffc883c2 2674d285 d285138b..t& ff4038e0: 8bd3440f 488b0442 ffc8830c 1274c985.D..B..H..t. ff4038f0: 0c2474ff 0c2474ff 2c2474ff 83d1ff52.t$..t$..t$,R... Still looks wrong - If I subtract an other kb I get the CBFS master header. => md 0xFF402800 ff402800: 4352414c 45564948 2000 0200LARCHIVE... ff402810: 3800 73666263 73616d20...8cbfs mas ff402820: 20726574 64616568 7265 ter header.. ff402830: 4342524f 32313131ORBC1112 ff402840: 00f0e800 0400 4000 00183000...@.0.. ff402850: ff402860: ff402870: ff402880: 4352414c 45564948 4c9a 1000LARCHIVE...L ff402890: 3800 6c6c6166 6b636162...8fallback ff4028a0: 6d6f722f 67617473 0065 /romstage... ff4028b0: fef2 ff4028c0: fef2 9a300... ff4028d0: 9a30 0003ffe8 4800bc00 31fcfef00..H...1 ff4028e0: 5900b9c0 50bffef0 29fef056 83abf3f9...Y...PV..) ff4028f0: 84e8f0e4 eb4f 909066fe 0030001fOf0. I am not sure whats wrong here :( I hope that somebody can push me into the right direction. The end goal is to be able to use u-boot's cbfs to access some files stored there. -- thanks -- Christian Gmeiner, MSc https://christian-gmeiner.info ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: coreboot meets apollolake
Hi
> Hi,
>
> I do not see anything obviously wrong with your configuration.
> Does the flash you use is 16mb or 8mb? IFD defines its own regions and FMAP
> must match IFD.
The flash is 8mb. If IFD gets dump with ifdtool then I have this:
:0fff fd
1000:00100fff res1
00101000:0010 pd
0011:007f bios
> One common issue is that people have IFD that uses 16mb and use FMAP that
> uses 8mb.
> you can find some sample ifds in mainboard/intel/leafhill
>
ifds == *.fmd file that gets processed?
>> Afterwards we tried to open the aforementioned coreboot.rom in
>> FIT.exe. This was not possible however as the tool gave the error
>
>
> This sounds like image was not stitched correctly, which is probably the root
> cause of the problem.
>
If I fit.exe could be more verbose about the problem I would knew where to dig.
> Unfortunately I do not have time to help you debug this issue.
>
> My only recommendation would be to post on coreboot mailing list
> https://www.coreboot.org/Mailinglist
> Please post there, somebody will help you out.
>
Lets hope for the best.
> Hope that helps.
> Andrey
>
> On Tue, Jan 15, 2019 at 3:52 AM Christian Gmeiner
> wrote:
>>
>> Hi Andrey
>>
>> Me and a colleague of mine are busy replacing the stock vendor BIOS on
>> a board our employer gave us with coreboot. The board is equipped with
>> an Apollolake CPU.
>>
>> I have found your presentation regarding coreboot and Apollolake
>> (hxxps://www.coreboot.org/images/2/23/Apollolake_SoC.pdf) and did run
>> into some problems.
>>
>> Let me give you a quick outline of what we did:
>>
>> We took an image from the stock vendor BIOS, removed the OEM signing
>> stuff. We then replaced this with a key pair we created and were able
>> to boot it.
>>
>> Attached to this email you can find the settings XML file we created
>> in the process.
>>
>> We then took the outimage.bin created by the FIT.exe tool and
>> configured it as the IFWI in the coreboot build process, as can be
>> seen below:
>>
>> CONFIG_IFD_BIN_PATH="3rdparty/blobs/mainboard/$(MAINBOARDDIR)/descriptor.bin"
>> CONFIG_NEED_IFWI=y
>> CONFIG_IFWI_FMAP_NAME="IFWI_CORE"
>> CONFIG_IFWI_FILE_NAME="3rdparty/blobs/mainboard/$(CONFIG_MAINBOARD_DIR)/ifwi.bin"
>> CONFIG_HAVE_IFD_BIN=y
>>
>> We also took the first 4k from the image as the "descriptor.bin".
>>
>> The fmd file we came up with is visible below.
>>
>> :0fff fd
>> 1000:00100fff res1
>> 00101000:0010 pd
>> 0011:007f bios
>>
>> FLASH 8M {
>> SI_DESC@0x0 0x1000
>> DEVICE_EXTENSION@0x1000 0x10EFFF
>> IFWI@0x11 0x6f {
>> IFWI_CORE@0x0 0x2ff000
>> FMAP@0x2FF000 0x1000
>> RW_MRC_CACHE@0x30 0x1
>> COREBOOT(CBFS)@0x31 0x10
>> UNUSED_HOLE
>> NOT_MEMORY_MAPPED@0x6B 0x4
>> }
>> }
>>
>> When generating a coreboot.rom image and flashing it to our BIOS flash
>> chip, it wouldn't boot though. We didn't see any post codes at all, so
>> the image is likely not even executed.
>>
>> Afterwards we tried to open the aforementioned coreboot.rom in
>> FIT.exe. This was not possible however as the tool gave the error
>>
>> Error 30: Failed to decompose Full Image.
>> Error 10: Failed to open with processed commands.
>> Unable to open file: U:\Apollo Lake Intel(R) TXE
>> 3.1.60.2280\Tools\FIT\WINDOWS\coreboot.bin. Reverting to default
>> configuration.
>>
>> It seems that we made an error in process. Would you be so kind to
>> have a look at this and point us in the right direction?
>>
>> --
>> Thanks a lot!
>> --
>> Christian Gmeiner, MSc
>>
>> https://christian-gmeiner.info
>
>
>
> --
> Best regards,
> Andrey Petrov
--
greets
--
Christian Gmeiner, MSc
https://christian-gmeiner.info
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org
Re: [coreboot] Kabylake H: SPI Transaction Error at Flash Offset d10000
Hi
Am Fr., 16. Nov. 2018 um 15:57 Uhr schrieb Jose Trujillo via coreboot
:
>
> Hello coreboot engineers:
>
> My Kabylake H system "HM175" with coreboot "bsl6" and "kblrvp" platforms
> with properly configured I/O failed to save Memory training data to the SPI
> cache 'RW_MRC_CACHE'.
>
> FMAP: Found "FLASH" version 1.1 at d0.
> FMAP: base = ff00 size = 100 #areas = 4
> FMAP: area RW_MRC_CACHE found @ d1 (65536 bytes)
> MRC: Checking cached data update for 'RW_MRC_CACHE'.
> SF: Detected FAST_SPI Hardware Sequencer with sector size 0x1000, total
> 0x10
> MRC: no data in 'RW_MRC_CACHE'
> MRC: cache data 'RW_MRC_CACHE' needs update.
> SPI Transaction Error at Flash Offset d1 HSFSTS = 0x01046003
> REGF metadata allocation failed: 392 data blocks 4096 total blocks
> MRC: Could not find region 'UNIFIED_MRC_CACHE'
> FMAP: area RW_MRC_CACHE found @ d1 (65536 bytes)
> MRC: NOT enabling PRR for 'RW_MRC_CACHE'
>
> As a consequence fast boot never works. (fast boot works correctly on my
> coffeelake system).
>
> Nico helped me to test the system ability to save data to the MRC_CACHE block
> from linux booting coreboot and I wrote random data to the 'RW_MRC_CACHE'
> block with the "flashrom" tool succesfully.
>
> Maybe someone that had experience with this issue or have some idea how to
> fix it can give me advise on how to resolve this problem.
>
I run into the same problem: https://review.coreboot.org/c/coreboot/+/29159
Make sure you have this block in your devicetree.cb
# Lock Down
register "common_soc_config" = "{
.chipset_lockdown = CHIPSET_LOCKDOWN_COREBOOT,
}"
--
greets
--
Christian Gmeiner, MSc
https://christian-gmeiner.info
--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Wired problems with Intel skylake based board
Am Di., 16. Okt. 2018 um 11:25 Uhr schrieb Peter Stuge : > > Christian Gmeiner wrote: > > The system does not hang if I only change > > > > mem_cfg->PegDisableSpreadSpectrumClocking = 1; > > > > But it has no effect on the PCIe reference clock and it looks like > > spread spectrum is still used. > > AFAIK Peg refers to PCI Express Graphics. Maybe there's another, > per-port, setting? > Could be but and the comment is about this variable is wrong: https://github.com/coreboot/coreboot/blob/f3122426b851b9ca009e501a8d8c60d062f84c98/src/vendorcode/intel/fsp/fsp2_0/skykabylake/FspmUpd.h#L534 -- greets -- Christian Gmeiner, MSc https://christian-gmeiner.info -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Wired problems with Intel skylake based board
Hi
Am Mo., 15. Okt. 2018 um 15:26 Uhr schrieb Naresh G. Solanki
:
>
> Hi,
>
> There are two things here.
> 1. System fails to boot i.e., hangs
Correct.
> 2. FPGA's connected to root port are not detected in FW/OS
Wrong. The FPGAs are detected correctly and work most of the time. The only
problem we have is that the PCIe reference clock is not 100MHz as
spread spectrum
is activated. This causes that the internal clock used for EtherCAT
ist not reliable
which has the result that we fail to sync with EtherCAT clients and
there no communication
over EtherCAT works.
>
> For problem 1, can you give data on where exactly it hangs?, Is it in
> OS or FW ?, Can you provide kernel/coreboot log, port 80 dump when it
> hangs.
It only hangs If I change the following values:
mem_cfg->PegDisableSpreadSpectrumClocking = 1;
mem_cfg->PchPmPciePllSsc = 0;
The 'physical' cause for the hang is also known: PLT_RST# never gets
high again. There are chances
that it does not hang but PCI devices (sata, usb hc, ...) are not
working as expected as the PCe reference clock
is in such a case at around 92 Mhz.
The end goal is to disable PCIe Spread Specturm and get a constant
PCIe reference clock
of 100MHz.
The system does not hang if I only change
mem_cfg->PegDisableSpreadSpectrumClocking = 1;
But it has no effect on the PCIe reference clock and it looks like
spread spectrum is still used.
> For problem 2, Can you try setting UPD PcieRpHotPlug, & check the
> behaviour. reference:
> https://review.coreboot.org/cgit/coreboot.git/tree/src/soc/intel/skylake/chip_fsp20.c#n300
>
> Can you please check FPGA datasheet & check for frequency tolerance of
> PCIE_CLK_REF signal from FPGA.
> Also can you re-verify board layout for any PDG(Platform Design Guide)
> violations like impedance, length matching, limits for differential
> PCIE_CLK_REF, PCIe Lanes.
> Sometimes noise generated within board can generate huge EMI. I assume
> high noisy circuits(power supply, backlight driver etc) are kept away
> from high speed PCIe signals.
>
> Regards,
> Naresh G Solanki
> On Mon, Oct 15, 2018 at 5:37 PM Christian Gmeiner
> wrote:
> >
> > Am Fr., 12. Okt. 2018 um 10:15 Uhr schrieb Nico Huber :
> > >
> > > On 10/11/18 11:29 AM, Christian Gmeiner wrote:
> > > > During the last weeks I found the root cause of my problem - PCIe
> > > > spread spectrum
> > > >
> > > > Our FPGAs need a stable 100MHz PCIE clock to work. The used FSP config
> > > > thing looked
> > > > like this:
> > > >
> > > > void mainboard_memory_init_params(FSPM_UPD *mupd)
> > > > {
> > > > FSP_M_CONFIG *mem_cfg;
> > > > struct spd_block blk = {
> > > > .addr_map = { 0x50 },
> > > > };
> > > >
> > > > mem_cfg = >FspmConfig;
> > > >
> > > > mem_cfg->PegDisableSpreadSpectrumClocking = 1;
> > > > mem_cfg->PchPmPciePllSsc = 0;
> > > >
> > > > ...
> > > > }
> > > >
> > > > With this configuration the PCIe reference clock was off more then 8%
> > > > which
> > > > caused the system to hang during cold and warm boots.
> > > >
> > > > In the next step I removed assignment of PchPmPciePllSsc as it is
> > > > documented
> > > > as 'No BIOS override'. With this change I got more then 1000 soft and
> > > > 2000 hard reboots
> > > > without any problem. Keep in mind we started with only 10 successful
> > > > reboots.
> > >
> > > Please be more specific about the final setting of this UPD. `No BIOS
> > > override` is the documentation for the default value of 0xff. But is
> > > this set to the default in the binary? who knows...
> > >
> >
> > void mainboard_memory_init_params(FSPM_UPD *mupd)
> > {
> > FSP_M_CONFIG *mem_cfg;
> > struct spd_block blk = {
> > .addr_map = { 0x50 },
> > };
> >
> > mem_cfg = >FspmConfig;
> >
> > /* Disable PCIe Spread Spectrum Clocking */
> > printk(BIOS_ERR, "PegDisableSpreadSpectrumClocking: %x\n",
> > mem_cfg->PegDisableSpreadSpectrumClocking);
> > printk(BIOS_ERR, "PchPmPciePllSsc: %x\n", mem_cfg->PchPmPciePllSsc);
> > mem_cfg->PegDisableSpreadSpectrumClocking = 1;
> >
> > get_spd_smbus();
> > dump_spd_info();
> > assert(blk.spd_array[0][0] != 0);
> >
> > mainboard_fill_dq_map_data(_cfg->DqByteMapCh0);
> > mainboard_fill_dqs
Re: [coreboot] Wired problems with Intel skylake based board
Am Fr., 12. Okt. 2018 um 10:15 Uhr schrieb Nico Huber :
>
> On 10/11/18 11:29 AM, Christian Gmeiner wrote:
> > During the last weeks I found the root cause of my problem - PCIe
> > spread spectrum
> >
> > Our FPGAs need a stable 100MHz PCIE clock to work. The used FSP config
> > thing looked
> > like this:
> >
> > void mainboard_memory_init_params(FSPM_UPD *mupd)
> > {
> > FSP_M_CONFIG *mem_cfg;
> > struct spd_block blk = {
> > .addr_map = { 0x50 },
> > };
> >
> > mem_cfg = >FspmConfig;
> >
> > mem_cfg->PegDisableSpreadSpectrumClocking = 1;
> > mem_cfg->PchPmPciePllSsc = 0;
> >
> > ...
> > }
> >
> > With this configuration the PCIe reference clock was off more then 8% which
> > caused the system to hang during cold and warm boots.
> >
> > In the next step I removed assignment of PchPmPciePllSsc as it is documented
> > as 'No BIOS override'. With this change I got more then 1000 soft and
> > 2000 hard reboots
> > without any problem. Keep in mind we started with only 10 successful
> > reboots.
>
> Please be more specific about the final setting of this UPD. `No BIOS
> override` is the documentation for the default value of 0xff. But is
> this set to the default in the binary? who knows...
>
void mainboard_memory_init_params(FSPM_UPD *mupd)
{
FSP_M_CONFIG *mem_cfg;
struct spd_block blk = {
.addr_map = { 0x50 },
};
mem_cfg = >FspmConfig;
/* Disable PCIe Spread Spectrum Clocking */
printk(BIOS_ERR, "PegDisableSpreadSpectrumClocking: %x\n",
mem_cfg->PegDisableSpreadSpectrumClocking);
printk(BIOS_ERR, "PchPmPciePllSsc: %x\n", mem_cfg->PchPmPciePllSsc);
mem_cfg->PegDisableSpreadSpectrumClocking = 1;
get_spd_smbus();
dump_spd_info();
assert(blk.spd_array[0][0] != 0);
mainboard_fill_dq_map_data(_cfg->DqByteMapCh0);
mainboard_fill_dqs_map_data(_cfg->DqsMapCpu2DramCh0);
mainboard_fill_rcomp_res_data(_cfg->RcompResistor);
mainboard_fill_rcomp_strength_data(_cfg->RcompTarget);
mem_cfg->DqPinsInterleaved = TRUE;
mem_cfg->MemorySpdDataLen = blk.len;
mem_cfg->MemorySpdPtr00 = (uintptr_t) blk.spd_array[0];
}
And here is the output taken from cbmem -1:
..
FMAP: base = ff00 size = 100 #areas = 4
FMAP: area RW_MRC_CACHE found @ a5 (65536 bytes)
MRC: no data in 'RW_MRC_CACHE'
PegDisableSpreadSpectrumClocking: 0
PchPmPciePllSsc: ff
SPD @ 0x50
SPD: module type is DDR4
..
> >
> > The big problem is that PegDisableSpreadSpectrumClocking has no effect
> > at all. I measured
> > the freq it is not the 100MHz as expected. And I need to have a stable
> > 100MHz this clock source
> > is used internally by the FPGA to drive internal clocks. The end
> > results is that EtherCAT is not
> > able to sync.
>
> This setting is about a different clock, I guess. Can you please clarify
> what is connected to which clock on your board.
>
Our FPGAs are using the 100 MHz PCIe clock as input to drive internal
clocks etc. One
of these clock is used for EtherCAT. If spread spectrum is active we
are around 100 MHz
(worst measured freq was ~92 MHz) and as a result the internal FPGA clock is not
stable/reliable --> EtherCAT sync fails.
If I use the following pattern:
mem_cfg->PegDisableSpreadSpectrumClocking = 1;
mem_cfg->PchPmPciePllSsc = 0;
I get a stable 100 MHz PCIe clock signal and everything works - except
the device hangs
after < 10 warm reboots. Looks like PCIe link training fails
uncountable times (seen with protocol
analyzer).
--
greets
--
Christian Gmeiner, MSc
https://christian-gmeiner.info
--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Wired problems with Intel skylake based board
Am Di., 25. Sep. 2018 um 12:27 Uhr schrieb Peter Stuge :
>
> Christian Gmeiner wrote:
> > Most of the time the system works as expected but from time to rebooting
> > the system fails completely.
>
> Only ever when rebooting, or does cold boot also fail sometimes?
>
Both fail.
> (Make a test system to cold boot your system in a loop.)
>
>
> > there are two FPGAs connected via PCIe to the system where one is used
> > to reset the system. The reset is done via SYS_RESET#.
>
> Are the FPGAs also reset by that?
>
Yes
> If yes, how long do they need to initialize to where HDL acts
> correctly on PCIe?
>
I would need to measure this but i would say less then 300ms.
>
> > Now I run into different kind of issues:
> > - pcie link training fails from time to time
>
> On both links, or only one of them? Can you tell?
>
This is hard to tell.. all I see that the link gets reset quite fast
and quite often.
>
> > - looks like PLTRST# of the sunrisepoint pch holds the system in reset
> > for minutes.
>
> I don't know if there's enough PCH documentation to know exactly why
> it would do that - but I can imagine that it holds reset as long as
> some conditions are not met, I can also imagine that the FPGAs cause
> some undefined PCIe behavior in the PCH which happens to get it stuck
> in reset for a while.
>
>
> > Are there any hints to debug my issues?
>
> As always, try to isolate the problem.
>
> Can you completely remove one or ideally both FPGAs from the equation?
>
> You mention that one of them is used for reset. At least disable the
> other one, destructively if need be.
>
During the last weeks I found the root cause of my problem - PCIe
spread spectrum
Our FPGAs need a stable 100MHz PCIE clock to work. The used FSP config
thing looked
like this:
void mainboard_memory_init_params(FSPM_UPD *mupd)
{
FSP_M_CONFIG *mem_cfg;
struct spd_block blk = {
.addr_map = { 0x50 },
};
mem_cfg = >FspmConfig;
mem_cfg->PegDisableSpreadSpectrumClocking = 1;
mem_cfg->PchPmPciePllSsc = 0;
...
}
With this configuration the PCIe reference clock was off more then 8% which
caused the system to hang during cold and warm boots.
In the next step I removed assignment of PchPmPciePllSsc as it is documented
as 'No BIOS override'. With this change I got more then 1000 soft and
2000 hard reboots
without any problem. Keep in mind we started with only 10 successful reboots.
The big problem is that PegDisableSpreadSpectrumClocking has no effect
at all. I measured
the freq it is not the 100MHz as expected. And I need to have a stable
100MHz this clock source
is used internally by the FPGA to drive internal clocks. The end
results is that EtherCAT is not
able to sync.
I tried to change the ICC config via MEI messaging but I am not able
to change the clock settings
even with an successful return code.
--
greets
--
Christian Gmeiner, MSc
https://christian-gmeiner.info
--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot
[coreboot] Wired problems with Intel skylake based board
Hi all I have an almost working coreboot/u-boot boot solution based on kabylake FSP. Most of the time the system works as expected but from time to rebooting the system fails completely. On my board, which is powered by an COM Express module (i3-6100U), there are two FPGAs connected via PCIe to the system where one is used to reset the system. The reset is done via SYS_RESET#. Now I run into different kind of issues: - pcie link training fails from time to time multiple times with the end result at FSP does multiple global resets. - looks like PLTRST# of the sunrisepoint pch holds the system in reset for minutes. Are there any hints to debug my issues? -- greets -- Christian Gmeiner, MSc https://christian-gmeiner.info -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] setting smbios values from the OS
2014-06-16 19:05 GMT+02:00 Rafael Vanoni rafael.van...@pluribusnetworks.com: On 06/13/2014 09:40 AM, Marc Jones wrote: Rafael, i don't think that you can update them once the OS loads. The OS would have already made decisions based on the settings. Marc On Tue, Jun 10, 2014 at 7:41 PM, Rafael Vanoni rafael.van...@pluribusnetworks.com wrote: Hi folks, first time posting here. I was wondering if it would be possible to modify smbios values once a system is up and running. Has anyone ever looked into that? If not, any pointers on how to implement this would be greatly appreciated. I'm fairly new to coreboot but would like to look into this. This is with coreboot + seabios, btw. Thanks, Rafael Hi Marc, That's true, but my intention is to modify more 'informational' fields like version, sn, etc. Nothing that would break the OS. Wrong: http://lxr.free-electrons.com/ident?i=DMI_MATCH You can modify dmi values in coreboot - see bachmann/ot205 greets -- Christian Gmeiner, MSc https://soundcloud.com/christian-gmeiner -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] AMD Geode LX800 - CS5536 with Coreboot v3?
Hi 2014-01-30 Darmawan Salihun darmawan.sali...@gmail.com: Hi Kyosti, On 1/30/14, Kyösti Mälkki kyosti.mal...@gmail.com wrote: On 01/30/2014 09:41 AM, Darmawan Salihun wrote: Hi all, Is it still possible to use Coreboot v3 for an AMD Geode LX800-CS5536 board? Or do I have to resort to other Coreboot version? You might be very much on your own just with the v3 build environment. I think bachmann/ot200 board is one of the most recent boards with Geode LX + CS5536 and some testing on coreboot v4. I am the maintainer of the bachmann/ot200 mainboard and current git runs well on the device. OK. I'll have a look at Coreboot v4. Is this where to clone it from: http://review.coreboot.org/coreboot.git http://review.coreboot.org/gitweb?p=coreboot.git greets -- Christian Gmeiner, MSc -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Shortened in types (u32) vs stdint types (uint32_t)
2014-01-29 David Woodhouse dw...@infradead.org: On Tue, 2014-01-28 at 13:11 -0600, mrnuke wrote: As a result, I propose we make stdint types mandatory, and deprecate shortname types. People don't want to learn a separate set of data types for every project to which they contribute. stdint types solve this problem by being standardized. I am far from liking this change, but it just makes sense. Right. The short ones are a hangover from before C99 added the real, standard types. We really don't want to be screwing around with non-standard nonsense like DWORD, u32, and whatever the BSDs use which ISTR is different again. Just join us in the 21st century and use the C standard types. Yes, they're different to what you were used to in the last millennium. You'll get over it. I have the same opinion - use the types C99 provides. greets -- Christian Gmeiner, MSc -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Freescale i.MX6
Hi Wolfgang thank you for your quick response. If there is actually no active effort to support i.MX6, I’m interested in leading that project. But I cannot start before the end of the year because I have to wait for our hardware and to bring-up the board first with u-boot. I think that I could spend 2-3 days to look into initial support for the I.MX6 during the next 2-3 weeks. Another point is to think about hardware donation. I have access to some I.MX6D and one I.MX6Q boards.. also I own a ARM jtag. So I have all I need :) greets -- Christian Gmeiner, MSc -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Freescale i.MX6
2013/9/20 defa...@rlf.de: On Fri, 20 Sep 2013 12:53:07 +0200 Christian Gmeiner christian.gmei...@gmail.com wrote: Hi Guys. thank you for your quick response. If there is actually no active effort to support i.MX6, I’m interested in leading that project. But I cannot start before the end of the year because I have to wait for our hardware and to bring-up the board first with u-boot. I think that I could spend 2-3 days to look into initial support for the I.MX6 during the next 2-3 weeks. well I can give you a git-link for an U-Boot already running and kicking on i.MX6 (DQ), it's DT/FDT capable. If you want to cut this short. u-boot... I am using mainline u-boot.git for a custom I.MX6D board.. but thanks. Another point is to think about hardware donation. I have access to some I.MX6D and one I.MX6Q boards.. also I own a ARM jtag. So I have all I need :) I also have access to i.MX6D/Q boards, no JTAG/OLIMEX though. -- Christian Gmeiner, MSc -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] AMD LX northbridge question
Looking at src / northbridge / amd / lx / northbridge.c I see a the
following lines:
400 static void pci_domain_enable(device_t dev)
401 {
402 printk(BIOS_SPEW, Entering northbridge.c: %s\n, __func__);
403
404 // do this here for now -- this chip really breaks our device model
405 northbridge_init_early();
406 cpubug();
407 chipsetinit();
http://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/northbridge/amd/lx/northbridge.c;h=6eae35298ac13b29b3815a72378b9f09e90d8dd5;hb=HEAD#l404
Can somebody tell me why this chip really breaks our device model?
And what would
be the correct way to do it?
thanks
--
Christian Gmeiner, MSc
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [use Piratenpad] List of ideas for coreboot meeting on Sunday and Monday in Berlin
2013/5/24 Paul Menzel paulepan...@users.sourceforge.net: Dear coreboot folks, for some seconds I missed, that in #coreboot Patrick already announced to use the login-less Piratenpad for this purpose [1]. Please use that for the idea listing instead of the mailing list. Thanks, Paul [1] http://piratenpad.de/p/coreboot-summit-2013 I wish I could attend the hackfest :/ Maybe next time... -- Christian Gmeiner, MSc -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Exposing performance data to user space/systemd
Hi Paul as LinuxTag approaches and some of the systemd developers are going to be there, I remembered the discussion how systemd only supports exposing performance data on EFI systems [1]. Christian already brought up coreboot/SeaBIOS in that discussion. H. Peter Anvin (Syslinux) also voiced a need for a having that for non-EFI systems. Christin, are there any news? The biggest problem is the defined interface between the coreboot and systemd. Thanks to the CBMEM console, the cbmem utility can read, and the timer work, we have performance data available now. If I am not mistaken, Chrome OS also supports reading these values. So maybe such an interface could be designed during LinuxTag and implemented afterward. In the next weeks I will find some time for some coreboot work and maybe I will get something up and running. greets -- Christian Gmeiner, MSc -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Recording the LinuxTag talks
2013/5/21 Carl-Daniel Hailfinger c-d.hailfinger.devel.2...@gmx.net: Hi, would someone please be so kind and record the coreboot talks at LinuxTag? A few of my colleagues can't be at LinuxTag, but they have expressed interest in watching the talks if any recording is made available. Thanks in advance! that would be great! -- Christian Gmeiner, MSc -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Can the LiPPERT Cool RoadRunner-LX image be used for Gene 5315 Rev.B?
2013/3/28 sergey serg99...@mail.ru: Hello everybody, Dear Paul wrote: Could you please provide an URL for this board and the information listed in the FAQ »Will coreboot work on my machine?« [2]. 1. Board vendor: AAEON Board name: Gene5315 Rev.B CPU: AMD Geode LX 800 Northbridge: AMD Geode™ LX Southbridge: AMD Geode™ CS5536 ROM chip package: PLCC looks like a normal LX800 device... should be doable to support without much time needed. 2. Output of lspci -tvnn: k2000@k2000-desktop:~$ lspci -tvnn -[:00]-+-01.0 Advanced Micro Devices [AMD] CS5536 [Geode companion] Host Bridge [1022:2080] +-01.1 Advanced Micro Devices [AMD] Geode LX Video [1022:2081] +-01.2 Advanced Micro Devices [AMD] Geode LX AES Security Block [1022:2082] +-06.0 Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ [10ec:8139] +-09.0 Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ [10ec:8139] +-0f.0 Advanced Micro Devices [AMD] CS5536 [Geode companion] ISA [1022:2090] +-0f.2 Advanced Micro Devices [AMD] CS5536 [Geode companion] IDE [1022:209a] +-0f.3 Advanced Micro Devices [AMD] CS5536 [Geode companion] Audio [1022:2093] +-0f.4 Advanced Micro Devices [AMD] CS5536 [Geode companion] OHC [1022:2094] \-0f.5 Advanced Micro Devices [AMD] CS5536 [Geode companion] EHC [1022:2095] k2000@k2000-desktop:~$ 3. Super I/O: ITE IT8712F 4. Output of flashrom -V: k2000@k2000-desktop:~$ flashrom -V flashrom v0.9.6.1-r1564 on Linux 2.6.32-38-generic (i586) flashrom is free software, get the source code at http://www.flashrom.org flashrom was built with libpci 3.0.0, GCC 4.4.3, little endian Command line (1 args): flashrom -V Please select a programmer with the --programmer parameter. Valid choices are: internal, dummy, nic3com, nicrealtek, gfxnvidia, drkaiser, satasii, serprog, buspirate_spi, rayer_spi, pony_spi, nicintel, nicintel_spi, ogp_spi, satamv, linux_spi k2000@k2000-desktop:~$ try to use this and post the output flashrom --programmer internal -V 5. URL for board Gene5315 Rev.B [1]. Dear Paul wrote: You should try it. Just make sure you have a way to recover from a failed flash, when it does not work as also documented in the FAQ [4]. I tryed to record coreboot in bios chip. Coreboot could not to run system. Does this mean you can recover from a bad coreboot rom? greets -- Christian Gmeiner, MSc -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] i915tool
2013/2/21 ron minnich rminn...@gmail.com:
I just updated it.
https://code.google.com/p/i915tool/
I had to wait, starting some time ago, because there was too much info
appearing in it about this:
http://techland.time.com/2013/02/21/googles-chomebook-pixel-the-chromebook-goes-high-end/
and I got nervous.
Status: you'll see in as we upstream the coreboot that we can turn on
graphics in coreboot now without a vbios. The code is crude and I'm in
the process of creating a replacement. The tool to create the real
code is in the i915tool and is called gen915code.c. Note that it does
lot of annotation, turning things like this:
{W, 1, , _PIPEACONF, 0x0040, },
{W, 1, , _PIPEACONF, (/* PIPECONF_FRAME_START_DELAY_MASK */0x027)|
PIPECONF_BPP_6 | PIPECONF_DITHER_TYPE_SP |0x0
What this means is that moving to other laptops *may* be easier.
We've got kernel patches too, and the result is that we've (in an
experiment) reduced boot time to a login prompt to less than 4 seconds
(after firmware is finished).
My goal is to make that better, but we'll see. But we chopped a full 3
seconds off of boot.
I am sorry this i915tool is a mess. I really wish it were better. I
offer it in the state it is because I'm hoping it can be used, but
it's very experimental and represents a lot of lessons learned the
hard way. Part of this mess is that my ideas about how to do the work
have changed so much since I started it.
Here are docs, which are also not very good, sorry!
https://docs.google.com/document/d/1g8FMob25VZYxbWri2iFB8YiSL8gwF9vKJH3HGxr0xQU/edit?usp=sharing
Questions to me. Hope that some part of this is useful.
nice!
--
Christian Gmeiner, MSc
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [SeaBIOS] USB Problems geode lx800
2012/10/28 Kevin O'Connor ke...@koconnor.net On Thu, Oct 18, 2012 at 12:25:58PM +0200, Christian Gmeiner wrote: 2012/10/17 Kevin O'Connor ke...@koconnor.net: The controller is supposed to update the toggle bit in the qh. The same qh is used for all transfers, so it should already be up to date between transfers. It is possible something subtle is going on here. USB is finally working :) http://dpaste.com/815054/ Great! Can you post the EHCI patch you used to make this work? I will.. but it will take some time as I am currently out of office, I am at LinuxCon in Barcelona at the moment :) -- Christian Gmeiner, MSc Thanks, -Kevin -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [SeaBIOS] USB Problems geode lx800
2012/10/17 Kevin O'Connor ke...@koconnor.net: On Wed, Oct 17, 2012 at 07:42:33AM +0200, Christian Gmeiner wrote: 2012/10/17 Kevin O'Connor ke...@koconnor.net: On Tue, Oct 16, 2012 at 04:11:08PM +0200, Christian Gmeiner wrote: I have made some success to get USB working - current SeaBios ehci driver does not support toggling between DATA0 and DATA1. Here is my current patch to get a little bit more running: The toggle bit should be updated automatically by the controller. It should not be necessary to do it manually. If this is impacting your results, something subtle must going on. Maybe you are right (starred at the spec for some minutes), but who updates the toggle bit in the qh? So I think that this line is needed: pipe-qh.token|= (pipe-pipe.toogle?QTD_TOGGLE:0); The controller is supposed to update the toggle bit in the qh. The same qh is used for all transfers, so it should already be up to date between transfers. It is possible something subtle is going on here. USB is finally working :) http://dpaste.com/815054/ But the next problems says hello: handle_hwpic1 irq=0 Some hints? --- Christian Gmeiner, MSc -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [SeaBIOS] USB Problems geode lx800
2012/10/17 Kevin O'Connor ke...@koconnor.net: On Tue, Oct 16, 2012 at 04:11:08PM +0200, Christian Gmeiner wrote: 2012/10/15 Kevin O'Connor ke...@koconnor.net: On Sun, Oct 14, 2012 at 07:48:00PM +, Christian Gmeiner wrote: On 11 Oct 2012 16:42, Christian Gmeiner christian.gmei...@gmail.com wrote: 2012/10/11 Christian Gmeiner christian.gmei...@gmail.com: 2012/10/11 Kevin O'Connor ke...@koconnor.net: On Tue, Oct 09, 2012 at 02:31:05PM +0200, Christian Gmeiner wrote: 2012/10/9 Kevin O'Connor ke...@koconnor.net: On Mon, Oct 08, 2012 at 02:14:03PM +0200, Christian Gmeiner wrote: HI all I am running into some usb problems with coreboot seabios: Can you set the debug level to 8 and post the whole log? Also, for timeout issues, having timestamps (via tools/readserial.py tool) sometimes helps. [...] Kevin do you have an idea what could be wrong? I haven't had a chance to take a look at it. Something odd is going on, as it appears the transfer that's failing isn't even being started. I'll see if I can take a look this week. -Kevin He Kevin, I have made some success to get USB working - current SeaBios ehci driver does not support toggling between DATA0 and DATA1. Here is my current patch to get a little bit more running: The toggle bit should be updated automatically by the controller. It should not be necessary to do it manually. If this is impacting your results, something subtle must going on. Maybe you are right (starred at the spec for some minutes), but who updates the toggle bit in the qh? So I think that this line is needed: pipe-qh.token|= (pipe-pipe.toogle?QTD_TOGGLE:0); I can run some tests later... I am out of office the half day. Also if the HC updates the toogle in qtd's it should be readable after the transfer is complete - or? So I will add a debug statement to print the toggle value of all processed qtd... and in theory I should see a DATA0 - DATA1 toggle. ehci-hcd.c from linux: /* Except for control endpoints, we make hardware maintain data * toggle (like OHCI) ... here (re)initialize the toggle in the QH, * and set the pseudo-toggle in udev. Only usb_clear_halt() will * ever clear it. */ So there mus be a way to tell the hardware to maintain the toggle bit on its own or to do it in software? -- Christian Gmeiner MSc -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [SeaBIOS] USB Problems geode lx800
2012/10/15 Kevin O'Connor ke...@koconnor.net:
On Sun, Oct 14, 2012 at 07:48:00PM +, Christian Gmeiner wrote:
On 11 Oct 2012 16:42, Christian Gmeiner christian.gmei...@gmail.com
wrote:
2012/10/11 Christian Gmeiner christian.gmei...@gmail.com:
2012/10/11 Kevin O'Connor ke...@koconnor.net:
On Tue, Oct 09, 2012 at 02:31:05PM +0200, Christian Gmeiner wrote:
2012/10/9 Kevin O'Connor ke...@koconnor.net:
On Mon, Oct 08, 2012 at 02:14:03PM +0200, Christian Gmeiner wrote:
HI all
I am running into some usb problems with coreboot seabios:
Can you set the debug level to 8 and post the whole log? Also, for
timeout issues, having timestamps (via tools/readserial.py tool)
sometimes helps.
[...]
Kevin do you have an idea what could be wrong?
I haven't had a chance to take a look at it. Something odd is going
on, as it appears the transfer that's failing isn't even being
started. I'll see if I can take a look this week.
-Kevin
He Kevin,
I have made some success to get USB working - current SeaBios ehci
driver does not support toggling between
DATA0 and DATA1. Here is my current patch to get a little bit more running:
diff --git a/src/blockcmd.c b/src/blockcmd.c
index 77c690f..a66d7ed 100644
--- a/src/blockcmd.c
+++ b/src/blockcmd.c
@@ -189,6 +189,7 @@ scsi_init_drive(struct drive_s *drive, const char
*s, int prio)
int
cdb_get_inquiry(struct disk_op_s *op, struct cdbres_inquiry *data)
{
+dprintf(1, %s\n, __func__);
struct cdb_request_sense cmd;
memset(cmd, 0, sizeof(cmd));
cmd.command = CDB_CMD_INQUIRY;
@@ -202,6 +203,7 @@ cdb_get_inquiry(struct disk_op_s *op, struct
cdbres_inquiry *data)
int
cdb_get_sense(struct disk_op_s *op, struct cdbres_request_sense *data)
{
+dprintf(1, %s\n, __func__);
struct cdb_request_sense cmd;
memset(cmd, 0, sizeof(cmd));
cmd.command = CDB_CMD_REQUEST_SENSE;
@@ -215,6 +217,7 @@ cdb_get_sense(struct disk_op_s *op, struct
cdbres_request_sense *data)
int
cdb_test_unit_ready(struct disk_op_s *op)
{
+dprintf(1, %s\n, __func__);
struct cdb_request_sense cmd;
memset(cmd, 0, sizeof(cmd));
cmd.command = CDB_CMD_TEST_UNIT_READY;
@@ -227,6 +230,7 @@ cdb_test_unit_ready(struct disk_op_s *op)
int
cdb_read_capacity(struct disk_op_s *op, struct cdbres_read_capacity *data)
{
+dprintf(1, %s\n, __func__);
struct cdb_read_capacity cmd;
memset(cmd, 0, sizeof(cmd));
cmd.command = CDB_CMD_READ_CAPACITY;
diff --git a/src/usb-ehci.c b/src/usb-ehci.c
index 2676615..02463c7 100644
--- a/src/usb-ehci.c
+++ b/src/usb-ehci.c
@@ -204,6 +204,7 @@ ehci_waittick(struct usb_ehci_s *cntl)
yield();
}
// Ring doorbell
+dprintf(1, ring 'doorbell'\n);
writel(cntl-regs-usbcmd, cmd | CMD_IAAD);
// Wait for completion
for (;;) {
@@ -217,6 +218,7 @@ ehci_waittick(struct usb_ehci_s *cntl)
yield();
}
// Ack completion
+dprintf(1, Ack completion\n);
writel(cntl-regs-usbsts, STS_IAA);
}
@@ -495,6 +497,9 @@ ehci_alloc_pipe(struct usbdevice_s *usbdev
return usbpipe;
}
+/* initial value */
+usbpipe-toogle = 0;
+
// Allocate a new queue head.
struct ehci_pipe *pipe;
if (eptype == USB_ENDPOINT_XFER_CONTROL)
@@ -641,6 +646,34 @@ ehci_control(struct usb_pipe *p, int dir, const
void *cmd, int cmdsize
return ret;
}
+static int ehci_set_async_schedule(struct usb_ehci_s *ehcic, int enable)
+{
+dprintf(7, %s: enable %d\n, __func__, enable);
+
+// Set async schedule status.
+u32 cmd = readl(ehcic-regs-usbcmd);
+if (enable)
+cmd |= CMD_ASE;
+else
+cmd = ~CMD_ASE;
+
+writel(ehcic-regs-usbcmd, cmd);
+
+/* Wait for the controller to accept async schedule status.
+ * This shouldn't take too long, but we should timeout nevertheless.
+ */
+enable = enable ? STS_ASS : 0;
+int timeout = 100; /* time out after 100ms */
+while (((readl(ehcic-regs-usbsts) STS_ASS) != enable)
+ timeout--)
+mdelay(1);
+if (timeout 0) {
+dprintf(7, ehci async schedule status change timed out.\n);
+return 1;
+}
+return 0;
+}
+
#define STACKQTDS 4
int
@@ -652,6 +685,12 @@ ehci_send_bulk(struct usb_pipe *p, int dir, void
*data, int datasize)
dprintf(7, ehci_send_bulk qh=%p dir=%d data=%p size=%d\n
, pipe-qh, dir, data, datasize);
+struct usb_ehci_s *ehcic = container_of(
+GET_LOWFLAT(pipe-pipe.cntl), struct usb_ehci_s, usb);
+
+// stop async schedule
+ehci_set_async_schedule(ehcic, 0);
+
// Allocate 4 tds on stack (with required alignment)
u8 tdsbuf[sizeof(struct ehci_qtd) * STACKQTDS + EHCI_QTD_ALIGN - 1];
struct ehci_qtd *tds = (void*)ALIGN((u32)tdsbuf, EHCI_QTD_ALIGN);
@@ -661,12 +700,23 @@ ehci_send_bulk(struct usb_pipe *p, int dir, void
*data, int datasize)
u16 maxpacket = GET_LOWFLAT(pipe-pipe.maxpacket);
int tdpos = 0;
+struct ehci_qtd *last
Re: [coreboot] [SeaBIOS] USB Problems geode lx800
On 11 Oct 2012 16:42, Christian Gmeiner christian.gmei...@gmail.com wrote: Christian Gmeiner, MSc 2012/10/11 Christian Gmeiner christian.gmei...@gmail.com: 2012/10/11 Kevin O'Connor ke...@koconnor.net: On Tue, Oct 09, 2012 at 02:31:05PM +0200, Christian Gmeiner wrote: 2012/10/9 Kevin O'Connor ke...@koconnor.net: On Mon, Oct 08, 2012 at 02:14:03PM +0200, Christian Gmeiner wrote: HI all I am running into some usb problems with coreboot seabios: Can you set the debug level to 8 and post the whole log? Also, for timeout issues, having timestamps (via tools/readserial.py tool) sometimes helps. Attached Hrmm, I guess you've disabled threads in your config? yep... From your log, I see: [14:23:00.5] ehci_send_bulk qh=0x000ef680 dir=0 data=0x6d55 size=31^M [14:23:00.5] ehci_send_bulk qh=0x000ef700 dir=128 data=0x6e3c size=36^M [14:23:00.5] ehci_send_bulk qh=0x000ef700 dir=128 data=0x6d8f size=13^M [14:23:05.5] WARNING - Timeout at ehci_wait_td:542!^M [14:23:05.5] ehci pipe=0x000ef700 cur= tok= next=6b80 td=0x6b80 +status=d0d80^M [14:23:05.5] USB transmission failed^M [14:23:05.5] Unable to configure USB MSC drive.^M This looks like the transfer is stalling in the cdb_get_inquiry() call as part of scsi_init_drive(). The drive is identified okay and at least some transfers look okay, so it doesn't appear to be a controller issue. I've been told some USB sticks are very picky about init order, but I'm surprised to see that this is occuring for you on a variety of USB sticks. It's possible to verify that a stall has occurred - print out tds[i].token for all tds in ehci_send_bulk() on the error path. Does this device still have problems if you soft-reset after a failed boot? Here are the results with some more debug: Cold Reboot |0f7a5000| pmm_malloc zone=0x0f7afe87 handle= size=192 align=40 ret=0x0f7a7bc0 (detail=0x0f7a7d70) |0f7a5000| ehci_control: td at phys(f7a7bc0): status: 80 : token 80e80 |0f7a5000| - cerr: 3, total_len: 0 |0f7a5000| ehci_control: td at phys(f7a7c00): status: 0 : token d00 |0f7a5000| - cerr: 3, total_len: 0 |0f7a5000| ehci_control: td at phys(f7a7c40): status: 0 : token 0 |0f7a5000| - cerr: 0, total_len: 0 |0f7a5000| pmm_free 0x0f7a7bc0 (detail=0x0f7a7d70) |0f7a5000| ehci_alloc_async_pipe 0x0f7a9090 2 |0f7a5000| pmm_malloc zone=0x0f7afe7f handle= size=92 align=80 ret=0x000ef700 (detail=0x0f7a7d70) |0f7a5000| ehci_alloc_async_pipe 0x0f7a9090 2 |0f7a5000| pmm_malloc zone=0x0f7afe7f handle= size=92 align=80 ret=0x000ef680 (detail=0x0f7a7d10) |0f7a5000| ehci_control 0x0f7a7cd0 (dir=128 cmd=8 data=1) |0f7a5000| pmm_malloc zone=0x0f7afe87 handle= size=192 align=40 ret=0x0f7a7bc0 (detail=0x0f7a7ce0) |0f7a5000| ehci_control: td at phys(f7a7bc0): status: 80 : token 80e80 |0f7a5000| - cerr: 3, total_len: 0 |0f7a5000| ehci_control: td at phys(f7a7c00): status: 0 : token d00 |0f7a5000| - cerr: 3, total_len: 0 |0f7a5000| ehci_control: td at phys(f7a7c40): status: 0 : token 1c00 |0f7a5000| - cerr: 3, total_len: 0 |0f7a5000| pmm_free 0x0f7a7bc0 (detail=0x0f7a7ce0) |0f7a5000| pmm_malloc zone=0x0f7afe83 handle= size=48 align=10 ret=0x000fdae0 (detail=0x0f7a7ce0) |0f7a5000| usb_cmd_data id=0x000fdae0 write=0 count=1 bs=36 buf=0x0f7a5f3c |0f7a5000| cbw to device |0f7a5000| ehci_send_bulk qh=0x000ef680 dir=0 data=0x0f7a5e65 size=31 |0f7a5000| before setup: td at phys(f7a5c80): status: 0 : token 0 |0f7a5000| - cerr: 0, total_len: 0 |0f7a5000| ehci_send_bulk: td at phys(f7a5c80): status: 80 : token c80 |0f7a5000| - cerr: 3, total_len: 0 |0f7a5000| Data-In from the device to the host - 36 bytes |0f7a5000| ehci_send_bulk qh=0x000ef700 dir=128 data=0x0f7a5f3c size=36 |0f7a5000| before setup: td at phys(f7a5c80): status: 0 : token 0 |0f7a5000| - cerr: 0, total_len: 0 |0f7a5000| ehci_send_bulk: td at phys(f7a5c80): status: 80 : token d80 |0f7a5000| - cerr: 3, total_len: 0 |0f7a5000| ehci_wait_td: td at phys(f7a5c80): status: 80 : token d80 |0f7a5000| - cerr: 3, total_len: 0 |0f7a5000| ehci_wait_td: td at phys(f7a5c80): status: 80 : token d80 |0f7a5000| - cerr: 3, total_len: 0 |0f7a5000| ehci_wait_td: td at phys(f7a5c80): status: 80 : token d80 |0f7a5000| - cerr: 3, total_len: 0 |0f7a5000| ehci_wait_td: td at phys(f7a5c80): status: 80 : token d80 |0f7a5000| - cerr: 3, total_len: 0 |0f7a5000| ehci_wait_td: td at phys(f7a5c80): status: 80 : token d80 |0f7a5000| - cerr: 3, total_len: 0 |0f7a5000| ehci_wait_td: td at phys(f7a5c80): status: 80 : token d80 |0f7a5000| - cerr: 3, total_len: 0 |0f7a5000| ehci_wait_td: td at phys(f7a5c80): status: 80 : token d80 |0f7a5000| - cerr: 3, total_len: 0 |0f7a5000| ehci_wait_td: td at phys(f7a5c80): status: 80 : token d80 |0f7a5000| - cerr: 3
Re: [coreboot] [SeaBIOS] USB Problems geode lx800
2012/10/11 Kevin O'Connor ke...@koconnor.net: On Tue, Oct 09, 2012 at 02:31:05PM +0200, Christian Gmeiner wrote: 2012/10/9 Kevin O'Connor ke...@koconnor.net: On Mon, Oct 08, 2012 at 02:14:03PM +0200, Christian Gmeiner wrote: HI all I am running into some usb problems with coreboot seabios: Can you set the debug level to 8 and post the whole log? Also, for timeout issues, having timestamps (via tools/readserial.py tool) sometimes helps. Attached Hrmm, I guess you've disabled threads in your config? yep... From your log, I see: [14:23:00.5] ehci_send_bulk qh=0x000ef680 dir=0 data=0x6d55 size=31^M [14:23:00.5] ehci_send_bulk qh=0x000ef700 dir=128 data=0x6e3c size=36^M [14:23:00.5] ehci_send_bulk qh=0x000ef700 dir=128 data=0x6d8f size=13^M [14:23:05.5] WARNING - Timeout at ehci_wait_td:542!^M [14:23:05.5] ehci pipe=0x000ef700 cur= tok= next=6b80 td=0x6b80 +status=d0d80^M [14:23:05.5] USB transmission failed^M [14:23:05.5] Unable to configure USB MSC drive.^M This looks like the transfer is stalling in the cdb_get_inquiry() call as part of scsi_init_drive(). The drive is identified okay and at least some transfers look okay, so it doesn't appear to be a controller issue. I've been told some USB sticks are very picky about init order, but I'm surprised to see that this is occuring for you on a variety of USB sticks. It's possible to verify that a stall has occurred - print out tds[i].token for all tds in ehci_send_bulk() on the error path. Does this device still have problems if you soft-reset after a failed boot? Here are the results with some more debug: Cold Reboot |0f7a5000| pmm_malloc zone=0x0f7afe87 handle= size=192 align=40 ret=0x0f7a7bc0 (detail=0x0f7a7d70) |0f7a5000| ehci_control: td at phys(f7a7bc0): status: 80 : token 80e80 |0f7a5000| - cerr: 3, total_len: 0 |0f7a5000| ehci_control: td at phys(f7a7c00): status: 0 : token d00 |0f7a5000| - cerr: 3, total_len: 0 |0f7a5000| ehci_control: td at phys(f7a7c40): status: 0 : token 0 |0f7a5000| - cerr: 0, total_len: 0 |0f7a5000| pmm_free 0x0f7a7bc0 (detail=0x0f7a7d70) |0f7a5000| ehci_alloc_async_pipe 0x0f7a9090 2 |0f7a5000| pmm_malloc zone=0x0f7afe7f handle= size=92 align=80 ret=0x000ef700 (detail=0x0f7a7d70) |0f7a5000| ehci_alloc_async_pipe 0x0f7a9090 2 |0f7a5000| pmm_malloc zone=0x0f7afe7f handle= size=92 align=80 ret=0x000ef680 (detail=0x0f7a7d10) |0f7a5000| ehci_control 0x0f7a7cd0 (dir=128 cmd=8 data=1) |0f7a5000| pmm_malloc zone=0x0f7afe87 handle= size=192 align=40 ret=0x0f7a7bc0 (detail=0x0f7a7ce0) |0f7a5000| ehci_control: td at phys(f7a7bc0): status: 80 : token 80e80 |0f7a5000| - cerr: 3, total_len: 0 |0f7a5000| ehci_control: td at phys(f7a7c00): status: 0 : token d00 |0f7a5000| - cerr: 3, total_len: 0 |0f7a5000| ehci_control: td at phys(f7a7c40): status: 0 : token 1c00 |0f7a5000| - cerr: 3, total_len: 0 |0f7a5000| pmm_free 0x0f7a7bc0 (detail=0x0f7a7ce0) |0f7a5000| pmm_malloc zone=0x0f7afe83 handle= size=48 align=10 ret=0x000fdae0 (detail=0x0f7a7ce0) |0f7a5000| usb_cmd_data id=0x000fdae0 write=0 count=1 bs=36 buf=0x0f7a5f3c |0f7a5000| cbw to device |0f7a5000| ehci_send_bulk qh=0x000ef680 dir=0 data=0x0f7a5e65 size=31 |0f7a5000| before setup: td at phys(f7a5c80): status: 0 : token 0 |0f7a5000| - cerr: 0, total_len: 0 |0f7a5000| ehci_send_bulk: td at phys(f7a5c80): status: 80 : token c80 |0f7a5000| - cerr: 3, total_len: 0 |0f7a5000| Data-In from the device to the host - 36 bytes |0f7a5000| ehci_send_bulk qh=0x000ef700 dir=128 data=0x0f7a5f3c size=36 |0f7a5000| before setup: td at phys(f7a5c80): status: 0 : token 0 |0f7a5000| - cerr: 0, total_len: 0 |0f7a5000| ehci_send_bulk: td at phys(f7a5c80): status: 80 : token d80 |0f7a5000| - cerr: 3, total_len: 0 |0f7a5000| ehci_wait_td: td at phys(f7a5c80): status: 80 : token d80 |0f7a5000| - cerr: 3, total_len: 0 |0f7a5000| ehci_wait_td: td at phys(f7a5c80): status: 80 : token d80 |0f7a5000| - cerr: 3, total_len: 0 |0f7a5000| ehci_wait_td: td at phys(f7a5c80): status: 80 : token d80 |0f7a5000| - cerr: 3, total_len: 0 |0f7a5000| ehci_wait_td: td at phys(f7a5c80): status: 80 : token d80 |0f7a5000| - cerr: 3, total_len: 0 |0f7a5000| ehci_wait_td: td at phys(f7a5c80): status: 80 : token d80 |0f7a5000| - cerr: 3, total_len: 0 |0f7a5000| ehci_wait_td: td at phys(f7a5c80): status: 80 : token d80 |0f7a5000| - cerr: 3, total_len: 0 |0f7a5000| ehci_wait_td: td at phys(f7a5c80): status: 80 : token d80 |0f7a5000| - cerr: 3, total_len: 0 |0f7a5000| ehci_wait_td: td at phys(f7a5c80): status: 80 : token d80 |0f7a5000| - cerr: 3, total_len: 0 |0f7a5000| ehci_wait_td: td at phys(f7a5c80): status: 80 : token d80 |0f7a5000| - cerr: 3, total_len: 0 |0f7a5000| ehci_wait_td: td at phys(f7a5c80): status: 80 : token d80 |0f7a5000| - cerr: 3, total_len: 0 Warm Reboot --- 0f7a5000| pmm_free 0x0f7a7bc0 (detail=0x0f7a7d70) |0f7a5000
Re: [coreboot] [SeaBIOS] USB Problems geode lx800
Christian Gmeiner, MSc 2012/10/11 Christian Gmeiner christian.gmei...@gmail.com: 2012/10/11 Kevin O'Connor ke...@koconnor.net: On Tue, Oct 09, 2012 at 02:31:05PM +0200, Christian Gmeiner wrote: 2012/10/9 Kevin O'Connor ke...@koconnor.net: On Mon, Oct 08, 2012 at 02:14:03PM +0200, Christian Gmeiner wrote: HI all I am running into some usb problems with coreboot seabios: Can you set the debug level to 8 and post the whole log? Also, for timeout issues, having timestamps (via tools/readserial.py tool) sometimes helps. Attached Hrmm, I guess you've disabled threads in your config? yep... From your log, I see: [14:23:00.5] ehci_send_bulk qh=0x000ef680 dir=0 data=0x6d55 size=31^M [14:23:00.5] ehci_send_bulk qh=0x000ef700 dir=128 data=0x6e3c size=36^M [14:23:00.5] ehci_send_bulk qh=0x000ef700 dir=128 data=0x6d8f size=13^M [14:23:05.5] WARNING - Timeout at ehci_wait_td:542!^M [14:23:05.5] ehci pipe=0x000ef700 cur= tok= next=6b80 td=0x6b80 +status=d0d80^M [14:23:05.5] USB transmission failed^M [14:23:05.5] Unable to configure USB MSC drive.^M This looks like the transfer is stalling in the cdb_get_inquiry() call as part of scsi_init_drive(). The drive is identified okay and at least some transfers look okay, so it doesn't appear to be a controller issue. I've been told some USB sticks are very picky about init order, but I'm surprised to see that this is occuring for you on a variety of USB sticks. It's possible to verify that a stall has occurred - print out tds[i].token for all tds in ehci_send_bulk() on the error path. Does this device still have problems if you soft-reset after a failed boot? Here are the results with some more debug: Cold Reboot |0f7a5000| pmm_malloc zone=0x0f7afe87 handle= size=192 align=40 ret=0x0f7a7bc0 (detail=0x0f7a7d70) |0f7a5000| ehci_control: td at phys(f7a7bc0): status: 80 : token 80e80 |0f7a5000| - cerr: 3, total_len: 0 |0f7a5000| ehci_control: td at phys(f7a7c00): status: 0 : token d00 |0f7a5000| - cerr: 3, total_len: 0 |0f7a5000| ehci_control: td at phys(f7a7c40): status: 0 : token 0 |0f7a5000| - cerr: 0, total_len: 0 |0f7a5000| pmm_free 0x0f7a7bc0 (detail=0x0f7a7d70) |0f7a5000| ehci_alloc_async_pipe 0x0f7a9090 2 |0f7a5000| pmm_malloc zone=0x0f7afe7f handle= size=92 align=80 ret=0x000ef700 (detail=0x0f7a7d70) |0f7a5000| ehci_alloc_async_pipe 0x0f7a9090 2 |0f7a5000| pmm_malloc zone=0x0f7afe7f handle= size=92 align=80 ret=0x000ef680 (detail=0x0f7a7d10) |0f7a5000| ehci_control 0x0f7a7cd0 (dir=128 cmd=8 data=1) |0f7a5000| pmm_malloc zone=0x0f7afe87 handle= size=192 align=40 ret=0x0f7a7bc0 (detail=0x0f7a7ce0) |0f7a5000| ehci_control: td at phys(f7a7bc0): status: 80 : token 80e80 |0f7a5000| - cerr: 3, total_len: 0 |0f7a5000| ehci_control: td at phys(f7a7c00): status: 0 : token d00 |0f7a5000| - cerr: 3, total_len: 0 |0f7a5000| ehci_control: td at phys(f7a7c40): status: 0 : token 1c00 |0f7a5000| - cerr: 3, total_len: 0 |0f7a5000| pmm_free 0x0f7a7bc0 (detail=0x0f7a7ce0) |0f7a5000| pmm_malloc zone=0x0f7afe83 handle= size=48 align=10 ret=0x000fdae0 (detail=0x0f7a7ce0) |0f7a5000| usb_cmd_data id=0x000fdae0 write=0 count=1 bs=36 buf=0x0f7a5f3c |0f7a5000| cbw to device |0f7a5000| ehci_send_bulk qh=0x000ef680 dir=0 data=0x0f7a5e65 size=31 |0f7a5000| before setup: td at phys(f7a5c80): status: 0 : token 0 |0f7a5000| - cerr: 0, total_len: 0 |0f7a5000| ehci_send_bulk: td at phys(f7a5c80): status: 80 : token c80 |0f7a5000| - cerr: 3, total_len: 0 |0f7a5000| Data-In from the device to the host - 36 bytes |0f7a5000| ehci_send_bulk qh=0x000ef700 dir=128 data=0x0f7a5f3c size=36 |0f7a5000| before setup: td at phys(f7a5c80): status: 0 : token 0 |0f7a5000| - cerr: 0, total_len: 0 |0f7a5000| ehci_send_bulk: td at phys(f7a5c80): status: 80 : token d80 |0f7a5000| - cerr: 3, total_len: 0 |0f7a5000| ehci_wait_td: td at phys(f7a5c80): status: 80 : token d80 |0f7a5000| - cerr: 3, total_len: 0 |0f7a5000| ehci_wait_td: td at phys(f7a5c80): status: 80 : token d80 |0f7a5000| - cerr: 3, total_len: 0 |0f7a5000| ehci_wait_td: td at phys(f7a5c80): status: 80 : token d80 |0f7a5000| - cerr: 3, total_len: 0 |0f7a5000| ehci_wait_td: td at phys(f7a5c80): status: 80 : token d80 |0f7a5000| - cerr: 3, total_len: 0 |0f7a5000| ehci_wait_td: td at phys(f7a5c80): status: 80 : token d80 |0f7a5000| - cerr: 3, total_len: 0 |0f7a5000| ehci_wait_td: td at phys(f7a5c80): status: 80 : token d80 |0f7a5000| - cerr: 3, total_len: 0 |0f7a5000| ehci_wait_td: td at phys(f7a5c80): status: 80 : token d80 |0f7a5000| - cerr: 3, total_len: 0 |0f7a5000| ehci_wait_td: td at phys(f7a5c80): status: 80 : token d80 |0f7a5000| - cerr: 3, total_len: 0 |0f7a5000| ehci_wait_td: td at phys(f7a5c80): status: 80 : token d80 |0f7a5000| - cerr: 3, total_len: 0 |0f7a5000| ehci_wait_td: td at phys(f7a5c80): status: 80 : token
Re: [coreboot] [SeaBIOS] USB Problems geode lx800
2012/10/9 Christian Gmeiner christian.gmei...@gmail.com: 2012/10/9 Kevin O'Connor ke...@koconnor.net: On Mon, Oct 08, 2012 at 02:14:03PM +0200, Christian Gmeiner wrote: HI all I am running into some usb problems with coreboot seabios: init usb pmm_malloc zone=0x1f7afe7f handle= size=72 align=10 ret=0x1f7a8860 (detail=0x1f7a88b0) [...] Mabye somebody has some hints how to start debugging this and what I should look for. Hi Christian, Can you set the debug level to 8 and post the whole log? Also, for timeout issues, having timestamps (via tools/readserial.py tool) sometimes helps. Attached Did this regress, or has it never worked? What type of USB drive are you attempting to use? It never worked and tried it with a hand full of different usb sticks. This one is my target stick, which must work: Bus 002 Device 029: ID 1370:3252 Swissbit Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x1370 Swissbit idProduct 0x3252 bcdDevice1.00 iManufacturer 1 Swissbit iProduct2 unitedCONTRAST iSerial 3 60042417C301 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 32 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 200mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 8 Mass Storage bInterfaceSubClass 6 SCSI bInterfaceProtocol 80 Bulk-Only iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 255 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 255 Device Qualifier (for other device speed): bLength10 bDescriptorType 6 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 bNumConfigurations 1 Device Status: 0x (Bus Powered) I got access to an ellisys usb explorer and dumped the whole transfer between usb stick and lx800. I started to look at the whole USB stuff this day and I hope we can get it working :) To view the dump you need this: http://www.ellisys.com/products/usbex200/download.php The dump can be found here: https://docs.google.com/open?id=0B_fznDimUHVuTkRfYkE5b0NtRzg greets --- Christian Gmeiner, MSc -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [SeaBIOS] USB Problems geode lx800
2012/10/9 Kevin O'Connor ke...@koconnor.net: On Mon, Oct 08, 2012 at 02:14:03PM +0200, Christian Gmeiner wrote: HI all I am running into some usb problems with coreboot seabios: init usb pmm_malloc zone=0x1f7afe7f handle= size=72 align=10 ret=0x1f7a8860 (detail=0x1f7a88b0) [...] Mabye somebody has some hints how to start debugging this and what I should look for. Hi Christian, Can you set the debug level to 8 and post the whole log? Also, for timeout issues, having timestamps (via tools/readserial.py tool) sometimes helps. Attached Did this regress, or has it never worked? What type of USB drive are you attempting to use? It never worked and tried it with a hand full of different usb sticks. This one is my target stick, which must work: Bus 002 Device 029: ID 1370:3252 Swissbit Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x1370 Swissbit idProduct 0x3252 bcdDevice1.00 iManufacturer 1 Swissbit iProduct2 unitedCONTRAST iSerial 3 60042417C301 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 32 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 200mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 8 Mass Storage bInterfaceSubClass 6 SCSI bInterfaceProtocol 80 Bulk-Only iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 255 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 255 Device Qualifier (for other device speed): bLength10 bDescriptorType 6 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 bNumConfigurations 1 Device Status: 0x (Bus Powered) --- Christian Gmeiner, MSc -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] USB Problems geode lx800
HI all I am running into some usb problems with coreboot seabios: init usb pmm_malloc zone=0x1f7afe7f handle= size=72 align=10 ret=0x1f7a8860 (detail=0x1f7a88b0) EHCI init on dev 00:0f.5 (regs=0xfe038010) pmm_malloc zone=0x1f7afe83 handle= size=4096 align=1000 ret=0x1f7bf000 (detail=0x1f7a8830) pmm_malloc zone=0x1f7afe83 handle= size=68 align=80 ret=0x1f7bef80 (detail=0x1f7a8800) pmm_malloc zone=0x1f7afe83 handle= size=68 align=80 ret=0x1f7bef00 (detail=0x1f7a87d0) pmm_malloc zone=0x1f7afe7f handle= size=28 align=10 ret=0x1f7a8780 (detail=0x1f7a87a0) pmm_free 0x1f7a8780 (detail=0x1f7a87a0) pmm_malloc zone=0x1f7afe7f handle= size=28 align=10 ret=0x1f7a8780 (detail=0x1f7a87a0) set_address 0x1f7a8860 ehci_alloc_async_pipe 0x1f7a8860 0 pmm_malloc zone=0x1f7afe7f handle= size=92 align=80 ret=0x1f7a8680 (detail=0x1f7a8750) ehci_control 0x1f7a86d0 (dir=0 cmd=8 data=0) pmm_malloc zone=0x1f7afe7f handle= size=192 align=40 ret=0x1f7a85c0 (detail=0x1f7a8720) pmm_free 0x1f7a85c0 (detail=0x1f7a8720) ehci_alloc_async_pipe 0x1f7a8860 0 config_usb: 0x1f7a86d0 ehci_control 0x1f7a86d0 (dir=128 cmd=8 data=8) pmm_malloc zone=0x1f7afe7f handle= size=192 align=40 ret=0x1f7a85c0 (detail=0x1f7a8720) pmm_free 0x1f7a85c0 (detail=0x1f7a8720) device rev=0200 cls=00 sub=00 proto=00 size=40 ehci_alloc_async_pipe 0x1f7a8860 0 ehci_control 0x1f7a86d0 (dir=128 cmd=8 data=9) pmm_malloc zone=0x1f7afe7f handle= size=192 align=40 ret=0x1f7a85c0 (detail=0x1f7a8720) pmm_free 0x1f7a85c0 (detail=0x1f7a8720) pmm_malloc zone=0x1f7afe7f handle= size=32 align=10 ret=0x1f7a8700 (detail=0x1f7a8720) ehci_control 0x1f7a86d0 (dir=128 cmd=8 data=32) pmm_malloc zone=0x1f7afe7f handle= size=192 align=40 ret=0x1f7a8580 (detail=0x1f7a8650) pmm_free 0x1f7a8580 (detail=0x1f7a8650) ehci_control 0x1f7a86d0 (dir=0 cmd=8 data=0) pmm_malloc zone=0x1f7afe7f handle= size=192 align=40 ret=0x1f7a8580 (detail=0x1f7a8650) pmm_free 0x1f7a8580 (detail=0x1f7a8650) ehci_alloc_async_pipe 0x1f7a8860 2 pmm_malloc zone=0x1f7afe77 handle= size=92 align=80 ret=0x000ef700 (detail=0x1f7a8650) ehci_alloc_async_pipe 0x1f7a8860 2 pmm_malloc zone=0x1f7afe77 handle= size=92 align=80 ret=0x000ef680 (detail=0x1f7a8620) ehci_control 0x1f7a86d0 (dir=128 cmd=8 data=1) pmm_malloc zone=0x1f7afe7f handle= size=192 align=40 ret=0x1f7a8500 (detail=0x1f7a85f0) pmm_free 0x1f7a8500 (detail=0x1f7a85f0) pmm_malloc zone=0x1f7afe7b handle= size=48 align=10 ret=0x000fdb30 (detail=0x1f7a85f0) Searching bootorder for: /pci@i0cf8/usb@f,5/storage@2/*@0/*@0,0 Searching bootorder for: /pci@i0cf8/usb@f,5/usb-*@2 ehci_send_bulk qh=0x000ef680 dir=0 data=0x6d55 size=31 ehci_send_bulk qh=0x000ef700 dir=128 data=0x6e3c size=36 ehci_send_bulk qh=0x000ef700 dir=128 data=0x6d8f size=13 WARNING - Timeout at ehci_wait_td:542! ehci pipe=0x000ef700 cur= tok= next=6b80 td=0x6b80 status=d0d80 USB transmission failed Unable to configure USB MSC drive. pmm_free 0x000fdb30 (detail=0x1f7a85f0) Unable to configure USB MSC device. pmm_free 0x1f7a8700 (detail=0x1f7a8720) pmm_free 0x1f7a8780 (detail=0x1f7a87a0) pmm_malloc zone=0x1f7afe7f handle= size=28 align=10 ret=0x1f7a8780 (detail=0x1f7a87a0) pmm_free 0x1f7a8780 (detail=0x1f7a87a0) pmm_malloc zone=0x1f7afe7f handle= size=28 align=10 ret=0x1f7a8780 (detail=0x1f7a87a0) pmm_free 0x1f7a8780 (detail=0x1f7a87a0) ehci_free_pipes 0x1f7a8860 pmm_free 0x1f7a8680 (detail=0x1f7a8750) pmm_free 0x000ef680 (detail=0x1f7a8620) pmm_free 0x000ef700 (detail=0x1f7a8650) pmm_free 0x1f7bf000 (detail=0x1f7a8830) pmm_free 0x1f7bef80 (detail=0x1f7a8800) pmm_free 0x1f7bef00 (detail=0x1f7a87d0) pmm_free 0x1f7a8860 (detail=0x1f7a88b0) init serial Found 2 serial ports init hard drives Mabye somebody has some hints how to start debugging this and what I should look for. --- Christian Gmeiner, MSc -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] USB Problems geode lx800
2012/10/8 Christian Gmeiner christian.gmei...@gmail.com: HI all I am running into some usb problems with coreboot seabios: init usb pmm_malloc zone=0x1f7afe7f handle= size=72 align=10 ret=0x1f7a8860 (detail=0x1f7a88b0) EHCI init on dev 00:0f.5 (regs=0xfe038010) pmm_malloc zone=0x1f7afe83 handle= size=4096 align=1000 ret=0x1f7bf000 (detail=0x1f7a8830) pmm_malloc zone=0x1f7afe83 handle= size=68 align=80 ret=0x1f7bef80 (detail=0x1f7a8800) pmm_malloc zone=0x1f7afe83 handle= size=68 align=80 ret=0x1f7bef00 (detail=0x1f7a87d0) pmm_malloc zone=0x1f7afe7f handle= size=28 align=10 ret=0x1f7a8780 (detail=0x1f7a87a0) pmm_free 0x1f7a8780 (detail=0x1f7a87a0) pmm_malloc zone=0x1f7afe7f handle= size=28 align=10 ret=0x1f7a8780 (detail=0x1f7a87a0) set_address 0x1f7a8860 ehci_alloc_async_pipe 0x1f7a8860 0 pmm_malloc zone=0x1f7afe7f handle= size=92 align=80 ret=0x1f7a8680 (detail=0x1f7a8750) ehci_control 0x1f7a86d0 (dir=0 cmd=8 data=0) pmm_malloc zone=0x1f7afe7f handle= size=192 align=40 ret=0x1f7a85c0 (detail=0x1f7a8720) pmm_free 0x1f7a85c0 (detail=0x1f7a8720) ehci_alloc_async_pipe 0x1f7a8860 0 config_usb: 0x1f7a86d0 ehci_control 0x1f7a86d0 (dir=128 cmd=8 data=8) pmm_malloc zone=0x1f7afe7f handle= size=192 align=40 ret=0x1f7a85c0 (detail=0x1f7a8720) pmm_free 0x1f7a85c0 (detail=0x1f7a8720) device rev=0200 cls=00 sub=00 proto=00 size=40 ehci_alloc_async_pipe 0x1f7a8860 0 ehci_control 0x1f7a86d0 (dir=128 cmd=8 data=9) pmm_malloc zone=0x1f7afe7f handle= size=192 align=40 ret=0x1f7a85c0 (detail=0x1f7a8720) pmm_free 0x1f7a85c0 (detail=0x1f7a8720) pmm_malloc zone=0x1f7afe7f handle= size=32 align=10 ret=0x1f7a8700 (detail=0x1f7a8720) ehci_control 0x1f7a86d0 (dir=128 cmd=8 data=32) pmm_malloc zone=0x1f7afe7f handle= size=192 align=40 ret=0x1f7a8580 (detail=0x1f7a8650) pmm_free 0x1f7a8580 (detail=0x1f7a8650) ehci_control 0x1f7a86d0 (dir=0 cmd=8 data=0) pmm_malloc zone=0x1f7afe7f handle= size=192 align=40 ret=0x1f7a8580 (detail=0x1f7a8650) pmm_free 0x1f7a8580 (detail=0x1f7a8650) ehci_alloc_async_pipe 0x1f7a8860 2 pmm_malloc zone=0x1f7afe77 handle= size=92 align=80 ret=0x000ef700 (detail=0x1f7a8650) ehci_alloc_async_pipe 0x1f7a8860 2 pmm_malloc zone=0x1f7afe77 handle= size=92 align=80 ret=0x000ef680 (detail=0x1f7a8620) ehci_control 0x1f7a86d0 (dir=128 cmd=8 data=1) pmm_malloc zone=0x1f7afe7f handle= size=192 align=40 ret=0x1f7a8500 (detail=0x1f7a85f0) pmm_free 0x1f7a8500 (detail=0x1f7a85f0) pmm_malloc zone=0x1f7afe7b handle= size=48 align=10 ret=0x000fdb30 (detail=0x1f7a85f0) Searching bootorder for: /pci@i0cf8/usb@f,5/storage@2/*@0/*@0,0 Searching bootorder for: /pci@i0cf8/usb@f,5/usb-*@2 ehci_send_bulk qh=0x000ef680 dir=0 data=0x6d55 size=31 ehci_send_bulk qh=0x000ef700 dir=128 data=0x6e3c size=36 ehci_send_bulk qh=0x000ef700 dir=128 data=0x6d8f size=13 WARNING - Timeout at ehci_wait_td:542! ehci pipe=0x000ef700 cur= tok= next=6b80 td=0x6b80 status=d0d80 USB transmission failed Unable to configure USB MSC drive. pmm_free 0x000fdb30 (detail=0x1f7a85f0) Unable to configure USB MSC device. pmm_free 0x1f7a8700 (detail=0x1f7a8720) pmm_free 0x1f7a8780 (detail=0x1f7a87a0) pmm_malloc zone=0x1f7afe7f handle= size=28 align=10 ret=0x1f7a8780 (detail=0x1f7a87a0) pmm_free 0x1f7a8780 (detail=0x1f7a87a0) pmm_malloc zone=0x1f7afe7f handle= size=28 align=10 ret=0x1f7a8780 (detail=0x1f7a87a0) pmm_free 0x1f7a8780 (detail=0x1f7a87a0) ehci_free_pipes 0x1f7a8860 pmm_free 0x1f7a8680 (detail=0x1f7a8750) pmm_free 0x000ef680 (detail=0x1f7a8620) pmm_free 0x000ef700 (detail=0x1f7a8650) pmm_free 0x1f7bf000 (detail=0x1f7a8830) pmm_free 0x1f7bef80 (detail=0x1f7a8800) pmm_free 0x1f7bef00 (detail=0x1f7a87d0) pmm_free 0x1f7a8860 (detail=0x1f7a88b0) init serial Found 2 serial ports init hard drives Mabye somebody has some hints how to start debugging this and what I should look for. added some debug to seabios: http://dpaste.com/811158/ and tired my luck with FILO (using libpayload from coreboot): http://dpaste.com/811165/ --- Christian Gmeiner, MSc -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] USB Problems geode lx800
2012/10/8 Christian Gmeiner christian.gmei...@gmail.com: 2012/10/8 Christian Gmeiner christian.gmei...@gmail.com: HI all I am running into some usb problems with coreboot seabios: init usb pmm_malloc zone=0x1f7afe7f handle= size=72 align=10 ret=0x1f7a8860 (detail=0x1f7a88b0) EHCI init on dev 00:0f.5 (regs=0xfe038010) pmm_malloc zone=0x1f7afe83 handle= size=4096 align=1000 ret=0x1f7bf000 (detail=0x1f7a8830) pmm_malloc zone=0x1f7afe83 handle= size=68 align=80 ret=0x1f7bef80 (detail=0x1f7a8800) pmm_malloc zone=0x1f7afe83 handle= size=68 align=80 ret=0x1f7bef00 (detail=0x1f7a87d0) pmm_malloc zone=0x1f7afe7f handle= size=28 align=10 ret=0x1f7a8780 (detail=0x1f7a87a0) pmm_free 0x1f7a8780 (detail=0x1f7a87a0) pmm_malloc zone=0x1f7afe7f handle= size=28 align=10 ret=0x1f7a8780 (detail=0x1f7a87a0) set_address 0x1f7a8860 ehci_alloc_async_pipe 0x1f7a8860 0 pmm_malloc zone=0x1f7afe7f handle= size=92 align=80 ret=0x1f7a8680 (detail=0x1f7a8750) ehci_control 0x1f7a86d0 (dir=0 cmd=8 data=0) pmm_malloc zone=0x1f7afe7f handle= size=192 align=40 ret=0x1f7a85c0 (detail=0x1f7a8720) pmm_free 0x1f7a85c0 (detail=0x1f7a8720) ehci_alloc_async_pipe 0x1f7a8860 0 config_usb: 0x1f7a86d0 ehci_control 0x1f7a86d0 (dir=128 cmd=8 data=8) pmm_malloc zone=0x1f7afe7f handle= size=192 align=40 ret=0x1f7a85c0 (detail=0x1f7a8720) pmm_free 0x1f7a85c0 (detail=0x1f7a8720) device rev=0200 cls=00 sub=00 proto=00 size=40 ehci_alloc_async_pipe 0x1f7a8860 0 ehci_control 0x1f7a86d0 (dir=128 cmd=8 data=9) pmm_malloc zone=0x1f7afe7f handle= size=192 align=40 ret=0x1f7a85c0 (detail=0x1f7a8720) pmm_free 0x1f7a85c0 (detail=0x1f7a8720) pmm_malloc zone=0x1f7afe7f handle= size=32 align=10 ret=0x1f7a8700 (detail=0x1f7a8720) ehci_control 0x1f7a86d0 (dir=128 cmd=8 data=32) pmm_malloc zone=0x1f7afe7f handle= size=192 align=40 ret=0x1f7a8580 (detail=0x1f7a8650) pmm_free 0x1f7a8580 (detail=0x1f7a8650) ehci_control 0x1f7a86d0 (dir=0 cmd=8 data=0) pmm_malloc zone=0x1f7afe7f handle= size=192 align=40 ret=0x1f7a8580 (detail=0x1f7a8650) pmm_free 0x1f7a8580 (detail=0x1f7a8650) ehci_alloc_async_pipe 0x1f7a8860 2 pmm_malloc zone=0x1f7afe77 handle= size=92 align=80 ret=0x000ef700 (detail=0x1f7a8650) ehci_alloc_async_pipe 0x1f7a8860 2 pmm_malloc zone=0x1f7afe77 handle= size=92 align=80 ret=0x000ef680 (detail=0x1f7a8620) ehci_control 0x1f7a86d0 (dir=128 cmd=8 data=1) pmm_malloc zone=0x1f7afe7f handle= size=192 align=40 ret=0x1f7a8500 (detail=0x1f7a85f0) pmm_free 0x1f7a8500 (detail=0x1f7a85f0) pmm_malloc zone=0x1f7afe7b handle= size=48 align=10 ret=0x000fdb30 (detail=0x1f7a85f0) Searching bootorder for: /pci@i0cf8/usb@f,5/storage@2/*@0/*@0,0 Searching bootorder for: /pci@i0cf8/usb@f,5/usb-*@2 ehci_send_bulk qh=0x000ef680 dir=0 data=0x6d55 size=31 ehci_send_bulk qh=0x000ef700 dir=128 data=0x6e3c size=36 ehci_send_bulk qh=0x000ef700 dir=128 data=0x6d8f size=13 WARNING - Timeout at ehci_wait_td:542! ehci pipe=0x000ef700 cur= tok= next=6b80 td=0x6b80 status=d0d80 USB transmission failed Unable to configure USB MSC drive. pmm_free 0x000fdb30 (detail=0x1f7a85f0) Unable to configure USB MSC device. pmm_free 0x1f7a8700 (detail=0x1f7a8720) pmm_free 0x1f7a8780 (detail=0x1f7a87a0) pmm_malloc zone=0x1f7afe7f handle= size=28 align=10 ret=0x1f7a8780 (detail=0x1f7a87a0) pmm_free 0x1f7a8780 (detail=0x1f7a87a0) pmm_malloc zone=0x1f7afe7f handle= size=28 align=10 ret=0x1f7a8780 (detail=0x1f7a87a0) pmm_free 0x1f7a8780 (detail=0x1f7a87a0) ehci_free_pipes 0x1f7a8860 pmm_free 0x1f7a8680 (detail=0x1f7a8750) pmm_free 0x000ef680 (detail=0x1f7a8620) pmm_free 0x000ef700 (detail=0x1f7a8650) pmm_free 0x1f7bf000 (detail=0x1f7a8830) pmm_free 0x1f7bef80 (detail=0x1f7a8800) pmm_free 0x1f7bef00 (detail=0x1f7a87d0) pmm_free 0x1f7a8860 (detail=0x1f7a88b0) init serial Found 2 serial ports init hard drives Mabye somebody has some hints how to start debugging this and what I should look for. added some debug to seabios: http://dpaste.com/811158/ and tired my luck with FILO (using libpayload from coreboot): http://dpaste.com/811165/ I can boot with FILO from usb successfully into Linux --- Christian Gmeiner, MSc -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] VideoBios question
Hi all. As you may noticed I am working on the SeaVideoBios (Geode part). And I am running into a simple question: What is the default state/video mode the VideoBios should enter during/after init? In general I need to set the wanted mode via int10 AH=00h Would it be okay to have no mode set during init and trust that the mode is set before using it? thanks --- Christian Gmeiner, MSc -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [SeaBIOS] Data exchange between coreboot - seabios - option rom
2012/8/23 Kevin O'Connor ke...@koconnor.net: On Wed, Aug 22, 2012 at 04:13:29PM +0200, Christian Gmeiner wrote: 2012/8/22 Kevin O'Connor ke...@koconnor.net: I'm not sure I fully understand your requirements. Will the board truly have different flat screens hooked up to it? One can't simply There are different screens (timing and resolution) connected to the device. compile the EPI info into the BIOS? Also, if you have to interrogate the display via i2c, can you simply fully generate the EPI info in the vgabios at runtime? After some time of hacking I came up with the following solution. 1) Reserve 128 byte in SeaVIDOEBIOS (between ROM haeder and entry points) 2) Add all needed epi files to cbfs 3) Add possibility to patch vbios during loading based on i2c content - see http://review.coreboot.org/#/c/1478/ Why read the i2c and then patch the vgabios - why not just have the vgabios read from i2c directly? May I need to say that we are talking here about two different i2c buses. * i2c bus of cs5563 * i2c bus for EDID data transfer - used by VGA As may panel is connected via LVDS I can not get EDID data from it. So I want to use EPI and EDID extension. So I would read the i2c eeprom at the cs5536 smb bus and get 3 values. Based on these values I decide which EDID/EPI binary blob I would like to use. 4) Extend vbios to make use of epi/edid data by writing a simple parser 5) Extend VBE 6) Extend geode code in vbios to make use of parsed epi/edid data -Kevin -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [SeaBIOS] Data exchange between coreboot - seabios - option rom
2012/8/23 Kevin O'Connor ke...@koconnor.net:
On Thu, Aug 23, 2012 at 08:54:08AM +0200, Christian Gmeiner wrote:
2012/8/23 Kevin O'Connor ke...@koconnor.net:
Why read the i2c and then patch the vgabios - why not just have the
vgabios read from i2c directly?
May I need to say that we are talking here about two different i2c buses.
* i2c bus of cs5563
* i2c bus for EDID data transfer - used by VGA
As may panel is connected via LVDS I can not get EDID data from it. So
I want to use
EPI and EDID extension.
So I would read the i2c eeprom at the cs5536 smb bus and get 3 values.
Based on these
values I decide which EDID/EPI binary blob I would like to use.
So, why not read the i2c eeprom directly from the vgabios? It seems
fragile to build an interface between coreboot and a vgabios just so
coreboot can read the eeprom.
Ok lets say I can read the eeprom in vga option rom. I have 3 values
and can identify
what panel it is. fine.. and now? I need to know what
timings/resolution each supported
panel has.
switch (panel)
{
case 1:
set a hand full of variables
break;
...
case 7:
set a hand full of variables
break;
}
So I need to modify the VGA option sources everytime a new panel gets
added. And I am not
sure that you will accept patches that add vendor specific stuff if
there is a vendor independent
solution: EDID/EPI!
Is not an interface I want to build... I want to extend SeaVIDEOBIOS
to support EDID/EPI, which
_CAN_ be stored directly in the option rom - but its not a _MUST_.
I think I will finish my work and present a patch series for the
SesVIDEOBIOS part and we can discuss it
further. I hope that everybody sees/understands what I really want to
do - sometimes I really hate
discussing such stuff in a virtual world via mail and irc.
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [SeaBIOS] Data exchange between coreboot - seabios - option rom
2012/8/22 Kevin O'Connor ke...@koconnor.net: On Tue, Aug 21, 2012 at 04:57:56PM +0200, Christian Gmeiner wrote: 2012/8/21 Christian Gmeiner christian.gmei...@gmail.com: Hi all, my vacation is over and I need to look in some stuff deeper to finally get the combination coreboot/seabios fully working. The only missing part aside from a lot of testing is the video bios stuff. Here I am working on a patch series to extend seabios vga option rom to support flat panels. I would like to to use EPI (http://www.epi-standard.org/) for the description of the panels. Due EOL changes my target hardware supports different kind of flat panels (with different timings). I can detect what panel is used with the help of an i2c eeprom. So the normal CBFS will be extended by n EPI raw files. And here the troubles begins :) 1) Can I add symbolic links during runtime It would be fine if somewhere during the boot (coreboot or seabios) I can readout the needed bytes from the eeprom, decide which EPI file to use and create something line a symlink to the choosen one. panel.epi - 640_480_panel_name.epi I don't know of anyway to do this. The effort to implement this would probably be large. yes that would take ages As I found out this can be done via nvram. So coreboot set the filename of the EPI file to use and seabios/... etc can simply use it. Using CMOS for passing temporary variables around is quite ugly. I'd recommend against it. ok 2) Can I load a CBFS file in the option rom? The idea is to load the EPI raw file and provide it via VBE (vbe_104f15) BIOS call. So the geode lx option rom can read out the timing informations via VBE and setup the video mode. It's possible. However, the vgabios currently runs in 16bit mode. Getting the existing CBFS code to run in 16bit mode would be a pain. Probably better to convert the vgabios init phase to jump into 32bit mode. However, that is a bit of work. It could also be possible to store the EPI data at a defined memory area where the option rom can simply check for existing identifiers and checksum. I'd recommend against that - magic areas of memory have been quite troublesome in the past. Any hints are really welcome. I'm not sure I fully understand your requirements. Will the board truly have different flat screens hooked up to it? One can't simply There are different screens (timing and resolution) connected to the device. compile the EPI info into the BIOS? Also, if you have to interrogate the display via i2c, can you simply fully generate the EPI info in the vgabios at runtime? After some time of hacking I came up with the following solution. 1) Reserve 128 byte in SeaVIDOEBIOS (between ROM haeder and entry points) 2) Add all needed epi files to cbfs 3) Add possibility to patch vbios during loading based on i2c content - see http://review.coreboot.org/#/c/1478/ 4) Extend vbios to make use of epi/edid data by writing a simple parser 5) Extend VBE 6) Extend geode code in vbios to make use of parsed epi/edid data Here is the first result, which looks quite good. http://dpaste.com/790033/ --- Christian Gmeiner, MSc -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Data exchange between coreboot - seabios - option rom
Hi all, my vacation is over and I need to look in some stuff deeper to finally get the combination coreboot/seabios fully working. The only missing part aside from a lot of testing is the video bios stuff. Here I am working on a patch series to extend seabios vga option rom to support flat panels. I would like to to use EPI (http://www.epi-standard.org/) for the description of the panels. Due EOL changes my target hardware supports different kind of flat panels (with different timings). I can detect what panel is used with the help of an i2c eeprom. So the normal CBFS will be extended by n EPI raw files. And here the troubles begins :) 1) Can I add symbolic links during runtime It would be fine if somewhere during the boot (coreboot or seabios) I can readout the needed bytes from the eeprom, decide which EPI file to use and create something line a symlink to the choosen one. panel.epi - 640_480_panel_name.epi 2) Can I load a CBFS file in the option rom? The idea is to load the EPI raw file and provide it via VBE (vbe_104f15) BIOS call. So the geode lx option rom can read out the timing informations via VBE and setup the video mode. The result should be something like this: http://www.youtube.com/watch?v=83CDqJMblkw greets --- Christian Gmeiner, MSc -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Data exchange between coreboot - seabios - option rom
2012/8/21 Christian Gmeiner christian.gmei...@gmail.com: Hi all, my vacation is over and I need to look in some stuff deeper to finally get the combination coreboot/seabios fully working. The only missing part aside from a lot of testing is the video bios stuff. Here I am working on a patch series to extend seabios vga option rom to support flat panels. I would like to to use EPI (http://www.epi-standard.org/) for the description of the panels. Due EOL changes my target hardware supports different kind of flat panels (with different timings). I can detect what panel is used with the help of an i2c eeprom. So the normal CBFS will be extended by n EPI raw files. And here the troubles begins :) 1) Can I add symbolic links during runtime It would be fine if somewhere during the boot (coreboot or seabios) I can readout the needed bytes from the eeprom, decide which EPI file to use and create something line a symlink to the choosen one. panel.epi - 640_480_panel_name.epi As I found out this can be done via nvram. So coreboot set the filename of the EPI file to use and seabios/... etc can simply use it. 2) Can I load a CBFS file in the option rom? The idea is to load the EPI raw file and provide it via VBE (vbe_104f15) BIOS call. So the geode lx option rom can read out the timing informations via VBE and setup the video mode. It could also be possible to store the EPI data at a defined memory area where the option rom can simply check for existing identifiers and checksum. Any hints are really welcome. --- Christian Gmeiner, MSc -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
