search

litex-hub / linux-on-litex-vexriscv

Linux on LiteX-VexRiscv
BSD 2-Clause "Simplified" License
551 stars 174 forks source link

Could not fetch special ref '680e9975fbd8c2662d5fdeca3d5eca427b175ef2'; #310

Closed 280185386 closed 1 year ago

280185386 commented 1 year ago

when build buildroot :

GIT_DIR=/home/eda/litex/buildroot/dl/linux/git/.git git fetch origin -t remote: Enumerating objects: 4646, done. remote: Counting objects: 100% (136/136), done. remote: Total 4646 (delta 136), reused 136 (delta 136), pack-reused 4510 Receiving objects: 100% (4646/4646), 20.91 MiB | 6.22 MiB/s, done. Resolving deltas: 100% (320/320), completed with 74 local objects. From https://github.com/litex-hub/linux

wget --passive-ftp -nd -t 3 -O '/home/eda/litex/buildroot/output/build/.linux-680e9975fbd8c2662d5fdeca3d5eca427b175ef2-br1.tar.gz.qKOb2D/output' 'http://sources.buildroot.net/linux-680e9975fbd8c2662d5fdeca3d5eca427b175ef2-br1.tar.gz' --2022-10-12 02:20:53-- http://sources.buildroot.net/linux-680e9975fbd8c2662d5fdeca3d5eca427b175ef2-br1.tar.gz Resolving sources.buildroot.net (sources.buildroot.net)... 104.26.1.37, 104.26.0.37, 172.67.72.56, ... Connecting to sources.buildroot.net (sources.buildroot.net)|104.26.1.37|:80... connected. HTTP request sent, awaiting response... 404 Not Found 2022-10-12 02:20:54 ERROR 404: Not Found.

package/pkg-generic.mk:185: recipe for target '/home/eda/litex/buildroot/output/build/linux-headers-680e9975fbd8c2662d5fdeca3d5eca427b175ef2/.stamp_downloaded' failed make[1]: [/home/eda/litex/buildroot/output/build/linux-headers-680e9975fbd8c2662d5fdeca3d5eca427b175ef2/.stamp_downloaded] Error 1 Makefile:84: recipe for target '_all' failed make: [_all] Error 2

how to fix this error ? thank U

280185386 commented 1 year ago

/litex/linux-on-litex-vexriscv/buildroot/configs/litex_vexriscv_defconfig :

Kernel (litex-rebase branch)

BR2_LINUX_KERNEL=y BR2_LINUX_KERNEL_CUSTOM_GIT=y BR2_LINUX_KERNEL_CUSTOM_REPO_URL="https://github.com/litex-hub/linux.git" BR2_LINUX_KERNEL_CUSTOM_REPO_VERSION="680e9975fbd8c2662d5fdeca3d5eca427b175ef2" BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG=y BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="$(BR2_EXTERNAL_LITEX_VEXRISCV_PATH)/board/litex_vexriscv/linux.config" BR2_LINUX_KERNEL_IMAGE=y

BR2_LINUX_KERNEL_CUSTOM_REPO_VERSION should be ?

Dolu1990 commented 1 year ago

Hi, ahh likely there was some destructive operation made on the linux fork repo.

So overall, linux 5.14 should be good, but i realy have no idea where is what in which branch.

@gsomlo Do you know who to ping for this kind of issue (Litex linux fork branch management) ?

gsomlo commented 1 year ago

I only "curate" the litex-rebase branch in github/litex-hub. I also keep the master branch sync-ed up with torvalds/linux, on a roughly daily basis. The litex-rebase branch is being constantly rebased on top of torvalds/linux, so at any given time it should be "upstream master" plus the (at this time, 21) out-of-tree LiteX specific patches.

Not sure how well (or poorly) that meshes with the workflow under discussion in this issue, but here's what I do when I update:

git fetch upstream
git checkout master
git merge upstream/master
git push
git checkout litex-rebase
git rebase master
<build and test on my litex+rocket board(s) -- no vexriscv tests as I don't have a handy initrd, or bitstream>
git push origin/litex-rebase --force

So, on a typical day, litex-rebase is 0 commits behind, and 21(-ish) commits ahead, of torvalds/linux (see here)

Hope this helps clear things up...

Dolu1990 commented 1 year ago

Ahhh i see, so the issue maybe not having a stable linux version to pull from may :

I mean, there is so many thing which can break in the flow, i'm personnaly trying to freeze things as much as possible ^^ (fear fear fear)

gsomlo commented 1 year ago

On Fri, Oct 14, 2022 at 08:02:03AM -0700, Dolu1990 wrote:

I mean, there is so many thing which can break in the flow, i'm personnaly trying to freeze things as much as possible

We could, occasionally, snapshot some branch (maybe even litex-rebase) at a point where it works well with whatever downstream we care about, e.g.:

git checkout litex-rebase
git checkout -b litex-rebase-frozen-v00X
git push origin/litex-rebase-frozen-v00X

and then use frozen-v00X in the downstream project, until such time as it is convenient (or necessary) to repeat the above steps with Y=X+1, and switch downstream to frozen-v00Y...

My original (and current) goal for litex-rebase was to track upstream Linux and have LiteX specific drivers in a form that is as close to "ready for upstream submission" as possible.

And then submit them (or encourage/enable their developer(s) to submit) upstream as soon as they're considered "stable" and "ready".

I wanted not to have to hunt for drivers in (very) old kernel branches and then have to worry about them no longer "fitting" a newer/current kernel. This way, they're always re-based on top of the "latest shiny", and if anything breaks during build, we can tell, and we can keep up with the evolving kernel.

Personally, I am constantly testing sata and mmc out-of-tree patches, and I'm hoping the rest (vexriscv-specific, video, etc.) are getting some testing by other members of the LiteX community... :)

But if you want something that does not change, I guess snapshotting might be worth considering...

Dolu1990 commented 1 year ago

And then submit them (or encourage/enable their developer(s) to submit) upstream as soon as they're considered "stable" and "ready".

I wanted not to have to hunt for drivers in (very) old kernel branches and then have to worry about them no longer "fitting" a newer/current kernel. This way, they're always re-based on top of the "latest shiny", and if anything breaks during build, we can tell, and we can keep up with the evolving kernel.

I understand the issue.

I'm hoping the rest (vexriscv-specific, video, etc.) are getting some testing by other members of the LiteX community... :)

Man power is kinda the issue. Not many poeple cover both hardware / software aspect, it take time to verify the stability of a new build, always stuff todo ^^

We could, occasionally, snapshot some branch (maybe even litex-rebase) at a point where it works well with whatever downstream we care about, e.g.: But if you want something that does not change, I guess snapshotting might be worth considering...

Seems great to me :)

280185386 commented 1 year ago

Is there an effecctive fixed step to guide me to build Linux files ? I have tried many times with buildroot,but all failed . thanks

280185386 commented 1 year ago

I installed gcc 11 and xpack-riscv-none-elf-gcc-12.2.0-1 on ubuntu18.04 ,then compile the buildroot , get the same error shown as before

Dolu1990 commented 1 year ago

Buildroot will compile and install its own GCC version, so you don't need to have xpack preinstalled for it.

./arch/riscv/include/asm/vdso/gettimeofday.h:71: Error: unrecognized opcode csrr a5,0xc01'

that's a paine, were you using buildroot upstream ? Maybe, try with buildroot 9ef54b7d instead, that one was working for me a long time ago.

Dolu1990 commented 1 year ago

@280185386 Which git hash of linux did you used ?

Dolu1990 commented 1 year ago

@gsomlo Where should the litex linux issue be open ?

(with GCC11 + https://github.com/litex-hub/linux/commit/3057c40d89dd6d4b01cf50b9c770e58705063df0 i got some type error in the litex-spiflash driver: )

drivers/mtd/spi-nor/litex-spiflash.c:305:22: error: initialization of ‘int (*)(struct spi_nor *, u8,  const u8 *, size_t)’ {aka ‘int (*)(struct spi_nor *, unsigned char,  const unsigned char *, long unsigned int)’} from incompatible pointer type ‘ssize_t (*)(struct spi_nor *, u8,  const u8 *, size_t)’ {aka ‘long int (*)(struct spi_nor *, unsigned char,  const unsigned char *, long unsigned int)’} [-Werror=incompatible-pointer-types]
  305 |         .write_reg = spi_flash_nor_write_reg,
      |
Dolu1990 commented 1 year ago

Ahh note, that's for RV64.

Dolu1990 commented 1 year ago

Betwwen 5.14 and 6.1 they added the CONFIG_NONPORTABLE, which has to be set to y, else linux just compile for 64 bits instead of 32 bits XDXD

Dolu1990 commented 1 year ago

@gsomlo @280185386 i pushed a fix based on the linux litex-rebase branch (linux 6.1) I forked the litex-linux repo just to have a stable thing. It build with buildroot upstream the buildroot defconfig had to use GCC11 to avoid the CSR issue. the linux defconfig had to include CONFIG_NONPORTABLE=y in order to allow 32 bits compilation.

gsomlo commented 1 year ago

On Mon, Oct 24, 2022 at 09:38:38AM -0700, Dolu1990 wrote:

I forked the litex-linux repo just to have a stable thing. It build with buildroot upstream the buildroot defconfig had to use GCC11 to avoid the CSR issue. the linux defconfig had to include CONFIG_NONPORTABLE=y in order to allow 32 bits compilation.

Sounds good. So far I see nothing that needs to be considered for adoption by the litex-rebase branch (or upstream linux).

Aside from (maybe) a vexriscv-specific defconfig (I have one for rocket in litex-rebase, but I assume the vexriscv specific ones are kept and maintained elsewhere -- which is totally OK with me :)