ਭਾਗ 3: ਲਗਭਗ ਲੋਡ ਹੋ ਰਿਹਾ ਹੈ Linux SD ਕਾਰਡ ਤੋਂ RocketChip ਤੱਕ

В ਪਿਛਲੇ ਭਾਗ был реализован более-менее работающий контроллер памяти, а точнее — обёртка над IP Core из Quartus, являющаяся переходником на TileLink. Сегодня же в рубрике «Портируем RocketChip на малоизвестную китайскую плату с Циклоном» вы увидите работающую консоль. Процесс несколько затянулся: я уже было думал, что сейчас по-быстрому запущу Linux, и пойдём дальше, но не тут то было. В этой части предлагаю посмотреть на процесс запуска U-Boot, BBL, и робкие попытки Linux kernel инициализироваться. Но консоль есть — U-Boot-овская, и довольно-таки продвинутая, имеющая многое из того, что вы ожидаете от полноценной консоли.

ਹਾਰਡਵੇਅਰ ਵਿੱਚ ਇੱਕ SD ਕਾਰਡ ਸ਼ਾਮਲ ਹੋਵੇਗਾ ਜੋ SPI ਇੰਟਰਫੇਸ ਦੁਆਰਾ ਜੁੜਿਆ ਹੋਇਆ ਹੈ, ਨਾਲ ਹੀ ਇੱਕ UART. ਸਾਫਟਵੇਅਰ ਹਿੱਸੇ ਵਿੱਚ, BootROM ਨਾਲ ਤਬਦੀਲ ਕੀਤਾ ਜਾਵੇਗਾ xip 'ਤੇ sdboot ਅਤੇ, ਅਸਲ ਵਿੱਚ, ਹੇਠਾਂ ਦਿੱਤੇ ਲੋਡਿੰਗ ਪੜਾਅ ਸ਼ਾਮਲ ਕੀਤੇ ਗਏ ਹਨ (SD ਕਾਰਡ 'ਤੇ)।

ਹਾਰਡਵੇਅਰ ਨੂੰ ਪੂਰਾ ਕਰਨਾ

ਇਸ ਲਈ, ਕੰਮ: ਤੁਹਾਨੂੰ ਇੱਕ "ਵੱਡੇ" ਕੋਰ 'ਤੇ ਜਾਣ ਦੀ ਲੋੜ ਹੈ ਅਤੇ ਇੱਕ UART (ਰਸਬੇਰੀ ਤੋਂ) ਅਤੇ ਇੱਕ SD ਅਡਾਪਟਰ (ਅਸੀਂ ਕੈਟੇਲੈਕਸ ਤੋਂ ਛੇ ਪਿੰਨਾਂ ਨਾਲ ਇੱਕ ਕਾਰਡ ਵਰਤਿਆ ਹੈ: GND, VCC, MISO, MOSI, SCK, CS) .

ਅਸੂਲ ਵਿੱਚ, ਸਭ ਕੁਝ ਕਾਫ਼ੀ ਸਧਾਰਨ ਸੀ. ਪਰ ਇਸ ਤੋਂ ਪਹਿਲਾਂ ਕਿ ਮੈਨੂੰ ਇਹ ਅਹਿਸਾਸ ਹੋ ਜਾਵੇ, ਮੈਨੂੰ ਇੱਕ ਪਾਸੇ ਤੋਂ ਦੂਜੇ ਪਾਸੇ ਸੁੱਟ ਦਿੱਤਾ ਗਿਆ ਸੀ: ਪਿਛਲੀ ਵਾਰ ਤੋਂ ਬਾਅਦ, ਮੈਂ ਫੈਸਲਾ ਕੀਤਾ ਕਿ ਦੁਬਾਰਾ ਮੈਨੂੰ ਇਸ ਵਿੱਚ ਮਿਲਾਉਣ ਦੀ ਲੋੜ ਹੈ. System ਕੁਝ ਅਜਿਹਾ HasPeripheryUART (ਅਤੇ ਉਸ ਅਨੁਸਾਰ ਲਾਗੂ ਕਰਨਾ), SD ਕਾਰਡ ਲਈ ਉਹੀ - ਅਤੇ ਸਭ ਕੁਝ ਤਿਆਰ ਹੋ ਜਾਵੇਗਾ। ਫਿਰ ਮੈਂ ਇਹ ਦੇਖਣ ਦਾ ਫੈਸਲਾ ਕੀਤਾ ਕਿ ਇਸਨੂੰ "ਗੰਭੀਰ" ਡਿਜ਼ਾਈਨ ਵਿੱਚ ਕਿਵੇਂ ਲਾਗੂ ਕੀਤਾ ਗਿਆ ਸੀ। ਇਸ ਲਈ, ਇਸ ਬਾਰੇ ਗੰਭੀਰ ਕੀ ਹੈ? ਆਰਟੀ, ਜ਼ਾਹਰ ਤੌਰ 'ਤੇ, ਫਿੱਟ ਨਹੀਂ ਬੈਠਦੀ - ਰਾਖਸ਼ ਰਹਿੰਦਾ ਹੈ unleahshed.DevKitConfigs. ਅਤੇ ਅਚਾਨਕ ਇਹ ਪਤਾ ਚਲਿਆ ਕਿ ਹਰ ਜਗ੍ਹਾ ਕੁਝ ਓਵਰਲੇਅ ਸਨ, ਜੋ ਕੁੰਜੀਆਂ ਦੁਆਰਾ ਪੈਰਾਮੀਟਰਾਂ ਦੁਆਰਾ ਜੋੜਿਆ ਗਿਆ ਸੀ. ਮੇਰਾ ਅਨੁਮਾਨ ਹੈ ਕਿ ਇਹ ਸ਼ਾਇਦ ਬਹੁਤ ਲਚਕਦਾਰ ਅਤੇ ਸੰਰਚਨਾਯੋਗ ਹੈ, ਪਰ ਮੈਂ ਘੱਟੋ ਘੱਟ ਪਹਿਲਾਂ ਕੁਝ ਚਲਾਉਣਾ ਚਾਹਾਂਗਾ ... ਕੀ ਤੁਹਾਡੇ ਕੋਲ ਉਹੀ ਚੀਜ਼ ਨਹੀਂ ਹੈ, ਸਿਰਫ ਸਰਲ ਅਤੇ ਵਧੇਰੇ ਤੰਗ ਕਰਨ ਵਾਲੀ? .. ਇਹ ਉਦੋਂ ਹੋਇਆ ਜਦੋਂ ਮੈਂ ਪਾਰ ਆਇਆ vera.iofpga.FPGAChip ਮਾਈਕ੍ਰੋਸੇਮੀ FPGAs ਲਈ ਅਤੇ ਤੁਰੰਤ ਇਸ ਨੂੰ ਹਵਾਲਿਆਂ ਲਈ ਵੱਖ ਕਰ ਲਿਆ ਅਤੇ ਸਮਾਨਤਾ ਦੁਆਰਾ ਮੇਰੇ ਖੁਦ ਦੇ ਲਾਗੂ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ, ਖੁਸ਼ਕਿਸਮਤੀ ਨਾਲ ਇੱਕ ਫਾਈਲ ਵਿੱਚ ਘੱਟ ਜਾਂ ਘੱਟ ਪੂਰਾ “ਮਦਰਬੋਰਡ ਲੇਆਉਟ” ਹੈ।

ਇਹ ਪਤਾ ਚਲਿਆ ਕਿ ਤੁਹਾਨੂੰ ਅਸਲ ਵਿੱਚ ਸ਼ਾਮਲ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਹੈ System.scala ਲਾਈਨਾਂ

class System(implicit p: Parameters) extends RocketSubsystem
...
  with HasPeripherySPI
  with HasPeripheryUART
...
{
  val tlclock = new FixedClockResource("tlclk", p(DevKitFPGAFrequencyKey))
  ...
}

class SystemModule[+L <: System](_outer: L)
  extends RocketSubsystemModuleImp(_outer)
...
    with HasPeripheryUARTModuleImp
    with HasPeripheryGPIOModuleImp
...

ਕਲਾਸ ਬਾਡੀ ਵਿੱਚ ਲਾਈਨ System ਉਸ ਬਾਰੰਬਾਰਤਾ ਬਾਰੇ ਜਾਣਕਾਰੀ ਜੋੜਦਾ ਹੈ ਜਿਸ 'ਤੇ ਸਾਡੇ SoC ਦਾ ਇਹ ਹਿੱਸਾ dts ਫਾਈਲ ਵਿੱਚ ਕੰਮ ਕਰਦਾ ਹੈ। ਜਿੱਥੋਂ ਤੱਕ ਮੈਂ ਸਮਝਦਾ ਹਾਂ, DTS/DTB ਏਮਬੈਡਡ ਡਿਵਾਈਸਾਂ ਲਈ ਪਲੱਗ-ਐਂਡ-ਪਲੇ ਤਕਨਾਲੋਜੀ ਦਾ ਇੱਕ ਸਥਿਰ ਐਨਾਲਾਗ ਹੈ: dts ਵਰਣਨ ਟ੍ਰੀ ਨੂੰ ਇੱਕ ਬਾਈਨਰੀ dtb ਫਾਈਲ ਵਿੱਚ ਕੰਪਾਇਲ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਅਤੇ ਬੂਟਲੋਡਰ ਦੁਆਰਾ ਕਰਨਲ ਵਿੱਚ ਟ੍ਰਾਂਸਫਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਤਾਂ ਜੋ ਇਹ ਸਹੀ ਢੰਗ ਨਾਲ ਸੰਰਚਿਤ ਕਰ ਸਕੇ। ਹਾਰਡਵੇਅਰ। ਦਿਲਚਸਪ ਗੱਲ ਇਹ ਹੈ ਕਿ, ਨਾਲ ਲਾਈਨ ਦੇ ਬਿਨਾਂ tlclock ਹਰ ਚੀਜ਼ ਪੂਰੀ ਤਰ੍ਹਾਂ ਸੰਸਲੇਸ਼ਣ ਕਰਦੀ ਹੈ, ਪਰ BootROM ਕੰਪਾਇਲ ਕਰਨਾ (ਮੈਨੂੰ ਤੁਹਾਨੂੰ ਯਾਦ ਦਿਵਾਉਣ ਦਿਓ, ਹੁਣ ਇਹ ਪਹਿਲਾਂ ਹੀ ਹੋਵੇਗਾ sdboot) ਕੰਮ ਨਹੀਂ ਕਰੇਗਾ - ਸੰਕਲਨ ਪ੍ਰਕਿਰਿਆ ਦੇ ਦੌਰਾਨ ਇਹ dts ਫਾਈਲ ਨੂੰ ਪਾਰਸ ਕਰਦਾ ਹੈ ਅਤੇ ਇੱਕ ਮੈਕਰੋ ਨਾਲ ਇੱਕ ਸਿਰਲੇਖ ਬਣਾਉਂਦਾ ਹੈ TL_CLK, ਜਿਸਦਾ ਧੰਨਵਾਦ ਉਹ ਬਾਹਰੀ ਇੰਟਰਫੇਸ ਲਈ ਬਾਰੰਬਾਰਤਾ ਵਿਭਾਜਕਾਂ ਨੂੰ ਸਹੀ ਢੰਗ ਨਾਲ ਕੌਂਫਿਗਰ ਕਰਨ ਦੇ ਯੋਗ ਹੋਵੇਗਾ।

ਤੁਹਾਨੂੰ "ਵਾਇਰਿੰਗ" ਨੂੰ ਥੋੜ੍ਹਾ ਠੀਕ ਕਰਨ ਦੀ ਵੀ ਲੋੜ ਪਵੇਗੀ:

Platform.scala:

class PlatformIO(implicit val p: Parameters) extends Bundle {

...

  // UART
  io.uart_tx := sys.uart(0).txd
  sys.uart(0).rxd := RegNext(RegNext(io.uart_rx))

  // SD card
  io.sd_cs := sys.spi(0).cs(0)
  io.sd_sck := sys.spi(0).sck
  io.sd_mosi := sys.spi(0).dq(0).o
  sys.spi(0).dq(0).i := false.B
  sys.spi(0).dq(1).i := RegNext(RegNext(io.sd_miso))
  sys.spi(0).dq(2).i := false.B
  sys.spi(0).dq(3).i := false.B
}

ਰਜਿਸਟਰ ਚੇਨ, ਇਮਾਨਦਾਰ ਹੋਣ ਲਈ, ਅਸਲ ਕੋਡ ਵਿੱਚ ਕੁਝ ਹੋਰ ਸਥਾਨਾਂ ਨਾਲ ਸਮਾਨਤਾ ਦੁਆਰਾ ਜੋੜਿਆ ਗਿਆ ਸੀ। ਜ਼ਿਆਦਾਤਰ ਸੰਭਾਵਨਾ ਹੈ, ਉਹਨਾਂ ਨੂੰ ਇਸ ਤੋਂ ਬਚਾਉਣਾ ਚਾਹੀਦਾ ਹੈ ਮੈਟਾਸਟੇਬਿਲਟੀ. ਸ਼ਾਇਦ ਵਿੱਚ ਕੁੱਝ ਬਲਾਕਾਂ ਦੀ ਪਹਿਲਾਂ ਹੀ ਆਪਣੀ ਸੁਰੱਖਿਆ ਹੈ, ਪਰ ਪਹਿਲਾਂ ਮੈਂ ਇਸਨੂੰ ਘੱਟੋ-ਘੱਟ "ਉੱਚ-ਗੁਣਵੱਤਾ ਦੇ ਪੱਧਰ 'ਤੇ ਲਾਂਚ ਕਰਨਾ ਚਾਹੁੰਦਾ ਹਾਂ।" ਮੇਰੇ ਲਈ ਇੱਕ ਹੋਰ ਦਿਲਚਸਪ ਸਵਾਲ ਇਹ ਹੈ ਕਿ MISO ਅਤੇ MOSI ਵੱਖ-ਵੱਖ ਕਿਉਂ ਹਨ dq? ਮੈਨੂੰ ਅਜੇ ਤੱਕ ਜਵਾਬ ਨਹੀਂ ਮਿਲਿਆ ਹੈ, ਪਰ ਅਜਿਹਾ ਲਗਦਾ ਹੈ ਕਿ ਬਾਕੀ ਕੋਡ ਸਿਰਫ ਅਜਿਹੇ ਕੁਨੈਕਸ਼ਨ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ.

ਭੌਤਿਕ ਤੌਰ 'ਤੇ, ਮੈਂ ਬਲਾਕ 'ਤੇ ਮੁਫਤ ਸੰਪਰਕਾਂ ਲਈ ਡਿਜ਼ਾਈਨ ਪਿੰਨ ਨਿਰਧਾਰਤ ਕੀਤੇ ਅਤੇ ਵੋਲਟੇਜ ਚੋਣ ਜੰਪਰ ਨੂੰ 3.3V 'ਤੇ ਭੇਜ ਦਿੱਤਾ।

SD ਅਡਾਪਟਰ

ਉੱਪਰੋਂ ਵੇਖੋ:

ਹੇਠਲਾ ਦ੍ਰਿਸ਼:

ਸੌਫਟਵੇਅਰ ਡੀਬੱਗਿੰਗ: ਟੂਲ

ਪਹਿਲਾਂ, ਆਓ ਉਪਲਬਧ ਡੀਬਗਿੰਗ ਟੂਲਸ ਅਤੇ ਉਹਨਾਂ ਦੀਆਂ ਸੀਮਾਵਾਂ ਬਾਰੇ ਗੱਲ ਕਰੀਏ।

ਮਿਨੀਕਾਮ

Во-первых, нам будет нужно как-то читать то, что выводит загрузчик и ядро. Для этого на Linux (в данном случае — на том, что на RaspberryPi) нам потребуется программа Minicom. Вообще говоря, подойдёт любая программа для работы с последовательны портом.

ਕਿਰਪਾ ਕਰਕੇ ਧਿਆਨ ਦਿਓ ਕਿ ਜਦੋਂ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਪੋਰਟ ਡਿਵਾਈਸ ਦਾ ਨਾਮ ਇਸ ਤਰ੍ਹਾਂ ਦਿੱਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ -D /dev/ttyS0 - ਵਿਕਲਪ ਦੇ ਬਾਅਦ -D. ਖੈਰ, ਮੁੱਖ ਜਾਣਕਾਰੀ: ਬਾਹਰ ਨਿਕਲਣ ਲਈ, ਵਰਤੋਂ Ctrl-A, X. ਮੇਰੇ ਕੋਲ ਅਸਲ ਵਿੱਚ ਇੱਕ ਕੇਸ ਸੀ ਜਦੋਂ ਇਹ ਸੁਮੇਲ ਕੰਮ ਨਹੀਂ ਕਰਦਾ ਸੀ - ਤਾਂ ਤੁਸੀਂ ਬਸ ਇੱਕ ਗੁਆਂਢੀ SSH ਸੈਸ਼ਨ ਤੋਂ ਕਹਿ ਸਕਦੇ ਹੋ killall -KILL minicom.

ਇੱਕ ਹੋਰ ਵਿਸ਼ੇਸ਼ਤਾ ਹੈ. ਖਾਸ ਤੌਰ 'ਤੇ, RaspberryPi ਦੇ ਦੋ UARTs ਹਨ, ਅਤੇ ਦੋਵੇਂ ਪੋਰਟਾਂ ਨੂੰ ਪਹਿਲਾਂ ਹੀ ਕਿਸੇ ਚੀਜ਼ ਲਈ ਅਨੁਕੂਲਿਤ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ: ਇੱਕ ਬਲੂਟੁੱਥ ਲਈ, ਦੂਜਾ ਮੂਲ ਰੂਪ ਵਿੱਚ ਕਰਨਲ ਕੰਸੋਲ ਨੂੰ ਆਉਟਪੁੱਟ ਕਰਦਾ ਹੈ। ਖੁਸ਼ਕਿਸਮਤੀ ਨਾਲ, ਇਸ ਵਿਵਹਾਰ ਨੂੰ ਓਵਰਰਾਈਡ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ ਇਸ ਮੈਨੂਅਲ ਦੇ ਅਨੁਸਾਰ.

ਮੈਮੋਰੀ ਮੁੜ ਲਿਖਣਾ

ਡੀਬੱਗਿੰਗ ਕਰਦੇ ਸਮੇਂ, ਇੱਕ ਅਨੁਮਾਨ ਦੀ ਜਾਂਚ ਕਰਨ ਲਈ, ਮੈਨੂੰ ਕਈ ਵਾਰ ਕਰਨਾ ਪੈਂਦਾ ਸੀ ਬੂਟਲੋਡਰ ਲੋਡ ਕਰੋ (ਅਫਸੋਸ) ਹੋਸਟ ਤੋਂ ਸਿੱਧਾ RAM ਵਿੱਚ. ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਇਹ ਸਿੱਧੇ GDB ਤੋਂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਪਰ ਅੰਤ ਵਿੱਚ ਮੈਂ ਇੱਕ ਸਧਾਰਨ ਮਾਰਗ ਦੀ ਪਾਲਣਾ ਕੀਤੀ: ਮੈਂ ਰਾਸਬੇਰੀ ਵਿੱਚ ਲੋੜੀਂਦੀ ਫਾਈਲ ਦੀ ਨਕਲ ਕੀਤੀ, SSH (ਓਪਨਓਸੀਡੀ ਤੋਂ ਟੇਲਨੈੱਟ) ਦੁਆਰਾ ਪੋਰਟ 4444 ਨੂੰ ਵੀ ਅੱਗੇ ਭੇਜਿਆ ਅਤੇ ਕਮਾਂਡ ਦੀ ਵਰਤੋਂ ਕੀਤੀ। load_image. ਜਦੋਂ ਤੁਸੀਂ ਇਹ ਕਰਦੇ ਹੋ, ਅਜਿਹਾ ਲਗਦਾ ਹੈ ਕਿ ਸਭ ਕੁਝ ਜੰਮ ਗਿਆ ਹੈ, ਪਰ ਅਸਲ ਵਿੱਚ "ਇਹ ਨੀਂਦ ਨਹੀਂ ਆਉਂਦੀ, ਇਹ ਹੌਲੀ ਹੌਲੀ ਝਪਕਦੀ ਹੈ": ਇਹ ਫਾਈਲ ਨੂੰ ਡਾਊਨਲੋਡ ਕਰਦਾ ਹੈ, ਇਹ ਸਿਰਫ ਕੁਝ ਕਿਲੋਬਾਈਟ ਪ੍ਰਤੀ ਸਕਿੰਟ ਦੀ ਗਤੀ ਨਾਲ ਕਰਦਾ ਹੈ।

ਬਰੇਕਪੁਆਇੰਟ ਸਥਾਪਤ ਕਰਨ ਦੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ

ਨਿਯਮਤ ਪ੍ਰੋਗਰਾਮਾਂ ਨੂੰ ਡੀਬੱਗ ਕਰਨ ਵੇਲੇ ਬਹੁਤ ਸਾਰੇ ਲੋਕਾਂ ਨੂੰ ਸ਼ਾਇਦ ਇਸ ਬਾਰੇ ਸੋਚਣ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ, ਪਰ ਬਰੇਕਪੁਆਇੰਟ ਹਮੇਸ਼ਾ ਹਾਰਡਵੇਅਰ ਵਿੱਚ ਸੈੱਟ ਨਹੀਂ ਕੀਤੇ ਜਾਂਦੇ ਹਨ। ਕਈ ਵਾਰ ਬ੍ਰੇਕਪੁਆਇੰਟ ਸੈਟ ਕਰਨ ਵਿੱਚ ਅਸਥਾਈ ਤੌਰ 'ਤੇ ਸਹੀ ਜਗ੍ਹਾ 'ਤੇ ਵਿਸ਼ੇਸ਼ ਹਦਾਇਤਾਂ ਨੂੰ ਲਿਖਣਾ ਸ਼ਾਮਲ ਹੁੰਦਾ ਹੈ ਸਿੱਧੇ ਮਸ਼ੀਨ ਕੋਡ ਵਿੱਚ. ਉਦਾਹਰਨ ਲਈ, ਮੇਰੀ ਸਟੈਂਡਰਡ ਕਮਾਂਡ ਇਸ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰਦੀ ਹੈ b GDB ਵਿੱਚ। ਇੱਥੇ ਕੀ ਹੈ:

• ਤੁਸੀਂ BootROM ਦੇ ਅੰਦਰ ਇੱਕ ਬਿੰਦੀ ਨਹੀਂ ਲਗਾ ਸਕਦੇ ਕਿਉਂਕਿ ROM
• ਤੁਸੀਂ SD ਕਾਰਡ ਤੋਂ RAM ਵਿੱਚ ਲੋਡ ਕੀਤੇ ਕੋਡ 'ਤੇ ਇੱਕ ਬ੍ਰੇਕਪੁਆਇੰਟ ਸੈਟ ਕਰ ਸਕਦੇ ਹੋ, ਪਰ ਤੁਹਾਨੂੰ ਇਸ ਦੇ ਲੋਡ ਹੋਣ ਤੱਕ ਉਡੀਕ ਕਰਨੀ ਪਵੇਗੀ। ਨਹੀਂ ਤਾਂ, ਅਸੀਂ ਕੋਡ ਦੇ ਟੁਕੜੇ ਨੂੰ ਦੁਬਾਰਾ ਨਹੀਂ ਲਿਖਾਂਗੇ, ਪਰ ਲੋਡਰ ਸਾਡੇ ਬ੍ਰੇਕਪੁਆਇੰਟ ਨੂੰ ਦੁਬਾਰਾ ਲਿਖ ਦੇਵੇਗਾ

ਮੈਨੂੰ ਯਕੀਨ ਹੈ ਕਿ ਤੁਸੀਂ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਹਾਰਡਵੇਅਰ ਬ੍ਰੇਕਪੁਆਇੰਟਸ ਦੀ ਵਰਤੋਂ ਕਰਨ ਲਈ ਕਹਿ ਸਕਦੇ ਹੋ, ਪਰ ਫਿਰ ਵੀ ਉਹਨਾਂ ਦੀ ਗਿਣਤੀ ਸੀਮਤ ਹੈ।

ਤੇਜ਼ BootROM ਤਬਦੀਲੀ

ਡੀਬੱਗਿੰਗ ਦੇ ਸ਼ੁਰੂਆਤੀ ਪੜਾਅ 'ਤੇ, ਅਕਸਰ ਬੂਟਰੋਮ ਨੂੰ ਠੀਕ ਕਰਨ ਅਤੇ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਦੀ ਇੱਛਾ ਹੁੰਦੀ ਹੈ। ਪਰ ਇੱਕ ਸਮੱਸਿਆ ਹੈ: BootROM FPGA ਵਿੱਚ ਲੋਡ ਕੀਤੇ ਗਏ ਡਿਜ਼ਾਈਨ ਦਾ ਹਿੱਸਾ ਹੈ, ਅਤੇ ਇਸਦਾ ਸੰਸਲੇਸ਼ਣ ਕੁਝ ਮਿੰਟਾਂ ਦਾ ਮਾਮਲਾ ਹੈ (ਅਤੇ ਇਹ C ਅਤੇ ਅਸੈਂਬਲਰ ਤੋਂ BootROM ਚਿੱਤਰ ਦੇ ਲਗਭਗ ਤੁਰੰਤ ਸੰਕਲਨ ਤੋਂ ਬਾਅਦ ਹੈ...)। ਖੁਸ਼ਕਿਸਮਤੀ ਨਾਲ, ਅਸਲ ਵਿੱਚ ਸਭ ਕੁਝ ਬਹੁਤ ਤੇਜ਼: ਕਾਰਵਾਈਆਂ ਦਾ ਕ੍ਰਮ ਇਸ ਪ੍ਰਕਾਰ ਹੈ:

• regenerate bootrom.mif (ਮੈਂ HEX ਦੀ ਬਜਾਏ MIF 'ਤੇ ਸਵਿਚ ਕੀਤਾ, ਕਿਉਂਕਿ ਮੈਨੂੰ ਹਮੇਸ਼ਾ HEX ਨਾਲ ਕੁਝ ਸਮੱਸਿਆਵਾਂ ਸਨ, ਅਤੇ MIF Alter ਦਾ ਮੂਲ ਫਾਰਮੈਟ ਹੈ)
• Quartus ਵਿੱਚ ਕਹਿੰਦੇ ਹਨ Processing -> Update Memory Initialization File
• ਅਸੈਂਬਲਰ ਆਈਟਮ 'ਤੇ (ਟਾਸਕ ਦੇ ਖੱਬੇ ਕਾਲਮ ਵਿੱਚ) ਕਮਾਂਡ ਦੁਬਾਰਾ ਸ਼ੁਰੂ ਕਰੋ

ਹਰ ਚੀਜ਼ ਬਾਰੇ ਸਭ ਕੁਝ - ਸਕਿੰਟ ਦੇ ਇੱਕ ਜੋੜੇ ਨੂੰ.

SD ਕਾਰਡ ਤਿਆਰ ਕੀਤਾ ਜਾ ਰਿਹਾ ਹੈ

ਇੱਥੇ ਹਰ ਚੀਜ਼ ਮੁਕਾਬਲਤਨ ਸਧਾਰਨ ਹੈ, ਪਰ ਤੁਹਾਨੂੰ ਧੀਰਜ ਰੱਖਣ ਦੀ ਲੋੜ ਹੈ ਅਤੇ ਲਗਭਗ 14Gb ਡਿਸਕ ਸਪੇਸ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ:

git clone https://github.com/sifive/freedom-u-sdk
git submodule update --recursive --init
make

ਜਿਸ ਤੋਂ ਬਾਅਦ ਤੁਹਾਨੂੰ ਇੱਕ ਸਾਫ਼, ਜਾਂ ਇਸ ਦੀ ਬਜਾਏ, ਇੱਕ ਅਜਿਹਾ ਪਾਉਣ ਦੀ ਜ਼ਰੂਰਤ ਹੈ ਜਿਸ ਵਿੱਚ ਕੁਝ ਵੀ ਜ਼ਰੂਰੀ ਨਹੀਂ ਹੈ, SD ਕਾਰਡ, ਅਤੇ ਚਲਾਉਣਾ

sudo make DISK=/dev/sdX format-boot-loader

… ਕਿੱਥੇ sdX — ਕਾਰਡ ਨੂੰ ਦਿੱਤਾ ਗਿਆ ਡਿਵਾਈਸ। ਧਿਆਨ ਦਿਓ: ਕਾਰਡ ਦਾ ਡੇਟਾ ਮਿਟਾ ਦਿੱਤਾ ਜਾਵੇਗਾ, ਓਵਰਰਾਈਟ ਕੀਤਾ ਜਾਵੇਗਾ ਅਤੇ ਆਮ ਤੌਰ 'ਤੇ! ਪੂਰੀ ਅਸੈਂਬਲੀ ਨੂੰ ਹੇਠਾਂ ਤੋਂ ਕਰਨਾ ਮੁਸ਼ਕਿਲ ਹੈ sudoਕਿਉਂਕਿ ਤਦ ਸਾਰੀਆਂ ਬਿਲਡ ਕਲਾਕ੍ਰਿਤੀਆਂ ਨਾਲ ਸਬੰਧਤ ਹੋਣਗੀਆਂ root, ਅਤੇ ਅਸੈਂਬਲੀ ਨੂੰ ਹੇਠਾਂ ਤੋਂ ਕਰਨਾ ਹੋਵੇਗਾ sudo ਲਗਾਤਾਰ.

ਨਤੀਜਾ GPT ਵਿੱਚ ਚਾਰ ਭਾਗਾਂ ਵਾਲਾ ਇੱਕ ਕਾਰਡ ਹੈ, ਜਿਸ ਵਿੱਚੋਂ ਇੱਕ ਵਿੱਚ FAT ਹੈ uEnv.txt ਅਤੇ FIT ਫਾਰਮੈਟ ਵਿੱਚ ਇੱਕ ਬੂਟ ਹੋਣ ਯੋਗ ਚਿੱਤਰ (ਇਸ ਵਿੱਚ ਕਈ ਉਪ-ਚਿੱਤਰਾਂ ਹਨ, ਹਰੇਕ ਵਿੱਚ ਇਸਦੇ ਆਪਣੇ ਡਾਊਨਲੋਡ ਪਤੇ ਦੇ ਨਾਲ), ਦੂਜਾ ਭਾਗ ਖਾਲੀ ਹੈ, ਇਸਨੂੰ ਲੀਨਕਸ ਲਈ Ext4 ਵਿੱਚ ਫਾਰਮੈਟ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਦੋ ਹੋਰ ਭਾਗ - ਰਹੱਸਮਈ: ਯੂ-ਬੂਟ ਇੱਕ 'ਤੇ ਰਹਿੰਦਾ ਹੈ (ਇਸਦਾ ਆਫਸੈੱਟ, ਜਿੱਥੋਂ ਤੱਕ ਮੈਂ ਸਮਝਦਾ ਹਾਂ, ਬੂਟਰੋਮ ਵਿੱਚ ਹਾਰਡਕੋਡ ਕੀਤਾ ਗਿਆ ਹੈ), ਦੂਜੇ ਪਾਸੇ, ਅਜਿਹਾ ਲਗਦਾ ਹੈ, ਇਸਦੇ ਵਾਤਾਵਰਣ ਵੇਰੀਏਬਲ ਰਹਿੰਦੇ ਹਨ, ਪਰ ਮੈਂ ਉਹਨਾਂ ਦੀ ਵਰਤੋਂ ਨਹੀਂ ਕਰਦਾ ਹਾਂ।

ਪਹਿਲਾ ਪੱਧਰ, BootROM

ਪ੍ਰਸਿੱਧ ਸਿਆਣਪ ਕਹਿੰਦੀ ਹੈ: "ਜੇ ਪ੍ਰੋਗਰਾਮਿੰਗ ਵਿੱਚ ਇੱਕ ਟੈਂਬੋਰੀਨ ਨਾਲ ਨੱਚਣਾ ਹੈ, ਤਾਂ ਇਲੈਕਟ੍ਰੋਨਿਕਸ ਵਿੱਚ ਅੱਗ ਬੁਝਾਉਣ ਵਾਲੇ ਨਾਲ ਨੱਚਣਾ ਵੀ ਹੈ." ਇਹ ਇਸ ਤੱਥ ਬਾਰੇ ਵੀ ਨਹੀਂ ਹੈ ਕਿ ਇੱਕ ਵਾਰ ਮੈਂ ਬੋਰਡ ਨੂੰ ਲਗਭਗ ਸਾੜ ਦਿੱਤਾ, ਇਹ ਫੈਸਲਾ ਕਰਦੇ ਹੋਏ ਕਿ "ਠੀਕ ਹੈ, GND ਉਹੀ ਨੀਵਾਂ ਪੱਧਰ ਹੈ।" (ਜ਼ਾਹਰ ਹੈ, ਇੱਕ ਰੋਧਕ ਸਭ ਤੋਂ ਬਾਅਦ ਦੁਖੀ ਨਹੀਂ ਹੋਵੇਗਾ ...) ਇਹ ਇਸ ਤੱਥ ਬਾਰੇ ਵਧੇਰੇ ਹੈ ਕਿ ਜੇਕਰ ਹੱਥ ਉੱਥੋਂ ਨਹੀਂ ਵਧਦੇ, ਤਾਂ ਇਲੈਕਟ੍ਰੋਨਿਕਸ ਕਦੇ ਵੀ ਹੈਰਾਨੀ ਲਿਆਉਣਾ ਬੰਦ ਨਹੀਂ ਕਰਦਾ: ਜਦੋਂ ਕਨੈਕਟਰ ਨੂੰ ਬੋਰਡ 'ਤੇ ਸੋਲਡਰ ਕਰਦੇ ਹੋਏ, ਮੈਂ ਅਜੇ ਵੀ ਸੰਪਰਕਾਂ ਨੂੰ ਸਹੀ ਤਰ੍ਹਾਂ ਸੋਲਡਰ ਨਹੀਂ ਕਰ ਸਕਿਆ - ਵੀਡੀਓ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਸੋਲਡਰ ਸਿੱਧੇ ਕਿਵੇਂ ਫੈਲਦਾ ਹੈ ਪੂਰੇ ਕੁਨੈਕਸ਼ਨ ਉੱਤੇ, ਬਸ ਇੱਕ ਸੋਲਡਰਿੰਗ ਆਇਰਨ ਲਗਾਓ, ਮੇਰੇ ਲਈ, ਉਸਨੇ ਬੇਤਰਤੀਬੇ "ਥੱਪੜ" ਮਾਰਿਆ। ਖੈਰ, ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਸੋਲਡਰ ਸੋਲਡਰਿੰਗ ਆਇਰਨ ਦੇ ਤਾਪਮਾਨ ਲਈ ਢੁਕਵਾਂ ਨਹੀਂ ਸੀ, ਸ਼ਾਇਦ ਕੁਝ ਹੋਰ... ਆਮ ਤੌਰ 'ਤੇ, ਜਦੋਂ ਮੈਂ ਦੇਖਿਆ ਕਿ ਮੇਰੇ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਇੱਕ ਦਰਜਨ ਸੰਪਰਕ ਹਨ, ਮੈਂ ਹਾਰ ਮੰਨ ਲਈ ਅਤੇ ਡੀਬੱਗ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰ ਦਿੱਤਾ। ਅਤੇ ਫਿਰ ਇਹ ਸ਼ੁਰੂ ਹੋਇਆ ਰਹੱਸਮਈ: ਮੈਂ UART ਤੋਂ RX/TX ਕਨੈਕਟ ਕੀਤਾ, ਮੈਂ ਫਰਮਵੇਅਰ ਲੋਡ ਕਰਦਾ ਹਾਂ - ਇਹ ਕਹਿੰਦਾ ਹੈ

INIT
CMD0
ERROR

ਖੈਰ, ਸਭ ਕੁਝ ਤਰਕਪੂਰਨ ਹੈ - ਮੈਂ SD ਕਾਰਡ ਮੋਡੀਊਲ ਨੂੰ ਕਨੈਕਟ ਨਹੀਂ ਕੀਤਾ. ਅਸੀਂ ਸਥਿਤੀ ਨੂੰ ਠੀਕ ਕਰਦੇ ਹਾਂ, ਫਰਮਵੇਅਰ ਲੋਡ ਕਰਦੇ ਹਾਂ... ਅਤੇ ਚੁੱਪ... ਮੈਂ ਆਪਣਾ ਮਨ ਕਿਉਂ ਨਹੀਂ ਬਦਲਿਆ, ਪਰ ਬਾਕਸ ਹੁਣੇ ਖੁੱਲ੍ਹਿਆ ਹੈ: ਇੱਕ ਮੋਡੀਊਲ ਪਿੰਨ ਨੂੰ VCC ਨਾਲ ਕਨੈਕਟ ਕੀਤਾ ਜਾਣਾ ਸੀ। ਮੇਰੇ ਕੇਸ ਵਿੱਚ, ਮੋਡੀਊਲ ਨੇ ਪਾਵਰ ਸਪਲਾਈ ਲਈ 5V ਦਾ ਸਮਰਥਨ ਕੀਤਾ, ਇਸਲਈ ਬਿਨਾਂ ਦੋ ਵਾਰ ਸੋਚੇ, ਮੈਂ ਮੋਡੀਊਲ ਤੋਂ ਬੋਰਡ ਦੇ ਉਲਟ ਪਾਸੇ ਵੱਲ ਆਉਣ ਵਾਲੀ ਤਾਰ ਨੂੰ ਪਲੱਗ ਕੀਤਾ। ਨਤੀਜੇ ਵਜੋਂ, ਟੇਢੇ ਢੰਗ ਨਾਲ ਸੋਲਡ ਕੀਤਾ ਕੁਨੈਕਟਰ ਤਿੱਖਾ ਹੋ ਗਿਆ, ਅਤੇ UART ਸੰਪਰਕ ਬਸ ਗੁੰਮ ਹੋ ਗਿਆ ਸੀ। facepalm.jpg ਆਮ ਤੌਰ 'ਤੇ, "ਬੁਰਾ ਸਿਰ ਲੱਤਾਂ ਨੂੰ ਆਰਾਮ ਨਹੀਂ ਦਿੰਦਾ," ਅਤੇ ਟੇਢੇ ਹੱਥ ਸਿਰ ਨੂੰ ਆਰਾਮ ਨਹੀਂ ਦਿੰਦੇ ...

ਨਤੀਜੇ ਵਜੋਂ, ਮੈਂ ਲੰਬੇ ਸਮੇਂ ਤੋਂ ਉਡੀਕਿਆ ਦੇਖਿਆ

INIT
CMD0
CMD8
ACMD41
CMD58
CMD16
CMD18
LOADING /

ਇਸ ਤੋਂ ਇਲਾਵਾ, ਇਹ ਹਿਲਦਾ ਹੈ ਅਤੇ ਲੋਡਿੰਗ ਇੰਡੀਕੇਟਰ ਸਪਿਨ ਹੁੰਦਾ ਹੈ। ਮੈਨੂੰ ਤੁਰੰਤ ਮੇਰੇ ਸਕੂਲ ਦੇ ਦਿਨ ਅਤੇ ਇੱਕ ਫਲਾਪੀ ਡਿਸਕ ਤੋਂ MinuetOS ਦੀ ਆਰਾਮ ਨਾਲ ਲੋਡਿੰਗ ਯਾਦ ਹੈ। ਜਦੋਂ ਤੱਕ ਡਰਾਈਵ ਪੀਸ ਨਹੀਂ ਜਾਂਦੀ।

ਸਮੱਸਿਆ ਇਹ ਹੈ ਕਿ BOOT ਸੰਦੇਸ਼ ਤੋਂ ਬਾਅਦ ਕੁਝ ਨਹੀਂ ਹੁੰਦਾ। ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਇਹ ਓਪਨਓਸੀਡੀ ਦੁਆਰਾ ਰਾਸਬੇਰੀ ਤੋਂ, ਹੋਸਟ 'ਤੇ GDB ਨਾਲ ਜੁੜਨ ਦਾ ਸਮਾਂ ਹੈ, ਅਤੇ ਦੇਖੋ ਕਿ ਇਹ ਕੀ ਹੈ।

ਸਭ ਤੋਂ ਪਹਿਲਾਂ, GDB ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਕਨੈਕਟ ਕਰਨਾ ਤੁਰੰਤ ਦਿਖਾਇਆ ਗਿਆ ਹੈ $pc (ਪ੍ਰੋਗਰਾਮ ਕਾਊਂਟਰ, ਮੌਜੂਦਾ ਹਦਾਇਤ ਦਾ ਪਤਾ) ਲਈ ਉੱਡਦਾ ਹੈ 0x0 - ਇਹ ਸ਼ਾਇਦ ਕਈ ਤਰੁੱਟੀਆਂ ਤੋਂ ਬਾਅਦ ਵਾਪਰਦਾ ਹੈ। ਇਸ ਲਈ, ਸੰਦੇਸ਼ ਜਾਰੀ ਹੋਣ ਤੋਂ ਤੁਰੰਤ ਬਾਅਦ BOOT ਚਲੋ ਇੱਕ ਅਨੰਤ ਲੂਪ ਜੋੜੀਏ। ਇਹ ਉਸਨੂੰ ਕੁਝ ਸਮੇਂ ਲਈ ਦੇਰੀ ਕਰੇਗਾ ...

diff --git a/bootrom/sdboot/sd.c b/bootrom/sdboot/sd.c
index c6b5ede..bca1b7f 100644
--- a/bootrom/sdboot/sd.c
+++ b/bootrom/sdboot/sd.c
@@ -224,6 +224,8 @@ int main(void)

        kputs("BOOT");

+    while(*(volatile char *)0x10000){}
+
        __asm__ __volatile__ ("fence.i" : : : "memory");
        return 0;
 }

ਅਜਿਹੇ ਗੁੰਝਲਦਾਰ ਕੋਡ ਦੀ ਵਰਤੋਂ "ਭਰੋਸੇਯੋਗਤਾ ਲਈ" ਕੀਤੀ ਜਾਂਦੀ ਹੈ: ਮੈਂ ਕਿਤੇ ਸੁਣਿਆ ਹੈ ਕਿ ਇੱਕ ਬੇਅੰਤ ਲੂਪ ਇੱਕ ਪਰਿਭਾਸ਼ਿਤ ਵਿਵਹਾਰ ਹੈ, ਪਰ ਕੰਪਾਈਲਰ ਦਾ ਅਨੁਮਾਨ ਲਗਾਉਣ ਦੀ ਸੰਭਾਵਨਾ ਨਹੀਂ ਹੈ (ਮੈਂ ਤੁਹਾਨੂੰ ਯਾਦ ਦਿਵਾਉਂਦਾ ਹਾਂ ਕਿ 0x10000 ਸਥਿਤ BootROM).

ਇਹ ਜਾਪਦਾ ਹੈ, ਹੋਰ ਕੀ ਉਮੀਦ ਕਰਨੀ ਹੈ - ਕਠੋਰ ਏਮਬੇਡ, ਕਿਸ ਕਿਸਮ ਦੇ ਸਰੋਤ ਕੋਡ ਹਨ? ਪਰ ਵਿੱਚ ਉਹ ਲੇਖ ਲੇਖਕ ਸੀ ਕੋਡ ਨੂੰ ਡੀਬੱਗ ਕਰ ਰਿਹਾ ਸੀ... Kreks-fex-pex:

(gdb) file builds/zeowaa-e115/sdboot.elf
A program is being debugged already.
Are you sure you want to change the file? (y or n) y
Reading symbols from builds/zeowaa-e115/sdboot.elf...done.

ਤੁਹਾਨੂੰ ਸਿਰਫ਼ MIF ਫ਼ਾਈਲ ਜਾਂ ਬਿਨ ਨੂੰ ਨਹੀਂ, ਸਗੋਂ ELF ਫਾਰਮੈਟ ਵਿੱਚ ਅਸਲ ਸੰਸਕਰਣ ਨੂੰ ਡਾਊਨਲੋਡ ਕਰਨ ਦੀ ਲੋੜ ਹੈ।

ਹੁਣ ਤੁਸੀਂ nਵੀਂ ਕੋਸ਼ਿਸ਼ ਨਾਲ ਪਤਾ ਲਗਾ ਸਕਦੇ ਹੋ ਜਿੱਥੇ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਜਾਰੀ ਰਹੇਗਾ (ਇਹ ਇਕ ਹੋਰ ਕਾਰਨ ਹੈ ਕਿ ਕੰਪਾਈਲਰ ਨੂੰ ਇਹ ਅਨੁਮਾਨ ਨਹੀਂ ਲਗਾਉਣਾ ਚਾਹੀਦਾ ਸੀ ਕਿ ਲੂਪ ਅਨੰਤ ਹੈ)। ਟੀਮ

set variable $pc=0xADDR

ਤੁਹਾਨੂੰ ਫਲਾਈ 'ਤੇ ਰਜਿਸਟਰ ਮੁੱਲ ਨੂੰ ਬਦਲਣ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ (ਇਸ ਕੇਸ ਵਿੱਚ, ਮੌਜੂਦਾ ਹਦਾਇਤ ਦਾ ਪਤਾ)। ਇਸਦੀ ਮਦਦ ਨਾਲ, ਤੁਸੀਂ ਮੈਮੋਰੀ (ਅਤੇ ਮੈਮੋਰੀ-ਮੈਪਡ ਰਜਿਸਟਰਾਂ) ਵਿੱਚ ਲਿਖੇ ਮੁੱਲਾਂ ਨੂੰ ਬਦਲ ਸਕਦੇ ਹੋ।

ਆਖਰਕਾਰ, ਮੈਂ ਇਸ ਸਿੱਟੇ 'ਤੇ ਪਹੁੰਚਿਆ (ਪੱਕਾ ਨਹੀਂ ਕਿ ਕਿਹੜਾ ਸਹੀ ਹੈ) ਕਿ ਸਾਡੇ ਕੋਲ "ਗਲਤ ਸਿਸਟਮ ਦਾ ਇੱਕ SD ਕਾਰਡ ਚਿੱਤਰ" ਹੈ, ਅਤੇ ਸਾਨੂੰ ਡਾਉਨਲੋਡ ਕੀਤੇ ਡੇਟਾ ਦੀ ਸ਼ੁਰੂਆਤ ਵਿੱਚ ਨਹੀਂ ਜਾਣ ਦੀ ਜ਼ਰੂਰਤ ਹੈ, ਪਰ 0x89800 ਬਾਈਟ ਹੋਰ:

diff --git a/bootrom/sdboot/head.S b/bootrom/sdboot/head.S
index 14fa740..2a6c944 100644
--- a/bootrom/sdboot/head.S
+++ b/bootrom/sdboot/head.S
@@ -13,7 +13,7 @@ _prog_start:
   smp_resume(s1, s2)
   csrr a0, mhartid
   la a1, dtb
-  li s1, PAYLOAD_DEST
+  li s1, (PAYLOAD_DEST + 0x89800)
   jr s1

   .section .rodata

ਸ਼ਾਇਦ ਇਹ ਇਸ ਤੱਥ ਤੋਂ ਵੀ ਪ੍ਰਭਾਵਿਤ ਹੋਇਆ ਸੀ ਕਿ ਹੱਥ ਵਿੱਚ ਇੱਕ ਬੇਲੋੜਾ 4Gb ਕਾਰਡ ਨਾ ਹੋਣ ਕਰਕੇ, ਮੈਂ ਇੱਕ 2Gb ਲਿਆ ਅਤੇ ਇਸਨੂੰ ਬੇਤਰਤੀਬੇ ਮੇਕਫਾਈਲ ਵਿੱਚ ਬਦਲ ਦਿੱਤਾ। DEMO_END=11718750 'ਤੇ DEMO_END=3078900 (ਕਿਸੇ ਖਾਸ ਅਰਥ ਵਿੱਚ ਅਰਥ ਨਾ ਲੱਭੋ - ਇੱਥੇ ਕੋਈ ਨਹੀਂ ਹੈ, ਬੱਸ ਇਹ ਹੈ ਕਿ ਹੁਣ ਚਿੱਤਰ ਕਾਰਡ 'ਤੇ ਰੱਖਿਆ ਗਿਆ ਹੈ)।

ਪੱਧਰ ਦੋ, ਯੂ-ਬੂਟ

ਹੁਣ ਅਸੀਂ ਅਜੇ ਵੀ "ਡਿੱਗ ਰਹੇ ਹਾਂ", ਪਰ ਅਸੀਂ ਪਹਿਲਾਂ ਹੀ ਸਹੀ ਜਗ੍ਹਾ 'ਤੇ ਹਾਂ 0x0000000080089a84. ਇੱਥੇ ਮੈਨੂੰ ਸਵੀਕਾਰ ਕਰਨਾ ਪਏਗਾ: ਅਸਲ ਵਿੱਚ, ਪੇਸ਼ਕਾਰੀ "ਸਾਰੇ ਸਟਾਪਾਂ ਦੇ ਨਾਲ" ਨਹੀਂ ਜਾਂਦੀ ਹੈ, ਪਰ ਅੰਸ਼ਕ ਤੌਰ 'ਤੇ "ਬਾਅਦ" ਲਿਖੀ ਜਾਂਦੀ ਹੈ, ਇਸ ਲਈ ਇੱਥੇ ਮੈਂ ਪਹਿਲਾਂ ਹੀ ਸਾਡੇ SoC ਤੋਂ ਸਹੀ dtb ਫਾਈਲ ਨੂੰ ਸੰਮਿਲਿਤ ਕਰਨ ਵਿੱਚ ਪ੍ਰਬੰਧਿਤ ਕੀਤਾ ਹੈ, ਇਸਨੂੰ ਸੈਟਿੰਗਾਂ ਵਿੱਚ ਠੀਕ ਕਰੋ HiFive_U-Boot ਵੇਰੀਏਬਲ CONFIG_SYS_TEXT_BASE=0x80089800 (ਦੀ ਬਜਾਏ 0x08000000) ਤਾਂ ਜੋ ਡਾਉਨਲੋਡ ਪਤਾ ਅਸਲ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੋਵੇ। ਹੁਣ ਅਸੀਂ ਅਗਲੇ ਪੱਧਰ ਦਾ ਨਕਸ਼ਾ ਲੋਡ ਕਰਦੇ ਹਾਂ, ਇੱਕ ਹੋਰ ਚਿੱਤਰ:

(gdb) file ../freedom-u-sdk/work/HiFive_U-Boot/u-boot
(gdb) tui en

ਅਤੇ ਅਸੀਂ ਦੇਖਦੇ ਹਾਂ:

   │304     /*                                               │
   │305      * trap entry                                    │
   │306      */                                              │
   │307     trap_entry:                                      │
   │308         addi sp, sp, -32*REGBYTES                    │
  >│309         SREG x1, 1*REGBYTES(sp)                      │
   │310         SREG x2, 2*REGBYTES(sp)                      │
   │311         SREG x3, 3*REGBYTES(sp)                      │

ਇਸ ਤੋਂ ਇਲਾਵਾ, ਅਸੀਂ ਲਾਈਨਾਂ 308 ਅਤੇ 309 ਦੇ ਵਿਚਕਾਰ ਛਾਲ ਮਾਰਦੇ ਹਾਂ। ਅਤੇ ਇਹ ਹੈਰਾਨੀ ਦੀ ਗੱਲ ਨਹੀਂ ਹੈ ਕਿ $sp ਦਾ ਮਤਲਬ ਹੈ 0xfffffffe31cdc0a0. ਹਾਏ, ਇਹ ਲਾਈਨ 307 ਦੇ ਕਾਰਨ ਲਗਾਤਾਰ "ਭੱਜਦਾ" ਵੀ ਹੈ। ਇਸ ਲਈ, ਆਓ ਇੱਥੇ ਇੱਕ ਬ੍ਰੇਕਪੁਆਇੰਟ ਸੈੱਟ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੀਏ। trap_entry, ਅਤੇ ਫਿਰ ਵਾਪਸ ਜਾਓ 0x80089800 (ਯੂ-ਬੂਟ ਦਾ ਐਂਟਰੀ ਪੁਆਇੰਟ), ਅਤੇ ਆਓ ਉਮੀਦ ਕਰੀਏ ਕਿ ਇਸ ਨੂੰ ਜੰਪ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਰਜਿਸਟਰਾਂ ਨੂੰ ਸਹੀ ਢੰਗ ਨਾਲ ਸੈੱਟ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ... ਲੱਗਦਾ ਹੈ ਕਿ ਇਹ ਕੰਮ ਕਰਦਾ ਹੈ:

(gdb) b trap_entry
Breakpoint 1 at 0x80089a80: file /hdd/trosinenko/fpga/freedom-u-sdk/HiFive_U-Boot/arch/riscv/cpu/HiFive/start.S, line 308.
(gdb) set variable $pc=0x80089800
(gdb) c
Continuing.

Breakpoint 1, trap_entry () at /hdd/trosinenko/fpga/freedom-u-sdk/HiFive_U-Boot/arch/riscv/cpu/HiFive/start.S:308
(gdb) p/x $sp
$4 = 0x81cf950

ਸਟੈਕ ਪੁਆਇੰਟਰ ਇੰਨਾ ਹੈ, ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ: ਇਹ RAM ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਬਾਈਪਾਸ ਕਰਨ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ (ਜਦੋਂ ਤੱਕ, ਬੇਸ਼ੱਕ, ਸਾਡੇ ਕੋਲ ਪਹਿਲਾਂ ਤੋਂ ਪਤਾ ਅਨੁਵਾਦ ਨਹੀਂ ਹੈ, ਪਰ ਆਓ ਇੱਕ ਸਧਾਰਨ ਵਿਕਲਪ ਦੀ ਉਮੀਦ ਕਰੀਏ)।

ਆਉ ਇਸ ਨਾਲ ਪੁਆਇੰਟਰ ਨੂੰ ਬਦਲਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੀਏ 0x881cf950. ਨਤੀਜੇ ਵਜੋਂ, ਅਸੀਂ ਇਸ ਸਿੱਟੇ 'ਤੇ ਪਹੁੰਚਦੇ ਹਾਂ ਕਿ handle_trap ਬੁਲਾਇਆ ਅਤੇ ਬੁਲਾਇਆ, ਅਤੇ ਉਸੇ ਸਮੇਂ ਅਸੀਂ ਅੰਦਰ ਜਾਂਦੇ ਹਾਂ _exit_trap ਇੱਕ ਦਲੀਲ ਨਾਲ epc=2148315240 (ਦਸ਼ਮਲਵ ਵਿੱਚ):

(gdb) x/10i 2148315240
   0x800cb068 <strnlen+12>:     lbu     a4,0(a5)
   0x800cb06c <strnlen+16>:     bnez    a4,0x800cb078 <strnlen+28>
   0x800cb070 <strnlen+20>:     sub     a0,a5,a0
   0x800cb074 <strnlen+24>:     ret
   0x800cb078 <strnlen+28>:     addi    a5,a5,1
   0x800cb07c <strnlen+32>:     j       0x800cb064 <strnlen+8>
   0x800cb080 <strdup>: addi    sp,sp,-32
   0x800cb084 <strdup+4>:       sd      s0,16(sp)
   0x800cb088 <strdup+8>:       sd      ra,24(sp)
   0x800cb08c <strdup+12>:      li      s0,0

'ਤੇ ਬਰੇਕਪੁਆਇੰਟ ਸੈੱਟ ਕਰੋ strnlen, ਅਸੀਂ ਜਾਰੀ ਰੱਖਦੇ ਹਾਂ ਅਤੇ ਦੇਖਦੇ ਹਾਂ:

(gdb) bt
#0  strnlen (s=s@entry=0x10060000 "", count=18446744073709551615) at lib/string.c:283
#1  0x00000000800cc14c in string (buf=buf@entry=0x881cbd4c "", end=end@entry=0x881cc15c "", s=0x10060000 "", field_width=<optimized out>, precision=<optimized out>, flags=<optimized out>) at lib/vsprintf.c:265
#2  0x00000000800cc63c in vsnprintf_internal (buf=buf@entry=0x881cbd38 "exception code: 5 , ", size=size@entry=1060, fmt=0x800d446e "s , epc %08x , ra %08lxn", fmt@entry=0x800d4458 "exception code: %d , %s , epc %08x , ra %08lxn", args=0x881cc1a0,
    args@entry=0x881cc188) at lib/vsprintf.c:619
#3  0x00000000800cca54 in vsnprintf (buf=buf@entry=0x881cbd38 "exception code: 5 , ", size=size@entry=1060, fmt=fmt@entry=0x800d4458 "exception code: %d , %s , epc %08x , ra %08lxn", args=args@entry=0x881cc188) at lib/vsprintf.c:710
#4  0x00000000800cca68 in vscnprintf (buf=buf@entry=0x881cbd38 "exception code: 5 , ", size=size@entry=1060, fmt=fmt@entry=0x800d4458 "exception code: %d , %s , epc %08x , ra %08lxn", args=args@entry=0x881cc188) at lib/vsprintf.c:717
#5  0x00000000800ccb50 in printf (fmt=fmt@entry=0x800d4458 "exception code: %d , %s , epc %08x , ra %08lxn") at lib/vsprintf.c:792
#6  0x000000008008a9f0 in _exit_trap (regs=<optimized out>, epc=2148315240, code=<optimized out>) at arch/riscv/lib/interrupts.c:92
#7  handle_trap (mcause=<optimized out>, epc=<optimized out>, regs=<optimized out>) at arch/riscv/lib/interrupts.c:55
#8  0x0000000080089b10 in trap_entry () at /hdd/trosinenko/fpga/freedom-u-sdk/HiFive_U-Boot/arch/riscv/cpu/HiFive/start.S:343
Backtrace stopped: frame did not save the PC

ਦਿਸਦਾ ਹੈ, _exit_trap ਆਈ ਹੋਈ ਅਪਵਾਦ ਬਾਰੇ ਡੀਬਗਿੰਗ ਜਾਣਕਾਰੀ ਪ੍ਰਦਾਨ ਕਰਨਾ ਚਾਹੁੰਦਾ ਹੈ, ਪਰ ਉਹ ਨਹੀਂ ਕਰ ਸਕਦਾ. ਇਸ ਲਈ, ਕਿਸੇ ਤਰ੍ਹਾਂ ਸਾਡੇ ਸਰੋਤ ਦੁਬਾਰਾ ਨਹੀਂ ਪ੍ਰਦਰਸ਼ਿਤ ਕੀਤੇ ਜਾਂਦੇ ਹਨ. set directories ../freedom-u-sdk/HiFive_U-Boot/ ਬਾਰੇ! ਹੁਣ ਪ੍ਰਦਰਸ਼ਿਤ!

ਖੈਰ, ਚਲੋ ਇਸਨੂੰ ਦੁਬਾਰਾ ਚਲਾਉਂਦੇ ਹਾਂ, ਅਤੇ ਸਟੈਕ ਟ੍ਰੇਸ ਤੋਂ ਅਸਲੀ ਸਮੱਸਿਆ ਦੇ ਕਾਰਨ ਨੂੰ ਵੇਖਦੇ ਹਾਂ ਜਿਸ ਨਾਲ ਪਹਿਲੀ ਗਲਤੀ ਹੋਈ ਸੀ (mcause == 5). ਜੇ ਮੈਂ ਸਹੀ ਤਰ੍ਹਾਂ ਸਮਝਦਾ ਹਾਂ ਕਿ ਕੀ ਲਿਖਿਆ ਹੈ ਇੱਥੇ ਪੰਨਾ 37 'ਤੇ, ਫਿਰ ਇਸ ਅਪਵਾਦ ਦਾ ਮਤਲਬ ਹੈ Load access fault. ਕਾਰਨ ਇੱਥੇ ਜਾਪਦਾ ਹੈ

arch/riscv/cpu/HiFive/start.S:

call_board_init_f:
    li  t0, -16
    li  t1, CONFIG_SYS_INIT_SP_ADDR
    and sp, t1, t0  /* force 16 byte alignment */

#ifdef CONFIG_DEBUG_UART
    jal debug_uart_init
#endif

call_board_init_f_0:
    mv  a0, sp
    jal board_init_f_alloc_reserve
    mv  sp, a0
    jal board_init_f_init_reserve

    mv  a0, zero    /* a0 <-- boot_flags = 0 */
    la t5, board_init_f
    jr t5       /* jump to board_init_f() */

$sp ਦਾ ਇੱਕੋ ਹੀ ਗਲਤ ਅਰਥ ਹੈ, ਅਤੇ ਅੰਦਰ board_init_f_init_reserve ਇੱਕ ਗਲਤੀ ਹੁੰਦੀ ਹੈ। ਅਜਿਹਾ ਲਗਦਾ ਹੈ ਕਿ ਇਹ ਦੋਸ਼ੀ ਹੈ: ਇੱਕ ਅਸਪਸ਼ਟ ਨਾਮ ਵਾਲਾ ਇੱਕ ਵੇਰੀਏਬਲ CONFIG_SYS_INIT_SP_ADDR. ਇਹ ਫਾਇਲ ਵਿੱਚ ਪਰਿਭਾਸ਼ਿਤ ਕੀਤਾ ਗਿਆ ਹੈ HiFive_U-Boot/include/configs/HiFive-U540.h. ਕਿਸੇ ਸਮੇਂ ਮੈਂ ਇਹ ਵੀ ਸੋਚਿਆ ਸੀ, ਹੋ ਸਕਦਾ ਹੈ, ਠੀਕ ਹੈ, ਮੈਨੂੰ ਪ੍ਰੋਸੈਸਰ ਲਈ ਇੱਕ ਬੂਟ ਲੋਡਰ ਜੋੜਨਾ ਚਾਹੀਦਾ ਹੈ - ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਪ੍ਰੋਸੈਸਰ ਨੂੰ ਥੋੜਾ ਜਿਹਾ ਠੀਕ ਕਰਨਾ ਸੌਖਾ ਹੋ ਜਾਵੇ? ਪਰ ਫਿਰ ਮੈਂ ਦੇਖਿਆ ਕਿ ਇਹ ਪੂਰੀ ਤਰ੍ਹਾਂ ਮੁਕੰਮਲ ਨਾ ਹੋਣ ਤੋਂ ਇੱਕ ਕਲਾਤਮਕ ਚੀਜ਼ ਵਰਗਾ ਸੀ#if 0-ਇੱਕ ਵੱਖਰੀ ਮੈਮੋਰੀ ਸੰਰਚਨਾ ਲਈ ਖਾਸ ਸੈਟਿੰਗਾਂ, ਅਤੇ ਤੁਸੀਂ ਅਜਿਹਾ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਸਕਦੇ ਹੋ:

diff --git a/include/configs/HiFive-U540.h b/include/configs/HiFive-U540.h
index ca89383..245542c 100644
--- a/include/configs/HiFive-U540.h
+++ b/include/configs/HiFive-U540.h
@@ -65,12 +65,9 @@
 #define CONFIG_SYS_SDRAM_BASE  PHYS_SDRAM_0
 #endif
 #if 1
-/*#define CONFIG_NR_DRAM_BANKS 1*/
+#define CONFIG_NR_DRAM_BANKS   1
 #define PHYS_SDRAM_0   0x80000000              /* SDRAM Bank #1 */
-#define PHYS_SDRAM_1   
-       (PHYS_SDRAM_0 + PHYS_SDRAM_0_SIZE)      /* SDRAM Bank #2 */
-#define PHYS_SDRAM_0_SIZE      0x80000000      /* 2 GB */
-#define PHYS_SDRAM_1_SIZE      0x10000000      /* 256 MB */
+#define PHYS_SDRAM_0_SIZE      0x40000000      /* 1 GB */
 #define CONFIG_SYS_SDRAM_BASE  PHYS_SDRAM_0
 #endif
 /*
@@ -81,7 +78,7 @@
 #define CONSOLE_ARG                            "console=ttyS0,115200 "

 /* Init Stack Pointer */
-#define CONFIG_SYS_INIT_SP_ADDR                (0x08000000 + 0x001D0000 - 
+#define CONFIG_SYS_INIT_SP_ADDR                (0x80000000 + 0x001D0000 - 
                                        GENERATED_GBL_DATA_SIZE)

 #define CONFIG_SYS_LOAD_ADDR           0xa0000000      /* partway up SDRAM */

ਕਿਸੇ ਸਮੇਂ ਬੈਸਾਖੀਆਂ ਦੀ ਗਿਣਤੀ ਤਕਨੀਕੀ ਫਾਸਟਨਰ ਇੱਕ ਨਾਜ਼ੁਕ ਬਿੰਦੂ 'ਤੇ ਪਹੁੰਚ ਗਿਆ ਹੈ. ਥੋੜਾ ਜਿਹਾ ਸੰਘਰਸ਼ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਮੈਨੂੰ ਆਪਣੇ ਬੋਰਡ ਲਈ ਸਹੀ ਪੋਰਟ ਬਣਾਉਣ ਦੀ ਜ਼ਰੂਰਤ ਆਈ. ਅਜਿਹਾ ਕਰਨ ਲਈ, ਸਾਨੂੰ ਸਾਡੀ ਸੰਰਚਨਾ ਦੇ ਅਨੁਕੂਲ ਹੋਣ ਲਈ ਕਈ ਫਾਈਲਾਂ ਨੂੰ ਕਾਪੀ ਅਤੇ ਐਡਜਸਟ ਕਰਨ ਦੀ ਲੋੜ ਹੈ।

ਖੈਰ, ਲਗਭਗ, ਇੱਥੇ ਇੱਕ ਛੋਟੀ ਜਿਹੀ ਸਾਰਣੀ ਹੈ

trosinenko@trosinenko-pc:/hdd/trosinenko/fpga/freedom-u-sdk/HiFive_U-Boot$ git show --name-status
commit 39cd67d59c16ac87b46b51ac1fb58f16f1eb1048 (HEAD -> zeowaa-1gb)
Author: Anatoly Trosinenko <anatoly.trosinenko@gmail.com>
Date:   Tue Jul 2 17:13:16 2019 +0300

    Initial support for Zeowaa A-E115FB board

M       arch/riscv/Kconfig
A       arch/riscv/cpu/zeowaa-1gb/Makefile
A       arch/riscv/cpu/zeowaa-1gb/cpu.c
A       arch/riscv/cpu/zeowaa-1gb/start.S
A       arch/riscv/cpu/zeowaa-1gb/timer.c
A       arch/riscv/cpu/zeowaa-1gb/u-boot.lds
M       arch/riscv/dts/Makefile
A       arch/riscv/dts/zeowaa-1gb.dts
A       board/Zeowaa/zeowaa-1gb/Kconfig
A       board/Zeowaa/zeowaa-1gb/MAINTAINERS
A       board/Zeowaa/zeowaa-1gb/Makefile
A       board/Zeowaa/zeowaa-1gb/Zeowaa-A-E115FB.c
A       configs/zeowaa-1gb_defconfig
A       include/configs/zeowaa-1gb.h

ਵਿੱਚ ਵੇਰਵੇ ਮਿਲ ਸਕਦੇ ਹਨ ਰਿਪੋਜ਼ਟਰੀਆਂ.

Как оказалось, на этой SiFive-овской плате регистры некоторых устройств имеют другие адреса. А ещё оказалось, что U-Boot конфигурируется уже знакомым по ядру Linux механизмом Kconfig — например, можно скомандовать make menuconfig, ਅਤੇ ਇੱਕ ਸੁਵਿਧਾਜਨਕ ਟੈਕਸਟ ਇੰਟਰਫੇਸ ਤੁਹਾਡੇ ਸਾਹਮਣੇ ਪ੍ਰਗਟ ਹੋਵੇਗਾ ਜੋ ਕਿ ਦੁਆਰਾ ਮਾਪਦੰਡਾਂ ਦਾ ਵਰਣਨ ਦਿਖਾ ਰਿਹਾ ਹੈ ? ਆਦਿ ਆਮ ਤੌਰ 'ਤੇ, ਦੋ ਬੋਰਡਾਂ ਦੇ ਵਰਣਨ ਤੋਂ ਤੀਜੇ ਦੇ ਵਰਣਨ ਨੂੰ ਇਕੱਠਾ ਕਰਨਾ, ਉਥੋਂ ਹਰ ਕਿਸਮ ਦੇ ਦਿਖਾਵੇ ਵਾਲੇ PLL ਪੁਨਰ-ਸੰਰਚਨਾ ਨੂੰ ਬਾਹਰ ਕੱਢਦਾ ਹੈ (ਜ਼ਾਹਰ ਤੌਰ 'ਤੇ, ਇਹ PCIe ਦੁਆਰਾ ਹੋਸਟ ਕੰਪਿਊਟਰ ਤੋਂ ਨਿਯੰਤਰਣ ਨਾਲ ਜੁੜਿਆ ਹੋਇਆ ਹੈ, ਪਰ ਇਹ ਨਿਸ਼ਚਿਤ ਨਹੀਂ ਹੈ) , ਮੈਨੂੰ ਕੁਝ ਫਰਮਵੇਅਰ ਪ੍ਰਾਪਤ ਹੋਏ, ਜਿਸ ਨੇ ਮੰਗਲ 'ਤੇ ਸਹੀ ਮੌਸਮ ਵਿੱਚ ਮੈਨੂੰ UART ਦੁਆਰਾ ਇੱਕ ਸੁਨੇਹਾ ਦਿੱਤਾ ਕਿ ਇਹ ਕਿਸ ਕਮਟ ਹੈਸ਼ ਤੋਂ ਕੰਪਾਇਲ ਕੀਤਾ ਗਿਆ ਸੀ, ਅਤੇ ਇਸ ਬਾਰੇ ਕਿ ਮੇਰੇ ਕੋਲ ਕਿੰਨਾ DRAM ਹੈ (ਪਰ ਮੈਂ ਖੁਦ ਇਹ ਜਾਣਕਾਰੀ ਹੈਡਰ ਵਿੱਚ ਲਿਖੀ ਹੈ)।

ਸਿਰਫ਼ ਅਫ਼ਸੋਸ ਦੀ ਗੱਲ ਇਹ ਹੈ ਕਿ ਇਸਦੇ ਬਾਅਦ ਬੋਰਡ ਨੇ ਆਮ ਤੌਰ 'ਤੇ ਪ੍ਰੋਸੈਸਰ JTAG ਦੁਆਰਾ ਜਵਾਬ ਦੇਣਾ ਬੰਦ ਕਰ ਦਿੱਤਾ, ਅਤੇ ਇੱਕ SD ਕਾਰਡ ਤੋਂ ਲੋਡ ਕਰਨਾ, ਅਫ਼ਸੋਸ, ਮੇਰੀ ਸੰਰਚਨਾ ਵਿੱਚ ਤੇਜ਼ ਨਹੀਂ ਹੈ। ਦੂਜੇ ਪਾਸੇ, ਕਈ ਵਾਰ BootROM ਇੱਕ ਸੁਨੇਹਾ ਦਿੰਦਾ ਹੈ ਕਿ ERROR, ਬੂਟ ਕਰਨ ਵਿੱਚ ਅਸਫਲ, ਅਤੇ ਯੂ-ਬੂਟ ਤੁਰੰਤ ਪੌਪ ਅੱਪ ਹੋ ਗਿਆ। ਇਹ ਉਦੋਂ ਸੀ ਜਦੋਂ ਇਹ ਮੇਰੇ 'ਤੇ ਆ ਗਿਆ: ਜ਼ਾਹਰ ਤੌਰ 'ਤੇ, FPGA ਵਿੱਚ ਬਿੱਟਸਟ੍ਰੀਮ ਨੂੰ ਰੀਬੂਟ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਮੈਮੋਰੀ ਮਿਟਦੀ ਨਹੀਂ ਹੈ, ਇਸ ਕੋਲ "ਅਨਟ੍ਰੇਨ" ਕਰਨ ਦਾ ਸਮਾਂ ਨਹੀਂ ਹੈ, ਆਦਿ. ਸੰਖੇਪ ਵਿੱਚ, ਤੁਸੀਂ ਸਿਰਫ਼ ਉਦੋਂ ਕਰ ਸਕਦੇ ਹੋ ਜਦੋਂ ਕੋਈ ਸੁਨੇਹਾ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ LOADING / ਡੀਬੱਗਰ ਅਤੇ ਕਮਾਂਡ ਨਾਲ ਜੁੜੋ set variable $pc=0x80089800, ਇਸ ਤਰ੍ਹਾਂ ਇਸ ਲੰਬੇ ਲੋਡਿੰਗ ਨੂੰ ਬਾਈਪਾਸ ਕਰਨਾ (ਬੇਸ਼ਕ, ਇਸ ਧਾਰਨਾ 'ਤੇ ਕਿ ਪਿਛਲੀ ਵਾਰ ਇਹ ਬਹੁਤ ਜਲਦੀ ਟੁੱਟ ਗਿਆ ਸੀ ਕਿ ਇਸ ਕੋਲ ਅਸਲ ਕੋਡ ਦੇ ਸਿਖਰ 'ਤੇ ਕੁਝ ਵੀ ਲੋਡ ਕਰਨ ਦਾ ਸਮਾਂ ਨਹੀਂ ਸੀ)।

ਵੈਸੇ, ਕੀ ਇਹ ਆਮ ਤੌਰ 'ਤੇ ਸਧਾਰਣ ਹੈ ਕਿ ਪ੍ਰੋਸੈਸਰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਫ੍ਰੀਜ਼ ਹੋ ਜਾਂਦਾ ਹੈ ਅਤੇ JTAG ਡੀਬਗਰ ਸੁਨੇਹਿਆਂ ਨਾਲ ਇਸ ਨਾਲ ਜੁੜ ਨਹੀਂ ਸਕਦਾ ਹੈ?

Error: unable to halt hart 0
Error:   dmcontrol=0x80000001
Error:   dmstatus =0x00030c82

ਇਸ ਲਈ, ਉਡੀਕ ਕਰੋ! ਮੈਂ ਇਸਨੂੰ ਪਹਿਲਾਂ ਹੀ ਦੇਖਿਆ ਹੈ! ਕੁਝ ਅਜਿਹਾ ਹੀ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਟਾਇਲਿੰਕ ਡੈੱਡਲਾਕ ਹੋ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਮੈਂ ਕਿਸੇ ਤਰ੍ਹਾਂ ਮੈਮੋਰੀ ਕੰਟਰੋਲਰ ਦੇ ਲੇਖਕ 'ਤੇ ਭਰੋਸਾ ਨਹੀਂ ਕਰਦਾ - ਮੈਂ ਇਸਨੂੰ ਆਪਣੇ ਆਪ ਲਿਖਿਆ... ਅਚਾਨਕ, ਕੰਟਰੋਲਰ ਨੂੰ ਸੰਪਾਦਿਤ ਕਰਨ ਤੋਂ ਬਾਅਦ ਪ੍ਰੋਸੈਸਰ ਦੇ ਪਹਿਲੇ ਸਫਲ ਪੁਨਰ ਨਿਰਮਾਣ ਤੋਂ ਬਾਅਦ, ਮੈਂ ਦੇਖਿਆ:

INIT
CMD0
CMD8
ACMD41
CMD58
CMD16
CMD18
LOADING
BOOT

U-Boot 2018.09-g39cd67d-dirty (Jul 03 2019 - 13:50:33 +0300)

DRAM:  1 GiB
MMC:
BEFORE LOAD ENVBEFORE FDTCONTROLADDRBEFORE LOADADDRIn:    serial
Out:   serial
Err:   serial
Hit any key to stop autoboot:  3

ਅੱਗੇ ਇਸ ਅਜੀਬ ਲਾਈਨ ਨੂੰ In: serial ਧਿਆਨ ਨਾ ਦਿਓ - ਮੈਂ ਇੱਕ ਹੈਂਗਿੰਗ ਪ੍ਰੋਸੈਸਰ 'ਤੇ ਇਹ ਸਮਝਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਿਹਾ ਸੀ ਕਿ ਕੀ ਇਹ ਵਾਤਾਵਰਣ ਨਾਲ ਸਹੀ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰਦਾ ਹੈ। ਤੁਹਾਡਾ ਕੀ ਮਤਲਬ ਹੈ, "ਇਹ ਦਸ ਮਿੰਟਾਂ ਤੋਂ ਇਸ ਤਰ੍ਹਾਂ ਲਟਕ ਰਿਹਾ ਹੈ"? ਘੱਟੋ-ਘੱਟ ਇਸ ਨੂੰ ਮੁੜ ਸਥਾਪਿਤ ਕਰਨ ਅਤੇ ਬੂਟ ਮੀਨੂ 'ਤੇ ਜਾਣ ਦਾ ਪ੍ਰਬੰਧ ਕੀਤਾ ਗਿਆ ਹੈ! ਇੱਕ ਛੋਟਾ ਜਿਹਾ ਵਿਗਾੜ: ਹਾਲਾਂਕਿ ਯੂ-ਬੂਟ SD ਕਾਰਡ ਤੋਂ ਪਹਿਲੇ 2^24 ਬਾਈਟਾਂ ਵਿੱਚ ਲੋਡ ਹੁੰਦਾ ਹੈ, ਜਦੋਂ ਇਹ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ, ਇਹ ਆਪਣੇ ਆਪ ਨੂੰ ਇੱਕ ਦੂਰ ਦੇ ਪਤੇ 'ਤੇ ਕਾਪੀ ਕਰਦਾ ਹੈ, ਜਾਂ ਤਾਂ ਸੰਰਚਨਾ ਸਿਰਲੇਖ ਵਿੱਚ ਲਿਖਿਆ ਜਾਂਦਾ ਹੈ, ਜਾਂ ਸਿਰਫ਼ RAM ਦੇ ਉੱਚੇ ਪਤਿਆਂ 'ਤੇ। , ਅਤੇ ELF ਰੀਲੋਕੇਸ਼ਨ -ਅੱਖਰ ਕਰਦਾ ਹੈ, ਅਤੇ ਉੱਥੇ ਕੰਟਰੋਲ ਟ੍ਰਾਂਸਫਰ ਕਰਦਾ ਹੈ। ਇਸ ਲਈ: ਅਜਿਹਾ ਲਗਦਾ ਹੈ ਕਿ ਅਸੀਂ ਇਸ ਪੱਧਰ ਨੂੰ ਪਾਸ ਕਰ ਲਿਆ ਹੈ ਅਤੇ ਇੱਕ ਬੋਨਸ ਪ੍ਰਾਪਤ ਕੀਤਾ ਹੈ ਕਿ ਪ੍ਰੋਸੈਸਰ ਉਸ ਤੋਂ ਬਾਅਦ ਕੱਸ ਕੇ ਨਹੀਂ ਲਟਕਿਆ.

ਤਾਂ ਟਾਈਮਰ ਕੰਮ ਕਿਉਂ ਨਹੀਂ ਕਰ ਰਿਹਾ? ਇੰਝ ਲੱਗਦਾ ਹੈ ਕਿ ਘੜੀ ਕਿਸੇ ਕਾਰਨ ਕੰਮ ਨਹੀਂ ਕਰ ਰਹੀ ਹੈ...

(gdb) x/x 0x0200bff8
0x200bff8:      0x00000000

ਜੇ ਤੁਸੀਂ ਤੀਰਾਂ ਨੂੰ ਹੱਥੀਂ ਮੋੜਦੇ ਹੋ ਤਾਂ ਕੀ ਹੋਵੇਗਾ?

(gdb) set variable *0x0200bff8=310000000
(gdb) c

ਫਿਰ:

Hit any key to stop autoboot:  0
MMC_SPI: 0 at 0:1 hz 20000000 mode 0

ਸਿੱਟਾ: ਘੜੀ ਟਿਕ ਨਹੀਂ ਰਹੀ ਹੈ। ਸ਼ਾਇਦ ਇਹੀ ਕਾਰਨ ਹੈ ਕਿ ਕੀਬੋਰਡ ਇਨਪੁਟ ਕੰਮ ਨਹੀਂ ਕਰਦਾ:

HiFive_U-Boot/cmd/bootmenu.c:

static void bootmenu_loop(struct bootmenu_data *menu,
        enum bootmenu_key *key, int *esc)
{
    int c;

    while (!tstc()) {
        WATCHDOG_RESET();
        mdelay(10);
    }

    c = getc();

    switch (*esc) {
    case 0:
        /* First char of ANSI escape sequence 'e' */
        if (c == 'e') {
            *esc = 1;
            *key = KEY_NONE;
        }
        break;
    case 1:
        /* Second char of ANSI '[' */
        if (c == '[') {
...

ਸਮੱਸਿਆ ਇਹ ਨਿਕਲੀ ਕਿ ਮੈਂ ਥੋੜਾ ਬਹੁਤ ਚਲਾਕ ਸੀ: ਮੈਂ ਪ੍ਰੋਸੈਸਰ ਸੰਰਚਨਾ ਵਿੱਚ ਕੁੰਜੀ ਜੋੜ ਦਿੱਤੀ:

  case DTSTimebase => BigInt(0)

... ਇਸ ਤੱਥ ਦੇ ਅਧਾਰ ਤੇ ਕਿ ਟਿੱਪਣੀ ਵਿੱਚ ਕਿਹਾ ਗਿਆ ਹੈ "ਜੇ ਤੁਸੀਂ ਨਹੀਂ ਜਾਣਦੇ, ਤਾਂ 0 ਛੱਡੋ।" ਅਤੇ ਸਭ ਦੇ ਬਾਅਦ WithNBigCores ਮੈਂ ਇਸਨੂੰ 1MHz 'ਤੇ ਸੈੱਟ ਕੀਤਾ ਹੈ (ਜਿਵੇਂ ਕਿ, ਇਸ ਨੂੰ ਯੂ-ਬੂਟ ਸੰਰਚਨਾ ਵਿੱਚ ਦਰਸਾਇਆ ਗਿਆ ਸੀ)। ਪਰ ਲਾਹਨਤ, ਮੈਂ ਸਾਫ਼-ਸੁਥਰਾ ਅਤੇ ਸੁਚੇਤ ਹਾਂ: ਮੈਨੂੰ ਉੱਥੇ ਨਹੀਂ ਪਤਾ, ਇੱਥੇ ਇਹ 25MHz ਹੈ! ਅੰਤ ਵਿੱਚ, ਕੁਝ ਵੀ ਕੰਮ ਨਹੀਂ ਕਰਦਾ. ਮੈਂ ਆਪਣੇ "ਸੁਧਾਰ" ਨੂੰ ਹਟਾ ਦਿੱਤਾ ਹੈ ਅਤੇ...

Hit any key to stop autoboot:  0
MMC_SPI: 0 at 0:1 hz 20000000 mode 0
## Unknown partition table type 0
libfdt fdt_path_offset() returned FDT_ERR_NOTFOUND
** No partition table - mmc 0 **
## Info: input data size = 34 = 0x22
Running uEnv.txt boot2...
## Error: "boot2" not defined
HiFive-Unleashed #

ਤੁਸੀਂ ਕਮਾਂਡਾਂ ਵੀ ਦਰਜ ਕਰ ਸਕਦੇ ਹੋ! ਉਦਾਹਰਨ ਲਈ, ਥੋੜਾ ਜਿਹਾ ਘੁੰਮਣ ਤੋਂ ਬਾਅਦ, ਤੁਸੀਂ ਅੰਤ ਵਿੱਚ ਦਾਖਲ ਹੋਣ ਦਾ ਅਨੁਮਾਨ ਲਗਾ ਸਕਦੇ ਹੋ mmc_spi 1 10000000 0; mmc part, SPI ਬਾਰੰਬਾਰਤਾ ਨੂੰ 20MHz ਤੋਂ 10MHz ਤੱਕ ਘਟਾ ਕੇ। ਕਿਉਂ? ਖੈਰ, 20MHz ਦੀ ਵੱਧ ਤੋਂ ਵੱਧ ਬਾਰੰਬਾਰਤਾ ਸੰਰਚਨਾ ਵਿੱਚ ਲਿਖੀ ਗਈ ਸੀ, ਅਤੇ ਇਹ ਅਜੇ ਵੀ ਉਥੇ ਲਿਖੀ ਗਈ ਹੈ. ਪਰ, ਜਿੱਥੋਂ ਤੱਕ ਮੈਂ ਸਮਝਦਾ ਹਾਂ, ਇੰਟਰਫੇਸ, ਘੱਟੋ-ਘੱਟ ਇੱਥੇ, ਇਸ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰਦੇ ਹਨ: ਕੋਡ ਹਾਰਡਵੇਅਰ ਯੂਨਿਟ (ਮੇਰਾ ਹਰ ਥਾਂ 25MHz ਹੈ) ਦੀ ਬਾਰੰਬਾਰਤਾ ਨੂੰ ਟੀਚੇ ਦੁਆਰਾ ਵੰਡਦਾ ਹੈ, ਅਤੇ ਨਤੀਜੇ ਵਜੋਂ ਮੁੱਲ ਨੂੰ ਅਨੁਸਾਰੀ ਨਿਯੰਤਰਣ ਵਿੱਚ ਇੱਕ ਵਿਭਾਜਕ ਵਜੋਂ ਸੈੱਟ ਕਰਦਾ ਹੈ। ਰਜਿਸਟਰ. ਸਮੱਸਿਆ ਇਹ ਹੈ ਕਿ ਜੇਕਰ 115200Hz UART ਲਈ ਲਗਭਗ ਲੋੜੀਂਦਾ ਹੈ, ਤਾਂ ਜੇਕਰ ਤੁਸੀਂ 25000000 ਨੂੰ 20000000 ਨਾਲ ਵੰਡਦੇ ਹੋ ਤਾਂ ਤੁਹਾਨੂੰ 1 ਮਿਲੇਗਾ, ਯਾਨੀ. ਇਹ 25MHz 'ਤੇ ਕੰਮ ਕਰੇਗਾ। ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਇਹ ਆਮ ਗੱਲ ਹੈ, ਪਰ ਜੇਕਰ ਪਾਬੰਦੀਆਂ ਸੈਟ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ, ਤਾਂ ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਕਿਸੇ ਨੂੰ ਇਸਦੀ ਲੋੜ ਹੈ (ਪਰ ਇਹ ਨਿਸ਼ਚਿਤ ਨਹੀਂ ਹੈ)... ਆਮ ਤੌਰ 'ਤੇ, ਇਸਨੂੰ ਸੈੱਟ ਕਰਨਾ ਅਤੇ ਅੱਗੇ ਵਧਣਾ ਆਸਾਨ ਹੈ - ਬਹੁਤ ਦੂਰ ਅਤੇ, ਹਾਏ, ਲੰਬੇ ਸਮੇਂ ਲਈ। 25MHz ਇੱਕ ਕੋਰ i9 ਨਹੀਂ ਹੈ।

ਕੰਸੋਲ ਆਉਟਪੁੱਟ

HiFive-Unleashed # env edit mmcsetup
edit: mmc_spi 1 10000000 0; mmc part
HiFive-Unleashed # boot
MMC_SPI: 1 at 0:1 hz 10000000 mode 0

Partition Map for MMC device 0  --   Partition Type: EFI

Part    Start LBA       End LBA         Name
        Attributes
        Type GUID
        Partition GUID
  1     0x00000800      0x0000ffde      "Vfat Boot"
        attrs:  0x0000000000000000
        type:   ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
        type:   data
        guid:   76bd71fd-1694-4ff3-8197-bfa81699c2fb
  2     0x00040800      0x002efaf4      "root"
        attrs:  0x0000000000000000
        type:   0fc63daf-8483-4772-8e79-3d69d8477de4
        type:   linux
        guid:   9f3adcc5-440c-4772-b7b7-283124f38bf3
  3     0x0000044c      0x000007e4      "uboot"
        attrs:  0x0000000000000000
        type:   5b193300-fc78-40cd-8002-e86c45580b47
        guid:   bb349257-0694-4e0f-9932-c801b4d76fa3
  4     0x00000400      0x0000044b      "uboot-env"
        attrs:  0x0000000000000000
        type:   a09354ac-cd63-11e8-9aff-70b3d592f0fa
        guid:   4db442d0-2109-435f-b858-be69629e7dbf
libfdt fdt_path_offset() returned FDT_ERR_NOTFOUND
2376 bytes read in 0 ms
Running uEnv.txt boot2...
15332118 bytes read in 0 ms
## Loading kernel from FIT Image at 90000000 ...
   Using 'config-1' configuration
   Trying 'bbl' kernel subimage
     Description:  BBL/SBI/riscv-pk
     Type:         Kernel Image
     Compression:  uncompressed
     Data Start:   0x900000d4
     Data Size:    74266 Bytes = 72.5 KiB
     Architecture: RISC-V
     OS:           Linux
     Load Address: 0x80000000
     Entry Point:  0x80000000
     Hash algo:    sha256
     Hash value:   28972571467c4ad0cf08a81d9cf92b9dffc5a7cb2e0cd12fdbb3216cf1f19cbd
   Verifying Hash Integrity ... sha256+ OK
## Loading fdt from FIT Image at 90000000 ...
   Using 'config-1' configuration
   Trying 'fdt' fdt subimage
     Description:  unavailable
     Type:         Flat Device Tree
     Compression:  uncompressed
     Data Start:   0x90e9d31c
     Data Size:    6911 Bytes = 6.7 KiB
     Architecture: RISC-V
     Load Address: 0x81f00000
     Hash algo:    sha256
     Hash value:   10b0244a5a9205357772ea1c4e135a4f882409262176d8c7191238cff65bb3a8
   Verifying Hash Integrity ... sha256+ OK
   Loading fdt from 0x90e9d31c to 0x81f00000
   Booting using the fdt blob at 0x81f00000
## Loading loadables from FIT Image at 90000000 ...
   Trying 'kernel' loadables subimage
     Description:  Linux kernel
     Type:         Kernel Image
     Compression:  uncompressed
     Data Start:   0x900123e8
     Data Size:    10781356 Bytes = 10.3 MiB
     Architecture: RISC-V
     OS:           Linux
     Load Address: 0x80200000
     Entry Point:  unavailable
     Hash algo:    sha256
     Hash value:   72a9847164f4efb2ac9bae736f86efe7e3772ab1f01ae275e427e2a5389c84f0
   Verifying Hash Integrity ... sha256+ OK
   Loading loadables from 0x900123e8 to 0x80200000
## Loading loadables from FIT Image at 90000000 ...
   Trying 'ramdisk' loadables subimage
     Description:  buildroot initramfs
     Type:         RAMDisk Image
     Compression:  gzip compressed
     Data Start:   0x90a5a780
     Data Size:    4467411 Bytes = 4.3 MiB
     Architecture: RISC-V
     OS:           Linux
     Load Address: 0x82000000
     Entry Point:  unavailable
     Hash algo:    sha256
     Hash value:   883dfd33ca047e3ac10d5667ffdef7b8005cac58b95055c2c2beda44bec49bd0
   Verifying Hash Integrity ... sha256+ OK
   Loading loadables from 0x90a5a780 to 0x82000000

ਠੀਕ ਹੈ, ਅਸੀਂ ਅਗਲੇ ਪੱਧਰ 'ਤੇ ਪਹੁੰਚ ਗਏ ਹਾਂ, ਪਰ ਇਹ ਅਜੇ ਵੀ ਠੰਢਾ ਹੈ। ਅਤੇ ਕਈ ਵਾਰ ਇਹ ਅਪਵਾਦਾਂ ਨੂੰ ਵੀ ਛਿੜਕਦਾ ਹੈ. ਤੁਸੀਂ ਨਿਸ਼ਚਿਤ ਪਤੇ 'ਤੇ ਕੋਡ ਦੀ ਉਡੀਕ ਵਿੱਚ ਪਏ ਰਹਿ ਕੇ mcause ਨੂੰ ਦੇਖ ਸਕਦੇ ਹੋ $pc ਅਤੇ ਬਾਅਦ ਵਿੱਚ si 'ਤੇ ਹੋਣਾ trap_entry. U-Boot ਹੈਂਡਲਰ ਖੁਦ ਸਿਰਫ mcause = 0..4 ਲਈ ਆਉਟਪੁੱਟ ਦੇ ਸਕਦਾ ਹੈ, ਇਸਲਈ ਇੱਕ ਗਲਤ ਬੂਟ ਵਿੱਚ ਫਸਣ ਲਈ ਤਿਆਰ ਹੋ ਜਾਓ। ਫਿਰ ਮੈਂ ਸੰਰਚਨਾ ਵਿੱਚ ਗਿਆ, ਇਹ ਦੇਖਣਾ ਸ਼ੁਰੂ ਕੀਤਾ ਕਿ ਮੈਂ ਕੀ ਬਦਲ ਰਿਹਾ ਹਾਂ, ਅਤੇ ਯਾਦ ਆਇਆ: ਉੱਥੇ ਵਿੱਚ conf/rvboot-fit.txt ਲਿਖਿਆ:

fitfile=image.fit
# below much match what's in FIT (ugha)

ਖੈਰ, ਚਲੋ ਸਾਰੀਆਂ ਫਾਈਲਾਂ ਨੂੰ ਪਾਲਣਾ ਵਿੱਚ ਲਿਆਉਂਦੇ ਹਾਂ, ਕਰਨਲ ਕਮਾਂਡ ਲਾਈਨ ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਦੀ ਚੀਜ਼ ਨਾਲ ਬਦਲਦੇ ਹਾਂ, ਕਿਉਂਕਿ ਇੱਥੇ ਸ਼ੱਕ ਹਨ ਕਿ SIF0 - ਇਹ PCIe ਦੁਆਰਾ ਕਿਤੇ ਆਉਟਪੁੱਟ ਹੈ:

-bootargs=console=ttySIF0,921600 debug
+bootargs=console=ttyS0,125200 debug

ਅਤੇ ਆਉ ਹੈਸ਼ਿੰਗ ਐਲਗੋਰਿਦਮ ਨੂੰ SHA-256 ਤੋਂ MD5 ਵਿੱਚ ਬਦਲੀਏ: ਮੈਨੂੰ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫਿਕ ਤਾਕਤ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ (ਖਾਸ ਕਰਕੇ ਜਦੋਂ ਡੀਬੱਗਿੰਗ ਕਰਦੇ ਹੋ), ਇਸ ਵਿੱਚ ਬਹੁਤ ਲੰਬਾ ਸਮਾਂ ਲੱਗਦਾ ਹੈ, ਅਤੇ ਲੋਡ ਕਰਨ ਦੌਰਾਨ ਇਕਸਾਰਤਾ ਦੀਆਂ ਗਲਤੀਆਂ ਨੂੰ ਫੜਨ ਲਈ, MD5 ਬਹੁਤ ਆਸਾਨ ਹੈ। ਅੰਤ ਦਾ ਨਤੀਜਾ ਕੀ ਹੈ? ਅਸੀਂ ਪਿਛਲੇ ਪੱਧਰ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਪੂਰਾ ਕਰਨਾ ਸ਼ੁਰੂ ਕੀਤਾ (ਸਧਾਰਨ ਹੈਸ਼ਿੰਗ ਦੇ ਕਾਰਨ), ਅਤੇ ਅਗਲਾ ਖੋਲ੍ਹਿਆ ਗਿਆ:

...
   Verifying Hash Integrity ... md5+ OK
   Loading loadables from 0x90a5a758 to 0x82000000
libfdt fdt_check_header(): FDT_ERR_BADMAGIC
chosen {
        linux,initrd-end = <0x00000000 0x83000000>;
        linux,initrd-start = <0x00000000 0x82000000>;
        riscv,kernel-end = <0x00000000 0x80a00000>;
        riscv,kernel-start = <0x00000000 0x80200000>;
        bootargs = "debug console=tty0 console=ttyS0,125200 root=/dev/mmcblk0p2 rootwait";
};
libfdt fdt_path_offset() returned FDT_ERR_NOTFOUND
chosen {
        linux,initrd-end = <0x00000000 0x83000000>;
        linux,initrd-start = <0x00000000 0x82000000>;
        riscv,kernel-end = <0x00000000 0x80a00000>;
        riscv,kernel-start = <0x00000000 0x80200000>;
        bootargs = "debug console=tty0 console=ttyS0,125200 root=/dev/mmcblk0p2 rootwait";
};
   Loading Kernel Image ... OK
Booting kernel in
3

ਪਰ ਘੜੀ ਟਿਕ ਨਹੀਂ ਰਹੀ...

(gdb) x/x 0x0200bff8
0x200bff8:      0x00000000

ਓਹੋ, ਅਜਿਹਾ ਲਗਦਾ ਹੈ ਕਿ ਘੜੀ ਨੂੰ ਠੀਕ ਕਰਨਾ ਇੱਕ ਪਲੇਸਬੋ ਬਣ ਗਿਆ, ਹਾਲਾਂਕਿ ਇਹ ਮੈਨੂੰ ਉਸ ਸਮੇਂ ਜਾਪਦਾ ਸੀ ਕਿ ਇਸਨੇ ਮਦਦ ਕੀਤੀ ਸੀ। ਨਹੀਂ, ਬੇਸ਼ਕ ਇਸ ਨੂੰ ਠੀਕ ਕਰਨ ਦੀ ਲੋੜ ਹੈ, ਪਰ ਆਓ ਪਹਿਲਾਂ ਤੀਰਾਂ ਨੂੰ ਹੱਥੀਂ ਮੋੜੀਏ ਅਤੇ ਵੇਖੀਏ ਕਿ ਕੀ ਹੁੰਦਾ ਹੈ:

0x00000000bff6dbb0 in ?? ()
(gdb) set variable *0x0200bff8=1000000
(gdb) c
Continuing.
^C
Program received signal SIGINT, Interrupt.
0x00000000bff6dbb0 in ?? ()
(gdb) set variable *0x0200bff8=2000000
(gdb) c
Continuing.
^C
Program received signal SIGINT, Interrupt.
0x00000000bff6dbb0 in ?? ()
(gdb) set variable *0x0200bff8=3000000
(gdb) c
Continuing.

ਇਸ ਦੌਰਾਨ…

   Loading Kernel Image ... OK
Booting kernel in
3
2
1
0
## Starting application at 0x80000000 ...

ਨਹੀਂ, ਮੈਂ ਘੜੀ ਨੂੰ ਸਵੈਚਲਿਤ ਕਰਾਂਗਾ - ਨਹੀਂ ਤਾਂ ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਉਹ ਉੱਥੇ ਟਾਈਮਰ ਨੂੰ ਕੈਲੀਬਰੇਟ ਕਰਨ ਦਾ ਫੈਸਲਾ ਕਰੇਗਾ!

ਇਸ ਦੌਰਾਨ, ਮੌਜੂਦਾ ਹਦਾਇਤਾਂ ਦਾ ਪਤਾ ਕਿਤੇ ਅੰਦਰ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ

0000000080001c20 <poweroff>:
    80001c20:   1141                    addi    sp,sp,-16
    80001c22:   e022                    sd      s0,0(sp)
    80001c24:   842a                    mv      s0,a0
    80001c26:   00005517                auipc   a0,0x5
    80001c2a:   0ca50513                addi    a0,a0,202 # 80006cf0 <softfloat_countLeadingZeros8+0x558>
    80001c2e:   e406                    sd      ra,8(sp)
    80001c30:   f7fff0ef                jal     ra,80001bae <printm>
    80001c34:   8522                    mv      a0,s0
    80001c36:   267000ef                jal     ra,8000269c <finisher_exit>
    80001c3a:   00010797                auipc   a5,0x10
    80001c3e:   41e78793                addi    a5,a5,1054 # 80012058 <htif>
    80001c42:   639c                    ld      a5,0(a5)
    80001c44:   c399                    beqz    a5,80001c4a <poweroff+0x2a>
    80001c46:   72c000ef                jal     ra,80002372 <htif_poweroff>
    80001c4a:   45a1                    li      a1,8
    80001c4c:   4501                    li      a0,0
    80001c4e:   dc7ff0ef                jal     ra,80001a14 <send_ipi_many>
    80001c52:   10500073                wfi
    80001c56:   bff5                    j       80001c52 <poweroff+0x32>

ਲੋਡ ਕੀਤੇ ਬਰਕਲੇ ਬੂਟ ਲੋਡਰ ਦੇ ਅੰਦਰ। ਵਿਅਕਤੀਗਤ ਤੌਰ 'ਤੇ, ਜੋ ਮੈਨੂੰ ਇਸ ਬਾਰੇ ਉਲਝਣ ਵਿੱਚ ਰੱਖਦਾ ਹੈ ਉਹ ਹੈ ਜ਼ਿਕਰ htif — ਹੋਸਟ ਇੰਟਰਫੇਸ ਕਰਨਲ ਦੇ ਟੀਥਰਡ ਲਾਂਚ ਲਈ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ (ਜੋ ਕਿ ਹੋਸਟ ਏਆਰਐਮ ਦੇ ਸਹਿਯੋਗ ਨਾਲ), ਮੈਂ ਸਟੈਂਡਅਲੋਨ ਮੰਨਿਆ ਹੈ। ਹਾਲਾਂਕਿ, ਜੇਕਰ ਤੁਹਾਨੂੰ ਸਰੋਤ ਕੋਡ ਵਿੱਚ ਇਹ ਫੰਕਸ਼ਨ ਮਿਲਦਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਦੇਖ ਸਕਦੇ ਹੋ ਕਿ ਹਰ ਚੀਜ਼ ਇੰਨੀ ਮਾੜੀ ਨਹੀਂ ਹੈ:

void poweroff(uint16_t code)
{
  printm("Power offrn");
  finisher_exit(code);
  if (htif) {
    htif_poweroff();
  } else {
    send_ipi_many(0, IPI_HALT);
    while (1) { asm volatile ("wfin"); }
  }
}

ਖੋਜ: ਘੜੀ ਸ਼ੁਰੂ ਕਰੋ

CLINT ਵਿੱਚ ਰਜਿਸਟਰਾਂ ਦੀ ਖੋਜ ਕਰਨਾ ਸਾਨੂੰ ਇਸ ਵੱਲ ਲੈ ਜਾਂਦਾ ਹੈ

    val io = IO(new Bundle {
      val rtcTick = Bool(INPUT)
    })

    val time = RegInit(UInt(0, width = timeWidth))
    when (io.rtcTick) { time := time + UInt(1) }

ਜੋ RTC ਨਾਲ ਜੁੜਦਾ ਹੈ, ਜਾਂ ਰਹੱਸਮਈ MockAON ਨਾਲ, ਜਿਸ ਬਾਰੇ ਮੈਂ ਸ਼ੁਰੂ ਵਿੱਚ ਸੋਚਿਆ ਸੀ: "ਤਾਂ, ਸਾਡੇ ਕੋਲ ਇੱਥੇ ਕੀ ਹੈ? ਅਸਪਸ਼ਟ? ਚਲੋ ਇਸਨੂੰ ਬੰਦ ਕਰੀਏ!" ਕਿਉਂਕਿ ਮੈਨੂੰ ਅਜੇ ਵੀ ਸਮਝ ਨਹੀਂ ਆਉਂਦੀ ਕਿ ਉੱਥੇ ਕਿਸ ਕਿਸਮ ਦਾ ਘੜੀ ਦਾ ਜਾਦੂ ਚੱਲ ਰਿਹਾ ਹੈ, ਇਸ ਲਈ ਮੈਂ ਇਸ ਤਰਕ ਨੂੰ ਦੁਬਾਰਾ ਲਾਗੂ ਕਰਾਂਗਾ System.scala:

  val rtcDivider = RegInit(0.asUInt(16.W)) // на всякий случай поддержу до 16ГГц, я оптимист :)
  val mhzInt = p(DevKitFPGAFrequencyKey).toInt
  // Преположим, частота равна целому числу мегагерц
  rtcDivider := Mux(rtcDivider === (mhzInt - 1).U, 0.U, rtcDivider + 1.U)
  outer.clintOpt.foreach { clint =>
    clint.module.io.rtcTick := rtcDivider === 0.U
  }

Пробираясь к Linux ਕਰਨਲ

ਇੱਥੇ ਕਹਾਣੀ ਪਹਿਲਾਂ ਹੀ ਖਿੱਚੀ ਜਾ ਚੁੱਕੀ ਹੈ ਅਤੇ ਥੋੜੀ ਇਕਸਾਰ ਹੋ ਗਈ ਹੈ, ਇਸ ਲਈ ਮੈਂ ਇਸਨੂੰ ਉੱਪਰ ਤੋਂ ਹੇਠਾਂ ਵਰਣਨ ਕਰਾਂਗਾ:

BBL ਨੇ FDT ਦੀ ਮੌਜੂਦਗੀ ਮੰਨੀ 0xF0000000, ਪਰ ਮੈਂ ਇਸਨੂੰ ਪਹਿਲਾਂ ਹੀ ਠੀਕ ਕਰ ਦਿੱਤਾ ਹੈ! ਖੈਰ, ਚਲੋ ਦੁਬਾਰਾ ਦੇਖੀਏ... ਇਸ ਵਿੱਚ ਮਿਲਿਆ HiFive_U-Boot/arch/riscv/lib/boot.c, ਦੁਆਰਾ ਬਦਲਿਆ ਗਿਆ 0x81F00000, ਯੂ-ਬੂਟ ਬੂਟ ਸੰਰਚਨਾ ਵਿੱਚ ਦਿੱਤਾ ਗਿਆ ਹੈ।

ਫਿਰ ਬੀਬੀਐਲ ਨੇ ਸ਼ਿਕਾਇਤ ਕੀਤੀ ਕਿ ਯਾਦਦਾਸ਼ਤ ਨਹੀਂ ਹੈ। ਮੇਰਾ ਮਾਰਗ ਫੰਕਸ਼ਨ ਵਿੱਚ ਪਿਆ mem_prop, ਕੀ ਵਿੱਚ riscv-pk/machine/fdt.c: ਉੱਥੋਂ ਮੈਂ ਸਿੱਖਿਆ ਕਿ ਤੁਹਾਨੂੰ fdt ram node ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਮਾਰਕ ਕਰਨ ਦੀ ਲੋੜ ਹੈ device_type = "memory" - ਫਿਰ, ਸ਼ਾਇਦ, ਪ੍ਰੋਸੈਸਰ ਜਨਰੇਟਰ ਨੂੰ ਠੀਕ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਹੋਏਗੀ, ਪਰ ਹੁਣ ਲਈ ਮੈਂ ਇਸਨੂੰ ਸਿਰਫ ਹੱਥੀਂ ਲਿਖਾਂਗਾ - ਕਿਸੇ ਵੀ ਤਰ੍ਹਾਂ, ਮੈਂ ਇਸ ਫਾਈਲ ਨੂੰ ਹੱਥੀਂ ਟ੍ਰਾਂਸਫਰ ਕੀਤਾ ਹੈ.

ਹੁਣ ਮੈਨੂੰ ਸੁਨੇਹਾ ਮਿਲਿਆ (ਕੈਰੇਜ ਰਿਟਰਨ ਦੇ ਨਾਲ, ਫਾਰਮੈਟ ਕੀਤੇ ਰੂਪ ਵਿੱਚ ਪ੍ਰਦਾਨ ਕੀਤਾ ਗਿਆ):

This is bbl's dummy_payload.  To boot a real kernel, reconfigure bbl
with the flag --with-payload=PATH, then rebuild bbl. Alternatively,
bbl can be used in firmware-only mode by adding device-tree nodes
for an external payload and use QEMU's -bios and -kernel options.

ਅਜਿਹਾ ਲਗਦਾ ਹੈ ਕਿ ਵਿਕਲਪ ਲੋੜ ਅਨੁਸਾਰ ਦਰਸਾਏ ਗਏ ਹਨ riscv,kernel-start и riscv,kernel-end DTB ਵਿੱਚ, ਪਰ ਜ਼ੀਰੋ ਪਾਰਸ ਕੀਤੇ ਗਏ ਹਨ। ਡੀਬੱਗਿੰਗ query_chosen ਨੇ ਦਿਖਾਇਆ ਕਿ BBL ਇੱਕ 32-ਬਿੱਟ ਐਡਰੈੱਸ ਨੂੰ ਪਾਰਸ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਿਹਾ ਹੈ, ਪਰ ਇਹ ਇੱਕ ਜੋੜਾ ਵਿੱਚ ਆਉਂਦਾ ਹੈ <0x0 0xADDR>, ਅਤੇ ਪਹਿਲਾ ਮੁੱਲ ਘੱਟ ਤੋਂ ਘੱਟ ਮਹੱਤਵਪੂਰਨ ਬਿੱਟ ਜਾਪਦਾ ਹੈ। ਸੈਕਸ਼ਨ ਵਿੱਚ ਸ਼ਾਮਲ ਕੀਤਾ ਗਿਆ chosen

chosen {
      #address-cells = <1>;
      #size-cells = <0>;
      ...
}

ਅਤੇ ਮੁੱਲਾਂ ਦੀ ਪੀੜ੍ਹੀ ਨੂੰ ਠੀਕ ਕੀਤਾ: ਜੋੜੋ ਨਾ 0x0 ਪਹਿਲਾ ਤੱਤ.

ਇਹ 100500 ਸਧਾਰਨ ਕਦਮ ਪੈਂਗੁਇਨ ਦੇ ਡਿੱਗਦੇ ਨੂੰ ਦੇਖਣਾ ਆਸਾਨ ਬਣਾ ਦੇਣਗੇ:

ਲੁਕਿਆ ਹੋਇਆ ਟੈਕਸਟ

   Verifying Hash Integrity ... md5+ OK
   Loading loadables from 0x90a5a758 to 0x82000000
libfdt fdt_check_header(): FDT_ERR_BADMAGIC
chosen {
        linux,initrd-end = <0x83000000>;
        linux,initrd-start = <0x82000000>;
        riscv,kernel-end = <0x80a00000>;
        riscv,kernel-start = <0x80200000>;
        #address-cells = <0x00000001>;
        #size-cells = <0x00000000>;
        bootargs = "debug console=tty0 console=ttyS0,125200 root=/dev/mmcblk0p2 rootwait";
        stdout-path = "uart0:38400n8";
};
libfdt fdt_path_offset() returned FDT_ERR_NOTFOUND
chosen {
        linux,initrd-end = <0x83000000>;
        linux,initrd-start = <0x82000000>;
        riscv,kernel-end = <0x80a00000>;
        riscv,kernel-start = <0x80200000>;
        #address-cells = <0x00000001>;
        #size-cells = <0x00000000>;
        bootargs = "debug console=tty0 console=ttyS0,125200 root=/dev/mmcblk0p2 rootwait";
        stdout-path = "uart0:38400n8";
};
   Loading Kernel Image ... OK
Booting kernel in
3
2
1
0
## Starting application at 0x80000000 ...
bbl loader

                SIFIVE, INC.

         5555555555555555555555555
        5555                   5555
       5555                     5555
      5555                       5555
     5555       5555555555555555555555
    5555       555555555555555555555555
   5555                             5555
  5555                               5555
 5555                                 5555
5555555555555555555555555555          55555
 55555           555555555           55555
   55555           55555           55555
     55555           5           55555
       55555                   55555
         55555               55555
           55555           55555
             55555       55555
               55555   55555
                 555555555
                   55555
                     5

           SiFive RISC-V Core IP
[    0.000000] OF: fdt: Ignoring memory range 0x80000000 - 0x80200000
[    0.000000] Linux version 4.19.0-sifive-1+ (trosinenko@trosinenko-pc) (gcc version 8.3.0 (Buildroot 2019.02-07449-g4eddd28f99)) #1 SMP Wed Jul 3 21:29:21 MSK 2019
[    0.000000] bootconsole [early0] enabled
[    0.000000] Initial ramdisk at: 0x(____ptrval____) (16777216 bytes)
[    0.000000] Zone ranges:
[    0.000000]   DMA32    [mem 0x0000000080200000-0x00000000bfffffff]
[    0.000000]   Normal   [mem 0x00000000c0000000-0x00000bffffffffff]
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x0000000080200000-0x00000000bfffffff]
[    0.000000] Initmem setup node 0 [mem 0x0000000080200000-0x00000000bfffffff]
[    0.000000] On node 0 totalpages: 261632
[    0.000000]   DMA32 zone: 3577 pages used for memmap
[    0.000000]   DMA32 zone: 0 pages reserved
[    0.000000]   DMA32 zone: 261632 pages, LIFO batch:63
[    0.000000] software IO TLB: mapped [mem 0xbb1fc000-0xbf1fc000] (64MB)

(ਲੋਗੋ BBL ਦੁਆਰਾ ਪ੍ਰਦਰਸ਼ਿਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਟਾਈਮਸਟੈਂਪ ਵਾਲਾ ਇੱਕ ਕਰਨਲ ਦੁਆਰਾ ਪ੍ਰਦਰਸ਼ਿਤ ਹੁੰਦਾ ਹੈ)।

ਖੁਸ਼ਕਿਸਮਤੀ ਨਾਲ, ਮੈਨੂੰ ਨਹੀਂ ਪਤਾ ਕਿ ਇਹ ਹਰ ਜਗ੍ਹਾ ਕਿਵੇਂ ਹੈ, ਪਰ RocketChip 'ਤੇ, ਜਦੋਂ ਤੁਸੀਂ JTAG ਰਾਹੀਂ ਇੱਕ ਡੀਬਗਰ ਨੂੰ ਜੋੜਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਬਾਕਸ ਦੇ ਬਾਹਰ ਜਾਲ ਫੜ ਸਕਦੇ ਹੋ - ਡੀਬਗਰ ਇਸ ਸਮੇਂ ਬਿਲਕੁਲ ਬੰਦ ਹੋ ਜਾਵੇਗਾ।

Program received signal SIGTRAP, Trace/breakpoint trap.
0xffffffe0000024ca in ?? ()
(gdb) bt
#0  0xffffffe0000024ca in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) file work/linux/vmlinux
A program is being debugged already.
Are you sure you want to change the file? (y or n) y
Reading symbols from work/linux/vmlinux...done.
(gdb) bt
#0  0xffffffe0000024ca in setup_smp () at /hdd/trosinenko/fpga/freedom-u-sdk/linux/arch/riscv/kernel/smpboot.c:75
#1  0x0000000000000000 in ?? ()
Backtrace stopped: frame did not save the PC

ਆਜ਼ਾਦੀ-u-sdk/linux/arch/riscv/kernel/smpboot.c:

void __init setup_smp(void)
{
    struct device_node *dn = NULL;
    int hart;
    bool found_boot_cpu = false;
    int cpuid = 1;

    while ((dn = of_find_node_by_type(dn, "cpu"))) {
        hart = riscv_of_processor_hartid(dn);
        if (hart < 0)
            continue;

        if (hart == cpuid_to_hartid_map(0)) {
            BUG_ON(found_boot_cpu);
            found_boot_cpu = 1;
            continue;
        }

        cpuid_to_hartid_map(cpuid) = hart;
        set_cpu_possible(cpuid, true);
        set_cpu_present(cpuid, true);
        cpuid++;
    }

    BUG_ON(!found_boot_cpu); // < ВЫ НАХОДИТЕСЬ ЗДЕСЬ
}

ਜਿਵੇਂ ਕਿ ਪੁਰਾਣੇ ਚੁਟਕਲੇ ਨੇ ਕਿਹਾ, CPU ਨਹੀਂ ਮਿਲਿਆ, ਸਾਫਟਵੇਅਰ ਇਮੂਲੇਸ਼ਨ ਚੱਲ ਰਿਹਾ ਹੈ. ਠੀਕ ਹੈ, ਜਾਂ ਨਹੀਂ ਚੱਲ ਰਿਹਾ. ਇੱਕ ਸਿੰਗਲ ਪ੍ਰੋਸੈਸਰ ਕੋਰ ਵਿੱਚ ਗੁਆਚ ਗਿਆ।

/* The lucky hart to first increment this variable will boot the other cores */
atomic_t hart_lottery;
unsigned long boot_cpu_hartid;

ਵਿੱਚ ਵਧੀਆ ਟਿੱਪਣੀ linux/arch/riscv/kernel/setup.c - ਟੌਮ ਸੌਅਰ ਵਿਧੀ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਵਾੜ ਦੀ ਇੱਕ ਕਿਸਮ ਦੀ ਪੇਂਟਿੰਗ. ਆਮ ਤੌਰ 'ਤੇ, ਅੱਜ ਕਿਸੇ ਕਾਰਨ ਕਰਕੇ ਕੋਈ ਵਿਜੇਤਾ ਨਹੀਂ ਸਨ, ਇਨਾਮ ਅਗਲੇ ਡਰਾਅ ਵਿੱਚ ਟ੍ਰਾਂਸਫਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ...

ਇੱਥੇ ਮੈਂ ਪਹਿਲਾਂ ਹੀ ਲੰਬੇ ਲੇਖ ਨੂੰ ਖਤਮ ਕਰਨ ਦਾ ਪ੍ਰਸਤਾਵ ਕਰਦਾ ਹਾਂ.

ਨੂੰ ਜਾਰੀ ਰੱਖਿਆ ਜਾਵੇਗਾ. ਇੱਕ ਚਲਾਕ ਬੱਗ ਨਾਲ ਲੜਾਈ ਹੋਵੇਗੀ ਜੋ ਛੁਪਾਉਣ ਦਾ ਪ੍ਰਬੰਧ ਕਰਦਾ ਹੈ ਜੇਕਰ ਤੁਸੀਂ ਹੌਲੀ-ਹੌਲੀ ਸਿੰਗਲ ਸਟੈਪ ਨਾਲ ਇਸ 'ਤੇ ਚੜ੍ਹ ਜਾਂਦੇ ਹੋ।

ਟੈਕਸਟ ਡਾਊਨਲੋਡ ਸਕ੍ਰੀਨਕਾਸਟ (ਬਾਹਰੀ ਲਿੰਕ):

ਸਰੋਤ: www.habr.com