Hello,
I've switched my Acer C720 years ago to legacy boot mode (SeaBIOS) to be
able to install another OS (FreeBSD). This required, after removing the
write protection screw, the following commands:
Disable the software write protection.
# flashrom --wp-disable
Run set_gbb_flags.sh with no parameters.
# set_gbb_flags.sh
GBB_FLAG_DEV_SCREEN_SHORT_DELAY 0x00000001
GBB_FLAG_FORCE_DEV_SWITCH_ON 0x00000008
GBB_FLAG_FORCE_DEV_BOOT_LEGACY 0x00000080
GBB_FLAG_DEFAULT_DEV_BOOT_LEGACY 0x00000400
Now set SeaBIOS as default.
# set_gbb_flags.sh 0x489
Enable back the software write protection.
# flashrom --wp-enable
This work fine and FreeBSD which I installed on a replaced SSD runs
fine on the hardware. The original SSD still contains the ChromeOS.
Now I want to switch back to boot a few times ChromeOS from this SSD to see
something in the boot messages of this and compare it with the sources.
I doubt that the replace SSD will boot due to the changed gbb_flags and
of course FreeBSD has no support for this tool. How I could change them
back, for example, booting some Ubuntu version? Or is there any other
standalone bootable tool to do so?
Thanks
Matthias
--
Matthias Apitz, ✉ guru(a)unixarea.de, ⌂ http://www.unixarea.de/ ☎ +49-176-38902045
"Wer übersieht, dass wir uns den anderen weggenommen haben und sie uns wiederhaben wollen,
kann von den Kämpfen der letzten Tage keinen verstehen. Und kann natürlich auch keinen
dieser Kämpfe bestehen." Hermann Kant in jW 1.10.1989
Hello Kim,
> Please any idea?
Since everything works with C2000 I/O HW as I expected, I am out of new
ideas. Again, I am forwarding my romstage/ROMCC email, since you have to
have global variable for your latest OUT values to store.
Either you should move your specific HW control blocks to ramstage, either
you must reserve/use some general purpose 32 bit x86 register in romstage
(getting familiar with ROMCC compiler declarations).
Best Regards,
Zoran
_______
On Tue, Jul 19, 2016 at 11:42 AM, Zoran Stojsavljevic <
zoran.stojsavljevic(a)gmail.com> wrote:
> Hello 김유석,
>
> I did not understand (very imporatnt question): why at all you do need SW
> I2C (bit-banging I2C) in Coreboot romstage? Maybe you can move your I2C
> operation later, in ramstage?!
>
> Isn't romstage just to do very quick boot and pass the phase where MRC
> (DDRs) should be initialized? And not sure if both L1 cashes are set as CAR
> (L1 I-cache as well as L1 D-cache)? It seems to me that only L1 D-cache is
> initialized as CAR, L1 I-cache remains to be true cache for flash code to
> be executed fast.
>
> I do know that romstage is compiled with the special ROMCC compiler, which
> was adopted by Eric Biederman (2003-2006, ebiederman(a)lnxi.com):
> https://github.com/wt/coreboot/blob/master/util/romcc/romcc.1
>
> Maybe, this compiler allows you to store your outl() value into some
> 32-bit reserved (for this purpose) common purpose register (instead of
> global variable), but at this point in time, I need more time to
> investigate ROMCC.
>
> Some other people very well might know answers about ROMCC on coreboot
> mailing list. ;-)
>
> Zoran
>
> On Tue, Jul 19, 2016 at 8:40 AM, 김유석 <poplinux0(a)gmail.com> wrote:
>
>> Sorry. i was have a miss-typing.
>>
>> I can read the some global variable. => X
>> I can't read the some global variable. => O
>>
>>
>>
>> Thank you.
>>
>>
>>
>> 2016-07-19 오후 3:26에 김유석 이(가) 쓴 글:
>>
>> Dear Sir.
>>
>> Thank's your advise.
>>
>> I can read the some global variable.
>> Because the outl() api is directly write value to register. Not global
>> variable. I guess.
>>
>> Perhaps, your mean is a must use GLOBAL value for SC_GP_LVL?(do not try
>> to read from SC_GP_LVL)
>> I was try to use the GLOBAL value on coreboot. But occured the compile
>> error.
>>
>> the global value "u32 val_sc_gp_lvl" is defined on
>> "src/southbridge/intel/fsp_rangeley/gpio.c"
>> and use this value is on
>> "src/southbridge/intel/fsp_rangeley/gpio.c::setup_soc_gpios()"
>>
>> If i call setup_soc_gpios() is
>> "src/mainboard/intel/mohonpeak/romstage.c::early_mainboard_romstage_entry()",
>> occured build error. log is see below.
>>
>> OBJCOPY cbfs/fallback/bootblock.elf
>> LINK cbfs/fallback/romstage.debug
>> OBJCOPY bootblock.raw.bin
>> Forbidden global variables in romstage:
>> ffffff00 B val_sc_gp_lvl
>>
>> If i do not call setup_soc_gpios(), not occured the build error.
>>
>>
>> Current status
>> * 1. setup input mode to the target pin*
>> => can read the value from SC_GP_LVL register
>> *2. setup output mode to the target pin*
>> => When a write value to SC_GP_LVL register, successfully change the
>> HIGH/LOW status of pin.
>> => But when a read the value from SC_GP_LVL register, can't read the
>> value.
>>
>>
>> My Goal is a create SW I2C port on my rangeley platform.
>> Almost works is done. But just one is fail.
>>
>> Please advise to me.
>>
>> Thank you.
>>
>>
>>
>> 2016-07-18 오후 3:52에 Zoran Stojsavljevic 이(가) 쓴 글:
>>
>> > But DS is said to me that SC_GP_LVL is WR register.
>>
>> So, as I assumed, SC_GP_LVL is WR ONLY register. If it always works and
>> puts out values, and retains them (which is another of mine assumption),
>> the solution to RD problem is simplistic.
>>
>> Immediately after the: outl(GPIO, gpiobase + GPIO_SC_GP_LVL);
>>
>> Please, always remember the I/O data value you outl() into some heap
>> global variable (which will always retain the latest outl() data value). If
>> you need it back, read this variable.
>>
>> Best Regards,
>> Zoran
>>
>> On Mon, Jul 18, 2016 at 7:20 AM, 김유석 <poplinux0(a)gmail.com> wrote:
>>
>>> Dear Sir.
>>>
>>> I was test with by your advise. But SC_GP_LVL is always read 0x00
>>>
>>> source code & result is see below.
>>>
>>> u32 read_gpio_level(const struct soc_gpio_map *gpio)
>>> {
>>>
>>> u16 gpiobase __attribute__((unused)) =
>>> pci_read_config16(SOC_LPC_DEV, GBASE) & ~0xf;
>>>
>>> printk(BIOS_DEBUG, "%s() : Start\n", __FUNCTION__);
>>> printk(BIOS_DEBUG, " GPIO_SC_USE_SEL : 0x%x\n", inl(gpiobase +
>>> GPIO_SC_USE_SEL));
>>> printk(BIOS_DEBUG, " GPIO_SC_IO_SEL : 0x%x\n", inl(gpiobase +
>>> GPIO_SC_IO_SEL));
>>> printk(BIOS_DEBUG, " GPIO_SC_GP_LVL : 0x%x\n", inl(gpiobase +
>>> GPIO_SC_GP_LVL));
>>> printk(BIOS_DEBUG, "%s() : End\n\n", __FUNCTION__);
>>>
>>> return 0;
>>> }
>>>
>>> int set_gpio_level(const struct soc_gpio_map *gpio,
>>> const int num,
>>> const int lvl)
>>> {
>>> u16 gpiobase __attribute__((unused)) =
>>> pci_read_config16(SOC_LPC_DEV, GBASE) & ~0xf;
>>> u32 GPIO = 0;
>>>
>>> GPIO = setBit(GPIO, num);
>>>
>>> printk(BIOS_DEBUG, "%s() : GPIO set value 0x%x\n", __FUNCTION__,
>>> GPIO);
>>> outl(GPIO, gpiobase + GPIO_SC_GP_LVL);
>>>
>>> return 0;
>>> }
>>>
>>>
>>> void early_mainboard_romstage_entry(void)
>>> {
>>> setup_soc_gpios(&gpio_map);
>>> set_gpio_level(&gpio_map, 12, 1);
>>> mdelay(500);
>>> read_gpio_level(&gpio_map);
>>>
>>> set_gpio_level(&gpio_map, 13, 1);
>>> mdelay(500);
>>> read_gpio_level(&gpio_map);
>>>
>>> set_gpio_level(&gpio_map, 14, 1);
>>> mdelay(500);
>>> read_gpio_level(&gpio_map);
>>> };
>>>
>>>
>>>
>>> ==================================================================================
>>> coreboot-NexG-59a9b0a6 Mon Jul 18 05:09:30 UTC 2016 romstage
>>> starting...
>>> set_gpio_level() : GPIO set value 0x1000
>>> read_gpio_level() : Start
>>> GPIO_SC_USE_SEL : 7000
>>> GPIO_SC_IO_SEL : 0
>>> GPIO_SC_GP_LVL : 0
>>> read_gpio_level() : End
>>>
>>> set_gpio_level() : GPIO set value 0x2000
>>> read_gpio_level() : Start
>>> GPIO_SC_USE_SEL : 7000
>>> GPIO_SC_IO_SEL : 0
>>> GPIO_SC_GP_LVL : 0
>>> read_gpio_level() : End
>>>
>>> set_gpio_level() : GPIO set value 0x4000
>>> read_gpio_level() : Start
>>> GPIO_SC_USE_SEL : 7000
>>> GPIO_SC_IO_SEL : 0
>>> GPIO_SC_GP_LVL : 0
>>> read_gpio_level() : End
>>>
>>>
>>>
>>>
>>>
>>> And I was re-view the DS of C2000.
>>>
>>> But DS is said to me that SC_GP_LVL is WR register.
>>>
>>>
>>>
>>> Please help me.
>>>
>>> Thank you.
>>>
>>>
>>>
>>>
>>> 2016-07-13 오후 4:40에 Zoran Stojsavljevic 이(가) 쓴 글:
>>>
>>> *> When write 0x7000 write to SC_GP_LVL, Can read the 0x00 from
>>> SC_GP_LVL. everytime.*
>>>
>>> Please, try to do the following exercise:
>>>
>>> [1] WR 0x1000 to SC_GP_LVL, then RD the value out of it: what it is?
>>> [2] WR 0x2000 to SC_GP_LVL, then RD the value out of it: what it is?
>>> [3] WR 0x4000 to SC_GP_LVL, then RD the value out of it: what it is?
>>>
>>> If you have all 0x0, most likely it does mean that Rangeley's SC_GP_LVL
>>> register isd WR ONLY (when you read it, all 0s).
>>>
>>> To verify this, you should fetch the following document:
>>>
>>> http://www.intel.com/content/www/us/en/processors/atom/atom-c2000-microserv…
>>>
>>> And read Chapter 25 - General Purpose I/O (GPIO).
>>>
>>> Best Regards,
>>> Zoran
>>>
>>> On Wed, Jul 13, 2016 at 6:39 AM, 김유석 <poplinux0(a)gmail.com> wrote:
>>>
>>>> Dear Sir.
>>>>
>>>>
>>>> I want to control the GPIO pin that pin number is 12, 13, 14
>>>>
>>>>
>>>> DataSheet(P 1909) and coreboot source
>>>> code(src/southbridge/intel/fsp_rangeley/gpio.c, gpio.h) is said to me that
>>>> "It is very easy"
>>>>
>>>>
>>>> If i want to set the HIGH to 12, 13, 14
>>>>
>>>> Just setup the some register, is see below.
>>>>
>>>> SC_USE_SEL = 0x7000(b0111 0000 0000 0000)
>>>>
>>>> Is mean, the 12, 13, 14 is config to GPIO mode.(enable GPIO)
>>>>
>>>> SC_IO_SEL = 0x00(b0000 0000 0000 0000)
>>>>
>>>> Is mean, the 12, 13, 14 is output mode
>>>>
>>>> SC_GP_LVL = 0x7000(b0111 0000 0000 0000)
>>>>
>>>> Is mean, the 12, 13, 14 is set to HIGH level(1)
>>>>
>>>>
>>>> src/southbridge/intel/fsp_rangeley/gpio.h
>>>>
>>>> /* Core GPIO */
>>>> const struct soc_gpio soc_gpio_mode = {
>>>> .gpio12 = GPIO_MODE_GPIO, /* Board ID GPIO */
>>>> .gpio13 = GPIO_MODE_GPIO, /* Board ID GPIO */
>>>> .gpio14 = GPIO_MODE_GPIO, /* Board ID GPIO */
>>>> };
>>>>
>>>> const struct soc_gpio soc_gpio_direction = {
>>>> .gpio12 = GPIO_DIR_OUTPUT,
>>>> .gpio13 = GPIO_DIR_OUTPUT,
>>>> .gpio14 = GPIO_DIR_OUTPUT,
>>>> };
>>>>
>>>> const struct soc_gpio soc_gpio_level = {
>>>> .gpio12 = GPIO_LEVEL_HIGH,
>>>> .gpio13 = GPIO_LEVEL_HIGH,
>>>> .gpio14 = GPIO_LEVEL_HIGH,
>>>> };
>>>>
>>>>
>>>> Yes, It is perfectley running.
>>>>
>>>> The 12, 13, 14 PIN is goto active-HIGH.(I was check this pin use by
>>>> oscilloscope.)
>>>>
>>>>
>>>> And I'm try to read the SC_GP_LVL register for check current
>>>> status/config of gpio pins
>>>>
>>>> I was *respected* the read value is *0x7000*, because i was writed the
>>>> *0x7000* to SC_GP_LVL.
>>>>
>>>>
>>>> But, every time readed the *0x00* from SC_GP_LVL register.
>>>>
>>>>
>>>> *When write 0x7000 write to SC_USE_SEL, Can read the 0x7000 from
>>>> SC_USE_SEL.*
>>>>
>>>> *When write 0x00 write to SC_IO_SEL, Can read the 0x00 from SC_IO_SEL.*
>>>>
>>>>
>>>> But,
>>>>
>>>>
>>>> *When write 0x7000 write to SC_GP_LVL, Can read the 0x00 from
>>>> SC_GP_LVL. everytime.*
>>>>
>>>>
>>>> I don't understand this sistuation.
>>>>
>>>>
>>>> Please advise to me.
>>>>
>>>>
>>>> Thank you.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> coreboot mailing list: coreboot(a)coreboot.org
>>>> https://www.coreboot.org/mailman/listinfo/coreboot
>>>>
>>>
>>>
>>>
>>
>>
>>
>
Dear Zoran.
_I was perectly understand the I2C algo_. It is very easy to me.
And I was know that I2C_DATA line is must need a mode
change(INPUT/OUTPUT) for bidirectional communication.
*At present, I2C is not important to me.*
I want to say. that my purpose is just control GPIO pins.
My problem is...
Suppose this sistuation.
Initial status of gpio
pin
SC_IO_SEL
SC_GP_LVL
GPIO_11(reset of some ic)
output
HIGH
GPIO_12(LED1)
output
LOW
GPIO_13(detect pin)
input
HIGH
After power-on. suppose, must need turn on the GPIO_12(LED1).
It is easy.
void led_control(u32 pin_num)
{
u32 current_status = inl(gbase + SC_GP_LVL);
current_status = setbit(current_status, pin_num);
}
*But, My case is can't read status of outputmode pins.*
Can read the status of *inputmode pins*.
ButCan't read the status of *outputmode pins.*
current status is very important information for bit operation(set/clear).
GPIO_11 is output mode => can't read this status.
GPIO_12 is output mode => can't read this status.
GPIO_13 is input mode => can read this status.
If I try to control without knowing the current state, *must becomes
problem.*
So, I try to find the solution that "How to read the status of
outputmode gpio pins"
Another platform is can get a status of pin. use by "register of IO
direction" and "register of IO Level".
If I use the AND operation, can get a status of output mode pins.
Please any idea?
Thank you.
2016-07-20 오후 3:56에 Zoran Stojsavljevic 이(가) 쓴 글:
> Hello Kim,
>
> Kim, listen to me/read me now very carefully. Please. :-)
>
> For the standard I2C interface, you have only two serial lines:
> I2C_CLK and I2C_DATA. Your C2000 is master, so it will ALWAYS provide
> I2C_CLK as OUT. With I2C_DATA things are a bit more complicated. It is
> IN/OUT line, and once you output on it, you MUST turn it around.
>
> I'll provide to you an adequate example. Let us assume SC_USE_SEL has
> two dedicated IO_14 as I2C_CLK, and IO_13 as I2C_DATA.
>
> For the I2C_CLK, it is always output. For I2C_DATA, it is bidirectional.
>
> So, when you supply slave I2C address on the bus, the following is true:
> GPIO_SC_USE_SEL : 6000
> GPIO_SC_IO_SEL : 0 (all pins as OUT direction)
> GPIO_SC_GP_LVL : bit banging on pins 13, 14
>
> Now, you need to turn around your data bus, to be IN. Here is the
> situation:
> GPIO_SC_USE_SEL : 6000
> GPIO_SC_IO_SEL : 2000 (pin 13 is now defined as IN direction!)
> GPIO_SC_GP_LVL : answer coming on pin 13, you have to sample it
> correctly in time READing this register (only bit 13 is valid) and
> looking into bit 13 value).
>
> You might try it. And I rest my case here, Kim!
>
> Zoran
>
> On Wed, Jul 20, 2016 at 6:52 AM, 김유석 <poplinux0(a)gmail.com
> <mailto:poplinux0@gmail.com>> wrote:
>
> Dear Sir.
>
> I'm understand your worry.
>
> My phase is develop the raw level API for gpio control.
> SW I2C is will use the raw level API. SW I2C is will implementation.
>
> I was set the SC_USE_SEL, and SC_IO_SEL. correctly.
>
> And I already check the some function.
> 1. outmode => is OK.
> If i set the HIGH on 12, 13, 14. then i can saw the HIGH
> status using ocilloscope.
> If i set the LOW on 12, 13, 14. then i can saw the LOW
> status using ocilloscope.
> 2. input mode => is OK.
> If i assign the 3.3V to 12, 13, 14. then i can read the
> SC_GP_LVL(0x7000).
> If i assign the 0V to 12, 13, 14. then i can read the
> SC_GP_LVL(0x00)
>
> But just one function is fail.
>
> step 1. set the output mode. => is success
> step 2. set the level. => is success
> step 3. read the current config of SC_GP_LVL => is fail.
> if if write 0x7000 to SC_GP_LVL, I want to read the value
> 0x7000 from SC_GP_LVL. But i can't
>
> Thank you.
>
>
>
>
> 2016-07-19 오후 9:12에 Zoran Stojsavljevic 이(가) 쓴 글:
>> Hey Kim,
>>
>> You have forced me myself to read the manual (chapter 25, C2000
>> Data Sheet). I was really wondering... So I decided to spend some
>> time and read it myself (anyway, I have some time, albeit I do
>> some other stuff). ;-)
>>
>> There is description of two power domains there, which I/O are
>> using in order to drive customer I/O wishes. Two of them are:
>> Core Well and SUS Well. You are using Core Well GPIOs, namely
>> they are described in Ch. 25.3.1:
>> Choosing the native Signal Mode or Customer GPIO Mode.
>>
>> Inline image 1
>> Questions here: did you set properly register: SC_USE_SEL? Your
>> bits 12/13/14 should be in this register 1s (x111 xxxx xxxx xxxx
>> binary), and you need to set also properly SC_IO_SEL register
>> (them to be outputs). I am now looking into your code, and it
>> seems you did it correctly (three OUT values):
>> GPIO_SC_USE_SEL : 7000
>> GPIO_SC_IO_SEL : 0
>> GPIO_SC_GP_LVL : 0
>>
>> Then you output your OUT values. Hmmmmmm... Considering I2C, you
>> inevitable should read some INPUT values?! Which pins these are?
>> You should have from master (your C2000) to supply CLK and OUT,
>> but you also need to read IN values... Don't you???
>>
>> I do NOT see input from I2C slave device... Any thoughts (any ideas)?
>>
>> Zoran
>>
>> On Mon, Jul 18, 2016 at 7:20 AM, 김유석 <poplinux0(a)gmail.com
>> <mailto:poplinux0@gmail.com>> wrote:
>>
>> Dear Sir.
>>
>> I was test with by your advise. But SC_GP_LVL is always read 0x00
>>
>> source code & result is see below.
>>
>> u32 read_gpio_level(const struct soc_gpio_map *gpio)
>> {
>>
>> u16 gpiobase __attribute__((unused)) =
>> pci_read_config16(SOC_LPC_DEV, GBASE) & ~0xf;
>>
>> printk(BIOS_DEBUG, "%s() : Start\n", __FUNCTION__);
>> printk(BIOS_DEBUG, " GPIO_SC_USE_SEL : 0x%x\n",
>> inl(gpiobase + GPIO_SC_USE_SEL));
>> printk(BIOS_DEBUG, " GPIO_SC_IO_SEL : 0x%x\n",
>> inl(gpiobase + GPIO_SC_IO_SEL));
>> printk(BIOS_DEBUG, " GPIO_SC_GP_LVL : 0x%x\n",
>> inl(gpiobase + GPIO_SC_GP_LVL));
>> printk(BIOS_DEBUG, "%s() : End\n\n", __FUNCTION__);
>>
>> return 0;
>> }
>>
>> int set_gpio_level(const struct soc_gpio_map *gpio,
>> const int num,
>> const int lvl)
>> {
>> u16 gpiobase __attribute__((unused)) =
>> pci_read_config16(SOC_LPC_DEV, GBASE) & ~0xf;
>> u32 GPIO = 0;
>>
>> GPIO = setBit(GPIO, num);
>>
>> printk(BIOS_DEBUG, "%s() : GPIO set value 0x%x\n",
>> __FUNCTION__, GPIO);
>> outl(GPIO, gpiobase + GPIO_SC_GP_LVL);
>>
>> return 0;
>> }
>>
>>
>> void early_mainboard_romstage_entry(void)
>> {
>> setup_soc_gpios(&gpio_map);
>> set_gpio_level(&gpio_map, 12, 1);
>> mdelay(500);
>> read_gpio_level(&gpio_map);
>>
>> set_gpio_level(&gpio_map, 13, 1);
>> mdelay(500);
>> read_gpio_level(&gpio_map);
>>
>> set_gpio_level(&gpio_map, 14, 1);
>> mdelay(500);
>> read_gpio_level(&gpio_map);
>> };
>>
>>
>> ==================================================================================
>> coreboot-NexG-59a9b0a6 Mon Jul 18 05:09:30 UTC 2016
>> romstage starting...
>> set_gpio_level() : GPIO set value 0x1000
>> read_gpio_level() : Start
>> GPIO_SC_USE_SEL : 7000
>> GPIO_SC_IO_SEL : 0
>> GPIO_SC_GP_LVL : 0
>> read_gpio_level() : End
>>
>> set_gpio_level() : GPIO set value 0x2000
>> read_gpio_level() : Start
>> GPIO_SC_USE_SEL : 7000
>> GPIO_SC_IO_SEL : 0
>> GPIO_SC_GP_LVL : 0
>> read_gpio_level() : End
>>
>> set_gpio_level() : GPIO set value 0x4000
>> read_gpio_level() : Start
>> GPIO_SC_USE_SEL : 7000
>> GPIO_SC_IO_SEL : 0
>> GPIO_SC_GP_LVL : 0
>> read_gpio_level() : End
>>
>>
>>
>>
>>
>> And I was re-view the DS of C2000.
>>
>> But DS is said to me that SC_GP_LVL is WR register.
>>
>>
>>
>> Please help me.
>>
>> Thank you.
>>
>>
>>
>>
>> 2016-07-13 오후 4:40에 Zoran Stojsavljevic 이(가) 쓴 글:
>>> *_> When write 0x7000 write to SC_GP_LVL, Can read the 0x00
>>> from SC_GP_LVL. everytime._*
>>>
>>> Please, try to do the following exercise:
>>>
>>> [1] WR 0x1000 to SC_GP_LVL, then RD the value out of it:
>>> what it is?
>>> [2] WR 0x2000 to SC_GP_LVL, then RD the value out of it:
>>> what it is?
>>> [3] WR 0x4000 to SC_GP_LVL, then RD the value out of it:
>>> what it is?
>>>
>>> If you have all 0x0, most likely it does mean that
>>> Rangeley's SC_GP_LVL register isd WR ONLY (when you read it,
>>> all 0s).
>>>
>>> To verify this, you should fetch the following document:
>>> http://www.intel.com/content/www/us/en/processors/atom/atom-c2000-microserv…
>>>
>>> And read Chapter 25 - General Purpose I/O (GPIO).
>>>
>>> Best Regards,
>>> Zoran
>>>
>>> On Wed, Jul 13, 2016 at 6:39 AM, 김유석 <poplinux0(a)gmail.com
>>> <mailto:poplinux0@gmail.com>> wrote:
>>>
>>> Dear Sir.
>>>
>>>
>>> I want to control the GPIO pin that pin number is 12, 13, 14
>>>
>>>
>>> DataSheet(P 1909) and coreboot source
>>> code(src/southbridge/intel/fsp_rangeley/gpio.c, gpio.h)
>>> is said to me that "It is very easy"
>>>
>>>
>>> If i want to set the HIGH to 12, 13, 14
>>>
>>> Just setup the some register, is see below.
>>>
>>> SC_USE_SEL = 0x7000(b0111 0000 0000 0000)
>>>
>>> Is mean, the 12, 13, 14 is config to GPIO
>>> mode.(enable GPIO)
>>>
>>> SC_IO_SEL = 0x00(b0000 0000 0000 0000)
>>>
>>> Is mean, the 12, 13, 14 is output mode
>>>
>>> SC_GP_LVL = 0x7000(b0111 0000 0000 0000)
>>>
>>> Is mean, the 12, 13, 14 is set to HIGH level(1)
>>>
>>>
>>> src/southbridge/intel/fsp_rangeley/gpio.h
>>>
>>> /* Core GPIO */
>>> const struct soc_gpio soc_gpio_mode = {
>>> .gpio12 = GPIO_MODE_GPIO, /* Board ID GPIO */
>>> .gpio13 = GPIO_MODE_GPIO, /* Board ID GPIO */
>>> .gpio14 = GPIO_MODE_GPIO, /* Board ID GPIO */
>>> };
>>>
>>> const struct soc_gpio soc_gpio_direction = {
>>> .gpio12 = GPIO_DIR_OUTPUT,
>>> .gpio13 = GPIO_DIR_OUTPUT,
>>> .gpio14 = GPIO_DIR_OUTPUT,
>>> };
>>>
>>> const struct soc_gpio soc_gpio_level = {
>>> .gpio12 = GPIO_LEVEL_HIGH,
>>> .gpio13 = GPIO_LEVEL_HIGH,
>>> .gpio14 = GPIO_LEVEL_HIGH,
>>> };
>>>
>>>
>>> Yes, It is perfectley running.
>>>
>>> The 12, 13, 14 PIN is goto active-HIGH.(I was check this
>>> pin use by oscilloscope.)
>>>
>>>
>>> And I'm try to read the SC_GP_LVL register for check
>>> current status/config of gpio pins
>>>
>>> I was *respected* the read value is *0x7000*, because i
>>> was writed the *0x7000* to SC_GP_LVL.
>>>
>>>
>>> But, every time readed the *0x00* from SC_GP_LVL register.
>>>
>>>
>>> _When write 0x7000 write to SC_USE_SEL, Can read the
>>> 0x7000 from SC_USE_SEL._
>>>
>>> _When write 0x00 write to SC_IO_SEL, Can read the 0x00
>>> from SC_IO_SEL._
>>>
>>>
>>> But,
>>>
>>>
>>> *_When write 0x7000 write to SC_GP_LVL, Can read the
>>> 0x00 from SC_GP_LVL. everytime._*
>>>
>>>
>>> I don't understand this sistuation.
>>>
>>>
>>> Please advise to me.
>>>
>>>
>>> Thank you.
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>> coreboot mailing list: coreboot(a)coreboot.org
>>> <mailto:coreboot@coreboot.org>
>>> https://www.coreboot.org/mailman/listinfo/coreboot
>>>
>>>
>>
>>
>
>
Hello Kim,
Kim, listen to me/read me now very carefully. Please. :-)
For the standard I2C interface, you have only two serial lines: I2C_CLK and
I2C_DATA. Your C2000 is master, so it will ALWAYS provide I2C_CLK as OUT.
With I2C_DATA things are a bit more complicated. It is IN/OUT line, and
once you output on it, you MUST turn it around.
I'll provide to you an adequate example. Let us assume SC_USE_SEL has two
dedicated IO_14 as I2C_CLK, and IO_13 as I2C_DATA.
For the I2C_CLK, it is always output. For I2C_DATA, it is bidirectional.
So, when you supply slave I2C address on the bus, the following is true:
GPIO_SC_USE_SEL : 6000
GPIO_SC_IO_SEL : 0 (all pins as OUT direction)
GPIO_SC_GP_LVL : bit banging on pins 13, 14
Now, you need to turn around your data bus, to be IN. Here is the situation:
GPIO_SC_USE_SEL : 6000
GPIO_SC_IO_SEL : 2000 (pin 13 is now defined as IN direction!)
GPIO_SC_GP_LVL : answer coming on pin 13, you have to sample it correctly
in time READing this register (only bit 13 is valid) and looking into bit
13 value).
You might try it. And I rest my case here, Kim!
Zoran
On Wed, Jul 20, 2016 at 6:52 AM, 김유석 <poplinux0(a)gmail.com> wrote:
> Dear Sir.
>
> I'm understand your worry.
>
> My phase is develop the raw level API for gpio control.
> SW I2C is will use the raw level API. SW I2C is will implementation.
>
> I was set the SC_USE_SEL, and SC_IO_SEL. correctly.
>
> And I already check the some function.
> 1. outmode => is OK.
> If i set the HIGH on 12, 13, 14. then i can saw the HIGH status
> using ocilloscope.
> If i set the LOW on 12, 13, 14. then i can saw the LOW status using
> ocilloscope.
> 2. input mode => is OK.
> If i assign the 3.3V to 12, 13, 14. then i can read the
> SC_GP_LVL(0x7000).
> If i assign the 0V to 12, 13, 14. then i can read the SC_GP_LVL(0x00)
>
> But just one function is fail.
>
> step 1. set the output mode. => is success
> step 2. set the level. => is success
> step 3. read the current config of SC_GP_LVL => is fail.
> if if write 0x7000 to SC_GP_LVL, I want to read the value 0x7000
> from SC_GP_LVL. But i can't
>
> Thank you.
>
>
>
>
> 2016-07-19 오후 9:12에 Zoran Stojsavljevic 이(가) 쓴 글:
>
> Hey Kim,
>
> You have forced me myself to read the manual (chapter 25, C2000 Data
> Sheet). I was really wondering... So I decided to spend some time and read
> it myself (anyway, I have some time, albeit I do some other stuff). ;-)
>
> There is description of two power domains there, which I/O are using in
> order to drive customer I/O wishes. Two of them are: Core Well and SUS
> Well. You are using Core Well GPIOs, namely they are described in Ch.
> 25.3.1:
> Choosing the native Signal Mode or Customer GPIO Mode.
>
> [image: Inline image 1]
>
> Questions here: did you set properly register: SC_USE_SEL? Your bits
> 12/13/14 should be in this register 1s (x111 xxxx xxxx xxxx binary), and
> you need to set also properly SC_IO_SEL register (them to be outputs). I am
> now looking into your code, and it seems you did it correctly (three OUT
> values):
> GPIO_SC_USE_SEL : 7000
> GPIO_SC_IO_SEL : 0
> GPIO_SC_GP_LVL : 0
>
> Then you output your OUT values. Hmmmmmm... Considering I2C, you
> inevitable should read some INPUT values?! Which pins these are? You should
> have from master (your C2000) to supply CLK and OUT, but you also need to
> read IN values... Don't you???
>
> I do NOT see input from I2C slave device... Any thoughts (any ideas)?
>
> Zoran
>
> On Mon, Jul 18, 2016 at 7:20 AM, 김유석 <poplinux0(a)gmail.com> wrote:
>
>> Dear Sir.
>>
>> I was test with by your advise. But SC_GP_LVL is always read 0x00
>>
>> source code & result is see below.
>>
>> u32 read_gpio_level(const struct soc_gpio_map *gpio)
>> {
>>
>> u16 gpiobase __attribute__((unused)) = pci_read_config16(SOC_LPC_DEV,
>> GBASE) & ~0xf;
>>
>> printk(BIOS_DEBUG, "%s() : Start\n", __FUNCTION__);
>> printk(BIOS_DEBUG, " GPIO_SC_USE_SEL : 0x%x\n", inl(gpiobase +
>> GPIO_SC_USE_SEL));
>> printk(BIOS_DEBUG, " GPIO_SC_IO_SEL : 0x%x\n", inl(gpiobase +
>> GPIO_SC_IO_SEL));
>> printk(BIOS_DEBUG, " GPIO_SC_GP_LVL : 0x%x\n", inl(gpiobase +
>> GPIO_SC_GP_LVL));
>> printk(BIOS_DEBUG, "%s() : End\n\n", __FUNCTION__);
>>
>> return 0;
>> }
>>
>> int set_gpio_level(const struct soc_gpio_map *gpio,
>> const int num,
>> const int lvl)
>> {
>> u16 gpiobase __attribute__((unused)) = pci_read_config16(SOC_LPC_DEV,
>> GBASE) & ~0xf;
>> u32 GPIO = 0;
>>
>> GPIO = setBit(GPIO, num);
>>
>> printk(BIOS_DEBUG, "%s() : GPIO set value 0x%x\n", __FUNCTION__,
>> GPIO);
>> outl(GPIO, gpiobase + GPIO_SC_GP_LVL);
>>
>> return 0;
>> }
>>
>>
>> void early_mainboard_romstage_entry(void)
>> {
>> setup_soc_gpios(&gpio_map);
>> set_gpio_level(&gpio_map, 12, 1);
>> mdelay(500);
>> read_gpio_level(&gpio_map);
>>
>> set_gpio_level(&gpio_map, 13, 1);
>> mdelay(500);
>> read_gpio_level(&gpio_map);
>>
>> set_gpio_level(&gpio_map, 14, 1);
>> mdelay(500);
>> read_gpio_level(&gpio_map);
>> };
>>
>>
>>
>> ==================================================================================
>> coreboot-NexG-59a9b0a6 Mon Jul 18 05:09:30 UTC 2016 romstage starting...
>> set_gpio_level() : GPIO set value 0x1000
>> read_gpio_level() : Start
>> GPIO_SC_USE_SEL : 7000
>> GPIO_SC_IO_SEL : 0
>> GPIO_SC_GP_LVL : 0
>> read_gpio_level() : End
>>
>> set_gpio_level() : GPIO set value 0x2000
>> read_gpio_level() : Start
>> GPIO_SC_USE_SEL : 7000
>> GPIO_SC_IO_SEL : 0
>> GPIO_SC_GP_LVL : 0
>> read_gpio_level() : End
>>
>> set_gpio_level() : GPIO set value 0x4000
>> read_gpio_level() : Start
>> GPIO_SC_USE_SEL : 7000
>> GPIO_SC_IO_SEL : 0
>> GPIO_SC_GP_LVL : 0
>> read_gpio_level() : End
>>
>>
>>
>>
>>
>> And I was re-view the DS of C2000.
>>
>> But DS is said to me that SC_GP_LVL is WR register.
>>
>>
>>
>> Please help me.
>>
>> Thank you.
>>
>>
>>
>>
>> 2016-07-13 오후 4:40에 Zoran Stojsavljevic 이(가) 쓴 글:
>>
>> *> When write 0x7000 write to SC_GP_LVL, Can read the 0x00 from
>> SC_GP_LVL. everytime.*
>>
>> Please, try to do the following exercise:
>>
>> [1] WR 0x1000 to SC_GP_LVL, then RD the value out of it: what it is?
>> [2] WR 0x2000 to SC_GP_LVL, then RD the value out of it: what it is?
>> [3] WR 0x4000 to SC_GP_LVL, then RD the value out of it: what it is?
>>
>> If you have all 0x0, most likely it does mean that Rangeley's SC_GP_LVL
>> register isd WR ONLY (when you read it, all 0s).
>>
>> To verify this, you should fetch the following document:
>>
>> http://www.intel.com/content/www/us/en/processors/atom/atom-c2000-microserv…
>>
>> And read Chapter 25 - General Purpose I/O (GPIO).
>>
>> Best Regards,
>> Zoran
>>
>> On Wed, Jul 13, 2016 at 6:39 AM, 김유석 <poplinux0(a)gmail.com> wrote:
>>
>>> Dear Sir.
>>>
>>>
>>> I want to control the GPIO pin that pin number is 12, 13, 14
>>>
>>>
>>> DataSheet(P 1909) and coreboot source
>>> code(src/southbridge/intel/fsp_rangeley/gpio.c, gpio.h) is said to me that
>>> "It is very easy"
>>>
>>>
>>> If i want to set the HIGH to 12, 13, 14
>>>
>>> Just setup the some register, is see below.
>>>
>>> SC_USE_SEL = 0x7000(b0111 0000 0000 0000)
>>>
>>> Is mean, the 12, 13, 14 is config to GPIO mode.(enable GPIO)
>>>
>>> SC_IO_SEL = 0x00(b0000 0000 0000 0000)
>>>
>>> Is mean, the 12, 13, 14 is output mode
>>>
>>> SC_GP_LVL = 0x7000(b0111 0000 0000 0000)
>>>
>>> Is mean, the 12, 13, 14 is set to HIGH level(1)
>>>
>>>
>>> src/southbridge/intel/fsp_rangeley/gpio.h
>>>
>>> /* Core GPIO */
>>> const struct soc_gpio soc_gpio_mode = {
>>> .gpio12 = GPIO_MODE_GPIO, /* Board ID GPIO */
>>> .gpio13 = GPIO_MODE_GPIO, /* Board ID GPIO */
>>> .gpio14 = GPIO_MODE_GPIO, /* Board ID GPIO */
>>> };
>>>
>>> const struct soc_gpio soc_gpio_direction = {
>>> .gpio12 = GPIO_DIR_OUTPUT,
>>> .gpio13 = GPIO_DIR_OUTPUT,
>>> .gpio14 = GPIO_DIR_OUTPUT,
>>> };
>>>
>>> const struct soc_gpio soc_gpio_level = {
>>> .gpio12 = GPIO_LEVEL_HIGH,
>>> .gpio13 = GPIO_LEVEL_HIGH,
>>> .gpio14 = GPIO_LEVEL_HIGH,
>>> };
>>>
>>>
>>> Yes, It is perfectley running.
>>>
>>> The 12, 13, 14 PIN is goto active-HIGH.(I was check this pin use by
>>> oscilloscope.)
>>>
>>>
>>> And I'm try to read the SC_GP_LVL register for check current
>>> status/config of gpio pins
>>>
>>> I was *respected* the read value is *0x7000*, because i was writed the
>>> *0x7000* to SC_GP_LVL.
>>>
>>>
>>> But, every time readed the *0x00* from SC_GP_LVL register.
>>>
>>>
>>> *When write 0x7000 write to SC_USE_SEL, Can read the 0x7000 from
>>> SC_USE_SEL.*
>>>
>>> *When write 0x00 write to SC_IO_SEL, Can read the 0x00 from SC_IO_SEL.*
>>>
>>>
>>> But,
>>>
>>>
>>> *When write 0x7000 write to SC_GP_LVL, Can read the 0x00 from SC_GP_LVL.
>>> everytime.*
>>>
>>>
>>> I don't understand this sistuation.
>>>
>>>
>>> Please advise to me.
>>>
>>>
>>> Thank you.
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>> coreboot mailing list: coreboot(a)coreboot.org
>>> https://www.coreboot.org/mailman/listinfo/coreboot
>>>
>>
>>
>>
>
>
Dear Sir.
Thank's your advise.
SW I2C is request of my client. to control special device.
And my customer are required to control at the romstage phase.
So, I try to find the solution of sw I2C on romstage.
But, if it is determined to be impossible, I'll be to convince customers.
Thank you.
2016-07-19 오후 6:42에 Zoran Stojsavljevic 이(가) 쓴 글:
> Hello 김유석,
>
> I did not understand (very imporatnt question): why at all you do need
> SW I2C (bit-banging I2C) in Coreboot romstage? Maybe you can move your
> I2C operation later, in ramstage?!
>
> Isn't romstage just to do very quick boot and pass the phase where MRC
> (DDRs) should be initialized? And not sure if both L1 cashes are set
> as CAR (L1 I-cache as well as L1 D-cache)? It seems to me that only L1
> D-cache is initialized as CAR, L1 I-cache remains to be true cache for
> flash code to be executed fast.
>
> I do know that romstage is compiled with the special ROMCC compiler,
> which was adopted by Eric Biederman (2003-2006, ebiederman(a)lnxi.com
> <mailto:iederman@lnxi.com>):
> https://github.com/wt/coreboot/blob/master/util/romcc/romcc.1
>
> Maybe, this compiler allows you to store your outl() value into some
> 32-bit reserved (for this purpose) common purpose register (instead of
> global variable), but at this point in time, I need more time to
> investigate ROMCC.
>
> Some other people very well might know answers about ROMCC on coreboot
> mailing list. ;-)
>
> Zoran
>
> On Tue, Jul 19, 2016 at 8:40 AM, 김유석 <poplinux0(a)gmail.com
> <mailto:poplinux0@gmail.com>> wrote:
>
> Sorry. i was have a miss-typing.
>
>> I can read the some global variable. => X
>> I can't read the some global variable. => O
>
>
> Thank you.
>
>
>
> 2016-07-19 오후 3:26에 김유석 이(가) 쓴 글:
>> Dear Sir.
>>
>> Thank's your advise.
>>
>> I can read the some global variable.
>> Because the outl() api is directly write value to register. Not
>> global variable. I guess.
>>
>> Perhaps, your mean is a must use GLOBAL value for SC_GP_LVL?(do
>> not try to read from SC_GP_LVL)
>> I was try to use the GLOBAL value on coreboot. But occured the
>> compile error.
>>
>> the global value "u32 val_sc_gp_lvl" is defined on
>> "src/southbridge/intel/fsp_rangeley/gpio.c"
>> and use this value is on
>> "src/southbridge/intel/fsp_rangeley/gpio.c::setup_soc_gpios()"
>>
>> If i call setup_soc_gpios() is
>> "src/mainboard/intel/mohonpeak/romstage.c::early_mainboard_romstage_entry()",
>> occured build error. log is see below.
>>
>> OBJCOPY cbfs/fallback/bootblock.elf
>> LINK cbfs/fallback/romstage.debug
>> OBJCOPY bootblock.raw.bin
>> Forbidden global variables in romstage:
>> ffffff00 B val_sc_gp_lvl
>>
>> If i do not call setup_soc_gpios(), not occured the build error.
>>
>>
>> Current status
>> * 1. setup input mode to the target pin*
>> => can read the value from SC_GP_LVL register
>> *2. setup output mode to the target pin*
>> => When a write value to SC_GP_LVL register, successfully
>> change the HIGH/LOW status of pin.
>> => But when a read the value from SC_GP_LVL register, can't
>> read the value.
>>
>>
>> My Goal is a create SW I2C port on my rangeley platform.
>> Almost works is done. But just one is fail.
>>
>> Please advise to me.
>>
>> Thank you.
>>
>>
>>
>> 2016-07-18 오후 3:52에 Zoran Stojsavljevic 이(가) 쓴 글:
>>> > But DS is said to me that SC_GP_LVL is WR register.
>>>
>>> So, as I assumed, SC_GP_LVL is WR ONLY register. If it always
>>> works and puts out values, and retains them (which is another of
>>> mine assumption), the solution to RD problem is simplistic.
>>>
>>> Immediately after the:outl(GPIO, gpiobase + GPIO_SC_GP_LVL);
>>>
>>> Please, always remember the I/O data value you outl() into some
>>> heap global variable (which will always retain the latest outl()
>>> data value). If you need it back, read this variable.
>>>
>>> Best Regards,
>>> Zoran
>>>
>>> On Mon, Jul 18, 2016 at 7:20 AM, 김유석 <poplinux0(a)gmail.com
>>> <mailto:poplinux0@gmail.com>> wrote:
>>>
>>> Dear Sir.
>>>
>>> I was test with by your advise. But SC_GP_LVL is always read
>>> 0x00
>>>
>>> source code & result is see below.
>>>
>>> u32 read_gpio_level(const struct soc_gpio_map *gpio)
>>> {
>>>
>>> u16 gpiobase __attribute__((unused)) =
>>> pci_read_config16(SOC_LPC_DEV, GBASE) & ~0xf;
>>>
>>> printk(BIOS_DEBUG, "%s() : Start\n", __FUNCTION__);
>>> printk(BIOS_DEBUG, " GPIO_SC_USE_SEL : 0x%x\n",
>>> inl(gpiobase + GPIO_SC_USE_SEL));
>>> printk(BIOS_DEBUG, " GPIO_SC_IO_SEL : 0x%x\n",
>>> inl(gpiobase + GPIO_SC_IO_SEL));
>>> printk(BIOS_DEBUG, " GPIO_SC_GP_LVL : 0x%x\n",
>>> inl(gpiobase + GPIO_SC_GP_LVL));
>>> printk(BIOS_DEBUG, "%s() : End\n\n", __FUNCTION__);
>>>
>>> return 0;
>>> }
>>>
>>> int set_gpio_level(const struct soc_gpio_map *gpio,
>>> const int num,
>>> const int lvl)
>>> {
>>> u16 gpiobase __attribute__((unused)) =
>>> pci_read_config16(SOC_LPC_DEV, GBASE) & ~0xf;
>>> u32 GPIO = 0;
>>>
>>> GPIO = setBit(GPIO, num);
>>>
>>> printk(BIOS_DEBUG, "%s() : GPIO set value 0x%x\n",
>>> __FUNCTION__, GPIO);
>>> outl(GPIO, gpiobase + GPIO_SC_GP_LVL);
>>>
>>> return 0;
>>> }
>>>
>>>
>>> void early_mainboard_romstage_entry(void)
>>> {
>>> setup_soc_gpios(&gpio_map);
>>> set_gpio_level(&gpio_map, 12, 1);
>>> mdelay(500);
>>> read_gpio_level(&gpio_map);
>>>
>>> set_gpio_level(&gpio_map, 13, 1);
>>> mdelay(500);
>>> read_gpio_level(&gpio_map);
>>>
>>> set_gpio_level(&gpio_map, 14, 1);
>>> mdelay(500);
>>> read_gpio_level(&gpio_map);
>>> };
>>>
>>>
>>> ==================================================================================
>>> coreboot-NexG-59a9b0a6 Mon Jul 18 05:09:30 UTC 2016
>>> romstage starting...
>>> set_gpio_level() : GPIO set value 0x1000
>>> read_gpio_level() : Start
>>> GPIO_SC_USE_SEL : 7000
>>> GPIO_SC_IO_SEL : 0
>>> GPIO_SC_GP_LVL : 0
>>> read_gpio_level() : End
>>>
>>> set_gpio_level() : GPIO set value 0x2000
>>> read_gpio_level() : Start
>>> GPIO_SC_USE_SEL : 7000
>>> GPIO_SC_IO_SEL : 0
>>> GPIO_SC_GP_LVL : 0
>>> read_gpio_level() : End
>>>
>>> set_gpio_level() : GPIO set value 0x4000
>>> read_gpio_level() : Start
>>> GPIO_SC_USE_SEL : 7000
>>> GPIO_SC_IO_SEL : 0
>>> GPIO_SC_GP_LVL : 0
>>> read_gpio_level() : End
>>>
>>>
>>>
>>>
>>>
>>> And I was re-view the DS of C2000.
>>>
>>> But DS is said to me that SC_GP_LVL is WR register.
>>>
>>>
>>>
>>> Please help me.
>>>
>>> Thank you.
>>>
>>>
>>>
>>>
>>> 2016-07-13 오후 4:40에 Zoran Stojsavljevic 이(가) 쓴 글:
>>>> *_> When write 0x7000 write to SC_GP_LVL, Can read the 0x00
>>>> from SC_GP_LVL. everytime._*
>>>>
>>>> Please, try to do the following exercise:
>>>>
>>>> [1] WR 0x1000 to SC_GP_LVL, then RD the value out of it:
>>>> what it is?
>>>> [2] WR 0x2000 to SC_GP_LVL, then RD the value out of it:
>>>> what it is?
>>>> [3] WR 0x4000 to SC_GP_LVL, then RD the value out of it:
>>>> what it is?
>>>>
>>>> If you have all 0x0, most likely it does mean that
>>>> Rangeley's SC_GP_LVL register isd WR ONLY (when you read
>>>> it, all 0s).
>>>>
>>>> To verify this, you should fetch the following document:
>>>> http://www.intel.com/content/www/us/en/processors/atom/atom-c2000-microserv…
>>>>
>>>> And read Chapter 25 - General Purpose I/O (GPIO).
>>>>
>>>> Best Regards,
>>>> Zoran
>>>>
>>>> On Wed, Jul 13, 2016 at 6:39 AM, 김유석 <poplinux0(a)gmail.com
>>>> <mailto:poplinux0@gmail.com>> wrote:
>>>>
>>>> Dear Sir.
>>>>
>>>>
>>>> I want to control the GPIO pin that pin number is 12,
>>>> 13, 14
>>>>
>>>>
>>>> DataSheet(P 1909) and coreboot source
>>>> code(src/southbridge/intel/fsp_rangeley/gpio.c, gpio.h)
>>>> is said to me that "It is very easy"
>>>>
>>>>
>>>> If i want to set the HIGH to 12, 13, 14
>>>>
>>>> Just setup the some register, is see below.
>>>>
>>>> SC_USE_SEL = 0x7000(b0111 0000 0000 0000)
>>>>
>>>> Is mean, the 12, 13, 14 is config to GPIO
>>>> mode.(enable GPIO)
>>>>
>>>> SC_IO_SEL = 0x00(b0000 0000 0000 0000)
>>>>
>>>> Is mean, the 12, 13, 14 is output mode
>>>>
>>>> SC_GP_LVL = 0x7000(b0111 0000 0000 0000)
>>>>
>>>> Is mean, the 12, 13, 14 is set to HIGH level(1)
>>>>
>>>>
>>>> src/southbridge/intel/fsp_rangeley/gpio.h
>>>>
>>>> /* Core GPIO */
>>>> const struct soc_gpio soc_gpio_mode = {
>>>> .gpio12 = GPIO_MODE_GPIO, /* Board ID GPIO */
>>>> .gpio13 = GPIO_MODE_GPIO, /* Board ID GPIO */
>>>> .gpio14 = GPIO_MODE_GPIO, /* Board ID GPIO */
>>>> };
>>>>
>>>> const struct soc_gpio soc_gpio_direction = {
>>>> .gpio12 = GPIO_DIR_OUTPUT,
>>>> .gpio13 = GPIO_DIR_OUTPUT,
>>>> .gpio14 = GPIO_DIR_OUTPUT,
>>>> };
>>>>
>>>> const struct soc_gpio soc_gpio_level = {
>>>> .gpio12 = GPIO_LEVEL_HIGH,
>>>> .gpio13 = GPIO_LEVEL_HIGH,
>>>> .gpio14 = GPIO_LEVEL_HIGH,
>>>> };
>>>>
>>>>
>>>> Yes, It is perfectley running.
>>>>
>>>> The 12, 13, 14 PIN is goto active-HIGH.(I was check
>>>> this pin use by oscilloscope.)
>>>>
>>>>
>>>> And I'm try to read the SC_GP_LVL register for check
>>>> current status/config of gpio pins
>>>>
>>>> I was *respected* the read value is *0x7000*, because i
>>>> was writed the *0x7000* to SC_GP_LVL.
>>>>
>>>>
>>>> But, every time readed the *0x00* from SC_GP_LVL register.
>>>>
>>>>
>>>> _When write 0x7000 write to SC_USE_SEL, Can read the
>>>> 0x7000 from SC_USE_SEL._
>>>>
>>>> _When write 0x00 write to SC_IO_SEL, Can read the 0x00
>>>> from SC_IO_SEL._
>>>>
>>>>
>>>> But,
>>>>
>>>>
>>>> *_When write 0x7000 write to SC_GP_LVL, Can read the
>>>> 0x00 from SC_GP_LVL. everytime._*
>>>>
>>>>
>>>> I don't understand this sistuation.
>>>>
>>>>
>>>> Please advise to me.
>>>>
>>>>
>>>> Thank you.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> coreboot mailing list: coreboot(a)coreboot.org
>>>> <mailto:coreboot@coreboot.org>
>>>> https://www.coreboot.org/mailman/listinfo/coreboot
>>>>
>>>>
>>>
>>>
>>
>
>
The ASUS KGPE-D16 fails verification for branch master as of commit dc97b1ce2f4e671e73e2a3fb65e49a881a694590
The following tests failed:
BOOT_FAILURE
Commits since last successful test:
dc97b1c soc/intel/apollolake: Fix bitshift issue in bootblock
b921725 nb/intel/x4x: Fix CAS latency detection
47995fb arch/riscv: Remove enter_supervisor
b8e67ac arch/riscv: Change all eret instructions to .word 0x30200073 (mret)
5d687ad google/oak & elm: initialize touchscreen reset gpio
<124 commits skipped>
70cd543 AMD k8 fam10: Drop excessive spinlock initialization
b5664de Romstage spinlocks require EARLY_CBMEM_INIT
d113190 AMD k8 fam10: Fix romstage handoff
880b458 google/chromeec: Update EC command header
1f83ffa gru: include ram_code in coreboot table
See attached log for details
This message was automatically generated from Raptor Engineering's ASUS KGPE-D16 test stand
Want to test on your own equipment? Check out https://www.raptorengineeringinc.com/content/REACTS/intro.html
Raptor Engineering also offers coreboot consulting services! Please visit https://www.raptorengineeringinc.com for more information
Please contact Timothy Pearson at Raptor Engineering <tpearson(a)raptorengineeringinc.com> regarding any issues stemming from this notification
Hey Kim,
You have forced me myself to read the manual (chapter 25, C2000 Data
Sheet). I was really wondering... So I decided to spend some time and read
it myself (anyway, I have some time, albeit I do some other stuff). ;-)
There is description of two power domains there, which I/O are using in
order to drive customer I/O wishes. Two of them are: Core Well and SUS
Well. You are using Core Well GPIOs, namely they are described in Ch.
25.3.1:
Choosing the native Signal Mode or Customer GPIO Mode.
[image: Inline image 1]
Questions here: did you set properly register: SC_USE_SEL? Your bits
12/13/14 should be in this register 1s (x111 xxxx xxxx xxxx binary), and
you need to set also properly SC_IO_SEL register (them to be outputs). I am
now looking into your code, and it seems you did it correctly (three OUT
values):
GPIO_SC_USE_SEL : 7000
GPIO_SC_IO_SEL : 0
GPIO_SC_GP_LVL : 0
Then you output your OUT values. Hmmmmmm... Considering I2C, you inevitable
should read some INPUT values?! Which pins these are? You should have from
master (your C2000) to supply CLK and OUT, but you also need to read IN
values... Don't you???
I do NOT see input from I2C slave device... Any thoughts (any ideas)?
Zoran
On Mon, Jul 18, 2016 at 7:20 AM, 김유석 <poplinux0(a)gmail.com> wrote:
> Dear Sir.
>
> I was test with by your advise. But SC_GP_LVL is always read 0x00
>
> source code & result is see below.
>
> u32 read_gpio_level(const struct soc_gpio_map *gpio)
> {
>
> u16 gpiobase __attribute__((unused)) = pci_read_config16(SOC_LPC_DEV,
> GBASE) & ~0xf;
>
> printk(BIOS_DEBUG, "%s() : Start\n", __FUNCTION__);
> printk(BIOS_DEBUG, " GPIO_SC_USE_SEL : 0x%x\n", inl(gpiobase +
> GPIO_SC_USE_SEL));
> printk(BIOS_DEBUG, " GPIO_SC_IO_SEL : 0x%x\n", inl(gpiobase +
> GPIO_SC_IO_SEL));
> printk(BIOS_DEBUG, " GPIO_SC_GP_LVL : 0x%x\n", inl(gpiobase +
> GPIO_SC_GP_LVL));
> printk(BIOS_DEBUG, "%s() : End\n\n", __FUNCTION__);
>
> return 0;
> }
>
> int set_gpio_level(const struct soc_gpio_map *gpio,
> const int num,
> const int lvl)
> {
> u16 gpiobase __attribute__((unused)) = pci_read_config16(SOC_LPC_DEV,
> GBASE) & ~0xf;
> u32 GPIO = 0;
>
> GPIO = setBit(GPIO, num);
>
> printk(BIOS_DEBUG, "%s() : GPIO set value 0x%x\n", __FUNCTION__, GPIO);
> outl(GPIO, gpiobase + GPIO_SC_GP_LVL);
>
> return 0;
> }
>
>
> void early_mainboard_romstage_entry(void)
> {
> setup_soc_gpios(&gpio_map);
> set_gpio_level(&gpio_map, 12, 1);
> mdelay(500);
> read_gpio_level(&gpio_map);
>
> set_gpio_level(&gpio_map, 13, 1);
> mdelay(500);
> read_gpio_level(&gpio_map);
>
> set_gpio_level(&gpio_map, 14, 1);
> mdelay(500);
> read_gpio_level(&gpio_map);
> };
>
>
>
> ==================================================================================
> coreboot-NexG-59a9b0a6 Mon Jul 18 05:09:30 UTC 2016 romstage starting...
> set_gpio_level() : GPIO set value 0x1000
> read_gpio_level() : Start
> GPIO_SC_USE_SEL : 7000
> GPIO_SC_IO_SEL : 0
> GPIO_SC_GP_LVL : 0
> read_gpio_level() : End
>
> set_gpio_level() : GPIO set value 0x2000
> read_gpio_level() : Start
> GPIO_SC_USE_SEL : 7000
> GPIO_SC_IO_SEL : 0
> GPIO_SC_GP_LVL : 0
> read_gpio_level() : End
>
> set_gpio_level() : GPIO set value 0x4000
> read_gpio_level() : Start
> GPIO_SC_USE_SEL : 7000
> GPIO_SC_IO_SEL : 0
> GPIO_SC_GP_LVL : 0
> read_gpio_level() : End
>
>
>
>
>
> And I was re-view the DS of C2000.
>
> But DS is said to me that SC_GP_LVL is WR register.
>
>
>
> Please help me.
>
> Thank you.
>
>
>
>
> 2016-07-13 오후 4:40에 Zoran Stojsavljevic 이(가) 쓴 글:
>
> *> When write 0x7000 write to SC_GP_LVL, Can read the 0x00 from SC_GP_LVL.
> everytime.*
>
> Please, try to do the following exercise:
>
> [1] WR 0x1000 to SC_GP_LVL, then RD the value out of it: what it is?
> [2] WR 0x2000 to SC_GP_LVL, then RD the value out of it: what it is?
> [3] WR 0x4000 to SC_GP_LVL, then RD the value out of it: what it is?
>
> If you have all 0x0, most likely it does mean that Rangeley's SC_GP_LVL
> register isd WR ONLY (when you read it, all 0s).
>
> To verify this, you should fetch the following document:
>
> http://www.intel.com/content/www/us/en/processors/atom/atom-c2000-microserv…
>
> And read Chapter 25 - General Purpose I/O (GPIO).
>
> Best Regards,
> Zoran
>
> On Wed, Jul 13, 2016 at 6:39 AM, 김유석 <poplinux0(a)gmail.com> wrote:
>
>> Dear Sir.
>>
>>
>> I want to control the GPIO pin that pin number is 12, 13, 14
>>
>>
>> DataSheet(P 1909) and coreboot source
>> code(src/southbridge/intel/fsp_rangeley/gpio.c, gpio.h) is said to me that
>> "It is very easy"
>>
>>
>> If i want to set the HIGH to 12, 13, 14
>>
>> Just setup the some register, is see below.
>>
>> SC_USE_SEL = 0x7000(b0111 0000 0000 0000)
>>
>> Is mean, the 12, 13, 14 is config to GPIO mode.(enable GPIO)
>>
>> SC_IO_SEL = 0x00(b0000 0000 0000 0000)
>>
>> Is mean, the 12, 13, 14 is output mode
>>
>> SC_GP_LVL = 0x7000(b0111 0000 0000 0000)
>>
>> Is mean, the 12, 13, 14 is set to HIGH level(1)
>>
>>
>> src/southbridge/intel/fsp_rangeley/gpio.h
>>
>> /* Core GPIO */
>> const struct soc_gpio soc_gpio_mode = {
>> .gpio12 = GPIO_MODE_GPIO, /* Board ID GPIO */
>> .gpio13 = GPIO_MODE_GPIO, /* Board ID GPIO */
>> .gpio14 = GPIO_MODE_GPIO, /* Board ID GPIO */
>> };
>>
>> const struct soc_gpio soc_gpio_direction = {
>> .gpio12 = GPIO_DIR_OUTPUT,
>> .gpio13 = GPIO_DIR_OUTPUT,
>> .gpio14 = GPIO_DIR_OUTPUT,
>> };
>>
>> const struct soc_gpio soc_gpio_level = {
>> .gpio12 = GPIO_LEVEL_HIGH,
>> .gpio13 = GPIO_LEVEL_HIGH,
>> .gpio14 = GPIO_LEVEL_HIGH,
>> };
>>
>>
>> Yes, It is perfectley running.
>>
>> The 12, 13, 14 PIN is goto active-HIGH.(I was check this pin use by
>> oscilloscope.)
>>
>>
>> And I'm try to read the SC_GP_LVL register for check current
>> status/config of gpio pins
>>
>> I was *respected* the read value is *0x7000*, because i was writed the
>> *0x7000* to SC_GP_LVL.
>>
>>
>> But, every time readed the *0x00* from SC_GP_LVL register.
>>
>>
>> *When write 0x7000 write to SC_USE_SEL, Can read the 0x7000 from
>> SC_USE_SEL.*
>>
>> *When write 0x00 write to SC_IO_SEL, Can read the 0x00 from SC_IO_SEL.*
>>
>>
>> But,
>>
>>
>> *When write 0x7000 write to SC_GP_LVL, Can read the 0x00 from SC_GP_LVL.
>> everytime.*
>>
>>
>> I don't understand this sistuation.
>>
>>
>> Please advise to me.
>>
>>
>> Thank you.
>>
>>
>>
>>
>>
>>
>> --
>> coreboot mailing list: coreboot(a)coreboot.org
>> https://www.coreboot.org/mailman/listinfo/coreboot
>>
>
>
>
Hello 김유석,
I did not understand (very imporatnt question): why at all you do need SW
I2C (bit-banging I2C) in Coreboot romstage? Maybe you can move your I2C
operation later, in ramstage?!
Isn't romstage just to do very quick boot and pass the phase where MRC
(DDRs) should be initialized? And not sure if both L1 cashes are set as CAR
(L1 I-cache as well as L1 D-cache)? It seems to me that only L1 D-cache is
initialized as CAR, L1 I-cache remains to be true cache for flash code to
be executed fast.
I do know that romstage is compiled with the special ROMCC compiler, which
was adopted by Eric Biederman (2003-2006, ebiederman(a)lnxi.com):
https://github.com/wt/coreboot/blob/master/util/romcc/romcc.1
Maybe, this compiler allows you to store your outl() value into some 32-bit
reserved (for this purpose) common purpose register (instead of global
variable), but at this point in time, I need more time to investigate ROMCC.
Some other people very well might know answers about ROMCC on coreboot
mailing list. ;-)
Zoran
On Tue, Jul 19, 2016 at 8:40 AM, 김유석 <poplinux0(a)gmail.com> wrote:
> Sorry. i was have a miss-typing.
>
> I can read the some global variable. => X
> I can't read the some global variable. => O
>
>
>
> Thank you.
>
>
>
> 2016-07-19 오후 3:26에 김유석 이(가) 쓴 글:
>
> Dear Sir.
>
> Thank's your advise.
>
> I can read the some global variable.
> Because the outl() api is directly write value to register. Not global
> variable. I guess.
>
> Perhaps, your mean is a must use GLOBAL value for SC_GP_LVL?(do not try to
> read from SC_GP_LVL)
> I was try to use the GLOBAL value on coreboot. But occured the compile
> error.
>
> the global value "u32 val_sc_gp_lvl" is defined on
> "src/southbridge/intel/fsp_rangeley/gpio.c"
> and use this value is on
> "src/southbridge/intel/fsp_rangeley/gpio.c::setup_soc_gpios()"
>
> If i call setup_soc_gpios() is
> "src/mainboard/intel/mohonpeak/romstage.c::early_mainboard_romstage_entry()",
> occured build error. log is see below.
>
> OBJCOPY cbfs/fallback/bootblock.elf
> LINK cbfs/fallback/romstage.debug
> OBJCOPY bootblock.raw.bin
> Forbidden global variables in romstage:
> ffffff00 B val_sc_gp_lvl
>
> If i do not call setup_soc_gpios(), not occured the build error.
>
>
> Current status
> * 1. setup input mode to the target pin*
> => can read the value from SC_GP_LVL register
> *2. setup output mode to the target pin*
> => When a write value to SC_GP_LVL register, successfully change the
> HIGH/LOW status of pin.
> => But when a read the value from SC_GP_LVL register, can't read the
> value.
>
>
> My Goal is a create SW I2C port on my rangeley platform.
> Almost works is done. But just one is fail.
>
> Please advise to me.
>
> Thank you.
>
>
>
> 2016-07-18 오후 3:52에 Zoran Stojsavljevic 이(가) 쓴 글:
>
> > But DS is said to me that SC_GP_LVL is WR register.
>
> So, as I assumed, SC_GP_LVL is WR ONLY register. If it always works and
> puts out values, and retains them (which is another of mine assumption),
> the solution to RD problem is simplistic.
>
> Immediately after the: outl(GPIO, gpiobase + GPIO_SC_GP_LVL);
>
> Please, always remember the I/O data value you outl() into some heap
> global variable (which will always retain the latest outl() data value). If
> you need it back, read this variable.
>
> Best Regards,
> Zoran
>
> On Mon, Jul 18, 2016 at 7:20 AM, 김유석 <poplinux0(a)gmail.com> wrote:
>
>> Dear Sir.
>>
>> I was test with by your advise. But SC_GP_LVL is always read 0x00
>>
>> source code & result is see below.
>>
>> u32 read_gpio_level(const struct soc_gpio_map *gpio)
>> {
>>
>> u16 gpiobase __attribute__((unused)) = pci_read_config16(SOC_LPC_DEV,
>> GBASE) & ~0xf;
>>
>> printk(BIOS_DEBUG, "%s() : Start\n", __FUNCTION__);
>> printk(BIOS_DEBUG, " GPIO_SC_USE_SEL : 0x%x\n", inl(gpiobase +
>> GPIO_SC_USE_SEL));
>> printk(BIOS_DEBUG, " GPIO_SC_IO_SEL : 0x%x\n", inl(gpiobase +
>> GPIO_SC_IO_SEL));
>> printk(BIOS_DEBUG, " GPIO_SC_GP_LVL : 0x%x\n", inl(gpiobase +
>> GPIO_SC_GP_LVL));
>> printk(BIOS_DEBUG, "%s() : End\n\n", __FUNCTION__);
>>
>> return 0;
>> }
>>
>> int set_gpio_level(const struct soc_gpio_map *gpio,
>> const int num,
>> const int lvl)
>> {
>> u16 gpiobase __attribute__((unused)) = pci_read_config16(SOC_LPC_DEV,
>> GBASE) & ~0xf;
>> u32 GPIO = 0;
>>
>> GPIO = setBit(GPIO, num);
>>
>> printk(BIOS_DEBUG, "%s() : GPIO set value 0x%x\n", __FUNCTION__,
>> GPIO);
>> outl(GPIO, gpiobase + GPIO_SC_GP_LVL);
>>
>> return 0;
>> }
>>
>>
>> void early_mainboard_romstage_entry(void)
>> {
>> setup_soc_gpios(&gpio_map);
>> set_gpio_level(&gpio_map, 12, 1);
>> mdelay(500);
>> read_gpio_level(&gpio_map);
>>
>> set_gpio_level(&gpio_map, 13, 1);
>> mdelay(500);
>> read_gpio_level(&gpio_map);
>>
>> set_gpio_level(&gpio_map, 14, 1);
>> mdelay(500);
>> read_gpio_level(&gpio_map);
>> };
>>
>>
>>
>> ==================================================================================
>> coreboot-NexG-59a9b0a6 Mon Jul 18 05:09:30 UTC 2016 romstage starting...
>> set_gpio_level() : GPIO set value 0x1000
>> read_gpio_level() : Start
>> GPIO_SC_USE_SEL : 7000
>> GPIO_SC_IO_SEL : 0
>> GPIO_SC_GP_LVL : 0
>> read_gpio_level() : End
>>
>> set_gpio_level() : GPIO set value 0x2000
>> read_gpio_level() : Start
>> GPIO_SC_USE_SEL : 7000
>> GPIO_SC_IO_SEL : 0
>> GPIO_SC_GP_LVL : 0
>> read_gpio_level() : End
>>
>> set_gpio_level() : GPIO set value 0x4000
>> read_gpio_level() : Start
>> GPIO_SC_USE_SEL : 7000
>> GPIO_SC_IO_SEL : 0
>> GPIO_SC_GP_LVL : 0
>> read_gpio_level() : End
>>
>>
>>
>>
>>
>> And I was re-view the DS of C2000.
>>
>> But DS is said to me that SC_GP_LVL is WR register.
>>
>>
>>
>> Please help me.
>>
>> Thank you.
>>
>>
>>
>>
>> 2016-07-13 오후 4:40에 Zoran Stojsavljevic 이(가) 쓴 글:
>>
>> *> When write 0x7000 write to SC_GP_LVL, Can read the 0x00 from
>> SC_GP_LVL. everytime.*
>>
>> Please, try to do the following exercise:
>>
>> [1] WR 0x1000 to SC_GP_LVL, then RD the value out of it: what it is?
>> [2] WR 0x2000 to SC_GP_LVL, then RD the value out of it: what it is?
>> [3] WR 0x4000 to SC_GP_LVL, then RD the value out of it: what it is?
>>
>> If you have all 0x0, most likely it does mean that Rangeley's SC_GP_LVL
>> register isd WR ONLY (when you read it, all 0s).
>>
>> To verify this, you should fetch the following document:
>>
>> http://www.intel.com/content/www/us/en/processors/atom/atom-c2000-microserv…
>>
>> And read Chapter 25 - General Purpose I/O (GPIO).
>>
>> Best Regards,
>> Zoran
>>
>> On Wed, Jul 13, 2016 at 6:39 AM, 김유석 <poplinux0(a)gmail.com> wrote:
>>
>>> Dear Sir.
>>>
>>>
>>> I want to control the GPIO pin that pin number is 12, 13, 14
>>>
>>>
>>> DataSheet(P 1909) and coreboot source
>>> code(src/southbridge/intel/fsp_rangeley/gpio.c, gpio.h) is said to me that
>>> "It is very easy"
>>>
>>>
>>> If i want to set the HIGH to 12, 13, 14
>>>
>>> Just setup the some register, is see below.
>>>
>>> SC_USE_SEL = 0x7000(b0111 0000 0000 0000)
>>>
>>> Is mean, the 12, 13, 14 is config to GPIO mode.(enable GPIO)
>>>
>>> SC_IO_SEL = 0x00(b0000 0000 0000 0000)
>>>
>>> Is mean, the 12, 13, 14 is output mode
>>>
>>> SC_GP_LVL = 0x7000(b0111 0000 0000 0000)
>>>
>>> Is mean, the 12, 13, 14 is set to HIGH level(1)
>>>
>>>
>>> src/southbridge/intel/fsp_rangeley/gpio.h
>>>
>>> /* Core GPIO */
>>> const struct soc_gpio soc_gpio_mode = {
>>> .gpio12 = GPIO_MODE_GPIO, /* Board ID GPIO */
>>> .gpio13 = GPIO_MODE_GPIO, /* Board ID GPIO */
>>> .gpio14 = GPIO_MODE_GPIO, /* Board ID GPIO */
>>> };
>>>
>>> const struct soc_gpio soc_gpio_direction = {
>>> .gpio12 = GPIO_DIR_OUTPUT,
>>> .gpio13 = GPIO_DIR_OUTPUT,
>>> .gpio14 = GPIO_DIR_OUTPUT,
>>> };
>>>
>>> const struct soc_gpio soc_gpio_level = {
>>> .gpio12 = GPIO_LEVEL_HIGH,
>>> .gpio13 = GPIO_LEVEL_HIGH,
>>> .gpio14 = GPIO_LEVEL_HIGH,
>>> };
>>>
>>>
>>> Yes, It is perfectley running.
>>>
>>> The 12, 13, 14 PIN is goto active-HIGH.(I was check this pin use by
>>> oscilloscope.)
>>>
>>>
>>> And I'm try to read the SC_GP_LVL register for check current
>>> status/config of gpio pins
>>>
>>> I was *respected* the read value is *0x7000*, because i was writed the
>>> *0x7000* to SC_GP_LVL.
>>>
>>>
>>> But, every time readed the *0x00* from SC_GP_LVL register.
>>>
>>>
>>> *When write 0x7000 write to SC_USE_SEL, Can read the 0x7000 from
>>> SC_USE_SEL.*
>>>
>>> *When write 0x00 write to SC_IO_SEL, Can read the 0x00 from SC_IO_SEL.*
>>>
>>>
>>> But,
>>>
>>>
>>> *When write 0x7000 write to SC_GP_LVL, Can read the 0x00 from SC_GP_LVL.
>>> everytime.*
>>>
>>>
>>> I don't understand this sistuation.
>>>
>>>
>>> Please advise to me.
>>>
>>>
>>> Thank you.
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>> coreboot mailing list: coreboot(a)coreboot.org
>>> https://www.coreboot.org/mailman/listinfo/coreboot
>>>
>>
>>
>>
>
>
>
Dear Sir.
Thank's your advise.
I can read the some global variable.
Because the outl() api is directly write value to register. Not global
variable. I guess.
Perhaps, your mean is a must use GLOBAL value for SC_GP_LVL?(do not try
to read from SC_GP_LVL)
I was try to use the GLOBAL value on coreboot. But occured the compile
error.
the global value "u32 val_sc_gp_lvl" is defined on
"src/southbridge/intel/fsp_rangeley/gpio.c"
and use this value is on
"src/southbridge/intel/fsp_rangeley/gpio.c::setup_soc_gpios()"
If i call setup_soc_gpios() is
"src/mainboard/intel/mohonpeak/romstage.c::early_mainboard_romstage_entry()",
occured build error. log is see below.
OBJCOPY cbfs/fallback/bootblock.elf
LINK cbfs/fallback/romstage.debug
OBJCOPY bootblock.raw.bin
Forbidden global variables in romstage:
ffffff00 B val_sc_gp_lvl
If i do not call setup_soc_gpios(), not occured the build error.
Current status
* 1. setup input mode to the target pin*
=> can read the value from SC_GP_LVL register
*2. setup output mode to the target pin*
=> When a write value to SC_GP_LVL register, successfully change
the HIGH/LOW status of pin.
=> But when a read the value from SC_GP_LVL register, can't read
the value.
My Goal is a create SW I2C port on my rangeley platform.
Almost works is done. But just one is fail.
Please advise to me.
Thank you.
2016-07-18 오후 3:52에 Zoran Stojsavljevic 이(가) 쓴 글:
> > But DS is said to me that SC_GP_LVL is WR register.
>
> So, as I assumed, SC_GP_LVL is WR ONLY register. If it always works
> and puts out values, and retains them (which is another of mine
> assumption), the solution to RD problem is simplistic.
>
> Immediately after the:outl(GPIO, gpiobase + GPIO_SC_GP_LVL);
>
> Please, always remember the I/O data value you outl() into some heap
> global variable (which will always retain the latest outl() data
> value). If you need it back, read this variable.
>
> Best Regards,
> Zoran
>
> On Mon, Jul 18, 2016 at 7:20 AM, 김유석 <poplinux0(a)gmail.com
> <mailto:poplinux0@gmail.com>> wrote:
>
> Dear Sir.
>
> I was test with by your advise. But SC_GP_LVL is always read 0x00
>
> source code & result is see below.
>
> u32 read_gpio_level(const struct soc_gpio_map *gpio)
> {
>
> u16 gpiobase __attribute__((unused)) =
> pci_read_config16(SOC_LPC_DEV, GBASE) & ~0xf;
>
> printk(BIOS_DEBUG, "%s() : Start\n", __FUNCTION__);
> printk(BIOS_DEBUG, " GPIO_SC_USE_SEL : 0x%x\n", inl(gpiobase
> + GPIO_SC_USE_SEL));
> printk(BIOS_DEBUG, " GPIO_SC_IO_SEL : 0x%x\n", inl(gpiobase
> + GPIO_SC_IO_SEL));
> printk(BIOS_DEBUG, " GPIO_SC_GP_LVL : 0x%x\n", inl(gpiobase
> + GPIO_SC_GP_LVL));
> printk(BIOS_DEBUG, "%s() : End\n\n", __FUNCTION__);
>
> return 0;
> }
>
> int set_gpio_level(const struct soc_gpio_map *gpio,
> const int num,
> const int lvl)
> {
> u16 gpiobase __attribute__((unused)) =
> pci_read_config16(SOC_LPC_DEV, GBASE) & ~0xf;
> u32 GPIO = 0;
>
> GPIO = setBit(GPIO, num);
>
> printk(BIOS_DEBUG, "%s() : GPIO set value 0x%x\n",
> __FUNCTION__, GPIO);
> outl(GPIO, gpiobase + GPIO_SC_GP_LVL);
>
> return 0;
> }
>
>
> void early_mainboard_romstage_entry(void)
> {
> setup_soc_gpios(&gpio_map);
> set_gpio_level(&gpio_map, 12, 1);
> mdelay(500);
> read_gpio_level(&gpio_map);
>
> set_gpio_level(&gpio_map, 13, 1);
> mdelay(500);
> read_gpio_level(&gpio_map);
>
> set_gpio_level(&gpio_map, 14, 1);
> mdelay(500);
> read_gpio_level(&gpio_map);
> };
>
>
> ==================================================================================
> coreboot-NexG-59a9b0a6 Mon Jul 18 05:09:30 UTC 2016 romstage
> starting...
> set_gpio_level() : GPIO set value 0x1000
> read_gpio_level() : Start
> GPIO_SC_USE_SEL : 7000
> GPIO_SC_IO_SEL : 0
> GPIO_SC_GP_LVL : 0
> read_gpio_level() : End
>
> set_gpio_level() : GPIO set value 0x2000
> read_gpio_level() : Start
> GPIO_SC_USE_SEL : 7000
> GPIO_SC_IO_SEL : 0
> GPIO_SC_GP_LVL : 0
> read_gpio_level() : End
>
> set_gpio_level() : GPIO set value 0x4000
> read_gpio_level() : Start
> GPIO_SC_USE_SEL : 7000
> GPIO_SC_IO_SEL : 0
> GPIO_SC_GP_LVL : 0
> read_gpio_level() : End
>
>
>
>
>
> And I was re-view the DS of C2000.
>
> But DS is said to me that SC_GP_LVL is WR register.
>
>
>
> Please help me.
>
> Thank you.
>
>
>
>
> 2016-07-13 오후 4:40에 Zoran Stojsavljevic 이(가) 쓴 글:
>> *_> When write 0x7000 write to SC_GP_LVL, Can read the 0x00 from
>> SC_GP_LVL. everytime._*
>>
>> Please, try to do the following exercise:
>>
>> [1] WR 0x1000 to SC_GP_LVL, then RD the value out of it: what it is?
>> [2] WR 0x2000 to SC_GP_LVL, then RD the value out of it: what it is?
>> [3] WR 0x4000 to SC_GP_LVL, then RD the value out of it: what it is?
>>
>> If you have all 0x0, most likely it does mean that Rangeley's
>> SC_GP_LVL register isd WR ONLY (when you read it, all 0s).
>>
>> To verify this, you should fetch the following document:
>> http://www.intel.com/content/www/us/en/processors/atom/atom-c2000-microserv…
>>
>> And read Chapter 25 - General Purpose I/O (GPIO).
>>
>> Best Regards,
>> Zoran
>>
>> On Wed, Jul 13, 2016 at 6:39 AM, 김유석 <poplinux0(a)gmail.com
>> <mailto:poplinux0@gmail.com>> wrote:
>>
>> Dear Sir.
>>
>>
>> I want to control the GPIO pin that pin number is 12, 13, 14
>>
>>
>> DataSheet(P 1909) and coreboot source
>> code(src/southbridge/intel/fsp_rangeley/gpio.c, gpio.h) is
>> said to me that "It is very easy"
>>
>>
>> If i want to set the HIGH to 12, 13, 14
>>
>> Just setup the some register, is see below.
>>
>> SC_USE_SEL = 0x7000(b0111 0000 0000 0000)
>>
>> Is mean, the 12, 13, 14 is config to GPIO mode.(enable GPIO)
>>
>> SC_IO_SEL = 0x00(b0000 0000 0000 0000)
>>
>> Is mean, the 12, 13, 14 is output mode
>>
>> SC_GP_LVL = 0x7000(b0111 0000 0000 0000)
>>
>> Is mean, the 12, 13, 14 is set to HIGH level(1)
>>
>>
>> src/southbridge/intel/fsp_rangeley/gpio.h
>>
>> /* Core GPIO */
>> const struct soc_gpio soc_gpio_mode = {
>> .gpio12 = GPIO_MODE_GPIO, /* Board ID GPIO */
>> .gpio13 = GPIO_MODE_GPIO, /* Board ID GPIO */
>> .gpio14 = GPIO_MODE_GPIO, /* Board ID GPIO */
>> };
>>
>> const struct soc_gpio soc_gpio_direction = {
>> .gpio12 = GPIO_DIR_OUTPUT,
>> .gpio13 = GPIO_DIR_OUTPUT,
>> .gpio14 = GPIO_DIR_OUTPUT,
>> };
>>
>> const struct soc_gpio soc_gpio_level = {
>> .gpio12 = GPIO_LEVEL_HIGH,
>> .gpio13 = GPIO_LEVEL_HIGH,
>> .gpio14 = GPIO_LEVEL_HIGH,
>> };
>>
>>
>> Yes, It is perfectley running.
>>
>> The 12, 13, 14 PIN is goto active-HIGH.(I was check this pin
>> use by oscilloscope.)
>>
>>
>> And I'm try to read the SC_GP_LVL register for check current
>> status/config of gpio pins
>>
>> I was *respected* the read value is *0x7000*, because i was
>> writed the *0x7000* to SC_GP_LVL.
>>
>>
>> But, every time readed the *0x00* from SC_GP_LVL register.
>>
>>
>> _When write 0x7000 write to SC_USE_SEL, Can read the 0x7000
>> from SC_USE_SEL._
>>
>> _When write 0x00 write to SC_IO_SEL, Can read the 0x00 from
>> SC_IO_SEL._
>>
>>
>> But,
>>
>>
>> *_When write 0x7000 write to SC_GP_LVL, Can read the 0x00
>> from SC_GP_LVL. everytime._*
>>
>>
>> I don't understand this sistuation.
>>
>>
>> Please advise to me.
>>
>>
>> Thank you.
>>
>>
>>
>>
>>
>>
>> --
>> coreboot mailing list: coreboot(a)coreboot.org
>> <mailto:coreboot@coreboot.org>
>> https://www.coreboot.org/mailman/listinfo/coreboot
>>
>>
>
>